From joelja@bogus.com Tue Oct 1 08:41:21 2013 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 C2A3C21E81B9 for ; Tue, 1 Oct 2013 08:40:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.904 X-Spam-Level: X-Spam-Status: No, score=-101.904 tagged_above=-999 required=5 tests=[AWL=-0.695, BAYES_00=-2.599, PLING_QUERY=1.39, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fAwGVHfKHO6R for ; Tue, 1 Oct 2013 08:40:58 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id F0EEC21F9A44 for ; Tue, 1 Oct 2013 08:40:46 -0700 (PDT) Received: from [192.168.1.8] (c-50-174-18-221.hsd1.ca.comcast.net [50.174.18.221]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r91FehuB012465 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 1 Oct 2013 15:40:44 GMT (envelope-from joelja@bogus.com) Content-Type: multipart/signed; boundary="Apple-Mail=_21F1413B-F9E1-4186-93CC-7AB04D95C003"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: joel jaeggli In-Reply-To: <5249A238.10500@cisco.com> Date: Tue, 1 Oct 2013 08:40:41 -0700 Message-Id: References: <791AD3077F94194BB2BDD13565B6295D55726BC7@DAPHNIS.office.hd> <5249A238.10500@cisco.com> To: Benoit Claise X-Mailer: Apple Mail (2.1510) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Tue, 01 Oct 2013 15:40:44 +0000 (UTC) Cc: "eman@ietf.org" , Ted Ghose Subject: Re: [eman] Power States != Charging States? 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, 01 Oct 2013 15:41:21 -0000 --Apple-Mail=_21F1413B-F9E1-4186-93CC-7AB04D95C003 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Sep 30, 2013, at 9:09 AM, Benoit Claise wrote: > Hi Ted, >> Hi Rolf >>=20 >> +1 >>=20 >> Thanks for clearly articulating the points. I totally agree the = charging state should be orthogonal to power state. >>=20 >> My position is that battery should _also_ have power state indicating = if it is receiving power (charging) or giving power to the electrical = network, and how much > That makes sense. >=20 > Regards, Benoit In my limited experience with battery controllers batteries are either: charging discharging full empty in all cases state of charge, e.g. capacity is germain. >>=20 >> This will be useful to account for all the power source and sink >>=20 >> Best >>=20 >> -tg- >> Sent from my iPhone >>=20 >>> On Sep 25, 2013, at 6:18 AM, Rolf Winter = wrote: >>>=20 >>> Hi, >>>=20 >>> this thread attempts to close an open issue in the framework = document (v10) where section 9.1.4 reads: >>>=20 >>> 9.1.4. Batteries Power State Set >>>=20 >>> Batteries have operational and administrational states that >>> could be represented as a power state set. Since the work >>> for battery management is parallel to this document, we are >>> not proposing any Power State Sets for batteries at this >>> time. >>>=20 >>> I argue that batteries have no power states given the power state = definition: >>>=20 >>> A Power State is a condition or mode of a device that >>> broadly characterizes its capabilities, power >>> consumption, and responsiveness to input. >>>=20 >>> There are charging states currently defined in the battery MIB, = which seem to be orthogonal to power states. I guess a universal power = state set is "on" and "off". Any device can really be in one of these = two modes. Even a simple light bulb. What would be "on" for a battery? = Maybe charging because it receives energy (like any other device that is = actually "on")? But every device that is on, fulfills its primary = function. I would argue that the primary function of a battery is to = provide energy. Batteries are different and I maybe we should ack this = fact and not try to create battery power state sets just because we have = this for devices. >>>=20 >>> I think the Email thread = http://www.ietf.org/mail-archive/web/eman/current/msg02000.html seemed = to agree that charging states and power states are orthogonal. If they = are, why should they be of the same class? The problem is that the power = state above as used for devices would suggest that if a device is off, = it does not consume any energy. But if the battery is charging, then it = does (given that the battery is modeled as part of the device). So if a = power state is indeed conflating power consumption and capabilities, = then a device would be in two different power states at the same time. = But it is not. It is in one power state and the batteries in it are in a = certain charging state and each of these can be freely combined. I.e. = charging/on, discharging/on, charging/off etc... I guess the main = question is, what is the advantage of defining a charging state as a = power state (the set of charging states as a power state set)? >>>=20 >>>=20 >>> Best, >>>=20 >>> Rolf >>>=20 >>> NEC Europe Ltd | Registered Office: Athene, Odyssey Business Park, = West End Road, London, HA4 6QE, GB | Registered in England 2832014 >>>=20 >>>=20 >>> _______________________________________________ >>> eman mailing list >>> eman@ietf.org >>> https://www.ietf.org/mailman/listinfo/eman >> _______________________________________________ >> eman mailing list >> eman@ietf.org >> https://www.ietf.org/mailman/listinfo/eman >> . >>=20 >=20 >=20 > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman >=20 --Apple-Mail=_21F1413B-F9E1-4186-93CC-7AB04D95C003 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlJK7PkACgkQ8AA1q7Z/VrKeyQCfTrturqnT3d0GrL/Xi8I1sbZL Hq4An2AcJSCsErh7FHCnsctQokHop6zw =9gAX -----END PGP SIGNATURE----- --Apple-Mail=_21F1413B-F9E1-4186-93CC-7AB04D95C003-- From bnordman@lbl.gov Tue Oct 1 12:42:45 2013 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 6E54D21F963F for ; Tue, 1 Oct 2013 12:42:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.044 X-Spam-Level: X-Spam-Status: No, score=-2.044 tagged_above=-999 required=5 tests=[FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, PLING_QUERY=1.333, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2xkX5B-RjpNY for ; Tue, 1 Oct 2013 12:42:25 -0700 (PDT) Received: from fe1.lbl.gov (fe1.lbl.gov [128.3.41.133]) by ietfa.amsl.com (Postfix) with ESMTP id 9851F21F855F for ; Tue, 1 Oct 2013 12:40:05 -0700 (PDT) X-Ironport-SBRS: 5.5 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvcCAP0hS1LRVdi2m2dsb2JhbABXA4JDfFK4QohEgSQFCBYOAQEBAQEGCwsJFCiCJQEBAQMBAQEBawsFCwsLDRUZIgUNAQUBHAYTCYd3BgyefJ5BjgIGCgQCAQWBIwwEBwoHhBEDiTmORoEvjmAYKYRuHIEsAQgX X-IronPort-AV: E=Sophos;i="4.90,1015,1371106800"; d="scan'208";a="29490852" Received: from mail-qc0-f182.google.com ([209.85.216.182]) by fe1.lbl.gov with ESMTP; 01 Oct 2013 12:32:50 -0700 Received: by mail-qc0-f182.google.com with SMTP id n4so5158111qcx.27 for ; Tue, 01 Oct 2013 12:32:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=dGRjdyTyRpgvFDSkXAPxB95srkc2watAqvGhuvwv2UM=; b=KNqwWgfeSFVXKEIqob18VMoieqE21dm530VolCSAcDqB0sQKZ4shrJ+zfeR6zgEUzM FR96i1/RCl4Sw5GIyxRNgfwrs0cs1FIt1OTEQYnkV/8OQPuqdYZRFic6f9NKzdnRj/pV q5ZaR0Dl40tzfCUU4Tu3jpjb7sFeOyVt15muj8VT6A1leVn8mlfVXmtCA3604uJgC8eN UYF0YVb038hf7+ANn649j5zm+y+rZ/LlHEJIeqkXbdNR6gWT0aA7GV6lhqef32Y9t+Xc zye0cqKas5JIRKZslSfSSNjx6xVnai7OfFr8UtkBKIVBfyS+yg74JgWl+gUteeV6GF0i OL2g== X-Gm-Message-State: ALoCoQmjcYyPPtTOoD8JYp6bGUfSuzCDKhGyU1eacEZJdn61SeUJHLplLg6ZES3ZVMMluAHCb9Se6bJWN99AD4yI5J6WvPSzLYw5H/3mHtkV0KHva6MvUmiKyXgVr3ESr1XQfPz8ADXX X-Received: by 10.49.127.116 with SMTP id nf20mr4716044qeb.90.1380655970081; Tue, 01 Oct 2013 12:32:50 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.49.127.116 with SMTP id nf20mr4715927qeb.90.1380655968932; Tue, 01 Oct 2013 12:32:48 -0700 (PDT) Received: by 10.140.80.212 with HTTP; Tue, 1 Oct 2013 12:32:48 -0700 (PDT) In-Reply-To: References: <791AD3077F94194BB2BDD13565B6295D55726BC7@DAPHNIS.office.hd> <5249A238.10500@cisco.com> Date: Tue, 1 Oct 2013 12:32:48 -0700 Message-ID: From: Bruce Nordman To: joel jaeggli Content-Type: multipart/alternative; boundary=047d7b5d8d5f95e85704e7b304d6 Cc: Ted Ghose , "eman@ietf.org" Subject: Re: [eman] Power States != Charging States? 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, 01 Oct 2013 19:42:45 -0000 --047d7b5d8d5f95e85704e7b304d6 Content-Type: text/plain; charset=ISO-8859-1 I agree with Rolf that the battery charging state is a different concept from power state. The current charging state entries in the battery MIB document are: unknown, charging, fastCharging, maintainingCharge, noCharging, and discharging. It seems plausible to me that over time storage technologies will evolve so that more entries in this list will be desired. The power state registry could then be used as a place to put such additional charging state sets, in which case it should be stated to cover both power and charging states. Or, a second registry just for battery states could be created. Or, states could be added by updating the battery MIB. Note that a battery can have data only as listed in the battery MIB, it can only have component data as an energy object, or both. For the energy object aspect of batteries, there is a field for the battery component for power state. This could be left empty, or used. It occurs to me that a battery could be available/in-use, which I would consider to be On, or not electrically available (for charging or discharging), which I would consider to be Off (perhaps for being physically removed, or simply selected to be not available for use). IEEE 1621 covers this. Finally, I thought that the battery MIB draft had indications for battery failure. This seems like something that could be reported on in either the charging state or power state context. --Bruce On Tue, Oct 1, 2013 at 8:40 AM, joel jaeggli wrote: > > On Sep 30, 2013, at 9:09 AM, Benoit Claise wrote: > > > Hi Ted, > >> Hi Rolf > >> > >> +1 > >> > >> Thanks for clearly articulating the points. I totally agree the > charging state should be orthogonal to power state. > >> > >> My position is that battery should _also_ have power state indicating > if it is receiving power (charging) or giving power to the electrical > network, and how much > > That makes sense. > > > > Regards, Benoit > > In my limited experience with battery controllers batteries are either: > > charging > discharging > full > empty > > in all cases state of charge, e.g. capacity is germain. > > >> > >> This will be useful to account for all the power source and sink > >> > >> Best > >> > >> -tg- > >> Sent from my iPhone > >> > >>> On Sep 25, 2013, at 6:18 AM, Rolf Winter > wrote: > >>> > >>> Hi, > >>> > >>> this thread attempts to close an open issue in the framework document > (v10) where section 9.1.4 reads: > >>> > >>> 9.1.4. Batteries Power State Set > >>> > >>> Batteries have operational and administrational states that > >>> could be represented as a power state set. Since the work > >>> for battery management is parallel to this document, we are > >>> not proposing any Power State Sets for batteries at this > >>> time. > >>> > >>> I argue that batteries have no power states given the power state > definition: > >>> > >>> A Power State is a condition or mode of a device that > >>> broadly characterizes its capabilities, power > >>> consumption, and responsiveness to input. > >>> > >>> There are charging states currently defined in the battery MIB, which > seem to be orthogonal to power states. I guess a universal power state set > is "on" and "off". Any device can really be in one of these two modes. Even > a simple light bulb. What would be "on" for a battery? Maybe charging > because it receives energy (like any other device that is actually "on")? > But every device that is on, fulfills its primary function. I would argue > that the primary function of a battery is to provide energy. Batteries are > different and I maybe we should ack this fact and not try to create battery > power state sets just because we have this for devices. > >>> > >>> I think the Email thread > http://www.ietf.org/mail-archive/web/eman/current/msg02000.html seemed to > agree that charging states and power states are orthogonal. If they are, > why should they be of the same class? The problem is that the power state > above as used for devices would suggest that if a device is off, it does > not consume any energy. But if the battery is charging, then it does (given > that the battery is modeled as part of the device). So if a power state is > indeed conflating power consumption and capabilities, then a device would > be in two different power states at the same time. But it is not. It is in > one power state and the batteries in it are in a certain charging state and > each of these can be freely combined. I.e. charging/on, discharging/on, > charging/off etc... I guess the main question is, what is the advantage of > defining a charging state as a power state (the set of charging states as a > power state set)? > >>> > >>> > >>> Best, > >>> > >>> Rolf > >>> > >>> NEC Europe Ltd | Registered Office: Athene, Odyssey Business Park, > West End Road, London, HA4 6QE, GB | Registered in England 2832014 > >>> > >>> > >>> _______________________________________________ > >>> eman mailing list > >>> eman@ietf.org > >>> https://www.ietf.org/mailman/listinfo/eman > >> _______________________________________________ > >> eman mailing list > >> eman@ietf.org > >> https://www.ietf.org/mailman/listinfo/eman > >> . > >> > > > > > > _______________________________________________ > > eman mailing list > > eman@ietf.org > > https://www.ietf.org/mailman/listinfo/eman > > > > > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman > > -- *Bruce Nordman* Lawrence Berkeley National Laboratory *nordman.lbl.gov* BNordman@LBL.gov 510-486-7089 m: 510-501-7943 --047d7b5d8d5f95e85704e7b304d6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I agree with Rolf that = the battery charging state is a different concept
from power state.
<= br>
The current charging state entries in the battery MIB document are= :
unknown, charging, fastCharging, maintainingCharge, noCharging, and d= ischarging.

It seems plausible to me that over time storage technolo= gies will evolve so that
more entries in this list will be desired= .=A0 The power state registry could then be
used as a place to put such additional charging state sets, in which case i= t should
be stated to cover both power and charging states.=A0 Or, a sec= ond registry just for
battery states could be created.=A0 Or, stat= es could be added by updating the battery
MIB.

Note that a battery can have data only as listed in the b= attery MIB, it can only
have component data as an energy object, or both= .=A0 For the energy object aspect
of batteries, there is a field for the= battery component for power state.=A0 This could
be left empty, or used.=A0 It occurs to me that a battery could be availabl= e/in-use, which
I would consider to be On, or not electrically available= (for charging or discharging),
which I would consider to be Off (perhap= s for being physically removed, or simply
selected to be not available for use).=A0 IEEE 1621 covers this.

Finally, I thought that the battery MIB draft had indications for batter= y failure.=A0 This
seems like something that could be reported on in eit= her the charging state or
power state context.

--Bruce


On Tue, Oct 1, 2013 at 8:40 AM, joel = jaeggli <joelja@bogus.com> wrote:

On Sep 30, 2013, at 9:09 AM, Benoit Claise <bclaise@cisco.com> wrote:

> Hi Ted,
>> Hi Rolf
>>
>> +1
>>
>> Thanks for clearly articulating the points. I totally agree the ch= arging state should be orthogonal to power state.
>>
>> My position is that battery should _also_ have power state indicat= ing if it is receiving power (charging) or giving power to the electrical n= etwork, and how much
> That makes sense.
>
> Regards, Benoit

In my limited experience with battery controllers batteries are eithe= r:

charging
discharging
full
empty

in all cases =A0state of charge, e.g. capacity is germain.

>>
>> This will be useful to account for all the power source and sink >>
>> Best
>>
>> -tg-
>> Sent from my iPhone
>>
>>> On Sep 25, 2013, at 6:18 AM, Rolf Winter <Rolf.Winter@neclab.eu> wrote:
>>>
>>> Hi,
>>>
>>> this thread attempts to close an open issue in the framework d= ocument (v10) where section 9.1.4 reads:
>>>
>>> 9.1.4. Batteries Power State Set
>>>
>>> =A0 =A0 =A0 =A0Batteries have operational and administrational= states that
>>> =A0 =A0 =A0 =A0could be represented as a power state set. Sinc= e the work
>>> =A0 =A0 =A0 =A0for battery management is parallel to this docu= ment, we are
>>> =A0 =A0 =A0 =A0not proposing any Power State Sets for batterie= s at this
>>> =A0 =A0 =A0 =A0time.
>>>
>>> I argue that batteries have no power states given the power st= ate definition:
>>>
>>> =A0 =A0 =A0 =A0A Power State is a condition or mode of a devic= e that
>>> =A0 =A0 =A0 =A0broadly characterizes its capabilities, power >>> =A0 =A0 =A0 =A0consumption, and responsiveness to input.
>>>
>>> There are charging states currently defined in the battery MIB= , which seem to be orthogonal to power states. I guess a universal power st= ate set is "on" and "off". Any device can really be in = one of these two modes. Even a simple light bulb. What would be "on&qu= ot; for a battery? Maybe charging because it receives energy (like any othe= r device that is actually "on")? But every device that is on, ful= fills its primary function. I would argue that the primary function of a ba= ttery is to provide energy. Batteries are different and I maybe we should a= ck this fact and not try to create battery power state sets just because we= have this for devices.
>>>
>>> I think the Email thread http://www.ietf.or= g/mail-archive/web/eman/current/msg02000.html seemed to agree that char= ging states and power states are orthogonal. If they are, why should they b= e of the same class? The problem is that the power state above as used for = devices would suggest that if a device is off, it does not consume any ener= gy. But if the battery is charging, then it does (given that the battery is= modeled as part of the device). So if a power state is indeed conflating p= ower consumption and capabilities, then a device would be in two different = power states at the same time. But it is not. It is in one power state and = the batteries in it are in a certain charging state and each of these can b= e freely combined. I.e. charging/on, discharging/on, charging/off etc... I = guess the main question is, what is the advantage of defining a charging st= ate as a power state (the set of charging states as a power state set)?
>>>
>>>
>>> Best,
>>>
>>> Rolf
>>>
>>> NEC Europe Ltd | Registered Office: Athene, Odyssey Business P= ark, West End =A0Road, London, HA4 6QE, GB | Registered in England 2832014<= br> >>>
>>>
>>> _______________________________________________
>>> eman mailing list
>>> eman@ietf.org
>>> https://www.ietf.org/mailman/listinfo/eman
>> _______________________________________________
>> eman mailing list
>> eman@ietf.org
>> https://www.ietf.org/mailman/listinfo/eman
>> .
>>
>
>
> _______________________________________________
> eman mailing list
> eman@ietf.org
> https://www.ietf.org/mailman/listinfo/eman
>


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




--
Bruce Nordman
Lawrence Be= rkeley National Laboratory
= nordman.lbl.gov
BNordman@LBL.gov
510-486-7089
m: 510-501-7943
--047d7b5d8d5f95e85704e7b304d6-- From Rolf.Winter@neclab.eu Wed Oct 2 03:03:02 2013 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 D674711E81B4 for ; Wed, 2 Oct 2013 03:03:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.209 X-Spam-Level: X-Spam-Status: No, score=-102.209 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, PLING_QUERY=1.39, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BzTChQdFAxBY for ; Wed, 2 Oct 2013 03:02:53 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 1113221E82B3 for ; Wed, 2 Oct 2013 03:02:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id AB6DF105A45; Wed, 2 Oct 2013 11:59:02 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EiasYRKVNh6n; Wed, 2 Oct 2013 11:59:02 +0200 (CEST) Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 8B98C104C50; Wed, 2 Oct 2013 11:58:42 +0200 (CEST) Received: from DAPHNIS.office.hd ([169.254.2.213]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Wed, 2 Oct 2013 12:01:51 +0200 From: Rolf Winter To: Bruce Nordman , joel jaeggli Thread-Topic: [eman] Power States != Charging States? Thread-Index: Ac658agNBCTPrXG/QuKZUDsu7CoziP//5VmAgAgEsACAAYpKgIAAQNoA//7vG4A= Date: Wed, 2 Oct 2013 10:01:50 +0000 Message-ID: <791AD3077F94194BB2BDD13565B6295D55727F6E@DAPHNIS.office.hd> References: <791AD3077F94194BB2BDD13565B6295D55726BC7@DAPHNIS.office.hd> <5249A238.10500@cisco.com> In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.0.212] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "eman@ietf.org" , Ted Ghose Subject: Re: [eman] Power States != Charging States? 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, 02 Oct 2013 10:03:02 -0000 Hi, So it seems there is a general agreement that power and charging states are= different. But I am still not sure we need a separate power state. I think= I read two different things so far. 1) introduce a state that shows if it is charging or discharging and how mu= ch=20 2) introduce state which merely indicates whether the battery can be used (= either charged or discharged or not) I thought 1 is already covered by the current battery MIB with charging sta= tes and the actual measurements of e.g. the actual current etc. The same I = guess applied to devices which might have a couple of power states and then= actual measurements to quantify energy use. I am not sure about 2 since I have a hard time making a connection with the= definition of power state that we have: A Power State is a condition or mode of a device that broadly characterizes its capabilities, power consumption, and responsiveness to input.=20 It is more like "availability for use" rather than an actual power state. T= hat however is currently not covered by the MIB and we can think about whet= her we should introduce this. Best, Rolf NEC Europe Ltd | Registered Office: Athene, Odyssey Business Park, West End= Road, London, HA4 6QE, GB | Registered in England 2832014 > -----Original Message----- > From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of > Bruce Nordman > Sent: Dienstag, 1. Oktober 2013 21:33 > To: joel jaeggli > Cc: Ted Ghose; eman@ietf.org > Subject: Re: [eman] Power States !=3D Charging States? >=20 > I agree with Rolf that the battery charging state is a different > concept from power state. >=20 >=20 > The current charging state entries in the battery MIB document are: >=20 > unknown, charging, fastCharging, maintainingCharge, noCharging, and > discharging. >=20 > It seems plausible to me that over time storage technologies will > evolve so that >=20 > more entries in this list will be desired. The power state registry > could then be used as a place to put such additional charging state > sets, in which case it should be stated to cover both power and > charging states. Or, a second registry just for >=20 > battery states could be created. Or, states could be added by updating > the battery MIB. >=20 >=20 > Note that a battery can have data only as listed in the battery MIB, it > can only have component data as an energy object, or both. For the > energy object aspect of batteries, there is a field for the battery > component for power state. This could be left empty, or used. It > occurs to me that a battery could be available/in-use, which I would > consider to be On, or not electrically available (for charging or > discharging), which I would consider to be Off (perhaps for being > physically removed, or simply selected to be not available for use). > IEEE 1621 covers this. >=20 >=20 > Finally, I thought that the battery MIB draft had indications for > battery failure. This seems like something that could be reported on > in either the charging state or >=20 > power state context. >=20 > --Bruce >=20 >=20 >=20 > On Tue, Oct 1, 2013 at 8:40 AM, joel jaeggli wrote: >=20 >=20 >=20 > On Sep 30, 2013, at 9:09 AM, Benoit Claise > wrote: >=20 > > Hi Ted, > >> Hi Rolf > >> > >> +1 > >> > >> Thanks for clearly articulating the points. I totally agree > the charging state should be orthogonal to power state. > >> > >> My position is that battery should _also_ have power state > indicating if it is receiving power (charging) or giving power to the > electrical network, and how much > > That makes sense. > > > > Regards, Benoit >=20 >=20 > In my limited experience with battery controllers batteries are > either: >=20 > charging > discharging > full > empty >=20 > in all cases state of charge, e.g. capacity is germain. >=20 >=20 > >> > >> This will be useful to account for all the power source and > sink > >> > >> Best > >> > >> -tg- > >> Sent from my iPhone > >> > >>> On Sep 25, 2013, at 6:18 AM, Rolf Winter > wrote: > >>> > >>> Hi, > >>> > >>> this thread attempts to close an open issue in the framework > document (v10) where section 9.1.4 reads: > >>> > >>> 9.1.4. Batteries Power State Set > >>> > >>> Batteries have operational and administrational states > that > >>> could be represented as a power state set. Since the > work > >>> for battery management is parallel to this document, > we are > >>> not proposing any Power State Sets for batteries at > this > >>> time. > >>> > >>> I argue that batteries have no power states given the power > state definition: > >>> > >>> A Power State is a condition or mode of a device that > >>> broadly characterizes its capabilities, power > >>> consumption, and responsiveness to input. > >>> > >>> There are charging states currently defined in the battery > MIB, which seem to be orthogonal to power states. I guess a universal > power state set is "on" and "off". Any device can really be in one of > these two modes. Even a simple light bulb. What would be "on" for a > battery? Maybe charging because it receives energy (like any other > device that is actually "on")? But every device that is on, fulfills > its primary function. I would argue that the primary function of a > battery is to provide energy. Batteries are different and I maybe we > should ack this fact and not try to create battery power state sets > just because we have this for devices. > >>> > >>> I think the Email thread http://www.ietf.org/mail- > archive/web/eman/current/msg02000.html seemed to agree that charging > states and power states are orthogonal. If they are, why should they be > of the same class? The problem is that the power state above as used > for devices would suggest that if a device is off, it does not consume > any energy. But if the battery is charging, then it does (given that > the battery is modeled as part of the device). So if a power state is > indeed conflating power consumption and capabilities, then a device > would be in two different power states at the same time. But it is not. > It is in one power state and the batteries in it are in a certain > charging state and each of these can be freely combined. I.e. > charging/on, discharging/on, charging/off etc... I guess the main > question is, what is the advantage of defining a charging state as a > power state (the set of charging states as a power state set)? > >>> > >>> > >>> Best, > >>> > >>> Rolf > >>> > >>> NEC Europe Ltd | Registered Office: Athene, Odyssey Business > Park, West End Road, London, HA4 6QE, GB | Registered in England > 2832014 > >>> > >>> > >>> _______________________________________________ > >>> eman mailing list > >>> eman@ietf.org > >>> https://www.ietf.org/mailman/listinfo/eman > >> _______________________________________________ > >> eman mailing list > >> eman@ietf.org > >> https://www.ietf.org/mailman/listinfo/eman > >> . > >> > > > > > > _______________________________________________ > > eman mailing list > > eman@ietf.org > > https://www.ietf.org/mailman/listinfo/eman > > >=20 >=20 >=20 > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman >=20 >=20 >=20 >=20 >=20 >=20 > -- > Bruce Nordman > Lawrence Berkeley National Laboratory > nordman.lbl.gov > BNordman@LBL.gov > 510-486-7089 > m: 510-501-7943 From tghose@juniper.net Wed Oct 2 06:56:08 2013 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 BECE921F9E6C for ; Wed, 2 Oct 2013 06:56:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.923 X-Spam-Level: X-Spam-Status: No, score=0.923 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, PLING_QUERY=1.39, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2v+QAfmX6s4c for ; Wed, 2 Oct 2013 06:55:57 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe001.messaging.microsoft.com [216.32.181.181]) by ietfa.amsl.com (Postfix) with ESMTP id 77E9721F8EEA for ; Wed, 2 Oct 2013 06:53:48 -0700 (PDT) Received: from mail21-ch1-R.bigfish.com (10.43.68.252) by CH1EHSOBE022.bigfish.com (10.43.70.79) with Microsoft SMTP Server id 14.1.225.22; Wed, 2 Oct 2013 13:53:47 +0000 Received: from mail21-ch1 (localhost [127.0.0.1]) by mail21-ch1-R.bigfish.com (Postfix) with ESMTP id B58CB2C00F4; Wed, 2 Oct 2013 13:53:47 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT003.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -19 X-BigFish: VPS-19(zz98dI9371I542I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL17326ah1de097h186068h8275bh8275dhz2fh2a8h839h944hd25he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h2052h20b3m1155h) Received-SPF: pass (mail21-ch1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=tghose@juniper.net; helo=BL2PRD0510HT003.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(51704005)(377454003)(24454002)(189002)(199002)(13464003)(79102001)(19580405001)(83322001)(19580395003)(15202345003)(76482001)(53806001)(59766001)(77982001)(50986001)(47976001)(49866001)(47736001)(4396001)(81342001)(51856001)(65816001)(46102001)(80022001)(63696002)(80976001)(74366001)(66066001)(69226001)(33656001)(31966008)(81542001)(74502001)(74662001)(47446002)(83072001)(77096001)(56816003)(81816001)(56776001)(82746002)(54356001)(54316002)(36756003)(76796001)(81686001)(74876001)(74706001)(76786001)(15975445006)(83716002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR05MB196; H:BL2PR05MB195.namprd05.prod.outlook.com; CLIP:50.156.10.246; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail21-ch1 (localhost.localdomain [127.0.0.1]) by mail21-ch1 (MessageSwitch) id 138072202677031_20726; Wed, 2 Oct 2013 13:53:46 +0000 (UTC) Received: from CH1EHSMHS007.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.239]) by mail21-ch1.bigfish.com (Postfix) with ESMTP id 0CDC74C004A; Wed, 2 Oct 2013 13:53:46 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by CH1EHSMHS007.bigfish.com (10.43.70.7) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 2 Oct 2013 13:53:41 +0000 Received: from BL2PR05MB196.namprd05.prod.outlook.com (10.242.198.155) by BL2PRD0510HT003.namprd05.prod.outlook.com (10.255.100.38) with Microsoft SMTP Server (TLS) id 14.16.359.1; Wed, 2 Oct 2013 13:53:41 +0000 Received: from BL2PR05MB195.namprd05.prod.outlook.com (10.242.198.149) by BL2PR05MB196.namprd05.prod.outlook.com (10.242.198.155) with Microsoft SMTP Server (TLS) id 15.0.775.9; Wed, 2 Oct 2013 13:53:40 +0000 Received: from BL2PR05MB195.namprd05.prod.outlook.com ([169.254.6.159]) by BL2PR05MB195.namprd05.prod.outlook.com ([169.254.6.159]) with mapi id 15.00.0775.005; Wed, 2 Oct 2013 13:53:40 +0000 From: Ted Ghose To: Rolf Winter Thread-Topic: [eman] Power States != Charging States? Thread-Index: AQHOufUYdwSJ6a3Za0Kx55ucEoZo/JneevYAgAGKSoCAAEDaAIAA8s8AgABAxN4= Date: Wed, 2 Oct 2013 13:53:39 +0000 Message-ID: <4C227BE7-1FAE-4DC4-B5A8-2F0CB0D429F1@juniper.net> References: <791AD3077F94194BB2BDD13565B6295D55726BC7@DAPHNIS.office.hd> <5249A238.10500@cisco.com> , <791AD3077F94194BB2BDD13565B6295D55727F6E@DAPHNIS.office.hd> In-Reply-To: <791AD3077F94194BB2BDD13565B6295D55727F6E@DAPHNIS.office.hd> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.156.10.246] x-forefront-prvs: 0987ACA2E2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%0$Dn%LBL.GOV$RO%1$TLS%0$FQDN%$TlsDn% Cc: "eman@ietf.org" Subject: Re: [eman] Power States != Charging States? 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, 02 Oct 2013 13:56:08 -0000 We still need to know know the amount of power battery is receiving or givi= ng to the system.=20 How are we addressing that?=20 I totally agree charging state has nothing to do with it=20 -tg- Sent from my iPhone > On Oct 2, 2013, at 3:04 AM, "Rolf Winter" wrote: >=20 > Hi, >=20 > So it seems there is a general agreement that power and charging states a= re different. But I am still not sure we need a separate power state. I thi= nk I read two different things so far. >=20 > 1) introduce a state that shows if it is charging or discharging and how = much=20 > 2) introduce state which merely indicates whether the battery can be used= (either charged or discharged or not) >=20 > I thought 1 is already covered by the current battery MIB with charging s= tates and the actual measurements of e.g. the actual current etc. The same = I guess applied to devices which might have a couple of power states and th= en actual measurements to quantify energy use. >=20 > I am not sure about 2 since I have a hard time making a connection with t= he definition of power state that we have: >=20 > A Power State is a condition or mode of a device that > broadly characterizes its capabilities, power > consumption, and responsiveness to input.=20 >=20 > It is more like "availability for use" rather than an actual power state.= That however is currently not covered by the MIB and we can think about wh= ether we should introduce this. >=20 > Best, >=20 > Rolf >=20 >=20 >=20 > NEC Europe Ltd | Registered Office: Athene, Odyssey Business Park, West E= nd Road, London, HA4 6QE, GB | Registered in England 2832014 >=20 >=20 >> -----Original Message----- >> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of >> Bruce Nordman >> Sent: Dienstag, 1. Oktober 2013 21:33 >> To: joel jaeggli >> Cc: Ted Ghose; eman@ietf.org >> Subject: Re: [eman] Power States !=3D Charging States? >>=20 >> I agree with Rolf that the battery charging state is a different >> concept from power state. >>=20 >>=20 >> The current charging state entries in the battery MIB document are: >>=20 >> unknown, charging, fastCharging, maintainingCharge, noCharging, and >> discharging. >>=20 >> It seems plausible to me that over time storage technologies will >> evolve so that >>=20 >> more entries in this list will be desired. The power state registry >> could then be used as a place to put such additional charging state >> sets, in which case it should be stated to cover both power and >> charging states. Or, a second registry just for >>=20 >> battery states could be created. Or, states could be added by updating >> the battery MIB. >>=20 >>=20 >> Note that a battery can have data only as listed in the battery MIB, it >> can only have component data as an energy object, or both. For the >> energy object aspect of batteries, there is a field for the battery >> component for power state. This could be left empty, or used. It >> occurs to me that a battery could be available/in-use, which I would >> consider to be On, or not electrically available (for charging or >> discharging), which I would consider to be Off (perhaps for being >> physically removed, or simply selected to be not available for use). >> IEEE 1621 covers this. >>=20 >>=20 >> Finally, I thought that the battery MIB draft had indications for >> battery failure. This seems like something that could be reported on >> in either the charging state or >>=20 >> power state context. >>=20 >> --Bruce >>=20 >>=20 >>=20 >> On Tue, Oct 1, 2013 at 8:40 AM, joel jaeggli wrote: >>=20 >>=20 >>=20 >> On Sep 30, 2013, at 9:09 AM, Benoit Claise >> wrote: >>=20 >> > Hi Ted, >> >> Hi Rolf >> >> >> >> +1 >> >> >> >> Thanks for clearly articulating the points. I totally agree >> the charging state should be orthogonal to power state. >> >> >> >> My position is that battery should _also_ have power state >> indicating if it is receiving power (charging) or giving power to the >> electrical network, and how much >> > That makes sense. >> > >> > Regards, Benoit >>=20 >>=20 >> In my limited experience with battery controllers batteries are >> either: >>=20 >> charging >> discharging >> full >> empty >>=20 >> in all cases state of charge, e.g. capacity is germain. >>=20 >>=20 >> >> >> >> This will be useful to account for all the power source and >> sink >> >> >> >> Best >> >> >> >> -tg- >> >> Sent from my iPhone >> >> >> >>> On Sep 25, 2013, at 6:18 AM, Rolf Winter >> wrote: >> >>> >> >>> Hi, >> >>> >> >>> this thread attempts to close an open issue in the framework >> document (v10) where section 9.1.4 reads: >> >>> >> >>> 9.1.4. Batteries Power State Set >> >>> >> >>> Batteries have operational and administrational states >> that >> >>> could be represented as a power state set. Since the >> work >> >>> for battery management is parallel to this document, >> we are >> >>> not proposing any Power State Sets for batteries at >> this >> >>> time. >> >>> >> >>> I argue that batteries have no power states given the power >> state definition: >> >>> >> >>> A Power State is a condition or mode of a device that >> >>> broadly characterizes its capabilities, power >> >>> consumption, and responsiveness to input. >> >>> >> >>> There are charging states currently defined in the battery >> MIB, which seem to be orthogonal to power states. I guess a universal >> power state set is "on" and "off". Any device can really be in one of >> these two modes. Even a simple light bulb. What would be "on" for a >> battery? Maybe charging because it receives energy (like any other >> device that is actually "on")? But every device that is on, fulfills >> its primary function. I would argue that the primary function of a >> battery is to provide energy. Batteries are different and I maybe we >> should ack this fact and not try to create battery power state sets >> just because we have this for devices. >> >>> >> >>> I think the Email thread http://www.ietf.org/mail- >> archive/web/eman/current/msg02000.html seemed to agree that charging >> states and power states are orthogonal. If they are, why should they be >> of the same class? The problem is that the power state above as used >> for devices would suggest that if a device is off, it does not consume >> any energy. But if the battery is charging, then it does (given that >> the battery is modeled as part of the device). So if a power state is >> indeed conflating power consumption and capabilities, then a device >> would be in two different power states at the same time. But it is not. >> It is in one power state and the batteries in it are in a certain >> charging state and each of these can be freely combined. I.e. >> charging/on, discharging/on, charging/off etc... I guess the main >> question is, what is the advantage of defining a charging state as a >> power state (the set of charging states as a power state set)? >> >>> >> >>> >> >>> Best, >> >>> >> >>> Rolf >> >>> >> >>> NEC Europe Ltd | Registered Office: Athene, Odyssey Business >> Park, West End Road, London, HA4 6QE, GB | Registered in England >> 2832014 >> >>> >> >>> >> >>> _______________________________________________ >> >>> eman mailing list >> >>> eman@ietf.org >> >>> https://www.ietf.org/mailman/listinfo/eman >> >> _______________________________________________ >> >> eman mailing list >> >> eman@ietf.org >> >> https://www.ietf.org/mailman/listinfo/eman >> >> . >> >> >> > >> > >> > _______________________________________________ >> > eman mailing list >> > eman@ietf.org >> > https://www.ietf.org/mailman/listinfo/eman >> > >>=20 >>=20 >>=20 >> _______________________________________________ >> eman mailing list >> eman@ietf.org >> https://www.ietf.org/mailman/listinfo/eman >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> -- >> Bruce Nordman >> Lawrence Berkeley National Laboratory >> nordman.lbl.gov >> BNordman@LBL.gov >> 510-486-7089 >> m: 510-501-7943 >=20 >=20 >=20 From jparello@cisco.com Wed Oct 2 07:23:20 2013 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 8427221F92C2 for ; Wed, 2 Oct 2013 07:23:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.609 X-Spam-Level: X-Spam-Status: No, score=-8.609 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, PLING_QUERY=1.39, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XJJ5ejuzvmVc for ; Wed, 2 Oct 2013 07:23:09 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 758AD21F90AC for ; Wed, 2 Oct 2013 07:23:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9756; q=dns/txt; s=iport; t=1380723783; x=1381933383; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=k2l6XmPUOnu4r0aW0pL4ExmRoXtxLHeuaEQariNOXRE=; b=YhZHz6KSufX679kJBaz5NxGRWqmGpK+6t+7zyJJe/VpCieBIXsQAY9G1 pMac9YF6oohrsLnCZc4HYhqXDCpav9+mCTuwqNxoD5p+Lbjedd/hciNuV JWZcTeYn7B7DN6yQ7v5Z8neyyqJ9NNFTMLwmXnE+to2miRxH7FLgoFQcS A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj0HAGArTFKtJXHB/2dsb2JhbABVA4MHOEzBG4ELDRZ0giUBAQEDAQEBATc0CwUHBAIBCA4DBAEBARUJCQcnCxQJCAIEDgUJh3cGBwW9T44CBgoEAgEFgQAIGxAHBgQHgw6BBAOYAYEvix2FM4MkgWgBCBc X-IronPort-AV: E=Sophos;i="4.90,1019,1371081600"; d="scan'208";a="267117316" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-7.cisco.com with ESMTP; 02 Oct 2013 14:23:02 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r92EN21m031782 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 2 Oct 2013 14:23:02 GMT Received: from xmb-aln-x04.cisco.com ([169.254.9.229]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.004; Wed, 2 Oct 2013 09:23:01 -0500 From: "John Parello (jparello)" To: Ted Ghose Thread-Topic: [eman] Power States != Charging States? Thread-Index: Ac658agNBCTPrXG/QuKZUDsu7CoziAALVlSAAQCV9QAAMUlCgAAIG0kAAB5ZxAAACBiagP//tGPI Date: Wed, 2 Oct 2013 14:23:01 +0000 Message-ID: References: <791AD3077F94194BB2BDD13565B6295D55726BC7@DAPHNIS.office.hd> <5249A238.10500@cisco.com> , <791AD3077F94194BB2BDD13565B6295D55727F6E@DAPHNIS.office.hd>, <4C227BE7-1FAE-4DC4-B5A8-2F0CB0D429F1@juniper.net> In-Reply-To: <4C227BE7-1FAE-4DC4-B5A8-2F0CB0D429F1@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "eman@ietf.org" Subject: Re: [eman] Power States != Charging States? 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, 02 Oct 2013 14:23:20 -0000 So I'm seeing we all agree charing states are orthogonal to the current pow= er states. That it's reasonable to expect a battery modeled by an Energy Object to imp= lement power states to show what it is receiving or giving to the system. +1 On Bruce's comment in it;s entirety also that we could include the batte= ry states in power states at some later date. Rolf I'm not sure I see that the definition of power states does not cover = states of a battery. "A condition or mode that broadly characterize..power.= .." does seem to cover if a battery is receving energy and storing it? Anyo= ne else see this is ok or not? I did bring up that we call these power states when "energy states" and "en= ergy interfaces" is more accurate. Would that be more comfortable to you. E= TSI is using Energy States in their liaison with us is the GAL. I will update 9.1.4 according to this thread an lets see how that rolls. Jp Sent from my iPad=20 (expect ridiculous spelling mistakes)=20 On Oct 2, 2013, at 6:56 AM, "Ted Ghose" wrote: > We still need to know know the amount of power battery is receiving or gi= ving to the system.=20 >=20 > How are we addressing that?=20 >=20 > I totally agree charging state has nothing to do with it=20 >=20 > -tg- > Sent from my iPhone >=20 >> On Oct 2, 2013, at 3:04 AM, "Rolf Winter" wrote: >>=20 >> Hi, >>=20 >> So it seems there is a general agreement that power and charging states = are different. But I am still not sure we need a separate power state. I th= ink I read two different things so far. >>=20 >> 1) introduce a state that shows if it is charging or discharging and how= much=20 >> 2) introduce state which merely indicates whether the battery can be use= d (either charged or discharged or not) >>=20 >> I thought 1 is already covered by the current battery MIB with charging = states and the actual measurements of e.g. the actual current etc. The same= I guess applied to devices which might have a couple of power states and t= hen actual measurements to quantify energy use. >>=20 >> I am not sure about 2 since I have a hard time making a connection with = the definition of power state that we have: >>=20 >> A Power State is a condition or mode of a device that >> broadly characterizes its capabilities, power >> consumption, and responsiveness to input.=20 >>=20 >> It is more like "availability for use" rather than an actual power state= . That however is currently not covered by the MIB and we can think about w= hether we should introduce this. >>=20 >> Best, >>=20 >> Rolf >>=20 >>=20 >>=20 >> NEC Europe Ltd | Registered Office: Athene, Odyssey Business Park, West = End Road, London, HA4 6QE, GB | Registered in England 2832014 >>=20 >>=20 >>> -----Original Message----- >>> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of >>> Bruce Nordman >>> Sent: Dienstag, 1. Oktober 2013 21:33 >>> To: joel jaeggli >>> Cc: Ted Ghose; eman@ietf.org >>> Subject: Re: [eman] Power States !=3D Charging States? >>>=20 >>> I agree with Rolf that the battery charging state is a different >>> concept from power state. >>>=20 >>>=20 >>> The current charging state entries in the battery MIB document are: >>>=20 >>> unknown, charging, fastCharging, maintainingCharge, noCharging, and >>> discharging. >>>=20 >>> It seems plausible to me that over time storage technologies will >>> evolve so that >>>=20 >>> more entries in this list will be desired. The power state registry >>> could then be used as a place to put such additional charging state >>> sets, in which case it should be stated to cover both power and >>> charging states. Or, a second registry just for >>>=20 >>> battery states could be created. Or, states could be added by updating >>> the battery MIB. >>>=20 >>>=20 >>> Note that a battery can have data only as listed in the battery MIB, it >>> can only have component data as an energy object, or both. For the >>> energy object aspect of batteries, there is a field for the battery >>> component for power state. This could be left empty, or used. It >>> occurs to me that a battery could be available/in-use, which I would >>> consider to be On, or not electrically available (for charging or >>> discharging), which I would consider to be Off (perhaps for being >>> physically removed, or simply selected to be not available for use). >>> IEEE 1621 covers this. >>>=20 >>>=20 >>> Finally, I thought that the battery MIB draft had indications for >>> battery failure. This seems like something that could be reported on >>> in either the charging state or >>>=20 >>> power state context. >>>=20 >>> --Bruce >>>=20 >>>=20 >>>=20 >>> On Tue, Oct 1, 2013 at 8:40 AM, joel jaeggli wrote: >>>=20 >>>=20 >>>=20 >>> On Sep 30, 2013, at 9:09 AM, Benoit Claise >>> wrote: >>>=20 >>>> Hi Ted, >>>>> Hi Rolf >>>>>=20 >>>>> +1 >>>>>=20 >>>>> Thanks for clearly articulating the points. I totally agree >>> the charging state should be orthogonal to power state. >>>>>=20 >>>>> My position is that battery should _also_ have power state >>> indicating if it is receiving power (charging) or giving power to the >>> electrical network, and how much >>>> That makes sense. >>>>=20 >>>> Regards, Benoit >>>=20 >>>=20 >>> In my limited experience with battery controllers batteries are >>> either: >>>=20 >>> charging >>> discharging >>> full >>> empty >>>=20 >>> in all cases state of charge, e.g. capacity is germain. >>>=20 >>>=20 >>>>>=20 >>>>> This will be useful to account for all the power source and >>> sink >>>>>=20 >>>>> Best >>>>>=20 >>>>> -tg- >>>>> Sent from my iPhone >>>>>=20 >>>>>> On Sep 25, 2013, at 6:18 AM, Rolf Winter >>> wrote: >>>>>>=20 >>>>>> Hi, >>>>>>=20 >>>>>> this thread attempts to close an open issue in the framework >>> document (v10) where section 9.1.4 reads: >>>>>>=20 >>>>>> 9.1.4. Batteries Power State Set >>>>>>=20 >>>>>> Batteries have operational and administrational states >>> that >>>>>> could be represented as a power state set. Since the >>> work >>>>>> for battery management is parallel to this document, >>> we are >>>>>> not proposing any Power State Sets for batteries at >>> this >>>>>> time. >>>>>>=20 >>>>>> I argue that batteries have no power states given the power >>> state definition: >>>>>>=20 >>>>>> A Power State is a condition or mode of a device that >>>>>> broadly characterizes its capabilities, power >>>>>> consumption, and responsiveness to input. >>>>>>=20 >>>>>> There are charging states currently defined in the battery >>> MIB, which seem to be orthogonal to power states. I guess a universal >>> power state set is "on" and "off". Any device can really be in one of >>> these two modes. Even a simple light bulb. What would be "on" for a >>> battery? Maybe charging because it receives energy (like any other >>> device that is actually "on")? But every device that is on, fulfills >>> its primary function. I would argue that the primary function of a >>> battery is to provide energy. Batteries are different and I maybe we >>> should ack this fact and not try to create battery power state sets >>> just because we have this for devices. >>>>>>=20 >>>>>> I think the Email thread http://www.ietf.org/mail- >>> archive/web/eman/current/msg02000.html seemed to agree that charging >>> states and power states are orthogonal. If they are, why should they be >>> of the same class? The problem is that the power state above as used >>> for devices would suggest that if a device is off, it does not consume >>> any energy. But if the battery is charging, then it does (given that >>> the battery is modeled as part of the device). So if a power state is >>> indeed conflating power consumption and capabilities, then a device >>> would be in two different power states at the same time. But it is not. >>> It is in one power state and the batteries in it are in a certain >>> charging state and each of these can be freely combined. I.e. >>> charging/on, discharging/on, charging/off etc... I guess the main >>> question is, what is the advantage of defining a charging state as a >>> power state (the set of charging states as a power state set)? >>>>>>=20 >>>>>>=20 >>>>>> Best, >>>>>>=20 >>>>>> Rolf >>>>>>=20 >>>>>> NEC Europe Ltd | Registered Office: Athene, Odyssey Business >>> Park, West End Road, London, HA4 6QE, GB | Registered in England >>> 2832014 >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> eman mailing list >>>>>> eman@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/eman >>>>> _______________________________________________ >>>>> eman mailing list >>>>> eman@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/eman >>>>> . >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> eman mailing list >>>> eman@ietf.org >>>> https://www.ietf.org/mailman/listinfo/eman >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> eman mailing list >>> eman@ietf.org >>> https://www.ietf.org/mailman/listinfo/eman >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> -- >>> Bruce Nordman >>> Lawrence Berkeley National Laboratory >>> nordman.lbl.gov >>> BNordman@LBL.gov >>> 510-486-7089 >>> m: 510-501-7943 >=20 > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman From bnordman@lbl.gov Wed Oct 2 11:27:15 2013 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 010D421F8D0B for ; Wed, 2 Oct 2013 11:27:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.315 X-Spam-Level: X-Spam-Status: No, score=-3.315 tagged_above=-999 required=5 tests=[AWL=1.271, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, PLING_QUERY=1.39, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fs-dUTgTg5Zb for ; Wed, 2 Oct 2013 11:26:56 -0700 (PDT) Received: from fe1.lbl.gov (fe1.lbl.gov [128.3.41.133]) by ietfa.amsl.com (Postfix) with ESMTP id E2E6421F9EB6 for ; Wed, 2 Oct 2013 11:22:08 -0700 (PDT) X-Ironport-SBRS: 4.8 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAEAKJjTFLRVdiwlGdsb2JhbABWA4JDfEwGuGKIRIELBQgWDgEBAQEHCwsJEiqCJQEBAQMBAQEBawsFBwQLCwMDBAEBARUSByIFDQEFAQsJCAYTCYd3BgcFnxCePI4CBgoEAgEFgSMMBAYBBgQHhBIDiTmOSIEvix2DSBgphG4cgSwBCBc X-IronPort-AV: E=Sophos;i="4.90,1020,1371106800"; d="scan'208";a="29597807" Received: from mail-qc0-f176.google.com ([209.85.216.176]) by fe1.lbl.gov with ESMTP; 02 Oct 2013 11:22:06 -0700 Received: by mail-qc0-f176.google.com with SMTP id t7so802781qcv.21 for ; Wed, 02 Oct 2013 11:22:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=jTee6+w3/g+JCp0J3OlRx2uK/yGQOoSIF5lfQLdMDR8=; b=fSJDIOi/fFHfmnnTs+KsDFAkFDeVjlvDVZovsXUNuXogEGzkbYEyF76Xgmg1eShMZp sKkkaNBp55d554iVJJTst4BKsElzSajlQmgTUQLcHdLJgczA2yuFUp0JQYAXL47I8KKx MDGhWe/xI1Mi241uzS/bZ8L9oBlJ4JJZ5NNrFvDqJqq3VJp6eg42mVGKt3XONAytmZ5x wq0bdqynIIZr8bt2N4Gacxnl+1q8PtOQlTeNH1xPHN5ncj0jYNqAXODNbU2Bfxl2ekH3 44HLB8TCa3RScPHxLMZftxzO0OnWex2yigTTmTlg484eIvEsX9icLTDp6hYPfWqxU9tW qcDw== X-Gm-Message-State: ALoCoQlQzq5l5Z4HVb0MfvhGvxEZc5RKsgts2vdswVJVaL52GzAjKMzZud/6eiPRol381o8mGTtPjP4o9arC7BkUoqH9me0Sa0cMGwcgEd2SK7hJLjn8a+NgtxhvYOZUMdCDg46ZG7Hs X-Received: by 10.229.244.69 with SMTP id lp5mr4714459qcb.14.1380738126273; Wed, 02 Oct 2013 11:22:06 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.229.244.69 with SMTP id lp5mr4714448qcb.14.1380738126125; Wed, 02 Oct 2013 11:22:06 -0700 (PDT) Received: by 10.140.80.212 with HTTP; Wed, 2 Oct 2013 11:22:06 -0700 (PDT) In-Reply-To: <4C227BE7-1FAE-4DC4-B5A8-2F0CB0D429F1@juniper.net> References: <791AD3077F94194BB2BDD13565B6295D55726BC7@DAPHNIS.office.hd> <5249A238.10500@cisco.com> <791AD3077F94194BB2BDD13565B6295D55727F6E@DAPHNIS.office.hd> <4C227BE7-1FAE-4DC4-B5A8-2F0CB0D429F1@juniper.net> Date: Wed, 2 Oct 2013 11:22:06 -0700 Message-ID: From: Bruce Nordman To: Ted Ghose Content-Type: multipart/alternative; boundary=001a11c2c54c892c3004e7c625ee Cc: "eman@ietf.org" Subject: Re: [eman] Power States != Charging States? 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, 02 Oct 2013 18:27:15 -0000 --001a11c2c54c892c3004e7c625ee Content-Type: text/plain; charset=ISO-8859-1 For reporting power/energy, a battery would typically be modeled as a component and so report power/energy values as any other component would (this a subset of a device would report since components do not report complex power). That is, a battery has battery MIB data, as well as component (energy object) data. We would expect devices to report both, though they could do just one or the other. --Bruce On Wed, Oct 2, 2013 at 6:53 AM, Ted Ghose wrote: > We still need to know know the amount of power battery is receiving or > giving to the system. > > How are we addressing that? > > I totally agree charging state has nothing to do with it > > -tg- > Sent from my iPhone > > > On Oct 2, 2013, at 3:04 AM, "Rolf Winter" wrote: > > > > Hi, > > > > So it seems there is a general agreement that power and charging states > are different. But I am still not sure we need a separate power state. I > think I read two different things so far. > > > > 1) introduce a state that shows if it is charging or discharging and how > much > > 2) introduce state which merely indicates whether the battery can be > used (either charged or discharged or not) > > > > I thought 1 is already covered by the current battery MIB with charging > states and the actual measurements of e.g. the actual current etc. The same > I guess applied to devices which might have a couple of power states and > then actual measurements to quantify energy use. > > > > I am not sure about 2 since I have a hard time making a connection with > the definition of power state that we have: > > > > A Power State is a condition or mode of a device that > > broadly characterizes its capabilities, power > > consumption, and responsiveness to input. > > > > It is more like "availability for use" rather than an actual power > state. That however is currently not covered by the MIB and we can think > about whether we should introduce this. > > > > Best, > > > > Rolf > > > > > > > > NEC Europe Ltd | Registered Office: Athene, Odyssey Business Park, West > End Road, London, HA4 6QE, GB | Registered in England 2832014 > > > > > >> -----Original Message----- > >> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of > >> Bruce Nordman > >> Sent: Dienstag, 1. Oktober 2013 21:33 > >> To: joel jaeggli > >> Cc: Ted Ghose; eman@ietf.org > >> Subject: Re: [eman] Power States != Charging States? > >> > >> I agree with Rolf that the battery charging state is a different > >> concept from power state. > >> > >> > >> The current charging state entries in the battery MIB document are: > >> > >> unknown, charging, fastCharging, maintainingCharge, noCharging, and > >> discharging. > >> > >> It seems plausible to me that over time storage technologies will > >> evolve so that > >> > >> more entries in this list will be desired. The power state registry > >> could then be used as a place to put such additional charging state > >> sets, in which case it should be stated to cover both power and > >> charging states. Or, a second registry just for > >> > >> battery states could be created. Or, states could be added by updating > >> the battery MIB. > >> > >> > >> Note that a battery can have data only as listed in the battery MIB, it > >> can only have component data as an energy object, or both. For the > >> energy object aspect of batteries, there is a field for the battery > >> component for power state. This could be left empty, or used. It > >> occurs to me that a battery could be available/in-use, which I would > >> consider to be On, or not electrically available (for charging or > >> discharging), which I would consider to be Off (perhaps for being > >> physically removed, or simply selected to be not available for use). > >> IEEE 1621 covers this. > >> > >> > >> Finally, I thought that the battery MIB draft had indications for > >> battery failure. This seems like something that could be reported on > >> in either the charging state or > >> > >> power state context. > >> > >> --Bruce > >> > >> > >> > >> On Tue, Oct 1, 2013 at 8:40 AM, joel jaeggli wrote: > >> > >> > >> > >> On Sep 30, 2013, at 9:09 AM, Benoit Claise > >> wrote: > >> > >> > Hi Ted, > >> >> Hi Rolf > >> >> > >> >> +1 > >> >> > >> >> Thanks for clearly articulating the points. I totally agree > >> the charging state should be orthogonal to power state. > >> >> > >> >> My position is that battery should _also_ have power state > >> indicating if it is receiving power (charging) or giving power to the > >> electrical network, and how much > >> > That makes sense. > >> > > >> > Regards, Benoit > >> > >> > >> In my limited experience with battery controllers batteries are > >> either: > >> > >> charging > >> discharging > >> full > >> empty > >> > >> in all cases state of charge, e.g. capacity is germain. > >> > >> > >> >> > >> >> This will be useful to account for all the power source and > >> sink > >> >> > >> >> Best > >> >> > >> >> -tg- > >> >> Sent from my iPhone > >> >> > >> >>> On Sep 25, 2013, at 6:18 AM, Rolf Winter > >> wrote: > >> >>> > >> >>> Hi, > >> >>> > >> >>> this thread attempts to close an open issue in the framework > >> document (v10) where section 9.1.4 reads: > >> >>> > >> >>> 9.1.4. Batteries Power State Set > >> >>> > >> >>> Batteries have operational and administrational states > >> that > >> >>> could be represented as a power state set. Since the > >> work > >> >>> for battery management is parallel to this document, > >> we are > >> >>> not proposing any Power State Sets for batteries at > >> this > >> >>> time. > >> >>> > >> >>> I argue that batteries have no power states given the power > >> state definition: > >> >>> > >> >>> A Power State is a condition or mode of a device that > >> >>> broadly characterizes its capabilities, power > >> >>> consumption, and responsiveness to input. > >> >>> > >> >>> There are charging states currently defined in the battery > >> MIB, which seem to be orthogonal to power states. I guess a universal > >> power state set is "on" and "off". Any device can really be in one of > >> these two modes. Even a simple light bulb. What would be "on" for a > >> battery? Maybe charging because it receives energy (like any other > >> device that is actually "on")? But every device that is on, fulfills > >> its primary function. I would argue that the primary function of a > >> battery is to provide energy. Batteries are different and I maybe we > >> should ack this fact and not try to create battery power state sets > >> just because we have this for devices. > >> >>> > >> >>> I think the Email thread http://www.ietf.org/mail- > >> archive/web/eman/current/msg02000.html seemed to agree that charging > >> states and power states are orthogonal. If they are, why should they be > >> of the same class? The problem is that the power state above as used > >> for devices would suggest that if a device is off, it does not consume > >> any energy. But if the battery is charging, then it does (given that > >> the battery is modeled as part of the device). So if a power state is > >> indeed conflating power consumption and capabilities, then a device > >> would be in two different power states at the same time. But it is not. > >> It is in one power state and the batteries in it are in a certain > >> charging state and each of these can be freely combined. I.e. > >> charging/on, discharging/on, charging/off etc... I guess the main > >> question is, what is the advantage of defining a charging state as a > >> power state (the set of charging states as a power state set)? > >> >>> > >> >>> > >> >>> Best, > >> >>> > >> >>> Rolf > >> >>> > >> >>> NEC Europe Ltd | Registered Office: Athene, Odyssey Business > >> Park, West End Road, London, HA4 6QE, GB | Registered in England > >> 2832014 > >> >>> > >> >>> > >> >>> _______________________________________________ > >> >>> eman mailing list > >> >>> eman@ietf.org > >> >>> https://www.ietf.org/mailman/listinfo/eman > >> >> _______________________________________________ > >> >> eman mailing list > >> >> eman@ietf.org > >> >> https://www.ietf.org/mailman/listinfo/eman > >> >> . > >> >> > >> > > >> > > >> > _______________________________________________ > >> > eman mailing list > >> > eman@ietf.org > >> > https://www.ietf.org/mailman/listinfo/eman > >> > > >> > >> > >> > >> _______________________________________________ > >> eman mailing list > >> eman@ietf.org > >> https://www.ietf.org/mailman/listinfo/eman > >> > >> > >> > >> > >> > >> > >> -- > >> Bruce Nordman > >> Lawrence Berkeley National Laboratory > >> nordman.lbl.gov > >> BNordman@LBL.gov > >> 510-486-7089 > >> m: 510-501-7943 > > > > > > > > -- *Bruce Nordman* Lawrence Berkeley National Laboratory *nordman.lbl.gov* BNordman@LBL.gov 510-486-7089 m: 510-501-7943 --001a11c2c54c892c3004e7c625ee Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
For reporting power/energy, a battery would= typically be modeled as a component
and so report power/energy va= lues as any other component would (this a subset
of a device would repor= t since components do not report complex power).
That is, a battery has battery MIB data, as well as component (energy= object) data.
We would expect devices to report both, though they= could do just one or the other.
--Bruce


On Wed, Oct 2, 2013 at 6:53 AM, Ted Ghos= e <tghose@juniper.net> wrote:
We still need to know know the amount of power battery is receiving or givi= ng to the system.

How are we addressing that?

I totally agree charging state has nothing to do with it

-tg-
Sent from my iPhone

> On Oct 2, 2013, at 3:04 = AM, "Rolf Winter" <Ro= lf.Winter@neclab.eu> wrote:
>
> Hi,
>
> So it seems there is a general agreement that power and charging state= s are different. But I am still not sure we need a separate power state. I = think I read two different things so far.
>
> 1) introduce a state that shows if it is charging or discharging and h= ow much
> 2) introduce state which merely indicates whether the battery can be u= sed (either charged or discharged or not)
>
> I thought 1 is already covered by the current battery MIB with chargin= g states and the actual measurements of e.g. the actual current etc. The sa= me I guess applied to devices which might have a couple of power states and= then actual measurements to quantify energy use.
>
> I am not sure about 2 since I have a hard time making a connection wit= h the definition of power state that we have:
>
> A Power State is a condition or mode of a device that
> broadly characterizes its capabilities, power
> consumption, and responsiveness to input.
>
> It is more like "availability for use" rather than an actual= power state. That however is currently not covered by the MIB and we can t= hink about whether we should introduce this.
>
> Best,
>
> Rolf
>
>
>
> NEC Europe Ltd | Registered Office: Athene, Odyssey Business Park, Wes= t End =A0Road, London, HA4 6QE, GB | Registered in England 2832014
>
>
>> -----Original Message-----
>> From: eman-bounces@ietf.o= rg [mailto:eman-bounces@ietf.o= rg] On Behalf Of
>> Bruce Nordman
>> Sent: Dienstag, 1. Oktober 2013 21:33
>> To: joel jaeggli
>> Cc: Ted Ghose; eman@ietf.org<= br> >> Subject: Re: [eman] Power States !=3D Charging States?
>>
>> I agree with Rolf that the battery charging state is a different >> concept from power state.
>>
>>
>> The current charging state entries in the battery MIB document are= :
>>
>> unknown, charging, fastCharging, maintainingCharge, noCharging, an= d
>> discharging.
>>
>> It seems plausible to me that over time storage technologies will<= br> >> evolve so that
>>
>> more entries in this list will be desired. =A0The power state regi= stry
>> could then be used as a place to put such additional charging stat= e
>> sets, in which case it should be stated to cover both power and >> charging states. =A0Or, a second registry just for
>>
>> battery states could be created. =A0Or, states could be added by u= pdating
>> the battery MIB.
>>
>>
>> Note that a battery can have data only as listed in the battery MI= B, it
>> can only have component data as an energy object, or both. =A0For = the
>> energy object aspect of batteries, there is a field for the batter= y
>> component for power state. =A0This could be left empty, or used. = =A0It
>> occurs to me that a battery could be available/in-use, which I wou= ld
>> consider to be On, or not electrically available (for charging or<= br> >> discharging), which I would consider to be Off (perhaps for being<= br> >> physically removed, or simply selected to be not available for use= ).
>> IEEE 1621 covers this.
>>
>>
>> Finally, I thought that the battery MIB draft had indications for<= br> >> battery failure. =A0This seems like something that could be report= ed on
>> in either the charging state or
>>
>> power state context.
>>
>> --Bruce
>>
>>
>>
>> On Tue, Oct 1, 2013 at 8:40 AM, joel jaeggli <joelja@bogus.com> wrote:
>>
>>
>>
>> =A0 =A0On Sep 30, 2013, at 9:09 AM, Benoit Claise <bclaise@cisco.com>
>> wrote:
>>
>> =A0 =A0> Hi Ted,
>> =A0 =A0>> Hi Rolf
>> =A0 =A0>>
>> =A0 =A0>> +1
>> =A0 =A0>>
>> =A0 =A0>> Thanks for clearly articulating the points. I tota= lly agree
>> the charging state should be orthogonal to power state.
>> =A0 =A0>>
>> =A0 =A0>> My position is that battery should _also_ have pow= er state
>> indicating if it is receiving power (charging) or giving power to = the
>> electrical network, and how much
>> =A0 =A0> That makes sense.
>> =A0 =A0>
>> =A0 =A0> Regards, Benoit
>>
>>
>> =A0 =A0In my limited experience with battery controllers batteries= are
>> either:
>>
>> =A0 =A0charging
>> =A0 =A0discharging
>> =A0 =A0full
>> =A0 =A0empty
>>
>> =A0 =A0in all cases =A0state of charge, e.g. capacity is germain.<= br> >>
>>
>> =A0 =A0>>
>> =A0 =A0>> This will be useful to account for all the power s= ource and
>> sink
>> =A0 =A0>>
>> =A0 =A0>> Best
>> =A0 =A0>>
>> =A0 =A0>> -tg-
>> =A0 =A0>> Sent from my iPhone
>> =A0 =A0>>
>> =A0 =A0>>> On Sep 25, 2013, at 6:18 AM, Rolf Winter
>> <Rolf.Winter@neclab.eu= > wrote:
>> =A0 =A0>>>
>> =A0 =A0>>> Hi,
>> =A0 =A0>>>
>> =A0 =A0>>> this thread attempts to close an open issue in= the framework
>> document (v10) where section 9.1.4 reads:
>> =A0 =A0>>>
>> =A0 =A0>>> 9.1.4. Batteries Power State Set
>> =A0 =A0>>>
>> =A0 =A0>>> =A0 =A0 =A0 =A0Batteries have operational and = administrational states
>> that
>> =A0 =A0>>> =A0 =A0 =A0 =A0could be represented as a power= state set. Since the
>> work
>> =A0 =A0>>> =A0 =A0 =A0 =A0for battery management is paral= lel to this document,
>> we are
>> =A0 =A0>>> =A0 =A0 =A0 =A0not proposing any Power State S= ets for batteries at
>> this
>> =A0 =A0>>> =A0 =A0 =A0 =A0time.
>> =A0 =A0>>>
>> =A0 =A0>>> I argue that batteries have no power states gi= ven the power
>> state definition:
>> =A0 =A0>>>
>> =A0 =A0>>> =A0 =A0 =A0 =A0A Power State is a condition or= mode of a device that
>> =A0 =A0>>> =A0 =A0 =A0 =A0broadly characterizes its capab= ilities, power
>> =A0 =A0>>> =A0 =A0 =A0 =A0consumption, and responsiveness= to input.
>> =A0 =A0>>>
>> =A0 =A0>>> There are charging states currently defined in= the battery
>> MIB, which seem to be orthogonal to power states. I guess a univer= sal
>> power state set is "on" and "off". Any device = can really be in one of
>> these two modes. Even a simple light bulb. What would be "on&= quot; for a
>> battery? Maybe charging because it receives energy (like any other=
>> device that is actually "on")? But every device that is = on, fulfills
>> its primary function. I would argue that the primary function of a=
>> battery is to provide energy. Batteries are different and I maybe = we
>> should ack this fact and not try to create battery power state set= s
>> just because we have this for devices.
>> =A0 =A0>>>
>> =A0 =A0>>> I think the Email thread http://www.ietf.org/mail-
>> archive/web/eman/current/msg02000.html seemed to agree that chargi= ng
>> states and power states are orthogonal. If they are, why should th= ey be
>> of the same class? The problem is that the power state above as us= ed
>> for devices would suggest that if a device is off, it does not con= sume
>> any energy. But if the battery is charging, then it does (given th= at
>> the battery is modeled as part of the device). So if a power state= is
>> indeed conflating power consumption and capabilities, then a devic= e
>> would be in two different power states at the same time. But it is= not.
>> It is in one power state and the batteries in it are in a certain<= br> >> charging state and each of these can be freely combined. I.e.
>> charging/on, discharging/on, charging/off etc... I guess the main<= br> >> question is, what is the advantage of defining a charging state as= a
>> power state (the set of charging states as a power state set)?
>> =A0 =A0>>>
>> =A0 =A0>>>
>> =A0 =A0>>> Best,
>> =A0 =A0>>>
>> =A0 =A0>>> Rolf
>> =A0 =A0>>>
>> =A0 =A0>>> NEC Europe Ltd | Registered Office: Athene, Od= yssey Business
>> Park, West End =A0Road, London, HA4 6QE, GB | Registered in Englan= d
>> 2832014
>> =A0 =A0>>>
>> =A0 =A0>>>
>> =A0 =A0>>> ______________________________________________= _
>> =A0 =A0>>> eman mailing list
>> =A0 =A0>>> eman@ietf.org=
>> =A0 =A0>>> https://www.ietf.org/mailman/listinfo/eman >> =A0 =A0>> _______________________________________________ >> =A0 =A0>> eman mailing list
>> =A0 =A0>> eman@ietf.org=
>> =A0 =A0>> https://www.ietf.org/mailman/listinfo/eman
>> =A0 =A0>> .
>> =A0 =A0>>
>> =A0 =A0>
>> =A0 =A0>
>> =A0 =A0> _______________________________________________
>> =A0 =A0> eman mailing list
>> =A0 =A0> eman@ietf.org
>> =A0 =A0> https://www.ietf.org/mailman/listinfo/eman
>> =A0 =A0>
>>
>>
>>
>> =A0 =A0_______________________________________________
>> =A0 =A0eman mailing list
>> =A0 =A0eman@ietf.org
>> =A0 =A0https://www.ietf.org/mailman/listinfo/eman
>>
>>
>>
>>
>>
>>
>> --
>> Bruce Nordman
>> Lawrence Berkeley National Laboratory
>> nordman.lbl.g= ov
>> BNordman@LBL.gov
>> 510-486-7089
>> m: 510-501-794= 3
>
>
>




--
Bruce Nordman
La= wrence Berkeley National Laboratory
nordman.lbl.g= ov
BNordman@LBL.gov
510-486-7089
m: 510-501-7943
--001a11c2c54c892c3004e7c625ee-- From bnordman@lbl.gov Wed Oct 2 15:14:00 2013 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 DC6FA21F991F for ; Wed, 2 Oct 2013 15:14:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.646 X-Spam-Level: X-Spam-Status: No, score=-4.646 tagged_above=-999 required=5 tests=[AWL=1.331, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qE9ctSimCKCv for ; Wed, 2 Oct 2013 15:13:50 -0700 (PDT) Received: from fe1.lbl.gov (fe1.lbl.gov [128.3.41.133]) by ietfa.amsl.com (Postfix) with ESMTP id 7CBBE21F9E6B for ; Wed, 2 Oct 2013 15:13:29 -0700 (PDT) X-Ironport-SBRS: 5.5 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: At8BAIeZTFLRVdgwm2dsb2JhbABQBgOCQ3xSuHaIRIESCBYOAQEBAQEGCwsJFCiCJQEBAQMBAQEBFwECCkcEBwUHAgILCwYEAQEhAQYHGwcFDQEFAQsJCAYTiAAGDJ9InjMEjX4NAweBKAwEBgEGC4QSA4k5imuDXYEvjmUYKYRuHIEs X-IronPort-AV: E=Sophos;i="4.90,1021,1371106800"; d="scan'208";a="29628783" Received: from mail-qa0-f48.google.com ([209.85.216.48]) by fe1.lbl.gov with ESMTP; 02 Oct 2013 15:13:26 -0700 Received: by mail-qa0-f48.google.com with SMTP id hu16so1071274qab.7 for ; Wed, 02 Oct 2013 15:13:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=zC//3c9R/Q+0Ec4Ev6g/7VvJoGKAf5MCpkv1sOpEJ8o=; b=Ya+mM/mAbu53TSpm/CgikhQJ7ltL5Xk+sTUDHXpFYyyNY+Gpa2LXkHMjngodA0HRTA hWnJ2yEJRAByWAr/gTANEWQcjAF/zgK91Z07ZCwKQwxO2I7z4yt8JrBzI6fdI7R3uenR k2968zmhtCPv+m/IBeeJ8zxDA4usf7x+Id8qYSf0ueSoUITdfVdiC5tuWj6cM0na3n01 TezGyFTqip7bPWOiSIM9jhK4VVGboFl8YlgIVsvdck/1CKzzcnhXe466mXrycdBHospb Usu/xH8Z6t3clNNP5U7A8JDxYWQy+JxPBMSsuE0LnBF2egt1Z2Tc56xJkVYhjQCHXvPS 8pZg== X-Gm-Message-State: ALoCoQlHKhABIJeMPlULR00OoeaoV/wpYFUYQVv1flHwKav2xuJiqGaSywVoetg3E/A2krKCgbpHv8z6wBH6qVsu1x/eDpp2w+ttnpw/nXkUjMuTLEqw/b/khXrzxOOPaILTOnPGEbI6 X-Received: by 10.49.39.39 with SMTP id m7mr5856786qek.60.1380752006380; Wed, 02 Oct 2013 15:13:26 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.49.39.39 with SMTP id m7mr5856716qek.60.1380752005283; Wed, 02 Oct 2013 15:13:25 -0700 (PDT) Received: by 10.140.80.212 with HTTP; Wed, 2 Oct 2013 15:13:25 -0700 (PDT) In-Reply-To: <9AB93E4127C26F4BA7829DEFDCE5A6E85A41C6F0@DAPHNIS.office.hd> References: <9AB93E4127C26F4BA7829DEFDCE5A6E85A41C6F0@DAPHNIS.office.hd> Date: Wed, 2 Oct 2013 15:13:25 -0700 Message-ID: From: Bruce Nordman To: Juergen Quittek Content-Type: multipart/alternative; boundary=047d7bdc1564cc55ec04e7c9602a Cc: "eman@ietf.org" , "ops-ads@tools.ietf.org" Subject: Re: [eman] WG Last Call for EMAN Framework -09 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2013 22:14:01 -0000 --047d7bdc1564cc55ec04e7c9602a Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Review of draft-ietf-eman-framework-09 (I think little of this any different in -10) The EMAN Framework draft is improving, as has been noted. That said, the comments below plus those in the review a few days ago from Juergen Quittek indicate that the document still has far to go. This list is not comprehensive--that is not feasible with so much to address. In addition, fixes that these comments lead to are likely to introduce new issues or make clear existing ones that are not now readily apparent. As this document has changed considerably over the past three+ years, new issues continue to crop up. Conceptual issues: The mechanisms described for importance and role are non-standard and arbitrary. We might do well to have standard mechanisms for some of these, but creating an anecdotal set solely in the context of EMAN seems unlikely to contribute to that. Until such time as there is some basis for incorporating specific content, these should be left as free-form keywords encoded in some standard syntax. The "relationship" concept is not necessary. Simpler methods can express what is required. It makes the document harder to understand, and so is a barrier to it being widely adopted. It is stated that a device should be labeled as "a consumer, producer, or meter, distributor, or store of energy". It isn't explained what the value of making this distinction is. The concept of "caliber"is not needed; accuracy is sufficient. The draft states that a device must have at least two states: one on state and one off state. There are devices for sale that have two states, on and sleep (but no off) and devices with only one state. Why have this restriction? and why require a device to report power states at all? most will certainly but some might appropriately not do so. The explanation of power state semantics in 4.5 is not consistent with general usage of the concept of power state. Power limitation may be useful, but it is a different concept from power state and should not be conflated. 4.5.4. These are arbitrary. It would be better to specify registration of the Cisco power state set since that is presumably already in use. 4.6. Power Source Relationship and Metering Relationship are redundant. As the text points out, both are about wiring topologies. 4.6.3. The second and last paragraphs seem to be contradictory as to whether two non-connected PIs can have a Power Source Relationship. 4.6.3. It is not clear how metering is to be applied. 4.6.4. It is stated that "Establishing aggregation relationships within the same device would make modeling more complex=85". The ER Framework accomplishes this without any complexity burden, so the statement in general is not true. It may be true of the EMAN Framework but that is simply a flaw in the document. 4.6.5. The text leaves "proxy" relationships for future development, but there are requirements (8.1) for proxy control that the framework seems to not cover. 6. It is stated that some products cannot support power interfaces. Any device can and could simply report "unknown" for data they do not know. 6.1. The draft indicates that power interfaces can be between devices and components. This adds a lot of complexity to the PI concept. It would be much simpler to not allow PIs between components. For those niche applications that desire that, the component in question could be modeled as a distinct device. Thus, complexity of EMAN could be reduced without sacrificing capability. Aggregation: 4.6. It is completely unclear how the Aggregation Relationship mentioned is supposed to operate. 4.6.4. It is suggested that a device can report only a single aggregation. Is that true? 6.3. explains what aggregation is, but not how it actually works. The two sentences in the middle paragraph contradict each other. Corrections: The introductions states that "The framework introduces the concept of a power interface". This is not true. The power interface concept was introduced in draft-quittek-eman-reference-model-02, over two years ago. Also, the definition provided for Power Interface doesn't make sense, and does not correspond to the concept described in the Reference Model, or the ER Framework. The latter has a clear explanation, the first sentence of which could be a definition. The bulleted text under 4.5.2 on IEEE 1621 is wrong. I have pointed this out many many times without it being fixed. Also, for 4.5.5, IEEE 1621 does NOT say that hibernate is a form of sleep; it says that hibernate should be presented as a form of off. This error has also been pointed out many times. Details: 2. Definition of "Meter". Change "intended to measure" to "that measures". In general, what is the difference intended when "are intended to" is used as opposed to what the referenced concepts actually do? Unnecessary text: The document is burdened throughout by text that is unnecessary to accomplish what is needed. This makes reading it more difficult and so would impede use of the standard. An example is defining and discussing Non-Electrical Equipment. This is more appropriate to an application/implementation discussion document, not a framework. Other examples include the list of target devices in Section 3.1, all of Section 3.4, sections 4.3.3, 4.3.4, 4.3.5, the second half of 4.3.6, and the middle two paragraphs of 4.4. The requirements RFC says: 5.5.1. Energy Measurement The standard must provide means for reporting measured values of energy and the direction of the energy flow received or provided by an entity. The standard must also provide the means to report the energy passing through each Power Interface. The Framework says: 4.4.3. Measurements: Energy Optionally, an Energy Object that can report actual power readings will have energy attributes that provide the energy used, produced, or stored in kWh. Aside from noting that kWh are to be used, what is the point of saying this at all? and if this is about reporting energy, why does the text talk about power? On Fri, Sep 27, 2013 at 9:56 PM, Juergen Quittek wrote: > Dear all, > > Here is my review of draft-ietf-eman-framework-10. I did not review > version -09 for which the call was made, but the newer version -10 that w= as > posted during last call. > > Seeing the list off issues I found, I believe that there is still a long > way to go to get this draft into reasonable shape. > > I tried to make constructive comments by suggesting text replacements to > solve some of the issues that I describe below, but some comments need mo= re > work, such as 15. (missing reference model definition), 16. (confused lis= t > of concerns), etc. > > I have not yet fully checked the examples in Section 6, since I expect > that this would better be done after some of the issues in Sections 1-5 > have been settled. > > > General comments: > > A. The document rather looks like a documentation of a software design > (with some extensions) than like a framework for energy management. > Modeling focusses on abstractions, classes, attributes, but issues of the > physical world are neglected. > > B. Do we claim that energy management is (a) a part of network management > extending FCAPS or do we see this energy management (b) as something > separate from network management? Several statements in the draft seem to > assume (b). > > C. The text has improved from earlier versions. Still, phrasing is often > sloppy and not up to the quality we should have for RFCs. Many phrasings > sound nice, but only as long as you are not interested in understanding > exactly what they mean. I commented on several instances below, but by fa= r > not on all of them. > > D. I have not thoroughly reviewed the ridiculously long terminology > section on pages 5-10. This can be cut significantly. Do we really want t= o > re-define terms you can find in text books, such as power-->Power, > energy-->Energy, device-->Device, etc., etc.? It is certainly necessary = to > define a term like "Power State", But defining "Power State Set" as a set > of power states, etc., etc. is just a waste. > > E. The physical reference model in section 3.2 is missing most of the > required content. Basic components of the model are not defined, see item > 15. below. Further missing is the physical mode of a meter and of a power > interface. > > F. The information model in this draft is lacking elements for battery > management. > > G. Technically, I would like to make a proposal for Sections 4.3.2-4.3.6, > the context information as there are currently: category, importance, > keywords, role, and domain. I see that all of them can have their value i= n > certain deployments. However, I see two limitations: > G.1. The set of content information is fixed. > All of the included attributes have potential to be useful in certain > deployments. However, in other scenarios, or with other management system= s, > other context information will be relevant, such as, for example, the > devices location or its power-down-priority. > G.2. There is only one instance of each per Energy Object > The current model allows for only one instance of each context attribute. > This is often not sufficient, particularly for type, role, and domain. As > discussed many times on the list, a device can be contained in multiple > metering domain, ad device can have multiple roles, and it can match > multiple categories, such as, for example, distributor and meter. > What I think is needed is a more open and extensible framework for contex= t > information, that allows arbitrary context information and multiple > instances of each context. The result could, for example, in XML look lik= e > > distributor > meter > PDU > East Wing > Server Room > Building A > East Wing Level 3 > 0.7 > > or in JSON look like > "context": { > "category": [ "distributor", "meter" ], > "role": "PDU", > "location": [ "East Wing", "Server Room" ], > "meteringDomain": [ "Building A", "East Wing Level 3" ], > "costFactor": 0.7 > } > > > Specific comments: > > 1. Abstract, line 1: "This document defines a framework for providing > Energy Management ..." > Why for only for 'providing' energy management? Why not as well for > operating, maintaining, etc. I suggest deleting 'providing'. > > 2. Abstract, lines 5-7: "The information model consists of an Energy > Management Domain as a set of Energy Objects. Each Energy Object is > identified, classified, and given context." > Obviously, the first sentence is nonsense. The second sentence is only > correct if it is mandatory to add context and classification to every > energy object. I do not see this in the framework. I suggest replacing th= e > quoted text it with "The information model describes Energy Objects to > which information on their identity, classification, and context can be > attributed." > > 3. Abstract, lines 7-9: "Energy Objects can be monitored and controlled > with respect to Power, Power State, Energy, Demand, Power Attributes, and > Battery." > Control is only available for power states and for battery states. The > current text implies much more. I suggest clarifying this, for example, > using the following text as replacement: "The framework covers monitoring > of Power, Power State, Energy, Demand, Power Attributes, battery properti= es > and battery states of Energy Objects. It also covers control of power > states and battery states." > > 4. Section 1 "Introduction", 2nd paragraph, lines 3-4 (page 3): "router" > --> "" > > 5. Section 1 "Introduction", 2nd paragraph, lines 8-9 (page 4): "If a > device contains batteries, these can also be monitored and controlled." > Obviously, it is not sufficient that a device just contains batteries for > being able to control them. I suggest replacing the text by "Monitoring a= nd > control of batteries contained in devices is also covered by the EMAN > framework. > > 6. Section 1 "Introduction", 5th paragraph, last 2 lines: "and an > understanding of the potential aggregation (ex: does a meter aggregate > values from other devices)" > I do not think it is clear at this place what "aggregation"/"aggregate" > means. > > 7. Section 2: Terminology, page 9, "Power Interface" > The text says: "A Power Interface (...) is an information model (class) > that represents ...". This is wrong. A Power interface is located at a > device and is not an abstract class. The abstract class is called "Power > Interface Class", see section 4.2.3 > > 8. Section 2: Terminology, page 9, "Energy Object" > See point 7. above. These are physical objects, not classes. > > 9. Section 3.1, 3rd paragraph, last sentence: "These target devices > include:" > I don't think the list below is exclusive. Suggestion: "These target > devices include, for example:" > > 10. Section 3.1, 4th paragraph, line 1: "Target devices will primarily > communicate via Internet Protocols" > Why "will"? Probably correct would be "do". > > 11. Section 3.1, 4th paragraph, lines 2-3: "The target devices may also > include those communicating via non-IP protocols ..." > What's this? Do we here defining a standard? Either the standard includes > non-IP devices or not. > > 12. Section 3.1, 4th paragraph, lines 4-5: "These types of target devices > are expected to be managed through gateways ..." > What means "are expected"? What if this is not the case? > A proposal for solving 10., 11., and 12.: > OLD > Target devices will primarily communicate via Internet > Protocols (IP). The target devices may also include those > communicating via non-IP protocols deployed among the power > distribution and IP communication network. These types of > target devices are expect to be managed through gateways or > proxies that can communicate using IP. > NEW > Target devices include devices that communicate via the Internet > Protocol (IP) as well as devices using other means for > communication. > The latter are managed through gateways or proxies that can > communicate using IP. > > 13. Section 3 "Concerns Specific to Energy Management" > This section describes target devices, a physical reference model, and > "major concerns specific to Energy Management". Giving it a title that > covers only the third item contained is inappropriate. > > 14. Section 3 "Concerns Specific to Energy Management", 2nd sentence: > "physical reference models" and Section 3.2 "Physical Reference Model", > first sentence: "The following reference models describe ..." > Here we have a terminology issue: The title of the section is "Physical > Reference Model" and also the Abstract of the draft states "The framework > presents a physical reference model ...". Both use the singular form of > model. But the second sentence of Section 3 and the first sentence of > section 3.2 talk about multiple models. I think the Abstract and the > section title are correct, but the sentence is wrong. There seem to be ju= st > a single model which is used to illustrate different scenarios in the > figures in this section. > > 15. Section 3.2 "Physical Reference Model" > A model is used, but I cannot find it described in the draft, neither in > this section where one would expect it, nor anywhere else. Where is it? > Just to be clear, a reference model typically consists of a set of roles, > such as, for example, device, energy management system, power source, etc= ., > and of relations, such as a power source relationship, a monitoring > relationship, a control relationship, etc. I cannot find these defined as > components of the model. > > 16. Section 3.3 "Concerns Differing from Network Management" > This section rather looks like a power point slide that can hardly be > understood without a person presenting it. The bullets in this section ar= e > too short for the reader to easily understand what issue is addressed at > all and what the consequences are. Some of the bullets do not make any > sense to me. At least 6 out of 7 seem to be broken: > - bullet #1: This does not seem to be different from network management > - bullet #2: I don't understand the last line: "controlling a simple > light by controlling its outlet". How does this work? > - bullet #3: What special coordination do devices need if there is more > than one PDU in a power distribution network? > - bullet #4: What means "require a separate interface model from Networ= k > Management"? > - bullet #5: Seems to be broken. I don't get the message. Is there a > typo in the last line? > - bullet #7: I am not sure what is really a difference to network > management where we have the entity MIB and different models for managing > devices (e.g. routers) and components (e.g. line cards). The third > paragraph of Section 4.1 claims that this is very similar to network > management. > > 17. Section 3.4 "Concerns Not Addressed", 1st paragraph, line 4: > "normalized to the electrical units for power and energy". This is > nonsense. There is indeed an "electrical" units for power (Voltamperes,VA= ), > but we are using rather "non-electrical ones, such as Watts (Joule per > second) and Watt-hours. > OLD > Non-Electrical Equipment > > The primary focus of this framework is the management of > Electrical Equipment. Some Non-Electrical Equipment may be > connected to communication networks and could have their > energy managed if normalized to the electrical units for > power and energy. Non- > Electrical equipment that do not convert-to or present-as > equivalent to Electrical Equipment is not addressed. > NEW > Non-Electrical Equipment > > The primary focus of this framework is the management of > Electrical Equipment. Non-Electrical Equipment can be covered > by the framework only if it provides interfaces that comply with > the framework. For example, it must use the same units for power > and energy. > > 18. Section 4 "Energy Management Abstraction" > The first paragraph is identical with the first paragraph of Section 1 > "Introduction" and can be removed. > > 19. Section 4.1 "Conceptual Model" > I am missing here a lot of information on the model. > 19.1. Is the model normative or informational? > 19.2. Is it a model to be implemented inside the EnMS only or as well on > the Energy Objects? > 19.3. If it is implemented at the Energy Objects, why storing context > information? This typically resides in the management system only. > 19.4. If it is implemented on Energy Objects, how does it specify which > information is included for a device, and which (more limited) informatio= n > is included for a component or power interface? > 19.5. The model is lacking information on batteries. > > 20. Section 4.1, 3rd paragraph, line 1: "Therefore"-->"" > > 21. Section 4.1, 4th paragraph, line 2: "a Device, a Component, and a > Power Interface" > -->"a Device class, a Component class, and a Power Interface class" > > 22. Section 4.1, 5th paragraph, line 2 > OLD > For modeling additional attributes, this section describes > attributes of an Energy Object for: identification, > classification, context, control, power and energy. > NEW > This section describes attributes of an Energy Object for > identification, > classification, context, control, power and energy. > > 23. Section 4.1, 6th paragraph. > The first sentence seems to be broken. The "interconnections for Network > Management" are also used for Energy Management. Energy management needs = at > least some of them to communicate between the EnMS and devices. > > 24. Section 4.1, title > This section is titled "Conceptual Model". But as the last paragraph of i= t > states, the conceptual model is actually not in this section, but in the > following sections 4.2-4.6. The title should be changed after fixing 20.-= 23. > > 25. Section 4.2, title > "Energy Object" --> "Energy Object Class" > > 26. Section 4.2.1, 2nd paragraph, line 2: "may represent" --> "represents= " > > 27. Section 4.2.1, 2nd paragraph: > Is this list exclusive? Are there no other kinds of devices supported? > > 28. Section 4.2.1, 2nd paragraph: > A device may be both, a meter and a distributor. How is this modeled? > > 29. Section 4.2.1, 3rd paragraph: > OLD > A Device Class instance may represent a physical device > that contains other components. > NEW > A Device Class instance may represent a physical device > that contains other components. > > 30. Section 4.3.1, 2nd sentence: "Ideally, the UUID is used to distinguis= h > the Energy Object within the EnMS". Why ideally? What can be ideal for us > info model designer does not necessarily have to be ideal for the EnMS > developer. > > 31. Section 4.3.2. "Context in General" > What I am missing in this section > > 32. Section 4.3.2, last paragraph: > I do not see the point made by this paragraph. How would context > information help the EnMS in this case? > > 33. Section 4.4, "Measurements", 2nd paragraph: > This is similar to item 17. There is no electrical or non-electrical > Watt-hour. > OLD > For the purposes of this framework, energy will be limited > to electrical energy in watt-hours. Other forms of Energy > Objects that use or produce non-electrical energy may be > modeled as an Energy Object but must provide information > converted to and expressed in watt-hours. > NEW > Within this framework, energy will only be quantified in units of > in watt-hours. Energy Objects and Meters measuring Energy in > other units must convert values to Watt-hours before reporting > them. > > 34. Section 4.4.1 "Measurements: Power", line 1: > "Each Energy Object contains a Nameplate Power attribute that describes > the nominal power as specified by the manufacturer." I am not sure, you > will always find someone reading all the nameplate power values and > entering them to the device or the EnMS. > OLD > Each Energy Object contains a Nameplate Power attribute > NEW > Each Energy Object may contain a Nameplate Power attribute > > 35. Section 4.4.1 "Measurements: Power", 2nd paragraph, line 1: > OLD > Each Energy Object will have information that describes the > NEW > Each Energy Object may have information that describes the > OR NEW > Each Energy Object has information that describes the > > 35. Section 4.4.4, last sentence: "Demand measurements can be provided > when the Energy Object is capable of measuring actual power." > This is wrong. Either delete this sentence (preferred) or use this one > instead: "Demand measurements can only be provided when the Energy Object > is capable of measuring demand." > > 36. Section 4.5 "Control", first sentence: An Energy Object can be > controlled by setting a Power State or a battery state. > > 37. Section 4.5 "Control" > Power States and Power State sets are introduced in Section "Control". > That's wrong. Many devices will allow monitoring of power states only, > particularly devices, that control power states by themselves or by manua= l > users interaction only. The concept of power states should be explained > outside of section 4, either in a subsection of section 3 or in a new > separate section between current sections 3 and 4. > > 38. section 4.5.1 "Power State Sets" > Why is the ACPI power state set excluded from the list of existing sets? > ACPI power states should have their own subsection as IEEE1621 and DMTF > have. > > 39. Section 4.5.4. "Power State Set: IETF EMAN" > Shouldn't we call this rather "Power State Set: Cisco EnergyWise"? > > 40. Section 4.5.4, first sentence: > "An EMAN Power State Set represents an attempt at a standard approach for > modeling the different levels of power of a device." The same holds for > every other power state set, particularly for the ones mentioned in the > subsections above. I suggest removing this sentence. > > 41. Section 4.5.4. > I am fine with the non-operational power states that also other ACPI and > DMTF support similarly, but I have problems with the operational states > (7-12). They are defined only relatively to each other stating that one > with a lower number "provides less usage" than a higher number. > 41.1: Is "providing usage" proper terminology? > 41.2: What is meant with "provide less usage"? Does it mean that usage > numbers are ALWAYS lower than in a higher state? Even if measured in shor= t > time intervals? Such a behavior would hardly be implementable on many > devices. > 41.3: In the real world, power states have ranges of power values that > they cover and some have wider ranges than others. This can hardly be > modeled by a power state set that only knows a strict consecutive order o= f > power states and power values. > > 42. Section 4.6, 2nd paragraph, first sentence: "Relationships are modele= d > with a Relationship class that contains the UUID of the participants in t= he > relationship ...": > "of the participants" --> "of the other participant" > > 43. Section 5 "Energy Management Information Model" > The text states that this model is a "reference for implementers". > Obviously, the model is useful for management system implementers. What i= s > not discussed is how to use it for implementations of EMAN on devices, > components and interfaces. The model does not give guidance for these. > Among the missing information for these cases is what needs to be > implemented on different classes of devices. > > Cheers, > Juergen > > > -----Original Message----- > > From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of > > Nevil Brownlee > > Sent: Dienstag, 10. September 2013 23:28 > > To: eman@ietf.org > > Cc: ops-ads@tools.ietf.org > > Subject: [eman] WG Last Call for EMAN Framework -09 > > > > > > Hi all: > > > > A new revision of the EMAN Framework draft was published yesterday. > > Version -09 has many changes, improvements and clarifications since the > -08 > > version (published just before IETF-87 in Berlin). > > > > The WG Last Call for it starts now, and will end on Friday, 27 Septembe= r. > > > > Please read it now, and send your comments/suggestions/etc to the EMAN > list. > > Comments like "seems fine now" are good, as are suggestions for further > > improvement (accompanied by OLD/NEW text). > > > > Cheers, Nevil > > > > -- > > --------------------------------------------------------------------- > > Nevil Brownlee Computer Science Department > > Phone: +64 9 373 7599 x88941 The University of Auckland > > FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand > > _______________________________________________ > > eman mailing list > > eman@ietf.org > > https://www.ietf.org/mailman/listinfo/eman > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman > --=20 *Bruce Nordman* Lawrence Berkeley National Laboratory *nordman.lbl.gov* BNordman@LBL.gov 510-486-7089 m: 510-501-7943 --047d7bdc1564cc55ec04e7c9602a Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Review of draft-ietf-eman-framework-09
(I think little = of this any different in -10)

The EMAN Framework draft is improving,= as has been noted.=A0 That said,
the comments below plus those in the r= eview a few days ago from Juergen
Quittek indicate that the document still has far to go.=A0 This list
is = not comprehensive--that is not feasible with so much to address.
In addi= tion, fixes that these comments lead to are likely to introduce
new issu= es or make clear existing ones that are not now readily apparent.
As this document has changed considerably over the past three+ years,
n= ew issues continue to crop up.


Conceptual issues:

The mec= hanisms described for importance and role are non-standard and
arbitrar= y.=A0 We might do well to have standard mechanisms for some
of these, but creating an anecdotal set solely in the context of EMAN
se= ems unlikely to contribute to that.=A0 Until such time as there is some
= basis for incorporating specific content, these should be left as
free-= form keywords encoded in some standard syntax.

The "relationship" concept is not necessary.=A0 Simpler metho= ds can express
what is required.=A0 It makes the document harder to unde= rstand, and so
is a barrier to it being widely adopted.

It is sta= ted that a device should be labeled as "a consumer, producer,
or meter, distributor, or store of energy".=A0 It isn't explained = what the
value of making this distinction is.

The concept of &quo= t;caliber"is not needed; accuracy is sufficient.

The draft stat= es that a device must have at least two states: one
on state and one off state.=A0 There are devices for sale that have
two= states, on and sleep (but no off) and devices with only one
state.=A0 W= hy have this restriction?=A0 and why require a device to
report power st= ates at all?=A0 most will certainly but some might
appropriately not do so.

The explanation of power state semantics in= 4.5 is not consistent
with general usage of the concept of power state.= =A0 Power limitation
may be useful, but it is a different concept from p= ower state and
should not be conflated.

4.5.4. These are arbitrary.=A0 It would be = better to specify registration
of the Cisco power state set since that i= s presumably already in use.

4.6. Power Source Relationship and Mete= ring Relationship are redundant.
As the text points out, both are about wiring topologies.

4.6.3. The= second and last paragraphs seem to be contradictory as
to whether two n= on-connected PIs can have a Power Source Relationship.

4.6.3. It is = not clear how metering is to be applied.

4.6.4. It is stated that "Establishing aggregation relationships w= ithin
the same device would make modeling more complex=85".=A0 The = ER Framework
accomplishes this without any complexity burden, so the sta= tement in
general is not true.=A0 It may be true of the EMAN Framework but that issimply a flaw in the document.

4.6.5. The text leaves "proxy&q= uot; relationships for future development,
but there are requirements (8= .1) for proxy control that the framework
seems to not cover.

6. It is stated that some products cannot suppor= t power interfaces.
Any device can and could simply report "unknown= " for data they do not know.

6.1. The draft indicates that powe= r interfaces can be between devices and
components.=A0 This adds a lot of complexity to the PI concept.=A0 It would=
be much simpler to not allow PIs between components.=A0 For those niche=
applications that desire that, the component in question could be model= ed
as a distinct device.=A0 Thus, complexity of EMAN could be reduced without<= br>sacrificing capability.

Aggregation:

4.6. It is completely= unclear how the Aggregation Relationship mentioned
is supposed to opera= te.

4.6.4.=A0 It is suggested that a device can report only a single aggreg= ation.
Is that true?

6.3. explains what aggregation is, but not h= ow it actually works.
The two sentences in the middle paragraph contrad= ict each other.
=A0
Corrections:

The introductions states that "The framewor= k introduces the concept of
a power interface".=A0 This is not true= .=A0 The power interface concept
was introduced in draft-quittek-eman-re= ference-model-02, over two
years ago.=A0 Also, the definition provided for Power Interface doesn't=
make sense, and does not correspond to the concept described in the
= Reference Model, or the ER Framework.=A0 The latter has a clear explanation= ,
the first sentence of which could be a definition.

The bulleted text= under 4.5.2 on IEEE 1621 is wrong.=A0 I have pointed
this out many many= times without it being fixed.=A0 Also, for 4.5.5,
IEEE 1621 does NOT s= ay that hibernate is a form of sleep; it says that
hibernate should be presented as a form of off.=A0 This error has also
b= een pointed out many times.

Details:

2. Definition of "M= eter".=A0 Change "intended to measure" to "that measure= s".
In general, what is the difference intended when "are intended to"= ; is
used as opposed to what the referenced concepts actually do?
Unnecessary text:

The document is burdened throughout by text that = is unnecessary to
accomplish what is needed.=A0 This makes reading it more difficult and
s= o would impede use of the standard.=A0 An example is defining and
discus= sing Non-Electrical Equipment.=A0 This is more appropriate to
an applica= tion/implementation discussion document, not a framework.
Other examples include the list of target devices in Section 3.1, all
of= Section 3.4, sections 4.3.3, 4.3.4, 4.3.5, the second half of 4.3.6,
an= d the middle two paragraphs of 4.4.

The requirements RFC says:
5.5.1.=A0 Energy Measurement
=A0=A0 The standard must provide means for = reporting measured values of
=A0=A0 energy and the direction of the ener= gy flow received or provided by
=A0=A0 an entity.=A0 The standard must a= lso provide the means to report the
=A0=A0 energy passing through each Power Interface.
The Framework says:<= br>=A0=A0=A0 4.4.3. Measurements: Energy
=A0=A0=A0=A0=A0=A0=A0 Optional= ly, an Energy Object that can report actual power
=A0=A0=A0=A0=A0=A0=A0= readings will have energy attributes that provide the
=A0=A0=A0=A0=A0=A0=A0 energy used, produced, or stored in kWh.=A0
Aside= from noting that kWh are to be used, what is the point of saying
this a= t all?=A0 and if this is about reporting energy, why does the text
talk = about power?



On = Fri, Sep 27, 2013 at 9:56 PM, Juergen Quittek <Quittek@neclab.eu> wrote:
Dear all,

Here is my review of draft-ietf-eman-framework-10. I did not review version= -09 for which the call was made, but the newer version -10 that was posted= during last call.

Seeing the list off issues I found, I believe that there is still a long wa= y to go to get this draft into reasonable shape.

I tried to make constructive comments by suggesting text replacements to so= lve some of the issues that I describe below, but some comments need more w= ork, such as 15. (missing reference model definition), 16. (confused list o= f concerns), etc.

I have not yet fully checked the examples in Section 6, since I expect that= this would better be done after some of the issues in Sections 1-5 have be= en settled.


General comments:

A. The document rather looks like a documentation of a software design (wit= h some extensions) than like a framework for energy management. Modeling fo= cusses on abstractions, classes, attributes, but issues of the physical wor= ld are neglected.

B. Do we claim that energy management is (a) a part of network management e= xtending FCAPS or do we see this energy management (b) as something separat= e from network management? Several statements in the draft seem to assume (= b).

C. The text has improved from earlier versions. Still, phrasing is often sl= oppy and not up to the quality we should have for RFCs. Many phrasings soun= d nice, but only as long as you are not interested in understanding exactly= what they mean. I commented on several instances below, but by far not on = all of them.

D. I have not thoroughly reviewed the ridiculously long terminology section= on pages 5-10. This can be cut significantly. Do we really want to re-defi= ne terms you can find in text books, such as power-->Power, energy-->= Energy, device-->Device, etc., etc.? =A0It is certainly necessary to def= ine a term like "Power State", But defining "Power State Set= " as a set of power states, etc., etc. is just a waste.

E. The physical reference model in section 3.2 is missing most of the requi= red content. Basic components of the model are not defined, see item 15. be= low. Further missing is the physical mode of a meter and of a power interfa= ce.

F. The information model in this draft is lacking elements for battery mana= gement.

G. Technically, I would like to make a proposal for Sections 4.3.2-4.3.6, t= he context information as there are currently: category, importance, keywor= ds, role, and domain. I see that all of them can have their value in certai= n deployments. However, I see two limitations:
G.1. The set of content information is fixed.
All of the included attributes have potential to be useful in certain deplo= yments. However, in other scenarios, or with other management systems, othe= r context information will be relevant, such as, for example, the devices l= ocation or its power-down-priority.
G.2. There is only one instance of each per Energy Object
The current model allows for only one instance of each context attribute. T= his is often not sufficient, particularly for type, role, and domain. As di= scussed many times on the list, a device can be contained in multiple meter= ing domain, ad device can have multiple roles, and it can match multiple ca= tegories, such as, for example, distributor and meter.
What I think is needed is a more open and extensible framework for context = information, that allows arbitrary context information and multiple instanc= es of each context. The result could, for example, in XML look like
<context>
=A0 =A0 <category>distributor</category>
=A0 =A0 <category>meter</category>
=A0 =A0 <role>PDU</role>
=A0 =A0 <location>East Wing</location>
=A0 =A0 <location>Server Room</location>
=A0 =A0 <meteringDomain>Building A</meteringDomain>
=A0 =A0 <meteringDomain>East Wing Level 3</meteringDomain>
=A0 =A0 <costFactor>0.7</costFactor>
</context>
or in JSON look like
"context": {
=A0 =A0 "category": [ "distributor", "meter" = ],
=A0 =A0 "role": "PDU",
=A0 =A0 "location": [ "East Wing", "Server Room&qu= ot; ],
=A0 =A0 "meteringDomain": [ "Building A", "East Wi= ng Level 3" ],
=A0 =A0 "costFactor": 0.7
}


Specific comments:

1. Abstract, line 1: "This document defines a framework for providing = Energy Management ..."
Why for only for 'providing' energy management? Why not as well for= operating, maintaining, etc. I suggest deleting 'providing'.

2. Abstract, lines 5-7: "The information model consists of an Energy M= anagement Domain as a set of Energy Objects. Each Energy Object is identifi= ed, classified, and given context."
Obviously, the first sentence is nonsense. The second sentence is only corr= ect if it is mandatory to add context and classification to every energy ob= ject. I do not see this in the framework. I suggest replacing the quoted te= xt it with "The information model describes Energy Objects to which in= formation on their identity, classification, and context can be attributed.= "

3. Abstract, lines 7-9: "Energy Objects can be monitored and controlle= d with respect to Power, Power State, Energy, Demand, Power Attributes, and= Battery."
Control is only available for power states and for battery states. The curr= ent text implies much more. I suggest clarifying this, for example, using t= he following text as replacement: "The framework covers monitoring of = Power, Power State, Energy, Demand, Power Attributes, battery properties an= d battery states of Energy Objects. It also covers control of power states = and battery states."

4. Section 1 "Introduction", 2nd paragraph, lines 3-4 (page 3): &= quot;router" --> ""

5. Section 1 "Introduction", 2nd paragraph, lines 8-9 (page 4): &= quot;If a device contains batteries, these can also be monitored and contro= lled."
Obviously, it is not sufficient that a device just contains batteries for b= eing able to control them. I suggest replacing the text by "Monitoring= and control of batteries contained in devices is also covered by the EMAN = framework.

6. Section 1 "Introduction", 5th paragraph, last 2 lines: "a= nd an understanding of the potential aggregation (ex: does a meter aggregat= e values from other devices)"
I do not think it is clear at this place what "aggregation"/"= ;aggregate" means.

7. Section 2: Terminology, page 9, "Power Interface"
The text says: "A Power Interface (...) is an information model (class= ) that represents ...". This is wrong. A Power interface is located at= a device and is not an abstract class. The abstract class is called "= Power Interface Class", see section 4.2.3

8. Section 2: Terminology, page 9, "Energy Object"
See point 7. above. These are physical objects, not classes.

9. Section 3.1, 3rd paragraph, last sentence: "These target devices in= clude:"
I don't think the list below is exclusive. Suggestion: "These targ= et devices include, for example:"

10. Section 3.1, 4th paragraph, line 1: "Target devices will primarily= communicate via Internet Protocols"
Why "will"? Probably correct would be "do".

11. Section 3.1, 4th paragraph, lines 2-3: "The target devices may als= o include those communicating via non-IP protocols ..."
What's this? Do we here defining a standard? Either the standard includ= es non-IP devices or not.

12. Section 3.1, 4th paragraph, lines 4-5: "These types of target devi= ces are expected to be managed through gateways ..."
What means "are expected"? What if this is not the case?
A proposal for solving 10., 11., and 12.:
OLD
=A0 =A0 =A0 =A0 Target devices will primarily communicate via Internet
=A0 =A0 =A0 =A0 Protocols (IP). The target devices may also include those
=A0 =A0 =A0 =A0 communicating via non-IP protocols deploy= ed among the power
=A0 =A0 =A0 =A0 distribution and IP communication network. These type= s of
=A0 =A0 =A0 =A0 target devices are expect to be managed through gateways or=
=A0 =A0 =A0 =A0 proxies that can communicate using IP.
NEW
=A0 =A0 =A0 =A0 Target devices include devices that communicate via the Int= ernet
=A0 =A0 =A0 =A0 Protocol (IP) as well as devices using other means for comm= unication.
=A0 =A0 =A0 =A0 The latter are managed through gateways or proxies that can=
=A0 =A0 =A0 =A0 communicate using IP.

13. Section 3 "Concerns Specific to Energy Management"
This section describes target devices, a physical reference model, and &quo= t;major concerns specific to Energy Management". Giving it a title tha= t covers only the third item contained is inappropriate.

14. Section 3 "Concerns Specific to Energy Management", 2nd sente= nce: "physical reference models" and Section 3.2 "Physical R= eference Model", first sentence: "The following reference models = describe ..."
Here we have a terminology issue: The title of the section is =A0"Phys= ical Reference Model" and also the Abstract of the draft states "= The framework presents a physical reference model ...". Both use the s= ingular form of model. =A0But the second sentence of Section 3 and the firs= t sentence of section 3.2 talk about multiple models. I think the Abstract = and the section title are correct, but the sentence is wrong. There seem to= be just a single model which is used to illustrate different scenarios in = the figures in this section.

15. Section 3.2 "Physical Reference Model"
A model is used, but I cannot find it described in the draft, neither in th= is section where one would expect it, nor anywhere else. Where is it? Just = to be clear, a reference model typically consists of a set of roles, such a= s, for example, device, energy management system, power source, etc., and o= f relations, such as a power source relationship, a monitoring relationship= , a control relationship, etc. I cannot find these defined as components of= the model.

16. Section 3.3 "Concerns Differing from Network Management"
This section rather looks like a power point slide that can hardly be under= stood without a person presenting it. The bullets in this section are too s= hort for the reader to easily understand what issue is addressed at all and= what the consequences are. Some of the bullets do not make any sense to me= . At least 6 out of 7 seem to be broken:
=A0 - bullet #1: This does not seem to be different from network management=
=A0 - bullet #2: =A0I don't understand the last line: "controlling= a simple light by controlling its outlet". How does this work?
=A0 - bullet #3: What special coordination do devices need if there is more= than one PDU in a power distribution network?
=A0 - bullet #4: What means "require a separate interface model from N= etwork Management"?
=A0 - bullet #5: Seems to be broken. I don't get the message. Is there = a typo in the last line?
=A0 - bullet #7: I am not sure what is really a difference to network manag= ement where we have the entity MIB and different models for managing device= s (e.g. routers) and components (e.g. line cards). The third paragraph of S= ection 4.1 claims that this is very similar to network management.

17. =A0Section 3.4 "Concerns Not Addressed", 1st paragraph, line = 4: "normalized to the electrical units for power and energy". Thi= s is nonsense. There is indeed an "electrical" units for power (V= oltamperes,VA), but we are using rather "non-electrical ones, such as = Watts (Joule per second) and Watt-hours.
OLD
=A0 =A0 =A0 =A0 Non-Electrical Equipment

=A0 =A0 =A0 =A0 The primary focus of this framework is the management of =A0 =A0 =A0 =A0 Electrical Equipment. =A0Some Non-Electrical Equipment may = be
=A0 =A0 =A0 =A0 connected to communication networks and could have their =A0 =A0 =A0 =A0 energy managed if normalized to the electrical units for =A0 =A0 =A0 =A0 power and energy. Non-
=A0 =A0 =A0 =A0 Electrical equipment that do not convert-to or present-as =A0 =A0 =A0 =A0 equivalent to Electrical Equipment is not addressed.
NEW
=A0 =A0 =A0 =A0 Non-Electrical Equipment

=A0 =A0 =A0 =A0 The primary focus of this framework is the management of =A0 =A0 =A0 =A0 Electrical Equipment. =A0Non-Electrical Equipment can be co= vered
=A0 =A0 =A0 =A0 by the framework only if it provides interfaces that comply= with
=A0 =A0 =A0 =A0 the framework. For example, it must use the same units for = power
=A0 =A0 =A0 =A0 and energy.

18. Section 4 "Energy Management Abstraction"
The first paragraph is identical with the first paragraph of Section 1 &quo= t;Introduction" and can be removed.

19. Section 4.1 "Conceptual Model"
I am missing here a lot of information on the model.
19.1. Is the model normative or informational?
19.2. Is it a model to be implemented inside the EnMS only or as well on th= e Energy Objects?
19.3. If it is implemented at the Energy Objects, why storing context infor= mation? This typically resides in the management system only.
19.4. If it is implemented on Energy Objects, how does it specify which inf= ormation is included for a device, and which (more limited) information is = included for a component or power interface?
19.5. The model is lacking information on batteries.

20. Section 4.1, 3rd paragraph, line 1: "Therefore"-->"&q= uot;

21. Section 4.1, 4th paragraph, line 2: "a Device, a Component, and a = Power Interface"
-->"a Device class, a Component class, and a Power Interface class&= quot;

22. Section 4.1, 5th paragraph, line 2
OLD
=A0 =A0 =A0 =A0 For modeling additional attributes, this section describes<= br> =A0 =A0 =A0 =A0 attributes of an Energy Object for: identification,
=A0 =A0 =A0 =A0 classification, context, control, power and energy.
NEW
=A0 =A0 =A0 =A0 This section describes attributes of an Energy Object for i= dentification,
=A0 =A0 =A0 =A0 classification, context, control, power and energy.

23. Section 4.1, 6th paragraph.
The first sentence seems to be broken. The "interconnections for Netwo= rk Management" are also used for Energy Management. Energy management = needs at least some of them to communicate between the EnMS and devices.
24. Section 4.1, title
This section is titled "Conceptual Model". But as the last paragr= aph of it states, the conceptual model is actually not in this section, but= in the following sections 4.2-4.6. The title should be changed after fixin= g 20.-23.

25. Section 4.2, title
"Energy Object" --> "Energy Object Class"

26. Section 4.2.1, 2nd paragraph, line 2: "may represent" --> = "represents"

27. Section 4.2.1, 2nd paragraph:
Is this list exclusive? Are there no other kinds of devices supported?

28. Section 4.2.1, 2nd paragraph:
A device may be both, a meter and a distributor. How is this modeled?

29. Section 4.2.1, 3rd paragraph:
OLD
=A0 =A0 =A0 =A0 A Device Class instance may represent a physical device
=A0 =A0 =A0 =A0 that contains other components.
NEW
=A0 =A0 =A0 =A0 A Device Class instance may represent a physical device
=A0 =A0 =A0 =A0 that contains other components.

30. Section 4.3.1, 2nd sentence: "Ideally, the UUID is used to disting= uish the Energy Object within the EnMS". Why ideally? What can be idea= l for us info model designer does not necessarily have to be ideal for the = EnMS developer.

31. Section 4.3.2. "Context in General"
What I am missing in this section

32. Section 4.3.2, last paragraph:
I do not see the point made by this paragraph. How would context informatio= n help the EnMS in this case?

33. Section 4.4, "Measurements", 2nd paragraph:
This is similar to item 17. There is no electrical or non-electrical Watt-h= our.
OLD
=A0 =A0 =A0 =A0 For the purposes of this framework, energy will be limited<= br> =A0 =A0 =A0 =A0 to electrical energy in watt-hours. =A0Other forms of Energ= y
=A0 =A0 =A0 =A0 Objects that use or produce non-electrical energy may be =A0 =A0 =A0 =A0 modeled as an Energy Object but must provide information =A0 =A0 =A0 =A0 converted to and expressed in watt-hours.
NEW
=A0 =A0 =A0 =A0 Within this framework, energy will only be quantified in un= its of
=A0 =A0 =A0 =A0 in watt-hours. Energy Objects and Meters measuring Energy i= n
=A0 =A0 =A0 =A0 other units must convert values to Watt-hours before report= ing them.

34. Section 4.4.1 "Measurements: Power", line 1:
"Each Energy Object contains a Nameplate Power attribute that describe= s the nominal power as specified by the manufacturer." I am not sure, = you will always find someone reading all the nameplate power values and ent= ering them to the device or the EnMS.
OLD
=A0 =A0 =A0 =A0 Each Energy Object contains a Nameplate Power attribute
NEW
=A0 =A0 =A0 =A0 Each Energy Object may contain a Nameplate Power attribute<= br>
35. Section 4.4.1 "Measurements: Power", 2nd paragraph, line 1: OLD
=A0 =A0 =A0 =A0 Each Energy Object will have information that describes the=
NEW
=A0 =A0 =A0 =A0 Each Energy Object may have information that describes the<= br> OR NEW
=A0 =A0 =A0 =A0 Each Energy Object has information that describes the

35. Section 4.4.4, last sentence: "Demand measurements can be provided= when the Energy Object is capable of measuring actual power."
This is wrong. Either delete this sentence (preferred) or use this one inst= ead: "Demand measurements can only be provided when the Energy Object = is capable of measuring demand."

36. Section 4.5 "Control", first sentence: An Energy Object can b= e controlled by setting a Power State or a battery state.

37. Section 4.5 "Control"
Power States and Power State sets are introduced in Section "Control&q= uot;. That's wrong. Many devices will allow monitoring of power states = only, particularly devices, that control power states by themselves or by m= anual users interaction only. The concept of power states should be explain= ed outside of section 4, either in a subsection of section 3 or in a new se= parate section between current sections 3 and 4.

38. section 4.5.1 "Power State Sets"
Why is the ACPI power state set excluded from the list of existing sets? ACPI power states should have their own subsection as IEEE1621 and DMTF hav= e.

39. Section 4.5.4. "Power State Set: IETF EMAN"
Shouldn't we call this rather "Power State Set: Cisco EnergyWise&q= uot;?

40. Section 4.5.4, first sentence:
"An EMAN Power State Set represents an attempt at a standard approach = for modeling the different levels of power of a device." The same hold= s for every other power state set, particularly for the ones mentioned in t= he subsections above. I suggest removing this sentence.

41. Section 4.5.4.
I am fine with the non-operational power states that also other ACPI and DM= TF support similarly, but I have problems with the operational states (7-12= ). They are defined only relatively to each other stating that one with a l= ower number "provides less usage" than a higher number.
41.1: Is "providing usage" proper terminology?
41.2: What is meant with "provide less usage"? Does it mean that = usage numbers are ALWAYS lower than in a higher state? Even if measured in = short time intervals? Such a behavior would hardly be implementable on many= devices.
41.3: In the real world, power states have ranges of power values that they= cover and some have wider ranges than others. This can hardly be modeled b= y a power state set that only knows a strict consecutive order of power sta= tes and power values.

42. Section 4.6, 2nd paragraph, first sentence: "Relationships are mod= eled with a Relationship class that contains the UUID of the participants i= n the relationship ...":
"of =A0the participants" --> "of the other participant&qu= ot;

43. Section 5 "Energy Management Information Model"
The text states that this model is a "reference for implementers"= . Obviously, the model is useful for management system implementers. What i= s not discussed is how to use it for implementations of EMAN on devices, co= mponents and interfaces. The model does not give guidance for these. Among = the missing information for these cases is what needs to be implemented on = different classes of devices.

Cheers,
=A0 =A0 Juergen

> -----Original Message-----
> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of
> Nevil Brownlee
> Sent: Dienstag, 10. September 2013 23:28
> To: eman@ietf.org
> Cc: ops-ads@tools.ietf.org
> Subject: [eman] WG Last Call for EMAN Framework -09
>
>
> Hi all:
>
> A new revision of the EMAN Framework draft was published yesterday. > Version -09 has many changes, improvements and clarifications since th= e -08
> version (published just before IETF-87 in Berlin).
>
> The WG Last Call for it starts now, and will end on Friday, 27 Septemb= er.
>
> Please read it now, and send your comments/suggestions/etc to the EMAN= list.
> Comments like "seems fine now" are good, as are suggestions = for further
> improvement (accompanied by OLD/NEW text).
>
> Cheers, Nevil
>
> --
> ---------------------------------------------------------------------<= br> > =A0 Nevil Brownlee =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= Computer Science Department
> =A0 Phone: +64 9 373 7599 x88941 =A0 =A0 =A0 =A0 =A0 =A0 The University= of Auckland
> =A0 FAX: = +64 9 373 7453 =A0 Private Bag 92019, Auckland 1142, New Zealand
> ________________________= _______________________
> eman mailing list
> eman@ietf.org
> https://www.ietf.org/mailman/listinfo/eman
_______________________________________________
eman mailing list
eman@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/eman



--
Bruce Nordman
La= wrence Berkeley National Laboratory
nordman.lbl.g= ov
BNordman@LBL.gov
510-486-7089
m: 510-501-7943
--047d7bdc1564cc55ec04e7c9602a-- From bnordman@lbl.gov Wed Oct 2 15:15:41 2013 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 A619221F9A43 for ; Wed, 2 Oct 2013 15:15:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.089 X-Spam-Level: X-Spam-Status: No, score=-5.089 tagged_above=-999 required=5 tests=[AWL=0.887, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pKr-LHgqtC2M for ; Wed, 2 Oct 2013 15:15:31 -0700 (PDT) Received: from fe1.lbl.gov (fe1.lbl.gov [128.3.41.133]) by ietfa.amsl.com (Postfix) with ESMTP id 81B7821F9A61 for ; Wed, 2 Oct 2013 15:14:22 -0700 (PDT) X-Ironport-SBRS: 5.6 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqwDAIeZTFLRVYAvnGdsb2JhbABWA4JDfFKvEgGJY4lWCBYOAQEBAQEGDQkJFCiDRAddEgEFASITCYd9DJxFgwOeM44IEIFRhBIDiTmOSIEvjmUYKYRuHIE1 X-IronPort-AV: E=Sophos;i="4.90,1021,1371106800"; d="scan'208";a="29628862" Received: from mail-qe0-f47.google.com ([209.85.128.47]) by fe1.lbl.gov with ESMTP; 02 Oct 2013 15:14:21 -0700 Received: by mail-qe0-f47.google.com with SMTP id b4so1107343qen.6 for ; Wed, 02 Oct 2013 15:14:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=HBoO5HmKy9mMvcImf9riZOXKcGa6FEF4HaegB4cCako=; b=b11fjBqLuwS94mplYIhVhpFFbW4P975QccW2IIjenziWzxoQK5Yp4d6QCoJprbNxfg nY7kjeeqbBLRhICfQ4NnMboJYgLD35h/Ssp4ielaYfKypwQFUtJoEyZBBEBiFrT9FxQu 0ptTvZGX94hyUIESgTD6WBju3bA4eruDATSKJd48b7ER+eTMNHQpxVVGNYYua+hEp8Us mf+q/JCFt1rY/b8CQ0gYMXRcN0irRAABTKH3Q5NhPTDMUQNASVtYGBU+/pMRDrjsLMyR J8GKGI6/SAQzrAwfRuEl7R8SFtqeRcffSZNxCzSI0um/wSn+9JCRDLLNvccr/CYY79uX z5bw== X-Gm-Message-State: ALoCoQkAWZGgON0LVUllFJp1LDnUlff2rFPQ1/4z7rjLduwMrxY1pKOHavcKZWfDwJhUrafijHuuKzQqPmxU4LcYA87GVs3pkHEXCNp78/KMw70kH8LL0Q9ui6ssu+PbIGSWbBik2dAv X-Received: by 10.224.24.201 with SMTP id w9mr4861677qab.103.1380752061242; Wed, 02 Oct 2013 15:14:21 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.224.24.201 with SMTP id w9mr4861667qab.103.1380752061154; Wed, 02 Oct 2013 15:14:21 -0700 (PDT) Received: by 10.140.80.212 with HTTP; Wed, 2 Oct 2013 15:14:21 -0700 (PDT) Date: Wed, 2 Oct 2013 15:14:21 -0700 Message-ID: From: Bruce Nordman To: eman mailing list Content-Type: multipart/alternative; boundary=001a11c2a26020d76604e7c9645f Subject: [eman] Way forward for EMAN Framework 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, 02 Oct 2013 22:15:41 -0000 --001a11c2a26020d76604e7c9645f Content-Type: text/plain; charset=ISO-8859-1 As my previous email noted, and as per Juergen Quittek's recent review http://www.ietf.org/mail-archive/web/eman/current/msg02007.html there are still many many outstanding problems with the current Framework draft. This draft has been out for consideration and evolving for over three years, so having so many outstanding problems is troubling. The the pace of improvement over these years has been quite slow. It seems unlikely that continuing on the process of trying to fix this document will lead to it being suitable as an RFC in a reasonable timeframe. It would be better to produce no result than to produce a substandard one. That said, there are alternatives. One good one is to use the "Energy Reporting (ER) Framework" -- draft-nordman-eman-er-framework-01 -- as the basis for the framework work item from EMAN. A key next step is for that draft to receive critical review by EMAN participants to directly compare it to the current EMAN Framework draft. This would productively move EMAN forward. My assessment of the two is that the ER Framework: * Is simpler to read and understand - for a variety of audiences * Will be simpler to implement (for end devices and management systems) * Lacks many ambiguities present in the EMAN Framework * More fully and directly implements the EMAN Requirements * Has features and capabilities not in the EMAN Framework These all make it more suitable as an RFC and more likely to be successful as a standard. EMAN is not the only organization considering energy management data models and so to be successful will need to be clearly superior to alternatives. I look forward to more detailed and productive discussion on the list. Thank you, --Bruce -- *Bruce Nordman* Lawrence Berkeley National Laboratory *nordman.lbl.gov* BNordman@LBL.gov 510-486-7089 m: 510-501-7943 --001a11c2a26020d76604e7c9645f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
As my previous email noted, and as per Juergen Quittek'= ;s recent review
=A0 http://www.ietf.org/mail-archive/web/eman/current= /msg02007.html
there are still many many outstanding problems with the
current Framewo= rk draft.=A0 This draft has been out for consideration
and evolving for = over three years, so having so many outstanding
problems is troubling.= =A0 The the pace of improvement over these
years has been quite slow.=A0 It seems unlikely that continuing on
the = process of trying to fix this document will lead to it being
suitable as= an RFC in a reasonable timeframe.=A0 It would be better
to produce no r= esult than to produce a substandard one.=A0

That said, there are alternatives.=A0 One good one is to use the
&qu= ot;Energy Reporting (ER) Framework" -- draft-nordman-eman-er-framework= -01
-- as the basis for the framework work item from EMAN.=A0 A key next=
step is for that draft to receive critical review by EMAN participants
t= o directly compare it to the current EMAN Framework draft.=A0 This
would= productively move EMAN forward.

My assessment of the two is that th= e ER Framework:
* Is simpler to read and understand - for a variety of audiences
* Will = be simpler to implement (for end devices and management systems)
* Lacks= many ambiguities present in the EMAN Framework
* More fully and directl= y implements the EMAN Requirements
* Has features and capabilities not in the EMAN Framework
These all make= it more suitable as an RFC and more likely to be
successful as a standa= rd.

EMAN is not the only organization considering energy management<= br> data models and so to be successful will need to be clearly superior
to = alternatives.

I look forward to more detailed and productive discuss= ion on the list.
Thank you,

--Bruce


-- <= br> Bruce Nordman
Lawrence Berkeley National Laboratory
nor= dman.lbl.gov
BNordman@LBL.gov
510-486-7089
m: 510-501-7943
--001a11c2a26020d76604e7c9645f-- From tghose@juniper.net Wed Oct 2 17:20:24 2013 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 2834C21F8E3D for ; Wed, 2 Oct 2013 17:20:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.534 X-Spam-Level: X-Spam-Status: No, score=0.534 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OnIntcLsC4YG for ; Wed, 2 Oct 2013 17:20:11 -0700 (PDT) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0189.outbound.messaging.microsoft.com [213.199.154.189]) by ietfa.amsl.com (Postfix) with ESMTP id 97BD921F9FAC for ; Wed, 2 Oct 2013 17:19:56 -0700 (PDT) Received: from mail148-db8-R.bigfish.com (10.174.8.235) by DB8EHSOBE024.bigfish.com (10.174.4.87) with Microsoft SMTP Server id 14.1.225.22; Thu, 3 Oct 2013 00:19:55 +0000 Received: from mail148-db8 (localhost [127.0.0.1]) by mail148-db8-R.bigfish.com (Postfix) with ESMTP id 41002A0348 for ; Thu, 3 Oct 2013 00:19:55 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -18 X-BigFish: VPS-18(zz98dI9371Ic857h1415Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL17326ah18c673h1de097h186068h1954cbh8275bh8275dhz2fh2a8h839hbe3hd25he5bhf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h2052h20f0h20b3m1155h) Received-SPF: pass (mail148-db8: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=tghose@juniper.net; helo=BL2PRD0510HT002.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(189002)(199002)(51414003)(24454002)(377454003)(36756003)(51856001)(49866001)(16236675002)(4396001)(83072001)(46102001)(53806001)(59766001)(77982001)(74366001)(47976001)(50986001)(47736001)(66066001)(81816001)(85306001)(81342001)(81542001)(80022001)(56776001)(74876001)(82746002)(74662001)(77096001)(54356001)(54316002)(31966008)(33656001)(74706001)(80976001)(76482001)(79102001)(69226001)(65816001)(81686001)(63696002)(16601075003)(15202345003)(15975445006)(74502001)(76796001)(83322001)(56816003)(76786001)(47446002)(19580395003)(19580405001)(83716002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR05MB194; H:BL2PR05MB195.namprd05.prod.outlook.com; CLIP:66.129.246.4; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail148-db8 (localhost.localdomain [127.0.0.1]) by mail148-db8 (MessageSwitch) id 138075951966580_24495; Thu, 3 Oct 2013 00:18:39 +0000 (UTC) Received: from DB8EHSMHS003.bigfish.com (unknown [10.174.8.247]) by mail148-db8.bigfish.com (Postfix) with ESMTP id 14B5DC0343; Thu, 3 Oct 2013 00:18:36 +0000 (UTC) Received: from BL2PRD0510HT002.namprd05.prod.outlook.com (157.56.240.101) by DB8EHSMHS003.bigfish.com (10.174.4.13) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 3 Oct 2013 00:18:33 +0000 Received: from BL2PR05MB194.namprd05.prod.outlook.com (10.242.198.147) by BL2PRD0510HT002.namprd05.prod.outlook.com (10.255.100.37) with Microsoft SMTP Server (TLS) id 14.16.359.1; Thu, 3 Oct 2013 00:18:31 +0000 Received: from BL2PR05MB195.namprd05.prod.outlook.com (10.242.198.149) by BL2PR05MB194.namprd05.prod.outlook.com (10.242.198.147) with Microsoft SMTP Server (TLS) id 15.0.775.9; Thu, 3 Oct 2013 00:18:29 +0000 Received: from BL2PR05MB195.namprd05.prod.outlook.com ([169.254.6.159]) by BL2PR05MB195.namprd05.prod.outlook.com ([169.254.6.159]) with mapi id 15.00.0775.005; Thu, 3 Oct 2013 00:18:29 +0000 From: Ted Ghose To: Bruce Nordman Thread-Topic: [eman] Way forward for EMAN Framework Thread-Index: AQHOv84VychinvmPnkevdxKxHYe+xw== Date: Thu, 3 Oct 2013 00:18:29 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.246.4] x-forefront-prvs: 09888BC01D Content-Type: multipart/alternative; boundary="_000_C6C6EB3302754AD7B5BCC4F2E871FBE9junipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%0$Dn%LBL.GOV$RO%1$TLS%0$FQDN%$TlsDn% Cc: eman mailing list Subject: Re: [eman] Way forward for EMAN Framework 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, 03 Oct 2013 00:20:24 -0000 --_000_C6C6EB3302754AD7B5BCC4F2E871FBE9junipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2h5IG5vdCBmaXggdGhlIGV4aXN0aW5nIG9uZSByYXRoZXIgc3RhcnRpbmcgYSBkaXNjdXNzaW9u IG9uIGEgbmV3IGRyYWZ0PyBTb21ldGhpbmcgSSBtaXNzZWQ/DQoNClRoYW5rcw0KDQotdGctDQpT ZW50IGZyb20gbXkgaVBob25lDQoNCk9uIE9jdCAyLCAyMDEzLCBhdCAzOjE1IFBNLCBCcnVjZSBO b3JkbWFuIDxibm9yZG1hbkBsYmwuZ292PG1haWx0bzpibm9yZG1hbkBsYmwuZ292Pj4gd3JvdGU6 DQoNCkFzIG15IHByZXZpb3VzIGVtYWlsIG5vdGVkLCBhbmQgYXMgcGVyIEp1ZXJnZW4gUXVpdHRl aydzIHJlY2VudCByZXZpZXcNCiAgaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2Vi L2VtYW4vY3VycmVudC9tc2cwMjAwNy5odG1sDQp0aGVyZSBhcmUgc3RpbGwgbWFueSBtYW55IG91 dHN0YW5kaW5nIHByb2JsZW1zIHdpdGggdGhlDQpjdXJyZW50IEZyYW1ld29yayBkcmFmdC4gIFRo aXMgZHJhZnQgaGFzIGJlZW4gb3V0IGZvciBjb25zaWRlcmF0aW9uDQphbmQgZXZvbHZpbmcgZm9y IG92ZXIgdGhyZWUgeWVhcnMsIHNvIGhhdmluZyBzbyBtYW55IG91dHN0YW5kaW5nDQpwcm9ibGVt cyBpcyB0cm91YmxpbmcuICBUaGUgdGhlIHBhY2Ugb2YgaW1wcm92ZW1lbnQgb3ZlciB0aGVzZQ0K eWVhcnMgaGFzIGJlZW4gcXVpdGUgc2xvdy4gIEl0IHNlZW1zIHVubGlrZWx5IHRoYXQgY29udGlu dWluZyBvbg0KdGhlIHByb2Nlc3Mgb2YgdHJ5aW5nIHRvIGZpeCB0aGlzIGRvY3VtZW50IHdpbGwg bGVhZCB0byBpdCBiZWluZw0Kc3VpdGFibGUgYXMgYW4gUkZDIGluIGEgcmVhc29uYWJsZSB0aW1l ZnJhbWUuICBJdCB3b3VsZCBiZSBiZXR0ZXINCnRvIHByb2R1Y2Ugbm8gcmVzdWx0IHRoYW4gdG8g cHJvZHVjZSBhIHN1YnN0YW5kYXJkIG9uZS4NCg0KVGhhdCBzYWlkLCB0aGVyZSBhcmUgYWx0ZXJu YXRpdmVzLiAgT25lIGdvb2Qgb25lIGlzIHRvIHVzZSB0aGUNCiJFbmVyZ3kgUmVwb3J0aW5nIChF UikgRnJhbWV3b3JrIiAtLSBkcmFmdC1ub3JkbWFuLWVtYW4tZXItZnJhbWV3b3JrLTAxDQotLSBh cyB0aGUgYmFzaXMgZm9yIHRoZSBmcmFtZXdvcmsgd29yayBpdGVtIGZyb20gRU1BTi4gIEEga2V5 IG5leHQNCnN0ZXAgaXMgZm9yIHRoYXQgZHJhZnQgdG8gcmVjZWl2ZSBjcml0aWNhbCByZXZpZXcg YnkgRU1BTiBwYXJ0aWNpcGFudHMNCnRvIGRpcmVjdGx5IGNvbXBhcmUgaXQgdG8gdGhlIGN1cnJl bnQgRU1BTiBGcmFtZXdvcmsgZHJhZnQuICBUaGlzDQp3b3VsZCBwcm9kdWN0aXZlbHkgbW92ZSBF TUFOIGZvcndhcmQuDQoNCk15IGFzc2Vzc21lbnQgb2YgdGhlIHR3byBpcyB0aGF0IHRoZSBFUiBG cmFtZXdvcms6DQoqIElzIHNpbXBsZXIgdG8gcmVhZCBhbmQgdW5kZXJzdGFuZCAtIGZvciBhIHZh cmlldHkgb2YgYXVkaWVuY2VzDQoqIFdpbGwgYmUgc2ltcGxlciB0byBpbXBsZW1lbnQgKGZvciBl bmQgZGV2aWNlcyBhbmQgbWFuYWdlbWVudCBzeXN0ZW1zKQ0KKiBMYWNrcyBtYW55IGFtYmlndWl0 aWVzIHByZXNlbnQgaW4gdGhlIEVNQU4gRnJhbWV3b3JrDQoqIE1vcmUgZnVsbHkgYW5kIGRpcmVj dGx5IGltcGxlbWVudHMgdGhlIEVNQU4gUmVxdWlyZW1lbnRzDQoqIEhhcyBmZWF0dXJlcyBhbmQg Y2FwYWJpbGl0aWVzIG5vdCBpbiB0aGUgRU1BTiBGcmFtZXdvcmsNClRoZXNlIGFsbCBtYWtlIGl0 IG1vcmUgc3VpdGFibGUgYXMgYW4gUkZDIGFuZCBtb3JlIGxpa2VseSB0byBiZQ0Kc3VjY2Vzc2Z1 bCBhcyBhIHN0YW5kYXJkLg0KDQpFTUFOIGlzIG5vdCB0aGUgb25seSBvcmdhbml6YXRpb24gY29u c2lkZXJpbmcgZW5lcmd5IG1hbmFnZW1lbnQNCmRhdGEgbW9kZWxzIGFuZCBzbyB0byBiZSBzdWNj ZXNzZnVsIHdpbGwgbmVlZCB0byBiZSBjbGVhcmx5IHN1cGVyaW9yDQp0byBhbHRlcm5hdGl2ZXMu DQoNCkkgbG9vayBmb3J3YXJkIHRvIG1vcmUgZGV0YWlsZWQgYW5kIHByb2R1Y3RpdmUgZGlzY3Vz c2lvbiBvbiB0aGUgbGlzdC4NClRoYW5rIHlvdSwNCg0KLS1CcnVjZQ0KDQoNCi0tDQpCcnVjZSBO b3JkbWFuDQpMYXdyZW5jZSBCZXJrZWxleSBOYXRpb25hbCBMYWJvcmF0b3J5DQpub3JkbWFuLmxi bC5nb3Y8aHR0cDovL25vcmRtYW4ubGJsLmdvdj4NCkJOb3JkbWFuQExCTC5nb3Y8bWFpbHRvOkJO b3JkbWFuQExCTC5nb3Y+DQo1MTAtNDg2LTcwODkNCm06IDUxMC01MDEtNzk0Mw0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmVtYW4gbWFpbGluZyBsaXN0 DQplbWFuQGlldGYub3JnPG1haWx0bzplbWFuQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9lbWFuDQo= --_000_C6C6EB3302754AD7B5BCC4F2E871FBE9junipernet_ Content-Type: text/html; charset="utf-8" Content-ID: <82684826F8D67B49920DE0A418DD28DE@junipernetworks.onmicrosoft.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQo8 ZGl2PldoeSBub3QgZml4IHRoZSBleGlzdGluZyBvbmUgcmF0aGVyIHN0YXJ0aW5nIGEgZGlzY3Vz c2lvbiBvbiBhIG5ldyBkcmFmdD8gU29tZXRoaW5nIEkgbWlzc2VkPzwvZGl2Pg0KPGRpdj48YnI+ DQo8L2Rpdj4NCjxkaXY+VGhhbmtzPGJyPg0KPGJyPg0KLXRnLQ0KPGRpdj5TZW50IGZyb20gbXkg aVBob25lPC9kaXY+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KT24gT2N0IDIsIDIwMTMsIGF0IDM6MTUg UE0sIEJydWNlIE5vcmRtYW4gJmx0OzxhIGhyZWY9Im1haWx0bzpibm9yZG1hbkBsYmwuZ292Ij5i bm9yZG1hbkBsYmwuZ292PC9hPiZndDsgd3JvdGU6PGJyPg0KPGJyPg0KPC9kaXY+DQo8YmxvY2tx dW90ZSB0eXBlPSJjaXRlIj4NCjxkaXY+DQo8ZGl2IGRpcj0ibHRyIj5BcyBteSBwcmV2aW91cyBl bWFpbCBub3RlZCwgYW5kIGFzIHBlciBKdWVyZ2VuIFF1aXR0ZWsncyByZWNlbnQgcmV2aWV3DQo8 YnI+DQombmJzcDsgPGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2Vi L2VtYW4vY3VycmVudC9tc2cwMjAwNy5odG1sIj5odHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJj aGl2ZS93ZWIvZW1hbi9jdXJyZW50L21zZzAyMDA3Lmh0bWw8L2E+PGJyPg0KdGhlcmUgYXJlIHN0 aWxsIG1hbnkgbWFueSBvdXRzdGFuZGluZyBwcm9ibGVtcyB3aXRoIHRoZSA8YnI+DQpjdXJyZW50 IEZyYW1ld29yayBkcmFmdC4mbmJzcDsgVGhpcyBkcmFmdCBoYXMgYmVlbiBvdXQgZm9yIGNvbnNp ZGVyYXRpb248YnI+DQphbmQgZXZvbHZpbmcgZm9yIG92ZXIgdGhyZWUgeWVhcnMsIHNvIGhhdmlu ZyBzbyBtYW55IG91dHN0YW5kaW5nPGJyPg0KcHJvYmxlbXMgaXMgdHJvdWJsaW5nLiZuYnNwOyBU aGUgdGhlIHBhY2Ugb2YgaW1wcm92ZW1lbnQgb3ZlciB0aGVzZTxicj4NCnllYXJzIGhhcyBiZWVu IHF1aXRlIHNsb3cuJm5ic3A7IEl0IHNlZW1zIHVubGlrZWx5IHRoYXQgY29udGludWluZyBvbiA8 YnI+DQp0aGUgcHJvY2VzcyBvZiB0cnlpbmcgdG8gZml4IHRoaXMgZG9jdW1lbnQgd2lsbCBsZWFk IHRvIGl0IGJlaW5nPGJyPg0Kc3VpdGFibGUgYXMgYW4gUkZDIGluIGEgcmVhc29uYWJsZSB0aW1l ZnJhbWUuJm5ic3A7IEl0IHdvdWxkIGJlIGJldHRlcjxicj4NCnRvIHByb2R1Y2Ugbm8gcmVzdWx0 IHRoYW4gdG8gcHJvZHVjZSBhIHN1YnN0YW5kYXJkIG9uZS4mbmJzcDsgPGJyPg0KPGJyPg0KVGhh dCBzYWlkLCB0aGVyZSBhcmUgYWx0ZXJuYXRpdmVzLiZuYnNwOyBPbmUgZ29vZCBvbmUgaXMgdG8g dXNlIHRoZTxicj4NCiZxdW90O0VuZXJneSBSZXBvcnRpbmcgKEVSKSBGcmFtZXdvcmsmcXVvdDsg LS0gZHJhZnQtbm9yZG1hbi1lbWFuLWVyLWZyYW1ld29yay0wMTxicj4NCi0tIGFzIHRoZSBiYXNp cyBmb3IgdGhlIGZyYW1ld29yayB3b3JrIGl0ZW0gZnJvbSBFTUFOLiZuYnNwOyBBIGtleSBuZXh0 PGJyPg0Kc3RlcCBpcyBmb3IgdGhhdCBkcmFmdCB0byByZWNlaXZlIGNyaXRpY2FsIHJldmlldyBi eSBFTUFOIHBhcnRpY2lwYW50czxicj4NCnRvIGRpcmVjdGx5IGNvbXBhcmUgaXQgdG8gdGhlIGN1 cnJlbnQgRU1BTiBGcmFtZXdvcmsgZHJhZnQuJm5ic3A7IFRoaXM8YnI+DQp3b3VsZCBwcm9kdWN0 aXZlbHkgbW92ZSBFTUFOIGZvcndhcmQuPGJyPg0KPGJyPg0KTXkgYXNzZXNzbWVudCBvZiB0aGUg dHdvIGlzIHRoYXQgdGhlIEVSIEZyYW1ld29yazo8YnI+DQoqIElzIHNpbXBsZXIgdG8gcmVhZCBh bmQgdW5kZXJzdGFuZCAtIGZvciBhIHZhcmlldHkgb2YgYXVkaWVuY2VzPGJyPg0KKiBXaWxsIGJl IHNpbXBsZXIgdG8gaW1wbGVtZW50IChmb3IgZW5kIGRldmljZXMgYW5kIG1hbmFnZW1lbnQgc3lz dGVtcyk8YnI+DQoqIExhY2tzIG1hbnkgYW1iaWd1aXRpZXMgcHJlc2VudCBpbiB0aGUgRU1BTiBG cmFtZXdvcms8YnI+DQoqIE1vcmUgZnVsbHkgYW5kIGRpcmVjdGx5IGltcGxlbWVudHMgdGhlIEVN QU4gUmVxdWlyZW1lbnRzPGJyPg0KKiBIYXMgZmVhdHVyZXMgYW5kIGNhcGFiaWxpdGllcyBub3Qg aW4gdGhlIEVNQU4gRnJhbWV3b3JrPGJyPg0KVGhlc2UgYWxsIG1ha2UgaXQgbW9yZSBzdWl0YWJs ZSBhcyBhbiBSRkMgYW5kIG1vcmUgbGlrZWx5IHRvIGJlPGJyPg0Kc3VjY2Vzc2Z1bCBhcyBhIHN0 YW5kYXJkLjxicj4NCjxicj4NCkVNQU4gaXMgbm90IHRoZSBvbmx5IG9yZ2FuaXphdGlvbiBjb25z aWRlcmluZyBlbmVyZ3kgbWFuYWdlbWVudDxicj4NCmRhdGEgbW9kZWxzIGFuZCBzbyB0byBiZSBz dWNjZXNzZnVsIHdpbGwgbmVlZCB0byBiZSBjbGVhcmx5IHN1cGVyaW9yPGJyPg0KdG8gYWx0ZXJu YXRpdmVzLjxicj4NCjxicj4NCkkgbG9vayBmb3J3YXJkIHRvIG1vcmUgZGV0YWlsZWQgYW5kIHBy b2R1Y3RpdmUgZGlzY3Vzc2lvbiBvbiB0aGUgbGlzdC48YnI+DQpUaGFuayB5b3UsPGJyPg0KPGJy Pg0KLS1CcnVjZTxicj4NCjxiciBjbGVhcj0iYWxsIj4NCjxicj4NCi0tIDxicj4NCjxmb250IHNp emU9IjQiPjxiPkJydWNlIE5vcmRtYW48L2I+PC9mb250Pjxicj4NCjxzcGFuIHN0eWxlPSJjb2xv cjpyZ2IoMCwwLDE1MykiPkxhd3JlbmNlIEJlcmtlbGV5IE5hdGlvbmFsIExhYm9yYXRvcnk8L3Nw YW4+PGJyPg0KPGI+PHNwYW4gc3R5bGU9ImNvbG9yOnJnYigwLDEwMiwwKSI+PGEgaHJlZj0iaHR0 cDovL25vcmRtYW4ubGJsLmdvdiIgdGFyZ2V0PSJfYmxhbmsiPm5vcmRtYW4ubGJsLmdvdjwvYT48 L3NwYW4+PC9iPjxicj4NCjxhIGhyZWY9Im1haWx0bzpCTm9yZG1hbkBMQkwuZ292Ij5CTm9yZG1h bkBMQkwuZ292PC9hPjxicj4NCjUxMC00ODYtNzA4OTxicj4NCm06IDUxMC01MDEtNzk0Mzxicj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4N CjxkaXY+PHNwYW4+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188L3NwYW4+PGJyPg0KPHNwYW4+ZW1hbiBtYWlsaW5nIGxpc3Q8L3NwYW4+PGJyPg0KPHNwYW4+ PGEgaHJlZj0ibWFpbHRvOmVtYW5AaWV0Zi5vcmciPmVtYW5AaWV0Zi5vcmc8L2E+PC9zcGFuPjxi cj4NCjxzcGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v ZW1hbiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lbWFuPC9hPjwvc3Bh bj48YnI+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_C6C6EB3302754AD7B5BCC4F2E871FBE9junipernet_-- From bclaise@cisco.com Thu Oct 3 07:39:53 2013 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 3AD6B21F9343 for ; Thu, 3 Oct 2013 07:39:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t7D9qszLdmZb for ; Thu, 3 Oct 2013 07:39:46 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 1EAF921F9926 for ; Thu, 3 Oct 2013 07:30:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=305535; q=dns/txt; s=iport; t=1380810630; x=1382020230; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=TChJJpfE40JbrONbyvRCXuBHF8/isVw873YAwgoUC3c=; b=YHLl6uAbcZzDMrkq9B3+5Fyft2lxHTeOiaCJe+SaiL3s4sECoQCD7tdJ CSWkIsbHmbPz+lSVTL0uGQMx/8JqE2VYYSQ3TNMeD4t5seXwsUgt2Qaoz 4OJ04iMr3d+IoIlhDVJNG0JWbaWMmYfXW9lVk+TPreB8rgnY5BKqB8gQN Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEADp/TVKQ/khL/2dsb2JhbADHWw X-IronPort-AV: E=Sophos;i="4.90,872,1371081600"; d="scan'208,217";a="18026895" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-3.cisco.com with ESMTP; 03 Oct 2013 14:30:28 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r93EUInN026076 for ; Thu, 3 Oct 2013 14:30:20 GMT Message-ID: <524D7F7A.40904@cisco.com> Date: Thu, 03 Oct 2013 16:30:18 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: eman mailing list References: <52495367.2060106@cisco.com> In-Reply-To: <52495367.2060106@cisco.com> Content-Type: multipart/alternative; boundary="------------070306010905080804080002" Subject: [eman] draft-ietf-eman-framework-10: WGLC comments X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2013 14:39:53 -0000 This is a multi-part message in MIME format. --------------070306010905080804080002 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Dear all, Here is my review. Sorry for the delay. > Network Working Group J. Parello > Internet-Draft B. Claise > Intended Status: Informational Cisco Systems, Inc. > Expires: March 23, 2014 B. Schoening > Independent Consultant > J. Quittek > NEC Europe Ltd > > September 23, 2013 > > > > > > Energy Management Framework > > > > > > draft-ietf-eman-framework-10 > > > > > Status of this Memo > > This Internet-Draft is submitted in full conformance with > the provisions ofBCP 78 andBCP 79 . > > Internet-Drafts are working documents of the Internet > Engineering Task Force (IETF), its areas, and its working > groups. Note that other groups may also distribute working > documents as Internet-Drafts. > > Internet-Drafts are draft documents valid for a maximum of > six months and may be updated, replaced, or obsoleted by > other documents at any time. It is inappropriate to use > Internet-Drafts as reference material or to cite them other > than as "work in progress." > > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/ietf/1id-abstracts.txt > > The list of Internet-Draft Shadow Directories can be > accessed athttp://www.ietf.org/shadow.html > > This Internet-Draft will expire on March 23, 2014. > > > > > > > > > > > > > > Claise et al Expires March 23, 2014 [Page 1] > > > Internet-Draft EMAN Framework September 2013 > > > Copyright Notice > > Copyright (c) 2013 IETF Trust and the persons identified as > the document authors. All rights reserved. > > This document is subject toBCP 78 and the IETF Trust's > Legal Provisions Relating to IETF Documents > (http://trustee.ietf.org/license-info) in effect on the > date of publication of this document. Please review these > documents carefully, as they describe your rights and > restrictions with respect to this document. Code Components > extracted from this document must include Simplified BSD > License text as described inSection 4 .e of the Trust Legal > Provisions and are provided without warranty as described > in the Simplified BSD License. > > Abstract > > This document defines a framework for providing Energy > Management for devices and device components within or > connected to communication networks. The framework > presents a physical reference model and information model. > The information model consists of an Energy Management > Domain as a set of Energy Objects. Each Energy Object is > identified, classified and given context. Energy Objects > can be monitored and controlled with respect to Power, > Power State, Energy, Demand, Power Attributes, and Battery. > Additionally the framework models relationships and > capabilities between Energy Objects. On the top of Jürgen's feedback on the abstract, I'm wondering: What is a "physical" reference model? > > > > > > > > > > > > > > > > > > > > > > Claise et al. Expires March 23, 2014 [Page 2] > > > Internet-Draft EMAN Framework September 2013 > > > Table of Contents > > 1 . Introduction...........................................3 > 1.1 . Energy Management Documents Overview..............4 > 2 . Terminology............................................5 > 3 . Concerns Specific to Energy Management................11 > 3.1 . Target Devices...................................11 > 3.2 . Physical Reference Model.........................12 > 3.3 . Concerns Differing from Network Management.......13 > 3.4 . Concerns Not Addressed...........................14 > 4 . Energy Management Abstraction.........................14 > 4.1 . Conceptual Model.................................15 > 4.2 . Energy Object....................................15 > 4.3 . Energy Object Attributes.........................16 > 4.4 . Measurements.....................................19 > 4.5 . Control..........................................21 > 4.6 . Relationships....................................26 > 5 . Energy Management Information Model...................30 > 6 . Modeling Relationships between Devices................34 > 6.1 . Power Source Relationship........................34 > 6.2 . Metering Relationship............................37 > 6.3 . Aggregation Relationship.........................39 > 7 . Relationship to Other Standards.......................40 > 8 . Security Considerations...............................40 > 8.1 . Security Considerations for SNMP.................41 > 9 . IANA Considerations...................................42 > 9.1 . IANA Registration of new Power State Sets........42 > 9.2 . Updating the Registration of .. Power State Sets. 43 > 10 . References...........................................43 > 11 . Acknowledgments......................................47 > > > > > 1 > . > Introduction > > > > Network management is often divided into the five main > areas defined in the ISO Telecommunications Management > Network model: Fault, Configuration, Accounting, > Performance, and Security Management (FCAPS) [X.700 ]. Not > covered by this traditional management model is Energy > Management, which is rapidly becoming a critical area of > concern worldwide, as seen in [ISO50001 ]. > > This document defines an energy management framework for > devices within or connected to communication networks. The > devices, or components of these devices (such as router > line cards, fans, disks), can then be monitored and > controlled. Monitoring includes measuring power, energy, > demand, and attributes of power. Energy control can be > performed by setting a devices' or components' power state. power state -> Power State. Some more instances: be consistent in terms of capitalization in the introduction. > > > Claise et al. Expires March 23, 2014 [Page 3] > > > Internet-Draft EMAN Framework September 2013 > > If a device contains batteries, these can also be monitored > and controlled. > > This framework further describes how to identify, classify > and provide context for such devices. While the context > information is not specific to Energy Management, some > context attributes are specified in the framework, > addressing the following use cases: how important is a > device in terms of its business impact, how should devices > be grouped for reporting and searching, and how should a > device role be described. These context attributes help in > fault management and impact analysis while controlling the > power states. Guidelines for using context for energy > management are described. > > The framework introduces the concept of a power interface > that is analogous to a network interface. A power interface > is defined as an interconnection among devices where energy > can be provided, received, or both. > > The most basic example of Energy Management is a single > device reporting information about itself. In many cases, > however, energy is not measured by the device itself, but > measured upstream in the power distribution tree. For > example, a power distribution unit (PDU) may measure the > energy it supplies to attached devices and report this to > an energy management system. Therefore, devices often have > relationships to other devices or components in the power > network. An EnMS (Energy Management System) generally > requires an understanding of the power topology (who > provides power to whom), the metering topology (who meters > whom), and an understanding of the potential aggregation > (ex: does a meter aggregate values from other devices). > We need to introduce that there are different relationship types, to solve the different problems. > The relationships build on the power interface concept. The > different relationships among devices and components, > specified in this document, include: power source > relationship, metering relationship, and aggregation > relationship. > > > > > 1.1 > . > Energy Management Documents Overview > > > > The EMAN standard provides a set of specifications for > Energy Management. This document specifies the framework, > per the Energy Management requirements specified in [EMAN- > REQ]. > > The applicability statement document [EMAN-AS ] includes use > cases, a cross-reference between existing standards and the > > > Claise et al. Expires March 23, 2014 [Page 4] > > > Internet-Draft EMAN Framework September 2013 > > EMAN standard, and a description of this framework's > relationship to other frameworks. > > The Energy Object Context MIB [EMAN-OBJECT-MIB ] specifies > objects for addressing Energy Object Identification, > classification, context information, and relationships from > the point of view of Energy Management. > > The Power and Energy Monitoring MIB [EMAN-MON-MIB ] > specifies objects for monitoring of Power, Energy, Demand, > Power Attributes, and Power States. > > The Battery Monitoring MIB [EMAN-BATTERY-MIB ] defines > managed objects that provide information on the status of > batteries in managed devices. > > > > > 2 > . > Terminology > > > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", > "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", > and "OPTIONAL" in this document are to be interpreted as > described inRFC-2119 [RFC2119 ]. > > In this document these words will appear with that > interpretation only when in ALL CAPS. Lower case uses of > these words are not to be interpreted as carryingRFC- > 2119 significance. > > In this section some terms have a NOTE that is not part of > the definition itself, but accounts for differences between > terminologies of different standards organizations or > further clarifies the definition. The final agreement on [EMAN-REQ] was http://www.rfc-editor.org/authors/rfc6988.txt The terms specified in the terminology section are capitalized throughout the document; the exceptions are the well-known terms "energy" and "power". These terms are generic and are used in generated terms such as "energy-saving", "low-power", etc. I suggest you do the same. I searched for a specific term in the terminology section, and realized that the order is not alphabetical. A sentence such as: "The terms in the terminology section are not classified alphabetically, but the order has been chosen to improve the document readiness, with terms building on the top of each others" > > $ Energy Management Please change the "$" sign for all entries in the terminology section. > Energy Management is a set of functions for measuring, > modeling, planning, and optimizing networks to ensure > that the network and network attached devices use energy > efficiently and appropriately for the nature of the > application and the cost constraints of the organization. > > Reference: Adapted from [ITU-T-M-3400 ] > > NOTES: > 1. Energy management refers to the activities, methods, > procedures and tools that pertain to measuring, modeling, > planning, controlling and optimizing the use of energy in > networked systems [NMF ]. > > > > > Claise et al. Expires March 23, 2014 [Page 5] > > > Internet-Draft EMAN Framework September 2013 > > 2. Energy Management is a management domain which is > congruent to any of the FCAPS areas of management in the > ISO/OSI Network Management Model [TMN ]. Energy Management > for communication networks and attached devices is a > subset or part of an organization's greater Energy > Management Policies. > > $ Energy Management System (EnMS) > An Energy Management System is a combination of hardware > and software used to administer a network with the > primary purpose of energy management. > > NOTES: > 1. An Energy Management System according to [ISO50001 ] > (ISO-EnMS) is a set of systems or procedures upon which > organizations can develop and implement an energy policy, > set targets, action plans and take into account legal > requirements related to energy use. An ISO-EnMS allows > organizations to improve energy performance and > demonstrate conformity to requirements, standards, and/or > legal requirements. > > 2. Example ISO-EnMS: Company A defines a set of policies > and procedures indicating there should exist multiple > computerized systems that will poll energy measurements > from their meters and pricing / source data from their > local utility. Company A specifies that their CFO (Chief > Financial Officer) should collect information and > summarize it quarterly to be sent to an accounting firm > to produce carbon accounting reporting as required by > their local government. > > 3. For the purposes of EMAN, the definition herein is the > preferred meaning of an Energy Management System (EnMS). > The definition from [ISO50001 ] can be referred to as ISO > Energy Management System (ISO-EnMS). > > $ Energy Monitoring > Energy Monitoring is a part of Energy Management that > deals with collecting or reading information from Energy > Objects to aid in Energy Management. > > $ Energy Control > Energy Control is a part of Energy Management that deals > with directing influence over Energy Objects. > > $ Electrical Equipment > A general term including materials, fittings, devices, > appliances, fixtures, apparatus, machines, etc., used as > > > Claise et al. Expires March 23, 2014 [Page 6] > > > Internet-Draft EMAN Framework September 2013 > > a part of, or in connection with, an electric > installation. > Reference: [IEEE100 ] > > $ Non-Electrical Equipment (Mechanical Equipment) > A general term including materials, fittings, devices, > appliances, fixtures, apparatus, machines, etc., used as > a part of, or in connection with, non-electrical power > installations. > > Reference: Adapted from [IEEE100 ] > > $ Device > A piece of electrical or non-electrical equipment. > Reference: Adapted from [IEEE100 ] > > $ Component > A part of an electrical or non-electrical equipment > (Device). > Reference: Adapted from [ITU-T-M-3400 ] > > $ Power Inlet > A Power Inlet (or simply inlet) is an interface at which > a device or component receives energy from another device > or component. > > $ Power Outlet > A Power Outlet (or simply outlet) is an interface at > which a device or component provides energy to another > device or component. Are Power Inlets and Power Oulets Power Interfaces? If yes, the definitions should be changed accordingly $ Power Inlet A Power Inlet (or simply inlet) is an Power Interface at which a device or component receives energy from another device or component. > > $ Energy > That which does work or is capable of doing work. As used > by electric utilities, it is generally a reference to > electrical energy and is measured in kilowatt hours > (kWh). > > Reference: [IEEE100 ] > > NOTES > 1. Energy is the capacity of a system to produce external > activity or perform work [ISO50001 ] > > $ Provide Energy > A device (or component) "provides" energy to another > device if there is an energy flow from this device to the > other one. > > $ Receive Energy > > > Claise et al. Expires March 23, 2014 [Page 7] > > > Internet-Draft EMAN Framework September 2013 > > A device (or component) "receives" energy from another > device if there is an energy flow from the other device > to this one. > > $ Meter (energy meter) > a device intended to measure electrical energy by > integrating power with respect to time. > > Reference: Adapted from [IEC60050 ] > > $ Battery > one or more cells (consisting of an assembly of > electrodes, electrolyte, container, terminals and usually > separators) that are a source and/or store of electric > energy. > > Reference: Adapted from [IEC60050 ] > > $ Power > The time rate at which energy is emitted, transferred, or > received; usually expressed in watts (joules per second). > > Reference: [IEEE100 ] > > $ Nameplate Power > The Nameplate Power is the nominal Power of a device as > specified by the device manufacturer. s/a device/an Electrical Device? > > $ Power Attributes > Measurements of the electrical current, voltage, phase > and frequencies at a given point in an electrical power > system. > Reference: Adapted from [IEC60050 ] > > NOTES: > 1. Power Attributes are not intended to be judgmental > with respect to a reference or technical value and are > independent of any usage context. > > $ Power Quality > Characteristics of the electrical current, voltage, phase > and frequencies at a given point in an electric power > system, evaluated against a set of reference technical > parameters. These parameters might, in some cases, relate > to the compatibility between electricity supplied in an > electric power system and the loads connected to that > electric power system. > > Reference: [IEC60050 ] > > > Claise et al. Expires March 23, 2014 [Page 8] > > > Internet-Draft EMAN Framework September 2013 > > > NOTES: > 1. Electrical characteristics representing power quality > information are typically required by customer facility > energy management systems. It is not intended to satisfy > the detailed requirements of power quality monitoring. > Standards typically also give ranges of allowed values; > the information attributes are the raw measurements, not > the "yes/no" determination by the various standards. > > Reference: [ASHRAE-201 ] > > $ Demand > The average value of power or a related quantity over a > specified interval of time. Note: Demand is expressed in > kilowatts, kilovolt-amperes, kilovars, or other suitable > units. > > Reference: [IEEE100 ] > > NOTES: > 1. For EMAN we use kilowatts. > > $ Power State > A Power State is a condition or mode of a device that > broadly characterizes its capabilities, power > consumption, and responsiveness to input. > > Reference: Adapted from [IEEE1621 ] > > $ Power State Set > A Power State Set is a collection of Power States that > comprises a named or logical control grouping. > > $ Energy Object > An Energy Object (EO) is an information model (class) > that represents a piece of equipment that is part of, or > attached to, a communications network which is monitored, > controlled, or aids in the management of another device > for Energy Management. > > $ Power Interface > A Power Interface (or simply interface) is an information > model (class) that represents the interconnections among > devices or components where energy can be provided, > received, or both. > > $ Energy Management Domain > > > > Claise et al. Expires March 23, 2014 [Page 9] > > > Internet-Draft EMAN Framework September 2013 > > An Energy Management Domain is a set of Energy Objects > that is considered one unit of management. > > $ Energy Object Identification > Energy Object Identification is a set of attributes that > enable an Energy Object to be universally unique or > linked to other systems. > > $ Energy Object Context > Energy Object Context is a set of attributes that allow > an Energy Management System to classify an Energy Object > within an organization. > > $ Energy Object Relationship > An Energy Object Relationship is an association among > Energy Objects. > > NOTES > 1. Relationships can be named and could include > Aggregation, Metering, and Power Source. > Reference: Adapted from [CHEN ] > > $ Power Source Relationship > A Power Source Relationship is an Energy Object > Relationship where one Energy Object provides power to > one or more Energy Objects. These Energy Objects are > referred to as having a Power Source Relationship. > > $ Metering Relationship > A Metering Relationship is an Energy Object Relationship > where one Energy Object measures power, energy, demand or > power attributes of one or more other Energy Objects. The > measuring Energy Object has a Metering Relationship with > each of the measured objects. > > $ Aggregation Relationship > An Aggregation Relationship is an Energy Object > Relationship where one Energy Object aggregates Energy > Management information of one or more other Energy > Objects. The aggregating Energy Object has an Aggregation > Relationship with each of the other Energy Objects. > > > > > > > > > > > Claise et al. Expires March 23, 2014 [Page 10] > > > Internet-Draft EMAN Framework September 2013 > > > > > > 3 > . > Concerns Specific to Energy Management > > > > This section explains areas of concern for Energy > Management that do not exist in traditional Network > Management. This section describes target devices, outlines > physical reference models, and lists the major concerns Again "physical" reference model. > specific to Energy Management. > > > > > 3.1 > . > Target Devices > > > > With Energy Management, there exists a wide variety of > devices that may be contained in the same deployment as > communication network but comprise a separate facility, > home, or power distribution network. > > Energy Management has special challenges because a power > distribution network supplies energy to devices and > components, while a separate communications network > monitors and controls the power distribution network. > > The target devices for Energy Management are all devices > that can be monitored or controlled (directly or > indirectly) by an Energy Management System (EnMS). These > target devices include: > o Simple electrical appliances and fixtures > o Hosts, such as a PC, a server, or a printer > o Switches, routers, base stations, and other > network equipment and middle boxes > o Components within devices, such as a battery > inside a PC, a line card inside a switch, etc. > o Power over Ethernet (PoE) endpoints > o Power Distribution Units (PDU) > o Protocol gateway devices for Building Management > Systems (BMS) > o Electrical meters > o Sensor controllers with subtended sensors I'm confused by the Device definition in the terminology, which is NOT used in this text, while "device" (paragraph above) and "target device" are used > > Target devices will primarily communicate via Internet > Protocols (IP). The target devices may also include those > communicating via non-IP protocols deployed among the power > distribution and IP communication network. These types of > target devices are expect to be managed through gateways or > proxies that can communicate using IP. > > > > > > > > Claise et al. Expires March 23, 2014 [Page 11] > > > Internet-Draft EMAN Framework September 2013 > > > > > > 3.2 > . > Physical Reference Model > > > > The following reference models describe physical power > topologies that exist in parallel to the communication > topology. While many more permutations of topologies can be Permutation of topologies or permutations of elements, which in turn, create different topologies? I believe you meant the latter. > created the following are some basic ones that show how > Energy Management topologies differ from Network Management > topologies. > > Basic Energy Management > > +--------------------------+ > | Energy Management System | > +--------------------------+ > ^ ^ > monitoring | | control > v v > +---------+ > | device | > +---------+ > > Basic Power Supply > > +-----------------------------------------+ > | energy management system | > +-----------------------------------------+ > ^ ^ ^ ^ > monitoring | | control monitoring | | control > v v v v > +--------------+ +-----------------+ > | power supply |########| device | > +--------------+ +-----------------+ > energy management system -> Energy Management System Pay attention to the terms capitalization in the figures as well. Here, we speak about device -> Device, monitoring -> Energy Monitoring control -> Energy Control You removed the fact that ######## is energy. Device versus device versus target device? I'm wondering if we should not add the Power Interfaces in the figures. > Single Power Supply with Multiple Devices > > +---------------------------------------+ > | energy management system | > +---------------------------------------+ > ^ ^ ^ ^ > monitoring | | control monitoring | | control > v v v v > +--------+ +------------------+ > | power |########| device 1 | > | supply | # +------------------+-+ > +--------+ #######| device 2 | > # +------------------+-+ > #######| device 3 | > +------------------+ > > > Claise et al. Expires March 23, 2014 [Page 12] > > > Internet-Draft EMAN Framework September 2013 > > > Multiple Power Supplies with Single Devices > > +----------------------------------------------+ > | energy management system | > +----------------------------------------------+ > ^ ^ ^ ^ ^ ^ > mon. | | ctrl. mon. | | ctrl. mon. | | ctrl. > v v v v v v > +----------+ +----------+ +----------+ > | power |######| device |######| power | > | supply 1 |######| | | supply 2 | > +----------+ +----------+ +----------+ > > > > > 3.3 > . > Concerns Differing from Network Management > > > > o Identification of the power source of a device may be > independent of the communication network and require > unique identifiers. > > o Controlling power for a device may have to be > fulfilled by addressing the power source as opposed > to directing control to the device. For example > controlling a device by controlling the outlet of the > PDU or controlling a simple light by controlling its > outlet. > > o Control of a device may need to be coordinated if > there are multiple power supplies. > > o Modeling of power when the flow of energy can be bi- > directional and require a separate interface model > from Network Management. For example energy received > into a battery or energy provided from battery). > > o Some devices may need out-of-band or proxy > capabilities to respond to communications request > even though it is in a non-operational power state. > > o Estimates and source of measurements may vary among > devices. For example when devices do not have the > capability to measure power an estimate can be > provided from the device or estimated by the EnMS. > This may require annotation of a measurement. > > o A device may require a separate abstract model to > describe its components and interconnections than a > model used to describe it for Network Management. > > > > Claise et al. Expires March 23, 2014 [Page 13] > > > Internet-Draft EMAN Framework September 2013 > > > > > > 3.4 > . > Concerns Not Addressed > One line of intro please: "concerns not addressed" is vague Which concerns? Is "concerns" the right term? Should we have some concerns that some concerns are not addressed? :-) Not addressed by this framework, I guess. What you want to say is "out of scope of this framework", right? > > Non-Electrical Equipment > > The primary focus of this framework is the management of > Electrical Equipment. Some Non-Electrical Equipment may be > connected to communication networks and could have their > energy managed if normalized to the electrical units for > power and energy. Non- > Electrical equipment that do not convert-to or present-as > equivalent to Electrical Equipment is not addressed. Non-Electrical equipments that do not convert-to or present-as equivalent to Electrical Equipments are not addressed. > > > Energy Procurement and Manufacturing > > While an EnMS may be a central point for corporate > reporting, cost computation, environmental impact analysis, > and regulatory compliance reporting - Energy Management in > this framework excludes energy procurement and the > environmental impact of energy use. > > As such the framework does not include: > o Cost in currency or environmental units of > manufacturing a device. > o Embedded carbon or environmental equivalences of a > device > o Cost in currency or environmental impact to dismantle > or recycle a device. > o Supply chain analysis of energy sources for device > deployment > o Conversion of the usage or production of energy to > units expressed from the source of that energy (such > as the greenhouse gas emissions associated with > 1000kW from a diesel source). > > > > > 4 > . > Energy Management Abstraction > > > > Network management is often divided into the five main > areas defined in the ISO Telecommunications Management > Network model: Fault, Configuration, Accounting, > Performance, and Security Management (FCAPS) [X.700 ]. This > traditional management model does not cover Energy > Management. > > This section describes a conceptual model of information > that can be used for Energy Management. The classes and > categories of attributes in the model are described with > rationale for each. > > > Claise et al. Expires March 23, 2014 [Page 14] > > > Internet-Draft EMAN Framework September 2013 > > > > > > 4.1 > . > Conceptual Model > > > > This section describes an information model addressing > issues specific to Energy Management, which complements > existing Network Management models. > > An information model for Energy Management will need to No need. > describe a means to report information, provide control, > and model the interconnections among physical entities > (equipment). interconnections = relationships We introduced the notion of relationships already Proposal: describe a means to report information, provide control, and model the relationships among physical entities (equipment). Here, it's physical entities (equipment). We had already device, Device, target device, Electrical Object Be consistent. > > Therefore, this section proposes a similar conceptual model > for physical entities to that used in Network Management: > devices, components, and interfaces. This section then > defines the additional attributes specific to Energy > Management for those entities that are not available in > existing Network Management models. > > For modeling the physical entities this section describes > three classes: a Device, a Component, and a Power > Interface. These classes are sub-types of an abstract > Energy Object class. I finally get it, I think. You really want to Energy Object to be an (instance of the) Device, Component, or Power Interface class in the information model. The readers start with the terminology and since they don't know you will need an information model, they're puzzled by the Energy Object definition. Proposal: whenever you mean the information model class, just mention Device Class Component Class etc. As you did with the subtitles below. And no need to define Energy Object in the terminology section. If you really want, insert the definition in this information model section here, along with the Device Class definition. Same thing for component. Btw, the Energy Object is not a class but an instance of the class. > > For modeling additional attributes, this section describes > attributes of an Energy Object for: identification, > classification, context, control, power and energy. > > Since the interconnections between physical entities for interconnection = relationship > Energy Management may have no relation to the > interconnections for Network Management the Energy Object interconnection = topology > classes contain a separate Relationships class as an > attribute to model these types of interconnections. > > The remainder of this section describes the conceptual > model of the classes and categories of attributes in the > information model. The formal definitions of the classes > and attributes are specified inSection 5 . > > > > > 4.2 > . > Energy Object > > > > An Energy Object is an abstract class that contains the > base attributes for Energy Management. There are three > types of Energy Objects: Device, Component and Power > Interface. > > > > > > 4.2.1 > . > Device Class > > > > > > Claise et al. Expires March 23, 2014 [Page 15] > > > Internet-Draft EMAN Framework September 2013 > > The Device Class is a sub-class of Energy Object that > represents a physical piece of equipment. > > A Device Class instance may represent a device that is a > consumer, producer, meter, distributor, or store of energy. > > A Device Class instance may represent a physical device > that contains other components. > > > > > 4.2.2 > . > Component Class > > > > The Component Class is a sub-class of Energy Object that > represents a part of a physical piece of equipment. > > > > > 4.2.3 > . > Power Interface Class > > > > The power interface class is a sub-class of Energy Object > that represents the interconnection among devices and > components. Does it? It represents the attach point for the relationship. I see later: Power Source relationships are intended to identify the connections between Power Interfaces. The Power Interface definition should be improved. > There are some similarities between Power Interfaces and > network interfaces. A network interface can be set to > different states, such as sending or receiving data on an > attached line. Similarly, a Power Interface can be > receiving or providing power. > > Physically, a Power Interface instance can represent an AC > power socket, an AC power cord attached to a device, or an > 8P8C (RJ45) PoE socket, etc. > > > > > 4.3 > . > Energy Object Attributes > > > > This section describes categories of attributes for an > Energy Object. > > > > > 4.3.1 > . > Identification > > > > A Universal Unique Identifier (UUID) [RFC4122 ] is used to > uniquely and persistently identify an Energy Object. > Ideally the UUID is used to distinguish the Energy Object > within the EnMS. > > Every Energy Object has an optional unique printable name. > Possible naming conventions are: textual DNS name, MAC > address of the device, interface ifName, or a text string > uniquely identifying the Energy Object. As an example, in > the case of IP phones, the Energy Object name can be the > device's DNS name. > > > > > Claise et al. Expires March 23, 2014 [Page 16] > > > Internet-Draft EMAN Framework September 2013 > > Additionally an alternate key is provided to allow an > Energy Object to be optionally linked with models in > different systems. > > > > > 4.3.2 > . > Context in General > > > > In order to aid in reporting and in differentiation between > Energy Objects, each object optionally contains information > establishing its business, site, or organizational context > within a deployment. > > Energy Objects contain a category attribute that broadly > describes how the object is used in a deployment. The > category indicates if the Energy Object is primarily > functioning as a consumer, producer, meter, distributor or > store of energy. > > Given the category and context of an object, an EnMS can > summarize or analyze measurements. For example, metered > usage reported by a meter and consumption usage reported by > a device connected to that meter may measure the same > usage. With the two measurements identified by category and > context an EnMS can make summarizations and inferences. Shouldn't this text be part of 4.3.4? > > > > > 4.3.3 > . > Context: Importance > > > > An Energy Object can provide an importance value in the > range of 1 to 100 to help rank a device's use or relative > value to the site. The importance range is from 1 (least > important) to 100 (most important). The default importance > value is 1. > > For example: A typical office environment has several types > of phones, which can be rated according to their business > impact. A public desk phone has a lower importance (for > example, 10) than a business-critical emergency phone (for > example, 100). As another example: A company can consider > that a PC and a phone for a customer-service engineer are > more important than a PC and a phone for lobby use. > > Although EnMS and administrators can establish their own > ranking, the following example is a broad recommendation > for commercial deployments [CISCO-EW ]: > > 90 to 100 Emergency response > 80 to 90 Executive or business-critical > 70 to 79 General or Average > 60 to 69 Staff or support > 40 to 59 Public or guest > > > Claise et al. Expires March 23, 2014 [Page 17] > > > Internet-Draft EMAN Framework September 2013 > > 1 to 39 Decorative or hospitality > > > > > 4.3.4 > . > Context: Keywords > > > > An Energy Object can provide a set of keywords. These > keywords are a list of tags that can be used for grouping, > summary reporting within or between Energy Management > Domains, and for searching. All alphanumeric characters > and symbols (other than a comma), such as #, (, $, !, and > &, are allowed. Potential examples are: IT, lobby, > HumanResources, Accounting, StoreRoom, CustomerSpace, > router, phone, floor2, or SoftwareLab. There is no default > value for a keyword. > Multiple keywords can be assigned to a device. White > spaces before and after the commas are excluded, as well as > within a keyword itself. In such cases, commas separate the > keywords and no spaces between keywords are allowed. For > example, "HR,Bldg1,Private". > > > > > 4.3.5 > . > Context: Role > > > > An Energy Object contains a "role description" string that > indicates the purpose the Energy Object serves in the > deployment. This could be a string describing the context > the device fulfills in deployment. > > Administrators can define any naming scheme for the role of > a device. As guidance, a two-word role that combines the > service the device provides along with type can be used > [IPENERGY ]. > > Example types of devices: Router, Switch, Light, Phone, > WorkStation, Server, Display, Kiosk, HVAC. > > Example Services by Line of Business: > > Line of Business Service > Education Student, Faculty, Administration, > Athletic > Finance Trader, Teller, Fulfillment > Manufacturing Assembly, Control, Shipping > Retail Advertising, Cashier > Support Helpdesk, Management > Medical Patient, Administration, Billing > > Role as a two-word string: "Faculty Desktop", "Teller > Phone", "Shipping HVAC", "Advertising Display", "Helpdesk > Kiosk", "Administration Switch". > > > > Claise et al. Expires March 23, 2014 [Page 18] > > > Internet-Draft EMAN Framework September 2013 > > > > > 4.3.6 > . > Context: Domain > > > > An Energy Object contains a string to indicate membership > in an Energy Management Domain. An Energy Management Domain > can be any collection of devices in a deployment, but it is > recommended to map 1:1 with a metered or sub-metered > portion of the site. > > In building management, a meter refers to the meter > provided by the utility used for billing and measuring > power to an entire building or unit within a building. A > sub-meter refers to a customer- or user-installed meter > that is not used by the utility to bill but is instead used > to get measurements from sub portions of a building. > An Energy Object should be a member of a single Energy > Management Domain therefore one attribute is provided. The > Energy Management Domain may be configured on an Energy > Object. > > > > > 4.4 > . > Measurements > > > > An Energy Object contains attributes to describe power, > energy and demand measurements. > > For the purposes of this framework, energy will be limited > to electrical energy in watt-hours. Other forms of Energy > Objects that use or produce non-electrical energy may be > modeled as an Energy Object but must provide information > converted to and expressed in watt-hours. > > An analogy for understanding power versus energy > measurements can be made to speed and distance in > automobiles. Just as a speedometer indicates the rate of > change of distance (speed), a power measurement indicates > the rate of transfer of energy. The odometer in an > automobile measures the cumulative distance traveled and > similarly an energy measurement indicates the accumulated > energy transferred. > > Demand measurements are averages of power measurements over > time. So using the same analogy to an automobile: measuring > the average vehicle speed over multiple intervals of time > for a given distance travelled, demand is the average power > measured over multiple time intervals for a given energy > value. > > > > > 4.4.1 > . > Measurements: Power > > > > > > > Claise et al. Expires March 23, 2014 [Page 19] > > > Internet-Draft EMAN Framework September 2013 > > Each Energy Object contains a Nameplate Power attribute > that describes the nominal power as specified by the > manufacturer. The EnMS can use the Nameplate Power for > provisioning, capacity planning and (potentially) billing. > > Each Energy Object will have information that describes the In the future, avoid the future tense for future RFCs. :-) > present power information, along with how that measurement > was obtained or derived (e.g., actual, estimated, or > static). > > A power measurement is qualified with the units, magnitude > and direction of power flow, and is qualified as to the > means by which the measurement was made. > > Power measurement magnitude conforms to the [IEC61850 ] > definition of unit multiplier for the SI (System > International) units of measure. Measured values are > represented in SI units obtained by BaseValue * (10 ^ > Scale). For example, if current power usage of an Energy > Object is 3, it could be 3 W, 3 mW, 3 KW, or 3 MW, > depending on the value of the scaling factor. 3W implies > that the BaseValue is 3 and Scale = 0, whereas 3mW implies > BaseValue = 3 and ScaleFactor = -3. > > An Energy Object indicates how the power measurement was > obtained with a caliber attribute that indicates: > o Whether the measurements were made at the device > itself or at a remote source. > o Description of the method that was used to measure > the power and whether this method can distinguish > actual or estimated values. > o Accuracy for actual measured values > > > > > 4.4.2 > . > Measurements: Power Attributes > > > > Optionally, an Energy Object describes the Power > measurements with Power Attribute information reflecting > the electrical characteristics of the measurement. These > Power Attributes adhere to the [IEC-61850-7-2] standard for > describing AC measurements. > > > > > 4.4.3 > . > Measurements: Energy > > > > Optionally, an Energy Object that can report actual power > readings will have energy attributes that provide the > energy used, produced, or stored in kWh. > > > > > 4.4.4 > . > Measurements: Demand > > > > > > Claise et al. Expires March 23, 2014 [Page 20] > > > Internet-Draft EMAN Framework September 2013 > > Optionally, an Energy Object will provide demand > information over time. Demand measurements can be provided > when the Energy Object is capable of measuring actual > power. > > > > > 4.5 > . > Control > > > > An Energy Object can be controlled by setting a Power > State. An Energy Object implements at least one set of > Power States consisting of at least two states, an on state > and an off state. > > Each Energy Object should indicate the sets of Power States > that it implements. that it supports This is more precise. > Well-known Power State Sets are > registered with IANA. > > When a device is set to a particular Power State, it may be > busy. The device will set the desired Power State and then > update the actual Power State when it changes. There are > then two Power State control variables: actual and > requested. > There are many existing standards for and implementations > of Power States. An Energy Object can support a mixed set > of Power States defined in different standards. A basic > example is given by the three Power States defined in > IEEE1621 [IEEE1621 ]: on, off, and sleep. The DMTF [DMTF ], > ACPI [ACPI ], and PWG define larger numbers of Power States. > > The semantics of a Power State are specified by > a) the functionality provided by an Energy Object in > this state, > b) a limitation of the power that an Energy Object uses > in this state, > c) a combination of a) and b) > > The semantics of a Power State should be clearly defined. > Limitation (curtailment) of the power used by an Energy > Object in a state may specified by: > o an absolute power value > o a percentage value of power relative to the energy > object's nameplate power > o an indication of power relative to another power > state. For example: Specify that power in state A is > less than in state B. > o For supporting Power State management an Energy > Object provides statistics on Power States including > the time an Energy Object spent in a certain Power > State and the number of times an Energy Object > entered a power state. > > > Claise et al. Expires March 23, 2014 [Page 21] > > > Internet-Draft EMAN Framework September 2013 > > > When requesting an Energy Object to enter a Power State an > indication of the Power State's name or number can be used. > Optionally an absolute or percentage of Nameplate Power can > be provided to allow the Energy Object to transition to a > nearest or equivalent Power State. > > > > > 4.5.1 > . > Power State Sets > > > > There are several standards and implementations of Power > State Sets. An Energy Object can support one or multiple > Power State Set implementation(s) concurrently. > > There are currently three Power State Sets advocated: > IEEE1621(256) - [IEEE1621 ] > DMTF(512) - [DMTF ] > EMAN(768) - [EMAN-MON-MIB ] > > The respective specific states related to each Power State > Set are specified in the following sections. The guidelines > for the modification of Power State Sets are specified in > the IANA Considerations Section. > > > > > 4.5.2 > . > Power State Set: IEEE1621 > > > > The IEEE1621 Power State Set [IEEE1621 ] consists of 3 > rudimentary states: on, off or sleep. > > o on(0) - The device is fully On and all features of > the device are in working mode. > o off(1) - The device is mechanically switched off > and does not consume energy. > o sleep(2) - The device is in a power saving mode, and > some features may not be available immediately. > > > > > 4.5.3 > . > Power State Set: DMTF > > > > The DMTF [DMTF ] standards organization has defined a power > profile standard based on the CIM (Common Information > Model) model that consists of 15 power states: > > {ON (2), SleepLight (3), SleepDeep (4), Off-Hard (5), Off- > Soft (6), Hibernate(7), PowerCycle Off-Soft (8), PowerCycle > Off-Hard (9), MasterBus reset (10), Diagnostic Interrupt > (11), Off-Soft-Graceful (12), Off-Hard Graceful (13), > MasterBus reset Graceful (14), Power-Cycle Off-Soft > Graceful (15), PowerCycle-Hard Graceful (16)} > > > > > Claise et al. Expires March 23, 2014 [Page 22] > > > Internet-Draft EMAN Framework September 2013 > > The DMTF standard is targeted for hosts and computers. > Details of the semantics of each Power State within the > DMTF Power State Set can be obtained from the DMTF Power > State Management Profile specification [DMTF ]. > > The DMTF power profile extends ACPI power states. The > following table provides a mapping between DMTF and ACPI > Power State Set: > > DMTF ACPI > Reserved(0) > Reserved(1) > ON (2) G0-S0 > Sleep-Light (3) G1-S1 G1-S2 > Sleep-Deep (4) G1-S3 > Power Cycle (Off-Soft) (5) G2-S5 > Off-hard (6) G3 > Hibernate (Off-Soft) (7) G1-S4 > Off-Soft (8) G2-S5 > Power Cycle (Off-Hard) (9) G3 > Master Bus Reset (10) G2-S5 > Diagnostic Interrupt (11) G2-S5 > Off-Soft Graceful (12) G2-S5 > Off-Hard Graceful (13) G3 > MasterBus Reset Graceful (14) G2-S5 > Power Cycle off-soft Graceful (15) G2-S5 > Power Cycle off-hard Graceful (16) G3 > > > > > 4.5.4 > . > Power State Set: IETF EMAN > > > > An EMAN Power State Set represents an attempt at a standard > approach for modeling the different levels of power of a > device. The EMAN Power States are an expansion of the > basic Power States as defined in [IEEE1621 ] that also > incorporates the Power States defined in [ACPI ] and [DMTF ]. > Therefore, in addition to the non-operational states as > defined in [ACPI ] and [DMTF ] standards, several > intermediate operational states have been defined. > > An Energy Object may implement fewer or more Power States > than a particular EMAN Power State Set specifies. In this > case, the Energy Object implementation can determine its > own mapping to the predefined EMAN Power States within the > EMAN Power State Set. > > There are twelve EMAN Power States that expand on > [IEEE1621 ]. The expanded list of Power States is derived > from [CISCO-EW ] and is divided into six operational states > and six non-operational states. > > > Claise et al. Expires March 23, 2014 [Page 23] > > > Internet-Draft EMAN Framework September 2013 > > > The lowest non-operational state is 1 and the highest is 6. > Each non-operational state corresponds to an [ACPI ] Global > and System state between G3 (hard-off) and G1 (sleeping). > Each operational state represents a performance state, and > may be mapped to [ACPI ] states P0 (maximum performance > power) through P5 (minimum performance and minimum power). > > In each of the non-operational states (from mechoff(1) to > ready(6)), the Power State preceding it is expected to have > a lower Power value and a longer delay in returning to an > operational state: > > mechoff(1) : An off state where no Energy Object > features are available. The Energy Object is unavailable. > No energy is being consumed and the power connector can be > removed. > > softoff(2) : Similar to mechoff(1), but some > components remain powered or receive trace power so that > the Energy Object can be awakened from its off state. In > softoff(2), no context is saved and the device typically > requires a complete boot when awakened. > > hibernate(3): No Energy Object features are > available. The Energy Object may be awakened without > requiring a complete boot, but the time for availability is > longer than sleep(4). An example for state hibernate(3) is > a save to-disk state where DRAM context is not maintained. > Typically, energy consumption is zero or close to zero. > > sleep(4) : No Energy Object features are > available, except for out-of-band management, such as wake- > up mechanisms. The time for availability is longer than > standby(5). An example for state sleep(4) is a save-to-RAM > state, where DRAM context is maintained. Typically, energy > consumption is close to zero. > > standby(5) : No Energy Object features are > available, except for out-of-band management, such as wake- > up mechanisms. This mode is analogous to cold-standby. > The time for availability is longer than ready(6). For > example processor context is may not be maintained. > Typically, energy consumption is close to zero. > > ready(6) : No Energy Object features are > available, except for out-of-band management, such as wake- > up mechanisms. This mode is analogous to hot-standby. The > Energy Object can be quickly transitioned into an > > > Claise et al. Expires March 23, 2014 [Page 24] > > > Internet-Draft EMAN Framework September 2013 > > operational state. For example, processors are not > executing, but processor context is maintained. > > lowMinus(7) : Indicates some Energy Object > features may not be available and the Energy Object has > taken measures or selected options to provide less than > low(8) usage. > > low(8) : Indicates some features may not be > available and the Energy Object has taken measures or > selected options to provide less than mediumMinus(9) usage. > > mediumMinus(9): Indicates all Energy Object > features are available but the Energy Object has taken > measures or selected options to provide less than > medium(10) usage. > > medium(10) : Indicates all Energy Object features > are available but the Energy Object has taken measures or > selected options to provide less than highMinus(11) usage. > highMinus(11): Indicates all Energy Object > features are available and power usage is less than > high(12). > > high(12) : Indicates all Energy Object features > are available and the Energy Object is consuming the > highest power. > > > > > 4.5.5 > . > Power State Sets Comparison > > > > A comparison of Power States from different Power State > Sets can be seen in the following table: > IEEE1621 DMTF ACPI EMAN > > Non-operational states > off Off-Hard G3, S5 MechOff(1) > off Off-Soft G2, S5 SoftOff(2) > sleep Hibernate G1, S4 Hibernate(3) > sleep Sleep-Deep G1, S3 Sleep(4) > sleep Sleep-Light G1, S2 Standby(5) > sleep Sleep-Light G1, S1 Ready(6) > > Operational states: > on on G0, S0, P5 LowMinus(7) > on on G0, S0, P4 Low(8) > on on G0, S0, P3 MediumMinus(9) > on on G0, S0, P2 Medium(10) > on on G0, S0, P1 HighMinus(11) > on on G0, S0, P0 High(12) > > > Claise et al. Expires March 23, 2014 [Page 25] > > > Internet-Draft EMAN Framework September 2013 > > > > > > 4.6 > . > Relationships > > > > Two Energy Objects can establish an Energy Object > Relationship to model the deployment topology with respect > to Energy Management. > > Relationships are modeled with a Relationship class that > contains the UUID of the participants in the relationship > and a description of the type of relationship. The types of > relationships are: power source, metering, and > aggregations. > > o The Power Source Relationship gives a view of the > physical wiring topology. For example: a data center > server receiving power from two specific Power > Interfaces from two different PDUs. > > Note: A power source relationship may or may not > change as the direction of power changes between two > Energy Objects. The relationship may remain to > indicate the change of power direction was unintended > or an error condition. > > o The Metering Relationship gives the view of the > metering topology. Physical meters can be placed > anywhere in a power distribution tree. For example, > utility meters monitor and report accumulated power > consumption of the entire building. Logically, the > metering topology overlaps with the wiring topology, > as meters are connected to the wiring topology. A > typical example is meters that clamp onto the > existing wiring. > > o The Aggregation Relationship gives a model of devices > that may aggregate (sum, average, etc) values for > other devices. The Aggregation Relationship is > slightly different compared to the other > relationships as this refers more to a management > function. > > In some situations, it is not possible to discover the > Energy Object Relationships, and they must be set by an > EnMS or administrator. Given that relationships can be > assigned manually, the following sections describes > guidelines for use. > > > > > > Claise et al. Expires March 23, 2014 [Page 26] > > > Internet-Draft EMAN Framework September 2013 > > > > > 4.6.1 > . > Relationship Conventions and Guidelines > > > > This Energy Management framework does not impose many > "MUST" rules related to Energy Object Relationships. There > are always corner cases that could be excluded with too > strict specifications of relationships. However, this > Energy Management framework proposes a series of > guidelines, indicated with "SHOULD" and "MAY". > > > > > 4.6.2 > . > Guidelines: Power Source > > > > Power Source relationships are intended to identify the > connections between Power Interfaces. This is analogous to > a Layer 2 connection in networking devices (a "one-hop > connection"). > > The preferred modeling would be for Power Interfaces to > participate in Power Source Relationships. It some cases > Energy Objects may not have the capability to model Power > Interfaces. Therefore a Power Source Relationship can be > established between two Energy Objects or two non-connected > Power Interfaces. > > While strictly speaking Components and Power Interfaces on > the same device do provide or receive energy from each > other, the Power Source relationship is intended to show > energy transfer between Devices. Therefore the relationship > is implied when on the same Device. > > An Energy Object SHOULD NOT establish a Power Source > Relationship with a Component. > o A Power Source Relationship SHOULD be established > with the next known Power Interface in the wiring > topology. > > o The next known Power Interface in the wiring topology > would be the next device implementing the framework. > In some cases the domain of devices under management > may include some devices that do not implement the > framework. In these cases, the Power Source > relationship can be established with the next device > in the topology that implements the framework and > logically shows the Power Source of the device. > > > > > > > > > Claise et al. Expires March 23, 2014 [Page 27] > > > Internet-Draft EMAN Framework September 2013 > > o Transitive Power Source relationships SHOULD NOT be > established. For example, if an Energy Object A has > a Power Source Relationship "Poweredby" with the > Energy Object B, and if the Energy Object B has a > Power Source Relationship "Poweredby" with the Energy > Object C, then the Energy Object A SHOULD NOT have a > Power Source Relationship "Poweredby" with the Energy > Object C. > > > > > 4.6.3 > . > Guidelines: Metering Relationship > > > > Metering Relationships are intended to show when one Device > acting as a Meter is measuring the power or energy at a > point in a power distribution system. Since one point of a > power distribution system may cover many Devices within a > wiring topology, this relationship type can be seen as an > arbitrary set. > > Some Devices, however, may include measuring hardware for > components and Power Interfaces or for the entire Device. > For example, some PDUs may have the ability to measure > Power for each Power Interface (metered by outlet). Others > may be able to control power at each Power Interface but > can only measure Power at the Power Inlet and a total for > all Power Interfaces (metered by device). > > While the Metering Relationship SHOULD be used between > devices, in some cases the Device MAY be modeled as an > Energy Object that meters all of its Power Outlets and each > Power Outlet MAY be metered by the Energy Object > representing the Device. > > In general: > o A Metering Relationship MAY be established with any > other Energy Object, Component, or Power Interface. > > o Transitive Metering relationships MAY be used. > > o When there is a series of meters for one Energy > Object, the Energy Object MAY establish a Metering > relationship with one or more of the meters. > > > > > 4.6.4 > . > Guidelines: Aggregation > > > > Aggregation relationships are intended to identify when one > device is used to accumulate values from other devices. > Typically this is for energy or power values among devices > and not for Components or Power Interfaces on the same > device. > > > Claise et al. Expires March 23, 2014 [Page 28] > > > Internet-Draft EMAN Framework September 2013 > > > The intent of Aggregation relationships is to indicate when > one device is providing aggregate values for a set of other > devices when it is not obvious from the power source or > simple containment within a device. > > Establishing aggregation relationships within the same > device would make modeling more complex and the aggregated > values can be implied from the use of Power Inlets, outlet > and Energy Object values on the same device. > > Since an EnMS is naturally a point of aggregation it is not > necessary to model aggregation for Energy Management > Systems. > > Aggregation SHOULD be used for power and energy. It MAY be "Aggregation SHOULD be used for power and energy" is misleading I guess you mean: "The Aggregation Relationship is intended for power and energy" For the rest below. Section 6 is a series of examples I'm fine with section 7, 8, and 9 (IANA, which I wrote) Regards, Benoit > used for aggregation of other values from the information > model, but the rules and logical ability to aggregate each > attribute is out of scope for this document. > > In general: > o A Device SHOULD NOT establish an Aggregation > Relationship with Components contained on the same > device. > o A Device SHOULD NOT establish an Aggregation > Relationship with the Power Interfaces contained on > the same device. > o A Device SHOULD NOT establish an Aggregation > Relationship with an EnMS. > o Aggregators SHOULD log or provide notification in the > case of errors or missing values while performing > aggregation. > > > > > 4.6.5 > . > Energy Object Relationship Extensions > > > > This framework for Energy Management is based on three > relationship types: Aggregation , Metering, and Power > Source. > This framework is defined with possible future extension of > new Energy Object Relationships in mind. > For example: > o Some Devices that may not be IP connected. This can > be modeled with a proxy relationship to an Energy > Object within the domain. This type of proxy > relationship is left for further development. > > > > > > > Claise et al. Expires March 23, 2014 [Page 29] > > > Internet-Draft EMAN Framework September 2013 > > o A Power Distribution Unit (PDU) that allows physical > entities like outlets to be "ganged" together as a > logical entity for simplified management purposes, > could be modeled with an extension called a "gang > relationship", whose semantics would specify the > Energy Objects' grouping. > > > > > 5 > . > Energy Management Information Model > > > > This section presents an information model expression of > the concepts in this framework as a reference for > implementers. The information model is implemented as a MIB > in the different related IETF EMAN documents. However, > other programming structures with different data models > could be used as well. > > Data modeling specifications of this information model may > where needed specify which attributes are required or > optional. > > EDITORs NOTE: The working group is converging on the use > of code/pseudo-code rather than ascii UML diagram. IF so we > would have to define priimitve type as reference (eg. Int, > string, etc)If agreeable we can either indicate a BNF > syntax in a formal syntax section or use the following > table if obvious: > > Syntax > > UML Construct > [ISO-IEC-19501-2005 ] Equivalent Notation > -------------------- ------------------------------------ > Notes // Notes > Class > (Generalization) CLASS name {member..} > Sub-Class > (Specialization) CLASS subclass > EXTENDS superclass {member..} > Class Member > (Attribute) attribute : type > > > > > > > > > > > > Claise et al. Expires March 23, 2014 [Page 30] > > > Internet-Draft EMAN Framework September 2013 > > > Model > > CLASS EnergyObject { > > // identification / classification > index : int > identifier : uuid > alternatekey : string > > // context > domainName : string > role : string > keywords [0..n] : string > importance : int > > // relationship > relationships [0..n] : Relationship > > // measurements > nameplate : Nameplate > power : PowerMeasurement > energy : EnergyMeasurment > demand : DemandMeasurement > > // control > powerControl [0..n] : PowerStateSet > } > > CLASS Device EXTENDS EnergyObject { > eocategory : enum { producer, consumer, meter, > distributor, store } > } > > CLASS Component EXTENDS EnergyObject > eocategory : enum { producer, consumer, meter, > distributor, store } > } > > CLASS Interface EXTENDS EnergyObject{ > eoIfType : enum ( inlet, outlet, both} > } > > CLASS Nameplate { > nominalPower : PowerMeasurement > details : URI > } > > > > > Claise et al. Expires March 23, 2014 [Page 31] > > > Internet-Draft EMAN Framework September 2013 > > CLASS Relationship { > relationshipType : enum { meters, meteredby, > powers, poweredby, aggregates, aggregatedby } > relationshipObject : uuid > } > > CLASS Measurement { > multiplier: enum { -24..24} > caliber : enum { actual, estimated, static } > accuracy : enum { 0..10000} // hundreds of percent > } > > CLASS PowerMeasurement EXTENDS Measurement { > value : long > units : "W" > powerAttribute : PowerAttribute > } > > CLASS EnergyMeasurement EXTENDS Measurement { > startTime : time > units : "kWh" > provided : long > used : long > produced : long > stored : long > } > > CLASS TimedMeasurement EXTENDS Measurement { > startTime : timestamp > value : Measurement > maximum : Measurement > } > > CLASS TimeInterval { > value : long > units : enum { seconds, miliseconds,...} > } > > CLASS DemandMeasurement EXTENDS Measurement { > intervalLength : TimeInte > rval > interval : long > intervalMode : enum { periodic, sliding, total } > intervalWindow : TimeInterval > sampleRate : TimeInterval > status : enum { active, inactive } > measurements[0..n] : TimedMeasurements > } > > > > Claise et al. Expires March 23, 2014 [Page 32] > > > Internet-Draft EMAN Framework September 2013 > > CLASS PowerStateSet { > powerSetIdentifier : int > name : string > powerStates [0..n] : PowerState > operState : int > adminState : int > reason : string > configuredTime : timestamp > } > > CLASS PowerState { > powerStateIdentifier : int > name : string > cardinality : int > maximumPower : PowerMeasurement > totalTimeInState : time > entryCount : long > } > > CLASS PowerAttribute { > > // container for attributes > acQuality : ACQuality > } > > CLASS ACQuality { > acConfiguration : enum {SNGL, DEL,WYE} > avgVoltage : long > avgCurrent : long > frequency : long > unitMultiplier : int > accuracy : int > totalActivePower : long > totalReactivePower : long > totalApparentPower : long > totalPowerFactor : long > phases [0..2] : ACPhase > } > > CLASS ACPhase { > phaseIndex : long > avgCurrent : long > activePower : long > reactivePower : long > apparentPower : long > powerFactor : long > } > > > > > Claise et al. Expires March 23, 2014 [Page 33] > > > Internet-Draft EMAN Framework September 2013 > > CLASS DelPhase EXTENDS ACPhase { > phaseToNextPhaseVoltage : long > thdVoltage : long > thdCurrent : long > } > > CLASS WYEPhase EXTENDS ACPhase { > phaseToNeutralVoltage : long > thdCurrent : long > thdVoltage : long > } > > > > > 6 > . > Modeling Relationships between Devices > > > > In this section we give examples of how to use the Energy > Management framework relationships to model physical > topologies. Where applicable, we show how the framework > can be applied when Devices have the capability to model > Power Interfaces. We also show how the framework can be > applied when devices cannot support Power Interfaces but > only monitor information or control the Device as a whole. > For instance, a PDU may only be able to measure power and > energy for the entire unit without the ability to > distinguish among the inlets or outlet. > > > > > 6.1 > . > Power Source Relationship > > > > The Power Source relationship is used to model the > interconnections between Devices, Components and/Power > Interfaces to indicate the source of energy for an Energy > Object. In the following examples we show variations on > modeling the reference topologies using relationships. > > Given for all cases: > > Device W: A computer with one power supply. Power interface > 1 is an inlet for Device W. > > Device X: A computer with two power supplies. Power > interface 1 and power interface 2 are both inlets for > Device X. > > Device Y: A PDU with multiple Power Interfaces numbered > 0..10. Power interface 0 is an inlet and power interface > 1..10 are outlets. > > Device Z: A PDU with multiple Power Interfaces numbered > 0..10. Power interface 0 is an inlet and power interface > 1..10 are outlets. > > > Claise et al. Expires March 23, 2014 [Page 34] > > > Internet-Draft EMAN Framework September 2013 > > > Case 1: Simple Device with one Source > > Physical Topology: > > o Device W inlet 1 is plugged into Device Y outlet 8. > > With Power Interfaces: > > o Device W has an Energy Object representing the > computer itself as well as one Power Interface > defined as an inlet. > o Device Y would have an Energy Object representing the > PDU itself (the Device), with a Power Interface 0 > defined as an inlet and Power Interfaces 1..10 > defined as outlets. > > The interfaces of the devices would have a Power Source > Relationship such that: > Device W inlet 1 is powered by Device Y outlet 8. > > +-------+------+ poweredBy +------+----------+ > | PDU Y | PI 8 |-----------------| PI 1 | Device W | > +-------+------+ powers +------+----------+ > > Without Power Interfaces: > > o Device W has an Energy Object representing the > computer. > o Device Y would have an Energy Object representing the > PDU. > > The devices would have a Power Source Relationship such > that: > Device W is powered by Device Y. > > > +----------+ poweredBy +------------+ > | PDU Y |-----------------| Device W | > +----------+ powers +------------+ > > Case 2: Multiple Inlets > > Physical Topology: > o Device X inlet 1 is plugged into Device Y outlet 8. > o Device X inlet 2 is plugged into Device Y outlet 9. > > With Power Interfaces: > > > Claise et al. Expires March 23, 2014 [Page 35] > > > Internet-Draft EMAN Framework September 2013 > > > o Device X has an Energy Object representing the > computer itself. It contains two Power Interfaces > defined as inlets. > o Device Y would have an Energy Object representing the > PDU itself (the Device), with a Power Interface 0 > defined as an inlet and Power Interfaces 1..10 > defined as outlets. > > The interfaces of the devices would have a Power Source > Relationship such that: > Device X inlet 1 is powered by Device Y outlet 8. > Device X inlet 2 is powered by Device Y outlet 9. > > +-------+------+ poweredBy+------+----------+ > | | PI 8 |-----------------| PI 1 | | > | | |powers | | | > | PDU Y +------+ poweredBy+------+ Device X | > | | PI 9 |-----------------| PI 2 | | > | | |powers | | | > +-------+------+ +------+----------+ > > Without Power Interfaces: > > o Device X has an Energy Object representing the > computer. Device Y has an Energy Object representing > the PDU. > > > The devices would have a Power Source Relationship such > that: > Device X is powered by Device Y. > > +----------+ poweredBy +------------+ > | PDU Y |-----------------| Device X | > +----------+ powers +------------+ > > Case 3: Multiple Sources > > Physical Topology: > o Device X inlet 1 is plugged into Device Y outlet 8. > o Device X inlet 2 is plugged into Device Z outlet 9. > > With Power Interfaces: > > > > > > > Claise et al. Expires March 23, 2014 [Page 36] > > > Internet-Draft EMAN Framework September 2013 > > o Device X has an Energy Object representing the > computer itself. It contains two Power Interface > defined as inlets. > o Device Y would have an Energy Object representing the > PDU itself (the Device), with a Power Interface 0 > defined as an inlet and Power Interfaces 1..10 > defined as outlets. > o Device Z would have an Energy Object representing the > PDU itself (the Device), with a Power Interface 0 > defined as an inlet and Power Interfaces 1..10 > defined as outlets. > > The interfaces of the devices would have a Power Source > Relationship such that: > Device X inlet 1 is powered by Device Y outlet 8. > Device X inlet 2 is powered by Device Z outlet 9. > > +-------+------+ poweredBy+------+----------+ > | PDU Y | PI 8 |-----------------| PI 1 | | > | | |powers | | | > +-------+------+ +------+ | > | Device X | > +-------+------+ poweredBy+------+ | > | PDU Z | PI 9 |-----------------| PI 2 | | > | | |powers | | | > +-------+------+ +------+----------+ > > Without Power Interfaces: > > o Device X has an Energy Object representing the > computer. Device Y and Z would both have respective > Energy Objects representing each entire PDU. > > The devices would have a Power Source Relationship such > that: > Device X is powered by Device Y and powered by Device Z. > > +----------+ poweredBy +------------+ > | PDU Y |---------------------| Device X | > +----------+ powers +------------+ > > +----------+ poweredBy +------------+ > | PDU Z |---------------------| Device X | > +----------+ powers +------------+ > > > > > 6.2 > . > Metering Relationship > > > > > > Claise et al. Expires March 23, 2014 [Page 37] > > > Internet-Draft EMAN Framework September 2013 > > Case 1: Metering between two Devices > > The metering topology between two devices is closely > related to the power source topology. It is based on the > assumption that in many cases the power provided and the > power received is the same for both peers of a power source > relationship. > > We define in this case a Metering Relationship between two > Devices or Power Interfaces of Devices that have a power > source relationship. Power and energy values measured at > one peer of the power source relationship are reported for > the other peer as well. > > The Metering Relationship is independent of the direction > of the Power Source Relationship. The most common case is > that values measured at the power provider are reported for > the power receiver. > > +-----+---+ meteredBy +--------+ poweredBy +-------+ > |Meter| PI|--------------| switch |-------------| phone | > +-----+---+ meters +--------+ powers +-------+ > | | > | meteredBy | > +-------------------------------------------+ > meters > > Case 2: Metering among many Devices > > A Sub-meter in a power distribution system can logically > measure the > power or energy for all devices downstream from the meter > in the power distribution system. As such, a Power > metering relationship can be seen as a relationship between > a meter Device and all of the devices downstream from the > meter. > > We define in this case a Power Source relationship between > a metering device and devices downstream from the meter. > > In cases where the Power Source topology cannot be > discovered or derived from the information available in the > Energy Management Domain, the Metering Topology can be used > to relate the upstream meter to the downstream devices in > the absence of specific power source relationships. > > A Metering Relationship can occur between devices that are > not directly connected, as shown in the following figure: > > > > Claise et al. Expires March 23, 2014 [Page 38] > > > Internet-Draft EMAN Framework September 2013 > > > +---------------+ > | Device 1 | > +---------------+ > | PI | > +---------------+ > | > +---------------+ > | Meter | > +---------------+ > . > . > . > meters meters meters > +----------+ +----------+ +-----------+ > | Device A | | Device B | | Device C | > +----------+ +----------+ +-----------+ > > An analogy to communications networks would be modeling > connections between servers (meters) and clients (devices) > when the complete Layer 2 topology between the servers and > clients is not known. > > > > > 6.3 > . > Aggregation Relationship > > > > Some devices can act as aggregation points for other > devices. For example, a PDU controller device may contain > the summation of power and energy readings for many PDU > devices. The PDU controller will have aggregate values for > power and energy for a group of PDU devices. > > This aggregation is independent of the physical power or > communication topology. > An Aggregation Relationship is an Energy Object > Relationship where one Energy Object (called the Aggregate > Energy Object) aggregates the Energy Management information > of one or more other Energy Objects. These Energy Objects > are said to have an Aggregation Relationship. > > The functions that the aggregation point may perform > include the calculation of values such as average, count, > maximum, median, minimum, or the listing (collection) of > the aggregation values, etc. > Based on the experience gained on aggregations at the IETF > [draft-ietf-ipfix-a9n-08 ], the aggregation function in the > EMAN framework is limited to the summation. > > When aggregation occurs across a set of entities, values to > be aggregated may be missing for some entities. The EMAN > > > Claise et al. Expires March 23, 2014 [Page 39] > > > Internet-Draft EMAN Framework September 2013 > > framework does not specify how these should be treated, as > different implementations may have good reason to take > different approaches. One common treatment is to define > the aggregation as missing if any of the constituent > elements are missing (useful to be most precise). Another > is to treat the missing value as zero (useful to have > continuous data streams). > > The specifications of aggregation functions are out of > scope of the EMAN framework, but must be clearly specified > by the equipment vendor. > > > > > 7 > . > Relationship to Other Standards > > > > This Energy Management framework uses, as much as possible, > existing standards especially with respect to information > modeling and data modeling [RFC3444 ]. > > The data model for power- and energy-related objects is > based on [IEC61850 ]. > > Specific examples include: > o The scaling factor, which represents Energy Object > usage magnitude, conforms to the [IEC61850 ] > definition of unit multiplier for the SI (System > International) units of measure. > o The electrical characteristic is based on the ANSI > and IEC Standards, which require that we use an > accuracy class for power measurement. ANSI and IEC > define the following accuracy classes for power > measurement: > o IEC 62053-22 60044-1 class 0.1, 0.2, 0.5, 1 3. > o ANSI C12.20 class 0.2, 0.5 > o The electrical characteristics and quality adhere > closely to the [IEC61850-7-2 ] standard for describing > AC measurements. > o The power state definitions are based on the DMTF > Power State Profile and ACPI models, with operational > state extensions. > > > > > 8 > . > Security Considerations > > > > Regarding the data attributes specified here, some or all > may be considered sensitive or vulnerable in some network > environments. Reading or writing these attributes without > proper protection such as encryption or access > authorization may have negative effects on the network > capabilities. > > > > Claise et al. Expires March 23, 2014 [Page 40] > > > Internet-Draft EMAN Framework September 2013 > > > > > 8.1 > . > Security Considerations for SNMP > > > > Readable objects in MIB modules (i.e., objects with a MAX- > ACCESS other than not-accessible) may be considered > sensitive or vulnerable in some network environments. It > is important to control GET and/or NOTIFY access to these > objects and possibly to encrypt the values of these objects > when sending them over the network via SNMP. > > The support for SET operations in a non-secure environment > without proper protection can have a negative effect on > network operations. > > For example: > o Unauthorized changes to the Energy Management Domain > or business context of a device may result in > misreporting or interruption of power. > o Unauthorized changes to a power state may disrupt the > power settings of the different devices, and > therefore the state of functionality of the > respective devices. > o Unauthorized changes to the demand history may > disrupt proper accounting of energy usage. > > With respect to data transport, SNMP versions prior to > SNMPv3 did not include adequate security. Even if the > network itself is secure (for example, by using IPsec), > there is still no secure control over who on the secure > network is allowed to access and GET/SET > (read/change/create/delete) the objects in these MIB > modules. > > It is recommended that implementers consider the security > features as provided by the SNMPv3 framework (see > [RFC3410], section 8 ), including full support for the > SNMPv3 cryptographic mechanisms (for authentication and > privacy). > Further, deployment of SNMP versions prior to SNMPv3 is not > recommended. Instead, it is recommended to deploy SNMPv3 > and to enable cryptographic security. It is then a > customer/operator responsibility to ensure that the SNMP > entity giving access to an instance of these MIB modules is > properly configured to give access to the objects only to > those principals (users) that have legitimate rights to GET > or SET (change/create/delete) them. > > > > > > > Claise et al. Expires March 23, 2014 [Page 41] > > > Internet-Draft EMAN Framework September 2013 > > > > > 9 > . > IANA Considerations > > > > > > 9.1 > . > IANA Registration of new Power State Sets > > > > This document specifies an initial set of Power State Sets. > The list of these Power State Sets with their numeric > identifiers is given isSection 4 . IANA maintains the lists > of Power State Sets. > > New assignments for Power State Set are administered by > IANA through 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 state for > completeness and accuracy of the description. A pure vendor > specific implementation of Power State Set shall not be > adopted; since it would lead to proliferation of Power > State Sets. > > Power states in a Power State Set are limited to 255 > distinct values. New Power State Set must be assigned the > next available numeric identifier that is a multiple of > 256. > > > > > 9.1.1 > . > IANA Registration of the IEEE1621 Power State Set > > > > This document specifies a set of values for the IEEE1621 > Power State Set [IEEE1621 ]. The list of these values with > their identifiers is given inSection 4.6.2 . IANA created > a new registry for IEEE1621 Power State Set identifiers and > filled it with the initial list of identifiers. > > New assignments (or potentially deprecation) for the > IEEE1621 Power State Set is administered by IANA through > 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 state for completeness and > accuracy of the description. > > > > > 9.1.2 > . > IANA Registration of the DMTF Power State Set > > > > This document specifies a set of values for the DMTF Power > State Set. The list of these values with their identifiers > is given inSection 4 . IANA has created a new registry for > DMTF Power State Set identifiers and filled it with the > initial list of identifiers. > > New assignments (or potentially deprecation) for the DMTF > Power State Set is administered by IANA through Expert > Review [RFC5226 ], i.e., review by one of a group of experts > designated by an IETF Area Director. The group of experts > > > Claise et al. Expires March 23, 2014 [Page 42] > > > Internet-Draft EMAN Framework September 2013 > > must check the conformance with the DMTF standard [DMTF ], > on the top of checking for completeness and accuracy of the > description. > > > > > 9.1.3 > . > IANA Registration of the EMAN Power State Set > > > > This document specifies a set of values for the EMAN Power > State Set. The list of these values with their identifiers > is given inSection 4.6.4 . IANA has created a new registry > for EMAN Power State Set identifiers and filled it with the > initial list of identifiers. > > New assignments (or potentially deprecation) for the EMAN > Power State Set is administered by IANA through 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 state for completeness and > accuracy of the description. > > > > > 9.1.4 > . > Batteries Power State Set > > > > Batteries have operational and administrational states that > could be represented as a power state set. Since the work > for battery management is parallel to this document, we are > not proposing any Power State Sets for batteries at this > time. > > > > > 9.2 > . > Updating the Registration of Existing Power State Sets > > > > With the evolution of standards, over time, it may be > important to deprecate some of the existing the Power State > Sets, or to add or deprecate some Power States within a > Power State Set. > > The registrant shall publish an Internet-draft or an > individual submission with the clear specification on > deprecation of Power State Sets or Power States registered > with IANA. The deprecation or addition shall be > administered by IANA through Expert Review [RFC5226 ], i.e., > review by one of a group of experts designated by an IETF > Area Director. The process should also allow for a > mechanism for cases where others have significant > objections to claims on deprecation of a registration. > > > > > 10 > . > References > > > > Normative References > > > > > Claise et al. Expires March 23, 2014 [Page 43] > > > Internet-Draft EMAN Framework September 2013 > > [RFC2119] Bradner, S., "Key words for use in RFCs to > Indicate Requirement Levels",BCP 14 ,RFC 2119 , > March 1997 > > [RFC3410] Case, J., Mundy, R., Partain, D., and B. > Stewart, "Introduction and Applicability > Statements for Internet Standard Management > Framework ",RFC 3410 , December 2002 > > [RFC4122] Leach, P., Mealling, M., and R. Salz," A > Universally Unique Identifier (UUID) URN > Namespace",RFC 4122 , July 2005 > > [RFC5226] Narten, T., and H. Alvestrand, "Guidelines for > Writing an IANA Considerations Section in RFCs", > RFC 5226 , May 2008 > > [RFC6933] Bierman, A. and K. McCloghrie, "Entity MIB > (Version4)",RFC 6933 , May 2013 > > [RFC3444] Pras, A., Schoenwaelder, J. "On the Differences > between Information Models and Data Models",RFC > 3444 , January 2003 > > [ISO-IEC-19501-2005] ISO/IEC 19501:2005, Information > technology, Open Distributed Processing -- > Unified Modeling Language (UML), January 2005 > > Informative References > > [RFC2578] McCloghrie, K., Perkins, D., and J. > Schoenwaelder, "Structure of Management > Information Version 2 (SMIv2",RFC 2578 , April > 1999 > > > [RFC5101bis] Claise, B., Ed., and Trammel, T., Ed., > "Specification of the IP Flow Information Export > (IPFIX) Protocol for the Exchange of IP Traffic > Flow Information ",draft-ietf-ipfix-protocol- > rfc5101bis-08 , (work in progress), June 2013 > > [RFC6020] M. Bjorklund, Ed., " YANG - A Data Modeling > Language for the Network Configuration Protocol > (NETCONF)",RFC 6020 , October 2010 > > [ACPI] "Advanced Configuration and Power Interface > Specification",http://www.acpi.info/spec30b.htm > > > > Claise et al. Expires March 23, 2014 [Page 44] > > > Internet-Draft EMAN Framework September 2013 > > [IEEE1621] "Standard for User Interface Elements in Power > Control of Electronic Devices Employed in > Office/Consumer Environments", IEEE 1621, > December 2004 > > [LLDP] IEEE Std 802.1AB, "Station and Media Control > Connectivity Discovery", 2005 > > [LLDP-MED-MIB] ANSI/TIA-1057, "The LLDP Management > Information Base extension module for TIA-TR41.4 > media endpoint discovery information", July 2005 > > [EMAN-REQ] Quittek, J., Winter, R., Dietz, T., Claise, B., > and M. Chandramouli, "Requirements for Energy > Management",draft-ietf-eman-requirements-14 , > (work in progress), May 2013 > > [EMAN-OBJECT-MIB] Parello, J., and B. Claise, "Energy > Object Contet MIB",draft-ietf-eman-energy-aware- > mib-08 , (work in progress), April 2013 > > [EMAN-MON-MIB] Chandramouli, M.,Schoening, B., Quittek, J., > Dietz, T., and B. Claise, "Power and Energy > Monitoring MIB",draft-ietf-eman-energy- > monitoring-mib-05 , (work in progress), April 2013 > > [EMAN-BATTERY-MIB] Quittek, J., Winter, R., and T. Dietz, " > Definition of Managed Objects for Battery > Monitoring",draft-ietf-eman-battery-mib-08 , > (work in progress), February 2013 > > [EMAN-AS] Schoening, B., Chandramouli, M., and B. Nordman, > "Energy Management (EMAN) Applicability > Statement",draft-ietf-eman-applicability- > statement-03 , (work in progress), April 2013 > > [ITU-T-M-3400] TMN recommandation on Management Functions > (M.3400), 1997 > > [NMF] "Network Management Fundamentals", Alexander Clemm, > ISBN: 1-58720-137-2, 2007 > > [TMN] "TMN Management Functions : Performance Management", > ITU-T M.3400 > > [IEEE100] "The Authoritative Dictionary of IEEE Standards > Terms" > http://ieeexplore.ieee.org/xpl/mostRecentIssue.js > p?punumber=4116785 > > > Claise et al. Expires March 23, 2014 [Page 45] > > > Internet-Draft EMAN Framework September 2013 > > > [ISO50001] "ISO 50001:2011 Energy management systems - > Requirements with guidance for use", > http://www.iso.org/ > > [IEC60050] International Electrotechnical Vocabulary > http://www.electropedia.org/iev/iev.nsf/welcome?o > penform > > [IEC61850] Power Utility Automation, > http://www.iec.ch/smartgrid/standards/ > > [IEC61850-7-2] Abstract communication service interface > (ACSI),http://www.iec.ch/smartgrid/standards/ > > [IEEE-802.3at] IEEE 802.3 Working Group, "IEEE Std 802.3at- > 2009 - IEEE Standard for Information technology - > Telecommunications and information exchange > between systems - Local and metropolitan area > networks - Specific requirements - Part 3: > Carrier Sense Multiple Access with Collision > Detection (CSMA/CD) Access Method and Physical > Layer Specifications - Amendment: Data Terminal > Equipment (DTE) - Power via Media Dependent > Interface (MDI) Enhancements", October 2009 > > [DMTF] "Power State Management Profile DMTF DSP1027 > Version 2.0" December 2009 > http://www.dmtf.org/sites/default/files/standards > /documents/DSP1027_2.0.0.pdf > > [IPENERGY] R. Aldrich, J. Parello "IP-Enabled Energy > Management", 2010, Wiley Publishing > > [X.700] CCITT Recommendation X.700 (1992), Management > framework for Open Systems Interconnection (OSI) > for CCITT applications > > [ASHRAE-201] "ASHRAE Standard Project Committee 201 > (SPC 201)Facility Smart Grid Information > Model",http://spc201.ashraepcs.org > > [CHEN] "The Entity-Relationship Model: Toward a Unified > View of Data", Peter Pin-shan Chen, ACM > Transactions on Database Systems, 1976 > > > > > > > Claise et al. Expires March 23, 2014 [Page 46] > > > Internet-Draft EMAN Framework September 2013 > > [CISCO-EW] "Cisco EnergyWise Design Guide", John Parello, > Roland Saville, Steve Kramling, Cisco Validated > Designs, September 2010, > http://www.cisco.com/en/US/docs/solutions/Enterpr > ise/Borderless_Networks/Energy_Management/energyw > isedg.html > > > > > > > 11 > . > Acknowledgments > > > > The authors would like to Michael Brown for his editorial > work improving the text dramatically. Thanks to Rolf Winter > for his feedback and to Bill Mielke for feedback and very > detailed review. Thanks to Bruce Nordman for brainstorming > with numerous conference calls and discussions. Finally, > the authors would like to thank the EMAN chairs: Nevil > Brownlee, Bruce Nordman, and Tom Nadeau. > > This document was prepared using 2-Word-v2.0.template.dot. > > Authors' Addresses > > John Parello > Cisco Systems, Inc. > 3550 Cisco Way > San Jose, California 95134 > US > > Phone: +1 408 525 2339 > Email:jparello@cisco.com > > Benoit Claise > Cisco Systems, Inc. > De Kleetlaan 6a b1 > Diegem 1813 > BE > > Phone: +32 2 704 5622 > Email:bclaise@cisco.com > > > Brad Schoening > 44 Rivers Edge Drive > Little Silver, NJ 07739 > US > > Phone: > Email:brad.schoening@verizon.net > > > Claise et al. Expires March 23, 2014 [Page 47] > > > Internet-Draft EMAN Framework September 2013 > > > > Juergen Quittek > NEC Europe Ltd. > Network Laboratories > Kurfuersten-Anlage 36 > 69115 Heidelberg > Germany > > Phone: +49 6221 90511 15 > EMail:quittek@netlab.nec.de > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Claise et al. Expires March 23, 2014 [Page 48] > --------------070306010905080804080002 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Dear all,

Here is my review.
Sorry for the delay.
     Network Working Group                              J. Parello
     Internet-Draft                                      B. Claise
     Intended Status: Informational             Cisco Systems, Inc.
     Expires: March 23, 2014                          B. Schoening
                                            Independent Consultant
                                                        J. Quittek
                                                    NEC Europe Ltd
     
                                                September 23, 2013
     
     
                        
Energy Management Framework

                       
draft-ietf-eman-framework-10

     
     
     Status of this Memo
     
        This Internet-Draft is submitted in full conformance with
        the provisions of BCP 78 and BCP 79.
     
        Internet-Drafts are working documents of the Internet
        Engineering Task Force (IETF), its areas, and its working
        groups.  Note that other groups may also distribute working
        documents as Internet-Drafts.
     
        Internet-Drafts are draft documents valid for a maximum of
        six months and may be updated, replaced, or obsoleted by
        other documents at any time.  It is inappropriate to use
        Internet-Drafts as reference material or to cite them other
        than as "work in progress."
     
        The list of current Internet-Drafts can be accessed at
        http://www.ietf.org/ietf/1id-abstracts.txt
     
        The list of Internet-Draft Shadow Directories can be
        accessed at http://www.ietf.org/shadow.html
     
        This Internet-Draft will expire on March 23, 2014.
     
     
     
     
     
     
     
     
     
     
     
     
     
     Claise et al            Expires March 23, 2014        [Page 1]
     

     Internet-Draft              EMAN Framework      September 2013
     
     
     Copyright Notice
     
        Copyright (c) 2013 IETF Trust and the persons identified as
        the document authors. All rights reserved.
     
        This document is subject to BCP 78 and the IETF Trust's
        Legal Provisions Relating to IETF Documents
        (http://trustee.ietf.org/license-info) in effect on the
        date of publication of this document. Please review these
        documents carefully, as they describe your rights and
        restrictions with respect to this document. Code Components
        extracted from this document must include Simplified BSD
        License text as described in Section 4.e of the Trust Legal
        Provisions and are provided without warranty as described
        in the Simplified BSD License.
     
     Abstract
     
        This document defines a framework for providing Energy
        Management for devices and device components within or
        connected to communication networks.  The framework
        presents a physical reference model and information model.
        The information model consists of an Energy Management
        Domain as a set of Energy Objects. Each Energy Object is
        identified, classified and given context.  Energy Objects
        can be monitored and controlled with respect to Power,
        Power State, Energy, Demand, Power Attributes, and Battery.
        Additionally the framework models relationships and
        capabilities between Energy Objects.
On the top of Jürgen's feedback on the abstract, I'm wondering: What is a "physical" reference model?

     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     Claise et al.           Expires March 23, 2014       [Page 2]
     

     Internet-Draft              EMAN Framework      September 2013
     
     
     Table of Contents
     
        1. Introduction........................................... 3
           1.1. Energy Management Documents Overview.............. 4
        2. Terminology............................................ 5
        3. Concerns Specific to Energy Management................ 11
           3.1. Target Devices................................... 11
           3.2. Physical Reference Model......................... 12
           3.3. Concerns Differing from Network Management....... 13
           3.4. Concerns Not Addressed........................... 14
        4. Energy Management Abstraction......................... 14
           4.1. Conceptual Model................................. 15
           4.2. Energy Object.................................... 15
           4.3. Energy Object Attributes......................... 16
           4.4. Measurements..................................... 19
           4.5. Control.......................................... 21
           4.6. Relationships.................................... 26
        5. Energy Management Information Model................... 30
        6. Modeling Relationships between Devices................ 34
           6.1. Power Source Relationship........................ 34
           6.2. Metering Relationship............................ 37
           6.3. Aggregation Relationship......................... 39
        7. Relationship to Other Standards....................... 40
        8. Security Considerations............................... 40
           8.1. Security Considerations for SNMP................. 41
        9. IANA Considerations................................... 42
           9.1. IANA Registration of new Power State Sets........ 42
           9.2. Updating the Registration of .. Power State Sets. 43
        10. References........................................... 43
        11. Acknowledgments...................................... 47
     
     
1. Introduction

     
        Network management is often divided into the five main
        areas defined in the ISO Telecommunications Management
        Network model: Fault, Configuration, Accounting,
        Performance, and Security Management (FCAPS) [X.700].  Not
        covered by this traditional management model is Energy
        Management, which is rapidly becoming a critical area of
        concern worldwide, as seen in [ISO50001].
     
        This document defines an energy management framework for
        devices within or connected to communication networks.  The
        devices, or components of these devices (such as router
        line cards, fans, disks), can then be monitored and
        controlled.  Monitoring includes measuring power, energy,
        demand, and attributes of power.  Energy control can be
        performed by setting a devices' or components' power state.
power state -> Power State.
Some more instances: be consistent in terms of capitalization in the introduction.
     
     
     Claise et al.           Expires March 23, 2014       [Page 3]
     

     Internet-Draft              EMAN Framework      September 2013
     
        If a device contains batteries, these can also be monitored
        and controlled.
     
        This framework further describes how to identify, classify
        and provide context for such devices.  While the context
        information is not specific to Energy Management, some
        context attributes are specified in the framework,
        addressing the following use cases: how important is a
        device in terms of its business impact, how should devices
        be grouped for reporting and searching, and how should a
        device role be described.  These context attributes help in
        fault management and impact analysis while controlling the
        power states.  Guidelines for using context for energy
        management are described.
     
        The framework introduces the concept of a power interface
        that is analogous to a network interface. A power interface
        is defined as an interconnection among devices where energy
        can be provided, received, or both.
     
        The most basic example of Energy Management is a single
        device reporting information about itself.  In many cases,
        however, energy is not measured by the device itself, but
        measured upstream in the power distribution tree.  For
        example, a power distribution unit (PDU) may measure the
        energy it supplies to attached devices and report this to
        an energy management system.  Therefore, devices often have
        relationships to other devices or components in the power
        network.  An EnMS (Energy Management System) generally
        requires an understanding of the power topology (who
        provides power to whom), the metering topology (who meters
        whom), and an understanding of the potential aggregation
        (ex: does a meter aggregate values from other devices).
We need to introduce that there are different relationship types, to solve the different problems.
        The relationships build on the power interface concept. The
        different relationships among devices and components,
        specified in this document, include: power source
        relationship, metering relationship, and aggregation
        relationship.
     
     
1.1. Energy Management Documents Overview

     
        The EMAN standard provides a set of specifications for
        Energy Management.  This document specifies the framework,
        per the Energy Management requirements specified in [EMAN-
        REQ].
     
        The applicability statement document [EMAN-AS] includes use
        cases, a cross-reference between existing standards and the
     
     
     Claise et al.           Expires March 23, 2014       [Page 4]
     

     Internet-Draft              EMAN Framework      September 2013
     
        EMAN standard, and a description of this framework's
        relationship to other frameworks.
     
        The Energy Object Context MIB [EMAN-OBJECT-MIB] specifies
        objects for addressing Energy Object Identification,
        classification, context information, and relationships from
        the point of view of Energy Management.
     
        The Power and Energy Monitoring MIB [EMAN-MON-MIB]
        specifies objects for monitoring of Power, Energy, Demand,
        Power Attributes, and Power States.
     
        The Battery Monitoring MIB [EMAN-BATTERY-MIB] defines
        managed objects that provide information on the status of
        batteries in managed devices.
     
     
2. Terminology

     
        The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
        "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
        and "OPTIONAL" in this document are to be interpreted as
        described in RFC-2119 [RFC2119].
     
        In this document these words will appear with that
        interpretation   only when in ALL CAPS. Lower case uses of
        these words are not to be    interpreted as carrying RFC-
        2119 significance.
     
        In this section some terms have a NOTE that is not part of
        the definition itself, but accounts for differences between
        terminologies of different standards organizations or
        further clarifies the definition.
The final agreement on [EMAN-REQ] was http://www.rfc-editor.org/authors/rfc6988.txt

   The terms specified in the terminology section are capitalized
   throughout the document; the exceptions are the well-known terms
   "energy" and "power".  These terms are generic and are used in
   generated terms such as "energy-saving", "low-power", etc.

I suggest you do the same.


I searched for a specific term in the terminology section, and realized that the order is not alphabetical.
A sentence such as: "The terms in the terminology section are not classified alphabetically, but the order has been chosen to improve the document readiness, with terms building on the top of each others"


     
        $ Energy Management
Please change the "$" sign for all entries in the terminology section.
          Energy Management is a set of functions for measuring,
          modeling, planning, and optimizing networks to ensure
          that the network and network attached devices use energy
          efficiently and appropriately for the nature of the
          application and the cost constraints of the organization.
     
          Reference: Adapted from [ITU-T-M-3400]
     
          NOTES:
          1. Energy management refers to the activities, methods,
          procedures and tools that pertain to measuring, modeling,
          planning, controlling and optimizing the use of energy in
          networked systems [NMF].
     
     
     
     
     Claise et al.           Expires March 23, 2014       [Page 5]
     

     Internet-Draft              EMAN Framework      September 2013
     
          2. Energy Management is a management domain which is
          congruent to any of the FCAPS areas of management in the
          ISO/OSI Network Management Model [TMN]. Energy Management
          for communication networks and attached devices is a
          subset or part of an organization's greater Energy
          Management Policies.
     
        $ Energy Management System (EnMS)
          An Energy Management System is a combination of hardware
          and software used to administer a network with the
          primary purpose of energy management.
     
          NOTES:
          1. An Energy Management System according to [ISO50001]
          (ISO-EnMS) is a set of systems or procedures upon which
          organizations can develop and implement an energy policy,
          set targets, action plans and take into account legal
          requirements related to energy use.  An ISO-EnMS allows
          organizations to improve energy performance and
          demonstrate conformity to requirements, standards, and/or
          legal requirements.
     
          2. Example ISO-EnMS:  Company A defines a set of policies
          and procedures indicating there should exist multiple
          computerized systems that will poll energy measurements
          from their meters and pricing / source data from their
          local utility. Company A specifies that their CFO (Chief
          Financial Officer) should collect information and
          summarize it quarterly to be sent to an accounting firm
          to produce carbon accounting reporting as required by
          their local government.
     
          3. For the purposes of EMAN, the definition herein is the
          preferred meaning of an Energy Management System (EnMS).
          The definition from [ISO50001] can be referred to as ISO
          Energy Management System (ISO-EnMS).
     
        $ Energy Monitoring
          Energy Monitoring is a part of Energy Management that
          deals with collecting or reading information from Energy
          Objects to aid in Energy Management.
     
        $ Energy Control
          Energy Control is a part of Energy Management that deals
          with directing influence over Energy Objects.
     
        $ Electrical Equipment
          A general term including materials, fittings, devices,
          appliances, fixtures, apparatus, machines, etc., used as
     
     
     Claise et al.           Expires March 23, 2014       [Page 6]
     

     Internet-Draft              EMAN Framework      September 2013
     
          a part of, or in connection with, an electric
          installation.
          Reference: [IEEE100]
     
        $ Non-Electrical Equipment (Mechanical Equipment)
          A general term including materials, fittings, devices,
          appliances, fixtures, apparatus, machines, etc., used as
          a part of, or in connection with, non-electrical power
          installations.
     
          Reference: Adapted from [IEEE100]
     
        $ Device
          A piece of electrical or non-electrical equipment.
          Reference: Adapted from [IEEE100]
     
        $ Component
          A part of an electrical or non-electrical equipment
          (Device).
          Reference: Adapted from [ITU-T-M-3400]
     
        $ Power Inlet
          A Power Inlet (or simply inlet) is an interface at which
          a device or component receives energy from another device
          or component.
     
        $ Power Outlet
          A Power Outlet (or simply outlet) is an interface at
          which a device or component provides energy to another
          device or component.
Are Power Inlets and Power Oulets Power Interfaces?
If yes, the definitions should be changed accordingly

        $ Power Inlet
          A Power Inlet (or simply inlet) is an Power Interface at which
          a device or component receives energy from another device
          or component.

     
        $ Energy
          That which does work or is capable of doing work. As used
          by electric utilities, it is generally a reference to
          electrical energy and is measured in kilowatt hours
          (kWh).
     
          Reference: [IEEE100]
     
          NOTES
          1. Energy is the capacity of a system to produce external
          activity or perform work [ISO50001]
     
        $ Provide Energy
          A device (or component) "provides" energy to another
          device if there is an energy flow from this device to the
          other one.
     
        $ Receive Energy
     
     
     Claise et al.           Expires March 23, 2014       [Page 7]
     

     Internet-Draft              EMAN Framework      September 2013
     
          A device (or component) "receives" energy from another
          device if there is an energy flow from the other device
          to this one.
     
        $ Meter (energy meter)
          a device intended to measure electrical energy by
          integrating power with respect to time.
     
          Reference: Adapted from [IEC60050]
     
        $ Battery
          one or more cells (consisting of an assembly of
          electrodes, electrolyte, container, terminals and usually
          separators)  that are a source and/or store of electric
          energy.
     
          Reference: Adapted from [IEC60050]
     
        $ Power
          The time rate at which energy is emitted, transferred, or
          received; usually expressed in watts (joules per second).
     
          Reference: [IEEE100]
     
        $ Nameplate Power
          The Nameplate Power is the nominal Power of a device as
          specified by the device manufacturer.
s/a device/an Electrical Device?
     
        $ Power Attributes
          Measurements of the electrical current, voltage, phase
          and frequencies at a given point in an electrical power
          system.
          Reference: Adapted from [IEC60050]
     
          NOTES:
          1. Power Attributes are not intended to be judgmental
          with respect to a reference or technical value and are
          independent of any usage context.
     
        $ Power Quality
          Characteristics of the electrical current, voltage, phase
          and frequencies at a given point in an electric power
          system, evaluated against a set of reference technical
          parameters. These parameters might, in some cases, relate
          to the compatibility between electricity supplied in an
          electric power system and the loads connected to that
          electric power system.
     
          Reference: [IEC60050]
     
     
     Claise et al.           Expires March 23, 2014       [Page 8]
     

     Internet-Draft              EMAN Framework      September 2013
     
     
          NOTES:
          1. Electrical characteristics representing power quality
          information are typically required by customer facility
          energy management systems. It is not intended to satisfy
          the detailed requirements of power quality monitoring.
          Standards typically also give ranges of allowed values;
          the information attributes are the raw measurements, not
          the "yes/no" determination by the various standards.
     
          Reference: [ASHRAE-201]
     
        $ Demand
          The average value of power or a related quantity over a
          specified interval of time. Note: Demand is expressed in
          kilowatts, kilovolt-amperes, kilovars, or other suitable
          units.
     
          Reference: [IEEE100]
     
          NOTES:
          1. For EMAN we use kilowatts.
     
        $ Power State
          A Power State is a condition or mode of a device that
          broadly characterizes its capabilities, power
          consumption, and responsiveness to input.
     
          Reference: Adapted from [IEEE1621]
     
        $ Power State Set
          A Power State Set is a collection of Power States that
          comprises a named or logical control grouping.
     
        $ Energy Object
          An Energy Object (EO) is an information model (class)
          that represents a piece of equipment that is part of, or
          attached to, a communications network which is monitored,
          controlled, or aids in the management of another device
          for Energy Management.
     
        $ Power Interface
          A Power Interface (or simply interface) is an information
          model (class) that represents the interconnections among
          devices or components where energy can be provided,
          received, or both.
     
        $ Energy Management Domain
     
     
     
     Claise et al.           Expires March 23, 2014       [Page 9]
     

     Internet-Draft              EMAN Framework      September 2013
     
          An Energy Management Domain is a set of Energy Objects
          that is considered one unit of management.
     
        $ Energy Object Identification
          Energy Object Identification is a set of attributes that
          enable an Energy Object to be universally unique or
          linked to other systems.
     
        $ Energy Object Context
          Energy Object Context is a set of attributes that allow
          an Energy Management System to classify an Energy Object
          within an organization.
     
        $ Energy Object Relationship
          An Energy Object Relationship is an association among
          Energy Objects.
     
          NOTES
          1. Relationships can be named and could include
          Aggregation, Metering, and Power Source.
          Reference: Adapted from [CHEN]
     
        $ Power Source Relationship
          A Power Source Relationship is an Energy Object
          Relationship where one Energy Object provides power to
          one or more Energy Objects. These Energy Objects are
          referred to as having a Power Source Relationship.
     
        $ Metering Relationship
          A Metering Relationship is an Energy Object Relationship
          where one Energy Object measures power, energy, demand or
          power attributes of one or more other Energy Objects. The
          measuring Energy Object has a Metering Relationship with
          each of the measured objects.
     
        $ Aggregation Relationship
          An Aggregation Relationship is an Energy Object
          Relationship where one Energy Object aggregates Energy
          Management information of one or more other Energy
          Objects. The aggregating Energy Object has an Aggregation
          Relationship with each of the other Energy Objects.
     
     
     
     
     
     
     
     
     
     
     Claise et al.           Expires March 23, 2014      [Page 10]
     

     Internet-Draft              EMAN Framework      September 2013
     
     
     
3. Concerns Specific to Energy Management

     
        This section explains areas of concern for Energy
        Management that do not exist in traditional Network
        Management. This section describes target devices, outlines
        physical reference models, and lists the major concerns
Again "physical" reference model.
        specific to Energy Management.
     
     
3.1. Target Devices

     
        With Energy Management, there exists a wide variety of
        devices that may be contained in the same deployment as 
        communication network but comprise a separate facility,
        home, or power distribution network.
     
        Energy Management has special challenges because a power
        distribution network supplies energy to devices and
        components, while a separate communications network
        monitors and controls the power distribution network.
     
        The target devices for Energy Management are all devices
        that can be monitored or controlled (directly or
        indirectly) by an Energy Management System (EnMS). These
        target devices include:
           o     Simple electrical appliances and fixtures
           o     Hosts, such as a PC, a server, or a printer
           o     Switches, routers, base stations, and other
              network equipment and middle boxes
           o     Components within devices, such as a battery
              inside a PC, a line card inside a switch, etc.
           o     Power over Ethernet (PoE) endpoints
           o     Power Distribution Units (PDU)
           o     Protocol gateway devices for Building Management
              Systems (BMS)
           o     Electrical meters
           o     Sensor controllers with subtended sensors
I'm confused by the Device definition in the terminology, which is NOT used in this text, while "device" (paragraph above) and "target device" are used
     
        Target devices will primarily communicate via Internet
        Protocols (IP). The target devices may also include those
        communicating via non-IP protocols deployed among the power
        distribution and IP communication network. These types of
        target devices are expect to be managed through gateways or
        proxies that can communicate using IP.
     
     
     
     
     
     
     
     Claise et al.           Expires March 23, 2014      [Page 11]
     

     Internet-Draft              EMAN Framework      September 2013
     
     
     
3.2. Physical Reference Model

     
        The following reference models describe physical power
        topologies that exist in parallel to the communication
        topology. While many more permutations of topologies can be
Permutation of topologies or permutations of elements, which in turn, create different topologies?
I believe you meant the latter.
        created the following are some basic ones that show how
        Energy Management topologies differ from Network Management
        topologies.
     
        Basic Energy Management
     
                               +--------------------------+
                               | Energy Management System |
                               +--------------------------+
                                           ^  ^
                                monitoring |  | control
                                           v  v
                                       +---------+
                                       | device  |
                                       +---------+
     
        Basic Power Supply
     
                    +-----------------------------------------+
                    |         energy management system        |
                    +-----------------------------------------+
                          ^  ^                       ^  ^
               monitoring |  | control    monitoring |  | control
                          v  v                       v  v
                    +--------------+        +-----------------+
                    | power supply |########|      device     |
                    +--------------+        +-----------------+
     

energy management system -> Energy Management System

Pay attention to the terms capitalization in the figures as well. Here, we speak about 
	device -> Device, 
	monitoring -> Energy Monitoring
	control -> Energy Control

You removed the fact that ######## is energy.

Device versus device versus target device?

I'm wondering if we should not add the Power Interfaces in the figures.
 

        Single Power Supply with Multiple Devices
     
                      +---------------------------------------+
                      |       energy management system        |
                      +---------------------------------------+
                         ^  ^                       ^  ^
              monitoring |  | control    monitoring |  | control
                         v  v                       v  v
                      +--------+        +------------------+
                      | power  |########|         device 1 |
                      | supply |   #    +------------------+-+
                      +--------+   #######|         device 2 |
                                     #    +------------------+-+
                                     #######|         device 3 |
                                            +------------------+
     
     
     Claise et al.           Expires March 23, 2014      [Page 12]
     

     Internet-Draft              EMAN Framework      September 2013
     
     
        Multiple Power Supplies with Single Devices
     
             +----------------------------------------------+
             |          energy management system            |
             +----------------------------------------------+
                 ^  ^              ^  ^              ^  ^
            mon. |  | ctrl.   mon. |  | ctrl.   mon. |  | ctrl.
                 v  v              v  v              v  v
             +----------+      +----------+      +----------+
             | power    |######|  device  |######| power    |
             | supply 1 |######|          |      | supply 2 |
             +----------+      +----------+      +----------+
     
     
3.3. Concerns Differing from Network Management

     
           o  Identification of the power source of a device may be
              independent of the communication network and require
              unique identifiers.
     
           o  Controlling power for a device may have to be
              fulfilled by addressing the power source as opposed
              to directing control to the device. For example
              controlling a device by controlling the outlet of the
              PDU or controlling a simple light by controlling its
              outlet.
     
           o  Control of a device may need to be coordinated if
              there are multiple power supplies.
     
           o  Modeling of power when the flow of energy can be bi-
              directional and require a separate interface model
              from Network Management. For example energy received
              into a battery or energy provided from battery).
     
           o  Some devices may need out-of-band or proxy
              capabilities to respond to communications request
              even though it is in a non-operational power state.
     
           o  Estimates and source of measurements may vary among
              devices. For example when devices do not have the
              capability to measure power an estimate can be
              provided from the device or estimated by the EnMS.
              This may require annotation of a measurement.
     
           o  A device may require a separate abstract model to
              describe its components and interconnections than a
              model used to describe it for Network Management.
     
     
     
     Claise et al.           Expires March 23, 2014      [Page 13]
     

     Internet-Draft              EMAN Framework      September 2013
     
     
     
3.4. Concerns Not Addressed
One line of intro please: "concerns not addressed" is vague
Which concerns? Is "concerns" the right term? Should we have some concerns that some concerns are not addressed? :-)
Not addressed by this framework, I guess.
What you want to say is "out of scope of this framework", right?
     
        Non-Electrical Equipment
     
        The primary focus of this framework is the management of
        Electrical Equipment.  Some Non-Electrical Equipment may be
        connected to communication networks and could have their
        energy managed if normalized to the electrical units for
        power and energy. Non-
        Electrical equipment that do not convert-to or present-as
        equivalent to Electrical Equipment is not addressed.

        Non-Electrical equipments that do not convert-to or present-as
        equivalent to Electrical Equipments are not addressed.
     
     
        Energy Procurement and Manufacturing
     
        While an EnMS may be a central point for corporate
        reporting, cost computation, environmental impact analysis,
        and regulatory compliance reporting - Energy Management in
        this framework excludes energy procurement and the
        environmental impact of energy use.
     
        As such the framework does not include:
           o  Cost in currency or environmental units of
              manufacturing a device.
           o  Embedded carbon or environmental equivalences of a
              device
           o  Cost in currency or environmental impact to dismantle
              or recycle a device.
           o  Supply chain analysis of energy sources for device
              deployment
           o  Conversion of the usage or production of energy to
              units expressed from the source of that energy (such
              as the greenhouse gas emissions associated with
              1000kW from a diesel source).
     
     
4. Energy Management Abstraction

     
        Network management is often divided into the five main
        areas defined in the ISO Telecommunications Management
        Network model: Fault, Configuration, Accounting,
        Performance, and Security Management (FCAPS) [X.700].  This
        traditional management model does not cover Energy
        Management.
     
        This section describes a conceptual model of information
        that can be used for Energy Management. The classes and
        categories of attributes in the model are described with
        rationale for each.
     
     
     Claise et al.           Expires March 23, 2014      [Page 14]
     

     Internet-Draft              EMAN Framework      September 2013
     
     
     
4.1. Conceptual Model

     
        This section describes an information model addressing
        issues specific to Energy Management, which complements
        existing Network Management models.
     
        An information model for Energy Management will need to
No need. 
        describe a means to report information, provide control,
        and model the interconnections among physical entities
        (equipment).
interconnections = relationships
We introduced the notion of relationships already
Proposal:
        describe a means to report information, provide control,
        and model the relationships among physical entities
        (equipment).
Here, it's physical entities (equipment).
We had already device, Device, target device, Electrical Object
Be consistent.

     
        Therefore, this section proposes a similar conceptual model
        for physical entities to that used in Network Management:
        devices, components, and interfaces. This section then
        defines the additional attributes specific to Energy
        Management for those entities that are not available in
        existing Network Management models.
     
        For modeling the physical entities this section describes
        three classes:  a Device, a Component, and a Power
        Interface. These classes are sub-types of an abstract
        Energy Object class.
I finally get it, I think.
You really want to Energy Object to be an (instance of the) Device, Component, or Power Interface class in the information model.
The readers start with the terminology and since they don't know you will need an information model, they're puzzled by the Energy Object definition.
Proposal: whenever you mean the information model class, just mention
    Device Class
    Component Class
    etc.
As you did with the subtitles below.
And no need to define Energy Object in the terminology section. If you really want, insert the definition in this information model section here, along with the Device Class definition. Same thing for component.
Btw, the Energy Object is not a class but an instance of the class.
     
        For modeling additional attributes, this section describes
        attributes of an Energy Object for: identification,
        classification, context, control, power and energy.
     
        Since the interconnections between physical entities for
interconnection = relationship
        Energy Management may have no relation to the
        interconnections for Network Management the Energy Object
interconnection = topology
        classes contain a separate Relationships class as an
        attribute to model these types of interconnections.
     
        The remainder of this section describes the conceptual
        model of the classes and categories of attributes in the
        information model. The formal definitions of the classes
        and attributes are specified in Section 5.
     
     
4.2. Energy Object

     
        An Energy Object is an abstract class that contains the
        base attributes for Energy Management.  There are three
        types of Energy Objects: Device, Component and Power
        Interface.
     
     
     
4.2.1. Device Class

     
     
     
     Claise et al.           Expires March 23, 2014      [Page 15]
     

     Internet-Draft              EMAN Framework      September 2013
     
        The Device Class is a sub-class of Energy Object that
        represents a physical piece of equipment.
     
        A Device Class instance may represent a device that is a
        consumer, producer, meter, distributor, or store of energy.
     
        A Device Class instance may represent a physical device
        that contains other components.
     
     
4.2.2. Component Class

     
        The Component Class is a sub-class of Energy Object that
        represents a part of a physical piece of equipment.
     
     
4.2.3. Power Interface Class

     
        The power interface class is a sub-class of Energy Object
        that represents the interconnection among devices and
        components.
Does it?
It represents the attach point for the relationship. I see later:
        Power Source relationships are intended to identify the
        connections between Power Interfaces.
The Power Interface definition should be improved.

    

      
        There are some similarities between Power Interfaces and
        network interfaces.  A network interface can be set to
        different states, such as sending or receiving data on an
        attached line.  Similarly, a Power Interface can be
        receiving or providing power.
     
        Physically, a Power Interface instance can represent an AC
        power socket, an AC power cord attached to a device, or an
        8P8C (RJ45) PoE socket, etc.
     
     
4.3. Energy Object Attributes

     
        This section describes categories of attributes for an
        Energy Object.
     
     
4.3.1. Identification

     
        A Universal Unique Identifier (UUID) [RFC4122] is used to
        uniquely and persistently identify an Energy Object.
        Ideally the UUID is used to distinguish the Energy Object
        within the EnMS.
     
        Every Energy Object has an optional unique printable name.
        Possible naming conventions are: textual DNS name, MAC
        address of the device, interface ifName, or a text string
        uniquely identifying the Energy Object.  As an example, in
        the case of IP phones, the Energy Object name can be the
        device's DNS name.
     
     
     
     
     Claise et al.           Expires March 23, 2014      [Page 16]
     

      

     Internet-Draft              EMAN Framework      September 2013
     
        Additionally an alternate key is provided to allow an
        Energy Object to be optionally linked with models in
        different systems.
     
     
4.3.2. Context in General

     
        In order to aid in reporting and in differentiation between
        Energy Objects, each object optionally contains information
        establishing its business, site, or organizational context
        within a deployment.
     
        Energy Objects contain a category attribute that broadly
        describes how the object is used in a deployment. The
        category indicates if the Energy Object is primarily
        functioning as a consumer, producer, meter, distributor or
        store of energy.
     
        Given the category and context of an object, an EnMS can
        summarize or analyze measurements. For example, metered
        usage reported by a meter and consumption usage reported by
        a device connected to that meter may measure the same
        usage. With the two measurements identified by category and
        context an EnMS can make summarizations and inferences.

    

    Shouldn't this text be part of 4.3.4?

    

      
     
     
4.3.3. Context: Importance

     
        An Energy Object can provide an importance value in the
        range of 1 to 100 to help rank a device's use or relative
        value to the site.  The importance range is from 1 (least
        important) to 100 (most important).  The default importance
        value is 1.
     
        For example: A typical office environment has several types
        of phones, which can be rated according to their business
        impact.  A public desk phone has a lower importance (for
        example, 10) than a business-critical emergency phone (for
        example, 100).  As another example: A company can consider
        that a PC and a phone for a customer-service engineer are
        more important than a PC and a phone for lobby use.
     
        Although EnMS and administrators can establish their own
        ranking, the following example is a broad recommendation
        for commercial deployments [CISCO-EW]:
     
           90 to 100 Emergency response
           80 to 90 Executive or business-critical
           70 to 79 General or Average
           60 to 69 Staff or support
           40 to 59 Public or guest
     
     
     Claise et al.           Expires March 23, 2014      [Page 17]
     

      

     Internet-Draft              EMAN Framework      September 2013
     
           1  to 39 Decorative or hospitality
     
     
4.3.4. Context: Keywords

     
        An Energy Object can provide a set of keywords.  These
        keywords are a list of tags that can be used for grouping,
        summary reporting within or between Energy Management
        Domains, and for searching.  All alphanumeric characters
        and symbols (other than a comma), such as #, (, $, !, and
        &, are allowed.  Potential examples are: IT, lobby,
        HumanResources, Accounting, StoreRoom, CustomerSpace,
        router, phone, floor2, or SoftwareLab.  There is no default
        value for a keyword.
        Multiple keywords can be assigned to a device.  White
        spaces before and after the commas are excluded, as well as
        within a keyword itself. In such cases, commas separate the
        keywords and no spaces between keywords are allowed.  For
        example, "HR,Bldg1,Private".
     
     
4.3.5. Context: Role

     
        An Energy Object contains a "role description" string that
        indicates the purpose the Energy Object serves in the
        deployment.  This could be a string describing the context
        the device fulfills in deployment.
     
        Administrators can define any naming scheme for the role of
        a device.  As guidance, a two-word role that combines the
        service the device provides along with type can be used
        [IPENERGY].
     
        Example types of devices: Router, Switch, Light, Phone,
        WorkStation, Server, Display, Kiosk, HVAC.
     
        Example Services by Line of Business:
     
           Line of Business     Service
           Education            Student, Faculty, Administration,
                                Athletic
           Finance              Trader, Teller, Fulfillment
           Manufacturing        Assembly, Control, Shipping
           Retail               Advertising, Cashier
           Support              Helpdesk, Management
           Medical              Patient, Administration, Billing
     
        Role as a two-word string: "Faculty Desktop", "Teller
        Phone", "Shipping HVAC", "Advertising Display", "Helpdesk
        Kiosk", "Administration Switch".
     
     
     
     Claise et al.           Expires March 23, 2014      [Page 18]
     

      

     Internet-Draft              EMAN Framework      September 2013
     
     
4.3.6. Context: Domain

     
        An Energy Object contains a string to indicate membership
        in an Energy Management Domain. An Energy Management Domain
        can be any collection of devices in a deployment, but it is
        recommended to map 1:1 with a metered or sub-metered
        portion of the site.
     
        In building management, a meter refers to the meter
        provided by the utility used for billing and measuring
        power to an entire building or unit within a building.  A
        sub-meter refers to a customer- or user-installed meter
        that is not used by the utility to bill but is instead used
        to get measurements from sub portions of a building.
        An Energy Object should be a member of a single Energy
        Management Domain therefore one attribute is provided.  The
        Energy Management Domain may be configured on an Energy
        Object.
     
     
4.4. Measurements

     
        An Energy Object contains attributes to describe power,
        energy and demand measurements.
     
        For the purposes of this framework, energy will be limited
        to electrical energy in watt-hours.  Other forms of Energy
        Objects that use or produce non-electrical energy may be
        modeled as an Energy Object but must provide information
        converted to and expressed in watt-hours.
     
        An analogy for understanding power versus energy
        measurements can be made to speed and distance in
        automobiles. Just as a speedometer indicates the rate of
        change of distance (speed), a power measurement indicates
        the rate of transfer of energy. The odometer in an
        automobile measures the cumulative distance traveled and
        similarly an energy measurement indicates the accumulated
        energy transferred.
     
        Demand measurements are averages of power measurements over
        time. So using the same analogy to an automobile: measuring
        the average vehicle speed over multiple intervals of time
        for a given distance travelled, demand is the average power
        measured over multiple time intervals for a given energy
        value.
     
     
4.4.1. Measurements: Power

     
     
     
     
     Claise et al.           Expires March 23, 2014      [Page 19]
     

      

     Internet-Draft              EMAN Framework      September 2013
     
        Each Energy Object contains a Nameplate Power attribute
        that describes the nominal power as specified by the
        manufacturer. The EnMS can use the Nameplate Power for
        provisioning, capacity planning and (potentially) billing.
     
        Each Energy Object will have information that describes the

    

    In the future, avoid the future tense for future RFCs. :-)

    

      
        present power information, along with how that measurement
        was obtained or derived (e.g., actual, estimated, or
        static).
     
        A power measurement is qualified with the units, magnitude
        and direction of power flow, and is qualified as to the
        means by which the measurement was made.
     
        Power measurement magnitude conforms to the [IEC61850]
        definition of unit multiplier for the SI (System
        International) units of measure.  Measured values are
        represented in SI units obtained by BaseValue * (10 ^
        Scale).  For example, if current power usage of an Energy
        Object is 3, it could be 3 W, 3 mW, 3 KW, or 3 MW,
        depending on the value of the scaling factor.  3W implies
        that the BaseValue is 3 and Scale = 0, whereas 3mW implies
        BaseValue = 3 and ScaleFactor = -3.
     
        An Energy Object indicates how the power measurement was
        obtained with a caliber attribute that indicates:
           o  Whether the measurements were made at the device
              itself or at a remote source.
           o  Description of the method that was used to measure
              the power  and whether this method can distinguish
              actual or estimated values.
           o  Accuracy for actual measured values
     
     
4.4.2. Measurements: Power Attributes

     
        Optionally, an Energy Object describes the Power
        measurements with Power Attribute information reflecting
        the electrical characteristics of the measurement. These
        Power Attributes adhere to the [IEC-61850-7-2] standard for
        describing AC measurements.
     
     
4.4.3. Measurements: Energy

     
        Optionally, an Energy Object that can report actual power
        readings will have energy attributes that provide the
        energy used, produced, or stored in kWh.
     
     
4.4.4. Measurements: Demand

     
     
     
     Claise et al.           Expires March 23, 2014      [Page 20]
     

      

     Internet-Draft              EMAN Framework      September 2013
     
        Optionally, an Energy Object will provide demand
        information over time. Demand measurements can be provided
        when the Energy Object is capable of measuring actual
        power.
     
     
4.5. Control

     
        An Energy Object can be controlled by setting a Power
        State.  An Energy Object implements at least one set of
        Power States consisting of at least two states, an on state
        and an off state.
     
        Each Energy Object should indicate the sets of Power States
        that it implements.  

    

    that it supports 

    This is more precise.

    

      
Well-known Power State Sets are
        registered with IANA.
     
        When a device is set to a particular Power State, it may be
        busy. The device will set the desired Power State and then
        update the actual Power State when it changes.  There are
        then two Power State control variables: actual and
        requested.
        There are many existing standards for and implementations
        of Power States.  An Energy Object can support a mixed set
        of Power States defined in different standards. A basic
        example is given by the three Power States defined in
        IEEE1621 [IEEE1621]: on, off, and sleep. The DMTF [DMTF],
        ACPI [ACPI], and PWG define larger numbers of Power States.
     
        The semantics of a Power State are specified by
           a) the functionality provided by an Energy Object in
        this state,
           b) a limitation of the power that an Energy Object uses
        in this state,
           c) a combination of a) and b)
     
        The semantics of a Power State should be clearly defined.
        Limitation (curtailment) of the power used by an Energy
        Object in a state may specified by:
           o  an absolute power value
           o  a percentage value of power relative to the energy
              object's nameplate power
           o  an indication of power relative to another power
              state. For example: Specify that power in state A is
              less than in state B.
           o  For supporting Power State management an Energy
              Object provides statistics on Power States including
              the time an Energy Object spent in a certain Power
              State and the number of times an Energy Object
              entered a power state.
     
     
     Claise et al.           Expires March 23, 2014      [Page 21]
     

      

     Internet-Draft              EMAN Framework      September 2013
     
     
        When requesting an Energy Object to enter a Power State an
        indication of the Power State's name or number can be used.
        Optionally an absolute or percentage of Nameplate Power can
        be provided to allow the Energy Object to transition to a
        nearest or equivalent Power State.
     
     
4.5.1. Power State Sets

     
        There are several standards and implementations of Power
        State Sets.  An Energy Object can support one or multiple
        Power State Set implementation(s) concurrently.
     
        There are currently three Power State Sets advocated:
          IEEE1621(256) - [IEEE1621]
          DMTF(512)     - [DMTF]
          EMAN(768)     - [EMAN-MON-MIB]
     
        The respective specific states related to each Power State
        Set are specified in the following sections. The guidelines
        for the modification of Power State Sets are specified in
        the IANA Considerations Section.
     
     
4.5.2. Power State Set: IEEE1621

     
        The IEEE1621 Power State Set [IEEE1621] consists of 3
        rudimentary states: on, off or sleep.
     
           o  on(0)    - The device is fully On and all features of
              the device are in working mode.
           o  off(1)   - The device is mechanically switched off
              and does not consume energy.
           o  sleep(2) - The device is in a power saving mode, and
              some features may not be available immediately.
     
     
4.5.3. Power State Set: DMTF

     
        The DMTF [DMTF] standards organization has defined a power
        profile standard based on the CIM (Common Information
        Model) model that consists of 15 power states:
     
        {ON (2), SleepLight (3), SleepDeep (4), Off-Hard (5), Off-
        Soft (6), Hibernate(7), PowerCycle Off-Soft (8), PowerCycle
        Off-Hard (9), MasterBus reset (10), Diagnostic Interrupt
        (11), Off-Soft-Graceful (12), Off-Hard Graceful (13),
        MasterBus reset Graceful (14), Power-Cycle Off-Soft
        Graceful (15), PowerCycle-Hard Graceful (16)}
     
     
     
     
     Claise et al.           Expires March 23, 2014      [Page 22]
     

      

     Internet-Draft              EMAN Framework      September 2013
     
        The DMTF standard is targeted for hosts and computers.
        Details of the semantics of each Power State within the
        DMTF Power State Set can be obtained from the DMTF Power
        State Management Profile specification [DMTF].
     
        The DMTF power profile extends ACPI power states. The
        following table provides a mapping between DMTF and ACPI
        Power State Set:
     
             DMTF                              ACPI
            Reserved(0)
            Reserved(1)
            ON (2)                             G0-S0
            Sleep-Light (3)                    G1-S1 G1-S2
            Sleep-Deep (4)                     G1-S3
            Power Cycle (Off-Soft) (5)         G2-S5
            Off-hard (6)                       G3
            Hibernate (Off-Soft) (7)           G1-S4
            Off-Soft (8)                       G2-S5
            Power Cycle (Off-Hard) (9)         G3
            Master Bus Reset (10)              G2-S5
            Diagnostic Interrupt (11)          G2-S5
            Off-Soft Graceful (12)             G2-S5
            Off-Hard Graceful (13)             G3
            MasterBus Reset Graceful (14)      G2-S5
            Power Cycle off-soft Graceful (15) G2-S5
            Power Cycle off-hard Graceful (16) G3
     
     
4.5.4. Power State Set: IETF EMAN

     
        An EMAN Power State Set represents an attempt at a standard
        approach for modeling the different levels of power of a
        device.  The EMAN Power States are an expansion of the
        basic Power States as defined in [IEEE1621] that also
        incorporates the Power States defined in [ACPI] and [DMTF].
        Therefore, in addition to the non-operational states as
        defined in [ACPI] and [DMTF] standards, several
        intermediate operational states have been defined.
     
        An Energy Object may implement fewer or more Power States
        than a particular EMAN Power State Set specifies. In this
        case, the Energy Object implementation can determine its
        own mapping to the predefined EMAN Power States within the
        EMAN Power State Set.
     
        There are twelve EMAN Power States that expand on
        [IEEE1621]. The expanded list of Power States is derived
        from [CISCO-EW] and is divided into six operational states
        and six non-operational states.
     
     
     Claise et al.           Expires March 23, 2014      [Page 23]
     

      

     Internet-Draft              EMAN Framework      September 2013
     
     
        The lowest non-operational state is 1 and the highest is 6.
        Each non-operational state corresponds to an [ACPI] Global
        and System state between G3 (hard-off) and G1 (sleeping).
        Each operational state represents a performance state, and
        may be mapped to [ACPI] states P0 (maximum performance
        power) through P5 (minimum performance and minimum power).
     
        In each of the non-operational states (from mechoff(1) to
        ready(6)), the Power State preceding it is expected to have
        a lower Power value and a longer delay in returning to an
        operational state:
     
                 mechoff(1) : An off state where no Energy Object
        features are available.  The Energy Object is unavailable.
        No energy is being consumed and the power connector can be
        removed.
     
                 softoff(2) : Similar to mechoff(1), but some
        components remain powered or receive trace power so that
        the Energy Object can be awakened from its off state.  In
        softoff(2), no context is saved and the device typically
        requires a complete boot when awakened.
     
                 hibernate(3): No Energy Object features are
        available.   The Energy Object may be awakened without
        requiring a complete boot, but the time for availability is
        longer than sleep(4). An example for state hibernate(3) is
        a save to-disk state where DRAM context is not maintained.
        Typically, energy consumption is zero or close to zero.
     
                 sleep(4)    : No Energy Object features are
        available, except for out-of-band management, such as wake-
        up mechanisms.  The time for availability is longer than
        standby(5). An example for state sleep(4) is a save-to-RAM
        state, where DRAM context is maintained.  Typically, energy
        consumption is close to zero.
     
                 standby(5) : No Energy Object features are
        available, except for out-of-band management, such as wake-
        up mechanisms.  This mode is analogous to cold-standby.
        The time for availability is longer than ready(6).  For
        example processor context is may not be maintained.
        Typically, energy consumption is close to zero.
     
                 ready(6)    : No Energy Object features are
        available, except for out-of-band management, such as wake-
        up mechanisms. This mode is analogous to hot-standby.  The
        Energy Object can be quickly transitioned into an
     
     
     Claise et al.           Expires March 23, 2014      [Page 24]
     

      

     Internet-Draft              EMAN Framework      September 2013
     
        operational state.  For example, processors are not
        executing, but processor context is maintained.
     
                 lowMinus(7) : Indicates some Energy Object
        features may not be available and the Energy Object has
        taken measures or selected options to provide less than
        low(8) usage.
     
                 low(8)      : Indicates some features may not be
        available and the Energy Object has taken measures or
        selected options to provide less than mediumMinus(9) usage.
     
                 mediumMinus(9): Indicates all Energy Object
        features are available but the Energy Object has taken
        measures or selected options to provide less than
        medium(10) usage.
     
                 medium(10)  : Indicates all Energy Object features
        are available but the Energy Object has taken measures or
        selected options to provide less than highMinus(11) usage.
                 highMinus(11): Indicates all Energy Object
        features are available and power usage is less than
        high(12).
     
                 high(12)    : Indicates all Energy Object features
        are available and the Energy Object is consuming the
        highest power.
     
     
4.5.5. Power State Sets Comparison

     
        A comparison of Power States from different Power State
        Sets can be seen in the following table:
          IEEE1621  DMTF         ACPI           EMAN
     
          Non-operational states
          off       Off-Hard     G3, S5         MechOff(1)
          off       Off-Soft     G2, S5         SoftOff(2)
          sleep     Hibernate    G1, S4         Hibernate(3)
          sleep     Sleep-Deep   G1, S3         Sleep(4)
          sleep     Sleep-Light  G1, S2         Standby(5)
          sleep     Sleep-Light  G1, S1         Ready(6)
     
          Operational states:
          on        on           G0, S0, P5     LowMinus(7)
          on        on           G0, S0, P4     Low(8)
          on        on           G0, S0, P3     MediumMinus(9)
          on        on           G0, S0, P2     Medium(10)
          on        on           G0, S0, P1     HighMinus(11)
          on        on           G0, S0, P0     High(12)
     
     
     Claise et al.           Expires March 23, 2014      [Page 25]
     

      

     Internet-Draft              EMAN Framework      September 2013
     
     
     
4.6. Relationships

     
        Two Energy Objects can establish an Energy Object
        Relationship to model the deployment topology with respect
        to Energy Management.
     
        Relationships are modeled with a Relationship class that
        contains the UUID of the participants in the relationship
        and a description of the type of relationship. The types of
        relationships are:  power source, metering, and
        aggregations.
     
           o  The Power Source Relationship gives a view of the
              physical wiring topology.  For example: a data center
              server receiving power from two specific Power
              Interfaces from two different PDUs.
     
              Note: A power source relationship may or may not
              change as the direction of power changes between two
              Energy Objects. The relationship may remain to
              indicate the change of power direction was unintended
              or an error condition.
     
           o  The Metering Relationship gives the view of the
              metering topology.  Physical meters can be placed
              anywhere in a power distribution tree.  For example,
              utility meters monitor and report accumulated power
              consumption of the entire building. Logically, the
              metering topology overlaps with the wiring topology,
              as meters are connected to the wiring topology.  A
              typical example is meters that clamp onto the
              existing wiring.
     
           o  The Aggregation Relationship gives a model of devices
              that may aggregate (sum, average, etc) values for
              other devices.  The Aggregation Relationship is
              slightly different compared to the other
              relationships as this refers more to a management
              function.
     
        In some situations, it is not possible to discover the
        Energy Object Relationships, and they must be set by an
        EnMS or administrator.  Given that relationships can be
        assigned manually, the following sections describes
        guidelines for use.
     
     
     
     
     
     Claise et al.           Expires March 23, 2014      [Page 26]
     

    

    

      

     Internet-Draft              EMAN Framework      September 2013
     
     
4.6.1. Relationship Conventions and Guidelines

     
        This Energy Management framework does not impose many
        "MUST" rules related to Energy Object Relationships. There
        are always corner cases that could be excluded with too
        strict specifications of relationships. However, this
        Energy Management framework proposes a series of
        guidelines, indicated with "SHOULD" and "MAY".
     
     
4.6.2. Guidelines: Power Source

     
        Power Source relationships are intended to identify the
        connections between Power Interfaces. This is analogous to
        a Layer 2 connection in networking devices (a "one-hop
        connection").
     
        The preferred modeling would be for Power Interfaces to
        participate in Power Source Relationships. It some cases
        Energy Objects may not have the capability to model Power
        Interfaces.  Therefore a Power Source Relationship can be
        established between two Energy Objects or two non-connected
        Power Interfaces.
     
        While strictly speaking Components and Power Interfaces on
        the same device do provide or receive energy from each
        other, the Power Source relationship is intended to show
        energy transfer between Devices. Therefore the relationship
        is implied when on the same Device.
     
        An Energy Object SHOULD NOT establish a Power Source
        Relationship with a Component.
           o  A Power Source Relationship SHOULD be established
              with the next known Power Interface in the wiring
              topology.
     
           o  The next known Power Interface in the wiring topology
              would be the next device implementing the framework.
              In some cases the domain of devices under management
              may include some devices that do not implement the
              framework. In these cases, the Power Source
              relationship can be established with the next device
              in the topology that implements the framework and
              logically shows the Power Source of the device.
     
     
     
     
     
     
     
     
     Claise et al.           Expires March 23, 2014      [Page 27]
     

      

     Internet-Draft              EMAN Framework      September 2013
     
           o  Transitive Power Source relationships SHOULD NOT be
              established.  For example, if an Energy Object A has
              a Power Source Relationship "Poweredby" with the
              Energy Object B, and if the Energy Object B has a
              Power Source Relationship "Poweredby" with the Energy
              Object C, then the Energy Object A SHOULD NOT have a
              Power Source Relationship "Poweredby" with the Energy
              Object C.
     
     
4.6.3. Guidelines: Metering Relationship

     
        Metering Relationships are intended to show when one Device
        acting as a Meter is measuring the power or energy at a
        point in a power distribution system. Since one point of a
        power distribution system may cover many Devices within a
        wiring topology, this relationship type can be seen as an
        arbitrary set.
     
        Some Devices, however, may include measuring hardware for
        components and Power Interfaces or for the entire Device.
        For example, some PDUs may have the ability to measure
        Power for each Power Interface (metered by outlet). Others
        may be able to control power at each Power Interface but
        can only measure Power at the Power Inlet and a total for
        all Power Interfaces (metered by device).
     
        While the Metering Relationship SHOULD be used between
        devices, in some cases the Device MAY be modeled as an
        Energy Object that meters all of its Power Outlets and each
        Power Outlet MAY be metered by the Energy Object
        representing the Device.
     
        In general:
           o  A Metering Relationship MAY be established with any
              other Energy Object, Component, or Power Interface.
     
           o  Transitive Metering relationships MAY be used.
     
           o  When there is a series of meters for one Energy
              Object, the Energy Object MAY establish a Metering
              relationship with one or more of the meters.
     
     
4.6.4. Guidelines: Aggregation

     
        Aggregation relationships are intended to identify when one
        device is used to accumulate values from other devices.
        Typically this is for energy or power values among devices
        and not for Components or Power Interfaces on the same
        device.
     
     
     Claise et al.           Expires March 23, 2014      [Page 28]
     

      

     Internet-Draft              EMAN Framework      September 2013
     
     
        The intent of Aggregation relationships is to indicate when
        one device is providing aggregate values for a set of other
        devices when it is not obvious from the power source or
        simple containment within a device.
     
        Establishing aggregation relationships within the same
        device would make modeling more complex and the aggregated
        values can be implied from the use of Power Inlets, outlet
        and Energy Object values on the same device.
     
        Since an EnMS is naturally a point of aggregation it is not
        necessary to model aggregation for Energy Management
        Systems.
     
        Aggregation SHOULD be used for power and energy. It MAY be

    

    

    
"Aggregation SHOULD be used for power and energy" is misleading
I guess you mean: "The Aggregation Relationship is intended for power and energy"

For the rest below. 
Section 6 is a series of examples
I'm fine with section 7, 8, and 9 (IANA, which I wrote)

Regards, Benoit 


    

      
        used for aggregation of other values from the information
        model, but the rules and logical ability to aggregate each
        attribute is out of scope for this document.
     
        In general:
           o  A Device SHOULD NOT establish an Aggregation
              Relationship with Components contained on the same
              device.
           o  A Device SHOULD NOT establish an Aggregation
              Relationship with the Power Interfaces contained on
              the same device.
           o  A Device SHOULD NOT establish an Aggregation
              Relationship with an EnMS.
           o  Aggregators SHOULD log or provide notification in the
              case of errors or missing values while performing
              aggregation.
     
     
4.6.5. Energy Object Relationship Extensions

     
        This framework for Energy Management is based on three
        relationship types: Aggregation , Metering, and Power
        Source.
        This framework is defined with possible future extension of
        new Energy Object Relationships in mind.
        For example:
           o  Some Devices that may not be IP connected. This can
              be modeled with a proxy relationship to an Energy
              Object within the domain. This type of proxy
              relationship is left for further development.
     
     
     
     
     
     
     Claise et al.           Expires March 23, 2014      [Page 29]
     

      

     Internet-Draft              EMAN Framework      September 2013
     
           o  A Power Distribution Unit (PDU) that allows physical
              entities like outlets to be "ganged" together as a
              logical entity for simplified management purposes,
              could be modeled with an extension called a "gang
              relationship", whose semantics would specify the
              Energy Objects' grouping.
     
     
5. Energy Management Information Model

     
        This section presents an information model expression of
        the concepts in this framework as a reference for
        implementers. The information model is implemented as a MIB
        in the different related IETF EMAN documents.  However,
        other programming structures with different data models
        could be used as well.
     
        Data modeling specifications of this information model may
        where needed specify which attributes are required or
        optional.
     
        EDITORs NOTE:  The working group is converging on the use
        of code/pseudo-code rather than ascii UML diagram. IF so we
        would have to define priimitve type as reference (eg. Int,
        string, etc)If agreeable we can either indicate a BNF
        syntax in a formal syntax section or use the following
        table if obvious:
     
        Syntax
     
          UML Construct
          [ISO-IEC-19501-2005] Equivalent Notation
          -------------------- ------------------------------------
          Notes                // Notes
          Class
          (Generalization)     CLASS name {member..}
          Sub-Class
          (Specialization)     CLASS subclass
                                     EXTENDS superclass {member..}
          Class Member
          (Attribute)          attribute : type
     
     
     
     
     
     
     
     
     
     
     
     Claise et al.           Expires March 23, 2014      [Page 30]
     

      

     Internet-Draft              EMAN Framework      September 2013
     
     
        Model
     
        CLASS EnergyObject {
     
           // identification / classification
           index        : int
           identifier   : uuid
           alternatekey : string
     
           // context
           domainName      : string
           role            : string
           keywords [0..n] : string
           importance      : int
     
           // relationship
           relationships [0..n] : Relationship
     
           // measurements
           nameplate    : Nameplate
           power     : PowerMeasurement
           energy    : EnergyMeasurment
           demand    : DemandMeasurement
     
           // control
           powerControl [0..n] : PowerStateSet
        }
     
        CLASS Device EXTENDS EnergyObject {
              eocategory   : enum { producer, consumer, meter,
        distributor, store }
        }
     
        CLASS Component EXTENDS EnergyObject
              eocategory   : enum { producer, consumer, meter,
        distributor, store }
        }
     
        CLASS Interface EXTENDS EnergyObject{
              eoIfType : enum ( inlet, outlet, both}
        }
     
        CLASS Nameplate {
              nominalPower : PowerMeasurement
              details      : URI
        }
     
     
     
     
     Claise et al.           Expires March 23, 2014      [Page 31]
     

      

     Internet-Draft              EMAN Framework      September 2013
     
        CLASS Relationship {
              relationshipType    : enum { meters, meteredby,
        powers, poweredby, aggregates, aggregatedby }
              relationshipObject  : uuid
        }
     
        CLASS Measurement {
              multiplier: enum { -24..24}
              caliber   : enum { actual, estimated, static }
              accuracy  : enum { 0..10000} // hundreds of percent
        }
     
        CLASS PowerMeasurement EXTENDS Measurement {
              value          : long
              units          : "W"
              powerAttribute : PowerAttribute
        }
     
        CLASS EnergyMeasurement EXTENDS Measurement {
              startTime : time
              units     : "kWh"
              provided  : long
              used      : long
              produced  : long
              stored    : long
        }
     
        CLASS TimedMeasurement EXTENDS Measurement {
              startTime  : timestamp
              value      : Measurement
              maximum    : Measurement
        }
     
        CLASS TimeInterval {
              value      : long
              units      : enum { seconds, miliseconds,...}
        }
     
        CLASS DemandMeasurement EXTENDS Measurement {
              intervalLength : TimeInte
        rval
              interval       : long
              intervalMode   : enum { periodic, sliding, total }
              intervalWindow : TimeInterval
              sampleRate     : TimeInterval
              status         : enum { active, inactive }
              measurements[0..n] : TimedMeasurements
        }
     
     
     
     Claise et al.           Expires March 23, 2014      [Page 32]
     

      

     Internet-Draft              EMAN Framework      September 2013
     
        CLASS PowerStateSet {
              powerSetIdentifier : int
              name               : string
              powerStates [0..n] : PowerState
              operState          : int
              adminState         : int
              reason             : string
              configuredTime     : timestamp
        }
     
        CLASS PowerState {
              powerStateIdentifier  : int
              name             : string
              cardinality      : int
              maximumPower     : PowerMeasurement
              totalTimeInState : time
              entryCount       : long
        }
     
        CLASS PowerAttribute {
     
           // container for attributes
                 acQuality   : ACQuality
        }
     
        CLASS ACQuality {
           acConfiguration : enum {SNGL, DEL,WYE}
           avgVoltage   : long
           avgCurrent   : long
           frequency    : long
           unitMultiplier  : int
           accuracy    : int
           totalActivePower   : long
           totalReactivePower : long
           totalApparentPower : long
           totalPowerFactor : long
           phases [0..2]  : ACPhase
        }
     
        CLASS ACPhase {
           phaseIndex : long
           avgCurrent : long
           activePower : long
           reactivePower : long
           apparentPower : long
           powerFactor : long
        }
     
     
     
     
     Claise et al.           Expires March 23, 2014      [Page 33]
     

      

     Internet-Draft              EMAN Framework      September 2013
     
        CLASS DelPhase EXTENDS ACPhase {
           phaseToNextPhaseVoltage  : long
           thdVoltage : long
           thdCurrent : long
        }
     
        CLASS WYEPhase EXTENDS ACPhase {
           phaseToNeutralVoltage : long
           thdCurrent : long
           thdVoltage : long
        }
     
     
6. Modeling Relationships between Devices

     
        In this section we give examples of how to use the Energy
        Management framework relationships to model physical
        topologies.  Where applicable, we show how the framework
        can be applied when Devices have the capability to model
        Power Interfaces.  We also show how the framework can be
        applied when devices cannot support Power Interfaces but
        only monitor information or control the Device as a whole.
        For instance, a PDU may only be able to measure power and
        energy for the entire unit without the ability to
        distinguish among the inlets or outlet.
     
     
6.1. Power Source Relationship

     
        The Power Source relationship is used to model the
        interconnections between Devices, Components and/Power
        Interfaces to indicate the source of energy for an Energy
        Object. In the following examples we show variations on
        modeling the reference topologies using relationships.
     
        Given for all cases:
     
        Device W: A computer with one power supply. Power interface
        1 is an inlet for Device W.
     
        Device X: A computer with two power supplies. Power
        interface 1 and power interface 2 are both inlets for
        Device X.
     
        Device Y: A PDU with multiple Power Interfaces numbered
        0..10. Power interface 0 is an inlet and power interface
        1..10 are outlets.
     
        Device Z: A PDU with multiple Power Interfaces numbered
        0..10. Power interface 0 is an inlet and power interface
        1..10 are outlets.
     
     
     Claise et al.           Expires March 23, 2014      [Page 34]
     

      

     Internet-Draft              EMAN Framework      September 2013
     
     
        Case 1: Simple Device with one Source
     
        Physical Topology:
     
           o  Device W inlet 1 is plugged into Device Y outlet 8.
     
        With Power Interfaces:
     
           o  Device W has an Energy Object representing the
              computer itself as well as one Power Interface
              defined as an inlet.
           o  Device Y would have an Energy Object representing the
              PDU itself (the Device), with a Power Interface 0
              defined as an inlet and Power Interfaces 1..10
              defined as outlets.
     
        The interfaces of the devices would have a Power Source
        Relationship such that:
        Device W inlet 1 is powered by Device Y outlet 8.
     
           +-------+------+       poweredBy +------+----------+
           | PDU Y | PI 8 |-----------------| PI 1 | Device W |
           +-------+------+ powers          +------+----------+
     
        Without Power Interfaces:
     
           o  Device W has an Energy Object representing the
              computer.
           o  Device Y would have an Energy Object representing the
              PDU.
     
        The devices would have a Power Source Relationship such
        that:
        Device W is powered by Device Y.
     
     
           +----------+       poweredBy +------------+
           |  PDU Y   |-----------------|  Device W  |
           +----------+ powers          +------------+
     
        Case 2: Multiple Inlets
     
        Physical Topology:
           o  Device X inlet 1 is plugged into Device Y outlet 8.
           o  Device X inlet 2 is plugged into Device Y outlet 9.
     
        With Power Interfaces:
     
     
     Claise et al.           Expires March 23, 2014      [Page 35]
     

      

     Internet-Draft              EMAN Framework      September 2013
     
     
           o  Device X has an Energy Object representing the
              computer itself. It contains two Power Interfaces
              defined as inlets.
           o  Device Y would have an Energy Object representing the
              PDU itself (the Device), with a Power Interface 0
              defined as an inlet and Power Interfaces 1..10
              defined as outlets.
     
        The interfaces of the devices would have a Power Source
        Relationship such that:
        Device X inlet 1 is powered by Device Y outlet 8.
        Device X inlet 2 is powered by Device Y outlet 9.
     
           +-------+------+        poweredBy+------+----------+
           |       | PI 8 |-----------------| PI 1 |          |
           |       |      |powers           |      |          |
           | PDU Y +------+        poweredBy+------+ Device X |
           |       | PI 9 |-----------------| PI 2 |          |
           |       |      |powers           |      |          |
           +-------+------+                 +------+----------+
     
        Without Power Interfaces:
     
           o  Device X has an Energy Object representing the
              computer. Device Y has an Energy Object representing
              the PDU.
     
     
        The devices would have a Power Source Relationship such
        that:
        Device X is powered by Device Y.
     
           +----------+       poweredBy +------------+
           |  PDU Y   |-----------------|  Device X  |
           +----------+ powers          +------------+
     
        Case 3: Multiple Sources
     
        Physical Topology:
           o  Device X inlet 1 is plugged into Device Y outlet 8.
           o  Device X inlet 2 is plugged into Device Z outlet 9.
     
        With Power Interfaces:
     
     
     
     
     
     
     Claise et al.           Expires March 23, 2014      [Page 36]
     

      

     Internet-Draft              EMAN Framework      September 2013
     
           o  Device X has an Energy Object representing the
              computer itself. It contains two Power Interface
              defined as inlets.
           o  Device Y would have an Energy Object representing the
              PDU itself  (the Device), with a Power Interface 0
              defined as an inlet and Power Interfaces 1..10
              defined as outlets.
           o  Device Z would have an Energy Object representing the
              PDU itself  (the Device), with a Power Interface 0
              defined as an inlet and Power Interfaces 1..10
              defined as outlets.
     
        The interfaces of the devices would have a Power Source
        Relationship such that:
        Device X inlet 1 is powered by Device Y outlet 8.
        Device X inlet 2 is powered by Device Z outlet 9.
     
           +-------+------+        poweredBy+------+----------+
           | PDU Y | PI 8 |-----------------| PI 1 |          |
           |       |      |powers           |      |          |
           +-------+------+                 +------+          |
                                                   | Device X |
           +-------+------+        poweredBy+------+          |
           | PDU Z | PI 9 |-----------------| PI 2 |          |
           |       |      |powers           |      |          |
           +-------+------+                 +------+----------+
     
        Without Power Interfaces:
     
           o  Device X has an Energy Object representing the
              computer. Device Y and Z would both have respective
              Energy Objects representing each entire PDU.
     
        The devices would have a Power Source Relationship such
        that:
        Device X is powered by Device Y and powered by Device Z.
     
           +----------+           poweredBy +------------+
           |  PDU Y   |---------------------|  Device X  |
           +----------+ powers              +------------+
     
           +----------+           poweredBy +------------+
           |  PDU Z   |---------------------|  Device X  |
           +----------+ powers              +------------+
     
     
6.2. Metering Relationship

     
     
     
     Claise et al.           Expires March 23, 2014      [Page 37]
     

      

     Internet-Draft              EMAN Framework      September 2013
     
        Case 1: Metering between two Devices
     
        The metering topology between two devices is closely
        related to the power source topology.  It is based on the
        assumption that in many cases the power provided and the
        power received is the same for both peers of a power source
        relationship.
     
        We define in this case a Metering Relationship between two
        Devices or Power Interfaces of Devices that have a power
        source relationship.  Power and energy values measured at
        one peer of the power source relationship are reported for
        the other peer as well.
     
        The Metering Relationship is independent of the direction
        of the Power Source Relationship.  The most common case is
        that values measured at the power provider are reported for
        the power receiver.
     
        +-----+---+    meteredBy +--------+   poweredBy +-------+
        |Meter| PI|--------------| switch |-------------| phone |
        +-----+---+ meters       +--------+ powers      +-------+
                |                                           |
                |                                 meteredBy |
                +-------------------------------------------+
                 meters
     
        Case 2: Metering among many Devices
     
        A Sub-meter in a power distribution system can logically
        measure the
        power or energy for all devices downstream from the meter
        in the power distribution system.  As such, a Power
        metering relationship can be seen as a relationship between
        a meter Device and all of the devices downstream from the
        meter.
     
        We define in this case a Power Source relationship between
        a metering device and devices downstream from the meter.
     
        In cases where the Power Source topology cannot be
        discovered or derived from the information available in the
        Energy Management Domain, the Metering Topology can be used
        to relate the upstream meter to the downstream devices in
        the absence of specific power source relationships.
     
        A Metering Relationship can occur between devices that are
        not directly connected, as shown in the following figure:
     
     
     
     Claise et al.           Expires March 23, 2014      [Page 38]
     

      

     Internet-Draft              EMAN Framework      September 2013
     
     
                           +---------------+
                           |   Device 1    |
                           +---------------+
                           |      PI       |
                           +---------------+
                                   |
                           +---------------+
                           |     Meter     |
                           +---------------+
                                   .
                                   .
                                   .
                  meters        meters           meters
            +----------+   +----------+   +-----------+
            | Device A |   | Device B |   | Device C  |
            +----------+   +----------+   +-----------+
     
        An analogy to communications networks would be modeling
        connections between servers (meters) and clients (devices)
        when the complete Layer 2 topology between the servers and
        clients is not known.
     
     
6.3. Aggregation Relationship

     
        Some devices can act as aggregation points for other
        devices.  For example, a PDU controller device may contain
        the summation of power and energy readings for many PDU
        devices.  The PDU controller will have aggregate values for
        power and energy for a group of PDU devices.
     
        This aggregation is independent of the physical power or
        communication topology.
        An Aggregation Relationship is an Energy Object
        Relationship where one Energy Object (called the Aggregate
        Energy Object) aggregates the Energy Management information
        of one or more other Energy Objects.  These Energy Objects
        are said to have an Aggregation Relationship.
     
        The functions that the aggregation point may perform
        include the calculation of values such as average, count,
        maximum, median, minimum, or the listing (collection) of
        the aggregation values, etc.
        Based on the experience gained on aggregations at the IETF
        [draft-ietf-ipfix-a9n-08], the aggregation function in the
        EMAN framework is limited to the summation.
     
        When aggregation occurs across a set of entities, values to
        be aggregated may be missing for some entities.  The EMAN
     
     
     Claise et al.           Expires March 23, 2014      [Page 39]
     

      

     Internet-Draft              EMAN Framework      September 2013
     
        framework does not specify how these should be treated, as
        different implementations may have good reason to take
        different approaches.  One common treatment is to define
        the aggregation as missing if any of the constituent
        elements are missing (useful to be most precise). Another
        is to treat the missing value as zero (useful to have
        continuous data streams).
     
        The specifications of aggregation functions are out of
        scope of the EMAN framework, but must be clearly specified
        by the equipment vendor.
     
     
7. Relationship to Other Standards

     
        This Energy Management framework uses, as much as possible,
        existing standards especially with respect to information
        modeling and data modeling [RFC3444].
     
        The data model for power- and energy-related objects is
        based on [IEC61850].
     
        Specific examples include:
           o  The scaling factor, which represents Energy Object
              usage magnitude, conforms to the [IEC61850]
              definition of unit multiplier for the SI (System
              International) units of measure.
           o  The electrical characteristic is based on the ANSI
              and IEC Standards, which require that we use an
              accuracy class for power measurement.  ANSI and IEC
              define the following accuracy classes for power
              measurement:
           o  IEC 62053-22  60044-1 class 0.1, 0.2, 0.5, 1  3.
           o  ANSI C12.20 class 0.2, 0.5
           o  The electrical characteristics and quality adhere
              closely to the [IEC61850-7-2] standard for describing
              AC measurements.
           o  The power state definitions are based on the DMTF
              Power State Profile and ACPI models, with operational
              state extensions.
     
     
8. Security Considerations

     
        Regarding the data attributes specified here, some or all
        may be considered sensitive or vulnerable in some network
        environments. Reading or writing these attributes without
        proper protection such as encryption or access
        authorization may have negative effects on the network
        capabilities.
     
     
     
     Claise et al.           Expires March 23, 2014      [Page 40]
     

      

     Internet-Draft              EMAN Framework      September 2013
     
     
8.1. Security Considerations for SNMP

     
        Readable objects in MIB modules (i.e., objects with a MAX-
        ACCESS other than not-accessible) may be considered
        sensitive or vulnerable in some network environments.  It
        is important to control GET and/or NOTIFY access to these
        objects and possibly to encrypt the values of these objects
        when sending them over the network via SNMP.
     
        The support for SET operations in a non-secure environment
        without proper protection can have a negative effect on
        network operations.
     
        For example:
           o  Unauthorized changes to the Energy Management Domain
              or business context of a device may result in
              misreporting or interruption of power.
           o  Unauthorized changes to a power state may disrupt the
              power settings of the different devices, and
              therefore the state of functionality of the
              respective devices.
           o  Unauthorized changes to the demand history may
              disrupt proper accounting of energy usage.
     
        With respect to data transport, SNMP versions prior to
        SNMPv3 did not include adequate security.  Even if the
        network itself is secure (for example, by using IPsec),
        there is still no secure control over who on the secure
        network is allowed to access and GET/SET
        (read/change/create/delete) the objects in these MIB
        modules.
     
        It is recommended that implementers consider the security
        features as provided by the SNMPv3 framework (see
        [RFC3410], section 8), including full support for the
        SNMPv3 cryptographic mechanisms (for authentication and
        privacy).
        Further, deployment of SNMP versions prior to SNMPv3 is not
        recommended.  Instead, it is recommended to deploy SNMPv3
        and to enable cryptographic security.  It is then a
        customer/operator responsibility to ensure that the SNMP
        entity giving access to an instance of these MIB modules is
        properly configured to give access to the objects only to
        those principals (users) that have legitimate rights to GET
        or SET (change/create/delete) them.
     
     
     
     
     
     
     Claise et al.           Expires March 23, 2014      [Page 41]
     

      

     Internet-Draft              EMAN Framework      September 2013
     
     
9. IANA Considerations

     
9.1. IANA Registration of new Power State Sets

     
        This document specifies an initial set of Power State Sets.
        The list of these Power State Sets with their numeric
        identifiers is given is Section 4. IANA maintains the lists
        of Power State Sets.
     
        New assignments for Power State Set are administered by
        IANA through 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 state for
        completeness and accuracy of the description. A pure vendor
        specific implementation of Power State Set shall not be
        adopted; since it would lead to proliferation of Power
        State Sets.
     
        Power states in a Power State Set are limited to 255
        distinct values. New Power State Set must be assigned the
        next available numeric identifier that is a multiple of
        256.
     
     
9.1.1. IANA Registration of the IEEE1621 Power State Set

     
        This document specifies a set of values for the IEEE1621
        Power State Set [IEEE1621].  The list of these values with
        their identifiers is given in Section 4.6.2.  IANA created
        a new registry for IEEE1621 Power State Set identifiers and
        filled it with the initial list of identifiers.
     
        New assignments (or potentially deprecation) for the
        IEEE1621 Power State Set is administered by IANA through
        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 state for completeness and
        accuracy of the description.
     
     
9.1.2. IANA Registration of the DMTF Power State Set

     
        This document specifies a set of values for the DMTF Power
        State Set.  The list of these values with their identifiers
        is given in Section 4. IANA has created a new registry for
        DMTF Power State Set identifiers and filled it with the
        initial list of identifiers.
     
        New assignments (or potentially deprecation) for the DMTF
        Power State Set is administered by IANA through Expert
        Review [RFC5226], i.e., review by one of a group of experts
        designated by an IETF Area Director.  The group of experts
     
     
     Claise et al.           Expires March 23, 2014      [Page 42]
     

      

     Internet-Draft              EMAN Framework      September 2013
     
        must check the conformance with the DMTF standard [DMTF],
        on the top of checking for completeness and accuracy of the
        description.
     
     
9.1.3. IANA Registration of the EMAN Power State Set

     
        This document specifies a set of values for the EMAN Power
        State Set.  The list of these values with their identifiers
        is given in Section 4.6.4.  IANA has created a new registry
        for EMAN Power State Set identifiers and filled it with the
        initial list of identifiers.
     
        New assignments (or potentially deprecation) for the EMAN
        Power State Set is administered by IANA through 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 state for completeness and
        accuracy of the description.
     
     
9.1.4. Batteries Power State Set

     
        Batteries have operational and administrational states that
        could be represented as a power state set. Since the work
        for battery management is parallel to this document, we are
        not proposing any Power State Sets for batteries at this
        time.
     
     
9.2. Updating the Registration of Existing Power State Sets

     
        With the evolution of standards, over time, it may be
        important to deprecate some of the existing the Power State
        Sets, or to add or deprecate some Power States within a
        Power State Set.
     
        The registrant shall publish an Internet-draft or an
        individual submission with the clear specification on
        deprecation of Power State Sets or Power States registered
        with IANA.  The deprecation or addition shall be
        administered by IANA through Expert Review [RFC5226], i.e.,
        review by one of a group of experts designated by an IETF
        Area Director. The process should also allow for a
        mechanism for cases where others have significant
        objections to claims on deprecation of a registration.
     
     
10. References

     
     Normative References
     
     
     
     
     Claise et al.           Expires March 23, 2014      [Page 43]
     

      

     Internet-Draft              EMAN Framework      September 2013
     
        [RFC2119]  Bradner, S., "Key words for use in RFCs to
                  Indicate Requirement Levels", BCP 14, RFC 2119,
                  March 1997
     
        [RFC3410]  Case, J., Mundy, R., Partain, D., and B.
                  Stewart, "Introduction and Applicability
                  Statements for Internet Standard Management
                  Framework ", RFC 3410, December 2002
     
        [RFC4122] Leach, P., Mealling, M., and R. Salz," A
                  Universally Unique Identifier (UUID) URN
                  Namespace", RFC 4122, July 2005
     
        [RFC5226] Narten, T., and H. Alvestrand, "Guidelines for
                  Writing an IANA Considerations Section in RFCs",
                  RFC 5226, May 2008
     
        [RFC6933]  Bierman, A. and K. McCloghrie, "Entity MIB
                  (Version4)", RFC 6933, May 2013
     
        [RFC3444] Pras, A., Schoenwaelder, J. "On the Differences
                  between Information Models and Data Models", RFC
                  3444, January 2003
     
        [ISO-IEC-19501-2005] ISO/IEC 19501:2005, Information
                  technology, Open Distributed Processing --
                  Unified Modeling Language (UML), January 2005
     
     Informative References
     
        [RFC2578] McCloghrie, K., Perkins, D., and J.
                  Schoenwaelder, "Structure of Management
                  Information Version 2 (SMIv2", RFC 2578, April
                  1999
     
     
        [RFC5101bis] Claise, B., Ed., and Trammel, T., Ed.,
                  "Specification of the IP Flow Information Export
                  (IPFIX) Protocol for the Exchange of IP Traffic
                  Flow Information ", draft-ietf-ipfix-protocol-
                  rfc5101bis-08, (work in progress), June 2013
     
        [RFC6020] M. Bjorklund, Ed., " YANG - A Data Modeling
                  Language for the Network Configuration Protocol
                  (NETCONF)", RFC 6020, October 2010
     
        [ACPI] "Advanced Configuration and Power Interface
                  Specification", http://www.acpi.info/spec30b.htm
     
     
     
     Claise et al.           Expires March 23, 2014      [Page 44]
     

      

     Internet-Draft              EMAN Framework      September 2013
     
        [IEEE1621]  "Standard for User Interface Elements in Power
                  Control of Electronic Devices Employed in
                  Office/Consumer Environments", IEEE 1621,
                  December 2004
     
        [LLDP]  IEEE Std 802.1AB, "Station and Media Control
                  Connectivity Discovery", 2005
     
        [LLDP-MED-MIB]  ANSI/TIA-1057, "The LLDP Management
                  Information Base extension module for TIA-TR41.4
                  media endpoint discovery information", July 2005
     
        [EMAN-REQ] Quittek, J., Winter, R., Dietz, T., Claise, B.,
                  and M. Chandramouli, "Requirements for Energy
                  Management", draft-ietf-eman-requirements-14,
                  (work in progress), May 2013
     
        [EMAN-OBJECT-MIB] Parello, J., and B. Claise, "Energy
                  Object Contet MIB", draft-ietf-eman-energy-aware-
                  mib-08, (work in progress), April 2013
     
        [EMAN-MON-MIB] Chandramouli, M.,Schoening, B., Quittek, J.,
                  Dietz, T., and B. Claise, "Power and Energy
                  Monitoring MIB", draft-ietf-eman-energy-
                  monitoring-mib-05, (work in progress), April 2013
     
        [EMAN-BATTERY-MIB] Quittek, J., Winter, R., and T. Dietz, "
                  Definition of Managed Objects for Battery
                  Monitoring", draft-ietf-eman-battery-mib-08,
                  (work in progress), February 2013
     
        [EMAN-AS] Schoening, B., Chandramouli, M., and B. Nordman,
                  "Energy Management (EMAN) Applicability
                  Statement", draft-ietf-eman-applicability-
                  statement-03, (work in progress), April 2013
     
        [ITU-T-M-3400] TMN recommandation on Management Functions
                  (M.3400), 1997
     
        [NMF] "Network Management Fundamentals", Alexander Clemm,
                  ISBN: 1-58720-137-2, 2007
     
        [TMN] "TMN Management Functions : Performance Management",
                  ITU-T M.3400
     
        [IEEE100] "The Authoritative Dictionary of IEEE Standards
                  Terms"
                  http://ieeexplore.ieee.org/xpl/mostRecentIssue.js
                  p?punumber=4116785
     
     
     Claise et al.           Expires March 23, 2014      [Page 45]
     

      

     Internet-Draft              EMAN Framework      September 2013
     
     
        [ISO50001] "ISO 50001:2011 Energy management systems -
                  Requirements with guidance for use",
                  http://www.iso.org/
     
        [IEC60050] International Electrotechnical Vocabulary
                  http://www.electropedia.org/iev/iev.nsf/welcome?o
                  penform
     
        [IEC61850] Power Utility Automation,
                  http://www.iec.ch/smartgrid/standards/
     
        [IEC61850-7-2] Abstract communication service interface
                  (ACSI), http://www.iec.ch/smartgrid/standards/
     
        [IEEE-802.3at] IEEE 802.3 Working Group, "IEEE Std 802.3at-
                  2009 - IEEE Standard for Information technology -
                  Telecommunications and information exchange
                  between systems - Local and metropolitan area
                  networks - Specific requirements - Part 3:
                  Carrier Sense Multiple Access with Collision
                  Detection (CSMA/CD) Access Method and Physical
                  Layer Specifications - Amendment: Data Terminal
                  Equipment (DTE) -  Power via Media Dependent
                  Interface (MDI) Enhancements", October 2009
     
        [DMTF] "Power State Management Profile DMTF  DSP1027
                  Version 2.0"  December 2009
                  http://www.dmtf.org/sites/default/files/standards
                  /documents/DSP1027_2.0.0.pdf
     
        [IPENERGY] R. Aldrich, J. Parello "IP-Enabled Energy
                  Management", 2010, Wiley Publishing
     
        [X.700]  CCITT Recommendation X.700 (1992), Management
                  framework for Open Systems Interconnection (OSI)
                  for CCITT applications
     
        [ASHRAE-201] "ASHRAE Standard Project Committee 201
                        (SPC 201)Facility Smart Grid Information
                        Model", http://spc201.ashraepcs.org
     
        [CHEN] "The Entity-Relationship Model: Toward a Unified
                  View of Data",  Peter Pin-shan Chen, ACM
                  Transactions on Database Systems, 1976
     
     
     
     
     
     
     Claise et al.           Expires March 23, 2014      [Page 46]
     

      

     Internet-Draft              EMAN Framework      September 2013
     
        [CISCO-EW] "Cisco EnergyWise Design Guide",  John Parello,
                  Roland Saville, Steve Kramling, Cisco Validated
                  Designs, September 2010,
                  http://www.cisco.com/en/US/docs/solutions/Enterpr
                  ise/Borderless_Networks/Energy_Management/energyw
                  isedg.html
     
     
     
     
11. Acknowledgments

     
        The authors would like to Michael Brown for his editorial
        work improving the text dramatically. Thanks to Rolf Winter
        for his feedback and to Bill Mielke for feedback and very
        detailed review. Thanks to Bruce Nordman for brainstorming
        with numerous conference calls and discussions. Finally,
        the authors would like to thank the EMAN chairs: Nevil
        Brownlee, Bruce Nordman, and Tom Nadeau.
     
        This document was prepared using 2-Word-v2.0.template.dot.
     
     Authors' Addresses
     
        John Parello
        Cisco Systems, Inc.
        3550 Cisco Way
        San Jose, California 95134
        US
     
        Phone: +1 408 525 2339
        Email: jparello@cisco.com
     
        Benoit Claise
        Cisco Systems, Inc.
        De Kleetlaan 6a b1
        Diegem 1813
        BE
     
        Phone: +32 2 704 5622
        Email: bclaise@cisco.com
     
     
        Brad Schoening
        44 Rivers Edge Drive
        Little Silver, NJ 07739
        US
     
        Phone:
        Email: brad.schoening@verizon.net
     
     
     Claise et al.           Expires March 23, 2014      [Page 47]
     

      

     Internet-Draft              EMAN Framework      September 2013
     
     
     
        Juergen Quittek
        NEC Europe Ltd.
        Network Laboratories
        Kurfuersten-Anlage 36
        69115 Heidelberg
        Germany
     
        Phone: +49 6221 90511 15
        EMail: quittek@netlab.nec.de
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     Claise et al.           Expires March 23, 2014      [Page 48]
     


    

    

  


--------------070306010905080804080002--

From n.brownlee@auckland.ac.nz  Thu Oct  3 14:14:27 2013
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 D296621E80C0 for ; Thu,  3 Oct 2013 14:14:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ukiZxI9RICWs for ; Thu,  3 Oct 2013 14:14:16 -0700 (PDT)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id 7D36321F9425 for ; Thu,  3 Oct 2013 14:02:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1380834177; x=1412370177; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=gsX1ETep5WNpBeh+6N+v5H6rcjwgh1WSpKKP4hcXVlc=; b=W8ss/kHOr1RpzS/qJVEvpinNTEuFCWy1+oaIT6EdbWE8dStpRBxkOzwI JDawfgzkuf7EOiPv/qwu6+OttfLQ+vdgepykplAFA4Y2Iyq5uARYJWavy HzsOspWpg0pTEPc4YKc7LkRtf53E2hJFWs9vluEdQQeTjrHe5TVRO9izv 8=;
X-IronPort-AV: E=Sophos;i="4.90,1028,1371038400"; d="scan'208";a="215779982"
X-Ironport-HAT: UNIVERSITY - $RELAY-THROTTLE
X-Ironport-Source: 130.216.38.131 - Outgoing - Outgoing-SSL
Received: from nevil-laptop1.sfac.auckland.ac.nz (HELO [130.216.38.131]) ([130.216.38.131]) by mx2-int.auckland.ac.nz with ESMTP; 04 Oct 2013 10:02:55 +1300
Message-ID: <524DDB7E.1030105@auckland.ac.nz>
Date: Fri, 04 Oct 2013 10:02:54 +1300
From: Nevil Brownlee 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Bruce Nordman 
References:  
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: eman mailing list , Ted Ghose 
Subject: Re: [eman] Way forward for EMAN Framework
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, 03 Oct 2013 21:14:27 -0000

Hi Bruce:

It's good to see some useful feedback from the Framework draft's
WGLC, especially feedback that includes suggestions for improved
text.

However, the notion of "starting again" is unhelpful.  Let me remind
you of what the EMAN WG's charter says about the framework:

   2. Energy management framework.
   The EMAN WG will create a framework document that will describe
   extensions to current management framework, required for energy
   management. This includes: power and energy monitoring, power states,
   power state control, and potential power state transitions. The
   framework will focus on energy management for IP-based network
   equipment (routers, switches, PCs, IP cameras, phones and the like).
   Particularly, the relationships between reporting devices, remote
   devices, and monitoring probes (such as might be used in low-power and
   lossy networks) need to be elaborated. For the case of a device
   reporting on behalf of other devices and controlling those devices,
   the framework will address the issues of discovery and identification
   of remote devices.

That is, the WG focus is on extending Network Management to work
effectively for network devices - and that's what the current draft,
after three years of work, adresses.

Cheers, Nevil (EMAN co-chair)


On 3/10/13 1:18 PM, Ted Ghose wrote:
> Why not fix the existing one rather starting a discussion on a new draft? Something I missed?
>
> Thanks
>
> -tg-
> Sent from my iPhone
>
> On Oct 2, 2013, at 3:15 PM, Bruce Nordman > wrote:
>
> As my previous email noted, and as per Juergen Quittek's recent review
>    http://www.ietf.org/mail-archive/web/eman/current/msg02007.html
> there are still many many outstanding problems with the
> current Framework draft.  This draft has been out for consideration
> and evolving for over three years, so having so many outstanding
> problems is troubling.  The the pace of improvement over these
> years has been quite slow.  It seems unlikely that continuing on
> the process of trying to fix this document will lead to it being
> suitable as an RFC in a reasonable timeframe.  It would be better
> to produce no result than to produce a substandard one.
>
> That said, there are alternatives.  One good one is to use the
> "Energy Reporting (ER) Framework" -- draft-nordman-eman-er-framework-01
> -- as the basis for the framework work item from EMAN.  A key next
> step is for that draft to receive critical review by EMAN participants
> to directly compare it to the current EMAN Framework draft.  This
> would productively move EMAN forward.
>
> My assessment of the two is that the ER Framework:
> * Is simpler to read and understand - for a variety of audiences
> * Will be simpler to implement (for end devices and management systems)
> * Lacks many ambiguities present in the EMAN Framework
> * More fully and directly implements the EMAN Requirements
> * Has features and capabilities not in the EMAN Framework
> These all make it more suitable as an RFC and more likely to be
> successful as a standard.
>
> EMAN is not the only organization considering energy management
> data models and so to be successful will need to be clearly superior
> to alternatives.
>
> I look forward to more detailed and productive discussion on the list.
> Thank you,
>
> --Bruce
>
>
> --
> Bruce Nordman
> Lawrence Berkeley National Laboratory
> nordman.lbl.gov
> BNordman@LBL.gov
> 510-486-7089
> m: 510-501-7943
> _______________________________________________
> eman mailing list
> eman@ietf.org
> https://www.ietf.org/mailman/listinfo/eman
>
>
>
> _______________________________________________
> eman mailing list
> eman@ietf.org
> https://www.ietf.org/mailman/listinfo/eman
>


-- 
---------------------------------------------------------------------
  Nevil Brownlee                          Computer Science Department
  Phone: +64 9 373 7599 x88941             The University of Auckland
  FAX: +64 9 373 7453   Private Bag 92019, Auckland 1142, New Zealand

From bclaise@cisco.com  Sun Oct  6 10:15:58 2013
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 42E4011E811B for ; Sun,  6 Oct 2013 10:15:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.537
X-Spam-Level: 
X-Spam-Status: No, score=-10.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QaOO1hBHH95p for ; Sun,  6 Oct 2013 10:15:53 -0700 (PDT)
Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 6BBD211E8118 for ; Sun,  6 Oct 2013 10:15:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5552; q=dns/txt; s=iport; t=1381079752; x=1382289352; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=rPsOr603T3te2lK3Nemi3oViak0dsM/PDLy5C2ga31I=; b=SHWBGSLXZGc77bAkVpRUsy1jqH3XPHJjSy92obNL6pV5cmBB56Wg6nbn Ots0yGIzidT/0rm7duLZGexFt3cXPTzEekw/YhaczpDIS+z2InGpWj2iL kJwT1g30Wz6BwbUo15N1n0tGzBmNU5eOAW4rY8q++tKxm/iuheB2jxjSR I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhQFAOqZUVKQ/khL/2dsb2JhbABZgwc4wWqBExZ0giUBAQEDAQEBARobNgoBDAICCxEEAQEKFggHCQMCAQIBCQwfCQgGDQEFAgEBh3wGDLpSBASNfgYKB4E4BwaEHQOUJINdhjaLSoMmOoEsCRc
X-IronPort-AV: E=Sophos;i="4.90,1045,1371081600"; d="scan'208";a="18570299"
Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-4.cisco.com with ESMTP; 06 Oct 2013 17:15:51 +0000
Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r96HFkTZ026826; Sun, 6 Oct 2013 17:15:47 GMT
Message-ID: <52519AC5.4040700@cisco.com>
Date: Sun, 06 Oct 2013 19:15:49 +0200
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Juergen Quittek 
References: <9AB93E4127C26F4BA7829DEFDCE5A6E85A41C6F0@DAPHNIS.office.hd>
In-Reply-To: <9AB93E4127C26F4BA7829DEFDCE5A6E85A41C6F0@DAPHNIS.office.hd>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "eman@ietf.org" , "ops-ads@tools.ietf.org" 
Subject: Re: [eman] WG Last Call for EMAN Framework -09
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 06 Oct 2013 17:15:58 -0000

Hi Juergen,

Thanks for your feedback.
Let me address the specific comments. I'll come back to the general 
comments in a different email.
Actually, I removed the vast majority of comments, with which I agree.
>       
>
> Specific comments:
>   
>
>
> 19. Section 4.1 "Conceptual Model"
> I am missing here a lot of information on the model.
> 19.1. Is the model normative or informational?
> 19.2. Is it a model to be implemented inside the EnMS only or as well on the Energy Objects?
> 19.3. If it is implemented at the Energy Objects, why storing context information? This typically resides in the management system only.
> 19.4. If it is implemented on Energy Objects, how does it specify which information is included for a device, and which (more limited) information is included for a component or power interface?
> 19.5. The model is lacking information on batteries.
Fine with the batteries.
As an battery-mib draft author, would you mind providing some text.
> 29. Section 4.2.1, 3rd paragraph:
> OLD
>          A Device Class instance may represent a physical device
>          that contains other components.
> NEW
>          A Device Class instance may represent a physical device
>          that contains other components.
?
>
> 35. Section 4.4.4, last sentence: "Demand measurements can be provided when the Energy Object is capable of measuring actual power."
> This is wrong. Either delete this sentence (preferred) or use this one instead: "Demand measurements can only be provided when the Energy Object is capable of measuring demand."
Can't we compute the demand by measuring the actual power on low intervals.
> 38. section 4.5.1 "Power State Sets"
> Why is the ACPI power state set excluded from the list of existing sets?
> ACPI power states should have their own subsection as IEEE1621 and DMTF have.
Can't check right now, but I don't think the ACPI were ever a Power 
State Set in the set of EMAN documents.
>   
> 39. Section 4.5.4. "Power State Set: IETF EMAN"
> Shouldn't we call this rather "Power State Set: Cisco EnergyWise"?
It's like Cisco NetFlow and IPFIX.
When provided the spec for IPFIX, there was no point to remind people 
that it was Cisco NetFlow.
>
> 40. Section 4.5.4, first sentence:
> "An EMAN Power State Set represents an attempt at a standard approach for modeling the different levels of power of a device." The same holds for every other power state set, particularly for the ones mentioned in the subsections above. I suggest removing this sentence.
I could either way, but the idea was to say: the other Power State Set 
were defined somewhere else.
This one is a specific attempt at the IETF.
>
> 41. Section 4.5.4.
> I am fine with the non-operational power states that also other ACPI and DMTF support similarly, but I have problems with the operational states (7-12). They are defined only relatively to each other stating that one with a lower number "provides less usage" than a higher number.
I understand that there are challenges in defining them, but I think 
there is some value in trying to standardize them.
> 41.1: Is "providing usage" proper terminology?
> 41.2: What is meant with "provide less usage"? Does it mean that usage numbers are ALWAYS lower than in a higher state? Even if measured in short time intervals? Such a behavior would hardly be implementable on many devices.
> 41.3: In the real world, power states have ranges of power values that they cover and some have wider ranges than others. This can hardly be modeled by a power state set that only knows a strict consecutive order of power states and power values.

>
>
> 43. Section 5 "Energy Management Information Model"
> The text states that this model is a "reference for implementers". Obviously, the model is useful for management system implementers. What is not discussed is how to use it for implementations of EMAN on devices, components and interfaces. The model does not give guidance for these. Among the missing information for these cases is what needs to be implemented on different classes of devices.
Replying on the last point only, I believe it's the goal of the 
applicability statement draft.

Regards, Benoit
>
> Cheers,
>      Juergen
>
>> -----Original Message-----
>> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of
>> Nevil Brownlee
>> Sent: Dienstag, 10. September 2013 23:28
>> To: eman@ietf.org
>> Cc: ops-ads@tools.ietf.org
>> Subject: [eman] WG Last Call for EMAN Framework -09
>>
>>
>> Hi all:
>>
>> A new revision of the EMAN Framework draft was published yesterday.
>> Version -09 has many changes, improvements and clarifications since the -08
>> version (published just before IETF-87 in Berlin).
>>
>> The WG Last Call for it starts now, and will end on Friday, 27 September.
>>
>> Please read it now, and send your comments/suggestions/etc to the EMAN list.
>> Comments like "seems fine now" are good, as are suggestions for further
>> improvement (accompanied by OLD/NEW text).
>>
>> Cheers, Nevil
>>
>> --
>> ---------------------------------------------------------------------
>>    Nevil Brownlee                          Computer Science Department
>>    Phone: +64 9 373 7599 x88941             The University of Auckland
>>    FAX: +64 9 373 7453   Private Bag 92019, Auckland 1142, New Zealand
>> _______________________________________________
>> eman mailing list
>> eman@ietf.org
>> https://www.ietf.org/mailman/listinfo/eman
> .
>


From tnadeau@lucidvision.com  Mon Oct  7 04:19:57 2013
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 48CF021E80FD for ; Mon,  7 Oct 2013 04:19:57 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XPCcSY7JLqpQ for ; Mon,  7 Oct 2013 04:19:52 -0700 (PDT)
Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 09ADF21F9E73 for ; Mon,  7 Oct 2013 04:19:51 -0700 (PDT)
Received: from [192.168.1.113] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 1726A2599317 for ; Mon,  7 Oct 2013 07:19:51 -0400 (EDT)
From: Thomas Nadeau 
Content-Type: multipart/signed; boundary="Apple-Mail=_7F619131-FB6A-46AF-A493-36C062A40D6E"; protocol="application/pgp-signature"; micalg=pgp-sha512
Date: Mon, 7 Oct 2013 07:19:50 -0400
References: <52527773.9020400@cisco.com>
To: "eman@ietf.org" 
Message-Id: 
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
X-Mailer: Apple Mail (2.1510)
Subject: [eman] NOMCOM 2013 - Second Call for Nominations - two weeks left
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, 07 Oct 2013 11:19:57 -0000

--Apple-Mail=_7F619131-FB6A-46AF-A493-36C062A40D6E
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_A6C9942C-F5F0-4504-91E1-3E798F0AD305"


--Apple-Mail=_A6C9942C-F5F0-4504-91E1-3E798F0AD305
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii




>=20
> Subject:	NOMCOM 2013 - Second Call for Nominations - two weeks =
left
> Date:	Fri, 4 Oct 2013 10:31:49 -0700
> From:	NomCom Chair 2013 
> Reply-To:	, , =
, <"2013 
> To:	IETF Announcement List 
> CC:	IETF Discuss List 
>=20
> Nominations for the IESG, IAB, and IAOC are due to the Nomcom by =
Friday, 18 October, 2013.
>=20
> Is there someone you work with at IETF who has leadership potential =
and a growing track record? Please read the Nomcom call for nominations =
and consider nominating her or him. Or several folks! Deadline for =
nominations is October 18.  Nominate soon to give your nominee(s) plenty =
time to fill in the questionnaire. Information about the desired =
expertise for positions is here:=20
>            https://datatracker.ietf.org/nomcom/2013/expertise
>=20
> Lots more, including which positions are open, how to make a =
nomination, and how to=20
> send us your feedback on the desired expertise, follows.
>=20
> IETFers, let's hear from you!  Make nominations, accept nominations!
>=20
> If you have any questions about the process, feel free to get in touch =
with me.
>=20
> Best regards,
>=20
> Allison for the Nomcom
>=20
> Allison Mankin=20
> Nomcom Chair 2013-14
>=20
> ----- The Info You Need for Nominating -----
>=20
> The 2013-14 Nominating Committee (Nomcom) is seeking nominations
> from now until October 18, 2013. The open positions being considered
> by this year's Nomcom can be found later in this section, and also on
> this year's Nomcom website:=20
>=20
> https://datatracker.ietf.org/nomcom/2013/
>=20
> Nominations may be made by selecting the Nominate link at the top of
> the Nomcom 2013 home page, or by visiting the following URL:=20
>=20
> https://datatracker.ietf.org/nomcom/2013/nominate/
>=20
> Note that nominations made using the web tool require an ietf.org=20
> datatracker account. You can create a datatracker ietf.org account=20
> if you don't have one already by visiting the following URL:
>=20
> https://datatracker.ietf.org/accounts/create/
>=20
> Nominations may also be made by email to nomcom13 at ietf.org.
> If you nominate by email, please include the word "Nominate" in the =
Subject
> and indicate in the email who is being nominated, their email address =
(to
> confirm acceptance of the nomination), and the position for which you
> are making the nomination. If you use email, please use a separate =
email for
> each person you nominate, and for each position (if you are nominating =
one
> person for multiple positions).
>=20
> Self-nomination is welcome!  No need to be shy.
>=20
> Nomcom 2013-14 will follow the policy for "Open Disclosure of Willing
> Nominees" described in RFC 5680.  As stated in RFC 5680: "The list of
> nominees willing to be considered for positions under review in the
> current Nomcom cycle is not confidential". Willing nominees for each
> position will be listed in a publicly accessible way - anyone with a
> datatracker account may access the lists.  In all other ways, the=20
> confidentiality requirements of RFC 3777/BCP10 remain in effect.  All
> feedback and all Nomcom deliberations will remain confidential and =
will
> not be disclosed. =20
>=20
> In order to ensure time to collect sufficient community feedback about
> each of the willing nominees, nominations must be received by the=20
> Nomcom on or before October 18, 2013.  Please submit your nominations =20=

> as early as possible for the sake of your nominees, as we've set the=20=

> questionnaire submission deadline for October 25, 2013.
>=20
> The list of people and posts whose terms end with the March 2014 IETF =
meeting,=20
> and thus the positions for which we are accepting nominations: =20
>=20
> IAOC
> Chris Griffiths
>=20
> IAB
> Bernard Aboba
> Marc Blanchet
> Ross Callon
> Eliot Lear
> Hannes Tschofenig
>=20
> IESG
> Barry Leiba (Applications)
> Brian Haberman (Internet)
> Benoit Claise (Operations and Management)
> Gonzalo Camarillo (RAI)
> Stewart Bryant (Routing)
> Sean Turner (Security)
> Martin Stiemerling (Transport)
>=20
> Please be resourceful in identifying possible candidates for these
> positions, as developing our talent is a very crucial requirement for
> the IETF.  Also, please give serious consideration to accepting =
nominations
> you receive. =20
> =20
> The summaries of the desired expertise for the positions, developed by =
the=20
> respective bodies, are found at:
>=20
> https://datatracker.ietf.org/nomcom/2013/expertise/
>=20
> In addition to nominations, the Nomcom seeks community input on=20
> the positions themselves.  We need and welcome the community's=20
> views and input on the jobs within each organization. If you=20
> have ideas on the positions' responsibilities (more, less,=20
> different), please let us know.  You can send us email about this to
> nomcom13 at ietf.org, and we will use this feedback actively.
>=20
> Thank you for your help in nominating a great pool of strong and =
interesting
> nominees!
>=20
>=20
>=20
> .
>=20
>=20
>=20


--Apple-Mail=_A6C9942C-F5F0-4504-91E1-3E798F0AD305
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
	charset=us-ascii





        
          

            Subject:
            
            NOMCOM 2013 - Second Call for Nominations - two weeks
              left
          

          

            Date: 
            Fri, 4 Oct 2013 10:31:49 -0700
          

          

            From: 
            NomCom Chair 2013 <nomcom-chair-2013@ietf.org>
          

          

            Reply-To:
            
            <ietf@ietf.org>, <Nomcom@ietfa.amsl.com>,
              <Chair@ietfa.amsl.com>, <"2013
              <nomcom-chair-2013"@ietf.org>
          

          

            To: 
            IETF Announcement List <ietf-announce@ietf.org>
          

          

            CC: 
            IETF Discuss List <ietf@ietf.org>
          

        
      

      

      

      
Nominations for the IESG, IAB, and IAOC are due to the Nomcom by Friday, 18 October, 2013.

Is there someone you work with at IETF who has leadership potential and a growing track record? Please read the Nomcom call for nominations and consider nominating her or him. Or several folks! Deadline for nominations is October 18.  Nominate soon to give your nominee(s) plenty time to fill in the questionnaire. Information about the desired expertise for positions is here: 
           https://datatracker.ietf.org/nomcom/2013/expertise

Lots more, including which positions are open, how to make a nomination, and how to 
send us your feedback on the desired expertise, follows.

IETFers, let's hear from you!  Make nominations, accept nominations!

If you have any questions about the process, feel free to get in touch with me.

Best regards,

Allison for the Nomcom

Allison Mankin 
Nomcom Chair 2013-14

----- The Info You Need for Nominating -----

The 2013-14 Nominating Committee (Nomcom) is seeking nominations
from now until October 18, 2013. The open positions being considered
by this year's Nomcom can be found later in this section, and also on
this year's Nomcom website: 

https://datatracker.ietf.org/nomcom/2013/

Nominations may be made by selecting the Nominate link at the top of
the Nomcom 2013 home page, or by visiting the following URL: 

https://datatracker.ietf.org/nomcom/2013/nominate/

Note that nominations made using the web tool require an ietf.org 
datatracker account. You can create a datatracker ietf.org account 
if you don't have one already by visiting the following URL:

https://datatracker.ietf.org/accounts/create/

Nominations may also be made by email to nomcom13 at ietf.org.
If you nominate by email, please include the word "Nominate" in the Subject
and indicate in the email who is being nominated, their email address (to
confirm acceptance of the nomination), and the position for which you
are making the nomination. If you use email, please use a separate email for
each person you nominate, and for each position (if you are nominating one
person for multiple positions).

Self-nomination is welcome!  No need to be shy.

Nomcom 2013-14 will follow the policy for "Open Disclosure of Willing
Nominees" described in RFC 5680.  As stated in RFC 5680: "The list of
nominees willing to be considered for positions under review in the
current Nomcom cycle is not confidential". Willing nominees for each
position will be listed in a publicly accessible way - anyone with a
datatracker account may access the lists.  In all other ways, the 
confidentiality requirements of RFC 3777/BCP10 remain in effect.  All
feedback and all Nomcom deliberations will remain confidential and will
not be disclosed.  

In order to ensure time to collect sufficient community feedback about
each of the willing nominees, nominations must be received by the 
Nomcom on or before October 18, 2013.  Please submit your nominations  
as early as possible for the sake of your nominees, as we've set the 
questionnaire submission deadline for October 25, 2013.

The list of people and posts whose terms end with the March 2014 IETF meeting, 
and thus the positions for which we are accepting nominations:  

IAOC
Chris Griffiths

IAB
Bernard Aboba
Marc Blanchet
Ross Callon
Eliot Lear
Hannes Tschofenig

IESG
Barry Leiba (Applications)
Brian Haberman (Internet)
Benoit Claise (Operations and Management)
Gonzalo Camarillo (RAI)
Stewart Bryant (Routing)
Sean Turner (Security)
Martin Stiemerling (Transport)

Please be resourceful in identifying possible candidates for these
positions, as developing our talent is a very crucial requirement for
the IETF.  Also, please give serious consideration to accepting nominations
you receive.  
 
The summaries of the desired expertise for the positions, developed by the 
respective bodies, are found at:

https://datatracker.ietf.org/nomcom/2013/expertise/

In addition to nominations, the Nomcom seeks community input on 
the positions themselves.  We need and welcome the community's 
views and input on the jobs within each organization. If you 
have ideas on the positions' responsibilities (more, less, 
different), please let us know.  You can send us email about this to
nomcom13 at ietf.org, and we will use this feedback actively.

Thank you for your help in nominating a great pool of strong and interesting
nominees!



.



      

    

    

  





--Apple-Mail=_A6C9942C-F5F0-4504-91E1-3E798F0AD305--

--Apple-Mail=_7F619131-FB6A-46AF-A493-36C062A40D6E
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJSUpjWAAoJEPcO+I7eiUJZv9IP/1ODosT2MJLXu0XVreG0NjPL
lzYod5zRyjynYko6UN6jFmhUq9YMx0VeEhXRX/kFsNuHqtnKnoyfxtYAAZm620Ep
O92tiJmRJ+Nc+Bxg+M0hUmzuiHZA34T/eY2MCKmQ1yd7kykRjYl4fuuh6N9yt8va
6HfGAZoLOVib0yZYDrnNbdY6PT1qwLcr/57snkjfd2dSuYZbqDNniDmEFRZusE5L
W0lhFinaHCtmyhMqG1tnpoV+dCl7sC8FX+rCEQV1dVEYeWjaFXNnWkvRwfgKu6TC
gUWGzfThxOZhVAAwUGsIHbeqqEF/8TK/wrIyBywk3wcmmAt60pg0IfdUz6kSUAy3
Wfr8bhpcFrnLZ5KMZxA7BKW23t0QJTIXC7HH0u+RenCx8O6/e2D0TvCUkU0a1SLy
7DKyrroMa6Ks3iMGpe7Okj8DMyVXq7PpetvhSM4fCTaadfaEaGsT5y5kYLF5FqjU
sIjrHryc2kQbzfkpexjfcrorVfDolinojcC33Lq3Lz4DYF1vEcVM2AaL7pBMHORu
mZu0TFzKH5XaGG82Leu+fewO5zC1r131zWRMJTx/SQMQB44UucitKOIkELsGYZn4
RMFEyy2oy0ryNm9bFp1rc+Dbr1QhYUCA472DA5plcgrKHgnQ8lE6p9JYMvfpjhkv
eHgH7N4mDXXV1dlTBTEq
=KGnr
-----END PGP SIGNATURE-----

--Apple-Mail=_7F619131-FB6A-46AF-A493-36C062A40D6E--

From Rolf.Winter@neclab.eu  Tue Oct  8 01:44:57 2013
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 7052321E8180 for ; Tue,  8 Oct 2013 01:44:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.209
X-Spam-Level: 
X-Spam-Status: No, score=-102.209 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, PLING_QUERY=1.39, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VYF0WH4duHso for ; Tue,  8 Oct 2013 01:44:47 -0700 (PDT)
Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 6265221E8166 for ; Tue,  8 Oct 2013 01:44:46 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id D32A4105AE4; Tue,  8 Oct 2013 10:40:48 +0200 (CEST)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de)
Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DMzMxn1oxwr9; Tue,  8 Oct 2013 10:40:48 +0200 (CEST)
Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id B754B105A0A; Tue,  8 Oct 2013 10:40:28 +0200 (CEST)
Received: from DAPHNIS.office.hd ([169.254.2.213]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Tue, 8 Oct 2013 10:44:26 +0200
From: Rolf Winter 
To: Ted Ghose 
Thread-Topic: [eman] Power States != Charging States?
Thread-Index: Ac658agNBCTPrXG/QuKZUDsu7CoziP//5VmAgAgEsACAAYpKgIAAQNoA//7vG4CAAkR4gP/2x2Eg
Date: Tue, 8 Oct 2013 08:44:25 +0000
Message-ID: <791AD3077F94194BB2BDD13565B6295D55728E1B@DAPHNIS.office.hd>
References: <791AD3077F94194BB2BDD13565B6295D55726BC7@DAPHNIS.office.hd>  <5249A238.10500@cisco.com>	 , <791AD3077F94194BB2BDD13565B6295D55727F6E@DAPHNIS.office.hd> <4C227BE7-1FAE-4DC4-B5A8-2F0CB0D429F1@juniper.net>
In-Reply-To: <4C227BE7-1FAE-4DC4-B5A8-2F0CB0D429F1@juniper.net>
Accept-Language: en-US, de-DE
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.7.0.214]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "eman@ietf.org" 
Subject: Re: [eman] Power States != Charging States?
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, 08 Oct 2013 08:44:57 -0000

Hi,

I agree, but I think this should be done through actual measurements not th=
rough states.

Best,

Rolf=20

NEC Europe Ltd | Registered Office: Athene, Odyssey Business Park, West End=
  Road, London, HA4 6QE, GB | Registered in England 2832014


> -----Original Message-----
> From: Ted Ghose [mailto:tghose@juniper.net]
> Sent: Mittwoch, 2. Oktober 2013 15:54
> To: Rolf Winter
> Cc: Bruce Nordman; EXT - joelja@bogus.com; eman@ietf.org
> Subject: Re: [eman] Power States !=3D Charging States?
>=20
> We still need to know know the amount of power battery is receiving or
> giving to the system.
>=20
> How are we addressing that?
>=20
> I totally agree charging state has nothing to do with it
>=20
> -tg-
> Sent from my iPhone
>=20
> > On Oct 2, 2013, at 3:04 AM, "Rolf Winter" 
> wrote:
> >
> > Hi,
> >
> > So it seems there is a general agreement that power and charging
> states are different. But I am still not sure we need a separate power
> state. I think I read two different things so far.
> >
> > 1) introduce a state that shows if it is charging or discharging and
> > how much
> > 2) introduce state which merely indicates whether the battery can be
> > used (either charged or discharged or not)
> >
> > I thought 1 is already covered by the current battery MIB with
> charging states and the actual measurements of e.g. the actual current
> etc. The same I guess applied to devices which might have a couple of
> power states and then actual measurements to quantify energy use.
> >
> > I am not sure about 2 since I have a hard time making a connection
> with the definition of power state that we have:
> >
> > A Power State is a condition or mode of a device that broadly
> > characterizes its capabilities, power consumption, and responsiveness
> > to input.
> >
> > It is more like "availability for use" rather than an actual power
> state. That however is currently not covered by the MIB and we can
> think about whether we should introduce this.
> >
> > Best,
> >
> > Rolf
> >
> >
> >
> > NEC Europe Ltd | Registered Office: Athene, Odyssey Business Park,
> > West End  Road, London, HA4 6QE, GB | Registered in England 2832014
> >
> >
> >> -----Original Message-----
> >> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf
> >> Of Bruce Nordman
> >> Sent: Dienstag, 1. Oktober 2013 21:33
> >> To: joel jaeggli
> >> Cc: Ted Ghose; eman@ietf.org
> >> Subject: Re: [eman] Power States !=3D Charging States?
> >>
> >> I agree with Rolf that the battery charging state is a different
> >> concept from power state.
> >>
> >>
> >> The current charging state entries in the battery MIB document are:
> >>
> >> unknown, charging, fastCharging, maintainingCharge, noCharging, and
> >> discharging.
> >>
> >> It seems plausible to me that over time storage technologies will
> >> evolve so that
> >>
> >> more entries in this list will be desired.  The power state registry
> >> could then be used as a place to put such additional charging state
> >> sets, in which case it should be stated to cover both power and
> >> charging states.  Or, a second registry just for
> >>
> >> battery states could be created.  Or, states could be added by
> >> updating the battery MIB.
> >>
> >>
> >> Note that a battery can have data only as listed in the battery MIB,
> >> it can only have component data as an energy object, or both.  For
> >> the energy object aspect of batteries, there is a field for the
> >> battery component for power state.  This could be left empty, or
> >> used.  It occurs to me that a battery could be available/in-use,
> >> which I would consider to be On, or not electrically available (for
> >> charging or discharging), which I would consider to be Off (perhaps
> >> for being physically removed, or simply selected to be not available
> for use).
> >> IEEE 1621 covers this.
> >>
> >>
> >> Finally, I thought that the battery MIB draft had indications for
> >> battery failure.  This seems like something that could be reported
> on
> >> in either the charging state or
> >>
> >> power state context.
> >>
> >> --Bruce
> >>
> >>
> >>
> >> On Tue, Oct 1, 2013 at 8:40 AM, joel jaeggli 
> wrote:
> >>
> >>
> >>
> >>    On Sep 30, 2013, at 9:09 AM, Benoit Claise 
> >> wrote:
> >>
> >>    > Hi Ted,
> >>    >> Hi Rolf
> >>    >>
> >>    >> +1
> >>    >>
> >>    >> Thanks for clearly articulating the points. I totally agree
> the
> >> charging state should be orthogonal to power state.
> >>    >>
> >>    >> My position is that battery should _also_ have power state
> >> indicating if it is receiving power (charging) or giving power to
> the
> >> electrical network, and how much
> >>    > That makes sense.
> >>    >
> >>    > Regards, Benoit
> >>
> >>
> >>    In my limited experience with battery controllers batteries are
> >> either:
> >>
> >>    charging
> >>    discharging
> >>    full
> >>    empty
> >>
> >>    in all cases  state of charge, e.g. capacity is germain.
> >>
> >>
> >>    >>
> >>    >> This will be useful to account for all the power source and
> >> sink
> >>    >>
> >>    >> Best
> >>    >>
> >>    >> -tg-
> >>    >> Sent from my iPhone
> >>    >>
> >>    >>> On Sep 25, 2013, at 6:18 AM, Rolf Winter
> >>  wrote:
> >>    >>>
> >>    >>> Hi,
> >>    >>>
> >>    >>> this thread attempts to close an open issue in the framework
> >> document (v10) where section 9.1.4 reads:
> >>    >>>
> >>    >>> 9.1.4. Batteries Power State Set
> >>    >>>
> >>    >>>        Batteries have operational and administrational states
> >> that
> >>    >>>        could be represented as a power state set. Since the
> >> work
> >>    >>>        for battery management is parallel to this document,
> >> we are
> >>    >>>        not proposing any Power State Sets for batteries at
> >> this
> >>    >>>        time.
> >>    >>>
> >>    >>> I argue that batteries have no power states given the power
> >> state definition:
> >>    >>>
> >>    >>>        A Power State is a condition or mode of a device that
> >>    >>>        broadly characterizes its capabilities, power
> >>    >>>        consumption, and responsiveness to input.
> >>    >>>
> >>    >>> There are charging states currently defined in the battery
> >> MIB, which seem to be orthogonal to power states. I guess a
> universal
> >> power state set is "on" and "off". Any device can really be in one
> of
> >> these two modes. Even a simple light bulb. What would be "on" for a
> >> battery? Maybe charging because it receives energy (like any other
> >> device that is actually "on")? But every device that is on, fulfills
> >> its primary function. I would argue that the primary function of a
> >> battery is to provide energy. Batteries are different and I maybe we
> >> should ack this fact and not try to create battery power state sets
> >> just because we have this for devices.
> >>    >>>
> >>    >>> I think the Email thread http://www.ietf.org/mail-
> >> archive/web/eman/current/msg02000.html seemed to agree that charging
> >> states and power states are orthogonal. If they are, why should they
> >> be of the same class? The problem is that the power state above as
> >> used for devices would suggest that if a device is off, it does not
> >> consume any energy. But if the battery is charging, then it does
> >> (given that the battery is modeled as part of the device). So if a
> >> power state is indeed conflating power consumption and capabilities,
> >> then a device would be in two different power states at the same
> time. But it is not.
> >> It is in one power state and the batteries in it are in a certain
> >> charging state and each of these can be freely combined. I.e.
> >> charging/on, discharging/on, charging/off etc... I guess the main
> >> question is, what is the advantage of defining a charging state as a
> >> power state (the set of charging states as a power state set)?
> >>    >>>
> >>    >>>
> >>    >>> Best,
> >>    >>>
> >>    >>> Rolf
> >>    >>>
> >>    >>> NEC Europe Ltd | Registered Office: Athene, Odyssey Business
> >> Park, West End  Road, London, HA4 6QE, GB | Registered in England
> >> 2832014
> >>    >>>
> >>    >>>
> >>    >>> _______________________________________________
> >>    >>> eman mailing list
> >>    >>> eman@ietf.org
> >>    >>> https://www.ietf.org/mailman/listinfo/eman
> >>    >> _______________________________________________
> >>    >> eman mailing list
> >>    >> eman@ietf.org
> >>    >> https://www.ietf.org/mailman/listinfo/eman
> >>    >> .
> >>    >>
> >>    >
> >>    >
> >>    > _______________________________________________
> >>    > eman mailing list
> >>    > eman@ietf.org
> >>    > https://www.ietf.org/mailman/listinfo/eman
> >>    >
> >>
> >>
> >>
> >>    _______________________________________________
> >>    eman mailing list
> >>    eman@ietf.org
> >>    https://www.ietf.org/mailman/listinfo/eman
> >>
> >>
> >>
> >>
> >>
> >>
> >> --
> >> Bruce Nordman
> >> Lawrence Berkeley National Laboratory nordman.lbl.gov
> >> BNordman@LBL.gov
> >> 510-486-7089
> >> m: 510-501-7943
> >
> >
> >


From Rolf.Winter@neclab.eu  Tue Oct  8 09:29:28 2013
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 5921421E80B6 for ; Tue,  8 Oct 2013 09:29:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.909
X-Spam-Level: 
X-Spam-Status: No, score=-101.909 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, PLING_QUERY=1.39, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JZus1+lhF-9a for ; Tue,  8 Oct 2013 09:29:24 -0700 (PDT)
Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id CAC1121E8236 for ; Tue,  8 Oct 2013 09:29:21 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 6654F105A7A; Tue,  8 Oct 2013 18:25:21 +0200 (CEST)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de)
Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ydptDij0can9; Tue,  8 Oct 2013 18:25:21 +0200 (CEST)
Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 3B699105B31; Tue,  8 Oct 2013 18:25:06 +0200 (CEST)
Received: from DAPHNIS.office.hd ([169.254.2.213]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Tue, 8 Oct 2013 18:29:04 +0200
From: Rolf Winter 
To: "John Parello (jparello)" , Ted Ghose 
Thread-Topic: [eman] Power States != Charging States?
Thread-Index: Ac658agNBCTPrXG/QuKZUDsu7CoziP//5VmAgAgEsACAAYpKgIAAQNoA//7vG4CAAkR4gIAACDWA//bNg7A=
Date: Tue, 8 Oct 2013 16:29:04 +0000
Message-ID: <791AD3077F94194BB2BDD13565B6295D55729320@DAPHNIS.office.hd>
References: <791AD3077F94194BB2BDD13565B6295D55726BC7@DAPHNIS.office.hd>  <5249A238.10500@cisco.com>	 , <791AD3077F94194BB2BDD13565B6295D55727F6E@DAPHNIS.office.hd>, <4C227BE7-1FAE-4DC4-B5A8-2F0CB0D429F1@juniper.net> 
In-Reply-To: 
Accept-Language: en-US, de-DE
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.7.0.214]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "eman@ietf.org" 
Subject: Re: [eman] Power States != Charging States?
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, 08 Oct 2013 16:29:28 -0000

Hi John,

when you snip text out of a definition I think you can make anything fit th=
at defintion. But you snipped important things like the "consumption" bit a=
fter "power" or "responsiveness to input".=20

Best,

Rolf

NEC Europe Ltd | Registered Office: Athene, Odyssey Business Park, West End=
  Road, London, HA4 6QE, GB | Registered in England 2832014


> -----Original Message-----
> From: John Parello (jparello) [mailto:jparello@cisco.com]
> Sent: Mittwoch, 2. Oktober 2013 16:23
> To: Ted Ghose
> Cc: Rolf Winter; eman@ietf.org
> Subject: Re: [eman] Power States !=3D Charging States?
>=20
> So I'm seeing we all agree charing states are orthogonal to the current
> power states.
> That it's reasonable to expect a battery modeled by an Energy Object to
> implement power states to show what it is receiving or giving to the
> system.
>=20
> +1 On Bruce's comment in it;s entirety also that we could include the
> battery states in power states at some later date.
>=20
> Rolf I'm not sure I see that the definition of power states does not
> cover states of a battery. "A condition or mode that broadly
> characterize..power..." does seem to cover if a battery is receving
> energy and storing it? Anyone else see this is ok or not?
>=20
> I did bring up that we call these power states when "energy states" and
> "energy interfaces" is more accurate. Would that be more comfortable to
> you. ETSI is using Energy States in their liaison with us is the GAL.
>=20
> I will update 9.1.4 according to this thread an lets see how that rolls.
>=20
> Jp
>=20
> Sent from my iPad
> (expect ridiculous spelling mistakes)
>=20
> On Oct 2, 2013, at 6:56 AM, "Ted Ghose"  wrote:
>=20
> > We still need to know know the amount of power battery is receiving
> or giving to the system.
> >
> > How are we addressing that?
> >
> > I totally agree charging state has nothing to do with it
> >
> > -tg-
> > Sent from my iPhone
> >
> >> On Oct 2, 2013, at 3:04 AM, "Rolf Winter" 
> wrote:
> >>
> >> Hi,
> >>
> >> So it seems there is a general agreement that power and charging
> states are different. But I am still not sure we need a separate power
> state. I think I read two different things so far.
> >>
> >> 1) introduce a state that shows if it is charging or discharging and
> >> how much
> >> 2) introduce state which merely indicates whether the battery can be
> >> used (either charged or discharged or not)
> >>
> >> I thought 1 is already covered by the current battery MIB with
> charging states and the actual measurements of e.g. the actual current
> etc. The same I guess applied to devices which might have a couple of
> power states and then actual measurements to quantify energy use.
> >>
> >> I am not sure about 2 since I have a hard time making a connection
> with the definition of power state that we have:
> >>
> >> A Power State is a condition or mode of a device that broadly
> >> characterizes its capabilities, power consumption, and
> responsiveness
> >> to input.
> >>
> >> It is more like "availability for use" rather than an actual power
> state. That however is currently not covered by the MIB and we can
> think about whether we should introduce this.
> >>
> >> Best,
> >>
> >> Rolf
> >>
> >>
> >>
> >> NEC Europe Ltd | Registered Office: Athene, Odyssey Business Park,
> >> West End  Road, London, HA4 6QE, GB | Registered in England 2832014
> >>
> >>
> >>> -----Original Message-----
> >>> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On
> Behalf
> >>> Of Bruce Nordman
> >>> Sent: Dienstag, 1. Oktober 2013 21:33
> >>> To: joel jaeggli
> >>> Cc: Ted Ghose; eman@ietf.org
> >>> Subject: Re: [eman] Power States !=3D Charging States?
> >>>
> >>> I agree with Rolf that the battery charging state is a different
> >>> concept from power state.
> >>>
> >>>
> >>> The current charging state entries in the battery MIB document are:
> >>>
> >>> unknown, charging, fastCharging, maintainingCharge, noCharging, and
> >>> discharging.
> >>>
> >>> It seems plausible to me that over time storage technologies will
> >>> evolve so that
> >>>
> >>> more entries in this list will be desired.  The power state
> registry
> >>> could then be used as a place to put such additional charging state
> >>> sets, in which case it should be stated to cover both power and
> >>> charging states.  Or, a second registry just for
> >>>
> >>> battery states could be created.  Or, states could be added by
> >>> updating the battery MIB.
> >>>
> >>>
> >>> Note that a battery can have data only as listed in the battery MIB,
> >>> it can only have component data as an energy object, or both.  For
> >>> the energy object aspect of batteries, there is a field for the
> >>> battery component for power state.  This could be left empty, or
> >>> used.  It occurs to me that a battery could be available/in-use,
> >>> which I would consider to be On, or not electrically available (for
> >>> charging or discharging), which I would consider to be Off (perhaps
> >>> for being physically removed, or simply selected to be not
> available for use).
> >>> IEEE 1621 covers this.
> >>>
> >>>
> >>> Finally, I thought that the battery MIB draft had indications for
> >>> battery failure.  This seems like something that could be reported
> >>> on in either the charging state or
> >>>
> >>> power state context.
> >>>
> >>> --Bruce
> >>>
> >>>
> >>>
> >>> On Tue, Oct 1, 2013 at 8:40 AM, joel jaeggli 
> wrote:
> >>>
> >>>
> >>>
> >>>   On Sep 30, 2013, at 9:09 AM, Benoit Claise 
> >>> wrote:
> >>>
> >>>> Hi Ted,
> >>>>> Hi Rolf
> >>>>>
> >>>>> +1
> >>>>>
> >>>>> Thanks for clearly articulating the points. I totally agree
> >>> the charging state should be orthogonal to power state.
> >>>>>
> >>>>> My position is that battery should _also_ have power state
> >>> indicating if it is receiving power (charging) or giving power to
> >>> the electrical network, and how much
> >>>> That makes sense.
> >>>>
> >>>> Regards, Benoit
> >>>
> >>>
> >>>   In my limited experience with battery controllers batteries are
> >>> either:
> >>>
> >>>   charging
> >>>   discharging
> >>>   full
> >>>   empty
> >>>
> >>>   in all cases  state of charge, e.g. capacity is germain.
> >>>
> >>>
> >>>>>
> >>>>> This will be useful to account for all the power source and
> >>> sink
> >>>>>
> >>>>> Best
> >>>>>
> >>>>> -tg-
> >>>>> Sent from my iPhone
> >>>>>
> >>>>>> On Sep 25, 2013, at 6:18 AM, Rolf Winter
> >>>  wrote:
> >>>>>>
> >>>>>> Hi,
> >>>>>>
> >>>>>> this thread attempts to close an open issue in the framework
> >>> document (v10) where section 9.1.4 reads:
> >>>>>>
> >>>>>> 9.1.4. Batteries Power State Set
> >>>>>>
> >>>>>>       Batteries have operational and administrational states
> >>> that
> >>>>>>       could be represented as a power state set. Since the
> >>> work
> >>>>>>       for battery management is parallel to this document,
> >>> we are
> >>>>>>       not proposing any Power State Sets for batteries at
> >>> this
> >>>>>>       time.
> >>>>>>
> >>>>>> I argue that batteries have no power states given the power
> >>> state definition:
> >>>>>>
> >>>>>>       A Power State is a condition or mode of a device that
> >>>>>>       broadly characterizes its capabilities, power
> >>>>>>       consumption, and responsiveness to input.
> >>>>>>
> >>>>>> There are charging states currently defined in the battery
> >>> MIB, which seem to be orthogonal to power states. I guess a
> >>> universal power state set is "on" and "off". Any device can really
> >>> be in one of these two modes. Even a simple light bulb. What would
> >>> be "on" for a battery? Maybe charging because it receives energy
> >>> (like any other device that is actually "on")? But every device
> that
> >>> is on, fulfills its primary function. I would argue that the
> primary
> >>> function of a battery is to provide energy. Batteries are different
> >>> and I maybe we should ack this fact and not try to create battery
> >>> power state sets just because we have this for devices.
> >>>>>>
> >>>>>> I think the Email thread http://www.ietf.org/mail-
> >>> archive/web/eman/current/msg02000.html seemed to agree that
> charging
> >>> states and power states are orthogonal. If they are, why should
> they
> >>> be of the same class? The problem is that the power state above as
> >>> used for devices would suggest that if a device is off, it does not
> >>> consume any energy. But if the battery is charging, then it does
> >>> (given that the battery is modeled as part of the device). So if a
> >>> power state is indeed conflating power consumption and capabilities,
> >>> then a device would be in two different power states at the same
> time. But it is not.
> >>> It is in one power state and the batteries in it are in a certain
> >>> charging state and each of these can be freely combined. I.e.
> >>> charging/on, discharging/on, charging/off etc... I guess the main
> >>> question is, what is the advantage of defining a charging state as
> a
> >>> power state (the set of charging states as a power state set)?
> >>>>>>
> >>>>>>
> >>>>>> Best,
> >>>>>>
> >>>>>> Rolf
> >>>>>>
> >>>>>> NEC Europe Ltd | Registered Office: Athene, Odyssey Business
> >>> Park, West End  Road, London, HA4 6QE, GB | Registered in England
> >>> 2832014
> >>>>>>
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> eman mailing list
> >>>>>> eman@ietf.org
> >>>>>> https://www.ietf.org/mailman/listinfo/eman
> >>>>> _______________________________________________
> >>>>> eman mailing list
> >>>>> eman@ietf.org
> >>>>> https://www.ietf.org/mailman/listinfo/eman
> >>>>> .
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> eman mailing list
> >>>> eman@ietf.org
> >>>> https://www.ietf.org/mailman/listinfo/eman
> >>>
> >>>
> >>>
> >>>   _______________________________________________
> >>>   eman mailing list
> >>>   eman@ietf.org
> >>>   https://www.ietf.org/mailman/listinfo/eman
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> --
> >>> Bruce Nordman
> >>> Lawrence Berkeley National Laboratory nordman.lbl.gov
> >>> BNordman@LBL.gov
> >>> 510-486-7089
> >>> m: 510-501-7943
> >
> > _______________________________________________
> > eman mailing list
> > eman@ietf.org
> > https://www.ietf.org/mailman/listinfo/eman

From jparello@cisco.com  Tue Oct  8 10:07:22 2013
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 D14D411E80F7 for ; Tue,  8 Oct 2013 10:07:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.609
X-Spam-Level: 
X-Spam-Status: No, score=-8.609 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, PLING_QUERY=1.39, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qb4xrrLFs5tQ for ; Tue,  8 Oct 2013 10:07:17 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id DA05C11E80FB for ; Tue,  8 Oct 2013 10:07:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13045; q=dns/txt; s=iport; t=1381252029; x=1382461629; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=NhI6YRo5Jc4g8rnkpEh9KjG3zNv1mq2/CaryDlIkD4M=; b=aKiN62mEgfREaLGbLO5jRLrwYWueTPwmkOkV1UwT2FwcrI+93RGzhfWl Vhu6GKt1MmsLq9ii2Nme/l1iPL6i1KonXguRS7s0kXg82V11s2BQScLi0 6XYaQPNaW6Bg4B21r5O8bSbw48IrThfy4Qk7W5u0QnUSb8v5RCa6srYd7 E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AmwJANY6VFKtJV2d/2dsb2JhbABWA4MHOEwGwSSBFQ0WdIIlAQEBBAEBATc0CwwEAgEIEQQBAQEKCwkJBycLFAkIAgQOBQgBh30HBbpUjXMGCgQCAQWBAgYbEAcGBAeDDoEEA5kwix6FM4MkgWgBCBci
X-IronPort-AV: E=Sophos;i="4.90,1057,1371081600"; d="scan'208";a="269578456"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-6.cisco.com with ESMTP; 08 Oct 2013 17:07:06 +0000
Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r98H76Hk005200 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 8 Oct 2013 17:07:06 GMT
Received: from xmb-aln-x04.cisco.com ([169.254.9.229]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Tue, 8 Oct 2013 12:07:05 -0500
From: "John Parello (jparello)" 
To: Rolf Winter 
Thread-Topic: [eman] Power States != Charging States?
Thread-Index: Ac658agNBCTPrXG/QuKZUDsu7CoziAALVlSAAQCV9QAAMUlCgAAIG0kAAB5ZxAAACBiagP//tGPIgAnlBgD//7QYuA==
Date: Tue, 8 Oct 2013 17:07:05 +0000
Message-ID: <9C213D38848B89428F46808B16F6F08601664006@xmb-aln-x04.cisco.com>
References: <791AD3077F94194BB2BDD13565B6295D55726BC7@DAPHNIS.office.hd>  <5249A238.10500@cisco.com>	 , <791AD3077F94194BB2BDD13565B6295D55727F6E@DAPHNIS.office.hd>, <4C227BE7-1FAE-4DC4-B5A8-2F0CB0D429F1@juniper.net> , <791AD3077F94194BB2BDD13565B6295D55729320@DAPHNIS.office.hd>
In-Reply-To: <791AD3077F94194BB2BDD13565B6295D55729320@DAPHNIS.office.hd>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.21.118.32]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "eman@ietf.org" 
Subject: Re: [eman] Power States != Charging States?
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, 08 Oct 2013 17:07:23 -0000

Very true. Whether these are power state or more encompassing I like the id=
ea of the registry we came up with and then the devices listing which ones =
they implement.=0A=
=0A=
We've accepted that they do not need to overlap so for me I'd rather broade=
n the scope of the series and states  like.=0A=
=0A=
(again I prefer energy state but...)=0A=
"""=0A=
A Power State is a condition or mode of a device that broadly=0A=
characterizes its capabilities, power, and function=0A=
"""=0A=
=0A=
That would cover charging states?=0A=
=0A=
So a device could implement:=0A=
=0A=
Series:=0A=
=0A=
[0] IEEE:  on, off, sleep=0A=
[1] BATTERY: unknown, charging, fastCharging, maintainingCharge, noCharging=
, discharging=0A=
=0A=
If could also be modeled as a device with a battery component each with one=
 series.=0A=
=0A=
Jp=0A=
=0A=
=0A=
=0A=
________________________________________=0A=
From: Rolf Winter [Rolf.Winter@neclab.eu]=0A=
Sent: Tuesday, October 08, 2013 9:29 AM=0A=
To: John Parello (jparello); Ted Ghose=0A=
Cc: eman@ietf.org=0A=
Subject: RE: [eman] Power States !=3D Charging States?=0A=
=0A=
Hi John,=0A=
=0A=
when you snip text out of a definition I think you can make anything fit th=
at defintion. But you snipped important things like the "consumption" bit a=
fter "power" or "responsiveness to input".=0A=
=0A=
Best,=0A=
=0A=
Rolf=0A=
=0A=
NEC Europe Ltd | Registered Office: Athene, Odyssey Business Park, West End=
  Road, London, HA4 6QE, GB | Registered in England 2832014=0A=
=0A=
=0A=
> -----Original Message-----=0A=
> From: John Parello (jparello) [mailto:jparello@cisco.com]=0A=
> Sent: Mittwoch, 2. Oktober 2013 16:23=0A=
> To: Ted Ghose=0A=
> Cc: Rolf Winter; eman@ietf.org=0A=
> Subject: Re: [eman] Power States !=3D Charging States?=0A=
>=0A=
> So I'm seeing we all agree charing states are orthogonal to the current=
=0A=
> power states.=0A=
> That it's reasonable to expect a battery modeled by an Energy Object to=
=0A=
> implement power states to show what it is receiving or giving to the=0A=
> system.=0A=
>=0A=
> +1 On Bruce's comment in it;s entirety also that we could include the=0A=
> battery states in power states at some later date.=0A=
>=0A=
> Rolf I'm not sure I see that the definition of power states does not=0A=
> cover states of a battery. "A condition or mode that broadly=0A=
> characterize..power..." does seem to cover if a battery is receving=0A=
> energy and storing it? Anyone else see this is ok or not?=0A=
>=0A=
> I did bring up that we call these power states when "energy states" and=
=0A=
> "energy interfaces" is more accurate. Would that be more comfortable to=
=0A=
> you. ETSI is using Energy States in their liaison with us is the GAL.=0A=
>=0A=
> I will update 9.1.4 according to this thread an lets see how that rolls.=
=0A=
>=0A=
> Jp=0A=
>=0A=
> Sent from my iPad=0A=
> (expect ridiculous spelling mistakes)=0A=
>=0A=
> On Oct 2, 2013, at 6:56 AM, "Ted Ghose"  wrote:=0A=
>=0A=
> > We still need to know know the amount of power battery is receiving=0A=
> or giving to the system.=0A=
> >=0A=
> > How are we addressing that?=0A=
> >=0A=
> > I totally agree charging state has nothing to do with it=0A=
> >=0A=
> > -tg-=0A=
> > Sent from my iPhone=0A=
> >=0A=
> >> On Oct 2, 2013, at 3:04 AM, "Rolf Winter" =0A=
> wrote:=0A=
> >>=0A=
> >> Hi,=0A=
> >>=0A=
> >> So it seems there is a general agreement that power and charging=0A=
> states are different. But I am still not sure we need a separate power=0A=
> state. I think I read two different things so far.=0A=
> >>=0A=
> >> 1) introduce a state that shows if it is charging or discharging and=
=0A=
> >> how much=0A=
> >> 2) introduce state which merely indicates whether the battery can be=
=0A=
> >> used (either charged or discharged or not)=0A=
> >>=0A=
> >> I thought 1 is already covered by the current battery MIB with=0A=
> charging states and the actual measurements of e.g. the actual current=0A=
> etc. The same I guess applied to devices which might have a couple of=0A=
> power states and then actual measurements to quantify energy use.=0A=
> >>=0A=
> >> I am not sure about 2 since I have a hard time making a connection=0A=
> with the definition of power state that we have:=0A=
> >>=0A=
> >> A Power State is a condition or mode of a device that broadly=0A=
> >> characterizes its capabilities, power consumption, and=0A=
> responsiveness=0A=
> >> to input.=0A=
> >>=0A=
> >> It is more like "availability for use" rather than an actual power=0A=
> state. That however is currently not covered by the MIB and we can=0A=
> think about whether we should introduce this.=0A=
> >>=0A=
> >> Best,=0A=
> >>=0A=
> >> Rolf=0A=
> >>=0A=
> >>=0A=
> >>=0A=
> >> NEC Europe Ltd | Registered Office: Athene, Odyssey Business Park,=0A=
> >> West End  Road, London, HA4 6QE, GB | Registered in England 2832014=0A=
> >>=0A=
> >>=0A=
> >>> -----Original Message-----=0A=
> >>> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On=0A=
> Behalf=0A=
> >>> Of Bruce Nordman=0A=
> >>> Sent: Dienstag, 1. Oktober 2013 21:33=0A=
> >>> To: joel jaeggli=0A=
> >>> Cc: Ted Ghose; eman@ietf.org=0A=
> >>> Subject: Re: [eman] Power States !=3D Charging States?=0A=
> >>>=0A=
> >>> I agree with Rolf that the battery charging state is a different=0A=
> >>> concept from power state.=0A=
> >>>=0A=
> >>>=0A=
> >>> The current charging state entries in the battery MIB document are:=
=0A=
> >>>=0A=
> >>> unknown, charging, fastCharging, maintainingCharge, noCharging, and=
=0A=
> >>> discharging.=0A=
> >>>=0A=
> >>> It seems plausible to me that over time storage technologies will=0A=
> >>> evolve so that=0A=
> >>>=0A=
> >>> more entries in this list will be desired.  The power state=0A=
> registry=0A=
> >>> could then be used as a place to put such additional charging state=
=0A=
> >>> sets, in which case it should be stated to cover both power and=0A=
> >>> charging states.  Or, a second registry just for=0A=
> >>>=0A=
> >>> battery states could be created.  Or, states could be added by=0A=
> >>> updating the battery MIB.=0A=
> >>>=0A=
> >>>=0A=
> >>> Note that a battery can have data only as listed in the battery MIB,=
=0A=
> >>> it can only have component data as an energy object, or both.  For=0A=
> >>> the energy object aspect of batteries, there is a field for the=0A=
> >>> battery component for power state.  This could be left empty, or=0A=
> >>> used.  It occurs to me that a battery could be available/in-use,=0A=
> >>> which I would consider to be On, or not electrically available (for=
=0A=
> >>> charging or discharging), which I would consider to be Off (perhaps=
=0A=
> >>> for being physically removed, or simply selected to be not=0A=
> available for use).=0A=
> >>> IEEE 1621 covers this.=0A=
> >>>=0A=
> >>>=0A=
> >>> Finally, I thought that the battery MIB draft had indications for=0A=
> >>> battery failure.  This seems like something that could be reported=0A=
> >>> on in either the charging state or=0A=
> >>>=0A=
> >>> power state context.=0A=
> >>>=0A=
> >>> --Bruce=0A=
> >>>=0A=
> >>>=0A=
> >>>=0A=
> >>> On Tue, Oct 1, 2013 at 8:40 AM, joel jaeggli =0A=
> wrote:=0A=
> >>>=0A=
> >>>=0A=
> >>>=0A=
> >>>   On Sep 30, 2013, at 9:09 AM, Benoit Claise =0A=
> >>> wrote:=0A=
> >>>=0A=
> >>>> Hi Ted,=0A=
> >>>>> Hi Rolf=0A=
> >>>>>=0A=
> >>>>> +1=0A=
> >>>>>=0A=
> >>>>> Thanks for clearly articulating the points. I totally agree=0A=
> >>> the charging state should be orthogonal to power state.=0A=
> >>>>>=0A=
> >>>>> My position is that battery should _also_ have power state=0A=
> >>> indicating if it is receiving power (charging) or giving power to=0A=
> >>> the electrical network, and how much=0A=
> >>>> That makes sense.=0A=
> >>>>=0A=
> >>>> Regards, Benoit=0A=
> >>>=0A=
> >>>=0A=
> >>>   In my limited experience with battery controllers batteries are=0A=
> >>> either:=0A=
> >>>=0A=
> >>>   charging=0A=
> >>>   discharging=0A=
> >>>   full=0A=
> >>>   empty=0A=
> >>>=0A=
> >>>   in all cases  state of charge, e.g. capacity is germain.=0A=
> >>>=0A=
> >>>=0A=
> >>>>>=0A=
> >>>>> This will be useful to account for all the power source and=0A=
> >>> sink=0A=
> >>>>>=0A=
> >>>>> Best=0A=
> >>>>>=0A=
> >>>>> -tg-=0A=
> >>>>> Sent from my iPhone=0A=
> >>>>>=0A=
> >>>>>> On Sep 25, 2013, at 6:18 AM, Rolf Winter=0A=
> >>>  wrote:=0A=
> >>>>>>=0A=
> >>>>>> Hi,=0A=
> >>>>>>=0A=
> >>>>>> this thread attempts to close an open issue in the framework=0A=
> >>> document (v10) where section 9.1.4 reads:=0A=
> >>>>>>=0A=
> >>>>>> 9.1.4. Batteries Power State Set=0A=
> >>>>>>=0A=
> >>>>>>       Batteries have operational and administrational states=0A=
> >>> that=0A=
> >>>>>>       could be represented as a power state set. Since the=0A=
> >>> work=0A=
> >>>>>>       for battery management is parallel to this document,=0A=
> >>> we are=0A=
> >>>>>>       not proposing any Power State Sets for batteries at=0A=
> >>> this=0A=
> >>>>>>       time.=0A=
> >>>>>>=0A=
> >>>>>> I argue that batteries have no power states given the power=0A=
> >>> state definition:=0A=
> >>>>>>=0A=
> >>>>>>       A Power State is a condition or mode of a device that=0A=
> >>>>>>       broadly characterizes its capabilities, power=0A=
> >>>>>>       consumption, and responsiveness to input.=0A=
> >>>>>>=0A=
> >>>>>> There are charging states currently defined in the battery=0A=
> >>> MIB, which seem to be orthogonal to power states. I guess a=0A=
> >>> universal power state set is "on" and "off". Any device can really=0A=
> >>> be in one of these two modes. Even a simple light bulb. What would=0A=
> >>> be "on" for a battery? Maybe charging because it receives energy=0A=
> >>> (like any other device that is actually "on")? But every device=0A=
> that=0A=
> >>> is on, fulfills its primary function. I would argue that the=0A=
> primary=0A=
> >>> function of a battery is to provide energy. Batteries are different=
=0A=
> >>> and I maybe we should ack this fact and not try to create battery=0A=
> >>> power state sets just because we have this for devices.=0A=
> >>>>>>=0A=
> >>>>>> I think the Email thread http://www.ietf.org/mail-=0A=
> >>> archive/web/eman/current/msg02000.html seemed to agree that=0A=
> charging=0A=
> >>> states and power states are orthogonal. If they are, why should=0A=
> they=0A=
> >>> be of the same class? The problem is that the power state above as=0A=
> >>> used for devices would suggest that if a device is off, it does not=
=0A=
> >>> consume any energy. But if the battery is charging, then it does=0A=
> >>> (given that the battery is modeled as part of the device). So if a=0A=
> >>> power state is indeed conflating power consumption and capabilities,=
=0A=
> >>> then a device would be in two different power states at the same=0A=
> time. But it is not.=0A=
> >>> It is in one power state and the batteries in it are in a certain=0A=
> >>> charging state and each of these can be freely combined. I.e.=0A=
> >>> charging/on, discharging/on, charging/off etc... I guess the main=0A=
> >>> question is, what is the advantage of defining a charging state as=0A=
> a=0A=
> >>> power state (the set of charging states as a power state set)?=0A=
> >>>>>>=0A=
> >>>>>>=0A=
> >>>>>> Best,=0A=
> >>>>>>=0A=
> >>>>>> Rolf=0A=
> >>>>>>=0A=
> >>>>>> NEC Europe Ltd | Registered Office: Athene, Odyssey Business=0A=
> >>> Park, West End  Road, London, HA4 6QE, GB | Registered in England=0A=
> >>> 2832014=0A=
> >>>>>>=0A=
> >>>>>>=0A=
> >>>>>> _______________________________________________=0A=
> >>>>>> eman mailing list=0A=
> >>>>>> eman@ietf.org=0A=
> >>>>>> https://www.ietf.org/mailman/listinfo/eman=0A=
> >>>>> _______________________________________________=0A=
> >>>>> eman mailing list=0A=
> >>>>> eman@ietf.org=0A=
> >>>>> https://www.ietf.org/mailman/listinfo/eman=0A=
> >>>>> .=0A=
> >>>>=0A=
> >>>>=0A=
> >>>> _______________________________________________=0A=
> >>>> eman mailing list=0A=
> >>>> eman@ietf.org=0A=
> >>>> https://www.ietf.org/mailman/listinfo/eman=0A=
> >>>=0A=
> >>>=0A=
> >>>=0A=
> >>>   _______________________________________________=0A=
> >>>   eman mailing list=0A=
> >>>   eman@ietf.org=0A=
> >>>   https://www.ietf.org/mailman/listinfo/eman=0A=
> >>>=0A=
> >>>=0A=
> >>>=0A=
> >>>=0A=
> >>>=0A=
> >>>=0A=
> >>> --=0A=
> >>> Bruce Nordman=0A=
> >>> Lawrence Berkeley National Laboratory nordman.lbl.gov=0A=
> >>> BNordman@LBL.gov=0A=
> >>> 510-486-7089=0A=
> >>> m: 510-501-7943=0A=
> >=0A=
> > _______________________________________________=0A=
> > eman mailing list=0A=
> > eman@ietf.org=0A=
> > https://www.ietf.org/mailman/listinfo/eman=0A=

From brads@coraid.com  Tue Oct  8 15:32:57 2013
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 D41EB11E80E6 for ; Tue,  8 Oct 2013 15:32:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CbwEhEs-eERm for ; Tue,  8 Oct 2013 15:32:52 -0700 (PDT)
Received: from server506.appriver.com (server506h.appriver.com [50.56.144.38]) by ietfa.amsl.com (Postfix) with ESMTP id AA09A21F9301 for ; Tue,  8 Oct 2013 15:32:51 -0700 (PDT)
X-Note-AR-ScanTimeLocal: 10/8/2013 5:32:51 PM
X-Policy: GLOBAL - coraid.com
X-Policy: GLOBAL - coraid.com
X-Policy: GLOBAL - coraid.com
X-Policy: GLOBAL - coraid.com
X-Primary: brads@coraid.com
X-Note: This Email was scanned by AppRiver SecureTide
X-Virus-Scan: V-
X-Note-SnifferID: 0
X-Note: TCH-CT/SI:0-38/SG:2 10/8/2013 5:32:33 PM
X-GBUdb-Analysis: 0, 10.242.229.139, Ugly c=1 p=-0.935643 Source White
X-Signature-Violations: 0-0-0-10746-c
X-Note-419: 31.201 ms. Fail:0 Chk:1347 of 1347 total
X-Note: SCH-CT/SI:0-1347/SG:1 10/8/2013 5:32:50 PM
X-Note: Spam Tests Failed: 
X-Country-Path: UNKNOWN->PRIVATE->UNITED STATES
X-Note-Sending-IP: 10.242.229.139
X-Note-Reverse-DNS: 
X-Note-Return-Path: brads@coraid.com
X-Note: User Rule Hits: 
X-Note: Global Rule Hits: G340 G341 G342 G343 G347 G348 G455 
X-Note: Encrypt Rule Hits: 
X-Note: Mail Class: VALID
X-Note: Headers Injected
Received: from [10.242.229.139] (HELO smtp.exg6.exghost.com) by server506.appriver.com (CommuniGate Pro SMTP 6.0.2) with ESMTPS id 119813620; Tue, 08 Oct 2013 17:32:51 -0500
Received: from DAGN05C-E6.exg6.exghost.com ([169.254.3.11]) by HT05-E6.exg6.exghost.com ([10.242.230.112]) with mapi id 14.03.0158.001; Tue, 8 Oct 2013 17:32:50 -0500
From: Brad Schoening 
To: Juergen Quittek , Nevil Brownlee , "eman@ietf.org" 
Thread-Topic: [eman] WG Last Call for EMAN Framework -09
Thread-Index: Ac68BvPUSwGPwstz/USB/jP7XW0N9gIXpgsA
Date: Tue, 8 Oct 2013 22:32:49 +0000
Message-ID: 
In-Reply-To: <9AB93E4127C26F4BA7829DEFDCE5A6E85A41C6F0@DAPHNIS.office.hd>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.14.0.111121
x-originating-ip: [50.56.144.247]
x-rerouted-by-exchange: 
Content-Type: text/plain; charset="Windows-1252"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "ops-ads@tools.ietf.org" 
Subject: Re: [eman] WG Last Call for EMAN Framework -09
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 08 Oct 2013 22:32:57 -0000

Juergen,

Regarding you point on 'category', I found two uses of scalar product
classification in the entity MIB and and extension in VMWare's CIM model.
The Entity MIB uses the language "set this object to the =8A value that mos=
t
accurately indicates the general class".  Clearly, there could be multiple
values, but the Entity MIB chose to use a simple scalar.

I think we should follow the entity MIB model using their approach of
scalar value. The utility of a scalar value is easier to work with.

Here's the description from the Entity MIB:

	entPhysicalClass OBJECT-TYPE
	SYNTAX      PhysicalClass
	MAX-ACCESS  read-only

	DESCRIPTION

	"An indication of the general hardware type of the physical entity.

	An agent should set this object to the standard enumeration
	value that most accurately indicates the general class of
	the physical entity, or the primary class if there is more=09
	than one entity.

	If no appropriate standard registration identifier exists
	for this physical entity, then the value 'other(1)' is
	returned.  If the value is unknown by this agent, then the
	value 'unknown(2)' is returned."
	::=3D { entPhysicalEntry 5 }

	1:other
	2:unknown
	3:chassis
	4:backplane
	5:container
	6:powerSupply
	7:fan
	8:sensor
	9:module
	10:port=09
	11:stack
	12:cpu

Also, in VMWare's CIM model, they extend this with their 'packageType'
variable:

PackageType

Enumeration defining the type of the PhysicalPackage. Note that this
enumeration expands on the list in the Entity MIB (the attribute,
entPhysicalClass). The numeric values are consistent with CIM's enum
numbering guidelines, but are slightly different than the MIB's values.
Unknown - indicates that the package type is not known. Other - The
package type does not correspond to an existing enumerated value. The
value is specified using the OtherPackageType property. The values "Rack"
through "Port/Connector" are defined per the Entity-MIB (where the
semantics of rack are equivalent to the MIB's 'stack' value). The other
values (for battery, processor, memory, power source/generator and storage
media package) are self-explanatory. A value of "Blade" should be used
when the PhysicalPackage contains the operational hardware aspects of a
ComputerSystem, without the supporting mechanicals such as power and
cooling. For example, a Blade Server includes processor(s) and memory, and
relies on the containing chassis to supply power and cooling. In many
respects, a Blade can be considered a "Module/Card". However, it is
tracked differently by inventory systems and differs in terms of service
philosophy. For example, a Blade is intended to be hot-plugged into a
hosting enclosure without requiring additional cabling, and does not
require a cover to be removed from the enclosure for installation.
Similarly, a "Blade Expansion" has characteristics of a "Blade" and a
"Module/Card". However, it is distinct from both due to inventory tracking
and service philosophy, and because of its hardware dependence on a Blade.
A Blade Expansion must be attached to a Blade prior to inserting the
resultant assembly into an enclosure.

Values	Unknown, Other, Rack, Chassis/Frame, Cross Connect/Backplane,
Container/Frame Slot, Power Supply, Fan, Sensor, Module/Card,
Port/Connector, Battery, Processor, Memory, Power Source/Generator,
Storage Media Package (e.g., Disk or Tape Drive), Blade, Blade Expansion

ValueMap	0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17




Brad Schoening
Engineering | Coraid
Tel: +1 917 304 7190
brads@coraid.com | www.coraid.com 
Coraid: Redefining
Storage





On 9/28/13 12:56 AM, "Juergen Quittek"  wrote:

>G.2. There is only one instance of each per Energy Object
>The current model allows for only one instance of each context attribute.
>This is often not sufficient, particularly for type, role, and domain. As
>discussed many times on the list, a device can be contained in multiple
>metering domain, ad device can have multiple roles, and it can match
>multiple categories, such as, for example, distributor and meter.
>What I think is needed is a more open and extensible framework for
>context information, that allows arbitrary context information and
>multiple instances of each context. The result could, for example, in XML
>look like
>
>    distributor
>    meter
>    PDU
>    East Wing
>    Server Room
>    Building A
>    East Wing Level 3
>    0.7
>
>or in JSON look like
>"context": {
>    "category": [ "distributor", "meter" ],
>    "role": "PDU",
>    "location": [ "East Wing", "Server Room" ],
>    "meteringDomain": [ "Building A", "East Wing Level 3" ],
>    "costFactor": 0.7
>}


From brads@coraid.com  Wed Oct  9 13:38:19 2013
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 6791F21E809F for ; Wed,  9 Oct 2013 13:38:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7dpqB23NcraY for ; Wed,  9 Oct 2013 13:38:13 -0700 (PDT)
Received: from server506.appriver.com (server506l.appriver.com [50.56.144.158]) by ietfa.amsl.com (Postfix) with ESMTP id CA2F621E81A1 for ; Wed,  9 Oct 2013 13:37:58 -0700 (PDT)
X-Note-AR-ScanTimeLocal: 10/9/2013 3:37:57 PM
X-Policy: GLOBAL - coraid.com
X-Policy: GLOBAL - coraid.com
X-Policy: GLOBAL - coraid.com
X-Policy: GLOBAL - coraid.com
X-Primary: brads@coraid.com
X-Note: This Email was scanned by AppRiver SecureTide
X-Virus-Scan: V-
X-Note-SnifferID: 0
X-Note: TCH-CT/SI:0-72/SG:2 10/9/2013 3:37:28 PM
X-GBUdb-Analysis: 0, 10.242.229.139, Ugly c=1 p=-0.942333 Source White
X-Signature-Violations: 0-0-0-1957-c
X-Note-419: 0 ms. Fail:0 Chk:1347 of 1347 total
X-Note: SCH-CT/SI:0-1347/SG:1 10/9/2013 3:37:43 PM
X-Note: Spam Tests Failed: 
X-Country-Path: UNKNOWN->PRIVATE->UNITED STATES
X-Note-Sending-IP: 10.242.229.139
X-Note-Reverse-DNS: 
X-Note-Return-Path: brads@coraid.com
X-Note: User Rule Hits: 
X-Note: Global Rule Hits: G340 G341 G342 G343 G347 G348 G455 
X-Note: Encrypt Rule Hits: 
X-Note: Mail Class: VALID
X-Note: Headers Injected
Received: from [10.242.229.139] (HELO smtp.exg6.exghost.com) by server506.appriver.com (CommuniGate Pro SMTP 6.0.2) with ESMTPS id 14815168; Wed, 09 Oct 2013 15:37:57 -0500
Received: from DAGN05C-E6.exg6.exghost.com ([169.254.3.11]) by HT10-E6.exg6.exghost.com ([50.56.144.169]) with mapi id 14.03.0158.001; Wed, 9 Oct 2013 15:37:48 -0500
From: Brad Schoening 
To: Juergen Quittek , Nevil Brownlee , "eman@ietf.org" 
Thread-Topic: [eman] WG Last Call for EMAN Framework -09
Thread-Index: Ac68BvPUSwGPwstz/USB/jP7XW0N9gJBsXMA
Date: Wed, 9 Oct 2013 20:37:47 +0000
Message-ID: 
In-Reply-To: <9AB93E4127C26F4BA7829DEFDCE5A6E85A41C6F0@DAPHNIS.office.hd>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.14.0.111121
x-originating-ip: [50.56.144.246]
x-rerouted-by-exchange: 
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "ops-ads@tools.ietf.org" 
Subject: Re: [eman] WG Last Call for EMAN Framework -09
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 09 Oct 2013 20:38:19 -0000

The DTFM power states are a superset of the ACPI states.



On 9/28/13 12:56 AM, "Juergen Quittek"  wrote:

>38. section 4.5.1 "Power State Sets"
>Why is the ACPI power state set excluded from the list of existing sets?
>ACPI power states should have their own subsection as IEEE1621 and DMTF
>have.


From moulchan@cisco.com  Thu Oct 10 02:38:00 2013
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 C3BD921F9FB6 for ; Thu, 10 Oct 2013 02:38:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.608
X-Spam-Level: 
X-Spam-Status: No, score=-8.608 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, PLING_QUERY=1.39, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M9xsEhJXhsKQ for ; Thu, 10 Oct 2013 02:37:56 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id B06CD21E80EB for ; Thu, 10 Oct 2013 02:37:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=33442; q=dns/txt; s=iport; t=1381397873; x=1382607473; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=zwuCZmYGtTr5K9fH7w0Iyl2JCuJLl75bQ7k/pITEOHM=; b=Vhi+lu0Hc2ABIr3WBezbYtpFApOA1Dm/xiiaKsEnkQH7xWSDSGq4nZlZ mCKj0uh6vGfC0bQxivCKEP26gwkmiaqovEoe3TCgrh8G+IHPBDGKXF61X vO24LsLN2g4YQjMZ+1rUa5pwEWhIqI4IfrpBmdeHuO1ZCbssimIH9aFu5 Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AlEKAAl1VlKtJV2b/2dsb2JhbABWA4JDRDhMBoRGvFmBEg0WbQeCJQEBAQMBAQEBF1QQBwYBGQQBAQEKCwsHLgsUCQgCBBMIAYd3BgcFl1ihOI14BgoEAgEFgQIGGwwFBgYEB4MOgQQDmTSLIIUzgySBaAEIFyI
X-IronPort-AV: E=Sophos;i="4.90,1070,1371081600";  d="scan'208,217";a="270408768"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-6.cisco.com with ESMTP; 10 Oct 2013 09:37:52 +0000
Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r9A9bqes028376 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 10 Oct 2013 09:37:52 GMT
Received: from xmb-rcd-x08.cisco.com ([169.254.8.94]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.004; Thu, 10 Oct 2013 04:37:52 -0500
From: "Mouli Chandramouli (moulchan)" 
To: "eman@ietf.org" 
Thread-Topic: [eman] Power States != Charging States?
Thread-Index: Ac658agNBCTPrXG/QuKZUDsu7CoziAALVlSAAQCV9QAAMUlCgAAIG0kAAB5ZxAAACBiagP//tGPIgAnlBgD//7QYuIADWd6A
Date: Thu, 10 Oct 2013 09:37:51 +0000
Message-ID: <852AF0ED49D9F24BBBFA1B4DEEBE3BA42ADB79B2@xmb-rcd-x08.cisco.com>
In-Reply-To: <9C213D38848B89428F46808B16F6F08601664006@xmb-aln-x04.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.7.130812
x-originating-ip: [10.142.100.75]
Content-Type: multipart/alternative; boundary="_000_852AF0ED49D9F24BBBFA1B4DEEBE3BA42ADB79B2xmbrcdx08ciscoc_"
MIME-Version: 1.0
Subject: [eman]  Power States != Charging States?
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, 10 Oct 2013 09:38:00 -0000

--_000_852AF0ED49D9F24BBBFA1B4DEEBE3BA42ADB79B2xmbrcdx08ciscoc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,

I would agree with Joel Jaggli's suggestion on battery states -

http://www.ietf.org/mail-archive/web/eman/current/msg02010.html


charging
discharging
full
Empty

Thanks
Mouli


Very true. Whether these are power state or more encompassing I like the id=
ea of the registry we came up with and then the devices listing which ones =
they implement.

We've accepted that they do not need to overlap so for me I'd rather broade=
n the scope of the series and states  like.

(again I prefer energy state but...)
"""
A Power State is a condition or mode of a device that broadly
characterizes its capabilities, power, and function
"""

That would cover charging states?

So a device could implement:

Series:

[0] IEEE:  on, off, sleep
[1] BATTERY: unknown, charging, fastCharging, maintainingCharge, noCharging=
, discharging

If could also be modeled as a device with a battery component each with one=
 series.

Jp



________________________________________
From: Rolf Winter [Rolf.Winter@neclab.eu]
Sent: Tuesday, October 08, 2013 9:29 AM
To: John Parello (jparello); Ted Ghose
Cc: eman@ietf.org
Subject: RE: [eman] Power States !=3D Charging States?

Hi John,

when you snip text out of a definition I think you can make anything fit th=
at defintion. But you snipped important things like the "consumption" bit a=
fter "power" or "responsiveness to input".

Best,

Rolf

NEC Europe Ltd | Registered Office: Athene, Odyssey Business Park, West End=
  Road, London, HA4 6QE, GB | Registered in England 2832014


-----Original Message-----
From: John Parello (jparello) [mailto:jparello@cisco.com]
Sent: Mittwoch, 2. Oktober 2013 16:23
To: Ted Ghose
Cc: Rolf Winter; eman@ietf.org
Subject: Re: [eman] Power States !=3D Charging States?

So I'm seeing we all agree charing states are orthogonal to the current
power states.
That it's reasonable to expect a battery modeled by an Energy Object to
implement power states to show what it is receiving or giving to the
system.

+1 On Bruce's comment in it;s entirety also that we could include the
battery states in power states at some later date.

Rolf I'm not sure I see that the definition of power states does not
cover states of a battery. "A condition or mode that broadly
characterize..power..." does seem to cover if a battery is receving
energy and storing it? Anyone else see this is ok or not?

I did bring up that we call these power states when "energy states" and
"energy interfaces" is more accurate. Would that be more comfortable to
you. ETSI is using Energy States in their liaison with us is the GAL.

I will update 9.1.4 according to this thread an lets see how that rolls.

Jp

Sent from my iPad
(expect ridiculous spelling mistakes)

On Oct 2, 2013, at 6:56 AM, "Ted Ghose" > wrote:

> We still need to know know the amount of power battery is receiving
or giving to the system.
>
> How are we addressing that?
>
> I totally agree charging state has nothing to do with it
>
> -tg-
> Sent from my iPhone
>
>> On Oct 2, 2013, at 3:04 AM, "Rolf Winter" >
wrote:
>>
>> Hi,
>>
>> So it seems there is a general agreement that power and charging
states are different. But I am still not sure we need a separate power
state. I think I read two different things so far.
>>
>> 1) introduce a state that shows if it is charging or discharging and
>> how much
>> 2) introduce state which merely indicates whether the battery can be
>> used (either charged or discharged or not)
>>
>> I thought 1 is already covered by the current battery MIB with
charging states and the actual measurements of e.g. the actual current
etc. The same I guess applied to devices which might have a couple of
power states and then actual measurements to quantify energy use.
>>
>> I am not sure about 2 since I have a hard time making a connection
with the definition of power state that we have:
>>
>> A Power State is a condition or mode of a device that broadly
>> characterizes its capabilities, power consumption, and
responsiveness
>> to input.
>>
>> It is more like "availability for use" rather than an actual power
state. That however is currently not covered by the MIB and we can
think about whether we should introduce this.
>>
>> Best,
>>
>> Rolf
>>
>>
>>
>> NEC Europe Ltd | Registered Office: Athene, Odyssey Business Park,
>> West End  Road, London, HA4 6QE, GB | Registered in England 2832014
>>
>>
>>> -----Original Message-----
>>> From: eman-bounces@ietf.org [mailto:eman-=
bounces@ietf.org] On
Behalf
>>> Of Bruce Nordman
>>> Sent: Dienstag, 1. Oktober 2013 21:33
>>> To: joel jaeggli
>>> Cc: Ted Ghose; eman@ietf.org
>>> Subject: Re: [eman] Power States !=3D Charging States?
>>>
>>> I agree with Rolf that the battery charging state is a different
>>> concept from power state.
>>>
>>>
>>> The current charging state entries in the battery MIB document are:
>>>
>>> unknown, charging, fastCharging, maintainingCharge, noCharging, and
>>> discharging.
>>>
>>> It seems plausible to me that over time storage technologies will
>>> evolve so that
>>>
>>> more entries in this list will be desired.  The power state
registry
>>> could then be used as a place to put such additional charging state
>>> sets, in which case it should be stated to cover both power and
>>> charging states.  Or, a second registry just for
>>>
>>> battery states could be created.  Or, states could be added by
>>> updating the battery MIB.
>>>
>>>
>>> Note that a battery can have data only as listed in the battery MIB,
>>> it can only have component data as an energy object, or both.  For
>>> the energy object aspect of batteries, there is a field for the
>>> battery component for power state.  This could be left empty, or
>>> used.  It occurs to me that a battery could be available/in-use,
>>> which I would consider to be On, or not electrically available (for
>>> charging or discharging), which I would consider to be Off (perhaps
>>> for being physically removed, or simply selected to be not
available for use).
>>> IEEE 1621 covers this.
>>>
>>>
>>> Finally, I thought that the battery MIB draft had indications for
>>> battery failure.  This seems like something that could be reported
>>> on in either the charging state or
>>>
>>> power state context.
>>>
>>> --Bruce
>>>
>>>
>>>
>>> On Tue, Oct 1, 2013 at 8:40 AM, joel jaeggli >
wrote:
>>>
>>>
>>>
>>>   On Sep 30, 2013, at 9:09 AM, Benoit Claise >
>>> wrote:
>>>
>>>> Hi Ted,
>>>>> Hi Rolf
>>>>>
>>>>> +1
>>>>>
>>>>> Thanks for clearly articulating the points. I totally agree
>>> the charging state should be orthogonal to power state.
>>>>>
>>>>> My position is that battery should _also_ have power state
>>> indicating if it is receiving power (charging) or giving power to
>>> the electrical network, and how much
>>>> That makes sense.
>>>>
>>>> Regards, Benoit
>>>
>>>
>>>   In my limited experience with battery controllers batteries are
>>> either:
>>>
>>>   charging
>>>   discharging
>>>   full
>>>   empty
>>>
>>>   in all cases  state of charge, e.g. capacity is germain.
>>>
>>>
>>>>>
>>>>> This will be useful to account for all the power source and
>>> sink
>>>>>
>>>>> Best
>>>>>
>>>>> -tg-
>>>>> Sent from my iPhone
>>>>>
>>>>>> On Sep 25, 2013, at 6:18 AM, Rolf Winter
>>> > wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> this thread attempts to close an open issue in the framework
>>> document (v10) where section 9.1.4 reads:
>>>>>>
>>>>>> 9.1.4. Batteries Power State Set
>>>>>>
>>>>>>       Batteries have operational and administrational states
>>> that
>>>>>>       could be represented as a power state set. Since the
>>> work
>>>>>>       for battery management is parallel to this document,
>>> we are
>>>>>>       not proposing any Power State Sets for batteries at
>>> this
>>>>>>       time.
>>>>>>
>>>>>> I argue that batteries have no power states given the power
>>> state definition:
>>>>>>
>>>>>>       A Power State is a condition or mode of a device that
>>>>>>       broadly characterizes its capabilities, power
>>>>>>       consumption, and responsiveness to input.
>>>>>>
>>>>>> There are charging states currently defined in the battery
>>> MIB, which seem to be orthogonal to power states. I guess a
>>> universal power state set is "on" and "off". Any device can really
>>> be in one of these two modes. Even a simple light bulb. What would
>>> be "on" for a battery? Maybe charging because it receives energy
>>> (like any other device that is actually "on")? But every device
that
>>> is on, fulfills its primary function. I would argue that the
primary
>>> function of a battery is to provide energy. Batteries are different
>>> and I maybe we should ack this fact and not try to create battery
>>> power state sets just because we have this for devices.
>>>>>>
>>>>>> I think the Email thread http://www.ietf.org/mail-
>>> archive/web/eman/current/msg02000.html seemed to agree that
charging
>>> states and power states are orthogonal. If they are, why should
they
>>> be of the same class? The problem is that the power state above as
>>> used for devices would suggest that if a device is off, it does not
>>> consume any energy. But if the battery is charging, then it does
>>> (given that the battery is modeled as part of the device). So if a
>>> power state is indeed conflating power consumption and capabilities,
>>> then a device would be in two different power states at the same
time. But it is not.
>>> It is in one power state and the batteries in it are in a certain
>>> charging state and each of these can be freely combined. I.e.
>>> charging/on, discharging/on, charging/off etc... I guess the main
>>> question is, what is the advantage of defining a charging state as
a
>>> power state (the set of charging states as a power state set)?
>>>>>>
>>>>>>
>>>>>> Best,
>>>>>>
>>>>>> Rolf
>>>>>>
>>>>>> NEC Europe Ltd | Registered Office: Athene, Odyssey Business
>>> Park, West End  Road, London, HA4 6QE, GB | Registered in England
>>> 2832014
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> eman mailing list
>>>>>> eman@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/eman
>>>>> _______________________________________________
>>>>> eman mailing list
>>>>> eman@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/eman
>>>>> .
>>>>
>>>>
>>>> _______________________________________________
>>>> eman mailing list
>>>> eman@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/eman
>>>
>>>
>>>
>>>   _______________________________________________
>>>   eman mailing list
>>>   eman@ietf.org
>>>   https://www.ietf.org/mailman/listinfo/eman
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Bruce Nordman
>>> Lawrence Berkeley National Laboratory nordman.lbl.gov
>>> BNordman@LBL.gov
>>> 510-486-7089
>>> m: 510-501-7943
>
> _______________________________________________
> eman mailing list
> eman@ietf.org
> https://www.ietf.org/mailman/listinfo/eman
_______________________________________________
eman mailing list
eman@ietf.org
https://www.ietf.org/mailman/listinfo/eman


--_000_852AF0ED49D9F24BBBFA1B4DEEBE3BA42ADB79B2xmbrcdx08ciscoc_
Content-Type: text/html; charset="us-ascii"
Content-ID: <7B777981F33B364B904844F5E83C7525@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable







Hi,







I would agree with Joel Jaggli's suggestion on battery states -  =
 







http://www.ietf.org/mail-archive/web/eman/current/msg02010.html











charging


discharging


full


Empty







Thanks


Mouli

















Very true. Whether these are power state or more encompassing I like t=
he idea of the registry we came up with and then the devices listing which =
ones they implement.







We've accepted that they do not need to overlap so for me I'd rather b=
roaden the scope of the series and states  like.







(again I prefer energy state but...)


"""


A Power State is a condition or mode of a device that broadly


characterizes its capabilities, power, and function


"""







That would cover charging states?







So a device could implement:







Series:







[0] IEEE:  on, off, sleep


[1] BATTERY: unknown, charging, fastCharging, maintainingCharge, noCha=
rging, discharging







If could also be modeled as a device with a battery component each wit=
h one series.







Jp

















________________________________________


From: Rolf Winter [Rolf.Winte=
r@neclab.eu]


Sent: Tuesday, October 08, 2013 9:29 AM


To: John Parello (jparello); Ted Ghose



Subject: RE: [eman] Power States !=3D Charging States?







Hi John,







when you snip text out of a definition I think you can make anything f=
it that defintion. But you snipped important things like the "consumpt=
ion" bit after "power" or "responsiveness to input"=
;.







Best,







Rolf







NEC Europe Ltd | Registered Office: Athene, Odyssey Business Park, Wes=
t End  Road, London, HA4 6QE, GB | Registered in England 2832014<=
/div>













-----Original Message-----


From: John Parello (jparello) [m=
ailto:jparello@cisco.com]


Sent: Mittwoch, 2. Oktober 2013 16:23


To: Ted Ghose


Cc: Rolf Winter; eman@ietf.org

Subject: Re: [eman] Power States !=3D Charging States?







So I'm seeing we all agree charing states are orthogonal to the curren=
t


power states.


That it's reasonable to expect a battery modeled by an Energy Object t=
o


implement power states to show what it is receiving or giving to the

system.







+1 On Bruce's comment in it;s entirety also that we could include =
the


battery states in power states at some later date.







Rolf I'm not sure I see that the definition of power states does not

cover states of a battery. "A condition or mode that broadly

characterize..power..." does seem to cover if a battery is recevi=
ng


energy and storing it? Anyone else see this is ok or not?







I did bring up that we call these power states when "energy state=
s" and


"energy interfaces" is more accurate. Would that be more com=
fortable to


you. ETSI is using Energy States in their liaison with us is the GAL.<=
/div>






I will update 9.1.4 according to this thread an lets see how that roll=
s.







Jp







Sent from my iPad


(expect ridiculous spelling mistakes)







On Oct 2, 2013, at 6:56 AM, "Ted Ghose" <tghose@juniper.net> wrote:







> We still need to know know the amount of power battery is receivi=
ng


or giving to the system.


>


> How are we addressing that?


>


> I totally agree charging state has nothing to do with it


>


> -tg-


> Sent from my iPhone


>


>> On Oct 2, 2013, at 3:04 AM, "Rolf Winter" <Rolf.Winter@neclab.eu>


wrote:


>>


>> Hi,


>>


>> So it seems there is a general agreement that power and charg=
ing


states are different. But I am still not sure we need a separate power=



state. I think I read two different things so far.


>>


>> 1) introduce a state that shows if it is charging or discharg=
ing and


>> how much


>> 2) introduce state which merely indicates whether the battery=
 can be


>> used (either charged or discharged or not)


>>


>> I thought 1 is already covered by the current battery MIB wit=
h


charging states and the actual measurements of e.g. the actual current=



etc. The same I guess applied to devices which might have a couple of<=
/div>

power states and then actual measurements to quantify energy use.

>>


>> I am not sure about 2 since I have a hard time making a conne=
ction


with the definition of power state that we have:


>>


>> A Power State is a condition or mode of a device that broadly=



>> characterizes its capabilities, power consumption, and


responsiveness


>> to input.


>>


>> It is more like "availability for use" rather than =
an actual power


state. That however is currently not covered by the MIB and we can

think about whether we should introduce this.


>>


>> Best,


>>


>> Rolf


>>


>>


>>


>> NEC Europe Ltd | Registered Office: Athene, Odyssey Business =
Park,


>> West End  Road, London, HA4 6QE, GB | Registered in=
 England 2832014


>>


>>


>>> -----Original Message-----



Behalf


>>> Of Bruce Nordman


>>> Sent: Dienstag, 1. Oktober 2013 21:33


>>> To: joel jaeggli


>>> Cc: Ted Ghose; eman@ietf=
.org


>>> Subject: Re: [eman] Power States !=3D Charging States?

>>>


>>> I agree with Rolf that the battery charging state is a di=
fferent


>>> concept from power state.


>>>


>>>


>>> The current charging state entries in the battery MIB doc=
ument are:


>>>


>>> unknown, charging, fastCharging, maintainingCharge, noCha=
rging, and


>>> discharging.


>>>


>>> It seems plausible to me that over time storage technolog=
ies will


>>> evolve so that


>>>


>>> more entries in this list will be desired.  The=
 power state


registry


>>> could then be used as a place to put such additional char=
ging state


>>> sets, in which case it should be stated to cover both pow=
er and


>>> charging states.  Or, a second registry just fo=
r


>>>


>>> battery states could be created.  Or, states co=
uld be added by


>>> updating the battery MIB.


>>>


>>>


>>> Note that a battery can have data only as listed in the b=
attery MIB,


>>> it can only have component data as an energy object, or b=
oth.  For


>>> the energy object aspect of batteries, there is a field f=
or the


>>> battery component for power state.  This could =
be left empty, or


>>> used.  It occurs to me that a battery could be =
available/in-use,


>>> which I would consider to be On, or not electrically avai=
lable (for


>>> charging or discharging), which I would consider to be Of=
f (perhaps


>>> for being physically removed, or simply selected to be no=
t


available for use).


>>> IEEE 1621 covers this.


>>>


>>>


>>> Finally, I thought that the battery MIB draft had indicat=
ions for


>>> battery failure.  This seems like something tha=
t could be reported


>>> on in either the charging state or


>>>


>>> power state context.


>>>


>>> --Bruce


>>>


>>>


>>>


>>> On Tue, Oct 1, 2013 at 8:40 AM, joel jaeggli <joelja@bogus.com>


wrote:


>>>


>>>


>>>


>>>   On Sep 30, 2013, at 9:09 AM, Benoit Claise &l=
t;bclaise@cisco.com>


>>> wrote:


>>>


>>>> Hi Ted,


>>>>> Hi Rolf


>>>>>


>>>>> +1


>>>>>


>>>>> Thanks for clearly articulating the points. I tot=
ally agree


>>> the charging state should be orthogonal to power state.

>>>>>


>>>>> My position is that battery should _also_ have po=
wer state


>>> indicating if it is receiving power (charging) or giving =
power to


>>> the electrical network, and how much


>>>> That makes sense.


>>>>


>>>> Regards, Benoit


>>>


>>>


>>>   In my limited experience with battery control=
lers batteries are


>>> either:


>>>


>>>   charging


>>>   discharging


>>>   full


>>>   empty


>>>


>>>   in all cases  state of charge, e.g.=
 capacity is germain.


>>>


>>>


>>>>>


>>>>> This will be useful to account for all the power =
source and


>>> sink


>>>>>


>>>>> Best


>>>>>


>>>>> -tg-


>>>>> Sent from my iPhone


>>>>>


>>>>>> On Sep 25, 2013, at 6:18 AM, Rolf Winter


>>>>>>


>>>>>> Hi,


>>>>>>


>>>>>> this thread attempts to close an open issue i=
n the framework


>>> document (v10) where section 9.1.4 reads:


>>>>>>


>>>>>> 9.1.4. Batteries Power State Set


>>>>>>


>>>>>>       Batteries=
 have operational and administrational states


>>> that


>>>>>>       could be =
represented as a power state set. Since the


>>> work


>>>>>>       for batte=
ry management is parallel to this document,


>>> we are


>>>>>>       not propo=
sing any Power State Sets for batteries at


>>> this


>>>>>>       time.

>>>>>>


>>>>>> I argue that batteries have no power states g=
iven the power


>>> state definition:


>>>>>>


>>>>>>       A Power S=
tate is a condition or mode of a device that


>>>>>>       broadly c=
haracterizes its capabilities, power


>>>>>>       consumpti=
on, and responsiveness to input.


>>>>>>


>>>>>> There are charging states currently defined i=
n the battery


>>> MIB, which seem to be orthogonal to power states. I guess=
 a


>>> universal power state set is "on" and "off=
". Any device can really


>>> be in one of these two modes. Even a simple light bulb. W=
hat would


>>> be "on" for a battery? Maybe charging because i=
t receives energy


>>> (like any other device that is actually "on")? =
But every device


that


>>> is on, fulfills its primary function. I would argue that =
the


primary


>>> function of a battery is to provide energy. Batteries are=
 different


>>> and I maybe we should ack this fact and not try to create=
 battery


>>> power state sets just because we have this for devices.

>>>>>>


>>>>>> I think the Email thread http://www.ietf.org/mail-


>>> archive/web/eman/current/msg02000.html seemed to agree th=
at


charging


>>> states and power states are orthogonal. If they are, why =
should


they


>>> be of the same class? The problem is that the power state=
 above as


>>> used for devices would suggest that if a device is off, i=
t does not


>>> consume any energy. But if the battery is charging, then =
it does


>>> (given that the battery is modeled as part of the device)=
. So if a


>>> power state is indeed conflating power consumption and ca=
pabilities,


>>> then a device would be in two different power states at t=
he same


time. But it is not.


>>> It is in one power state and the batteries in it are in a=
 certain


>>> charging state and each of these can be freely combined. =
I.e.


>>> charging/on, discharging/on, charging/off etc... I guess =
the main


>>> question is, what is the advantage of defining a charging=
 state as


a


>>> power state (the set of charging states as a power state =
set)?


>>>>>>


>>>>>>


>>>>>> Best,


>>>>>>


>>>>>> Rolf


>>>>>>


>>>>>> NEC Europe Ltd | Registered Office: Athene, O=
dyssey Business


>>> Park, West End  Road, London, HA4 6QE, GB | Reg=
istered in England


>>> 2832014


>>>>>>


>>>>>>


>>>>>> _____________________________________________=
__


>>>>>> eman mailing list




>>>>> _______________________________________________

>>>>> eman mailing list




>>>>> .


>>>>


>>>>


>>>> _______________________________________________


>>>> eman mailing list


>>>> eman@ietf.org


>>>


>>>


>>>


>>>   _____________________________________________=
__


>>>   eman mailing list




>>>


>>>


>>>


>>>


>>>


>>>


>>> --


>>> Bruce Nordman


>>> Lawrence Berkeley National Laboratory nordman.lbl.gov

>>> BNordman@LBL.gov<=
/div>

>>> 510-486-7089


>>> m: 510-501-7943


>


> _______________________________________________


> eman mailing list






_______________________________________________


eman mailing list
















--_000_852AF0ED49D9F24BBBFA1B4DEEBE3BA42ADB79B2xmbrcdx08ciscoc_--

From Rolf.Winter@neclab.eu  Fri Oct 11 00:58:09 2013
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 B5B8521F92E7 for ; Fri, 11 Oct 2013 00:58:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.809
X-Spam-Level: 
X-Spam-Status: No, score=-101.809 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, PLING_QUERY=1.39, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QcCWqXUKMeak for ; Fri, 11 Oct 2013 00:58:02 -0700 (PDT)
Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 5918111E813A for ; Fri, 11 Oct 2013 00:58:00 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 0179B105BCF; Fri, 11 Oct 2013 09:53:49 +0200 (CEST)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de)
Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Cuv3uHriMd7; Fri, 11 Oct 2013 09:53:48 +0200 (CEST)
Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id D9012105B78; Fri, 11 Oct 2013 09:53:38 +0200 (CEST)
Received: from DAPHNIS.office.hd ([169.254.2.16]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Fri, 11 Oct 2013 09:57:49 +0200
From: Rolf Winter 
To: "Mouli Chandramouli (moulchan)" , "eman@ietf.org" 
Thread-Topic: [eman]  Power States != Charging States?
Thread-Index: AQHOxZx3MIkC6RZhc0ap0VUdJ/E8t5nvIWWA
Date: Fri, 11 Oct 2013 07:57:48 +0000
Message-ID: <791AD3077F94194BB2BDD13565B6295D557404D8@DAPHNIS.office.hd>
References: <9C213D38848B89428F46808B16F6F08601664006@xmb-aln-x04.cisco.com> <852AF0ED49D9F24BBBFA1B4DEEBE3BA42ADB79B2@xmb-rcd-x08.cisco.com>
In-Reply-To: <852AF0ED49D9F24BBBFA1B4DEEBE3BA42ADB79B2@xmb-rcd-x08.cisco.com>
Accept-Language: en-US, de-DE
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.7.0.199]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [eman] Power States != Charging States?
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Oct 2013 07:58:09 -0000

Hi,

I would like to disagree. There is an actual reason why we have the followi=
ng in the current battery MIB:

unknown(1),
charging(2),
fastCharging(3),
maintainingCharge(4),
noCharging(5),
discharging(6),
notSet(7)

These are existing charging states. Full and empty are not charging states =
they describe the actual charge (we have that in the MIB)! If new sets that=
 alter the current MIB set are proposed, then I would expect an actual just=
ification. BTW, I didn't read Joel's Email as an proposal to actually chang=
e the MIB definitions.

Best,

Rolf

NEC Europe Ltd | Registered Office: Athene, Odyssey Business Park, West End=
  Road, London, HA4 6QE, GB | Registered in England 2832014


> -----Original Message-----
> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of
> Mouli Chandramouli (moulchan)
> Sent: Donnerstag, 10. Oktober 2013 11:38
> To: eman@ietf.org
> Subject: [eman] Power States !=3D Charging States?
>=20
> Hi,
>=20
> I would agree with Joel Jaggli's suggestion on battery states -
>=20
> http://www.ietf.org/mail-archive/web/eman/current/msg02010.html
>=20
>=20
> charging
> discharging
> full
> Empty
>=20
> Thanks
> Mouli
>=20
>=20
> Very true. Whether these are power state or more encompassing I like
> the idea of the registry we came up with and then the devices listing
> which ones they implement.
>=20
> We've accepted that they do not need to overlap so for me I'd rather
> broaden the scope of the series and states  like.
>=20
> (again I prefer energy state but...)
> """
> A Power State is a condition or mode of a device that broadly
> characterizes its capabilities, power, and function """
>=20
> That would cover charging states?
>=20
> So a device could implement:
>=20
> Series:
>=20
> [0] IEEE:  on, off, sleep
> [1] BATTERY: unknown, charging, fastCharging, maintainingCharge,
> noCharging, discharging
>=20
> If could also be modeled as a device with a battery component each with
> one series.
>=20
> Jp
>=20
>=20
>=20
> ________________________________________
> From: Rolf Winter [Rolf.Winter@neclab.eu]
> Sent: Tuesday, October 08, 2013 9:29 AM
> To: John Parello (jparello); Ted Ghose
> Cc: eman@ietf.org
> Subject: RE: [eman] Power States !=3D Charging States?
>=20
> Hi John,
>=20
> when you snip text out of a definition I think you can make anything
> fit that defintion. But you snipped important things like the
> "consumption" bit after "power" or "responsiveness to input".
>=20
> Best,
>=20
> Rolf
>=20
> NEC Europe Ltd | Registered Office: Athene, Odyssey Business Park, West
> End  Road, London, HA4 6QE, GB | Registered in England 2832014
>=20
>=20
>=20
> 	-----Original Message-----
> 	From: John Parello (jparello) [mailto:jparello@cisco.com]
> 	Sent: Mittwoch, 2. Oktober 2013 16:23
> 	To: Ted Ghose
> 	Cc: Rolf Winter; eman@ietf.org
> 	Subject: Re: [eman] Power States !=3D Charging States?
>=20
> 	So I'm seeing we all agree charing states are orthogonal to the
> current
> 	power states.
> 	That it's reasonable to expect a battery modeled by an Energy
> Object to
> 	implement power states to show what it is receiving or giving to
> the
> 	system.
>=20
> 	+1 On Bruce's comment in it;s entirety also that we could include
> the
> 	battery states in power states at some later date.
>=20
> 	Rolf I'm not sure I see that the definition of power states does
> not
> 	cover states of a battery. "A condition or mode that broadly
> 	characterize..power..." does seem to cover if a battery is
> receving
> 	energy and storing it? Anyone else see this is ok or not?
>=20
> 	I did bring up that we call these power states when "energy
> states" and
> 	"energy interfaces" is more accurate. Would that be more
> comfortable to
> 	you. ETSI is using Energy States in their liaison with us is the
> GAL.
>=20
> 	I will update 9.1.4 according to this thread an lets see how that
> rolls.
>=20
> 	Jp
>=20
> 	Sent from my iPad
> 	(expect ridiculous spelling mistakes)
>=20
> 	On Oct 2, 2013, at 6:56 AM, "Ted Ghose" 
> wrote:
>=20
> 	> We still need to know know the amount of power battery is
> receiving
> 	or giving to the system.
> 	>
> 	> How are we addressing that?
> 	>
> 	> I totally agree charging state has nothing to do with it
> 	>
> 	> -tg-
> 	> Sent from my iPhone
> 	>
> 	>> On Oct 2, 2013, at 3:04 AM, "Rolf Winter"
> 
> 	wrote:
> 	>>
> 	>> Hi,
> 	>>
> 	>> So it seems there is a general agreement that power and
> charging
> 	states are different. But I am still not sure we need a separate
> power
> 	state. I think I read two different things so far.
> 	>>
> 	>> 1) introduce a state that shows if it is charging or
> discharging and
> 	>> how much
> 	>> 2) introduce state which merely indicates whether the battery
> can be
> 	>> used (either charged or discharged or not)
> 	>>
> 	>> I thought 1 is already covered by the current battery MIB with
> 	charging states and the actual measurements of e.g. the actual
> current
> 	etc. The same I guess applied to devices which might have a
> couple of
> 	power states and then actual measurements to quantify energy use.
> 	>>
> 	>> I am not sure about 2 since I have a hard time making a
> connection
> 	with the definition of power state that we have:
> 	>>
> 	>> A Power State is a condition or mode of a device that broadly
> 	>> characterizes its capabilities, power consumption, and
> 	responsiveness
> 	>> to input.
> 	>>
> 	>> It is more like "availability for use" rather than an actual
> power
> 	state. That however is currently not covered by the MIB and we
> can
> 	think about whether we should introduce this.
> 	>>
> 	>> Best,
> 	>>
> 	>> Rolf
> 	>>
> 	>>
> 	>>
> 	>> NEC Europe Ltd | Registered Office: Athene, Odyssey Business
> Park,
> 	>> West End  Road, London, HA4 6QE, GB | Registered in England
> 2832014
> 	>>
> 	>>
> 	>>> -----Original Message-----
> 	>>> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On
> 	Behalf
> 	>>> Of Bruce Nordman
> 	>>> Sent: Dienstag, 1. Oktober 2013 21:33
> 	>>> To: joel jaeggli
> 	>>> Cc: Ted Ghose; eman@ietf.org
> 	>>> Subject: Re: [eman] Power States !=3D Charging States?
> 	>>>
> 	>>> I agree with Rolf that the battery charging state is a
> different
> 	>>> concept from power state.
> 	>>>
> 	>>>
> 	>>> The current charging state entries in the battery MIB
> document are:
> 	>>>
> 	>>> unknown, charging, fastCharging, maintainingCharge,
> noCharging, and
> 	>>> discharging.
> 	>>>
> 	>>> It seems plausible to me that over time storage technologies
> will
> 	>>> evolve so that
> 	>>>
> 	>>> more entries in this list will be desired.  The power state
> 	registry
> 	>>> could then be used as a place to put such additional charging
> state
> 	>>> sets, in which case it should be stated to cover both power
> and
> 	>>> charging states.  Or, a second registry just for
> 	>>>
> 	>>> battery states could be created.  Or, states could be added
> by
> 	>>> updating the battery MIB.
> 	>>>
> 	>>>
> 	>>> Note that a battery can have data only as listed in the
> battery MIB,
> 	>>> it can only have component data as an energy object, or both.
> For
> 	>>> the energy object aspect of batteries, there is a field for
> the
> 	>>> battery component for power state.  This could be left empty,
> or
> 	>>> used.  It occurs to me that a battery could be available/in-
> use,
> 	>>> which I would consider to be On, or not electrically
> available (for
> 	>>> charging or discharging), which I would consider to be Off
> (perhaps
> 	>>> for being physically removed, or simply selected to be not
> 	available for use).
> 	>>> IEEE 1621 covers this.
> 	>>>
> 	>>>
> 	>>> Finally, I thought that the battery MIB draft had indications
> for
> 	>>> battery failure.  This seems like something that could be
> reported
> 	>>> on in either the charging state or
> 	>>>
> 	>>> power state context.
> 	>>>
> 	>>> --Bruce
> 	>>>
> 	>>>
> 	>>>
> 	>>> On Tue, Oct 1, 2013 at 8:40 AM, joel jaeggli
> 
> 	wrote:
> 	>>>
> 	>>>
> 	>>>
> 	>>>   On Sep 30, 2013, at 9:09 AM, Benoit Claise
> 
> 	>>> wrote:
> 	>>>
> 	>>>> Hi Ted,
> 	>>>>> Hi Rolf
> 	>>>>>
> 	>>>>> +1
> 	>>>>>
> 	>>>>> Thanks for clearly articulating the points. I totally agree
> 	>>> the charging state should be orthogonal to power state.
> 	>>>>>
> 	>>>>> My position is that battery should _also_ have power state
> 	>>> indicating if it is receiving power (charging) or giving
> power to
> 	>>> the electrical network, and how much
> 	>>>> That makes sense.
> 	>>>>
> 	>>>> Regards, Benoit
> 	>>>
> 	>>>
> 	>>>   In my limited experience with battery controllers batteries
> are
> 	>>> either:
> 	>>>
> 	>>>   charging
> 	>>>   discharging
> 	>>>   full
> 	>>>   empty
> 	>>>
> 	>>>   in all cases  state of charge, e.g. capacity is germain.
> 	>>>
> 	>>>
> 	>>>>>
> 	>>>>> This will be useful to account for all the power source and
> 	>>> sink
> 	>>>>>
> 	>>>>> Best
> 	>>>>>
> 	>>>>> -tg-
> 	>>>>> Sent from my iPhone
> 	>>>>>
> 	>>>>>> On Sep 25, 2013, at 6:18 AM, Rolf Winter
> 	>>>  wrote:
> 	>>>>>>
> 	>>>>>> Hi,
> 	>>>>>>
> 	>>>>>> this thread attempts to close an open issue in the
> framework
> 	>>> document (v10) where section 9.1.4 reads:
> 	>>>>>>
> 	>>>>>> 9.1.4. Batteries Power State Set
> 	>>>>>>
> 	>>>>>>       Batteries have operational and administrational
> states
> 	>>> that
> 	>>>>>>       could be represented as a power state set. Since the
> 	>>> work
> 	>>>>>>       for battery management is parallel to this document,
> 	>>> we are
> 	>>>>>>       not proposing any Power State Sets for batteries at
> 	>>> this
> 	>>>>>>       time.
> 	>>>>>>
> 	>>>>>> I argue that batteries have no power states given the
> power
> 	>>> state definition:
> 	>>>>>>
> 	>>>>>>       A Power State is a condition or mode of a device
> that
> 	>>>>>>       broadly characterizes its capabilities, power
> 	>>>>>>       consumption, and responsiveness to input.
> 	>>>>>>
> 	>>>>>> There are charging states currently defined in the battery
> 	>>> MIB, which seem to be orthogonal to power states. I guess a
> 	>>> universal power state set is "on" and "off". Any device can
> really
> 	>>> be in one of these two modes. Even a simple light bulb. What
> would
> 	>>> be "on" for a battery? Maybe charging because it receives
> energy
> 	>>> (like any other device that is actually "on")? But every
> device
> 	that
> 	>>> is on, fulfills its primary function. I would argue that the
> 	primary
> 	>>> function of a battery is to provide energy. Batteries are
> different
> 	>>> and I maybe we should ack this fact and not try to create
> battery
> 	>>> power state sets just because we have this for devices.
> 	>>>>>>
> 	>>>>>> I think the Email thread http://www.ietf.org/mail-
> 	>>> archive/web/eman/current/msg02000.html seemed to agree that
> 	charging
> 	>>> states and power states are orthogonal. If they are, why
> should
> 	they
> 	>>> be of the same class? The problem is that the power state
> above as
> 	>>> used for devices would suggest that if a device is off, it
> does not
> 	>>> consume any energy. But if the battery is charging, then it
> does
> 	>>> (given that the battery is modeled as part of the device). So
> if a
> 	>>> power state is indeed conflating power consumption and
> capabilities,
> 	>>> then a device would be in two different power states at the
> same
> 	time. But it is not.
> 	>>> It is in one power state and the batteries in it are in a
> certain
> 	>>> charging state and each of these can be freely combined. I.e.
> 	>>> charging/on, discharging/on, charging/off etc... I guess the
> main
> 	>>> question is, what is the advantage of defining a charging
> state as
> 	a
> 	>>> power state (the set of charging states as a power state
> set)?
> 	>>>>>>
> 	>>>>>>
> 	>>>>>> Best,
> 	>>>>>>
> 	>>>>>> Rolf
> 	>>>>>>
> 	>>>>>> NEC Europe Ltd | Registered Office: Athene, Odyssey
> Business
> 	>>> Park, West End  Road, London, HA4 6QE, GB | Registered in
> England
> 	>>> 2832014
> 	>>>>>>
> 	>>>>>>
> 	>>>>>> _______________________________________________
> 	>>>>>> eman mailing list
> 	>>>>>> eman@ietf.org
> 	>>>>>> https://www.ietf.org/mailman/listinfo/eman
> 	>>>>> _______________________________________________
> 	>>>>> eman mailing list
> 	>>>>> eman@ietf.org
> 	>>>>> https://www.ietf.org/mailman/listinfo/eman
> 	>>>>> .
> 	>>>>
> 	>>>>
> 	>>>> _______________________________________________
> 	>>>> eman mailing list
> 	>>>> eman@ietf.org
> 	>>>> https://www.ietf.org/mailman/listinfo/eman
> 	>>>
> 	>>>
> 	>>>
> 	>>>   _______________________________________________
> 	>>>   eman mailing list
> 	>>>   eman@ietf.org
> 	>>>   https://www.ietf.org/mailman/listinfo/eman
> 	>>>
> 	>>>
> 	>>>
> 	>>>
> 	>>>
> 	>>>
> 	>>> --
> 	>>> Bruce Nordman
> 	>>> Lawrence Berkeley National Laboratory nordman.lbl.gov
> 	>>> BNordman@LBL.gov
> 	>>> 510-486-7089
> 	>>> m: 510-501-7943
> 	>
> 	> _______________________________________________
> 	> eman mailing list
> 	> eman@ietf.org
> 	> https://www.ietf.org/mailman/listinfo/eman
>=20
> _______________________________________________
> eman mailing list
> eman@ietf.org
> https://www.ietf.org/mailman/listinfo/eman


From joelja@bogus.com  Fri Oct 11 01:31:40 2013
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 2790B21E80C7 for ; Fri, 11 Oct 2013 01:31:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.667
X-Spam-Level: 
X-Spam-Status: No, score=-101.667 tagged_above=-999 required=5 tests=[AWL=-1.058, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, PLING_QUERY=1.39, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iNxh1Du2KCl6 for ; Fri, 11 Oct 2013 01:31:39 -0700 (PDT)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id A070F21E8165 for ; Fri, 11 Oct 2013 01:31:36 -0700 (PDT)
Received: from [192.168.1.11] (c-50-174-18-221.hsd1.ca.comcast.net [50.174.18.221]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r9B8VX15062054 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 11 Oct 2013 08:31:34 GMT (envelope-from joelja@bogus.com)
Content-Type: multipart/signed; boundary="Apple-Mail=_1AC37525-3454-4B30-A6D8-C3CF159FAE1A"; protocol="application/pgp-signature"; micalg=pgp-sha1
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: joel jaeggli 
In-Reply-To: <791AD3077F94194BB2BDD13565B6295D557404D8@DAPHNIS.office.hd>
Date: Fri, 11 Oct 2013 01:31:30 -0700
Message-Id: <4FB7A32D-72C2-436B-93BB-DE6EBD037FFE@bogus.com>
References: <9C213D38848B89428F46808B16F6F08601664006@xmb-aln-x04.cisco.com> <852AF0ED49D9F24BBBFA1B4DEEBE3BA42ADB79B2@xmb-rcd-x08.cisco.com> <791AD3077F94194BB2BDD13565B6295D557404D8@DAPHNIS.office.hd>
To: Rolf Winter 
X-Mailer: Apple Mail (2.1510)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Fri, 11 Oct 2013 08:31:34 +0000 (UTC)
Cc: "eman@ietf.org" 
Subject: Re: [eman] Power States != Charging States?
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Oct 2013 08:31:40 -0000

--Apple-Mail=_1AC37525-3454-4B30-A6D8-C3CF159FAE1A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


On Oct 11, 2013, at 12:57 AM, Rolf Winter  wrote:

> Hi,
>=20
> I would like to disagree. There is an actual reason why we have the =
following in the current battery MIB:
>=20
> unknown(1),
> charging(2),
> fastCharging(3),
> maintainingCharge(4),
> noCharging(5),
> discharging(6),
> notSet(7)
>=20
> These are existing charging states. Full and empty are not charging =
states they describe the actual charge (we have that in the MIB)! If new =
sets that alter the current MIB set are proposed, then I would expect an =
actual justification. BTW, I didn't read Joel's Email as an proposal to =
actually change the MIB definitions.

it wasn't

>=20
> Best,
>=20
> Rolf
>=20
> NEC Europe Ltd | Registered Office: Athene, Odyssey Business Park, =
West End  Road, London, HA4 6QE, GB | Registered in England 2832014
>=20
>=20
>> -----Original Message-----
>> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf =
Of
>> Mouli Chandramouli (moulchan)
>> Sent: Donnerstag, 10. Oktober 2013 11:38
>> To: eman@ietf.org
>> Subject: [eman] Power States !=3D Charging States?
>>=20
>> Hi,
>>=20
>> I would agree with Joel Jaggli's suggestion on battery states -
>>=20
>> http://www.ietf.org/mail-archive/web/eman/current/msg02010.html
>>=20
>>=20
>> charging
>> discharging
>> full
>> Empty
>>=20
>> Thanks
>> Mouli
>>=20
>>=20
>> Very true. Whether these are power state or more encompassing I like
>> the idea of the registry we came up with and then the devices listing
>> which ones they implement.
>>=20
>> We've accepted that they do not need to overlap so for me I'd rather
>> broaden the scope of the series and states  like.
>>=20
>> (again I prefer energy state but...)
>> """
>> A Power State is a condition or mode of a device that broadly
>> characterizes its capabilities, power, and function """
>>=20
>> That would cover charging states?
>>=20
>> So a device could implement:
>>=20
>> Series:
>>=20
>> [0] IEEE:  on, off, sleep
>> [1] BATTERY: unknown, charging, fastCharging, maintainingCharge,
>> noCharging, discharging
>>=20
>> If could also be modeled as a device with a battery component each =
with
>> one series.
>>=20
>> Jp
>>=20
>>=20
>>=20
>> ________________________________________
>> From: Rolf Winter [Rolf.Winter@neclab.eu]
>> Sent: Tuesday, October 08, 2013 9:29 AM
>> To: John Parello (jparello); Ted Ghose
>> Cc: eman@ietf.org
>> Subject: RE: [eman] Power States !=3D Charging States?
>>=20
>> Hi John,
>>=20
>> when you snip text out of a definition I think you can make anything
>> fit that defintion. But you snipped important things like the
>> "consumption" bit after "power" or "responsiveness to input".
>>=20
>> Best,
>>=20
>> Rolf
>>=20
>> NEC Europe Ltd | Registered Office: Athene, Odyssey Business Park, =
West
>> End  Road, London, HA4 6QE, GB | Registered in England 2832014
>>=20
>>=20
>>=20
>> 	-----Original Message-----
>> 	From: John Parello (jparello) [mailto:jparello@cisco.com]
>> 	Sent: Mittwoch, 2. Oktober 2013 16:23
>> 	To: Ted Ghose
>> 	Cc: Rolf Winter; eman@ietf.org
>> 	Subject: Re: [eman] Power States !=3D Charging States?
>>=20
>> 	So I'm seeing we all agree charing states are orthogonal to the
>> current
>> 	power states.
>> 	That it's reasonable to expect a battery modeled by an Energy
>> Object to
>> 	implement power states to show what it is receiving or giving to
>> the
>> 	system.
>>=20
>> 	+1 On Bruce's comment in it;s entirety also that we could =
include
>> the
>> 	battery states in power states at some later date.
>>=20
>> 	Rolf I'm not sure I see that the definition of power states does
>> not
>> 	cover states of a battery. "A condition or mode that broadly
>> 	characterize..power..." does seem to cover if a battery is
>> receving
>> 	energy and storing it? Anyone else see this is ok or not?
>>=20
>> 	I did bring up that we call these power states when "energy
>> states" and
>> 	"energy interfaces" is more accurate. Would that be more
>> comfortable to
>> 	you. ETSI is using Energy States in their liaison with us is the
>> GAL.
>>=20
>> 	I will update 9.1.4 according to this thread an lets see how =
that
>> rolls.
>>=20
>> 	Jp
>>=20
>> 	Sent from my iPad
>> 	(expect ridiculous spelling mistakes)
>>=20
>> 	On Oct 2, 2013, at 6:56 AM, "Ted Ghose" 
>> wrote:
>>=20
>> 	> We still need to know know the amount of power battery is
>> receiving
>> 	or giving to the system.
>> 	>
>> 	> How are we addressing that?
>> 	>
>> 	> I totally agree charging state has nothing to do with it
>> 	>
>> 	> -tg-
>> 	> Sent from my iPhone
>> 	>
>> 	>> On Oct 2, 2013, at 3:04 AM, "Rolf Winter"
>> 
>> 	wrote:
>> 	>>
>> 	>> Hi,
>> 	>>
>> 	>> So it seems there is a general agreement that power and
>> charging
>> 	states are different. But I am still not sure we need a separate
>> power
>> 	state. I think I read two different things so far.
>> 	>>
>> 	>> 1) introduce a state that shows if it is charging or
>> discharging and
>> 	>> how much
>> 	>> 2) introduce state which merely indicates whether the battery
>> can be
>> 	>> used (either charged or discharged or not)
>> 	>>
>> 	>> I thought 1 is already covered by the current battery MIB =
with
>> 	charging states and the actual measurements of e.g. the actual
>> current
>> 	etc. The same I guess applied to devices which might have a
>> couple of
>> 	power states and then actual measurements to quantify energy =
use.
>> 	>>
>> 	>> I am not sure about 2 since I have a hard time making a
>> connection
>> 	with the definition of power state that we have:
>> 	>>
>> 	>> A Power State is a condition or mode of a device that broadly
>> 	>> characterizes its capabilities, power consumption, and
>> 	responsiveness
>> 	>> to input.
>> 	>>
>> 	>> It is more like "availability for use" rather than an actual
>> power
>> 	state. That however is currently not covered by the MIB and we
>> can
>> 	think about whether we should introduce this.
>> 	>>
>> 	>> Best,
>> 	>>
>> 	>> Rolf
>> 	>>
>> 	>>
>> 	>>
>> 	>> NEC Europe Ltd | Registered Office: Athene, Odyssey Business
>> Park,
>> 	>> West End  Road, London, HA4 6QE, GB | Registered in England
>> 2832014
>> 	>>
>> 	>>
>> 	>>> -----Original Message-----
>> 	>>> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] =
On
>> 	Behalf
>> 	>>> Of Bruce Nordman
>> 	>>> Sent: Dienstag, 1. Oktober 2013 21:33
>> 	>>> To: joel jaeggli
>> 	>>> Cc: Ted Ghose; eman@ietf.org
>> 	>>> Subject: Re: [eman] Power States !=3D Charging States?
>> 	>>>
>> 	>>> I agree with Rolf that the battery charging state is a
>> different
>> 	>>> concept from power state.
>> 	>>>
>> 	>>>
>> 	>>> The current charging state entries in the battery MIB
>> document are:
>> 	>>>
>> 	>>> unknown, charging, fastCharging, maintainingCharge,
>> noCharging, and
>> 	>>> discharging.
>> 	>>>
>> 	>>> It seems plausible to me that over time storage technologies
>> will
>> 	>>> evolve so that
>> 	>>>
>> 	>>> more entries in this list will be desired.  The power state
>> 	registry
>> 	>>> could then be used as a place to put such additional =
charging
>> state
>> 	>>> sets, in which case it should be stated to cover both power
>> and
>> 	>>> charging states.  Or, a second registry just for
>> 	>>>
>> 	>>> battery states could be created.  Or, states could be added
>> by
>> 	>>> updating the battery MIB.
>> 	>>>
>> 	>>>
>> 	>>> Note that a battery can have data only as listed in the
>> battery MIB,
>> 	>>> it can only have component data as an energy object, or =
both.
>> For
>> 	>>> the energy object aspect of batteries, there is a field for
>> the
>> 	>>> battery component for power state.  This could be left =
empty,
>> or
>> 	>>> used.  It occurs to me that a battery could be available/in-
>> use,
>> 	>>> which I would consider to be On, or not electrically
>> available (for
>> 	>>> charging or discharging), which I would consider to be Off
>> (perhaps
>> 	>>> for being physically removed, or simply selected to be not
>> 	available for use).
>> 	>>> IEEE 1621 covers this.
>> 	>>>
>> 	>>>
>> 	>>> Finally, I thought that the battery MIB draft had =
indications
>> for
>> 	>>> battery failure.  This seems like something that could be
>> reported
>> 	>>> on in either the charging state or
>> 	>>>
>> 	>>> power state context.
>> 	>>>
>> 	>>> --Bruce
>> 	>>>
>> 	>>>
>> 	>>>
>> 	>>> On Tue, Oct 1, 2013 at 8:40 AM, joel jaeggli
>> 
>> 	wrote:
>> 	>>>
>> 	>>>
>> 	>>>
>> 	>>>   On Sep 30, 2013, at 9:09 AM, Benoit Claise
>> 
>> 	>>> wrote:
>> 	>>>
>> 	>>>> Hi Ted,
>> 	>>>>> Hi Rolf
>> 	>>>>>
>> 	>>>>> +1
>> 	>>>>>
>> 	>>>>> Thanks for clearly articulating the points. I totally =
agree
>> 	>>> the charging state should be orthogonal to power state.
>> 	>>>>>
>> 	>>>>> My position is that battery should _also_ have power state
>> 	>>> indicating if it is receiving power (charging) or giving
>> power to
>> 	>>> the electrical network, and how much
>> 	>>>> That makes sense.
>> 	>>>>
>> 	>>>> Regards, Benoit
>> 	>>>
>> 	>>>
>> 	>>>   In my limited experience with battery controllers =
batteries
>> are
>> 	>>> either:
>> 	>>>
>> 	>>>   charging
>> 	>>>   discharging
>> 	>>>   full
>> 	>>>   empty
>> 	>>>
>> 	>>>   in all cases  state of charge, e.g. capacity is germain.
>> 	>>>
>> 	>>>
>> 	>>>>>
>> 	>>>>> This will be useful to account for all the power source =
and
>> 	>>> sink
>> 	>>>>>
>> 	>>>>> Best
>> 	>>>>>
>> 	>>>>> -tg-
>> 	>>>>> Sent from my iPhone
>> 	>>>>>
>> 	>>>>>> On Sep 25, 2013, at 6:18 AM, Rolf Winter
>> 	>>>  wrote:
>> 	>>>>>>
>> 	>>>>>> Hi,
>> 	>>>>>>
>> 	>>>>>> this thread attempts to close an open issue in the
>> framework
>> 	>>> document (v10) where section 9.1.4 reads:
>> 	>>>>>>
>> 	>>>>>> 9.1.4. Batteries Power State Set
>> 	>>>>>>
>> 	>>>>>>       Batteries have operational and administrational
>> states
>> 	>>> that
>> 	>>>>>>       could be represented as a power state set. Since =
the
>> 	>>> work
>> 	>>>>>>       for battery management is parallel to this =
document,
>> 	>>> we are
>> 	>>>>>>       not proposing any Power State Sets for batteries at
>> 	>>> this
>> 	>>>>>>       time.
>> 	>>>>>>
>> 	>>>>>> I argue that batteries have no power states given the
>> power
>> 	>>> state definition:
>> 	>>>>>>
>> 	>>>>>>       A Power State is a condition or mode of a device
>> that
>> 	>>>>>>       broadly characterizes its capabilities, power
>> 	>>>>>>       consumption, and responsiveness to input.
>> 	>>>>>>
>> 	>>>>>> There are charging states currently defined in the =
battery
>> 	>>> MIB, which seem to be orthogonal to power states. I guess a
>> 	>>> universal power state set is "on" and "off". Any device can
>> really
>> 	>>> be in one of these two modes. Even a simple light bulb. What
>> would
>> 	>>> be "on" for a battery? Maybe charging because it receives
>> energy
>> 	>>> (like any other device that is actually "on")? But every
>> device
>> 	that
>> 	>>> is on, fulfills its primary function. I would argue that the
>> 	primary
>> 	>>> function of a battery is to provide energy. Batteries are
>> different
>> 	>>> and I maybe we should ack this fact and not try to create
>> battery
>> 	>>> power state sets just because we have this for devices.
>> 	>>>>>>
>> 	>>>>>> I think the Email thread http://www.ietf.org/mail-
>> 	>>> archive/web/eman/current/msg02000.html seemed to agree that
>> 	charging
>> 	>>> states and power states are orthogonal. If they are, why
>> should
>> 	they
>> 	>>> be of the same class? The problem is that the power state
>> above as
>> 	>>> used for devices would suggest that if a device is off, it
>> does not
>> 	>>> consume any energy. But if the battery is charging, then it
>> does
>> 	>>> (given that the battery is modeled as part of the device). =
So
>> if a
>> 	>>> power state is indeed conflating power consumption and
>> capabilities,
>> 	>>> then a device would be in two different power states at the
>> same
>> 	time. But it is not.
>> 	>>> It is in one power state and the batteries in it are in a
>> certain
>> 	>>> charging state and each of these can be freely combined. =
I.e.
>> 	>>> charging/on, discharging/on, charging/off etc... I guess the
>> main
>> 	>>> question is, what is the advantage of defining a charging
>> state as
>> 	a
>> 	>>> power state (the set of charging states as a power state
>> set)?
>> 	>>>>>>
>> 	>>>>>>
>> 	>>>>>> Best,
>> 	>>>>>>
>> 	>>>>>> Rolf
>> 	>>>>>>
>> 	>>>>>> NEC Europe Ltd | Registered Office: Athene, Odyssey
>> Business
>> 	>>> Park, West End  Road, London, HA4 6QE, GB | Registered in
>> England
>> 	>>> 2832014
>> 	>>>>>>
>> 	>>>>>>
>> 	>>>>>> _______________________________________________
>> 	>>>>>> eman mailing list
>> 	>>>>>> eman@ietf.org
>> 	>>>>>> https://www.ietf.org/mailman/listinfo/eman
>> 	>>>>> _______________________________________________
>> 	>>>>> eman mailing list
>> 	>>>>> eman@ietf.org
>> 	>>>>> https://www.ietf.org/mailman/listinfo/eman
>> 	>>>>> .
>> 	>>>>
>> 	>>>>
>> 	>>>> _______________________________________________
>> 	>>>> eman mailing list
>> 	>>>> eman@ietf.org
>> 	>>>> https://www.ietf.org/mailman/listinfo/eman
>> 	>>>
>> 	>>>
>> 	>>>
>> 	>>>   _______________________________________________
>> 	>>>   eman mailing list
>> 	>>>   eman@ietf.org
>> 	>>>   https://www.ietf.org/mailman/listinfo/eman
>> 	>>>
>> 	>>>
>> 	>>>
>> 	>>>
>> 	>>>
>> 	>>>
>> 	>>> --
>> 	>>> Bruce Nordman
>> 	>>> Lawrence Berkeley National Laboratory nordman.lbl.gov
>> 	>>> BNordman@LBL.gov
>> 	>>> 510-486-7089
>> 	>>> m: 510-501-7943
>> 	>
>> 	> _______________________________________________
>> 	> eman mailing list
>> 	> eman@ietf.org
>> 	> https://www.ietf.org/mailman/listinfo/eman
>>=20
>> _______________________________________________
>> eman mailing list
>> eman@ietf.org
>> https://www.ietf.org/mailman/listinfo/eman
>=20
> _______________________________________________
> eman mailing list
> eman@ietf.org
> https://www.ietf.org/mailman/listinfo/eman
>=20


--Apple-Mail=_1AC37525-3454-4B30-A6D8-C3CF159FAE1A
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iEYEARECAAYFAlJXt2IACgkQ8AA1q7Z/VrL+MwCeMQZ8uIeSGhQm7TLKz69r8DOR
szUAn0esj0IcTx/B61zlL+sVnD8CfMHf
=F1Z6
-----END PGP SIGNATURE-----

--Apple-Mail=_1AC37525-3454-4B30-A6D8-C3CF159FAE1A--

From Rolf.Winter@neclab.eu  Fri Oct 11 07:59:13 2013
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 17B3011E817A for ; Fri, 11 Oct 2013 07:59:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.759
X-Spam-Level: 
X-Spam-Status: No, score=-101.759 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, PLING_QUERY=1.39, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gjCegwiWve1t for ; Fri, 11 Oct 2013 07:59:06 -0700 (PDT)
Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id BB83C11E81F7 for ; Fri, 11 Oct 2013 07:59:04 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id E5B39105BE9; Fri, 11 Oct 2013 16:54:51 +0200 (CEST)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de)
Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bNONr4axAEAY; Fri, 11 Oct 2013 16:54:51 +0200 (CEST)
Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id C9F71105BC7; Fri, 11 Oct 2013 16:54:41 +0200 (CEST)
Received: from DAPHNIS.office.hd ([169.254.2.16]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Fri, 11 Oct 2013 16:58:54 +0200
From: Rolf Winter 
To: "John Parello (jparello)" 
Thread-Topic: [eman] Power States != Charging States?
Thread-Index: Ac658agNBCTPrXG/QuKZUDsu7CoziP//5VmAgAgEsACAAYpKgIAAQNoA//7vG4CAAkR4gIAACDWA//bNg7CAEs5RgP/+lEyQ
Date: Fri, 11 Oct 2013 14:58:53 +0000
Message-ID: <791AD3077F94194BB2BDD13565B6295D557416F2@DAPHNIS.office.hd>
References: <791AD3077F94194BB2BDD13565B6295D55726BC7@DAPHNIS.office.hd>  <5249A238.10500@cisco.com>	 , <791AD3077F94194BB2BDD13565B6295D55727F6E@DAPHNIS.office.hd>, <4C227BE7-1FAE-4DC4-B5A8-2F0CB0D429F1@juniper.net> , <791AD3077F94194BB2BDD13565B6295D55729320@DAPHNIS.office.hd> <9C213D38848B89428F46808B16F6F08601664006@xmb-aln-x04.cisco.com>
In-Reply-To: <9C213D38848B89428F46808B16F6F08601664006@xmb-aln-x04.cisco.com>
Accept-Language: en-US, de-DE
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.7.0.199]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "eman@ietf.org" 
Subject: Re: [eman] Power States != Charging States?
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Oct 2013 14:59:13 -0000

I think we should step back before watering down a definition that made a l=
ot of sense to me. The question is what we want to achieve. I heard some pe=
ople wanted power states _plus_ charging states for a battery. If that is w=
hat we want then what you propose doesn't make a whole lot of sense since a=
 battery can be in two different power states that express very different t=
hings. If we want to use a common registry, I am fine with that but I don't=
 see why we need to alter standard terms for that. If the two are mutually =
exclusive then you won't have a problem. I actually prefer to have a regist=
ry for charging (or power or the two combined in a single registry) states =
since we will potentially see a number of additional charging states in the=
 future as battery technology evolves.

Best,=20

Rolf

NEC Europe Ltd | Registered Office: Athene, Odyssey Business Park, West End=
  Road, London, HA4 6QE, GB | Registered in England 2832014


> -----Original Message-----
> From: John Parello (jparello) [mailto:jparello@cisco.com]
> Sent: Dienstag, 8. Oktober 2013 19:07
> To: Rolf Winter
> Cc: eman@ietf.org
> Subject: RE: [eman] Power States !=3D Charging States?
>=20
> Very true. Whether these are power state or more encompassing I like
> the idea of the registry we came up with and then the devices listing
> which ones they implement.
>=20
> We've accepted that they do not need to overlap so for me I'd rather
> broaden the scope of the series and states  like.
>=20
> (again I prefer energy state but...)
> """
> A Power State is a condition or mode of a device that broadly
> characterizes its capabilities, power, and function """
>=20
> That would cover charging states?
>=20
> So a device could implement:
>=20
> Series:
>=20
> [0] IEEE:  on, off, sleep
> [1] BATTERY: unknown, charging, fastCharging, maintainingCharge,
> noCharging, discharging
>=20
> If could also be modeled as a device with a battery component each with
> one series.
>=20
> Jp
>=20
>=20
>=20
> ________________________________________
> From: Rolf Winter [Rolf.Winter@neclab.eu]
> Sent: Tuesday, October 08, 2013 9:29 AM
> To: John Parello (jparello); Ted Ghose
> Cc: eman@ietf.org
> Subject: RE: [eman] Power States !=3D Charging States?
>=20
> Hi John,
>=20
> when you snip text out of a definition I think you can make anything
> fit that defintion. But you snipped important things like the
> "consumption" bit after "power" or "responsiveness to input".
>=20
> Best,
>=20
> Rolf
>=20
> NEC Europe Ltd | Registered Office: Athene, Odyssey Business Park, West
> End  Road, London, HA4 6QE, GB | Registered in England 2832014
>=20
>=20
> > -----Original Message-----
> > From: John Parello (jparello) [mailto:jparello@cisco.com]
> > Sent: Mittwoch, 2. Oktober 2013 16:23
> > To: Ted Ghose
> > Cc: Rolf Winter; eman@ietf.org
> > Subject: Re: [eman] Power States !=3D Charging States?
> >
> > So I'm seeing we all agree charing states are orthogonal to the
> > current power states.
> > That it's reasonable to expect a battery modeled by an Energy Object
> > to implement power states to show what it is receiving or giving to
> > the system.
> >
> > +1 On Bruce's comment in it;s entirety also that we could include the
> > battery states in power states at some later date.
> >
> > Rolf I'm not sure I see that the definition of power states does not
> > cover states of a battery. "A condition or mode that broadly
> > characterize..power..." does seem to cover if a battery is receving
> > energy and storing it? Anyone else see this is ok or not?
> >
> > I did bring up that we call these power states when "energy states"
> > and "energy interfaces" is more accurate. Would that be more
> > comfortable to you. ETSI is using Energy States in their liaison with
> us is the GAL.
> >
> > I will update 9.1.4 according to this thread an lets see how that
> rolls.
> >
> > Jp
> >
> > Sent from my iPad
> > (expect ridiculous spelling mistakes)
> >
> > On Oct 2, 2013, at 6:56 AM, "Ted Ghose"  wrote:
> >
> > > We still need to know know the amount of power battery is receiving
> > or giving to the system.
> > >
> > > How are we addressing that?
> > >
> > > I totally agree charging state has nothing to do with it
> > >
> > > -tg-
> > > Sent from my iPhone
> > >
> > >> On Oct 2, 2013, at 3:04 AM, "Rolf Winter" 
> > wrote:
> > >>
> > >> Hi,
> > >>
> > >> So it seems there is a general agreement that power and charging
> > states are different. But I am still not sure we need a separate
> power
> > state. I think I read two different things so far.
> > >>
> > >> 1) introduce a state that shows if it is charging or discharging
> > >> and how much
> > >> 2) introduce state which merely indicates whether the battery can
> > >> be used (either charged or discharged or not)
> > >>
> > >> I thought 1 is already covered by the current battery MIB with
> > charging states and the actual measurements of e.g. the actual
> current
> > etc. The same I guess applied to devices which might have a couple of
> > power states and then actual measurements to quantify energy use.
> > >>
> > >> I am not sure about 2 since I have a hard time making a connection
> > with the definition of power state that we have:
> > >>
> > >> A Power State is a condition or mode of a device that broadly
> > >> characterizes its capabilities, power consumption, and
> > responsiveness
> > >> to input.
> > >>
> > >> It is more like "availability for use" rather than an actual power
> > state. That however is currently not covered by the MIB and we can
> > think about whether we should introduce this.
> > >>
> > >> Best,
> > >>
> > >> Rolf
> > >>
> > >>
> > >>
> > >> NEC Europe Ltd | Registered Office: Athene, Odyssey Business Park,
> > >> West End  Road, London, HA4 6QE, GB | Registered in England
> 2832014
> > >>
> > >>
> > >>> -----Original Message-----
> > >>> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On
> > Behalf
> > >>> Of Bruce Nordman
> > >>> Sent: Dienstag, 1. Oktober 2013 21:33
> > >>> To: joel jaeggli
> > >>> Cc: Ted Ghose; eman@ietf.org
> > >>> Subject: Re: [eman] Power States !=3D Charging States?
> > >>>
> > >>> I agree with Rolf that the battery charging state is a different
> > >>> concept from power state.
> > >>>
> > >>>
> > >>> The current charging state entries in the battery MIB document
> are:
> > >>>
> > >>> unknown, charging, fastCharging, maintainingCharge, noCharging,
> > >>> and discharging.
> > >>>
> > >>> It seems plausible to me that over time storage technologies will
> > >>> evolve so that
> > >>>
> > >>> more entries in this list will be desired.  The power state
> > registry
> > >>> could then be used as a place to put such additional charging
> > >>> state sets, in which case it should be stated to cover both power
> > >>> and charging states.  Or, a second registry just for
> > >>>
> > >>> battery states could be created.  Or, states could be added by
> > >>> updating the battery MIB.
> > >>>
> > >>>
> > >>> Note that a battery can have data only as listed in the battery
> > >>> MIB, it can only have component data as an energy object, or both.
> > >>> For the energy object aspect of batteries, there is a field for
> > >>> the battery component for power state.  This could be left empty,
> > >>> or used.  It occurs to me that a battery could be
> > >>> available/in-use, which I would consider to be On, or not
> > >>> electrically available (for charging or discharging), which I
> > >>> would consider to be Off (perhaps for being physically removed,
> or
> > >>> simply selected to be not
> > available for use).
> > >>> IEEE 1621 covers this.
> > >>>
> > >>>
> > >>> Finally, I thought that the battery MIB draft had indications for
> > >>> battery failure.  This seems like something that could be
> reported
> > >>> on in either the charging state or
> > >>>
> > >>> power state context.
> > >>>
> > >>> --Bruce
> > >>>
> > >>>
> > >>>
> > >>> On Tue, Oct 1, 2013 at 8:40 AM, joel jaeggli 
> > wrote:
> > >>>
> > >>>
> > >>>
> > >>>   On Sep 30, 2013, at 9:09 AM, Benoit Claise 
> > >>> wrote:
> > >>>
> > >>>> Hi Ted,
> > >>>>> Hi Rolf
> > >>>>>
> > >>>>> +1
> > >>>>>
> > >>>>> Thanks for clearly articulating the points. I totally agree
> > >>> the charging state should be orthogonal to power state.
> > >>>>>
> > >>>>> My position is that battery should _also_ have power state
> > >>> indicating if it is receiving power (charging) or giving power to
> > >>> the electrical network, and how much
> > >>>> That makes sense.
> > >>>>
> > >>>> Regards, Benoit
> > >>>
> > >>>
> > >>>   In my limited experience with battery controllers batteries are
> > >>> either:
> > >>>
> > >>>   charging
> > >>>   discharging
> > >>>   full
> > >>>   empty
> > >>>
> > >>>   in all cases  state of charge, e.g. capacity is germain.
> > >>>
> > >>>
> > >>>>>
> > >>>>> This will be useful to account for all the power source and
> > >>> sink
> > >>>>>
> > >>>>> Best
> > >>>>>
> > >>>>> -tg-
> > >>>>> Sent from my iPhone
> > >>>>>
> > >>>>>> On Sep 25, 2013, at 6:18 AM, Rolf Winter
> > >>>  wrote:
> > >>>>>>
> > >>>>>> Hi,
> > >>>>>>
> > >>>>>> this thread attempts to close an open issue in the framework
> > >>> document (v10) where section 9.1.4 reads:
> > >>>>>>
> > >>>>>> 9.1.4. Batteries Power State Set
> > >>>>>>
> > >>>>>>       Batteries have operational and administrational states
> > >>> that
> > >>>>>>       could be represented as a power state set. Since the
> > >>> work
> > >>>>>>       for battery management is parallel to this document,
> > >>> we are
> > >>>>>>       not proposing any Power State Sets for batteries at
> > >>> this
> > >>>>>>       time.
> > >>>>>>
> > >>>>>> I argue that batteries have no power states given the power
> > >>> state definition:
> > >>>>>>
> > >>>>>>       A Power State is a condition or mode of a device that
> > >>>>>>       broadly characterizes its capabilities, power
> > >>>>>>       consumption, and responsiveness to input.
> > >>>>>>
> > >>>>>> There are charging states currently defined in the battery
> > >>> MIB, which seem to be orthogonal to power states. I guess a
> > >>> universal power state set is "on" and "off". Any device can
> really
> > >>> be in one of these two modes. Even a simple light bulb. What
> would
> > >>> be "on" for a battery? Maybe charging because it receives energy
> > >>> (like any other device that is actually "on")? But every device
> > that
> > >>> is on, fulfills its primary function. I would argue that the
> > primary
> > >>> function of a battery is to provide energy. Batteries are
> > >>> different and I maybe we should ack this fact and not try to
> > >>> create battery power state sets just because we have this for
> devices.
> > >>>>>>
> > >>>>>> I think the Email thread http://www.ietf.org/mail-
> > >>> archive/web/eman/current/msg02000.html seemed to agree that
> > charging
> > >>> states and power states are orthogonal. If they are, why should
> > they
> > >>> be of the same class? The problem is that the power state above
> as
> > >>> used for devices would suggest that if a device is off, it does
> > >>> not consume any energy. But if the battery is charging, then it
> > >>> does (given that the battery is modeled as part of the device).
> So
> > >>> if a power state is indeed conflating power consumption and
> > >>> capabilities, then a device would be in two different power
> states
> > >>> at the same
> > time. But it is not.
> > >>> It is in one power state and the batteries in it are in a certain
> > >>> charging state and each of these can be freely combined. I.e.
> > >>> charging/on, discharging/on, charging/off etc... I guess the main
> > >>> question is, what is the advantage of defining a charging state
> as
> > a
> > >>> power state (the set of charging states as a power state set)?
> > >>>>>>
> > >>>>>>
> > >>>>>> Best,
> > >>>>>>
> > >>>>>> Rolf
> > >>>>>>
> > >>>>>> NEC Europe Ltd | Registered Office: Athene, Odyssey Business
> > >>> Park, West End  Road, London, HA4 6QE, GB | Registered in England
> > >>> 2832014
> > >>>>>>
> > >>>>>>
> > >>>>>> _______________________________________________
> > >>>>>> eman mailing list
> > >>>>>> eman@ietf.org
> > >>>>>> https://www.ietf.org/mailman/listinfo/eman
> > >>>>> _______________________________________________
> > >>>>> eman mailing list
> > >>>>> eman@ietf.org
> > >>>>> https://www.ietf.org/mailman/listinfo/eman
> > >>>>> .
> > >>>>
> > >>>>
> > >>>> _______________________________________________
> > >>>> eman mailing list
> > >>>> eman@ietf.org
> > >>>> https://www.ietf.org/mailman/listinfo/eman
> > >>>
> > >>>
> > >>>
> > >>>   _______________________________________________
> > >>>   eman mailing list
> > >>>   eman@ietf.org
> > >>>   https://www.ietf.org/mailman/listinfo/eman
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>> --
> > >>> Bruce Nordman
> > >>> Lawrence Berkeley National Laboratory nordman.lbl.gov
> > >>> BNordman@LBL.gov
> > >>> 510-486-7089
> > >>> m: 510-501-7943
> > >
> > > _______________________________________________
> > > eman mailing list
> > > eman@ietf.org
> > > https://www.ietf.org/mailman/listinfo/eman

From jparello@cisco.com  Sun Oct 13 14:51:11 2013
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 65FE421E808E for ; Sun, 13 Oct 2013 14:51:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Level: 
X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hlVuU2xzblOJ for ; Sun, 13 Oct 2013 14:51:09 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 070A521F93FB for ; Sun, 13 Oct 2013 14:51:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=304983; q=dns/txt; s=iport; t=1381701067; x=1382910667; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=08khP+Vb9s93L6D0w6FjLaESvn89yM0hlRsKs4bW1Io=; b=kBZTUQfm32+hQw+fjbYB0Ar3hA7rRGAQvJDGABJM4TQbcOdYuazlDjAy dsabZBZ1aJzArko5nq75Y1pOpin0ISIAP2rttULvpQKrahkrCto5H8m1u 3MpkwUEMLJWKdILSknyWl9J0gq4GtPL1TkmhzwFpTf0k5HvF0Qtej+9jJ U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApsEAPMUW1KtJV2Z/2dsb2JhbADIBw
X-IronPort-AV: E=Sophos;i="4.93,487,1378857600";  d="scan'208,217";a="271647455"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-3.cisco.com with ESMTP; 13 Oct 2013 21:51:06 +0000
Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r9DLp6Ok026536 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sun, 13 Oct 2013 21:51:06 GMT
Received: from xmb-aln-x04.cisco.com ([169.254.9.229]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.004; Sun, 13 Oct 2013 16:51:05 -0500
From: "John Parello (jparello)" 
To: eman mailing list 
Thread-Topic: [eman] draft-ietf-eman-framework-10: WGLC comments
Thread-Index: AQHOwEZ2rLo/iDXsF0u6f1LsNHe1v5nzO8SP
Date: Sun, 13 Oct 2013 21:51:05 +0000
Message-ID: <9C213D38848B89428F46808B16F6F086016678F4@xmb-aln-x04.cisco.com>
References: <52495367.2060106@cisco.com>,<524D7F7A.40904@cisco.com>
In-Reply-To: <524D7F7A.40904@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.21.78.193]
Content-Type: multipart/alternative; boundary="_000_9C213D38848B89428F46808B16F6F086016678F4xmbalnx04ciscoc_"
MIME-Version: 1.0
Subject: Re: [eman] draft-ietf-eman-framework-10: WGLC comments
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 13 Oct 2013 21:51:11 -0000

--_000_9C213D38848B89428F46808B16F6F086016678F4xmbalnx04ciscoc_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,

Responding to the last email in the thread:

I will send a reply / seperate thread for each review labelled by reviewer.

Thanks.
Jp


________________________________
From: eman-bounces@ietf.org [eman-bounces@ietf.org] on behalf of Benoit Cla=
ise (bclaise)
Sent: Thursday, October 03, 2013 7:30 AM
To: eman mailing list
Subject: [eman] draft-ietf-eman-framework-10: WGLC comments

Dear all,

Here is my review.
Sorry for the delay.

     Network Working Group                              J. Parello
     Internet-Draft                                      B. Claise
     Intended Status: Informational             Cisco Systems, Inc.
     Expires: March 23, 2014                          B. Schoening
                                            Independent Consultant
                                                        J. Quittek
                                                    NEC Europe Ltd

                                                September 23, 2013



Energy Management Framework


draft-ietf-eman-framework-10



     Status of this Memo

        This Internet-Draft is submitted in full conformance with
        the provisions of BCP 78 and BCP =
79.

        Internet-Drafts are working documents of the Internet
        Engineering Task Force (IETF), its areas, and its working
        groups.  Note that other groups may also distribute working
        documents as Internet-Drafts.

        Internet-Drafts are draft documents valid for a maximum of
        six months and may be updated, replaced, or obsoleted by
        other documents at any time.  It is inappropriate to use
        Internet-Drafts as reference material or to cite them other
        than as "work in progress."

        The list of current Internet-Drafts can be accessed at
        http://www.ietf.org/ietf/1id-abstracts.txt

        The list of Internet-Draft Shadow Directories can be
        accessed at http://www.ietf.org/shadow.html

        This Internet-Draft will expire on March 23, 2014.













     Claise et al            Expires March 23, 2014        [Page 1]


 
     Internet-Draft              EMAN Framework      September 2013


     Copyright Notice

        Copyright (c) 2013 IETF Trust and the persons identified as
        the document authors. All rights reserved.

        This document is subject to BCP 78 and the IETF Trust's
        Legal Provisions Relating to IETF Documents
        (http://trustee.ietf.org/license-info) in effect on the
        date of publication of this document. Please review these
        documents carefully, as they describe your rights and
        restrictions with respect to this document. Code Components
        extracted from this document must include Simplified BSD
        License text as described in Section 4.e of the Trust Legal
        Provisions and are provided without warranty as described
        in the Simplified BSD License.

     Abstract

        This document defines a framework for providing Energy
        Management for devices and device components within or
        connected to communication networks.  The framework
        presents a physical reference model and information model.
        The information model consists of an Energy Management
        Domain as a set of Energy Objects. Each Energy Object is
        identified, classified and given context.  Energy Objects
        can be monitored and controlled with respect to Power,
        Power State, Energy, Demand, Power Attributes, and Battery.
        Additionally the framework models relationships and
        capabilities between Energy Objects.

On the top of J=FCrgen's feedback on the abstract, I'm wondering: What is a=
 "physical" reference model?























     Claise et al.           Expires March 23, 2014       [Page 2]


 
     Internet-Draft              EMAN Framework      September 2013


     Table of Contents

        1. Introduction........................................... 3
           1.1. Energy Management Documents Overview.............. 4
        2. Terminology............................................ 5
        3. Concerns Specific to Energy Management................ 11
           3.1. Target Devices................................... 11
           3.2. Physical Reference Model......................... 12
           3.3. Concerns Differing from Network Management....... 13
           3.4. Concerns Not Addressed........................... 14
        4. Energy Management Abstraction......................... 14
           4.1. Conceptual Model................................. 15
           4.2. Energy Object.................................... 15
           4.3. Energy Object Attributes......................... 16
           4.4. Measurements..................................... 19
           4.5. Control.......................................... 21
           4.6. Relationships.................................... 26
        5. Energy Management Information Model................... 30
        6. Modeling Relationships between Devices................ 34
           6.1. Power Source Relationship........................ 34
           6.2. Metering Relationship............................ 37
           6.3. Aggregation Relationship......................... 39
        7. Relationship to Other Standards....................... 40
        8. Security Considerations............................... 40
           8.1. Security Considerations for SNMP................. 41
        9. IANA Considerations................................... 42
           9.1. IANA Registration of new Power State Sets........ 42
           9.2. Updating the Registration of .. Power State Sets. 43
        10. References........................................... 43
        11. Acknowledgments...................................... 47


1. Intro=
duction


        Network management is often divided into the five main
        areas defined in the ISO Telecommunications Management
        Network model: Fault, Configuration, Accounting,
        Performance, and Security Management (FCAPS) [X.700].  Not
        covered by this traditional management model is Energy
        Management, which is rapidly becoming a critical area of
        concern worldwide, as seen in [ISO50001].

        This document defines an energy management framework for
        devices within or connected to communication networks.  The
        devices, or components of these devices (such as router
        line cards, fans, disks), can then be monitored and
        controlled.  Monitoring includes measuring power, energy,
        demand, and attributes of power.  Energy control can be
        performed by setting a devices' or components' power state.

power state -> Power State.
Some more instances: be consistent in terms of capitalization in the introd=
uction.



     Claise et al.           Expires March 23, 2014       [Page 3]


 
     Internet-Draft              EMAN Framework      September 2013

        If a device contains batteries, these can also be monitored
        and controlled.

        This framework further describes how to identify, classify
        and provide context for such devices.  While the context
        information is not specific to Energy Management, some
        context attributes are specified in the framework,
        addressing the following use cases: how important is a
        device in terms of its business impact, how should devices
        be grouped for reporting and searching, and how should a
        device role be described.  These context attributes help in
        fault management and impact analysis while controlling the
        power states.  Guidelines for using context for energy
        management are described.

        The framework introduces the concept of a power interface
        that is analogous to a network interface. A power interface
        is defined as an interconnection among devices where energy
        can be provided, received, or both.

        The most basic example of Energy Management is a single
        device reporting information about itself.  In many cases,
        however, energy is not measured by the device itself, but
        measured upstream in the power distribution tree.  For
        example, a power distribution unit (PDU) may measure the
        energy it supplies to attached devices and report this to
        an energy management system.  Therefore, devices often have
        relationships to other devices or components in the power
        network.  An EnMS (Energy Management System) generally
        requires an understanding of the power topology (who
        provides power to whom), the metering topology (who meters
        whom), and an understanding of the potential aggregation
        (ex: does a meter aggregate values from other devices).


We need to introduce that there are different relationship types, to solve =
the different problems.

        The relationships build on the power interface concept. The
        different relationships among devices and components,
        specified in this document, include: power source
        relationship, metering relationship, and aggregation
        relationship.


1.1. E=
nergy Management Documents Overview


        The EMAN standard provides a set of specifications for
        Energy Management.  This document specifies the framework,
        per the Energy Management requirements specified in [EMAN-
        REQ].

        The applicability statement document [EMAN-AS] includes use
        cases, a cross-reference between existing standards and the


     Claise et al.           Expires March 23, 2014       [Page 4]


 
     Internet-Draft              EMAN Framework      September 2013

        EMAN standard, and a description of this framework's
        relationship to other frameworks.

        The Energy Object Context MIB [EMAN-OBJECT-MIB] specifies
        objects for addressing Energy Object Identification,
        classification, context information, and relationships from
        the point of view of Energy Management.

        The Power and Energy Monitoring MIB [EMAN-MON-MIB]
        specifies objects for monitoring of Power, Energy, Demand,
        Power Attributes, and Power States.

        The Battery Monitoring MIB [EMAN-BATTERY-MIB] defines
        managed objects that provide information on the status of
        batteries in managed devices.


2. Termi=
nology


        The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
        "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
        and "OPTIONAL" in this document are to be interpreted as
        described in RFC-2119 [RFC2119<=
http://tools.ietf.org/html/rfc2119>].

        In this document these words will appear with that
        interpretation   only when in ALL CAPS. Lower case uses of
        these words are not to be    interpreted as carrying RFC-
        2119 significance.

        In this section some terms have a NOTE that is not part of
        the definition itself, but accounts for differences between
        terminologies of different standards organizations or
        further clarifies the definition.

The final agreement on [EMAN-REQ] was http://www.rfc-editor.org/authors/rfc=
6988.txt


   The terms specified in the terminology section are capitalized
   throughout the document; the exceptions are the well-known terms
   "energy" and "power".  These terms are generic and are used in
   generated terms such as "energy-saving", "low-power", etc.

I suggest you do the same.


I searched for a specific term in the terminology section, and realized tha=
t the order is not alphabetical.
A sentence such as: "The terms in the terminology section are not classifie=
d alphabetically, but the order has been chosen to improve the document rea=
diness, with terms building on the top of each others"




        $ Energy Management

Please change the "$" sign for all entries in the terminology section.

          Energy Management is a set of functions for measuring,
          modeling, planning, and optimizing networks to ensure
          that the network and network attached devices use energy
          efficiently and appropriately for the nature of the
          application and the cost constraints of the organization.

          Reference: Adapted from [ITU-T-M-3400]

          NOTES:
          1. Energy management refers to the activities, methods,
          procedures and tools that pertain to measuring, modeling,
          planning, controlling and optimizing the use of energy in
          networked systems [NMF].




     Claise et al.           Expires March 23, 2014       [Page 5]


 
     Internet-Draft              EMAN Framework      September 2013

          2. Energy Management is a management domain which is
          congruent to any of the FCAPS areas of management in the
          ISO/OSI Network Management Model [TMN]. Energy Management
          for communication networks and attached devices is a
          subset or part of an organization's greater Energy
          Management Policies.

        $ Energy Management System (EnMS)
          An Energy Management System is a combination of hardware
          and software used to administer a network with the
          primary purpose of energy management.

          NOTES:
          1. An Energy Management System according to [ISO50001]
          (ISO-EnMS) is a set of systems or procedures upon which
          organizations can develop and implement an energy policy,
          set targets, action plans and take into account legal
          requirements related to energy use.  An ISO-EnMS allows
          organizations to improve energy performance and
          demonstrate conformity to requirements, standards, and/or
          legal requirements.

          2. Example ISO-EnMS:  Company A defines a set of policies
          and procedures indicating there should exist multiple
          computerized systems that will poll energy measurements
          from their meters and pricing / source data from their
          local utility. Company A specifies that their CFO (Chief
          Financial Officer) should collect information and
          summarize it quarterly to be sent to an accounting firm
          to produce carbon accounting reporting as required by
          their local government.

          3. For the purposes of EMAN, the definition herein is the
          preferred meaning of an Energy Management System (EnMS).
          The definition from [ISO50001] can be referred to as ISO
          Energy Management System (ISO-EnMS).

        $ Energy Monitoring
          Energy Monitoring is a part of Energy Management that
          deals with collecting or reading information from Energy
          Objects to aid in Energy Management.

        $ Energy Control
          Energy Control is a part of Energy Management that deals
          with directing influence over Energy Objects.

        $ Electrical Equipment
          A general term including materials, fittings, devices,
          appliances, fixtures, apparatus, machines, etc., used as


     Claise et al.           Expires March 23, 2014       [Page 6]


 
     Internet-Draft              EMAN Framework      September 2013

          a part of, or in connection with, an electric
          installation.
          Reference: [IEEE100]

        $ Non-Electrical Equipment (Mechanical Equipment)
          A general term including materials, fittings, devices,
          appliances, fixtures, apparatus, machines, etc., used as
          a part of, or in connection with, non-electrical power
          installations.

          Reference: Adapted from [IEEE100]

        $ Device
          A piece of electrical or non-electrical equipment.
          Reference: Adapted from [IEEE100]

        $ Component
          A part of an electrical or non-electrical equipment
          (Device).
          Reference: Adapted from [ITU-T-M-3400]

        $ Power Inlet
          A Power Inlet (or simply inlet) is an interface at which
          a device or component receives energy from another device
          or component.

        $ Power Outlet
          A Power Outlet (or simply outlet) is an interface at
          which a device or component provides energy to another
          device or component.

Are Power Inlets and Power Oulets Power Interfaces?
If yes, the definitions should be changed accordingly


        $ Power Inlet
          A Power Inlet (or simply inlet) is an Power Interface at which
          a device or component receives energy from another device
          or component.



        $ Energy
          That which does work or is capable of doing work. As used
          by electric utilities, it is generally a reference to
          electrical energy and is measured in kilowatt hours
          (kWh).

          Reference: [IEEE100]

          NOTES
          1. Energy is the capacity of a system to produce external
          activity or perform work [ISO50001]

        $ Provide Energy
          A device (or component) "provides" energy to another
          device if there is an energy flow from this device to the
          other one.

        $ Receive Energy


     Claise et al.           Expires March 23, 2014       [Page 7]


 
     Internet-Draft              EMAN Framework      September 2013

          A device (or component) "receives" energy from another
          device if there is an energy flow from the other device
          to this one.

        $ Meter (energy meter)
          a device intended to measure electrical energy by
          integrating power with respect to time.

          Reference: Adapted from [IEC60050]

        $ Battery
          one or more cells (consisting of an assembly of
          electrodes, electrolyte, container, terminals and usually
          separators)  that are a source and/or store of electric
          energy.

          Reference: Adapted from [IEC60050]

        $ Power
          The time rate at which energy is emitted, transferred, or
          received; usually expressed in watts (joules per second).

          Reference: [IEEE100]


        $ Nameplate Power
          The Nameplate Power is the nominal Power of a device as
          specified by the device manufacturer.

s/a device/an Electrical Device?


        $ Power Attributes
          Measurements of the electrical current, voltage, phase
          and frequencies at a given point in an electrical power
          system.
          Reference: Adapted from [IEC60050]

          NOTES:
          1. Power Attributes are not intended to be judgmental
          with respect to a reference or technical value and are
          independent of any usage context.

        $ Power Quality
          Characteristics of the electrical current, voltage, phase
          and frequencies at a given point in an electric power
          system, evaluated against a set of reference technical
          parameters. These parameters might, in some cases, relate
          to the compatibility between electricity supplied in an
          electric power system and the loads connected to that
          electric power system.

          Reference: [IEC60050]


     Claise et al.           Expires March 23, 2014       [Page 8]


 
     Internet-Draft              EMAN Framework      September 2013


          NOTES:
          1. Electrical characteristics representing power quality
          information are typically required by customer facility
          energy management systems. It is not intended to satisfy
          the detailed requirements of power quality monitoring.
          Standards typically also give ranges of allowed values;
          the information attributes are the raw measurements, not
          the "yes/no" determination by the various standards.

          Reference: [ASHRAE-201]

        $ Demand
          The average value of power or a related quantity over a
          specified interval of time. Note: Demand is expressed in
          kilowatts, kilovolt-amperes, kilovars, or other suitable
          units.

          Reference: [IEEE100]

          NOTES:
          1. For EMAN we use kilowatts.

        $ Power State
          A Power State is a condition or mode of a device that
          broadly characterizes its capabilities, power
          consumption, and responsiveness to input.

          Reference: Adapted from [IEEE1621]

        $ Power State Set
          A Power State Set is a collection of Power States that
          comprises a named or logical control grouping.

        $ Energy Object
          An Energy Object (EO) is an information model (class)
          that represents a piece of equipment that is part of, or
          attached to, a communications network which is monitored,
          controlled, or aids in the management of another device
          for Energy Management.

        $ Power Interface
          A Power Interface (or simply interface) is an information
          model (class) that represents the interconnections among
          devices or components where energy can be provided,
          received, or both.

        $ Energy Management Domain



     Claise et al.           Expires March 23, 2014       [Page 9]


 
     Internet-Draft              EMAN Framework      September 2013

          An Energy Management Domain is a set of Energy Objects
          that is considered one unit of management.

        $ Energy Object Identification
          Energy Object Identification is a set of attributes that
          enable an Energy Object to be universally unique or
          linked to other systems.

        $ Energy Object Context
          Energy Object Context is a set of attributes that allow
          an Energy Management System to classify an Energy Object
          within an organization.

        $ Energy Object Relationship
          An Energy Object Relationship is an association among
          Energy Objects.

          NOTES
          1. Relationships can be named and could include
          Aggregation, Metering, and Power Source.
          Reference: Adapted from [CHEN]

        $ Power Source Relationship
          A Power Source Relationship is an Energy Object
          Relationship where one Energy Object provides power to
          one or more Energy Objects. These Energy Objects are
          referred to as having a Power Source Relationship.

        $ Metering Relationship
          A Metering Relationship is an Energy Object Relationship
          where one Energy Object measures power, energy, demand or
          power attributes of one or more other Energy Objects. The
          measuring Energy Object has a Metering Relationship with
          each of the measured objects.

        $ Aggregation Relationship
          An Aggregation Relationship is an Energy Object
          Relationship where one Energy Object aggregates Energy
          Management information of one or more other Energy
          Objects. The aggregating Energy Object has an Aggregation
          Relationship with each of the other Energy Objects.










     Claise et al.           Expires March 23, 2014      [Page 10]


 
     Internet-Draft              EMAN Framework      September 2013



3. Conce=
rns Specific to Energy Management


        This section explains areas of concern for Energy
        Management that do not exist in traditional Network
        Management. This section describes target devices, outlines
        physical reference models, and lists the major concerns

Again "physical" reference model.

        specific to Energy Management.


3.1. T=
arget Devices


        With Energy Management, there exists a wide variety of
        devices that may be contained in the same deployment as
        communication network but comprise a separate facility,
        home, or power distribution network.

        Energy Management has special challenges because a power
        distribution network supplies energy to devices and
        components, while a separate communications network
        monitors and controls the power distribution network.

        The target devices for Energy Management are all devices
        that can be monitored or controlled (directly or
        indirectly) by an Energy Management System (EnMS). These
        target devices include:
           o     Simple electrical appliances and fixtures
           o     Hosts, such as a PC, a server, or a printer
           o     Switches, routers, base stations, and other
              network equipment and middle boxes
           o     Components within devices, such as a battery
              inside a PC, a line card inside a switch, etc.
           o     Power over Ethernet (PoE) endpoints
           o     Power Distribution Units (PDU)
           o     Protocol gateway devices for Building Management
              Systems (BMS)
           o     Electrical meters
           o     Sensor controllers with subtended sensors

I'm confused by the Device definition in the terminology, which is NOT used=
 in this text, while "device" (paragraph above) and "target device" are use=
d


        Target devices will primarily communicate via Internet
        Protocols (IP). The target devices may also include those
        communicating via non-IP protocols deployed among the power
        distribution and IP communication network. These types of
        target devices are expect to be managed through gateways or
        proxies that can communicate using IP.







     Claise et al.           Expires March 23, 2014      [Page 11]


 
     Internet-Draft              EMAN Framework      September 2013



3.2. P=
hysical Reference Model


        The following reference models describe physical power
        topologies that exist in parallel to the communication
        topology. While many more permutations of topologies can be

Permutation of topologies or permutations of elements, which in turn, creat=
e different topologies?
I believe you meant the latter.

        created the following are some basic ones that show how
        Energy Management topologies differ from Network Management
        topologies.

        Basic Energy Management

                               +--------------------------+
                               | Energy Management System |
                               +--------------------------+
                                           ^  ^
                                monitoring |  | control
                                           v  v
                                       +---------+
                                       | device  |
                                       +---------+

        Basic Power Supply

                    +-----------------------------------------+
                    |         energy management system        |
                    +-----------------------------------------+
                          ^  ^                       ^  ^
               monitoring |  | control    monitoring |  | control
                          v  v                       v  v
                    +--------------+        +-----------------+
                    | power supply |########|      device     |
                    +--------------+        +-----------------+



energy management system -> Energy Management System

Pay attention to the terms capitalization in the figures as well. Here, we =
speak about
        device -> Device,
        monitoring -> Energy Monitoring
        control -> Energy Control

You removed the fact that ######## is energy.

Device versus device versus target device?

I'm wondering if we should not add the Power Interfaces in the figures.



        Single Power Supply with Multiple Devices

                      +---------------------------------------+
                      |       energy management system        |
                      +---------------------------------------+
                         ^  ^                       ^  ^
              monitoring |  | control    monitoring |  | control
                         v  v                       v  v
                      +--------+        +------------------+
                      | power  |########|         device 1 |
                      | supply |   #    +------------------+-+
                      +--------+   #######|         device 2 |
                                     #    +------------------+-+
                                     #######|         device 3 |
                                            +------------------+


     Claise et al.           Expires March 23, 2014      [Page 12]


 
     Internet-Draft              EMAN Framework      September 2013


        Multiple Power Supplies with Single Devices

             +----------------------------------------------+
             |          energy management system            |
             +----------------------------------------------+
                 ^  ^              ^  ^              ^  ^
            mon. |  | ctrl.   mon. |  | ctrl.   mon. |  | ctrl.
                 v  v              v  v              v  v
             +----------+      +----------+      +----------+
             | power    |######|  device  |######| power    |
             | supply 1 |######|          |      | supply 2 |
             +----------+      +----------+      +----------+


3.3. C=
oncerns Differing from Network Management


           o  Identification of the power source of a device may be
              independent of the communication network and require
              unique identifiers.

           o  Controlling power for a device may have to be
              fulfilled by addressing the power source as opposed
              to directing control to the device. For example
              controlling a device by controlling the outlet of the
              PDU or controlling a simple light by controlling its
              outlet.

           o  Control of a device may need to be coordinated if
              there are multiple power supplies.

           o  Modeling of power when the flow of energy can be bi-
              directional and require a separate interface model
              from Network Management. For example energy received
              into a battery or energy provided from battery).

           o  Some devices may need out-of-band or proxy
              capabilities to respond to communications request
              even though it is in a non-operational power state.

           o  Estimates and source of measurements may vary among
              devices. For example when devices do not have the
              capability to measure power an estimate can be
              provided from the device or estimated by the EnMS.
              This may require annotation of a measurement.

           o  A device may require a separate abstract model to
              describe its components and interconnections than a
              model used to describe it for Network Management.



     Claise et al.           Expires March 23, 2014      [Page 13]


 
     Internet-Draft              EMAN Framework      September 2013



3.4. C=
oncerns Not Addressed

One line of intro please: "concerns not addressed" is vague
Which concerns? Is "concerns" the right term? Should we have some concerns =
that some concerns are not addressed? :-)
Not addressed by this framework, I guess.
What you want to say is "out of scope of this framework", right?


        Non-Electrical Equipment

        The primary focus of this framework is the management of
        Electrical Equipment.  Some Non-Electrical Equipment may be
        connected to communication networks and could have their
        energy managed if normalized to the electrical units for
        power and energy. Non-
        Electrical equipment that do not convert-to or present-as
        equivalent to Electrical Equipment is not addressed.


        Non-Electrical equipments that do not convert-to or present-as
        equivalent to Electrical Equipments are not addressed.



        Energy Procurement and Manufacturing

        While an EnMS may be a central point for corporate
        reporting, cost computation, environmental impact analysis,
        and regulatory compliance reporting - Energy Management in
        this framework excludes energy procurement and the
        environmental impact of energy use.

        As such the framework does not include:
           o  Cost in currency or environmental units of
              manufacturing a device.
           o  Embedded carbon or environmental equivalences of a
              device
           o  Cost in currency or environmental impact to dismantle
              or recycle a device.
           o  Supply chain analysis of energy sources for device
              deployment
           o  Conversion of the usage or production of energy to
              units expressed from the source of that energy (such
              as the greenhouse gas emissions associated with
              1000kW from a diesel source).


4. Energ=
y Management Abstraction


        Network management is often divided into the five main
        areas defined in the ISO Telecommunications Management
        Network model: Fault, Configuration, Accounting,
        Performance, and Security Management (FCAPS) [X.700].  This
        traditional management model does not cover Energy
        Management.

        This section describes a conceptual model of information
        that can be used for Energy Management. The classes and
        categories of attributes in the model are described with
        rationale for each.


     Claise et al.           Expires March 23, 2014      [Page 14]


 
     Internet-Draft              EMAN Framework      September 2013



4.1. C=
onceptual Model


        This section describes an information model addressing
        issues specific to Energy Management, which complements
        existing Network Management models.

        An information model for Energy Management will need to

No need.

        describe a means to report information, provide control,
        and model the interconnections among physical entities
        (equipment).

interconnections =3D relationships
We introduced the notion of relationships already
Proposal:

        describe a means to report information, provide control,
        and model the relationships among physical entities
        (equipment).

Here, it's physical entities (equipment).
We had already device, Device, target device, Electrical Object
Be consistent.



        Therefore, this section proposes a similar conceptual model
        for physical entities to that used in Network Management:
        devices, components, and interfaces. This section then
        defines the additional attributes specific to Energy
        Management for those entities that are not available in
        existing Network Management models.

        For modeling the physical entities this section describes
        three classes:  a Device, a Component, and a Power
        Interface. These classes are sub-types of an abstract
        Energy Object class.

I finally get it, I think.
You really want to Energy Object to be an (instance of the) Device, Compone=
nt, or Power Interface class in the information model.
The readers start with the terminology and since they don't know you will n=
eed an information model, they're puzzled by the Energy Object definition.
Proposal: whenever you mean the information model class, just mention
    Device Class
    Component Class
    etc.
As you did with the subtitles below.
And no need to define Energy Object in the terminology section. If you real=
ly want, insert the definition in this information model section here, alon=
g with the Device Class definition. Same thing for component.
Btw, the Energy Object is not a class but an instance of the class.


        For modeling additional attributes, this section describes
        attributes of an Energy Object for: identification,
        classification, context, control, power and energy.

        Since the interconnections between physical entities for

interconnection =3D relationship

        Energy Management may have no relation to the
        interconnections for Network Management the Energy Object

interconnection =3D topology

        classes contain a separate Relationships class as an
        attribute to model these types of interconnections.

        The remainder of this section describes the conceptual
        model of the classes and categories of attributes in the
        information model. The formal definitions of the classes
        and attributes are specified in Section 5.


4.2. E=
nergy Object


        An Energy Object is an abstract class that contains the
        base attributes for Energy Management.  There are three
        types of Energy Objects: Device, Component and Power
        Interface.



4.2.1. Device Class




     Claise et al.           Expires March 23, 2014      [Page 15]


 
     Internet-Draft              EMAN Framework      September 2013

        The Device Class is a sub-class of Energy Object that
        represents a physical piece of equipment.

        A Device Class instance may represent a device that is a
        consumer, producer, meter, distributor, or store of energy.

        A Device Class instance may represent a physical device
        that contains other components.


4.2.2. Component Class


        The Component Class is a sub-class of Energy Object that
        represents a part of a physical piece of equipment.


4.2.3. Power Interface Class


        The power interface class is a sub-class of Energy Object
        that represents the interconnection among devices and
        components.

Does it?
It represents the attach point for the relationship. I see later:

        Power Source relationships are intended to identify the
        connections between Power Interfaces.


The Power Interface definition should be improved.

        There are some similarities between Power Interfaces and
        network interfaces.  A network interface can be set to
        different states, such as sending or receiving data on an
        attached line.  Similarly, a Power Interface can be
        receiving or providing power.

        Physically, a Power Interface instance can represent an AC
        power socket, an AC power cord attached to a device, or an
        8P8C (RJ45) PoE socket, etc.


4.3. E=
nergy Object Attributes


        This section describes categories of attributes for an
        Energy Object.


4.3.1. Identification


        A Universal Unique Identifier (UUID) [RFC4122] is used to
        uniquely and persistently identify an Energy Object.
        Ideally the UUID is used to distinguish the Energy Object
        within the EnMS.

        Every Energy Object has an optional unique printable name.
        Possible naming conventions are: textual DNS name, MAC
        address of the device, interface ifName, or a text string
        uniquely identifying the Energy Object.  As an example, in
        the case of IP phones, the Energy Object name can be the
        device's DNS name.




     Claise et al.           Expires March 23, 2014      [Page 16]


 
     Internet-Draft              EMAN Framework      September 2013

        Additionally an alternate key is provided to allow an
        Energy Object to be optionally linked with models in
        different systems.


4.3.2. Context in General


        In order to aid in reporting and in differentiation between
        Energy Objects, each object optionally contains information
        establishing its business, site, or organizational context
        within a deployment.

        Energy Objects contain a category attribute that broadly
        describes how the object is used in a deployment. The
        category indicates if the Energy Object is primarily
        functioning as a consumer, producer, meter, distributor or
        store of energy.

        Given the category and context of an object, an EnMS can
        summarize or analyze measurements. For example, metered
        usage reported by a meter and consumption usage reported by
        a device connected to that meter may measure the same
        usage. With the two measurements identified by category and
        context an EnMS can make summarizations and inferences.

Shouldn't this text be part of 4.3.4?



4.3.3. Context: Importance


        An Energy Object can provide an importance value in the
        range of 1 to 100 to help rank a device's use or relative
        value to the site.  The importance range is from 1 (least
        important) to 100 (most important).  The default importance
        value is 1.

        For example: A typical office environment has several types
        of phones, which can be rated according to their business
        impact.  A public desk phone has a lower importance (for
        example, 10) than a business-critical emergency phone (for
        example, 100).  As another example: A company can consider
        that a PC and a phone for a customer-service engineer are
        more important than a PC and a phone for lobby use.

        Although EnMS and administrators can establish their own
        ranking, the following example is a broad recommendation
        for commercial deployments [CISCO-EW]:

           90 to 100 Emergency response
           80 to 90 Executive or business-critical
           70 to 79 General or Average
           60 to 69 Staff or support
           40 to 59 Public or guest


     Claise et al.           Expires March 23, 2014      [Page 17]


 
     Internet-Draft              EMAN Framework      September 2013

           1  to 39 Decorative or hospitality


4.3.4. Context: Keywords


        An Energy Object can provide a set of keywords.  These
        keywords are a list of tags that can be used for grouping,
        summary reporting within or between Energy Management
        Domains, and for searching.  All alphanumeric characters
        and symbols (other than a comma), such as #, (, $, !, and
        &, are allowed.  Potential examples are: IT, lobby,
        HumanResources, Accounting, StoreRoom, CustomerSpace,
        router, phone, floor2, or SoftwareLab.  There is no default
        value for a keyword.
        Multiple keywords can be assigned to a device.  White
        spaces before and after the commas are excluded, as well as
        within a keyword itself. In such cases, commas separate the
        keywords and no spaces between keywords are allowed.  For
        example, "HR,Bldg1,Private".


4.3.5. Context: Role


        An Energy Object contains a "role description" string that
        indicates the purpose the Energy Object serves in the
        deployment.  This could be a string describing the context
        the device fulfills in deployment.

        Administrators can define any naming scheme for the role of
        a device.  As guidance, a two-word role that combines the
        service the device provides along with type can be used
        [IPENERGY].

        Example types of devices: Router, Switch, Light, Phone,
        WorkStation, Server, Display, Kiosk, HVAC.

        Example Services by Line of Business:

           Line of Business     Service
           Education            Student, Faculty, Administration,
                                Athletic
           Finance              Trader, Teller, Fulfillment
           Manufacturing        Assembly, Control, Shipping
           Retail               Advertising, Cashier
           Support              Helpdesk, Management
           Medical              Patient, Administration, Billing

        Role as a two-word string: "Faculty Desktop", "Teller
        Phone", "Shipping HVAC", "Advertising Display", "Helpdesk
        Kiosk", "Administration Switch".



     Claise et al.           Expires March 23, 2014      [Page 18]


 
     Internet-Draft              EMAN Framework      September 2013


4.3.6. Context: Domain


        An Energy Object contains a string to indicate membership
        in an Energy Management Domain. An Energy Management Domain
        can be any collection of devices in a deployment, but it is
        recommended to map 1:1 with a metered or sub-metered
        portion of the site.

        In building management, a meter refers to the meter
        provided by the utility used for billing and measuring
        power to an entire building or unit within a building.  A
        sub-meter refers to a customer- or user-installed meter
        that is not used by the utility to bill but is instead used
        to get measurements from sub portions of a building.
        An Energy Object should be a member of a single Energy
        Management Domain therefore one attribute is provided.  The
        Energy Management Domain may be configured on an Energy
        Object.


4.4. M=
easurements


        An Energy Object contains attributes to describe power,
        energy and demand measurements.

        For the purposes of this framework, energy will be limited
        to electrical energy in watt-hours.  Other forms of Energy
        Objects that use or produce non-electrical energy may be
        modeled as an Energy Object but must provide information
        converted to and expressed in watt-hours.

        An analogy for understanding power versus energy
        measurements can be made to speed and distance in
        automobiles. Just as a speedometer indicates the rate of
        change of distance (speed), a power measurement indicates
        the rate of transfer of energy. The odometer in an
        automobile measures the cumulative distance traveled and
        similarly an energy measurement indicates the accumulated
        energy transferred.

        Demand measurements are averages of power measurements over
        time. So using the same analogy to an automobile: measuring
        the average vehicle speed over multiple intervals of time
        for a given distance travelled, demand is the average power
        measured over multiple time intervals for a given energy
        value.


4.4.1. Measurements: Power





     Claise et al.           Expires March 23, 2014      [Page 19]


 
     Internet-Draft              EMAN Framework      September 2013

        Each Energy Object contains a Nameplate Power attribute
        that describes the nominal power as specified by the
        manufacturer. The EnMS can use the Nameplate Power for
        provisioning, capacity planning and (potentially) billing.

        Each Energy Object will have information that describes the

In the future, avoid the future tense for future RFCs. :-)

        present power information, along with how that measurement
        was obtained or derived (e.g., actual, estimated, or
        static).

        A power measurement is qualified with the units, magnitude
        and direction of power flow, and is qualified as to the
        means by which the measurement was made.

        Power measurement magnitude conforms to the [IEC61850]
        definition of unit multiplier for the SI (System
        International) units of measure.  Measured values are
        represented in SI units obtained by BaseValue * (10 ^
        Scale).  For example, if current power usage of an Energy
        Object is 3, it could be 3 W, 3 mW, 3 KW, or 3 MW,
        depending on the value of the scaling factor.  3W implies
        that the BaseValue is 3 and Scale =3D 0, whereas 3mW implies
        BaseValue =3D 3 and ScaleFactor =3D -3.

        An Energy Object indicates how the power measurement was
        obtained with a caliber attribute that indicates:
           o  Whether the measurements were made at the device
              itself or at a remote source.
           o  Description of the method that was used to measure
              the power  and whether this method can distinguish
              actual or estimated values.
           o  Accuracy for actual measured values


4.4.2. Measurements: Power Attributes


        Optionally, an Energy Object describes the Power
        measurements with Power Attribute information reflecting
        the electrical characteristics of the measurement. These
        Power Attributes adhere to the [IEC-61850-7-2] standard for
        describing AC measurements.


4.4.3. Measurements: Energy


        Optionally, an Energy Object that can report actual power
        readings will have energy attributes that provide the
        energy used, produced, or stored in kWh.


4.4.4. Measurements: Demand




     Claise et al.           Expires March 23, 2014      [Page 20]


 
     Internet-Draft              EMAN Framework      September 2013

        Optionally, an Energy Object will provide demand
        information over time. Demand measurements can be provided
        when the Energy Object is capable of measuring actual
        power.


4.5. C=
ontrol


        An Energy Object can be controlled by setting a Power
        State.  An Energy Object implements at least one set of
        Power States consisting of at least two states, an on state
        and an off state.

        Each Energy Object should indicate the sets of Power States
        that it implements.

that it supports
This is more precise.

Well-known Power State Sets are
        registered with IANA.

        When a device is set to a particular Power State, it may be
        busy. The device will set the desired Power State and then
        update the actual Power State when it changes.  There are
        then two Power State control variables: actual and
        requested.
        There are many existing standards for and implementations
        of Power States.  An Energy Object can support a mixed set
        of Power States defined in different standards. A basic
        example is given by the three Power States defined in
        IEEE1621 [IEEE1621]: on, off, and sleep. The DMTF [DMTF],
        ACPI [ACPI], and PWG define larger numbers of Power States.

        The semantics of a Power State are specified by
           a) the functionality provided by an Energy Object in
        this state,
           b) a limitation of the power that an Energy Object uses
        in this state,
           c) a combination of a) and b)

        The semantics of a Power State should be clearly defined.
        Limitation (curtailment) of the power used by an Energy
        Object in a state may specified by:
           o  an absolute power value
           o  a percentage value of power relative to the energy
              object's nameplate power
           o  an indication of power relative to another power
              state. For example: Specify that power in state A is
              less than in state B.
           o  For supporting Power State management an Energy
              Object provides statistics on Power States including
              the time an Energy Object spent in a certain Power
              State and the number of times an Energy Object
              entered a power state.


     Claise et al.           Expires March 23, 2014      [Page 21]


 
     Internet-Draft              EMAN Framework      September 2013


        When requesting an Energy Object to enter a Power State an
        indication of the Power State's name or number can be used.
        Optionally an absolute or percentage of Nameplate Power can
        be provided to allow the Energy Object to transition to a
        nearest or equivalent Power State.


4.5.1. Power State Sets


        There are several standards and implementations of Power
        State Sets.  An Energy Object can support one or multiple
        Power State Set implementation(s) concurrently.

        There are currently three Power State Sets advocated:
          IEEE1621(256) - [IEEE1621]
          DMTF(512)     - [DMTF]
          EMAN(768)     - [EMAN-MON-MIB]

        The respective specific states related to each Power State
        Set are specified in the following sections. The guidelines
        for the modification of Power State Sets are specified in
        the IANA Considerations Section.


4.5.2. Power State Set: IEEE1621


        The IEEE1621 Power State Set [IEEE1621] consists of 3
        rudimentary states: on, off or sleep.

           o  on(0)    - The device is fully On and all features of
              the device are in working mode.
           o  off(1)   - The device is mechanically switched off
              and does not consume energy.
           o  sleep(2) - The device is in a power saving mode, and
              some features may not be available immediately.


4.5.3. Power State Set: DMTF


        The DMTF [DMTF] standards organization has defined a power
        profile standard based on the CIM (Common Information
        Model) model that consists of 15 power states:

        {ON (2), SleepLight (3), SleepDeep (4), Off-Hard (5), Off-
        Soft (6), Hibernate(7), PowerCycle Off-Soft (8), PowerCycle
        Off-Hard (9), MasterBus reset (10), Diagnostic Interrupt
        (11), Off-Soft-Graceful (12), Off-Hard Graceful (13),
        MasterBus reset Graceful (14), Power-Cycle Off-Soft
        Graceful (15), PowerCycle-Hard Graceful (16)}




     Claise et al.           Expires March 23, 2014      [Page 22]


 
     Internet-Draft              EMAN Framework      September 2013

        The DMTF standard is targeted for hosts and computers.
        Details of the semantics of each Power State within the
        DMTF Power State Set can be obtained from the DMTF Power
        State Management Profile specification [DMTF].

        The DMTF power profile extends ACPI power states. The
        following table provides a mapping between DMTF and ACPI
        Power State Set:

             DMTF                              ACPI
            Reserved(0)
            Reserved(1)
            ON (2)                             G0-S0
            Sleep-Light (3)                    G1-S1 G1-S2
            Sleep-Deep (4)                     G1-S3
            Power Cycle (Off-Soft) (5)         G2-S5
            Off-hard (6)                       G3
            Hibernate (Off-Soft) (7)           G1-S4
            Off-Soft (8)                       G2-S5
            Power Cycle (Off-Hard) (9)         G3
            Master Bus Reset (10)              G2-S5
            Diagnostic Interrupt (11)          G2-S5
            Off-Soft Graceful (12)             G2-S5
            Off-Hard Graceful (13)             G3
            MasterBus Reset Graceful (14)      G2-S5
            Power Cycle off-soft Graceful (15) G2-S5
            Power Cycle off-hard Graceful (16) G3


4.5.4. Power State Set: IETF EMAN


        An EMAN Power State Set represents an attempt at a standard
        approach for modeling the different levels of power of a
        device.  The EMAN Power States are an expansion of the
        basic Power States as defined in [IEEE1621] that also
        incorporates the Power States defined in [ACPI] and [DMTF].
        Therefore, in addition to the non-operational states as
        defined in [ACPI] and [DMTF] standards, several
        intermediate operational states have been defined.

        An Energy Object may implement fewer or more Power States
        than a particular EMAN Power State Set specifies. In this
        case, the Energy Object implementation can determine its
        own mapping to the predefined EMAN Power States within the
        EMAN Power State Set.

        There are twelve EMAN Power States that expand on
        [IEEE1621]. The expanded list of Power States is derived
        from [CISCO-EW] and is divided into six operational states
        and six non-operational states.


     Claise et al.           Expires March 23, 2014      [Page 23]


 
     Internet-Draft              EMAN Framework      September 2013


        The lowest non-operational state is 1 and the highest is 6.
        Each non-operational state corresponds to an [ACPI] Global
        and System state between G3 (hard-off) and G1 (sleeping).
        Each operational state represents a performance state, and
        may be mapped to [ACPI] states P0 (maximum performance
        power) through P5 (minimum performance and minimum power).

        In each of the non-operational states (from mechoff(1) to
        ready(6)), the Power State preceding it is expected to have
        a lower Power value and a longer delay in returning to an
        operational state:

                 mechoff(1) : An off state where no Energy Object
        features are available.  The Energy Object is unavailable.
        No energy is being consumed and the power connector can be
        removed.

                 softoff(2) : Similar to mechoff(1), but some
        components remain powered or receive trace power so that
        the Energy Object can be awakened from its off state.  In
        softoff(2), no context is saved and the device typically
        requires a complete boot when awakened.

                 hibernate(3): No Energy Object features are
        available.   The Energy Object may be awakened without
        requiring a complete boot, but the time for availability is
        longer than sleep(4). An example for state hibernate(3) is
        a save to-disk state where DRAM context is not maintained.
        Typically, energy consumption is zero or close to zero.

                 sleep(4)    : No Energy Object features are
        available, except for out-of-band management, such as wake-
        up mechanisms.  The time for availability is longer than
        standby(5). An example for state sleep(4) is a save-to-RAM
        state, where DRAM context is maintained.  Typically, energy
        consumption is close to zero.

                 standby(5) : No Energy Object features are
        available, except for out-of-band management, such as wake-
        up mechanisms.  This mode is analogous to cold-standby.
        The time for availability is longer than ready(6).  For
        example processor context is may not be maintained.
        Typically, energy consumption is close to zero.

                 ready(6)    : No Energy Object features are
        available, except for out-of-band management, such as wake-
        up mechanisms. This mode is analogous to hot-standby.  The
        Energy Object can be quickly transitioned into an


     Claise et al.           Expires March 23, 2014      [Page 24]


 
     Internet-Draft              EMAN Framework      September 2013

        operational state.  For example, processors are not
        executing, but processor context is maintained.

                 lowMinus(7) : Indicates some Energy Object
        features may not be available and the Energy Object has
        taken measures or selected options to provide less than
        low(8) usage.

                 low(8)      : Indicates some features may not be
        available and the Energy Object has taken measures or
        selected options to provide less than mediumMinus(9) usage.

                 mediumMinus(9): Indicates all Energy Object
        features are available but the Energy Object has taken
        measures or selected options to provide less than
        medium(10) usage.

                 medium(10)  : Indicates all Energy Object features
        are available but the Energy Object has taken measures or
        selected options to provide less than highMinus(11) usage.
                 highMinus(11): Indicates all Energy Object
        features are available and power usage is less than
        high(12).

                 high(12)    : Indicates all Energy Object features
        are available and the Energy Object is consuming the
        highest power.


4.5.5. Power State Sets Comparison


        A comparison of Power States from different Power State
        Sets can be seen in the following table:
          IEEE1621  DMTF         ACPI           EMAN

          Non-operational states
          off       Off-Hard     G3, S5         MechOff(1)
          off       Off-Soft     G2, S5         SoftOff(2)
          sleep     Hibernate    G1, S4         Hibernate(3)
          sleep     Sleep-Deep   G1, S3         Sleep(4)
          sleep     Sleep-Light  G1, S2         Standby(5)
          sleep     Sleep-Light  G1, S1         Ready(6)

          Operational states:
          on        on           G0, S0, P5     LowMinus(7)
          on        on           G0, S0, P4     Low(8)
          on        on           G0, S0, P3     MediumMinus(9)
          on        on           G0, S0, P2     Medium(10)
          on        on           G0, S0, P1     HighMinus(11)
          on        on           G0, S0, P0     High(12)


     Claise et al.           Expires March 23, 2014      [Page 25]


 
     Internet-Draft              EMAN Framework      September 2013



4.6. R=
elationships


        Two Energy Objects can establish an Energy Object
        Relationship to model the deployment topology with respect
        to Energy Management.

        Relationships are modeled with a Relationship class that
        contains the UUID of the participants in the relationship
        and a description of the type of relationship. The types of
        relationships are:  power source, metering, and
        aggregations.

           o  The Power Source Relationship gives a view of the
              physical wiring topology.  For example: a data center
              server receiving power from two specific Power
              Interfaces from two different PDUs.

              Note: A power source relationship may or may not
              change as the direction of power changes between two
              Energy Objects. The relationship may remain to
              indicate the change of power direction was unintended
              or an error condition.

           o  The Metering Relationship gives the view of the
              metering topology.  Physical meters can be placed
              anywhere in a power distribution tree.  For example,
              utility meters monitor and report accumulated power
              consumption of the entire building. Logically, the
              metering topology overlaps with the wiring topology,
              as meters are connected to the wiring topology.  A
              typical example is meters that clamp onto the
              existing wiring.

           o  The Aggregation Relationship gives a model of devices
              that may aggregate (sum, average, etc) values for
              other devices.  The Aggregation Relationship is
              slightly different compared to the other
              relationships as this refers more to a management
              function.

        In some situations, it is not possible to discover the
        Energy Object Relationships, and they must be set by an
        EnMS or administrator.  Given that relationships can be
        assigned manually, the following sections describes
        guidelines for use.





     Claise et al.           Expires March 23, 2014      [Page 26]


 
     Internet-Draft              EMAN Framework      September 2013


4.6.1. Relationship Conventions and Guidelines


        This Energy Management framework does not impose many
        "MUST" rules related to Energy Object Relationships. There
        are always corner cases that could be excluded with too
        strict specifications of relationships. However, this
        Energy Management framework proposes a series of
        guidelines, indicated with "SHOULD" and "MAY".


4.6.2. Guidelines: Power Source


        Power Source relationships are intended to identify the
        connections between Power Interfaces. This is analogous to
        a Layer 2 connection in networking devices (a "one-hop
        connection").

        The preferred modeling would be for Power Interfaces to
        participate in Power Source Relationships. It some cases
        Energy Objects may not have the capability to model Power
        Interfaces.  Therefore a Power Source Relationship can be
        established between two Energy Objects or two non-connected
        Power Interfaces.

        While strictly speaking Components and Power Interfaces on
        the same device do provide or receive energy from each
        other, the Power Source relationship is intended to show
        energy transfer between Devices. Therefore the relationship
        is implied when on the same Device.

        An Energy Object SHOULD NOT establish a Power Source
        Relationship with a Component.
           o  A Power Source Relationship SHOULD be established
              with the next known Power Interface in the wiring
              topology.

           o  The next known Power Interface in the wiring topology
              would be the next device implementing the framework.
              In some cases the domain of devices under management
              may include some devices that do not implement the
              framework. In these cases, the Power Source
              relationship can be established with the next device
              in the topology that implements the framework and
              logically shows the Power Source of the device.








     Claise et al.           Expires March 23, 2014      [Page 27]


 
     Internet-Draft              EMAN Framework      September 2013

           o  Transitive Power Source relationships SHOULD NOT be
              established.  For example, if an Energy Object A has
              a Power Source Relationship "Poweredby" with the
              Energy Object B, and if the Energy Object B has a
              Power Source Relationship "Poweredby" with the Energy
              Object C, then the Energy Object A SHOULD NOT have a
              Power Source Relationship "Poweredby" with the Energy
              Object C.


4.6.3. Guidelines: Metering Relationship


        Metering Relationships are intended to show when one Device
        acting as a Meter is measuring the power or energy at a
        point in a power distribution system. Since one point of a
        power distribution system may cover many Devices within a
        wiring topology, this relationship type can be seen as an
        arbitrary set.

        Some Devices, however, may include measuring hardware for
        components and Power Interfaces or for the entire Device.
        For example, some PDUs may have the ability to measure
        Power for each Power Interface (metered by outlet). Others
        may be able to control power at each Power Interface but
        can only measure Power at the Power Inlet and a total for
        all Power Interfaces (metered by device).

        While the Metering Relationship SHOULD be used between
        devices, in some cases the Device MAY be modeled as an
        Energy Object that meters all of its Power Outlets and each
        Power Outlet MAY be metered by the Energy Object
        representing the Device.

        In general:
           o  A Metering Relationship MAY be established with any
              other Energy Object, Component, or Power Interface.

           o  Transitive Metering relationships MAY be used.

           o  When there is a series of meters for one Energy
              Object, the Energy Object MAY establish a Metering
              relationship with one or more of the meters.


4.6.4. Guidelines: Aggregation


        Aggregation relationships are intended to identify when one
        device is used to accumulate values from other devices.
        Typically this is for energy or power values among devices
        and not for Components or Power Interfaces on the same
        device.


     Claise et al.           Expires March 23, 2014      [Page 28]


 
     Internet-Draft              EMAN Framework      September 2013


        The intent of Aggregation relationships is to indicate when
        one device is providing aggregate values for a set of other
        devices when it is not obvious from the power source or
        simple containment within a device.

        Establishing aggregation relationships within the same
        device would make modeling more complex and the aggregated
        values can be implied from the use of Power Inlets, outlet
        and Energy Object values on the same device.

        Since an EnMS is naturally a point of aggregation it is not
        necessary to model aggregation for Energy Management
        Systems.

        Aggregation SHOULD be used for power and energy. It MAY be


"Aggregation SHOULD be used for power and energy" is misleading
I guess you mean: "The Aggregation Relationship is intended for power and e=
nergy"

For the rest below.
Section 6 is a series of examples
I'm fine with section 7, 8, and 9 (IANA, which I wrote)

Regards, Benoit


        used for aggregation of other values from the information
        model, but the rules and logical ability to aggregate each
        attribute is out of scope for this document.

        In general:
           o  A Device SHOULD NOT establish an Aggregation
              Relationship with Components contained on the same
              device.
           o  A Device SHOULD NOT establish an Aggregation
              Relationship with the Power Interfaces contained on
              the same device.
           o  A Device SHOULD NOT establish an Aggregation
              Relationship with an EnMS.
           o  Aggregators SHOULD log or provide notification in the
              case of errors or missing values while performing
              aggregation.


4.6.5. Energy Object Relationship Extensions


        This framework for Energy Management is based on three
        relationship types: Aggregation , Metering, and Power
        Source.
        This framework is defined with possible future extension of
        new Energy Object Relationships in mind.
        For example:
           o  Some Devices that may not be IP connected. This can
              be modeled with a proxy relationship to an Energy
              Object within the domain. This type of proxy
              relationship is left for further development.






     Claise et al.           Expires March 23, 2014      [Page 29]


 
     Internet-Draft              EMAN Framework      September 2013

           o  A Power Distribution Unit (PDU) that allows physical
              entities like outlets to be "ganged" together as a
              logical entity for simplified management purposes,
              could be modeled with an extension called a "gang
              relationship", whose semantics would specify the
              Energy Objects' grouping.


5. Energ=
y Management Information Model


        This section presents an information model expression of
        the concepts in this framework as a reference for
        implementers. The information model is implemented as a MIB
        in the different related IETF EMAN documents.  However,
        other programming structures with different data models
        could be used as well.

        Data modeling specifications of this information model may
        where needed specify which attributes are required or
        optional.

        EDITORs NOTE:  The working group is converging on the use
        of code/pseudo-code rather than ascii UML diagram. IF so we
        would have to define priimitve type as reference (eg. Int,
        string, etc)If agreeable we can either indicate a BNF
        syntax in a formal syntax section or use the following
        table if obvious:

        Syntax

          UML Construct
          [ISO-IEC-19501-2005] Equivalent Notation
          -------------------- ------------------------------------
          Notes                // Notes
          Class
          (Generalization)     CLASS name {member..}
          Sub-Class
          (Specialization)     CLASS subclass
                                     EXTENDS superclass {member..}
          Class Member
          (Attribute)          attribute : type











     Claise et al.           Expires March 23, 2014      [Page 30]


 
     Internet-Draft              EMAN Framework      September 2013


        Model

        CLASS EnergyObject {

           // identification / classification
           index        : int
           identifier   : uuid
           alternatekey : string

           // context
           domainName      : string
           role            : string
           keywords [0..n] : string
           importance      : int

           // relationship
           relationships [0..n] : Relationship

           // measurements
           nameplate    : Nameplate
           power     : PowerMeasurement
           energy    : EnergyMeasurment
           demand    : DemandMeasurement

           // control
           powerControl [0..n] : PowerStateSet
        }

        CLASS Device EXTENDS EnergyObject {
              eocategory   : enum { producer, consumer, meter,
        distributor, store }
        }

        CLASS Component EXTENDS EnergyObject
              eocategory   : enum { producer, consumer, meter,
        distributor, store }
        }

        CLASS Interface EXTENDS EnergyObject{
              eoIfType : enum ( inlet, outlet, both}
        }

        CLASS Nameplate {
              nominalPower : PowerMeasurement
              details      : URI
        }




     Claise et al.           Expires March 23, 2014      [Page 31]


 
     Internet-Draft              EMAN Framework      September 2013

        CLASS Relationship {
              relationshipType    : enum { meters, meteredby,
        powers, poweredby, aggregates, aggregatedby }
              relationshipObject  : uuid
        }

        CLASS Measurement {
              multiplier: enum { -24..24}
              caliber   : enum { actual, estimated, static }
              accuracy  : enum { 0..10000} // hundreds of percent
        }

        CLASS PowerMeasurement EXTENDS Measurement {
              value          : long
              units          : "W"
              powerAttribute : PowerAttribute
        }

        CLASS EnergyMeasurement EXTENDS Measurement {
              startTime : time
              units     : "kWh"
              provided  : long
              used      : long
              produced  : long
              stored    : long
        }

        CLASS TimedMeasurement EXTENDS Measurement {
              startTime  : timestamp
              value      : Measurement
              maximum    : Measurement
        }

        CLASS TimeInterval {
              value      : long
              units      : enum { seconds, miliseconds,...}
        }

        CLASS DemandMeasurement EXTENDS Measurement {
              intervalLength : TimeInte
        rval
              interval       : long
              intervalMode   : enum { periodic, sliding, total }
              intervalWindow : TimeInterval
              sampleRate     : TimeInterval
              status         : enum { active, inactive }
              measurements[0..n] : TimedMeasurements
        }



     Claise et al.           Expires March 23, 2014      [Page 32]


 
     Internet-Draft              EMAN Framework      September 2013

        CLASS PowerStateSet {
              powerSetIdentifier : int
              name               : string
              powerStates [0..n] : PowerState
              operState          : int
              adminState         : int
              reason             : string
              configuredTime     : timestamp
        }

        CLASS PowerState {
              powerStateIdentifier  : int
              name             : string
              cardinality      : int
              maximumPower     : PowerMeasurement
              totalTimeInState : time
              entryCount       : long
        }

        CLASS PowerAttribute {

           // container for attributes
                 acQuality   : ACQuality
        }

        CLASS ACQuality {
           acConfiguration : enum {SNGL, DEL,WYE}
           avgVoltage   : long
           avgCurrent   : long
           frequency    : long
           unitMultiplier  : int
           accuracy    : int
           totalActivePower   : long
           totalReactivePower : long
           totalApparentPower : long
           totalPowerFactor : long
           phases [0..2]  : ACPhase
        }

        CLASS ACPhase {
           phaseIndex : long
           avgCurrent : long
           activePower : long
           reactivePower : long
           apparentPower : long
           powerFactor : long
        }




     Claise et al.           Expires March 23, 2014      [Page 33]


 
     Internet-Draft              EMAN Framework      September 2013

        CLASS DelPhase EXTENDS ACPhase {
           phaseToNextPhaseVoltage  : long
           thdVoltage : long
           thdCurrent : long
        }

        CLASS WYEPhase EXTENDS ACPhase {
           phaseToNeutralVoltage : long
           thdCurrent : long
           thdVoltage : long
        }


6. Model=
ing Relationships between Devices


        In this section we give examples of how to use the Energy
        Management framework relationships to model physical
        topologies.  Where applicable, we show how the framework
        can be applied when Devices have the capability to model
        Power Interfaces.  We also show how the framework can be
        applied when devices cannot support Power Interfaces but
        only monitor information or control the Device as a whole.
        For instance, a PDU may only be able to measure power and
        energy for the entire unit without the ability to
        distinguish among the inlets or outlet.


6.1. P=
ower Source Relationship


        The Power Source relationship is used to model the
        interconnections between Devices, Components and/Power
        Interfaces to indicate the source of energy for an Energy
        Object. In the following examples we show variations on
        modeling the reference topologies using relationships.

        Given for all cases:

        Device W: A computer with one power supply. Power interface
        1 is an inlet for Device W.

        Device X: A computer with two power supplies. Power
        interface 1 and power interface 2 are both inlets for
        Device X.

        Device Y: A PDU with multiple Power Interfaces numbered
        0..10. Power interface 0 is an inlet and power interface
        1..10 are outlets.

        Device Z: A PDU with multiple Power Interfaces numbered
        0..10. Power interface 0 is an inlet and power interface
        1..10 are outlets.


     Claise et al.           Expires March 23, 2014      [Page 34]


 
     Internet-Draft              EMAN Framework      September 2013


        Case 1: Simple Device with one Source

        Physical Topology:

           o  Device W inlet 1 is plugged into Device Y outlet 8.

        With Power Interfaces:

           o  Device W has an Energy Object representing the
              computer itself as well as one Power Interface
              defined as an inlet.
           o  Device Y would have an Energy Object representing the
              PDU itself (the Device), with a Power Interface 0
              defined as an inlet and Power Interfaces 1..10
              defined as outlets.

        The interfaces of the devices would have a Power Source
        Relationship such that:
        Device W inlet 1 is powered by Device Y outlet 8.

           +-------+------+       poweredBy +------+----------+
           | PDU Y | PI 8 |-----------------| PI 1 | Device W |
           +-------+------+ powers          +------+----------+

        Without Power Interfaces:

           o  Device W has an Energy Object representing the
              computer.
           o  Device Y would have an Energy Object representing the
              PDU.

        The devices would have a Power Source Relationship such
        that:
        Device W is powered by Device Y.


           +----------+       poweredBy +------------+
           |  PDU Y   |-----------------|  Device W  |
           +----------+ powers          +------------+

        Case 2: Multiple Inlets

        Physical Topology:
           o  Device X inlet 1 is plugged into Device Y outlet 8.
           o  Device X inlet 2 is plugged into Device Y outlet 9.

        With Power Interfaces:


     Claise et al.           Expires March 23, 2014      [Page 35]


 
     Internet-Draft              EMAN Framework      September 2013


           o  Device X has an Energy Object representing the
              computer itself. It contains two Power Interfaces
              defined as inlets.
           o  Device Y would have an Energy Object representing the
              PDU itself (the Device), with a Power Interface 0
              defined as an inlet and Power Interfaces 1..10
              defined as outlets.

        The interfaces of the devices would have a Power Source
        Relationship such that:
        Device X inlet 1 is powered by Device Y outlet 8.
        Device X inlet 2 is powered by Device Y outlet 9.

           +-------+------+        poweredBy+------+----------+
           |       | PI 8 |-----------------| PI 1 |          |
           |       |      |powers           |      |          |
           | PDU Y +------+        poweredBy+------+ Device X |
           |       | PI 9 |-----------------| PI 2 |          |
           |       |      |powers           |      |          |
           +-------+------+                 +------+----------+

        Without Power Interfaces:

           o  Device X has an Energy Object representing the
              computer. Device Y has an Energy Object representing
              the PDU.


        The devices would have a Power Source Relationship such
        that:
        Device X is powered by Device Y.

           +----------+       poweredBy +------------+
           |  PDU Y   |-----------------|  Device X  |
           +----------+ powers          +------------+

        Case 3: Multiple Sources

        Physical Topology:
           o  Device X inlet 1 is plugged into Device Y outlet 8.
           o  Device X inlet 2 is plugged into Device Z outlet 9.

        With Power Interfaces:






     Claise et al.           Expires March 23, 2014      [Page 36]


 
     Internet-Draft              EMAN Framework      September 2013

           o  Device X has an Energy Object representing the
              computer itself. It contains two Power Interface
              defined as inlets.
           o  Device Y would have an Energy Object representing the
              PDU itself  (the Device), with a Power Interface 0
              defined as an inlet and Power Interfaces 1..10
              defined as outlets.
           o  Device Z would have an Energy Object representing the
              PDU itself  (the Device), with a Power Interface 0
              defined as an inlet and Power Interfaces 1..10
              defined as outlets.

        The interfaces of the devices would have a Power Source
        Relationship such that:
        Device X inlet 1 is powered by Device Y outlet 8.
        Device X inlet 2 is powered by Device Z outlet 9.

           +-------+------+        poweredBy+------+----------+
           | PDU Y | PI 8 |-----------------| PI 1 |          |
           |       |      |powers           |      |          |
           +-------+------+                 +------+          |
                                                   | Device X |
           +-------+------+        poweredBy+------+          |
           | PDU Z | PI 9 |-----------------| PI 2 |          |
           |       |      |powers           |      |          |
           +-------+------+                 +------+----------+

        Without Power Interfaces:

           o  Device X has an Energy Object representing the
              computer. Device Y and Z would both have respective
              Energy Objects representing each entire PDU.

        The devices would have a Power Source Relationship such
        that:
        Device X is powered by Device Y and powered by Device Z.

           +----------+           poweredBy +------------+
           |  PDU Y   |---------------------|  Device X  |
           +----------+ powers              +------------+

           +----------+           poweredBy +------------+
           |  PDU Z   |---------------------|  Device X  |
           +----------+ powers              +------------+


6.2. M=
etering Relationship




     Claise et al.           Expires March 23, 2014      [Page 37]


 
     Internet-Draft              EMAN Framework      September 2013

        Case 1: Metering between two Devices

        The metering topology between two devices is closely
        related to the power source topology.  It is based on the
        assumption that in many cases the power provided and the
        power received is the same for both peers of a power source
        relationship.

        We define in this case a Metering Relationship between two
        Devices or Power Interfaces of Devices that have a power
        source relationship.  Power and energy values measured at
        one peer of the power source relationship are reported for
        the other peer as well.

        The Metering Relationship is independent of the direction
        of the Power Source Relationship.  The most common case is
        that values measured at the power provider are reported for
        the power receiver.

        +-----+---+    meteredBy +--------+   poweredBy +-------+
        |Meter| PI|--------------| switch |-------------| phone |
        +-----+---+ meters       +--------+ powers      +-------+
                |                                           |
                |                                 meteredBy |
                +-------------------------------------------+
                 meters

        Case 2: Metering among many Devices

        A Sub-meter in a power distribution system can logically
        measure the
        power or energy for all devices downstream from the meter
        in the power distribution system.  As such, a Power
        metering relationship can be seen as a relationship between
        a meter Device and all of the devices downstream from the
        meter.

        We define in this case a Power Source relationship between
        a metering device and devices downstream from the meter.

        In cases where the Power Source topology cannot be
        discovered or derived from the information available in the
        Energy Management Domain, the Metering Topology can be used
        to relate the upstream meter to the downstream devices in
        the absence of specific power source relationships.

        A Metering Relationship can occur between devices that are
        not directly connected, as shown in the following figure:



     Claise et al.           Expires March 23, 2014      [Page 38]


 
     Internet-Draft              EMAN Framework      September 2013


                           +---------------+
                           |   Device 1    |
                           +---------------+
                           |      PI       |
                           +---------------+
                                   |
                           +---------------+
                           |     Meter     |
                           +---------------+
                                   .
                                   .
                                   .
                  meters        meters           meters
            +----------+   +----------+   +-----------+
            | Device A |   | Device B |   | Device C  |
            +----------+   +----------+   +-----------+

        An analogy to communications networks would be modeling
        connections between servers (meters) and clients (devices)
        when the complete Layer 2 topology between the servers and
        clients is not known.


6.3. A=
ggregation Relationship


        Some devices can act as aggregation points for other
        devices.  For example, a PDU controller device may contain
        the summation of power and energy readings for many PDU
        devices.  The PDU controller will have aggregate values for
        power and energy for a group of PDU devices.

        This aggregation is independent of the physical power or
        communication topology.
        An Aggregation Relationship is an Energy Object
        Relationship where one Energy Object (called the Aggregate
        Energy Object) aggregates the Energy Management information
        of one or more other Energy Objects.  These Energy Objects
        are said to have an Aggregation Relationship.

        The functions that the aggregation point may perform
        include the calculation of values such as average, count,
        maximum, median, minimum, or the listing (collection) of
        the aggregation values, etc.
        Based on the experience gained on aggregations at the IETF
        [draft-ietf-ipfix-a9n-08], the aggregation function in the
        EMAN framework is limited to the summation.

        When aggregation occurs across a set of entities, values to
        be aggregated may be missing for some entities.  The EMAN


     Claise et al.           Expires March 23, 2014      [Page 39]


 
     Internet-Draft              EMAN Framework      September 2013

        framework does not specify how these should be treated, as
        different implementations may have good reason to take
        different approaches.  One common treatment is to define
        the aggregation as missing if any of the constituent
        elements are missing (useful to be most precise). Another
        is to treat the missing value as zero (useful to have
        continuous data streams).

        The specifications of aggregation functions are out of
        scope of the EMAN framework, but must be clearly specified
        by the equipment vendor.


7. Relat=
ionship to Other Standards


        This Energy Management framework uses, as much as possible,
        existing standards especially with respect to information
        modeling and data modeling [RFC3444].

        The data model for power- and energy-related objects is
        based on [IEC61850].

        Specific examples include:
           o  The scaling factor, which represents Energy Object
              usage magnitude, conforms to the [IEC61850]
              definition of unit multiplier for the SI (System
              International) units of measure.
           o  The electrical characteristic is based on the ANSI
              and IEC Standards, which require that we use an
              accuracy class for power measurement.  ANSI and IEC
              define the following accuracy classes for power
              measurement:
           o  IEC 62053-22  60044-1 class 0.1, 0.2, 0.5, 1  3.
           o  ANSI C12.20 class 0.2, 0.5
           o  The electrical characteristics and quality adhere
              closely to the [IEC61850-7-2] standard for describing
              AC measurements.
           o  The power state definitions are based on the DMTF
              Power State Profile and ACPI models, with operational
              state extensions.


8. Secur=
ity Considerations


        Regarding the data attributes specified here, some or all
        may be considered sensitive or vulnerable in some network
        environments. Reading or writing these attributes without
        proper protection such as encryption or access
        authorization may have negative effects on the network
        capabilities.



     Claise et al.           Expires March 23, 2014      [Page 40]


 
     Internet-Draft              EMAN Framework      September 2013


8.1. S=
ecurity Considerations for SNMP


        Readable objects in MIB modules (i.e., objects with a MAX-
        ACCESS other than not-accessible) may be considered
        sensitive or vulnerable in some network environments.  It
        is important to control GET and/or NOTIFY access to these
        objects and possibly to encrypt the values of these objects
        when sending them over the network via SNMP.

        The support for SET operations in a non-secure environment
        without proper protection can have a negative effect on
        network operations.

        For example:
           o  Unauthorized changes to the Energy Management Domain
              or business context of a device may result in
              misreporting or interruption of power.
           o  Unauthorized changes to a power state may disrupt the
              power settings of the different devices, and
              therefore the state of functionality of the
              respective devices.
           o  Unauthorized changes to the demand history may
              disrupt proper accounting of energy usage.

        With respect to data transport, SNMP versions prior to
        SNMPv3 did not include adequate security.  Even if the
        network itself is secure (for example, by using IPsec),
        there is still no secure control over who on the secure
        network is allowed to access and GET/SET
        (read/change/create/delete) the objects in these MIB
        modules.

        It is recommended that implementers consider the security
        features as provided by the SNMPv3 framework (see
        [RFC3410], section 8)=
, including full support for the
        SNMPv3 cryptographic mechanisms (for authentication and
        privacy).
        Further, deployment of SNMP versions prior to SNMPv3 is not
        recommended.  Instead, it is recommended to deploy SNMPv3
        and to enable cryptographic security.  It is then a
        customer/operator responsibility to ensure that the SNMP
        entity giving access to an instance of these MIB modules is
        properly configured to give access to the objects only to
        those principals (users) that have legitimate rights to GET
        or SET (change/create/delete) them.






     Claise et al.           Expires March 23, 2014      [Page 41]


 
     Internet-Draft              EMAN Framework      September 2013


9. IANA =
Considerations


9.1. I=
ANA Registration of new Power State Sets


        This document specifies an initial set of Power State Sets.
        The list of these Power State Sets with their numeric
        identifiers is given is Section 4. IANA maintains the lists
        of Power State Sets.

        New assignments for Power State Set are administered by
        IANA through 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 state for
        completeness and accuracy of the description. A pure vendor
        specific implementation of Power State Set shall not be
        adopted; since it would lead to proliferation of Power
        State Sets.

        Power states in a Power State Set are limited to 255
        distinct values. New Power State Set must be assigned the
        next available numeric identifier that is a multiple of
        256.


9.1.1. IANA Registration of the IEEE1621 Power State Set


        This document specifies a set of values for the IEEE1621
        Power State Set [IEEE1621].  The list of these values with
        their identifiers is given in Section 4.6.2.  IANA created
        a new registry for IEEE1621 Power State Set identifiers and
        filled it with the initial list of identifiers.

        New assignments (or potentially deprecation) for the
        IEEE1621 Power State Set is administered by IANA through
        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 state for completeness and
        accuracy of the description.


9.1.2. IANA Registration of the DMTF Power State Set


        This document specifies a set of values for the DMTF Power
        State Set.  The list of these values with their identifiers
        is given in Section 4. IANA has created a new registry for
        DMTF Power State Set identifiers and filled it with the
        initial list of identifiers.

        New assignments (or potentially deprecation) for the DMTF
        Power State Set is administered by IANA through Expert
        Review [RFC5226], i.e., review =
by one of a group of experts
        designated by an IETF Area Director.  The group of experts


     Claise et al.           Expires March 23, 2014      [Page 42]


 
     Internet-Draft              EMAN Framework      September 2013

        must check the conformance with the DMTF standard [DMTF],
        on the top of checking for completeness and accuracy of the
        description.


9.1.3. IANA Registration of the EMAN Power State Set


        This document specifies a set of values for the EMAN Power
        State Set.  The list of these values with their identifiers
        is given in Section 4.6.4.  IANA has created a new registry
        for EMAN Power State Set identifiers and filled it with the
        initial list of identifiers.

        New assignments (or potentially deprecation) for the EMAN
        Power State Set is administered by IANA through 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 state for completeness and
        accuracy of the description.


9.1.4. Batteries Power State Set


        Batteries have operational and administrational states that
        could be represented as a power state set. Since the work
        for battery management is parallel to this document, we are
        not proposing any Power State Sets for batteries at this
        time.


9.2. U=
pdating the Registration of Existing Power State Sets


        With the evolution of standards, over time, it may be
        important to deprecate some of the existing the Power State
        Sets, or to add or deprecate some Power States within a
        Power State Set.

        The registrant shall publish an Internet-draft or an
        individual submission with the clear specification on
        deprecation of Power State Sets or Power States registered
        with IANA.  The deprecation or addition shall be
        administered by IANA through Expert Review [RFC5226], i.e.,
        review by one of a group of experts designated by an IETF
        Area Director. The process should also allow for a
        mechanism for cases where others have significant
        objections to claims on deprecation of a registration.


10. Ref=
erences


     Normative References




     Claise et al.           Expires March 23, 2014      [Page 43]


 
     Internet-Draft              EMAN Framework      September 2013

        [RFC2119]  Bradner, S., "Key words for use in RFCs to
                  Indicate Requirement Levels", BCP 14, RFC 2119,
                  March 1997

        [RFC3410]  Case, J., Mundy, R., Partain, D., and B.
                  Stewart, "Introduction and Applicability
                  Statements for Internet Standard Management
                  Framework ", RFC 3410=
, December 2002

        [RFC4122] Leach, P., Mealling, M., and R. Salz," A
                  Universally Unique Identifier (UUID) URN
                  Namespace", RFC 4122,=
 July 2005

        [RFC5226] Narten, T., and H. Alvestrand, "Guidelines for
                  Writing an IANA Considerations Section in RFCs",
                  RFC 5226, May 2008

        [RFC6933]  Bierman, A. and K. McCloghrie, "Entity MIB
                  (Version4)", RFC 6933=
, May 2013

        [RFC3444] Pras, A., Schoenwaelder, J. "On the Differences
                  between Information Models and Data Models", RFC
                  3444, January 2003

        [ISO-IEC-19501-2005] ISO/IEC 19501:2005, Information
                  technology, Open Distributed Processing --
                  Unified Modeling Language (UML), January 2005

     Informative References

        [RFC2578] McCloghrie, K., Perkins, D., and J.
                  Schoenwaelder, "Structure of Management
                  Information Version 2 (SMIv2", RFC 2578, April
                  1999


        [RFC5101bis] Claise, B., Ed., and Trammel, T., Ed.,
                  "Specification of the IP Flow Information Export
                  (IPFIX) Protocol for the Exchange of IP Traffic
                  Flow Information ", draft-ietf-ipfix-protocol-
                  rfc5101bis-08, (work in progress), June 2013

        [RFC6020] M. Bjorklund, Ed., " YANG - A Data Modeling
                  Language for the Network Configuration Protocol
                  (NETCONF)", RFC 6020,=
 October 2010

        [ACPI] "Advanced Configuration and Power Interface
                  Specification", http://www.acpi.info/spec30b.htm



     Claise et al.           Expires March 23, 2014      [Page 44]


 
     Internet-Draft              EMAN Framework      September 2013

        [IEEE1621]  "Standard for User Interface Elements in Power
                  Control of Electronic Devices Employed in
                  Office/Consumer Environments", IEEE 1621,
                  December 2004

        [LLDP]  IEEE Std 802.1AB, "Station and Media Control
                  Connectivity Discovery", 2005

        [LLDP-MED-MIB]  ANSI/TIA-1057, "The LLDP Management
                  Information Base extension module for TIA-TR41.4
                  media endpoint discovery information", July 2005

        [EMAN-REQ] Quittek, J., Winter, R., Dietz, T., Claise, B.,
                  and M. Chandramouli, "Requirements for Energy
                  Management", draft-ietf-eman-requirements-14,
                  (work in progress), May 2013

        [EMAN-OBJECT-MIB] Parello, J., and B. Claise, "Energy
                  Object Contet MIB", draft-ietf-eman-energy-aware-
                  mib-08, (work in progress), April 2013

        [EMAN-MON-MIB] Chandramouli, M.,Schoening, B., Quittek, J.,
                  Dietz, T., and B. Claise, "Power and Energy
                  Monitoring MIB", draft-ietf-eman-energy-
                  monitoring-mib-05, (work in progress), April 2013

        [EMAN-BATTERY-MIB] Quittek, J., Winter, R., and T. Dietz, "
                  Definition of Managed Objects for Battery
                  Monitoring", draft-ietf-eman-battery-mib-08,
                  (work in progress), February 2013

        [EMAN-AS] Schoening, B., Chandramouli, M., and B. Nordman,
                  "Energy Management (EMAN) Applicability
                  Statement", draft-ietf-eman-applicability-
                  statement-03, (work in progress), April 2013

        [ITU-T-M-3400] TMN recommandation on Management Functions
                  (M.3400), 1997

        [NMF] "Network Management Fundamentals", Alexander Clemm,
                  ISBN: 1-58720-137-2, 2007

        [TMN] "TMN Management Functions : Performance Management",
                  ITU-T M.3400

        [IEEE100] "The Authoritative Dictionary of IEEE Standards
                  Terms"
                  http://ieeexplore.ieee.org/xpl/mostRecentIssue.js
                  p?punumber=3D4116785


     Claise et al.           Expires March 23, 2014      [Page 45]


 
     Internet-Draft              EMAN Framework      September 2013


        [ISO50001] "ISO 50001:2011 Energy management systems -
                  Requirements with guidance for use",
                  http://www.iso.org/

        [IEC60050] International Electrotechnical Vocabulary
                  http://www.electropedia.org/iev/iev.nsf/welcome?o
                  penform

        [IEC61850] Power Utility Automation,
                  http://www.iec.ch/smartgrid/standards/

        [IEC61850-7-2] Abstract communication service interface
                  (ACSI), http://www.iec.ch/smartgrid/standards/

        [IEEE-802.3at] IEEE 802.3 Working Group, "IEEE Std 802.3at-
                  2009 - IEEE Standard for Information technology -
                  Telecommunications and information exchange
                  between systems - Local and metropolitan area
                  networks - Specific requirements - Part 3:
                  Carrier Sense Multiple Access with Collision
                  Detection (CSMA/CD) Access Method and Physical
                  Layer Specifications - Amendment: Data Terminal
                  Equipment (DTE) -  Power via Media Dependent
                  Interface (MDI) Enhancements", October 2009

        [DMTF] "Power State Management Profile DMTF  DSP1027
                  Version 2.0"  December 2009
                  http://www.dmtf.org/sites/default/files/standards
                  /documents/DSP1027_2.0.0.pdf

        [IPENERGY] R. Aldrich, J. Parello "IP-Enabled Energy
                  Management", 2010, Wiley Publishing

        [X.700]  CCITT Recommendation X.700 (1992), Management
                  framework for Open Systems Interconnection (OSI)
                  for CCITT applications

        [ASHRAE-201] "ASHRAE Standard Project Committee 201
                        (SPC 201)Facility Smart Grid Information
                        Model", http://spc201.ashraepcs.org

        [CHEN] "The Entity-Relationship Model: Toward a Unified
                  View of Data",  Peter Pin-shan Chen, ACM
                  Transactions on Database Systems, 1976






     Claise et al.           Expires March 23, 2014      [Page 46]


 
     Internet-Draft              EMAN Framework      September 2013

        [CISCO-EW] "Cisco EnergyWise Design Guide",  John Parello,
                  Roland Saville, Steve Kramling, Cisco Validated
                  Designs, September 2010,
                  http://www.cisco.com/en/US/docs/solutions/Enterpr
                  ise/Borderless_Networks/Energy_Management/energyw
                  isedg.html




11. Ack=
nowledgments


        The authors would like to Michael Brown for his editorial
        work improving the text dramatically. Thanks to Rolf Winter
        for his feedback and to Bill Mielke for feedback and very
        detailed review. Thanks to Bruce Nordman for brainstorming
        with numerous conference calls and discussions. Finally,
        the authors would like to thank the EMAN chairs: Nevil
        Brownlee, Bruce Nordman, and Tom Nadeau.

        This document was prepared using 2-Word-v2.0.template.dot.

     Authors' Addresses

        John Parello
        Cisco Systems, Inc.
        3550 Cisco Way
        San Jose, California 95134
        US

        Phone: +1 408 525 2339
        Email: jparello@cisco.com

        Benoit Claise
        Cisco Systems, Inc.
        De Kleetlaan 6a b1
        Diegem 1813
        BE

        Phone: +32 2 704 5622
        Email: bclaise@cisco.com


        Brad Schoening
        44 Rivers Edge Drive
        Little Silver, NJ 07739
        US

        Phone:
        Email: brad.schoening@verizon.net


     Claise et al.           Expires March 23, 2014      [Page 47]


 
     Internet-Draft              EMAN Framework      September 2013



        Juergen Quittek
        NEC Europe Ltd.
        Network Laboratories
        Kurfuersten-Anlage 36
        69115 Heidelberg
        Germany

        Phone: +49 6221 90511 15
        EMail: quittek@netlab.nec.de








































     Claise et al.           Expires March 23, 2014      [Page 48]




--_000_9C213D38848B89428F46808B16F6F086016678F4xmbalnx04ciscoc_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable








Hi,



Responding to the last email in the thread:



I will send a reply / seperate thread for each review labelled by reviewer.=




Thanks.

Jp








From: eman-bounces@ietf.org [eman-bounces=
@ietf.org] on behalf of Benoit Claise (bclaise)

Sent: Thursday, October 03, 2013 7:30 AM

To: eman mailing list

Subject: [eman] draft-ietf-eman-framework-10: WGLC comments










Dear all,



Here is my review.

Sorry for the delay.






     Network Working Group                              J. Parello=0A=
     Internet-Draft                                      B. Claise=0A=
     Intended Status: Informational             Cisco Systems, Inc.=0A=
     Expires: March 23, 2014                          B. Schoening=0A=
                                            Independent Consultant=0A=
                                                        J. Quittek=0A=
                                                    NEC Europe Ltd=0A=
     =0A=
                                                September 23, 2013=0A=
     =0A=
     =0A=
                        
Energy Management Framework<=
/h1>=0A=
                       
draft-ietf-eman-framework-10<=
/h1>=0A=
     =0A=
     =0A=
     Status of this Memo=0A=
     =0A=
        This Internet-Draft is submitted in full conformance with=0A=
        the provisions of BCP 78 and BCP 79.=0A=
     =0A=
        Internet-Drafts are working documents of the Internet=0A=
        Engineering Task Force (IETF), its areas, and its working=0A=
        groups.  Note that other groups may also distribute working=0A=
        documents as Internet-Drafts.=0A=
     =0A=
        Internet-Drafts are draft documents valid for a maximum of=0A=
        six months and may be updated, replaced, or obsoleted by=0A=
        other documents at any time.  It is inappropriate to use=0A=
        Internet-Drafts as reference material or to cite them other=0A=
        than as "work in progress."=0A=
     =0A=
        The list of current Internet-Drafts can be accessed at=0A=
        http://www.ietf.org/ietf/1id-abstracts.txt=0A=
     =0A=
        The list of Internet-Draft Shadow Directories can be=0A=
        accessed at http://www.ietf.org/shadow.html=0A=
     =0A=
        This Internet-Draft will expire on March 23, 2014.=0A=
     =0A=
     =0A=
     =0A=
     =0A=
     =0A=
     =0A=
     =0A=
     =0A=
     =0A=
     =0A=
     =0A=
     =0A=
     =0A=
     Claise et al            Expires March 23, 2014   =
     [Page 1]=0A=
     


 =0A=
     Internet-Draft              EMAN Framework      S=
eptember 2013=0A=
     =0A=
     =0A=
     Copyright Notice=0A=
     =0A=
        Copyright (c) 2013 IETF Trust and the persons identified as=0A=
        the document authors. All rights reserved.=0A=
     =0A=
        This document is subject to BCP 78 and the IETF Trust's=0A=
        Legal Provisions Relating to IETF Documents=0A=
        (http://trustee.ietf.org/license-info) in effect on the=0A=
        date of publication of this document. Please review these=0A=
        documents carefully, as they describe your rights and=0A=
        restrictions with respect to this document. Code Components=0A=
        extracted from this document must include Simplified BSD=0A=
        License text as described in Section 4.e o=
f the Trust Legal=0A=
        Provisions and are provided without warranty as described=0A=
        in the Simplified BSD License.=0A=
     =0A=
     Abstract=0A=
     =0A=
        This document defines a framework for providing Energy=0A=
        Management for devices and device components within or=0A=
        connected to communication networks.  The framework=0A=
        presents a physical reference model and information model.=0A=
        The information model consists of an Energy Management=0A=
        Domain as a set of Energy Objects. Each Energy Object is=0A=
        identified, classified and given context.  Energy Objects=0A=
        can be monitored and controlled with respect to Power,=0A=
        Power State, Energy, Demand, Power Attributes, and Battery.=0A=
        Additionally the framework models relationships and=0A=
        capabilities between Energy Objects.



On the top of J=FCrgen's feedback on the abstract, I'm wondering: What is a=
 "physical" reference model?






     =0A=
     =0A=
     =0A=
     =0A=
     =0A=
     =0A=
     =0A=
     =0A=
     =0A=
     =0A=
     =0A=
     =0A=
     =0A=
     =0A=
     =0A=
     =0A=
     =0A=
     =0A=
     =0A=
     =0A=
     =0A=
     Claise et al.           Expires March 23, 2014   =
    [Page 2]=0A=
     


 =0A=
     Internet-Draft              EMAN Framework      S=
eptember 2013=0A=
     =0A=
     =0A=
     Table of Contents=0A=
     =0A=
        1. Introduction...........................=
................ 3=0A=
           1.1. Energy Management Documents Over=
view.............. 4=0A=
        2. Terminology............................=
................ 5=0A=
        3. Concerns Specific to Energy Management.=
............... 11=0A=
           3.1. Target Devices..................=
................. 11=0A=
           3.2. Physical Reference Model........=
................. 12=0A=
           3.3. Concerns Differing from Network =
Management....... 13=0A=
           3.4. Concerns Not Addressed..........=
................. 14=0A=
        4. Energy Management Abstraction..........=
............... 14=0A=
           4.1. Conceptual Model................=
................. 15=0A=
           4.2. Energy Object...................=
................. 15=0A=
           4.3. Energy Object Attributes........=
................. 16=0A=
           4.4. Measurements....................=
................. 19=0A=
           4.5. Control.........................=
................. 21=0A=
           4.6. Relationships...................=
................. 26=0A=
        5. Energy Management Information Model....=
............... 30=0A=
        6. Modeling Relationships between Devices.=
............... 34=0A=
           6.1. Power Source Relationship.......=
................. 34=0A=
           6.2. Metering Relationship...........=
................. 37=0A=
           6.3. Aggregation Relationship........=
................. 39=0A=
        7. Relationship to Other Standards........=
............... 40=0A=
        8. Security Considerations................=
............... 40=0A=
           8.1. Security Considerations for SNMP=
................. 41=0A=
        9. IANA Considerations....................=
............... 42=0A=
           9.1. IANA Registration of new Power S=
tate Sets........ 42=0A=
           9.2. Updating the Registration of .. =
Power State Sets. 43=0A=
        10. References...........................=
................ 43=0A=
        11. Acknowledgments......................=
................ 47=0A=
     =0A=
     
1. Introduction
=0A=
     =0A=
        Network management is often divided into the five main=0A=
        areas defined in the ISO Telecommunications Management=0A=
        Network model: Fault, Configuration, Accounting,=0A=
        Performance, and Security Management (FCAPS) [=
X.700].  Not=0A=
        covered by this traditional management model is Energy=0A=
        Management, which is rapidly becoming a critical area of=0A=
        concern worldwide, as seen in [ISO50001].=0A=
     =0A=
        This document defines an energy management framework for=0A=
        devices within or connected to communication networks.  The=0A=
        devices, or components of these devices (such as router=0A=
        line cards, fans, disks), can then be monitored and=0A=
        controlled.  Monitoring includes measuring power, energy,=0A=
        demand, and attributes of power.  Energy control can be=0A=
        performed by setting a devices' or components' power state.



power state -> Power State.

Some more instances: be consistent in terms of capitalization in the introd=
uction.




     =0A=
     =0A=
     Claise et al.           Expires March 23, 2014   =
    [Page 3]=0A=
     


 =0A=
     Internet-Draft              EMAN Framework      S=
eptember 2013=0A=
     =0A=
        If a device contains batteries, these can also be monitored=0A=
        and controlled.=0A=
     =0A=
        This framework further describes how to identify, classify=0A=
        and provide context for such devices.  While the context=0A=
        information is not specific to Energy Management, some=0A=
        context attributes are specified in the framework,=0A=
        addressing the following use cases: how important is a=0A=
        device in terms of its business impact, how should devices=0A=
        be grouped for reporting and searching, and how should a=0A=
        device role be described.  These context attributes help in=0A=
        fault management and impact analysis while controlling the=0A=
        power states.  Guidelines for using context for energy=0A=
        management are described.=0A=
     =0A=
        The framework introduces the concept of a power interface=0A=
        that is analogous to a network interface. A power interface=0A=
        is defined as an interconnection among devices where energy=0A=
        can be provided, received, or both.=0A=
     =0A=
        The most basic example of Energy Management is a single=0A=
        device reporting information about itself.  In many cases,=0A=
        however, energy is not measured by the device itself, but=0A=
        measured upstream in the power distribution tree.  For=0A=
        example, a power distribution unit (PDU) may measure the=0A=
        energy it supplies to attached devices and report this to=0A=
        an energy management system.  Therefore, devices often have=0A=
        relationships to other devices or components in the power=0A=
        network.  An EnMS (Energy Management System) generally=0A=
        requires an understanding of the power topology (who=0A=
        provides power to whom), the metering topology (who meters=0A=
        whom), and an understanding of the potential aggregation=0A=
        (ex: does a meter aggregate values from other devices).=0A=
     



We need to introduce that there are different relationship types, to solve =
the different problems.




        The relationships build on the power interfa=
ce concept. The=0A=
        different relationships among devices and components,=0A=
        specified in this document, include: power source=0A=
        relationship, metering relationship, and aggregation=0A=
        relationship.=0A=
     =0A=
     
1.1. Energy Management Documents Overview
=
=0A=
     =0A=
        The EMAN standard provides a set of specifications for=0A=
        Energy Management.  This document specifies the framework,=0A=
        per the Energy Management requirements specified in [EMAN-=0A=
        REQ].=0A=
     =0A=
        The applicability statement document [EMAN-AS] includes use=0A=
        cases, a cross-reference between existing standards and the=0A=
     =0A=
     =0A=
     Claise et al.           Expires March 23, 2014   =
    [Page 4]=0A=
     


 =0A=
     Internet-Draft              EMAN Framework      S=
eptember 2013=0A=
     =0A=
        EMAN standard, and a description of this framework's=0A=
        relationship to other frameworks.=0A=
     =0A=
        The Energy Object Context MIB [EMAN-OBJECT-MIB] specifies=0A=
        objects for addressing Energy Object Identification,=0A=
        classification, context information, and relationships from=0A=
        the point of view of Energy Management.=0A=
     =0A=
        The Power and Energy Monitoring MIB [EMAN-MON-MIB]=0A=
        specifies objects for monitoring of Power, Energy, Demand,=0A=
        Power Attributes, and Power States.=0A=
     =0A=
        The Battery Monitoring MIB [EMAN-B=
ATTERY-MIB] defines=0A=
        managed objects that provide information on the status of=0A=
        batteries in managed devices.=0A=
     =0A=
     
2. Terminology
=0A=
     =0A=
        The key words "MUST", "MUST NOT", "REQUIRE=
D", "SHALL",=0A=
        "SHALL NOT", "SHOULD", "SHOULD NOT", =
"RECOMMENDED", "MAY",=0A=
        and "OPTIONAL" in this document are to be interpreted as=
=0A=
        described in RFC-2119 [RFC2119].=0A=
     =0A=
        In this document these words will appear with that=0A=
        interpretation   only when in ALL CAPS. Lower case uses of=0A=
        these words are not to be    interpreted as carrying RFC-=0A=
        21=
19 significance.=0A=
     =0A=
        In this section some terms have a NOTE that is not part of=0A=
        the definition itself, but accounts for differences between=0A=
        terminologies of different standards organizations or=0A=
        further clarifies the definition.



The final agreement on [EMAN-REQ] was 
http://www.rfc-editor.org/authors/rfc6988.txt




   The terms specified in the terminology section are capitalized=0A=
   throughout the document; the exceptions are the well-known terms=0A=
   "energy" and "power".  These terms are generic and a=
re used in=0A=
   generated terms such as "energy-saving", "low-power"=
, etc.



I suggest you do the same.





I searched for a specific term in the terminology section, and realized tha=
t the order is not alphabetical.

A sentence such as: "The terms in the terminology section are not clas=
sified alphabetically, but the order has been chosen to improve the documen=
t readiness, with terms building on the top of each others"








     =0A=
        $ Energy Management



Please change the "$" sign for all entries in the terminology sec=
tion.




          Energy Management is a set of functions fo=
r measuring,=0A=
          modeling, planning, and optimizing networks to ensure=0A=
          that the network and network attached devices use energy=0A=
          efficiently and appropriately for the nature of the=0A=
          application and the cost constraints of the organization.=0A=
     =0A=
          Reference: Adapted from [ITU-T-M-3400=
]=0A=
     =0A=
          NOTES:=0A=
          1. Energy management refers to the activities, methods,=0A=
          procedures and tools that pertain to measuring, modeling,=0A=
          planning, controlling and optimizing the use of energy in=0A=
          networked systems [NMF].=0A=
     =0A=
     =0A=
     =0A=
     =0A=
     Claise et al.           Expires March 23, 2014   =
    [Page 5]=0A=
     


 =0A=
     Internet-Draft              EMAN Framework      S=
eptember 2013=0A=
     =0A=
          2. Energy Management is a management domain which is=0A=
          congruent to any of the FCAPS areas of management in the=0A=
          ISO/OSI Network Management Model [TMN]. Energ=
y Management=0A=
          for communication networks and attached devices is a=0A=
          subset or part of an organization's greater Energy=0A=
          Management Policies.=0A=
     =0A=
        $ Energy Management System (EnMS)=0A=
          An Energy Management System is a combination of hardware=0A=
          and software used to administer a network with the=0A=
          primary purpose of energy management.=0A=
     =0A=
          NOTES:=0A=
          1. An Energy Management System according to [ISO50001]=0A=
          (ISO-EnMS) is a set of systems or procedures upon which=0A=
          organizations can develop and implement an energy policy,=0A=
          set targets, action plans and take into account legal=0A=
          requirements related to energy use.  An ISO-EnMS allows=0A=
          organizations to improve energy performance and=0A=
          demonstrate conformity to requirements, standards, and/or=0A=
          legal requirements.=0A=
     =0A=
          2. Example ISO-EnMS:  Company A defines a set of policies=0A=
          and procedures indicating there should exist multiple=0A=
          computerized systems that will poll energy measurements=0A=
          from their meters and pricing / source data from their=0A=
          local utility. Company A specifies that their CFO (Chief=0A=
          Financial Officer) should collect information and=0A=
          summarize it quarterly to be sent to an accounting firm=0A=
          to produce carbon accounting reporting as required by=0A=
          their local government.=0A=
     =0A=
          3. For the purposes of EMAN, the definition herein is the=0A=
          preferred meaning of an Energy Management System (EnMS).=0A=
          The definition from [ISO50001] can be referred to as ISO=0A=
          Energy Management System (ISO-EnMS).=0A=
     =0A=
        $ Energy Monitoring=0A=
          Energy Monitoring is a part of Energy Management that=0A=
          deals with collecting or reading information from Energy=0A=
          Objects to aid in Energy Management.=0A=
     =0A=
        $ Energy Control=0A=
          Energy Control is a part of Energy Management that deals=0A=
          with directing influence over Energy Objects.=0A=
     =0A=
        $ Electrical Equipment=0A=
          A general term including materials, fittings, devices,=0A=
          appliances, fixtures, apparatus, machines, etc., used as=0A=
     =0A=
     =0A=
     Claise et al.           Expires March 23, 2014   =
    [Page 6]=0A=
     


 =0A=
     Internet-Draft              EMAN Framework      S=
eptember 2013=0A=
     =0A=
          a part of, or in connection with, an electric=0A=
          installation.=0A=
          Reference: [IEEE100]=0A=
     =0A=
        $ Non-Electrical Equipment (Mechanical Equipment)=0A=
          A general term including materials, fittings, devices,=0A=
          appliances, fixtures, apparatus, machines, etc., used as=0A=
          a part of, or in connection with, non-electrical power=0A=
          installations.=0A=
     =0A=
          Reference: Adapted from [IEEE100]=0A=
     =0A=
        $ Device=0A=
          A piece of electrical or non-electrical equipment.=0A=
          Reference: Adapted from [IEEE100]=0A=
     =0A=
        $ Component=0A=
          A part of an electrical or non-electrical equipment=0A=
          (Device).=0A=
          Reference: Adapted from [ITU-T-M-3400=
]=0A=
     =0A=
        $ Power Inlet=0A=
          A Power Inlet (or simply inlet) is an interface at which=0A=
          a device or component receives energy from another device=0A=
          or component.=0A=
     =0A=
        $ Power Outlet=0A=
          A Power Outlet (or simply outlet) is an interface at=0A=
          which a device or component provides energy to another=0A=
          device or component.



Are Power Inlets and Power Oulets Power Interfaces?

If yes, the definitions should be changed accordingly




        $ Power Inlet=0A=
          A Power Inlet (or simply inlet) is an Power Interface at which=0A=
          a device or component receives energy from another device=0A=
          or component.






     =0A=
        $ Energy=0A=
          That which does work or is capable of doing work. As used=0A=
          by electric utilities, it is generally a reference to=0A=
          electrical energy and is measured in kilowatt hours=0A=
          (kWh).=0A=
     =0A=
          Reference: [IEEE100]=0A=
     =0A=
          NOTES=0A=
          1. Energy is the capacity of a system to produce external=0A=
          activity or perform work [ISO50001]=0A=
     =0A=
        $ Provide Energy=0A=
          A device (or component) "provides" energy to another=0A=
          device if there is an energy flow from this device to the=0A=
          other one.=0A=
     =0A=
        $ Receive Energy=0A=
     =0A=
     =0A=
     Claise et al.           Expires March 23, 2014   =
    [Page 7]=0A=
     


 =0A=
     Internet-Draft              EMAN Framework      S=
eptember 2013=0A=
     =0A=
          A device (or component) "receives" energy from another=
=0A=
          device if there is an energy flow from the other device=0A=
          to this one.=0A=
     =0A=
        $ Meter (energy meter)=0A=
          a device intended to measure electrical energy by=0A=
          integrating power with respect to time.=0A=
     =0A=
          Reference: Adapted from [IEC60050]=0A=
     =0A=
        $ Battery=0A=
          one or more cells (consisting of an assembly of=0A=
          electrodes, electrolyte, container, terminals and usually=0A=
          separators)  that are a source and/or store of electric=0A=
          energy.=0A=
     =0A=
          Reference: Adapted from [IEC60050]=0A=
     =0A=
        $ Power=0A=
          The time rate at which energy is emitted, transferred, or=0A=
          received; usually expressed in watts (joules per second).=0A=
     =0A=
          Reference: [IEEE100]






     =0A=
        $ Nameplate Power=0A=
          The Nameplate Power is the nominal Power of a device as=0A=
          specified by the device manufacturer.



s/a device/an Electrical Device?




     =0A=
        $ Power Attributes=0A=
          Measurements of the electrical current, voltage, phase=0A=
          and frequencies at a given point in an electrical power=0A=
          system.=0A=
          Reference: Adapted from [IEC60050]=0A=
     =0A=
          NOTES:=0A=
          1. Power Attributes are not intended to be judgmental=0A=
          with respect to a reference or technical value and are=0A=
          independent of any usage context.=0A=
     =0A=
        $ Power Quality=0A=
          Characteristics of the electrical current, voltage, phase=0A=
          and frequencies at a given point in an electric power=0A=
          system, evaluated against a set of reference technical=0A=
          parameters. These parameters might, in some cases, relate=0A=
          to the compatibility between electricity supplied in an=0A=
          electric power system and the loads connected to that=0A=
          electric power system.=0A=
     =0A=
          Reference: [IEC60050]=0A=
     =0A=
     =0A=
     Claise et al.           Expires March 23, 2014   =
    [Page 8]=0A=
     


 =0A=
     Internet-Draft              EMAN Framework      S=
eptember 2013=0A=
     =0A=
     =0A=
          NOTES:=0A=
          1. Electrical characteristics representing power quality=0A=
          information are typically required by customer facility=0A=
          energy management systems. It is not intended to satisfy=0A=
          the detailed requirements of power quality monitoring.=0A=
          Standards typically also give ranges of allowed values;=0A=
          the information attributes are the raw measurements, not=0A=
          the "yes/no" determination by the various standards.=0A=
     =0A=
          Reference: [ASHRAE-201]=0A=
     =0A=
        $ Demand=0A=
          The average value of power or a related quantity over a=0A=
          specified interval of time. Note: Demand is expressed in=0A=
          kilowatts, kilovolt-amperes, kilovars, or other suitable=0A=
          units.=0A=
     =0A=
          Reference: [IEEE100]=0A=
     =0A=
          NOTES:=0A=
          1. For EMAN we use kilowatts.=0A=
     =0A=
        $ Power State=0A=
          A Power State is a condition or mode of a device that=0A=
          broadly characterizes its capabilities, power=0A=
          consumption, and responsiveness to input.=0A=
     =0A=
          Reference: Adapted from [IEEE1621]=0A=
     =0A=
        $ Power State Set=0A=
          A Power State Set is a collection of Power States that=0A=
          comprises a named or logical control grouping.=0A=
     =0A=
        $ Energy Object=0A=
          An Energy Object (EO) is an information model (class)=0A=
          that represents a piece of equipment that is part of, or=0A=
          attached to, a communications network which is monitored,=0A=
          controlled, or aids in the management of another device=0A=
          for Energy Management.=0A=
     =0A=
        $ Power Interface=0A=
          A Power Interface (or simply interface) is an information=0A=
          model (class) that represents the interconnections among=0A=
          devices or components where energy can be provided,=0A=
          received, or both.=0A=
     =0A=
        $ Energy Management Domain=0A=
     =0A=
     =0A=
     =0A=
     Claise et al.           Expires March 23, 2014   =
    [Page 9]=0A=
     


 =0A=
     Internet-Draft              EMAN Framework      S=
eptember 2013=0A=
     =0A=
          An Energy Management Domain is a set of Energy Objects=0A=
          that is considered one unit of management.=0A=
     =0A=
        $ Energy Object Identification=0A=
          Energy Object Identification is a set of attributes that=0A=
          enable an Energy Object to be universally unique or=0A=
          linked to other systems.=0A=
     =0A=
        $ Energy Object Context=0A=
          Energy Object Context is a set of attributes that allow=0A=
          an Energy Management System to classify an Energy Object=0A=
          within an organization.=0A=
     =0A=
        $ Energy Object Relationship=0A=
          An Energy Object Relationship is an association among=0A=
          Energy Objects.=0A=
     =0A=
          NOTES=0A=
          1. Relationships can be named and could include=0A=
          Aggregation, Metering, and Power Source.=0A=
          Reference: Adapted from [CHEN]=0A=
     =0A=
        $ Power Source Relationship=0A=
          A Power Source Relationship is an Energy Object=0A=
          Relationship where one Energy Object provides power to=0A=
          one or more Energy Objects. These Energy Objects are=0A=
          referred to as having a Power Source Relationship.=0A=
     =0A=
        $ Metering Relationship=0A=
          A Metering Relationship is an Energy Object Relationship=0A=
          where one Energy Object measures power, energy, demand or=0A=
          power attributes of one or more other Energy Objects. The=0A=
          measuring Energy Object has a Metering Relationship with=0A=
          each of the measured objects.=0A=
     =0A=
        $ Aggregation Relationship=0A=
          An Aggregation Relationship is an Energy Object=0A=
          Relationship where one Energy Object aggregates Energy=0A=
          Management information of one or more other Energy=0A=
          Objects. The aggregating Energy Object has an Aggregation=0A=
          Relationship with each of the other Energy Objects.=0A=
     =0A=
     =0A=
     =0A=
     =0A=
     =0A=
     =0A=
     =0A=
     =0A=
     =0A=
     =0A=
     Claise et al.           Expires March 23, 2014   =
   [Page 10]=0A=
     


 =0A=
     Internet-Draft              EMAN Framework      S=
eptember 2013=0A=
     =0A=
     =0A=
     
3. Concerns Specific to Energy Management
=0A=
     =0A=
        This section explains areas of concern for Energy=0A=
        Management that do not exist in traditional Network=0A=
        Management. This section describes target devices, outlines=0A=
        physical reference models, and lists the major concerns



Again "physical" reference model.




        specific to Energy Management.=0A=
     =0A=
     
3.1. Target Devices
=0A=
     =0A=
        With Energy Management, there exists a wide variety of=0A=
        devices that may be contained in the same deployment as =0A=
        communication network but comprise a separate facility,=0A=
        home, or power distribution network.=0A=
     =0A=
        Energy Management has special challenges because a power=0A=
        distribution network supplies energy to devices and=0A=
        components, while a separate communications network=0A=
        monitors and controls the power distribution network.=0A=
     =0A=
        The target devices for Energy Management are all devices=0A=
        that can be monitored or controlled (directly or=0A=
        indirectly) by an Energy Management System (EnMS). These=0A=
        target devices include:=0A=
           o     Simple electrical appliances and fixtures=0A=
           o     Hosts, such as a PC, a server, or a printer=0A=
           o     Switches, routers, base stations, and other=0A=
              network equipment and middle boxes=0A=
           o     Components within devices, such as a battery=0A=
              inside a PC, a line card inside a switch, etc.=0A=
           o     Power over Ethernet (PoE) endpoints=0A=
           o     Power Distribution Units (PDU)=0A=
           o     Protocol gateway devices for Building Management=0A=
              Systems (BMS)=0A=
           o     Electrical meters=0A=
           o     Sensor controllers with subtended sensors





I'm confused by the Device definition in the terminology, which is NOT used=
 in this text, while "device" (paragraph above) and "target =
device" are used




     =0A=
        Target devices will primarily communicate via Internet=0A=
        Protocols (IP). The target devices may also include those=0A=
        communicating via non-IP protocols deployed among the power=0A=
        distribution and IP communication network. These types of=0A=
        target devices are expect to be managed through gateways or=0A=
        proxies that can communicate using IP.=0A=
     =0A=
     =0A=
     =0A=
     =0A=
     =0A=
     =0A=
     =0A=
     Claise et al.           Expires March 23, 2014   =
   [Page 11]=0A=
     


 =0A=
     Internet-Draft              EMAN Framework      S=
eptember 2013=0A=
     =0A=
     =0A=
     
3.2. Physical Reference Model
=0A=
     =0A=
        The following reference models describe physical power=0A=
        topologies that exist in parallel to the communication=0A=
        topology. While many more permutations of topologies can be



Permutation of topologies or permutations of elements, which in turn, creat=
e different topologies?

I believe you meant the latter.




        created the following are some basic ones th=
at show how=0A=
        Energy Management topologies differ from Network Management=0A=
        topologies.=0A=
     =0A=
        Basic Energy Management=0A=
     =0A=
                               +--------------------------+=0A=
                               | Energy Management System |=0A=
                               +--------------------------+=0A=
                                           ^  ^=0A=
                                monitoring |  | control=0A=
                                           v  v=0A=
                                       +---------+=0A=
                                       | device  |=0A=
                                       +---------+=0A=
     =0A=
        Basic Power Supply=0A=
     =0A=
                    +-----------------------------------------+=0A=
                    |         energy management system        |=0A=
                    +-----------------------------------------+=0A=
                          ^  ^                       ^  ^=0A=
               monitoring |  | control    monitoring |  | control=0A=
                          v  v                       v  v=0A=
                    +--------------+        +-----------------&=
#43;=0A=
                    | power supply |########|      device     |=0A=
                    +--------------+        +-----------------&=
#43;=0A=
     






energy management system -> Energy Management Sys=
tem=0A=
=0A=
Pay attention to the terms capitalization in the figures as well. Here, we =
speak about =0A=
	device -> Device, =0A=
	monitoring -> Energy Monitoring=0A=
	control -> Energy Control=0A=
=0A=
You removed the fact that ######## is energy.=0A=
=0A=
Device versus device versus target device?=0A=
=0A=
I'm wondering if we should not add the Power Interfaces in the figures.=0A=
 =0A=





        Single Power Supply with Multiple Devices=0A=
     =0A=
                      +---------------------------------------+=0A=
                      |       energy management system        |=0A=
                      +---------------------------------------+=0A=
                         ^  ^                       ^  ^=0A=
              monitoring |  | control    monitoring |  | control=0A=
                         v  v                       v  v=0A=
                      +--------+        +------------------+=
;=0A=
                      | power  |########|         device 1 |=0A=
                      | supply |   #    +------------------+-+=
=0A=
                      +--------+   #######|         device 2 |=0A=
                                     #    +------------------+-+=
;=0A=
                                     #######|         device 3 |=0A=
                                            +------------------+=0A=
     =0A=
     =0A=
     Claise et al.           Expires March 23, 2014   =
   [Page 12]=0A=
     


 =0A=
     Internet-Draft              EMAN Framework      S=
eptember 2013=0A=
     =0A=
     =0A=
        Multiple Power Supplies with Single Devices=0A=
     =0A=
             +----------------------------------------------+=0A=
             |          energy management system            |=0A=
             +----------------------------------------------+=0A=
                 ^  ^              ^  ^              ^  ^=0A=
            mon. |  | ctrl.   mon. |  | ctrl.   mon. |  | ctrl.=0A=
                 v  v              v  v              v  v=0A=
             +----------+      +----------+      +-----=
-----+=0A=
             | power    |######|  device  |######| power    |=0A=
             | supply 1 |######|          |      | supply 2 |=0A=
             +----------+      +----------+      +-----=
-----+=0A=
     =0A=
     
3.3. Concerns Differing from Network Management
=0A=
     =0A=
           o  Identification of the power source of a device may be=0A=
              independent of the communication network and require=0A=
              unique identifiers.=0A=
     =0A=
           o  Controlling power for a device may have to be=0A=
              fulfilled by addressing the power source as opposed=0A=
              to directing control to the device. For example=0A=
              controlling a device by controlling the outlet of the=0A=
              PDU or controlling a simple light by controlling its=0A=
              outlet.=0A=
     =0A=
           o  Control of a device may need to be coordinated if=0A=
              there are multiple power supplies.=0A=
     =0A=
           o  Modeling of power when the flow of energy can be bi-=0A=
              directional and require a separate interface model=0A=
              from Network Management. For example energy received=0A=
              into a battery or energy provided from battery).=0A=
     =0A=
           o  Some devices may need out-of-band or proxy=0A=
              capabilities to respond to communications request=0A=
              even though it is in a non-operational power state.=0A=
     =0A=
           o  Estimates and source of measurements may vary among=0A=
              devices. For example when devices do not have the=0A=
              capability to measure power an estimate can be=0A=
              provided from the device or estimated by the EnMS.=0A=
              This may require annotation of a measurement.=0A=
     =0A=
           o  A device may require a separate abstract model to=0A=
              describe its components and interconnections than a=0A=
              model used to describe it for Network Management.=0A=
     =0A=
     =0A=
     =0A=
     Claise et al.           Expires March 23, 2014   =
   [Page 13]=0A=
     


 =0A=
     Internet-Draft              EMAN Framework      S=
eptember 2013=0A=
     =0A=
     =0A=
     
3.4. Concerns Not Addressed



One line of intro please: "concerns not addressed" is vague 

Which concerns? Is "concerns" the right term? Should we have some=
 concerns that some concerns are not addressed? :-)

Not addressed by this framework, I guess.

What you want to say is "out of scope of this framework", right?<=
br>



     =0A=
        Non-Electrical Equipment=0A=
     =0A=
        The primary focus of this framework is the management of=0A=
        Electrical Equipment.  Some Non-Electrical Equipment may be=0A=
        connected to communication networks and could have their=0A=
        energy managed if normalized to the electrical units for=0A=
        power and energy. Non-=0A=
        Electrical equipment that do not convert-to or present-as=0A=
        equivalent to Electrical Equipment is not addressed.






        Non-Electrical equipments that do not conver=
t-to or present-as=0A=
        equivalent to Electrical Equipments are not addressed.




     =0A=
     =0A=
        Energy Procurement and Manufacturing=0A=
     =0A=
        While an EnMS may be a central point for corporate=0A=
        reporting, cost computation, environmental impact analysis,=0A=
        and regulatory compliance reporting - Energy Management in=0A=
        this framework excludes energy procurement and the=0A=
        environmental impact of energy use.=0A=
     =0A=
        As such the framework does not include:=0A=
           o  Cost in currency or environmental units of=0A=
              manufacturing a device.=0A=
           o  Embedded carbon or environmental equivalences of a=0A=
              device=0A=
           o  Cost in currency or environmental impact to dismantle=0A=
              or recycle a device.=0A=
           o  Supply chain analysis of energy sources for device=0A=
              deployment=0A=
           o  Conversion of the usage or production of energy to=0A=
              units expressed from the source of that energy (such=0A=
              as the greenhouse gas emissions associated with=0A=
              1000kW from a diesel source).=0A=
     =0A=
     
4. Energy Management Abstraction
=0A=
     =0A=
        Network management is often divided into the five main=0A=
        areas defined in the ISO Telecommunications Management=0A=
        Network model: Fault, Configuration, Accounting,=0A=
        Performance, and Security Management (FCAPS) [=
X.700].  This=0A=
        traditional management model does not cover Energy=0A=
        Management.=0A=
     =0A=
        This section describes a conceptual model of information=0A=
        that can be used for Energy Management. The classes and=0A=
        categories of attributes in the model are described with=0A=
        rationale for each.=0A=
     =0A=
     =0A=
     Claise et al.           Expires March 23, 2014   =
   [Page 14]=0A=
     


 =0A=
     Internet-Draft              EMAN Framework      S=
eptember 2013=0A=
     =0A=
     =0A=
     
4.1. Conceptual Model
=0A=
     =0A=
        This section describes an information model addressing=0A=
        issues specific to Energy Management, which complements=0A=
        existing Network Management models.=0A=
     =0A=
        An information model for Energy Management will need to



No need. 




        describe a means to report information, prov=
ide control,=0A=
        and model the interconnections among physical entities=0A=
        (equipment).



interconnections =3D relationships

We introduced the notion of relationships already

Proposal:


        describe a means to report information, prov=
ide control,=0A=
        and model the relationships among physical entities=0A=
        (equipment).

Here, it's physical entities (equipment).

We had already device, Device, target device, Electrical Object

Be consistent.






     =0A=
        Therefore, this section proposes a similar conceptual model=0A=
        for physical entities to that used in Network Management:=0A=
        devices, components, and interfaces. This section then=0A=
        defines the additional attributes specific to Energy=0A=
        Management for those entities that are not available in=0A=
        existing Network Management models.=0A=
     =0A=
        For modeling the physical entities this section describes=0A=
        three classes:  a Device, a Component, and a Power=0A=
        Interface. These classes are sub-types of an abstract=0A=
        Energy Object class.



I finally get it, I think.

You really want to Energy Object to be an (instance of the) Device, Compone=
nt, or Power Interface class in the information model.

The readers start with the terminology and since they don't know you will n=
eed an information model, they're puzzled by the Energy Object definition.<=
br>
Proposal: whenever you mean the information model class, just mention

    Device Class

    Component Class

    etc.

As you did with the subtitles below.

And no need to define Energy Object in the terminology section. If you real=
ly want, insert the definition in this information model section here, alon=
g with the Device Class definition. Same thing for component.

Btw, the Energy Object is not a class but an instance of the class.




     =0A=
        For modeling additional attributes, this section describes=0A=
        attributes of an Energy Object for: identification,=0A=
        classification, context, control, power and energy.=0A=
     =0A=
        Since the interconnections between physical entities for



interconnection =3D relationship




        Energy Management may have no relation to th=
e=0A=
        interconnections for Network Management the Energy Object



interconnection =3D topology




        classes contain a separate Relationships cla=
ss as an=0A=
        attribute to model these types of interconnections.=0A=
     =0A=
        The remainder of this section describes the conceptual=0A=
        model of the classes and categories of attributes in the=0A=
        information model. The formal definitions of the classes=0A=
        and attributes are specified in Section 5.=
=0A=
     =0A=
     
4.2. Energy Object
=0A=
     =0A=
        An Energy Object is an abstract class that contains the=0A=
        base attributes for Energy Management.  There are three=0A=
        types of Energy Objects: Device, Component and Power=0A=
        Interface.=0A=
     =0A=
     =0A=
     
4.2.1. Device Class
=0A=
     =0A=
     =0A=
     =0A=
     Claise et al.           Expires March 23, 2014   =
   [Page 15]=0A=
     


 =0A=
     Internet-Draft              EMAN Framework      S=
eptember 2013=0A=
     =0A=
        The Device Class is a sub-class of Energy Object that=0A=
        represents a physical piece of equipment.=0A=
     =0A=
        A Device Class instance may represent a device that is a=0A=
        consumer, producer, meter, distributor, or store of energy.=0A=
     =0A=
        A Device Class instance may represent a physical device=0A=
        that contains other components.=0A=
     =0A=
     
4.2.2. Component Class
=0A=
     =0A=
        The Component Class is a sub-class of Energy Object that=0A=
        represents a part of a physical piece of equipment.=0A=
     =0A=
     
4.2.3. Power Interface Class
=0A=
     =0A=
        The power interface class is a sub-class of Energy Object=0A=
        that represents the interconnection among devices and=0A=
        components.



Does it?

It represents the attach point for the relationship. I see later:


        Power Source relationships are intended to i=
dentify the=0A=
        connections between Power Interfaces. =0A=


The Power Interface definition should be improved.






        There are some similarities between Power In=
terfaces and=0A=
        network interfaces.  A network interface can be set to=0A=
        different states, such as sending or receiving data on an=0A=
        attached line.  Similarly, a Power Interface can be=0A=
        receiving or providing power.=0A=
     =0A=
        Physically, a Power Interface instance can represent an AC=0A=
        power socket, an AC power cord attached to a device, or an=0A=
        8P8C (RJ45) PoE socket, etc.=0A=
     =0A=
     
4.3. Energy Object Attributes
=0A=
     =0A=
        This section describes categories of attributes for an=0A=
        Energy Object.=0A=
     =0A=
     
4.3.1. Identification
=0A=
     =0A=
        A Universal Unique Identifier (UUID) [RFC4122] is used to=0A=
        uniquely and persistently identify an Energy Object.=0A=
        Ideally the UUID is used to distinguish the Energy Object=0A=
        within the EnMS.=0A=
     =0A=
        Every Energy Object has an optional unique printable name.=0A=
        Possible naming conventions are: textual DNS name, MAC=0A=
        address of the device, interface ifName, or a text string=0A=
        uniquely identifying the Energy Object.  As an example, in=0A=
        the case of IP phones, the Energy Object name can be the=0A=
        device's DNS name.=0A=
     =0A=
     =0A=
     =0A=
     =0A=
     Claise et al.           Expires March 23, 2014   =
   [Page 16]=0A=
     


 =0A=
     Internet-Draft              EMAN Framework      S=
eptember 2013=0A=
     =0A=
        Additionally an alternate key is provided to allow an=0A=
        Energy Object to be optionally linked with models in=0A=
        different systems.=0A=
     =0A=
     
4.3.2. Context in General
=0A=
     =0A=
        In order to aid in reporting and in differentiation between=0A=
        Energy Objects, each object optionally contains information=0A=
        establishing its business, site, or organizational context=0A=
        within a deployment.=0A=
     =0A=
        Energy Objects contain a category attribute that broadly=0A=
        describes how the object is used in a deployment. The=0A=
        category indicates if the Energy Object is primarily=0A=
        functioning as a consumer, producer, meter, distributor or=0A=
        store of energy.=0A=
     =0A=
        Given the category and context of an object, an EnMS can=0A=
        summarize or analyze measurements. For example, metered=0A=
        usage reported by a meter and consumption usage reported by=0A=
        a device connected to that meter may measure the same=0A=
        usage. With the two measurements identified by category and=0A=
        context an EnMS can make summarizations and inferences.



Shouldn't this text be part of 4.3.4?




     =0A=
     
4.3.3. Context: Importance
=0A=
     =0A=
        An Energy Object can provide an importance value in the=0A=
        range of 1 to 100 to help rank a device's use or relative=0A=
        value to the site.  The importance range is from 1 (least=0A=
        important) to 100 (most important).  The default importance=0A=
        value is 1.=0A=
     =0A=
        For example: A typical office environment has several types=0A=
        of phones, which can be rated according to their business=0A=
        impact.  A public desk phone has a lower importance (for=0A=
        example, 10) than a business-critical emergency phone (for=0A=
        example, 100).  As another example: A company can consider=0A=
        that a PC and a phone for a customer-service engineer are=0A=
        more important than a PC and a phone for lobby use.=0A=
     =0A=
        Although EnMS and administrators can establish their own=0A=
        ranking, the following example is a broad recommendation=0A=
        for commercial deployments [CISCO-EW]:=0A=
     =0A=
           90 to 100 Emergency response=0A=
           80 to 90 Executive or business-critical=0A=
           70 to 79 General or Average=0A=
           60 to 69 Staff or support=0A=
           40 to 59 Public or guest=0A=
     =0A=
     =0A=
     Claise et al.           Expires March 23, 2014   =
   [Page 17]=0A=
     


 =0A=
     Internet-Draft              EMAN Framework      S=
eptember 2013=0A=
     =0A=
           1  to 39 Decorative or hospitality=0A=
     =0A=
     
4.3.4. Context: Keywords
=0A=
     =0A=
        An Energy Object can provide a set of keywords.  These=0A=
        keywords are a list of tags that can be used for grouping,=0A=
        summary reporting within or between Energy Management=0A=
        Domains, and for searching.  All alphanumeric characters=0A=
        and symbols (other than a comma), such as #, (, $, !, and=0A=
        &, are allowed.  Potential examples are: IT, lobby,=0A=
        HumanResources, Accounting, StoreRoom, CustomerSpace,=0A=
        router, phone, floor2, or SoftwareLab.  There is no default=0A=
        value for a keyword.=0A=
        Multiple keywords can be assigned to a device.  White=0A=
        spaces before and after the commas are excluded, as well as=0A=
        within a keyword itself. In such cases, commas separate the=0A=
        keywords and no spaces between keywords are allowed.  For=0A=
        example, "HR,Bldg1,Private".=0A=
     =0A=
     
4.3.5. Context: Role
=0A=
     =0A=
        An Energy Object contains a "role description" string tha=
t=0A=
        indicates the purpose the Energy Object serves in the=0A=
        deployment.  This could be a string describing the context=0A=
        the device fulfills in deployment.=0A=
     =0A=
        Administrators can define any naming scheme for the role of=0A=
        a device.  As guidance, a two-word role that combines the=0A=
        service the device provides along with type can be used=0A=
        [IPENERGY].=0A=
     =0A=
        Example types of devices: Router, Switch, Light, Phone,=0A=
        WorkStation, Server, Display, Kiosk, HVAC.=0A=
     =0A=
        Example Services by Line of Business:=0A=
     =0A=
           Line of Business     Service=0A=
           Education            Student, Faculty, Administration,=0A=
                                Athletic=0A=
           Finance              Trader, Teller, Fulfillment=0A=
           Manufacturing        Assembly, Control, Shipping=0A=
           Retail               Advertising, Cashier=0A=
           Support              Helpdesk, Management=0A=
           Medical              Patient, Administration, Billing=0A=
     =0A=
        Role as a two-word string: "Faculty Desktop", "Telle=
r=0A=
        Phone", "Shipping HVAC", "Advertising Display&q=
uot;, "Helpdesk=0A=
        Kiosk", "Administration Switch".=0A=
     =0A=
     =0A=
     =0A=
     Claise et al.           Expires March 23, 2014   =
   [Page 18]=0A=
     


 =0A=
     Internet-Draft              EMAN Framework      S=
eptember 2013=0A=
     =0A=
     
4.3.6. Context: Domain
=0A=
     =0A=
        An Energy Object contains a string to indicate membership=0A=
        in an Energy Management Domain. An Energy Management Domain=0A=
        can be any collection of devices in a deployment, but it is=0A=
        recommended to map 1:1 with a metered or sub-metered=0A=
        portion of the site.=0A=
     =0A=
        In building management, a meter refers to the meter=0A=
        provided by the utility used for billing and measuring=0A=
        power to an entire building or unit within a building.  A=0A=
        sub-meter refers to a customer- or user-installed meter=0A=
        that is not used by the utility to bill but is instead used=0A=
        to get measurements from sub portions of a building.=0A=
        An Energy Object should be a member of a single Energy=0A=
        Management Domain therefore one attribute is provided.  The=0A=
        Energy Management Domain may be configured on an Energy=0A=
        Object.=0A=
     =0A=
     
4.4. Measurements
=0A=
     =0A=
        An Energy Object contains attributes to describe power,=0A=
        energy and demand measurements.=0A=
     =0A=
        For the purposes of this framework, energy will be limited=0A=
        to electrical energy in watt-hours.  Other forms of Energy=0A=
        Objects that use or produce non-electrical energy may be=0A=
        modeled as an Energy Object but must provide information=0A=
        converted to and expressed in watt-hours.=0A=
     =0A=
        An analogy for understanding power versus energy=0A=
        measurements can be made to speed and distance in=0A=
        automobiles. Just as a speedometer indicates the rate of=0A=
        change of distance (speed), a power measurement indicates=0A=
        the rate of transfer of energy. The odometer in an=0A=
        automobile measures the cumulative distance traveled and=0A=
        similarly an energy measurement indicates the accumulated=0A=
        energy transferred.=0A=
     =0A=
        Demand measurements are averages of power measurements over=0A=
        time. So using the same analogy to an automobile: measuring=0A=
        the average vehicle speed over multiple intervals of time=0A=
        for a given distance travelled, demand is the average power=0A=
        measured over multiple time intervals for a given energy=0A=
        value.=0A=
     =0A=
     
4.4.1. Measurements: Power
=0A=
     =0A=
     =0A=
     =0A=
     =0A=
     Claise et al.           Expires March 23, 2014   =
   [Page 19]=0A=
     


 =0A=
     Internet-Draft              EMAN Framework      S=
eptember 2013=0A=
     =0A=
        Each Energy Object contains a Nameplate Power attribute=0A=
        that describes the nominal power as specified by the=0A=
        manufacturer. The EnMS can use the Nameplate Power for=0A=
        provisioning, capacity planning and (potentially) billing.=0A=
     =0A=
        Each Energy Object will have information that describes the



In the future, avoid the future tense for future RFCs. :-)




        present power information, along with how th=
at measurement=0A=
        was obtained or derived (e.g., actual, estimated, or=0A=
        static).=0A=
     =0A=
        A power measurement is qualified with the units, magnitude=0A=
        and direction of power flow, and is qualified as to the=0A=
        means by which the measurement was made.=0A=
     =0A=
        Power measurement magnitude conforms to the [IEC61850]=0A=
        definition of unit multiplier for the SI (System=0A=
        International) units of measure.  Measured values are=0A=
        represented in SI units obtained by BaseValue * (10 ^=0A=
        Scale).  For example, if current power usage of an Energy=0A=
        Object is 3, it could be 3 W, 3 mW, 3 KW, or 3 MW,=0A=
        depending on the value of the scaling factor.  3W implies=0A=
        that the BaseValue is 3 and Scale =3D 0, whereas 3mW implies=0A=
        BaseValue =3D 3 and ScaleFactor =3D -3.=0A=
     =0A=
        An Energy Object indicates how the power measurement was=0A=
        obtained with a caliber attribute that indicates:=0A=
           o  Whether the measurements were made at the device=0A=
              itself or at a remote source.=0A=
           o  Description of the method that was used to measure=0A=
              the power  and whether this method can distinguish=0A=
              actual or estimated values.=0A=
           o  Accuracy for actual measured values=0A=
     =0A=
     
4.4.2. Measurements: Power Attributes
=
=0A=
     =0A=
        Optionally, an Energy Object describes the Power=0A=
        measurements with Power Attribute information reflecting=0A=
        the electrical characteristics of the measurement. These=0A=
        Power Attributes adhere to the [IEC-61850-7-2] standard for=0A=
        describing AC measurements.=0A=
     =0A=
     
4.4.3. Measurements: Energy
=0A=
     =0A=
        Optionally, an Energy Object that can report actual power=0A=
        readings will have energy attributes that provide the=0A=
        energy used, produced, or stored in kWh.=0A=
     =0A=
     
4.4.4. Measurements: Demand
=0A=
     =0A=
     =0A=
     =0A=
     Claise et al.           Expires March 23, 2014   =
   [Page 20]=0A=
     


 =0A=
     Internet-Draft              EMAN Framework      S=
eptember 2013=0A=
     =0A=
        Optionally, an Energy Object will provide demand=0A=
        information over time. Demand measurements can be provided=0A=
        when the Energy Object is capable of measuring actual=0A=
        power.=0A=
     =0A=
     
4.5. Control
=0A=
     =0A=
        An Energy Object can be controlled by setting a Power=0A=
        State.  An Energy Object implements at least one set of=0A=
        Power States consisting of at least two states, an on state=0A=
        and an off state.=0A=
     =0A=
        Each Energy Object should indicate the sets of Power States=0A=
        that it implements.  



that it supports 

This is more precise.




Well-known Power State Sets are=0A=
        registered with IANA.=0A=
     =0A=
        When a device is set to a particular Power State, it may be=0A=
        busy. The device will set the desired Power State and then=0A=
        update the actual Power State when it changes.  There are=0A=
        then two Power State control variables: actual and=0A=
        requested.=0A=
        There are many existing standards for and implementations=0A=
        of Power States.  An Energy Object can support a mixed set=0A=
        of Power States defined in different standards. A basic=0A=
        example is given by the three Power States defined in=0A=
        IEEE1621 [IEEE1621]: on, off, and sleep. The DMTF =
[DMTF],=0A=
        ACPI [ACPI], and PWG define larger numb=
ers of Power States.=0A=
     =0A=
        The semantics of a Power State are specified by=0A=
           a) the functionality provided by an Energy Object in=0A=
        this state,=0A=
           b) a limitation of the power that an Energy Object uses=0A=
        in this state,=0A=
           c) a combination of a) and b)=0A=
     =0A=
        The semantics of a Power State should be clearly defined.=0A=
        Limitation (curtailment) of the power used by an Energy=0A=
        Object in a state may specified by:=0A=
           o  an absolute power value=0A=
           o  a percentage value of power relative to the energy=0A=
              object's nameplate power=0A=
           o  an indication of power relative to another power=0A=
              state. For example: Specify that power in state A is=0A=
              less than in state B.=0A=
           o  For supporting Power State management an Energy=0A=
              Object provides statistics on Power States including=0A=
              the time an Energy Object spent in a certain Power=0A=
              State and the number of times an Energy Object=0A=
              entered a power state.=0A=
     =0A=
     =0A=
     Claise et al.           Expires March 23, 2014   =
   [Page 21]=0A=
     


 =0A=
     Internet-Draft              EMAN Framework      S=
eptember 2013=0A=
     =0A=
     =0A=
        When requesting an Energy Object to enter a Power State an=0A=
        indication of the Power State's name or number can be used.=0A=
        Optionally an absolute or percentage of Nameplate Power can=0A=
        be provided to allow the Energy Object to transition to a=0A=
        nearest or equivalent Power State.=0A=
     =0A=
     
4.5.1. Power State Sets
=0A=
     =0A=
        There are several standards and implementations of Power=0A=
        State Sets.  An Energy Object can support one or multiple=0A=
        Power State Set implementation(s) concurrently.=0A=
     =0A=
        There are currently three Power State Sets advocated:=0A=
          IEEE1621(256) - [IEEE1621]=0A=
          DMTF(512)     - [DMTF]=0A=
          EMAN(768)     - [EMAN-MON-MIB]=0A=
     =0A=
        The respective specific states related to each Power State=0A=
        Set are specified in the following sections. The guidelines=0A=
        for the modification of Power State Sets are specified in=0A=
        the IANA Considerations Section.=0A=
     =0A=
     
4.5.2. Power State Set: IEEE1621
=0A=
     =0A=
        The IEEE1621 Power State Set [IEEE1621] consists o=
f 3=0A=
        rudimentary states: on, off or sleep.=0A=
     =0A=
           o  on(0)    - The device is fully On and all features of=0A=
              the device are in working mode.=0A=
           o  off(1)   - The device is mechanically switched off=0A=
              and does not consume energy.=0A=
           o  sleep(2) - The device is in a power saving mode, and=0A=
              some features may not be available immediately.=0A=
     =0A=
     
4.5.3. Power State Set: DMTF
=0A=
     =0A=
        The DMTF [DMTF] standards organization h=
as defined a power=0A=
        profile standard based on the CIM (Common Information=0A=
        Model) model that consists of 15 power states:=0A=
     =0A=
        {ON (2), SleepLight (3), SleepDeep (4), Off-Hard (5), Off-=0A=
        Soft (6), Hibernate(7), PowerCycle Off-Soft (8), PowerCycle=0A=
        Off-Hard (9), MasterBus reset (10), Diagnostic Interrupt=0A=
        (11), Off-Soft-Graceful (12), Off-Hard Graceful (13),=0A=
        MasterBus reset Graceful (14), Power-Cycle Off-Soft=0A=
        Graceful (15), PowerCycle-Hard Graceful (16)}=0A=
     =0A=
     =0A=
     =0A=
     =0A=
     Claise et al.           Expires March 23, 2014   =
   [Page 22]=0A=
     


 =0A=
     Internet-Draft              EMAN Framework      S=
eptember 2013=0A=
     =0A=
        The DMTF standard is targeted for hosts and computers.=0A=
        Details of the semantics of each Power State within the=0A=
        DMTF Power State Set can be obtained from the DMTF Power=0A=
        State Management Profile specification [DMTF=
].=0A=
     =0A=
        The DMTF power profile extends ACPI power states. The=0A=
        following table provides a mapping between DMTF and ACPI=0A=
        Power State Set:=0A=
     =0A=
             DMTF                              ACPI=0A=
            Reserved(0)=0A=
            Reserved(1)=0A=
            ON (2)                             G0-S0=0A=
            Sleep-Light (3)                    G1-S1 G1-S2=0A=
            Sleep-Deep (4)                     G1-S3=0A=
            Power Cycle (Off-Soft) (5)         G2-S5=0A=
            Off-hard (6)                       G3=0A=
            Hibernate (Off-Soft) (7)           G1-S4=0A=
            Off-Soft (8)                       G2-S5=0A=
            Power Cycle (Off-Hard) (9)         G3=0A=
            Master Bus Reset (10)              G2-S5=0A=
            Diagnostic Interrupt (11)          G2-S5=0A=
            Off-Soft Graceful (12)             G2-S5=0A=
            Off-Hard Graceful (13)             G3=0A=
            MasterBus Reset Graceful (14)      G2-S5=0A=
            Power Cycle off-soft Graceful (15) G2-S5=0A=
            Power Cycle off-hard Graceful (16) G3=0A=
     =0A=
     
4.5.4. Power State Set: IETF EMAN
=0A=
     =0A=
        An EMAN Power State Set represents an attempt at a standard=0A=
        approach for modeling the different levels of power of a=0A=
        device.  The EMAN Power States are an expansion of the=0A=
        basic Power States as defined in [IEEE1621] that a=
lso=0A=
        incorporates the Power States defined in [A=
CPI] and [DMTF].=0A=
        Therefore, in addition to the non-operational states as=0A=
        defined in [ACPI] and [DMTF] standards, several=0A=
        intermediate operational states have been defined.=0A=
     =0A=
        An Energy Object may implement fewer or more Power States=0A=
        than a particular EMAN Power State Set specifies. In this=0A=
        case, the Energy Object implementation can determine its=0A=
        own mapping to the predefined EMAN Power States within the=0A=
        EMAN Power State Set.=0A=
     =0A=
        There are twelve EMAN Power States that expand on=0A=
        [IEEE1621]. The expanded list of Power States is d=
erived=0A=
        from [CISCO-EW] and is divided into six operational states=0A=
        and six non-operational states.=0A=
     =0A=
     =0A=
     Claise et al.           Expires March 23, 2014   =
   [Page 23]=0A=
     


 =0A=
     Internet-Draft              EMAN Framework      S=
eptember 2013=0A=
     =0A=
     =0A=
        The lowest non-operational state is 1 and the highest is 6.=0A=
        Each non-operational state corresponds to an [ACPI] Global=0A=
        and System state between G3 (hard-off) and G1 (sleeping).=0A=
        Each operational state represents a performance state, and=0A=
        may be mapped to [ACPI] states P0 (maxi=
mum performance=0A=
        power) through P5 (minimum performance and minimum power).=0A=
     =0A=
        In each of the non-operational states (from mechoff(1) to=0A=
        ready(6)), the Power State preceding it is expected to have=0A=
        a lower Power value and a longer delay in returning to an=0A=
        operational state:=0A=
     =0A=
                 mechoff(1) : An off state where no Energy Object=0A=
        features are available.  The Energy Object is unavailable.=0A=
        No energy is being consumed and the power connector can be=0A=
        removed.=0A=
     =0A=
                 softoff(2) : Similar to mechoff(1), but some=0A=
        components remain powered or receive trace power so that=0A=
        the Energy Object can be awakened from its off state.  In=0A=
        softoff(2), no context is saved and the device typically=0A=
        requires a complete boot when awakened.=0A=
     =0A=
                 hibernate(3): No Energy Object features are=0A=
        available.   The Energy Object may be awakened without=0A=
        requiring a complete boot, but the time for availability is=0A=
        longer than sleep(4). An example for state hibernate(3) is=0A=
        a save to-disk state where DRAM context is not maintained.=0A=
        Typically, energy consumption is zero or close to zero.=0A=
     =0A=
                 sleep(4)    : No Energy Object features are=0A=
        available, except for out-of-band management, such as wake-=0A=
        up mechanisms.  The time for availability is longer than=0A=
        standby(5). An example for state sleep(4) is a save-to-RAM=0A=
        state, where DRAM context is maintained.  Typically, energy=0A=
        consumption is close to zero.=0A=
     =0A=
                 standby(5) : No Energy Object features are=0A=
        available, except for out-of-band management, such as wake-=0A=
        up mechanisms.  This mode is analogous to cold-standby.=0A=
        The time for availability is longer than ready(6).  For=0A=
        example processor context is may not be maintained.=0A=
        Typically, energy consumption is close to zero.=0A=
     =0A=
                 ready(6)    : No Energy Object features are=0A=
        available, except for out-of-band management, such as wake-=0A=
        up mechanisms. This mode is analogous to hot-standby.  The=0A=
        Energy Object can be quickly transitioned into an=0A=
     =0A=
     =0A=
     Claise et al.           Expires March 23, 2014   =
   [Page 24]=0A=
     


 =0A=
     Internet-Draft              EMAN Framework      S=
eptember 2013=0A=
     =0A=
        operational state.  For example, processors are not=0A=
        executing, but processor context is maintained.=0A=
     =0A=
                 lowMinus(7) : Indicates some Energy Object=0A=
        features may not be available and the Energy Object has=0A=
        taken measures or selected options to provide less than=0A=
        low(8) usage.=0A=
     =0A=
                 low(8)      : Indicates some features may not be=0A=
        available and the Energy Object has taken measures or=0A=
        selected options to provide less than mediumMinus(9) usage.=0A=
     =0A=
                 mediumMinus(9): Indicates all Energy Object=0A=
        features are available but the Energy Object has taken=0A=
        measures or selected options to provide less than=0A=
        medium(10) usage.=0A=
     =0A=
                 medium(10)  : Indicates all Energy Object features=0A=
        are available but the Energy Object has taken measures or=0A=
        selected options to provide less than highMinus(11) usage.=0A=
                 highMinus(11): Indicates all Energy Object=0A=
        features are available and power usage is less than=0A=
        high(12).=0A=
     =0A=
                 high(12)    : Indicates all Energy Object features=0A=
        are available and the Energy Object is consuming the=0A=
        highest power.=0A=
     =0A=
     
4.5.5. Power State Sets Comparison
=0A=
     =0A=
        A comparison of Power States from different Power State=0A=
        Sets can be seen in the following table:=0A=
          IEEE1621  DMTF         ACPI           EMAN=0A=
     =0A=
          Non-operational states=0A=
          off       Off-Hard     G3, S5         MechOff(1)=0A=
          off       Off-Soft     G2, S5         SoftOff(2)=0A=
          sleep     Hibernate    G1, S4         Hibernate(3)=0A=
          sleep     Sleep-Deep   G1, S3         Sleep(4)=0A=
          sleep     Sleep-Light  G1, S2         Standby(5)=0A=
          sleep     Sleep-Light  G1, S1         Ready(6)=0A=
     =0A=
          Operational states:=0A=
          on        on           G0, S0, P5     LowMinus(7)=0A=
          on        on           G0, S0, P4     Low(8)=0A=
          on        on           G0, S0, P3     MediumMinus(9)=0A=
          on        on           G0, S0, P2     Medium(10)=0A=
          on        on           G0, S0, P1     HighMinus(11)=0A=
          on        on           G0, S0, P0     High(12)=0A=
     =0A=
     =0A=
     Claise et al.           Expires March 23, 2014   =
   [Page 25]=0A=
     


 =0A=
     Internet-Draft              EMAN Framework      S=
eptember 2013=0A=
     =0A=
     =0A=
     
4.6. Relationships
=0A=
     =0A=
        Two Energy Objects can establish an Energy Object=0A=
        Relationship to model the deployment topology with respect=0A=
        to Energy Management.=0A=
     =0A=
        Relationships are modeled with a Relationship class that=0A=
        contains the UUID of the participants in the relationship=0A=
        and a description of the type of relationship. The types of=0A=
        relationships are:  power source, metering, and=0A=
        aggregations.=0A=
     =0A=
           o  The Power Source Relationship gives a view of the=0A=
              physical wiring topology.  For example: a data center=0A=
              server receiving power from two specific Power=0A=
              Interfaces from two different PDUs.=0A=
     =0A=
              Note: A power source relationship may or may not=0A=
              change as the direction of power changes between two=0A=
              Energy Objects. The relationship may remain to=0A=
              indicate the change of power direction was unintended=0A=
              or an error condition.=0A=
     =0A=
           o  The Metering Relationship gives the view of the=0A=
              metering topology.  Physical meters can be placed=0A=
              anywhere in a power distribution tree.  For example,=0A=
              utility meters monitor and report accumulated power=0A=
              consumption of the entire building. Logically, the=0A=
              metering topology overlaps with the wiring topology,=0A=
              as meters are connected to the wiring topology.  A=0A=
              typical example is meters that clamp onto the=0A=
              existing wiring.=0A=
     =0A=
           o  The Aggregation Relationship gives a model of devices=0A=
              that may aggregate (sum, average, etc) values for=0A=
              other devices.  The Aggregation Relationship is=0A=
              slightly different compared to the other=0A=
              relationships as this refers more to a management=0A=
              function.=0A=
     =0A=
        In some situations, it is not possible to discover the=0A=
        Energy Object Relationships, and they must be set by an=0A=
        EnMS or administrator.  Given that relationships can be=0A=
        assigned manually, the following sections describes=0A=
        guidelines for use.=0A=
     =0A=
     =0A=
     =0A=
     =0A=
     =0A=
     Claise et al.           Expires March 23, 2014   =
   [Page 26]=0A=
     






 =0A=
     Internet-Draft              EMAN Framework      S=
eptember 2013=0A=
     =0A=
     
4.6.1. Relationship Conventions and Guidelines
=
=0A=
     =0A=
        This Energy Management framework does not impose many=0A=
        "MUST" rules related to Energy Object Relationships. Ther=
e=0A=
        are always corner cases that could be excluded with too=0A=
        strict specifications of relationships. However, this=0A=
        Energy Management framework proposes a series of=0A=
        guidelines, indicated with "SHOULD" and "MAY".=
=0A=
     =0A=
     
4.6.2. Guidelines: Power Source
=0A=
     =0A=
        Power Source relationships are intended to identify the=0A=
        connections between Power Interfaces. This is analogous to=0A=
        a Layer 2 connection in networking devices (a "one-hop=0A=
        connection").=0A=
     =0A=
        The preferred modeling would be for Power Interfaces to=0A=
        participate in Power Source Relationships. It some cases=0A=
        Energy Objects may not have the capability to model Power=0A=
        Interfaces.  Therefore a Power Source Relationship can be=0A=
        established between two Energy Objects or two non-connected=0A=
        Power Interfaces.=0A=
     =0A=
        While strictly speaking Components and Power Interfaces on=0A=
        the same device do provide or receive energy from each=0A=
        other, the Power Source relationship is intended to show=0A=
        energy transfer between Devices. Therefore the relationship=0A=
        is implied when on the same Device.=0A=
     =0A=
        An Energy Object SHOULD NOT establish a Power Source=0A=
        Relationship with a Component.=0A=
           o  A Power Source Relationship SHOULD be established=0A=
              with the next known Power Interface in the wiring=0A=
              topology.=0A=
     =0A=
           o  The next known Power Interface in the wiring topology=0A=
              would be the next device implementing the framework.=0A=
              In some cases the domain of devices under management=0A=
              may include some devices that do not implement the=0A=
              framework. In these cases, the Power Source=0A=
              relationship can be established with the next device=0A=
              in the topology that implements the framework and=0A=
              logically shows the Power Source of the device.=0A=
     =0A=
     =0A=
     =0A=
     =0A=
     =0A=
     =0A=
     =0A=
     =0A=
     Claise et al.           Expires March 23, 2014   =
   [Page 27]=0A=
     


 =0A=
     Internet-Draft              EMAN Framework      S=
eptember 2013=0A=
     =0A=
           o  Transitive Power Source relationships SHOULD NOT be=0A=
              established.  For example, if an Energy Object A has=0A=
              a Power Source Relationship "Poweredby" with the=0A=
              Energy Object B, and if the Energy Object B has a=0A=
              Power Source Relationship "Poweredby" with the Ener=
gy=0A=
              Object C, then the Energy Object A SHOULD NOT have a=0A=
              Power Source Relationship "Poweredby" with the Ener=
gy=0A=
              Object C.=0A=
     =0A=
     
4.6.3. Guidelines: Metering Relationship
=0A=
     =0A=
        Metering Relationships are intended to show when one Device=0A=
        acting as a Meter is measuring the power or energy at a=0A=
        point in a power distribution system. Since one point of a=0A=
        power distribution system may cover many Devices within a=0A=
        wiring topology, this relationship type can be seen as an=0A=
        arbitrary set.=0A=
     =0A=
        Some Devices, however, may include measuring hardware for=0A=
        components and Power Interfaces or for the entire Device.=0A=
        For example, some PDUs may have the ability to measure=0A=
        Power for each Power Interface (metered by outlet). Others=0A=
        may be able to control power at each Power Interface but=0A=
        can only measure Power at the Power Inlet and a total for=0A=
        all Power Interfaces (metered by device).=0A=
     =0A=
        While the Metering Relationship SHOULD be used between=0A=
        devices, in some cases the Device MAY be modeled as an=0A=
        Energy Object that meters all of its Power Outlets and each=0A=
        Power Outlet MAY be metered by the Energy Object=0A=
        representing the Device.=0A=
     =0A=
        In general:=0A=
           o  A Metering Relationship MAY be established with any=0A=
              other Energy Object, Component, or Power Interface.=0A=
     =0A=
           o  Transitive Metering relationships MAY be used.=0A=
     =0A=
           o  When there is a series of meters for one Energy=0A=
              Object, the Energy Object MAY establish a Metering=0A=
              relationship with one or more of the meters.=0A=
     =0A=
     
4.6.4. Guidelines: Aggregation
=0A=
     =0A=
        Aggregation relationships are intended to identify when one=0A=
        device is used to accumulate values from other devices.=0A=
        Typically this is for energy or power values among devices=0A=
        and not for Components or Power Interfaces on the same=0A=
        device.=0A=
     =0A=
     =0A=
     Claise et al.           Expires March 23, 2014   =
   [Page 28]=0A=
     


 =0A=
     Internet-Draft              EMAN Framework      S=
eptember 2013=0A=
     =0A=
     =0A=
        The intent of Aggregation relationships is to indicate when=0A=
        one device is providing aggregate values for a set of other=0A=
        devices when it is not obvious from the power source or=0A=
        simple containment within a device.=0A=
     =0A=
        Establishing aggregation relationships within the same=0A=
        device would make modeling more complex and the aggregated=0A=
        values can be implied from the use of Power Inlets, outlet=0A=
        and Energy Object values on the same device.=0A=
     =0A=
        Since an EnMS is naturally a point of aggregation it is not=0A=
        necessary to model aggregation for Energy Management=0A=
        Systems.=0A=
     =0A=
        Aggregation SHOULD be used for power and energy. It MAY be






"Aggregation SHOULD be used for power and energ=
y" is misleading=0A=
I guess you mean: "The Aggregation Relationship is intended for power =
and energy"=0A=
=0A=
For the rest below. =0A=
Section 6 is a series of examples=0A=
I'm fine with section 7, 8, and 9 (IANA, which I wrote)=0A=
=0A=
Regards, Benoit =0A=





        used for aggregation of other values from th=
e information=0A=
        model, but the rules and logical ability to aggregate each=0A=
        attribute is out of scope for this document.=0A=
     =0A=
        In general:=0A=
           o  A Device SHOULD NOT establish an Aggregation=0A=
              Relationship with Components contained on the same=0A=
              device.=0A=
           o  A Device SHOULD NOT establish an Aggregation=0A=
              Relationship with the Power Interfaces contained on=0A=
              the same device.=0A=
           o  A Device SHOULD NOT establish an Aggregation=0A=
              Relationship with an EnMS.=0A=
           o  Aggregators SHOULD log or provide notification in the=0A=
              case of errors or missing values while performing=0A=
              aggregation.=0A=
     =0A=
     
4.6.5. Energy Object Relationship Extensions
=0A=
     =0A=
        This framework for Energy Management is based on three=0A=
        relationship types: Aggregation , Metering, and Power=0A=
        Source.=0A=
        This framework is defined with possible future extension of=0A=
        new Energy Object Relationships in mind.=0A=
        For example:=0A=
           o  Some Devices that may not be IP connected. This can=0A=
              be modeled with a proxy relationship to an Energy=0A=
              Object within the domain. This type of proxy=0A=
              relationship is left for further development.=0A=
     =0A=
     =0A=
     =0A=
     =0A=
     =0A=
     =0A=
     Claise et al.           Expires March 23, 2014   =
   [Page 29]=0A=
     


 =0A=
     Internet-Draft              EMAN Framework      S=
eptember 2013=0A=
     =0A=
           o  A Power Distribution Unit (PDU) that allows physical=0A=
              entities like outlets to be "ganged" together as a=
=0A=
              logical entity for simplified management purposes,=0A=
              could be modeled with an extension called a "gang=0A=
              relationship", whose semantics would specify the=0A=
              Energy Objects' grouping.=0A=
     =0A=
     
5. Energy Management Information Model
=0A=
     =0A=
        This section presents an information model expression of=0A=
        the concepts in this framework as a reference for=0A=
        implementers. The information model is implemented as a MIB=0A=
        in the different related IETF EMAN documents.  However,=0A=
        other programming structures with different data models=0A=
        could be used as well.=0A=
     =0A=
        Data modeling specifications of this information model may=0A=
        where needed specify which attributes are required or=0A=
        optional.=0A=
     =0A=
        EDITORs NOTE:  The working group is converging on the use=0A=
        of code/pseudo-code rather than ascii UML diagram. IF so we=0A=
        would have to define priimitve type as reference (eg. Int,=0A=
        string, etc)If agreeable we can either indicate a BNF=0A=
        syntax in a formal syntax section or use the following=0A=
        table if obvious:=0A=
     =0A=
        Syntax=0A=
     =0A=
          UML Construct=0A=
          [ISO-IEC-19501-2005] Equivalent Notation=0A=
          -------------------- ------------------------------------=0A=
          Notes                // Notes=0A=
          Class=0A=
          (Generalization)     CLASS name {member..}=0A=
          Sub-Class=0A=
          (Specialization)     CLASS subclass=0A=
                                     EXTENDS superclass {member..}=0A=
          Class Member=0A=
          (Attribute)          attribute : type=0A=
     =0A=
     =0A=
     =0A=
     =0A=
     =0A=
     =0A=
     =0A=
     =0A=
     =0A=
     =0A=
     =0A=
     Claise et al.           Expires March 23, 2014   =
   [Page 30]=0A=
     


 =0A=
     Internet-Draft              EMAN Framework      S=
eptember 2013=0A=
     =0A=
     =0A=
        Model=0A=
     =0A=
        CLASS EnergyObject {=0A=
     =0A=
           // identification / classification=0A=
           index        : int=0A=
           identifier   : uuid=0A=
           alternatekey : string=0A=
     =0A=
           // context=0A=
           domainName      : string=0A=
           role            : string=0A=
           keywords [0..n] : string=0A=
           importance      : int=0A=
     =0A=
           // relationship=0A=
           relationships [0..n] : Relationship=0A=
     =0A=
           // measurements=0A=
           nameplate    : Nameplate=0A=
           power     : PowerMeasurement=0A=
           energy    : EnergyMeasurment=0A=
           demand    : DemandMeasurement=0A=
     =0A=
           // control=0A=
           powerControl [0..n] : PowerStateSet=0A=
        }=0A=
     =0A=
        CLASS Device EXTENDS EnergyObject {=0A=
              eocategory   : enum { producer, consumer, meter,=0A=
        distributor, store }=0A=
        }=0A=
     =0A=
        CLASS Component EXTENDS EnergyObject=0A=
              eocategory   : enum { producer, consumer, meter,=0A=
        distributor, store }=0A=
        }=0A=
     =0A=
        CLASS Interface EXTENDS EnergyObject{=0A=
              eoIfType : enum ( inlet, outlet, both}=0A=
        }=0A=
     =0A=
        CLASS Nameplate {=0A=
              nominalPower : PowerMeasurement=0A=
              details      : URI=0A=
        }=0A=
     =0A=
     =0A=
     =0A=
     =0A=
     Claise et al.           Expires March 23, 2014   =
   [Page 31]=0A=
     


 =0A=
     Internet-Draft              EMAN Framework      S=
eptember 2013=0A=
     =0A=
        CLASS Relationship {=0A=
              relationshipType    : enum { meters, meteredby,=0A=
        powers, poweredby, aggregates, aggregatedby }=0A=
              relationshipObject  : uuid=0A=
        }=0A=
     =0A=
        CLASS Measurement {=0A=
              multiplier: enum { -24..24}=0A=
              caliber   : enum { actual, estimated, static }=0A=
              accuracy  : enum { 0..10000} // hundreds of percent=0A=
        }=0A=
     =0A=
        CLASS PowerMeasurement EXTENDS Measurement {=0A=
              value          : long=0A=
              units          : "W"=0A=
              powerAttribute : PowerAttribute=0A=
        }=0A=
     =0A=
        CLASS EnergyMeasurement EXTENDS Measurement {=0A=
              startTime : time=0A=
              units     : "kWh"=0A=
              provided  : long=0A=
              used      : long=0A=
              produced  : long=0A=
              stored    : long=0A=
        }=0A=
     =0A=
        CLASS TimedMeasurement EXTENDS Measurement {=0A=
              startTime  : timestamp=0A=
              value      : Measurement=0A=
              maximum    : Measurement=0A=
        }=0A=
     =0A=
        CLASS TimeInterval {=0A=
              value      : long=0A=
              units      : enum { seconds, miliseconds,...}=0A=
        }=0A=
     =0A=
        CLASS DemandMeasurement EXTENDS Measurement {=0A=
              intervalLength : TimeInte=0A=
        rval=0A=
              interval       : long=0A=
              intervalMode   : enum { periodic, sliding, total }=0A=
              intervalWindow : TimeInterval=0A=
              sampleRate     : TimeInterval=0A=
              status         : enum { active, inactive }=0A=
              measurements[0..n] : TimedMeasurements=0A=
        }=0A=
     =0A=
     =0A=
     =0A=
     Claise et al.           Expires March 23, 2014   =
   [Page 32]=0A=
     


 =0A=
     Internet-Draft              EMAN Framework      S=
eptember 2013=0A=
     =0A=
        CLASS PowerStateSet {=0A=
              powerSetIdentifier : int=0A=
              name               : string=0A=
              powerStates [0..n] : PowerState=0A=
              operState          : int=0A=
              adminState         : int=0A=
              reason             : string=0A=
              configuredTime     : timestamp=0A=
        }=0A=
     =0A=
        CLASS PowerState {=0A=
              powerStateIdentifier  : int=0A=
              name             : string=0A=
              cardinality      : int=0A=
              maximumPower     : PowerMeasurement=0A=
              totalTimeInState : time=0A=
              entryCount       : long=0A=
        }=0A=
     =0A=
        CLASS PowerAttribute {=0A=
     =0A=
           // container for attributes=0A=
                 acQuality   : ACQuality=0A=
        }=0A=
     =0A=
        CLASS ACQuality {=0A=
           acConfiguration : enum {SNGL, DEL,WYE}=0A=
           avgVoltage   : long=0A=
           avgCurrent   : long=0A=
           frequency    : long=0A=
           unitMultiplier  : int=0A=
           accuracy    : int=0A=
           totalActivePower   : long=0A=
           totalReactivePower : long=0A=
           totalApparentPower : long=0A=
           totalPowerFactor : long=0A=
           phases [0..2]  : ACPhase=0A=
        }=0A=
     =0A=
        CLASS ACPhase {=0A=
           phaseIndex : long=0A=
           avgCurrent : long=0A=
           activePower : long=0A=
           reactivePower : long=0A=
           apparentPower : long=0A=
           powerFactor : long=0A=
        }=0A=
     =0A=
     =0A=
     =0A=
     =0A=
     Claise et al.           Expires March 23, 2014   =
   [Page 33]=0A=
     


 =0A=
     Internet-Draft              EMAN Framework      S=
eptember 2013=0A=
     =0A=
        CLASS DelPhase EXTENDS ACPhase {=0A=
           phaseToNextPhaseVoltage  : long=0A=
           thdVoltage : long=0A=
           thdCurrent : long=0A=
        }=0A=
     =0A=
        CLASS WYEPhase EXTENDS ACPhase {=0A=
           phaseToNeutralVoltage : long=0A=
           thdCurrent : long=0A=
           thdVoltage : long=0A=
        }=0A=
     =0A=
     
6. Modeling Relationships between Devices
=0A=
     =0A=
        In this section we give examples of how to use the Energy=0A=
        Management framework relationships to model physical=0A=
        topologies.  Where applicable, we show how the framework=0A=
        can be applied when Devices have the capability to model=0A=
        Power Interfaces.  We also show how the framework can be=0A=
        applied when devices cannot support Power Interfaces but=0A=
        only monitor information or control the Device as a whole.=0A=
        For instance, a PDU may only be able to measure power and=0A=
        energy for the entire unit without the ability to=0A=
        distinguish among the inlets or outlet.=0A=
     =0A=
     
6.1. Power Source Relationship
=0A=
     =0A=
        The Power Source relationship is used to model the=0A=
        interconnections between Devices, Components and/Power=0A=
        Interfaces to indicate the source of energy for an Energy=0A=
        Object. In the following examples we show variations on=0A=
        modeling the reference topologies using relationships.=0A=
     =0A=
        Given for all cases:=0A=
     =0A=
        Device W: A computer with one power supply. Power interface=0A=
        1 is an inlet for Device W.=0A=
     =0A=
        Device X: A computer with two power supplies. Power=0A=
        interface 1 and power interface 2 are both inlets for=0A=
        Device X.=0A=
     =0A=
        Device Y: A PDU with multiple Power Interfaces numbered=0A=
        0..10. Power interface 0 is an inlet and power interface=0A=
        1..10 are outlets.=0A=
     =0A=
        Device Z: A PDU with multiple Power Interfaces numbered=0A=
        0..10. Power interface 0 is an inlet and power interface=0A=
        1..10 are outlets.=0A=
     =0A=
     =0A=
     Claise et al.           Expires March 23, 2014   =
   [Page 34]=0A=
     


 =0A=
     Internet-Draft              EMAN Framework      S=
eptember 2013=0A=
     =0A=
     =0A=
        Case 1: Simple Device with one Source=0A=
     =0A=
        Physical Topology:=0A=
     =0A=
           o  Device W inlet 1 is plugged into Device Y outlet 8.=0A=
     =0A=
        With Power Interfaces:=0A=
     =0A=
           o  Device W has an Energy Object representing the=0A=
              computer itself as well as one Power Interface=0A=
              defined as an inlet.=0A=
           o  Device Y would have an Energy Object representing the=0A=
              PDU itself (the Device), with a Power Interface 0=0A=
              defined as an inlet and Power Interfaces 1..10=0A=
              defined as outlets.=0A=
     =0A=
        The interfaces of the devices would have a Power Source=0A=
        Relationship such that:=0A=
        Device W inlet 1 is powered by Device Y outlet 8.=0A=
     =0A=
           +-------+------+       poweredBy +------+---=
-------+=0A=
           | PDU Y | PI 8 |-----------------| PI 1 | Device W |=0A=
           +-------+------+ powers          +------+---=
-------+=0A=
     =0A=
        Without Power Interfaces:=0A=
     =0A=
           o  Device W has an Energy Object representing the=0A=
              computer.=0A=
           o  Device Y would have an Energy Object representing the=0A=
              PDU.=0A=
     =0A=
        The devices would have a Power Source Relationship such=0A=
        that:=0A=
        Device W is powered by Device Y.=0A=
     =0A=
     =0A=
           +----------+       poweredBy +------------+=0A=
           |  PDU Y   |-----------------|  Device W  |=0A=
           +----------+ powers          +------------+=0A=
     =0A=
        Case 2: Multiple Inlets=0A=
     =0A=
        Physical Topology:=0A=
           o  Device X inlet 1 is plugged into Device Y outlet 8.=0A=
           o  Device X inlet 2 is plugged into Device Y outlet 9.=0A=
     =0A=
        With Power Interfaces:=0A=
     =0A=
     =0A=
     Claise et al.           Expires March 23, 2014   =
   [Page 35]=0A=
     


 =0A=
     Internet-Draft              EMAN Framework      S=
eptember 2013=0A=
     =0A=
     =0A=
           o  Device X has an Energy Object representing the=0A=
              computer itself. It contains two Power Interfaces=0A=
              defined as inlets.=0A=
           o  Device Y would have an Energy Object representing the=0A=
              PDU itself (the Device), with a Power Interface 0=0A=
              defined as an inlet and Power Interfaces 1..10=0A=
              defined as outlets.=0A=
     =0A=
        The interfaces of the devices would have a Power Source=0A=
        Relationship such that:=0A=
        Device X inlet 1 is powered by Device Y outlet 8.=0A=
        Device X inlet 2 is powered by Device Y outlet 9.=0A=
     =0A=
           +-------+------+        poweredBy+------+---=
-------+=0A=
           |       | PI 8 |-----------------| PI 1 |          |=0A=
           |       |      |powers           |      |          |=0A=
           | PDU Y +------+        poweredBy+------+ Device=
 X |=0A=
           |       | PI 9 |-----------------| PI 2 |          |=0A=
           |       |      |powers           |      |          |=0A=
           +-------+------+                 +------+---=
-------+=0A=
     =0A=
        Without Power Interfaces:=0A=
     =0A=
           o  Device X has an Energy Object representing the=0A=
              computer. Device Y has an Energy Object representing=0A=
              the PDU.=0A=
     =0A=
     =0A=
        The devices would have a Power Source Relationship such=0A=
        that:=0A=
        Device X is powered by Device Y.=0A=
     =0A=
           +----------+       poweredBy +------------+=0A=
           |  PDU Y   |-----------------|  Device X  |=0A=
           +----------+ powers          +------------+=0A=
     =0A=
        Case 3: Multiple Sources=0A=
     =0A=
        Physical Topology:=0A=
           o  Device X inlet 1 is plugged into Device Y outlet 8.=0A=
           o  Device X inlet 2 is plugged into Device Z outlet 9.=0A=
     =0A=
        With Power Interfaces:=0A=
     =0A=
     =0A=
     =0A=
     =0A=
     =0A=
     =0A=
     Claise et al.           Expires March 23, 2014   =
   [Page 36]=0A=
     


 =0A=
     Internet-Draft              EMAN Framework      S=
eptember 2013=0A=
     =0A=
           o  Device X has an Energy Object representing the=0A=
              computer itself. It contains two Power Interface=0A=
              defined as inlets.=0A=
           o  Device Y would have an Energy Object representing the=0A=
              PDU itself  (the Device), with a Power Interface 0=0A=
              defined as an inlet and Power Interfaces 1..10=0A=
              defined as outlets.=0A=
           o  Device Z would have an Energy Object representing the=0A=
              PDU itself  (the Device), with a Power Interface 0=0A=
              defined as an inlet and Power Interfaces 1..10=0A=
              defined as outlets.=0A=
     =0A=
        The interfaces of the devices would have a Power Source=0A=
        Relationship such that:=0A=
        Device X inlet 1 is powered by Device Y outlet 8.=0A=
        Device X inlet 2 is powered by Device Z outlet 9.=0A=
     =0A=
           +-------+------+        poweredBy+------+---=
-------+=0A=
           | PDU Y | PI 8 |-----------------| PI 1 |          |=0A=
           |       |      |powers           |      |          |=0A=
           +-------+------+                 +------+   =
       |=0A=
                                                   | Device X |=0A=
           +-------+------+        poweredBy+------+   =
       |=0A=
           | PDU Z | PI 9 |-----------------| PI 2 |          |=0A=
           |       |      |powers           |      |          |=0A=
           +-------+------+                 +------+---=
-------+=0A=
     =0A=
        Without Power Interfaces:=0A=
     =0A=
           o  Device X has an Energy Object representing the=0A=
              computer. Device Y and Z would both have respective=0A=
              Energy Objects representing each entire PDU.=0A=
     =0A=
        The devices would have a Power Source Relationship such=0A=
        that:=0A=
        Device X is powered by Device Y and powered by Device Z.=0A=
     =0A=
           +----------+           poweredBy +------------+=
=0A=
           |  PDU Y   |---------------------|  Device X  |=0A=
           +----------+ powers              +------------+=
=0A=
     =0A=
           +----------+           poweredBy +------------+=
=0A=
           |  PDU Z   |---------------------|  Device X  |=0A=
           +----------+ powers              +------------+=
=0A=
     =0A=
     
6.2. Metering Relationship
=0A=
     =0A=
     =0A=
     =0A=
     Claise et al.           Expires March 23, 2014   =
   [Page 37]=0A=
     


 =0A=
     Internet-Draft              EMAN Framework      S=
eptember 2013=0A=
     =0A=
        Case 1: Metering between two Devices=0A=
     =0A=
        The metering topology between two devices is closely=0A=
        related to the power source topology.  It is based on the=0A=
        assumption that in many cases the power provided and the=0A=
        power received is the same for both peers of a power source=0A=
        relationship.=0A=
     =0A=
        We define in this case a Metering Relationship between two=0A=
        Devices or Power Interfaces of Devices that have a power=0A=
        source relationship.  Power and energy values measured at=0A=
        one peer of the power source relationship are reported for=0A=
        the other peer as well.=0A=
     =0A=
        The Metering Relationship is independent of the direction=0A=
        of the Power Source Relationship.  The most common case is=0A=
        that values measured at the power provider are reported for=0A=
        the power receiver.=0A=
     =0A=
        +-----+---+    meteredBy +--------+   poweredBy=
 +-------+=0A=
        |Meter| PI|--------------| switch |-------------| phone |=0A=
        +-----+---+ meters       +--------+ powers     =
 +-------+=0A=
                |                                           |=0A=
                |                                 meteredBy |=0A=
                +-------------------------------------------+=0A=
                 meters=0A=
     =0A=
        Case 2: Metering among many Devices=0A=
     =0A=
        A Sub-meter in a power distribution system can logically=0A=
        measure the=0A=
        power or energy for all devices downstream from the meter=0A=
        in the power distribution system.  As such, a Power=0A=
        metering relationship can be seen as a relationship between=0A=
        a meter Device and all of the devices downstream from the=0A=
        meter.=0A=
     =0A=
        We define in this case a Power Source relationship between=0A=
        a metering device and devices downstream from the meter.=0A=
     =0A=
        In cases where the Power Source topology cannot be=0A=
        discovered or derived from the information available in the=0A=
        Energy Management Domain, the Metering Topology can be used=0A=
        to relate the upstream meter to the downstream devices in=0A=
        the absence of specific power source relationships.=0A=
     =0A=
        A Metering Relationship can occur between devices that are=0A=
        not directly connected, as shown in the following figure:=0A=
     =0A=
     =0A=
     =0A=
     Claise et al.           Expires March 23, 2014   =
   [Page 38]=0A=
     


 =0A=
     Internet-Draft              EMAN Framework      S=
eptember 2013=0A=
     =0A=
     =0A=
                           +---------------+=0A=
                           |   Device 1    |=0A=
                           +---------------+=0A=
                           |      PI       |=0A=
                           +---------------+=0A=
                                   |=0A=
                           +---------------+=0A=
                           |     Meter     |=0A=
                           +---------------+=0A=
                                   .=0A=
                                   .=0A=
                                   .=0A=
                  meters        meters           meters=0A=
            +----------+   +----------+   +-----------&=
#43;=0A=
            | Device A |   | Device B |   | Device C  |=0A=
            +----------+   +----------+   +-----------&=
#43;=0A=
     =0A=
        An analogy to communications networks would be modeling=0A=
        connections between servers (meters) and clients (devices)=0A=
        when the complete Layer 2 topology between the servers and=0A=
        clients is not known.=0A=
     =0A=
     
6.3. Aggregation Relationship
=0A=
     =0A=
        Some devices can act as aggregation points for other=0A=
        devices.  For example, a PDU controller device may contain=0A=
        the summation of power and energy readings for many PDU=0A=
        devices.  The PDU controller will have aggregate values for=0A=
        power and energy for a group of PDU devices.=0A=
     =0A=
        This aggregation is independent of the physical power or=0A=
        communication topology.=0A=
        An Aggregation Relationship is an Energy Object=0A=
        Relationship where one Energy Object (called the Aggregate=0A=
        Energy Object) aggregates the Energy Management information=0A=
        of one or more other Energy Objects.  These Energy Objects=0A=
        are said to have an Aggregation Relationship.=0A=
     =0A=
        The functions that the aggregation point may perform=0A=
        include the calculation of values such as average, count,=0A=
        maximum, median, minimum, or the listing (collection) of=0A=
        the aggregation values, etc.=0A=
        Based on the experience gained on aggregations at the IETF=0A=
        [draft-ietf-ipfix-a9n-08], the aggregation function in th=
e=0A=
        EMAN framework is limited to the summation.=0A=
     =0A=
        When aggregation occurs across a set of entities, values to=0A=
        be aggregated may be missing for some entities.  The EMAN=0A=
     =0A=
     =0A=
     Claise et al.           Expires March 23, 2014   =
   [Page 39]=0A=
     


 =0A=
     Internet-Draft              EMAN Framework      S=
eptember 2013=0A=
     =0A=
        framework does not specify how these should be treated, as=0A=
        different implementations may have good reason to take=0A=
        different approaches.  One common treatment is to define=0A=
        the aggregation as missing if any of the constituent=0A=
        elements are missing (useful to be most precise). Another=0A=
        is to treat the missing value as zero (useful to have=0A=
        continuous data streams).=0A=
     =0A=
        The specifications of aggregation functions are out of=0A=
        scope of the EMAN framework, but must be clearly specified=0A=
        by the equipment vendor.=0A=
     =0A=
     
7. Relationship to Other Standards
=0A=
     =0A=
        This Energy Management framework uses, as much as possible,=0A=
        existing standards especially with respect to information=0A=
        modeling and data modeling [RFC3444].=0A=
     =0A=
        The data model for power- and energy-related objects is=0A=
        based on [IEC61850].=0A=
     =0A=
        Specific examples include:=0A=
           o  The scaling factor, which represents Energy Object=0A=
              usage magnitude, conforms to the [IEC=
61850]=0A=
              definition of unit multiplier for the SI (System=0A=
              International) units of measure.=0A=
           o  The electrical characteristic is based on the ANSI=0A=
              and IEC Standards, which require that we use an=0A=
              accuracy class for power measurement.  ANSI and IEC=0A=
              define the following accuracy classes for power=0A=
              measurement:=0A=
           o  IEC 62053-22  60044-1 class 0.1, 0.2, 0.5, 1  3.=0A=
           o  ANSI C12.20 class 0.2, 0.5=0A=
           o  The electrical characteristics and quality adhere=0A=
              closely to the [IEC61850-7-2]=
 standard for describing=0A=
              AC measurements.=0A=
           o  The power state definitions are based on the DMTF=0A=
              Power State Profile and ACPI models, with operational=0A=
              state extensions.=0A=
     =0A=
     
8. Security Considerations
=0A=
     =0A=
        Regarding the data attributes specified here, some or all=0A=
        may be considered sensitive or vulnerable in some network=0A=
        environments. Reading or writing these attributes without=0A=
        proper protection such as encryption or access=0A=
        authorization may have negative effects on the network=0A=
        capabilities.=0A=
     =0A=
     =0A=
     =0A=
     Claise et al.           Expires March 23, 2014   =
   [Page 40]=0A=
     


 =0A=
     Internet-Draft              EMAN Framework      S=
eptember 2013=0A=
     =0A=
     
8.1. Security Considerations for SNMP
=0A=
     =0A=
        Readable objects in MIB modules (i.e., objects with a MAX-=0A=
        ACCESS other than not-accessible) may be considered=0A=
        sensitive or vulnerable in some network environments.  It=0A=
        is important to control GET and/or NOTIFY access to these=0A=
        objects and possibly to encrypt the values of these objects=0A=
        when sending them over the network via SNMP.=0A=
     =0A=
        The support for SET operations in a non-secure environment=0A=
        without proper protection can have a negative effect on=0A=
        network operations.=0A=
     =0A=
        For example:=0A=
           o  Unauthorized changes to the Energy Management Domain=0A=
              or business context of a device may result in=0A=
              misreporting or interruption of power.=0A=
           o  Unauthorized changes to a power state may disrupt the=0A=
              power settings of the different devices, and=0A=
              therefore the state of functionality of the=0A=
              respective devices.=0A=
           o  Unauthorized changes to the demand history may=0A=
              disrupt proper accounting of energy usage.=0A=
     =0A=
        With respect to data transport, SNMP versions prior to=0A=
        SNMPv3 did not include adequate security.  Even if the=0A=
        network itself is secure (for example, by using IPsec),=0A=
        there is still no secure control over who on the secure=0A=
        network is allowed to access and GET/SET=0A=
        (read/change/create/delete) the objects in these MIB=0A=
        modules.=0A=
     =0A=
        It is recommended that implementers consider the security=0A=
        features as provided by the SNMPv3 framework (see=0A=
        [RFC3410], section 8), including full support for the=0A=
        SNMPv3 cryptographic mechanisms (for authentication and=0A=
        privacy).=0A=
        Further, deployment of SNMP versions prior to SNMPv3 is not=0A=
        recommended.  Instead, it is recommended to deploy SNMPv3=0A=
        and to enable cryptographic security.  It is then a=0A=
        customer/operator responsibility to ensure that the SNMP=0A=
        entity giving access to an instance of these MIB modules is=0A=
        properly configured to give access to the objects only to=0A=
        those principals (users) that have legitimate rights to GET=0A=
        or SET (change/create/delete) them.=0A=
     =0A=
     =0A=
     =0A=
     =0A=
     =0A=
     =0A=
     Claise et al.           Expires March 23, 2014   =
   [Page 41]=0A=
     


 =0A=
     Internet-Draft              EMAN Framework      S=
eptember 2013=0A=
     =0A=
     
9. IANA Considerations
=0A=
     
9.1. IANA Registration of new Power State Sets
=0A=
     =0A=
        This document specifies an initial set of Power State Sets.=0A=
        The list of these Power State Sets with their numeric=0A=
        identifiers is given is Section 4. IANA ma=
intains the lists=0A=
        of Power State Sets.=0A=
     =0A=
        New assignments for Power State Set are administered by=0A=
        IANA through Expert Review [RFC5226], i.e., review by one=0A=
        of a group of experts designated by an IETF Area Director.=0A=
        The group of experts MUST check the requested state for=0A=
        completeness and accuracy of the description. A pure vendor=0A=
        specific implementation of Power State Set shall not be=0A=
        adopted; since it would lead to proliferation of Power=0A=
        State Sets.=0A=
     =0A=
        Power states in a Power State Set are limited to 255=0A=
        distinct values. New Power State Set must be assigned the=0A=
        next available numeric identifier that is a multiple of=0A=
        256.=0A=
     =0A=
     
9.1.1. IANA Registration of the IEEE1621 Power Stat=
e Set
=0A=
     =0A=
        This document specifies a set of values for the IEEE1621=0A=
        Power State Set [IEEE1621].  The list of these val=
ues with=0A=
        their identifiers is given in Section 4.6.=
2.  IANA created=0A=
        a new registry for IEEE1621 Power State Set identifiers and=0A=
        filled it with the initial list of identifiers.=0A=
     =0A=
        New assignments (or potentially deprecation) for the=0A=
        IEEE1621 Power State Set is administered by IANA through=0A=
        Expert Review [RFC5226], i.e., review by one of a group of=0A=
        experts designated by an IETF Area Director.  The group of=0A=
        experts must check the requested state for completeness and=0A=
        accuracy of the description.=0A=
     =0A=
     
9.1.2. IANA Registration of the DMTF Power State Se=
t
=0A=
     =0A=
        This document specifies a set of values for the DMTF Power=0A=
        State Set.  The list of these values with their identifiers=0A=
        is given in Section 4. IANA has created a =
new registry for=0A=
        DMTF Power State Set identifiers and filled it with the=0A=
        initial list of identifiers.=0A=
     =0A=
        New assignments (or potentially deprecation) for the DMTF=0A=
        Power State Set is administered by IANA through Expert=0A=
        Review [RFC5226], i.e., review by one of a group of experts=0A=
        designated by an IETF Area Director.  The group of experts=0A=
     =0A=
     =0A=
     Claise et al.           Expires March 23, 2014   =
   [Page 42]=0A=
     


 =0A=
     Internet-Draft              EMAN Framework      S=
eptember 2013=0A=
     =0A=
        must check the conformance with the DMTF standard [DMTF],=0A=
        on the top of checking for completeness and accuracy of the=0A=
        description.=0A=
     =0A=
     
9.1.3. IANA Registration of the EMAN Power State Se=
t
=0A=
     =0A=
        This document specifies a set of values for the EMAN Power=0A=
        State Set.  The list of these values with their identifiers=0A=
        is given in Section 4.6.4.  IANA has c=
reated a new registry=0A=
        for EMAN Power State Set identifiers and filled it with the=0A=
        initial list of identifiers.=0A=
     =0A=
        New assignments (or potentially deprecation) for the EMAN=0A=
        Power State Set is administered by IANA through Expert=0A=
        Review [RFC5226], i.e., review by one of a group of experts=0A=
        designated by an IETF Area Director.  The group of experts=0A=
        must check the requested state for completeness and=0A=
        accuracy of the description.=0A=
     =0A=
     
9.1.4. Batteries Power State Set
=0A=
     =0A=
        Batteries have operational and administrational states that=0A=
        could be represented as a power state set. Since the work=0A=
        for battery management is parallel to this document, we are=0A=
        not proposing any Power State Sets for batteries at this=0A=
        time.=0A=
     =0A=
     
9.2. Updating the Registration of Existing Power State =
Sets
=0A=
     =0A=
        With the evolution of standards, over time, it may be=0A=
        important to deprecate some of the existing the Power State=0A=
        Sets, or to add or deprecate some Power States within a=0A=
        Power State Set.=0A=
     =0A=
        The registrant shall publish an Internet-draft or an=0A=
        individual submission with the clear specification on=0A=
        deprecation of Power State Sets or Power States registered=0A=
        with IANA.  The deprecation or addition shall be=0A=
        administered by IANA through Expert Review [RFC5226], i.e.,=0A=
        review by one of a group of experts designated by an IETF=0A=
        Area Director. The process should also allow for a=0A=
        mechanism for cases where others have significant=0A=
        objections to claims on deprecation of a registration.=0A=
     =0A=
     
10. References
=0A=
     =0A=
     Normative References=0A=
     =0A=
     =0A=
     =0A=
     =0A=
     Claise et al.           Expires March 23, 2014   =
   [Page 43]=0A=
     


 =0A=
     Internet-Draft              EMAN Framework      S=
eptember 2013=0A=
     =0A=
        [RFC2119]  Bradner, =
S., "Key words for use in RFCs to=0A=
                  Indicate Requirement Levels", BCP 14, RFC 2119,=0A=
                  March 1997=0A=
     =0A=
        [RFC3410]  Case, J.,=
 Mundy, R., Partain, D., and B.=0A=
                  Stewart, "Introduction and Applicability=0A=
                  Statements for Internet Standard Management=0A=
                  Framework ", RFC 3410, December 2002=0A=
     =0A=
        [RFC4122] Leach, P.,=
 Mealling, M., and R. Salz," A=0A=
                  Universally Unique Identifier (UUID) URN=0A=
                  Namespace", RFC 4122, July 2005=0A=
     =0A=
        [RFC5226] Narten, T.=
, and H. Alvestrand, "Guidelines for=0A=
                  Writing an IANA Considerations Section in RFCs",=0A=
                  RFC 5226, May 2008=0A=
     =0A=
        [RFC6933]  Bierman, =
A. and K. McCloghrie, "Entity MIB=0A=
                  (Version4)", RFC 6933, May 2013=0A=
     =0A=
        [RFC3444] Pras, A., =
Schoenwaelder, J. "On the Differences=0A=
                  between Information Models and Data Models", RFC=0A=
                  3444, January 2003=0A=
     =0A=
        [I=
SO-IEC-19501-2005] ISO/IEC 19501:2005, Information=0A=
                  technology, Open Distributed Processing --=0A=
                  Unified Modeling Language (UML), January 2005=0A=
     =0A=
     Informative References=0A=
     =0A=
        [RFC2578] McCloghrie=
, K., Perkins, D., and J.=0A=
                  Schoenwaelder, "Structure of Management=0A=
                  Information Version 2 (SMIv2", RFC 2578, April=0A=
                  1999=0A=
     =0A=
     =0A=
        [RFC5101bis] C=
laise, B., Ed., and Trammel, T., Ed.,=0A=
                  "Specification of the IP Flow Information Export=0A=
                  (IPFIX) Protocol for the Exchange of IP Traffic=0A=
                  Flow Information ", draft-ietf=
-ipfix-protocol-=0A=
                  rfc5101bis-08, (work in progres=
s), June 2013=0A=
     =0A=
        [RFC6020] M. Bjorklu=
nd, Ed., " YANG - A Data Modeling=0A=
                  Language for the Network Configuration Protocol=0A=
                  (NETCONF)", RFC 6020, October 2010=0A=
     =0A=
        [ACPI] "Advanced Conf=
iguration and Power Interface=0A=
                  Specification", http://www.acpi.info/spec30b.htm=0A=
     =0A=
     =0A=
     =0A=
     Claise et al.           Expires March 23, 2014   =
   [Page 44]=0A=
     


 =0A=
     Internet-Draft              EMAN Framework      S=
eptember 2013=0A=
     =0A=
        [IEEE1621]  "=
Standard for User Interface Elements in Power=0A=
                  Control of Electronic Devices Employed in=0A=
                  Office/Consumer Environments", IEEE 1621,=0A=
                  December 2004=0A=
     =0A=
        [LLDP]  IEEE Std 802.1AB, =
"Station and Media Control=0A=
                  Connectivity Discovery", 2005=0A=
     =0A=
        [LLDP-MED-MIB<=
/a>]  ANSI/TIA-1057, "The LLDP Management=0A=
                  Information Base extension module for TIA-TR41.4=0A=
                  media endpoint discovery information", July 2005=0A=
     =0A=
        [EMAN-REQ] Quittek=
, J., Winter, R., Dietz, T., Claise, B.,=0A=
                  and M. Chandramouli, "Requirements for Energy=0A=
                  Management", draft-ietf-eman-requireme=
nts-14,=0A=
                  (work in progress), May 2013=0A=
     =0A=
        [EMAN-OB=
JECT-MIB] Parello, J., and B. Claise, "Energy=0A=
                  Object Contet MIB", draft-ietf-ema=
n-energy-aware-=0A=
                  mib-08, (work in progress), April 2=
013=0A=
     =0A=
        [EMAN-MON-MIB<=
/a>] Chandramouli, M.,Schoening, B., Quittek, J.,=0A=
                  Dietz, T., and B. Claise, "Power and Energy=0A=
                  Monitoring MIB", draft-ietf-e=
man-energy-=0A=
                  monitoring-mib-05, (work in pr=
ogress), April 2013=0A=
     =0A=
        [EMAN-=
BATTERY-MIB] Quittek, J., Winter, R., and T. Dietz, "=0A=
                  Definition of Managed Objects for Battery=0A=
                  Monitoring", draft-ietf-eman-battery-mi=
b-08,=0A=
                  (work in progress), February 2013=0A=
     =0A=
        [EMAN-AS] Schoening,=
 B., Chandramouli, M., and B. Nordman,=0A=
                  "Energy Management (EMAN) Applicability=0A=
                  Statement", draft-ietf-eman=
-applicability-=0A=
                  statement-03, (work in progr=
ess), April 2013=0A=
     =0A=
        [ITU-T-M-3400<=
/a>] TMN recommandation on Management Functions=0A=
                  (M.3400), 1997=0A=
     =0A=
        [NMF] "Network Manageme=
nt Fundamentals", Alexander Clemm,=0A=
                  ISBN: 1-58720-137-2, 2007=0A=
     =0A=
        [TMN] "TMN Management F=
unctions : Performance Management",=0A=
                  ITU-T M.3400=0A=
     =0A=
        [IEEE100] "The =
Authoritative Dictionary of IEEE Standards=0A=
                  Terms"=0A=
                  http://ieeexplore.ieee.org/xpl/mostRecentIssue.js=0A=
                  p?punumber=3D4116785=0A=
     =0A=
     =0A=
     Claise et al.           Expires March 23, 2014   =
   [Page 45]=0A=
     


 =0A=
     Internet-Draft              EMAN Framework      S=
eptember 2013=0A=
     =0A=
     =0A=
        [ISO50001] "I=
SO 50001:2011 Energy management systems -=0A=
                  Requirements with guidance for use",=0A=
                  http://=
www.iso.org/=0A=
     =0A=
        [IEC60050] Interna=
tional Electrotechnical Vocabulary=0A=
                  http://www.electropedia.org/iev/iev.nsf/welcome?o=0A=
                  penform=0A=
     =0A=
        [IEC61850] Power U=
tility Automation,=0A=
                  http://www.iec.ch/smartgrid/standards/=0A=
     =0A=
        [IEC61850-7-2<=
/a>] Abstract communication service interface=0A=
                  (ACSI), http://www.iec.ch/smartgrid/standards/=0A=
     =0A=
        [IEEE-802.3at<=
/a>] IEEE 802.3 Working Group, "IEEE Std 802.3at-=0A=
                  2009 - IEEE Standard for Information technology -=0A=
                  Telecommunications and information exchange=0A=
                  between systems - Local and metropolitan area=0A=
                  networks - Specific requirements - Part 3:=0A=
                  Carrier Sense Multiple Access with Collision=0A=
                  Detection (CSMA/CD) Access Method and Physical=0A=
                  Layer Specifications - Amendment: Data Terminal=0A=
                  Equipment (DTE) -  Power via Media Dependent=0A=
                  Interface (MDI) Enhancements", October 2009=0A=
     =0A=
        [DMTF] "Power State M=
anagement Profile DMTF  DSP1027=0A=
                  Version 2.0"  December 2009=0A=
                  http://www.dmtf.org/site=
s/default/files/standards=0A=
                  /documents/DSP1027_2.0.0=
.pdf=0A=
     =0A=
        [IPENERGY] R. Aldr=
ich, J. Parello "IP-Enabled Energy=0A=
                  Management", 2010, Wiley Publishing=0A=
     =0A=
        [X.700]  CCITT Recommend=
ation X.700 (1992), Management=0A=
                  framework for Open Systems Interconnection (OSI)=0A=
                  for CCITT applications=0A=
     =0A=
        [ASHRAE-201] &=
quot;ASHRAE Standard Project Committee 201=0A=
                        (SPC 201)Facility Smart Grid Information=0A=
                        Model", http://spc201.ashraepcs.org=0A=
     =0A=
        [CHEN] "The Entity-Re=
lationship Model: Toward a Unified=0A=
                  View of Data",  Peter Pin-shan Chen, ACM=0A=
                  Transactions on Database Systems, 1976=0A=
     =0A=
     =0A=
     =0A=
     =0A=
     =0A=
     =0A=
     Claise et al.           Expires March 23, 2014   =
   [Page 46]=0A=
     


 =0A=
     Internet-Draft              EMAN Framework      S=
eptember 2013=0A=
     =0A=
        [CISCO-EW] "C=
isco EnergyWise Design Guide",  John Parello,=0A=
                  Roland Saville, Steve Kramling, Cisco Validated=0A=
                  Designs, September 2010,=0A=
                  htt=
p://www.cisco.com/en/US/docs/solutions/Enterpr=0A=
                  ise=
/Borderless_Networks/Energy_Management/energyw=0A=
                  isedg.html=0A=
     =0A=
     =0A=
     =0A=
     
11. Acknowledgments
=0A=
     =0A=
        The authors would like to Michael Brown for his editorial=0A=
        work improving the text dramatically. Thanks to Rolf Winter=0A=
        for his feedback and to Bill Mielke for feedback and very=0A=
        detailed review. Thanks to Bruce Nordman for brainstorming=0A=
        with numerous conference calls and discussions. Finally,=0A=
        the authors would like to thank the EMAN chairs: Nevil=0A=
        Brownlee, Bruce Nordman, and Tom Nadeau.=0A=
     =0A=
        This document was prepared using 2-Word-v2.0.template.dot.=0A=
     =0A=
     Authors' Addresses=0A=
     =0A=
        John Parello=0A=
        Cisco Systems, Inc.=0A=
        3550 Cisco Way=0A=
        San Jose, California 95134=0A=
        US=0A=
     =0A=
        Phone: +1 408 525 2339=0A=
        Email: jparello@cisco.com=0A=
     =0A=
        Benoit Claise=0A=
        Cisco Systems, Inc.=0A=
        De Kleetlaan 6a b1=0A=
        Diegem 1813=0A=
        BE=0A=
     =0A=
        Phone: +32 2 704 5622=0A=
        Email: bclaise@cisco.com=0A=
     =0A=
     =0A=
        Brad Schoening=0A=
        44 Rivers Edge Drive=0A=
        Little Silver, NJ 07739=0A=
        US=0A=
     =0A=
        Phone:=0A=
        Email: brad.schoening@verizon.net=0A=
     =0A=
     =0A=
     Claise et al.           Expires March 23, 2014   =
   [Page 47]=0A=
     


 =0A=
     Internet-Draft              EMAN Framework      S=
eptember 2013=0A=
     =0A=
     =0A=
     =0A=
        Juergen Quittek=0A=
        NEC Europe Ltd.=0A=
        Network Laboratories=0A=
        Kurfuersten-Anlage 36=0A=
        69115 Heidelberg=0A=
        Germany=0A=
     =0A=
        Phone: +49 6221 90511 15=0A=
        EMail: quittek@netlab.nec.de=0A=
     =0A=
     =0A=
     =0A=
     =0A=
     =0A=
     =0A=
     =0A=
     =0A=
     =0A=
     =0A=
     =0A=
     =0A=
     =0A=
     =0A=
     =0A=
     =0A=
     =0A=
     =0A=
     =0A=
     =0A=
     =0A=
     =0A=
     =0A=
     =0A=
     =0A=
     =0A=
     =0A=
     =0A=
     =0A=
     =0A=
     =0A=
     =0A=
     =0A=
     =0A=
     =0A=
     =0A=
     =0A=
     =0A=
     =0A=
     =0A=
     Claise et al.           Expires March 23, 2014      [Page 48]=0A=
     =0A=















--_000_9C213D38848B89428F46808B16F6F086016678F4xmbalnx04ciscoc_--

From jparello@cisco.com  Sun Oct 13 14:54:19 2013
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 37FCE21F9D0A for ; Sun, 13 Oct 2013 14:54:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.303
X-Spam-Level: 
X-Spam-Status: No, score=-8.303 tagged_above=-999 required=5 tests=[AWL=-0.305, BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fdY1dUx3g8yX for ; Sun, 13 Oct 2013 14:54:11 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id B849B21F9A37 for ; Sun, 13 Oct 2013 14:54:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=66174; q=dns/txt; s=iport; t=1381701250; x=1382910850; h=from:to:cc:subject:date:message-id:mime-version; bh=3ZevnBU7AXzZdGFCEk5DBj6IN+CHk8E7qeKB57PjByA=; b=OpNeWXZPiNRGa3p0LRnjzw8+3szBMU5dOBkyBG/6Wz2G/y4oOqPOctb0 MeGCDk1mDk43OeHYHGi1hjpo3a6avHdohl7X6qMdGtHj/t3Wetj/oiVjL gZYzYXeDC163OpghQlW2UaomkmwYnHKSmDnyGRX/XhRyJaivHXf5ubgG4 Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AlwGAM0VW1KtJV2Z/2dsb2JhbABPAQmCQ0Q4UsFtgRoWbQeCJwEEGgEMQAsHEgEqFgE/JgEEDgMKARCHbQy8aY4DDAEDBgGBBw8igyaBBAOJBIsklV+DJECBJwkXIg
X-IronPort-AV: E=Sophos;i="4.93,487,1378857600";  d="scan'208,217";a="271629643"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-8.cisco.com with ESMTP; 13 Oct 2013 21:54:08 +0000
Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r9DLs7GJ028693 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 13 Oct 2013 21:54:07 GMT
Received: from xmb-aln-x04.cisco.com ([169.254.9.229]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.004; Sun, 13 Oct 2013 16:54:07 -0500
From: "John Parello (jparello)" 
To: "eman@ietf.org" 
Thread-Topic: Quittek - [eman] draft-ietf-eman-framework-10: WGLC comments
Thread-Index: Ac7IXr1CHjLfu4ypRT2Bbdujv+boog==
Date: Sun, 13 Oct 2013 21:54:06 +0000
Message-ID: <9C213D38848B89428F46808B16F6F08601667906@xmb-aln-x04.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.21.78.193]
Content-Type: multipart/alternative; boundary="_000_9C213D38848B89428F46808B16F6F08601667906xmbalnx04ciscoc_"
MIME-Version: 1.0
Subject: [eman] Quittek -  draft-ietf-eman-framework-10: WGLC comments
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 13 Oct 2013 21:54:19 -0000

--_000_9C213D38848B89428F46808B16F6F08601667906xmbalnx04ciscoc_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Thanks Juergen for the detailed review. I've applied the majority of your c=
omments which will apear in -11
See inline:
(+) Applied in the draft
(-) Regretfully not applied for the reasons listed
(!) Not applied needing more clarification and/or see further comment or th=
read

 for better reading....


------
Dear all,

Here is my review of draft-ietf-eman-framework-10. I did not review version=
 -09 for which the call was made, but the newer version -10 that was posted=
 during last call.



General comments:

A. The document rather looks like a documentation of a software design (wit=
h some extensions) than like a framework for energy management. Modeling fo=
cusses on abstractions, classes, attributes, but issues of the physical wor=
ld are neglected.

JP : Hopefully cleared up with your comments below

B. Do we claim that energy management is (a) a part of network management e=
xtending FCAPS or do we see this energy management (b) as something separat=
e from network management? Several statements in the draft seem to assume (=
b).

JP : It's clearly both. For example Security is a an area of mgt that can s=
tand apart from network management and is also a part of it.

C. The text has improved from earlier versions. Still, phrasing is often sl=
oppy and not up to the quality we should have for RFCs. Many phrasings soun=
d nice, but only as long as you are not interested in understanding exactly=
 what they mean. I commented on several instances below, but by far not on =
all of them.

JP : Obviously by submitting the draft to  WGLC we feel it is ready to prog=
ress.  I'd hate for you to withdraw as an author but considering your stron=
g value judgement on the rest of our work I would completely understand if =
you did and wanted to remain a valued reviewer.  I'll progress on your comm=
ents and edits below in the hope that you can reconcile your feelings on th=
is.

D. I have not thoroughly reviewed the ridiculously long terminology section=
 on pages 5-10. This can be cut significantly. Do we really want to re-defi=
ne terms you can find in text books, such as power-->Power, energy-->Energy=
, device-->Device, etc., etc.?  It is certainly necessary to define a term =
like "Power State", But defining "Power State Set" as a set of power states=
, etc., etc. is just a waste.

JP : We moved the modeling terms out as well so this shortened the section.=
 As a WG, we, you included, have spent many a call and draft revision on th=
e terms. I'll consider this as a +1 from you on the separate terminology dr=
aft that I both proposed as work for the group and I asked for as a WG docu=
ment at IETF 87.

E. The physical reference model in section 3.2 is missing most of the requi=
red content. Basic components of the model are not defined, see item 15. be=
low. Further missing is the physical mode of a meter and of a power interfa=
ce.

JP : For the physical I hope you can see we tried to trim the draft to a re=
asonable discussion on the physical topologies. Please see modifications in=
 -11 and described below. As for the physical mode of a power interface as =
a meter we discussed that in
http://www.ietf.org/mail-archive/web/eman/current/msg01993.html
http://www.ietf.org/mail-archive/web/eman/current/msg01996.html
and concluded that metering is an overloaded term and should be used to des=
cribe a device that is a meter not the act of measuring. Measuring !=3D met=
ering.


F. The information model in this draft is lacking elements for battery mana=
gement.

JP : Which elements from the battery MIB should be provided back in the abs=
tract model of the framework? We included store and the stored energy field=
s. We could as in other threads put the charging states in the state regist=
ries and consolidate the models.


G. Technically, I would like to make a proposal for Sections 4.3.2-4.3.6, t=
he context information as there are currently: category, importance, keywor=
ds, role, and domain. I see that all of them can have their value in certai=
n deployments. However, I see two limitations:
G.1. The set of content information is fixed.
All of the included attributes have potential to be useful in certain deplo=
yments. However, in other scenarios, or with other management systems, othe=
r context information will be relevant, such as, for example, the devices l=
ocation or its power-down-priority.
G.2. There is only one instance of each per Energy Object
The current model allows for only one instance of each context attribute. T=
his is often not sufficient, particularly for type, role, and domain. As di=
scussed many times on the list, a device can be contained in multiple meter=
ing domain, ad device can have multiple roles, and it can match multiple ca=
tegories, such as, for example, distributor and meter.
What I think is needed is a more open and extensible framework for context =
information, that allows arbitrary context information and multiple instanc=
es of each context. The result could, for example, in XML look like

    distributor
    meter
    PDU
    East Wing
    Server Room
    Building A
    East Wing Level 3
    0.7

or in JSON look like
"context": {
    "category": [ "distributor", "meter" ],
    "role": "PDU",
    "location": [ "East Wing", "Server Room" ],
    "meteringDomain": [ "Building A", "East Wing Level 3" ],
    "costFactor": 0.7
}

JP : We've discussed this at length and the approach we chose was to use a =
vector for the keywords to allow for further defining context you describe.=
 We proposed scalar for the PRIMARY category and the PRIMARY role.

LOCATION: I think you are mistaking a vector as a way to provide a syntacti=
c/semantic definition of an attribute. Clearly location  is not a vector as=
 you describe it above. Recall RFC3814 has syslocation as a scalar. I doubt=
 you propose a device can exist in two locations, but what I glean from you=
r example is the desire for a syntax and semantic description of a specific=
 location.  I think adding a syntax and semantic to a scalar location attri=
bute such as described in rfc4776 (or geopriv) would be more appropriate. S=
o +1 on that, but just making it a vector does nothing.

ROLE: So I think what you want is a syntax and  semantic description of Rol=
e as well. In the absence of that work I think (based on feedback in deploy=
ments) it best to keep the attributes a scalar with guidelines to avoid the=
 same kind of mistake you propose with location.  In general making the val=
ues a vector in case it might be needed is over engineering the attribute. =
 Given the experience we've had from our deployments of these fields for qu=
ite some years now we've settled without the need for a vector for role, ca=
tegory, and domain. So -1 on vector for the same reasons as location and +1=
 on working on a semantic in later work.

CATEGORY: We discussed this previously. We said the category represents the=
 primary purpose w.r.t. EM.
See reply here http://www.ietf.org/mail-archive/web/eman/current/msg02026.h=
tml
We implemented this in our devices and systems as a vector and changed to a=
 scalar for reason's that echo Brad's description. The value of the field w=
as marginalized when it was a vector.

ETC: We can separate this to a thread not to debate but to remind you of th=
e approach if that's helpful (ex: not sure what you're talking about for me=
tering domain? and cost "factor" is specifically out of scope.)


Specific comments:

1. Abstract, line 1: "This document defines a framework for providing Energ=
y Management ..."
Why for only for 'providing' energy management? Why not as well for operati=
ng, maintaining, etc. I suggest deleting 'providing'.

+ JP - removed "providing"

2. Abstract, lines 5-7: "The information model consists of an Energy Manage=
ment Domain as a set of Energy Objects. Each Energy Object is identified, c=
lassified, and given context."
Obviously, the first sentence is nonsense. The second sentence is only corr=
ect if it is mandatory to add context and classification to every energy ob=
ject. I do not see this in the framework. I suggest replacing the quoted te=
xt it with "The information model describes Energy Objects to which informa=
tion on their identity, classification, and context can be attributed."

+ JP - ignoring the value judgement (especially since we reviewed this abst=
ract at length together) your point under it all was to make sure the abstr=
act do not infer mandatory. Done.

3. Abstract, lines 7-9: "Energy Objects can be monitored and controlled wit=
h respect to Power, Power State, Energy, Demand, Power Attributes, and Batt=
ery."
Control is only available for power states and for battery states. The curr=
ent text implies much more. I suggest clarifying this, for example, using t=
he following text as replacement: "The framework covers monitoring of Power=
, Power State, Energy, Demand, Power Attributes, battery properties and bat=
tery states of Energy Objects. It also covers control of power states and b=
attery states."

! JP : Not sure how the current text implies more. For example by controlli=
ng power states you will control energy so I think the text as it stands is=
 more concise with the same meaning esp. for an abstract.  I think the text=
 you have is equal and less concise than the original. If you give me an id=
ea / example of what you think it implies that it should not then I am sure=
 I  can craft something simpler.

4. Section 1 "Introduction", 2nd paragraph, lines 3-4 (page 3): "router" --=
> ""

+ JP : done

5. Section 1 "Introduction", 2nd paragraph, lines 8-9 (page 4): "If a devic=
e contains batteries, these can also be monitored and controlled."
Obviously, it is not sufficient that a device just contains batteries for b=
eing able to control them. I suggest replacing the text by "Monitoring and =
control of batteries contained in devices is also covered by the EMAN frame=
work.

+ JP : change to "The framework also covers monitoring and control of batte=
ries contained in devices."

6. Section 1 "Introduction", 5th paragraph, last 2 lines: "and an understan=
ding of the potential aggregation (ex: does a meter aggregate values from o=
ther devices)"
I do not think it is clear at this place what "aggregation"/"aggregate" mea=
ns.

+ JP: Carried the alliteration along and replaced it with
"""
An EnMS (Energy Management System) generally requires an understanding of t=
he power topology (who provides power to whom), the metering topology (who =
meters whom), and an understanding of the potential aggregation (who aggreg=
ate values of others).
"""

7. Section 2: Terminology, page 9, "Power Interface"
The text says: "A Power Interface (...) is an information model (class) tha=
t represents ...". This is wrong. A Power interface is located at a device =
and is not an abstract class. The abstract class is called "Power Interface=
 Class", see section 4.2.3

- JP : The Power Interface (class) is an abstract representation on a Devic=
e (class) of a physical inlet or outlet which is located on a physical devi=
ce.

8. Section 2: Terminology, page 9, "Energy Object"
See point 7. above. These are physical objects, not classes.

- JP : We've made the distinction between the abstract representation in th=
e model versus the physical. Ex: I've tripped over many devices in my life =
but never an Energy Object. So Energy Object is the class and device being =
a piece of equipment is the physical thing.

9. Section 3.1, 3rd paragraph, last sentence: "These target devices include=
:"
I don't think the list below is exclusive. Suggestion: "These target device=
s include, for example:"

+ JP : Done

10. Section 3.1, 4th paragraph, line 1: "Target devices will primarily comm=
unicate via Internet Protocols"
Why "will"? Probably correct would be "do".

+ JP : Deleted "will"

11. Section 3.1, 4th paragraph, lines 2-3: "The target devices may also inc=
lude those communicating via non-IP protocols ..."
What's this? Do we here defining a standard? Either the standard includes n=
on-IP devices or not.
12. Section 3.1, 4th paragraph, lines 4-5: "These types of target devices a=
re expected to be managed through gateways ..."
What means "are expected"? What if this is not the case?
A proposal for solving 10., 11., and 12.:
OLD
        Target devices will primarily communicate via Internet
        Protocols (IP). The target devices may also include those
        communicating via non-IP protocols deployed among the power
        distribution and IP communication network. These types of
        target devices are expect to be managed through gateways or
        proxies that can communicate using IP.
NEW
        Target devices include devices that communicate via the Internet
        Protocol (IP) as well as devices using other means for communicatio=
n.
        The latter are managed through gateways or proxies that can
        communicate using IP.

+ JP : applied NEW

13. Section 3 "Concerns Specific to Energy Management"
This section describes target devices, a physical reference model, and "maj=
or concerns specific to Energy Management". Giving it a title that covers o=
nly the third item contained is inappropriate.

+ JP: "3. Target Devices, Physical Reference Model and Management Concerns"

14. Section 3 "Concerns Specific to Energy Management", 2nd sentence: "phys=
ical reference models" and Section 3.2 "Physical Reference Model", first se=
ntence: "The following reference models describe ..."
Here we have a terminology issue: The title of the section is  "Physical Re=
ference Model" and also the Abstract of the draft states "The framework pre=
sents a physical reference model ...". Both use the singular form of model.=
  But the second sentence of Section 3 and the first sentence of section 3.=
2 talk about multiple models. I think the Abstract and the section title ar=
e correct, but the sentence is wrong. There seem to be just a single model =
which is used to illustrate different scenarios in the figures in this sect=
ion.

+ JP : singular for model and plural for topologies

15. Section 3.2 "Physical Reference Model"
A model is used, but I cannot find it described in the draft, neither in th=
is section where one would expect it, nor anywhere else. Where is it? Just =
to be clear, a reference model typically consists of a set of roles, such a=
s, for example, device, energy management system, power source, etc., and o=
f relations, such as a power source relationship, a monitoring relationship=
, a control relationship, etc. I cannot find these defined as components of=
 the model.

! JP : We have defined the components of the model as diagrammed. If there'=
s more you think we need to add to describe the role, etc, in the model can=
 you provide concise text?


16. Section 3.3 "Concerns Differing from Network Management"
This section rather looks like a power point slide that can hardly be under=
stood without a person presenting it. The bullets in this section are too s=
hort for the reader to easily understand what issue is addressed at all and=
 what the consequences are. Some of the bullets do not make any sense to me=
. At least 6 out of 7 seem to be broken:
  - bullet #1: This does not seem to be different from network management
  - bullet #2:  I don't understand the last line: "controlling a simple lig=
ht by controlling its outlet". How does this work?
  - bullet #3: What special coordination do devices need if there is more t=
han one PDU in a power distribution network?
  - bullet #4: What means "require a separate interface model from Network =
Management"?
  - bullet #5: Seems to be broken. I don't get the message. Is there a typo=
 in the last line?
  - bullet #7: I am not sure what is really a difference to network managem=
ent where we have the entity MIB and different models for managing devices =
(e.g. routers) and components (e.g. line cards). The third paragraph of Sec=
tion 4.1 claims that this is very similar to network management.

! JP : Yes. As an editorial exercise I condensed the pages you all wrote th=
at covered this section from the previous drafts to a list. So I'm trying t=
o capture what you all as the authors want in this section. I don't think w=
e need pages of description just a few paragraphs simply listing the differ=
ences - if the section is needed at all. @Authors So what points would you =
like in? I'll proposed a new section.

17.  Section 3.4 "Concerns Not Addressed", 1st paragraph, line 4: "normaliz=
ed to the electrical units for power and energy". This is nonsense. There i=
s indeed an "electrical" units for power (Voltamperes,VA), but we are using=
 rather "non-electrical ones, such as Watts (Joule per second) and Watt-hou=
rs.
OLD
        Non-Electrical Equipment

        The primary focus of this framework is the management of
        Electrical Equipment.  Some Non-Electrical Equipment may be
        connected to communication networks and could have their
        energy managed if normalized to the electrical units for
        power and energy. Non-
        Electrical equipment that do not convert-to or present-as
        equivalent to Electrical Equipment is not addressed.
NEW
        Non-Electrical Equipment

        The primary focus of this framework is the management of
        Electrical Equipment.  Non-Electrical Equipment can be covered
        by the framework only if it provides interfaces that comply with
        the framework. For example, it must use the same units for power
        and energy.

+ JP : Again ignoring the value judgement as we meant the units we selected=
 for electrical equipment (W not VA since that is different for real and ap=
parent power). Changed to NEW


18. Section 4 "Energy Management Abstraction"
The first paragraph is identical with the first paragraph of Section 1 "Int=
roduction" and can be removed.

+ JP : Deleted.

19. Section 4.1 "Conceptual Model"
I am missing here a lot of information on the model.
19.1. Is the model normative or informational?

! JP : question for the chair to indicate. @Nevil the entire draft is infor=
mational what should be listed here?

19.2. Is it a model to be implemented inside the EnMS only or as well on th=
e Energy Objects?
19.3. If it is implemented at the Energy Objects, why storing context infor=
mation? This typically resides in the management system only.

- JP : we've discussed this on numerous threads. On the device for reasons =
described. It may be set on the device to be included in the EnMS and vice =
versa.

19.4. If it is implemented on Energy Objects, how does it specify which inf=
ormation is included for a device, and which (more limited) information is =
included for a component or power interface?

- JP : It's not limited for a component see class Component.

19.5. The model is lacking information on batteries.

! JP : See Benoit reply

20. Section 4.1, 3rd paragraph, line 1: "Therefore"-->""

+ JP : done

21. Section 4.1, 4th paragraph, line 2: "a Device, a Component, and a Power=
 Interface"
-->"a Device class, a Component class, and a Power Interface class"

+ JP : done

22. Section 4.1, 5th paragraph, line 2
OLD
        For modeling additional attributes, this section describes
        attributes of an Energy Object for: identification,
        classification, context, control, power and energy.
NEW
        This section describes attributes of an Energy Object for identific=
ation,
        classification, context, control, power and energy.

+ JP : done

23. Section 4.1, 6th paragraph.
The first sentence seems to be broken. The "interconnections for Network Ma=
nagement" are also used for Energy Management. Energy management needs at l=
east some of them to communicate between the EnMS and devices.

! JP : "may have no relation" so that covers your concern I think.

24. Section 4.1, title
This section is titled "Conceptual Model". But as the last paragraph of it =
states, the conceptual model is actually not in this section, but in the fo=
llowing sections 4.2-4.6. The title should be changed after fixing 20.-23.

+ JP : changed to  "next sections"

25. Section 4.2, title
"Energy Object" --> "Energy Object Class"

+ JP : done

26. Section 4.2.1, 2nd paragraph, line 2: "may represent" --> "represents"

+ JP : done

27. Section 4.2.1, 2nd paragraph:
Is this list exclusive? Are there no other kinds of devices supported?

! JP : nothing to do here. If there are more categories of devices in this =
context (EM) feel free to suggest and we can discuss. These categories are =
based on years of deployments and we've found little to no overlap in indic=
ating one primary category per device. Also it's been exhaustive for our de=
ployments. We can surely add more but we've found it to be enough.

28. Section 4.2.1, 2nd paragraph:
A device may be both, a meter and a distributor. How is this modeled?

- JP : We discussed this with you already and this is described as the prim=
ary purpose. For the problem space on EM these categories rarely overlap an=
d when they do the primary purpose always outweighs the others.
http://www.ietf.org/mail-archive/web/eman/current/msg02026.html

29. Section 4.2.1, 3rd paragraph:
OLD
        A Device Class instance may represent a physical device
        that contains other components.
NEW
        A Device Class instance may represent a physical device
        that contains other components.

- JP : Nothing to do here??

30. Section 4.3.1, 2nd sentence: "Ideally, the UUID is used to distinguish =
the Energy Object within the EnMS". Why ideally? What can be ideal for us i=
nfo model designer does not necessarily have to be ideal for the EnMS devel=
oper.

+ JP : Since we have RFC4122 now, this is
"""
A Universal Unique Identifier (UUID) [RFC4122] is used to uniquely and pers=
istently identify an Energy Object.
"""

31. Section 4.3.2. "Context in General"
What I am missing in this section

- JP : Can't read your mind ;)

32. Section 4.3.2, last paragraph:
I do not see the point made by this paragraph. How would context informatio=
n help the EnMS in this case?

+ JP : I agree with that. I deleted
"""
For example, metered usage reported by a meter and consumption usage report=
ed by a device connected to that meter may measure the same usage. With the=
 two measurements identified by category and context an EnMS can make summa=
rizations and inferences.
"""

33. Section 4.4, "Measurements", 2nd paragraph:
This is similar to item 17. There is no electrical or non-electrical Watt-h=
our.
OLD
        For the purposes of this framework, energy will be limited
        to electrical energy in watt-hours.  Other forms of Energy
        Objects that use or produce non-electrical energy may be
        modeled as an Energy Object but must provide information
        converted to and expressed in watt-hours.
NEW
        Within this framework, energy will only be quantified in units of
        in watt-hours. Energy Objects and Meters measuring Energy in
        other units must convert values to Watt-hours before reporting them=
.

+ JP : Done
"""
Within this framework, energy will only be quantified in units of in watt-h=
ours. Energy Objects measuring Energy in other units must convert values to=
 watt-hours.
"""

34. Section 4.4.1 "Measurements: Power", line 1:
"Each Energy Object contains a Nameplate Power attribute that describes the=
 nominal power as specified by the manufacturer." I am not sure, you will a=
lways find someone reading all the nameplate power values and entering them=
 to the device or the EnMS.
OLD
        Each Energy Object contains a Nameplate Power attribute
NEW
        Each Energy Object may contain a Nameplate Power attribute

35. Section 4.4.1 "Measurements: Power", 2nd paragraph, line 1:
OLD
        Each Energy Object will have information that describes the
NEW
        Each Energy Object may have information that describes the
OR NEW
        Each Energy Object has information that describes the

- JP : Left this out. I see your point for the device but this is describin=
g the  class. The class in the information model contains the attribute. Th=
e device may not provide it but the attribute is defined in the class and d=
oes exist there.

35. Section 4.4.4, last sentence: "Demand measurements can be provided when=
 the Energy Object is capable of measuring actual power."
This is wrong. Either delete this sentence (preferred) or use this one inst=
ead: "Demand measurements can only be provided when the Energy Object is ca=
pable of measuring demand."

- JP : Again we'd all like to be the harbinger of right and wrong but I'll =
comment on your opinion. What you have suggested is a tautology. We could s=
ay that for any attribute. However the point was, If a device is not capabl=
e of measuring power I'm not sure how it could measure demand (even energy)=
 for that matter. So if the device is not capable of actual power measureme=
nts demand and energy would be non existent.

36. Section 4.5 "Control", first sentence: An Energy Object can be controll=
ed by setting a Power State or a battery state.

! JP : Defer that. Can battery be listed as a power state series? see other=
 thread.

37. Section 4.5 "Control"
Power States and Power State sets are introduced in Section "Control". That=
's wrong. Many devices will allow monitoring of power states only, particul=
arly devices, that control power states by themselves or by manual users in=
teraction only. The concept of power states should be explained outside of =
section 4, either in a subsection of section 3 or in a new separate section=
 between current sections 3 and 4.

- JP : We had this exact conversion on authors call with you and decided th=
at it could be introduced as control. Of course you can monitor states but =
they are more naturally introduced  and explained w.r.t control  @Benoit we=
 had this discussion and IIRC you preferred to leave it as control section =
as well.  @All Reviewed last author call we thought it ok to introduce here=
.

38. section 4.5.1 "Power State Sets"
Why is the ACPI power state set excluded from the list of existing sets?
ACPI power states should have their own subsection as IEEE1621 and DMTF hav=
e.

! JP : We never listed the ACPI states as a series since DMTF is a super se=
t and it would suffice. We could add it but it would have to cover the rank=
ed P states (which you said can't be done BTW for the ordering and definiti=
on of lower states) If we get consensus that it's needed we can add it. IMO=
 we have it covered by DMTF but I could see a reason to have them as a seri=
es.
http://www.ietf.org/mail-archive/web/eman/current/msg02027.html

39. Section 4.5.4. "Power State Set: IETF EMAN"
Shouldn't we call this rather "Power State Set: Cisco EnergyWise"?

- JP : See Benoit reply +1 on that.

40. Section 4.5.4, first sentence:
"An EMAN Power State Set represents an attempt at a standard approach for m=
odeling the different levels of power of a device." The same holds for ever=
y other power state set, particularly for the ones mentioned in the subsect=
ions above. I suggest removing this sentence.

+ JP : See Benoit's reply. He meant for IETF. I removed it.

41. Section 4.5.4.
I am fine with the non-operational power states that also other ACPI and DM=
TF support similarly, but I have problems with the operational states (7-12=
). They are defined only relatively to each other stating that one with a l=
ower number "provides less usage" than a higher number.
41.1: Is "providing usage" proper terminology?
41.2: What is meant with "provide less usage"? Does it mean that usage numb=
ers are ALWAYS lower than in a higher state? Even if measured in short time=
 intervals? Such a behavior would hardly be implementable on many devices.

+ JP : "...use less energy than ..."

41.3: In the real world, power states have ranges of power values that they=
 cover and some have wider ranges than others. This can hardly be modeled b=
y a power state set that only knows a strict consecutive order of power sta=
tes and power values.

! JP : With ranges you can indicate the maximums of the ranges and order th=
ose so not sure of your point here.  The ACPI P states are defined identica=
l to this. Asked and answered numerous times.

42. Section 4.6, 2nd paragraph, first sentence: "Relationships are modeled =
with a Relationship class that contains the UUID of the participants in the=
 relationship ...":
"of  the participants" --> "of the other participant"

+ JP : Done

43. Section 5 "Energy Management Information Model"
The text states that this model is a "reference for implementers". Obviousl=
y, the model is useful for management system implementers. What is not disc=
ussed is how to use it for implementations of EMAN on devices, components a=
nd interfaces. The model does not give guidance for these. Among the missin=
g information for these cases is what needs to be implemented on different =
classes of devices.

! JP : See Benoit reply this is part of applicability.

Cheers,
    Juergen

Thanks for the detailed review!!
Jp


--_000_9C213D38848B89428F46808B16F6F08601667906xmbalnx04ciscoc_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable










Thanks Juergen for the detailed review. I've applied the majority of your c=
omments which will apear in -11

See inline:

(+) Applied in the draft

(-) Regretfully not applied for the reasons listed

(!) Not applied needing more clarification and/or see further comment or th=
read



<deletia> for better reading....





------

Dear all,



Here is my review of draft-ietf-eman-framework-10. I did not review version=
 -09 for which the call was made, but the newer version -10 that was posted=
 during last call.



<deletia>



General comments:



A. The document rather looks like a documentation of a software design (wit=
h some extensions) than like a framework for energy management. Modeling fo=
cusses on abstractions, classes, attributes, but issues of the physical wor=
ld are neglected.



JP : Hopefully cleared up with your comments below



B. Do we claim that energy management is (a) a part of network management e=
xtending FCAPS or do we see this energy management (b) as something separat=
e from network management? Several statements in the draft seem to assume (=
b).



JP : It's clearly both. For example Security is a an area of mgt that can s=
tand apart from network management and is also a part of it. 




C. The text has improved from earlier versions. Still, phrasing is often sl=
oppy and not up to the quality we should have for RFCs. Many phrasings soun=
d nice, but only as long as you are not interested in understanding exactly=
 what they mean. I commented on
 several instances below, but by far not on all of them.



JP : Obviously by submitting the draft to  WGLC we feel it is ready to=
 progress.  I'd hate for you to withdraw as an author but considering =
your strong value judgement on the rest of our work I would completely unde=
rstand if you did and wanted to remain a valued
 reviewer.  I'll progress on your comments and edits below in the hope=
 that you can reconcile your feelings on this.



D. I have not thoroughly reviewed the ridiculously long terminology section=
 on pages 5-10. This can be cut significantly. Do we really want to re-defi=
ne terms you can find in text books, such as power-->Power, energy-->=
Energy, device-->Device, etc., etc.? 
 It is certainly necessary to define a term like "Power State", B=
ut defining "Power State Set" as a set of power states, etc., etc=
. is just a waste. 




JP : We moved the modeling terms out as well so this shortened the section.=
 As a WG, we, you included, have spent many a call and draft revision on th=
e terms. I'll consider this as a +1 from you on the separate terminolog=
y draft that I both proposed as work
 for the group and I asked for as a WG document at IETF 87. 



E. The physical reference model in section 3.2 is missing most of the requi=
red content. Basic components of the model are not defined, see item 15. be=
low. Further missing is the physical mode of a meter and of a power interfa=
ce.



JP : For the physical I hope you can see we tried to trim the draft to a re=
asonable discussion on the physical topologies. Please see modifications in=
 -11 and described below. As for the physical mode of a power interface as =
a meter we discussed that in


http://www.ietf.org/mail-archive/web/eman/current/msg01993.html

http://www.ietf.org/mail-archive/web/eman/current/msg01996.html

and concluded that metering is an overloaded term and should be used to des=
cribe a device that is a meter not the act of measuring. Measuring !=3D met=
ering.





F. The information model in this draft is lacking elements for battery mana=
gement.



JP : Which elements from the battery MIB should be provided back in the abs=
tract model of the framework? We included store and the stored energy field=
s. We could as in other threads put the charging states in the state regist=
ries and consolidate the models.





G. Technically, I would like to make a proposal for Sections 4.3.2-4.3.6, t=
he context information as there are currently: category, importance, keywor=
ds, role, and domain. I see that all of them can have their value in certai=
n deployments. However, I see two
 limitations: 

G.1. The set of content information is fixed. 

All of the included attributes have potential to be useful in certain deplo=
yments. However, in other scenarios, or with other management systems, othe=
r context information will be relevant, such as, for example, the devices l=
ocation or its power-down-priority.

G.2. There is only one instance of each per Energy Object

The current model allows for only one instance of each context attribute. T=
his is often not sufficient, particularly for type, role, and domain. As di=
scussed many times on the list, a device can be contained in multiple meter=
ing domain, ad device can have multiple
 roles, and it can match multiple categories, such as, for example, distrib=
utor and meter.

What I think is needed is a more open and extensible framework for context =
information, that allows arbitrary context information and multiple instanc=
es of each context. The result could, for example, in XML look like


<context>

    <category>distributor</category>

    <category>meter</category>

    <role>PDU</role>

    <location>East Wing</location>

    <location>Server Room</location>

    <meteringDomain>Building A</meteringDomain><=
br>
    <meteringDomain>East Wing Level 3</meteringDoma=
in>

    <costFactor>0.7</costFactor>

</context>

or in JSON look like

"context": {

    "category": [ "distributor", "m=
eter" ],

    "role": "PDU",

    "location": [ "East Wing", "Ser=
ver Room" ],

    "meteringDomain": [ "Building A", &q=
uot;East Wing Level 3" ],

    "costFactor": 0.7

}

     

JP : We've discussed this at length and the approach we chose was to use a =
vector for the keywords to allow for further defining context you describe.=
 We proposed scalar for the PRIMARY category and the PRIMARY role.




LOCATION: I think you are mistaking a vector as a way to provide a syntacti=
c/semantic definition of an attribute. Clearly location  is not a vect=
or as you describe it above. Recall RFC3814 has syslocation as a scalar. I =
doubt you propose a device can exist
 in two locations, but what I glean from your example is the desire for a s=
yntax and semantic description of a specific location.  I think adding=
 a syntax and semantic to a scalar location attribute such as described in =
rfc4776 (or geopriv) would be more appropriate.
 So +1 on that, but just making it a vector does nothing. 



ROLE: So I think what you want is a syntax and  semantic description o=
f Role as well. In the absence of that work I think (based on feedback in d=
eployments) it best to keep the attributes a scalar with guidelines to avoi=
d the same kind of mistake you propose
 with location.  In general making the values a vector in case it migh=
t be needed is over engineering the attribute.  Given the experience w=
e've had from our deployments of these fields for quite some years now we'v=
e settled without the need for a vector for
 role, category, and domain. So -1 on vector for the same reasons as locati=
on and +1 on working on a semantic in later work.



CATEGORY: We discussed this previously. We said the category represents the=
 primary purpose w.r.t. EM.


See reply here http://www.ietf.org/mail-archive/web/eman/current/msg02026.h=
tml

We implemented this in our devices and systems as a vector and changed to a=
 scalar for reason's that echo Brad's description. The value of the field w=
as marginalized when it was a vector.



ETC: We can separate this to a thread not to debate but to remind you of th=
e approach if that's helpful (ex: not sure what you're talking about for me=
tering domain? and cost "factor" is specifically out of scope.)




Specific comments:

 

1. Abstract, line 1: "This document defines a framework for providing =
Energy Management ..."

Why for only for 'providing' energy management? Why not as well for operati=
ng, maintaining, etc. I suggest deleting 'providing'.



+ JP - removed "providing"



2. Abstract, lines 5-7: "The information model consists of an Energy M=
anagement Domain as a set of Energy Objects. Each Energy Object is identifi=
ed, classified, and given context."


Obviously, the first sentence is nonsense. The second sentence is only corr=
ect if it is mandatory to add context and classification to every energy ob=
ject. I do not see this in the framework. I suggest replacing the quoted te=
xt it with "The information model
 describes Energy Objects to which information on their identity, classific=
ation, and context can be attributed."



+ JP - ignoring the value judgement (especially since we reviewed this =
abstract at length together) your point under it all was to make sure the a=
bstract do not infer mandatory. Done.



3. Abstract, lines 7-9: "Energy Objects can be monitored and controlle=
d with respect to Power, Power State, Energy, Demand, Power Attributes, and=
 Battery."

Control is only available for power states and for battery states. The curr=
ent text implies much more. I suggest clarifying this, for example, using t=
he following text as replacement: "The framework covers monitoring of =
Power, Power State, Energy, Demand, Power
 Attributes, battery properties and battery states of Energy Objects. It al=
so covers control of power states and battery states."



! JP : Not sure how the current text implies more. For example by controlli=
ng power states you will control energy so I think the text as it stands is=
 more concise with the same meaning esp. for an abstract.  I think the=
 text you have is equal and less concise
 than the original. If you give me an idea / example of what you think it i=
mplies that it should not then I am sure I  can craft something simple=
r.




4. Section 1 "Introduction", 2nd paragraph, lines 3-4 (page 3): &=
quot;router" --> ""



+ JP : done



5. Section 1 "Introduction", 2nd paragraph, lines 8-9 (page 4): &=
quot;If a device contains batteries, these can also be monitored and contro=
lled."

Obviously, it is not sufficient that a device just contains batteries for b=
eing able to control them. I suggest replacing the text by "Monitoring=
 and control of batteries contained in devices is also covered by the EMAN =
framework.



+ JP : change to "The framework also covers monitoring and control=
 of batteries contained in devices."



6. Section 1 "Introduction", 5th paragraph, last 2 lines: "a=
nd an understanding of the potential aggregation (ex: does a meter aggregat=
e values from other devices)"  


I do not think it is clear at this place what "aggregation"/"=
;aggregate" means.



+ JP: Carried the alliteration along and replaced it with

"""

An EnMS (Energy Management System) generally requires an understanding of t=
he power topology (who provides power to whom), the metering topology (who =
meters whom), and an understanding of the potential aggregation (who aggreg=
ate values of others).

"""



7. Section 2: Terminology, page 9, "Power Interface"

The text says: "A Power Interface (...) is an information model (class=
) that represents ...". This is wrong. A Power interface is located at=
 a device and is not an abstract class. The abstract class is called "=
Power Interface Class", see section 4.2.3



- JP : The Power Interface (class) is an abstract representation on a Devic=
e (class) of a physical inlet or outlet which is located on a physical devi=
ce.



8. Section 2: Terminology, page 9, "Energy Object" 

See point 7. above. These are physical objects, not classes.



- JP : We've made the distinction between the abstract representation in th=
e model versus the physical. Ex: I've tripped over many devices in my life =
but never an Energy Object. So Energy Object is the class and device being =
a piece of equipment is the physical
 thing.



9. Section 3.1, 3rd paragraph, last sentence: "These target devices in=
clude:"

I don't think the list below is exclusive. Suggestion: "These target d=
evices include, for example:"




+ JP : Done



10. Section 3.1, 4th paragraph, line 1: "Target devices will primarily=
 communicate via Internet Protocols"

Why "will"? Probably correct would be "do".



+ JP : Deleted "will"



11. Section 3.1, 4th paragraph, lines 2-3: "The target devices may als=
o include those communicating via non-IP protocols ..."

What's this? Do we here defining a standard? Either the standard includes n=
on-IP devices or not.


12. Section 3.1, 4th paragraph, lines 4-5: "These types of target devi=
ces are expected to be managed through gateways ..."

What means "are expected"? What if this is not the case?

A proposal for solving 10., 11., and 12.: 

OLD

        Target devices will primarily co=
mmunicate via Internet 

        Protocols (IP). The target devic=
es may also include those 

        communicating via non-IP protoco=
ls deployed among the power 

        distribution and IP communicatio=
n network. These types of 

        target devices are expect to be =
managed through gateways or 

        proxies that can communicate usi=
ng IP. 

NEW

        Target devices include devices t=
hat communicate via the Internet 

        Protocol (IP) as well as devices=
 using other means for communication. 

        The latter are managed through g=
ateways or proxies that can 

        communicate using IP.  



+ JP : applied NEW



13. Section 3 "Concerns Specific to Energy Management"

This section describes target devices, a physical reference model, and &quo=
t;major concerns specific to Energy Management". Giving it a title tha=
t covers only the third item contained is inappropriate.




+ JP: "3. Target Devices, Physical Reference Model and Management =
Concerns"



14. Section 3 "Concerns Specific to Energy Management", 2nd sente=
nce: "physical reference models" and Section 3.2 "Physical R=
eference Model", first sentence: "The following reference models =
describe ..."

Here we have a terminology issue: The title of the section is  "P=
hysical Reference Model" and also the Abstract of the draft states &qu=
ot;The framework presents a physical reference model ...". Both use th=
e singular form of model.  But the second sentence of Section
 3 and the first sentence of section 3.2 talk about multiple models. I thin=
k the Abstract and the section title are correct, but the sentence is wrong=
. There seem to be just a single model which is used to illustrate differen=
t scenarios in the figures in this
 section.



+ JP : singular for model and plural for topologies 



15. Section 3.2 "Physical Reference Model"

A model is used, but I cannot find it described in the draft, neither in th=
is section where one would expect it, nor anywhere else. Where is it? Just =
to be clear, a reference model typically consists of a set of roles, such a=
s, for example, device, energy management
 system, power source, etc., and of relations, such as a power source relat=
ionship, a monitoring relationship, a control relationship, etc. I cannot f=
ind these defined as components of the model.



! JP : We have defined the components of the model as diagrammed. If there'=
s more you think we need to add to describe the role, etc, in the model can=
 you provide concise text?





16. Section 3.3 "Concerns Differing from Network Management"

This section rather looks like a power point slide that can hardly be under=
stood without a person presenting it. The bullets in this section are too s=
hort for the reader to easily understand what issue is addressed at all and=
 what the consequences are. Some
 of the bullets do not make any sense to me. At least 6 out of 7 seem to be=
 broken:

  - bullet #1: This does not seem to be different from network managem=
ent

  - bullet #2:  I don't understand the last line: "controlli=
ng a simple light by controlling its outlet". How does this work?

  - bullet #3: What special coordination do devices need if there is m=
ore than one PDU in a power distribution network? 


  - bullet #4: What means "require a separate interface model fro=
m Network Management"?

  - bullet #5: Seems to be broken. I don't get the message. Is there a=
 typo in the last line?

  - bullet #7: I am not sure what is really a difference to network ma=
nagement where we have the entity MIB and different models for managing dev=
ices (e.g. routers) and components (e.g. line cards). The third paragraph o=
f Section 4.1 claims that this is very
 similar to network management.



! JP : Yes. As an editorial exercise I condensed the pages you all wrote th=
at covered this section from the previous drafts to a list. So I'm trying t=
o capture what you all as the authors want in this section. I don't think w=
e need pages of description just
 a few paragraphs simply listing the differences - if the section is needed=
 at all. @Authors So what points would you like in? I'll proposed a new sec=
tion.



17.  Section 3.4 "Concerns Not Addressed", 1st paragraph, li=
ne 4: "normalized to the electrical units for power and energy". =
This is nonsense. There is indeed an "electrical" units for power=
 (Voltamperes,VA), but we are using rather "non-electrical ones, such
 as Watts (Joule per second) and Watt-hours.

OLD

        Non-Electrical Equipment 

         

        The primary focus of this framew=
ork is the management of 

        Electrical Equipment.  Some=
 Non-Electrical Equipment may be 

        connected to communication netwo=
rks and could have their 

        energy managed if normalized to =
the electrical units for 

        power and energy. Non- 

        Electrical equipment that do not=
 convert-to or present-as 

        equivalent to Electrical Equipme=
nt is not addressed.

NEW

        Non-Electrical Equipment 

         

        The primary focus of this framew=
ork is the management of 

        Electrical Equipment.  Non-=
Electrical Equipment can be covered

        by the framework only if it prov=
ides interfaces that comply with 

        the framework. For example, it m=
ust use the same units for power

        and energy. 



+ JP : Again ignoring the value judgement as we meant the units we sele=
cted for electrical equipment (W not VA since that is different for real an=
d apparent power). Changed to NEW





18. Section 4 "Energy Management Abstraction"

The first paragraph is identical with the first paragraph of Section 1 &quo=
t;Introduction" and can be removed.



+ JP : Deleted.



19. Section 4.1 "Conceptual Model"

I am missing here a lot of information on the model. 

19.1. Is the model normative or informational?



! JP : question for the chair to indicate. @Nevil the entire draft is infor=
mational what should be listed here?



19.2. Is it a model to be implemented inside the EnMS only or as well on th=
e Energy Objects?

19.3. If it is implemented at the Energy Objects, why storing context infor=
mation? This typically resides in the management system only.




- JP : we've discussed this on numerous threads. On the device for reasons =
described. It may be set on the device to be included in the EnMS and vice =
versa.




19.4. If it is implemented on Energy Objects, how does it specify which inf=
ormation is included for a device, and which (more limited) information is =
included for a component or power interface?



- JP : It's not limited for a component see class Component.



19.5. The model is lacking information on batteries.



! JP : See Benoit reply 



20. Section 4.1, 3rd paragraph, line 1: "Therefore"-->"&q=
uot;



+ JP : done



21. Section 4.1, 4th paragraph, line 2: "a Device, a Component, and a =
Power Interface"

-->"a Device class, a Component class, and a Power Interface class&=
quot;



+ JP : done



22. Section 4.1, 5th paragraph, line 2

OLD

        For modeling additional attribut=
es, this section describes 

        attributes of an Energy Object f=
or: identification, 

        classification, context, control=
, power and energy.

NEW

        This section describes attribute=
s of an Energy Object for identification,


        classification, context, control=
, power and energy.



+ JP : done



23. Section 4.1, 6th paragraph.

The first sentence seems to be broken. The "interconnections for Netwo=
rk Management" are also used for Energy Management. Energy management =
needs at least some of them to communicate between the EnMS and devices.


! JP : "may have no relation" so that covers your concern I think=
.



24. Section 4.1, title

This section is titled "Conceptual Model". But as the last paragr=
aph of it states, the conceptual model is actually not in this section, but=
 in the following sections 4.2-4.6. The title should be changed after fixin=
g 20.-23.



+ JP : changed to  "next sections"



25. Section 4.2, title

"Energy Object" --> "Energy Object Class"



+ JP : done



26. Section 4.2.1, 2nd paragraph, line 2: "may represent" --> =
"represents"



+ JP : done



27. Section 4.2.1, 2nd paragraph:

Is this list exclusive? Are there no other kinds of devices supported? 



! JP : nothing to do here. If there are more categories of devices in this =
context (EM) feel free to suggest and we can discuss. These categories are =
based on years of deployments and we've found little to no overlap in indic=
ating one primary category per device.
 Also it's been exhaustive for our deployments. We can surely add more but =
we've found it to be enough.



28. Section 4.2.1, 2nd paragraph:

A device may be both, a meter and a distributor. How is this modeled?



- JP : We discussed this with you already and this is described as the prim=
ary purpose. For the problem space on EM these categories rarely overlap an=
d when they do the primary purpose always outweighs the others.


http://www.ietf.org/mail-archive/web/eman/current/msg02026.html



29. Section 4.2.1, 3rd paragraph:

OLD

        A Device Class instance may repr=
esent a physical device 

        that contains other components.<=
br>
NEW

        A Device Class instance may repr=
esent a physical device 

        that contains other components.<=
br>


- JP : Nothing to do here??



30. Section 4.3.1, 2nd sentence: "Ideally, the UUID is used to disting=
uish the Energy Object within the EnMS". Why ideally? What can be idea=
l for us info model designer does not necessarily have to be ideal for the =
EnMS developer.



+ JP : Since we have RFC4122 now, this is 

"""

A Universal Unique Identifier (UUID) [RFC4122] is used to uniquely and pers=
istently identify an Energy Object.


""" 



31. Section 4.3.2. "Context in General"

What I am missing in this section 



- JP : Can't read your mind ;) 



32. Section 4.3.2, last paragraph:

I do not see the point made by this paragraph. How would context informatio=
n help the EnMS in this case?



+ JP : I agree with that. I deleted

"""

For example, metered usage reported by a meter and consumption usage report=
ed by a device connected to that meter may measure the same usage. With the=
 two measurements identified by category and context an EnMS can make summa=
rizations and inferences.

"""



33. Section 4.4, "Measurements", 2nd paragraph:

This is similar to item 17. There is no electrical or non-electrical Watt-h=
our.

OLD

        For the purposes of this framewo=
rk, energy will be limited 

        to electrical energy in watt-hou=
rs.  Other forms of Energy 

        Objects that use or produce non-=
electrical energy may be 

        modeled as an Energy Object but =
must provide information 

        converted to and expressed in wa=
tt-hours. 

NEW

        Within this framework, energy wi=
ll only be quantified in units of 

        in watt-hours. Energy Objects an=
d Meters measuring Energy in

        other units must convert values =
to Watt-hours before reporting them.



+ JP : Done 

"""

Within this framework, energy will only be quantified in units of in watt-h=
ours. Energy Objects measuring Energy in other units must convert values to=
 watt-hours.

"""



34. Section 4.4.1 "Measurements: Power", line 1:

"Each Energy Object contains a Nameplate Power attribute that describe=
s the nominal power as specified by the manufacturer." I am not sure, =
you will always find someone reading all the nameplate power values and ent=
ering them to the device or the EnMS.


OLD

        Each Energy Object contains a Na=
meplate Power attribute 

NEW

        Each Energy Object may contain a=
 Nameplate Power attribute 



35. Section 4.4.1 "Measurements: Power", 2nd paragraph, line 1:
OLD

        Each Energy Object will have inf=
ormation that describes the

NEW

        Each Energy Object may have info=
rmation that describes the

OR NEW

        Each Energy Object has informati=
on that describes the



- JP : Left this out. I see your point for the device but this is describin=
g the  class. The class in the information model contains the attribut=
e. The device may not provide it but the attribute is defined in the class =
and does exist there.




35. Section 4.4.4, last sentence: "Demand measurements can be provided=
 when the Energy Object is capable of measuring actual power."

This is wrong. Either delete this sentence (preferred) or use this one inst=
ead: "Demand measurements can only be provided when the Energy Object =
is capable of measuring demand."




- JP : Again we'd all like to be the harbinger of right and wrong but I'll =
comment on your opinion. What you have suggested is a tautology. We could s=
ay that for any attribute. However the point was, If a device is not capabl=
e of measuring power I'm not sure
 how it could measure demand (even energy) for that matter. So if the devic=
e is not capable of actual power measurements demand and energy would be no=
n existent.



36. Section 4.5 "Control", first sentence: An Energy Object can b=
e controlled by setting a Power State or a battery state.



! JP : Defer that. Can battery be listed as a power state series? see other=
 thread.



37. Section 4.5 "Control"

Power States and Power State sets are introduced in Section "Control&q=
uot;. That's wrong. Many devices will allow monitoring of power states only=
, particularly devices, that control power states by themselves or by manua=
l users interaction only. The concept of power
 states should be explained outside of section 4, either in a subsection of=
 section 3 or in a new separate section between current sections 3 and 4.


- JP : We had this exact conversion on authors call with you and decided th=
at it could be introduced as control. Of course you can monitor states but =
they are more naturally introduced  and explained w.r.t control  =
@Benoit we had this discussion and IIRC you
 preferred to leave it as control section as well.  @All Reviewed last=
 author call we thought it ok to introduce here.



38. section 4.5.1 "Power State Sets"

Why is the ACPI power state set excluded from the list of existing sets?
ACPI power states should have their own subsection as IEEE1621 and DMTF hav=
e.

 

! JP : We never listed the ACPI states as a series since DMTF is a super se=
t and it would suffice. We could add it but it would have to cover the rank=
ed P states (which you said can't be done BTW for the ordering and definiti=
on of lower states) If we get consensus
 that it's needed we can add it. IMO we have it covered by DMTF but I could=
 see a reason to have them as a series.

http://www.ietf.org/mail-archive/web/eman/current/msg02027.html



39. Section 4.5.4. "Power State Set: IETF EMAN"

Shouldn't we call this rather "Power State Set: Cisco EnergyWise"=
? 



- JP : See Benoit reply +1 on that.

 

40. Section 4.5.4, first sentence: 

"An EMAN Power State Set represents an attempt at a standard approach =
for modeling the different levels of power of a device." The same hold=
s for every other power state set, particularly for the ones mentioned in t=
he subsections above. I suggest removing this
 sentence.



+ JP : See Benoit's reply. He meant for IETF. I removed it.



41. Section 4.5.4.

I am fine with the non-operational power states that also other ACPI and DM=
TF support similarly, but I have problems with the operational states (7-12=
). They are defined only relatively to each other stating that one with a l=
ower number "provides less usage"
 than a higher number. 

41.1: Is "providing usage" proper terminology?

41.2: What is meant with "provide less usage"? Does it mean that =
usage numbers are ALWAYS lower than in a higher state? Even if measured in =
short time intervals? Such a behavior would hardly be implementable on many=
 devices.



+ JP : "...use less energy than ..."



41.3: In the real world, power states have ranges of power values that they=
 cover and some have wider ranges than others. This can hardly be modeled b=
y a power state set that only knows a strict consecutive order of power sta=
tes and power values.



! JP : With ranges you can indicate the maximums of the ranges and order th=
ose so not sure of your point here.  The ACPI P states are defined ide=
ntical to this. Asked and answered numerous times.



42. Section 4.6, 2nd paragraph, first sentence: "Relationships are mod=
eled with a Relationship class that contains the UUID of the participants i=
n the relationship ...":

"of  the participants" --> "of the other participant=
"



+ JP : Done



43. Section 5 "Energy Management Information Model"

The text states that this model is a "reference for implementers"=
. Obviously, the model is useful for management system implementers. What i=
s not discussed is how to use it for implementations of EMAN on devices, co=
mponents and interfaces. The model does not
 give guidance for these. Among the missing information for these cases is =
what needs to be implemented on different classes of devices.



! JP : See Benoit reply this is part of applicability.



Cheers,

    Juergen



Thanks for the detailed review!!

Jp








--_000_9C213D38848B89428F46808B16F6F08601667906xmbalnx04ciscoc_--

From jparello@cisco.com  Sun Oct 13 14:56:37 2013
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 0DAD921F9D0A for ; Sun, 13 Oct 2013 14:56:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.502
X-Spam-Level: 
X-Spam-Status: No, score=-9.502 tagged_above=-999 required=5 tests=[AWL=1.096,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rBYpL3HnDPIk for ; Sun, 13 Oct 2013 14:56:31 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id A5FC111E8143 for ; Sun, 13 Oct 2013 14:56:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8786; q=dns/txt; s=iport; t=1381701390; x=1382910990; h=from:to:cc:subject:date:message-id:mime-version; bh=McLkNg+yBsWavPee/vL9VsTjrzypI2hiuv9rdmc4LQw=; b=CaT2j86z3frji779S470OUJqXK8xyEp93b8X2x1XBWYH6w5ur8apuaar cyVUEuhM5jgFtwQi0LYkYtAd0UWFcDFqXJn74xQjWznwv0upPwvawDqQE et9fV9loOWrpwZ2nYvgWqcu049m8h7B/ZKHIOEy85R0hvZ77GIJ52ksWw o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AlkGAE0WW1KtJXHB/2dsb2JhbABZgkNEgQrBbYEaFm0HgicBBHIHEgEqViYBBA4Nh368do4DF4EHMYMmgQQDiQSLJJVfgySCKQ
X-IronPort-AV: E=Sophos;i="4.93,487,1378857600";  d="scan'208,217";a="271647953"
Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-3.cisco.com with ESMTP; 13 Oct 2013 21:56:27 +0000
Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r9DLuROS019814 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 13 Oct 2013 21:56:27 GMT
Received: from xmb-aln-x04.cisco.com ([169.254.9.229]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.004; Sun, 13 Oct 2013 16:56:27 -0500
From: "John Parello (jparello)" 
To: "eman@ietf.org" 
Thread-Topic: Rolf.Winter -  draft-ietf-eman-framework-10: WGLC comments
Thread-Index: Ac7IXxCtsmVkrfYnQcSjeFSKsHqBhg==
Date: Sun, 13 Oct 2013 21:56:26 +0000
Message-ID: <9C213D38848B89428F46808B16F6F08601667923@xmb-aln-x04.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.21.78.193]
Content-Type: multipart/alternative; boundary="_000_9C213D38848B89428F46808B16F6F08601667923xmbalnx04ciscoc_"
MIME-Version: 1.0
Subject: [eman] Rolf.Winter -  draft-ietf-eman-framework-10: WGLC comments
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 13 Oct 2013 21:56:37 -0000

--_000_9C213D38848B89428F46808B16F6F08601667923xmbalnx04ciscoc_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Rolf,

Thanks again, this is the followup to the first rev I did.
 I applied the changes see inline. You should be good in rev-11.

Jp



> ! weird spelling (e.g. Battery is capitalized in the abstract) !
> inconsistent spelling (e.g. "Energy Management System" and "energy
> management system" are both used throughout the text without apparent
> reason, same applies to "power", "demand" and a whole bunch of other
> terms)
>
> JP : Yeah I'm not comfortable with the capitalization either. When we
> started the draft all the comments we  had were to capitalize
> everything in the terminology section. You're facing the same issue in
> the requirements. In order to help with this I am publishing a new
> version of the terminology draft with a proposed capitalization scheme
> that is more sane. Terms that are common are lower case and anything
> that originates in our WG is capitalized. Let's discuss / open a thread
> in that context them apply those minor edits to both drafts.

This is what the requirements draft converged to as well.

! JP - Great we definitely agree here. See thread on terminology and caps s=
ummary. I'll make the changes after that discussion closes.

> - measured in kilowatt hours... I personally would write "measured in
> watt hours" as kilo is merely an SI prefix. Kilo is certainly a common
> prefix but I am sure there are consumers that are measured in other SI
> prefixes...
>
> JP : direct quote so I left it kilo. I agree with you but it's a direct
> quote.

If that's the case, I think it should be actually put in quotation marks to=
 show that.

+ JP : I added a note in the definition to indicate this.
"While IEEE100 defines Demand in kilo measurements for EMAN we use watts wi=
th any suitable metric prefix ."

  >
> + I think the rule regarding SI unit and numerical value is that there
> is a space in between the two. In either case, use one scheme
> consistently.
>
> JP : I don't see a rule for space but the prefixes from use are clearly
> non spaced kilometer, miligram, picowatt. Scrubbed.

That's not what I meant. I meant between numerical value and the SI unit. S=
o it is not 3mW but 3 mW. That's still in the document (both forms, so it i=
s still inconsistent).

+ JP : Thanks didn't follow before, done now

>
> + "Limitation (curtailment) of the power used by an Energy Object in a
> state is specified by" I would add an "e.g." here, since not all of
> them have to be used at the same time.
>
> JP - I changed "is" to  "may" to indicate the choice

Then you should add a "be"

+ JP : Done


> + This sentence "Since one point of a power distribution system may
> cover many Devices with a complex wiring topology, this relationship
> type can be seen as an arbitrary set." sounds strange to me. Why can
> this be seen as an arbitrary set. Complex !=3D arbitrary.
>
> JP -  "Since one point of a power distribution system may cover many
> Devices within a wiring topology"

Sure, but why would one call this arbitrary I still don't get.

+ JP: Yep I removed arbitrary, it's a set.

> - regarding the PDU in section 6, shouldn't "among the inlets or
> outlet" be "among the inlet or outlets"
>
> JP - A  PDU  or (any device) may have multiple inlets (very common) so
> that was intentionally made plural.

But then I still don't get why you insist on a single outlet because a PDU =
surely has more than one?

+ JP : We agree. it was always meant to be multiple inlets and outlets. Bot=
h are plural now. Thanks again for the details!

Thanks!
Jp



--_000_9C213D38848B89428F46808B16F6F08601667923xmbalnx04ciscoc_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable








Hi Rolf,



Thanks again, this is the followup to the first rev I did. 

 I applied the changes see inline. You should be good in rev-11. 



Jp 







> ! weird spelling (e.g. Battery is capitalized in the abstract) !

> inconsistent spelling (e.g. "Energy Management System" and &=
quot;energy

> management system" are both used throughout the text without appa=
rent

> reason, same applies to "power", "demand" and a wh=
ole bunch of other

> terms)

> 

> JP : Yeah I'm not comfortable with the capitalization either. When we<=
br>
> started the draft all the comments we  had were to capitalize

> everything in the terminology section. You're facing the same issue in=


> the requirements. In order to help with this I am publishing a new

> version of the terminology draft with a proposed capitalization scheme=


> that is more sane. Terms that are common are lower case and anything
> that originates in our WG is capitalized. Let's discuss / open a threa=
d

> in that context them apply those minor edits to both drafts.



This is what the requirements draft converged to as well.



! JP - Great we definitely agree here. See thread on terminology and caps s=
ummary. I'll make the changes after that discussion closes.



> - measured in kilowatt hours... I personally would write "measure=
d in

> watt hours" as kilo is merely an SI prefix. Kilo is certainly a c=
ommon

> prefix but I am sure there are consumers that are measured in other SI=


> prefixes...

> 

> JP : direct quote so I left it kilo. I agree with you but it's a direc=
t

> quote.



If that's the case, I think it should be actually put in quotation marks to=
 show that.



+ JP : I added a note in the definition to indicate this.

"While IEEE100 defines Demand in kilo measurements for EMAN we use wat=
ts with any suitable metric prefix ."




  > 

> + I think the rule regarding SI unit and numerical value is that t=
here

> is a space in between the two. In either case, use one scheme

> consistently.

> 

> JP : I don't see a rule for space but the prefixes from use are clearl=
y

> non spaced kilometer, miligram, picowatt. Scrubbed.



That's not what I meant. I meant between numerical value and the SI unit. S=
o it is not 3mW but 3 mW. That's still in the document (both forms, so it i=
s still inconsistent).



+ JP : Thanks didn't follow before, done now



> 

> + "Limitation (curtailment) of the power used by an Energy Ob=
ject in a

> state is specified by" I would add an "e.g." here, sinc=
e not all of

> them have to be used at the same time.

> 

> JP - I changed "is" to  "may" to indicate the=
 choice



Then you should add a "be"



+ JP : Done



 

> + This sentence "Since one point of a power distribution syst=
em may

> cover many Devices with a complex wiring topology, this relationship
> type can be seen as an arbitrary set." sounds strange to me. Why =
can

> this be seen as an arbitrary set. Complex !=3D arbitrary.

> 

> JP -  "Since one point of a power distribution system may co=
ver many

> Devices within a wiring topology"



Sure, but why would one call this arbitrary I still don't get.



+ JP: Yep I removed arbitrary, it's a set.



> - regarding the PDU in section 6, shouldn't "among the inlets or<=
br>
> outlet" be "among the inlet or outlets"

> 

> JP - A  PDU  or (any device) may have multiple inlets (very =
common) so

> that was intentionally made plural.



But then I still don't get why you insist on a single outlet because a PDU =
surely has more than one?



+ JP : We agree. it was always meant to be multiple inlets and outlets.=
 Both are plural now. Thanks again for the details!



Thanks!

Jp










--_000_9C213D38848B89428F46808B16F6F08601667923xmbalnx04ciscoc_--

From jparello@cisco.com  Sun Oct 13 14:58:15 2013
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 E3A6021E8130 for ; Sun, 13 Oct 2013 14:58:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.576
X-Spam-Level: 
X-Spam-Status: No, score=-9.576 tagged_above=-999 required=5 tests=[AWL=0.622,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_BAYES_6x6=0.4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CRlL3tGZrvXU for ; Sun, 13 Oct 2013 14:58:11 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id EDDE421F9A1C for ; Sun, 13 Oct 2013 14:58:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17870; q=dns/txt; s=iport; t=1381701489; x=1382911089; h=from:to:cc:subject:date:message-id:mime-version; bh=ihP+Gra4grSRcSajdWIXBMTZJmbGXIupLqmikJUXtK4=; b=UBnWDvb9Tc2PkYdOL6ObYCAN2pLMPM/QZrkOaYjTDZETJavabDjD3pFZ Aapc4eHTGi2kIsZe4t3fBCGPG6Nf0GogsLZfrmR5EmEn/MSwaFqtjtysc Ji+BdbG5CkiCmQrLYyu3pViQboA381+4f3S/gk6zmsV4/Q1SQ5CHRsXPa I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AlsGANEWW1KtJXG9/2dsb2JhbABPCoJDRDhSwW2BGhZtB4InAQQnSwcSASpWJgEEDg2Hfgy8aY4JBguBBzGDJoEEA4kEiySVX4MkgXA5
X-IronPort-AV: E=Sophos;i="4.93,487,1378857600";  d="scan'208,217";a="268625253"
Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-9.cisco.com with ESMTP; 13 Oct 2013 21:58:00 +0000
Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r9DLvxbu021490 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sun, 13 Oct 2013 21:57:59 GMT
Received: from xmb-aln-x04.cisco.com ([169.254.9.229]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.004; Sun, 13 Oct 2013 16:57:59 -0500
From: "John Parello (jparello)" 
To: "eman@ietf.org" 
Thread-Topic: Bclaise - draft-ietf-eman-framework-10: WGLC comments
Thread-Index: Ac7IX0dtXM1E5X8eSmaK2EjI0mefNA==
Date: Sun, 13 Oct 2013 21:57:58 +0000
Message-ID: <9C213D38848B89428F46808B16F6F08601667938@xmb-aln-x04.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.21.78.193]
Content-Type: multipart/alternative; boundary="_000_9C213D38848B89428F46808B16F6F08601667938xmbalnx04ciscoc_"
MIME-Version: 1.0
Subject: [eman] Bclaise - draft-ietf-eman-framework-10: WGLC comments
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 13 Oct 2013 21:58:16 -0000

--_000_9C213D38848B89428F46808B16F6F08601667938xmbalnx04ciscoc_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Thanks Benoit for the detailed review. I've applied the majority of your co=
mments which will appear in -11
See inline:
(+) Applied in the draft
(-) Regretfully not applied for the reasons listed
(!) Not applied needing more clarification and/or see further comment or th=
read

I deleted the draft txt form your email for better reading....



Abstract:

    On the top of J=C3=BCrgen's feedback on the abstract, I'm wondering: Wh=
at is a "physical" reference model?

1. Introduction

    power state -> Power State.
    Some more instances: be consistent in terms of capitalization in the in=
troduction.

    We need to introduce that there are different relationship types, to so=
lve the different problems.

+ JP : Done

2. Terminology

    The final agreement on [EMAN-REQ] was http://www.rfc-editor.org/authors=
/rfc6988.txt The terms specified in the terminology section are capitalized=
 throughout the document; the exceptions are the well-known terms "energy" =
and "power". These terms are generic and are used in generated terms such a=
s "energy-saving", "low-power", etc.I suggest you do the same.

    I searched for a specific term in the terminology section, and realized=
 that the order is not alphabetical. A sentence such as: "The terms in the =
terminology section are not classified alphabetically, but the order has be=
en chosen to improve the document readiness, with terms building on the top=
 of each others"

    Please change the "$" sign for all entries in the terminology section.

+ JP : Done

    Are Power Inlets and Power Oulets Power Interfaces? If yes, the definit=
ions should be changed accordingly

+ JP : Scrubbed. outlets/inlets are the physical and Power Interfaces are t=
he abstraction / model.

    Nameplate Power  s/a device/an Electrical Device?

! JP : this definition highly reviewed and we have no definition of an Elec=
trical Device. Basic grammar would be to use Electric Device but no need to=
 go there at all. Just device.



3. Concerns...

    Again "physical" reference model.

+ JP : thanks this was scrubbed in the entire document so can't list a spec=
ific line but please review as this should meet what you want

3.1 Target Devices

           I'm confused by the Device definition in the terminology, which =
is NOT used in this text, while "device" (paragraph above) and "target devi=
ce" are used

+ JP : Revised definition use and this section.

3.2 Physical Reference Model

             Permutation of topologies or permutations of elements, which i=
n turn, create different topologies?
I believe you meant the latter.

+ JP : changed
"""
While many more topologies can be created with combination of devices, the =
following are some basic ones that show how Energy Management topologies di=
ffer from Network Management topologies.
"""


        energy management system -> Energy Management System Pay attention =
to the terms capitalization in the figures as well. Here, we speak about de=
vice -> Device, monitoring -> Energy Monitoring control -> Energy Control Y=
ou removed the fact that ######## is energy. Device versus device versus ta=
rget device? I'm wondering if we should not add the Power Interfaces in the=
 figures.

+ JP : done didn't add PI can add if we agree as a group this is needed.

3.4 Concerns not addressed

      One line of intro please: "concerns not addressed" is vague  Which co=
ncerns? Is "concerns" the right term? Should we have some concerns that som=
e concerns are not addressed? :-) Not addressed by this framework, I guess.=
 What you want to say is "out of scope of this framework", right?

+ JP : Done

      Non-Electrical equipments that do not convert-to or present-as equiva=
lent to Electrical Equipments are not addressed.

! JP : Combined yours with  JQ text
"""
The primary focus of this framework is the management of Electrical Equipme=
nt. Non-Electrical Equipment can be covered by the framework by providing i=
nterfaces that comply with the framework. For example, using the same units=
 for power and energy. Therefore, Non-Electrical Equipment that do not conv=
ert-to or present-as equivalent to Electrical Equipment are not addressed.
"""

4.1 Conceptual Model

          1st Para: No need.

      2nd Para: interconnections =3D relationships We introduced the notion=
 of relationships already Proposal:
""
describe a means to report information, provide control, and model the rela=
tionships among physical entities (equipment).
Here, it's physical entities (equipment).
""
    We had already device, Device, target device, Electrical Object
    Be consistent.

+ JP : 1P edited from other comments. 2P changed to
"""
An information model for Energy Management will need to describe a means to=
 monitor and control devices and components. The model will also need to de=
scribe the relationships among and connections between devices and componen=
ts.
""

    3rd Para:
I finally get it, I think. You really want to Energy Object to be an (insta=
nce of the) Device, Component, or Power Interface class in the information =
model. The readers start with the terminology and since they don't know you=
 will need an information model, they're puzzled by the Energy Object defin=
ition. Proposal: whenever you mean the information model class, just mentio=
n
    Device Class
    Component Class
    etc.
As you did with the subtitles below.
And no need to define Energy Object in the terminology section. If you real=
ly want, insert the definition in this information model section here, alon=
g with the Device Class definition. Same thing for component.
Btw, the Energy Object is not a class but an instance of the class.

+ JP : Ok scrubbed this as discussed.

nterconnection =3D relationship
 Energy Management may have no
relation to the interconnections for Network Management the Energy
Object
interconnection =3D topology

! JP : change interconnection where redundant but had to keep it in cases w=
here we are describing a relationship. I can't describe a relationship by s=
aying it's a relation etc.


4.2.3 Power Interface Class

The power
interface class is a sub-class of Energy Object that represents the
interconnection among devices and components.
Does it?
It represents the attach point for the relationship. I see later:
 Power Source relationships are intended
to identify the connections between Power Interfaces.
The Power Interface definition should be improved.

+ JP : moved definition into class description and clarified definition.

4.3.2 Context in General

Shouldn't this text be part of 4.3.4 [jp:keywords]?

! JP : Not sure what you mean there. Section 4.3.4 is regarding keywords wh=
ich is part of context and 4.3.2 is talks about context in general

4.4.1 Measurements: Power

In the future, avoid the future tense for future RFCs. :-)

+ JP : done in the present ;)

4.5 Control

Power States that it implements.
that it supports
This is more precise.

+ JP : Done I think implements is clearer but ok changed to supports.

4.6.4 Guidelines: Aggregation

Since an EnMS is naturally a point of aggregation it is not necessary to
model aggregation for Energy Management Systems. Aggregation SHOULD be
used for power and energy. It MAY be

"Aggregation SHOULD be used for power and
energy" is misleading I guess you mean: "The Aggregation
Relationship is intended for power and energy" For the rest below.
Section 6 is a series of examples I'm fine with section 7, 8, and 9
(IANA, which I wrote) Regards, Benoit

+ JP : Done

Thanks!!

Jp







--_000_9C213D38848B89428F46808B16F6F08601667938xmbalnx04ciscoc_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable








Thanks Benoit for the detailed review. I've applied the majority of =
your comments which will appear in -11

See inline:

(+) Applied in the draft

(-) Regretfully not applied for the reasons listed

(!) Not applied needing more clarification and/or see further comment or th=
read



I deleted the draft txt form your email for better reading....







Abstract:



    On the top of J=C3=BCrgen's feedback on the abstract, I'=
m wondering: What is a "physical" reference model?



1. Introduction



    power state -> Power State.

    Some more instances: be consistent in terms of capitaliz=
ation in the introduction.



    We need to introduce that there are different relationsh=
ip types, to solve the different problems.



+ JP : Done



2. Terminology



    The final agreement on [EMAN-REQ] was http://www.rfc-edi=
tor.org/authors/rfc6988.txt The terms specified in the terminology section =
are capitalized throughout the document; the exceptions are the well-known =
terms "energy" and "power". These terms are generic
 and are used in generated terms such as "energy-saving", "l=
ow-power", etc.I suggest you do the same.



    I searched for a specific term in the terminology sectio=
n, and realized that the order is not alphabetical. A sentence such as: &qu=
ot;The terms in the terminology section are not classified alphabetically, =
but the order has been chosen to improve the document
 readiness, with terms building on the top of each others"



    Please change the "$" sign for all entries in =
the terminology section.



+ JP : Done



    Are Power Inlets and Power Oulets Power Interfaces? If y=
es, the definitions should be changed accordingly



+ JP : Scrubbed. outlets/inlets are the physical and Power Interfaces a=
re the abstraction / model.

        

    Nameplate Power  s/a device/an Electrical Device?


! JP : this definition highly reviewed and we have no definition of an Elec=
trical Device. Basic grammar would be to use Electric Device but no need to=
 go there at all. Just device.







3. Concerns...



    Again "physical" reference model.



+ JP : thanks this was scrubbed in the entire document so can't list a =
specific line but please review as this should meet what you want



3.1 Target Devices



           I'm confused by the Devi=
ce definition in the terminology, which is NOT used in this text, while &qu=
ot;device" (paragraph above) and "target device" are used


+ JP : Revised definition use and this section.



3.2 Physical Reference Model



             Permutation =
of topologies or permutations of elements, which in turn, create different =
topologies?

I believe you meant the latter.



+ JP : changed

"""

While many more topologies can be created with combination of devices, the =
following are some basic ones that show how Energy Management topologies di=
ffer from Network Management topologies.

"""





        energy management system -> Energy Mana=
gement System Pay attention to the terms capitalization in the figures as w=
ell. Here, we speak about device -> Device, monitoring -> Energy Moni=
toring control -> Energy Control You removed the fact that ########
 is energy. Device versus device versus target device? I'm wondering if we =
should not add the Power Interfaces in the figures.



+ JP : done didn't add PI can add if we agree as a group this is needed=
.  



3.4 Concerns not addressed



      One line of intro please: "concerns not addr=
essed" is vague  Which concerns? Is "concerns" the righ=
t term? Should we have some concerns that some concerns are not addressed? =
:-) Not addressed by this framework, I guess. What you want to say is "=
;out of
 scope of this framework", right?



+ JP : Done



      Non-Electrical equipments that do not convert-to =
or present-as equivalent to Electrical Equipments are not addressed.



! JP : Combined yours with  JQ text

"""

The primary focus of this framework is the management of Electrical Equipme=
nt. Non-Electrical Equipment can be covered by the framework by providing i=
nterfaces that comply with the framework. For example, using the same units=
 for power and energy. Therefore,
 Non-Electrical Equipment that do not convert-to or present-as equivalent t=
o Electrical Equipment are not addressed.

"""



4.1 Conceptual Model



          1st Para: No need. 



      2nd Para: interconnections =3D relationships We i=
ntroduced the notion of relationships already Proposal:

""

describe a means to report information, provide control, and model the rela=
tionships among physical entities (equipment).

Here, it's physical entities (equipment).

""

    We had already device, Device, target device, Electrical=
 Object

    Be consistent.



+ JP : 1P edited from other comments. 2P changed to

"""

An information model for Energy Management will need to describe a means to=
 monitor and control devices and components. The model will also need to de=
scribe the relationships among and connections between devices and componen=
ts.

""



    3rd Para: 

I finally get it, I think. You really want to Energy Object to be an (insta=
nce of the) Device, Component, or Power Interface class in the information =
model. The readers start with the terminology and since they don't know you=
 will need an information model,
 they're puzzled by the Energy Object definition. Proposal: whenever you me=
an the information model class, just mention

    Device Class

    Component Class

    etc.

As you did with the subtitles below.

And no need to define Energy Object in the terminology section. If you real=
ly want, insert the definition in this information model section here, alon=
g with the Device Class definition. Same thing for component.

Btw, the Energy Object is not a class but an instance of the class.



+ JP : Ok scrubbed this as discussed.



nterconnection =3D relationship

 Energy Management may have no

relation to the interconnections for Network Management the Energy

Object

interconnection =3D topology



! JP : change interconnection where redundant but had to keep it in cases w=
here we are describing a relationship. I can't describe a relationship by s=
aying it's a relation etc.



    

4.2.3 Power Interface Class



The power

interface class is a sub-class of Energy Object that represents the

interconnection among devices and components.

Does it?

It represents the attach point for the relationship. I see later:

 Power Source relationships are intended

to identify the connections between Power Interfaces. 

The Power Interface definition should be improved.



+ JP : moved definition into class description and clarified definition=
.



4.3.2 Context in General



Shouldn't this text be part of 4.3.4 [jp:keywords]?



! JP : Not sure what you mean there. Section 4.3.4 is regarding keywords wh=
ich is part of context and 4.3.2 is talks about context in general



4.4.1 Measurements: Power



In the future, avoid the future tense for future RFCs. :-)



+ JP : done in the present ;)



4.5 Control



Power States that it implements. 

that it supports 

This is more precise.



+ JP : Done I think implements is clearer but ok changed to supports.


4.6.4 Guidelines: Aggregation



Since an EnMS is naturally a point of aggregation it is not necessary to
model aggregation for Energy Management Systems. Aggregation SHOULD be

used for power and energy. It MAY be



"Aggregation SHOULD be used for power and

energy" is misleading I guess you mean: "The Aggregation

Relationship is intended for power and energy" For the rest below.

Section 6 is a series of examples I'm fine with section 7, 8, and 9

(IANA, which I wrote) Regards, Benoit 



+ JP : Done



Thanks!!



Jp


















--_000_9C213D38848B89428F46808B16F6F08601667938xmbalnx04ciscoc_--

From jparello@cisco.com  Sun Oct 13 15:02:27 2013
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 EB93E21E808E for ; Sun, 13 Oct 2013 15:02:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.9
X-Spam-Level: 
X-Spam-Status: No, score=-9.9 tagged_above=-999 required=5 tests=[AWL=0.698, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oHUNLOB0y6KR for ; Sun, 13 Oct 2013 15:02:22 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 4CE5821E811B for ; Sun, 13 Oct 2013 15:02:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18545; q=dns/txt; s=iport; t=1381701739; x=1382911339; h=from:to:cc:subject:date:message-id:mime-version; bh=GtA+lEZoJuVXIxnLU1thyuI4bnSoxhBE/54x7fYjB5E=; b=MkMN4xWqcp6YvwYBCbRUbpQxLj1IVGS4Dr1W1KH/oXfarRI1hXf+5XMc VVMtJ3I5VwCSU3U694dueqXyO5TDZLPR9u2RKcOrNQseMZZcPnXZ1D+fx 988Jou/c6bBXyQNITw3d6cMNnP6l3K2dJxTXg93CfOEBanIP7XLJZUmtc w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AlkGAHgXW1KtJXG9/2dsb2JhbABZgkNEgQrBbYEaFm0HgicBBGcLBxIBKlYmAQQODYd+vHeOEwEGgQcxgyaBBAOqB4MkgWcBHyI
X-IronPort-AV: E=Sophos;i="4.93,487,1378857600";  d="scan'208,217";a="271610513"
Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-7.cisco.com with ESMTP; 13 Oct 2013 22:02:18 +0000
Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r9DM2I5X025163 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 13 Oct 2013 22:02:18 GMT
Received: from xmb-aln-x04.cisco.com ([169.254.9.229]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.004; Sun, 13 Oct 2013 17:02:18 -0500
From: "John Parello (jparello)" 
To: "eman@ietf.org" 
Thread-Topic: BNordman - draft-ietf-eman-framework-09: WGLC comments
Thread-Index: Ac7IX+GcdJ3yiX5rSB2HSKtG8uKgEQ==
Date: Sun, 13 Oct 2013 22:02:17 +0000
Message-ID: <9C213D38848B89428F46808B16F6F0860166795D@xmb-aln-x04.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.21.78.193]
Content-Type: multipart/alternative; boundary="_000_9C213D38848B89428F46808B16F6F0860166795Dxmbalnx04ciscoc_"
MIME-Version: 1.0
Subject: [eman] BNordman - draft-ietf-eman-framework-09: WGLC comments
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 13 Oct 2013 22:02:28 -0000

--_000_9C213D38848B89428F46808B16F6F0860166795Dxmbalnx04ciscoc_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hi Bruce,

Thanks so much for your comments. Considering your position on the draft I'=
ll limit the comments applied to those that are or are near editorial. Thos=
e that indicate a previously stated approach counter to your proposal I'll =
leave so we don't have unnecessary debate or lobbying.

(+) Applied in the draft
(-) Regretfully not applied for the reasons listed
(!) Not applied needing more clarification and/or see further comment or th=
read


Thanks
Jp

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


The EMAN Framework draft is improving, as has been noted.  That said,
the comments below plus those in the review a few days ago from Juergen
Quittek indicate that the document still has far to go.  This list
is not comprehensive--that is not feasible with so much to address.
In addition, fixes that these comments lead to are likely to introduce
new issues or make clear existing ones that are not now readily apparent.
As this document has changed considerably over the past three+ years,
new issues continue to crop up.


Conceptual issues:

The mechanisms described for importance and role are non-standard and
arbitrary.  We might do well to have standard mechanisms for some
of these, but creating an anecdotal set solely in the context of EMAN
seems unlikely to contribute to that.  Until such time as there is some
basis for incorporating specific content, these should be left as
free-form keywords encoded in some standard syntax.

- JP : We gave guidance on that field.  Moving this to keywords with no sta=
ndard syntax only moves your point to another attribute?.

The "relationship" concept is not necessary.  Simpler methods can express
what is required.  It makes the document harder to understand, and so
is a barrier to it being widely adopted.

- JP : We receive feedback that this was useful and we've carried this appr=
oach for some time

It is stated that a device should be labeled as "a consumer, producer,
or meter, distributor, or store of energy".  It isn't explained what the
value of making this distinction is.

! JP : we can expand on that but though the category was enough. Suggestion=
s?

The concept of "caliber"is not needed; accuracy is sufficient.

- JP : This was our most asked for attributes. Accuracy for a device that d=
oes not use statistical nor physical (H/W) means to measure power is meanin=
gless. We need a way to indicate which devices can or can't measure power (=
some based on table lookups for example) See any EnMS on their "power ratin=
gs"  Joulex, Nimsoft, Schneider etc. Also device manufacturers embraced thi=
s notion at ODVA and the Cisco implementation. Very much needed.

The draft states that a device must have at least two states: one
on state and one off state.  There are devices for sale that have
two states, on and sleep (but no off) and devices with only one
state.  Why have this restriction?  and why require a device to
report power states at all?  most will certainly but some might
appropriately not do so.

+ JP :  should


The explanation of power state semantics in 4.5 is not consistent
with general usage of the concept of power state.  Power limitation
may be useful, but it is a different concept from power state and
should not be conflated.

4.5.4. These are arbitrary.  It would be better to specify registration
of the Cisco power state set since that is presumably already in use.

4.6. Power Source Relationship and Metering Relationship are redundant.
As the text points out, both are about wiring topologies.

4.6.3. The second and last paragraphs seem to be contradictory as
to whether two non-connected PIs can have a Power Source Relationship.

4.6.3. It is not clear how metering is to be applied.

4.6.4. It is stated that "Establishing aggregation relationships within
the same device would make modeling more complex=E2=80=A6".  The ER Framewo=
rk
accomplishes this without any complexity burden, so the statement in
general is not true.  It may be true of the EMAN Framework but that is
simply a flaw in the document.

4.6.5. The text leaves "proxy" relationships for future development,
but there are requirements (8.1) for proxy control that the framework
seems to not cover.

6. It is stated that some products cannot support power interfaces.
Any device can and could simply report "unknown" for data they do not know.

6.1. The draft indicates that power interfaces can be between devices and
components.  This adds a lot of complexity to the PI concept.  It would
be much simpler to not allow PIs between components.  For those niche
applications that desire that, the component in question could be modeled
as a distinct device.  Thus, complexity of EMAN could be reduced without
sacrificing capability.

Aggregation:

4.6. It is completely unclear how the Aggregation Relationship mentioned
is supposed to operate.

4.6.4.  It is suggested that a device can report only a single aggregation.
Is that true?

6.3. explains what aggregation is, but not how it actually works.
The two sentences in the middle paragraph contradict each other.

Corrections:

The introductions states that "The framework introduces the concept of
a power interface".  This is not true.  The power interface concept
was introduced in draft-quittek-eman-reference-model-02, over two
years ago.  Also, the definition provided for Power Interface doesn't
make sense, and does not correspond to the concept described in the
Reference Model, or the ER Framework.  The latter has a clear explanation,
the first sentence of which could be a definition.

! JP : We merged that document with this and the authors are on this docume=
nt. @Chairs can we reference a non-wg item that is expired, best way to foo=
tnote this?

The bulleted text under 4.5.2 on IEEE 1621 is wrong.  I have pointed
this out many many times without it being fixed.  Also, for 4.5.5,
IEEE 1621 does NOT say that hibernate is a form of sleep; it says that
hibernate should be presented as a form of off.  This error has also
been pointed out many times.

+ JP : changed to off in 4.5.5.  Section 4.5.2 now directly quotes IEEE1621=
 4.1
"""
The IEEE1621 Power State Set [IEEE1621] consists of 3 rudimentary states: o=
n, off or sleep.
In IEEE1621 devices are limited to the three basic power states =97 on, sle=
ep, and off. Any additional power states are variants of one of the basic s=
tates rather than a fourth state.
"""

Details:

2. Definition of "Meter".  Change "intended to measure" to "that measures".
In general, what is the difference intended when "are intended to" is
used as opposed to what the referenced concepts actually do?

- JP : see IEC60050

Unnecessary text:

The document is burdened throughout by text that is unnecessary to
accomplish what is needed.  This makes reading it more difficult and
so would impede use of the standard.  An example is defining and
discussing Non-Electrical Equipment.  This is more appropriate to
an application/implementation discussion document, not a framework.
Other examples include the list of target devices in Section 3.1, all
of Section 3.4, sections 4.3.3, 4.3.4, 4.3.5, the second half of 4.3.6,
and the middle two paragraphs of 4.4.

The requirements RFC says:
5.5.1.  Energy Measurement
   The standard must provide means for reporting measured values of
   energy and the direction of the energy flow received or provided by
   an entity.  The standard must also provide the means to report the
   energy passing through each Power Interface.
The Framework says:
    4.4.3. Measurements: Energy
        Optionally, an Energy Object that can report actual power
        readings will have energy attributes that provide the
        energy used, produced, or stored in kWh.
Aside from noting that kWh are to be used, what is the point of saying
this at all?  and if this is about reporting energy, why does the text
talk about power?

! JP : Not sure how you can have energy values if you can't measure actual =
power. ANything you can suggest to make that clearer as you read it?

Thanks!
Jp



--_000_9C213D38848B89428F46808B16F6F0860166795Dxmbalnx04ciscoc_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable








Hi Bruce,



Thanks so much for your comments. Considering your position on the draft I'=
ll limit the comments applied to those that are or are near editorial. Thos=
e that indicate a previously stated approach counter to your proposal I'll =
leave so we don't have unnecessary
 debate or lobbying. 



(+) Applied in the draft

(-) Regretfully not applied for the reasons listed

(!) Not applied needing more clarification and/or see further comment or th=
read





Thanks

Jp



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





The EMAN Framework draft is improving, as has been noted.  That said,<=
br>
the comments below plus those in the review a few days ago from Juergen

Quittek indicate that the document still has far to go.  This list

is not comprehensive--that is not feasible with so much to address.

In addition, fixes that these comments lead to are likely to introduce

new issues or make clear existing ones that are not now readily apparent.
As this document has changed considerably over the past three+ years, <=
br>
new issues continue to crop up.





Conceptual issues:



The mechanisms described for importance and role are non-standard and 

arbitrary.  We might do well to have standard mechanisms for some

of these, but creating an anecdotal set solely in the context of EMAN

seems unlikely to contribute to that.  Until such time as there is som=
e

basis for incorporating specific content, these should be left as 

free-form keywords encoded in some standard syntax.



- JP : We gave guidance on that field.  Moving this to keywords with n=
o standard syntax only moves your point to another attribute?.


 

The "relationship" concept is not necessary.  Simpler method=
s can express

what is required.  It makes the document harder to understand, and so<=
br>
is a barrier to it being widely adopted.



- JP : We receive feedback that this was useful and we've carried this appr=
oach for some time



It is stated that a device should be labeled as "a consumer, producer,=
 

or meter, distributor, or store of energy".  It isn't explained w=
hat the

value of making this distinction is.



! JP : we can expand on that but though the category was enough. Suggestion=
s?



The concept of "caliber"is not needed; accuracy is sufficient.


- JP : This was our most asked for attributes. Accuracy for a device that d=
oes not use statistical nor physical (H/W) means to measure power is meanin=
gless. We need a way to indicate which devices can or can't measure power (=
some based on table lookups for
 example) See any EnMS on their "power ratings"  Joulex, Nim=
soft, Schneider etc. Also device manufacturers embraced this notion at ODVA=
 and the Cisco implementation. Very much needed.



The draft states that a device must have at least two states: one

on state and one off state.  There are devices for sale that have 

two states, on and sleep (but no off) and devices with only one

state.  Why have this restriction?  and why require a device to
report power states at all?  most will certainly but some might

appropriately not do so.



+ JP :  should





The explanation of power state semantics in 4.5 is not consistent

with general usage of the concept of power state.  Power limitation
may be useful, but it is a different concept from power state and

should not be conflated.



4.5.4. These are arbitrary.  It would be better to specify registratio=
n

of the Cisco power state set since that is presumably already in use.



4.6. Power Source Relationship and Metering Relationship are redundant.

As the text points out, both are about wiring topologies.



4.6.3. The second and last paragraphs seem to be contradictory as

to whether two non-connected PIs can have a Power Source Relationship.



4.6.3. It is not clear how metering is to be applied.



4.6.4. It is stated that "Establishing aggregation relationships withi=
n

the same device would make modeling more complex=E2=80=A6".  The =
ER Framework

accomplishes this without any complexity burden, so the statement in

general is not true.  It may be true of the EMAN Framework but that is=


simply a flaw in the document.



4.6.5. The text leaves "proxy" relationships for future developme=
nt,

but there are requirements (8.1) for proxy control that the framework

seems to not cover.



6. It is stated that some products cannot support power interfaces.

Any device can and could simply report "unknown" for data they do=
 not know.



6.1. The draft indicates that power interfaces can be between devices and
components.  This adds a lot of complexity to the PI concept.  It=
 would

be much simpler to not allow PIs between components.  For those niche<=
br>
applications that desire that, the component in question could be modeled
as a distinct device.  Thus, complexity of EMAN could be reduced witho=
ut

sacrificing capability.



Aggregation:



4.6. It is completely unclear how the Aggregation Relationship mentioned
is supposed to operate.



4.6.4.  It is suggested that a device can report only a single aggrega=
tion.

Is that true?



6.3. explains what aggregation is, but not how it actually works. 

The two sentences in the middle paragraph contradict each other.

 

Corrections:



The introductions states that "The framework introduces the concept of=


a power interface".  This is not true.  The power interface =
concept

was introduced in draft-quittek-eman-reference-model-02, over two

years ago.  Also, the definition provided for Power Interface doesn't<=
br>
make sense, and does not correspond to the concept described in the

Reference Model, or the ER Framework.  The latter has a clear explanat=
ion,

the first sentence of which could be a definition.



! JP : We merged that document with this and the authors are on this docume=
nt. @Chairs can we reference a non-wg item that is expired, best way to foo=
tnote this?



The bulleted text under 4.5.2 on IEEE 1621 is wrong.  I have pointed
this out many many times without it being fixed.  Also, for 4.5.5, 
IEEE 1621 does NOT say that hibernate is a form of sleep; it says that

hibernate should be presented as a form of off.  This error has also
been pointed out many times.



+ JP : changed to off in 4.5.5.  Section 4.5.2 now directly quotes=
 IEEE1621 4.1

"""

The IEEE1621 Power State Set [IEEE1621] consists of 3 rudimentary states: o=
n, off or sleep.

In IEEE1621 devices are limited to the three basic power states =97 on, sle=
ep, and off. Any additional power states are variants of one of the basic s=
tates rather than a fourth state.

"""



Details:



2. Definition of "Meter".  Change "intended to measure&=
quot; to "that measures".

In general, what is the difference intended when "are intended to"=
; is

used as opposed to what the referenced concepts actually do?



- JP : see IEC60050



Unnecessary text:



The document is burdened throughout by text that is unnecessary to

accomplish what is needed.  This makes reading it more difficult and
so would impede use of the standard.  An example is defining and

discussing Non-Electrical Equipment.  This is more appropriate to

an application/implementation discussion document, not a framework.

Other examples include the list of target devices in Section 3.1, all

of Section 3.4, sections 4.3.3, 4.3.4, 4.3.5, the second half of 4.3.6,

and the middle two paragraphs of 4.4.



The requirements RFC says:

5.5.1.  Energy Measurement

   The standard must provide means for reporting measured values =
of

   energy and the direction of the energy flow received or provid=
ed by

   an entity.  The standard must also provide the means to r=
eport the

   energy passing through each Power Interface.

The Framework says:

    4.4.3. Measurements: Energy 

        Optionally, an Energy Object tha=
t can report actual power 

        readings will have energy attrib=
utes that provide the 

        energy used, produced, or stored=
 in kWh.  

Aside from noting that kWh are to be used, what is the point of saying

this at all?  and if this is about reporting energy, why does the text=


talk about power?



! JP : Not sure how you can have energy values if you can't measure actual =
power. ANything you can suggest to make that clearer as you read it?



Thanks!

Jp










--_000_9C213D38848B89428F46808B16F6F0860166795Dxmbalnx04ciscoc_--

From jparello@cisco.com  Sun Oct 13 22:37:33 2013
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 EF4BC21E80B8 for ; Sun, 13 Oct 2013 22:37:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.416
X-Spam-Level: 
X-Spam-Status: No, score=-9.416 tagged_above=-999 required=5 tests=[AWL=-0.019, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ouv1DyLM1WuH for ; Sun, 13 Oct 2013 22:37:28 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 6792C21E80B2 for ; Sun, 13 Oct 2013 22:37:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8949; q=dns/txt; s=iport; t=1381729046; x=1382938646; h=from:to:subject:date:message-id:mime-version; bh=T07TL2p6pBpNVZpmb3NeS7u5cMbAicdZGK1Rpvg4UDE=; b=JLTIshlbuNp4jkG7Om4YhzmaaFqZ5FZbYan5iNekGgVVjSoddkbDhfgY cd2dXhj63ru2PSCaPsMkWga1Nd96MpqbiHkzvgz8kMfjbf00QU4ZIYAgH vbs3AODABX6M6XA5imgDSMAAlHihHWIaSkGTebdhOf6gfA6RHWa4gsmD5 w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AsQFAM+CW1KtJXG9/2dsb2JhbABZgkNEgQrBZ4EaFm0HgicBBIELASpWJgEEG4d+nC6hFY4agQeDV4EEA6oHgySCKQ
X-IronPort-AV: E=Sophos;i="4.93,490,1378857600";  d="scan'208,217";a="271773336"
Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-4.cisco.com with ESMTP; 14 Oct 2013 05:37:24 +0000
Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r9E5bLDX017244 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 14 Oct 2013 05:37:21 GMT
Received: from xmb-aln-x04.cisco.com ([169.254.9.229]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Mon, 14 Oct 2013 00:37:21 -0500
From: "John Parello (jparello)" 
To: "eman@ietf.org" 
Thread-Topic: Authors - draft-ietf-eman-framework-10: WGLC comments
Thread-Index: Ac7Inz/7R3qVc61VRsGPcvbes8mfag==
Date: Mon, 14 Oct 2013 05:37:21 +0000
Message-ID: <9C213D38848B89428F46808B16F6F08601667AFA@xmb-aln-x04.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.21.120.37]
Content-Type: multipart/alternative; boundary="_000_9C213D38848B89428F46808B16F6F08601667AFAxmbalnx04ciscoc_"
MIME-Version: 1.0
Subject: [eman] Authors - draft-ietf-eman-framework-10: WGLC comments
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Oct 2013 05:37:34 -0000

--_000_9C213D38848B89428F46808B16F6F08601667AFAxmbalnx04ciscoc_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hi,

These are the review comments we had among the authors on 10/8 and applied:

* 10/8 Author's call
Nevil, Benoit, Brad, John

** Discussed specific points from reviews and concluded=85..


*** Capitalization
    Move modeling (class) into section 4
        only power / energy not capitalize
        See txt
+ JP : Done, had the option to lower case common terms went with that will =
review 10/15 before publishing

*** Scalar vs Vector
       Category  - overloaded if vectore { cons, prod, meter, distributor, =
store }
            Primary is better received
        ex: car { biz, pleasure, commute }
       Role - need semantic not vector
       Location? (new) - clearly not vector but semantic like rfc4776 bette=
r geo-priv
       Domain - no problem we discussed and went with single
Experience in filed is that scalar was only needed for these.
ref point lldp : brad

+ JP : Done


*** Section 3.3 Bullet list
   Editing trying to get a sane list not pages. What would we like there?
 put back or better description..

+ JP : Agree with JQ I consolidate those sections to main points and unless=
 we want that section I deleted it. Serves no purpose any longer with requi=
rements draft and applicability IMO.Any objections??

*** Context in device versus in NMS
   Ask and answered we can discuss again

+ JP : nothing to do here agreed on device and not hidden in mms

*** Should state be in a section on control if they can be used for monitor=
ing
   We talked about this in authors call and said ok in control, everything =
can be monitored and seemed a better location.
we are ok with in control. "add sentence that while power state in control =
they can be used for monitoring wihout any change ..."

+ JP : Added sentence

*** Demand, Energy when power is not actual
   relates to caliber.
   IF power isn't actual demand and energy is not applicable. Thought exerc=
ise that you can report energy and demand and not provide power but that's =
mental exercise.  could ignore this but that was the point
ask for improvement txt

+ JP : asked in comment and clarified in sections after definition move.

*** Better description of physical
physical strict border between sections on physcal and modelled
Only physical before section 6
physical: inlet outlet "electrical connection"
modeling: power interface

+ JP : used scheme below


*** Section 6.2 Metering
   Should be for a "METER" Case 2 not just because an interface measures en=
ergy. That would clear up the controversy.
   S.B. one case not two was confusing people

+ JP : Consolidated to only use for a meter

*** Feedback: lost from uml link to interfaces and components
  Added

+JP: PowerInterface powerInterfaces[0..n]  Component components[0..n]
 Note: Component could sub-class Device. May confuse the non modelers so le=
aving as siblings and can remove.

*** Make sure the text doesn't read energy object as instance but as class.

+ JP : Done went with this scheme strictly

"""
I) This physical thing IRL,
II)Is described by
III) and represented by this

I)Physical      II) Modeling (Meta Data)  III)Instance
---------------------------------------------------------

equipment        Energy Object (Class)    Energy Object
device           Device (Class)           Device
component        Component (Class)        Component
inlet / outlet   Power Interface (Class)  Power Interface
"""

Thanks!
Jp


--_000_9C213D38848B89428F46808B16F6F08601667AFAxmbalnx04ciscoc_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable








Hi,



These are the review comments we had among the authors on 10/8 and applied:=




* 10/8 Author's call

Nevil, Benoit, Brad, John



** Discussed specific points from reviews and concluded=85..

 



*** Capitalization

    Move modeling (class) into section 4

        only power / energy not capitali=
ze

        See txt 

+ JP : Done, had the option to lower case common terms went with that w=
ill review 10/15 before publishing



*** Scalar vs Vector

       Category  - overloaded if vectore=
 { cons, prod, meter, distributor, store }

            Primary =
is better received

        ex: car { biz, pleasure, commute }
       Role - need semantic not vector

       Location? (new) - clearly not vector b=
ut semantic like rfc4776 better geo-priv

       Domain - no problem we discussed and w=
ent with single

Experience in filed is that scalar was only needed for these.

ref point lldp : brad



+ JP : Done





*** Section 3.3 Bullet list

   Editing trying to get a sane list not pages. What would we lik=
e there?

 put back or better description..



+ JP : Agree with JQ I consolidate those sections to main points and un=
less we want that section I deleted it. Serves no purpose any longer with r=
equirements draft and applicability IMO.Any objections??



*** Context in device versus in NMS

   Ask and answered we can discuss again



+ JP : nothing to do here agreed on device and not hidden in mms



*** Should state be in a section on control if they can be used for monitor=
ing

   We talked about this in authors call and said ok in control, e=
verything can be monitored and seemed a better location.

we are ok with in control. "add sentence that while power state in con=
trol they can be used for monitoring wihout any change ..."



+ JP : Added sentence



*** Demand, Energy when power is not actual

   relates to caliber. 

   IF power isn't actual demand and energy is not applicable. Tho=
ught exercise that you can report energy and demand and not provide power b=
ut that's mental exercise.  could ignore this but that was the point
ask for improvement txt



+ JP : asked in comment and clarified in sections after definition move=
. 



*** Better description of physical

physical strict border between sections on physcal and modelled

Only physical before section 6

physical: inlet outlet "electrical connection"

modeling: power interface



+ JP : used scheme below





*** Section 6.2 Metering

   Should be for a "METER" Case 2 not just because an i=
nterface measures energy. That would clear up the controversy.


   S.B. one case not two was confusing people



+ JP : Consolidated to only use for a meter



*** Feedback: lost from uml link to interfaces and components

  Added



+JP: PowerInterface powerInterfaces[0..n]  Component components[0.=
.n]

 Note: Component could sub-class Device. May confuse the non modelers =
so leaving as siblings and can remove.



*** Make sure the text doesn't read energy object as instance but as class.=




+ JP : Done went with this scheme strictly 



"""

I) This physical thing IRL,

II)Is described by

III) and represented by this



I)Physical      II) Modeling (Meta Data)  III=
)Instance

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



equipment        Energy Object (Class)&n=
bsp;   Energy Object 

device           Device (=
Class)           Device
component        Component (Class) =
       Component

inlet / outlet   Power Interface (Class)  Power Interface
"""



Thanks!

Jp








--_000_9C213D38848B89428F46808B16F6F08601667AFAxmbalnx04ciscoc_--

From moulchan@cisco.com  Tue Oct 15 06:49:13 2013
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 0351721E80E8 for ; Tue, 15 Oct 2013 06:49:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.603
X-Spam-Level: 
X-Spam-Status: No, score=-9.603 tagged_above=-999 required=5 tests=[AWL=0.995,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qcPE0fnV-oOz for ; Tue, 15 Oct 2013 06:49:07 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 9426721E80CE for ; Tue, 15 Oct 2013 06:48:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2681; q=dns/txt; s=iport; t=1381844936; x=1383054536; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=4oz3uf1+7/YsUEj7dwXIsoGa32toLabpCYnlx/WY7+I=; b=lO5T5ib39Yk1N35xGgLOwIyrvYBiciWffs+WBtqpgKO17TdZS+DSnaKj 7oKn1wlHfIhxYaxR9KjOoajbapmYLUaww8rkok/70WcDw86PFsuOmuQDA GQngW4l4xqKyv1kfPUonrt3sL0by/cPHkqYSctDjF+FmO1SokXxGQEwcX w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AigGAMFGXVKtJXG9/2dsb2JhbABagkNEgQrCI4EhFm0HgicBBHIZAQwBHVYlAgQbh36baKFEjxk4gx+BBgOqBoMkgik
X-IronPort-AV: E=Sophos;i="4.93,499,1378857600";  d="scan'208,217";a="272297656"
Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-5.cisco.com with ESMTP; 15 Oct 2013 13:48:56 +0000
Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r9FDmtK6027985 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 15 Oct 2013 13:48:56 GMT
Received: from xmb-rcd-x08.cisco.com ([169.254.8.94]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.004; Tue, 15 Oct 2013 08:48:55 -0500
From: "Mouli Chandramouli (moulchan)" 
To: "eman@ietf.org" 
Thread-Topic: draft-ietf-eman-applicability-statement-03
Thread-Index: AQHOya1J/mCrTbQ/v0SrKiRphbJxhw==
Date: Tue, 15 Oct 2013 13:48:54 +0000
Message-ID: <852AF0ED49D9F24BBBFA1B4DEEBE3BA42ADBD274@xmb-rcd-x08.cisco.com>
In-Reply-To: <9C213D38848B89428F46808B16F6F08601667AFA@xmb-aln-x04.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.8.130913
x-originating-ip: [10.65.39.207]
Content-Type: multipart/alternative; boundary="_000_852AF0ED49D9F24BBBFA1B4DEEBE3BA42ADBD274xmbrcdx08ciscoc_"
MIME-Version: 1.0
Subject: [eman] draft-ietf-eman-applicability-statement-03
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, 15 Oct 2013 13:49:13 -0000

--_000_852AF0ED49D9F24BBBFA1B4DEEBE3BA42ADBD274xmbrcdx08ciscoc_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hello all,

We are working on updating the  draft Applicability Statement draft before =
this IETF meeting.

We would like to get the input of the WG on a coupe of important points.

Currently, the EMAN Applicability Statement draft as it stands  contains =
=96 use cases and relation standards;  and does not have a discussion of ho=
w the technologies developed in EMAN WG =96 EMAN Framework, MIB modules can=
 be implemented.

Should this draft be split in to two drafts  -  (1) use cases and related s=
tandards  (2)  Applicability of EMAN Framework

or  a consolidated Applicability statement draft which contains a section o=
f how the Framework can be applied.

Please provide your thoughts.

Thanks
Mouli



--_000_852AF0ED49D9F24BBBFA1B4DEEBE3BA42ADBD274xmbrcdx08ciscoc_
Content-Type: text/html; charset="Windows-1252"
Content-ID: 
Content-Transfer-Encoding: quoted-printable







Hello all,







We are working on updating the  draft Applicability Statement dra=
ft before this IETF meeting. 







We would like to get the input of the WG on a coupe of important point=
s. 







Currently, the EMAN Applicability Statement draft as it stands  c=
ontains =96 use cases and relation standards;  and does not have a dis=
cussion of how the technologies developed in EMAN WG =96 EMAN Framework, MI=
B modules can be implemented.  







Should this draft be split in to two drafts  -  (1) use case=
s and related standards  (2)  Applicability of EMAN Framework &nb=
sp; 







or  a consolidated Applicability statement draft which contains a=
 section of how the Framework can be applied. 







Please provide your thoughts. 







Thanks


Mouli















--_000_852AF0ED49D9F24BBBFA1B4DEEBE3BA42ADBD274xmbrcdx08ciscoc_--

From blueroofmusic@gmail.com  Tue Oct 15 07:03:24 2013
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 DD8B121F9D56 for ; Tue, 15 Oct 2013 07:03:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PYU6o9ixYW+w for ; Tue, 15 Oct 2013 07:03:24 -0700 (PDT)
Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id C460321E8123 for ; Tue, 15 Oct 2013 07:03:19 -0700 (PDT)
Received: by mail-ie0-f180.google.com with SMTP id e14so9998417iej.39 for ; Tue, 15 Oct 2013 07:03:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=kU5pw5TH7xVJWouSa5wKetHh+/RRa8j773YjQfzm8W4=; b=ys4/qK443K6HmPJUtUR3uvWS8VnJRPwwz/rMYUz7zWIVnPnselBk/+tuldp5ptqHAz xmkMTPb+yzla4uBWWps1Rql8qUNcee7ZgpZ8ybrCnzE/xLot1+9seNDkN3aNTT7MwEfg t9WrOwnUuAOLzgpIulex+LBUn8zMIeN3ItBliksdywOiOX5OIBa5AdJrWFURpPOVoGqD wOTelt2XgHGwA2mlmDSVX6DN3J8VqvulTGuGO5CxcGyVRp2L5/DLLITjHQ6WuRwBQaw2 N5eDeWzQgvKHZC4u1EnNePvqXzlH11uXMfsR6pMkssnth00VdZvy4+AhnXaTVc6idOFM Xv0g==
X-Received: by 10.42.202.145 with SMTP id fe17mr237784icb.92.1381845799225; Tue, 15 Oct 2013 07:03:19 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.50.96.135 with HTTP; Tue, 15 Oct 2013 07:02:59 -0700 (PDT)
In-Reply-To: <852AF0ED49D9F24BBBFA1B4DEEBE3BA42ADBD274@xmb-rcd-x08.cisco.com>
References: <9C213D38848B89428F46808B16F6F08601667AFA@xmb-aln-x04.cisco.com> <852AF0ED49D9F24BBBFA1B4DEEBE3BA42ADBD274@xmb-rcd-x08.cisco.com>
From: Ira McDonald 
Date: Tue, 15 Oct 2013 10:02:59 -0400
Message-ID: 
To: "Mouli Chandramouli (moulchan)" , Ira McDonald 
Content-Type: multipart/alternative; boundary=20cf301af979ff554f04e8c80b4f
Cc: "eman@ietf.org" 
Subject: Re: [eman] draft-ietf-eman-applicability-statement-03
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, 15 Oct 2013 14:03:25 -0000

--20cf301af979ff554f04e8c80b4f
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Hi Mouli,

I prefer a single Applicability Statement - simpler for implementors and
avoids inconsistencies between two documents.

Cheers,
- Ira


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



On Tue, Oct 15, 2013 at 9:48 AM, Mouli Chandramouli (moulchan) <
moulchan@cisco.com> wrote:

>  Hello all,
>
>  We are working on updating the  draft Applicability Statement draft
> before this IETF meeting.
>
>  We would like to get the input of the WG on a coupe of important points.
>
>  Currently, the EMAN Applicability Statement draft as it stands  contains
> =96 use cases and relation standards;  and does not have a discussion of =
how
> the technologies developed in EMAN WG =96 EMAN Framework, MIB modules can=
 be
> implemented.
>
>  Should this draft be split in to two drafts  -  (1) use cases and
> related standards  (2)  Applicability of EMAN Framework
>
>  or  a consolidated Applicability statement draft which contains a
> section of how the Framework can be applied.
>
>  Please provide your thoughts.
>
>  Thanks
> Mouli
>
>
>
> _______________________________________________
> eman mailing list
> eman@ietf.org
> https://www.ietf.org/mailman/listinfo/eman
>
>

--20cf301af979ff554f04e8c80b4f
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable


Hi Mouli,

I prefer a sing=
le Applicability Statement - simpler for implementors and
avoids i=
nconsistencies between two documents.

Cheers,
- Ira



Ira McDonald (M=
usician / Software Architect)
Chair - Linux Foundation Open Printing WG<=
br>Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG =
IPP WG


Co-Chair - TCG Trusted Mobility Solutions WG
Chair - TCG Embedded System=
s Hardcopy SG
IETF Designated Expert - IPP & Printer MIB
Blue Roo=
f Music/High North Inc
http://sites.google.=
com/site/blueroofmusic


http://sites.google.com/site/highnorthincmailto:bluer=
oofmusic@gmail.com


Winter=A0 579 Park Place=A0 Saline, MI=A0 48176=A0 734-944-0094
Summer=
=A0 PO Box 221=A0 Grand Marais, MI 49839=A0 906-494-2434







On Tue, Oct 15, 2013 at 9:48 AM, Mouli C=
handramouli (moulchan) <moulchan@cisco.com> wrote:









Hello all,







We are working on updating the =A0draft Applicability Statement draft =
before this IETF meeting.=A0







We would like to get the input of the WG on a coupe of important point=
s.=A0







Currently, the EMAN Applicability Statement draft as it stands =A0cont=
ains =96 use cases and relation standards; =A0and does not have a discussio=
n of how the technologies developed in EMAN WG =96 EMAN Framework, MIB modu=
les can be implemented. =A0









Should this draft be split in to two drafts =A0- =A0(1) use cases and =
related standards =A0(2) =A0Applicability of EMAN Framework =A0=A0







or =A0a consolidated Applicability statement draft which contains a se=
ction of how the Framework can be applied.=A0







Please provide your thoughts.=A0







Thanks


Mouli
















_______________________________________________

eman mailing list

eman@ietf.org

ht=
tps://www.ietf.org/mailman/listinfo/eman





--20cf301af979ff554f04e8c80b4f--

From jparello@cisco.com  Tue Oct 15 08:57:45 2013
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 55BA811E8116 for ; Tue, 15 Oct 2013 08:57:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level: 
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SyXjMOJrch5C for ; Tue, 15 Oct 2013 08:57:39 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id E78D211E813D for ; Tue, 15 Oct 2013 08:57:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11730; q=dns/txt; s=iport; t=1381852659; x=1383062259; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=wOGF7x1+QNTq9LORNf1g2pQdg8zv1d1gNREiYXzmsiw=; b=KQOvs3juG/5Ry1AsKTP8x6ZGQkPOgWidYx1gyxLPVh74MwE8mrkHmIMb 08wX4x7HCS5EGwpARAgViRIEtLIhkrHAKvX66w3pH43tYvPua4Puu+05Y HBvElslZD3VpKi1Rzt94h1CKNJ6/nUyO00Lq2VSUHrHQXdNRdTAbyDZsx w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Au0FAF9lXVKtJV2b/2dsb2JhbABXA4JDRDhSuV+IS4EiFnSCJQEBAQQBAQEqPgMEBxACAQgRBAEBCx0HIQYLFAkIAgQBDQUIE4dZAw4BDLNPDYlrjFyCPSEMBAYBEYMOgQYDlhuDGIsdhTaDJIIp
X-IronPort-AV: E=Sophos;i="4.93,500,1378857600";  d="scan'208,217";a="272360536"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-5.cisco.com with ESMTP; 15 Oct 2013 15:57:38 +0000
Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r9FFvcH3030266 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 15 Oct 2013 15:57:38 GMT
Received: from xmb-aln-x04.cisco.com ([169.254.9.229]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.004; Tue, 15 Oct 2013 10:57:37 -0500
From: "John Parello (jparello)" 
To: Ira McDonald , "Mouli Chandramouli (moulchan)" 
Thread-Topic: [eman] draft-ietf-eman-applicability-statement-03
Thread-Index: AQHOya1XhPmRAxL68E2HFGZjRtJddZn2HvmA///MDyA=
Date: Tue, 15 Oct 2013 15:57:37 +0000
Message-ID: <9C213D38848B89428F46808B16F6F0860166902A@xmb-aln-x04.cisco.com>
References: <9C213D38848B89428F46808B16F6F08601667AFA@xmb-aln-x04.cisco.com> <852AF0ED49D9F24BBBFA1B4DEEBE3BA42ADBD274@xmb-rcd-x08.cisco.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [171.71.223.71]
Content-Type: multipart/alternative; boundary="_000_9C213D38848B89428F46808B16F6F0860166902Axmbalnx04ciscoc_"
MIME-Version: 1.0
Cc: "eman@ietf.org" 
Subject: Re: [eman] draft-ietf-eman-applicability-statement-03
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, 15 Oct 2013 15:57:45 -0000

--_000_9C213D38848B89428F46808B16F6F0860166902Axmbalnx04ciscoc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

+1

Contained in one doc for me.

Jp

From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Ira=
 McDonald
Sent: Tuesday, October 15, 2013 7:03 AM
To: Mouli Chandramouli (moulchan); Ira McDonald
Cc: eman@ietf.org
Subject: Re: [eman] draft-ietf-eman-applicability-statement-03

Hi Mouli,
I prefer a single Applicability Statement - simpler for implementors and
avoids inconsistencies between two documents.
Cheers,
- Ira

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

On Tue, Oct 15, 2013 at 9:48 AM, Mouli Chandramouli (moulchan) > wrote:
Hello all,

We are working on updating the  draft Applicability Statement draft before =
this IETF meeting.

We would like to get the input of the WG on a coupe of important points.

Currently, the EMAN Applicability Statement draft as it stands  contains - =
use cases and relation standards;  and does not have a discussion of how th=
e technologies developed in EMAN WG - EMAN Framework, MIB modules can be im=
plemented.

Should this draft be split in to two drafts  -  (1) use cases and related s=
tandards  (2)  Applicability of EMAN Framework

or  a consolidated Applicability statement draft which contains a section o=
f how the Framework can be applied.

Please provide your thoughts.

Thanks
Mouli



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


--_000_9C213D38848B89428F46808B16F6F0860166902Axmbalnx04ciscoc_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











+1



 <=
/p>

Contained in one doc for =
me.


 <=
/p>

Jp


 <=
/p>

From: eman-bou=
nces@ietf.org [mailto:eman-bounces@ietf.org]
On Behalf Of Ira McDonald

Sent: Tuesday, October 15, 2013 7:03 AM

To: Mouli Chandramouli (moulchan); Ira McDonald

Cc: eman@ietf.org

Subject: Re: [eman] draft-ietf-eman-applicability-statement-03<=
/o:p>


 












Hi Mouli,<=
/p>



I prefer a single Applicability Statement - simpler =
for implementors and




avoids inconsistencie=
s between two documents.




Cheers,




- Ira













Ira McDonald (Musicia=
n / Software Architect)

Chair - Linux Foundation Open Printing WG

Secretary - IEEE-ISTO Printer Working Group

Co-Chair - IEEE-ISTO PWG IPP WG

Co-Chair - TCG Trusted Mobility Solutions WG

Chair - TCG Embedded Systems Hardcopy SG

IETF Designated Expert - IPP & Printer MIB

Blue Roof Music/High North Inc

http://sites.google.com/site/blueroofmusic

http://sites.google.com/site/highnorthinc=


mailto:blueroo=
fmusic@gmail.com

Winter  579 Park Place  Saline, MI  48176  734-944-0094=


Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434




 




On Tue, Oct 15, 2013 at 9:48 AM, Mouli Chandramouli =
(moulchan) <moul=
chan@cisco.com> wrote:






Hello all,






 






We are working on updating the  dr=
aft Applicability Statement draft before this IETF meeting. 






 






We would like to get the input of the W=
G on a coupe of important points. 






 






Currently, the EMAN Applicability State=
ment draft as it stands  contains – use cases and relation stand=
ards;  and does not have a discussion of how the technologies develope=
d
 in EMAN WG – EMAN Framework, MIB modules can be implemented.  <=
o:p>






 






Should this draft be split in to two dr=
afts  -  (1) use cases and related standards  (2)  Appl=
icability of EMAN Framework   






 






or  a consolidated Applicability s=
tatement draft which contains a section of how the Framework can be applied=
. 






 






Please provide your thoughts. 






 






Thanks






Mouli





 <=
/p>





 <=
/p>







_______________________________________________

eman mailing list

eman@ietf.org

ht=
tps://www.ietf.org/mailman/listinfo/eman




 








--_000_9C213D38848B89428F46808B16F6F0860166902Axmbalnx04ciscoc_--

From brads@coraid.com  Tue Oct 15 12:25:19 2013
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 ADEAF21F9C05 for ; Tue, 15 Oct 2013 12:25:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4TsM-x-6VL06 for ; Tue, 15 Oct 2013 12:25:15 -0700 (PDT)
Received: from server506.appriver.com (server506k.appriver.com [50.56.144.157]) by ietfa.amsl.com (Postfix) with ESMTP id AC23F21F9A44 for ; Tue, 15 Oct 2013 12:25:13 -0700 (PDT)
X-Note-AR-ScanTimeLocal: 10/15/2013 2:25:11 PM
X-Policy: GLOBAL - coraid.com
X-Policy: GLOBAL - coraid.com
X-Policy: GLOBAL - coraid.com
X-Primary: brads@coraid.com
X-Note: This Email was scanned by AppRiver SecureTide
X-Virus-Scan: V-
X-Note-SnifferID: 0
X-Note: TCH-CT/SI:0-125/SG:5 10/15/2013 2:24:17 PM
X-GBUdb-Analysis: 0, 10.242.229.139, Ugly c=1 p=-0.959424 Source White
X-Signature-Violations: 0-0-0-32767-c
X-Note-419: 31.2006 ms. Fail:0 Chk:1350 of 1350 total
X-Note: SCH-CT/SI:0-1350/SG:1 10/15/2013 2:24:57 PM
X-Note: Spam Tests Failed: 
X-Country-Path: UNKNOWN->PRIVATE->UNITED STATES
X-Note-Sending-IP: 10.242.229.139
X-Note-Reverse-DNS: smtp.exg6.exghost.com
X-Note-Return-Path: brads@coraid.com
X-Note: User Rule Hits: 
X-Note: Global Rule Hits: G340 G341 G342 G343 G347 G348 G457 
X-Note: Encrypt Rule Hits: 
X-Note: Mail Class: VALID
X-Note: Headers Injected
Received: from [10.242.229.139] (HELO smtp.exg6.exghost.com) by server506.appriver.com (CommuniGate Pro SMTP 6.0.2) with ESMTPS id 16122010; Tue, 15 Oct 2013 14:25:07 -0500
Received: from DAGN05C-E6.exg6.exghost.com ([169.254.3.11]) by HT02-E6.exg6.exghost.com ([50.56.144.20]) with mapi id 14.03.0158.001; Tue, 15 Oct 2013 14:24:36 -0500
From: Brad Schoening 
To: Ira McDonald , "Mouli Chandramouli (moulchan)" 
Thread-Topic: [eman] draft-ietf-eman-applicability-statement-03
Thread-Index: AQHOya1Xeg5HWhS/8UWKWtUOm1szVZn2HvmAgAAWyQA=
Date: Tue, 15 Oct 2013 19:24:35 +0000
Message-ID: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.14.0.111121
x-originating-ip: [50.56.144.247]
x-rerouted-by-exchange: 
Content-Type: multipart/alternative; boundary="_000_CE82EC88EB6A1bradscoraidcom_"
MIME-Version: 1.0
Cc: "eman@ietf.org" 
Subject: Re: [eman] draft-ietf-eman-applicability-statement-03
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, 15 Oct 2013 19:25:20 -0000

--_000_CE82EC88EB6A1bradscoraidcom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Ira,

The root of the issue is that the "Applicability Statement" begin as a comp=
anion documents to the EMAN Framework addressing the applicability of other=
 standards and information models w.r.t. the EMAN framework.   Since then, =
use cases have also been added to the Applicability Statement document.

Use of the name 'Applicability' has lead to confusion that this document wi=
ll also provide implementation guidelines and best practices. While such a =
document would be valuable, its not clear how it relates to abstract use ca=
ses and international and national standards bodies.

The Abstract of the Applicability statement claims:


        Abstract

        The objective of Energy Management (EMAN)is to provide an energy
        management framework for networked devices. This document
        presents the applicability of the EMAN framework for a variety
        of scenarios. This document lists use cases and target devices
        that can potentially implement the EMAN framework and associated
        SNMP MIB modules. These use cases are useful for identifying
        monitoring requirements that need to be considered. Further, we
        describe the relationship of the EMAN framework to relevant

other energy monitoring standards and architectures.

So, it might be more useful to think of this as the EMAN Framework Applicab=
ility Statement vs. an EMAN MIB Applicability/Implementation Guide.

Regards,

Brad

Brad Schoening
Engineering | Coraid
Tel: +1 917 304 7190
brads@coraid.com | www.coraid.com
Coraid: Redefining Storage


From: Ira McDonald =
>
Date: Tue, 15 Oct 2013 10:02:59 -0400
To: "Mouli Chandramouli (moulchan)" >, Ira McDonald >
Cc: "eman@ietf.org" >
Subject: Re: [eman] draft-ietf-eman-applicability-statement-03

Hi Mouli,

I prefer a single Applicability Statement - simpler for implementors and
avoids inconsistencies between two documents.

Cheers,
- Ira


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



On Tue, Oct 15, 2013 at 9:48 AM, Mouli Chandramouli (moulchan) > wrote:
Hello all,

We are working on updating the  draft Applicability Statement draft before =
this IETF meeting.

We would like to get the input of the WG on a coupe of important points.

Currently, the EMAN Applicability Statement draft as it stands  contains =
=96 use cases and relation standards;  and does not have a discussion of ho=
w the technologies developed in EMAN WG =96 EMAN Framework, MIB modules can=
 be implemented.

Should this draft be split in to two drafts  -  (1) use cases and related s=
tandards  (2)  Applicability of EMAN Framework

or  a consolidated Applicability statement draft which contains a section o=
f how the Framework can be applied.

Please provide your thoughts.

Thanks
Mouli



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


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

--_000_CE82EC88EB6A1bradscoraidcom_
Content-Type: text/html; charset="Windows-1252"
Content-ID: <1B7B7016125A2B4F81A935B006BE2AE3@fwd6.exghost.com>
Content-Transfer-Encoding: quoted-printable











Ira,







The root of the issue is that the "Applicability Statement" =
begin as a companion documents to the EMAN Framework addressing the applica=
bility of other standards and information models w.r.t. the EMAN framework.=
   Since then, use cases have also been added
 to the Applicability Statement document.







Use of the name 'Applicability' has lead to confusion that this docume=
nt will also provide implementation guidelines and best practices. While su=
ch a document would be valuable, its not clear how it relates to abstract u=
se cases and international and national
 standards bodies.







The Abstract of the Applicability statement claims:







	Abst=
ract

        The objective of Energy Management (EMAN)is to provide an energy
        management framework for networked devices. This document
        presents the applicability of the EMAN framework for a variety
        of scenarios. This document lists use cases and target devices
        that can potentially implement the EMAN framework and associated
        SNMP MIB modules. These use cases are useful for identifying
        monitoring requirements that need to be considered. Further, we
        describe the relationship of the EMAN framework to relevant 

other energy monitoring standards and architectures.=








So, it might be more useful to think of this as the EMAN Framework App=
licability Statement vs. an EMAN MIB Applicability/Implementation Guide.






Regards,







Brad


 





Brad
 Schoening

Engineering | Coraid

Tel: +1 917 304 7190

brads@coraid.com | 
www.coraid.com




Coraid: Redefinin=
g Storage




















From: Ira McDonald <blueroofmusic@gmail.com>

Date: Tue, 15 Oct 2013 10:02:59 -04=
00

To: "Mouli Chandramouli (moulc=
han)" <moulchan@cisco.com=
>, Ira McDonald <blueroofm=
usic@gmail.com>

Cc: "eman@ietf.org" <eman@i=
etf.org>

Subject: Re: [eman] draft-ietf-eman=
-applicability-statement-03

















Hi Mouli,





I prefer a single Applicability Statement - simpler for implementors and


avoids inconsistencies between two documents.





Cheers,



- Ira









Ira McDonald (Musician / Software Architect)

Chair - Linux Foundation Open Printing WG

Secretary - IEEE-ISTO Printer Working Group

Co-Chair - IEEE-ISTO PWG IPP WG

Co-Chair - TCG Trusted Mobility Solutions WG

Chair - TCG Embedded Systems Hardcopy SG

IETF Designated Expert - IPP & Printer MIB

Blue Roof Music/High North Inc

http://sites.google.com/site/blueroofmusic=


http://sites.google.com/site/highnorthinc
mailto:blueroo=
fmusic@gmail.com

Winter  579 Park Place  Saline, MI  48176  734-944-0094=


Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434
























On Tue, Oct 15, 2013 at 9:48 AM, Mouli Chandramo=
uli (moulchan)
<moulchan@cisco.com> wrote:






Hello all,







We are working on updating the  draft Applicability Statement dra=
ft before this IETF meeting. 







We would like to get the input of the WG on a coupe of important point=
s. 







Currently, the EMAN Applicability Statement draft as it stands  c=
ontains =96 use cases and relation standards;  and does not have a dis=
cussion of how the technologies developed in EMAN WG =96 EMAN Framework, MI=
B modules can be implemented.  







Should this draft be split in to two drafts  -  (1) use case=
s and related standards  (2)  Applicability of EMAN Framework &nb=
sp; 







or  a consolidated Applicability statement draft which contains a=
 section of how the Framework can be applied. 







Please provide your thoughts. 







Thanks



Mouli















_______________________________________________

eman mailing list

eman@ietf.org

ht=
tps://www.ietf.org/mailman/listinfo/eman











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



--_000_CE82EC88EB6A1bradscoraidcom_--

From blueroofmusic@gmail.com  Tue Oct 15 13:42:24 2013
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 7AC7D11E8205 for ; Tue, 15 Oct 2013 13:42:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RyrabfOejH4d for ; Tue, 15 Oct 2013 13:42:23 -0700 (PDT)
Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 20F8911E820E for ; Tue, 15 Oct 2013 13:42:21 -0700 (PDT)
Received: by mail-ie0-f179.google.com with SMTP id aq17so14698499iec.10 for ; Tue, 15 Oct 2013 13:42:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=0g54/CpLWoOcqv3nZ/nI8dzci3FJ3OAWOSoUVtQnBYc=; b=eocBP2IJ38iwQAL8cwaiXxxjvJpBy9l+FjcZfTO5MUUC8RhYbNXLrCT/1VZ69KdSH9 1wLTAYMcFwMMTZD0aOz9vQ7dwNxeXZDX2s6gvsgnG2N/8kmZqR/yIl0GSskZfubHILVv PFdnk+sx0IVqo7Y2Z6juHBY2sbbM+K/zXj61bJ+7q1yA1qD32k6Y5FBPVmkN5edwgcTo ko/tQFxJefI3Id1VVRuDX7pibUVbbJm5SKwvZDuAbGigbMI91ON7w3MtVgjLB472yrxq xBEINnZSet/R4LRs3G51aIIdlD1P0kejh0SQ1KhDK/JxDMmu10aw50H0GbID4FVzgxyN vUHQ==
X-Received: by 10.50.61.35 with SMTP id m3mr16609079igr.56.1381869740549; Tue, 15 Oct 2013 13:42:20 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.50.96.135 with HTTP; Tue, 15 Oct 2013 13:42:00 -0700 (PDT)
In-Reply-To: 
References:  
From: Ira McDonald 
Date: Tue, 15 Oct 2013 16:42:00 -0400
Message-ID: 
To: Brad Schoening 
Content-Type: multipart/alternative; boundary=001a1134b62c02f1d504e8cd9f4f
Cc: "eman@ietf.org" 
Subject: Re: [eman] draft-ietf-eman-applicability-statement-03
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, 15 Oct 2013 20:42:24 -0000

--001a1134b62c02f1d504e8cd9f4f
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Hi Brad,

Ah - I see (I think) - I was thinking about the implementation guidelines
(for MIBs or
other bindings of the EMAN Model).

I agree that Applicability for the external standards and EMAN use cases
seems
to be an obscure use of the word Applicability.

I'd prefer a different title, such as "EMAN Framework Standards Context".

And a second "EMAN MIBs Implementation Guide" document.

Does that make sense?

Cheers,
- Ira



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



On Tue, Oct 15, 2013 at 3:24 PM, Brad Schoening  wrote:

>   Ira,
>
>  The root of the issue is that the "Applicability Statement" begin as a
> companion documents to the EMAN Framework addressing the applicability of
> other standards and information models w.r.t. the EMAN framework.   Since
> then, use cases have also been added to the Applicability Statement
> document.
>
>  Use of the name 'Applicability' has lead to confusion that this document
> will also provide implementation guidelines and best practices. While suc=
h
> a document would be valuable, its not clear how it relates to abstract us=
e
> cases and international and national standards bodies.
>
>  The Abstract of the Applicability statement claims:
>
>  	Abstract
>
>         The objective of Energy Management (EMAN)is to provide an energy
>         management framework for networked devices. This document
>         presents the applicability of the EMAN framework for a variety
>         of scenarios. This document lists use cases and target devices
>         that can potentially implement the EMAN framework and associated
>         SNMP MIB modules. These use cases are useful for identifying
>         monitoring requirements that need to be considered. Further, we
>         describe the relationship of the EMAN framework to relevant
>
> other energy monitoring standards and architectures.
>
>  So, it might be more useful to think of this as the EMAN Framework
> Applicability Statement vs. an EMAN MIB Applicability/Implementation Guid=
e.
>
>  Regards,
>
>  Brad
>
>  *Brad Schoening*
> Engineering | Coraid
> Tel: +1 917 304 7190
> brads@coraid.com | www.coraid.com
>  *Coraid: Redefining Storage*
>
>
>   From: Ira McDonald 
> Date: Tue, 15 Oct 2013 10:02:59 -0400
> To: "Mouli Chandramouli (moulchan)" , Ira McDonald <
> blueroofmusic@gmail.com>
> Cc: "eman@ietf.org" 
> Subject: Re: [eman] draft-ietf-eman-applicability-statement-03
>
>    Hi Mouli,
>
>  I prefer a single Applicability Statement - simpler for implementors and
>  avoids inconsistencies between two documents.
>
>  Cheers,
>  - Ira
>
>
> Ira McDonald (Musician / Software Architect)
> Chair - Linux Foundation Open Printing WG
> Secretary - IEEE-ISTO Printer Working Group
> Co-Chair - IEEE-ISTO PWG IPP WG
> Co-Chair - TCG Trusted Mobility Solutions WG
> Chair - TCG Embedded Systems Hardcopy SG
> IETF Designated Expert - IPP & Printer MIB
> Blue Roof Music/High North Inc
> http://sites.google.com/site/blueroofmusic
> http://sites.google.com/site/highnorthinc
> mailto:blueroofmusic@gmail.com
> Winter  579 Park Place  Saline, MI  48176  734-944-0094
> Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434
>
>
>
> On Tue, Oct 15, 2013 at 9:48 AM, Mouli Chandramouli (moulchan) <
> moulchan@cisco.com> wrote:
>
>>  Hello all,
>>
>>  We are working on updating the  draft Applicability Statement draft
>> before this IETF meeting.
>>
>>  We would like to get the input of the WG on a coupe of important
>> points.
>>
>>  Currently, the EMAN Applicability Statement draft as it stands
>>  contains =96 use cases and relation standards;  and does not have a
>> discussion of how the technologies developed in EMAN WG =96 EMAN Framewo=
rk,
>> MIB modules can be implemented.
>>
>>  Should this draft be split in to two drafts  -  (1) use cases and
>> related standards  (2)  Applicability of EMAN Framework
>>
>>  or  a consolidated Applicability statement draft which contains a
>> section of how the Framework can be applied.
>>
>>  Please provide your thoughts.
>>
>>  Thanks
>>  Mouli
>>
>>
>>
>> _______________________________________________
>> eman mailing list
>> eman@ietf.org
>> https://www.ietf.org/mailman/listinfo/eman
>>
>>
>  _______________________________________________ eman mailing list
> eman@ietf.orghttps://www.ietf.org/mailman/listinfo/eman
>

--001a1134b62c02f1d504e8cd9f4f
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable


Hi Brad,

Ah - I see =
(I think) - I was thinking about the implementation guidelines (for MIBs or=

other bindings of the EMAN Model).

I agree that Appl=
icability for the external standards and EMAN use cases seems



to be an obscure use of the word Applicability.=A0 

I'd pr=
efer a different title, such as "EMAN Framework Standards Context"=
;.

And a second "EMAN MIBs Implementation Guide"=
; document.



Does that make sense?

Cheers,
- Ira



Ira McDonald (Musician / Software Architect)
Chair - Li=
nux Foundation Open Printing WG


Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG IPP=
 WG
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - TCG Embedded=
 Systems Hardcopy SG
IETF Designated Expert - IPP & Printer MIB


Blue Roof Music/High North Inc
http://sites=
.google.com/site/blueroofmusic
http://si=
tes.google.com/site/highnorthinc


mailto:blueroo=
fmusic@gmail.com
Winter=A0 579 Park Place=A0 Saline, MI=A0 48176=A0 =
734-944-0094
Summer=A0 PO Box 221=A0 Grand Marais, MI 49839=A0 906-494-2=
434







On Tue, Oct 15, 2013 at 3:24 PM, Brad Sc=
hoening <brads@coraid.com> wrote:













Ira,







The root of the issue is that the "Applicability Statement" =
begin as a companion documents to the EMAN Framework addressing the applica=
bility of other standards and information models w.r.t. the EMAN framework.=
 =A0 Since then, use cases have also been added
 to the Applicability Statement document.







Use of the name 'Applicability' has lead to confusion that thi=
s document will also provide implementation guidelines and best practices. =
While such a document would be valuable, its not clear how it relates to ab=
stract use cases and international and national
 standards bodies.







The Abstract of the Applicability statement claims:








	Abstract

        The objective of Energy Management (EMAN)is to provide an energy
        management framework for networked devices. This document
        presents the applicability of the EMAN framework for a variety
        of scenarios. This document lists use cases and target devices
        that can potentially implement the EMAN framework and associated
        SNMP MIB modules. These use cases are useful for identifying
        monitoring requirements that need to be considered. Further, we
        describe the relationship of the EMAN framework to relevant=A0

other energ=
y monitoring standards and architectures.







So, it might be more useful to think of this as the EMAN Framework App=
licability Statement vs. an EMAN MIB Applicability/Implementation Guide.






Regards,







Brad


=A0





Brad
 Schoening

Engineering | Coraid

Tel: +1 917 304 7190

brads@coraid.com =
| 
www.coraid.com




Coraid: Redefining Storage


































Hi Mouli,





I prefer a single Applicability Statement - simpler for implementors and


avoids inconsistencies between two documents.





Cheers,



- Ira









Ira McDonald (Musician / Software Architect)

Chair - Linux Foundation Open Printing WG

Secretary - IEEE-ISTO Printer Working Group

Co-Chair - IEEE-ISTO PWG IPP WG

Co-Chair - TCG Trusted Mobility Solutions WG

Chair - TCG Embedded Systems Hardcopy SG

IETF Designated Expert - IPP & Printer MIB

Blue Roof Music/High North Inc

http://sites.google.com/site/blueroofmusic=


http://sites.google.com/site/highnorthinc
mailto:blueroo=
fmusic@gmail.com

Winter=A0 579 Park Place=A0 Saline, MI=A0 48176=A0 734-944-0094

Summer=A0 PO Box 221=A0 Grand Marais, MI 49839=A0 906-494-2434
























On Tue, Oct 15, 2013 at 9:48 AM, Mouli Chandramo=
uli (moulchan)
<moulchan@cisco.com> wrote:






Hello all,







We are working on updating the =A0draft Applicability Statement draft =
before this IETF meeting.=A0







We would like to get the input of the WG on a coupe of important point=
s.=A0







Currently, the EMAN Applicability Statement draft as it stands =A0cont=
ains =96 use cases and relation standards; =A0and does not have a discussio=
n of how the technologies developed in EMAN WG =96 EMAN Framework, MIB modu=
les can be implemented. =A0









Should this draft be split in to two drafts =A0- =A0(1) use cases and =
related standards =A0(2) =A0Applicability of EMAN Framework =A0=A0







or =A0a consolidated Applicability statement draft which contains a se=
ction of how the Framework can be applied.=A0







Please provide your thoughts.=A0







Thanks



Mouli















_______________________________________________

eman mailing list

eman@ietf.org

ht=
tps://www.ietf.org/mailman/listinfo/eman











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







--001a1134b62c02f1d504e8cd9f4f--

From n.brownlee@auckland.ac.nz  Thu Oct 17 18:49:32 2013
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 5532B11E81A3 for ; Thu, 17 Oct 2013 18:49:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ug1ORX8skQjS for ; Thu, 17 Oct 2013 18:49:28 -0700 (PDT)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id 2DBD411E8202 for ; Thu, 17 Oct 2013 18:49:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1382060963; x=1413596963; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=3bWPgoaeMr+0tLopDi7lz12VkAWNeNCuJYps1R9Sd10=; b=egiD0kMCWqlwsae1oHt6I/AjLtUOC0WS52H4IUv3YOAq3tcnSMQvNQlf NNOmMeCuv7nOo5o5OibW+oL6g1Df+ly75bAwB2oGwsbu7MfuXipDu3v7g n/n4PQvD6v0d5puT/o74hGqFrf16CDqK2hqJL575lREmhGaYETlRrbHAm U=;
X-IronPort-AV: E=Sophos;i="4.93,519,1378814400"; d="scan'208";a="218153332"
X-Ironport-HAT: UNIVERSITY - $RELAY-THROTTLE
X-Ironport-Source: 130.216.38.131 - Outgoing - Outgoing-SSL
Received: from nevil-laptop1.sfac.auckland.ac.nz (HELO [130.216.38.131]) ([130.216.38.131]) by mx2-int.auckland.ac.nz with ESMTP; 18 Oct 2013 14:49:22 +1300
Message-ID: <526093A2.9030809@auckland.ac.nz>
Date: Fri, 18 Oct 2013 14:49:22 +1300
From: Nevil Brownlee 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: "eman@ietf.org" 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [eman] Agenda for IETF 88, Vancouver (first 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: Fri, 18 Oct 2013 01:49:32 -0000

Hi all:

Here's the first draft of our agenda.

Please send me any changes/improvements/etc.

If you have drafts you would like to present, let me know
about those too.

Cheers, Nevil


==================================================
Energy Management WG (eman)
Agenda for IETF 88, Vancouver  (agenda-00)
Tuesday, 5 November 2013, 1610-1840, Plaza A
==================================================

Chairs:
Nevil Brownlee  
Thomas Nadeau   

AGENDA:

1. Note Well, Agenda review, Scribes                        =  5 min

2. Update from last meeting / WG Status (Nevil)             = 10 min
      EMAN Requirements
        Published as RFC 6988
      WG LC for EMAN Framework -09, 11-27 September
        Brought lots of feedback

3. Current charter work items                               = 60 min
    a) Energy Management Framework (John Parello)
         draft-ietf-eman-framework-10, 23 Sep 13
           Many changes in response to WGLC reviews

    b) Energy-aware Networks and Devices MIB (Mouli Chandramouli)
         draft-ietf-eman-energy-aware-mib-09, 12 Jul 13

    c) Power and Energy Monitoring MIB (Mouli Chandramouli or Benoit Claise)
         draft-ietf-eman-energy-monitoring-mib-06, 15 Jul 13

    d) Definition of Managed Objects for Battery Monitoring (Juergen 
Quittek)
         draft-ietf-eman-battery-mib-09, 15 Jul 13

    e) Energy Management (EMAN) Applicability Statement (John Parello)
         draft-ietf-eman-applicability-statement-03, 18 Apr 13

5. Other drafts (if time permits)                           =

6. Milestones update                                        =

7. Any Other Business                                       =

Presentation slides will be available at
   https://datatracker.ietf.org/meeting/88/materials.html
   (search for EMAN in the Operations and Management Area)

Participation via jabber is offered at ipfix@jabber.ietf.org,
   and also via meetecho

-- 
---------------------------------------------------------------------
  Nevil Brownlee                          Computer Science Department
  Phone: +64 9 373 7599 x88941             The University of Auckland
  FAX: +64 9 373 7453   Private Bag 92019, Auckland 1142, New Zealand

From bclaise@cisco.com  Fri Oct 18 01:41:24 2013
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 576C121F9B08 for ; Fri, 18 Oct 2013 01:41:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.399
X-Spam-Level: 
X-Spam-Status: No, score=-10.399 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_BAYES_6x6=0.4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SfmOuGVw4TkR for ; Fri, 18 Oct 2013 01:41:19 -0700 (PDT)
Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 2A50021F9FE7 for ; Fri, 18 Oct 2013 01:41:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20241; q=dns/txt; s=iport; t=1382085678; x=1383295278; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=19zrEIpMhnRK8U929vJB+EgAgXHPAos/ykv4fr9I+UU=; b=SXY8evQCY/aIYX5ND+r44TheAEucXAvz5ToJLGVKK0ZNiomw/HJzCvdS +qLbGlStx/k1/sTlV387IV8Z7o56KrfNuMsP0YZwm0B093bGV5OX7dFN9 5Foykfl9LWVy6/eooQwzpR/jyHr1aNyOEjg0tevlR7MJwvGJ0esaDIdkN M=;
X-IronPort-AV: E=Sophos;i="4.93,520,1378857600"; d="scan'208,217";a="92418575"
Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 18 Oct 2013 08:41:18 +0000
Received: from [10.60.67.88] (ams-bclaise-8917.cisco.com [10.60.67.88]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r9I8fFKs008146; Fri, 18 Oct 2013 08:41:15 GMT
Message-ID: <5260F42B.9030704@cisco.com>
Date: Fri, 18 Oct 2013 10:41:15 +0200
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: "John Parello (jparello)" 
References: <9C213D38848B89428F46808B16F6F08601667938@xmb-aln-x04.cisco.com>
In-Reply-To: <9C213D38848B89428F46808B16F6F08601667938@xmb-aln-x04.cisco.com>
Content-Type: multipart/alternative; boundary="------------090103000804040707010706"
Cc: "eman@ietf.org" 
Subject: Re: [eman] Bclaise - draft-ietf-eman-framework-10: WGLC comments
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Oct 2013 08:41:24 -0000

This is a multi-part message in MIME format.
--------------090103000804040707010706
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Thanks John.

Regards, Benoit
> Thanks Benoit for the detailed review. I've applied the majority of 
> your comments which will appear in -11
> See inline:
> (+) Applied in the draft
> (-) Regretfully not applied for the reasons listed
> (!) Not applied needing more clarification and/or see further comment 
> or thread
>
> I deleted the draft txt form your email for better reading....
>
>
>
> Abstract:
>
>     On the top of Jürgen's feedback on the abstract, I'm wondering: 
> What is a "physical" reference model?
>
> 1. Introduction
>
>     power state -> Power State.
>     Some more instances: be consistent in terms of capitalization in 
> the introduction.
>
>     We need to introduce that there are different relationship types, 
> to solve the different problems.
>
> + JP : Done
>
> 2. Terminology
>
>     The final agreement on [EMAN-REQ] was 
> http://www.rfc-editor.org/authors/rfc6988.txt The terms specified in 
> the terminology section are capitalized throughout the document; the 
> exceptions are the well-known terms "energy" and "power". These terms 
> are generic and are used in generated terms such as "energy-saving", 
> "low-power", etc.I suggest you do the same.
>
>     I searched for a specific term in the terminology section, and 
> realized that the order is not alphabetical. A sentence such as: "The 
> terms in the terminology section are not classified alphabetically, 
> but the order has been chosen to improve the document readiness, with 
> terms building on the top of each others"
>
>     Please change the "$" sign for all entries in the terminology section.
>
> + JP : Done
>
>     Are Power Inlets and Power Oulets Power Interfaces? If yes, the 
> definitions should be changed accordingly
>
> + JP : Scrubbed. outlets/inlets are the physical and Power Interfaces 
> are the abstraction / model.
>
>     Nameplate Power  s/a device/an Electrical Device?
>
> ! JP : this definition highly reviewed and we have no definition of an 
> Electrical Device. Basic grammar would be to use Electric Device but 
> no need to go there at all. Just device.
>
>
>
> 3. Concerns...
>
>     Again "physical" reference model.
>
> + JP : thanks this was scrubbed in the entire document so can't list a 
> specific line but please review as this should meet what you want
>
> 3.1 Target Devices
>
>            I'm confused by the Device definition in the terminology, 
> which is NOT used in this text, while "device" (paragraph above) and 
> "target device" are used
>
> + JP : Revised definition use and this section.
>
> 3.2 Physical Reference Model
>
>              Permutation of topologies or permutations of elements, 
> which in turn, create different topologies?
> I believe you meant the latter.
>
> + JP : changed
> """
> While many more topologies can be created with combination of devices, 
> the following are some basic ones that show how Energy Management 
> topologies differ from Network Management topologies.
> """
>
>
>         energy management system -> Energy Management System Pay 
> attention to the terms capitalization in the figures as well. Here, we 
> speak about device -> Device, monitoring -> Energy Monitoring control 
> -> Energy Control You removed the fact that ######## is energy. Device 
> versus device versus target device? I'm wondering if we should not add 
> the Power Interfaces in the figures.
>
> + JP : done didn't add PI can add if we agree as a group this is needed.
>
> 3.4 Concerns not addressed
>
>       One line of intro please: "concerns not addressed" is vague  
> Which concerns? Is "concerns" the right term? Should we have some 
> concerns that some concerns are not addressed? :-) Not addressed by 
> this framework, I guess. What you want to say is "out of scope of this 
> framework", right?
>
> + JP : Done
>
>       Non-Electrical equipments that do not convert-to or present-as 
> equivalent to Electrical Equipments are not addressed.
>
> ! JP : Combined yours with  JQ text
> """
> The primary focus of this framework is the management of Electrical 
> Equipment. Non-Electrical Equipment can be covered by the framework by 
> providing interfaces that comply with the framework. For example, 
> using the same units for power and energy. Therefore, Non-Electrical 
> Equipment that do not convert-to or present-as equivalent to 
> Electrical Equipment are not addressed.
> """
>
> 4.1 Conceptual Model
>
>           1st Para: No need.
>
>       2nd Para: interconnections = relationships We introduced the 
> notion of relationships already Proposal:
> ""
> describe a means to report information, provide control, and model the 
> relationships among physical entities (equipment).
> Here, it's physical entities (equipment).
> ""
>     We had already device, Device, target device, Electrical Object
>     Be consistent.
>
> + JP : 1P edited from other comments. 2P changed to
> """
> An information model for Energy Management will need to describe a 
> means to monitor and control devices and components. The model will 
> also need to describe the relationships among and connections between 
> devices and components.
> ""
>
>     3rd Para:
> I finally get it, I think. You really want to Energy Object to be an 
> (instance of the) Device, Component, or Power Interface class in the 
> information model. The readers start with the terminology and since 
> they don't know you will need an information model, they're puzzled by 
> the Energy Object definition. Proposal: whenever you mean the 
> information model class, just mention
>     Device Class
>     Component Class
>     etc.
> As you did with the subtitles below.
> And no need to define Energy Object in the terminology section. If you 
> really want, insert the definition in this information model section 
> here, along with the Device Class definition. Same thing for component.
> Btw, the Energy Object is not a class but an instance of the class.
>
> + JP : Ok scrubbed this as discussed.
>
> nterconnection = relationship
>  Energy Management may have no
> relation to the interconnections for Network Management the Energy
> Object
> interconnection = topology
>
> ! JP : change interconnection where redundant but had to keep it in 
> cases where we are describing a relationship. I can't describe a 
> relationship by saying it's a relation etc.
>
>
> 4.2.3 Power Interface Class
>
> The power
> interface class is a sub-class of Energy Object that represents the
> interconnection among devices and components.
> Does it?
> It represents the attach point for the relationship. I see later:
>  Power Source relationships are intended
> to identify the connections between Power Interfaces.
> The Power Interface definition should be improved.
>
> + JP : moved definition into class description and clarified definition.
>
> 4.3.2 Context in General
>
> Shouldn't this text be part of 4.3.4 [jp:keywords]?
>
> ! JP : Not sure what you mean there. Section 4.3.4 is regarding 
> keywords which is part of context and 4.3.2 is talks about context in 
> general
>
> 4.4.1 Measurements: Power
>
> In the future, avoid the future tense for future RFCs. :-)
>
> + JP : done in the present ;)
>
> 4.5 Control
>
> Power States that it implements.
> that it supports
> This is more precise.
>
> + JP : Done I think implements is clearer but ok changed to supports.
>
> 4.6.4 Guidelines: Aggregation
>
> Since an EnMS is naturally a point of aggregation it is not necessary to
> model aggregation for Energy Management Systems. Aggregation SHOULD be
> used for power and energy. It MAY be
>
> "Aggregation SHOULD be used for power and
> energy" is misleading I guess you mean: "The Aggregation
> Relationship is intended for power and energy" For the rest below.
> Section 6 is a series of examples I'm fine with section 7, 8, and 9
> (IANA, which I wrote) Regards, Benoit
>
> + JP : Done
>
> Thanks!!
>
> Jp
>
>
>
>
>
>


--------------090103000804040707010706
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    
Thanks John.

      

      Regards, Benoit

    

    

      
      
      
Thanks Benoit for the detailed review.
        I've applied the majority of your comments which will appear in
        -11

        See inline:

        (+) Applied in the draft

        (-) Regretfully not applied for the reasons listed

        (!) Not applied needing more clarification and/or see further
        comment or thread

        

        I deleted the draft txt form your email for better reading....

        

        

        

        Abstract:

        

            On the top of Jürgen's feedback on the abstract, I'm
        wondering: What is a "physical" reference model?

        

        1. Introduction

        

            power state -> Power State.

            Some more instances: be consistent in terms of
        capitalization in the introduction.

        

            We need to introduce that there are different relationship
        types, to solve the different problems.

        

        + JP : Done

        

        2. Terminology

        

            The final agreement on [EMAN-REQ] was
        http://www.rfc-editor.org/authors/rfc6988.txt The terms
        specified in the terminology section are capitalized throughout
        the document; the exceptions are the well-known terms "energy"
        and "power". These terms are generic and are used in generated
        terms such as "energy-saving", "low-power", etc.I suggest you do
        the same.

        

            I searched for a specific term in the terminology section,
        and realized that the order is not alphabetical. A sentence such
        as: "The terms in the terminology section are not classified
        alphabetically, but the order has been chosen to improve the
        document readiness, with terms building on the top of each
        others"

        

            Please change the "$" sign for all entries in the
        terminology section.

        

        + JP : Done

        

            Are Power Inlets and Power Oulets Power Interfaces? If yes,
        the definitions should be changed accordingly

        

        + JP : Scrubbed. outlets/inlets are the physical and Power
        Interfaces are the abstraction / model.

                

            Nameplate Power  s/a device/an Electrical Device?

        

        ! JP : this definition highly reviewed and we have no definition
        of an Electrical Device. Basic grammar would be to use Electric
        Device but no need to go there at all. Just device.

        

        

        

        3. Concerns...

        

            Again "physical" reference model.

        

        + JP : thanks this was scrubbed in the entire document so can't
        list a specific line but please review as this should meet what
        you want

        

        3.1 Target Devices

        

                   I'm confused by the Device definition in the
        terminology, which is NOT used in this text, while "device"
        (paragraph above) and "target device" are used

        

        + JP : Revised definition use and this section.

        

        3.2 Physical Reference Model

        

                     Permutation of topologies or permutations of
        elements, which in turn, create different topologies?

        I believe you meant the latter.

        

        + JP : changed

        """

        While many more topologies can be created with combination of
        devices, the following are some basic ones that show how Energy
        Management topologies differ from Network Management topologies.

        """

        

        

                energy management system -> Energy Management System
        Pay attention to the terms capitalization in the figures as
        well. Here, we speak about device -> Device, monitoring ->
        Energy Monitoring control -> Energy Control You removed the
        fact that ######## is energy. Device versus device versus target
        device? I'm wondering if we should not add the Power Interfaces
        in the figures.

        

        + JP : done didn't add PI can add if we agree as a group this is
        needed.  

        

        3.4 Concerns not addressed

        

              One line of intro please: "concerns not addressed" is
        vague  Which concerns? Is "concerns" the right term? Should we
        have some concerns that some concerns are not addressed? :-) Not
        addressed by this framework, I guess. What you want to say is
        "out of scope of this framework", right?

        

        + JP : Done

        

              Non-Electrical equipments that do not convert-to or
        present-as equivalent to Electrical Equipments are not
        addressed.

        

        ! JP : Combined yours with  JQ text

        """

        The primary focus of this framework is the management of
        Electrical Equipment. Non-Electrical Equipment can be covered by
        the framework by providing interfaces that comply with the
        framework. For example, using the same units for power and
        energy. Therefore, Non-Electrical Equipment that do not
        convert-to or present-as equivalent to Electrical Equipment are
        not addressed.

        """

        

        4.1 Conceptual Model

        

                  1st Para: No need. 

        

              2nd Para: interconnections = relationships We introduced
        the notion of relationships already Proposal:

        ""

        describe a means to report information, provide control, and
        model the relationships among physical entities (equipment).

        Here, it's physical entities (equipment).

        ""

            We had already device, Device, target device, Electrical
        Object

            Be consistent.

        

        + JP : 1P edited from other comments. 2P changed to

        """

        An information model for Energy Management will need to describe
        a means to monitor and control devices and components. The model
        will also need to describe the relationships among and
        connections between devices and components.

        ""

        

            3rd Para: 

        I finally get it, I think. You really want to Energy Object to
        be an (instance of the) Device, Component, or Power Interface
        class in the information model. The readers start with the
        terminology and since they don't know you will need an
        information model, they're puzzled by the Energy Object
        definition. Proposal: whenever you mean the information model
        class, just mention

            Device Class

            Component Class

            etc.

        As you did with the subtitles below.

        And no need to define Energy Object in the terminology section.
        If you really want, insert the definition in this information
        model section here, along with the Device Class definition. Same
        thing for component.

        Btw, the Energy Object is not a class but an instance of the
        class.

        

        + JP : Ok scrubbed this as discussed.

        

        nterconnection = relationship

         Energy Management may have no

        relation to the interconnections for Network Management the
        Energy

        Object

        interconnection = topology

        

        ! JP : change interconnection where redundant but had to keep it
        in cases where we are describing a relationship. I can't
        describe a relationship by saying it's a relation etc.

        

            

        4.2.3 Power Interface Class

        

        The power

        interface class is a sub-class of Energy Object that represents
        the

        interconnection among devices and components.

        Does it?

        It represents the attach point for the relationship. I see
        later:

         Power Source relationships are intended

        to identify the connections between Power Interfaces. 

        The Power Interface definition should be improved.

        

        + JP : moved definition into class description and clarified
        definition.

        

        4.3.2 Context in General

        

        Shouldn't this text be part of 4.3.4 [jp:keywords]?

        

        ! JP : Not sure what you mean there. Section 4.3.4 is regarding
        keywords which is part of context and 4.3.2 is talks about
        context in general

        

        4.4.1 Measurements: Power

        

        In the future, avoid the future tense for future RFCs. :-)

        

        + JP : done in the present ;)

        

        4.5 Control

        

        Power States that it implements. 

        that it supports 

        This is more precise.

        

        + JP : Done I think implements is clearer but ok changed to
        supports.

        

        4.6.4 Guidelines: Aggregation

        

        Since an EnMS is naturally a point of aggregation it is not
        necessary to

        model aggregation for Energy Management Systems. Aggregation
        SHOULD be

        used for power and energy. It MAY be

        

        "Aggregation SHOULD be used for power and

        energy" is misleading I guess you mean: "The Aggregation

        Relationship is intended for power and energy" For the rest
        below.

        Section 6 is a series of examples I'm fine with section 7, 8,
        and 9

        (IANA, which I wrote) Regards, Benoit 

        

        + JP : Done

        

        Thanks!!

        

        Jp

        

        

        

        

        

        

      

    

    

  


--------------090103000804040707010706--

From internet-drafts@ietf.org  Fri Oct 18 06:34:17 2013
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 E4D0611E8112; Fri, 18 Oct 2013 06:34:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Level: 
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L6iNCg8tj4zQ; Fri, 18 Oct 2013 06:34:17 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E45111E8203; Fri, 18 Oct 2013 06:34:17 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.80.p3
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20131018133417.4150.91987.idtracker@ietfa.amsl.com>
Date: Fri, 18 Oct 2013 06:34:17 -0700
Cc: eman@ietf.org
Subject: [eman] I-D Action: draft-ietf-eman-applicability-statement-04.txt
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Oct 2013 13:34:18 -0000

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

	Title           : Energy Management (EMAN) Applicability Statement
	Author(s)       : Brad Schoening
                          Mouli Chandramouli
                          Bruce Nordman
	Filename        : draft-ietf-eman-applicability-statement-04.txt
	Pages           : 30
	Date            : 2013-10-18

Abstract:
        The objective of Energy Management (EMAN) is to provide an
        energy management framework for networked devices.  This
        document presents the applicability of the EMAN framework to a
        variety of scenarios.  This document lists use cases and target
        devices that can potentially implement the EMAN framework and
        associated SNMP MIB modules.  These use cases are useful for
        identifying requirements for the framework and MIBs.  Further,
        we describe the relationship of the EMAN framework to relevant
        other energy monitoring standards and architectures.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-eman-applicability-statement

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-eman-applicability-statement-04

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-eman-applicability-statement-=
04


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

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


From moulchan@cisco.com  Fri Oct 18 06:39:30 2013
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 553D411E820A for ; Fri, 18 Oct 2013 06:39:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level: 
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jF7Wog9gMO-L for ; Fri, 18 Oct 2013 06:39:25 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 5BA7F11E8203 for ; Fri, 18 Oct 2013 06:39:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8136; q=dns/txt; s=iport; t=1382103565; x=1383313165; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=oK/hcOahViPEJSynLrnWHhvEW5BEtJInKIn9MddOyAc=; b=dKOHfrrdkDFilsXcRNF7P+HD/vWIlPeyzB5igNpZ8DH+XcItgXkgmLzI RFUPIiVx/L18T7D73T4wmnMRbbtXcLOoI82rn3/1zt+m2I95PNZuCGgHw uVHAnDpCiHgDF47jZhMGLpRuVzSkMkj/vevkhGgY1bOxVkzfFWa6TzWc6 w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvMGAB05YVKtJV2Z/2dsb2JhbABagkNEOEwGhEexDIhNgSQWbQeCJwEEAQEBawQZAQgiHS4LFBECBBMIAYd9BwWfLqFAjyUtC4MfgQoDmTiQWIMkgik
X-IronPort-AV: E=Sophos;i="4.93,522,1378857600";  d="scan'208,217";a="273717591"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-2.cisco.com with ESMTP; 18 Oct 2013 13:39:24 +0000
Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r9IDdOsX016491 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 18 Oct 2013 13:39:24 GMT
Received: from xmb-rcd-x08.cisco.com ([169.254.8.94]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.004; Fri, 18 Oct 2013 08:39:24 -0500
From: "Mouli Chandramouli (moulchan)" 
To: "eman@ietf.org" 
Thread-Topic: [eman] I-D Action: draft-ietf-eman-applicability-statement-04.txt
Thread-Index: AQHOzAbBYXYvmSIMUUWa7pGkLuIdl5n7Jt8A
Date: Fri, 18 Oct 2013 13:39:24 +0000
Message-ID: <852AF0ED49D9F24BBBFA1B4DEEBE3BA42ADBF4E8@xmb-rcd-x08.cisco.com>
In-Reply-To: <20131018133417.4150.91987.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.8.130913
x-originating-ip: [10.142.100.80]
Content-Type: multipart/alternative; boundary="_000_852AF0ED49D9F24BBBFA1B4DEEBE3BA42ADBF4E8xmbrcdx08ciscoc_"
MIME-Version: 1.0
Subject: Re: [eman] I-D Action: draft-ietf-eman-applicability-statement-04.txt
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Oct 2013 13:39:30 -0000

--_000_852AF0ED49D9F24BBBFA1B4DEEBE3BA42ADBF4E8xmbrcdx08ciscoc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Hello all,

Since the Applicability statement draft shall expire soon, an updated versi=
on has been submitted.

With respect to the applicability statement draft , this contains use cases=
 and related standards section, which have been presented and reviewed at a=
 few IETF meetings.

Upon the Framework draft and the MIB modules are baselined,  a Section on t=
he applicability of the EMAN Framework to the use cases listed and implemen=
tation guidance shall be included.

Thanks
Mouli


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

Title           : Energy Management (EMAN) Applicability Statement
Author(s)       : Brad Schoening
                          Mouli Chandramouli
                          Bruce Nordman
Filename        : draft-ietf-eman-applicability-statement-04.txt
Pages           : 30
Date            : 2013-10-18

Abstract:
        The objective of Energy Management (EMAN) is to provide an
        energy management framework for networked devices.  This
        document presents the applicability of the EMAN framework to a
        variety of scenarios.  This document lists use cases and target
        devices that can potentially implement the EMAN framework and
        associated SNMP MIB modules.  These use cases are useful for
        identifying requirements for the framework and MIBs.  Further,
        we describe the relationship of the EMAN framework to relevant
        other energy monitoring standards and architectures.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-eman-applicability-statement

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-eman-applicability-statement-04

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-eman-applicability-statement-=
04


Please note that it may take a couple of minutes from the time of submissio=
n
until the htmlized version and diff are available at tools.ietf.org.

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

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


--_000_852AF0ED49D9F24BBBFA1B4DEEBE3BA42ADBF4E8xmbrcdx08ciscoc_
Content-Type: text/html; charset="us-ascii"
Content-ID: <6E4DA664AFEFAE4AA8241BAABC87B312@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable












Hello all,







Since the Applicability statement draft shall expire soon, an updated =
version has been submitted. 







With respect to the applicability statement draft , this contains use =
cases and related standards section, which have been presented and reviewed=
 at a few IETF meetings. 







Upon the Framework draft and the MIB modules are baselined,  a Se=
ction on the applicability of the EMAN Framework to the use cases listed an=
d implementation guidance shall be included. 







Thanks


Mouli

















A New Internet-Draft is available from the on-line Internet-Drafts dir=
ectories.


This draft is a work item of the Energy Management Working Group of th=
e IETF.







Title&=
nbsp;          : Energy Manage=
ment (EMAN) Applicability Statement


Author=
(s)       : Brad Schoening


           &nbs=
p;            &=
nbsp; Mouli Chandramouli


           &nbs=
p;            &=
nbsp; Bruce Nordman


Filena=
me        : draft-ietf-eman-applica=
bility-statement-04.txt


Pages&=
nbsp;          : 30


Date&n=
bsp;           : 201=
3-10-18







Abstract:


        The objective of Energ=
y Management (EMAN) is to provide an


        energy management fram=
ework for networked devices.  This


        document presents the =
applicability of the EMAN framework to a


        variety of scenarios.&=
nbsp; This document lists use cases and target


        devices that can poten=
tially implement the EMAN framework and


        associated SNMP MIB mo=
dules.  These use cases are useful for


        identifying requiremen=
ts for the framework and MIBs.  Further,


        we describe the relati=
onship of the EMAN framework to relevant


        other energy monitorin=
g standards and architectures.

















The IETF datatracker status page for this draft is:








There's also a htmlized version available at:








A diff from the previous version is available at:













Please note that it may take a couple of minutes from the time of subm=
ission


until the htmlized version and diff are available at tools.ietf.org.






Internet-Drafts are also available by anonymous FTP at:








_______________________________________________


eman mailing list
















--_000_852AF0ED49D9F24BBBFA1B4DEEBE3BA42ADBF4E8xmbrcdx08ciscoc_--

From internet-drafts@ietf.org  Fri Oct 18 15:27:32 2013
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 1CE9011E80E6; Fri, 18 Oct 2013 15:27:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.555
X-Spam-Level: 
X-Spam-Status: No, score=-102.555 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qr+cVsT8oWJr; Fri, 18 Oct 2013 15:27:31 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C2F511E80D9; Fri, 18 Oct 2013 15:27:31 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.80.p3
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20131018222731.23192.16493.idtracker@ietfa.amsl.com>
Date: Fri, 18 Oct 2013 15:27:31 -0700
Cc: eman@ietf.org
Subject: [eman] I-D Action: draft-ietf-eman-framework-11.txt
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Oct 2013 22:27:32 -0000

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

	Title           : Energy Management Framework
	Author(s)       : John Parello
                          Benoit Claise
                          Brad Schoening
                          Juergen Quittek
	Filename        : draft-ietf-eman-framework-11.txt
	Pages           : 47
	Date            : 2013-10-18

Abstract:
        This document defines a framework for Energy Management for
        devices and device components within or connected to
        communication networks.  The framework presents a physical
        reference model and information model. The information
        model consists of an Energy Management Domain as a set of
        Energy Objects. Each Energy Object can be attributed with
        identity, classification, and context.  Energy Objects can
        be monitored and controlled with respect to power, Power
        State, energy, demand, Power Attributes, and battery.
        Additionally the framework models relationships and
        capabilities between Energy Objects.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-eman-framework

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-eman-framework-11

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-eman-framework-11


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

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


From jparello@cisco.com  Fri Oct 18 15:34:07 2013
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 D52DA21F994A for ; Fri, 18 Oct 2013 15:34:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.299
X-Spam-Level: 
X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_92=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BCzef0vJoAX6 for ; Fri, 18 Oct 2013 15:34:02 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id E061821F9A37 for ; Fri, 18 Oct 2013 15:33:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2511; q=dns/txt; s=iport; t=1382135640; x=1383345240; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=EOfx3gVNWbu5pzTeBql/EKfZWyMFcTEkPqqf5QvJZnE=; b=S5ri2rM0ngkKf/PDhBhodYASR2QSIPMZw1k3MAE/dx4+4GNMGnDMJxqE c9OAhpS0zB/nZLdSgqx0nM488rwSVpwYZP9V4X5/oba6QZ5csS8UkJ3Cm nPGcWRvKdu48mseb2KLAP9tx2m8pyLVWO/VsAxsvL90YOCZ2hAdKj4Q1y U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av4FAP61YVKtJV2b/2dsb2JhbABRCYMHOEwGviiBJRZtB4IlAQEBBAEBATc0BBMEAgEIEQQBAQsUCQcnCxQJCAIEEwgBh3wBBwXAd44HDQqBBw8pBoMZgQoDmTiQWIMkgik
X-IronPort-AV: E=Sophos;i="4.93,525,1378857600"; d="scan'208";a="274059785"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-4.cisco.com with ESMTP; 18 Oct 2013 22:33:59 +0000
Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r9IMXxKN010178 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 18 Oct 2013 22:33:59 GMT
Received: from xmb-aln-x04.cisco.com ([169.254.9.229]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.004; Fri, 18 Oct 2013 17:33:59 -0500
From: "John Parello (jparello)" 
To: "eman@ietf.org" 
Thread-Topic: [eman] I-D Action: draft-ietf-eman-framework-11.txt
Thread-Index: AQHOzFFfSRGQJ0pz00GuP93AcYJ/UJn7Cp6Q
Date: Fri, 18 Oct 2013 22:33:58 +0000
Message-ID: <9C213D38848B89428F46808B16F6F0860166E6EF@xmb-aln-x04.cisco.com>
References: <20131018222731.23192.16493.idtracker@ietfa.amsl.com>
In-Reply-To: <20131018222731.23192.16493.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [171.71.223.71]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [eman] I-D Action: draft-ietf-eman-framework-11.txt
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Oct 2013 22:34:07 -0000

Thanks everyone for the detailed comments!
I've incorporated all the comment according to the previous emails.

If you have submitted comments please do read the reply then this version. =
If you are attending Vancouver(or not)  please do read this version and pro=
vide comments!

Thanks!
Jp et al.


-----Original Message-----
From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of int=
ernet-drafts@ietf.org
Sent: Friday, October 18, 2013 3:28 PM
To: i-d-announce@ietf.org
Cc: eman@ietf.org
Subject: [eman] I-D Action: draft-ietf-eman-framework-11.txt


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

	Title           : Energy Management Framework
	Author(s)       : John Parello
                          Benoit Claise
                          Brad Schoening
                          Juergen Quittek
	Filename        : draft-ietf-eman-framework-11.txt
	Pages           : 47
	Date            : 2013-10-18

Abstract:
        This document defines a framework for Energy Management for
        devices and device components within or connected to
        communication networks.  The framework presents a physical
        reference model and information model. The information
        model consists of an Energy Management Domain as a set of
        Energy Objects. Each Energy Object can be attributed with
        identity, classification, and context.  Energy Objects can
        be monitored and controlled with respect to power, Power
        State, energy, demand, Power Attributes, and battery.
        Additionally the framework models relationships and
        capabilities between Energy Objects.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-eman-framework

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-eman-framework-11

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-eman-framework-11


Please note that it may take a couple of minutes from the time of submissio=
n until the htmlized version and diff are available at tools.ietf.org.

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

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

From prao96@stanford.edu  Sun Oct 20 23:50:04 2013
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 204AD11E84DE for ; Sun, 20 Oct 2013 23:50:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.976
X-Spam-Level: 
X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o69Nq1sffh0z for ; Sun, 20 Oct 2013 23:49:52 -0700 (PDT)
Received: from smtp.stanford.edu (smtp1.Stanford.EDU [171.67.219.81]) by ietfa.amsl.com (Postfix) with ESMTP id 8630311E833B for ; Sun, 20 Oct 2013 23:49:50 -0700 (PDT)
Received: from smtp.stanford.edu (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id F242922218 for ; Sun, 20 Oct 2013 23:49:49 -0700 (PDT)
Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.stanford.edu (Postfix) with ESMTPS id 8B6E421045 for ; Sun, 20 Oct 2013 23:49:49 -0700 (PDT)
Received: by mail-wi0-f169.google.com with SMTP id cb5so4715539wib.2 for ; Sun, 20 Oct 2013 23:49:48 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=6uqbmN9XEvwmvm8toyi6q5toJHuzkTE47fk4Sp4VknQ=; b=OyEVPZZcDsDNwugjfn5bu7WBBKPK1mUqIZqB6dIIul2oRXDkFC/ZgCWxm0bPzSekEv BjuldcVK1WQhk1yd7SK7oF0CoY/U+F9KrA6pt3+IglZYm49fwgEIgpeA8kbL+OHMFWkH e/TxiceoNTaiUMZL4HxnUhSG/CXIB+Eu7keWIwfVrb3ZFuQ+5dPXluwAas4YIrJZW98M v4gXmntra2xiTIGZ/AZS3LgsWoAVtdM/53wmWThpCCwkR+DWWMylZk7rHlM6SgAj7o8N rtLYPeyeMrEarorCcGcBFLVBmgZycM+/GtafqEDD7I7oXAeDAOCpPCf8zp0iqSLvQMR9 W35g==
X-Gm-Message-State: ALoCoQlAznhn4PVif6gmri4SQu48RsywXf2jLL9SHVkkvKUS+U/Ui7dYiEw/lGlHVaoBfvwXOyuheXOmBy3SrDWCSX2MeNUf6dW0+wqwaUHX4AEaMYc0f4Mv9hlrZlYvmQ2UEizlkyDH
X-Received: by 10.194.21.131 with SMTP id v3mr296524wje.44.1382338188101; Sun, 20 Oct 2013 23:49:48 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.194.21.131 with SMTP id v3mr296521wje.44.1382338188037; Sun, 20 Oct 2013 23:49:48 -0700 (PDT)
Received: by 10.217.127.3 with HTTP; Sun, 20 Oct 2013 23:49:48 -0700 (PDT)
Date: Sun, 20 Oct 2013 23:49:48 -0700
Message-ID: 
From: Priyanka Rao 
To: eman@ietf.org
Content-Type: multipart/alternative; boundary=047d7b5d64f2a85af704e93ab04f
Subject: [eman] IETF Draft - Python Implementation
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, 21 Oct 2013 07:37:11 -0000

--047d7b5d64f2a85af704e93ab04f
Content-Type: text/plain; charset=ISO-8859-1

Hi all,

Just joined the ietf eman mailing list and wanted to introduce myself.  My
name is Priyanka and I am a sophomore studying at Stanford University.  I
am majoring in electrical engineering with a minor in computer science.

Currently, I am working on a draft for IETF that looks at the framework for
energy management systems.  It's still a work in progress but I'm
developing a python implementation that reads and parses CSV files with
SNMP data.  So far, it looks like the implementation I have fits well with
currently existing systems. I'm planning on submitting my draft later this
week and would love to hear any thoughts or feedback on other things I can
look into in my implementation.

Best,
Priyanka

--047d7b5d64f2a85af704e93ab04f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


Hi all,=A0

Just joined the ietf e=
man mailing list and wanted to introduce myself. =A0My name is Priyanka and=
 I am a sophomore studying at Stanford University. =A0I am majoring in elec=
trical engineering with a minor in computer science. =A0



Currently, I am working on a draft for IETF=
 that looks at the framework for energy management systems. =A0It's sti=
ll a work in progress but I'm developing a python implementation that r=
eads and parses CSV files with SNMP data. =A0So far, it looks like the impl=
ementation I have fits well with currently existing systems. I'm planni=
ng on submitting my draft later this week and would love to hear any though=
ts or feedback on other things I can look into in my implementation.



Best,=A0
Priyanka


--047d7b5d64f2a85af704e93ab04f--

From internet-drafts@ietf.org  Mon Oct 21 11:16:00 2013
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 5109411E8122; Mon, 21 Oct 2013 11:16:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.572
X-Spam-Level: 
X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CZDA3QLiSX9M; Mon, 21 Oct 2013 11:15:59 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EA4FC11E8317; Mon, 21 Oct 2013 11:15:48 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.80.p3
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20131021181548.32469.56501.idtracker@ietfa.amsl.com>
Date: Mon, 21 Oct 2013 11:15:48 -0700
Cc: eman@ietf.org
Subject: [eman] I-D Action: draft-ietf-eman-energy-monitoring-mib-07.txt
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Oct 2013 18:16:00 -0000

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

	Title           : Power and Energy Monitoring MIB
	Author(s)       : Mouli Chandramouli
                          Brad Schoening
                          Juergen Quittek
                          Thomas Dietz
                          Benoit Claise
	Filename        : draft-ietf-eman-energy-monitoring-mib-07.txt
	Pages           : 79
	Date            : 2013-10-21

Abstract:
        This document defines a subset of the Management Information
        Base (MIB) for power and energy monitoring of devices.

     =


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-eman-energy-monitoring-mib

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-eman-energy-monitoring-mib-07

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-eman-energy-monitoring-mib-07


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

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


From internet-drafts@ietf.org  Mon Oct 21 12:25:56 2013
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 2F51911E85AF; Mon, 21 Oct 2013 12:25:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.574
X-Spam-Level: 
X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P+fzSogSOY6d; Mon, 21 Oct 2013 12:25:55 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9991211E8468; Mon, 21 Oct 2013 12:25:46 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.80.p3
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20131021192546.32534.92505.idtracker@ietfa.amsl.com>
Date: Mon, 21 Oct 2013 12:25:46 -0700
Cc: eman@ietf.org
Subject: [eman] I-D Action: draft-ietf-eman-battery-mib-10.txt
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Oct 2013 19:25:56 -0000

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

	Title           : Definition of Managed Objects for Battery Monitoring
	Author(s)       : Juergen Quittek
                          Rolf Winter
                          Thomas Dietz
	Filename        : draft-ietf-eman-battery-mib-10.txt
	Pages           : 33
	Date            : 2013-10-21

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


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-eman-battery-mib

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-eman-battery-mib-10

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-eman-battery-mib-10


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

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


From Quittek@neclab.eu  Mon Oct 21 12:35:36 2013
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 B3E8D11E8181 for ; Mon, 21 Oct 2013 12:35:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Level: 
X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ACfMmN1unZok for ; Mon, 21 Oct 2013 12:35:32 -0700 (PDT)
Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 4506411E86BE for ; Mon, 21 Oct 2013 12:35:09 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 549A3100311 for ; Mon, 21 Oct 2013 21:30:09 +0200 (CEST)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de)
Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NDNgokYzb-A6 for ; Mon, 21 Oct 2013 21:30:09 +0200 (CEST)
Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 39133100300 for ; Mon, 21 Oct 2013 21:30:04 +0200 (CEST)
Received: from DAPHNIS.office.hd ([169.254.2.16]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Mon, 21 Oct 2013 21:34:42 +0200
From: Juergen Quittek 
To: "eman@ietf.org" 
Thread-Topic: [eman] I-D Action: draft-ietf-eman-battery-mib-10.txt
Thread-Index: AQHOzpNrfFmYAQ8xSECZQrmR2EE3V5n/ivmQ
Date: Mon, 21 Oct 2013 19:34:42 +0000
Message-ID: <9AB93E4127C26F4BA7829DEFDCE5A6E85A455CF7@DAPHNIS.office.hd>
References: <20131021192546.32534.92505.idtracker@ietfa.amsl.com>
In-Reply-To: <20131021192546.32534.92505.idtracker@ietfa.amsl.com>
Accept-Language: de-DE, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.7.0.203]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [eman] I-D Action: draft-ietf-eman-battery-mib-10.txt
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Oct 2013 19:35:36 -0000

Dear all,

This update of the Battery MIB modules solves one of the two remaining issu=
es. It clarifies the battery identification, particularly in case of batter=
y replacements.

The last remaining issue concerns the compliance specification for notifica=
tions in the MIB module. We will fix this in the next version.=20

Anyway, as discussed at the last IETF meeting, we will not have a WGLC on t=
he Battery MIB before the eman framework is complete.

Best regards,
    Juergen

> -----Original Message-----
> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of
> internet-drafts@ietf.org
> Sent: Montag, 21. Oktober 2013 21:26
> To: i-d-announce@ietf.org
> Cc: eman@ietf.org
> Subject: [eman] I-D Action: draft-ietf-eman-battery-mib-10.txt
>=20
>=20
> A New Internet-Draft is available from the on-line Internet-Drafts direct=
ories.
>  This draft is a work item of the Energy Management Working Group of the
> IETF.
>=20
> 	Title           : Definition of Managed Objects for Battery Monitoring
> 	Author(s)       : Juergen Quittek
>                           Rolf Winter
>                           Thomas Dietz
> 	Filename        : draft-ietf-eman-battery-mib-10.txt
> 	Pages           : 33
> 	Date            : 2013-10-21
>=20
> Abstract:
>    This memo defines a portion of the Management Information Base (MIB)
>    for use with network management protocols in the Internet community.
>    In particular, it defines managed objects that provide information on
>    the status of batteries in managed devices.
>=20
>=20
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-eman-battery-mib
>=20
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-eman-battery-mib-10
>=20
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-eman-battery-mib-10
>=20
>=20
> Please note that it may take a couple of minutes from the time of submiss=
ion
> until the htmlized version and diff are available at tools.ietf.org.
>=20
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>=20
> _______________________________________________
> eman mailing list
> eman@ietf.org
> https://www.ietf.org/mailman/listinfo/eman

From internet-drafts@ietf.org  Mon Oct 21 12:54:09 2013
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 1919C11E832F; Mon, 21 Oct 2013 12:54:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.575
X-Spam-Level: 
X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i6Nwr4+g7w4z; Mon, 21 Oct 2013 12:54:08 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 667C311E8712; Mon, 21 Oct 2013 12:52:59 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.80.p3
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20131021195259.32534.27601.idtracker@ietfa.amsl.com>
Date: Mon, 21 Oct 2013 12:52:59 -0700
Cc: eman@ietf.org
Subject: [eman] I-D Action: draft-ietf-eman-energy-aware-mib-10.txt
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Oct 2013 19:54:09 -0000

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

	Title           : Energy Object Context MIB
	Author(s)       : John Parello
                          Benoit Claise
                          Mouli Chandramouli
	Filename        : draft-ietf-eman-energy-aware-mib-10.txt
	Pages           : 34
	Date            : 2013-10-21

Abstract:
        This document defines a subset of a Management Information Base
        (MIB) for energy management of devices. The module addresses
        device identification, context information, and the
        relationships between reporting devices, remote devices, and
        monitoring devices.

     =


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-eman-energy-aware-mib

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-eman-energy-aware-mib-10

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-eman-energy-aware-mib-10


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

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


From moulchan@cisco.com  Mon Oct 21 23:05:08 2013
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 027A011E846D for ; Mon, 21 Oct 2013 23:05:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level: 
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k-agOoVEluaU for ; Mon, 21 Oct 2013 23:04:52 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 87FE711E8341 for ; Mon, 21 Oct 2013 23:04:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7366; q=dns/txt; s=iport; t=1382421889; x=1383631489; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=XFrVqBBEhHbBA4iAUzV6DvxG5NPkNNakORtpnFbxkog=; b=fit7pyPhmuHBYw9p1L6663u5l5hFXlB8byCY0Gk32AQ4LPAIImyoDjVx 7Wsc2/I9FhTFxICRty3CnPH9VRoHuYlIzBNgUDFaMU/LuuIDvk87ps4bb Jx8kgYt1DvuIviX+PoTZBQ6RHXQlGU1y5XCD2FvFt01zTyL8nRKkiwbPj k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AtcHABIVZlKtJV2a/2dsb2JhbABZgkNEOE4GhEixNohFgSEWbQeCJwEEAQEBax0BCCIdLgsUEQIEEwgBh30IBZk4oVeOI4EHLQuDH4EKA5k4kFiDJIIq
X-IronPort-AV: E=Sophos;i="4.93,546,1378857600";  d="scan'208,217";a="274930701"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-7.cisco.com with ESMTP; 22 Oct 2013 06:04:49 +0000
Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r9M64nSx010963 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 22 Oct 2013 06:04:49 GMT
Received: from xmb-rcd-x08.cisco.com ([169.254.8.94]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.02.0318.004; Tue, 22 Oct 2013 01:04:48 -0500
From: "Mouli Chandramouli (moulchan)" 
To: "eman@ietf.org" 
Thread-Topic: [eman] I-D Action: draft-ietf-eman-energy-monitoring-mib-07.txt
Thread-Index: AQHOzomxNE6CPobUSECP3qpHjDr6kZoA7CqA
Date: Tue, 22 Oct 2013 06:04:48 +0000
Message-ID: <852AF0ED49D9F24BBBFA1B4DEEBE3BA42ADC0E41@xmb-rcd-x08.cisco.com>
In-Reply-To: <20131021181548.32469.56501.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.8.130913
x-originating-ip: [10.142.100.91]
Content-Type: multipart/alternative; boundary="_000_852AF0ED49D9F24BBBFA1B4DEEBE3BA42ADC0E41xmbrcdx08ciscoc_"
MIME-Version: 1.0
Subject: Re: [eman] I-D Action: draft-ietf-eman-energy-monitoring-mib-07.txt
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Oct 2013 06:05:08 -0000

--_000_852AF0ED49D9F24BBBFA1B4DEEBE3BA42ADC0E41xmbrcdx08ciscoc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hello all,

An updated version of the EMAN-MONITORING-MIB has been submitted.

Firstly, the MIB module is aligned to the information model presented in  S=
ection 7  of  http://tools.ietf.org/html/draft-ietf-eman-framework-11

After the last call Framework draft is completed, we shall submit a revised=
 version of the Monitoring MIB.

The Implementation Status section has been recommended in [RFC6982] has been updated.

Thanks
Mouli



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

Title           : Power and Energy Monitoring MIB
Author(s)       : Mouli Chandramouli
                          Brad Schoening
                          Juergen Quittek
                          Thomas Dietz
                          Benoit Claise
Filename        : draft-ietf-eman-energy-monitoring-mib-07.txt
Pages           : 79
Date            : 2013-10-21

Abstract:
        This document defines a subset of the Management Information
        Base (MIB) for power and energy monitoring of devices.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-eman-energy-monitoring-mib

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-eman-energy-monitoring-mib-07

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-eman-energy-monitoring-mib-07


Please note that it may take a couple of minutes from the time of submissio=
n
until the htmlized version and diff are available at tools.ietf.org.

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

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


--_000_852AF0ED49D9F24BBBFA1B4DEEBE3BA42ADC0E41xmbrcdx08ciscoc_
Content-Type: text/html; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable







Hello all,







An updated version of the EMAN-MONITORING-MIB has been submitted. =
;







Firstly, the MIB module is aligned to the information model presented =
in  Section 7  of  http://tools.ietf.org/html/draft-ietf-eman-frame=
work-11







After the last call Framework draft is completed, we shall submit a re=
vised version of the Monitoring MIB. 







The Implementation Status section has been recommended in [RFC6982] has=
 been updated. 







Thanks


Mouli 






















A New Internet-Draft is available from the on-line Internet-Drafts dir=
ectories.


This draft is a work item of the Energy Management Working Group of th=
e IETF.







Title&=
nbsp;          : Power and Ene=
rgy Monitoring MIB


Author=
(s)       : Mouli Chandramouli


           &nbs=
p;            &=
nbsp; Brad Schoening


           &nbs=
p;            &=
nbsp; Juergen Quittek


           &nbs=
p;            &=
nbsp; Thomas Dietz


           &nbs=
p;            &=
nbsp; Benoit Claise


Filena=
me        : draft-ietf-eman-energy-=
monitoring-mib-07.txt


Pages&=
nbsp;          : 79


Date&n=
bsp;           : 201=
3-10-21







Abstract:


        This document defines =
a subset of the Management Information


        Base (MIB) for power a=
nd energy monitoring of devices.







     







The IETF datatracker status page for this draft is:








There's also a htmlized version available at:








A diff from the previous version is available at:













Please note that it may take a couple of minutes from the time of subm=
ission


until the htmlized version and diff are available at tools.ietf.org.






Internet-Drafts are also available by anonymous FTP at:








_______________________________________________


eman mailing list
















--_000_852AF0ED49D9F24BBBFA1B4DEEBE3BA42ADC0E41xmbrcdx08ciscoc_--

From moulchan@cisco.com  Mon Oct 21 23:07:28 2013
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 082C411E846A for ; Mon, 21 Oct 2013 23:07:28 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2kDWwWrW7DAE for ; Mon, 21 Oct 2013 23:07:23 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id BF87611E815B for ; Mon, 21 Oct 2013 23:07:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7568; q=dns/txt; s=iport; t=1382422035; x=1383631635; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=Le5u66A3iJ47OB8iCef1aGdIRdgQQ4MJg5Zkc2fEMPI=; b=C9I1DimPjj8EEA//NHa1knl+9Il58zOzYAKlMpRjHU0yO5DG5o85Fomr 3ukpLa2sygYPuwzfZ8IlurYGXFBKfljY8M9rvCfQLYDT2tCDuUnQCF0/u hjTJHmDZt6gNS7aeKwllIk+KhA93IocxO9XLMTLvcQeaG7FriL8OQVvCP A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AtgHAOAUZlKtJXHB/2dsb2JhbABZgkNEOE4GhEixNohFgSEWbQeCJwEEAQEBawQZAQgiHS4LFBECBBMIAYd9CAWZOKFXjiOBBy0Lgx+BCgOZOJBYgySCKg
X-IronPort-AV: E=Sophos;i="4.93,546,1378857600";  d="scan'208,217";a="274961054"
Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-6.cisco.com with ESMTP; 22 Oct 2013 06:07:14 +0000
Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r9M67EJx007029 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 22 Oct 2013 06:07:14 GMT
Received: from xmb-rcd-x08.cisco.com ([169.254.8.94]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.004; Tue, 22 Oct 2013 01:07:13 -0500
From: "Mouli Chandramouli (moulchan)" 
To: "eman@ietf.org" 
Thread-Topic: [eman] I-D Action: draft-ietf-eman-energy-aware-mib-10.txt
Thread-Index: AQHOzpd1rFTflVppsEOUTRMeAIP3KpoA7LsA
Date: Tue, 22 Oct 2013 06:07:13 +0000
Message-ID: <852AF0ED49D9F24BBBFA1B4DEEBE3BA42ADC0E56@xmb-rcd-x08.cisco.com>
In-Reply-To: <20131021195259.32534.27601.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.8.130913
x-originating-ip: [10.142.100.91]
Content-Type: multipart/alternative; boundary="_000_852AF0ED49D9F24BBBFA1B4DEEBE3BA42ADC0E56xmbrcdx08ciscoc_"
MIME-Version: 1.0
Subject: Re: [eman] I-D Action: draft-ietf-eman-energy-aware-mib-10.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, 22 Oct 2013 06:07:28 -0000

--_000_852AF0ED49D9F24BBBFA1B4DEEBE3BA42ADC0E56xmbrcdx08ciscoc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hello all,

An updated version of the ENERGY-CONTEXT-MIB  has been submitted.

Firstly, the MIB module is aligned to the information model presented in  S=
ection 7  of  http://tools.ietf.org/html/draft-ietf-eman-framework-11.

New MIB objects eoIfType  to model the power interfaces has been included.

After the last call Framework draft is completed, we shall submit a revised=
 version of the ENERGY-CONTEXT-MIB.

The Implementation Status section has been recommended in [RFC6982] has been updated.

Thanks
Mouli



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

Title           : Energy Object Context MIB
Author(s)       : John Parello
                          Benoit Claise
                          Mouli Chandramouli
Filename        : draft-ietf-eman-energy-aware-mib-10.txt
Pages           : 34
Date            : 2013-10-21

Abstract:
        This document defines a subset of a Management Information Base
        (MIB) for energy management of devices. The module addresses
        device identification, context information, and the
        relationships between reporting devices, remote devices, and
        monitoring devices.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-eman-energy-aware-mib

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-eman-energy-aware-mib-10

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-eman-energy-aware-mib-10


Please note that it may take a couple of minutes from the time of submissio=
n
until the htmlized version and diff are available at tools.ietf.org.

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

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


--_000_852AF0ED49D9F24BBBFA1B4DEEBE3BA42ADC0E56xmbrcdx08ciscoc_
Content-Type: text/html; charset="us-ascii"
Content-ID: <8B1E8F7B91521542BFBBD7795036E595@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable









Hello all,







An updated version of the ENERGY-CONTEXT-MIB  has been submitted.=
 







Firstly, the MIB module is aligned to the information model presented =
in  Section 7  of  http://tools.ietf.org/html/draft-ietf-eman-frame=
work-11.







New MIB objects eoIfType  to model the power interfaces has been =
included. 







After the last call Framework draft is completed, we shall submit a re=
vised version of the ENERGY-CONTEXT-MIB. 







The Implementation Status section has been recommended in [RFC6982] has=
 been updated. 







Thanks


Mouli 
























A New Internet-Draft is available from the on-line Internet-Drafts dir=
ectories.


This draft is a work item of the Energy Management Working Group of th=
e IETF.







Title&=
nbsp;          : Energy Object=
 Context MIB


Author=
(s)       : John Parello


           &nbs=
p;            &=
nbsp; Benoit Claise


           &nbs=
p;            &=
nbsp; Mouli Chandramouli


Filena=
me        : draft-ietf-eman-energy-=
aware-mib-10.txt


Pages&=
nbsp;          : 34


Date&n=
bsp;           : 201=
3-10-21







Abstract:


        This document defines =
a subset of a Management Information Base


        (MIB) for energy manag=
ement of devices. The module addresses


        device identification,=
 context information, and the


        relationships between =
reporting devices, remote devices, and


        monitoring devices.






     







The IETF datatracker status page for this draft is:








There's also a htmlized version available at:


http://tools.ietf.org/html/draft-ietf-eman-energy-aware-mib-10






A diff from the previous version is available at:













Please note that it may take a couple of minutes from the time of subm=
ission


until the htmlized version and diff are available at tools.ietf.org.






Internet-Drafts are also available by anonymous FTP at:








_______________________________________________


eman mailing list
















--_000_852AF0ED49D9F24BBBFA1B4DEEBE3BA42ADC0E56xmbrcdx08ciscoc_--

From bclaise@cisco.com  Tue Oct 22 00:13:49 2013
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 2EE4311E8489 for ; Tue, 22 Oct 2013 00:13:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.577
X-Spam-Level: 
X-Spam-Status: No, score=-10.577 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rnTivkBXQsVr for ; Tue, 22 Oct 2013 00:13:44 -0700 (PDT)
Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 3FC0B11E8487 for ; Tue, 22 Oct 2013 00:13:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4280; q=dns/txt; s=iport; t=1382426021; x=1383635621; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=aYQYuyEdKcOqGYtE+IEnCQmirvNs4B6CDXsPqq2EB7w=; b=OehgoUgAh3gaDRpa6S1JMQpR429k4mGsgCQHuvX9aX3w9h78iJX23qGk 8f34HFURkA3F8M+rL5pIP5bMw0gn46lFf60v43R8q2LNCHXmaoq1Ngpst u2Q06fuK5OJXbuL85QVjgkNI8hgepgCnyJ21pJGSPasiuKIxuQyExY5O1 c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AjYFANkkZlKQ/khN/2dsb2JhbABZDoJ5OIlbtTuBJRZ0giYBAQQBAQFrCgEQCwQKExYPCQMCAQIBFTAGDQEFAgEBEIdyDbsOj0YHhCkDmAk2eYUMi0yCZUE6
X-IronPort-AV: E=Sophos;i="4.93,546,1378857600"; d="scan'208,217";a="18442620"
Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-3.cisco.com with ESMTP; 22 Oct 2013 07:13:40 +0000
Received: from [10.60.67.89] (ams-bclaise-8918.cisco.com [10.60.67.89]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r9M7DYFs004669; Tue, 22 Oct 2013 07:13:36 GMT
Message-ID: <5266259E.5070902@cisco.com>
Date: Tue, 22 Oct 2013 09:13:34 +0200
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Priyanka Rao 
References: 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------090107040903060103040500"
Cc: eman@ietf.org
Subject: Re: [eman] IETF Draft - Python Implementation
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, 22 Oct 2013 07:13:49 -0000

This is a multi-part message in MIME format.
--------------090107040903060103040500
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi Priyanka,

Welcome to the EMAN community.
Great to hear that you're working on EMAN.

Look at the "Implementation status" of
     http://tools.ietf.org/html/draft-ietf-eman-energy-aware-mib-10
http://tools.ietf.org/html/draft-ietf-eman-energy-monitoring-mib-07
... and let us know if your Python implementation qualifies.

Regards, Benoit
> Hi all,
>
> Just joined the ietf eman mailing list and wanted to introduce myself. 
>  My name is Priyanka and I am a sophomore studying at Stanford 
> University.  I am majoring in electrical engineering with a minor in 
> computer science.
>
> Currently, I am working on a draft for IETF that looks at the 
> framework for energy management systems.  It's still a work in 
> progress but I'm developing a python implementation that reads and 
> parses CSV files with SNMP data.  So far, it looks like the 
> implementation I have fits well with currently existing systems. I'm 
> planning on submitting my draft later this week and would love to hear 
> any thoughts or feedback on other things I can look into in my 
> implementation.
>
> Best,
> Priyanka
>
>
> _______________________________________________
> eman mailing list
> eman@ietf.org
> https://www.ietf.org/mailman/listinfo/eman


--------------090107040903060103040500
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    
Hi Priyanka,

      

      Welcome to the EMAN community.

      Great to hear that you're working on EMAN.

      

      Look at the "Implementation status" of

          http://tools.ietf.org/html/draft-ietf-eman-energy-aware-mib-10

         
      http://tools.ietf.org/html/draft-ietf-eman-energy-monitoring-mib-07

      ... and let us know if your Python implementation qualifies.    

      

      Regards, Benoit

    

    

      
      
Hi all, 
        


        

        
Just joined the ietf eman mailing list and wanted to
          introduce myself.  My name is Priyanka and I am a sophomore
          studying at Stanford University.  I am majoring in electrical
          engineering with a minor in computer science.  

        


        

        
Currently, I am working on a draft for IETF that looks at
          the framework for energy management systems.  It's still a
          work in progress but I'm developing a python implementation
          that reads and parses CSV files with SNMP data.  So far, it
          looks like the implementation I have fits well with currently
          existing systems. I'm planning on submitting my draft later
          this week and would love to hear any thoughts or feedback on
          other things I can look into in my implementation.

        


        

        
Best, 

          Priyanka

      

      

      

      

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


    

    

  


--------------090107040903060103040500--

From brads@coraid.com  Sun Oct 27 19:48:02 2013
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 90B9611E8215 for ; Sun, 27 Oct 2013 19:47:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.798
X-Spam-Level: 
X-Spam-Status: No, score=-0.798 tagged_above=-999 required=5 tests=[AWL=-1.800, BAYES_50=0.001, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dV2OuUEj5ynC for ; Sun, 27 Oct 2013 19:47:53 -0700 (PDT)
Received: from server506.appriver.com (server506f.appriver.com [50.56.144.36]) by ietfa.amsl.com (Postfix) with ESMTP id 5F1B611E82EB for ; Sun, 27 Oct 2013 19:47:52 -0700 (PDT)
X-Note-AR-ScanTimeLocal: 10/27/2013 9:47:47 PM
X-Policy: GLOBAL - coraid.com
X-Primary: brads@coraid.com
X-Note: This Email was scanned by AppRiver SecureTide
X-Virus-Scan: V-
X-Note: ICH-CT/SI:0-428/SG:1 10/27/2013 9:46:52 PM
X-Note-SnifferID: 0
X-Note: TCH-CT/SI:0-152/SG:8 10/27/2013 9:47:00 PM
X-GBUdb-Analysis: 0, 10.242.229.139, Ugly c=1 p=-0.900842 Source White
X-Signature-Violations: 0-0-0-32767-c
X-Note-419: 0 ms. Fail:0 Chk:1349 of 1349 total
X-Note: SCH-CT/SI:0-1349/SG:1 10/27/2013 9:47:39 PM
X-Note: Spam Tests Failed: 
X-Country-Path: UNKNOWN->PRIVATE->UNITED STATES
X-Note-Sending-IP: 10.242.229.139
X-Note-Reverse-DNS: smtp.exg6.exghost.com
X-Note-Return-Path: brads@coraid.com
X-Note: User Rule Hits: 
X-Note: Global Rule Hits: G325 G326 G327 G328 G332 G333 G443 G455 
X-Note: Encrypt Rule Hits: 
X-Note: Mail Class: VALID
X-Note: Headers Injected
Received: from [10.242.229.139] (HELO smtp.exg6.exghost.com) by server506.appriver.com (CommuniGate Pro SMTP 6.0.2) with ESMTPS id 125726832 for eman@ietf.org; Sun, 27 Oct 2013 21:47:47 -0500
Received: from DAGN05C-E6.exg6.exghost.com ([169.254.3.11]) by HT03-E6.exg6.exghost.com ([50.56.144.21]) with mapi id 14.03.0158.001; Sun, 27 Oct 2013 21:47:47 -0500
From: Brad Schoening 
To: "eman@ietf.org" 
Thread-Topic: Framework psudo code
Thread-Index: AQHO04gV7aqBGZSSm0KUJp/zTOMd/Q==
Date: Mon, 28 Oct 2013 02:47:46 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.14.0.111121
x-originating-ip: [50.56.144.246]
x-rerouted-by-exchange: 
Content-Type: multipart/related; boundary="_004_CE92D013F2111bradscoraidcom_"; type="multipart/alternative"
MIME-Version: 1.0
Subject: [eman] Framework psudo code
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, 28 Oct 2013 02:48:02 -0000

--_004_CE92D013F2111bradscoraidcom_
Content-Type: multipart/alternative;
	boundary="_000_CE92D013F2111bradscoraidcom_"

--_000_CE92D013F2111bradscoraidcom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Dear all,

I'm wondering if the pseudo code in the framework could be more clearly rep=
resented using a tabular format similar to what the IEC, DMTF and Ecma-400 =
use for their CIM objects.  Consider an example:

Our pseudo code:


        CLASS Measurement {
              multiplier: enum { -24..24}
              caliber   : enum { actual, estimated, static }
              accuracy  : enum { 0..10000} // hundreds of percent
        }



Re-written in a tabular format:

1.0 Measurement Class
Properties

Description

Type

Get/Set

Requirement

Multiplier

Base 10 exponent

Enum

G

Mandatory

Caliber

Actual, estimate, or static

Enum

G

Optional

Accuracy

Hundredths of percent

Enum

G

Optional


Below is a sample class definition taken from IEC-61850.  Also, note the us=
e of object-oriented class inheritance in the IEC model representation and =
use of attribute protocols for 'descriptions', 'controls' and 'settings':

[cid:9E19F038-2659-44D7-BCEE-F70117F77C65]

--_000_CE92D013F2111bradscoraidcom_
Content-Type: text/html; charset="us-ascii"
Content-ID: <6C3E003DDA0B9B4D9EF4A27CC3C09149@fwd6.exghost.com>
Content-Transfer-Encoding: quoted-printable













Our pseudo code:





        CLASS Measurem=
ent {
              multiplier: enum { -24..24}
              caliber   : enum { actual, estimated, static }
              accuracy  : enum { 0..10000} // hundreds of percent
        }




Re-written in a tabular format:









1.0 Measurement Class









Properties





Description





Type





Get/Set





Requirement









Multiplier





Base 10 exponent





Enum





G





Mandatory









Caliber





Actual, estimate, or static





Enum





G





Optional









Accuracy





Hundredths of percent





Enum





G





Optional






















Below is=
 a sample class definition taken from IEC-61850.  Also, note the use o=
f object-oriented class inheritance in the IEC model representation and use=
 of attribute protocols for 'descriptions',
 'controls' and 'settings':











--_000_CE92D013F2111bradscoraidcom_--

--_004_CE92D013F2111bradscoraidcom_
Content-Type: image/png; name="9E19F038-2659-44D7-BCEE-F70117F77C65.png"
Content-Description: 9E19F038-2659-44D7-BCEE-F70117F77C65.png
Content-Disposition: inline;
	filename="9E19F038-2659-44D7-BCEE-F70117F77C65.png"; size=147084;
	creation-date="Mon, 28 Oct 2013 02:47:46 GMT";
	modification-date="Mon, 28 Oct 2013 02:47:46 GMT"
Content-ID: <9E19F038-2659-44D7-BCEE-F70117F77C65>
Content-Transfer-Encoding: base64

iVBORw0KGgoAAAANSUhEUgAAAvwAAALMCAYAAACYImYiAABAAElEQVR4Aey9DXxU1Z3//+FvYgKa
QIKAJViIERosDAqygBZkwGWJWoYVUAtjC7YNlJ8LoVZo3Mp2w7/SaHchLOsmdDVUE6oG+TNYCaUm
wVA1vDBYJmpSTUqoDa3BJpoICc74u//vOfdxJvOUR5L4va9k7r3n+bzPw/3ec77n3CEKHeCDCTAB
JsAEmAATYAJMgAkwgUFJ4P8ZlLniTDEBJsAEmAATYAJMgAkwASYgCbDAzxWBCTABJsAEmAATYAJM
gAkMYgIs8A/iwuWsMQEmwASYABNgAkyACTABFvi5DjABJsAEmAATYAJMgAkwgUFMgAX+QVy4nDUm
wASYABNgAkyACTABJsACP9cBJsAEmAATYAJMgAkwASYwiAmwwD+IC5ezxgSYABNgAkyACTABJsAE
WODnOsAEmAATYAJMgAkwASbABAYxARb4B3HhctaYABNgAkyACTABJsAEmAAL/FwHmAATYAJMgAkw
ASbABJjAICbAAv8gLlzOGhNgAkyACTABJsAEmAATYIGf6wATYAJMgAkwASbABJgAExjEBFjgH8SF
y1ljAkyACTABJsAEmAATYAIs8HMdYAJMgAkwASbABJgAE2ACg5hAVP/NmxdnT1Xizx7gSksiP/88
GlPmTEdCiJSfqzmOYxXv4eMWYOyUW3H3gqmItYQR+LIdNcePouK9v6LlEjDh5tuxaG5qBP4Ch9Yj
pt7zOP5qJS58DiTNuQNTRwXJdGsd9r90HJ8RKdtd92K6xd25E4dwtLoJuHoy7l8+q3P50cL9/Epr
CVB5XJ2I6yfNwPTUUUY2vedOoOBoNd0nwn7/EowPD9zw25WL3oyv62G349ShA3A3fY7EyYuwZNbY
rmQtqJ9ulWXQUINbdC++Zhzf9xwOnDxDEQxF8m0OpHe2/gVPWq/anD97Dgnjx0Jtba04cehl/OGv
n+Omb96PWWN7uWJ3JWe91f67kpYe9nOe+vLK+gvAVRNwB/XHQXpANNeUwlXxZ1zp01ddicRrx2Di
zXOQYjwwQrTR1hrqRyuoHzX7MG9zFV50VVKn59sHXp14LSbZZiJ1bFwP55iDYwJMgAn0EgGl3x71
SiagULb9/u1KRUvwRFfkOv3ck397llLdFtyP0latZNr84xH+spV6Twh/vWzVUplj5CW7oilobFZ3
cOQrVjyVOXY1DFuOEjyEwEH7hNuhHKA4cioMj6bb0OVjeOjmRW/G1/WwW5Rcu1qP7NmV3cxhR+9m
WWZ3uiw7hhbepDvxuXMdRt2VbTijOHyEl9mFp6layc2wUbotfFsqFLtW90O1wcuZdLO+Ut3rwfZ/
OfOkx23WwdD9l+EuQD8l6l+hW+sVLeXp30ZNjmYfZpoFeD5QuM6ccuUyPiJ0THxmAkyACYQl0H9V
elr/hvcCvuTEBzSVhueOYPa6Anlpc2YiO9Ohui3biryjZ4P6q/rVz7DdrVo7MrKRlU6PeHGUbcFP
CmrU68vxGx1jxBobbVx2vLC4g2sNdpaeM9xExySp1yNjgo6OGY79LyzhOtIzkJGRDqdDY0NuXRtn
Y//ZdtWX4TYe0aHS6h9HF++jh0+gtDjgcNoxrKfjs+alk+mL0apnfC8MBA8ba4eD8pyx/nb0xbhi
1+NrR2WxSyXnyEZFtRuVD83qJMm+d1793Hqs20kdgWM0zUloR/Rw2J0OqmtOXD882Piy7vgynY36
SvH3ZPu/TNmxRhtp/2W4gw3ODOqr0tPhsJkhrXL+D2SvSJ2T1iOiQxs1OFIfpns1zKhaBOgDCzbO
w9YjZn+re+MzE2ACTKC/EeinTzCgtf4PUEUGJypbnsN0XcLxehFMcm1v+QxCHC1DOl7IfxypUe2I
rRiKjWXA6Zq/AUvGB+DfirKn1JcEOAuxf8dKCn4N2vaMxnZy3dpyMYCf/m20deG/Y2lbHqYGEzrb
z6H06BtooqnrW+9cgLFha4ET2/57B6Zq7rJLn0DSwi0Swrm/t8FXfycOFxpqcOjVQzjdeAmjU27D
PfcugNAyaq47jpK3PyKVoOuxaPF0Q73o7IkjOPnR5zRrPs4wbz17Ci+7XkXdp6RfhRikTLsd/7ho
FkZpeYpKnIRV69aR3VW41pp+kbcDL+P1ukbV38w7kEZxJcjUqj/nqo7jaNmb+FCEHTMcKbZZSLtj
Vkg1MYt3n8uzpDL1wtHTuIThuG2pnc6Bj3OnjmD/qychohx+3Uwsv38xdO0Qobbw2juCy9co/6b6
2fmqUrx2pom4qOYjp8zHunUzKcvDfSIRrF5yvUL5IeOY0bgt7ZtYMNVXncjbXIODLx5CNZUJYq7D
ovuWYdZ4vVH5BGfcdIiPVMxKD7+Gps+vxpRbZ+DTNw6QulgjIbwOtzv08FpRVfoy3jyjBmMbMxzN
586TitxkI1yhcnf0qMrf16/qxHu+Codf+yOuHPM1Es7+iIPF1RhOeX/g3il453AJPsIY3Dr3q3jr
xRdw+iyRn3IbHli5AEPPnsDzrtckh5SZabjHwlKEHKrc28+dQvHJv6sJOPMmDhy6FlPnzCc1uhuw
In0D3m/+HJNGGq8B0p23uQ6vFr+Kk1pdmzx/CZZa1U5az+LIb0/i8zFTYJ8SjZef24d3qIyuTaHy
v8csfzXSnvsN2/4pqlAsAC/qjr+Kt6lNTrl9LlDpQlH5h5Tw63DXt5yYntCM0hd/TW3sU6rL0+BY
Rip8PlVJqEG9hKOnyY9ou7ctwb0LfNVxZN3+I9XtRKrbEalcRsjHsQm/3LFa61tycOjRO+HYTg8A
9xv4sJVUPA1JvmN4IazIsW8f+Muzpbh/wkL5jNqethtrPY9jvLUf6hg8mzABJsAELi+BsHMAl8lB
bWG6QmTkv83hUOx2u5KRXaQ0hFLN0dLqEXOsbU2KuzhHoUEeGUZGUW3QnLQ1NSr1tdVKbYOuDGOq
E9ktaitBA+glixZ3rsEgpzK4Qo7Vnc7MnlUuU+XWVZzsuYaqjzlNbU5dB8qCGa5TcVvmrdvc+R3S
ZboNMPVNcYvUVxea6lauBj3AeiVDKyOQ2ocwbSzPNsLX86OeM5VazVugPHgaShSa0+no15al1GsZ
rC3K6Ggv/DhylUbNjZkXh1KpVwnNznqqyDHz45tOoe6kq/R4lMDuHEq5xqA6Xw/HphTriVAaTJU2
Z5HkYqgtWNSzal2ZAfPjo27lLgzoJtMVvE2IfHaIz6IO4Z9fce8S+m/kRm9zVjdZUiXNoxRnaSpm
fuWUka/zoiAsqmxmGBlKbbOpXmOa6+UtVHH0a/XsyDXDDFfuldkd/cs0t1QGVOlprDDbpk+8jhxF
r9qB86Gl0Z5j1DdrnerKtVlfzfyHav/hWFAJKDmBVBw1vh3K15ZNtVU7PLVKViC/6YU+amgd6pbu
3+8cqP/ycyJvDXek0mR9RFTk6KplDlUVtK1ScWr5sGeXKE0tTUpjY6PS1NSi1Jfo/Y7Z7k22mn9L
5JWWsEP1ExYvfMkEmAATuGwE+qlKjxcfvFNBz1H1cLtcKCsrw84tK5A0axuCK+eo7qNopKU0KxG2
tI1QNXWysXV5ih5ch3NswiiMT0lFilyA5cWRbWvk6L5wuHTW9R3c92cDGz2NxVG2dR72n/NimKkV
pFrIX90w3mIW6tKN4oL9OLR/P/bu2oY7bWssjgMMa9kz4CovR46hGvUC3j4PpH7zIWhKVig6WivD
aK+hctVCy3/wNppdacWBf1NnD4BMuBsaQS9umovteMVNw3TiMKba9en3VhSsV0fcQPM82YXFKMpJ
V926t+In++po4LIGP12hxebMQYW7EkVZ9PgXh6sYf9KCVg1C/3pJfSx9Y4HqyJaB4gqRXw2+xWt7
zYuYrblzZOajvLwITunMhXlbXoRQiEpdpnNxo/CVKum7veaoUQdzN/+TnNQy1BZ09azm4/i+Q8xD
0UFpKCophpEdUrcqJeY0loudtlXigtyky3LJzVDVsrY7HsaJEHnuEJ9FHUIEl11UguJcel3TjmeO
UGsbei0ey8myqFM4kZ1bhJXTEnDuyFakbS1TXdszUViUDx3ZzjUzsLfKv2yFU1JhIrUtZ+4DSCG9
Nl0dQ4y4FpaUIEeFSe4obmLgKnFByx5cL/wezSKICMp95JxNSLeb5ZeelY8Vk2heiIZ99TgNtbrm
E/j+bDG7JA5R14qQY0S6Ec7/PKFaGXWUbkXayi3pLXsaldQ+e/oI2/4jYCHSFJ9spiwjvxjF+WY5
u0ltRpR9oa4y6d6CN+pU1b5TTz2MrWqni6zCEpQUZpFrOvaswpM+qobxagTJ8cEmbM0EdOaKZmee
P3QI+/fvw65HH6C259J8J+Ma3wka0thciMT4RIwePRqJifGYoM1aBovOfwZgoj1Nc3oGf2nq+bIM
lg42ZwJMgAl0icBle9UIGXGLUpiujrjZ0nMVd32tUpJrjsymF1aH9E3D+0pRhl2hh58x6mcdQQzu
uY1GIPURIfKbXuQzWhTcX+/YmKNLUCIb4U9XKmoto9zOXKU4X5spsYzwKzRe3NbWRv/6KHvg9Fvj
p8plsDSuiY8+AG66pVFqbbjPU2uOLKvp9yguuSiSwqIRTuG3MlvjTaPwqjdz4auIx5GepRS6XIqr
uEJpsiTXjE8bjaORWH1036wfVJ45WUpuoUuprBexUb5pRK++2k2zOY1KQ61bKcrWR9cDj+oFG7kz
ZyHsSokxKl9rzFboI/zmKKBTqWhsUzw0/VTr0uuyPmpII9+Z2ggzjZaK2ZByfSTc4KIoxiimVpbm
CLIlDU2VSnZWjlLkKpezYW2WMsgsrpXxtzUUG6PWOcEySGnwj0+xjI46893kQhxmeel5FpzzHWp9
ceTqbZXaZLpWhyx5UtrcCr2Wybpl12ZFzLKlxZbW1faW+LPKVehtxiyYTSnSVtgbMyY0a6PWz8jK
3fSXL2dUZPYsceptsKlCX0xPcdbq48miDPXZiwylWkx2WNImZz8oQE+1ZXYsxEJ8GXeEP2Y8kbT/
SFi0GOVnyyxRU+FxmyPj2uyhQvWIhHlZdiobqgtaudsyXUoL1XWPp9EIy6c/JTvRB8nZ2BD57FAH
g7g13AXqp8gsq1ib47OUp9GPdfATWV9g1j0o/XVBdxBcbMwEmMCXkECA4VnqBi/7EYeVeafp35KQ
tY8g66mdcvToo4/D6dXHYvmOUiwnXdTSbYuwkEYVd67Jw9r785Cq6YBbQtYuW7F/0zewQizaE4cj
Bw15yw09c9Wwv/9+hGHjF+A/Cmkkd9UeoGAd0rRBaN+URyE2tnNFb6NFi7NJT/fisGG4ZuQ4TJt9
F+5fYurhm+EnY7SmzxuVNJXGYSkZhmUU5t7/XWDnRpqCOIiTZ+/CW4XqCJxj/VKoWudx+OZPsrGO
FkyLw7VnK/1rAdDMQXnBk5gbaNEBDb/pasTTpxpjsli84THNs3pq/aAEj/9oG/aUaeXsYxv5zYdv
v6E5LsPnhrfRmCamMPRBRbqMjtFTVYDZo00SqpcWzWcU5n97E7CdZk7chSg+NQcntZHwdJrVUrlo
Ti2nD35fqt3FY4RerxOmY/Nj0w1XrRfNIfztaTcYswa6g5M1DaD9VfXbiM/fmDHBcBujDdYaBqB1
HfpxyWyrOif78vlmnmInYA4x20PMykpPonWDmXYxip86Qc+YHqB6Hn6Vau4xjG24foxapz36Qgod
r5g3iqDcTX+XaJ4JPus+jGjo4i/V7xq3iYl6+qIwcfo0Mi+j/zP4lBDotZCG9zFOS1tUkk3Ocskq
4j9kbITa1YtI2n9kLPQUJI8foV56TdLTpn1VNUtMkqP3bt1xez1+r9V993YH4rXJJ90aFedkzZDE
aBo2VkzF9sJhd6YT+4sYNuwajByXjDuWfovWtJhbCOtR2jKL8fus+UAb5Y1mr1pP7kHSPOqbIjya
Gs5qLh24XcwG8cEEmAAT6McEeqfH7XaGW1Fz6j3U/+UjjJ5zp7av/FAMHxk6YLF4sex1N+pbv4r0
tQtIWI/CzYsWA1J4+gifimeW/nz2C+r4Ew5D2LdnFOIlWrzbn7rwmOjIiuoiCRpTV/4bsrL3GFPr
flntwq0D+c/Twukg7IIHaAoJupuEWXchAxtJjacMm9Z8H24pLdjw4Dcn604wdsFmtNTfgZePvIIX
XyCBX8hQ4ijbiX/b/wBKfYRC1QoUlS7aNn4i1AtUQbvu+CF8cGUyJl83DuMTz+D7M1ZIedzmyMCm
B+9BymcHMG+VpuajBRXJafhYXefBiSSjonjRYgiZaigeI1UO5OQvRTwJo1dS0j4X0u+V1+I6Tc0g
NvUuZNNw6RYCsmrGPC0JtDtMWmrQ5IyccCPZaRKWITzSwtr9lbjqaxMxaWIKogwplt5hM3Nw76R4
4wVFbC1+dYqWgKCxBLa45OmsCgOR+EgNq+z9D+lVXF97bzKzz5goS00vR1miQdusf/zkK5jb9lOd
K3d6gQnV2kZeq3dEybjKgs/z2ceBYYk6oKfN8mIaxHG3jMO2/86y0F+eLKlKTU7U7kSmLEdsPO1N
T/fUpm3OLGxJu06t55qTKxNt5u5HFm8RXcbHmDvnhPLgyMfh5/RFu6EcAsnjRyMuijq1OK1jG6Gr
OgbyR43WaGPCvh3HCs03mgi750ABsxkTYAJMoE8I9E8dfhop+vGM2UijLQhn/OSg1MM9f8old9sR
VMaMHS7hiA8D5eXlYe/+E1IXuun0c3CsWoON6xbi+VOkwOw9hxd3qyPFQgCU20WS2aG9eeRvL06c
U/VOz5VuI31qXaoEvn1PCt4/fhylpaU4UdPcJwURLpLiN07ibF0Namr0/yrU1J2TgpPVr/pMGouM
gnyrsc91O30kay9xy9tXquo4+9gGvvH4PdsDu4rENAUP5DikQzety5CHYz3s+qh9ew0eXTAN8RNm
4LW4FThYqoC+kwD6TkLoY+gw2rtFPbb+Wy7qSMbynjuOh+c5kDbbhglPnqBR3pO6eIxVW7dj9ZK5
MMf9/B/ooaNLmjJNc1CAZwpOyHI4d/xFo47qvkeO1F8MWjDB7sTqtasxHe/j2WdL8OY7Z2HKzaNw
32OmnrT0n/Eg5hgvE3qI5nnMpEnajQs79hyXbaDuSC4WrkjDbNsNeO69VsRdRzvEaK7GTLFj5erV
WG2/Fgd3PIvi196ndw6dmhlu71zF4aZbtZQUZOPp42cpGi9qDv3SYDYxZXyvRN3pcm/5FI2trWhV
u4cOaUpM0tPpwvZdR2QbaqVdW3asKVDdOpbiRvV9s4Pf3jYI1/47zSJAgoO/7I2hHa9UD+7W4fjH
lVTXVt+FlpJncbDkTdQ1eYwXKf++O0A0vkau0zhZU2fp/6gfrKpC3Tlq6NaDvppIYx6RHQFeZoJ7
dMN9ugZ11P9WVVH/ue1+rNKK25a5wdxFLngAbMMEmAATuLwE+qsaU3lWx10ziJQC0G4dmi53h50e
LHrcqltNZ5j8GTt2WHfdkDvfNBkfS/L3I+5t2ebHpfqalamba+bDN43qx2hMd7pOuJrSEl0vXHDT
dsoRNlbd71AfMbOGG0LVW0ZmdWuEadGX1fWfhWNPg8vQ/RX5yXDpe+gIW9L1dpr5tdmdisNu1gXd
rTU+PW3Vlp2dfDlB1bX22WXGrjgdZrg0JqnuMkMpCBS2SJnv0aDQiDzVx8D/hj67RUdduLXZLHFm
uExdcRG4X/3N1TOmRWzoKRtl2ajkaB/66pgOfU2EZX2ASKs1ftDuS6qSu2/WgsVnSZ9ZnqbetpFn
odev6/AbuxWJci8x1g50TG+m8ZE7K3+jLok0BahPgdxaOcnsRVju/h8Lk3rZAeJUaJVFoaWO+ucl
X4MaKG2B8hAQficMA8ZD/gO2/4hYmDr8RpkG4hDAzFzfINqFzaedZ2vrLkTWOvTdQfJrlGWQdqb3
z4Y7o20ECdCSZiNvmlMrR73pmWaB2zmQHnInryCpYGMmwASYQJ8T6J8j/PQEnZv5KmhBJV1ZDkcW
3E07kKLNt+u7iNgWTFCniuOm47naEmOXDt1nZn45nl87Xb2lIbAkzWK4GG9q/wt+X6a77HhOHu4z
j9vRweU0cfrvcDHG5yNUC2hXGFoQqR4T48zpdGP3kCTfWWrdbYdzJMOV+nS4bxr0oHRbcR81di6+
qw87k0bz/fbxujM60/qLX9YiP1Mte3dZAan0kI4AaQtnFlbgSeNbCnqIZtpSV/43KmlXEN/DgdyS
eixPEVP3M/CLwkzNugwFLjfSs7K0XXPcKCqr1ew6hu0bprgbi83H3MhSJyuktS0929ytRQ8idir+
u7ECmVp+3aoOE6nX5KPhySXGiKcMgOrvhizNoS0L3zQ+PiFtjR/btK9oZTkKGw7XQt91R3cg1Ckq
Gh7R9OSjsPjxY3DpbUmLH/Z0FNc+hakmPt17h7MRX7Q5i2L9jFucFkacnmeqVSPHaEO9hpko9wU4
XF+CTOsXkSg2e0YuatsC7WMeuC6JBOrBRht1mWbw/FMerxlEWO6Tv7nB2EVK+Bzup6dh5jkBK/Mb
aIcno3WpEYldkNxNWN0BauB8xPuFr6W2GyffeAK2/whZ6Ati4uI7UDXYWxN6zTBVtylh1gbUl+Rq
s0o0Ki4d2ZBV5MbmueZ8WnS81gvbrvFtA9ZAxbVe0P7m2v2C66/xtSHVH+3x4Gse4G7MNcMCmAoj
a6MInACbjXaPyi5CfUsej+4HocjGTIAJ9C8CQ8QrRv9Kkm9qvO2taJZz67EYNcraEfu6879rbT6P
di+Jj3GjDBVNfzd8f5kI0LaGDyTOhpwRT3fBk+cn+OrJEmXfRoVIf0MTEmiRn24R5uwVdYY80RFH
/jp4o3DPU52KjUugutHBNkzgHa1lXaMXlVEJoetn83lSM6OFilFD43okXmtK2lubSQXFi6jYOCTo
OslWB3TtJTfNhIVSgIQwafXz2uO3ZnoTKL3dL4OIEhhRubej+TypiYTg6BOXl9w3t8JLuuCCaR/l
xCcJXbqJiEWXQlY9EZfzxEXUtrhR1Ha7ERR7ZQJMgAkwge4T6PcCf/ezyCH0GwLtVdg0ywZ9IySR
LlINwYbpIRTV+03iOSFMgAkwASbABJgAExiYBPqtSs/AxMmpDknAcxGn1Tl+6cyZU4L1LOyHRMaW
TIAJMAEmwASYABPoLgEe4e8uQfbfCQJeUpdoRAttzT4sMRGjgqiedCJAdsoEmAATYAJMgAkwASYQ
hgAL/GEAsTUTYAJMgAkwASbABJgAExjIBFilZyCXHqedCTABJsAEmAATYAJMgAmEIcACfxhAbM0E
mAATYAJMgAkwASbABAYyARb4B3LpcdqZABNgAkyACTABJsAEmEAYAizwhwHE1kyACTABJsAEmAAT
YAJMYCATYIF/IJcep50JMAEmwASYABNgAkyACYQhwAJ/GEBszQSYABNgAkyACTABJsAEBjIBFvgH
culx2pkAE2ACTIAJMAEmwASYQBgCLPCHAcTWTIAJMAEmwASYABNgAkxgIBNggX8glx6nnQkwASbA
BJgAE2ACTIAJhCHAAn8YQGzNBJgAE2ACTIAJMAEmwAQGMgEW+Ady6XHamQATYAJMgAkwASbABJhA
GAIs8IcBxNZMgAkwASbABJgAE2ACTGAgE2CBfyCXHqedCTABJsAEmAATYAJMgAmEIcACfxhAbM0E
mAATYAJMgAkwASbABAYyARb4B3LpcdqZABNgAkyACTABJsAEmEAYAizwhwHE1kyACTABJsAEmAAT
YAJMYCATYIF/IJcep50JMAEmwASYABNgAkyACYQhcMVP6Qjjps+tvc1VeP6FYlS99x6qqqo6/ldW
4syl0fjauGicOlSA31ZdQuqN4xAVMKXtEbgJ6NHHsLmmFM++VIVRU76GEYEjgurmNXwxdgrGxfm9
S7Wfxf6nD6J1bCrZBQnAew6HfrkPVV+MxY3j4nzij/imG2G0trYjJiZI2iJOQGCH504cwr5X/hiS
X2CfvWDaWof9ew+FLAtRB5999jgSptwYtLwjTZm3+TwuRF+FGFklmlG671lUXgxVxj1TZyNNX3fc
RVRnvK1ovnAFhqoAuhNdH/pVy+D1T0Z3qi3WHd+PopOtmBK0P+rDLAyAqHqynfWP7HpRc+RZ/Od/
/wq/+e1JXDl5FpKDPTB6KcHecyfwy30V1Nd2v+8KnsTe6aO61n661laD503Y9E7+QsfJtkyglwko
/fBoqchWKNuh/7MqKOUtSq6N3NlylKag+WhScmRY2SHcBPVsWFTm2Ck9dqWixTDqcKG6EenJVhr9
bFsqc2R+siuDp1RpqVDzLPPmF0Ckt10Kw6OUZFH+iGOI7EWagoDuIuEX0GMvGEZSFi2VWbIsyrsJ
pKFclLtNMcKh8rFTfbRli/ob7OiZOhss9J4xj7DOeGqVTMpvVkWIet8zCerZUFoqIygn/yhblJyw
/ZG/ny/3fU+1s/5Csa06X+3DtedXYW1bnydN7d9sIZ9V3U9Ub/RRXWw/XWqr4Qj0Rv7Cxcn2TKB3
CfTOcG43X1LiZvwAjY1rZChRUS14bs0N2OgCiqobsXAk4CWbqFgxAu5BTDKdWmKCjO6LIBLwrdpK
3PzpcHRxzFwEguiYePUsfwP/RMckqRbuLfhhXhqeWzvVdBgdI69jTZOOV3E3wl1ejujUaR3tIjXp
Uhhe/LmsDBj5bURHGk8n3UXCr5NBdtl5dARlMTR5JcpL7sKUoV2ORnpsqSulczJG6OFER0PWpNhQ
pHumznYv5eF8R1pnLqKCgrpvmA4gXLj9xH5oJOXUMa3xYfujjn6+zCY91c76C8PWcx/KpORUtmDD
9O48cbqRI9m/jey1vlxNWe/0UV1qP11sq6EJ907+QsfJtkygdwn0S4EfUXEYNUrvLGNVAQlOXD9h
FBJ8JGaPSockqIa6E3ht31E0IgYpM+/ANxdP1wR8L/5+rhEXMMxCshWnSn+Lk2/9CY2XgOsmz8Gi
u+dirE/YFudduCxY54RjcSWWj+8EYm87PrnQDPytFamj1MR4m+vwavFxuOs+xKWY0Zg25w7cOTcl
+AuOXxje81U4+NonuPX2sXjj1/tw6lPg2uum4S7HnUhJUNN27tRRvPl3kck38fyhFNx151wktNbg
8PHzSB7nQdkrrxOk2/DA6gX0+kQvXM01OPjiUVQ3UmCUpvlL7sXcVGFjHq1nT+Al12v48NNLSJm/
FNfJ0mg1HJw7dQRvNCbh7sVToWM/X1WK3/0RmL90AcZq2LznKR2vHMXpDymu4ddh0V0OzEqxxtWO
qiMHUHyyDpdk2afhHkuYMsL2cyg98DJef+cshk+6A9/4KhV6mCMqKgqezy7Il0vxillVehhnopMx
bdR5uIpexacY4VfPOgYoVLzy1rjIwo7iF/fjfOqtWHCj6i4en6Dq+D4cPFYnGd6Wdg8WTB2lBdIT
ddZM86SrGnDolZPEZzimLXJgyazxPoltprZT/OoJ1MnyHI4U2zd82o/MO8Yg4bNqFFd8iClpKzH/
qnc71JlRHap6K04cLIaoWqfKDuDI+amYv0At70jqkE8iLWXw9RHn8crB16kMYig/TsrPWFKj2Iui
8veBEeOx6L7vYNZ4vVapoZyjuvVy8euyvQ+n+u9YtgTj9S5GOiFVjOMHcehYNbWz6zD/9kRpqr7m
mylprjmOFw8dCxGO6TbUlUjP0bK3ZPsYnjITjm8u9klPaD5m2XaOBZXHoTIMu2UOPG+9gldOf4iY
4SlI+9ZKTE0gdcKnC1Bx9hKunTQT33IuhrU8Q6eHWkgE/UwgHr7tTHVxnhj/7rW3ZX0cPjoF31j8
TUy3FFZoe5HH36I5+XYstrSnGmq/9SPmYPF0vY2BVDDDlWXnnhOiz8vP30+ZsKH9T2U49EkyFmn1
PXT908rTr42tpH7e/1A5n8fNM0fhhKsY71D/On7yfNy7lPpsn/YXD09THY7sewkn6SEn6rzR53vP
4/jh1+AhRmafo5UhdcDXz78b0+lhGPrZE6iPAsLV69B9jX9ug913v622Up/327ebMfNuaneWruLs
iSN4nd7Z5t99B1o6yA2CUfefR6Hrb7A8szkT6AECvTuB0BOhtyj5DqHe41AqO6hX6HYd1X9sWSVa
5P7ThC1KUbrp3qZNvQKZSr0neHrduY4gaTD9qG7SlSKXppJkN1V7Wty55B9KTkiVHj81gqYKxaGn
z2aT/kUY9uxyM1L/K7/pTV19Rfjz/c9QquVss8bHsFfVliplfq1+VPOmSsuUtSVN6fmVRkqaKlT1
JRmfUHEwwtbL0L9MVK+q2o85Fd1WXWj6tYSTVdKgxdWg5Mi6ocZhlKUz31SpanMr6Ub8JkORptwQ
ZdFSKcpQTwupjtmt+TCvzXpmZN+4MFS8tPjTi2oVpa1ScRrpMcMR6cku1xXB/Pl0pc5Smi1sYBMq
aWp8zlyzrOqLVdUlaWcpT2S4FLU5BMi7/X+UX1jKI6iqm6a+pMcLR6EiqlwkdciAaFz45cfC0Gb3
LVfRV5QbGkQepTxbtF017zYj3XbFZahbeJTiTP8wOrJy56cHCMehlDToHYfWH9lzQ6rGVeY6zXCM
fDiN/i08ny6y0PoGnYV5tilG29HT4yw08hA+PaRcqaksmmHqdVvvZ4yC9LnwbWeK0lhuqnOaZQUl
3612/uHshVqknfLgozJHbc7fLJKy7Oxzwr+9I72I6nsk9S9QG8uXbcUHFt34c7br9ZnUSPVeUX/W
dCyLdEVipD5Rfa5kmf0kha33+fniwRD22ePfRwn/oet1JH2NfNaHbD8901YbijNlG5R9sg6Z1A/V
Z4Xg0jF/PfE8Clt/9bTwmQn0AgH0Qpg9HKQu1OvCojV43Q5Ken6F2kG2VCuZshN0Km5NoPXpRPQH
QmaxEVBFjioQ0DSsYeZ/EbnA71DcHtJvzlAFCGeuWwald8IhBX56MImO2J6jCmQtlepLQrpL68o9
9UqWlrdqXcbwT6h/GNqLBpw5Sq3MXotSnKXnV5eKmlThkDpa3cStd96OHKW6oV6prKimR1eD1McW
gnBhpSqcehorlQyZJptSLAQf6jQzpNAgBCqVp6rHLgQAvQwDC0a+jBuUbC3c/Ao1/56GEvngBtQH
lTtffcAYZU81oDxHFcoyiuslmfJsVdDNKNSE3CY9vaFfvtTysmtCWIB6ZoSj1zP/glDv1Yeo3RRA
tfIRQnKRW2XYqL1E6eUu1qZ0v86aaXbmVqjCe1utkiVfXGyKS77d1mtl5VQqGrUKRXUsW7oxy0p/
cUjPL1ca6t2Ku16Ua8c6E5CAJmRmV+gvMxHUocABaS/+oq1Xyvw0uQs1QdWsj7ogl6OtGTB0qu1Z
SrVaHZV6ua6C6qO21qatVnuxdOYqquzeori0NuLQ2qLSUKwK6Y5sI5zGykK1PjryNeHYr9wC5MNT
W6SGQ+nRZFilukgVPuyyr4iEj1m2nWFhvmxS25QwxDoM7WVI5+PRX6Idmg54JOmhGhtRP9MRSOB2
RoKp7LspXO2lXxXg9XwHs6fw/fo/GaO/WSRl2cXnhH97j6T+ifYeuI0F40V1lwaT1PdVeqHI0frB
QhpQoMMoC+q71S64TSnRXnqztXZRofWL5hqDerVvt6vr4cI/e3zrevh6HVlf49Pvdcy+0mNt1VOt
CveWZ54+UJXhEs8O3/wp9Ozr/vMogvobIM9sxAR6isAgEfhpdN5CpFIK8PoDy6/hWgSuzNwipbK6
QWlra1Na2oJJ0GrAvsKoJTLLpY8bGkXRR3KLKHGe6ghG+P0eTMZojj1dyXeVK7WNLTKtbfRCEfTw
D8OYWdCkHfKoP4TMlw8/RuRGF/itL0GeepcUsOxZvjMMTdqonOwom8qlEGT3WZTqUVxyVsUUIgN1
7D786IErXn5smfpMjZrj2vJipbjcrbR49FEx8WLRqDQ2NCj1DXSu1gQqObpGQqkQXm1ZxuiXCKWx
XB3VNvOvhm39DSyIZPqEo6c31EJu3Y3xLulXPjJO/SXJmR9YcOxSndUfLr5to0WbfVHLtUWprxYC
vHjN8ygtTY10X6HkOMXLql9ZIUNRxQmdUsc6o9v4nCntYnRVZx1RHfIJQL/R82NJh97GaDZCP/zr
ttoXQCms9W0zJXJEX5210ut6kdWNxlwX+KsL1RfJdHpxbGqkulbfoDQ11WpCQJC+Rk+U5ayP8OmC
l2rVqJS4XEolvUhFxqdrLAIJw21udcbOmp5q+SKtln9k6TGFTGt/4V8WFgzGpW87o34iQwwMQHFk
5CjFFW6lsaVFaWkR4+TiCGdPTgK1Lz+ziMpS8yNezLvznIik/hnCZYc2JjPt86ML84Xq9Kxqpwuv
ss+LrCx0AV3vp/Vw9RHv8M8e3/Yfrl6LPEbc14QY4e+5tqrQzJ8YDKLBD/mWr9etIG25R55HehzB
6rdPUfMNE+hxAn57R1JXOxAP+3ioGrdq4rU1mYEXLcVOx8+LaN8QlGH7uhWYMTkJQ4fOwo92Hcb5
nsx77FT8Z3m2DHHFmjzUenwUhiOKKc62HPnpNNletgdrHPNww+h4DJ11P35VfjYi/1ZHE0aaiyY9
nvA67IDQt7fB6q/t73+Fm0yX3jXFGjRtXXk7SDjH6fq/ofXM20SWHpNzrre4iULyHHr9CXfEWBhF
D5Na/8njR/j4Spm7GIvnToXY2VRdR10Gxw2jMTopCROS6Dx5hep+z5/QRisdVDcxMHMPxI4Y7RNm
xDdUzywpNLyFWn5rOPK7iLfeR9HaDAGw4ZK2ZsBqSdddrLOXWshv+mxoS8m1QNvlufTkB3SOw5j4
iyh+fA2GDKFFqomjMWHybGwsEKXsd9hT0UVqPgFFUod8PPjf+KTDI2upIzXZcOVft6PjRYk5kJrk
o+CMUZOoXdHqILXsRF134Hqrm9iJWEpvKgKhODytF+V5z6oZSBxNdW1CEhITb8AWiUp3JZ2E/Pnw
7TfI3oHbb7SuQxmFBUuWSD31TvHpJAs9Yda656GVHeKIjTb5eC6Za206lR4Kx9pf+JeFjCjkTxTu
zCih1VqAa+dGpM22YXR8PBzrn8Sb50S9DWcfMnDDMqKy7GKbMyLRLiKrf5pjn/L0D8l6b0NKkkXx
PGoC5oj+44O/U59nHqHKIirlduRQ/S7b8jzOkZc/HHyKfu1wLlTXDXT22ROuXneqrzGzEOCq59rq
zGXfo/DdKDpaS8r51XhmJ91mPIgZATv5nnkeha7fAbLLRkygBwkMDoG/k0BSlz8OT1sj7YjjQk5W
Bom1buzZ4sD386o6GVJo56Pm/hAu0ndB2TpMtq0K7TiQbdRYrM6rRFNDLUqK8pGZTr2624V1C2/A
obPeQD6CmNkxLtF8oAdxJI19Q0329adJtmf+1OQThJcWh4mlqROvGY7o4WOl3ft1f/dxA4sQ4Wuh
33lx/n2roKktyNattXP7+TqcqjpLuyRDE1UcKK6uRXV1tfnvdqO6do0UzqU4M3K4zyLnaFrsebmP
YCJisFLqSp2VLzsfNfkIAdHDVLH91huvo4dcDTYmzcaWPS6kZ+XCVVyO6oYGFJPeT2cO3zoTzKeW
swjqULAQgpm3XApcV6R7rd55/J1Y6qP6/tsCXzftaLRUYV0IziisQH2tWddqqd653b/EjYGEhAAJ
jpYvtS582ORL7XxdFWrO0pBDN/mEZKGlJ3Dd802PkfROpSfyfsYI3+8iavwCPKe0oaG6AkW52XAK
obRgK+al7ZEvd+Hs9eDifZp4tM+LeqRl2ZU2p8dvnCOof4bbiC9G+rlsReMZMqI3ObP/CFcWo3DX
elK+xE4cPX4cxVup701fjzn6e2gnnz1h63UP9TU92VZjU/5RvvQUPHsUJ149KJ9hOQ/MtTC0Yvbv
QFS7zj6PIq2/1pj5mgn0FIEvncDfXrefRjOH4JHfXMTUuUuw4bEdON1UQkI/jeaFEhw04tHWoeKw
pRCFJdsLQAuBjMPnOWSYBr6o2vsApXUG3h6aggXLV+PxvIOg6XbpuIZ28umNI1T24ibQbiIU6c6C
V9BsibzylRfl3ddTkxCbdL10U3DwNYubszj4lHgl0A8v5Ohz2VmYrw4NePUVq8CvShquF161zLy0
4/nv34AZto14r50e4lLIOoPP41OQmpqq/o88hx/Tar/1u9+Uo+XSTdlTeF0MY2nHe2+U6Jd9dw4F
NkwqulVnXc/ipGXq6nTxQRnb8BGxaK1+DXvojtYOIO+xtViyeC5Sx3pQvlXM0UR+hMsaySH49BN1
ZiGSOhR5zOFdDhuZTI5ceOblGotj3/p43ZQZZFfm48Zb8zs5ei/SLg7VDXCRdjoan6LVNarvx3fc
B5vtCdSr2VMdh/idMPMb0tZVVm26aj6OO26wYfLjr6Gv+ZiJCHzVt+k5j10LhmDIgl8hMXUWlq/d
jOdKW0BqeTTQ8S4a2sPZkztNLjvTeMHIUHt9FQrorjNl2a02Z8QMRFL/LM4jvCzD87+l3b20o73q
FVlX7Qtm+rzY6PbBzikL75F99Zp587CdHGU/uNAQdjv77AlXr3uqr+nZtqq99JRtxOy0rUQgE47p
+huPP7WeeB5FUH/9o+V7JtCDBAaEwK8roAR6x9btAjHR3VvdxCZ9TU4Z71yxBE/sK8WpE6V44sf/
r1RVmTh2eKBgNDMhXbrw2P/ZhE2bzP+1ax/Atv1WYcJ45qj+SLXn55pqjzCwpkV1EPx33OSpZOnG
wmWbsP/4CRynrQd/tkM8uuyYMylYxxQ8vOA2ugD+FDZu24e6YO8ScTasoxXRcG3E/AeeQOmpE9j/
xAOYLT6SQJ3lXWKYM9aGh2nVJ1zrMH/tLhwXfB+YADGAJA61TBJwI20vAXrMrNm0C6Wlh7Bt6QRs
l26kFE/hTMVDIpyyLbiD4jpOce199H6IXS5tmRswPTYW39ycT2G44UhagF2HjuNE6T48MHqhHKlZ
fP9cxNLjT3eTlvQA9pWewKG8TZixTjAklSD5G9lPZ8rNGqI6IuXCmkUPYO/xs1arANemSo81vq7X
WRFFGRaOXivrz/5dazF7CwG05+LeqXEkXN5ENYlcPL0D+46fQhV9DfnRBVQOWsouaIO+1rRoVnSK
sM5ow+ZbN32f2tsJeCOpQ2YkPleB0+HjpMNNytK18oV7z6rJ2LTrEE7QtnuPUl0T9dGRkwmxVfqo
eSshxjqFm0f3HqF6tBfLJ6/yCUu4ydTcPPDEPgqnFLvWOrBmDwWU8c+YbNGw8PHodxNnWyzDKVhj
w6Y8kZ5D2LRsnux/ctYuJM2HCNoYhdkVFn5Jiew2wvREFlg4VwmYNI3c0Izo/Y/ulW3+UN5WrBPv
n445mBAbzp7cDR1Om1tSr7B1HpXlIRzZvwt36mWpNfhIyrKrbU5/5lAS5BFJ/RMOO1ueO1fcgG30
/DpxJA932tZQCDZkOLQ9f2XMEfwkzMSDYgZaHhlYNiPB8BTJs8ea5nD1OtK+xkhAkIuebqspC++X
faCIzpG7HOMt8Vrz1zPPowjqb/spPEADkkOW5lkGzCyJ4ksm0B0CPb4qoMcDbNO20cxUrGvq1Gg0
O4fvNnjqQkl99xTNjWUhkNhdwyl3gFEXiBE/JT2nJOA2aHp29MVCwq3/vzPfLZ35xqv7FGexlZi6
W0yorSAVbRGis7Ba80y7zuRm+MVnV/Rda6wxGNd+YaiLsfQFmKorfacDfSGlMNV3ChF5Ewv41Pz6
+lN9NymubHVXCJ2DzZmt+O5w2agUZZpbIVJXqtDUPOWDtujT1062uLUdYzSe9gwlW/qxxkk7Cmm7
7uhxOTLylXptBw+RnoaKfLm4V7cXi7CyitzaIj81xbXF2T7bDjqcalnoW/2prnx/fbkFqWeWxY2+
vs07sbMQzYrIMrRn005BtBiQ5mgUh2VrTGPRHi0+VbPWE3VWX9hJuz5J9moaRFnpu8OIelmRr+4Q
Y/Aj+0Ktzqn1o00pdJJfS/vRc+dfZ3Rz33Ojki8XAYv49TYZSR3yDYXAqf2Ata0HYKkvPrS2M09j
hZJp3aKU+KfnFGsLpNV4PA3lSoaVU3pmx3JqcivZRl5Uno5Mqo96ndZ39rCm0T8b4p52eMrySY9/
nQ3Hp4ssQvCytoWObT9cevSFota2SyWm7X5k7Wf8cfi2M7KlXdaytfap10mbg3Y00rcPC2dPQTRS
n0Avska/6czKUTKpbM1dsEQZhCtLCqcLz4l6l2hPvhzC17/gbSwwLyjOdN/+tdDYBStYWaibGfiX
RZO2gYG+eNeML9yzp2MfFbpeR9LXaH1WmPbTM21Vz6lYSCs2KdB2mdON9f7Gp9/rgedRuPpLz2/S
CFCQrm5hbCSHL5hADxAYIsKgjvVLeHjR2tyMdm8UYhMS5CLQfgvB24rmVjHcGoW4hDhj2rXH09ve
TrrxxCPW1AQNFoe3XaSJXNMXjxPiAg9velub0dzuJb6jgvJVy4C+hzwqIWi+vO0UDuU/eFztaG5W
l6sNjUtAwOTTB8maW8lN1NCg6Q2W1+6bU12j9A8lTuHJhoqtM3W2FXuXxmMN8tF2cDU8VNe9wfIu
yrKN6lcw+1BJirDOtFMcIvxY+qCZfkRSh3S3PXEWdU22IqojYtF3oKO1+bzsE0ZRfQx2tFM4srbR
BwITggUUzLPFXKRHHkHS09d8LEkLeNmX6WmnvqOV+o5gbT6cPagna231wEsFnkB9ZrAjfFl2ps0F
i0U1j6T+hQ6BtlKoykO8rRhuz0FMbaN+kfIXR8+vINU5XHCo27cWN6zag6LaNixPCdCPd+HZE7Je
d6ev8ctNX7ZVa9Q98TwKX3+tMfI1E+gZAl9igb9nAHIoTKB/EmhFHgn861py0VS6Vn4huX+mk1PF
BJhApARUgf8FVLaUSnW0SP35uztfdQSvlJ3Ejo1b4SYVvxbqI4K/Fvn75nsmwAQGIoGuDgwMxLxy
mpnAl4qA/gDnRv6lKnbO7KAmoGqW+68V6GyWPyzegjVyT1kbin75HRb2OwuQ3TOBAUiAR/gHYKFx
kplARARIn0FsHmNVo4nIHztiAkygnxKgNi3UJGnTgu4cQi2l8aMWRI8Zj1HdC6o7yWC/TIAJ9CEB
Fvj7EDZHxQSYABNgAkyACTABJsAE+prAgNiWs6+hcHxMgAkwASbABJgAE2ACTGCwEGCBf7CUJOeD
CTABJsAEmAATYAJMgAkEIMACfwAobMQEmAATYAJMgAkwASbABAYLARb4B0tJcj6YABNgAkyACTAB
JsAEmEAAAizwB4DCRkyACTABJsAEmAATYAJMYLAQYIF/sJQk54MJMAEmwASYABNgAkyACQQgwAJ/
AChsxASYABNgAkyACTABJsAEBgsBFvgHS0lyPpgAE2ACTIAJMAEmwASYQAACLPAHgMJGTIAJMAEm
wASYABNgAkxgsBBggX+wlCTngwkwASbABJgAE2ACTIAJBCDAAn8AKGzEBJgAE2ACTIAJMAEmwAQG
CwEW+AdLSXI+mAATYAJMgAkwASbABJhAAAJRAcz6hdHHH3+MZ555BjfffHO/SA8nggkwASbABJgA
E2ACTIAJdJdAZWUl1q9fj/j4+O4GFbH/IQodEbvuQ4eHDx/GkiVLMHHiRPzf//t/5X8fRs9RMQEm
wASYABNgAkyACTCBHiNwxRVXYMiQIXj//ffxxhtvYNasWT0WdriA+u0IvxD0r7zyShQWFuLqq6/G
Z599Fi4vbM8EmAATYAJMgAkwASbABPolgejoaHg8HsyYMQPjxo3r0zSyDn+f4ubImAATYAJMgAkw
ASbABJhA3xJggb9veXNsTIAJMAEmwASYABNgAkygTwmwwN+nuDkyJsAEmAATYAJMgAkwASbQtwRY
4O9b3hwbE2ACTIAJMAEmwASYABPoUwIs8Pcpbo6MCTABJsAEmAATYAJMgAn0LQEW+PuWN8fGBJgA
E2ACTIAJMAEmwAT6lEC/3ZazTylwZEyACTCB/kbgiy9wyes1UhUVFQWxh7N5kP0lYR+FmBiL+ReX
yJ/VTHen+7Ta6WadO39BcXh94uicf3bNBJgAE2ACfUuAR/j7ljfHxgSYABMgAhdx5LEZtBfzw6i5
GAjIRby8+R9w6623Gv//8A//gBlr/wNV5y9JDxdrDqp2G15Eix7EpVr87B+En82o0sKtfWmzEYYa
HoVz/8N46eRfdV+dPF/EwfW+cXQyAHbOBJgAE2ACfUyABf4+Bs7RMQEmwAQEgQsBBf2ObO68ZyVW
rrwHtwirt/Zh9U9+Q68LdOjzs1dfaVziCy+ahB0d0eqJfofJq1vuvAdrVq7EnfMnAh8cw+Pr7sZL
tREmwghLvbjyavVsxuHngG+ZABNgAkygXxHQHxn9KlGcGCbABJjAYCdwZUQZvBPf+fHDuEFo7Pxg
CR6euxrH3voD/nxpGb5q+L8ShkJPTJQm3huWxsWi7/wIy26IkfffeflnuO+nB/D4r8px97bFUE0N
p/Lii+ZaHCx8AW+cacKwsalIcyzHrTck+DrS775oxhsH96P4DzW4eHEYkm23YemKxRgn3zUuoqbE
hZeOvYUmsktMvgnL7rsbqaPUWJtr38D+F4pR03QRwxKTcdudy7D45q/oIfOZCTABJsAEeoAAj/D3
AEQOggkwASbQOwQa0UiC8BeXLqL+D6dwTEYyBldbh2oajuH5X/8avxb/BS58ECQhn3tVVSBhfcOi
ZZgvLi5ewBfi7H9crMLmO+7D4/kH0NDQgMP7cvEv992Bkr+aYVi9nPyfO/Avj+fisIj8sw+Qv+tf
4XjmpHRy/o1nsGrzL3DgYiKSx17EgfzHsWrxL/AXEfHFGvz4vn9B7oGLSE4di8YD+fjX792Nl+sD
x2ONk6+ZABNgAkwgcgLWx0bkvtglE2ACTIAJ9AGBt/Avi+f6xDP/R3dgHA3pG8o4pJ6z6xfHfNxE
ciMH34/V4BzJ1trAv+GtvuRF+XIx/0d78R/fmoq/vvEr/KK4FUMvBXo9+ALjFv8vdti8mHiLDVF/
PIBj3/sFUFVLawtm4u8fVMlwJyZej9sdSzB50p1IutmGUZSHS+fexVvC9pZETL7lLtz+XzeheWgK
brku0JyDkTy+YAJMgAkwgU4SYIG/k8DYORNgAkygJwl4QgY2EfesWYjRQv4lxfnrb5yD+TMn+Pq4
ZQNcT65AvDC98C7+/e512kyArzP/O/nCcEuqGrafpfdz1eDWmZPkxVdu/Q7+41bdkfGqoRlcgaui
2nDyd7/Cpk1SfFfNtbUFyQtXYf6ut3DswC+w+oBqNX/Nz/CThxYj4YYFePTOIjx++AA2f0+1nHjL
Sjz804cw8yss9OvE+cwEmAAT6C4BFvi7S5D9MwEmwAS6QSDaUMAPFEgS7vvB91Ud/kDWwuzqq5EY
P0zV3Y+JC6rDf2WUKUDXHH1JfSn46oiA+vvez1WhvubseRr+H4dLtSXY7foTblq0FAunXuWXkr/i
2WX/gn20rPhne4/APu4vePSO75kvHfFT8YP//S8s80ajpfYP+J0rF8fy/xW3Lp6HZckxmPfdf8VX
0tqBtj/jzWNHse/wPvzv0UWY+Z2pfvHwLRNgAkyACXSVAAv8XSXH/pgAE2AC3SZwDD999DFMVDfS
oQWvjRj7j4/g4cVjjZDbhDq7Zm8Yigt9i/7PzEurvf/MweM/eRR/oIgufnAYxzRF/5995xsBBf7k
Of9IQR3Dgc3bMPrR+fhz0S+kfn78guVYaIlExiG+F6CZedr/grJCEugtbir/i/T7afB+/ron8H37
TUilSQAR/6jhMZSWAixetQuYuAa5P70DN93wB3pxAEYnxllC4EsmwASYABPoLgEW+LtLkP0zASbA
BLpB4INjh30W2t453xrYMMv2mlZz4IqrR4A22MQHo68yt+U0nIxFnD5zcKVmSLr+clEt3d4yfyVW
/eBBzBtnjvobXukiZsJivLTjI/x40y7kPq6q6dzzo1x8+2axS4+u0pOoxnHFODh+tgb7/jUfP133
PZLs78GdE9/CBDspuQAAQABJREFU4WO0m9DFZbh100vY0L4du3I341iuGsuan/4vZpESf8yo+/G/
j36M7z2ej3Wr8qXlLff8CGsXTVAd8i8TYAJMgAn0CIEhCh09ElIPB/LBBx9g2rRp+P3vf08z1lfj
s89oGIsPJsAEmAAT6DsC9EXdlguXEBUTj2GB3w3MtNBOQi1fXIH4IA7FTkMX6MvAMVfFw/phYBkA
xXOR4kHUVRg2TH9TMYPmKybABJjAYCAQHR0Nj8dDH12cgb/85S9ISkrqs2zxCH+foeaImAATYAID
jMAVMYiPDyfpa3mKGaYuHA6SxSuEfbCgKJ5hQS2DBMjGTIAJMAEmEDEB3oc/YlTskAkwASbABJgA
E2ACTIAJDDwCLPAPvDLjFDMBJsAEmAATYAJMgAkwgYgJsMAfMSp2yASYABNgAkyACTABJsAEBh4B
FvgHXplxipkAE2ACTIAJMAEmwASYQMQE+u2i3QsXLsjdeZ5++mkMGTIEXq++6XTEeWOHTIAJMAEm
wASYABNgAkygXxCIioqC2BwzISEB7e30wcE+PPr1CL/YvugL+qgLC/t9WCP6KCqxLdXBgwe5bMPw
bm1txW9+85swrtiaCTABJsAEmMDgJPD++++jsrIy4sw1NjaipKQkYvd96VDIs0KuvfJK/QMpfRd7
v96H/6abboIY6edj8BH49NNPMWLECAiBVnxngY/ABGpqajBz5kzJKbALNmUCTIAJMAEmMHgJ/Pzn
P8e7776L5557LqJMHj16FD/84Q/xzjvvROT+cjgSmit9vQ9/vx7hvxyFwHEyASbABJgAE2ACTIAJ
MIHBRIAF/sFUmpwXJsAEmAATYAJMgAkwASbgR4AFfj8gfMsEmAATYAJMgAkwASbABAYTARb4B1Np
cl6YABNgAkyACTABJsAEmIAfARb4/YDwLRNgAkyACTABJsAEmAATGEwE+u0+/H0D2Uv7oFr3949C
bGx/Q6KmMSo2FgFTRls8tdN/UPu+AdlzsXhbca6xlcKLRtzoUYgLmOmei45DYgJMoB8R0Pqzjinq
ub7ZS3tfe6NicXm6+jD9eceMswkTYAJWAkH7CEQmBxn+ffsU2S/IePzMm8+joS0K48cmmKnwtuN8
cxNod3EMTRyLhFjTyrgSskxDOxLHj0Iga8NdH158qUf4q/KWY+jQoZb/aAyZthR5pWcjLgJvax3y
Nj2KU0JG7YWjKm+NTN9Tp5oDhn7qKTUPwewDegpi2Nt5CRKtYVxz6AlMi45HUlIS/Y9GfPQC7Cqt
M+z5ggkwgcFNoOpp/z5Z758X4UQP9LHtNfsQTX3+nU+d6hOQ56sO4dFth6B/Xqdqb+j+vE8SxZEw
gQFLoBV7l0dbZDa9f1DP/xlETjKza/W/3OhT2uvUfkHKg3c+BVPaakXBstGY4HRpbdiLU/u2kZwy
FKNHCzklCYlDh2DtriPw757OHv4RkibcgdP+FmZi+vzqSz5+GieB253pmH3NMHx4phQFLhfWLXQB
7hasnaraBy+VdhQ4bsC6MgfcTwZ31RM2MVTBAh3DJyyA0zkGE4Z1tyj7Li+B8nH2yKOY7NgurdKz
cjCuqRRbd7qwceENiK9uwerUcGURKFQ2YwJMYGARMPvkadQn68fFi1/B8Gj9rutnj0d9+sZ3PYjI
fXqr8H2bAy57PrY+pnobljiV+uv0HuivI08Gu2QCg4lA4q0ZSE+mHH18GnsKyujCjvSMaXQPpHZK
DnLhtfeaMWtWAupPvGYiio8xtSna61FCUTgL58pR+rr9j2DGqp3SrTMzGzNH/BVPb9mJPRvTsOdv
xfA8vljz60V1xR5KWi4m9SPRpbtSoglpAF/dtzmHhHt10mXz3rWwrdmDdU+8jO88t1It5OP7sLug
GGc+AsYkT8I/P7gOi6eOwtnSX+FZUd9wBk9s3YVNj6zH9IQo1AVxHwzR+aojyH3m/8P7Zy5i2I3f
wNqHvoPpY30ngX5fvAeNu0+i8uI1uPehDKycNV4GF5VwDSZN+jrGjNRfCLyoOvQ0dj9TjI8wBgse
fAjrl0w1KrD3fBWe3rEbxe99hLjkGVgVJi/B0tyj5t467ExThf2cikZsmDWKgt+ARV9ZitlbXHj/
nQZqyalqlDSjsu9/nkZx1Xt0n4y0dGIxV2XRfrYUT+58HZPvuQ1/L36B8niR8r8ZjuQzyHuiCB/i
GjhoNmb5dAq/nWZmnnwal1LmYdLnJ1F4sBLXzHDioe9OwfHdO3CQ/M5Ymo6M1XNhtNdwcee9iuHT
52Hsud+ioPRjJM9IwyOZKzGWW1mPVhcObPAT+PZP87A6pWM+z5bmIe/Vsxg6/g48snYB2k7tx+79
NFo/ntra2rn4SNi/HoO0RYkofqYI78n+8hHqL8d2DEwzCd5ft6M070m8FXMbbr/2A+zOLaYHwAys
2ZyBBSlqr9B+7gT27H4GpaI/jRuDmY61SF8+nZ4b5Pep3aChI6BsDTbmfRU5lN6ohHHUXw/HOKO/
BkL1/zK/lJ/lS7+KV3bnU/8/DAtW+PbpQTPGFkxg0BGIw5LNO7CE8uWt2asK/I5vI2fH6i6pzRx5
7X1snjUDp0i+CnS011ehgCwKpyeRzFCFn65Qhf3skgZsXqD2Kevv+ycsmpCGsu1pOPjdNixPEbJb
A8pJpLHn3ASLIlCgKPrWTOmnB31KWRk2bFivps6d61SItpJT2WTG01apOMgMjlylhUxbKnOkG8Cm
OJwO7dqhVJJlZY5+T+5FOBVNId2bkZhXTZW5WpgUhk0Nh6qJUtzgkY70NIrwbXa74TZXS7OehmyK
WxzVhemaG5ti18Jz5rulndJSoeZNhGWzGWEV1bcFzIvqqXd+P/nkExk/fWlXQFbTZc9RLCXRMeK2
aiVDlI38N9OfXlgt3ZplJVia9pKdce9U3G3kXI9TC8tmhCvCN/3muEUtoKMzcVv8O3I19moonf6t
rq5W6EvEnfbHHpjAQCSg93eO9CwlOztb+89SsnJLFNFslRa3kq611azCQuOaBgpkdvX+UPYRRpuH
kutWe5YWt9rfOnIqpXuzz+jYv1NkSq5d729En6lfZyr1wren1ojf7nAoeh+SIx4Ofn7154mePr2/
Dtf/6+7981NYK2nIPPAPExjsBLZv3644nU6fbOptmUbRO8gNv/3tb5Wvf/3rPu7VmxYl30Ht2J6u
OEXbtpHMQc922aeQfCXbMIWnPfWVWilPOZVqKTNo8pMtW1F7GzP48ixVNjNkyYZiKafo7dx0aV6J
Nk1f2jUN+uDqS63DT8ADHnLsxnUK9ULxcuQilLiKUFL9Kp7ftQ2ZVCPEQWs1MH1DPnLp7UBMKZU3
KTQyTe9yIdwLl75HK1780TpplFvRAOW0guoiEmlRhi1Pl/s4zXTV4nRpKRpKsqT5C6+qn4yOjlFH
mmLldPdZPLtKvKnaUdJwGqW/d4MqMgrWPIM6Wptc85I64uTIqcDp06dRX5wNhzMTV7d5AufFJwW9
eENpl7mwTqUFiK7uwA6I92t7ZjHalNPw1BdTToE9q36GKlFW0THSly2jCB7KHz0s5T298FB+T2hl
1YqLovD0OImQu+00TlTmSLewZaGBwm4ozpT3pW/Uy3OkccOejUaRttoien8DXMWVHXT7ZID8wwSY
QFACrj1bsWXLFu1/K7auewttwnXcVPzCnS/9bV21CqK3E/2ZOisougC1P0ynNq9QH9BQrPaXT/36
bemnw0+Y/jomXviwwVXvoT6kAVmy/38Pf5OaQYl4qLwYrpJqHN6fj+wstb+hsUfyE4e1rkqoj4dc
NB1cK/s4PX1qfx2+/9fd6/kpz1bj+PhTSaNDdtiACXwZCXR6Ej3p60hbTG3JXYrio0dlP5Jx332Y
LeDJNi8u2vH2a9TDONIwgQbt2xs/VGfskkd3mE0YdR3NAFiO8zUn6c6OOZP61fg+WOC3FJJ+Kfty
+3SMo0KOGxONP1f8Dpsmj6bV2DZsd6uupHxNijKqiBmPq7QaF9q9HoN51h8oN96oTg+l3v5PUlB0
l71jWThCK8ET1FqYOF6d5y478raPvQyx9W8Qii7ihWFh0hAMibfJigyU4hw9HzyXpCXS7NPkxfjF
m3HwucexWOrHd8yL6roPfkkAl8zPfKotjFHjFOpHR45XoVlb8SbkdHHc9635ssFFjZ+Pb8vnnybE
q9ZITv2aVGHSH5bfmDGBbDxaWUlZX3NJJ8cc2Zhjk2+WLw+2u2ZiNBknJk1S3VxSY400bsd9aRAK
SVFJX5PliJZL8vGvBsa/TIAJREIgu6QebS0taGpqUv9bNhhT43FTV8Pl1ENJx7b1s/Qb4zxu8jh5
PXbGbbJduyt8+1PdYWT9dTLGJYoOPg7XCd1hOmT/HxUHz0duPLNpMoZGJyJtq0u11H/1QQXquoMJ
JJH2/9NlHwaMGK6+0OhR8JkJMIGuELgG0+csII8urHJspLMNt8280TcgbwNeF/L+0qlS3ohNvE59
gT/zYYdBvPr3NcFQC6Hm9f0U5GKk9i95nwV+UT7WBbGnns9T3+ImjoTQij+152Gs2b4Hs3PL0dLW
gBwxpBzg0NfURupeDcKLSy3iaiQ8mlDb+uH7kFVn4lgZvx6VsYzkorrozDZ7ivEA1N1g6DVQqywt
FKuuR0OtG67CQhpl3oNUyoznkur31B8bpJf2qv3YtGkb9p84ZwQhLvS8+Bj25s3Q4aSNT4d7C3KN
HZLacfAnNqTNs2HZr6pk7J5WWkRBx6kqNf1CT+603zNWOtCEdHlNP/qt9r6jG2tnzXToVfLFPnn8
aPlw9sDXdefj1l4RQjzs/RLCt0yACWgEho8ag9i4OCQkJKj/cUIvVj28545gZ4F+twePPXVCvzHP
F8QoO421//3PNPxBh19/KozE0bn+WvWj/7ZXPY0ZK7bAZcuBu7ENDeXZ0iom2l+8j1FfEHSPxjny
/v+SR82P4ZUvmAAT6DqB1s8xZoo6yKcGchduTh7hE5634W2pUZCmvWwj7hpNTtmKJ/fXGG6bq/Zh
ixwJtmHCSPFCfh5vbnXDtmqOHPwzHPaDC/+eqR8kqe+TsM55P35vi0OruwAu7UWtcPPdvtM2ly7g
D78pwEb59CDhWet/VYHdhSf+z6NYsSkT6rgS5SGIe9/cJeCmpTREXebCwjseQM76qShdt0U6yX7w
dp/4t8xbhtj8+/Dus6oK0IJ5AVa0RSVhupO8F7hQdOheYPQ7cKyhlSM2UjM5PQs3LiIzep3Zs+L7
GJe7FO8/tREFlN/Ee9Qw/fOypK92xolKwSOkqrRzIU3dL5yAyoxMjDmzHXukMG/Hv987VTKZvFhk
jtK/6h6M/Hg9cPIp2SCR8SBmUDvr7CS3+vojgzZ+aEA+4NHluFvUCf6AgbIhE2ACAQk8tZH65CRz
NLuV3vHX5f8Si8c34T+dtECOfGXk5ODMxo1wbZyNPLvvrmpbF96BmPz1+KvWX2bQzJ14ZdBn6jpE
Gqa/1v1ZuwfdTEz9f/Kno9g9T+27a/7YCIgd3miTbtnHnHkWmbuuRdaGxX7RRt7/+3nkWybABLpD
gJ7LQxOmYLGNxC8h86XPw/i4aFy0hNlw+nW6c+DWiVo/RHJKBqn6ig1Gdq6YjFJnBu665mNs10Yf
7Fm7sWQ8idTNNSgkn8vnpFpC6yeXfbBOoEtR9Mmi3Xx10S4VhaL/2x0ZisttLsloqy02FrqSTpbi
dKiLM/TFGKRzb/gVi7XCue8Io0lxZesLbUU6bEq2q9pwpi5isykZGWZaHVnFxqKSai0PxmKRtlol
x2kuOoUtXSmhRbn6Ue3KNhaXiTyn52iL4ciBf150P71x9lm0q0VQX5Kr0ASKwVMsrHFpi+30NNSX
+7pxZBYq2vpmWs+nLcjLVRfk6QsAc+UiujalKF2ErS64VtrcCr0+GIuzFVqsLe4dml//sET8nYlb
Dw/OfKOs9Dx05syLdjtDi90OdALV+da+0NIXUNsUfZy6iI7MnflyEW+9K1PrLzKVWtrnQG/zsJkb
HDiyXEYb9G/XoftrbYEfMtRFexRKvlOkySk3bVCUBiU33exrHelOtW9NL1IXGNPSvlzpXvhR+x09
ffqmCwotNwzZ/2v9e662eUBH/wO9xDn9TCA8gZCLdrUNVqyhhF+0myvbaEW2uvFKRhEtw/f4ygQu
IS/YzAW8evj15fmKw1jAL9q2TcksrNDaPC3Xr8yWfVKJKUbqXn3OQv7q60W7Q0QKKOJ+d3zwwQe4
6aabcOHChX6QtnY0N3vojTDOZ9RdT5i3vRVtHvoyrDHtHNq97s/nTF9ua21tQ3RcQtAvQPrG48W5
mjdR8LOHsIWG6WmHIHXRsBZoe2szjXhHIYGmxTscFFczxRU1NAFGkjVHvnF08NljBp9++ilGjBhB
eW4F7UJjCdeLVvH1Yxo+M3larOUluSF/Qqc2rs8/xdu3cdfU1GDmzJlafv058D0TYAJWAlV5D8C2
rgAkIGPtZFob1Gbtl60urddd6K8t3kVf64mmvijIp3vbRV81lJ4doebTI+j/LVHyJRP4UhH4+c9/
jnfffRfPPfdcRPk+Sgtxf/jDH+Kdd9TNTSLy5OcodLsmOaC5Va7PG+ovs0n5yoM4khdDNfkhQ4aA
BH758S6/qHvtNlR6ei3SgRdwLOmRignhwEdUrOjsrXah3VtdGtf0qfe4EHEId77xNGP35HkghR06
7LjZbzV4rKiE0i7AD8UVLD++cQTw2+tGUeqDM2jiRQLIDeXv8hyXM+7Lk2OOlQkMFAKeS+r6nk8v
0qBBFA1oBBjv6JiX4P1hR7cdTUL2teRcrEUIe0TQ/4cNgx0wASbQYwRCt2uSA2h9UcAjhHwV0H0f
GrLA34ewezQqbxTSaLvQSU2fI2VuGuYGqXs9GicHxgSYABPoxwQmOnJQfvMnGNufPm/Zj3lx0pgA
E/jyEGCBf6CWNY1ezV2yHHMHavo53UyACTCBHiYQN34qtA9v93DIHBwTYAJMYGAT4H34B3b5ceqZ
ABNgAkyACTABJsAEmEBIAjzCHxIPW142Al4v2uk/NjakMn+fJM9Li3C8pEIVG3LVXZ8khSNhAkyA
CTABJsAE+oqAtxXnGsUmIbQBwOhR6PN9QnownzzC34MwOaieItCKfWuiMXTonTghN7IOF247Tuzd
hr2nmsM57IJ9K55eNJTSsjzCtHQhCvbCBJgAE2ACTIAJ9CsCNYeewLToeLmTTlLSaMRHL8Cu0rp+
lcbOJIYF/s7QYrd9RCAan0tBPz7IFyp9k1Gz937MXrMVl3rpE8Ex9LVccUSrJ/5lAkyACTABJsAE
BjGBs0cexWTHFsjvcmXlICuDPpJKn/zbuPAG7K2JaCSy39FhlZ4eLpKzpXnIez0Gy5d+Fa/szkfl
xWFYsOIhrF8y1diTte74PuwuKMaZj4AxyZPwzw+uw+Kpo+iDjXXIe/JpXEqZh0mfn0ThwUpcM8OJ
h747Bcd378DB9y5ixtJ0ZKyeSzvQq0drXSl2PkHxfNSK5FudeGTDcoy9/Fownafafhb7ntyJFyvP
YEZaGv5yxjeI9nMnsGf3Myh97yPaam8MZjrWIn35dOBsKXbskJ/kRfHuTOCfH8LaxSkI5j4YmrMn
9mPnbhfOUDtOvjUND/1gJVJ0yL5JCRm2t7kOL/5yN158gzJA6Zyx8D48tHoB1E2UWnFqfz7yXKX4
qDUOY278BtY+9B1MH5AF5geFb5kAE2ACTIAJDAYC3jr5RV2RlZyKRvrGEcln2IBFX1mK2VtceP8d
2v43NXXg5dTn01/96KYvvrTbG9mtzFG/3EY1gb7SZn6FsbBW/dptS2WO/Aqb+Dqbw6m71b7+2lJp
+aqvzeeLuMK9DFN8cVL76qKnodhwY7dr9rZs+r5j/z98v7TbpOQ6xBfrBDO7kSf965SKp1ZJF3b0
b3c4DHvxZWOTp2rvzHfTF/OCuw9EpqEky2Br07+gZ3DUv7aplVHIsNuUQu3Lms6MTCVdz1NWuYy2
oVj7KqgjXcnM0Ms+XX4hNFC6hBl/aTcYGTZnAkyACTCBLwOBQF/aDZXv4F/aDeXLYqfLYvYc+hZ2
7xxCnunrL+2ySg9R78kjOkYdFk7Pd0M5fRrl2WIaCPj40zY1mpGLUEL755dUv4rnd21Dpk01pg/L
Sp0RzTfcbadxojJHtbRloUE5DRIY5X3pG/XyXP1yoZxuyiyuR2lpJYpFYO4tOFA1wKabaPT+KTFI
T/msP12K023VyNC4yIwiEQ+VF8NVUo3DNEKenaUyBX3nLm76BlTS9+vFkU1v4s+tnkpXwd1Lhz4/
rXh511YysaGotg2nTzehMMOJ9LtG42K7j0PtJlTYbfhY/e4Prps2Dw9tLUZhUTnq190k/f7NXSHP
tjFfh+PBTBTlF6Gy9t+QxPNsgUCzGRNgAkyACTCBvidA+rtSFouPMTQz+j4RPR8jixo9z1SGOH3G
BHkeMVwV4fVo4sZE488Vv8MOxwoprOvmVL/MwzEHE0j3JDb5ZvqGLvD3u2ZiNJ29SZNUN5fE60E7
ztQI7TJge9oE7Yu78hbyK5Pq5YD4bf3b+5KFfdV8jBcpjp2Aacl0VrNHX8yMg+cjN57ZlgaHbmbJ
mc4uNlqrzmHcW7zKyxj5m4zrkwg6fZ945Y7nsNLfkX4fMuwE2L+XQWp+O7F9TZrxFeRs11PYvCQV
Ny7LgGNLGVx7NmL2HjVAR2Yhfvn4yuBfRdbj5TMTYAJMgAkwASbQ+wRIxJLDpmc+JUlLE/7p7D1f
hVdrgFkzpyJBiAsD7OAR/l4qsEse+rR7gOPUnoexZvsezM4tR0tbA3KERN/huKSaDL0KYr1o8vjR
8i3TA81c2sZiXLKQigFnfgUaG+tRWVxEI8rFWDLAvjIZPXyszEfZkbfVRka/jS3SSP60Vz2NGSu2
wGXLgbuxDQ3l2dI8RhfwNacx2qLdSN2r3ry4JONqwQVtEuZE3qPYtC0Pp853LMPQYXsxbv5DNINT
jBIqi+xMMfNQhi2OZ3FWRJY4B9topqK4pASFOVlw0CyGa/uqgTcjo4LjXybABJgAE2ACg4/A0OGQ
0hVpTOSWyqc35bEdB39iQ9o8G5b9qmpA5pkF/stVbJcu4A+/KcDGMjUB+vtBIGWcFqucb0nvtZNu
lHfugy68Wfk6dqStwKoVaXjHIixbnPfby9iUmcgUqSvbiPUkaO/adB9oINw4pLqTvGvHJ386in+f
t0Xe1fyxUZ6j1SF6PPXYRuw6VINw7o2A5UUCZi5VV9/PW7YJebsexex127GT1HGi/TbcFeGGDNtb
izVJN2Ahrex/B9fh9tlCvYgO27Xyxe3Yj0fDNi8Nua83IdV+G2ao72v4ysihqjv+ZQJMgAkwASbA
BC4vgagUPFKSJdOwdeEELN30KNYuHYoVcmbejn+/V3u2X95Udj723lmO0P1QB+qiXXe+Uy4AzdUW
1rpztfv/n733gYvqOvP/P7agoI6KVmMkWf+g+Uoax0RrtVZtB7uuNm2GNtqkcdwNaYNuksqQbWTx
Ffl+g9kSdH9ViHFR12Ij2D+YNuM2X4jfAF1MLdZCmsFkWIU4rMI2ECEy1Rky09zfc8698w+GvwLy
5zkvmLn33HOe85z3Oefe55x7zpkKdemHs6YwYGGuQTEZDTJ8Zjldd1oVGhNWYMxRWgVCZ4U8N+ZU
SKCt1hwZ1ntOAZTyXLP0o5Knb72SbrHdOvxBkBC8aFdRWmssfi56WtSaKBYhawtllXolR56rC3ON
iSZ14W5iARGgNbq0eNkg80+LerMEq67Dd8xeo5Kf6l1EK9IwKrnl3qXP3kW7iYpNrrvuWnZjRb4/
H0InvUkpsGqyWm1Kpkktb7W8oKTmlsk8dNRJ9eFFu52RYX8mwASYABMYDQQGfdGuBtVenOOzLeQz
25CoWKz9s4xXyBvsRbtjRL4o4SHnLl26hPvvvx83btwYcrrdukIutLS4ERml65e52x6XAw6ajhKp
I3nDZFXG9evXMWXKFDgcDkycOFFD6oJD4xIqGy5HC9zhOuhCZZJ+DdfhJKbEwBu3y/AhCtFDujho
Fo+OysUrI0Qw6dW1bA/ly0m/zhtallpeHtI1qtvyqq6uxrJlyySnznRhfybABJgAE2ACI5XASy+9
hPfeew/Hjx/vURZPnz6NZ599FhcuXOhR+K4D0fPcRQ9zer2v0/XfxP0xY8aADH75o15dp99/V7uz
a/ovJZYUQCACUf244iMsQjcsF5AEANEOI8jY7rxBRQgDuWMk1SeM4rZrjF2GDyEnjDoL6n75IS62
8+padhjpErxYOzD6yCmvwFzxMRNgAkyACTCBkUaAnudikLFT42P45Jfn8A+fsmJNmQATYAJMgAkw
ASbABJhArwmwwd9rZByBCTABJsAEmAATYAJMgAkMHwJs8A+fsmJNmQATYAJMgAkwASbABJhArwmw
wd9rZByBCTABJsAEmAATYAJMgAkMHwJs8A+fsmJNmQATYAJMgAkwASbABJhArwkM2V16rl27BpfL
hbFjx2KI7hzaa9gcIZjAZz/7WdqtqKf74gTHHU1nov6Hh4ePpixzXpkAE2ACTIAJ+AiI5+DPf/5z
33l3B0P5uSm25PzMZz6D1tZW3pZTFOTkyZOlsV9WVgZhGLrd/t847a6g+ToTYAJMgAkwASbABJgA
ExhKBMLCwvDpp5/ii1/8IiZMmDCoqg3ZEX4BRfSC7rrrLmn4f/LJJ4MKhhNjAkyACTABJsAEmAAT
YAL9RUCM7AuDXzgxmD2YjufwDyZtTosJMAEmwASYABNgAkyACQwyATb4Bxk4J8cEmAATYAJMgAkw
ASbABAaTABv8g0mb02ICTIAJMAEmwASYABNgAoNMgA3+QQbOyTEBJsAEmAATYAJMgAkwgcEkwAb/
YNLmtJgAE2ACTIAJMAEmwASYwCATGLK79LTn4PG44PH4fcPCIkAb+Qwp56HfDfAgDBERnShGeXB5
urg+pHLDyjABJsAEmAATYAJMgAmMBALDZIT/L/hZ4jzMm+f//5u/mYW1P9iHymsBvYBuSuSa7TQy
9p2Gq5twfbp8owqJQj/TT3E9pIAbOP4oXX+ws+shI3XqOaB56TRVvsAEmAATYAJMgAkwASYw3AgM
E4MfGKuRXW96Ek8+acJKOre9thffWLQb9p7Y/B4bnlv7OF7+XcvAlBFtpyp/QmHSWIwLmcJncVec
CaZv3E3vAG7RDXReblE9js4EmAATYAJMgAkwASYwdAjcsu05uFlZj+d+9AJihdYv/BOOPvEAdhUd
QW7Jk3hh3V2A5xpKf/YqfvWHKty4MQELvhCH7/7DtzBnggtv/zQXRULZs8lIOx6N9C2rENFp+E5y
dcOOX//0ZyixXaIAdyOOOh/fWk7pBrrWqyh+4yiKXvsdBfkyErf/AxZNUzGPnzYHczAZvp9a8HyI
Nw4fxGt/vIIJn1uER55KxKo5/l9eu1r5Bo7kFuHKDRJFeUnoIi9h1+34j/xc/AfJImFYtOohPPHI
KkqNHRNgAkyACTABJsAEmMBoJjBsRvi9heRs8x7dgb979El5cuWKOmr/9t5F2JyyF6+9T96t7+Pl
F5/Gyuy36eSvuFyY542IvNLL5AN0Ht4X1H/gqsH/XrAST7/4Ml57rY7+j+Dpb30RO35d4w8jjs6+
TG8gduF/Wovw2pFd+DvfG4i/4mLBi3jx8AWoWbiGo48+gCdfPIKi1la8lrcX31m5AKevqhOOPnx7
H774jSdx5LXXUFf3Go6IvDx0ENdC5sWF/3he6HYEE+5egM/dyMPe5O8gdt+5YN34jAkwASbABJgA
E2ACTGDUERh2Bn94QBF9bt69AWcezIn/NY4d+yX+cOogMp57TL1W8V80p34Ctvz0TawXPiszYfvJ
FvLpKnyAWO3QXngYR0T0H+Tjg4Zi/Pcf8uW0oryns2ALWhSwEvnvNODkyQ9w5MlYinEExTZ1Vv/Y
SXQaNVZO6XHZ/i92naVz0yuwnTyJql8/TyfAz6kzAtzA6Z/spe9YHDn7AYqLbXjlyYdh+to0OF2h
8tKG5v8RsYFZ965AQnI+Xjnya/zh7+9TPfmTCTABJsAEmAATYAJMYNQSUOeaDKPsuwN0/ei/xFA+
DebLzzDowm/id//xCh5/XFjSmqM59TKTvjn20ObQdxPeG1/79mjfxvgvIUIc3/UlbKIexNmiG3CK
1wXeeTqxcbj3DhEgAndOEd+hnYgiXd7TiKV/ryv6QzVcW/5GW7MwG38zU6QWgW+98DK+5Q1EHQx1
vYA3L5OxcjO97Th7BC8nb8bLMtxKPH/sJTy1br43Fn8zASbABJgAE2ACTIAJjEICw2+E32tYe67i
TZpWI9zSeVH0eRUH12ymKTDAK795Bx9U/Vod0ZchAj/GarZ5T8Orcd1/+UgeVFX/WRP2Z7wvFwUE
yqZj2x9hpzn30o2brX4H9lK0S96v2Cdfwdl33kHZb/Kx75Uj+GXiMuqQePCJ7MW04qY2hanyeAb+
977jqAralcibFw9mrUzAL4/l45f5R/D8Dx4m8Wfx4uMFRIUdE2ACTIAJMAEmwASYwGgmMMxG+Ivw
wlM/wJ0TbuD914pgkyX3HJ4w0MJZj9233eYnN+0oPLxXXaTrLd2/ummiDLm6AmQcnYEd/zC36/De
eNr3AoMwoouQ9/T3ENX8OPCnY3KKD558FHox3E7CVTu/CN/6QQb2GYDkF0WPYCXuixFLZ9WrdCDd
hLn3yw5J0ZF8FH9xCsb+4RWkHDmLh18pw6pFd+H+DfL1Ab71vf+NzA0RSNklxu3X49F/3EJLEtrn
5W4kP7CGtIvF7vy9WLFUTCUiFzsDOvWIP5kAE2ACTIAJMAEmwARGKYFhN8J/tug1WjArjP1YPPyD
TJy9lAw5gyZsDh595QdUjGeR/J1v4elL8/CwsHuL/oAPhK09YTakzW47iyO7juODtm7Ct6sQYXc9
iD/8OpPMdxte3pWCl1+zYf0PXsE7u9apU4TGRdK+PcKtxMN4C8kpwkAnA/zX+7FcbpXjfTUhA9Es
nUXYV3yETPiz2PXkZmnsr3xyH/7Pt9QpOIu+txev/EAY/Ud8xv6+3+xFrJjh0yEv87H3zVdIlg27
Nn8D33j8RUr6YRw5EM+79Gi4+YsJMAEmwASYABNgAqOVwBiF3FDM/KVLl7B48WLU1tZi7Nix+OST
T3qmpusGrv/1s5g8QVjGHZ3rBln/4ybA92O43YTvKMFDW37KHgQmTOj8BcmNG9fx2XGTtXRuoObt
3+BH30lGkVg0fHJLgCHuwvXrbQgjnSb4lPKn6qG0btACggmTJ2hrD/zXOuSFpgLduNEmf5E4VHh/
TD5iAkyACTABJsAEmAATGEwCn/nMZ/Dpp59i1qxZuHr1KqKjowct+c4t1kFToZ8TipgQYEx3lB0x
QS539V/oJrw/oPcojAz97ne3DwzjsZ/GGjL2pbtzYrsf5orA5MmhOycifBjp21lqHfJCXYKuOiGq
AvzJBJgAE2ACTIAJMAEmMJoIjDyDfyiWXtQiHHtlH26MnYFlXzWou/wMRT1ZJybABJgAE2ACTIAJ
MIERR4AN/kEo0rDJ87FOm5s/CMlxEkyACTABJsAEmAATYAJMwEdg2C3a9WnOB0yACTABJsAEmAAT
YAJMgAl0S4AN/m4RcQAmwASYABNgAkyACTABJjB8CQzZKT1tbW1yJXNFRQXCw8Phdnfx61XDlz9r
zgSYABNgAkyACTABJjAKCHh36RFZHWy7dsga/C6XSxr627ZtGwVVgLPIBJgAE2ACTIAJMAEmMBoI
TKAdGIWdO5huyBr8kydPliP8Yp9SdkyACTABJsAEmAATYAJMYCQQGDNmDHQ63aBmhefwDypuTowJ
MAEmwASYABNgAkyACQwuATb4B5c3p8YEmAATYAJMgAkwASbABAaVwJCd0hOagofmPHl8l8LCIhB2
u3PgIZ3oPyyCdPFp1rsDj8cFjycMERF9ldC79Dg0E2ACTIAJMAEmwASYwOghMKxG+KuPJSAyMtL3
Hx4+BvHJh1A7uOsegmpH5cGNUp8fn2sJ8u/qpKnyJLJPVmlBGpCxVORpHc45uorF15gAE2ACTIAJ
MAEmwASYQO8JDKMhZRcu/N4qc2gwmWG4B6g4uR+W/dtg+UiH1uOPYXCXP2iwJy2FyTQXX7i7Z6nX
nUzGnE37kVnerArwuDE5zoTEjUbc0zMRvS9ljsEEmAATYAJMgAkwASYwagkMI4P/Q1SWC4PfgIwj
+7A8gg5Tn8HOpfORkfdLvJ/9GJZHkZ+nCacO/gg/KbkM6ObiO888h8eWz1IL2NOCkrwjyH39LBzU
Pbh3pRFbt2/EbCGLnKepCnk5P0FxBcW9Yyk2J2/D+oXT5bWWqpPY+7MPsGbDF3AxLxvn73oCR1IX
o7oRWLbhUayZRSg9dTiWcQhXxs3G3RGNKC6pwOdWmrBzx0YIKbVF2XiSjH3hUjKO45GT23FH/X/D
NfUe/O26lRDqC1d75gQOHC7EZYcDd9y7Ac8kfw+LpqtF5akrQcahtzBjyRroPngTvzx7GXPjtiF9
+3q1w9NNHtUU+JMJMAEmwASYABNgAkxg1BBQhqi7ePGiMn78eL92jcWKAVCgz1Tqfb6tSq6R/Mg/
q6JZUZw2JVWvnhtMJjU8XSuocVIMt2Ixq9eM5nTFrMWDqUBKc9cX+sIbjAYpkzoXSjmJFa4806j5
qTJMuVbFXW9R/Qw5SiuFcdbk+8MYjH55meV01a+r0BcwKRUUyZZrknESC2pEMkpFjnouwhgMek2e
SbGKBMjV5CcGpaGXsqDkyABd51GVwJ9MgAkwASbABJgAE2ACt4uAsPFo2/lBTX7YzOFv+eACSomQ
Pk6PGfQd7PSYM02H2t/sQwa9BDCkF6Pk+HG8Vp4lg+W98T59O2B/V41177J1MGfZUE5vDOyZa8nT
hV+mbJDyzQU2lLxeAmt+KoymxWhpFgsEHPjTWYuMbEy3oNHpRu7ji9BSW636xS+To+sfvndBniOx
AM6S11HSWEzvI4DSonNooRCmgxaQgU62fi5aleNYohPTlPJknK88EA00lSBhmzg3oNDuRknJuyjL
NNJ5HkrfF2sEPHjvfLkMb8oph0JpHEgXKQBtbrGYuas8ymD8wQSYABNgAkyACTABJjDKCAwbg//q
n87LolmxbIF/N5yWP+FVaYfPxV1Tw9BguyTDlKathfhRg6krkuR5q/yMguH7ZnmUsXkF5syJRepP
zgIzosiOrsd5aXcn4olvLJRhFj32I7x+fB/Wx9B8H5cdb8t0TNj93EOYTrvpiAk2H7xD8cmtXD5X
fte+qxrjWVvXgmLRlKIpIDPe51qq34WYlGRcpVen30BMUxKXTVgUHQHHlQvyuiH9BayfLVIApkzW
JvaHi7NGvFsiJeCZx5bTeQveKRXdICOWL6B80KSgTvNIV9kxASbABJgAE2ACTIAJjD4Cw8Tgd6Hq
bWmR4yvLZ6ul5GnAoe1r1FH/1G3Qk13c0nxNXssqpJH7GhuKC/KRX1CIg9/Vw9HSgPFLnoG93o6y
giyYaKi99PA2/KKCRs6dH+GyiGn4POYIS91RhT07d+LQqUoa+yd7v57m9ovriUbESktenNCof4no
BRjwhXnC2G7CBWl802F4JH0ADb89KePpV9wn5+dfuVAh/TesvFd+o6kWclmCcZWaruoLjBurHTWh
8BdqvseFUwegpRalwt43xKkLfB2XUSLsff1KzKP8d5lHr2z+ZgJMgAkwASbABJgAExhVBIaHwe+x
ayPwQOb/eQ7JW7dgcXg05OwXmJGXtl6OuC8mQ1i41988i9pL5cjetBmbN+3Bddqsv/SfozE/dj4S
DpRi7Lz7cI86KI8Zk8k4183DSjHXpjQJP9yTjWSjnhbVZuBgtVuO1H/4nvp2wfSl+/xvF1zeUf8V
iBErch1XVOObDpOSUnHsxB6YNmTQGbDreyvpswXnX5evCbBt115UtXjgnaZkWHm/HPHX3X2fnPJT
mpKI5OxD2L3la0gRBr0xF48t0sFx+R3ZwTGsf0B2IFx2K4RE/YN6ed5lHikcOybABJgAE2ACTIAJ
MIFRSGBQVwz0IrGgRbveBbvaAlUqJkWvNyjmzALFLtbj+lyrUpjpX/RKlrJSYNVW3bZalUyTdxGs
uvDWnFOseKM7awoVU4B8U7pF0WL6FtKqC2PVxNz2AkUumE0skDKctlxF6mVMVBINqnwyxZWcMrtP
O2uuf8Gtxe5WrNoC3cyyRl8Ye3GWKlfTxWDOVSiodFZtgW96sbpsuabALNM0awt+lW7y6EuED5gA
E2ACTIAJMAEmwARuCwFhLw72ot0xIqdDsZ9z6dIl3H///bhx40av1fPQdpYOWsOqi9L5R+Q1KS66
5hS/jKuLgo5myQQ7D02LoV+/itRB18tfva09sRXzNx+G2WLHvoei4XA4aWaPDu3FiPTd4eEk3zc3
KFgFeabq4QmLRJSuq3AhopJX13kMHYd9mQATYAJMgAkwASbABAaegFhnSgY/oqMDV3oObLodTN6B
TW5wpIfpdHKKS6jUIuha5yZ0GHUSxHz83joX3ik8LCMtvOcO+iY5lE4o13X63hh91UON37M0vGnx
NxNgAkyACTABJsAEmMBIJjAiDf7BL7AwPJBchrLEKbhvYefdicHXi1NkAkyACTABJsAEmAATGO0E
hqzB76FpN59++imuXLkyLMpo7PQ5mEOLd/9C+v5lWGjMSjIBJsAEmAATYAJMgAncDgJ//etfBzXZ
IWvwt7a2wuVyYfbs2YMKhBMbHAKBS0fEXDZ2oQl4OTGj0HzYlwkwASbABEY2gd4+B3sb/nbR68sa
1VvRdcga/FOnTsX48eP7tGj3VoBw3MEhcP36dUyZMoUWNzswceLEwUl0GKZSXV2NZcuWSU7DUH1W
mQkwASbABJjALRF46aWX8N577+H48eM9knP69Gk8++yzuHDhQo/C345AYhBv0qRJg5r08NiHf1CR
cGJMgAkwASbABJgAE2ACTGDkEGCDf+SUJeeECTABJsAEmAATYAJMgAl0IMAGfwck7MEEmAATYAJM
gAkwASbABEYOATb4R05Zck6YABNgAkyACTABJsAEmEAHAmzwd0DCHkyACTABJsAEmAATYAJMYOQQ
GD4GP+3LL7bp9P3TeXvnoet9cSJeR2mQaYXy70saHKcbAu3KN0TxSgGirHx1QJRbhwIS9aSDZzeJ
D6fL7dpBiLwKPv1OwNM/Mj0h9O2Mvqdf0lR5dZbGaPLvDfvRxIXzygSYwAgnoNkXIZ+L9JwZ2TaD
v2yHicHvwLGN4YiMjPT/h4djzOKtKKlTjXxX9TGERy7HOYc/cz07cuDo1yMRPmY36gIjOCrxdUrv
x5Utgb58PCAEOpZvePgYxG3dg6pA/K5KbAysA3QswsXvPIEmTa/qYxupjhxEYLQBUfk2Ca0+8bS/
DUgW1A7GLMbuU9WqRgNRb11ViAuPRMa5W6PqqsqmNvrjHpaNAwf7IU1H5Y8lr97fF25TAQ9Qsr1i
31KJ3dSmbq20BygjLJYJMAEm0EsClQeFXRCJdXvOtYtZh51LhV25sQ+2YztRw+B0mBj8QFsroE+1
oKbejpqaGtgqCmHGYax96LA09tzuNsI9F+Mje099nNwKNQ0JgZUhHBDeEb0XxzH6QKB9+VYU52PS
4RTop+5GQ4C8VuhRYK2BneqAqAfllixYMjbjyWOqweuWgsZhyP7AREBe+nLodnxIDSEdFXa1HdTU
WJGfPhdpxlicqKXOL9Vb4SLIWO43FzYTLxQWYtM83S2JdLtF9Igelk04xumBcVp++pqwbsEjKC4s
w7x+xNFXXW5nvN6w91x9C2kZH2GUI7udxcVpMwEm0I8Ewiepz67SlNNB9oSruhQZVpGQzvvo7MdU
h56oYWPwC3TTZt6FmFmzERMTg4VL1iPtQCpgPYoPfENRFvzs4B5siYtD/NbdKKlVh/s9DWewO3kP
zjX5X+jUnsrG7hNVQSVSmrICx6r9rwiojxHkGipPYefWeMSR/C0B8uGqxaHd2Sg5cwrJ8XGIi0/G
qao6VBdlI24xhRVpN6hvIoIE8kkQgcDyXRL3GE7aLXQ9DXlBI8vTMG9BDGZTHRD1YPlDicghw9By
0R4ka+SeiFo5AwvoF6hF/mNiFuGxXS/BSL5XP3LKbIuO6nulP8XuLaIubkH2qSptio8LRdk7kV1U
K8OJD09dCXbuPIYG0TQctTi2O1nWb9F+iqq9Desmaq0XcdMfC1VFh7BV1PW4QPkkr6WK2sJWKSMu
fmtA2hS5O+PdUY1jOykutZndx36Fankj9iWK2pJjMs3FcfHIPlnpm7ZUR+1sZ3YRfC3M00ByqP3T
2z9Xcy3+eLEFYd4eoKsOJ4lBvLhHbKEwvjzSFL6Gc9hD7Xsxpb919wloLw/9CgQc1VH+9xw7Rby2
QOiTvOekylAL01/3il7pVHIIu7OPIXunqtPuYyXw3c3ase+snFy1RXhuVz7l4ihSs0t8TDtjH4CE
D5kAE2ACQ5OAGA+WLg2nq31PCpw/9arm77tTaucj82tYGfzBRdCCM4VvkNdGzIsSV8bJyxlJtTDu
MGPph2lYOz9DTtMJm/U3cO5PQeqvbDIMyPeAMQkXx46X52JQ2JhTiNxEICFWjaMF9H2JKUPRS424
EmPCCy/swKKbfvlwX0dhWhLWrjFirsmM+DvehVE/B7Epl/H93X8PUNor9v7WJ4sPekYgbPZqZJEx
n3/uclAEdbRS9fI0vS8NQ8PMGUFhRtNJ3ZnTEF2juyarY7JiLONw0jZggxnfXwkkGfU4WiVuaBGI
cr2BpA2v+aZAVfwiGRlvtEEX5sKJLfORUHEnXvjXDMSPT8OG2IdRKe6Nzmt4NSUJb32g3hSrTz4N
/YZtmBa/A88/dY+U/1yRmBBXh+em6rGtdBp2vPACnopT084LuMFSoE5cE7JXxSIhYzzM+3bA+epm
7KeQ3jdstaeSMX9tgkzzgDkOSZuWYuOhSilravQ4ZCRtwFltXpfDepLknET4pAi4r11AStIuXJSq
t+DYo3OwKekKTM8/j/jPncTa2K9C9iebzuDr0SuQjzgcOLwD005uxpzle4JGgwIVb60rREqCEa86
1yLzqZUoSdmEp/KqZZB+u1f0VqdLhUhLSkDJFCMOPx+PkwlrYcw+F6i2dtx5OYVNisbCe+dSOD0W
3jNdhu+KfQjh7MUEmAATGGIE6AFgTEcW2Xj7Tr2r6uapRV5KKTJz04eYrgOojjJE3cWLF5Xx48dr
2rUquUYohKHDvznfKsO0WnPoml4pa1ajuG3i3KCUt6rntlwjnacrjXTqlGENSoW81qrkGKAYcmyK
0lqmkH2pGLIqKJRNoVFTJatCFdhoLVRyC8oVtypOsRdn+uU7K2TY1OJ6edVty6VrUArVU8WWQ2nr
sxRNNU3C6P76+OOPJSOHw0EgtDKQ3AO5ULmLsvH6E2dTiDpALVkptDtlRGuOgVjnkMSR4Ww2mzJx
4kRfZqw5JsmtQ1sw5cq6rbSri4pSr9B7MCVTq8fueouMn18jarJdofufotbbZoU6VwrMuYqtnui5
GxVrhU3lSDINFE5tC1RWFE7vLROSYs3PVHKK7RSnXrHk5is2tSgUZ2NZUBtqtWZR2lkhy8Yp24y/
/Yp8BKVJ9UCfXuxrf7Z8wcGsyGxQHumWrZjyaySnQjPlI9Eiw6r3Ba2tNxbKvBfYfa1YyUnNVMqo
7lhFGxXyhO502WlXOWWpNwkpN/BD1jNjrqJlVanIonqnpdlf94pb1amxOJXylCgZBbHvppzUe2eO
lje1bXbOPpAKHzMBJsAE+p9ARkaGYjKZeiz4zTffVD7/+c/7wnvv17YyYbeZ6ckn7EDxPMpUbFZh
r3ntQV+UAT8Qz/CrV68OeDqBCXhfdFPaQ9uJUXgk5qDYdC/gvoFPMAELFi1DzHTvGKDQfxomaDly
yvnC/lkECx/cTtfX4j/rzLj7dRr9TLRAHzgluY0mLOhW41cWM+Ybl+LEA8U0q8vvpi9ajpml6bS4
d4XfkyZSeN+UC/VmTlFjOOV6AgNmaALcEFdH7rzyACD9fOhB6zWA/nxODNRmWYrxwESqBlQLMCEa
DyxdhKhhU5N9WenjgSCQCEuZCRPpVccnhCBqzkIsXzjLJy+wLoq5ibOpF3tduxo2ywDq4OLf37Lh
m+6ztArGCOtKNe53D+fj9RWbEbs/QYY201uvNP1Cn1z1oFm+UfneqgU+/0WP0Rsv7WxxzCdIWj4G
FqvvMo2Zd+/UNThWuL2z7iIWIJ70li9fXZfwdinN3itdi/C0QFlGiFlMMbpZ2EQjArGZbyH7227k
0KuBrApDh7UCjisXKbIR8+7wVpbZ2PqjHVJglWzt+zE/UrxXCHRehQL9qO7RK2J9nN73BiJcvGAs
t8spNP13rxA3kL7rpJs+WyglGQW9/wqbha7KSb1/ifZFb1i6ZU+B2DEBJsAEhjoBejBGL9tATwA9
fleXjpifJdHYoA1zxpcPdc37TT/vk6/fBA6kIMOSlYhb7TUtepnS9JXIpyH7g4f+DdEZwiBY3cEg
EBJjHkpHrnE/Nq9ZKxNYpSVTdSgBG5JaUVBuw1funY+wSwcxdenr2lXvV2jjwHuVv7sj4O0+qeEc
VRYkkeGYs2quL2IrDFi1Lg5LAvt5vqv+g2BJfv/hf0R3Lf0GrFu92mdshs6Tvy76pi/KgDp802zG
NuMB/Fsi3ehS92GRZOnCzclLkNfsRGSrHedKX8WGhA248/5m7FgcmMIkzCVD/PwHjcASYZACDWeO
Ie9KLLYvqcWcNQn0kqAY9geXYbauHlsiYwMjd3EstDRA6zPTcTMuU9nLko+YiXvIx5hrxeuPx9IW
anTiqMHZqpu4R1tZKjr0eprCsneviaY3pSJL041C+ly4tMovQ04J0/J85tBhuNcnYkpbPYXLRKOy
AzraOjSM9qipOFuNz81V8+gTEnggeyOBHmqnvr/uFe5e6iTqvPXPH/sUUjtRkzC+XWNwVZ/ovpz0
49TBjB6w9yXIB0yACTCBoUrgWhvCIxbhCXqtvWv/fsylsZ1d9QsR1vqfQ1XjftfrM/0ucSAFtmnD
9n1KIwJ/+0+ZKM1IQR4ZBMYlcuJ/CEk6PH6kmEwP1XmNJbn7C1bQaPJCRHlqcOSHSRRgkhroVtTS
0uEvoPRyBSqrKlFZeQ5FJ/ZglT6BrLwcfKddWQXO4e/IjcrEWo2zlSTnXCXOkaxz56rQ4rd/O0YZ
hj6dVrlOL/gzOcuwhUY5DiPlsBW5f79Mu/AhfhQbi+gDv6VhkIX46mrtTVY7Y5HeJ+C+B4G8TUdR
2eCAq+kcXiAjP/+jcDKk5UR5GFaTsU/Tv8/8dB+1tZ45Xew6em9Rih/uPUVl5ULVyUNyDr8aexa+
nEoLsxMO4EydE2HuOhx+MhZr174Bj3fIgjr0KSYgIy2Pqsx3Ica227uI2K9RGlak7hdpeFBXko01
25LwZ6obc5fHU/AU5BZVA2EeWH/+PFasXYN3qH/Vc9cmFxL3172i1zqJ7cYyXsTJqia4WqqxX9yj
Ep9AbLvOcbflJOqQtRLn61rooAfsew6IQzIBJsAEbhOBNvnWcrUpE9b9abDos7CWXm57evDMvE0K
93uyw8vg7zb7mgHuCxd8Pv1LD9EDn8YRszYGGQTqcl9fJGB6HHItZGGQ816790EzGUkZmE/7vodP
jUXtCjNdtcBqJyMncjwWyNCBH4Fp0/G0wGt83J6A3BqVppIs1S/F0qUrsGFzPlak56P+5FYyMXvj
1GkQa5eSnBVLsYJkrVhBC7TVDWx6I2iIhu2mLoWoi9467MuQbgm2p+vpNB3rFnpHsGfjxfJc6NM2
YCrV8cj5RhhTC/Ck1tkKrM1xaXZkmTKwNHoSImeswGFTDk4lLoFu0TeRQ0a3cZfOgFQAAEAASURB
VP4k+m2ASXjm7fEwUTIlb1/2JU1vU0O7sIV4yZpPmzIZKf1I6DeVa0FVi16kmUNvJNbMmUSLcecj
6XIiiu3PQV1WKkRShz4xk75p0fA3/W8V1FF9TfuwGPyrzYJJMo1wzFmbQm8jKvCdGFrMvPwpVOSn
ImVDLCIp/aUJh5FeYMPG2d4eRbDaHfpBovOvnyW3suyve0VvdVI1vIZN+hmIpHtUGpWv9V8f8r/J
1Nh3V06R0+6hAY/DxPphuTd19+yD2fAZE2ACTGAoEQgfF002mPociKJpPfSYQmLKOmlbqPa+9owY
SkoPgC5jxIT+AZB7yyIvXbqE+++/Hzdu3LhlWT4BDSVYHL0Wu+zuTh/kvrAhD1xwtLgRrtMhIrQd
EDIWe3YkcP36dUyZMgW0aBe0KLVjAPaRBKqrq7Fs2TLJqf+QtOBQ3FT84hErSrYuaifWQ3VcdGJ1
0HVTyV1UdtQaoNMFDyG7HC3kH9nBv11CnZyq6YdHRYWcsiTSFH23KGqDfXdaHnVRtDtROykeB9Ts
32ob78d7RQ91qsyOww+RhZLtsVRfPN3y77qc6BeK6c1HhG8/U1pP0S/s2/HmUybABJhANwReeukl
vPfeezh+/Hg3IdXLp0+fxrPPPosLFy70KPztCDRmzBjQol1ER1NnZJBc+8fdICU72Mm4cHLrcmyi
KQww5eMbnYzada9VBHRRwcZN93E4BBMYOgRaKg/R2pNtpJCRfrSsvbEv9AyjOt6zdyoRouMbImsR
ZEiH8g8RNIRX1+l3lmYIQV14dZFGmA49zH4X8sWlfrxX9FQnVylKxeYDogw79GQ6qtt1OYV1GNTo
H/Yd9WAfJsAEmAATGHgCo8Tgj8CyJ3Yj9ytjse7b62/BGBn4AuEUmMBAEtDdTYvXc3Jx99cexvJb
GSQfSCVZdp8IzH24HOVusbyZHRNgAkyACTCBYAKjxOAHZi9/CI8vD848nzGB0UYgbDr9Mm+HaTyj
jcLIzG9UzHLwLW5kli3nigkwASZwqwRG2KLdW8XB8ZkAE2ACTIAJMAEmwASYwMgiwAb/yCpPzg0T
YAJMgAkwASbABJgAEwgiwAZ/EA4+YQJMgAkwASbABJgAE2ACI4vAkJ3Df/PmTblt47p160YWcc6N
JPDXv/4VM2fORHx8PD7zGe53dlYt2traMGnSJHA76IwQ+zMBJsAEmMBIJtDURD8mSD+x3tPnoNju
W2zp3tPwt4OdsH9EngbTDVmD/9NPP8W1a9fw3e9+dzB5cFpMgAkwASbABJgAE2ACTGDACLz11lsD
JrszwaPrh7c6o8D+TIAJMAEmwASYABNgAkxgEAjcjh/e4rkUg1CwnAQTYAJMgAkwASbABJgAE7hd
BNjgv13kOV0mwASYABNgAkyACTABJjAIBIahwe9BS1MDGhoa0OTwDAKiW0zC45ELM3qnqQtNIn9N
DvQu3i3q2pvofcpXbxLgsEyACTABJsAEmAATYAL9QWBYGfyepnNIjgvH1BnRiI6OxoxJ4YjffRJN
QSRcOHMsG0W1PV393NvwQYl1e1J5cCMiIyPx43Mt3YZVAzRgT1wkZoj8zZiEhBO1PYw3wMEc1TiU
fQreXPQ+XwOsH4tnAkyACTABJsAEmAATCElgGBn8Lvzy2RXYXwqYUrOQn58FI2XJkrYJPzpVp2XO
gUPxkViTUILo2REhMxzs2dvwwbF7dDZpKUwmM75wt65HwVH7W6RQHvWJWSgutOCZr87uWbyBDNVw
CmMmxWLbe0CUN53e5ssbj7+ZABNgAkyACTABJsAEBpXAkN2WsyMFN2hrVXIGJDy3HXFkeX5nyeew
8ZF/R+QnTsDTgBNpKdhmEWEs+MnRM8jYuhphLdXIO3AIr1dcBnRzEZ+wFaa4hQjrJPylk9n4WSWw
MfkpLJkehtqiQzhQdh3ffmY7Vs+iToSnBSV5R5D7+lk4oMO9K43Yun0jQvYvPHWobgSWbXgUa2YR
apFmxgHUzliCL995Db/4SSFu3rESyS8+K9NqOncS+w78u8gArIdfx38/8Qs8TvFcDZU4THkoef9D
6CgPxmfM2Lhc6wi4anEo/Siw5Gu489pb2P8LJ57Py8CE09mwXInAkthx+J2lEB+Np3R2PoKPKT+5
he9j/NLv4MXUx0BZlK6h8hSOHipAxYeUq7krkWj+R6yeraO0zyA9Zb8a6PB+nNj6JTymvxmcL7ra
pY50vZrSffV8G9Z8eQ7O/0KkMx7x/7QTj68eAh0aNXf8yQSYABNgAkyACTCBkUlAGaLu4sWLyvjx
4wO0cyr5RihUCvLfnFWg1DQHXq5QTNo1EcaQWqi43TVKouZnTExUDNqxpd6tKM4Q4ZVmJUsv5BuU
Mim7VckxiHO9Utgo0nIrFrOavtGcrpi9+pgKAhTxH7rrLaq+hhylVXg3Fip6n44GxWjQy+uGzAoZ
yZZrVMNrYRLzbYqzpsDnpzcYfMeZ5VIhxWnL9flJNoYspVGpV9JlPlRdDQHH0BsU73lmhQqwuSJL
k2FQEhM1HfSqznaLOUh+Vnmz0j5f3emoEFeVo8bO6M1HqmL34+IjJsAEmAATYAJMgAmMeALCXrt6
9eqg5hODmlovEuto8FPkVpuSZVKNZK/hn1pg9Um15ZqkcZpa6DUjnYqtvFixFFYoja2NiiVVNTSz
NEO3Q/jWCoWmCSnQZ5LRTM5pVTsR+nTNMKUOgewAQEnNL1fsdptSXm5V7PWBPQ+fOkpjWabUx5il
GvTN5eo5DJlkklP3QTPWDdp16hEomdI4NyoVsodAnRyTaiSbyfgXrrUiR8rUm6lDQ+c1+YmqQa43
K+X1rdJPaS7TOjdGpZzkOL0GvVE14isyVaPey8HZWKOUFVqUMluj0mwvVBlQJ0XrDmh5VmUJHYLz
1b2OPo7UcSqwOUmCTePKBr/gyY4JMAEmwASYABMYPQRuh8E/TObwu9BCu9bUOaKx/fi7aLZXIMtM
4/XkMjbtQZVcn+vChd/nSb8lC+6Q302Vv8G/pCbDuGEpLfCdAWNGKfkbsXyBmIneMbzLbqXJQDSe
/6BezlX31FdBSlwRi2gpMQqG75vlUcbmFZgzJxapPzkLzBDyOroP3qFr5FYunyu/L59Tz1OfT8As
8qHOiPRfcc80+Q3HBzhrpUNDHOaKKf+uSyiUCiRi63cWyjDh48fJb+vlP8NJe/hcOl8uzzMPp2H5
LB3EDB3H5fchcqpP/ycsJznvv10iw6Rv/zZNQmrB20UilwY8MFflcP6No3hmgxFrYmdg6pwNkgGi
dYgUsRyXUSKFrcQ8bRlCUL661ZGy4eWYuAvxCyPgqbsIkU3o74NaUuKEHRNgAkyACTABJsAEmMBA
EBgeBr/Hju20a82c6FU4Q9vERM1egu37joCm65Crx003fXnq8bvD4jwRD8SIBbsOvJG+CXmlVmQV
16C5xgKaTiONaWm4dggP2Kt+L0LgwTV6aTj//rVfynPTl+5TDemWBoxf8gzs9XaUFWTBRAJLD2/D
Lyq8e9fI4NqHA38qUQ3rL8wThrUDVnmux5qF0+nchf9q10Fx2P8kjW2D4QF1caz7JuVOuGmIFJY8
uUvlqo6iE6NDI86XCNPZiK/dK9JQXb31bXnw4LIY+nZp6Rrw5UWUrstrwK9HjIjSch7PJGTAakxH
eX0zrPkqVdPaJZAUvZ2gjV+C0FrkIyhf3eoIfPjeBRkz8Ssqx5bad6XBb1y1SKYhL/IHE2ACTIAJ
MAEmwASYwIAQGB4Gf9gcGGmCPi1lxZqvxmPn7p3YEjcf0r43PIJ7xMiz8yNclog+xGsnzpBZCrS1
Cg89XH8+h71PGqWRKYxpabiGCH/zow+lhCvnf4uT2VuxJkUY7MCqper4fuk/R2N+7HwkHCjF2Hn3
4R514B4zJsuxcBnW9+Gy420ZfQViRILUwfi9PI/DghnqeaXWQflf0cK0pq5LhWqor1j2N/IcusX4
vtiKCBlISs7Gsexk6BNEJAO2fzuWjPVaUH/G/0ZABA18c0Ej9qDOkpquqofHa8DH6SHVcN6QscTH
ld8eR9JmqZQvz3C3qdcv/hZFVbQBavt8dacjvYWoLVffQixZpHL84I8VUmbc/XepsvmTCTABJsAE
mAATYAJMYOAIDNUZUx3m8NP8/UyTd7GnOq/dkJil2ORcd5GLeiVTm18PZMr55zWWVIXIyX+DySQX
zOpTLeo89xDhW235/kW1vgWyJjkPXnJqtZIOwWsIzDnFipiV3t657QWqrMQCed1dX6jOqzflq+G9
6wWMueqCXvK1mFXZBTV+ie7GcoVmL/nyQft1KoVapr3z+Y2Z5QHJexfsJio2McmfFg7LhcKkhzi1
a0wSC2q0OM1KfqI3T3rfgt4cbZ2Ds0aLTxwNWValfb6EkK50pFUHSo5c3GzS1iV4z43awmhNDf5i
AkyACTABJsAEmMAoICBs08FetDtGcB247kTfJV+6dAn3338/btzwj0ALaR6XAw6nB2GROugitHku
vmQ8cLTQ2H7ANRneHYkoXfuwUlqH8PA4IERERWkT1n2y/Qcu2h/USb80G6aLQkix/qD9diTTJGk6
nTpPv98Ea4IcLS0Ip/x0QCqua0x0xCQURa8uA62jNx3+ZgJMgAkwASbABJjAcCUwZswYkMEvf0R2
sPIw7Az+wQLD6TABJsAEmAATYAJMgAkwgf4mcDsM/uExh7+/SbM8JsAEmAATYAJMgAkwASYwSgh0
NUPjtiIQU3mioqKQkJBwW/XgxJkAE2ACTIAJMAEmwASYQH8RmDlzJlwuuad8f4nsVs6QNfjF6462
tjbExIitJdmNNAKibF9++WVs374dY8eOHWnZ67f8NDc3Iy8vT3LqN6EsiAkwASbABJjAMCHwhz/8
AR999BG+/vWv90hju92O0tLSIT1g7HQ6e5SX/gzEc/j7kybL6jGB69evY8qUKXDQAuiJEyf2ON5o
C1hdXY1ly5ZJTqMt75xfJsAEmAATYAIvvfQS3nvvPRw/frxHME6fPo1nn30WFy6ovwHUo0iDHIjn
8A8ycE6OCTABJsAEmAATYAJMgAmMdAK8aHeklzDnjwkwASbABJgAE2ACTGBUE2CDf1QXP2eeCTAB
JsAEmAATYAJMYKQTYIN/pJcw548JMAEmwASYABNgAkxgVBNgg39UFz9nngkwASbABJgAE2ACTGCk
Exg+Br/HI/csFfuWyn86b+88fdzTVMQLIY3S6ejbPs2enAt9O5dE+er8Yk/Ej4ww7cs3RDl3Vr6h
ysnjaEFDQwOamhwjg48vF+3aQYjK03V98wnq3YGnqzrcc1GeEPp2FtvTH2mSjF4k2ZkqHfwHhDGl
0rVcvld0KAj2YAJMgAl0R0CzL0KaWuIZMRAPie50ug3Xh4nB78CxjeGIjIz0/4eHY8zirSipU3+4
wFV9DOGRy3Gut/adqxLrSO6PK1uC8Dsqf0xp/RjBvkFBenbiqMTXA+W3VGL3zhM+uVXZ6xCZca5n
skZsKCrfhHbl6y3rcK0MqJw2kl9cdjArR1V2u3Jqwcmd8QifNBXR0dGYMWMS1ZNknGkI2dSHHdHq
E0/724BkRO1gzGLsPlWt5qV9feuPHLqqEBceiYxzt9YaXFRW4T1uUw4c7Ic0KzPonpEWXGduGclA
MBZKtZfL94pbLioWwASYABOoPLhRPjfX7Wn/LKjDzqXCrtzYe9txGGIdJgY/0NYK6FMtqKm3o6am
BraKQphxGGsfOowmAu92t9HnXIyP7FspRLSPFi58InDLv0wWDkySktQEPFffQlrGR/Cq6SZv/bjx
6sVR/NlWH1y+oozlvz0BOo2L+C5NWoFj1e17df5yaijai00Zl5FbZkNraysa7eVIxX6s2XAU7WMN
R9xux4cEKh0V9MMiKiMr8tPnIs0YixO11Pml+iZcBBnL/ebCZuKFwkJsmuctib5JdovK3uM2FY5x
emCclp++pUh3hE1lKPvuvL5GDx1vIBiLlEgu3ytCI2dfJsAEmEBfCYRPUp9dpSmn0RAgxFVdigyr
8NB5H50BV0fe4bAx+AX6aTPvQsys2fLXdxcuWY+0A6mA9Sg+8A08WvCzg3uwJS4O8Vt3o6RWNfHq
Sg4hec+pAIOPRoF370aR9nZAFms7AykyhKFRW3IMW+PjsDguHtknK4Om6TRUnsLOrfGIo7S3BKQt
ZFNfRTpXbRGe25VPx0eRml0C8W5CJGP9nwqc2LNVyk3ecxIjZDBa5rk3H9Nmz/WVr/iFZfk/e7qv
0+U12BNiM1DXieA/Xywng3gzjKsXQqfTYfrs5UjNy4VhbiMa1ZdBncQcLt6iNs3AgtlqO4iJWYTH
dr0EI/le/Uj95T5hNL5X+lPs3hKHuPgtyD5VpdVVF4qydyK7qNaXWU9dCXbuPKbWOUctju1OlnVY
tJ+iam/Duola60Xc9MdCVdEh2Rbi4gLlA56WKhzavVXKiIvfGpA2RQ7RpnwixYGjGsd2UtzFcdh9
7Feoljdif4jQ7Y/ytGcnjp3z38ZFO9tJb9FEO2ptqEXtx7KnIQU5as9gT/IWmcbWPScQeAsILd+f
fuBR54zVUF3J4ntFIEk+ZgJMgAkMMAExHixdGk5X+w2B86de1fy91oV2OkK/hpXBH1wGLThT+AZ5
bcS8KHFlnLyckVQL4w4zln6YhrXzVcPwjlnjsD/FiDfr1GkdrmoLNqWlYex4dVxfPLzPl/4KRUWn
cOoU/RcV4Zenz5PhKEXKj9pTyZi/NgHT4nfggDkOSZuWYuOhSnlNTCeKXmrElRgTXnhhBxbd9Kft
lwCETYrGwnvnkpceC++Zrl4aFw3sT8C/f/wlZD4Vh5KUTTAdrQqMNmqOS6urUFVVhcrKSvX/XCXq
WvxTcVphQnlNMRm3GUjwvprz23KS073rvk89qBRMHROPPcdO4kwlGbexj6Pk9V2I6fAaZ2SgrTtz
GhbKyl2T1VF9MZZxOGkbsMGM768Ekox6HK0SN7QIRLneQNKG1+RbMZH7il8kI+ONNujCXDixZT4S
Ku7EC/+agfjxadgQ+zAqxb3ReQ2vpiThrQ/Um2L1yaeh37BNtoXnn7pHyn+uSHTB6vDcVD22lU7D
jhdeAFVneS0v4AYr0gztmpC9KhYJGeNh3rcDzlc303sZobHqOm9/EZjQRvUh9T98HfqzRzcg4/1P
MJVez1374z4k/PaKKqSpBKvmr0HKzWV44cBTuJmyGXMePSE73p3L1xRo99U5Y6ArWXyvaAeST5kA
E2ACA06Anl3GdGQlAvtOvaum5qlFXkopMnPTBzz1IZOAMkTdxYsXlfHjx2vatSq5RigErcO/Od8q
w7Rac+iaXilrVqO4beLcoJS3ivNGJZPiGrIq5MWydL0CU4HiFGfOCoVGR4Pl6um68DPkKDI6feYY
oOjTixW3lKAotnwThTErNeTRaC1UcgvKfdfsxZn+tEm+gWRlVaiKqXrlqGmTLGuOISAdOs+ic69u
Wloj8evjjz+WjB0OB2Wv8/LNLNcKVHI0KBXEu95ilnFzCb7blkXHWVo5qaSabcVKptkow3jrTLrF
Niwx2mw2ZeLEiT7drTmi3rWrr+LclEu1nJxWn1OL67U49Qq9B1MyvfWv3iLj54uKq9gVuv8pathm
JUtPcsy5iq2ear27UbFW2FSuQXWY2gKF02ttSSRizc9UcortFKdeseTmKzbZsEiVxjLZtrx1v9Xa
saw0JRWnLZf08rdfkQ9/u+m6/blrCmSeCgUAt00xifyWSxpKBbUnfaba7mVbQ6ai1SjFWWNR0tPz
lXp31/K9Ovq+u2TctSy+V/go8gETYAJMoEcEMjIyFJPJ1KOwItCbb76pfP7zn/eFl/d+Iz3byoRt
ZqYnHz2f5PMoU7FZxbOHbAvV2PPFGegD8Ry/evXqQCcTJP+Wp6iT0oPixBx+JOag2HQvTdi/gU8w
AQsWLUPMdO8YoFBjGiZoOXJqI7/qLILpeLggESmb3kBT4mTkpVmRXvYV3+ihEJ1lbcX2Rf45ymKB
YaReew/kuoS3S2nguHQtwtNEOl5nhJhFEbNoOWaWpiN8zArvBfo2hpzB4JRrDSgLFEJoLk718ct8
89TliwprA8TkjMCc0emIdqJ8qUOGku1Lusynm8DMeigducb9SPj2j6HPnUwAfe/r4GiiqR3z47Bj
n/h3oanuEt44lIQE4yP4cuO7iNNerHSZyJC+KEbZE2EpM2EiTYr/5BMgas5CLF84y6e1qM8zp3jr
sg6z6U3Vde1q2CwDqPOKf3/Lhm+6z9IqGCOsK9W43z2cj9dXbEYsvXESzpxTiDT9Qi2m96tZTrX5
3qoFXg8seozeamlni2M+QdLyMbBYfZdBA/3dOnUNjhVu7wudiAWIJ73ly9fu2l/MWlBnBTn/r5Y4
nEIe8alZ2klBGyb7pohFxDyEXbtINVoQ3mX79qIMyEWnjLvTle8VART5kAkwASYwSAToph29bAM9
8fT4XV06Yn6WBH2ODXPGlw+SArc/mWFj8AtUhiUrEbfaa1r0Dl7MWhMMWIN9h5vJyEmE7UvtDAKf
paHKVRcYamlEzMQ9dGjMteL1x2NpCyc6cdTgbNVN3EOzKKoOJWBDUisKym34yr3zEXbpIKYufV2L
HOJLPy64MyCtmsBw43xGSaDvyD/ubpK3l4AOjx8pxqsz1mLpUvIz5GgXWpA7IxpJ6WVQdq0mvwia
w78Ij6dn4dUMPS5caSGDX87/8goaht9019JvwLrVq7vpEHotZ1rwHpRLHb5pNmOb8QD+LZFudKn7
sEj2LF24OXkJ8pqdiGy141zpq9iQsAF33t+MHYsDBUzCXDKuz3/QCCxRLeGGM8eQdyUW25fUYs6a
BHpJUAz7g8swW1ePLZGxgZG7OBZaGuDrp6AZl6nTMFfE6Kb9UZcHxl2JSNp9AHvn7oc+sxwxIe5s
sq99LWApAe2Ck32kGsbtX+2yfXeudAjG3ejK94rOafIVJsAEmMCAEbjWhvCIRXiCXmvv2r8f9KjA
rvqFCGv9zwFLcqgJHl5z+NvaTdjuDc2oL4HsHGQkCYPgCSwMMAgmhZITZHvOwpdTAUvCAZypcyLM
XYfDT8Zi7do34CE5bvn6YQUeWLoQUZ4aHPlhEknUpLZXWZxbK3G+riVUqppfW9CC4C4CjqhLpZcr
UFlViXPnzvn/q+pCs5geh1wLFahwvgKMgiGXJnSkrUHyoSJU1zWgrpaMuqf1KKX5/4Z7h7uxr2ZX
fLavVr4rnV7whcAswxYa5TiMlMNW5P79Mu3Ch/hRbCyiD/yWhkEW4qurV6j+Qe1AeEXhvgeBvE1H
UdnggKvpHF4gIz//o3DaKUud429YTcY+9afP/HQfjbb3zOli11E3vBQ/3HsKLbQvctXJQ3IOvxq7
6/Ynwsz+uydgsO5HhoVu4o+IXmBHN3dVPLW9bThcUguPpwmn9i5FUsoFegh0Lz9IWpeMu5bF94og
knzCBJgAExgkAm3yubnalAnr/jRY9FlYSy+3PV3ezwdJtUFKJsDsHaQUBzQZn+WnpRJ4HobV36aZ
/PtTkPJw0JClDDtpfAgUer+ycWl25Fx7CGvmaDL1iSi2PwfxnkD3oBnGJCPmh2fICImpZIiW7ofV
7sCS2PEQkx/GhavyI6fdQ+OYSSTnEspbS9BhQ85xJF//Od+2nX4NRvaRyLZYvLx0f7t8UqNsfnc7
mZkd3WwxtcdEU3vq/dcWPX4Qxa2fw9ptG/wGo94Eiy1bG8n2hx2eRwRqWheaR6r1LTCEWM4e9BJJ
twTb0/WwpG3EuoXe+Sqz8WJ5LspXbMBUbdqaMbUATy4h8q7L/j4VyRJtIevKHCyNVus7TDmwJy6B
jka3c0zbYJyvthG9yQyTHih5+zKN/mslSOchXdhCvGTNx8N6o5a+QVszr7abrtqflKdbih1m6ti9
+z2sne1vy4H9laglT6Ei9zKWrp1PLVA4I9WLVIgJTbO6aN8yaOBHN4y70pXvFYEg+ZgJMAEmMPAE
wsdF03NTfS5F0bQeE1IwPmWdtCvUYSr12sBrcntTGCNm9N9eFUKnfunSJdx///24ceNG6AB98K09
sRXzN8egUdkhDfU+iIDL4ZDz66Noy8dg54KjxY1w8o/w2xvBQXxn6i9mRoR1G9AXY6QdXL9+HVOm
TAEt2gUtSh2A7InycNIbmEhE6eSclQFIY+BFVldXY9myZZJT/6XWgkNxU/GLR6wo2bqonVgPcaNb
YKSODPiu66doC1TjafvTYL4u+pVjN3VZ2/u3S6iTUzX98KiokFOWOm9/nYgL5e1ygKoGdFG6DlPn
+kW+lmbnsvheEapY2I8JMAEmEIrASy+9hPfeew/Hjx8PdbmD3+nTp/Hss8/iwoULHa4NFY8xY8aA
Fu3KHwgdLJ26fqIPlhYDnQ79UujWSD1NYqApy4X1fTb2hZoRwqAPqW8EGRChr3QMHtaDTkHHWOzT
GwK9KY/eyB3eYVsqD9H6km2UCSPKLe2NfZG3MKrHod6ndMx3Z20hQhfaWO8oIZRP1+l3lmYoSZ36
RejQWVPtF/lawp3L6k3d5HtFp+XIF5gAE2ACTKDHBEaHwU+/FPpIfi7+duYKxMepO5L0mBAHZAIj
iIDu7pXIz8nF3V97GMvbv6QaQfnkrDABJsAEmAATYAJ+AqPE4J+OuMce9+eaj5jAKCUQNp1+mbfD
NJ5RCoOzzQSYABNgAkxglBAYXrv0jJJC4WwyASbABJgAE2ACTIAJMIH+IsAGf3+RZDlMgAkwASbA
BJgAE2ACTGAIEhiyU3rE7jxiF5fERPqVBHYjjoCbftnsjjvuwPbt2xE2incr6q5g//KXv2Dy5Mnc
DroDxdeZABNgAkxgRBIQuzaKHf16ag82NTWhra2tx+FvBzRh/7jkr7gOXupD1uAXCIRReOeddw4e
DU5p0AiIxij+Z86cifDwwN3SB02FYZFQSwttccntYFiUFSvJBJgAE2AC/U+gvr5eGsc9tQfFM1Ps
ON/T8P2vcfcShf0z2G5U7cM/2HA5vc4JDPw+/J2nPZyuDMw+/MOJAOvKBJgAE2ACo5kA78PfP6XP
c/j7hyNLYQJMgAkwASbABJgAE2ACQ5IAG/xDslhYKSbABJgAE2ACTIAJMAEm0D8E2ODvH44shQkw
ASbABJgAE2ACTIAJDEkCbPAPyWJhpZgAE2ACTIAJMAEmwASYQP8QYIO/fziyFCbABJgAE2ACTIAJ
MAEmMCQJDOltOUMTc6GpoRluhEM3Yzp0/ZQDj6MFjc1OYHwkZkyPQj+JDZ0F9u2UgIP2z3XQllqR
uhmIal+4Hg9c9O9ztH9/RKg9/D1URxrVOjKV6kjECC1MR1MDsQLCI6dielSEDwsfDBQBqn8uDyIi
+pk11VcXIga5nt5iXlwtaKD7ZeRUaqeygXnovtwI8hhmdTFYbw+Vb9hIvWEMVLNguUxgGBEYzc/N
YTXCX3fmEOLGkEEeHY3o6BmYFD4GyYfO0MOyh66lErt3nkBLUPAWnNqzBeGTpiJ6DsmdMRXhY+Jx
4lxDUCg+GVgCnqZzSF48BpNmzKCyjcbUSeGI23kyoKwcOLYxHJGRkf5/2r9/zOKtKKnz14C6kmyM
CffXkUiqI3uKagdW+UGWLljtjBesRDuIxoypkVi8ZQ+qgit2l1rVlRzCnlP9w6U/ZXWp9G2+6Kj8
sax75xy3qEi7+1BlBtXptHO3KLR30R1VBykvX0ef8tJ0BvFk2Iu699VsKyXcgmNbwuV9ecbU7IA2
2zudBj90sN7/U5VNnecfDyP9B58Yp8gEhiuB/nhuDte8e/UeNgZ/05k9mLNmGyalF8De3ApnayPK
89Oxf9saPJrds4el5+pbSMv4CJHe3FNX4VTyVBhT8pBVaEWz04nmehtyzJexeUU0Ttb6DUlfFD4Y
AAIu/PLJFdg/LR3l9kYq22bYinNQmrEJ249V+9JrawX0qRbU1NtRU1MDW0UhzDiMtQ8dRpMI5apE
wtokmLIKUU91pLXZDkumESkb5qOoIeDNgE/iMDxwUB5nrEDGZTPKbMTK2Qq71QJ9Xgr0X92NnnVT
XShK3ob8/7nZDwD6U1Y/qDOAInQLHkFxYRnm+W8gfUqt/X1o7qYylH13Xp9k9T3SOIo6SbzQ7LXz
XHsfFiTC2urGu88uATxX8WoekFlWD8X9LKJ6LfE2RWin90R6WwZ60zJCXwjeJsicLBMYAgT65bk5
BPJxqyrQr5ENSXfx4kVl/Pjxmm52JRVQYLYo7nbaWnNNCmBQylvpgrNGyTGnKoU1Ti2UUynMylSK
6510qVAxG/UUVq+Ys4oVEcJtL6BzKJllje2kNipZBkrPmKu0UsjCzFQlt7zeF0bISk3NV+rbK+ML
wQfdEfj4448le/q5bArarOToiXd6eVC04kyTYi6waX6tSg6ViSGrIihMc1mqLNPyZirPGrU8LfaA
gnHblFSDUSmwiQoy/JzNZlMmTpzoU9yaY6T8mhSrt4p7r9QXKnqqy4kFNdKnpjBLySm2e68qdjrP
KlTP7YWZMqyo+zllVK9Fu0nPVPILcqmNGBSDMVHJD6jvvZLlSzHgwGlXCrJSFaPBoBhN6UqxjQpL
c601ZUp6olEx6A1KYnq+UhNQTPbCHCU9J590S1QMVIbp+eVKvb1MSdV0zC3T8if1z1KKyyya/mbF
YrUrNsqzkGsyZyrldA+Qrot7hLgu0szMtSi56SZFT2maMwt87dxpL1YysyxUW73OrVgpfKLQx2BS
sixW3/3J3WzV9FZ5eq+Fug/Zi3OVXFEOXuesVwoyzSRTT7zofmb1p9iVflSQSkVBlmKSfEifggp5
n/OKDfxutebI9meme5soF1NqjmJt1tpNF4z8+hsUM8WpaalRssziHkztl+plgaars75cyaRy1Wvl
avfWV62sLJYcxUTpZhaq9TVQN3HcWb0Q9Tg1q9CfL3e9kptKdUpLoMfpWko66N1qzaI8ZNE9X3Od
lIN6/8/11QubReikPlNEGRRmpQ/b+4036/zNBIYSgYyMDMVkMvVYpTfffFP5/Oc/7wvf0+emL8Ig
HIh75tWrVwchJX8S4ueHh6QLMvhbKxQDwcmq8N2K/Tq3lmvX6KGohcus8D4gW5UsipdO1qC7kR7A
qaqxlFNolQ+MxuJ0+ZCyeR9GfqlKTUEiXUtVhO1Ylk4PM0OO70FQnKp2BkJEC5DAh10RCDb43UpZ
poF4Q9GTgZNrKVasNe07YaEM/mbFkio6cemKGlrrGJKcxPQcxVJcodi9RkxXygzha8EGPzGgjpE+
M7hjpKrvVHKpQ6TXOkQVmcQloAMVeO6ssUiDX0/Gd2EFGZrUbozETHYACssUS5ao+1ByrWp7C4wr
0go87yCrA8tmJdeoGYPFxUquWe10yw6a3aKWeWKOaqyLTp/W5oQY9SYNxUgdgYIcswwrOuyZ+QVK
VqKQY1Q7PgH6ZxVY6Jpal6A3K/mWXMUk8mYuVDXr4h4RmKYhNVcpLFA7RsZcm4zbWiEMQr06uEA+
NnmPgJKaW6gUF4h7CRSz7FTZFbNI00DGelkZdXY0nnSjCXUfCuSpUE3OkhxMSr7gJe9Z/rLwMgml
n3o/0yu5xeVKcb6qT2px+3akYdAMfsHIUkYDGGKAg9qR7HZ0xajVTmUo+JqUnPxCMnqdSnmuWjai
zcn61Fgm78n6xCylrJxki/zoM32y1bqmVxLNiWTw+zulqmZiIKbzeuHtqHiz5S2TMnHL71W6/9VB
72CDv4tyaCyWZZ1fIzpIjUqmVl6yE07PI9HxzvcNOnlzxd9MgAn0lcCtGfw9f272Vb++xBPPCzb4
NXJBBr/Ta/B7DfkAvHRNPECyhJHfIRwZ/HQz9nYA3DYxqpXjGx2qyCKjwSBG8Ts6py2XwqoPd+/I
caF4dtKIsTAgMstDP0g7SmKfUASCDX4Rwq1U0KhfIo1qioag/if6Ru7IKtUMR+81/7c53+pPQhtN
Fh1ErxyDOV/rEPiDDZejYIPfqeSbKF8Bhrw/H8RHGG2aYVuRZaCOgf9tSPC52jkw5GjctDaUXuwd
ZaZ0yEj3xg+OSwZ/kOx2svwKqUeNhbIcCnxvXezU8c5UymhEVsihiSD+EXPNWJJtmWJbc+i6r6Pd
qKRTmQbqrPe92VPvAama/m7ZdqEUatmxibci+iw1nW7uETJNerPn7cxLHRPVN4uqsWlQ1HEH7SES
8MbJmp+pvlWhUWdLbr7iHUhwkiHqu0dRvjreh/xlpaahV7wGrRgxFmWB1GLJsyv9VJ4GpaDCTrHc
it1aodjqQ93dqDVJg1+vlHkva+xzRCevG0bt9Rf3RJk/7bWT2ikxK9LmJZvYqRnwcsBGq2veN1Fq
JQn+7Lpe1Mt6YMpX3wwUmomNVj69Tred3oEGv5dP6HJQ30ga86mz0lrme1smOgCtZaKjlap2boKz
xWdMgAn0kcCtGfw9f272Ub0+RbsdBv/wmMMv51YSnlCOdnShqd3kup956XS3Ubg22uFHdXOXbwZK
i1EfYnr3hxffpUAP4m4dSY5ZC+o4IOf/1aLFegp5NH/14aXTNSn8desExM5LLVjy0FYcKnkXbmcz
airELGGan5/wU3jXSIo5/EjMQXFZGYqLC1FYXIaaRif2PbZIquARO4c4pmLj9h+hRFHgbK5HWUE6
SvdvxrMn/GsBbl3f2yXBjU8Ihl5Mvw7hRO3Wz50R4grt5BPk66ZWQK7N2xLUi05fqAgsiTfCWmT1
sQ+M3hNZ3vCOKxfp0Ih5d3jb52xs/dEOrJ4dIVPTZ37FP+dbNw/UIn2L8EVz1a9fBmqC5CIwg9rg
+mV3yTPxMc13BHkPmDlFDam2cwNmqKfU3kXFGdeDOwQg04zTU2qqCxesy+0hODSj2gp8b9UCLSSw
6LEd2Bo3m24Ys7A45hP88/IxGDNmDCJnrKE5737X/j7kv+I/CvcqQJqIskDGH+Vi0q70W5JwEJnG
UmxaOgeRY8KRcOAt3KQF7KGdqAGbsVBjhMjJWEE+be4QN8N2Ajro77mp3oPdtMuZdELofsyPpPzT
ovnIOaS/dKpsURqf/1+h66kIJupX5/ViFjbRK6O8zLfQ4qpGzn6ahLPVoJVtL9PtoLdIPdiFLoco
fCXZCEvheVSf/y2spizkJAKF56w4X5hGuhsxK1gMnzEBJnDbCPT9uXnbVB6ghIeHwa+7G+vpYZ+0
r9BnDHh5VJ7IQCkMWLWAbvaa/TIuXDMuPHaU0EPZ9+wUkcha8hosus+JhXJ5ePWtOq847bsBr+6i
J4nxPkyVPlEw7kqkBaAHsDedFkdmPoEYr/3SLiaf9oFAy3na4WMGDlWri6TDIqIQs+QhvEjDdyht
Q6AJYliyEnGrVyMubj3Wx61GzHR/6db8PIF2WUqDtzQjomZh9cZU0Mg3rFev90GxoRZFhxXCEE9J
xZmWYN08tW9iWykQd0+gGewP43Zd85/4jrwtQTOYA1jaf08LgdfHasa2L4I86E5WYOhwaTFfBvXL
NefCmUPZcmcl4WU9W+svX881nPUGC/EtOykh/P1egTXF7xt01JN7hFoNA6KF6ixMwly6J53/gLai
1FzDmWPYc+IcXNUnaIOBBMxNLoa9sRWK0waTN5D3O+A+5PWS33JQYhom+IsGDRepu2DW+8uiE/0c
jnA8dFBsaFCPiuICLChPwdLn/2+QeP+J6MlU4ZoPmRsfko8U3RNGfkEdjtxt9eSXCXoHSovK3dSB
pw0WqHP+4FxhkGuui45Fd/Vi4YPbobduw969/0IdqVQYl6hybzVdr2ryu5tymG+gEs3bjX9OTkOi
8UF885FU5G1OwNoMIPmhe4NE8QkTYAK3k0Dfn5u3U+uBSHt4GPyYjn/My6Ub7GYs33oIVXVNaGmq
Q1H2FizdZoEpPwvynq+bJkepDr5eiiYa7T2XdyBoZE12CKyVOF+nWkthMRtBc8eRsWEOdp44g4YW
GiGuPYfd8dFIs+pRmPUdX2dh9t89AYN1PzLo2bvrkaUDURajV2ZUDGgeLLbFPooTJVWoa2hA9bmT
eHIDdboSZwXsqkSI2o1KB0KTD2EaWZxDW1Seqa5DQ0MtSo6lIYEM4Y1fEp274e8Wmv4/MnFKsWbq
FpyspDdOLU2oLjmGpfM30dr1LOxcTyPM5MLHTaKOwXFUNjnQVHUSCSlWzPX1jcjKI/u/9HIVGjTj
cRLFSdr1b6h2uNBQeQIph+n9ln5mn2TJSNpHROzXxH4uSN1/Ci30Gwpi29Q125LwZ1Lh7gfWA5bN
OFpSS7+v0IKSo/tke104LcAwDBTW2bFmoHZ2Oci/u3tEUGDvSXCnU/WNwn0P0i1p01FUNjjgoq1S
XyAjP/+jcOrc0GsYcobVyzCbXgSe+ek+GlYIcNKi9d+HAq5At2AVvQ8pxQ/3nqJ7mFoWyWREmpbN
6eINharf+3nzERudhvddU7FkzUosmUuSx48NFN/uOA//cpQ6KB4HSg7uIfZGfG1BFNAnRn7Rc5fH
00kKcouq6W2HB9afP48Va9fgHTG03wPXbb2YvhIpZG9npOXBmPNdqDUeuNV0A1XrrhzCZq9Eut4K
Cw0ofWVZDGYtWkPR6YT2DVs9v5f1NzBhPmYCTKDfCfT0udnvCQ81gX2afDQIkYLm8Gvp1VcUKCa5
QIrmbco52rTLA+1Eoe0tIUPZizO1axSGds6gwV11fj9dddsL5blvVx8Zo1UpyxU7vXhlinhmpTBg
JxE1ebdSKBYcGrS5wKonf/aRQIc5/LSrSaYpcP4+zdemxZy+3T1oDn+oXXraJ19fnivnEweWZ2p+
cB1pH2conwfP4dc0bbbRDiPawlSt3ppokamfFYVrLFdoloFWr/Wy3gfucGTN1xbBJhbIOds06YLm
uXvDQzFlencd6aWsEDBbbZagMjHnesvD7Vs4qZaXXt01SJNhDVoroM6Z967HUeeZa7tz0VxskVfv
3H91/rVRm2uvLf71rQWgnXi6uEcEp6nFNRXIOf3quh6/XJqcrmSJNRVeziZvfa1XcgL89SazvG8Z
tfn+7e9D7dNsthYE8TJmFvrWGbUPK+eta/rRxHxt8a2mEy3ILW8MvDv6C8e7RsnoK3P9/8/e+0DF
Xd15/++0UCE6URLDumE9SSRaopuJJpsT1jXRgT4+SV0z7Daptgw90l1JHn89AlmVHbbhHKFPEdzV
wPGkkP7SYWtg28LuKfy2C/Ep4JLWhROHroMKTwIGqlALBsxMzUyc0e/vc79/5g+ZgeHfMEM+NyfM
98+9n/u5r/vn+7n3e+/9SvVW37qkmRjJc91pTYQ2/V9y2uR1TRp/eT1OfWCbWqrttqXO4ff59enk
O5q5XAh/412indfTOg3/9NE6oLnEO03v6emaKR+EDt1VYhMIWqsgq0BrC4ilvlRZayHus2MCTGBx
CCxsDr+qQzjPzcVRNywp4rkR6UW7q4RmFHHUuQsXLuDee+/FJ598co1uLhqFFPN34nS64KNe9OXK
KfoEqS4p2H3xtVaa5nPNF1o9cEzRyFxcInQ671DoNXHzhcUhcPnyZdxyyy2gbTlB2056hXpoVJOy
R+QudAv44qWL5DpJUCKVgVjOzYGBAezatUvm5IWkHnhcDjho2nQi1YPgqJQyHa9LCnpfsKbPitIg
bC8yEnfiMZsdh+8EzVenOnCNwDBlhZzqptYv0mX6B5RB6ZiidASvr9NTvUjnM7YRc4tDlDX5y9/T
2g0Xfb2bvhkdoj0J1Q5pcau8EonXHAtwKH00yYG/Ih5avRGsDC2UEb05EE1q6PIZqMk1Z/MtFwuN
N0CR+edDgBg+YQJMYN4EXnjhBbzzzjt49dVXw5Lx2muv4ejRo3j77bev8T/7c/OaIEtyQazvIoNf
/oDhkkQQRGjIx3MQv1FzKUF+As7wFCQjJikp1P24oMYPWT5kcNDrbHbLSiAuQfnwTajcC1e5BGHA
hOs5Rv3FJegQspjLaZq5TAvWsqOOEc3wweUroidMBqZyddrfMGVNC+U7nSH8rOnwSVm0oxnbiLnF
EqqsJYiOVkhRodohLcAMvDQvIX5D6RPcu4gneI6LzmDodjS4tICrcVQ+F9KkzrdcLDTewETwcyGA
B58wgdgmMPtzM7bTN5P2MWnwz5QgvscEmMAcCSTcjZ92dwF3hTD85iiOvTMBJsAEmAATYALRRYAN
/ujKD9aGCSwDgQSk7d6zDPFylEyACTABJsAEmEAkCMTILj2RQMFxMAEmwASYABNgAkyACTCBlUeA
Df6Vl6ecIibABJgAE2ACTIAJMAEm4CUQtVN6Pv30U3z22Wfo6enxKssHK4fAH/7wBzkx586dw+rV
q1dOwhY5JcPDw1wPFpkpi2MCTIAJMIHYIfDb3/4WH330Udj2oNjd7sqVK2H7Xy4Sbt8XKSOiQtRu
yykMwYyMDNx8880RAcGRRJbA559/DrvdjjVr1uALX+AXTaHoi06v6BxxPQhFiK8zASbABJjASibg
oi2kxbPwxhtvDCuZYsBYhBH2RbQ6+hYRrFYrvvzlL0dMxagd4Rd7tAujUOxTym7lEdD24f/www8D
9uFfeSldWIq0ffi5HiyMI4dmAkyACTCB2CSwmPvwRwsBsQ+//zeIIqEXD61GgjLHwQSYABNgAkyA
CTABJsAElokAG/zLBJ6jZQJMgAkwASbABJgAE2ACkSDABn8kKHMcTIAJMAEmwASYABNgAkxgmQiw
wb9M4DlaJsAEmAATYAJMgAkwASYQCQJs8EeCMsfBBJgAE2ACTIAJMAEmwASWiUDsGPwej7zNkthq
Sf5P5+xWHgHHxATGxsYw5QiSv+GWAY8LEyRjbGwCriBiYp2ah+rA/JxSh7xhiVNU8yH9ArLPNaWU
jTCVnpHTdNleKLMdCIYBWgUECBXnTGEwb10CouYTJsAEmAATCEZAtR2CttziOThDmx5MXKxeixGD
34G6g/FITEz0/Y+Px6rth9ExMl/jJ1azbGXq7ZnoQeH2VViTnIyUlBSsXROPjOImTHmTG14ZGOmo
xqr4RCSTjJSUZCTGr0Jl25BXSqwfuAbqEJ+4Gz2OuafE0XeC6s9XvWF7y6k+lSz0w3ZTaKmuRt88
9JkxBa4+ZFA+lveoJWDiLLIS18pl46FqW5CggXrMyGm67CDSQl0aqDtIDE/4lUs/n65eHKQ2KqM6
kKmjr5rCvBQizLR0+onjQybABJgAE1g4gd4Tot1OxMOVgW0zMILincKuPOh9Li48tuiVECMGP3DV
DujNzRgcHcbg4CD6ra0owElkHjiJiejly5qFRcCFnz2ZjuPrStE9PA6nfRL97TXoLD+Ep+sGvBJm
LQNkcOVm5sNU1YrRSTvsk8NorjCiaP8WtI0F7dt7ZcfKgdt9lVRdh/h5KJwYr3yERAu7+VAXur5x
xzwk+QXxXMSx/FNwJ/pdW4zDuNvwfGsrDt2hk6V5Lr2LZuTBZnfjraM7ro1hmh4Kp81YHUyvabKv
FRb6ilsuhDcg1AdMhLad+emoG5jeA0oIHmYBuoTWku8wASbABJiARiB+jfIc6Sx6DWPaRfp1DXSi
XB4/0s3rmeonKiYOY8bgFzTX3fYnSN2wEampqUjbsQ8lr5gB2ym8R4OArpE2VFY3oKGyEBlZherI
vwd9bbXIycrA9owcVDb1Qnkf4EJHbTGKK1vUUTcPehrKUFzdgT+MnUVZYSV6JnwG4lBLNcoa+mIi
Q2NTSSccF0lzw8PYvXE9EnRJSMs4jPYKE269KTBFM5UBz+h76CTvh4xfwYYkHXRJG3Hg6AswG4z4
g90ZKGiFnI1Q+a6sa0FdWQ6V8SwUVjbBv28z0duCwpwsuU681NhOqfZ9edA+NoShj91eEo6hs6gs
zEHG9gwcrmyA7+WZA2cbKuV6lKHGodxzoe2ll2Gjf8/kFqJtSDFyXWM9qDyche1CTpm/HIrKMUS6
Uh2lr2hnHS5D24DvHY5XEfngCoZs53GFjl1DbXj270/Q0QX8qPwUhnxVUw0SXA9QF+FfTpDealwd
qn4gqZpsRYALvU3VSvqyclDtbSdU8XP40cz83K3lNHYUjluILqHyJUi8riHUllWioakOhdQeZmQd
RkOP79E30laH6oYGlFG+ZRXWKWXINYYm0Z5mbEdWTjHa+tS8ErIKC1HboaZQnBcXou7se2irLkZ1
m++NmmekA8XFqrwgavElJsAEmMCSExDjZLIrwWsDvlkh51p+rF7XWm71dKX+SFHqzp8/L61evVrV
zi7VGCAZqqx+2k5KzWa9BJRK43TVbquhY0jQ50kFpgKpiy72W0zyNbOlVWpvrJCPDRXdsgx7v0U+
L2gdliatVfJxRdco3RuWqBshGWpsalzDUgGdmxoH1XP+WQwC9FlpmbnD4SBxbqmrwiCf601mydLc
LtkGRa76u9nLgJZ3ohzkldZIze1WaXjS7S8k5o77+/sl+hqfV2+lnBskq125ZKsxytwMZovUSmVc
T2k3Wvrlm87BRvmesbReam+uku8BRm9YawXVn1KlPkjj7cr9vCqpq6tRMpEcGOslJ0nqFv6gl2qa
u6Su5hrJQPe0+tHfKuqVXiqtqZeso+R7vEu+rxdyulsls17UyQpJ1CyJpNUbhdwKqcvaLVkK6BiU
FhHJdGe3ynIquiepcg+TX1E+TFJNfas0GiRLp+thtyn1G8iTGlubpVIRL8xUu8n5y6bT8fZSOQ2W
9m6pvV4cQzK3Ty9/ioK2GtJDXyOp+JWL2l+n0NkkdQ+2S0bBSGtr5PalKniYBegyU75oKnl/KR6h
k0hbTWuX1FyVJx9bbEpK5HQJnfMKpDxzI+k6LlWJvKP01Le3SxazUs40/91VIj8MUtekXWo3K/5E
mVR0qpDbZBG3fB6Kl1c5PmACTIAJhCZQXl4umUym0B6m3Tlz5ox0zz33eK/Kz0ljqVSVB0mvtsuS
e1DKozavwiLafN9z0RtoiQ9EW/zBBx8scSyB4hF4Gj1n0w1+i/zAVh5YApT2v6DeJiutGEJ6egBp
aRiVDXdTvc9QVx7svoy1WZSHnpBlrFINHwrebxEPN6Uj4ZQ7Ej4DS5POvwsjEGjwC1luyUrGZJ5B
GJda/uZJ7cOaNWiXZisDskbOYamxyiwbi5ocQ0G91wBZmNaRDz27wU+Gl9EiG+ZCO6swxPKaiaZ6
rPcZmpPdwjj3lWXhV1+hdKIVg69C0qqPc5CMZOoojLqdlC/1UrNVNYDddqmZDHUtnOS2EWuSqRrh
SgekQBoU2UbXnMPNcn5WyT2UScWILLBI/aNkHbrHJZu1P7ghLBvPkKqsikbuftGhr/GmU6Q1wE3T
Y3p7oIQ3SN3Cvp0mW2ZGaWi0DpN8tzRssyr6BUSgnMxu8CssRpsL5HRbBt2Su18MKPjyIUDsvHWZ
JV8CIqETikcY/KXtSteLLsidLy0f5XzzKysaP1+/R+2smdtVydQhoEEYrY7V9wuwlKWjSn7XU7pF
B1w8UM3eOGUv/IcJMAEmMCcCCzf4ledkf5d4BhbIAz9Om2iXK6R+eXDI91yck2IL8Czazkgb/DEz
pUdMnUVeDdq7utDe3orW9i4Mjjvx8je30Q3NrcON2uRa1yW8T5e3pa7VbiJhfTIdC0GK2/ZEIegh
SC4PZU/tVi7S37RHnqa/JfjPEQfe+vkRul0AvTIFzOuHDxaTgNhVZwo7DhymaQJvwe2cxKBVzNim
NRq5/wztZdtsZcAjdnFxrMXBp7+PDkmCc3IUXY2l6DyejaMNvrUAi6n5csty06tKfYYeCaoi8TfQ
QfewzEzM1dcf3A2t6CbeLMr/DM5ws3eeeULqARw79k1siEuA/s/TMFD7GFatWkULotfAeBzYfLMq
x6NMCXJ7Z0yJ2I5jS6LwuwqJm5QaBnm/nSR842Q9DMdzsTVlDd1Pxo/ODSOcDbecIqG4Ct8EpGnp
uEYPcd/XHjjVgNr6Bf/QO3JPoMLYiUM7NyG6bgGxAABAAElEQVRxVTxyX/klrtCC4fk6wWLDgVJQ
BxW5f/0SbFcoU+jVSzgufF1myZcQkTm9M1UTsCPLCFubTalfonIdvM9bVrTg8VrBohIm/KP8TXUa
5HrknbAo3oyN+GaaUsriNhhAb2Px//6yH46BNqrBRnzj/g2aOP5lAkyACSwPAWriUnbtpxbpOH4t
bLt/yaeXtQewafXyqLMcscaMwS/gGHbcj4w9e2hO6T7sy9iD1PXep1EQdsqj/eqnvgm/2sNeMxqG
mmpplq9wJ3HsRI9Pxvr7QVMPcKL2B3ilhMbmDu/xGkI+T3y0aASmztGuOsmoVefWxSUkIXXHAXyv
lSZTdV4N2JpxpjIw+JNcpCSXeOdOJyRtwJ6DZljIALF9cHnR1I06Qb4piapqyqJSUc5tnf3quhVQ
GfZOZLwmCbI9fQlecxBTvaiW5/GPoTx5J4quZME6OAoauAdNBULzyCcBMmjTLNm5r47SbwXofQCc
ZGW7nePops75I5uFQejClZt34PSkE5PD/Wi1mHH8yH780DqlBF6Ev5oecxHlcMTjwAk7LRYfhbW9
EXd2F2Hnd/9jRhFaWxLakw5P/LAdBhvJ2kmDButET2x2F74u4eWLf4xiqOM2vzZz+L+aod+3VTby
RVnR33Cjz7tcIKjD5JfQsfPUWhbo1U7BFH7yv3MV/82H0OBdpKzDowUF6DzyCn7wMq27MD+NbTM1
074Y+YgJMAEmsHQELl1FfMI2fJteO1YcP47ycuDYo2mIk9u6pYs2miTHlMGPq5qpHhqh10fCFmST
vViy92X0jDngmurDi/n04DV+C3eT7eEZacGWQ8dR0DyM8e4KNNPOGrXevQUT8D/+roJ2iSnCaZhh
3JEUOkK+s3ACSakgGxJHtj6Oho4+jNAe+gM9TXhyPw0l521AwFjrDGVgi4FmnlPvfVNOJc4OjNCe
7UPoqCtBbicNXv75HQvXM2YkKJ2k2++jnk5nLv757AhcjhGc+t9U/v0W7fonZ/MDWdQ7OIKTHUM0
4j6Blhd3Ir/obcTHOfEBeTQ98AB2pG6Ao68BuUU2eovwrjIy7BY1rhO/eqMPU9Tx2Lyb5KAIljZ6
oxLnge0n30V65l78Rlib+D2+v3UrUl55nYZa0vDQnnRx0a+XoZzO6+80PeYi493TW+iNQwneda3F
jr33Y8dmCr36SyFErCFOA3ijtxe9Pb3o6e1BTw+l3Teu4Au3PgMWmv8kOwoWjgtbF88s+RIkMqFC
/rEfYMDhwlhvA4pOAo/obwviE9Dd+QCNhHXimRdbMEHffRD+C+kBadq1SR78GGh4Grmn9aA5/BD9
8uytJd7F1BsMORT2JMm3wfKtXUHl80UmwASYQGQJKG+I95gqYDtegmZ9FTLp5aP6cjiyqixXbAuY
grSkQafP4b920W5g9Mqc0zypX5vyLW47B6Uqk2+eKQxmSZkSrM4/pbnPygxhJ81LFnPHae6xOheZ
Jt7K808DFwoHxsln8ydwzRz+SZtUYfKfvy8WENZI3in8NNN7tjIgtBnttshzlak+UX4q/831VnlO
+/y1Xb6Qwefw+61D8ZuHL7SU52KbGtW57rQYusa3TsVAi578FyfZAsLSGgqLMu9c4WaUmtV52bb6
wOtmeQEnLYCV68qoVKWur5EX2BJpa73Zy17IKm3s9wIcp/yhvp33vpEWiGrrBryexIE651ybw28X
8y395pgH+JVPAvVQ2gMfp4DzabJpxb9k9puPDn2B1D2uNQSBMdlqlI0AtLKl/PqvDVCPvcFo7Ylo
gwyhF/rSy0TvWoU56TJjvngVUA7UNNPUIi97U0W7d01EYFlQgkzaGgPqkrGiVV5voc3TL9A2MqAF
wWKRt6Giyxtpe6moy6XqYm3vZT5gAkyACcyZwELn8MsbuBgsynoxp01ur/LqledSwLNhzprNP4B4
dkR6Dv8qoS5FHHXuwoULuPfee/HJJ4FTB+ajqMvhoLm/8dDp5vBueawD21MycWzYjYMbtYUB84md
wwQjcPnyZdxyyy2gXXpAu9B4vYgvlYrBUjeNI+oS5s9d5LmTBCXS9pxzyHWvHtFyMDAwgF27dsmc
5q2Ty4EpdzySwin/wi/NQdcRN3/6HrruoMF8nS7wuqaT+FJhgn9+eUgOLb5IJP/+lxX/HjiUmwvK
Yy1u/99r9PC/OcvxvNqJWWTO93a4usyWL974Xb3ISNyJx2x2HL6Tdkel92bh1S8tr5LIv1faLAdT
qM1Yi58+ZkPH4W2z+OXbTIAJMIGZCbzwwgt455138Oqrr87sUb372muv4ejRo3j77bfD8r8cnsSa
ODL45Y9JRip+/2d6pOKMeDwJwugIO1YXmg7vxiF6HQ1TPf6Sjf2wyS2Gx7gE5QNF4edX8FjnlufB
ZayYqwk6JIULNITfuBDXNUYBxr64GEdxhpwJR5250Dc1kfP6vUaPOUiJpjITri6z5Yt/8mmJBi5f
oV4wrZERKyrCc3PLq6neWqwVaxZoUk93Mxv74TFmX0yACTCBpSdwXRj8c8OYgF3fLoPlwS/h4b/e
N4eOwtxiYd9MgAkwgYgRSLgbP+3uAu4K39Sfj26622nDgxoLbv/K17B7aaOaj3ochgkwASZw3RJg
gz9I1m/cfQBP+HbpDOKDLzEBJsAEYolAAtJ271lyhePWb8M3eRrPknPmCJgAE2ACcyUQW7v0zDV1
7J8JMAEmwASYABNgAkyACVznBNjgv84LACefCTABJsAEmAATYAJMYGUTiNopPZ9++ik+//xz9NJ+
1+xWHgGxO49w//3f/43Vq6+jT93NMSsvXryIzz77jOvBHLmxdybABJgAE1gZBEZHR3Hp0qWwn4Ni
l0en0xm2/+Wi5Ja/HxO52KN2W85z587hoYcekrcBjBwOjilSBERnTmy5euONN+ILX+AXTaG4C2P/
ypUrXA9CAeLrTIAJMAEmsKIJXL16VR4ATkwM+AxnyDR7PB64aItv/y2/Q3pephti0FMMaH/5y1+O
mAZRO8Iv9mgX7sMPP4wYDI4ocgS0ffh///vfR3WljByR4DFp+/BzPQjOh68yASbABJjAyiawUvfh
j3SHhIdWV3Y94dQxASbABJgAE2ACTIAJXOcE2OC/zgsAJ58JMAEmwASYABNgAkxgZRNgg39l5y+n
jgkwASbABJgAE2ACTOA6J8AG/3VeADj5TIAJMAEmwASYABNgAiubABv8Kzt/OXVMgAkwASbABJgA
E2AC1zmBGDL4xTZLnjlnl2NiDGNjY5iYcs05LAeIPAHHxIScX1OOIHmtbrUlttuS/9N5UOdxYYLy
fGxsAvMoMkFFRtNFD6Wf3SISoPKyJOWE5IYooYuo/HRR1E4uIFLXlFJvtOo3/Xx6bFF77ppS2hEZ
xsKYRG0aWTEmwATmRMDjoHZhhNq4iallaJvnpOqSeI4Zg7+v9mEkJp7AVJgYPBM9KM5ahTXJKUhJ
SUHy2kRsz6lEX7gCwoyHvS0OAZFfhdtFfiXL+bV2TTwyipv88tuBuoPxVAYSff/j47Fq+2F0jPgM
4JGOaqyKT0Qy5XlKSjIS41ehsm1ocZSMAimugTrEJ+5Gj/LdsiXUaAot1dXoW/J4ljAJYYruLacy
VdITpu/Q3kY6alHZopY1Vx8yqByW90S2wemrpnayfH5pGWsrQ+Japd6cGfVg+nnolEfZnYmzyEpc
K7cjD1Xb0Fe9c95MoixlrA4TYALzIkDPs8ocxK+hdmETtXHJaxG/KgsNPWPzkhargWLG4JcB629A
WB8OcPQiNzkd5RcL0NU/Tl9cs2PY1gz96SLoHyrD9ZXFsVA0XfjZk+k4vq4U3cOUX/ZJ9LfXoLP8
EJ6uG/Am4Kod0JubMTg6jMHBQfRbW1GAk8g8cBITwpeL8j0zH6aqVoxO2mGfHEZzhRFF+7egbWwB
w55eDZb/wO2+SkqsQ/xSq+K5iGP5p+AO7zsnS63NksrffKgLXd+4Y4FxuNBWeAT1v7uiyIm7Dc+3
tuLQHboFyp1bcDd51988vy9XD5wpAUrb4ZTcOLgxDtPP56bJ8vn2XHoXzciDze7GW0d3wE31RX/D
kteY5Uswx8wEmMAMBFxoKVwLY9FpVLXaMElf4J0c7UdNwUVkp6egacg3YDiDkBVxK7YMfg25awi1
ZbXo6W1DYUYGMrJyUN3S531F09dQitMwwdbzMvakrUdCgg4btx3Aq6Ot0NtK8HyTGIWjB3RlMer8
eniuoTYUFzdghdiGGq0Y+HXCcZHUNDyM3Rspv3RJSMs4jPYKE269KVD9dbf9CVI3bERqairSduxD
yStmwHYK79FAqmf0PXSS90PGr2BDkg66pI04cPQFmA1G/MHuDBS0Qs5G2mhUua4FdWU52J6RhcLK
Jm/5dY20obK6CS11ZcjYnoGcQhqxn1A7PqIOFRajzdvYUX2orkTHmGj86Pill2Gjf8/kFpKf4MP8
jqGzqCzMkWUfrmyA70WLB32kV05WBumUg8qmXpKoOKFTGflta6hEFtXdnOJaDEyMoEnVv7i2zftW
Zy5+h9qqUdsx4s3VETqvblPPZ2kv7GNDGPpYmMqKC50uYKy3BcWHs5AhdD9chg6VjYjvhI2K4hE9
as+KIYUrGLKdp7+aC80Es+gHxxDlb6EcZxbF2TYQ+q2BMGtt73RS+6iUh7K6s9ByT+ZZ3eGXFx0o
LqyFKAIjbZXIPE6BOy14sc6K96ady6XGM0FvfUiP7duRkUNlx0+PkbY6VDc0oIzYZBXWecuglnr5
1zWGpkqRju3IEuHV162uEaFH4NukvqZKelsyoASfIV6ljDegQcjNorLa1YJn//4EhbuAH5WfwlCQ
fr7IX6GnqBOHyxqgFe+zVE+8cdKwUENZMY0AykMJgKMPlVRWvdUlIGF8wgSYQLQS8Iz8O4zUtlV0
jePpfduQlJCApA1pOPzyL1FlIHvh737ibSOjNQ2LppcUpe78+fPS6tWrvdrZagwS9DWSXVyxWyUj
IBEEqaK+WaovNcrHjYNOcVOq0UPSV3R7w/oOnJLFQPeqrPKlrlKSYVBl0pV2M50bLZKQwm5pCXz8
8cdyntHnpSkit9RVQflL+ak3mSVLc7tkGxyfpgDlK+WdQc075eak1GzWU7hSSfE9LJH5L8vJK62R
mtut0vCke5qc2Drt7++X6Gt8XqXtthpKn0GyyhVBkmw1Stk3mC1Sa2OFpKf0Gy39sn/FL/HQm6X2
7naplPgBZmlYIKE6RG2dVGGdVGXbpSo6L+1WzvtbK8ivXiqtqZeso0FqxHi7HBfyqqSurkbJJLgb
6+W6028xyXlgtrRK7aSTyFeDWh99OhVIjc0WJZy4b66RGmvMst8KNXFz8WutoHJQ6qvzAecztheS
FOB3hnQ5+y2yfqaKRkpzq0T9UTonnkTQOdgs89CbSqVW66iPr8ZzBiYzt2dOqd4o2FZIXdZuyVIg
4qT8D5IlIiNtNQp7Y2m91N5cJetrqFK42K0iLyokb45bxX291E1ladym5iHpX99qlX477dxJ7apF
6AGTVN/eJTVW+Le5Il6l/hryCqQ8c6PSTqslS/kZl6qoXVbCt0sWsxLeYqPI3YNSHpUBU+Og4tXd
L5eLgmZBduZ4fWUkTyowFUhd7w0TI6GLSaqpb5VGqaxbqwz0PFDafPdwM92jdiavRmrvapYKZJ2U
OjHYKNiZlbZkuFH2h4JmWafR1gL5HuUsOybABCJMoLy8XDKZTGHHeubMGemee+6R/Y+3l1LdNUn9
QdrMwcY8uV7Lz8SwpS+OR9EOffDBB4sjLEwpCNNfxL3NaPA7FYO/oFVrfselUoJXIT9c6QEpHsR+
D3+f8vTwEEZPQat8yT2oNOqtwlpUHzIV3dMNTV9oPlo8AoEGv5DrlqzNNVKeQRjwwjAQ//Ok9mGt
lmoPfu2e77eg3uZTzDksNVaZZWNWk2MoqFc7BD5vsXI0u8FPxo1fJ1UYN8hrJppkKsmdA73URTaV
7JzdslFaJYx8qkPC4JeP5Ztk8JPx4+0AuG10nwzLEP0lxcDzGY/C4C0lI3PUPSp3ukz1qvFGspUG
1yh3Urw6qVZnv+iw6KtUA9Epd+qMNUp+zsWvv1EnkhNwPmN7Eeg3dLqEUdwqWRq7ZbYijuF2YUAb
ZIOZgMpti0HVPZDvzEyEXzGAEbw9m1QM5QKL1D8qjONxyWbtD2JQC41Uw9uvPIy2ik5UqSRaSrtN
GPgaa618aJ3HafpPS49zsJ7CQrLYtO7CuFRB59rgidzx9OajrErAHy0v273Nq9qRMbfL/qzygI6i
22S34GqSbFT1Z4tXk9ulqUXS3P2iU1zjHbjxLwty/fDr9Eh2vzox3iqnsZVkjTYLA1+0MWaZXTM9
U7S0BiSMT5gAE1hyAgsx+K1VZFMYLEHbTGUQRxn0WPJETItAtC+RNvhjc0oPkaLp3Nicos2PTUAy
DW0qE5vd+JTeYdN0/6BOzIDWb06W78WlZoKMHNT8nyFM2VpoGlAevrZzfdBwfHEpCYhddaaw48Bh
mpbxFtzOSQxaxSxcmp+f+8/e121iDj/yatDe1YX29la0tndhcNyJl7+5TVbOI3bmcKzFwae/jw5J
gnNyFF2Npeg8no2jDer0gKVMxjLIdlOB1mfokaDGHS/KffewykyU9oNI81aT2/AIXdGm16hBgv94
lCku7plmQhlu9q6pSUg9gGPHvokNnkt4nyRuS13rlZuwXtQ3kXmaW4cb1cU4bvm6VlmVOC9e9U2v
EesVwveryVebAt/pDO2FnyftMFi6SN/123bjtrGf0GKvVVhF/zdlFlGINep6CjcEbQTorgp0zc4k
dHuWhG+crIfheC62pqyhBenJ+NG5YYTaoEpWYudWb3lYm7KRlOjE+9q8Hsr9ILNcyM90/QPP3VcU
Abn6tXLaV61Khki97Z33lPIkKufB+6AVNTXl1/zEawWVNNyRRd2c8jflKVw7Hi0gYfk4N+VAz49I
sjkX28jvrPHKMfjKiDh1ikpBIPxLkeyN/ogpT/qKB5GkXdDdgWw6luvE+t2gt1zo6unDm784jgJL
PU0M/QXeHOjBL04DhQ/frYXiXybABGKEwObdVMM720H7EFzjfn/+Lbr2CG6freG6JmRsXohZg1/G
7fbloPywlS/qkE4PEluRGWenAjPFM3QGRzqBjLvWqTeSYDyWRws7X8GLpbSgt+LbSA1rVXCgXD5b
IIGpc7SrTjJqBxRTNC4hCak7DuB7rWQEdF4NMFAMO+5Hxp49NA94H/Zl7EHqeq8FgcGf5NLq+xKo
M7eRkLQBew6aQW91YPvg8gKVjOLg11jw2uJ2YUhbcUmrJh473hXJEJaQag3dEK8WeM8wOmzwGorC
m3C0EVJQJ9tUl/wM66leVMvz+JUAVz/VIvX5UaMMKs//olY7/a+FOg7l101G9jUuaHsR6Ct0uoC+
2lzsz38Ljd39GKcFoZNWYR76d2SErGDAwmQSVD8Xrty8A6cnaaHZcD9aLWYcP7IfP7ROa9wCk+E9
UxZ5U6dEVkGUhzZcVMtLME29AUMcNA87IVEv0E3/R23d6C58UC4zIm/1N9wYIhRdlsGSYe4X6dj5
ZoDm1MjP2g0G0JQ9fO/F46g8CVi+dX+ArFDxBngK40ToaXtjyNemUAf1DW+4JJrhaUJ50TEcO6nH
o4/sh9Fkg/ExMfRghiHN19Z4g/ABE2ACUU1Ad+sdpN9p/PiXmmWgqTuGHx+jyf3GP8Va7dIK/41N
g38WyyHN9E/UPHdi79ocNPXS6P3UBAY66rBzyyF6A1+F4n1i1EtxG//nt2GwHUc5PXuOPbZTu8y/
kSSQlIoKetNyZOvjaOjowwjtoT/Q04Qn91NlzNuAgI1igo2gqrpuMZjo6Dg20farZwdGaB/uIXTU
lSCXOnkH/1xU+uvF+XeSmlF7ugcOjwNnT1XS7iVGPHh3EqBbh3TCceLnnZigNyM9p1+he37OLSpZ
J371Rh+CfcJi8wNZZDkdwckOMp7EosoXdyK/6G3E37IF2dRPK9n7MnrGHHBN9eHF/CPUqH4Ld4c5
ihLEVPdTLPBQ8xt/wxrq5L+K3gkHJvqakFtkw2bNPpulvfCXGDJdJMstv2JKx30705DkGcQPn8mn
oGvU4NTBIWU6L/ZBXvfsLzRhFiYz6vd7fH/rVqS88jqQkoaH9ohcI+dnOCsX1L/EASV5aOijb1AQ
++O5pGPet6En/ePl1z+Up+dG6N4Aqo9Rvnj1D5ByzYlu64P0xo3ayNp/pwW5cXAMvob9+nSYu7Uc
uCZIwAXdnQ9QyevEMy+2UHlz0eLnBhSW08SdXZvUt0Q6PPoctdrlJejUV+AR1bgON94ZEfppcvt9
+4DmbJyicuvyTKHj1MtyuU9bp5N9bf2Kkcp1My1XP4ht65NwXya1KTYb9KX74Xtq+AnkQybABKKa
QFzqQdAaQZTv34TihrMYm6KZAEM9KMtKQYlNj9aqr18z0BXVCVqAcjE0nk0PMm04L3E17pyWaDF2
5R3ojEvF9yf7cVvpUzi0c4vXp8lsQUvJEwiYtKPbiedolKnzrb9BJm1Fx245CGzAc6/T8PLTJmRn
kuWvOgNN3xmuOhh2ZYzbeBCj3RY8lZ6LvbQFq+bM9VaY9wTkunYrRn81IzOY3Uf39EonSTOCjufS
lqe5Iql6WLp/id2ybbMRh9srUJ5pBL0UoY6wCTTA6nO62yFmXORTfri6J/Hcbuok+LmkHU/BarmI
nZlbIMxesujR3G/GBjLfNpQPouqjLUhPIYtOOIOZ/D4hj+Q65As+/WWDU6vX8j3S8lb/bSXD87vt
r83IO5KOncnUSaR0irR4x95naS/8befQ6QLWPlIAY74RW+KVdOWZqWfTeRy2YQd2bEvC/UV0np2N
lCtfosURd/iZ0nHYNwMTzKjfRnyPynR3+n6sFflEzmhuxJM7AvNDuaP9tSFbr0xbhKEU/f94QDaq
49K+hsaCH+PQ3k1ynpkKhAl/JfAtzvTtK7XzuDT8Y38zcrYa4c3WAgt++kSaHKk/Q02LgF/dDlhs
jcjVq+WNbhorWnHim0p44XfDQ9+gKTTlWF10wNdGzxKvEseduHm6Anrljvjrf2v9nqPotvwO6VRu
j8he9KjpGsUBte2PS70fpXS9qfQhWQcdcRejg0898qeyb/7DBJhA7BHY81wzupLLsTd7L7UwqjMU
oLW/BPuuI7tvlVhHoKU/mn4vXLiAe++9F5988smC1PK4HHA4gUSdDglszy+I5WIGvnz5Mm655RbQ
Lj2gXWi8osVXZGmslGacxEG3gAxzkVwnCUqk7TkTvNJj72BgYAC7du2SOc1Ve0dfLdboW2G1N+Fu
UCUQdWC6EPoa7JTDTVuY6tSR1kAP4uvWCTPlA9WvKSE6SHiRB24yt3S6a2INjGTRzjxw0BzweNrW
dSaVw4ouZLpcFAelKkR7In8FOS4BcSHamvkzUdJGDVl49ULoTz2+JNJzupu/DkLSHPWYHrk3fBKl
45qbM1xYaLzTRIfM32n++JQJMIFlJ/DCCy/gnXfewauvvhqWLq+99hqOHj2Kt99+e5p/tR2JS4zg
c2maCuqpWAdGi3blDwQG97H4V0M8lhY/ouWSGEd78CfN6cGyXJpyvIJAHO2RKwrlQrMsIZhxe70h
dl+mFDfLnSfBI6gj4zRphgoyo7EvBM5QvyKfB9RJTJpp5DsogeAXQ6YrgeIIXTpF+Z3JzZ/JHNMW
Un+RZUE6fjMpHXBvjnoEhBUn8w0/33DXKKBcmIFPiBB8mQkwgZgnsMjtSIzxiM05/DEGmdVlAstB
IHHz12g3o27cFbAIYjk04TiZABNgAkyACTCB5SSw4kf4lxMux80ElpNAHC2GzshIXU4VOG4mwASY
ABNgAkwgCgjwCH8UZAKrwASYABNgAkyACTABJsAElooAG/xLRZblMgEmwASYABNgAkyACTCBKCDA
Bn8UZAKrwASYABNgAkyACTABJsAElopA1M7hF9s1rl69Gvfdd99SpZ3lLiOBzz77DOvWrcNf/MVf
4Atf4H5nqKz49NNPaVvMBK4HoQDxdSbABJgAE1jRBMQ23h6PJ+znoNPpxMcffxy2/+WAJ+wfoWck
XdQa/F/84hflvcfLysoiyYPjihAB8X2Fxx9/HD/4wQ+QmMjbyITC/v7778v7CXM9CEWIrzMBJsAE
mMBKJtDY2Ijf/va3+Lu/+7uwktnb24tTp04hmp+bjz76KMRe/JF0UWvwi9F9YfT/5V/+ZSR5cFwR
IiB67MLt378/4MNbEYo+ZqIRH96Ko684cT2ImSxjRZkAE2ACTGARCYgPaH3++edhPwe/9KUv4Wc/
+1nY/hdR1TmJEm/vI+l4LkUkaXNcTIAJMAEmwASYABNgAkwgwgTY4I8wcI6OCTABJsAEmAATYAJM
gAlEkgAb/JGkzXExASbABJgAE2ACTIAJMIEIE2CDP8LAOTomwASYABNgAkyACTABJhBJAmzwR5I2
x8UEmAATYAJMgAkwASbABCJMIGYMfo/LBU8QOK4Q14N4ndMlEZ+Qrf2nLWAXzQXX2UNxLWIki6Zt
pAQFpn9O+e1xYWJsDGNjE1jxCCmtwcqJXF6XoPgEL6uRKhOAa0rJV8cSpC1yqeCYmAATYAJMIBoI
OCbEM2UME1OuaFAnojrEiMHvwKmvJiJ+VRlG/PE4evFV2sP9pd4p/6sLP3b14iDJFfvDa//j41ch
q7gBEwuVHkJnR+9LFNdLWOSULFTbiIXvq32Y0n9CTX/4+T3SUY1V8YlITklBSkoyEimfKtuGIqZ3
pCPqO/U4cYpHw4B/Y0W8didi90u9i6tOiLK6uJGEljbWVobEtUq+nhlliz80Kb7DBJgAE2ACMxHw
TPSgOGsV1iSLZ0oKktcmYntOJfquI6MrRgx+4IY1IitLkFvZ48vTeEBcXoqdTO3Qo9E2iOHBQQzS
/+7mKjSXZ+PJugFf/PM5CqVzvEhFAqL2wwjzSetcw+hv8KY/rPymjlluZj5MVa0YnbTDPjmM5goj
ivZvQdvYSjUQdTLV7K2lgZ3fdcC6xa4IVFaFu5k6VMvhBs6UAKXtcEpuHNx4XdeM5cDPcTIBJsAE
VgYBGrzKTU5H+cUCdPWP0xdu7Ri2NUN/ugj6h8owtjJSOWsqYsbg11LSWZSOugGHdgq79wgYaqtG
bYfvHcAInVe3qeeuIdSWVaPjbAsKszKQkVWIlr4RDJCfjO0ZyCmsRM+Y/6jpOtxxZyo2pqYilf7v
PpCHGj3QfH4YrqE2FBfXQbMpB1qqUVzdASW0C23VZWgSOqpxtrTUIicjwzvy7K+zn/q+QzlcJRqa
6lRdD6Oh53opkj4M4mim/PaMvodO8nPI+BVsSNJBl7QRB46+ALPBiD/YI/vJ6kCtI3FWHtj59YvS
NdKGMm95pGI40oHiwloMqcV7pK0WZbUNVB8OIyMjC2UNPRgbOUujH6JeHEbdWV8dEh3qX7WeVMph
TiGappXDoY46HKZw20lOdVOvb9pdiLLvp6Z86Bg6i7LDWXIdPFzWgCG1ao+0VSLzOHnptODFOqtP
rp+AkQ5KR3Udqotz5PjL6jrgaxmAULLP1pWhskXruI+hoayY6pf67s7Rh8piH6tQ6ROMK6sb0FBZ
KLclHSP+bYeqpGBQWIw2DTy1EG3VlehQ25mZ9Xeht6kaOXKe5Mhsg8TgR4MPmQATYAJMIBiBvoZS
nIYJtp6XsSdtPRISdNi47QBeHW2F3laC55tW7qwAfx4xY/BfJSvZWNMKSx6Qu7U8cHRTTdFl2ykc
+fWH3vRdovP8c+q5+zJaS/KRudeIzaYCZP3RWzDqN2Fr0UX8bdm3gONFSH/xdW9YceB2+049E+9i
wAYYbktGwpovobw8F6+PiFHkCbQcy0d5vgUXxBPZ8RaK8kvwaTwNj6pxGo0nsHr7nXQzzFFKOVwR
sg/lIu3I8yjIALLTU1DX52/O+HRbiUfh5Hdc6i6YKfHGTfE4XFaLlo5ejDi24PsdP8fBNGUkfOWx
GaUEW9DdWqp0hvquNQPdl2woyX8TWpfHfeltlB8/gY/U8mwfaUXJkWy04kE89dhmlGSnI2XTd3DL
15+ietGN3L350MQKiqeL8vHH3/4untr2EQ5ROWxQO9xDLYXYkpmLdVnP4RUqpPmHduJgba+CPIyy
7xlpwZote9GE/fjuKwVY3ZSNLWuKIarV6pQ7qHkml3IXUm+LD2rw2y9QOvJz0XGLESe/m4Wm3EwY
q5U3gDPJ3nDTeRQZf6xMzxt5A9kl5cj+yX/Jeo/9+kcoKh9BIr0tmSl9bvsI1fNsZNdfwXaCFL86
yOsVYvDT4+WwXfbmBM7nF+HX7yvnM+k/0fEidh46hcyny/Hdr98lsy3tWPCEQiVv+C8TYAJM4Loh
4MAbJ2g0v+I72Da9md7wEAoNQPfY5euDhhSl7vz589Lq1atV7exSjQGSoaZfkuxdEg20S4YqK93r
l4x0XGWdlP1ZqwySvkJcV1zAudMq+zW3j8o33f0WiXJYalVOpf4aowR9lSRLIr9kbMj3hR/ff6PU
Ouyk8JMSjfZLxvphrz7CT/2gm9QrJf9mSRarxpnXOKhqRD90jcqXV2fthtNWReGqJLu4oIYrVXWl
C1K9EQFp08LF6u/HH38sc3U4HHISbDUG4l+jpJ/+hpPfckDnsNRYZZaZavlkKKiXxmMVzDS9+/v7
pZtuusl7VePkpDJhoTIhytq4OBb1Q64TVCT9yxKFtNtqyJ9BssqFS5JkGQaN9bhUSuXRUGNT4qCy
pye/3cKvWg7NWiVR49HL8Sh5pC9tl9yqdv31JoqnQKJq4A0bUPZVf9qPqJ9AhVLnxEV7t1y3lfqs
pknTSwvk9yunw2ghrRQ33m4meXly/DPKHm8lf1T3qbKPNhfIx1qdbTZRPQsjfQpTvdSlND1+Wvkd
XlPX7VIVtRsVans1u/4GqdE6TOlzS8M2q9Q/qmagXxR8yASYABNY6QTKy8slk8kUdjLPnDkj3XPP
Pap/sp+oXUdpd5DwdvnZiYLWIPeW9pJ4Bn3wwQdLG8k06TEzwk9wgKtXAN0e/FtzATrzd6Lh7Bhm
GsdVpyDLQcUfMZXmtluUEE73VTozIFkV4Jbv+uaQi7H0quZ2dLW3o729Fe3dNky6f459G0UXMQkP
FhrR3HoOA+deh81UhRp689DaY8O51hLqSRqxgXwJJ+K858vJ8nHgn8DR/tH/+w5o2UCAc0JLQQJ2
ZBlha7MFTFkI8LwST2bJb49rCmOOtTj49PfRIUlwTo6iq5FGvo9n42jDwEok4k2Tm9Z7PPHDdirB
5Xiy+jVcTfHeUg+C72olboqir9+3S607CUimcrdv1594BazzHql1RqskFOfOx6gcnnuPdgq6gF91
AraSTFpMvwqr6P/W7NMU8iI+Uge0Q5d9JQJRuvUVD1JtUp3uDmTTofLOwg1RQ3HV7zWb6k37kdOR
ofeu4dGt30i3Lsjxzyh7/W5Ukc+unj68+YvjKLDU09uEX+DNgR78gpJQ+PDdpMTs6aNVE7hRq8aO
HmxXOQgWlT2zrwSbSf8duSdQYezEoZ2bkLgqHrmv/BJXlmkthcabf5kAE2ACsUfAjU/JoKMlgkGd
eM7oNwez0YJ6j+mLsWXwq6hTD5SCRjeRvTeT5mXRgt4QWeB2XQpyh+YLhOHsZEo98HAG9tDc+4yM
fcjYvQ1J2sOdwm8x0DuA02X4+8IS5BkfwaOPmXE6OxeZ5WQwHCCDwd+5/eJU7ZfLnwROxfjovW45
hOZT7pys971/Gv4veiW1b+uMHRz/KFfScaj8HvxJLlKSS7zTuxKSNmDPQTNotBu2D66DV3TrM2Ch
zm9zvhFHqCKs8VYEcdCGi2oR07qNocqEbFiHuimui+lpqrvYS+Vw2+00B/I23EXXjBYbJMlNi6Do
/3g/dY5LcJf/Gl//sq8JUX9FVbC9MeSbruO5hDem+ZnpVGhl+/Bjrxe33Ilfg9V0Y2bZSTDUmFBe
dAzHTurx6CP7YTTZYHwsDydpkpghjepduOnTYk+8Cz+1WmEV/7uteOwuGklQ6/oN8WrD4RlGh823
ycBM+jsc8Thwwg6nfRTW9kbc2V2End/9Dy02/mUCTIAJMIGwCOiQLgZMi8w4O20cxjN0Bkdo4Crj
Lv9hrrCExqSnmDT4aZhfHd1UmGsGSzxt7WIrehW9Ew5M9DUht8iGzZrNrD5855JL/nP4p4eL23g/
SvU2NNMD/MFdqdiwbS95oRMUYM8W9bXB9EDiXLcZ36LOSsneJ2mh4ADGaE/YnqZKpJOuhuz7vKOd
a8hr/rEfYMDhwlhvA4pOAo/obwsm8Tq4Fjy/5U4XjmMTba11dmCE9tYdQkcd7eREFfjgn99xHXAB
NqqdXzmxakWIjxcGfyd+dW6E9rEfQPWxI3QuStQcHdUZpRxW02JapRweo3J48M9uJ0Eb8BdmWsSe
+wrOjjgR5x7BySe3IjPzF/D4dYxnivH2+/aRgGyc6hii7ydMoePUy2imAGnrZqg//gLFVk7l30NT
H31/gdJ5/Jl8mtHzbWylOj+b7K1foUpIuzTYcBDb1ifhvkzqwNts0Jfuh3hPEG76vM1KXBLSduzA
DvF/9w5sFKMDunVIJ0knft6JCXob1XP6FTl9snjxZwb93z29BVtTSvCuay127L0fOzaT/9Vf8gbl
AybABJgAEwiPQJrpn2gopxN71+agqXcIU1MTGOiow84th2iiRxWK9ymtfnjSYtdXmI/m5U+gd/BS
U0Ue3TRjk7HcO8K/7a/NyDuSjp3JYnsPmolMf8VIuewSV+NO7dj7628E0fGcOnkb8PDfGGnR4Gbs
TiGBcXrqAABNBx9Fqh9V/xiUaJPwBI2Kvp9rooW4W72aGM2N+OFze7zn8sHFImxdUyQfmiraUbKi
C2Ug/3DyO27jQYx2W/BUei720vZamjPXW2Hes147XVG/8ToqbAHlVHSGuvDzZupwqtAS0r6GxoIf
49DeTSATGKYCmm+GK96BejGy7O9EsMD3TepdqjPCzkRzES2mVcthVReezVAmrGWUDKPm0gHs3aSW
cn0e2oefhUb+2rKvylV/1u85im7L75CeuQWiSyLqbE3XKA74b8F5w3Rt1cDen0s4pFdfxxpKYfvH
A/LS+Nlkx6VSh51kNJU+JOurS99PZ6fx1CN/6pU8U/roDTG5O2nLUq/3IAcbcbi9AuWZRtCLKHqw
mOQ2KdBjcP13/y8bzG16tS2jEPoCdP/wK4FB+YwJMAEmwARmJxCXiu9P9uO20qdomuQWr3+T2YKW
kie8zyzvjRV6sErM6Y/GtF24cAH33nsvPvnkkzmq54FjyoF4XRIS/AzvOQqJiHePywGH04O4xCTo
aFTS62h/+YzEnXjMZsdh6qU4kEj3ozwxXuXDO7h8+TJuueUW0KJd0KLU8ALN4MtFcgglEml7Tn+U
MwSJiVsDAwPYtWuXzGmuCgsmbloHogsoXHOVovh3OabgjqetT4OUQ5k9eUvShTkyP10FqgdTNO9f
R3k3l1LeW52BZ2g2fsfTW4mPJ3g65ynbX8UFp4++jjzlcF+TvnD0X8w89E8THzMBJsAEYoXACy+8
gHfeeQevvvpqWCq/9tprOHr0KN5+++1r/Ct2F9kK9LwK8ji7xv9SXRBrvWjRrvwRsKWKY7rcuTxf
p4eN0vM4erB6lwFGqY6KWnG0F2xSCOv0Enm5fIUs2ATqDER1KqJDuQRReaNDlajRYjGZJIgOdIiU
LTieGepBiCiVy65OdIqF3dRN0OlCNGXzle0X8YLTF5eApGAVPQz9Fxy3Xzr4kAkwASZwvROYye5a
6WxCPCVXerKjPH0Jd+On3V2AWPjHjgkwgaAENn+tG91usXQ4Nl2s6x+b1FlrJsAEmMD1SYAN/qjM
9wSk7Z42nz8q9WSlmMDyEUhK3Y3dyxf9gmOOdf0XDIAFMAEmwASYQMQIxOguPRHjwxExASbABJgA
E2ACTIAJMIGYJsAGf0xnHyvPBJgAE2ACTIAJMAEmwARmJhC1U3r+8Ic/4MYbb5R3KJk5CXw3Fgl8
/vnnuPXWW/Hggw/iC1/gfmeoPPz000+RmJjI9SAUIL7OBJgAE2ACK5rAxx9/DDd9GEnsWBeOu3Ll
Cu21PxW2/3BkLrYfYf84nbQ9XQRd1Br8wggUWzf+wz/8QwRxcFSRIiC2WzWZTKiurpYN2kjFG2vx
iG27nn32Wa4HsZZxrC8TYAJMgAksCoF//dd/xfvvv4+CgoKw5P3mN7+BxWKJ6ufmX/3VX0FszRlJ
F7UG/+rVqxEXF4esrKxI8uC4IkRAdOaEe/TRRxdlH/4IqR3xaMQ+/FwPIo6dI2QCTIAJMIEoISCe
g8KFaw8K+1F0EsL1v1zJTEgItdn10mjEcymWhitLZQJMgAkwASbABJgAE2ACUUGADf6oyAZWggkw
ASbABJgAE2ACTIAJLA0BNviXhitLZQJMgAkwASbABJgAE2ACUUGADf6oyAZWggkwASbABJgAE2AC
TIAJLA0BNviXhitLZQJMgAkwASbABJgAE2ACUUEgRgx+D1wuTyAwjyvItSD+AkPN+cwxMYGxsTFM
OabFP2dJHGBmAoF553G5EIy4K8h1j2NKzqOJCcfMUayEu8HKPaVL8JpeRRYjucF4L4bccGW4psYo
byfA1S9cYuyPCTABJsAEQhFwTIhnyhgmplyhvKzY6zFh8A/UHaS92ssx4c2GKdQ+nEjXDqLHa+N5
0PZsPBIf/xkWIxs9Ez0o3L4Ka5KTkZKSgrVr4pFR3IQpPx1aaA/5Pm/83ht8MA8CfbUPU36eUPk6
cOqriYhfVYYRf1mOXnyVPkL1Uq+WC1NoKs5C/Jq1ch4lJ6/Bqu2FODsWrKvgLyh2j/tOPU6c4tEw
4F/KidfuROx+qXdxE3YN78UVP5u0sbYyJK5NobxNxpnRGM/TqV6UFTf4tR+zpX76/SlwezOdCZ8z
ASbABMIjIGy64ixh04lnSgqS1yZie04l+jRzIjwxMe0rJgz+TeliL/4m9GkW/9R5/LRTcG9Gz7ta
bo2j6ziQZ9qNhe9s6sLPnkzH8XWl6B4eh9M+if72GnSWH8LTdcp+sPBcxLH8U3AnxnT+R5fy+hug
fRjihjVCtRLkVvb4dIwHxGUtf8faXsSh8ouwdPXDbrdjfLgbZhzH3v2nsHL7YTqZR/bW0sDO0Dpg
nQbGR2xhR8RbuJvjl6eQD5wpAUrb4ZTcOLhRKxmKTrH21/PBL1FS/hHmTZLbm1jLctaXCTCBaCFA
g1e5yekov1iArn6y6Zx2DNuaoT9dBP1DZRiLFj2XWI+YMPgTtqTDBBt+/Z5i8U/8phmdejOqCvTI
b35bQTRmQzkdPXL/Rvl8pK0O1Q0NKDuchazCOoz9YQi1ZdXoONuCwqwMZGQVoqVvBANt1cjYnoGc
wkr0jGmjpk44LpIYw8PYvXE9EnRJSMs4jPYKE269SYh3oe2ll0kjG57JLUTbEJmXLkV+S0stcjIy
UNk2JOvBfxZGoLMoHXUDPvPd7ifuw/PdgD4bxj1p0Ol0WL9xN8ynLTBsHse4lpV+/lfWYXlgZ8gv
ca6RNpRVd3jfdLlGOlBcWIshlclIWy3KahuoPhxGRkYWyhp6MDZylkY/RL04jLqzvvcqooP1q9aT
Sp3JKURTT2DTONRRh8MUbjvJqW7q9U3DCrM+OIbOynVU1MHDZQ0QVUm4kbZKZFIHHp0WvFhn9cmV
74rq1obiYqrX6sD/QEs1ir1ppvpZXYYmtdyM9bagmNqBDKqXOYfL0KFFEkRHmV1lA9oaKpEl/BfX
YmBiBE1lOXIai2vbQo/SO4ZQV1Yox5NF8bQNKIMRQtdnj9WT5qdg9urowFmKI0cwJ3aFlU0YUfNH
6FBZ3YCGSpJF7VTHyMfXtjeUu71N1Ur4rByZ/Yov8mre8w8TYAJMYC4E+hpKcVpYkT0vY08a2XQJ
OmzcdgCvjrZCbyvB803Xh70WEwY/4jbBaKIx/v98T85j6/9XDv3fHMQ3Hj8IlLfKvbOJgS66Z8af
bVBGAu0jP0Z+djY6sRl/lHgTdNJltJbkI3OvEZtNBcj6o7dg1G/C1qKL+NuybwHHi5D+4utqGdLh
7mwDDTCn0yufYtS1dKBvaAIZz72Klw+mkZ8EbNJvo189DA/sQjJNsYBbkW80nsDq7XfSvdgekVRB
LNvPVbLsjTWtsOQBuVvLA0ezVa3ufvhvAVsR1q7KQmVdE872UqXd+gQ6fn4MqYs92r1sJKZHPEpg
LOhuLYXcGeq71sxzX7KhJP9NONWg7ktvo/z4CXzkVi7YR1pRciQbrXgQTz22GSXZ6UjZ9B3c8vWn
qF50I3dvPjSx4n3C6aJ8/PG3v4untn2EQ+kpNJ1IscqHWgqxJTMX67KewysFGcg/tBMHa9VpRWHU
B89IC9Zs2Uvv7vbju68UYHVTNrasKcYIGfGrU+6g5plcyl1IvS3+GoM/Yc2XUF6ei9eFZ5rs13Is
H+X5FlwQOBxvoSi/BJ/Gx8M1UIeUnUa8n2rC888/h21XSpC5RS1PQXR020dQUpSN/RW/g6mA2oXy
I9iavAknnA/g2GN30+l+/LDX1wEVKirOhYacLci1/jGe/8dyZK0uwf6tX0Mv6RO3JgVpd28mb3qk
3bVe9t5T+QD2ZtfjgW8/j+cL9uOtokPI/ec++Z7QoSg/G9n1V7CdMiB+9S3XtDcTHS9i56FTyHy6
HN/9+l0y+9IO7RWoohH/ZQJMgAkwAQfeOEGj+RXfwbbpdsGGh1BIpl732OXrA5MUpe78+fMSfR7Z
q91gY54EfY3klEalAkCqsDolyd4lUS5JreNOqbsUEsztXv+2GiP5r5Ls2hWnVTKSX3P7qHzF3W9R
wiqnUr/qf1LzL7kla3ONlGfQy/5EPDRhSGofpniFc9skAwyS1a2cSqr8vMZB9QL/zETg448/lrk6
HA7Zm63GIOevkl92qcYAyVDTL+exntgbqqzkr1/OwyqrL5cm+9uligLKazl/RB5BKm2mcCvE9ff3
SzfddJM3NRonJ9UEi1Gk1yyNi2PBS2ZEyGxVdN1X9u22GjqnsqpWBlmGoUatG+NSqeBbY1PioHJM
3VipW/jV6kyrWknUePRyPEoe6UvbqaYorr/eRPEUSIPiQhj1wVpFeY4KyZub9m6KG5KSv2qaNL3U
OHw/k1KNHpKxfthbRkTe11Pk9q5SkmumlkKSxm2tkqWx26vjcHuFzMI/ff51VmGll7pUpbR2QUHn
lMulMahOk1IV6YMCi9Q/Sr7d45LN2u9tf9z9Ig9E+yWck9qWeqnZOi6fSW671FwASV8hyrjIP+HX
p4N8cVp7o7AzSI3WYZLmloZtViVe2TP/YQJMgAmsHALl5eWSyWQKO0FnzpyR7rnnHtW/U6o3Udtc
2h0kvF1+dqKgNci9pb0knlcffPDB0kYyTXpsjPATmY27/geN5v4K53rfoFnaRnzlbuqq6f4UFXTv
zH++gf9soum++8Wou+rEEPHB+yBGKDUnpoPcdotyxem+SmcGJKse3BB3tTnkLkyMTWHHgcOo7XgL
buckBq3NyMNJZOb+szI/3KMMl7q1YVQKLSTc8+Vk+stuUQhcvUJ5vAf/RtZQZ/5ONJwdC8hPsdoe
WzLw3Ms/BxlRNIffBovZgBLjY1jpg51uesv0xA/bqQSX48nq13A1ZTrx4LscCV+i6Ov37VJZJiCZ
rOx9u/7EK2Cd90gp07dplYTi3PmYEbZz79EOWRfwq06qkiWZtLh6FVbR/63ZpynkRXyk1onZ6gO9
F6NRlweRpMWnuwPZdKy8s3BD1FBcVV9LaH68v0l4sNCI5tZzGDj3OmymKtTQ26DWHhvOtZaQXCM2
kN/123bjtrGfeHXclFlEV9dAxC1ccB3X4Ub1BZ3WLii+FV0uBtUpCd84WQ/D8VxsTaHF4/HJ+NG5
YXjECwhySntzFYqEBOj/PA0DtY/J3FbFr4GRpi9tvlnxq/z16SCfT2tvduSeQIWxE4d2bkLiqnjk
vvJLXFmmtRb+WvMxE2ACTCC6CLjxKb2UpSWCQZ14zug3Xx92W8wY/HEbd9GEndP4zjOHANPXIex9
kKnwlSojjh8qRJHNiIf/VHldLu6IB6v+hhvF4TSnPoGnXQ04nTqHZNoZpFbdCSUuIQmpOw7ge630
bqHzasD0Apo1EOjcYcgPDMFnsxBIPVAKGs1G9t5MKgGiWybcFCy02n5t+Vn5TEyzWr9xG54orSIj
2Ia3359Sr6/gn/UZsFBnqDnfiCMEZo23QRMHbbioWM5e4zYUCdmwDnVTXPcr5Bd76dXotttpDuRt
uItuGS026my5aREU/R/vR3t7Ce7yX5k6Q30QddT2xpCvPnku4Q0RX5hui8FE843K8PeFJcgzPoJH
H6MWIjsXmeVA4YG7ZSl9tbnYn/8WGrv7MW53Y9JaRdeFme/nZtDRz5f30L9D5L1I3ZQrN+/A6Ukn
Jof70Wqh5eNi+o/VrxzSE0dpLsZQnrwTRVeyYB0cpUXJEqwVejSPfOITF+JIywqHIx4HTthpQ4FR
WNsbcWd3EXZ+9z9ChOLLTIAJMIHrlYAO6Vk0UFVkxlm/5ljQ8AydwREauMq4K3irvtKIxYzBT5N5
sddMBgJlTp7RtxPPnYYsyhMbDdbvx93eocIg2aQMrQW5EeRSUiro+YsjWx9HQ0cfRmjP1oGeJjy5
n4bh8jYoO224hcBO/OqNPlyH27kGgbaUl3TqaLYSh2KgJsFgIYOvZC8KaSHlwMgYRoZ6Uf3/6ClX
TDDMWBiWUtfIyt6odobkWFXLPT5eGPxUNs+NwDU1gOpjR+h8zdwVoyIuQuUfq6bFtC6M9Tbg2El6
cfZnt9PVDfgLqo/Nua/g7IgTce4RnHxyKzIzfwGPOjo+W4S337ePBGTjVMcQfUNgCh2nXqZ9t4C0
df7v5UJLidt4P0r1NjRT9X9wVyo2bNtLnukEBdizRZHhFm/6kI77dqYhyTOIHz6TT+fzYEGhNHdJ
Owj4/T2+v3UrUl55nZqqNDy0J125qw0IyL2bXpwboSeOx4kP6K7pgQewI3UDHH0NyC0ivbvfDdhd
KqDJmtbevHt6C71JKMG7rrXYsfd+7BBLBFZ/SYmT/zIBJsAEmICXQJrpn2jAuBN71+agidb6TU1N
YKCjDju30ACyoQrF+zZ6/a7kgxgy+OOg/0op5YUej+zyZY7uzp001YYent+6P2C6h/ac9WZe4mrc
6T3RDvwf/HTs7eRtwHOv21BhuojsTD020Z6tW9MPwZ5Xg+GqgzSWTE53O6jTiHy6/8O3lG6jvzQt
Bv4Nl4A/f20U3y+sPJpNFiY5bSB72xMn0F5VII+kbt2Ugk1bdiK/24Tm/uprF+f4iYrlw3hdil85
FSkRnaEumuRGTgWTkPY1NBYYkL+Xpnus3Yq+zaKG6LwD9dPrhsZTiAhwVGeEHYnmIlpMm0iLX7Np
WUwXns0Qk2VoVKRkmKbRdGPvJpois2YL8i/moX34WWjv2WarD+v3HEW3pQBHMrcgMX4tMo90o6Zr
FAf8t+C8Ybq2ctTqnw14+G9Eyguwm7BgvZ46ANRClD6KVLXTcfcjBcSmHFviVyGeWAyl01s66lbY
hukdL7ngOvpfpWNvuyAHgf7W1cpBwN+N+F63BfqS/VhLcSVuMcJobsSTO5RRiMR1d9Gbp5PE6mvo
cabiO/UFOH1kpzylJ1n/MzxipnR0jmDS+4LwTtoO1S+Cae3N7v9lg9lwHDuTE2n6UAqO0HZz3cVf
8QvAh0yACTABJiATiEvF9yf7aWfHUZoGuQVr1yZjK204oTdbMPwfT3ufWSud1ioxpz8aE3nhwgXc
e++9+OST2V9zL6X+2hdf3bTrji7h2qFL8QXghCDXl1KnlSD78uXLuOWWW0CLdkGLUheYJBccU04a
WU5Ekk7uJVFhkQAAQABJREFUji1QXvQEHxgYwK5du2ROc9XKRWzdNIlEtwhMXPQ1Y3e8LngdoHjE
tP0k2hp1Xs7lAGUfdEm6JdrbSpQPIkH6LX1V9VBc1JlIDMaKviZNBn1CnNKOeCjdDhrGF1vKXtuy
BCc5vb1ZzDwOHiNfZQJMgAksL4EXXngB77zzDl599dWwFHnttddw9OhRvP22um27Xyi53aXnTWJE
ngd+EU87FOveaNGu/BGwabeW7DTc58ySKRDtguMSEuSHcSgzko39aMjBBDIWQ+VQNOi3PDokiAZt
kaIW36IIJWvB8dCeyEubfZEsHzQwkBRqbmFcQIcjbh7pnt7eLJj9IpUPFsMEmAATiAUC82l3YyFd
4egYQ1N6wkkO+2ECTIAJMAEmwASYABNgAkzAnwAb/P40+JgJMAEmwASYABNgAkyACawwAmzwr7AM
5eQwASbABJgAE2ACTIAJMAF/Amzw+9PgYybABJgAE2ACTIAJMAEmsMIIRO2iXbE7j1jFXFtbu8KQ
c3IEAafTSdtExuNHP/oRbrgh5MaQ1z2s3//+9zIDrgfXfVFgAEyACTCB65LAm2++id/97ndh24Ni
dzuxA2A0PzeF/eNyqV/HjFCuRq3BL4x9sW3jv//7v0cIBUcTSQKfffYZbr31VrS1teGLX/xiJKOO
qbhEg3DzzTdzPYipXGNlmQATYAJMYLEIfPjhh/IgYbj2oN1ul+2KcP0vlp5zkSPsn0g73oc/0sQ5
PpnA4u7Dv3KhLmQf/pVLhVPGBJgAE2AC1wuBxdyHP1qYLcc+/DyHP1pyn/VgAkyACTABJsAEmAAT
YAJLQIAN/iWAyiKZABNgAkyACTABJsAEmEC0EGCDP1pygvVgAkyACTABJsAEmAATYAJLQIAN/iWA
yiKZABNgAkyACTABJsAEmEC0EGCDP1pygvVgAkyACTABJsAEmAATYAJLQCBGDH4P7VfqCUy+xxXk
WhB/gaFmPfPIcoXs6f+nxT+rJPYwNwKBeech/sGIi3yZft3jmMLY2BgmJhxzizIWfQcr95QOwWt6
FVmM5AXjvRhyw5XhmhqjvJ2AY3qmhytgEf0JxuE60Y5EQuXFiUfUvfDTFi6D2PQXeywWpwzEZm6x
1kxgrgQcE+KZQvbC1PXX5sWEwT9QdxCJieWY8ObsFGofTqRrB9HjtfE8aHs2HomP/wzzzkZXLx6O
F3KD/d+Js964vIrwwSIR6Kt9mLifwJQsz4FTX01E/KoyjPjLd/Tiq5Q3L/UqvkC+m4qzEL9mLVJS
UpCcvAarthfi7FgkTC1/xSJ33HfqceIUj4YB/1JOvHYnYvdLvYuryDW8F1f8bNLG2sqQuDaF8jYZ
Z0aXJk9HOmpR2TI0mypwDdQhPnG3X3szUxAHTlA7Ut6jldOZ/C7k3uLE4+h9SW7zfG3pQnRanrDh
5uNs2jn6ThCLr4aZz1Noqa5G34KfCwuRszhlYDYufJ8JxDoBz0QPirNWYU2yeKaQvbA2EdtzKtG3
1M10FIGLCYN/U3oWIWtCn2bxT53HTzsFxWb0vKvl1ji6jgN5pt1ImC/ghDthGRzE4PAwbM2lJMWA
RusghsW1wRbcq5uvYA4XFgH9DdC+BHfDGhGiBLmVPb6g8YC4rOXvWNuLOFR+EZaufogPbYwPd8OM
49i7/xQW/Az2xRplR0ohzN5aGtgZWges08AslsbEW7ibyXhdDjdwpgQobYdTcuPgRq1kLKYmLrQV
HkH9767MKtTtvkp+NmN1WCjicYMeuEHlN6vweXtYnHh0dz6G9tYu3BFW2uat7BIGDD8fZ1MiMV5u
eBBW1nku4lj+KbgXym1BchanDMzGhe8zgZgmQINXucnpKL9YgK7+cfqIlx3DtmboTxdB/1AZxmI6
ceErHxMGf8KWdJhgw6/fUyz+id80o1NvRlWBHvnNbyupHbOhnI4euX+jfO6Z6kNt2WFkZGQgI+sw
qlv6Al6xO4bOorIwBxnbM3C4sgEj8oCpDhtTU5G6cSPu3Jwsy7nj7lTlWupGCFPLNdKGyuoGNFQW
ktxCdMgBXehpqERWxnZkHS5DbXUZKpsC45OF8Z85E+gsSkfdgM98t/tJ+PB8N6DPhnFPGnQ6HdZv
3A3zaQsMm8cx7j8A7hdm5RyWB3aG/BImymhZdYf3TZdrpAPFhbUYUpmMtNWirLZBrR9ZKGvowdjI
WRr9UOpK3VnfexVh/vyq9SQKxb2cQjT1BDaNQx11OEz3tmdkobqp11fHXEMkvxotLbXIoTpY2RZ8
FF3Uw7LDWUo9LGvAkJrVI22VyKQOPDoteLHO6pOrptM11Ibi4jpoL3MGWqpR7E0zGYBUB5vUcjPW
24JiEQfpkUP1s0ONZKStGidsgO2IHrVn1XS5RtBUXUx1OQNZOeR3QBtQEBE3419OVMrpEfVckyOr
5BhAXTG1N9SelNX9GwZIrs950EfMc2ROOdQ29HrzRviZ6CP9crKIYQ7qWppQWebLK58M9WjGeKh9
GutBJaV1u2jXiKfSrgEircXVbb54PWOkL6WBPLgmh/Dm+SnEaX2qmRh4JmhUm9q+7dupPBSjLYBP
oLYjbXWobmiQ8zerUM2rGcO70NtULXPKyMqRy5N/NQ5V1oLl41QflQ85z7NQSO27VvYDNVTOJqh8
FBJ/0Z6/1NhOFxWjX74bUl8qYy+9TE8lG57JLUSbWqZC8ZdlBeU6DzmzlAElVfyXCTABjUBfQylO
Cyuy52XsSVuPhASy9bYdwKujrdDbSvB8U/DnkxZ+xfxKUerOnz8vrV69WtXOKTWaIOkruuXz1gI6
rrJK492lEmCWRunqeLvZeyxJw1IBIMFgllq7uqTGqjy6B8nS71TkjbdLNAAnIa9K6upqlEzi2Fgv
qXdlP3ZbDYUxSFa7EkT7q1wn//o8qcBUIHWNS5LNYpLlVzS2UlzKMQxV0qQWiH+vIfDxxx/LzBwO
h3zPVmMgpjWSgtsu1RggGWtaJUsesaY8Hha+nFbJQHlVZVXIOvvrZRmAUaqwNEpd1kHJ7r4mqpi+
0N/fL910003eNMicjBapu1WUfSrTNlFqFV4GqhPC2a3/P3tvAxTndd59/5VABLJXFlKEVSkukpFd
JIeVLb0ayW4kZVGqkZK3WqaV6r7WqhPaGjRuxoAfVwQeS2mgCV5lEmkZPe6ijooaCY1TeDpe3voF
KwUS8KPAKEvrxfZSCywYC5KADdZu7F15tznvde6PZZePZfkQYtF1mOX+Ouc65/zOx32dc1/nvq10
zRqqfx6njY6Nok2ryy67WQlrLq0WNfYCZV9et1bXCFuukY7NQhFLvJW2QfFYHY2ixqrW7Wq3Kqjb
oYYtrqoXLQ4ZhywzNQ2UCGGmYyk3tyBXWOuVElTSp/8L9DqUMMZcu2hscQgav9MxlTWV4aBLa5eW
UlFd74xom0p4asMyvupuWeCDwqqEtajp9rQp7bu62yd87irFn8VK9aOlXlipH9Hrk6/bofgzUhz1
TtmLDIsqs7xuETWNjaKqQLIgblTdPC5VDj1DFDX1DlGq+NPqJcVvU+IvEI7GelFMdVemTa+nbq1/
kJwaa2TZQJi0vszXXaMcm4urRGO9Xe2XqN/Ry0pnpW6jxyMGW5T2YZT9WhulQ6bJaFX6R73faqT+
Sjq9TrTIvEXUj8kZkM8Qn+pG6letaj2qIc4TOaWuyrzmFojc4hoKHT38YKOs00ZR1dgmGqvV+l2s
JThaXRtXjlT3ZD+RS/2HM6x/n6hrCPGnttBIdVi5L1D9V/v96Ol118uyNIpSe7Vw9hODKPyj1a3p
yZmiDkxUEHyOCcQ5gfLycmGxWGLOxRtvvCEee+wxzT/dH6kv1PXHSCE+UUX9tdQn59vJ+8DNmzfn
NVrMa2zTiCxS4Reiu4aUdlIIfXT7ksq81UkdrKdFuVnWD/pEWynd3Iob1RgC/cJRVS10/d5HHbFU
PvQbsHojGlWI5A2jlDr8/rA7QnSF3yjkjVJ1/aJY3lwcowpNYykpCiZdedX98TacQCwKv8nuVspY
3oRVZdYdUY5S3rC7UVgLVMVDNiD5K3VQuEXiJlT4lXZAHZWmdA5Sq5CdVkjhd0nl20bqlerG1mWl
/ofq56Ag4zVhsrtUz6TkG3WFk/Zluymul8qwdOGdozrIMJY2Cr3ZuKvlgKBAKDq4Fja3plsNOsF/
p40GeWEDE6Ep6mo71fKkp2tc+GGlEzdXU7ujfkBV1NQBgKdFKovaRICrXlTVtIXS2NsolTRdoR4T
x2A9XYOokSMOxfUKe7FVtPT6SOGXEwCj7T7gVicEpGKuDipGr0UOTNX+wVI9ykFVbFWl0iUZhAa6
lBVF+R4/0SCTEz0emnhQBnLEn7pGmWGfNqCyKdprv1LOejrkpAlyHQqXiPoRhYGvWx1gV7n0zo8G
WsRrspulkh7jaD2cKrxaH0yixtlLNS0gel1O4e6XtXiKuqbXf62uBPrVgWRBdYsY9AWEp98tnO7+
UB2QLHWnxBmWxuE2tX5IZFOlVwRcNLCgstKqS1T+UbhOR85UdUDPF2+ZwGIiMDuF3yeq5URPqTph
HMmFBvVygqagPvL0PBzdDYU/Lkx6CAzStv8RPXt/E9c6rpKVthlf20wGy4Yvg244eOPnV/HzWjL3
PZApvQIJa7El/TN8e8cSLFmyBMmpu+lh/BhneiBkL56UfhAnTjyDtfoj7TFexx+uwn26X+8HIMMS
fOnB5SFvq1M3AB+FDnlnpgRuk221YRf+1VGA5vxtuExmF6oFuypQrrbHxiwcP/0aDVx9ZMPvQhVN
r540P40mfb3HTONe4OECtJLhm//YSKtMyvFsxRXcXjc2wZO/JUaaoxv3b9dYJiGVtOX9278UEkDL
AUJOmlCtSdWpJ2Hb02a4rr1Pb3W5jjebqUme3EuLq9V2tunIJfJ9Ax/61OAy7GN/oJrGqWci/0s7
aaN1D1L004aHcYT2VTOOAKTVPG4H9KtjtinYU2iGo/4auq79DC6LDfZcoL7dhWv1J0muGWspxOrM
HVgz8Goojev3FtHZ5ZqNdmQc3g/eo2tmPPyg3rjTkPf949iVpi+OGG33Pi1ZMg+qfb8LAX1dMa0F
yiamSj78H+ED8pOZvpL+qy5ptWQi6QD9N5ph/Cu9LKi6P/RlUFBMlOuo8SjSZDmdwcZkKo9E6vfW
03BNcTJha3GYRoiXrP+OEX8X7GQuZcszhfpAzSOiMQh8qtpb5RhXKv3qkiWpkDRd71B90AWEb29T
Hg89EWqzU4XfmvMKrOZmHN62HslLEpFz9t/xqVw/MmVdiyzHhLX70GLLxZkju5FKC9yXH/geXEOB
cXmVSVXq4KEdoTQmPzBaX6dKL4JqKQW0+k6lRxIn5h+N63TkTF0HwguA95kAE5C96WfUddESwQmd
vM8YNRPuCT0sopNxo/AnpG2nBZmX8K0XD9MT9z+D1PdBqsLXbGacOVyIIpcZ+768Wikaf9dlrN+d
gw2Fjegd9ICmxsh6a9RJhUcq5LKzV9xIBypCdvz6yRi3hjXYKb1+pt/tqXrJGx27OSOQfrAUpKvg
yO69VANoMaQieQRVtNp+ZXmrFk8S2fBn4pulNlKCXXj7g5E5i3/BClqdhSoaDDnyzThGYJaHOjS5
04AbmhYWqueTZERRrCe5ppxOHJVwo4MWOmU+RDaQa/AoXTRXuWiwFaBFUPQbdKOx8SQeDV/EGNKC
x0cg1SXX1Z5R+/zgR7g63tukZzaaqFVfKsO3C08i1/wN/PHT1EMcycHecqDw4GYlXGdlDg7kv4Wa
NjcGPQEMO210fmz7VPOXmCi53SAFXo/Sj9bKCm2djn5uoq0kaMIKqe8pbhg3XPriclX27bD+Qacp
o0ndQLW1qSvEIPjRdaq9YX2TKlD7Hy0e2e/0kz8ryGpHKY+AbxBtjS34xgY1YRnfeJ7sVY/hBz/4
Hk2AFMO8NZTgUCyxMHD0+iBIyw3Qr9/VhrbCPaGF9CFBtCPzZ1x6X/gpZX+y8F5vIg6+4oHP0w9n
Yw0eaSvCtpf+PwIZY13Te3S/F6v3lcAX8KDb1QL7N/qRQ/eDDm19SHiClDrY7A4NWBLUYWa4F0yW
Xt2T3jyi8Y+FayxyaARM0U5W1/QU8ZYJMIFRAgbszKaJqqJitI5RC4I9b+AYTVxlPRo+zTUacrHt
xY3CD6zD7mJSEKhwcs2jb+J5xJRNZUK3SNMBbNamCgMBtWc37dqONBoDtP7zaUVR1Atvw1coDN34
zjWRsiEXZf1gG/KL3kaiPpGne4yyDekESIPZSrPKu1+gBWx96KLX/OXkUyKp/owOAaII4ksxEDBo
s9mqV3nLk4M9UxUpfCd3o7CyAV19A+jroYHb3xjRTMM7k14Z1CCL9n+aNhhSMqiCgapcNOPNa33w
j3Sh4sQxujz6BCpmGFTJZaj8ExW0mNaPgY7LOHGOJm3/r4fo7Fr8IbVHR85ZtPb5kBDow7lnN2Hv
3tcR1CfIp4jooSf2k4AjOE/t0B8cQdP508qTuIxV4xXRiUQlpD2FUqMLDmr+e7anY23mbvIm1eUC
7NqoylAH3zvxxLYMpAS78Y8v5tN1nQW10I9oXfCNTgzQ4Chp09eQS+GLz9RhJBhEX1MFdh/Lx6+n
aMiGTfsoXDNe/IEM50dnbSXN82ouaSOOFMhqehrtA14qj078IJ/Kw/wX2ExJfGTfXygMyus6aOF0
O8q/PXlZRY2HotuwQ/aFRahq6KKnnEG4Xn0JO/fuxn94tLSsfgpF1GTKT16C2f7/UM813kVjYNi0
h/IJnKj8N1osnQBv9xUcMO5EcRtBjMFNFf7dSxuxad1JvOtfia27n8JWelCKZV+gf1PVtchy9Pf+
KzZtWo9zvxhGeuaT2LN1C8mgpzr6SCssrQ89Qdb+zTn4Z1qo7vf24fz3RvlPlV51ZEjt7GonPTWJ
zj8a1+nImaoOhGWNd5kAE9AIZFh+SFMczdi98ihqO3owMjJEutoFbNtIE8gmG0r2T9QbLkJ882Cq
NKMoxtrwSyH92qIuR8jGlk76XIJuQsJSpdkgK7H1C7uyOE+16TbS4loLLdowhxZmBISzSl+sKP2Y
hUNbiKgEp3+qXau+eEs/q5/PDa0PUK8Mi5pizY7caBa50iYst4YsS9lNRmC8DT/xC9mVq3Z1uk26
LqPXIRdmQ9i1RbvStrfRFl6OxN1oobLUbYz1kPG7HWvDr9jJhzhp+dLWqIQWzBKXmgJpH6/Wfwst
mpULUZWFuBRE2o0brfoiJXVBk1VnSrb30i5ZWTQacKuL3zU5Up7F1jJar31k464s8lXjkQvZG8ne
XXGaDb++bkZL6ZhNQLRFtEOjsLfo6wVUu+3Q2oIxIfXDNptsd9q6AVrfUyoXZ9G6At3J9TnmsPTn
Fqv1pcolbcOJRbVWf6i9SudxR/ovqHKG2bmP9gdj+4dhVzVx0zgQPzLLoTVDahxkDC5sYf2RfJmA
jlvG2duoLniWfM2y76D+aOJFu7RmJVo8lFJntdpG9LIvrXHLKEJusEVdaFoftmBJtQsPy9skDKSQ
sXxMBVW0ZHliF1nPVD9Rw3tcoQXPSvqNBaJtUDOQj1bXSHRkOfpEvbbAXOdgaxxdYxWZ2oBosasv
dZB+TbQwUPLXiy5qeqm+0QNm8k9ryuTK7in4j5Wl1y26s01LTvQ6EJk7PmICi4HA7Gz4NQLDbmEL
uy/KdmuhlyXot6z55iTjn+9Fu0tkJiniBeeuX7+Oxx9/HJ988smM0+anL7AGkEyvbEyaWAY9+h0h
+0tDimFC+86JA40960VdyYv41YHvIG+XtBoOoi4vESfSnXjr+NaxnvlYI3Dr1i2sWLEC9JYe0Fto
ZsnFDy8VZDAhGSmTlfUsY7hbwbu6urB9+3aF03TT4Ce2ATJzmLT+T0Og0pYSDTAkjZ++l/FIM+YU
ejXqjNyctMNoMcv6QSQofRMkX/lKMRKSRl9LSW3YO0JPCQ0pMIzPbpSI1HCJKSkTmrhMVB49dfQK
367tsB3fr4QZai1D6u734A5cRMakcUePB0Hq1yj5yZPkN0oGwi5FY6BdS564PoQJmWQ3eviJOOmC
otU15UvIYeUYpHrlpYqZTP37JHcAXSytEyBmgcRJ+o8p0kufuE4Kr1hR+U/OVX5NfrpyJqtroxnj
PSYQ/wRefvllvPPOO7h48WJMmbly5QpeeOEFvP229tr2sFChfmFW/WOYwBnuyvWlpPArHwGboYhp
B5v0ljJtSQswQBLdsKN29PQu1pSoHmLJlAEbHv0NzLvX4c2CYix7qxznmoFql3wezW5+CCSRbjbr
gpyfpM5jLEmyQ5uj+KK1pVnHMyftMFpGo9ePhKSxlBKoPoWWEkcTPOZa9HATcUqj99mfMx/Auau5
KN7wG5SfcZC5jTOKsi+jjB4PEqhfm0nyI3ITLY5o1yKETHIQPfxEnHRB0a6NLceE6dSrqH6nSG+4
si8TGpX/5LIilP1ZyNFZ8ZYJMIHxBKbVL4wPHtdnFrXCP18lk/nNWnRv+ne0/mcfsL0ehT/5KjJW
j1Ui5is1HA8TYALxQiAh7SA8/S68ccVJywm+gEaXDVmZafGSfE4nE2ACTIAJxAkBVvjnpKASkL5j
P/3mRBgLYQJM4B4iYFibiUPfzLyHcsxZZQJMgAkwgfkmEEdv6ZlvNBwfE2ACTIAJMAEmwASYABOI
fwKs8Md/GXIOmAATYAJMgAkwASbABJjApAQWrEnPb3/7W/zud7/D+fPnJ008X4hfAj6fD5/73Ofw
4x//GEuXhr4YFb8ZukMp//Wvf43//u//5nZwh/iyWCbABJgAE1jYBH75y1/iV7/6Vcz3wXfffRfy
TYALWX+U+o/fr30dc57wL1iFX76yaOXKlaipqZknFBzNfBKQSmxqaipee+01RfGfz7jjKS7ZIXA7
iKcS47QyASbABJjAXBIYHBxUlONY9UH5uu+EhIQFrT9K/We+3aJ+D/98w+T4Yicwt+/hjz3eePM5
m/fwx1teOb1MgAkwASbABMYSmMv38I+VfbeO78Z7+NmG/26VNsfLBJgAE2ACTIAJMAEmwATmgQAr
/PMAmaNgAkyACTABJsAEmAATYAJ3iwAr/HeLPMfLBJgAE2ACTIAJMAEmwATmgQAr/PMAmaNgAkyA
CTABJsAEmAATYAJ3iwAr/HeLPMfLBJgAE2ACTIAJMAEmwATmgcCCfS3nuLwHg/DTL+TolUtJ9JsL
J199mJCUhEhpFB+9IjUpKfLsXMTHMiYn4B0agjcQQLIhFSmGMexjrQNBP4YGhxFAIlamrqZ6Mnl8
8XdF1suwdkC19t6ro7IvkO0/XkpPLbMk6mPYMQEmwASYwN0j4B0aIB0DSExeidUp91afHCcz/F5c
OJSI5OTk0V9iIpZsyUNT3yw/XODtwNdJ7o86RiJqoLfjRxTXjxB5NsILH8whgeBQOwq3LMFyejft
unXrsHJ5IrJKasP4x1YH+poqsCQxGakkY926VCQnLsGphp45TOndFdV1+W9G24DSHqgdLNmCsrqu
u5uweYy9s2IfksvbY4qxr6kSp+rmoPxHOlBWcjmsPsYUveLJ2/kKldnX0e6NPQz7ZAJMgAkwgbkj
IHWMkmypY0jdYB1SVyZjy9FT6LyHlLw4UfiB2x7AWOxAd38vuru74XbWowDnsPfgOQzNpk4kAssp
/LhxXqI8M3bWfzYRcdjJCfjxL8/uxJlVpWjrHYTPMwx3ox3N5Yfx/IVRRXbKOuDvQM7efFhs9egf
9sAz3AuH1YyiAxvRMBA+Kz55Shb6lYD3N9QQSuHsVdtBd7cL1aUbcNK8CZd7Zjn4XeiZ19JHTRbG
pfL/VM6PhsJjqP7Vp1N5nPJ68Oa/42T5h0ie0ud4D8mJsoehGaXxl/gME2ACTIAJ3GkCNLGbk7oT
5TcK0OImHcPnQa/LAeOlIhi/WoaBOx3/ApEfNwq/5LVqzZeQvjYN6enpyNi6HyfPFgOu83j/Vz2o
LCxBg6bw+PuaUFJYgS5tRm2gtRJlF2hG0E/+yipQV1eJo1lZoZlfGktEd0q4U7hcewGF2VnIys7D
5fZ7pYpERzM3V33w3iBJpn3YkUYmOIYUZGTlodFqwRfvj4xh0jpAo/Rg//toJu+HzV/D2hQDDClp
OPjCyyg2mfFbjy9SUNweydqaikfS1HaQnp6JZ068DDOdvfmhlkf/AGpPFSIrawuyj1K70KYw/D0N
KCm5AH3s01VXgZKKJqjDBFKOK8pQqzUa/0A7TuVlY8uWLOSVXUboQdokbWgszp6GClQ29YVO99Fx
RYN67O9rwKmKWtRdKEMWyT9KbbVzKNqAzI/2y6eQTW32aAm132vNWBU2Qp8srTLOV1zURRwzorJV
a6/BIdRVEJstW5Al2XSFT+8E0dlQiTzZxrOOoqKuEzJVktvfnqimvfMoDvECepouKH63ZGWjorZD
8atneKijDoVHs6mvKMSPahrptKr069d5ywSYABNgAvNDoPNyKS7BAlf7aezKIB0jyYC0zIO42F8P
o+skvls7B0+B5ycrs4olrhT+yJyOoLX+dTp1CA//Hn2iuKkcRa+/q3i5Tjf68jP5qPtPeTP342c/
PIbaQZpfC9xC/cl8mM2vYNmWR+hajEbASrgiHDmcg4xj30VBFnBk5zpc6ORn9ArwWf8zYPMRE3By
Jz1iK8GFuiZ09gwh6/hFnD6UEUV6WB1IodJM3w4aAsK8PpGU1ErUNXWgz7sR3296DYcyDFHkxPel
vtYrcFAWvvSAnH8eQsWOdThc9CH++qXTyH7oXRwwrlTqatLyL6C8PAc/65NqLCm+J/JRnl+F61Lj
976FovyT+IxM5TDUiq+v24lqZOHsueNYVXsE63ecUmdBYmxDt2ggfuz//JoEq+4jOs6/ph4HPH0U
12GYT/vw0rmX8Ohb+TCmnoSSLD1A2LbzwrPYeaQITz33EswrrqHoEqnPSzUPUdL64CNq3TFaSpF2
n/QvzcJSYc4nNqfP4rlMYrNpJWq1iYKu2r+B8cAxrMo+jpeeexT5ZiP+lgYpCcvXIWPzBgpvRMaj
q5WIe+oKsXFvjuL3LHUI+Ye34VBlh3LN31OL1G1m3Hj0z/DSX25A9UlKMDsmwASYABO4CwS8uPoK
zeZbv4XMpDHRr/0qCkn1aBu4NebCIj0UC9S99957YtmyZVrqPKLKDEFFMO5XUO1S/HTXWOiaTfjo
T/drsjrpmktQeYrqbp8QPqegmVCRW9M9mms6J6/bnMOj52jP57Ip8jzyrBautLFf8+MT1ZQeoyJf
O8WbaRH4+OOPlbL0er1auIBwOuwi12QMK+Nc0dhL5aa4qeuA4s3XK2psxUqZ6vXFVFAtBjUp8bZx
u93i/vvvDyXbZZf1fHw7gKVKyaPHZafrRtEYyrBaV1HcSDKGhd0IYa7uFcLTIoyanOruAB2WUrhi
IWu4y26m/QIhm4wIUPXvdShx2pzUGiZqQ+RtrHPaTBHtI/xYT2OL0rgopK9NScvYNqjKHBRWSqcl
rM06cqnt2WTbniKtsi8wQZjsah/h665W8lHl0tu6KluV5VHY6HIV2dVWYW8kVuQCbsnVThKlI78k
11jaKPEozl0ty4WY0QmZVxht5Et1w21WumYSEh87JsAEmAATmB6B8vJyYbFYYg70xhtviMcee0zz
T/dAC90zS9smCE96BfXlKKif4NqdPSXv4zdv3ryzkYyRHuMUNyXtLjtpv41cOxotm2mm/hN8hvvw
SOZ2pK9Wh2zpTx0mD2dwrecJvOYwo6p6M3Ksb6JrD8jMoxiX0skfzWRKMVl/QE8ExrlIFP3/9Q7p
TY9F+PKFrHCTsDXbDNePXfAe34rFO3cckf07eEBv1RnwYuvBPFTS73/5R9D3bitO0Szp3pyt8DTl
KYynqgNBCjfoXYlDz39f+flHBnCt8Tx2Hz6CF7ZvxcVn1BnfO5iReRAtnyrlwtFiwf30NqPPPgNS
1mdgR8ZaJW79mZOyBEU5o9ZV5PwSI9/Pwp5CM47VX0PXGjdcFhvsy/JR3+7CmrdP0gxIG6SUjxTa
Z7Ax+YwiYfSfanYT2Ya8qNyyHMfIdEZ1NgyL5/WD0JaeG4S527R/CKGHLklr8A06o5oWhXmTu973
0UCb/Q+vDF3YsJWG6KEJGdn6Jk+rjAm36ZUM5AKfqnRy6IlHjnJG+/fO+xT3KnRRHv7qK/LJn+oy
nzmOTG3fF1Ak0ZufaGWP/zrebCZToea9SDypeVA2ZkirqmW0bzy0I9QvJD8wUX8THo73mQATYAJM
4M4QoPskdf1G/anwmEhkz27ccG/00ZFa7hgQC+3QtPUpZO3Sb8FjUrf2SViNZnzn70jBNz2NqgOP
w3RkJ57Lpbk1TZEJhQiE2QurugBufSLVjVHV/cP32+j4sZBdrlRy1miDCymn9xf0iGh/cVgIeZbd
jAiMXKO36uyG3e1DXgYtlE5KQfrWg/j7elqWfeB2qAyk7Gh1oPvVHGzK2YBecRpp5DcpZS12HSpG
lekkTt8MaYgzSuLCCUQ10XgA+3btGr/QXCZSUUxX4b4wDXvgPTL4KTim1FWDyQLklOHbLhdyT3Tj
j1f+GsfINEUanVS5aTCtiOin/1YMiuMw0CtAE+jdNM6rXfjihtH2gVAbMuDP6lx4/CP5ElRamPrA
Q0ih7Q36hbuA/6OwQ9nzOvERNcPVsgcKeiCN8Z7S2mKYR2qSa7CTTnz88WibDdwalRW4HS2t+rqN
MBgky9Hrw8F1FC3tD7rfwgeJDyvL8zfQI49r7w8CW9V8DrRewKUPNuH4MzvUJNEdQ5FEA5RH6Yy5
yoXXvrlJeX0vvN242vkpHiWrKpl3V7Mb/hM7lDJKgDpYUIXwfybABJgAE5g/AgbslBO0OcVofbYJ
u+QNSnPBnjdwjCZvCo6v0k8t6m182fBrM3UTl8hqHHjOjOZLzTBlb0dKymZk00RgM83aPX1AVWQm
DGfYgL8gO5+Tu5+lhbhdGKB3tLbXnsLOIhcNGJ5QlBcZbjn98k/8Ay0E9mOg4zKKzgHfMK6ZUCSf
nCaBlHQarAHHNv05Ljd1om9gAF3ttXj2AM0w566NfDNKlDqwUSqzNNu7nl611drVh4GBHjRdOIkc
atCHnnx4mola2N4n0o1lig2PfIUW8DbjxR/UYYg+JCHramE5YNm+XlmxkpD2FEqNLjioXezZno61
mbspFB3QO692bVQV3Q07sum4CFUNXbQwIgjXqy9h597d+A8aa0zkUtIysWPrVmylX2a6auOeuHQ5
XEUX0THkxVBnLXKoPW1QH8ZpIhyovNQOb9CL1vOnaA2CGXs2h/XEoYjWYXcBUF54mmT5MUILaF8k
Wfqi3ehpJZWexgbNNzoxQON5w6Y99GwEOFH5b7RwOYF09Cu0vmEnitvkACIFX6bHDJcOn0cHPW3y
0yvcvrs7B9UfaoMFCdzVgWt9cl3QWvxhMQ0ccs6itc+HhEAfzj27CXv3vg4Si4eekB1PDv65tQ9+
bx/Of+8YhZE9CDsmwASYABOYbwIZlh+SnUczdq88itqOHoyMDKGr6QK2bSTLEJMNJfvT5jtJdye+
MSY+C+ZwrA2/tJk1aXa7kyXS51ZtdO2aPb7Tptki64a2mv3xOFvhYZcoNYfbjpOdc3HNqN23Fo7W
7AkqJeVnsTZq9ryTpYbPRyMwzoafysBqiSwDU65dhEz4NbvpqepAf1uVsk5DLye5La52hmyto6Vp
IV4bb8NPddpkD9mHT5TmYVdNBAOztT7Cf1tEu+gXpVSvpT36qKP1FNXFobouGZbWuNXLk7Wh0cDq
3mCbIOVak2FU1lToZafa8OvX5NYoqtpCiw7GSiIb/25Bb1eNSI/Zrtrwy0UGk6aVJLmqC9RwuTWK
XI/bEcHGVKCufVAu0voPm7T11NNtGa1/gd56JQ/SFr9N2uKTX3tuWH01hq83CYgWe25IjolsT+l5
ANvwK5D5HxNgAkxgegRmZ8OvxTXsFrYCWl+l9++0tRRXhekY00vTbH3LdMy3Df8SmWiKeMG569ev
4/HHH8cnn3wyb2kL+r3w+siEITkFhvDZSHq/e1byNjzt8iDvEfmuj2S6HlfWUPPGMNaIbt26hRUr
VoAW7YIWpYaCBWlWWppaBGg+ejaM/SSXihLJ9HrO8KIMRRQnO11dXdi+fbvCaXpJDsI7QoaLY+vy
dITQ7LsiwkAMZ1Td1TQk0mtWw8N7Oyux3FgPp6cWm0FmN1J+DOnye0cQSBzTNvVwUdIq6xTZiWH0
w9w6G3p1a3jCNFmy7kgDJUNEJyAvyi/8kqnYqCCawad6RldSKA/jHPUnI4FEuhZL7saF5hNMgAkw
ASZABF5++WW88847uHjxYkw8rly5ghdeeAFvv/32OP+qnke3xhnf18aJnNGJJUuWgBR+5SNgMxIw
g0Azuo3PIJ64CJJA72ad7EvL8qH/rU/l3Z4UjrjITXwmMiFJ/djZbFWkpBiVyPikFEuqacCUMpGJ
TCxhNT8J1B5mJWKSNNCrPckgRhnUyXKK1cnvM0xaL6KkVdapSDdJujRPk9edhIiBi/Q+uV/l4qT9
iRYVb5gAE2ACTGAeCUTT8+YxGXclKlb4Y8GetBk/aWsBHo1dOYlFLPthAvcigeQNf4rGxj3KAtd7
Mf+cZybABJgAE2AC802AFf6YiCchY8eumHyyJybABKITSKBF2llZ6dE98VUmwASYABNgAkxgzgjE
11t65izbLIgJMAEmwASYABNgAkyACdwbBFjhvzfKmXPJBJgAE2ACTIAJMAEmcI8SYIX/Hi14zjYT
YAJMgAkwASbABJjAvUFgwdrwf/jhh/j0008hX13EbvESMEzjLS2Ll8LUOeN2MDUj9sEEmAATYAKL
l8ClS5emlbmFft+k7xHxazlliabQ+wCT6HV63d3d0ypg9hwfBDweDzZv3oz/+q//wn333Rcfib4L
qZT1/+tf/zroQ3R3IXaOkgkwASbABJjA3SVw9uxZ5R5YUVERU0J+/vOf47vf/S6amppi8n83PH3p
S1/C8uXz+wX2BTvD//nPfx6f+9zn5nX0czcK/V6NU//Y1tq1ayM+vHWv8pgs3/LDZNwOJqPD55kA
E2ACTGCxE3jggQewbNmymPXBL37xi0hMTIzZ/93iJ+/t8+nmN7b5zBnHxQSYABNgAkyACTABJsAE
mABY4edKwASYABNgAkyACTABJsAEFjEBVvgXceFy1pgAE2ACTIAJMAEmwASYACv8XAeYABNgAkyA
CTABJsAEmMAiJrBgF+2OYx4Mwk+/kEtIQBL95sIF/X6MSk5AQhL95kIwy5g2Ae/QELyBAJINqUgx
jCmFWOtA0I+hwWEEkIiVqaupnkw7GQs4ALUD/2htBdXUpLjIoGy/ss0uDLRBqiPU0OOonS8sfguj
FDkVTIAJMIHpEfAODZCOASQmr8TqlKTpBY5z33Eyw+/FhUOJSE5OHv3RCuwlW/LQ1Ec37tk4fwcO
hctNTkQivfu/sLIJ3tnI5bDTIhAcakfhliVYnpqqrKxfuTwRWSW1GAlJia0O9DVVYEliMlLXrSM5
qUhOXIJTDT0hKfG+03X5b0bbgFJvqR0s2YKyuq4FnbXOin1ILm9fIGn04hWqI+Xto7Vr8oSNoI5e
Bdc5685gdnIWFr/JafEVJsAEmMBCJCB1jJJsqWNI3WAdUlcmY8vRU+iM5TawEDM0gzTFicIP3PYA
xmIHuvt7lXfzu531KMA57D14DkMzyHh4EA+MqHF1o5feed7tdqHeXoAzx/biaGVHuDfev2ME/PiX
Z3fizKpStPUOwucZhrvRjubyw3j+wqgiO2UdoMFbzt58WGz16B/2wDPcC4fVjKIDG9EwED4rfscy
cscFB7y/oYZQCmev2g66u12oLt2Ak+ZNuNwzy8HvHUx9Isk2LpX/F4JLxFIjEFNygjdwIv88Asmz
TPcs5SwsfrNkwcGZABNgAvNJwEu6QepOlN8oQIubdAyfB70uB4yXimD8ahkG5jMtdzGuuFH4JaNV
a76E9LVpSE9PR8bW/Th5thhwncf7v+pBZWEJGjSFx9/XhJLCCnRps3IDrZUou0Czi37yV1aBurpK
HM3KCpv5XYWHH0lHGslNz8jE/rzTcFfnwnGsFJ1Sh1LCVaK9owGFFC4r+ygq6jrDzIDuYgkuiqh9
8N6gjJj2YUcameAYUpCRlYdGqwVfvD8yg5PWARqlB/vfRzN5P2z+GtamGGBIScPBF15GscmM33p8
kYLi9ohGvkjFI2lqO0hPz8QzJ16Gmc7e/FDLo38AtacKkZW1BdlHqV1oUxj+ngaUlFyAPvbpqqtA
SUUT1GGCHw0VZajVGo1/oB2n8rKxZUsW8souI/QgbdI2NBaoH+2XTyGb2svREmpz15qxKuzpqben
FWUkP0uT36O11dYLZTgVeloxgMtlJbjcrg3pvZ04VVIJ2cz7Gipx6kIdLpQdxZasbBSeqg3la2xK
lGNvFy6U5CnxlV34V3S5In31NF1AXnaWIquitkNr28TkR6fhor8Xcwqpf1ETOSkbKdLfh9qKEiXf
2UfL0NQlp49mIIfCROMXmXo+YgJMgAkwgckIdF4uxSVY4Go/jV0ZpGMkGZCWeRAX++thdJ3Ed2sX
jxXAZAzk+bhS+CMzMoLW+tfp1CE8/HupQFM5il5/V/FyvaEC5WfyUfef6s32Zz88htpBmiML3EL9
yXyYza9g2ZZHyO+oQTGZjUe49VufpGMHzRTTzLAS7hh2bjuA3/vrAvz1Ni/yzUa8toBnVCMys+AP
DNh8xASc3EmP2Epwoa4JnT1DyDp+EacPZURJfVgdSKHSTN8OGgLCvD6RlNRK1DV1oM+7Ed9veg2H
MgxR5MT3pb7WK1RTgS89IKehh1CxYx0OF32Iv37pNLIfehcHjCtxgWxSkpZ/AeXlOfhZn3zaMYS6
E/koz6/Cdanxe99CUf5JfEamchhqxdfX7UQ1snD23HGsqj2C9TtOqbMgUdoQSQm5zgvPYueRIjz1
3Eswr7iGokvA8qXq5WBfHZZv3I1aHMBLZwuwjORvXF4Cmay197+HIvOP1ad2fVdx5GQ5jrz6CyXg
wP/5JxSV9yGZBg6evnoU5ZjxY99eWJ97Ck1Fh/Hcpa5Q/JE7xOQrm5BTvgwFp4/D9+MjOEMe9PFH
T10hNu7Nwars4zhbkIX8w9twSHm6l4T1xkzyaYTpK9uRSuZ+UdmQAdqFP1+Pw/kfwPLSS8j+Yi32
bvoq2kemKweIxi8yb3zEBJgAE2ACkxPw4uorNJtv/RYy9U5f97z2qygk1aNt4JZ+ZnFvxQJ17733
nqAvq2mp84gqMwSVxLhfQbVL8dNdY6FrNuGjP92vyeqkay5B5Smqu31C+JyCZkJFbk33aK7pnAkm
0eYZPaXs+VyKX2vbcChcQX2/5mlQlJIc5dqYYHwYG4GPP/5YKUv6kqwWICCcDrvINRnDyjhXNPZS
uSlu6jqgePP1ihpbsVLmen0xFVSLQU1KvG3cbregrxKHku2yy3o+vh3AUqXk0eOy03WjaAxl2Ceq
ZdspbiQZw8JuhDBX9wrhaRFk1aLIqu4O0GEp7RcLWcNddjPtFwjZZESAqn+vQ/Fnc1IjmagNkbdI
NyisJNsS1s4cuRBGm2yPQjhtJpJnpdRoztOmpMXmpDOD9Upc9bTb7yhQ9vV0OSyjMlx2kmGuotau
OkVmrkMmd5zzuatIjlG06BEqbR5CiU94hN1EcksbQ2Hd1ZIx5V8KC8j+wyScmuCobLS01/TqqegV
9mKraJF1eDpyqCSj8RuXQT7BBJgAE1jEBMrLy4XFYok5h2+88YZ47LHHNP90D6R7B0rbJghPegX1
/yion+DanT0l7+M3b968s5GMkT46xU2xL2Qn7beRa0ejZTPNuH+Cz3AfHsncjvTV6pAt/anD5OEM
rvU8gdccZlRVb0aO9U107QGZeRTjUjr5o5lMKSbrD+iJwBTO3+tUZk2PPaTODMtwG9bps8RJSCVt
6RZN+LGbCwL0Vp0BL7YezEMl/f6XfwR977bi1DYz9uZshacpD5L8VHUgSOEGvStx6PnvKz//yACu
NZ7H7sNH8ML2rbj4TMZcJPYuy5BmJWRu1mLB/fRY6rPPgJT1GdiRsVZJl2YZg8TQTEYStmbTMDfn
lxj5fhb2FJpxrP4auta44bLYYF+Wj/p2F9a8fZJmQNogpXyk0D6DjclyHjzcqesgItuQF5VbluOY
S/dnw7BnBxrocP/DK/WT2LCVht3aJIpsNkbrHtBDGdUZHsYR2qPmCazeARttWto78dnrZ1BQVY0P
c6z4ZZcZr9NTgsL/Se2fXOA2ycgyhmbpE+XTg7ZeZaF9SK7ik/xKz2SWE1CTT1P7jyCb2q8Sn/86
3mymq817kXhSC6BszJAWUumJ6qO/gLSWUpq//DcxG+8H79E1Mx5+UO9W05D3/eOKNPhjlwPv+1H5
qQL5PxNgAkyACUxNgO6TdGM0ak+Yx/qXdwfjhql1wrHh4vFYvzPFRdpNW59C1q7MidO69klYjWZ8
5+9IwTc9jaoDj8N0ZCeeyyXTcE2RCQUM3flDZyAtGcLdtbof02EBHkklRLqiEBZOVhJ2c0Rg5Bq9
VWc37G4f8jLoVYlJKUjfehB/X0/Lsg/cDuGXsUWrA92v5mBTzgb0itNII79JKWux61Axqkwncfqm
pm3OUZLvnhhSt40HsG/XrpCyG5EWRbldhfvC6vPAew6qyscUfdVgspDyX4Zvu1zIPdGNP175axwj
cxbSpVHl1pXpfjqyYlAch4FeAZpApirOq1344gZF41WjC7UFA/6szoXHP5IvQaVXnT3wEL1O9VPs
pP2PP9YbjrSK+0gNR/+l6uu62kPlukM1qgt+hKt07inFRwpMdguMRSfIttKI039/AMOWIzA/TQ2Z
Bu4lVD9CTtHYQ0e0szTMSC/8vGytJqwIJX8YN2iAskF6SVqDR2ljrnLhtW9uolee0oG3G1c7P8Wj
0kJKy4LePwRuT84m8aa8o9ygAQZtlGT60Vp5DoH9uch6kM6Ri0UODGui8lMl8X8mwASYABOYmoAB
O2nSy5VTjNZnm7ArbEYo2PMGjtGET8HxVVOLWQQ+4suG/7Y6SzYx99U48JwZzZeaYcrejpSUzcim
ScVmurE/fUBVZCYOJ882kwLSgY4O+rU3KQsBdxc1I7cmD+lySBQt2smF8pVYCaSk02ANOLbpz3G5
qRN9AwPoaq/Fswdohjl3LaTeFXJR6sBGqczS7Ot6etVWa1cfBgZ60HThJHKoQR968uGQiMWwM1mV
NDzyFZpjbsaLP6jDEGmvAx2XUVgOWLavV5ThhLSnUGp0wUHtYs/2dKzN3E046IAGt7s2qhrxhh3Z
dFyEqoYuWhgRhOvVl7Bz7278h2dicilpmdixdSu20i8zfTV5WofdBUB54Wl0DPkxQouFXyxyhRbt
PvTEfloecwTnm3ro3fwjaDp/WnmalrFKjX/T1+iJBL1BwUXrczJXp+CJvVSuNEAxlh5QBnITp0Ke
jRwc6v4Mm/bRMxGVyQi9f7+ztlKx4Vevr8UfFlNycs6itc+HhEAfzj27CXv3vg76bIB8PED/mvHm
1U6M0GAgGpukTV+jeFwoPlOHEfpmhHxF7O5j+fi1HDRMQ85U/NR0838mwASYABOIhUCG5Yc0XdSM
3SuPorajByMjQ+hquoBtG8kyxGRDyX45RXgPuDEmPgvmcKwNv7SzNWk2wJMl0ueuFlRkwi5tgck5
bZotsm5Sq9kfq7a7mhQ6R+qEEk6GVX5Gs7A5XCGbXhFwC5pf1Gx+ZTiy+yVbaKsWjyaJN9MgMM6G
f9glrJZw+30q71y7CJnwa7bWU9WB/rYqZe1FqCyp3IqrnaNlOY00LgSv4234qU6b7ERjcjfsqolg
YLbWR/hvi2gX/aKU6rK0YR91tJ6iujiiTZTWuNXLE7Wh0YCje75uQW9EjZBhtqs2/HJhQFuVbp8v
/RiFvUVfHyNFUJqo3IylLYq8se1annTROgCjskZH8aKuO7DUhGz61bOj/4dd1WHrOiis0p41irTu
w54bVveM4WtH+oVNy4e6ZicKG4rO43ZEsC+o0uve9OSIqPxG88V7TIAJMIHFTmB2NvwanWG3sBXI
9WOj9yVLcVWYjjG/FGU65tuGf4nMIkW84Nz169fx+OOP45NPPllwaeMEzZ7ArVu3sGLFCtCiXdCi
1JBA/avHAZqPNszis6x+kuujmdVkej1nmBFIKJ542enq6sL27dsVTtNLcxDeETJcTE4hjtMLGfId
9EIRYSCGcrZ7Bs7vHUEgcZI0+Ek+2cYbqIxmKH6aKVKZJKakTFgnlDpDElMov2Od/LpxxBeNo7LR
2NPrZcd+LHp6cmidQTR+YxPJx0yACTCBRUjg5ZdfxjvvvIOLFy/GlLsrV67ghRdewNtvvz3Of5Du
O1667yTP4r42TugMTiyhD7ySwq98BGwGwWcUZH7uszNKGge6FwkkJJENP2V8pjqqzixJNmb94J7c
0oCJFNtZuQQDmcbNSoLyTYVJy4HehTy/XzaPziRanYlQ9iWSqGwmj2d6cqgd0KBhUn6zKxoOzQSY
ABO45wgkzPt9Z+Egji8b/oXDjVPCBJgAE2ACTIAJMAEmwATiggAr/HFRTJxIJsAEmAATYAJMgAkw
ASYwMwKs8M+MG4diAkyACTABJsAEmAATYAJxQYAV/rgoJk4kE2ACTIAJMAEmwASYABOYGQFW+GfG
jUMxASbABJgAE2ACTIAJMIG4ILBg39Lz0Ucfwefz0Zcpwz4ZGhdIOZGxEPjd734H+VqqBx54AJ/7
HI87J2MmOck353I7mIwQn2cCTIAJMIHFTEDeB6V79dVXY8pmPNw3pf7j8Xj4tZyyRKUiuHTpUsj3
kLNbfARkRTcajcp7cu+7777Fl8E5ylF3dzcOHjyId999d44kshgmwASYABNgAvFD4JVXXgF9jBVn
zpyJKdEtLS0oKyvDT3/605j83w1P69evx3zrPgt2hj8hIUGZ+U1LS7sbZcFx3mEC8sNb0v3+7/9+
xIe37nC0cSdePuWST0C4HcRd0XGCmQATYAJMYA4IpNAHYeQHOmO9Dz744IP4whe+ELP/OUjijER8
/vOfn1G4mQZiW4qZkuNwTIAJMAEmwASYABNgAkwgDgiwwh8HhcRJZAJMgAkwASbABJgAE2ACMyXA
Cv9MyXE4JsAEmAATYAJMgAkwASYQBwRY4Y+DQuIkMgEmwASYABNgAkyACTCBmRJghX+m5DgcE2AC
TIAJMAEmwASYABOIAwIL9i0949gFg/DTL+ToLT5J9JtL5x0agjcQQLIhFSmGuZWtpDPohx9JlO7x
qQ76g0iY6MJ4r4v6TNQyiLUOEOehwWEEkIiVqasn5B3PEP1+/wTJp/awwOsP1/EJii3KKVnOCUlJ
mKC7iBJqqkuyH5V951T++DoTYAJMYPER8A4NkJ4HJCavxOqUpMWXwSg5ipMZfi8uHEpEcnLy6I8+
yLVkSx6a+iZSfqLkeIJLwaF2FG5ZguWpqcpHEFYuT0RWSS1GJvA741PBHhQmUvoTyzAwRoi/s4Iq
34/mNr4xcSz0w6nLILY60NdUgSXEOXXdOirLVOK9BKcaehZ69mNOX9flvNE2EN4ekreh1TuVmBHU
VVSgc0p/U8mZ/nWu49Nk5u3A16l8f9Qxp70QOiu2Ibm8fZqJYe9MgAkwgfgmIHWMkmyp50ndYB1S
VyZjy9FT6JzbLnZBQ4oThR+47QGMxQ509/dCfozI7axHAc5h78FzGJoVYj/+5dmdOLOqFG29g/B5
huFutKO5/DCevzB3H/0acb4O9ZMRJ/H/jrmJ00MFcnM9kzcrKPMcOLYymLIO+DuQszcfFls9+oc9
8Az3wmE1o+jARjQMhD0dmufczWV0Ae9vqCGUwtmrtgPZFtRfHR43TBFT8E/j++QAAEAASURBVAZO
5J9HIHkKf3fgMtfxaUKlD4wvpyBzPf8UwCoYl/LXy6dZGuydCTCBeCZAEyg5qTtRfqMALW7S83we
9LocMF4qgvGr4ydh4zmr0dIeNwq/zMSqNV9C+to0pKenI2Prfpw8Wwy4zuP9X/WgsrAEDT3qbL+/
rwklhRXo0mYyB1orUXZBndXqa7iAisuXUZaXjezCCxgI+uC9QcJN+7Ajjcw/DCnIyMpDo9WCL96v
ovP3NaCsoonMcfRjKb8SWnToayL5FSS35Ci2ZGVTXE2InET1o/FsPoxWB2ooycdONyJC/Qy///op
L2UVaGqtQ2F2FrKyC1HX2YeuhgpkbcnC0cJTaB/QU6IlKO43U5eBnsVJ6wCN0oP976OZPB42fw1r
UwwwpKTh4Asvo9hkxm89Pl1EnG9p5LvqIWymD9LJdjD6S4PU9wdaL6BQ1pEhtYaNdFI9ouOOET8a
fnQaLvp7MaeQ2opaQ/0D7ThFbWEL1a28sssIPTDT6mFdXSWOZmUpT0mUdnCqFk21p5S6mJ1XhiZN
joQaHOmkupuHLPKflZ2HirrO0XoeXsfHloAS1ylcrqW0K3U+D5fbw5+DBdHZQOmga1uyjuJUbYfa
FmW4GNs9gkP0dKOQ0r0FWUepr+gandYZ3yeMTSAw0tmAEuKURe278NTlUNvHmDSAUtZQcQpNWhuN
1jdInqcqalF3oUxr2/T0RSs3mQIqacUFB1pRFlam8mRPXQXKLneqHsb8j1oOY/wOdNRp+aK+Jbw8
Jyh/Ja/3XN80BhgfMgEmEHcEOi+X4hIscLWfxq4M0vOSDEjLPIiL/fUwuk7iu7WLxwogauGIBero
M8pi2bJlWuo8wm6CMNmcYakdFo5iowBKxaCg60YIo3bdZTfTeQhryzD594lqM12zqmFddpNyzZRb
IHKLayhkQLRY1XNGS7GocjQKV/dgWDxCeJxWCmMVUpp0HqeNjo2izaMe6/GZrTWirbFKGCluk61N
vSj/D7co5+wun/C51LCNYVF4lHM2Sgs5j1OYKbxMv63GIWy5atpgLBDVjiphkdcK6qXPuHYff/yx
kkev10v5mLoMCMwUdUDi6BU0nlLk5pbahaPRKXqHA3HNye12C/rCYCgPal3LFY0ul3A6naM/Vy9R
JBfQGJirhcfnFrlKfXFQKxDCXS/rsVGU2quFs5/ODLYIE1035tpES1u9KKY2RKNS0S/lhOqhUeQW
5Aprfa/wuOwKW1kXa+prRDG1Sdn+FP/EvkDGZSoW9S0tosaWq/itcsuYSVx4HVfOhP0LxQVhr28R
Dj2sS21g7iqLIqu4ql401sg8UPuyyvYVa7v3iCrqAwCLqG6ktFnV/qGmW03b+D4hLG1yl9InOeXa
64WzpUZtg8RX4a1dszpDvYOwkd/SNvU4Wt8wyrNYNLY1ilKFZ7HolYJ9apw2Ra5apia7S0uYytpS
060dh2+il4PTZgr1hT53lcLSQv1WS0u9oDkOOqb4pbhQmYyW/+i5xd03hdPkfSbABO4+gfLycmGx
WGJOyBtvvCEee+wxzb92n1DuGWNF+EQV9bu67jj26p08lvexmzdv3skoxsnGuDML5MRYhV+9Ycsb
UuSvoFq9CXbXSKXARooNFaByc5dKgVTyXcrNujp0c6ebvVFTrkN5DQinwy5yTXIAocsnpap3YmVF
vVGbhFPVR4SiMJirFKVKihxsLCY5uaJb0zXd1TJt2o1UU4zMoZv3GGWIbvRS4S9uVNWogHZTrlcP
hVsOZij9unoRykKc7UQq/DLx0ctAKnd6uY6WkVpWeh1QEPh6SdksVspc92cqqKZBYXy68Qq/qvzq
eQttw+pEoNehDDCVa8ZSVYGT2Q/ItkD1VquXqjJaIJSmQed8FE6GscmKrdXD3DClUq33RqGMo0mc
TxkAmNSBb6BfOKqqhabfCx8NJmQ9VhXWMXV8bFFocZVqdZ4khw3S+5VBnKV6VLkdbCyldJqV9hdL
u/d1Vyv5qnLprWZQWClteievcBjXJ4wmMtCvcimobhGDvoDw9LuF092vKvwRirkM4xE2GjjpA4Bo
fUOIp9aPCF+bUm4KszFy3VVykCInN0a56/3PaEppb4pyCFf4B131oqqmTc0HBe1tlIMprTwnKH+9
Tiz2vimCJx8wASZw1wnMTuGn+4mczCgNm4QN5Yj0CjnRchcmUeW9dr4V/rgx6ZH228i1o7GlBY2N
9ahvbEH3oA+nn8mkC0D6U4fp/2u41nMNrznMqKouRnP1m+hqbyYzj2J8NV2zhpWCDj2hmD8oAekR
/NDACLYezENl01sI+IbR7XQgV64PyPnnMNMc/6h5ghow9D9wm+ZNs4whe1vD6jS6dh0fKlYkA6iz
XqLjcqxfsgRLlqxXbPkdx/4JPRF2PSFxyqP8NStUg2yfFA4TUjX77IBydekcv7ljNO67sxdbGUxV
B4L+EQx4V+LQ899HkxDwDfejpaYUzWeO4IXLc7ce4+4w0mPtp8pmA6mucrA++nvreaRoXhLSDuIs
TddLV3r2W5C1UXFBZbEI1XH9hKxUZ7AxmeolLW5OXk8quuLUiimb3GN/kKqd0zercJ/2hhdVGr3t
QF5KWIst6Z/h2ztkHSdZqbvh0IPEuPWpksh3ErZmm+FqcMHr/wgf0JnM9JUhKUmrZZpk6mJr94FP
VfOlHONKJW1LlqSiiMK63nlfNQ0a1ycookP/EtbuQ4stF2eO7EZqciKWH/geXEOBmNpg9L5Btu1D
yNDaNpLW4Bt0ZiKDvYxvPE9XTuLnfV689dox6gsLYNTDhVJKO9Moh9WZO7Bm4FUkKv3SEqzfK6ks
D5XCROUvz91bfVM4XN5nAkwg/ggE8BndAoxLJ0657IWNG8be5yb2G+9n40bhl6BNW59C1q5dZEe7
H/uzdiF9ddiStrVPwmpsxnf+7jtwmA7AfMAMkysfz+Xmw0QLN9dqJSWVFOPS+7Qj2oxcoze6pKKy
S73NJiSlIH3rQfx9PRkoNN/WlHxZUxpwQ7sTjzVHlseuX38ckhlQlPTlWEYX/F1XUOSiZw+NTrhd
ZEHtcsNJi4KlovW/fxFtufEko4FQLItoJ6YyUPMbrQ50v5qDdakn0aehSUpZi12HikEjeLhu3lpE
wJYi6rrboSZ8p5wqHbmT3zob4qEDoBdcKS5wu5+2VtCsMS1iCtBAYBBtNJD+xoYwTTIQWz30d13G
+t052FDYiN5BD4TPTRaTsTtFkQxrz72/oAVV+zfRwFxN7O3PRtOhJZ9eu0ouxnYvvTp6fRA02gnQ
r9/VhrbCPcogfVyfID2HO78Xq/eVwBfwoNvVAvs3+pFDee2Q4wht1LM0URsFBXvRROj1nkmmdbK+
AZD9ihMf6VkLevCujFeTKXdDbvVTINNEvFL5Dzh7kvqTvF0TDjimUw6dlTk4kP8WatrcGPQEMOwk
YyRtIBWKd8Ly1xMc8sU7TIAJMIEFSsCAnXICqagYrSORSQz2vIFjzUDWo6siLyzSo7hS+HF7ojuh
XjKrceA5M5ovNcOUvR0pKZuRTYpeM918nz6wWfc0fpuSTgMFWki76c9xuakTfQMD9FSgFs8eoHfq
5K5VFKvERHljbsab1/rgH+lCxQmaYVPeoaGJW7qcJvD/HrWdQ8r1My/mU9i/xCa661/9cY4yI3s0
aysyMjORmZmBrVnPgNYkoOiHr4c9QdBkRcui5mXRbWIog1Ceo9SBjSapYp7BenrVVmtXHwYGetB0
4SRyqEEfevLhkIj43qG65urC1Y4OdLR3oL29nX7qtmdEKmJDqHh6L5rNVRj2uGChBUkHy1rVLCuv
yqF6fLUTtIYXG3Zk0/kiVDV00cxwEK5XX8LOvbvxH1L7jsnJuRFVPw0E1Fl0067toLXvaP3n07RI
KnZHuUL+iX+ghfZ+DHRcRtE54BvGNaQ5b8QRGnuf3H2aFqt7qX114gf51P7Mf4HNyrhk6nZv2LSH
ntgBJyr/jRbpJ8DbfQUHjDtR3PZRTAn09/4rNm1aj3O/GEZ65pPYs3ULhaOZcKnNG1ZhJ21eea0Z
Q/SEqf3S2cgnG1H6BjVyByovtcMb9KL1/CkKa8aezfSsZlw/kIQ/+h9WentYEXEthnkr+ZnATacc
Asojs514YlsGUoLd+EfZb4X3a2Plj0vTWA98zASYABNYeAQyLD+kXrMZu1ceRW1HD0ZGhtDVdAHb
NpJliMmGkv2h5+ALL/FzmaKQKdMC2xlrwz9+0e74BPvcqq2uXVtA57RJu1eyUdZslmUIV9iitZCE
YRctWAu33yf7/1y70Ez4yZtH1BRoi2fJ7spCixjlAkBag6s41RY6LLypVCjrDX0uZYFfuB20Hmd/
vbTzNwq5eFdZ0KjbEAfUhZajts9yoaRqryzDKnGZ7JSi+HbjbPhjKINY6kB/W5ViO05thLipv+Jq
Z8hOOd6oxWzDT3m10kLR7hpZN01Ur9RKP9iiLnKtVozr+4VNW98i/SrrJqplPRxlVVrjVhFpNtx6
PZQnVZvz0bqo2sbTsdIO+oVdWfSpyjJaCoSFbNnN2kL6iDquxjD6X4sLctGwlhaLtTG0Jkb4uoUt
TLZcGBxaI0tSYmn3Hrcjol6YCqpC6zom7BNGUydjEPXWyLUTtkZlaaviS7V919Jusggay4fWLkza
N1BIledonmV/UNWmrTbR+gG7tnBZiUg7F/nyAuVK2L/o5RCeV193JJPc4gKFf5WMc4LyF/dI3xQG
k3eZABNYAARmZ8OvZWDYLWxhepy811iKq8L0vPnNqIx/vm34l8gsUsQLzl2/fh2PP/44Pvnkk3lL
W5C+bCnnSKV1rmGCT1H6vV66lgiDgabuw1xHRRZehA1Nz2+C1xscdz3MK+9qBG7duoUVK1YQLy/o
LTQhLlOVQcjjFDuyrHxUmMn0es7I0poi4AK73NXVhe3btyuc5ippfvqqc8RXeWl2eYQm6JMNxEqz
TJlpXH7vCLWR5Om1AX8HsujDYU+7PMh7BPTUi8JPkJDJ2l/saQ3Cq2Z0QvlTyQmSaY+X1j9MWKfo
684j9PlGA9W3cITR+gZvZyWWG+vh9NRiM0iw5B8tEQNN2LJuL070BnAoLTyW8YFiLwc/MaFebQ7K
fnwq+AwTYAJMYPYEXn75Zbzzzju4ePFiTMKuXLmCF154AW+//fY4/6F+/C73eXKtGyn8ykfAxiXy
Dp2Ifte4Q5EuVLH6Z+wnu+kmTXZD9tPC4NufUrZooGBgpLMp36nKIFbZk5ZVrAIWsb8IZV/mM8FA
JnBzk2H5HYvJ2k+0GKRxza1PaYRGa2jCVhBEBJl9mVL7nEVGE+jdzZN+iT0hiRhOkPNofUPgFuXP
oUwwyLxN7vyozduBw+fIPtFSjf97CmVfyom9HJKIyQTpnjwxfIUJMAEmELcEovbjcZur2BLO2mls
nKL62vCntAAw8GhUP3yRCTCBSQgkbcZP2lqAR6MpvZOEXeCno/UNyRv+lN44tgePRl2BLTOYhO1/
WYaqPV/Avj/ZP6MB1QLHxMljAkyACTCBO0yAFf45AJySvgM75kAOi2AC9yaBJGTs2LUosx6tb0ig
xepZWekx5Tttx0F8kzuZmFixJybABJgAExhPIL7e0jM+/XyGCTABJsAEmAATYAJMgAkwgSgEWOGP
AocvMQEmwASYABNgAkyACTCBeCewYE165Nt55Ftcjh07Fu+MOf0TEAjQO+EffPBBFBQUICFhwVbD
CVI+v6fkW4weeOABbgfzi51jYwJMgAkwgQVCgF7TrrypLlZ9cHBwEJ999tmCvm9K/cdPb4acT7eg
NS2pFK5eTV/xYbcoCTz77LOLMl9zmSlZ/x9+eLF8NGwuybAsJsAEmAATuBcITFcPlP4fe+yxBY1G
Dkjm2/F7+OebOMfHBJgAE2ACTIAJMAEmcM8SuBvv4Wcb/nu2unHGmQATYAJMgAkwASbABO4FAqzw
3wulzHlkAkyACTABJsAEmAATuGcJxKnCH8TI0AAGBobgpY9zLlQXDPppUcYCTuBCBcfpYgJMgAkw
ASbABJgAE5gzAnGn8Hc1VCBrSSJWpq7DunWpWJ64BafquuYMiCLI24XKijqMzErqAH60LRnJyYfQ
7p2VIA7MBJgAE2ACTIAJMAEmwARmTCCuFP6eukJsOpCPZsquKbcYpQVm2nOhyLwJdQNzNJM+UIcl
yzfh2DtAyoyxUsCRD3DVJROahUcNsxHEYZkAE2ACTIAJMAEmwASYwMwJLOjXckZka6gJz5rPKKes
jb04npWm7O/7vSzsLGrG6z/rxsFnMoDgEBou2VH9mhNeGLAtOxff+uaukPLe1VCJH1+7jd1/uB7X
flID52+WIft/lOCbu9LgH2hFaZEaB86dweW8J/HMVgNaK3+An91Oxx8++hl+cuo1pB//IY7vT0dP
62WcPVePG/Su9Ac3H8C3Cv8KmatVpN4b/wkHpdBkekKNOziCpkv/iKrXrirp2vyUGXnPH0JaUkQu
+YAJMAEmwASYABNgAkyACcwtAbFAHX1oQSxbtiyUusEWq6CcC+TWiEDorNwJCJ9PP9MrrEbyI/0Z
TcIkt/JXUK+FGRZ2k3aOzpvNJvU6ikUvSep1FGjHqh9b2zCd7RbFuhxlaxSO3oBw2i0hvyaTUdu3
CJdHpkkId5V6vbheSg4IR4Eq01xQKujBhOrfUqP45X9MgAkwASbABJgAE2AC9wYBqZvevHlzXjMb
NyY9H/zHVeIDFPzRE4h8LJGApCT1TF/dGRRJMxqzHYNvNaEp0I1iIx2fscMp7ej9N/FmM21hRI3b
h9deewUW9VD+R9rBk7DRKIEEoM0j8PwOMuoZ6kObPEXO1tgNX8CJg8takHPsEp0xob43gKamt9Bi
leZFl9D8rrT89+PtX8jrwNZHHqT/XvS+pRxi8/Z9KLC50dbmQq91r3qS/zMBJsAEmAATYAJMgAkw
gTtEIG4U/sSlqiH87z20MgzFCNqbWtHR1UcqNvDRr24o12zFfwbl+7wJyVgR5tvf30kqObncE8jO
SEKw7z1aAUDO+GVItRzeG2iSAwLjU3hYs7sfef+XypoBekqA57PSkZSQAO8HbyvhTKXfxf40dbCx
4gEtQKIU1I+Oc3Kbiz9YJ212UmD66wJ5AuVHdmL9+k0o/icawKTOapWAIo//MQEmwASYABNgAkyA
CTCBaATiRuHXM1HtaIW+PLerthQ79+7Gtk1n8BvyoOja0mNisuq975eoVjT6zVhD+vhv3nlbOZ+7
58vKU4KRnrcUxd38lUxItdzb61Ls7o2HnlQHDHTuRrv6ZKH0j7epMsP/L/2CdjSE+p+oM/pLE2kA
oD8VMD+J9STYOzKAZVu/hd7+XrTU2GChpw7N547hJ87ZvQcoPCm8zwSYABNgAkyACTABJsAEJiIQ
Nwp/5p8cIUMceidPuRnbjhaiMC8Lmw6rC2xtbSeRRteWGZR5euS/mI9TFWXIXm9WFPqCmr+i60H0
tKnGOVsz1yks3v+lU9lmPf4lZYvAbXX73s/Q0DlE+164muTSWyO2Z4zOxhse+rKSluaiXBRWVKLs
6NdA64bJEqgKz2QaoD8VMGVtomXDpNx/ex02btqInLPN+MLDX8ajG+gkudQHtIGJesj/mQATYAJM
gAkwASbABJjA3BOY1xUD04hs7KJdGXTQWS3IUl4QBfVntIjqtv4wqR7hKB1dTCv9lVY7tQW7HmFX
FstahFNZWKsfm0WLXJtLztftEDSoUGSbbC5aa+sWZIhDx8WiW18XrHoVvY22kF8Zj6mgStBaXsW5
tAW91pZB9YTHJawWfWGvKr/A3ih8mizeMAEmwASYABNgAkyACdwbBKTeON+LdpdItBTxgnPXr1/H
448/jk8++WRM2oJkIuNFkOzzUwzSEGe8C/q98PqCSDakkM39+OtRzwS9IPEwpBjGLA6eKNTUaQkP
5afXd/qCQSRQugzTTVe4IN5nAkyACTABJsAEmAATiEsCS5YsASn89AFZ1eJkPjIRh2pnAinjo+Y1
E0FKSDIgZeKxwETeI88lUNjo4sP8T52WMM9IMhiUtQLh53ifCTABJsAEmAATYAJMgAncSQJxY8N/
JyGwbCbABJgAE2ACTIAJMAEmsFgJLNgZfmnKk5ycjLKyssXKnvPFBJgAE2ACTIAJMAEmcI8ReOCB
B+D3yxfKz59bsAq/tG9KSkrCjRs35o8GxzRvBAKBAH76059i3759SKBvG7CbmMBvf/tbXL16VeE0
sQ8+ywSYABNgAkxg8RLo6emBvBdu2bIlpkx++OGHcLvd2LVrV0z+74Ynqd/Ot4vDRbvzjYjjuxME
bt26hRUrVsBLC5nvv//+OxHFopDZ1dWF7du3K5wWRYY4E0yACTABJsAEpkHg5ZdfxjvvvIOLFy/G
FOrKlSt44YUX8Pbb6reXYgo0z57uxqJdtuGf50Lm6JgAE2ACTIAJMAEmwASYwHwSYIV/PmlzXEyA
CTABJsAEmAATYAJMYJ4JsMI/z8A5OibABJgAE2ACTIAJMAEmMJ8EWOGfT9ocFxNgAkyACTABJsAE
mAATmGcCrPDPM3COjgkwASbABJgAE2ACTIAJzCeB+HkfYjAIP/3CXQK91mi6GQh6RzDo9SEx0YDV
qw3h4nh/ARDwDg3BS6/sTDakIsUQWbpBemdteA1ISKDyj/QSykHQP4KRYR8CiclYuzrmTyeHwi/Y
nYnaQRQOdzcfss0mIGmSMoo5bUEqd5nHmAPcTY+UZ39QeaXwtFMRV/mcdu44ABNgAkxg9gQmuAfq
QmPRCb1DA6RjAInJK7E6Zf5fjamn9W5s42SG34sLOYnKh7jkx7j0XyK9q7/wQkeM3EZQW5KNxOUr
sW7dOqSmLseSLYVoHRhVIfuaKnGqridmeXUVFej0xuidvUUlEBxqR+GWJViemqqUz8rlicgqqcWI
HsrfgUNhZS/rQGLiEmSXXMaQ7kdugwO4LMuZGnMqlfO61JVYkkXl3De/H7gIT9Jc7neePxSq/6F2
QBy25FXgjmdxpANlxDtUJlNkrLNiH5LL26fwNcVlfyeyaNBW3h5rrFPIi+HybPoBb8ePlPJpj6Ff
iIjnLuQzBhTshQkwASawgAh4UbltvC6o3wuj3SekjlGSLXUM0gukDrgyGVuOnkLn/N1a7jrHOFH4
gdv9xKrYgf7hQfT399OvGw6rBWdytuFC19TK3EDDD3C4/AaqWtzweDwY7G1DMc5g94HzUO/NfjQU
HkP1rz6NrVCCN3Ai/zwCybF5Z1/RCPjxL8/uxJlVpWjrHYTPMwx3ox3N5Yfx/IWuUEAPjKhxdaO3
uxvd9Gtz2OAoP4JnQ378qP2bdThS7qFy7obH58OwLOePqJzXl6IvJCned0rhHtTawWA/XMRq1bl8
5JyLdfA7s/wHb/47TpZ/iFirfCJFY1wq/8/CJazBd+vrcfjh+XoaN7t+wPDI02isb8HDU0IaE8+8
53MWZcJBmQATYAJ3hUAy/qROvf/39jpJhyO1sMaJ3l465+7Gsc2T3Ce8HchJ3YnyGwVocZOO4fOg
1+WA8VIRjF8tw8Bdycv8Rxo3Cr9EY0rbgLUpq7F27Vr6pePg8f8JM50fvOVTyXl7cKGsEFlZWcjO
K0ND1+jQ7dfvtZH2cQTmXRkwGMicJ20Hii9VwbRhEIM0XuhrqMArLsB1zIjKVrX4gyOdqCzLU+Rl
Zeehoq5TMymhm/WPTsNFfy/mFKKhJ4bpPDWF/H9CAj545QeVTfuwI201kgwpyMjKQyMN6L4Y8U2u
VXj4kXSkpacjnX47DubCbgQc7/UqUv1dr+LwOcDa9r/xzV3pMJDJVwqVc2mdAya8i7fu+BT4hJmb
45MeqsepWL9aawer1yIz66/wNHFo/vVgyOTJP9COU3nZ9GXCLOSVXY6c/Y/SThAcQl0FtSH6omHW
0ZJQG/L3NOBvT1RTXs6juKIJEw+x/Wi/fArZ1P6OllSg7lozVoU/MZ1Mdl8TSgojn5Z11p6ip21y
sPcpelzv0X/dBdHZUIm87Cxql0fD2iRdn0S+HjJiOwmDifoB0JRAK+XrqBJnNgpP1Wo8x/cD/uEe
/PK9kZCp2UhnA0qoHLKyZLjL6NHAjY8n9nxOJjMif3zABJgAE1h0BBJId1Pv/2lpm5FG970VDz+C
NHkuIx2rx5gB69nvvFyKS7DA1X4auzJIx0gyIC3zIC7218PoOonv1sZq2aFLjNOtWKDuvffeE8uW
LdNS5xF2EwTN8Aua4Rc0wy/6e92ixmoWhF3U9AbIn09Um8mP2SpanG2iqoD2YRJOnyrC565W/AJm
Ya2qIT/dwiODac7X7RBUd4TRUirqnf10tlcU0DFMxaK+pUXU2HKV8FVuVaC73krHRlFqrxbOfi0S
XRhvpyTw8ccfKzzpS7vkNyBarCbl2GgpFlWORuHqHoyU4XMKE5Vnm2f0dGDQqZSRyeZUTg632UiG
WbgWUXHQ58EFfYk4lGmXXdb5UkEz/Go7oLbgrLcr7MxVLtXfYAuxorqcaxMtbfWi2Ej12GgVslZH
byceUSXbECyiupHqvN6+un0iMOgS9mIZt0XY613U2sY7V5VFSYe1ppHCqvtmu1o2QkwuWwS6RS6l
11LTrQoNuIWFjgscvRRMljuEtW1YueauUdthcVW9aKwpVeIrqCd/0eSPS+rkfcX4fkCINquR4jEK
u6NFtDjsSnpMdpX12H7A45R10KjWUy3tufZ64WypUfIEczXVdiqFsf1NrPmMInNcNvkEE2ACTGAR
ECgvLxcWi2VMTjzCRvc2q1O9N4RffOONN8Rjjz2mnSL9kfwZrW3hXrR9n6gi3dKo6RATeLhjp6Tu
evPmzTsmfyLBmOjkQjg3VuFXFRGpjIT/TKKqUVMSxLBS+CioEu5+0goDg8LldJMaMOqG3Y3CWqAO
EnQ5pQ635kEteP1GLgL9wlFVLTT9XvhIiaKnCcKmV66Ai278NKAIGzSMxsR7UxGIVPil74BwkjKV
a5LKlV7GuaKxV1MtSeGXSuDoNX3fLOo1Py47DRqMNqoJi8eNV/hVRXosh1xbvRjU6qI6KCgQpKdL
rMLX61C42ZyyNUzeTnzd6qC4yqUTHBRWYq53hv8/e+8DH1Vx7v9/0AQSMWBAIwX5D62xzSKhClJE
E+6XP9UaKCC2LK3Rm+BXRRJbpPEn9Bq4TQPfWwgoN8BPg4VQaaAa1CbybUhfAWlSm3jdqJtKAkkl
aQmSmMSwC7t6vs/MOWf37GZ3s0ASk/gc2Ow5c2aeeeY9f/aZOTNzHFbRscj2aewriurXZbRTTPnJ
7rCdyS7X8k5qWCo602a14yY7enq90xpuQ+Nsyc1UsotqyYAOrLtnifDPQHSIxA+Aqx2g6/L8XCW/
XOuAOlqVfBpMMGVqHRmvdqDVIhhRuyCaoHqVe0puidJocyit9Val3FovDf4O8QSZzsAyPVPJV0yA
CTCB/kDg6gx+GuAxk72Q7svgp4EoMZicUtDjmMRveE8b/H1mSs9FMZMhswQ22sFFzMum0Xc6yOSO
nyjPgEj8aFcu4rYmInoULcgNjcLL79ZC39hHrMzGpHg8s+V16uTYaA6/BTlpcVifsAxH5apPBy4K
SRdp+bY4QkZiysRL+MX0ARhAi4PDo2YjX72j/nWq/hzabCLjLT6/XAJ2nGtoRuwDK7Hz6Ptw2JpQ
XZ6PZOzCnMRXtDUWYmIFkJVfhJKiIhQVFaCo1IImx+uYP1adNzJu5kKak/U6TneYb9KGmsoaNLvX
Z1+ugr3IP1EwZaLe5qC1DvXIT6fxbzrumXsvbnJtYyPmMW7FpHAqu7SgN3ycmPgmDgHAfz1xXFCn
piWaaKEzlfkBA6KwlkJYPjwlp/DYHKKGXIRWQ+jccLSdQiFdxkwY5nIcH0u6aXnRmezYH1CNtqzG
u81tKHuZYk1LRIxxOpCU2oQqmnb36KzJrjhifvwMVsaPRWfyXQHkiX8GoNR5tAMIg+muW1G1c5nK
JHQIErYC44dqEgO0AyEj56IkKxlbl89GVHgohiz4T1jOObTdhrzjMWroP52BZRpl8DkTYAJMgAmI
Nv2S+Nkc5JuFaO9N46N83+xnrn3G4Bfch4cNpi3+QuS87C1i7hXWY1zqYde8+gtDY7GPtmJsqrWi
IIeW5D62ALvLxTz+ZuTQyuxhGce07AujeWAxeDg9i7oMFnzwifCjH+oiQ3vVfoybnYjxqUWobWyF
YrPSDLCOR+hVrknsKPFr6NL8Lu2oE4Wd2uLrkLBITIx9ABsLyAgsvuial95KuTVrbjzupjni8fHz
ET89BpEuIxcIv24kwSvGWyc8l+A4a97AJNMk7LWoBm3fJkw9Xwyl9Qm03WXESDyw7hCyyZ5fHp2E
St24livcM0Fj0rQ4yUEdqEaUFpXgvvGiI2CH/3qiksmvtUGhnqyDPvWWUpSm3kNmr3ZQq+mzyEeM
wAzy8tln7l6Vo+W8Hsr17Vf2yDjQtD1s3LwVm2gdRs5PZrrCuE+GYDzNu3v3VKPLqeHYHmzaX+a6
9ivf5UOcdM6ANm3TQjQgI2oa1l5YiPLqetBDE5RnmpBf1+4h0Wc7YG/DTXOfpUGKVlRbSpB9Xz0S
qU2p8CiGejxGcQHSGZRMoyw+ZwJMgAl8nQlEYMbCBFjWpuGY0dQjJM6at/FYMRD/zeFfC0B9yuD3
yJGR83Egl2b+bk3AjjIxRH8Wv4qOxqgX/gyMuhX33i3MDzrk72kk4nLIXF8/G6k7C1FV14C6mgps
e8JE5qEZcbeJfdrJUCH7pPh0JRrIcHI41F/luLvvAK0jxbFXttCiD8NBTxqEcXn8RCWaNUPLcJdP
L4dA5ESQDYXHoh/C/qOVqGtoQFXZQSQtoKHU5JEeu8JI7H5kh0xciII0yuY5o2gxZwUamptRQ3IS
Jy2Xo+I/ihUGb387IrFyh+j80pKk9ELZORo/fSElci1yCqvoSZUTllefw4w5s/Ge6CsEqCcR0ffQ
UxVg3c430UD757dVH8EC0wyklWqGuyjylgq8W+fVagqxGIXZ1D/LSN2CinN2NNMi35+vtbgW7XYq
GxH4wTNptDPTehTTE4z7bnV1MaR09U8kvnMfsG/pS6hoaIOdtll7ngzo3E9D0bl8g5gADLzbATht
OENBzbNmIXbiSLRV7kcipQulH6lPngK0A/baPyA6ehx2/aUJE2Puwj2xU0jSENpOVuji2d4IF/fh
P52BZbol8BkTYAJMgAmoBG41/xft6FOM2cNW4GAFPe1vPoeqo3swbdJSmiiShWfnj/16oOrxiUtB
Rug9h18s2tUXZ7pFNCpZcpFhmlJNc5UbS3PkwlvKOZpHCyUhLc8wn7tVKcpKke76fZjMSr5Vn6+s
KJZc7X5yHkVRr2SLeV+aLJM5RTHTwo8E1/zhei1u94JCt1581hmBDnP4myxKptk4f5/yOzlb0afw
Kz4W7fqOo1HJS/ec524yZyqWpr652MJ7Dn+1WLRqyvZYmyI4WHLUxay5ctEJrYfITXOVXVGG0/Os
LlyB6kmrNV+uVdHLfRytidGXTztqCxSxgFbMUTcunnYJtlUrmbI+uuuNe9EuLasNIFvKsFnkOo3k
XLeuIt/pAYZ77YytVsky1EuY3WWkU/kuRQO3FZ7tgKFdkGlPUNLk4uU0Re4VQO2E2gap7YDNmkN8
EuQcfjFPv0BbvKzzzKL1BvrhEU/Q6QwsU5fN30yACTCB/kLA3xx+sRi380W7GoUmq5KVom4OorfH
5rQct43Rw7CEDj09h3+ASCNF3OuOkydP4vbbb0d7u+ej884VdaKN5gHTq1rltIeO/u1030Zv7gyn
N7l2HEUUb3OF4c2ldnozL733lbby7OhXyFbfqmmYV9IxQnbxQaClpQU33HADaJce0C40Lh/623TF
TGcxbeWKD3praTO9UTkkhMqBn626rlh2DwasqqrCHXfcITlddrTONmIgqkKEj7fdBqonge/Ri2Tl
1Dp/+sg6ExpJ+efLRyDZvvz7drNTuXHQ47uO9fJy5Pv3690OOGkqjXg7o9jS11epDNQOyLC01ic8
kvLBKzne8Xjdhr90BpLpLYOvmQATYAJ9mcCvf/1rfPjhh9i7d29QyThy5AiefvppfPDBBx38u9pO
n7+LHbx3m4NYJ0cGv3wJWLdF4iXY12+Xl5e+dkmGYqSYouPvCKP73j+7br/i1czGQ+wJ7+livEuG
z9UYpZ6i+IoI6K/GDsQ8KFDUaYsMkM9Byejrnqiz478qBKonge91VuQD15lAsoMHHiYaa5/eL0e+
f7/e7UAI7dscqDgFagcChfWOxztJ/tIZSKa3DL5mAkyACTABlcDXue3su3P4ufQyASbABJgAE2AC
TIAJMAEm0CkBNvg7RcQemAATYAJMgAkwASbABJhA3yXABn/fzTvWnAkwASbABJgAE2ACTIAJdEqA
Df5OEbEHJsAEmAATYAJMgAkwASbQdwn02kW7YneeMFpAK1Zn89H/CFy8eFHuePKb3/wGAwcO7H8J
7KIUnT9/HoMGDeJ60EU8WQwTYAJMgAn0LQJ/+ctfcO7cuaB/B0+fPk0vnbQF7f+roCF2fLOLXSF7
8Oi1Br9gEB4ejo8++qgHcXBUPUXAQS8sGjx4MP7+97/j2muv7alo+1w8ouPL9aDPZRsrzASYABNg
Al1EoKmpSRrHwdqDYqDsmmuu6dX2o7B/evroh/vw9zRCju9KCPjbh/9KZPXnMFe1D39/BsNpYwJM
gAkwga8Fga7ch7+3APsq9uHnOfy9JfdZDybABJgAE2ACTIAJMAEm0A0E2ODvBqgskgkwASbABJgA
E2ACTIAJ9BYCbPD3lpxgPZgAE2ACTIAJMAEmwASYQDcQYIO/G6CySCbABJgAE2ACTIAJMAEm0FsI
sMHfW3KC9WACTIAJMAEmwASYABNgAt1AoFdvy+krvW20F2sbbekYHhGFyAij+k7atskp9+73FY7d
+gYB//kLOGnPWqchGSEhYQgxFgHDPae9Gc1NNjhCwzHypkjDnT5+6qRyTh/jEYiD0d9VnzvtsCMM
YX6YX7X8DgK6p06LvY9D6B0f3Z8MkVchQfByovlcM2yyXRtG7VpYBxKqgx3nGprgQCgiom6CR/Pn
FaLtXAO1k0Bo+DDcFOlHHuXnuUZV3jCS552vvveIpvR4e/SKu1suSVenqO9dLNxJvxkhPZAeJ+lP
EQXWP0B+iLaPwPsIr9aRninPXQyfxTGBr4BAUG3jV6BXT0TZZ0b4nefKkDplAIZERWHUqFEYNiQU
8c8eRLNGqa3iN3K/8rK2nsDGcXQ1gc7yF/YKLKH3Mog96fVPaOgALHx2P84ZlXE2YP+zC6WhE0Xl
ZFTUMAyIT8Wxup59wYVRpa48r3xpiSv9Rg5TVm5DdyexIoPYry/ryuQElNUtdbqtAt+nMvSbCr3l
CKgC6o7uxKbDNYE9+blbuW0uwjMC86o7tgcLB4RimKtdC8eUlTs75GXdsZ2IHxAOWaZHRWEIlf3U
nceoA+Z5iHr07ELRTlLZp/IfNYzkrdiESq/k1h3dhgHUGdblhZO8TYXudFbtX9mhnKnlbRqO9XQb
a69EPOmaUeaVCM+kX/aVvXIbtRO/cf2GBBbQjMPbtqHyitLehh2d6B84P+qwnsrstE0dy1JD4RrK
p4dg9S4IgRPDd5nA145AsG1jfwbTRwx+O36fNANbh6ejtLYRttYmWIuyUZyxFE/tqZL5EzF5GYoK
SjAhvD9nV39NW+f5K1LeChPyLNWora5GNX1K87OQn7EcSVoZAJk/B58YheUZrcgpqUYrvWmvqbYU
aee3Yva4dNT1G3zpsDY2or6+HvWN9bBQXRi+azUSd1V0awrHLy1ByY8mdGscRuHdUqdDgSEUiZ8x
b2P0dG5HYepjyP3nBS/34C4pKpgGib++j7bKPRg3OxGtaTmw1jfRmyFbUVueh/G7HsO41YddT7PO
HdtE/h7DkPQ81Da1UvvXiNLcdGx9bDYe2mYwAqkzkxg1AxmnU1BipXZSyLPkw7RvLUz3bkCDrgZ1
nhPnrIY5qwD1JK+1qRb5mQlYu2ASChvUp0eOtrOkfDrKa2tlXRP1Tf0cxu0RuqAe+g4ZgecLCrB0
QtdGTA9U6PA1au4jXc7TWLf6JTiu6PclFINMgN+i0Gl+jMWPshNgWfsqajwe7rXhjU1bgbSnEBNc
gfaRMHZiAl8DAsG2jf0dhdJLj48//li57rrrNO2alGwTFKSXemhblGlWUvKs0s1WW6RkZuUrTZqP
2oJsJT07V8lOT1bi4hKU9NxSpb62RElLiFPiEpKVnJJaD1l80bMEPvvsM4XqltLW1kYRd56/iq1c
iUOcUm4z6mlTy0VagXS0WXOkzMxSvRSofh21+RQ2Qcmv9QhsFNRrz61Wq3L99de79LNkxykwZSue
KXG4ODg0n7b6UiUzOUExmeKU5PRcxSPptlolLytNSYiLUxLM6UqR1cDL0ajkZ6UocSaTEmdOUwoM
92qLcqje1FMMNqUgM03JKRXn6mGrLlDS0nKVek2BavKbTHXNRHUvK69c0fXS/bu/bUp5XpZilvXS
LP3qafOo07ZqqstZSlFJvpIi/aYo+ZZaxVqQRbrGKeaUTKW0Xg1pqy1Q0rOKXIyEnLSUbKVa3Jbl
CEpWuZ7mVqUkN1ONn3RNycxzsaotyFTITpNlKlumm8IH4CO4lJIswdWclqVkmqHEZZW7k+px1qpk
x5HsuGxXm6XfbixKpzjTVH2VWiVN6JCS34GhJcdM/uKU0lY1pCU7ga7NikUHqAusL5DpSM6rli6O
6jyZpvxaQ644rEoapT/PqgqT5Swux8VQFxX426FYqN0VeWmKMyuZlO+6KiJPMrNyldxMKlsJKUqR
R4HUpLZWKznpdF+Uy+R0d9lz1Co5mVlKeaOq7+W07dVUPrKL3G19LV1nFajXrZYs4pClaPgUR5NF
+71QfyOy8i0ac1HeBWvKT3OKUlCthghYx1qtSk4a/fZQ2UzPyVVSKGymq8x5UgwmP5TGAhm/u9yS
jPp86ZZj1Sl7yuUrJtBfCGRkZChmszno5Lz99tvKt7/9bZf/YNtGV4AeOBHtyZkzZ3ogJncUcJ/2
rjNPg9+hlGSSoUOATGSE5OQXKZbqRg+FW8tF423y+vGDkkDGTl52igwr7mfm5ilZySa6Tuj4w+gh
kS+6k4Cnwd95/uoGv27cCN0cjeXyh1Q3qppKRRnoX/na0eAXRl26QiP8Co3wy085GVmibiTkWNQs
ayyhDg7VleQspaSUDHHRWTZlKqp53qTkJAgj1qzkFRUpOSmiLlC9kfZvq+teblGJkpcp4oKSJy1l
RSnPJL9ap7skXTVWdWOpKI2uE1QDsTpfrW9pOQVKSb7IE9It27fhqxq3JiWnqFQpyhWGLpS0IrVu
e9Tp1nIlge6J+1l5+VSH1fYAphQlNz9HMYt7KQUy/a3lmeQv02VIe8jxMvhLRZoo/dn5JaRrtuQW
l61ytFXnS0PZRJ2ignJBLzAf1QAnwy6viNipBqK/dIvyLNLj3TlVM9Dwl9It8jKrXCdtvFeq3ROZ
Rx0IymdTpuegiOrbpuRQ58Lk6nxonQiSm5yereQXlSu1TQbjnwKpP5DJSpHFopSXl7s/1Mny9OnW
xyo7IJR/lO9FeSIPyEDW9Gm1qGUUpmQlhYzmEs/mm4TYlFxRLhMylZLyUiqXIq+1Dr7GQGel6hZc
224ss0JT47WnwV8r2xLEUSe3hMp+VrLUXzemrdT5E+VEDCKVi45lwDrWqGSJOgfqlBZR/RMdO5mH
eifTzUw96zw/RP5KPloZF+FUDplKB5Te4vmaCfRxAldn8F9O29hzoESbwAa/xtvT4BeODqWcfpCT
48QPtNqAAvSDpI0UqT8o9AOh/S6qI1TZ2uhNo5Iufny0H3LxY2syjIz1XBZzTDoBT4NfuAbOX5Fn
0qhz5b1eBhKUAq0MqKPfWS5DT4+rL393NPhVQ9JdB1QOyVkFijYAqhkCKeoIMVlnNnrCoRocVDm0
kcI81+hurZKdRkYWMbRV50p/ORbdMGlUMom3biiWZ9HIbaZquOujkgXC2qDRYZE3maXiQh25NqUX
uQxDa67QmfTxYSkKmcKwyyuvJZPPodRayhVrvVqJPeq0ZiCnFandFof2NKdAe8hgFaPbJjXvPQ05
0kgam1rbQHJUA1qkkZ4u5Ocq+eWayeRoVfLJ0NTTKO4LQ1lvNwLzUVmZtVF0Uebyk93sxLXH4dJD
N+RblbyUBBr9TlASxIc6GXLg1uVPzxODFI2JOupLBjM9UdA7ZAZfdEodFWF0GoxFKhTyKY9goZel
uJRcl/FoyfZdznTGnvLFVb18EmHOVZ8iCBe1M5cg22Q1D0xKiY9kCL/iKZ80klNy1PynJymWcqva
fnsxuJy23VhmRSzGa49y4qhX8mkkXh8st5FBLzpkrhF1h4XKDZUhrQyrxrbvOqY+aTSk1Ut/oUeH
o5P8EP4bS0SHWB/QUDsJxvLWQSY7MIF+QuDqDP7LbBt7iJlod3va4O8zc/jPNTQj9oGV2Hn0fThs
Taguz0cydmFO4ivwtY7KcZHGY+bfAXXWZxii6Nn8/DtuIcbqMVw/4e9eQEDsPtJ5/op8zsovQklR
EYqKClBUakGT43XMH6tOYB03cyFgeR2nOyxga0NNZQ2anb0gqVetAlEwZaLe5qC53PXITyeTjY57
5t6Lm1xbmIhSvxWTwgfQwswBCB9Hpos8nGj75GM6S8CEm3XPY7HyV8/gbmLouKDWpEQTLXQeQGEH
RGEt+bZ8eKrD4tCQiXNABhqy/y9xtRzGPqqNi6fdRNPeT+J4MYVZPwehUsYARC/fR1JO41ObVMLj
T2ziDmQmFGPptHEIp8WriS/8CRdogaOvo5UcR9yg1mibqOCIQ5Q2rdtBKzxolrRhFxPPHZ18yRPz
t0133YqqncvU9IYOQQJNiR4/VPftgIgFF+Vk78B82k6hkLzGTBimB8b4WMqbDmXRdVuuJWhp1z2E
YvT3FmLZwoVYuOA25O8rRouIVo3aHch4RpPQRapp+xf6OHBJFI1B0qHDH5EO0/go6S52sGpoG4Yl
T/0KRxUFtqZ6lOSlo3jrcjy9v0oLW08BskD2uXgK7P68/xR87nllP49PKGTMRHf6w24S8akaqkKH
Y7Be7LRY3F+R+NGuXMRtTUT0qCFUbqPw8ru18NqQSnq/mrbd74qKkJGYMvESfjFdlHuqM1Gzke9W
jrYI08qAqwz7r2MOWTYtcOjtTdhkLKS6oue0Uaw4Dy4/gJvuWgozafW7d5vhrClGBpX/J+dN9BbH
10yACXgQCL5t9AjWDy/6hsHf/C7tJhGFnVVqkxkSFomJsQ9gYwHNjCy+6FrcFih/5A93IA9876sj
EGT+ttIP3Ky58bg7Ph7x8fMRPz0GkQYDIvy6kZSGYrx1wrU8UabJWfMGJpkmYa9FNWi/uoR2RczC
gBqKCNpKMCxiJB5Ydwi0ng/Lo5NQqVkUjotkrCETNG5NCzcd1EGmRZ5FJbhvfARCQ4VFeBrqgkWh
jx3Hdm7DUcMWP7TWAYqDtjSlT72lFKWp95Bp7H1EImFdMi32fAGb02lRaOYjmCjyImwEvklfNL2I
jETqlIiOSaOVOmjr8U0fdnxbWyge2CEWotajvCgPk0vXYtpzf/SOzHCtW1EGpw6nIo2Fro6fXyOP
lrFmRE3D2gsLUV5dD5qoAZrygfy6di+JnhJ88okYgRkU6rPP3Po5Ws57yTFckhG4gPoD65/M0RbT
hmH6koex8uGH8fCjS6ika0fEaMwnY3H1loIOBmPF/gwq7VQnJgvjMwIzFoqFnWk41qwHVr+dNW/j
MeqExX9zuHSofjWRdq9a71rEHhY5EncvSQM9BYDlTIsh8CD4yDLDfeOpyujiJXf6dWqB+ixuCXZc
GBqLfbSVblOtFQU5abQoeQF2l3slxh3AdXY5bbuDOia+DnvVfrmAenxqEWobW6HYrGRcdzxCtUQF
qmPUQ6SAcdD6pnTehNMW0b30fQSdHyG34sl0EzL2FeCP+7fQA+4UTBNZzwcTYAIBCATfNgYQ0i9u
9Q2DP3Ii6HcYj0U/hP1HK1HX0ICqsoNIWkDDcckjL+NHqV/kWf9LxGXkr9tQ7YghZOJCFKSRETVn
FLYdrkBDczNqqJwkTlouR8V/FNsffx0jsXJHAe1ftA/m9ELZ+R0/nZ500Nh8TmEVDf46YXn1OcyY
MxvvUV8hLPrfaCzegrSth+mJh5O2ndyG2Y+txr/ITouIvofuAet2vokG2j++rfoIFphmIK3Ut5E0
dt4jiLNsRQYNha5bNk3LkJH4HuVBfuILtBWqDSGOOuxKisacOW/RPuod8+yjfZNoRHc9PrIPQ+zs
mYgdT36uG9jRY3BWowyndmqKcfzdOtibq7Bt3WPkPkSVaZTjtOEMuZpnzULsxJFoq9yPxLVkmZV+
pD01JCiU9OLTlWigzlRgPqMwm8YfMlK3oOKcHc01hfg5yRruz8ojA/2nu/PIwl6LUQufRWFFFRoa
6lBxdD9WTptGhjztoS81vgn/e18OsG85ptN2nZV152jP/joUbluBaY/lw5ybBb1Y32r+L6RRyNnD
VuBgBT15aT6HqqN7MG3SUrI/s/Ds/LFS4qQ4YcpuxTjarvNYVR3FW4Oje9YjkSJdctcE6UfyslTh
REUFKsoqUFZWRh/1u8bXo7KwSVhO6V8/ewvKGtqIeyU2rybuCT/BbYZqZ8SvRaR9ncWvoqMx6oU/
A6Nuxb13i+4THXqvQb267L+hg4YQ4r2UJ204V0ltAeXJeB954nCogwFxd9+BsfSg6tgrW6hGGQ7Z
8FCZOlGJZioLgepYRPRcqkfF+PlmUcfsqDy4k2j7P4LLDzX8tJ+sA3YtR8J6C7KfjDM80fIvn+8w
ga87gWDbxn7PqYemK112NB3m8NMOCplm4/x9mlubnO3aUUOdN6nOFxWRWQzzjeW8YlpE5dolQc6p
dO9ucdnKcYCrJtBhDn8n+etr0a5vJRqVvHTP+ccmc6Zi8VqU6Dts73P1nsNfnUeLCWmXHn3mt66x
JUddZJgrJyHTeojcNIUaL9cnXdvNSvhvtea7FsAKPyk57l10vO/F0ZxqbYa7V50SkhxKgVj0G+e1
boLmI2fLhfFa/LRQU19rI0J5HK0W16JGqS8twi3VFiN41GlaJ0CdEdecanVOuKG+izn8tOONNvuf
5sNri3opjDlFsNF2r9HkZFtUn5ZcfUG/0DWBdhoiObRDjr7EwXU/OU+qHYgPLYJQaHdLF3ORHr+L
djUITVZa1Jng3a6lKyXVnpPd68vzFLNcCKrLj5O74HRYFtFkVbIMaRc6mNNyXO2kzr6+NMejDAh/
abnucuB3Dj/50xfP6rJc35T+LLGOgPzIDy2A1TemUfMr2TVH3hXGcNJIOtG4jit8Qlqeuh7HY63C
ZbbtjaWy3Kg60c5TJF9f5C/n8NO6D7Uk1CvZBt1NtLBY8E5wLXSuV7K0vFXTH7iONVlyZVxqvLT2
heL1ufBaS39n+eHGRDuaCT1M6doifPcdPmMC/ZXA1c3h16gE2Tb2FEPRNvT0HP4BInEUca87Tp48
idtvvx3t7Z6P1/W3rTpobENMa+CjbxJoaWnBDTfcANqWE7TtpCsRXZa/NLLW3EYjzCERiAj0SlJX
zL3zpKqqCnfccYfkdNkaOtuIAeit1BEd3qJKM4fRJm5GRPp4Y6t2L5zYXUUds1PeiinPkRR/Z4fw
K98g6/cts51J6Hg/WJlOe5t8K20E6emrRZFvOfV4q3NgPva2ZnrDM3H1MZLcUUvVRepAsMKJOb1Q
1e9hb6PhZSIV4kdXPaBLns+8133RhC6RR/QgIzyS4nU7X9VZsNx9RxKYre8wnbmqMkOprHdWnGXe
0TPjCD+Zp77N3VBKgqhjoZEUb2cqavd8enWMAABAAElEQVS7Iz+CjJq9MYFeS+DXv/41PvzwQ+zd
uzcoHY8cOYKnn34aH3zwQQf/wbaNHQJ2sYNYK0QGv3xBYheL9ivO0HL59dOrbuivEA+2Ae1VyrMy
nRLosvwlAy0y8mteSqizQ7aGn4M6zH5vBrrnR5wP5zBhbPpw9+V0OX59hfflFqzMkDDiFEBRUSY9
j8B8woRh6Rmg06vOdNAFhElDtHPpwcsLPo90HTr7Dpa7bzmB2foO05lr8DI7y7sw7x7DFdcx3zpf
HTvfMtmVCTABN4Fg20Z3iP5z1jfm8Pcf3pwSJsAEmAATYAJMgAkwASbQowTY4O9R3BwZE2ACTIAJ
MAEmwASYABPoWQJs8Pcsb46NCTABJsAEmAATYAJMgAn0KAE2+HsUN0fGBJgAE2ACTIAJMAEmwAR6
lkCvXbT7xRdfyLc7njt3rmeJcGw9QqC1lTaFp0Pkr83men1lj8TdlyJpamrietCXMox1ZQJMgAkw
gS4l8Pnnn8Nut0t7IRjBtO03vaXbGbT/YGR2h58vv/yyO8T6ldlrt+UsLS3FXXfd5VdxvsEEmAAT
YAJMgAkwASbABPoiAbHV6G233dZjqvfaEf7hw4fTntThEPu188EEmAATYAJMgAkwASbABPoDgYED
B2Lo0KE9mpRea/ALCuLFBKGhV/lu9R7FyZExASbABJgAE2ACTIAJMIHeRYAX7fau/GBtmAATYAJM
gAkwASbABJhAlxLo1SP8vlPqRPO5RtgcQGhEFG6K6PokOJ12WvARQq+473rZvtPErkyACTABJsAE
mAATYAJMoHsI9KkRfue5MqTGh2JY1CiMGjUKUUNCsXDDQVzOPj7nKg5i28FKD5qebg3ImBZO6wfm
oqzNwxtfMAEmwASYABNgAkyACTCBPkegDxn8dvz+6RnYWgyY07KQm5uFBMKdv34pfnW4LijwdQdT
ETVtKeyjb3H57+DmdGBovBnJ6Y/jmxEub3zCBJgAE2ACTIAJMAEmwAT6JIE+NGfFgTY54h6HxDVP
IT4SeDD2RixZ9v8j/JJ7H/eqo3uwZdvrOIsI3LYgEWkr4+kMqCnchqSlW2Umrc3Yi2UHn4LzTx3d
bq7/B+zDvon/NXcmKAo4644iY+efEBU7GxGn3sbvT5zG+PjHkP7UfCkXsKPs4C68vO8oLoxfgNSV
t+Pd3+YD/7YSK+PHkoBmHN23Gzmvn0Cb0GlmAlY+tQRjw/pkeWGlmQATYAJMgAkwASbABPoaAaWX
Hh9//LFy3XXXGbSzKbkJUIiv/KRk5SnVTYbbikMpyUxQ75sSFHOc6i8uq5Q8tSo5hrD0jEApb/Xl
pijWHLOUkZxXLYVX5ya74kRcgmLS4s+2tMr7pVlanIhTEkxu/RKyLXTfoeSnqG4JKelKiq6DOU+G
5T9MgAkwASbABJgAE2ACXy8CwpY9c+ZMjya6D03pCcOP91qRZSaTm46tq5di0rABeFafj99cgifX
0sg6UmAtex17/2hBMl0Vv16GZhpZN+/IhwxpzkGrshexEb7c7PjgL/uEeNwzdRT9deLDd0vltTm7
FMrR1/FCepy8vuhwAs1lSFst4jSjvPUoXn+/Gmmqelhwxzhyb0Pt+9I7brtjLlKyrCgttaA2c47q
yH+ZABNgAkyACTABJsAEmEA3E+gjBr8dzQ0NqGsbhaf2vo+m2nJkpaiGd8bSTai0k2l9+iQsEtZW
RIcPwIBwE3aJ6/Mqweaq9+X9hFkmbSoO2esd3M6iQtr3ZsSMEnNuGvH+USE1AU/+eDp9N+O94mJ5
PX1yJMX5P5BXWU9SB4KcEYVvjhffCbh9vHCIRNy/pwgHZCyfgXHjopH28gnyFind+A8TYAJMgAkw
ASbABJgAE+huAn3D4HfW4inalWfcqFk41kxm9NhYPLVltxzBB+pxgbboBC6qrBKyYa2tRnlJPnJy
81C06z5p4H/yQbm8v2Cm+zXGHdzO1YAG4Mlen4Vxwt5vrkGxuI6LVxfwtp3GUWHhm2ZigjTw6ZyO
iCHXyW9nzdtIFAP+4j7Z9G3NDbgu9knU1teiJC8L4uFE8a7HcKCcEsEHE2ACTIAJMAEmwASYABPo
AQJ9w+APGYcEs6Bhwex7F+LZDc9iRfwkdQQ/bpk0xiNGf0edstNahY//0YDj+9YhcflS/Kk5HCE0
Mv/u68ISBx5btxmVzTQdx4db86kP5Ih93MzbZSeh7fR76vX8qXIBr73WAmnP32eS1+HDh0uZ+xLN
eHbTBsydtFRem7T7xb8YhUnRk5D4QjEGTviONvpPA/xDw6U//sMEmAATYAJMgAkwASbABLqbQN8w
+BGGJTusyKSVuLDkI2N9BvbRSHtcchas+Sul8Y2b4lFQkg1T8VYkzJ6N1bssSMkuQfr8kcQwEjN/
Imb005G/HqdbxUlHtzP/8664gfl3TZDftRb1Ou67E+V1/d/fl9/xsZOpEwGEjF2I8tx06mhYkJFb
LDsHwsMM7f4D/8dCOptQnJGIGdPmYD31FlKyi/DQreLxAR9MgAkwASbABJgAE2ACTKD7CQwQS4S7
P5rLj+HkyZO4/fbb0d7e7hHYaW9Dm82JkPAIRPh6Ey69Jbe5zYbwiEh437bTvp6O0FAK5za4fbl5
ROj3wo79K6cj86QJjz+/ESvvCsWeJxYgkToaebUOLBnr3vFUxGFzks6kUze8GNivhnyDCTABJsAE
mAATYAJMoHcRGDBgAGiXHvkS2Z7SrM8Z/D0FJph4xEu7xml7+7v8J+eideePXQuDXe58wgSYABNg
AkyACTABJvC1J/BVGPzuYeivPf7LBzB2yWbUW36IE5U1uITrMWLidzBz+q00AYkPJsAEmAATYAJM
gAkwASbQOwiwwX9V+RCCkTF3Ywl9+GACTIAJMAEmwASYABNgAr2RQK81+M+fPw+73Y5QmnPPBxNg
AkyACTABJsAEmAAT6A8ErrnmGrS2tvboHP5ea/APHToUAwcOxJ///Gdp9DsccrP9/pDPnAYmwASY
ABNgAkyACTCBrxkBMXdf7JUzY8YMDB48uEdT32sN/pCQEAgwY8aMkYb/pUuXehQMR8YEmAATYAJM
gAkwASbABLqKgBjZ//LLL6W4a6+9tqvEBiWnj+zDH1Ra2BMTYAJMgAkwASbABJgAE2ACXgTY4PcC
wpdMgAkwASbABJgAE2ACTKA/Eei1U3q8ITvphVr07irXERISBpr18zU6nDh/9l8IGToCQ73fKNat
FJy0eJrAE289WictpjZkhTt2gx/dseX8Wcjg1w/H8MHBZJiTXrZ2EdcOGuyKT5elfge4T3q1f/EF
BtG8uGBiMsp12ttx8YtraU5d92yq6lO+sx1n/2XH8FuGX7a+Rt35nAkwASbABJgAE2ACgQj0kRH+
z/G75AmYMMH9GTNmJOas2oKK8z5NT59pPm89gowtR2D3ebc7He2oOLAFBypbrjiSlopdiJl6JwrP
BJ/eK47MELC98neSu/mVSulqr30NYwz5YMwT8y7Vj/BoP1OGXy4ZieiYqZg6dSpiJo/BKmIfiEB7
bTFWzRmDyZMnYwLlb8ZbVoMm6unxLQ/J+y9bjZLacfylZzCS9BJhx4xcggNlZ1xhhc5zRo7ESMNn
1V5d1xYc2fIIpWkyhZ2AJRmvBdCxHQdWGeTMmYM5c8T1KlR6vhDaFbezpRJbVs1xyR+5JANlZ9QS
6PzXO5h6Zww2HHHr6grIJ0yACTABJsAEmAAT6CICfcTgBwZqCZ5vTkJSkhkz6dp6aDPuj9mA2mBs
YKcVa+Y8jO3vNHcRuuDFVB94HPenbsalkEHBB/LweR65azYCMzdg/qTuGYH2iM54oQ2VD9HcvrB9
rp3NhDlJ5IX2MZsRPylcvddSBvOdi7D7BBC9eBU2PJeEaLpzaPPDeHRHhRbe68tuxS9mLschsvGT
1qzBfLq9PWkOjp/X/DlbULxjFR7cTELpMJK01x7Bg+v2UWRmbNiwhsrGCaQu2ouzWtCW07VQuw7R
iI6mj+Yuvs4c+Q0e3lxIbBdj8fxonNj+BP7ztVqDD+9TCi1kRM9EtNUK+k9HOMKNCrmCOHFsRwo2
U6JmmldhTRKl6sR2LFpfIDudIbfMxouLgd0P7wab/C5ofMIEmAATYAJMgAl0MQHNnOtiqd0mbj7W
/Op5RAutn/8ZXnpkKtYV7kbO0SQ8P/cWwHkexb/7Lf7w10qaFjIYk78bjx/9dBHGDbbj+Cs5ILOO
DK5UrN87CukrZiHMr39fCWhH5VuvYm/hO/iUZN84+U6seGQpYm4OUz07z+KtXTtw6G+fYPCNMVj2
eDJmjRtMI93HsWuXjBnFORnAgkSsiBuH89Zi/DbnD6j8tJ38T0b84hVYNJ3S4ONoqfwjNpJhuXjL
PRiq3Xe21OKN3By8QfGRAMTMegCPLJvlut9eS/HuOCDlj/7uYjz+yH3QVYUfXX1E7d9p/nJsen6R
z/sVB3eSyU029JpcvJoaJ6erLJ97GybMTgXO/hNiMNx7M6qzfyvEIXKfv+FtPP9oDM7e820s/vQ6
3BIienMXcSA5GqkqRrr2PL5oa5IO5qefwqP33YLr39mME4XlqKeIbqaI6k+po/lb3t6P+8dcj8FD
9djb8e4buylsNPa8uB1zw47jo8IHse+NY/jlonEddBRaL9tehGUyNjveemYCkqif8WLJLzHJZ026
iM9k/3IxNvwqjWKpxJu7C2Ft/ZxSBHojcxhm/nAV9YS2Y2/x40iLu1lK5j9MgAkwASbABJgAE+hK
An1mhF9PtE1YSvK4GfMeSpJnn3yijtof3xyD5Ws349BH5Nz6EbZvfAIztx2niy9wuoAsM+3YV3ya
XAD//nWf7u+zxdswL2kd9rXfiMmj27Fv+1rMm7pee7pwHi89NBVJG3ejkF6kcGjfZjw4czKO0NSN
L5r/jn1yFBgo3Lcbf220Ae2VWDlnOTbva8fkmNH4577teGLRnThQbXdHaDhr+J9iuorGD+4dp7na
8cZzM/EExTd49GTc2L4Pm1MfRPSWMnnfebYYD8x8kOQfohc71GH3xiRMvW8H1MFy/7pqwoP7KnwC
v9yxAzvkZwtNldqLWql+Cz4sUC3zpfPvcs1ND5u0DP/4RwMOPn+fD0MaaPy7apQXrkuRU2+mrnkD
l74RjXFDNUt68Hxs+H0J3sykIXGvY/CYqRCu+5JS8MtfrpIdg+ikZNwm7fp2nHxH1Sd13lRMjp6M
kY+8pOkKfC6n4ozFN0RPatBw3CZkt1LfUXwHONor86SxP/O517Bokt6B8A4wGIs2FaGhYbvspLZY
P1KfNAwZ6OJyc+w8+bTqT/9T6x2Yr5kAE2ACTIAJMAEm0CUEfI5LdonkbhJifO/ujROkeabF5MS4
ha9hzzQHbvvedxH6QS4KF60Dyv9Oc7JnYcUrb6N48jwUzsyE9eUVZHQG9q+PpOvJaLSWy9PoG79F
HY2HYLptMcZM/y5GEEG79Y9YJ4a0zS/CumkRnGU7ELNoI16ljsXcFY/i7cz/wby1h/Dcm5V4PHY4
+d8rR8Ax80aYZi7BvNw78el138L3xmlPC/RI5bcT/zpTR2dklF6vZ9dFNP1T9TTythlYuGQG7lp8
He6Y8R3pePLIH6RhuSr3rzRqPALFGfOwfPtG/NH6UyxFIF2Nk11U+YH+7t640XA7GvOSV2AcmbID
5fyf+Zg8xjM9gRZZhwzUjeZIrNnwHCrXbcQT8z7CDe+9jTgapl+2/WUZl/W0IUr9dGgUJsjzE9gt
BuzFERaqGtX2f6Jc2vszsWF3Ii4W/gYbD63Do1u+haK0qbhej1b0AK/VzHzSP4TKx9nqk2ik972J
c2doFKIn3azKpGcUb+5aSwFmYs3y6SI2OgL5pz5e9Wv44Tx6wkHHhifnuzs9g0LxDXI78c4HaEmd
7npCIz3yHybABJgAE2ACTIAJdAEB3YLsAlE9I8L4vt1P/y6G8uWALP0NQUToBbzzxot4+GF1nre8
qY+m0vsNpG0njTlxpxP/MrD7z+TvJ2P+xhM0Sr8O9+9T3eevehGb0xbRxAzt2PcEoumjH4V/rYJ9
RbRmJNIAcqiKOyz6+8hcvAdrD+1D0iJVWPRMmpa0NQ2zbnFJ08S048xJK52P1cXS91DMXE5PN07s
xvbU5dgu78zEc3t+jcdpatMn1SqX7cvv1O6pQdtsTnwRronxo6t37Jrvjl8zn8NfX3kEkc6LZOqK
I4R2uBHfTlyiEXJ6noEP/9GO2GjNoqZpRMePnsQ46iTdMrRjLLT3jgiE6DXPIvXRWJwZcRaFSbtx
qrGdDH7v7pf06vpTfSATm+kq6cUiPL9oJF575od4YjutB1h6EssmTcKmhgZs0n3feyOOHlqEE7Ij
OFUb4aeb8v0XWnWQ+rfj0Ow52KiHw3OwNjwuDXJn7Z+RKuYfmZMxzaWaf/8tlXsRPU90EEjH3SV4
NNYViB4+OdSU6+VU+uI/TIAJMAEmwASYABPoOgKahdN1ArtbUqj+YjLnGbx9SB3OnTYhkqI9gx2z
l2M3jbq++OZ7WDC2Fo/HLFLn7XsoNVC17YL2rwWOnIY1r+VihSMUn/39XbyxfzMKaYFn3MK5+KHm
JTrpRbz0+Ew46z9Ced0FjJo0xWXsCy8D9UW7zjDMXb0Zt/zwAnDhNP5cmI/dlJathxMw6/FYTZr+
FeIehdadyKgeOTMRv99zL0CdHEtpITZuP4SND+fhgYY0fGOM6BxYac7/m/iPf4tCg+V9VF+4DjET
yfhuUIV0pqsrKn8nQ4bjRtrCUvzzPIbi2wvmU2ekEHte/TN+qE3hOVu6Hw8+TGZ59AacLHrUPcKt
BY68ebQ8i4TapQsN9ZbrGYvnldqLuS1mMjmHICZGPPmx4nwrdUXaq7F3215UR/0vWhswix7HaF3G
IdfLvBkoBdXRugw6CWuFfHAin1AMRdzuDWj5+CKGDrqIixEm10Lhf31skaHWPGDMX9/+nWeKaWRf
NfbX0BOX1LhbZFjXn2tDVRatl7SOk+sOnzABJsAEmAATYAJMoEsI9DGDvxDPP74K3xjcjo8O0eJH
iWANHhFGlLPWtd3mpQu1KNhFBrkRkT6SWpeHjJei8MxPxwf2bwxL53/5T1ofsI8Wla7ZjdT5dyDm
HRrDJgVuHjaIFoHeLneVKdydi6I7b8DAv76ItbRFzeIXSzArhmxy1arEns3rcemhZDz0jSOYOo/G
jqNX4fdb78ed0X+ljgrwjeHS0vSKeTBuvZMM6ENklH5OBqzYy57Smjp1NqUvGhtyN2PGNG0qTnQU
Iih0KG0xKUbYP3r7bZRH3Yo3lj8hF8Tu/us/MGl8YF29Ivd/WZgK86rjcjqK8NTe/k/EPPR/kDp3
HGIfehLz1xWicHcSJn9oxqpvf4rttFhVHElr53Uw9oX7Ld9LoK7abpzYvAi/xBp8sll9bjE6UntC
IDz5OcIiVYM/deWzuPTwN5BP06fEmofoURR20Dn8dftuSr8gnImwd9bK6VSL500jPQZj+mKzWFyB
jWueQQHK1Xs/uEvqGH3fo4i+r2OkbWdPSsdvjxvucbOj/3bsXb9cK6fAm3vX452NdWi+LRmHty+T
cbhG+L89Qb32kMgXTIAJMAEmwASYABO4egJ9zOAXA8fCmBNHNBavehg/e2oFbhaXIePw0IursPuJ
7Uh9cBFZ5mYsjj6BQ4V/xan2FYgZPBZxtLKz8BDN8143BEseerkT/0Ko+4j7ZQmes/0CGzcnoZAG
qsWxastrmH2zQBiDLUVkUM5JwrqkE/LezKQt+I9Fk+T5uHt/SMbsIdJ9Hwq+twKPzn0Er2WexaK1
2/HgPG1CjnkDfpag+peBDH+G3aIa8KUf/Yumt1DnJmQSNr/9IjDvCaxbfr/qM3oxdr+wUE45GRqX
ije32Gkr0O14WNrZ0VizZyfuu6VzXQ3RytNrQ69XnbROi/H+iUN6Xmiu32tTTwbHYlflm9hO22tu
pjRvl0iiserFzdQhIP19HRRmJ6VpJaVp92YV8HN7SjBX6twxwEDDgoBb5qbh9xtscmvOtXIwnTpC
v3+JWIn0TsJ/kNx2IXedvInFz+Xi18u0vLnv/8PuVaeQtH2fNMyjDfnWMVbhoq+pWIzRNwr5AY72
Uyg29DqthdrF2EuuQC2n3pMd06TvTfZ4GuTywCdMgAkwASbABJgAE7hKAgMUOq5SRrcEP3nyJKZM
mYKamhoMHDgQly65jaSAEdIbU1vojalD/bwx1d5OczcGGd7i2ol/77jEG1PbLzpJxFAfb4K1o6Xl
IkJI/mD9tbS6AHpTcPtFr7fACjd6qyxCyH+gt9A6q/HMmNm0C00u/vG8us2lKlZ966x4A7HYatLb
/FR1Fck1pFfXh55v+NXV5efqT+ztLbjoDMEg0i+oSTrEpIWYhBDfQEh8aiby0m/eEKuWdjhpWpWv
siH1pEk7vu75jKuLHCt2LMH9G4fgzZMvI5YeSPDBBJgAE2ACTIAJ9E8C11xzDb788ku5G+GZM2cw
atSoHkto/zP4ewxdz0Zk3fsI5qytw+8rizDLcyZJzyrCsXUdAdqe9RGxc9Sa19BAO/TwwQSYABNg
AkyACfRfAl+lwe89KNx/KffxlEUvTadZ6O/gOhoBF69s4qPvE7B/7kDchhex/iE29vt+bnIKmAAT
YAJMgAn0XgK91uBvp6k3g2kqyrZt2+Tjjy++EBul81G170UUM4Z+ReBQ9n/1q/RwYpgAE2ACTIAJ
MIGOBEJDQ6XjDTfcALtdDOD23NFrDX6BQMzdP3/+fM/R4JiYABNgAkyACTABJsAEmEA3Ehg0aFA3
SvctulfP4b/99ttpUav6Qibf6rMrE2ACTIAJMAEmwASYABPoOwQGDBiAnl60e03fwcOaMgEmwASY
ABNgAkyACTABJnC5BNjgv1xi7J8JMAEmwASYABNgAkyACfQhAn3I4HfSAgfacD6og/wG67VTeSLe
rlpY0ZV6BVK8K3UOFE+Q92hnoeDzw8iou9JhjMNXGpw419CAc81dle++4vDt5gwelG8Buisx74oq
0GX66Hr5/P6q8tmnMlfv6GxGXd25q5dzWRIEQ88cF+1Wx4+nHzUKO5rPNaCh4RzafN32qYcTbW1t
Aeu1ne77Eue0t1HYK6tbQqZXMn1qd2WOapravCKwN5/DV9AUXFkSOBQTYAJMwA+BPmPwV+6ci/Dw
HWj2kxCjc+U28ptRZnS64vO2it9QvOEo014iW3d0JzYdrrkieV2pVyAF2ip3kM7fd+kcyG9P3KvI
CEf4+uDyo3LbNFfeebPvKl0D50Mz9qwIRRS9DCNq2LagyltX6WWv3IbQ8N9cfZz2SsSHhiOjLJja
4l/7LtPHfxTyTneVV2NZ6kSFLrxtx/4lw/BA/iddKLNzUd7tY9X+lbLdEm2X52cajmltmZBadXgT
pgwIx7CoUfQCmCgMCZ2CTYVVASNsrjyI+AGhGDJkCMJDB2Db0Y7tYXPZNoQPmYVyQ1xw1mHPyngq
40MobDimrNyJGoPdX7FtBcS8VvdnobsNO1eG1CkDSKYa54ZAbXBbBRZ6yFFlLtxW4Tdd5yr2Uxg1
TUPCQ7Fiw2HoXbb6oqcxbPpOGJPiVxDfYAJMgAn0UgJ9xuCX/EyDOrxN1hdXBzmaBl3n69Zlu0VM
XoaighJMCBdB7ShMfQy5/7xw2XJEALEZk2mQuiXTFQkIMlB46BDps/tjCk6h8UtLUPKjCUF5dmC4
i5En+6CCB+UpYD44z+C3+4DMknoojqcRGZTErvHkEAWX3rFw1VtnhYzA8wUFWDoh4qoU6zJ9OtGi
u8qrsSx1okKX3W6r2IXl+cn4w1OxXSYzaEGG9tHRdpYam3SU19aiurra8DmM27Vi0XB0A6IT1mJG
dgHqm1pha61HfuZ4rF0Qjf1VfsxbMqYTTUsxJLMITbZWlGTFYfWcJFS6DHen7EQMm7Ga1B4v2zxd
/7o/bkXiriEoqG5Ca20JTLsew89e1TsXbXj39X2IS89DaXkpSkqozSj9L0yRurZhT9IMbB2fhdpW
Gyx5KVifMAmFukWuR6B/h4/HehGePqXl5ZSmOHln5ndG6D48v501eG7acpxOz0ejzYba0hzsW5+A
7GNqBBOXZCLN8hi2ateegfmKCTABJtA3CPQtg19naq/Bzg07UVZRiNT4eMQvXIFthytdj4+FQWf5
Zzn2b1qJKfELkbrpIBoMz5btDWXYtHIhpkyJx8oN+1Gn/1hJudtw+PBOrCC5mwprYG+qwd8+bkYI
WWF1hduww0KyHzNh57EGVRvnORzelor4KVMQv+JZFFYZR1XtKNu/CQtJ1opnSe67xRge4J1ZzuZK
StdKxMs0rfRIU10hPVnYcxh7NqzwmaZzFYeRumIhsUjFb/KKSDfV6NeRGb+bKwvxLKU/XrLZ7x5l
k+nfhP0H9yB1oeC6EvvLtHRqAmqO7sFKuie4bjtY4WIubrfVHMOm1BXEgrhucnNtbahBzWfSmpVS
AqVTi0Z+GdkLB7960z2/eapKCi4fKP3b1myS7zlYO3stDlpp+kBdITZt209lifKY2B7VCotI6wbB
UCtDNbp9pJWho8coPyTDVByurEMVlR3hd0XqJpQ16AVOKuf+491DszfgoIg3fgoWirJVaSxbwLnK
w3iW8nxK/ArsOXwQm6hOqCOmF1Bj+RjubqkTlVR+RL7Fk19jXQmYF976uDUl4IHrIKhkiDhXyLKy
ApuorBhT3Vl5DVTOjGqIc3/lzttfA9URtdxTPqzcgKOuTJNCqG4J1vFYSPeM9ThQufOMow2Hfr4a
cVlPYqJ+o63Gr1zhJVA6A5dpPQJ/363A8NG4bexYTJw40fAZC9Xeb8BLc9YDaQXYuXI+RkZGICxi
JB54ZjeEffzBB/U+Bde8vRP5oJcAPhOPyLAI3P3UAZQUPI8RWi9VPJUTnYjkZNXINgo5X3WUOiEL
8W8TIxEx9m4kmIH8xhbVi70WBfSCkZ8snYfppim46+67cff0ieorBu0n8dt8IOfXyRgbEYaYJeuR
SaGy36o0inefh0QiVoSnz/TYEXg/tximtCI8Ez/S7cd45ryA60xmvPDkA7gpLAxjp5uRS+of/Msp
zddI/CQnAeuf/N3VP30zxsvnTIAJMIGeJKD00uPjjz9WrrvuOpd2luw4BaZspVW4tJYrCYBCnJTM
3HwlNz1BnudV26R/S7ZZXsel5SgFeVmKifzFZVtUWY0lCrXliik5SykpLVDSTCTHlKnUe8g1Kckp
yUpmQS1FlUWyTEopRWyrzpeyTOZ0paBchGhV6HeA7puV3KISJS/TS48cVY/MvCK6p54nZJerenT4
W6ukiDTFpSkFJSQrK1mmIceqp0mVraYpU+qRkGOVUmzVedJvQnquUpSvphdIUMolLK+IiJ1If3J2
gVJekqfQb66ChFzFIbwZuGYXlCj5ug4WVVB1foqMJy2nQCmheAR/V3oai6ROEFwNcoX25ZkmBeml
miKB01meFaeYMlVGRvZCN796B8pTitUSdD7YlNIcNY3J6dkyj1st2TKdMCUrKeYUpaRRURy1+dLN
lJytFJXkKymiDCFNqRUQDQyz8vKVrGQqt4KxKUXJzc9ReacUaCw8v1otgmmWWsaVRiVLyhVlq0jJ
SVPzP0fLC1eeUxkvKshW2SNOllOdVWZpk4zAmqeWJZFvRXnpUp8UKtuKEjgvPPXx1NWYTl910Kox
V+PMlHHGZaplwKW7n/IasJx5qaEEKneGsmSz5kgdzJl5VD4LlEyzlmdSnk3JFfU4IVMpKS9VclLE
vTilXBTeQOXOW5fWUpkPebUioDgCyKW7AdPZSZmW4g1/PNpHcrdki/KSrBRZLEp5ebn7Y6l11XVR
n7K08mQQFfC0PIvkUl1Id5XrZKVAa3dFQFtjtVJNxc5RLXgTQ0MbpOe7OTNHyc1S61lWKVUoOvQ6
JeuKqC9Ct6Jq7Z5o37T8kC4qV1OWv7ZUepJ/rLmi3aW2UM8S9y2/Z476ApmPah1RvTnq1TpfoKrr
NyzfYAJMgAkEQ0C0cbQtZzBeu8wPukxSFwsKaPDbVIM/pUCa6RRzo5JO8HQDR/74xWmdA7proR9+
mPPo51f/IUxR5G8UGWg2zXjLEr9MmtzkPPWHRiRJNfj0Hy6bkhPn7jzYqnPlD1OORTWshB408qSo
P0Tqudkgi570a/eEZK/DUa/k5+Qqmn1PP5wlslOTVa7KlmlKyJFpECGFYYzkfPnjLc9NuqGoKE2l
wsDSdfaMR//hSsktURptDqW13qqUW+tVI0BLf3qRzlX7YZUGeKuSTWk3pRepfkms+mNKLImj1A+Z
ik5CdI7SyaCrp3tGI17pJJ1Gv0b2gfRWjRs/earlSfD5YFW5W1QLQdXBpJToCdPZG9KqaIaezCuN
YZrG0KEZmnpRtQpDjPLKIM6VQUYDW4+3yGVgaMZjWpH0L8u03gEmF7VzpOU56SCNOVl2KN+o42A0
jiy5mUp2ERn8neSFUR+XkvqJlk7fdbBeSaN6YM5116PGItHRUDuhgctr4HKmR69/B1vuGi0FSk5e
qavs1hapdUR05KnGqJ2rlBzFWk8OjkbFUm6VHa9A5U7XQf9WeRmNS/9yKcc6qU/CYPdXpvUY3d+S
g6E86IMeRgNanutlT8s/vX1xSwp8ptY16uhTx8laXa5kJ1Nn3sfggrHu6hKbLGp7iTizYpYDJVCy
y9UCrpf3nJJqpbWV2kJt8CSfGhCbVYTTOrOaMJFefWBAl9/h21GtJFM5TMixdLjl14HaXXUQJJta
DsOh1alMrT023OFTJsAEmMBlE/gqDP6+OaWHSNEDa4wfpc9RDkMUDePrE0YdF8WT4zu0R9fkLl5o
ZmmAjb4gXbdiUjgt5KIFZ+Hj6FmBPNQ5P0Lut78Vpbl5fzlAooGL6vQUxwV1HkeiaZi20CwKa+m2
5cNTsLedQiGdx0wYJkLIY3wsmWHGeQ36DfEdMhJTJl7CL6arC8zCo2bTo3P3IdMUb1IfcZNzqEhT
aa1cSCZmXpiWTHelN3yoP/1FNHNp3m0yti6fjShanDZkwX/Ccs7hMW/cpoOk2GIXJsBSaEEbPVY/
XkxpWz8HodqCuOjlNNkdp/GpCpZ+k4e65IRNfADr1v0YI70npHeSThLo8wistygHfvL0cvOBHu+L
MgCHnihxMRyDDemQvDPvcc/vj5iA5eRLz1oRfsQNatm0iYxDHKK0ouqQ0oNbi0IBEeqaAqbmBTL+
JqcV1J8uhulRdxmPGP0diCrgnjglQoujCVUW4NFZk9VL+hvz42ewMn5sp2XOFcDPiUinzzpoPw+x
ZDVm4jBXyLCbRJkUIbS1LP7KazDlTEox/Ami3N0UMx0jGl51ld1xc0RNHaKV9Ej8aFcu4rYmInrU
EGoXovDyu7VwUpMQuNwZdJCnolJSGl2Z4F8uOk1ngDLtHa3Pa5qSY8oCdSzFoI778/5TarklHWVu
hBoKtianTUzBa/CcPuYZhZjSswS3TozFyqwcKt35+NNHgfyL0G3Ya6Zakl4Ex9G92Pu6gvLsBDw2
LVsujo2IWUk6vo+H756ICDG16Kn1sjxX/Uu0sZdk9Nob6encjkox/0fUjbYyWnTsXui7ybBQvdny
FnaRlJ8lxMjw8k8g/7QYeQq1u/sSslB/cCVucoeiuEZjvvGaz5kAE2ACfYxAnzX4JWeHaqSLc2mI
G+Hr1pfLTTWyHBfph5BmgNLoDWw2B9l1jSgtKsF94zWLTPg3yHUF9zgRJp/7yK+10QJPGxz0qbeU
ojT1HpoPOwIzyMtnn7l1dLScdwfyOrNX7ce42YkYn1qE2sZW0LAWzF5+XBaly11LE11biq2u2yEd
abhCUE8EN819FjZHK6otJci+rx6JFG+FNgddGAEjbnJZmaj9Sz5M86MRETYC36R7NFpGP8wOyc7W
aEVR0Xp8M5yQiQyg5LnINFdgm2Eev65AUOnUPRu/A+gdME8vMx+MUfo7F/ac5USNe/2C8zxOdPDs
zvcOt4JxkECpo+ECCjR8TF1Amj8kSmrU+DhYjla5dHCePwkLuRu8a7EMwXjqCbx7qtEVa8OxPdi0
vwxXnBcuSXRiqCvuOqhqcfGSm4Gul2An+fkrr52UM2PU4jzYcle5MxELVr+PvFIrGlsdaCrPotDS
5KVvOy4MjcW+Jhuaaq0oyEnD1scWYHc5GbEByp2I3+OQyhhdAsjtJJ0By7QxioDng0BV0/cRMRoL
qVysfuFtVxlSPTYgY9QkTHr+mO9w0tXQYQ2hQQNyC9MzOEAocSvt3qmuQQHTPQvIpRinqO0R66NW
0s44xmZ7ON0VLVHYOBN1KopRVa+XJxs+PU3dcNG/Cv8mDtDCXJq2hPLSciz7pt6OO/HewdU023It
7ogkf/rhx39zxU4Mo8XIw9MLYHv9qY4DFfZPfNRxXSh/MwEmwAR6P4G+afALi+Gyj4vyh2389IUU
ci1yxNZzIU5YXn0OM+bMxnv6b39AufSDQ0Zt8elKiHWXEdH3gB4ZY93ON2lRcAjaqo9ggWkG0krJ
E0ZhNk3Kz0jdgopztM91TSF+vtbid9Guw6Fa3HF334GxNLR07JUtEOPngQ81TaOn0pOD4kS8cqyO
7JM6vPSfj1Ew8TPc8bDX/gHR0eOw6y9NmBhzF+6JnUKeaKRT+8EWoVav+29U0T7ZDbRV3dpdwH2m
EeQ6Et9Lo0V2iS/gWJ0NIY467EqKxpw5b4GSjvGziCvtZLGLtuhzioXMm6dh9doPDCPUqi5Xlk6y
uwLoHThPLy8fVC07/jUWudFT5xOI5XiJ0mqnPdePvrRFPo25dTgZG0aPHcUE7RIxeRYSyMj5+Wba
HpD2Uxd5kZpB9ssd46TBNHnuT6QOGYcr0FBXhoxf+MvzSHznPmDf0pdQ0UCLkGl7w+epg5f7aSh1
UK+kzGlJCJTOsElYTmV//ewttECZ4qTF6JtXk34JP8FthChweQ1czrwBBl3uLooKPgNTp92KSGc1
dtPiWncdOYtfRUdj1At/pmp7K+69e4YaDdWJQOVO9eT+GzFePGU5bygC/uV2Wp+uqp0SOlFNtlTh
REUFKsoqUFZWRh/1u6ZZGM43YcUu6vTsWoolGw6iivbgP1dHmwasXAAqZsh79vtCSIcj5geinK3F
L/bTImxnG47t2ERlPwFxtxmtancwdzEJxTjCmjE7XS2HzTXYIcpsnFomrhvcgl20M45ow5xUpwq3
pVPpj8P0ySQ3bDJ+Qk3c8p+9RO2unXYB2ozVFuCZH5ioDY/ErbGxiBWf6bEYG6k/sbDh5FskflaM
66mo1MqXf9p56KlpIl3JeG7hOHxEzASvyhrq8BkOUYJuHUEFmA8mwASYQF8kcNkTj3ooQMc5/DSn
VZ+X77DKuZnu+afqPGV9fqWY32yc32nJobDmXG3+u0Mpz01TKK9cn/Q8q5oqH/Na1cV+7gWwllx1
sRmS82SYVmu+awGxkBlH84Bdcz9t1UqmNldVj8+1yLUDx3olWy4kVPUy0QJRM829TtAWpnVIk5gL
rq1LoBF3pSRbXZgpdTBrC9Xk/GTviGxKgbaAWNcpS8znFoeWfrJaXGzMmUWudQO04EGbs6vdp8V7
Ra4FisRVW/Cqyk1Q8q2qAp66B59OT/YB9Kb0+81Tma7LyAebRc7h1cuWOrc42bW2QnKi+PTFvWpa
TUp2ibbuwatsquEN5Ufkm16OVWGuv3IOuHEthiXPo2wlZBZoC3rVILVF6sJpoUMCra8Qc6nlnHTv
ckz5lmUoWzBnK2q2Bc4Lb31ciooTr3TKOelUbvQ6SCvcPeOkxeju6c+dlNeA5cxDC6FIUOVOrClJ
MNT55DS1HuuLoBtLc7SFz2rZTkjL09ZZBCp3Xrpoc8bd6xpoVY9fuRQ2YDo7KdNeUcu59YZy5XcO
PzHQ1zoJEdaCLLneQ28LRBnKLdXX8HhFol0ay53Y0CBHW3hr9K2Xe20pjHqr1erZHprSlNJGsdJd
HK1KQZa6sYGqS5yS51obRbncWCrbfF3PNL3NVgP7+KuuoXKVRx8+dKfWcm1hvqF8iHjiDIuCG0vS
qX6ZFauurh6Yv5kAE2ACV0BAtDE9vWh3gNCTIu51x8mTJ3H77bejvb29e3Sj0almGuAMj6Dt6PRB
oSBjctIoE0Jov3RXOHpDoyqMpr64HF3S7G3NcITSVnRhLie/J9IvPYiPCMaztxSaftDsCEVkEGHl
2y5pmnq42I5Pl2OvQHz4NCyztGLlZDHrlvTwmZ42uR4ikth1OIQOJDeC5HYk4fZ9pen0qbcutpM8
vZx80EUG/A4yrQFldHpTL1ue5afm8AZsqroDWc/Ml/l37tgGRM3+GFbHXtzqB7x4S6mDJv14l60r
zYtOVScP/uKUYTspryKsWEnhs5x5Rx5UXtipnhIBv3VeZx3RodwHLHcGXWoOrsCkDXeglebKu2uH
f7kiaMB0dlKmDVFfxSnp1yZIq+2hn+LjKZ/e5NxMYcIjI93th6cPv1dqmaA2wkf7oXJ2+pGrc/Ss
C34j6rIbduyJD8frP7Hi9Ydv7TKpLIgJMIGvLwHxgkEy+OmFh6N6DMLX1+DvMcR9KCIy+KeQwb+8
tAnPTPf9iL4PpaZfq+qsO4xQseA8IRlp488iYytNrMgux+srY/t1unt/4mqwcsAkTOQ61PuzKkgN
2yp3YojpeMDOdJCi2BsTYAJMQBL4Kgz+oAZzOH++JgTCbsOB0hLAtfDta5LuPpjMkLEPoLXegreP
lNOs8YEosmQhPmZsH0xJf1N5Iv6PtQBvNDRRwrjT3B9yt+mz4SiwbvP75Kw/pJHTwASYQP8n0GtH
+N977z0sWLAAkyZNklvK9f+s4BQyASbABJgAE2ACTIAJ9GcCYnRfTFs/ceKEfAt6T6W1147wCyDN
zc1ITEyULBwO934PPQWH42ECTIAJMAEmwASYABNgAl1BIFTbEvHf//3fe3wwu9ca/IMHD8a1116L
73//+xg4cCAuXVJfvtIVwFkGE2ACTIAJMAEmwASYABPoSQLXXHMNvvzySxlleLjfN6V0i0p9cx/+
bkHBQpkAE2ACTIAJMAEmwASYQP8jwAZ//8tTThETYAJMgAkwASbABJgAE3AR6LVTelwa6ie077Nd
f7O6dAtBmI894nXvfr+d7Th//nN6e+P1GD50sPTmbD+P8587yWk4hg7uASROJ6WF4gvTdsDXro06
h9C9HtDEGOXlnRPHs4IjaXn98OHoCWyXp6DqW7wzwUnvTNCLirw2CAqhlymIj+dB+UOFravywFsH
z7h8XTlx/uy/EDJ0BIbqivvy1sVuTqpjTnptsqte+SiXapQGP7oOV1IeKL72i19gEE3f884BVayT
3sNxEdcOGuzKPz06O72f4wtci8GDXW+R0G918k15SzIp0g4yOwkY5G1V/hfXDsJgQ97ZW86jxTkY
Nw+/XH2DjJa9MQEmwASYABMIQKCPjPB/jr3JEzBhgvEzBiNHzsFLx2sDJM/rVksFnhkzGTFTpyIm
ejIq6J1eZ8t2YMzkGEwlt+jJu9DiFaTrL9vxWuoYSotZxg+040CyuDambQLGjByJZ/aWgV7x9RUe
dlQc2IIDlZ5Uqo/swBziKJhNnRqDyWOWXF4+BJGi89YjyNhy5KrSb69+DWOIq/mVShlju3WvvDay
HjOGytGSX6LivLs3WX0gVebHK17pDkLtDl7s1Qc8dOjgwYdDS8UuKqN3ovCMWycf3rrYqR2/e0iU
weSA5VKyu+8Vj3pyJeXB+tYWjBwzAZMnT6ayvgrFtR1fsHd8y0Py/stWd/lztlixZdUcTKBwkydP
wJxHtqCyxc3JeuAZahdGGj6rUKmJdp6vwC/nUF2jsBPGjMSO4lq/DEVZMcqZM2eOvF61Vy1LvgKe
LTuAR0aq8idPGINVW97CWU21M4VrMDXmPpS5k+JLBLsxASbABJgAE+gWAn3E4AftNK4ei5NWYdWq
VUgyzycHK9Y9mK4ZKJ3zcZ77EPvIW3RSJl577U2MGkRvk/34bzLgqi25eLtkMYZ2LuYqfVyLS9IA
GULvPPU8FpuTkJREH5k2YN/aRci1djSEPEN131X1gcdxf+pmXAohUNpxpjgDsx/eSOTpRfNrNmBN
ksiHE5QPM3Gguot0dVqxZs7D2P5OsxbrlX194RBPIIAhPoKbV62R5WjxzGhSfzfuX3OIul7q4ejC
9eFfaMJ86eBDLXI6j9w1G4GZGzB/Us+OBg/UlPRbLkXZTDLDfP9o14j8lZSHlgrqMCZtpoq4GGvW
LKY0H8LyR//g4g9nC4p3rMKDm09IRO7SRzX+4GZsPmTF/KTn8Nyq+bAWbsbzB0VpFIcdVcdFDSfR
0dHyIy/kn3YcWnM/dpPX+WYzZpLbxuWPovi824fx7NrwYaCSIWXMpDJitapxtLtSbvRN585q/Nei
VBTSqXnNczBTBIc2J+HlY2elx0nzn6Q4rXg2t8wrIF8yASbABJgAE+h+Ar6fpHd/vFcYw2Ksfj4N
k2RoJ277dAxSC+vwaTMNo9GckjPH92L3sTZ6+WgyYoeL6wPY+38bMCPxf+OukL9hS1a+Gu8n1ai9
cBdGlR5AVr74iQYaTp3ChXvvkufttcexa8cBVH7ajtHfXYzHH7kPN2u2l4hjr2Ugpo39HG8cegfR
K9bj8bhxCBQG9jN47b93443KTxATF4d/1slovP5Q2jY9r6UNeOhbj2DOukL849Q5sjrE1CMnrEd+
h5xXi/EpbsT3HkrET+dGa+aHHcf3/jfevTQOt49owh9IL4z+Hh5/+qeIHqpnMY3Wv5WH/MK/4hOy
bGPmLcMjy2apHRx7LQ789+/QMOgWklyNYuoDPfT4PfjTLpVNcU4GsCARK+4Gdi/fLvXe8GYlHo0d
TueP4p6bH8H9Gwtx6u//BL04QU1Xey1ee+V3OGo9SdejEU+dmUXTb5H37GeO47/3HqO3V87AiH/9
GYfeacLomHg8vmoRbg6htLySIw0nnEjF+r2jkL5iFj71w53A+41HVcTH3/kvYlPaIvWG8360j5mH
wtbPibD/47y1GL99tQCnPrEhfPKdWPHIUsTohYKCnal4C7tzCiXb0d+NR+JPF2GcOmNMEyryoR1H
XtqF8kY7Jsx7BMtib+4QYUvlH7GRbMvFW+7ROp/tqHzrVewtfAeftg/Gjd5xO8/irV07cOhvn2Dw
jTFY9ngyZrkiDlRmOkTtx8GzXHp4ctYGXx5cASl/X90or158aQsWjbuImd+ejwtDvwXVsBdPvKKp
XrsCGE7s+Oc/xI2ZeDLtccSGWfG37YUo/Ps/yNSPQZjzX6g6RLej1+ClPyQjkjqqril69lN4WwSN
fg7bNz2Oz/8fe28DVlWV/Y9/mlAhA0cpM1/xrcIGSJ3UyCxwfkqjhY6mzgil+YB9NVNmxoi+YhM6
OcD/N4iMDspj0AhOheTg2HDtmSvzQ3PQBprura4lIJhQ4gsJIVe5zfmvvfc5954L916uiqbN3g/c
c85+WXutz177nLX3WXufn/TF2EVZeOfvFkTMZ6a9c/ANmgFjQ4OIbK3Es6NnwkB0U37eOS/LZD1Z
gxo6hq8oQFpCBGxPBCJ/SgIqLPVABLVznzFYSGOb5evzYX5mIkKcdENUI38lAhIBiYBEQCJwrRDQ
rMFrRb+b6RaRIT4B4/1pHvSMGWRj0hN2DsIGCzGaPitFDhkAd01fSAZ/HzR9tg9ZOQb0n/ssJvgc
R1aRmDG0GHKQ0DwUxdHvQ41CUVYyHpi5AONRiifDF/IZbDazl7M+DjlFa2A2LgMzb5uOlyKLVyxE
i5mzFrZTnsqcx45lE5DIjY1w1CUmctqdgfkSFQfNaKNXDBfOVKFoJysADB16Jz9W7X4ZU5fn03kw
woMNSF6Uj39nGJHFjZVvcbyYZj6FeDQrSTOhBgOKck7g0IlXEURGdGlGDBZqGYiKwVCE9H2pML8e
i8BvW7AvPUsY2by2YPxi8VDki0lNGPJz0Hv8AsRetOELlk6zz3O5sc8zY9yy19GwTJzzX2sVXhk9
BTn8ghlIxEtRDv65uQxps0fh26bPkJ7FBg7sn6VTRcTPF3fch9djh+J4CZNThPzS43iFDH5XuKOL
ejQanY51+7F9xyV6a/QNTh4p4XLPiZ7g9u3OefMOGiAlCjJcnCLkZxWj4MM3yZbzwamDGZgwL52n
M+wZtjlFX3Kd0eboe9/ejIPbV2ARDeIYfh+uJiPQRWj4dynFBuOJx4J46qnSTZgeRzhFxWDFkDPI
ykqkus3UrmnUrmexfcFYJLN2D6cpZZrtLspPR96RGkwb7AvPOsPJe/FThNc2jMCP+whz/OLFi7g/
6llMCyZFvdjinT441fItzp0REcuXTMdymjkPj1mH370ywzF33jsK695+GWOPZ2JmIrPgteCL8T9d
Q6PO9Vi97EXqqxW87VY/+WNwnFtPUQwFSzr1EdEeMal78VrsONi+OiH0exjdPCj0GTKCH1tp7U5X
4eC21bxsxh/iod5qOhXxDZqGXdoAgYaO5X/dx/PcHai92/HFg0/E0bR/Do7U/A4h0uLvhKGMkAhI
BCQCEoFrh8BN49KjQZC/PhEJZDSvT1eNwgAyRNRntk9PMW3WS/VJ0K5Z2d7BsThGBi4L4Wv2omHX
EjwY+zr2pUZRTBT2HmvAEnoIH3vvHW6Qryg4gl279qFgBVlwlvX4m+pa4wNRx5x1e+lLaRa8Mj3I
c5lTlcjjxv5qHDHugrGmDHHMaOwUDiFh3nRMnz4dsxcu58Z2zJoCzOWGwUkUcmM/HG9/aMSuPUbE
UPmihDdRq8ou3DGCubFnNNYgh1eSAyPzfz7/ETZzYz8ORpKzocGM1DnMMk0Uct1K+HB+grHZaMYx
yzt47JElhM0cHruGZvP5wELLF9DTYZx1kgOoLdnGjX0221nTYMSJIwXchSJ/eSYsVirg01OUCqeB
FEsnlxoGiaHURHPgvRH7xj5qEQrhqbDQgITx5gr3LuthNFwFSxGSExOQmJhsHwTafcY65W/FnleF
sZ+690M0GBtQlkOGG7kxrd9ZTkeatX89nY40ODxUA6PRgs1xcxDzk0C0MVnVUJQwG/OYsY8VOEK6
R+MEF8GGr06y1z/DcPftIkOjhZuwCL7jXkxf8DxyMnKw79CvMICSrZa/CWM/ZjO5uuyCefcaTvNN
GiTRO4cudcYFAy6jDFnpWL9+Pf9PT0/HIkO1yOelPnQkqrY+0Hcy1q2JwaH8ZEx5Zjs5M7HQG/Oz
XseSyaPg17EgXfsG3s1jLYZ85BtooEgh4DZ+QGvD59QqFKJWIycnFUzF8xNnoqjKim9bzolM9l+9
35YNJy1mmGnwYTabcbJV7VQs7/nD2JhO9czZjGj+po1FeshPqZU7EsgdibV1DFZGj2IFeLhjyBh+
bDxzda5qKjl5kAhIBCQCEgGJgNcI3GQGfxQKDpnJn5Yezh+WISOOzWomI+nP4sHfpdSqkRWgjQio
gBql+tNb8UXVp5xM1sIJtEhvKBZmCdotbTojgHJMCL+XdgjpQ55Ensu0NtaItwVzwjGYUfYdjDHD
eBUdfsKxee8+bF5BMvEwh9xGIsSsc2sjmGMMMzLnjaUFiaOn8rUIwEGcog1HHGE8Rgxgc52+GDFG
GBcsrfXEx9wQCl7xf4R3EL2reGiySL9EO7E4wniEjKYdd/r04bho2PTqoZ59y8xbCnUtTotpbWct
KD1swXnVwNUoRs96iM+8+gx+CE9xC74VbURDC1HREfytic+AEeDcNF8SYze7IeloH62MA3f7OA9d
1aOVtR+DV6CMjDsLGXdHjHlgw5qihOl4180iWW0wdc+9d3ESoyY9Jt5LvP8ZX7wqDNhhGMqx74PZ
r2aRy9B80CR75xDs22nthiNTK07SIFIfRv80ng9+LGQUz5w6E3EJccj48yHeDnYo85cjmBaqhsxe
z4sae9zGXAAAQABJREFUjhylnWi81Rl9ba7Oo/D2EQsf3DI/dvZ/7H9CRUYv9aEjVc3UzvhdMpYs
S0EG041D76NOW0TRsYD9uhXvvLScrsKRR4OrEx++zbFJnrkTpyiWDeobaJa94fUEzJgRi189H8NL
7vt/x3Cr3+12KuLEPuwgpTbhmak02KaFuWzAXfiZgxHLnnzed1bPnyLeIrDCbvPbcHALubfxtxLh
KDiSAv0yjG8hJK+wNHbgRV5KBCQCEgGJgETg2iKg2XTXtpZupD5gMG2dybjuE4iHJ9xPr/cPofmS
ZmJqFQn3A5tYHatFenH0xd1DmTVuIR/qvfjNT/qjwfQRqi7chpCRbJ7ZERyGsucytzYN4IUO7f8Y
rcsm0vwlbQva7KDjOAvAqDEhCBn3Bi4dG00+zEWYTq5AbIa7T69+GE0ZDWTe5JWlIMynBR99eBT4
4TCMEqKqZM6gmQ0ACB/bN6rR0k6G0KARwkCt+Ixqn8xnzM+e/VKUoXR7iArB3S40oqe2aLeXP3nj
U6A3Hn86+CQSJg+mCyu9CZiKuHw2IU9vH2KD0f6N8NkwH/2KJr6DKM9X+NRAh47B3m5q+5H3g3P1
PWnjRefgwB3e1+NMgibQR2AwDWqYPd4n8GEavJHBT1PDdY2E2WByVXEKNlzi7dUX7VZKIDVobRCD
OBpdkd+5lt6MCwx7Ilq5YwOKzwzG3Kd/DuE4QvHhcVh9/ydIz6HZ8reeoDcmo5xqERe0xamzmtEs
+His3l2A2PYe+PqzD/DXnekwZC1HxKxp+JlKIThuM7YvC4et/lNU1F3AoFFh8Oll81JnXLDRISpw
ABvYdohkl17qg3PJW+0yXmpn7e6KsHMJpyvuIUO7CQWxbWtD8GNqOwNNAtQzdf9sN7a8+U88EPu/
mB3SBzZ1ZDF6SF8aZ4/igwNDcwsn1/oV87in5mRvUm71x6LVq3GmF3Wm8xfxQD+tU7XCVFpEuaLw
6NhAnp//3NrPZX7mQjWPu/vFYLc5DRN1RVi5W9XXSCPu5kI46MkziYBEQCIgEZAIXGMELvNpe425
6ZK8Ac8vWIEx9Fa/tfVT8pUWs6H30wNdBGHk7sz4IwY80Qtx3IWiS6JOGfqPEKb1p/v2oaL/ffgr
udewR37OkRMY1dEWVEt6LBMURk4c5K1+KBkvZfTEA18XYz33O3CqVlzwKVtyaUjfjULDbBwil5vf
vxeBV6cNQCifhjbgr+89AQQexaKELDKm2dqCcTpCBsx8ZgMyooFtXPZw/GgYMR04Gj+hXBbi4ZlX
LiL6hxYkchefOQi/l9K1mVodJXbaQ50EzUtfi0sL4rFk2igse5vcJchfPX3eBJhpx6Q7vsgi1wqW
Oxyrn2SOOcDoCMasAfnLl6DvuUXAv/OEP3/cAoSSQev0UoIV0AIZ1tz0/7ZdfZNQiA3b++PFJRFa
DqfjFddj2EYLhA/ygc+XnxbhEFejKExiWHQKfXD/41E0A23AvHkrsG5RMN5PXM9zrVkwiez7PnhA
TZ+95BWkPu6LxGRqGzISF/xPrJ1aVHQsEmLbYc6ZSm8TXkNM1OuY2Km63rhvAtVVRAvRmW85Wdn/
/G0IFuYzLxVadxL1IELeJ2SJ37vIKO3d5wFhxOYUwDjhh+h5ZDMSaQA8h9ZKTA4Z7KXO2Fm0n+jH
gKwdtT4nMrSi1e9hpLy2hPzZg7zSBzthfuKL8J9RjyjKQuLzZGTP7Afu/RL8YwzqONhxLkhXt6Lf
HSwyH6+9ci8e9v236EtR0zGG6VWPc8jJJ7Dy23AulbUTnVMIHTOABmL+iOCDg/V46ZVT+DInh1KC
8bPHqL/TfvmxCQk8r/PPN2hgHlbhEbhXz5tvUOf8Zw9iKXe7YxTysXV1DV6uO4Tx8UakqYuCz3wh
3h7eO4puYDJIBCQCEgGJgETgOiLgcx3r6paqLIeKuIsMJxYcjrhFq5E0bbC4fDIBceQwn0OLF+MM
4bTt4hxa5FjUyT2bz+rZuWFPcjFQYFF3RSRgb4aVtqPMIl9lFhOM1XlbMaPDar2euo81eS4zGC8c
ysOx8EW0TV8iioJp8WVME7KELcIqUIPOogiciI15KzCBdhHJWbQJC2rSMIMM9HW0I07yejEAAdF5
+41nuUuMRoEZmTF3/53WODALNpgWPm5UZxkHI8m8F7QHIi1iXi/8nHn5FHUDID8xc+8gxM+CHvsZ
mfFkEJO/dMnDsVQ74TM5AUfevgOr5iXCkMMMWwrhMchb9792A9Zn8Awc2Z2KVbMTkZWcyLNErdiM
Daun8flcu8Gv86rgme5W1wb0HgY2ZjDQtHtOcgDmLoiwzwPrcb/cem7VRjCkQQba2lELwbTw+5ev
/AbjdE3A0jT2xi3JQN7FO7CIdlgR4gRjDenEMnXhcsiSdGwmL43lWTlI5IO5KGTsTQd57zg061Ib
UQzBWvL/N8TlIJ22Z9xFb3w6hn6DxYCz/NOvaEHwYES8UoY1bS/RmhUqly5yr8jYjSl8EUAIMoxk
uE6NQ3Icr5heJGTgN7QwmgXvdEbQdPz2hl+H1ypOfU7N+PwrzOD3Th8ctMUZ6y+71zVhdnI+mHs8
0+XdO5/FXR0zqteONvfFjFeMWH3meXpTkkxDEQr05mRv+hz+tsY3ZCF2p57A7MQcezul7t6p9t0+
+Pnm3TD/YjbyubFP3SFnK1907aZaarxG1DD+Ym7v9KapY5nzdZ857kuUaDCI9himWxRc+8lBSgnH
vQM7KFpHYvJaIiARkAhIBCQC3YzALQqFbqbZLeSOHTuGsLAwVFdXo2fPnrh0SX0/3yV1+jonvZa/
lb7eqfvQZZelOmawWWkmkyxT9hVQb+l4LkNfFT1PXxWlr/uSnXTFwdp6nmbIfWi7Qb3RQFsZPktu
QMhAzevz2esPt18SZV8oZQa3c3kP7Lj9GirhzD59TG8H3H/tlH0plQ2melOey5ea8erdF1Gvrh4P
0jsnMSzYl19p7YYrnbARv2y9Z++raWPaz/3FoVOQH1eAE686BjpCt2wEh6u6rThPOu/Ti3B2wZhr
nXEW7eqvvNEH51q0/nIleIkv7Yr+2UmzqO+epx2lXGNFfJ5nekVuSjQgu37hJDYMnICsmBzUpM3g
A5TrV7esSSIgEZAISARuBAR+8IMf4D//+Q//kOPJkycxaNCg68ZWp2fldav5mlVE+7nY956/8kp8
fHujz2UaBJ7L+BJfV86PVtKXGXzahe74DXM9sHzTpTHvywYwunJdnvoQ3y61hHB2YVw606M8VyE0
49W7cHX1eFcH5WJYeFAKH+L3qpvYZxQW085R+eQ2VP5CBCYHCu660q0+HvhypzNey+1VRm/0wZmQ
Z5mc83a88qgbHvsu8UnrN653OHu4kG9Cm7r4scvrf9ebUVmfREAiIBGQCHwvEXBpyn0vJf1eC9UL
0zfuxo/IKcJbE/l7DcdNLlzwUym05uF93EZvFPgq4JtcHsk+rU3pcQ9Sc/biKfvWnhIViYBEQCIg
EZAIXD8EbliDv62tDd9++y3ta26ED/nL25y2j7x+AN1cNX2D/2esvrlYlty6RMB34B1o+vh9GD92
mSwjbzoEfDHQtwnv0/1MBomAREAiIBH470TglltugeZJzz5keT3DDWvwMwM/ICAA7EM/MkgEJAIS
AYmAREAiIBGQCEgEvg8IBAYG8knt6ynLDWvw+/v748KFC/joo4+uJx6yLomAREAiIBGQCEgEJAIS
AYnANUOAzfTfdttt14y+K8I32Zd2XYkg4yQCEgGJgERAIiARkAhIBCQCEgF3CEiD3x0yMl4iIBGQ
CEgEJAISAYmAREAi8D1A4CYy+G2wsn3fvQqU19usXdJj9bLdUrojdCdfnvjpTp491eNlGu024317
6DG6VnLo63Algw2nGxpwuqm72t1VHa7jbN4D5ZqAFkuYd0cX6DZ+NL5cHr+rdnbJzNVH2ppQV3f6
6ulcFgWGoXOLs/tW53/nPKIKK5pON6Ch4TRaXCW75MOGlpYWj/3aSumuyNmsLVT2yvoWo9lBTJfc
XVmkkKmlQwXWptP4Dm4FVyaCLCURkAhIBNwgcNMY/Oat0+DntwVNbgTRR5s3Ud4Nh/VRV3zeUvl7
qtcPh1sEibr9W5G258p2wulOvjwJ1GLeQjz/1M6zp7zXI61ygx/81nrXHuZN4+1t1xH77uLVczs0
IS+2B/rTxzD699vklb51F19W8yb08Pv91ddpNSOyhx82HPamt7jnvtv4cV8FT7lW+qrXpS5Y6MZk
K3bO7Ycni7/oRppdk+p4fzy6cym/b7F7l/P/eBxQ72WM6tE9aQi7xQ/9+g+iD8D0R0CPMKQZjnqs
sMm8C5G39OCbKvj1uAWb9ne+HzYd3gS/gMmo0NUFWx3ylkaSjgdQWT+ELd2Kap3dX7kpFsyv1fE/
y3EPO30YCWG3EM0AsDrXeboHt1RilhMdQXPWpkq3cp2u3EllhEwBfj0Qu24PtCFbvfGX6DdxK/Si
uCUkEyQCEgGJwA2KwE1j8HP8Qnt59ZXadsoc2qt7FkP4j54PY0kZRvgxDqwwJDyHgi8vcHYu96cH
FQjtxX6vbfDrEcAruPY1eSfH8KfKUPbzEV5lbkegHSNn7L0q7lUmj+1gO4k/5QOpZfVQ2n+Jvl5R
7J5M7Uxx6bNMV72S3mcAXi0pwVMj/K+KsW7jpwsurpW+6nWpCxa6LbmlchsWFsfjnRfGdRtNrwnp
7o/tLafoZpOCitpaVFVV6f734AFVLRr2r0NwdCImZZeg/lwz2prrUZw6HImPB2PnUTfmLRnTi0Of
QkCqEefamlGWGYGVU+NgthvuNj6I6DdpJbE9HPp7UN3fNmLxtgCUVJ1Dc20ZQrc9h1+9qQ0uWvDB
X/IRkVKI8opylJXRPaP8/yKM89qCvLhJ2Dg8E7XNbTAVrsLa6FEwaBZ5R4D8hmMtK0//5RUVJFME
zxH+owEdc4prWzXWjF+I4ynFaKTtoGvLc5G/NhrZB0QFI+emIsn0HDaq166JyFiJgERAInBjI3Bz
GfwaltZqbF23FYcrDUiIjETkrFhs2mO2vz5mDxnTlxXYmbYUYZGzkJC2Cw26d8vWhsNIWzoLYWGR
WLpuJ+q0hxWnuwl79mxFLNFNM1TDeq4a//q8ib4FANQZNmGLiWg/F4qtBxoEN7bT2LMpAZFhYYiM
fRmGo/pZVSsO70zDLKIV+zLR/aAUgR4+c2trMpNcSxHJZVrqJFOdgd4s5O1B3rpYlzKdrtyDhNhZ
hEUCfl/I9voWRr8Gmf7YZDbgZZI/kmOz0zHLxuVPw85deUiYxXBdip2HVTlVAtX787CU0hium3ZV
2jFnyS3VB5CWEEtYEK5pDlybG6pR/TW3ZjkVT3Kq1fCDHnsW4ZZvSnPbpoKSd+1A8m9anYZSKpM4
JRG7LOQ+UGdA2qadpEvUxoTtflVZmKzrGIaqDlVr9pGqQ/sPUHtwDBOwx1yHo6Q7LG9sQhoON2gK
x5lz/OitIxZrbcAuVm9kGGYx3TLrdQs4bd6Dl6nNwyJjkbdnF9KoT4gZ0wuoNn0Ox7DUBjPpD2u3
SMqr7yse26IjPw5OiTfPfZA+NcXrjOW6Eos00hW91F3pqyc907PBzt3pXcd8DdRHhN5TOyxdh/32
RuNEqG8xrCMxi9L0/diT3jnX0YKiX69ERObzGKkltFS7pcuyeJLTs05rFbg7NgOBQzBm2DCMHDlS
9z8Mwt5vwPapa4GkEmxdGoWBff3h6z8QT76YA2Yff/xxvUvC1fu2ohj0YbgXI9HX1x+PvPAWykpe
xQB1lMreyrFBRHy8MLL1RM4e3U+DkFn4yci+8B/2CKJjgOLG8yKLtRYl1PGefmo6JoaG4aFHHsEj
E0eKrxJbj+FPxUDu7+IxzN8XIXPXIpVKZb9r1pN3nPv0xThWnv4njhuAjwpKEZpkxIuRAx159Ge2
C7gtNAZ/eP5J3Onri2ETY1BA7O/6Z42aayCezo3G2uf/fPVv3/T1ynOJgERAInA9EaAPANyQ4fPP
P1doyyI7b6bsCAWh2Uozi2muUKIBhXBSUguKlYKUaH5eWNXG85uyY/h1RFKuUlKYqYRSvohsk6DV
WKbQvVwJjc9UyspLlKRQohOaqtQ70Q1V4lfFK6kltVRVJtEKVcqp4raqYk4rNCZFKalgJZoVeg5Q
eoxSYCxTClM78JEr+EgtNFKaOI/OrhB8dPqtVVYxmSKSlJIyopUZz2XItWgyCdpCplTOR3SuhVNp
qyrkeaNTChRjsZAXiFYqOFgdKiLsmPzx2SVKRVmhQs9cBdEFSjvLpsM1u6RMKdZ4MAlCVcWreD1J
uSVKGdXD8LfL02jkPIHhqqPLuK9IDVWQUq4y4lnOiswIJTRVYKTHnvHmlm9PbUq1mrxuhzalPFfI
GJ+Szdu42ZTN5URovLIqZpVS1qgo7bXFPC40PlsxlhUrq5gOIUmpZSDqMMwsLFYy40lvGcahq5SC
4lyB96oSFQvnQ7OJYZopdFxpVDI5XaZbRiU3SbR/rtoW9jYnHTeWZAvsEcH1VMMqtfwcr8BSKHSJ
tZuxMIXzs4p0W1E8t4UzP8686uV01QctKuaizlReZ0Sq0AE772701aOedWBD8aR3Ol1qs+RyHmJS
C0k/S5TUGLXNOL02pYD14+hUpayiXMldxdIilAqmvJ70riMvzeW8HQprWUEWPNClVI9ydqHTnLzu
x+n+SPGmbKYv8YrRZFIqKioc/6Zae19n/SlT1ScdKY+nFZlEl/pCil2v45US9b7LCrY1VilVpHbt
VQxvwlB3D9LaPSY1VynIFP0ss5w6FAWtT/G+wvoL481Ypaax+5vaHjxG4Bqa6e5eyjPxH0sBu+/S
vVBrEkeS27P2+hLejqKPiGzt9aLPlwh23ZaVCRIBiYBEwBsE2D3u5MmT3mTttjzsi183ZPBo8LcJ
g39VCTfTif9GJYXA0wwc/vCLUAcHlGqiBz9iCunxqz0IVyn8GUUGWptqvGWyJ5NKN75QPGgYMMLg
0x5cbUpuhGPw0FZVwB9MuSZhWDE+aOZJEQ8icR6jo0Vv+tU0RrlDaK9XinMLFNW+pwdnGR/UZFYI
2lym6FwuAyvJDGPEF/OHNz8P1QxFRTlXzgwsjWfnerQH16qCMqWxrV1prrcoFZZ6YQSo8qcYNVzV
Bys3wJuVbJI9NMUo8hJZ8TAlLAlHzh9SFQ0JNjhKIYOuntL0RrzShZz6vHrsPfEtjBs3baq2ifft
YBG4m4SFIHgIVco0wTTsdbIqqqHH20rFMEnFsF01NDVVtTBDjNpKR87eQHoDW6vXaDcwVOMxycjz
c53WBsAUIwZHapsTD9yY47pD7UYDB71xZCpIVbKNZPB30RZ6fuxMaieqnK77YL2SRP0gpsDRjxqN
bKAhBqGe9dWznmnVa0dv9a7RVKLkFpbbdbfWKPoIG8hTjxGDq1W5iqWeItobFVOFhQ+8POmdxoN2
FHjpjUv3dKnFuuhPzGB3p9NajY4jx0GnD9qkh96A5uea7qntp91fHJQ8n4m+RgN9GjhZqiqU7Hga
zLuYXND3XY3iOZO4XyIiRonhEyVQsiuEgmv6nltWpTQ3071QnTwpphtIm4WVUwezKjEmrzYxoNHv
dGyvUuJJD6NzTZ2S3EbQfVdMgmTTnUMX1D6Vqt6PdSnyVCIgEZAIXDYC34XBf3O69BBS9MIawwdp
Psq+6E/T+JrDaDt9rTh01oPqq2uK70X/pga00QE8diNG+dFCLlr85RdE7wp4ED4/jO799/ZX4zoe
2sE/hHxRuKe0XxB+HItD+6kLzfojkYqYPqmBtaUGBjoPGdHPTmT4ODLD9H4N9hQ68RmIsJGX8NJE
scDMr/8UenXuCFymyFDxipuiezCZymv5QjLmeRE6d6JdXr8+7vhn1Uwjv9t4bFw4Bf1pcVrA47+F
6XS7k994mwYk1TZuVjRMBhNa6LX6wVKSbe1U9FAXxAUvJGd3HMcZASw9k/vY6fiOfBLJyb/AwI4O
6V3ISQRdBs98Mz1w06aX2w70ep/pANo1odhFIHrr5OB4pz7q8O/3H4GFlEtrWlZ+wA+FbraxhkME
+quq2s6pe7cWhQqih90FTLQFNvyLuxXUHy9F6BKHjvsP+RFYF3A4TrHSLJzDUROwZPJocUm/Ib94
EUsjh3Wpc/YCbk6YnC77oPUs2JLVkJH97CV972Q6yUqIbupWX73RM05F9+OF3t0ZMhEDGt60627Q
VNZTA1RN74ufbytAxMbFCB4UQPeF/nj9g1rQx7696i8OTlinJBntjeCeLrqU04NOOyr0cEYuOaGZ
oIEl/4w7PY3E8aMXhN4Sj7w1eugUW6XWwlzwGpzdx5wrYi49c3HfyHFYmplL2l2Mv3/qKT8r3YId
MdRLUoxo378DO/6ioCI7Gs+Nz+aLY/1DlhJ/H2HRIyPhz1yLXljL9fnoV+wee4lX34N1PB6sMDP/
H9Y3Wg7TomPHQt803UL1JtO72EZUfhUdopbrIj8tRg6j+25+dCbqdy3FnY5SVNcQROmv5blEQCIg
EbjJELhpDX6Oc7sw0tk5N8T14GvWlz1OGFntF+lBSB6gNHuDtrZ2susaUW4sw4zhqkXG8uvo2os7
ndifPDy2uLaNFni2oZ3+603lKE94lPxhB2ASpX79tYPH9vNnnajoL6xHdyJoymIMTzCitrEZNK2F
GH0Gdu5OJkoylVrsyT6d0XBQoi3x7pz2Mtram1FlKkP2jHospnorVR90ZgQMuNNuZaL2n8UIjQqG
v+8A3ENpNFtGD+Z2jl1bowVG41rc40eQsQYg8ezINFVik86PX2PAKzm1zPqjB749tulltoO+Snfn
zJ4zHap2rF+wncWhTpkd7d4pyZsIDigNNOyAAg2f0xCQ/IeYpvYfHgHT/qN2Hmxnj8FE8brsai0B
GE4jgQ9qGu21NhzIQ9rOw7jitrBTohNdX3H0QcHFxUsODDS+GHYcP3f62oWe6atm597qnXnrYjy+
8iMUllvQ2NyOcxWZVJqbvHS04kKfccg/14ZztRaU5CZh43OPI6eCjFgPesfqdwqcGX2MB7pdyOlR
p/VVeDzvBeqaroP/EMwivVj5h312HRIZG7Bh0CiMevWA63I8Vjdg9aFJA4rz1RrYQymWlPTYWPuk
QOijj1NMKWro3sPWRy2lnXH0t7hASmV3It+gUBpUlOJovaZPbThznIbhbHzldw/eooW55LaEivIK
zL9Hu4/b8OGuleRtmYgH+1I+LbjJ31S5Ff1oMXJgSgna/vJC54kK6xcu+rhGVB4lAhIBicCNj8DN
afAzi+Gyw0X+YBs+cRaVTEQu23rOxwbTm2swaeoUfKg9+z3SpQcOGbWlx81g6y79gx8FvTJG8ta9
tCjYBy1V7+Hx0ElIKqdMGIQp5JS/ISEDladpn+tqA36daHK7aLe9XVjcEY88iGE0tXTgjQyw+XPP
Qcg0ZCy9OShdjDcO1JF9Uoftv32OirHHcOdgrX0HwcFB2PbPcxgZ8hAeHRdGmWimU31gs1Irk/+I
o7RPdgNtVZe4DZgROoBiB+LhJFpkt/gPOFDXBp/2OmyLC8bUqe+CRMfwyYQr7WSxjbbos7GFzOnj
sTLxY90MteDlyuQku8sD357b9PLaQXDZ+VevckPGRhEQC7GdZLXSnuv7t2fwtzH3BZKxoc/YmYzX
Mf6jJyOajJxfp9P2gLSfOmuLhA1kvzwYxA2m0dOe5jxs2FOJhrrD2PCSuzbvix/NAPKf2o7KBlqE
TNsbvkoDvIIzPWiAeiU6p4rgSU7fUVhIur92SgYtUKY6aTF6+kriL/ppjCGIPOurZz3rCKDXeneR
dfBJGDv+PvS1VSGHFtc6+sgpvBYcjEF/+Ad12/vw2COTRDXUJzzpncjk+PUfzt6ynNWpgHu6Xfan
q7pPMZ6oJ5uO4lBlJSoPV+Lw4cP0L47VTcxwvhOx22jQs+0pzF23C0dpD/7TdbRpwNLHQWqGwpd/
yoh0CiFPMD1LxEs7aRG2rQUHtqSR7kcjYozeqnYUc6hJDwQRrBumpAg9bKrGFqazEUInbut9Htto
Zxx2D7NRnzJsSiHtj8DE0UTXdzSeplvcwl9tp/uulXYBSsdKE/DiE6F0D++L+8aNwzj2P3EchvXV
3li04di7RH5yiP2tKOfKVX7aeeiF8UyueKyZFYRPCTOGl7maBny6wDTovgGkwDJIBCQCEoGbEYHL
djy6TgU6+/CTT6vml99u4b6ZDv9T4aes+Vcy/2a9f6cpl8rGFKj+7+1KRUGSQm1l/08ptAipXPi1
isV+jgWwpgKx2AzxhbxMs6XYvoCY0YwgP2C772dblZKq+qpq9dkXuXbCsV7J5gsJBV+htEA0hnyv
o9WFaZ1kYr7g6roEmnFXyrLFwkzOQ4y6UI37J3esqE0pURcQazxlMn9uFlT5yWqxYxOTarSvG6AF
D6rPrppOi/eM9gWKhKu64FXQjVaKLYIBZ969l9MZew98k/xu25TLdRnt0GbiPryabgnf4nj72gqO
E9WnLe4VsoYq2WXquocOuinK6/SHtZumx4KY/Zf7gOvXYpgKnXQrOrVEXdAritQaxcJpxkM0ra9g
vtTcJ72jHlO7Zep0CzHZimg2z23RkR87o+ykg5zcJ530RuuDtMLduU5ajO5wf+5CXz3qmRMXjBGv
9I6tKYnW9fn4JNGPtUXQjeW56sJnodvRSYXqOgtPeteBF9Vn3LGugVb1uKVLZT3K2YVOd6ia+9br
9MqtDz9hoK11YiQsJZl8vYd2L2A6VFCureHpUIl6qdc7tqFBrrrwVp9b03t1KYxIarY43w9Dk5Ty
RrbSnYVmpSRTbGwgeIlQCu1ro6iVG8v5PV/jM0m7Z4vCLn7FGiq7PrrIoUU1V6gL83X6weqJ0C0K
bixLof4Vo1g0drXC8igRkAhIBK4AAXaPud6Ldm9hfFLFN1w4duwYHnjgAbS2tl4b3mh2qokmOP38
aTs6bVLIy5psNMsEH9ov3V6OvtAoiJHriz3STs3a0oT2HrQVna89yu0Jz0sv4v29ydyRCrkfNLX3
QF8vyvKvXZKbuh/bjk+jY61EpN94zDc1Y+lo5nVLfLiUp4Wvh+hL2HUKjAei6090OyPhyH2lcrrk
WyPbRZteTjtoJD0evZTVI40uEzXdctaf6j3rkHb0QWS+GMXb7/SBdeg/5XNY2nfgPjfAs6+UtpPT
T0fdutK26JJ1yuCuTl62C31lZdlKCpd61rFyr9rCSv2UEHDb5zWs/TvpvUe90/FSvSsWo9Y9iGby
lXf0Dvd0WVGPcnah07qqr+KU+GthSIv7oRv1caZPX3JuojJ+ffs67h/OOdxeCZ2ge4SL+4fA2eaG
roajc19wW1G3JViRF+mHvzxtwV8W3ddtVCUhiYBE4L8XAfaBQTL46YOHg64bCP+9Bv91g/gmqogM
/jAy+BeWn8OLE12/or+JpPles2qr24MebMF5dDyShp/Cho3kWJFdgb8sHfe9lvvGF64aS28ZhZGy
D934TeUlhy3mrQgIPehxMO0lKZlNIiARkAhwBL4Lg9+ryRzZPv8lCPiOwVvlZYB94dt/idw3oZg+
w55Ec70J+96rIK/xnjCaMhEZMuwmlOT7xvJI/H+WEvy14RwJJgfN34fWPfd1IEosm9y+Ofs+yChl
kAhIBL7/CNywM/yffPIJfvzjH6O8vPz73wpSQomAREAiIBGQCEgEJAISgf8KBJjLem1tLYbR19Cv
V7hhZ/iZ7z575TF16tTrhYWsRyIgEZAISAQkAhIBiYBEQCJwTRHw9fWFla0HvY7hhjX4+9JiMBbM
ZjN69uyJS5fEx1euIzayKomAREAiIBGQCEgEJAISAYlAtyDwgx/8AP/5z38wcOBA3H777d1C01si
N+c+/N5KJ/NJBCQCEgGJgERAIiARkAhIBP7LEZAG/3+5AkjxJQISAYmAREAiIBGQCEgEvt8I3LAu
PR1ht9G+zzb6pKuvfl94m42+9mijLfFpT/yOBVxeU37r5eR3SQTnz56ien3QJzBQ7OFva8XZs9/Q
FyFvR2Cf3q4LdWesKjfzARNByKWvwsfpOwH6lBvnXOBInzS4PRCBvb1rwevNfSe9Iz0kFdKFDjrJ
U7pHz7RKOvGgJbg92nD21Ffw6TMAffT9xW3+7knoxKeqp52pu8CM+tAp1oeoJ99O/co7dbDRdzou
4tZevd18S8N9upXWCH2LW9G7t9aHOnPpLsZmbcXFb6+srDua+nhX9K3nz+K8rTfuCrx8fvW05blE
QCIgEZAI/HcicJPM8H+DP8ePwIgR8ajUfYfL8ud4ihuBN8znvWo9y46Ey8rfmagV722Yi+CQsRg7
NgTLiqqA85V4cehohIwdi5Dg0U78dS7fHTGt2J0wlOSIsddV9ZaQi2Gh/Q8dOhBTV2xBlQ6v7qj9
cmmctbyHDRnvQb80xXryMF6ZO1DFkXAbPRQrKI93regdB7bWWux4ZQPMVyV/K/68QK93rdjB9dCB
84gRQ8kXbyq2H6y1M6a1h7d6aS/o8kTlYcYbXuNzvnIb6eMEGE46jUxcUu++yI5YAVr/1HTScVxg
111Wf9V7WzCV+tBY6kOsX40eOtcJT1c8ttaWYsXUoRg9ejRGkK5veNfSKdvBjAU8/XWLQ7Ns5y3I
WDEVI6jc6NEjMPXZDJjPO3Cy1u7GVPKtZP6V2v+KHWaV9nm8l/Esho4QZedu2O2hTVrx1goHjYG0
+cDUqex6hVudtJ03c940+gPnbsDhk6LnnDSsxtiQGTjsEKWTvDJCIiARkAhIBCQC7hC4SQx+0E7j
IvRwkuTKZtN7+vRyouL1he043sw6BATHIW/3Xqz9SRBspz9BPhEIjkvFboobdIWkveaBZiUvcSM2
gL6ZKkK7up45fE4M4uLi6D8G4ZRkKVqPpdsOe0+6u3PaLFg9dRGy3m9yUD5/GDETZiOHwThnBdat
iUMwpRalL8KSLZWOfFd1ZkXRM+FIzDmGK21qrfqeAeJMw1rTwzlxK7BixQrExURRBguS56XYjVit
PTQaV3vkPPTVau6K2lkUrF4PhK9D1KjrOxvcEStA9E+HXjLdjENMTCQCbhVynCzdgCmL1hOCQMzq
dVgdx/A8RHiG4y13o1WrBS+FL0QRFYpbvRqsRFbcVBw8K2jCdh6lW1ZgXjopGQV9l7TsSkc6FYyK
W4M1K6JgMaTj1V2OwcL547WcF9JOBAfTv0qSHU6+93ssSjcQtnMwJyoYh7KW47e7a3U5Op5SaUYj
OBzBFgvoj4If/PQM2YvYcGDLKs5beMwKgcOhLMxeW8IHy6Oinqc+bcHLBd9hf7bzKk8kAhIBiYBE
4GZD4Mb0o7hCFE8e3IEdH/TEzKhB+HvuWzC3+eHhJxbjmWnBTi4/R0oLcCb335TeD08sjsPscYN5
jdaTB/HHnAO447GfIzYiiL55T7PEGbnApMWIfcgHb2VsQR3LaTmIio8fwMgBF5CeWcxigC+qUHvh
IUxkiNpO4d1tW1D0ry/Q+44QzF8Wj8lBwvjhPJp6Yvywb/DXovcRHLsWyyKC0Fp7ENu2EM9nWjHk
x3Ow7NkZuMuXEaZgPYndf8zBX81fICQiAl9yJkSS/jd65WuIHSWa1LYgBEOnJsLy/sc4nzARfSij
+zqsOLjjj/jgUhAeGHAO7xBfGPIwlv3yGQT30VTEisp3C1FsOIIvaMARMn0+np0/mdNlPHSWKxGh
Nbkg84jstwSs3TEIKbGT8emurWTOkc20ugBvJkTwdlk4bQxGTEkATn0JNpbhSNEM/e43/oz9lmMU
MwSRMdROE3XttOMAff1yEgZ89Q8UvX8OQ0IisWzFbNxF7J48WIhCbuvVYUv6dsQvewajW8rxRyqD
Pn2oWS1o8JuMNcnzKb9nuahyF2EOVr6ahFE8xYYxZ4YiwVCHM000U+zGF+WspRR/erMENV+0wW/0
BMQ++xRC7A1MKnPWgj9vy0XpsTPoPSQEP1vwNCKCA53qZnbiyYNvofBADTD4EfwP4ampiJbxvPlv
WE+G5ZyMR+1tw+vOfYfrVu87RiNyTqwdS6oZlvf+jNw3S3EGd+DhBc79xb3OaDV2fXzqV2mYH+Qi
n60WOQuzeMK6vWYsGcfkXYJH73oWM9cbUPPZl8AogbK+9Kl/GVBEEVHr9uHVJSE49ej9mHPmNgz2
YTP1F/FWfDC1h76Edm7FlydYQjieT1qGcb4W/CvLAMNnJ8ioDuFY1teI2fyMfTsxc+jt6G130WvF
B3/NobLByNuchWm+B/GpYR7y/3oAr8wOUoc2Wj3s2Bvzs4yYz6OsePfFEYjLBzaXvQK1i+oz0/lF
fM3HxXOw7rUkqsWMvTkGWJq/oRTyFuwzBgvnAMvX58P8zESEXNlcR4c65aVEQCIgEZAI/LcgQObR
9yc0fVaKLJqBy0onmWhmjU2pGYry0e9QDWYHOUyjovXJCA6n+bJDRZSeg2/2WRAb0gffNn2G9Jws
hA+dSQY/0fi2BcVZ9JDvPxexE4B9WUXq7J8FWcn7MfXHE5BVJGYRLYYcJDQPRVREX+xaMBbJ3Kql
eXaaQSzKT0fekRpMG+yLpuPEIxkzWoiZs5bGB6V4kmYs2QRgeHgwctbHIadoDczGZQgkp4EdyyYg
kRWhmcK6RDLitcIdjlUV5bC09UFb+3l8+KYYiASPv5cbfp7r+BbHi2nmU4gioDOQUZVzAodOvIog
MopLM2KwUMtA9RoMRUjflwrz67HEI1zI9Wv4l5CFo4b80uN4JTYEn5QI2Z+Kesg+CPMdNR8nTsyH
j6aN1iq8MnoKmHnFDCyqDUXUTv/cXIa02aNEO2VlUTz7Z+mECPHzxR334fXYYDA9UFsFRVnJeGD6
XIzoQW3Ly1B2FsIn43deyCUyd/wtosHZBIz3B86eMYM3J836hg3WBHDOf968gwZIiSKSi1OE/Kxi
FHz4JiLYCKW1EvEhM/ngiM0qWzj26cghnZkhxjjA3T1x0vwWpsyjgREzOg+90MnYZxU0/LuUpz/x
WBC7JNpmLJ26kPCIworVQ1CRnoXl+Vm4VFaD+fQGoGr3y5i6nLVTMMKDDUhelI9/ZxiRNT+4C73k
1L362bclA2eDtGnti7jo/6AYrFxswReMAr2NmMuNfUFu3LLX0bDMPenGz8w80ZC8CgOTqe2D52Dz
xt8giA9OyTzuHYV1b7+MscczMTORDQ204IvxP10D6mBYvexFjEcFx3z1kz9WsWzFsfeFfiZMHwuG
NI0qcGjLErDbxzf8zdow3M1Gz6T1Y+jX0syGTJ5Dq7mQG/vha3Zj9ih3lnpvzE4z0r+gdd78qejn
AT3VfuKLB5+Io1dhOThS8zuESIvfM+gyVSIgEZAISAScELhpXHqcuHZz4dNTPExjyGBpMBqxe00U
z3muhc2ROcKKvEMw7tqFD99ezSOLDxwViT49+VH14gB5z8B+3jsErx/bx90HEJ4KS0MWJoTF4hgZ
vSyEr9mLhl1L0MvyN2Hsx2yGheow7yYDg8KbZPCy4KPOBc5ZtxfHjlnwyvQgHHvvHf5wX1FwBLt2
7UPBCrIKLevxNwtZGKcqkceN/dU4YtwFY00Z4pjR6CLkJMzD1OnTMXPmPCTnH0Jw1GpsjJ/Ec3qs
g3IIdwwyJMnINBprkMMryYGR+T+f/wibubEfB+OxBjQ0mJE6h5gwJAoeqXxnucYg9g0dXjQw6E25
RD1R5KftGIAxBu3GPp3Xlmzjxn74igLUNBhx4kgBd1HKX54Ji5VlFu1EoMPM0g/liGFBqYm/IQhZ
koFU3vTh2G1poJljstB0ZY4cOwbz1mj09kIuxpurkL8+EQk0+FqfzoxlCgFk0Lq0/Fqx51Vh7Kfu
/ZD0sgFlOWS4kQm+fmc5L1q1V7wJiSKdMJLeHilYgyhyd7rN+i1P5z9FCZgynZmg4eQO9S6mBbky
HG346iR7/UNG6e1i8GE98W8x+Am/A6Hhc8klJIfc0cowk1mwOIlCbuyH4+0Pjdi1x4gYii1KeBO1
JEtXOkNZvQoGGvCuX79e/aeBZaKJz1qz/sWlsBu1XpGjptRk74vV6wgrSxGWT5+H0lOsAdjM+utY
MnkUOc90Dr6Bd/NIiyEf+QYaLFAIuI0f6E3al6hgfY0wXpeTgzVcx5OxJOMgz3C7Vi1vFrWx6Qbh
Qw1/qsoCM3fbMcNcdUqnCq3Yu421fzhWL5zI6TBFcZ+fxmhVu/Ez3tbAuuejBEZU8o4hbIgBNJ7h
rwL4ufyRCEgEJAISAYmANwjcZAY/PXHJSBChFUeP6GfvtHhyNwkdyi8C/LUntCONnfn2oalZCn0G
B/Hjof3k9sLPOvy0ngdN4DmMfruBwh7yalBPAnoJL2+7iZa/HMG08C9k9nqe0XDkKPfF1YpNCL+X
dgjpQx4gVvIG+pRHZy2cQIv6hmJhljBEWtpol5HGGj4YCJ8TjsEsl+9gjBmmUXE+rsjZTW4Aa+yR
M5c+jZBAxqDnOuwFaM5zxABmCPpixBhhXLC01hMfc6MxeMX/QTCHNBAPTRbpl2gnFn1wyEWxnfCy
4RIDlOZVPznBp0tFUXKBOvjeQZw8z6x5h90cPesh4oSwHvwQnopiKa1oswNMk6/REfztgs+AEXy2
Fc2XVEOLBhYsO7XcbfaG4hG8zODevRFIu51cjlyitPYbhYJDZnqBRMbdh2XIiGNvcpKR9GfRblou
7agNpu659y4eNWrSY+K9xPufcb3TfP4jwgWmgyOW4fWsJES4nA1uwiVnyLVq6NiKkzSI1Aff4J+K
wdmhfMTNpsHgwjikpu/Ah18R1q2NOMYzH8K8sbSgdPRUvh4FOIhTF73VGX1trs/XvH0ENTTIsnCD
mHzZjz0r3I2oLbkW1LU49Q3m3lR62AJVHToRpV7B44JXv4yEJcuQwgdQFtQ06nSqUykW0Yp3XlpO
x3B6Q1KDEx++zQfwyTN34hRL9h2FtAY2oN2FJTNmYNnvXqOcNPauEO0kZvgpgt+DVMXi+tyKoilT
MZ0vzJ2O6VOKVA5Jl2v/gQR2m4qJx3j+ZoDOKdVdfvY2aPSU5bzPx+WUicEqK0LhW1zixwpLIz/K
H4mAREAiIBGQCHiLQAdzyNti1z+fMBSL8O9j6+l1Nntykj8uufiy0K/DKriORqjI5fjtpZnrbWwb
QPIIUN1eWjsYUtbGz7ihy21NR3GvzoLjNmP7snDY6j9FRd0FDBoVptXKyzt49MXdQ5kFbyG/6734
zU/6o8H0Eaou3IaQkb1xa9MAnp8NSlqXTaTZPtoClBsZndkYPCIM44In4lDOKYTH5SB99jw8QDO3
EeQr7qkO5j8swhk0s1PSCptm3bTTnOmgEcJAJcOnFZP5jOPZsyr4lK4PDrn0sT3VcVof3P84oXnI
gLw3/4GfvTqD0zpVvhPzFqVTQ6zDMeMStH9zhhc2H/2K4oLo/Cvyl9bTU8/tlq/acHy21Tlfp0W7
9jIkV3/v5XKmCgwYHAjuQdInEA9PuJ/cRA7ReKODAvFC2iCnL9rZeIYGTK0NYhBHoyu+oNQmVmHD
XCPktVrexYY3P8eE6F9gxjjtS3zhWLFmPP6+nlxyXipAJL1NstuPduZoS0ui7xRsvpi2Mh2Df3YB
uHAc/zAUk7tYDjbuicbk+H4YTZkNZPbmlaUgzKcFH314FPjhMIzq5YsGD3rpVEcXF/6Bd8CXtr/0
7Zivlz+tzqBAb7P+dPBJJEweTBdW7EudKlxgUumtA7lodQx97+KlQIjypB49OlHuWMRxzV/Z0S5L
9IbDh/z2f8zGajR4q6exwl2owo5NO1DV///Q2oDJxIqq3AG3874rBpG0VoONK3ybwXsAp9cHETnr
cP7zi+jTi7kshfJ2ZZV+9bmJ1736SX3/d53fdrKUZvYTRX5625cQwfBwhFvVYeyIu3mljgR5JhGQ
CEgEJAISgS4QuEkM/tvxQHQUNxQTp9NyNtodBRVZIK8VCnEYSw/vywnrZ5PrTUY0PisUD9fJk4J4
8d4DBwvXkORXsX3AQpz4ffLlkBU0hj/AZw0NOQUwTvgheh7ZTLvFHMIc8j+fHOKaXH/a5o+ZXZ/u
24eK/vfhrwuX80WJOUdOYFRQGEhaZB1KxksZPfHA18VYz+XuTOuSjVnrvgia8SIy5tCaAtqNZOH6
t3Asaz481mG3HA2Y+cwGEDTYlsws7HD8aBglBo7GT+jKQjw888pFRP/QgkTu4jMH4ffaC3dm6Nt2
MdNZV4gN2/vjxSURGLfgeUQRbQPNyo7+JAYr7j+DLFqcyEJc4nQ+ABgdMYeuDMhfvgR9zy0C/p0n
/PnjFiCUDFpteMLKOAUaCGkmt/YmYcvLG/BE/At42CmjenFXV3I5ZoydxzUGPL9gBcbcTcZ766e0
nkHMqt8/pK+LWhyDnHnzaFeiRcF4P3E9z7dmwSRuBI9+9Am6Jnnjfo27Ux9HTV4y34Hmhz99GjM0
iuFPkd/5fIyvzcKi/GRsKZ2OpA4GIRtN3DeB+kkRGaXfEBK0gLjV8gbGTqf6glfg7Y0zMSH4CMfy
7kA2OhqAUAZ1kQF/fY94CDyKRQm0LiKYrR8Z56XOaAw6js5YAXnJy3DkbsdIpJUs5diN6YgYHIRl
5FaXM4/cfOZNgJl2PrrjC+rXXB3IBebJzsY+q2Xww9GkmTk4lD4br2A1vqB1CSwM6euog0d0+rkV
/e5gkfl47ZV78bDvv0VfipqOMawoQXaE1uwUcYRS4ft+Ih/wz5k+npDtjYm0CxbIFWj96hdRQv7/
rBvOeeIhrrPBM5Yg2N5YrA4RWk4d4yf3BwVqUfzYOT9t+bpWrONhGfbuWIv319ehaUw89lD/Zeyd
+UK8Cbx3FCmeDBIBiYBEQCIgEbgMBHwuI+93mjUklhYxniSjkHbVyNcWX9Jivbytv6RFpSprYgoO
PfUO4ZSkRquZgmlrwLuRnCCM/SjaLeZFzXAKfAhrVkfR4lRavBhHyxxjyBoi/+AOBFzi0Fv1mYZv
CDKMOcDUOE6DZQ6Py8BvaLGpPuh5vCsiAXszrJhJxtYibuwEY3XeVlqwyQQbjBcO5eFY+CLaujIR
RcFkJMc0IStfT02cO+QkP+bf7Ma+otm0ljUBb8T8hHYC8lSHZkJHIebuv5NvOjNgg2nh40ZM5HbK
YCSZ9wK0BWIWLXhkhg6Ij7ffSFFdfET97FcvF3oPA7PdDbSwOSc5AHMXRNDuIuOwjWhlEa10Mp7Y
LqesrhWb05EwbTC7IBeeGTiyOxWrZifS4mi1nVZsxobV0/hMq8Ztp3ahha1CFXrjIdp9iV510ILp
LDwQ+wJ/a8GJO0CiS2/lusO+jSSnQT9swbcw8+mCFlPHLVqNJJV/LY9W1ThaU5B38Q4soh1WhDjB
WEPtu0xdqOo7ajbK8r7E0kXryb+dA4KYdW/jfzj42qDjEh/oTPsVrWfIX4ishTn4OV9QrdUmjv0G
i8Fj+adf0Zudwegd8ix2p57C7MQszJuexTOFx6zDr6KFPs6ggds62hkneb0YZIp2fRa82T3qjHO9
jqve8OMuL0CPnsKL3kJvdOxYqRkfblpPBr8v7pqcgCNv34FV8xJpECj4Q3gM8tb9Lya6G0uSDm3d
txlLpy9HTno6p7gmr4wWxYvWd/Aizhw66YsZrxix+szztDg/mYZYFMLjsDd9Dh94wWcUfkN0Wxld
Ve/mrCnA7+YLrIJm/C9yVtTQPSifyxPsol87162tqZiDIXe45s2ev7UGpWLcy6PYwm0ehgk3HnZe
+8lB+g3HvQOZ+S+DREAiIBGQCEgEvEfgFoWC99mvX85j5PMbFhaG6upq9OzZE5cuqQ8++tJp68Vv
iZGr+9Klq69ZatLxr3De2gu9r+orpVacP3+R9oGnuUEv6TCe6MOh6EU+5p2LkNznv0Uv2iawC9NB
E8Pl0XUd9JGgZ0fTriQZqHl9Ppu2Zky44IG8HCiNGdx9iEdvAyvjip6V1khctPlwmVy/o2FfSmUG
L2HoZrtLTzx4auOO5a5Ero40urxmusu+DEtrNzq3L5Wm9POU7tOL1na4BqTLKmCrog/BTaG3BQU4
8arY9pQXUuuGj2sseVuQZrlqV9c60zUrl5eD2pp9wpi6ttdfv9Xw4mthLq823sepCOtrnfsT8XK+
FTbyB+vjoiEEVq7TLo+Ly8l9EhsG0q5gMTmoSZshBiiXU1zmlQhIBCQCEoHvHIEf/OAH+M9//sM/
7Hjy5EkMGjTouvHU+Vl33aq+wop8fN1tdX5ZBH18XT3oBQnfyzBm3VfqS1u+X57VxnhyX4Tkdjfj
6Z6JTinu6viGbe5iEXt+uzL6NEIMm8uTipyM3ODpywxfjbDLI+39cxVCe2rjjtVdiVwdaXR5zXTX
fQPTW4jL15lOddIs9eLUKOST21D5CxGYzKfqKVcXdXtqC3c606nuq4qgtnY5CvJA9CrwcqeTojbi
hb7X4C54wspdmauNP3u4kG9Cm7r4sS76zNXWJMtLBCQCEgGJwPcRgZvP4P8+tsJ3LlMvTN+4Gz+i
ZYvez9t/50xLBtwgEPxUCnmhv4/baAacremQ4eZHwNbjHqTm7MVTYpusm18gKYFEQCIgEZAIXFcE
bj6XnusKj6xMIiARkAhIBCQCEgGJgERAInD1CEiXHhcYMt/tvn37YvHixdzf6QZdauCCcxklEZAI
SAQkAhIBiYBEQCIgEXBGgBn8t9xyCwYMGACrlb2Fv37hhnbp+frrrzFnzpzrh4asSSIgEZAISAQk
AhIBiYBEQCJwDREwGo3XkLpr0je0S88DDzyg7tLimnkZKxGQCEgEJAISAYmAREAiIBG4mRBgs/zX
e5eeH9xMAEleJQISAYmAREAiIBGQCEgEJAISgctD4CYy+G3k70T7dHsVKK+3Wbukx+rtLj+r7uTL
E+PdybOnerxMo91ivG8PPUbXSg59Ha5ksOF0QwNON3VXu7uqw3WczXugXBPQYgnz7ugC3caPxpfL
43fVzi6ZufpIWxPq6k5fPZ3LosAwdG5xdt/q/O+cR1RhRdPpBjQ0nEaLq2SXfNjQ0tLisV9bKd0V
OZu1hcpeWd9iNDuI6ZK7K4sUMrV0qMDadBrfwa3gykSQpSQCEgGJgBsEbhqD37x1Gvz8tqDJjSD6
aPMmyrvhsD7qis9bKn9P9frhcIsgUbd/K9L2VF8Rve7kyxMDLeYtxPNP7Tx7yns90io3+MFvrXft
Yd403t52HbHvLl49t0MT8mJ7oD99DKN/v01e6Vt38WU1b0IPv99ffZ1WMyJ7+GHDYW96i3vuu40f
91XwlGulr3pd6oKFbky2Yufcfniy+ItupNk1qY73x6M7l/L7Frt3Of+PxwH1XsaoHt2ThrBb/NCv
/yD6AEx/BPQIQ5rhqMcKm8y7EHlLDwQEBMCvxy3YtL/z/bDp8Cb4BUxGha4u2OqQtzSSdDyAyvoh
bOlWVOvs/spNsXwxG3vVLf5nOe5hpw8jIewWoinqXOfpHtxSiVl2GhqtWzBrU6VbuU5X7qQyQqYA
vx6IXbcH2pCt3vhL9Ju4FXpR3BKSCRIBiYBE4AZF4KYx+Dl+ob1cfBWzM7LtFBXa67bOCVcQ4z96
PowlZRjhxwpbYUh4DgVfXrgCSkAPKhXai/1e2+DXI4BXcO1r8k6O4U+VoeznI7zK3I5AO0bO2HtV
3KtMHtvBdhJ/ygdSy+qhtP8Sfb2i2D2Z2pni0r75V72S3mcAXi0pwVMj/K+KsW7jpwsurpW+6nWp
Cxa6LbmlchsWFsfjnRfGdRtNrwnp7o/tLafoZpOCitpaVFVV6f734AFVLRr2r0NwdCImZZeg/lwz
2prrUZw6HImPB2PnUTfmLRnTi0OfQkCqEefamlGWGYGVU+NgthvuNj6I6DdpJbE9nN/zNP7r/rYR
i7cFoKTqHJpryxC67Tn86k1tcNGCD/6Sj4iUQpRXlKOsjO4Z5f8XYUOJ7aAAAD3zSURBVJzXFuTF
TcLG4ZmobW6DqXAV1kaPgkGzyLUKtKPfcKxl5em/vKKCZIrgKeE/GqDlcD7aqrFm/EIcTylGY1sb
astzkb82GtkHRAUj56YiyfQcNqrXzoXllURAIiARuDkQuLkMfg1TazW2rtuKw5UGJERGInJWLDbt
MdtfHzODzvRlBXamLUVY5CwkpO1Cg+7dsrXhMNKWzkJYWCSWrtuJOu1hxeluwp49WxFLdNMM1bCe
q8a/Pm+CD1lhdYZN2GIi2s+FYuuBBsGN7TT2bEpAZFgYImNfhuGoflbVisM70zCLaMW+THQ/KEWg
h+8g2ZrMJNdSRHKZljrJVGegNwt5e5C3LtalTKcr9yAhdhZhkYDfF7LV38Lo1yDTH5vMBrxM8kdy
bHY6Ztm4/GnYuSsPCbMYrkux87Aqp0qgen8ellIaw3XTrko75iy5pfoA0hJiCQvCNc2Ba3NDNaq/
5tYsp+JJTrUaftBjzyLc8k1pbttUUPKuHUj+TavTUEplEqckYpeF3AfqDEjbtJN0idqYsN2vKguT
dR3DUNWhas0+UnVo/wFqD45hAvaY63CUdIfljU1Iw+EGTeE4c46fjiM0awN2sXojwzCL6ZZZr1vA
afMevExtHhYZi7w9u5BGfULMmF5AtelzOIalNphJf1i7RVJefV/x2BYd+XFwSoB77oMgzWB1xnJd
iUUa6Ype6q701ZOe6dlg5+70rmO+BuojQu+pHZauw357o3Ei1LcY1pGYRWn6fuxJ75zraEHRr1ci
IvN5jNQSWqrd0mVZPMnpWae1Ctwdm4HAIRgzbBhGjhyp+x8GYe83YPvUtUBSCbYujcLAvv7w9R+I
J1/MAbOPP/643iXh6n1bUQz6sNuLkejr649HXngLZSWvYoA6SmVv5dggIj5eGNl6ImeP7qdByCz8
ZGRf+A97BNExQHHjeZHFWosS6nhPPzUdE0PD8NAjj+CRiSPFZ+Osx/CnYiD3d/EY5u+LkLlrkUql
st8168k7zn36YhwrT/8Txw3ARwWlCE0y4sXIgY48+jPbBdwWGoM/PP8k7vT1xbCJMSgg9nf9s0bN
NRBP50Zj7fN/vvq3b/p65blEQCIgEbieCND+9jdk+Pzzz5XbbrvNzpspO0JBaLbSzGKaK5RoQCGc
lNSCYqUgJZqfF1a18fym7Bh+HZGUq5QUZiqhlC8i2yRoNZYpdC9XQuMzlbLyEiUplOiEpir1TnRD
lfhV8UpqSS1VlUm0QpVyqritqpjTCo1JUUoqWIlmhZ4DlB6jFBjLlMLUDnzkCj5SC42UJs6jsysE
H51+a5VVTKaIJKWkjGhlxnMZci2aTIK2kCmV8xGda+FU2qoKed7olALFWCzkBaKVCg5Wh4oIOyZ/
fHaJUlFWqNAzV0F0gdLOsulwzS4pU4o1HkyCUFXxKl5PUm6JUkb1MPzt8jQaOU9guOroMu4rUkMV
pJSrjHiWsyIzQglNFRjpsWe8ueXbU5tSrSav26FNKc8VMsanZPM2bjZlczkRGq+silmllDUqSntt
MY8Ljc9WjGXFyiqmQ0hSahmIOgwzC4uVzHjSW4Zx6CqloDhX4L2qRMXC+dBsYphmCh1XGpVMTpfp
llHJTRLtn6u2hb3NSceNJdkCe0RwPdWwSi0/xyuwFApdYu1mLEzh/Kwi3VYUz23hzI8zr3o5XfVB
i4q5qDOV1xmRKnTAzrsbffWoZx3YUDzpnU6X2iy5nIeY1ELSzxIlNUZtM06vTSlg/Tg6VSmrKFdy
V7G0CKWCKa8nvevIS3M5b4fCWlaQBQ90KdWjnF3oNCev+3G6P1K8KZvpS7xiNJmUiooKx7+p1t7X
WX/KVPVJR8rjaUUm0aW+kGLX63ilRL3vsoJtjVVKFaldexXDmzDU3YO0do9JzVUKMkU/yyynDkVB
61O8r7D+wngzVqlp7P6mtgePEbiGZrq7l/JM/MdSwO67dC/UmsSR5Pasvb6Et6PoIyJbe73o8yWC
XbdlZYJEQCIgEfAGAXaPo116vMnabXnQbZS6mZBHg79NGPyrSriZTjU3KikEnmbg8IdfhDo4oFQT
PfgRU0iPX+1BuErhzygy0NpU4y2TPZlUuvGF4kHDRBIGn/bgalNyIxyDh7aqAv5gyjUJw4rxQTNP
ingQifMYHS1606+mMcodQnu9UpxboKj2PT04y/igJrNC0OYyRedyGVhJZhgjvpg/vPl5qGYoKsq5
cmZgaTw716M9uFYVlCmNbe1Kc71FqbDUCyNAlT/FqOGqPli5Ad6sZJPsoSlGkZfIiocpYUk4cv6Q
qmhIsMFRChl09ZSmN+KVLuTU59Vj74lvYdy4aVO1TbxvB4vA3SQsBMFDqFKmCaZhr5NVUQ093lYq
hkkqhu2qoampqoUZYtRWOnL2BtIb2Fq9RruBoRqPSUaen+u0NgCmGDE4UtuceODGHNcdajcaOOiN
I1NBqpJtJIO/i7bQ82NnUjtR5XTdB+uVJOoHMQWOftRoZAMNMQj1rK+e9UyrXjt6q3eNphIlt7Dc
rru1RtFH2ECeeowYXK3KVSz1FNHeqJgqLHzg5UnvNB60o8BLb1y6p0st1kV/Yga7O53WanQcOQ46
fdAmPfQGND/XdE9tP+3+4qDk+Uz0NRro08DJUlWhZMfTYN7F5IK+72oUz5nE/RIRMUoMnyiBkl0h
FFzT99yyKqW5me6F6uRJMd1A2iysnDqYVYkxebWJAY1+p2N7lRJPehida+qU5DaC7rtiEiSb7hy6
oPapVPV+rEuRpxIBiYBE4LIR+C4M/pvTpYeQohfWGD5I81H2RX+axtccRtsvsjfHD6qvrim+F/2b
GtBGB/DYjRjlR4u5aMGZXxC9K+BB+Pwwuvff21+N63hoB5EGLgr3lPYLwo9jcWg/dZFZfyRSsumT
GlhbamCg85AR/VgJHoaPIzNM79egJbCjz0CEjbyElyaKRWZ+/afQq3NH4DJFhopX3BTdg8lUXssX
kjHPi9C5E+3y+vVxxz+rZhr53cZj48Ip6E+L0wIe/y1Mp9ud/MbbNCCptnGzomEymNBCr9UPlpJs
a6eih7ogLnghObvjOM4IYOmZ3MdOx3fkk0hO/gUGdnRI70JOIugyeOab6YGbNr3cdqDX+0wH0K4J
xS4C0VsnB8c79VGHf7//CCykXFrTsvIDfih0s401HCLQX1XVdk7du7UoVBA97C5goi2w4V/craD+
eClClzh03H/Ij8C6gMNxipVm4RyOmoAlk0eLS/oN+cWLWBo5rEudsxdwc8LkdNkHrWfBlqyGjOxn
L+l7J9NJVkJdy+JOX73RM05F9+OF3t0ZMhEDGt60627QVNZTA1RN74ufbytAxMbFCB4UQPeF/nj9
g1rY6JbgWe90PPBT1ilJRnsjuKeLLuX0oNMdq3V5TS45oZmggSWb1HH8f/SC0FvikbdGD51iq3Ra
mAteg7P7mHMVzKVnLu4bOQ5LM3NJu4vx90895WelW7AjhnpJihHt+3dgx18UVGRH47nx2XxxrH/I
UuLxIyx6ZCT8mWvRC2u5Ph/9it1jL/Hqe7COx4MVZub/w/pGy2FadOxYmJumW6jeZHoX24jKr6JD
1HJd5KfFyGF0382PzkT9rqW401GK6hqCKP21PJcISAQkAjcZAjetwc9xbhdGOjvnhrgefM36sscJ
I6v9Ij0IyQOUZm/Q1tZOdl0jyo1lmDFctchYfh1de3GnE/uTh8cW17bRAs82tNN/vakc5QmPkj/s
AEyi1K+/dvDYfv6sExX9hfXoTgRNWYzhCUbUNjaDprUQo8/Azt3JREmmUos92aczGg5KtCXendNe
Rlt7M6pMZcieUY/FVG+l6oPOjIABd9qtTNT+sxihUcHw9x2AeyiNZsvowdzOsWtrtMBoXIt7/Agy
1gAknh2Zpkps0vnxawx4JaeWWX/0wLfHNr3MdtBX6e6c2XOmQ9WO9Qu2szjUKbOj3TsleRPBAaWB
hh1QoOFzGgKS/xDT1P7DI2Daf9TOg+3sMZgoXpddrSUAw2kk8EFNo73WhgN5SNt5GFfcFnZKdKLr
K44+KLi4eMmBgcYXw47j505fu9AzfdXs3Fu9M29djMdXfoTCcgsam9txriKTSnOTl45WXOgzDvnn
2nCu1oKS3CRsfO5x5FSQEetB71j9ToEzo4/xQLcLOT3qtL4Kj+e9QF3TdfAfglmkFyv/sM+uQyJj
AzYMGoVRrx5wXY7H6gasPjRpQHG+WgN7KMWSkh4ba58UCH30cYopRQ3de9j6qKW0M47+FhdIqexO
5BsUSoOKUhyt1/SpDWeO0zCcja/87sFbtDCX3JZQUV6B+fdo93EbPty1krwtE/FgX8qnBTf5myq3
oh8tRg5MKUHbX17oPFFh/cJFH9eIyqNEQCIgEbjxEbg5DX5mMVx2uMgfbMMnzqKSichlW8/52GB6
cw0mTZ2CD7Vnv0e69MAho7b0uBls3aV/8KOgV8ZI3rqXFgX7oKXqPTweOglJ5ZQJgzCFnPI3JGSg
8jTtc11twK8TTW4X7ba3C4s74pEHMYymlg68kQE2f+45CJmGjKU3B6WL8caBOrJP6rD9t89RMfYY
7hyste8gODgI2/55DiNDHsKj48IoE810qg9sVmpl8h9xlPbJbqCt6hK3ATNCB1DsQDycRIvsFv8B
B+ra4NNeh21xwZg69V2Q6Bg+mXClnSy20RZ9NraQOX08ViZ+rJuhFrxcmZxkd3ng23ObXl47CC47
/+pVbsjYKAJiIbaTrFbac33/9gz+Nua+QDI29Bk7k/E6xn/0ZESTkfPrdNoekPZTZ22RsIHslweD
uME0etrTnIcNeyrRUHcYG15y1+Z98aMZQP5T21HZQIuQaXvDV2mAV3CmBw1Qr0TnVBE8yek7CgtJ
99dOyaAFylQnLUZPX0n8RT+NMQSRZ331rGcdAfRa7y6yDj4JY8ffh762KuTQ4lpHHzmF14KDMegP
/6Buex8ee2SSqIb6hCe9E5kcv/7D2VuWszoVcE+3y/50VfcpxhP1ZNNRHKqsROXhShw+fJj+xbG6
iRnOdyJ2Gw16tj2Fuet24SjtwX+6jjYNWPo4SM1Q+PJPGZFOIeQJpmeJeGknLcK2teDAljTS/WhE
jNFb1Y5iDjXpgSCCdcOUFKGHTdXYwnQ2QujEbb3PYxvtjMPuYTbqU4ZNKaT9EZg4muj6jsbTdItb
+KvtdN+10i5A6VhpAl58IpTu4X1x37hxGMf+J47DsL7aG4s2HHuXyE8Osb8V5Vy5yk87D70wnskV
jzWzgvApYcbwMlfTgE8XmAbdN4AUWAaJgERAInAzInDZjkfXqUBnH37yadX88tst3DfT4X8q/JQ1
/0rm36z37zTlUtmYAtX/vV2pKEhSqK3s/ymFFiGVC79WsdjPsQDWVCAWmyG+kJdpthTbFxAzmhHk
B2z3/WyrUlJVX1WtPvsi10441ivZfCGh4CuUFojGkO91tLowrZNMzBdcXZdAM+5KWbZYmMl5iFEX
qnH/5I4VtSkl6gJijadM5s/9/7d3PmBRXFf//5pAhBAkaGKsxn8obUgLRm2iL01Mwf4SE00wNX8r
pDE+QprEKG2RkKp5A7YWeFuDNr4oj8E0YDRoDMYUzFPkLRqLacEnS5u1ESw0QiJGiVDC6m4zv3Pv
zOzOLrvDqkhEzjzP7s7O3HvuOZ97Zvbc2XNnxKLZT1GLk01idoVz3gBNeNBydrX9NHmvwjlBkbhq
E15VuQlKqVVVwF13/+10Z2+iN9nvs0+lXefQD10WmcOr+5aaW5zsnFshOVF7+uRe1dYYJb9Km/fg
4ZtqfYP/iH7T/VgV5nyXOeDGuRiWEjffSsgu0yb0qlUaK9SJ00KHBJpfIXKpZU66px9Tv+UZfAuJ
+YrabeZ94amPU1Gx4mGnzEknv9GPQZrh7t4mTUZ3pT/34K+mfuamhVDEL78Tc0oSDMd8coZ6HOuT
oFurC7WJz6pvJ2SUaPMszPzOQxctZ9w1r4Fm9fiUS3VN7ezBpz2alrn1Br/ymcNPDPS5TkKEtSxP
zvfQzwXCh4qr9Tk8Ho1oX41+J25oUKhNvDWW1v1emwqj7mq3up8PYzKU6lYx010s7UpZnnpjA1WX
OKXEOTeKerm1Wp7zdT0z9HO2WtnLuzqHyumPXkrom9prtIn5Bv8Q7cQZJgW3VmXS8ZWoWHV19cr8
yQSYABM4DwLiHNPXk3YHCT2p4UtuOXLkCG655RZ0dnZeHN3o6lQbXeAMDqXb0ekXhfxsyUFXmRBA
90t31qMnNKrCKPXFudEpzdbRBnsg3YouyLnJ54osS3/Eh/pT2FMKpR+02QMR7kdd+bRLSlMPFrfj
0+XYahEfPBWPWNqREimybkkPr/Z0yPkQ4cSu2yJ0ILmhJLc7CVfp87XTq9662B769Fz6QRdp+umn
raYyetyp+5a7/zTsykLO4VuRt2yW7L8T+7IwfMbHsNpfx00+wIunlNop6cfTt863L3pUnQr4alPW
7cFfRV0xk8Krn3k27ldf2Og4JQI+j3mddWg3vzf1O4MuDduTMDHrVrRTrrzr6PAtV1Q1tbMHnzY0
fQGrpF+HIK2eD324j7t8epJzG9UJDg93nT/cS/j8pvoEnSO8nD9Uzg4fcnWO7seCz4Z6bYcNm+OD
8fbjVrz9xE29JpUFMQEmMHAJiIcLUsBPDzwc1WcQBm7A32eI+1FDFPBPooB/fvUpLJvm/S/6fmTN
Za2qo2kXAsWE84RkZIw/jtUvU2JFfg3eTplyWdt96RvXgJRBEzGBj6FLv6v81LCjbgOGxOw3HUz7
KYqLMQEmwAQkga8j4PfrYg73zwAhEHQztlVXAc6JbwPE7n5oZsDY+9HebMGe92ooa/wqVFjyEB89
th9acrmpPAH/Yy3DOy2nyDAeNF8OvXvqi2Eos671+c/Z5WAj28AEmMDlT4Cv8F/+fcwWMgEmwASY
ABNgAkyACVwiBPgKv6EjTp48CRvlyg8ePFjeQ9qwi1eZABNgAkyACTABJsAEmEC/IyCC/SuuuALt
7e19msN/yab0hIWF4aqrrsKf/vQnXHnllXQLQdcN3vpd77LCTIAJMAEmwASYABNgAgOaQADd7eWr
r77CtGnTEBIS0qcsLtmAX0ARo6DRo0fLwP/sWfVpi31KhxtjAkyACTABJsAEmAATYAK9QEBc2RcB
v1jExey+XPrng7f6khC3xQSYABNgAkyACTABJsAE+jEBDvj7ceex6kyACTABJsAEmAATYAJMoCcC
/Szgd+D0yeM4fvw4Tp6mh19d5EU8YMsmnkL/dSyOTnoow/E+b99BD9SxGY12OOTkaTGB2v3lBQzp
LPrm+PGT6PSy2ytGak88XM1ncVsn7ffW1w5ZTzwD7dwXsonaNJp57jLMaqjyO90aIN8lNn3gtmaK
8T4mwASYABNgAkxgABLoNwF/Z2MlFo8cg6joyZg8eTKioyLw4Is7cdxnpHhhvWmr34kxERFIfK3u
wgSdV20HKrMicdttv8Fn51X/fCt14o1HIxARkYxa+YDjTmxLHkPfxTaP1+zXcNrQTP176zFzTKTs
m8mToxE55kFs2t9oKNF91fruGowcE4HIyEiMGbkYlY0eT1V21OPFiEhE3l/s1tbx2m14knxB1IuI
GIllmyphrGndtgwjR440vBajTivgOFmLF2eSTaLumJFYX+lbx07r6wYZIzFz5kz5ffHrvn3i+EFV
NyE/MmIMFq95V/PR0ygmv416epubrt2p8BYmwASYABNgAkyACfQugX4S8H+BrQvnYwfZPm/xcqzJ
Xo5ZtH6g4Blk7KjvXSK6tIAQJM6bh/jRwfqWPvt0HNuL+QVk6yvJGNfH06qvGqKaGehh7bzERVi0
SH8lInHOaOiqHatcjRlPrIKV6iSmZSFtkewdrHg4FtvqjaG4S+jpWhogLMoFouYhLW0e7diB+Qvf
cgbDtuN1WP3oDBAGYOxVzraA49gyJxXliMLirCwkxgJFK+Zjd71+qd+Gw/uLZENRUVEQL9fSiR1p
c1BAis5KTARVxar5C1F50lXCuHZl8FBqhVQkGbGxUbBahYUgHXXL5VfXGw1QfvOA0E1wWC5125G7
CK/uO05bhmFe8WKgPBVvWb0zcQniNSbABJgAE2ACTIAJ9B4BH5FL7zXQK5L+/S+8L2OtWXjkyWTc
fkMA5t0xFqmZOxB88hPYMBFB1FBn435sXL8NdZ93YvR35+HpJ2fjBrHD1oht//sGWgbfiOtQj8q/
Ao8mx+LvlbX0yPS5WDhbDQobK19H4f99jv+36Cf4bkAYvhURhRHXhTpNcJy04o2Nhag88jlCRkfj
h48+jrioYdp+B6zvvYHCrZX4nFr53qML8OO7orTQsBN1727F6+Xv4/POEFwXeRuSnnwI0VI5p3in
nL0F2bQehR/GjtO29VTfrG0TLpr0nj/mYUnOS0TZy+JoRMH8dXJH1u46LJwieCzEnTc8iTmrynH0
H58CEz1r2rB/6ypZ55VNa/DAuDOI/fYsfBn2LQwWW211eHry3TJwloWMb53NeF98n5WMjIWP4GRE
K4oOrMPJ9jO0kTrb8RkOi5FhVBo2vZWM8IDBCAvR3Nx2FHtENB61HOtynsa/fxCOyU+sw1t/tCLu
EdUHaK9zCRo3GxUtLer3zlo8GTkH5SQ387HuZUUh27GjOEqfsYuLkZMaB8d9w1A0IxU11mYg7gbc
MOVuGmSsQ/rW9/HYS3f5Gjao7fE7E2ACTIAJMAEmwAR6iUD/uMJ/zTdxn7gITCHgw5PHYOaDi7Fu
H7Akdz1yno6Twb7jeCXuj30YuUU76GEGTShYtQiTZ6+HvHj7nw7syV2H3FXpSF9VgPLy/bia0jmO
rluHFYvWwyovDh/DG/PTUVDwPgJDg/Cftr9hRe4qFFa3qqgp4EuOnon0dUVoamrCjoJczJ8ZjXeP
qVeW63e+gJlPpKOovAntTUVY8cRMpG5Trwgfr1yLuxetQFHndYgc3Ymidem4e/JKNHpNRzqNT/5O
9WJ/hCk0sBFLT/XN2jblolrmx/sO/Gr1Gqxfv16+1qxZg/esWkLPmQ58IiTEZuFBGeyr4qY8/Spa
KFjOmO0Z7Iv9/8Gpz9Vyzyy8m9JkIpH7x88w+jsT1SD4P8B1sxbjzT3FkN2uFlXfQ27GM4sp4KYr
5YtffBFpcrAxD9MnhKn7O4+jRqxZcxEbFYmoyDFY9nqtnCNg++xf6iBirDqICxsdIet0/ttrR6jy
tPf9G9Nk3TW/S8aN2vjBrQB9CRp3F7aTzdsz4uibA9Xv7JFFvjFM+9skbAISxN8KBe/giOo2cj+/
MQEmwASYABNgAkzgYhLoHwE/hfQP5H6ANYtFqgjFcgd2IDd9EWZER2D1u2pKz5H33pIpJYuLP8D2
7XtQLIJC6yr8QaRP0K1O1ccbROGVijocsb6F6SOjsWC5iL52oPwjmjRaX0nXXuni7+JnME3EjgFX
0RswRF5yBup3F8qAb1bWblRUVOCDYkormrcYV9soOsUxlDxTRJ+xePNQBbbvqkAifduRulUG9a1W
GYIi6rpv4e5Hn0XBmgLsOfAzjPAWOHa24P0DVBlq+2LNvL5526ZchHA/l/J1uVi1apV85ebm4ony
BrWmznaIMe2mZ6FO68JvR9byRBwoWoEZP96kDtBCopHzagZujxrhTPFxSQxC2PCx8uuOAhq8ybVg
DNFYdrZ8DIlvVhoN3rIxj9ygKH0OdlDKz386TrnEyLWzhu8OHLPWoY7Sdurq6nDMOOv49EG8nEuD
sHmvICFKf1CGSXmSWvt6Kh7OFdolYknCRK2dENw4Vfw70Iku4Ta8MAEmwASYABNgAkygDwh4Czn7
oNlzbMLxbxz7zIHvJa/Hv1LP4NiRw9i3ewNdbS/Hut++h+TZN+KT+o+k0HXzb5OBu95CR5fx6u1U
REcOg57hEXP/AkriPoDdpbsx7tpSWSX5odv0qm6fdi02jIu9WW6/Me5pvCou5Iql8x84IlcO0D8Q
I+Wa+rYfxynTZNK9yZhF7ZRTUDunSN0za/EryM14QP47YaggByfie9TUG7VBChBpVr+z1aRtG077
xcVNAy9fZuHND9Zgcjhdt9ZwBgzWAl8KXGVGelMHpVbpAysqR+lP+2gsNmVSFMJEWpXHoofaa369
Ao9MdOCavxYhlVKemjoXYpgzpnY4GTirn9yPtBUUSM/KxqFXk9D13mrEUlrO81uTsH1hNEKikuif
hSRn8W+frcMOGozt+dMRJNx5jXO7uuIcdpARFvx45hw5aBT70nZbkTpF/dfAuqtIDiLSHpnh6i+f
5R3Yvz4ZD1M6kxgAFn+QiYlO+wMwIkL4Tyc850iINnlhAkyACTABJsAEmMDFINAvAn7bJ+/gttjF
ZP9iHGrJwLjoaRgXGYhKCvjLrcfR5gjCN8aIq75WzFuzG//9g+FosXyI+i+vRvQEPXqk3bOi8Q2D
xQE3fh/Z9KdBekEqnhF0Kbf7BxMN5cU2bXGcVSda1h39jMqNg836LlZv/Ri3JfwIs2OGIpLKldNU
4s1VmZgU0IEPDx0Grh2LieIfgvCpSNtZjCR7IL74x1/wzpZclK97BnFz70KS84qx1pB25dd65BhE
VrpU16x+pFnbQWjxh4vWtNnHsBFhzoGSW7nBoRgtNtC/Kb/ffz9Sb7+RvtiwJ3smFtHgJjab/vFI
Ele1jcuVuEbDfNYuRhCGTjEW87Le2fIPGZTHfvfbuIH2O0aL9uifGPlO6U+1O7F+659xS9Iv8EB0
GBzayCJydDiCbpwoJ3uXt3fI0p2fiYx7GqRcQ+1fGYon0tLw+WDqsNNncMtQ7a8dCs4tlTuo1Czc
OXmYLC/frhzqtbxIr1KD/UTsrMvBNEMVUU/3I5cgXmMCTIAJMAEmwASYwMUl4H+kdXH1MJUeND4O
aVQil67dT57ZgrQ5I/E+5eTL1I15t8mc6tN0+0YRcn+0Zw9qht+Ed+Y/I+/qU/DBvzCRrFTDdc9m
QnDvk2lIL8+VOxJ/ei/dS8X7EnnnfbSjHEWLfo5vZN+Do5tXYAdleVx77+OYHTACMfNo945yvPMe
lRt2GE+krpMDiLqKKfjzL6Mxv4hCxrQCpM66FdHvkySqe4MzqDS0SQG0tKT9rMw7F3tM6/fQ9nAz
Llrau6F156rduSZWyvHso4tx8zf0jXRv/ODvIfNXC4n9ODz9JqXPPJyL3IdvQ92ixbjuk3U0l0GU
jUXa/Z7BvtgehNgf0gBuB01gfZaC7DlDIbNfor6LUcbxlv7vgaiiLSERt6lB+6o5WD04G3h/s9xz
3YhQ+RkUeAoFRQS7qAunsqPwfjqt0xJz8whqNhRxsWTNgVV4/sXj+JRSgqiT8MPvE/GgACSlpsqy
7m//RksTbYmNw7eMugWN616e/n1IkaldQkIRNqQdxQtNBzA1uQI5clJwJz6qFGBolMkLE2ACTIAJ
MAEmwAT6iACFwv1hGYGffLATtpUvYF055e9TsCyW2HlZ+HXubJlmERSXit1rbJhDgfYTMtiMQtrm
DZgtZlg6gtWr0Go1t/dh0+/DIhpKFND00Ee/P85tn/yiZX0ETXwAVZs/RQrdfjI3XQ41kJj1Jn6i
XcKdnXsAWXR3mhWr1IEGohLx5mtPygFE3ItVWN71PFbRLRq1sQXdn30nZmiTct0aFQF8Im0peh8N
pxdCZJWY1w+AWdsw4+LWsPFLCIIpN9+4iHkTGnbn5mdfFAE/DVxuT8UHb16HpQ+no7yABjpiiU3E
5qxfqPMh1C1u7zeQXjuz2vDAiiK1P4nXzi1Pyqv2zoKDvfQb5fev3r0G7XRrznUr0mXRWWmb8YvZ
4+R6WPR87Mz+Fx5IL4C6OwrZO7eofoAwPPbKTtT96AEUyWCfUncKNtANdEwOA0qZOioMT7xGTAUx
XU43qf8+6IXKy1U/GatPCnZ8io+Eb867DxHGwYNegT+ZABNgAkyACTABJnARCAxSaLkIci9Y5JEj
RzBp0iQ0NDTgqquuwtmzam6GrfM0zlAWiMghD6Grsp6LQzyZlXJhBoeEiIu2vb/Qk2FPUwMBgynF
Jai7eKkfpaiEUfuei6qbg3QLM9Wts24TIu9egeU76faUhpyQnur33PZF5CKNpaffiqfL0pX5EG9w
PIHQd72/QsJCziGxRwiitk7T/zb0vIQQfVKGUT75wWlyFO+stbo++tAopjfXbdZtiJhJdxd68xAy
br+hN0WzLCbABJgAE2ACTOASJ3DFFVfgq6++kg/xPHbsGEaNGtVnGl+MkPiiKh8kgmWTFgKCQrxO
EjWpcm67AuguMd5moWpSzPTzV7eQ6LlYjhX0j8Af8OPtSc6Jqz3V7422zw2GZ+kAr4Mwz1LG7z3Z
ZCzrvk5thZnkJJn6QQ913RvqpW82VBWKlKFFeGw6B/u9BJXFMAEmwASYABNgAn4Q6HcBvx82XQZF
huHHB95E6EE7xAVzbxewLwMjB5gJZxA4NRvFC+7t86cnDzDQbC4TYAJMgAkwASbgQeCSDfg7Ozsp
VSME4iFPgwYNkn+BeOg+IL6+tvbQgLBzwBjZ/BoOlQ0Ya9lQJsAEmAATYAJMQCMgUnpEJv21114L
m83Wp1wu2YBfUBhMt0hsa2vrUyDcGBNgAkyACTABJsAEmAATuFgERHzb18slG/CLq/si2C/Q7qbS
12C4PSbABJgAE2ACTIAJMAEm0NsEROZKUJDZjNTebhG4ovdFskQmwASYABNgAkyACTABJsAELhUC
HPBfKj3BejABJsAEmAATYAJMgAkwgYtAoB8F/A6a4EC3rPFrobL+Fu1Rnmi3tyZW9KZeZor3ps5m
7fi5j55d4H9/GBldLDuMbXizwYETLS040dZb/e6tDe/bHP6D8i5A30rMe+MQ6DV9dL28fn5d/exV
mQvf6GhDU9OJC5dzThIEQ/ceF+et7i/3MmoTNrSdaEFLywl0eNvtVQ8HOjo6TI9rG+33Js5h66C6
53dsCZkeZnrV7vw2qjZ1eDRgazuBr+FUcH4mcC0mwASYgA8C/Sbgr9twF4KD18OfKbx1a6ns6oM+
TD63zR21v6V2g3GwQ63XtHcDcnY1nJsQrXRv6mWmQEfdetL5XqfOZmX7Yl/t6mAEr/SvP+rWTnX2
nSf73tLVvB/asDkpEMPpYRjDh671y996Sy9b3VoEBv/2wtu01SE+MBirD/pztPjWvtf08d2E3HOx
/NXoSz2o0Iu7bdjy4FDcX/pJL8rsWZTn+fHwlhR53hLnLvfXVOzTzmVC6uFdOZg0KBhDh4+iB8AM
x5DAScgpP2zaYFvddsQPCsSQIUMQHDgIa/d2Px+2HVyL4CG3o8bQFhxN2JwSTz4+hOoGY1LKBjQY
4v7atUnyjmwit1V9zXWdw04cROqkQSRTbTPL7BzcUYu5Thm6rEGYu7bWp10nardQHdWmIcGBSMra
BX3I1lzxUwydtgFGU3wK4h1MgAkwgUuUQL8J+CW/mMF+PY3VToVjBl/dK8hDIx9BRVkVIoKFOBvK
U59C8adfnpfsQKoVM1i8X9wlOHCIbODit+SfHeMfqkLVYxF+FbZjmJORO3u/qvtVyLQfHMfw+yIg
u6oZiv2nCPdLYu8UsgvHpcfKXfBM+oAReKmsDA9FhF6QYr2mTw9aXCx/NfpSDyr02u6O2o2YX5qM
t56b0msy/RZkOD/aO47TySYTNY2NqK+vN7x24RbNLVr2ZiEqIR3T88vQfKodXe3NKM0ej/R7orDl
sI/wloLpBTEPYUh2BU51taMqLw5LZi5CnTNwd8hBxNDpS0jt8TCeg5r+8DIWbByCsvpTaG+sQszG
p/CzrfrgogN/ebsIcZklqK6pRlUVnTOqf4NJUtcObF40HS+Pz0NjexcsJUuxMmEiyvWI3BNQ8His
FPXpVV1TQzbFyRKx3xnhWVL97mjA8qnz8c/MUrR2daGxuhBFKxOQv09tYMKD2ciwPIWXte/ehfBW
JsAEmMClTaB/Bfw6S1sDNmRtwMHacqTGxyN+bhLW7qpz/n0sfmQsn9ZgS04KJsXPRWrOdrQY/lu2
tRxETspcTJoUj5SsLWjSf6yk3LXYtWsDkkhuTnkDbKca8NeP2xBAUVhT+Vqst5Dsp2KwYV+Lqo3j
BHatTUX8pEmIT3oB5YeNV1VtOLglB3NJVtILJPcvlRhmMinb0VZHdqUgXtqU4mZTUzn9s7B5FzZn
JXm16UTtLqQmzSUWqfhtSQXppgb9OjLjZ1tdOV4g++Mlmy2uq2zS/hxs2b4ZqXMF1xRsOajZqQlo
2LsZKbRPcF27vdbJXOzuaNiHnNQkYkFcc1xc21sa0PCFjGalFDM7tWbkh5G92OBTb9rns09VSf71
A9m/Ni0HlVQnfUY6tlspfaCpHDlrt5AvUR8T272aswhbswRDzYca9PhI86G9+6g/JMNU7KprwmHy
HVE2KTUHB1t0h5PKud6M0ZHYamvBdtFu/CTMFb5VZ/Qt4ETdLrxAfT4pPgmbd21HDh0T6hXTL9Fg
+RiuYakDdeQ/ot/iqazxWDHtC099XJqSbubHIMgzRJtJ0leSkEO+YrS6J3818zOjGmLdl995lmuh
Y0T1e+qHlCzsdXaaFELHlmAdj7m0z3gcm/mdexsd2PHzJYjLexYT9B0dDT7liiJmdpr7tN6Ar892
YNho3Dx2LCZMmGB4jYUa77dg08yVQEYZNqTMwsjwUASFjsT9ywog4uO//a3Zq+CGPRtQikwULItH
eFAo7nhuG6rKXsIIbZQq/pUTg4jkZDXINgo5eXgvDULm4gcTwhE69g4kJAKlrafVIrZGlNGB9/hD
d2NazCT81x134I5pE9SnqtuO4PelQOGvkzE2NAjRD65ENtXKf7fOKN61HhCOKaI+vaZNGYEPiysR
k1GBZfEjXWWMa44vcXVMIn737P24nu6aMXZaIopJ/e1/PqqVGonHCxOw8tk3LvzfN2O7vM4EmAAT
6EsC9ACAS3L5+OOPlauvvtqpmyU/TkFMvtIutrTXKAmAQpyU7OJSpTgzQa6X1HfJ8pb8RPk9LqNQ
KSvJU2KoXFy+RZXVWqXQuVyJSc5TqqrLlIwYkhOTrTS7yY1RkpcmK9lljdRUHsmKUaqp4a76Uikr
JjFTKasRNdoV+h2g/YlKcUWVUpLtoUehqkd2SQXtU9cT8mtUPbq9NypLhU1xGUpZFcnKS5Y2FFp1
m1TZqk3ZUo+EQquU0lVfIssmZBYrFaWqvUCCUiNheTRE7IT9yfllSk1ViUK/uQoSihW7KGbgml9W
pZTqOlhUQfWlS2U7GYVlShW1I/g77WmtkDpBcDXIFdrXZMcoyKzWFDG3syYvTonJVhkZ2QvdfOpt
1qfUqsXvfuhSqgtVG5Mz82Uft1vypZ2ISVaWJi5VqloVxd5YKrfFJOcrFVWlylLhQ8hQGgVEA8O8
klIlL5n8VjCOWaoUlxaqvJeWaSzcP9otgmme6uNKq5In5QrfqlAKM9T+L9T6wtnn5OMVZfkqe8RJ
P9VZZVefkg1YS1RfEv1WUZIp9VlKvq0o5n3hro+7rkY7vR2DVo252ma2bDMuW/UBp+4+/NXUzzzU
UMz8zuBLXdZCqUNidgn5Z5mSnaj1mZTXpRSL4zghW6mqqVYKl4p9cUqNcF4zv/PUpb1a9kNJo6go
FhO5tNfUzh58Woo3vLmdH2m7JV/4S7JSYbEoNTU1rpel0Xmsi+MpT/MngyjT1Zo8kkvHQqbTr5OV
Mu28Kyp2tdYr9eR29nrBmxgazkF6vydmFyrFeepxlldNBxQt+jEljxVxvAjdKuq1feL8pvWH3KJy
jcnzdS6VheSbtVicd+lcqHeJa5fPNXtzmexH9RhRi9mb1WO+TFXXZ13ewQSYABPwh4A4xx07dsyf
or1WRjzx65JcTAP+LjXgX1omw3TSv1XJJHh6gCN//OK0wQHttdAPPxJL6OdX/yFcqsjfKArQurTg
LU/8Mmlyk0vUHxoBRg349B+uLqUwzjV46Kovlj9MhRY1sBJ60JUnRf0hUtcTDbLon35tn5Dssdib
ldLCYkWL7+mHs0oOavJqVNnSpoRCaYOoKQJjJJfKH2+5HqMHiopyqloEWLrO7u3oP1xLi6uU1i67
0t5sVWqszWoQoNmfWaFz1X5YZQDeruST7TGZFWpZEqv+mBJL4ij1Q7aikxCDo0wK6JppnzGIV3qw
01jWyN5MbzW48dGnWp/43w9WlbtFjRBUHWKUKt0wnb3BVkUL9GRfaQwzNIZ2LdDUXdUqAjHqK4M4
ZwcZA2y93QpngKEFjxkVsrz0aX0ATFvUwZHW56SDDOak71C/0cDBGBxZirOV/AoK+HvoC6M+TiX1
Fc1O78dgs5JBx0Fises4aq0QAw11EGrur+Z+pjevf/rrd62WMqWwpNrpu40V6jEiBvJ0xKiDq6WF
irWZNthbFUuNVQ68zPxO10H/VHkZg0vfcqnHejieRMDuy6f1Fl2fkoPBH/SLHsYAWq7rvqf1n35+
cUkyX1OPNRro08DJWl+j5CfTYN7LxQXjsatLPGVRz5eIS1QS5YUSKPk1qoPr/l5YVa+0t9O5ULt4
UkonkC6rqKcNZjVhwl79woAuv9unvV5JJj9MKLR02+VzA5131Ysg+XTmMCzaMZWtnY8Ne3iVCTAB
JnDOBL6OgL9/pvQQKfrDGuNH6TnKQRhOl/H1hFH7GfHP8a3aX9e0XTzQzNKCLvqA3PoyJgbTZC6a
cBY8jv4rkIua8yPkfvtbw7Vtnh92kGjgjJqeYv9SzeNYEDNUm2Q2HOm02/L3o7B1HEU5rUdHDBU1
5DJ+CoVhxrwGfYf4DBiJSRPO4vlp6iSz4OEz6K9z1yJtio9R/+KmzYHCpupGOZFMZF7EPDjNaW9w
mC/9RTN3Ud5tMl6ePwPDaXLakHt+CcsJu1veeJcOklqbMjcBlnILOuhv9f2VZNvKmQjUJsRFzadk
d/wTn6tg6Tc5zCknaML9WLHiRxjpmZDeg50k0OtirrfwAx99eq79QH/vCx+AXTdKfBmGEIMdknf2
na78/tAIzKdSeteK+iOuVX2zS3Qc4jBcc1W7lO7fXBSqiEBnCpjaF1j9V5lW0PzPSsQsdPl46Ojv
QBwCrsQpUVssp3DYAiy8PVL9Su/RP1qGlPixPfqcs4KPFWGn12PQdhJiymr0hKHOmkHXC58UNdTD
1Ke/+uNnUorhzQ+/uz56Gka0bHX67riZ4kgdonl6OB7bWIy4lxcgatQQOi8Mx6t/aYSDTgnmfmfQ
Qa6Kg5JsdHaCb7no0U4Tn/Zs1ut3SsmJyQMNLOVj3OnXSP388DnVb0lH2RuBBsfW5HSIFLwW9/Qx
9yZESs+DuGnCFKTkFZJ3l+KPH5mVF7U78HoiHSWZFbDvfR2vv62gJj8BT03Nl5NjQ6NTSL8P8cQd
ExAqUoueWyn9+fBn4hx7VjYfKA48udhQJ/J/xLHRcZAmHbsm5uYYJqq3Wd7FRpLys4RorV4P5Wky
8iQ67xYl5KF5ewqud9WitkZjlvE7rzMBJsAE+hmBfhvwS852NUgX6zIQN8LXoy/nNjXIsp+hH0LK
AKWrN+jqslNc14rqiirMHq9FZKK8Qa6zutuK85dHbi1t7KIJnl2w06vZUo3q1DspH3YEptPeL75w
6Wg/fdJNivGL7fAWjJuxAONTK9DY2g66rIVEYwGx7ssm2mWptDp3B3Sn4ZJEt8S7/q4X0GVvR72l
Cvmzm7GA2q3VctBFEDDiemeUicY/lyJmVhRCg0bgm7SPrpbRD7NdsutqtaKiYiW+GUzIRAeQeU4y
bbVYa8jj1xXwy069sPHTRG/TPj3HfjA26WtdxHOWAw2u+QuOkzjQrbCr37vt8meDBEoDDSdQoOVj
GgJS/pDw1OHj42DZe9ipg+PkEVhou6G41soQjKeRwF+Otjpbbdm3GTlbDuK8+8IpiVYMx4rrGFS1
OHPWxUDXS7CT/Hz5aw9+ZmxarPvrd3UbFuCeJR+ipNqK1nY7TtXkUW0Z8tKnDV+GTUHRqS6carSi
rDADLz91DwpqKIg18TvRvtsilTFuMZHbg52mPm1swnR9MOjQ9L6EjsZc8oslv9vj9CG1YAtWj5qI
iS/t815PbjUMWAPoogFtC9I72KSW2JXx/cnOiwIxd95DWypxlM49Yn5UCt0Zx3iKG0Z7xZkoaFwM
DSoqcbhZ96cufP5PGoaL8VXwN7GNJuZS2hJqqmvwyDf187gDh7YvoWzLdNwaTuX0xUf5ttoNGEqT
kYdllqHr7ee6X6iwfeLlGNeF8icTYAJM4NIn0D8DfhExnPNyRv6wjZ82l2qmo1Dcei7AAcvW5Zg+
cwYO6b/9pnLpB4eC2sp/1kHMuwyNuhP0lzFWbNhNk4ID0FH/Hu6JmY6MaiqEUZhBSfmrU9eg9gTd
57qhHD9Pt/ictGu3qxF33B23YixdWtr32hqI6+fmi2rT6Mn0z0HlAry2r4nikyZs+uVTVE38DHdf
bI1vISpqHDb++RQmRP8X7pwyiQrRlU7tB1vUWrLif3GY7pPdQreqS98IzI4ZQVtH4nsZNMluwe+w
r6kLAfYmbFwUhZkz3wWZjvG3E1e6k8VGukWfQ0xkzp2KJel/M1yhVnU5Pzsp7jLR27xPz60fVC27
vxtdbvTkWQRiPjaRrTa65/reTWvkvzE3DaNgw1iwuxi/t4RG3o4ECnJ+nku3B6T7qYu+SF1N8cut
42TAFHnX41KH1btq0dJ0EKuf99Xn4fjObKDooU2obaFJyHR7w5dogFf8eSANUM/H5zQTzOwMmoj5
5PsrZ6yhCcrUJk1Gz11C+iU8jpsJkbm/mvuZJ0C//e6MOMCnY/LUmxDuqEcBTa51HSPH8auoKIz6
3f/RYXsTvn/HdLUZOibM/E4t5HoPHS/+ZTlpcAHfcns8ni7oPCV0oiPZchgHamtRe7AWBw8epJf6
2dAmAufrkbSRBj0bH8KDWdtxmO7Bf6KJbhqQcg/IzVDywr1CSLcl+j7hZ+l4fgtNwnZ0YN/6HPL9
BMTdbIyqXdVcbhKIcYR19YxM1Q/bGrBe+Gyc6hNXh5zGRrozjjiHOeiYKl+bSd4fh2mRJDcoEo/T
KW7+zzbReddGdwHKxRILsOy+GDqHh+OmKVMwRbymTcHYcP0fiy4ceZfE3x7t/FdUauWtPN156Lmp
wq5kLJ87Dh8RM8GrroEGfIZFeNBNI8iBeWECTIAJ9EcC55x41EcVuufwU06rnpdvt8rcTFf+qZqn
rOdXivxmY36npZDqJhZr+e92paY4Q6G+cr4yS6yqVV7yWtXJfq4JsJZidbIZkktknXZrqXMCsZAZ
R3nAztzPrnolW8tV1dtzTnLtxrFZyZcTCVW9YmiCaCLlXidoE9O62SRywbV5CXTFXanKVydmSh0S
tYlqMj/Zs6EupUybQKzrlCfyucWi2U9Ri5NNYnaFc94ATXjQcna1/TR5r8I5QZG4ahNeVbkJSqlV
VcBdd//tdGdvojfZ77NPpV3n0A9dFpnDq/uWmluc7JxbITlRe/rkXtXWGCW/Spv34OGban2D/4h+
0/1YFeZ8lzngxrkYlhI330rILtMm9KpVGivUidNChwSaXyFyqWVOuqcfU7/lGXwLifmK2m3mfeGp
j1NRseJhp8xJJ7/Rj0Ga4e7eJk1Gd6U/9+Cvpn7mpoVQxC+/E3NKEgzHfHKGehzrk6Bbqwu1ic+q
bydklGjzLMz8zkMXLWfcNa+BZvX4lEt1Te3swac9mpa59Qa/8pnDTwz0uU5ChLUsT8730M8FwoeK
q/U5PB6NaF+NfiduaFCoTbw1ltb9XpsKo+5qt7qfD2MylOpWMdNdLO1KWZ56YwNVlzilxDk3inq5
tVqe83U9M/RztlrZy7s6h8rpj15K6Jvaa7SJ+Qb/EO3EGSYFt1Zl0vGVqFh1dfXK/MkEmAATOA8C
4hzT15N2Bwk9qeFLbjly5AhuueUWdHZ2Xhzd6OpUG13gDA6l29HpF4X8bMlBV5kQQPdLd9ajJzSq
wij1xbnRKc3W0QZ7IN2KLsi5yeeKLEt/xIf6U9hTCqUftNkDEe5HXfm0S0pTDxa349Pl2GoRHzwV
j1jakRIpsm5JD6/2dMj5EOHErtsidCC5oSS3OwlX6fO106veutge+vRc+kEXafrpp62mMnrcqfuW
u/807MpCzuFbkbdsluy/E/uyMHzGx7DaX8dNPsCLp5TaKenH07fOty96VJ0K+GpT1u3BX0VdMZPC
q595Nu5XX9joOCUCPo95nXVoN7839TuDLg3bkzAx61a0U6686+jwLVdUNbWzB582NH0Bq6RfhyCt
ng99uI+7fHqScxvVCQ4Pd50/3Ev4/Kb6BJ0jvJw/VM4OH3J1ju7Hgs+Gem2HDZvjg/H241a8/cRN
vSaVBTEBJjBwCYiHC1LATw88HNVnEAZuwN9niPtRQxTwT6KAf371KSyb5v0v+n5kzWWtqqNpFwLF
hPOEZGSMP47VL1NiRX4N3k6Zclnbfekb14CUQRMxgY+hS7+r/NSwo24DhsTsNx1M+ymKizEBJsAE
JIGvI+D362IO988AIRB0M7ZVVwHOiW8DxO5+aGbA2PvR3mzBnvdqKGv8KlRY8hAfPbYfWnK5qTwB
/2Mtwzstp8gwHjRfDr176othKLOu9fnP2eVgI9vABJjA5U/gkr3Cf+jQIUyfPh2vvPLK5d8LbCET
YAJMgAkwASbABJjAgCCwaNEiiNT1iRMn9pm9l+wVfjG1IJzyQ996660+g8ENMQEmwASYABNgAkyA
CTCBi0kgLCxMPhvlYrbhKfuSvcLvqSh/ZwJMgAkwASbABJgAE2ACTODcCfTP+/Cfu51cgwkwASbA
BJgAE2ACTIAJDEgCHPAPyG5no5kAE2ACTIAJMAEmwAQGCgEO+AdKT7OdTIAJMAEmwASYABNgAgOS
AAf8A7Lb2WgmwASYABNgAkyACTCBgUKAA/6B0tNsJxNgAkyACTABJsAEmMCAJMAB/4DsdjaaCTAB
JsAEmAATYAJMYKAQ4IB/oPQ028kEmAATYAJMgAkwASYwIAlwwD8gu52NZgJMgAkwASbABJgAExgo
BDjgHyg9zXYyASbABJgAE2ACTIAJDEgCHPAPyG5no5kAE2ACTIAJMAEmwAQGCgEO+AdKT7OdTIAJ
MAEmwASYABNgAgOSAAf8A7Lb2WgmwASYABNgAkyACTCBgUKAA/6B0tNsJxNgAkyACTABJsAEmMCA
JPD/AYkuGFwKqOV0AAAAAElFTkSuQmCC

--_004_CE92D013F2111bradscoraidcom_--

From bnordman@lbl.gov  Mon Oct 28 12:46:22 2013
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 0FDB721F9F2B for ; Mon, 28 Oct 2013 12:46:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.311
X-Spam-Level: 
X-Spam-Status: No, score=-5.311 tagged_above=-999 required=5 tests=[AWL=0.665,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S2zjFkL0JaYp for ; Mon, 28 Oct 2013 12:46:17 -0700 (PDT)
Received: from fe2.lbl.gov (fe2.lbl.gov [128.3.41.134]) by ietfa.amsl.com (Postfix) with ESMTP id AF2A121F9F26 for ; Mon, 28 Oct 2013 12:46:09 -0700 (PDT)
X-Ironport-SBRS: 4.8
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApIDAMa+blLRVaA0lGdsb2JhbABWA4JDfE4GrDKJZohMgSEIFg4BAQEBBwsLCRIqgiUBAQEEdxIWBgMBAi8iEgEFARICCAYTCYd+BQMFmWCeUY4WB4EWEQEXBguEGwOJP45LgS+ObBgphHEcgSw
X-IronPort-AV: E=Sophos;i="4.93,587,1378882800"; d="scan'208";a="33438298"
Received: from mail-pb0-f52.google.com ([209.85.160.52]) by fe2.lbl.gov with ESMTP; 28 Oct 2013 12:46:01 -0700
Received: by mail-pb0-f52.google.com with SMTP id rr4so5420836pbb.39 for ; Mon, 28 Oct 2013 12:46:01 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=KCaM1fucsWu1qT4tJsSEwzVuZTXzl2iNuAqGnjQZqoY=; b=ZLzo+Rr6Imd+Pmi5NmV7YvY4EDNg1Lbn8KkRwXEzT65aCt2+rzEt78DvGT2F7wLCA9 FfBkaZDnGC9r5zbRzMtZ2cvmb1gXcnMWu/e/B+/uGvLyoMpz+BtLYDFNZcTDOBTHLhd0 Bfv7LAQhGP4pezEGuabk66W+GqOUHH7rR4HnA0hTc3kpSUrqCG9FNBmXT0hTFWS+UdO7 IH9vlHNpeBXjW13bVBGBGBTEz9I6y3KKNyco07hEDKCnpNUIP5nNcZLrsOXzEuhAtuk7 OHMoBwLfvqL4xPFsCBPJzZJTuAxv6KEEVNzVPG8OHruzg7L9o/mC1Ad1U//1dPvjT9ZR nVcg==
X-Gm-Message-State: ALoCoQmchjc+eVt4mtFDmzVldXy4uIXGFlld6MO4toNFhql7ZP4fO6tC4ubDMrTRtLvOFVLdLpgzd8Nti1mceodV/vi6Lg9iQXyr2OtJVvIlYRD8k5mBcYiJzYRw1YtfHTOr8JvF/X/w
X-Received: by 10.68.134.65 with SMTP id pi1mr17928213pbb.59.1382989561694; Mon, 28 Oct 2013 12:46:01 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.68.134.65 with SMTP id pi1mr17928202pbb.59.1382989561496; Mon, 28 Oct 2013 12:46:01 -0700 (PDT)
Received: by 10.68.148.134 with HTTP; Mon, 28 Oct 2013 12:46:01 -0700 (PDT)
In-Reply-To: <20131021182142.32521.64947.idtracker@ietfa.amsl.com>
References: <20131021182142.32521.64947.idtracker@ietfa.amsl.com>
Date: Mon, 28 Oct 2013 12:46:01 -0700
Message-ID: 
From: Bruce Nordman 
To: eman mailing list 
Content-Type: multipart/alternative; boundary=047d7b10ceaf8a974a04e9d2593c
Subject: [eman] Fwd: New Version Notification for draft-nordman-eman-er-framework-02.txt
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Oct 2013 19:46:22 -0000

--047d7b10ceaf8a974a04e9d2593c
Content-Type: text/plain; charset=ISO-8859-1

A new version of the Energy Reporting Framework is available:
  draft-nordman-eman-er-framework-02

The major update is to specify the requirement levels of the
basic information elements in section 4 more precisely
and to provide some illustrative examples.

Critical review and comments welcomed.
Thanks,

-Bruce


---------- Forwarded message ----------
From: 
Date: Mon, Oct 21, 2013 at 11:21 AM
Subject: New Version Notification for draft-nordman-eman-er-framework-02.txt
To: Bruce Nordman 



A new version of I-D, draft-nordman-eman-er-framework-02.txt
has been successfully submitted by Bruce Nordman and posted to the
IETF repository.

Filename:        draft-nordman-eman-er-framework
Revision:        02
Title:           Energy Reporting Framework
Creation date:   2013-10-21
Group:           Individual Submission
Number of pages: 28
URL:
http://www.ietf.org/internet-drafts/draft-nordman-eman-er-framework-02.txt
Status:
http://datatracker.ietf.org/doc/draft-nordman-eman-er-framework
Htmlized:
http://tools.ietf.org/html/draft-nordman-eman-er-framework-02
Diff:
http://www.ietf.org/rfcdiff?url2=draft-nordman-eman-er-framework-02

Abstract:
   Managing energy consumption of devices presents new challenges and
   issues.  The EMAN Requirements draft identifies essential
   capabilities needed to accomplish this.  This draft describes how an
   energy management system can use EMAN to gather and interpret data
   from individual devices, and how some of the Requirements are
   implemented in the model.  This document focuses on Energy Reporting,
   though acknowledges and fully includes the limited control functions
   specified in the Requirements draft.  Topics addressed in detail
   include the topology of power distribution, reporting mechanisms, and
   the various roles of devices, power interfaces, and components.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat




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

--047d7b10ceaf8a974a04e9d2593c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


A new version of the Energy Reporting Framework is availab=
le:
=A0 draft-nordman-eman-er-framework-02
=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 
The major update is to sp=
ecify the requirement levels of the 
basic information elements in secti=
on 4 more precisely

and to provide some illustrative examples. 

Critical review and comm=
ents welcomed.
Thanks,

-Bruce


---------- Forwarded message ----------
From:  <internet-drafts@ietf.org>

Date: Mon, Oct 21, 2013 at 11:21 AM
Subject: New Version Notification fo=
r draft-nordman-eman-er-framework-02.txt
To: Bruce Nordman <bnordman@lbl.gov>




A new version of I-D, draft-nordman-eman-er-framework-02.txt

has been successfully submitted by Bruce Nordman and posted to the

IETF repository.



Filename: =A0 =A0 =A0 =A0draft-nordman-eman-er-framework

Revision: =A0 =A0 =A0 =A002

Title: =A0 =A0 =A0 =A0 =A0 Energy Reporting Framework

Creation date: =A0 2013-10-21

Group: =A0 =A0 =A0 =A0 =A0 Individual Submission

Number of pages: 28

URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.ietf.=
org/internet-drafts/draft-nordman-eman-er-framework-02.txt

Status: =A0 =A0 =A0 =A0 =A0http://datatracker.ietf.org/d=
oc/draft-nordman-eman-er-framework

Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/html/draft-=
nordman-eman-er-framework-02

Diff: =A0 =A0 =A0 =A0 =A0 =A0http://www.ietf.org/r=
fcdiff?url2=3Ddraft-nordman-eman-er-framework-02



Abstract:

=A0 =A0Managing energy consumption of devices presents new challenges and
=A0 =A0issues. =A0The EMAN Requirements draft identifies essential

=A0 =A0capabilities needed to accomplish this. =A0This draft describes how =
an

=A0 =A0energy management system can use EMAN to gather and interpret data
=A0 =A0from individual devices, and how some of the Requirements are

=A0 =A0implemented in the model. =A0This document focuses on Energy Reporti=
ng,

=A0 =A0though acknowledges and fully includes the limited control functions=


=A0 =A0specified in the Requirements draft. =A0Topics addressed in detail
=A0 =A0include the topology of power distribution, reporting mechanisms, an=
d

=A0 =A0the various roles of devices, power interfaces, and components.









Please note that it may take a couple of minutes from the time of submissio=
n

until the htmlized version and diff are available at tools.ietf.org.



The IETF Secretariat







-- 
Bruce Nordman
Lawrence Berkeley National L=
aboratory
nordman.lbl.gov

BNordman@LBL.gov
510-486-7089
m: 510-501-7943




--047d7b10ceaf8a974a04e9d2593c--

From jparello@cisco.com  Thu Oct 31 16:31:57 2013
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 C529221E8134 for ; Thu, 31 Oct 2013 16:31:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.297
X-Spam-Level: 
X-Spam-Status: No, score=-10.297 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Q0=0.303]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DiDClhVjnwCy for ; Thu, 31 Oct 2013 16:31:50 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id A8DB421F9F5B for ; Thu, 31 Oct 2013 16:31:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=432; q=dns/txt; s=iport; t=1383262310; x=1384471910; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=1iTiXMRHTpgKtbPBnVOGymIGSBhbDzjh4iYpITzZySU=; b=OsvofvEY9HfJJnkaimOnDOu/rTCxETcjPsk+iKNt27A5mJ8k7p48/Iq2 6ykOihKql77OalsQYRv5xPE4xILgq+xUG2CQ4t4H+8eayWvzMPNvayCJD eZknbc03gNw1sOckHVnBKgkuP1hy66//Kh/s4JsxYn3FeAEJB/YbGMTxz c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgIFAJDnclKtJV2d/2dsb2JhbABZgweBDL9ogSMWdIInAQQ6UQEqFEImAQQBGod+Abxwjx6DWIEOA6oTgyaCKg
X-IronPort-AV: E=Sophos;i="4.93,613,1378857600"; d="scan'208";a="279275806"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-6.cisco.com with ESMTP; 31 Oct 2013 23:31:50 +0000
Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r9VNVooG004162 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 31 Oct 2013 23:31:50 GMT
Received: from xmb-aln-x04.cisco.com ([169.254.9.229]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.004; Thu, 31 Oct 2013 18:31:50 -0500
From: "John Parello (jparello)" 
To: "eman@ietf.org" , "Juergen Quittek (ietf@quittek.at)" 
Thread-Topic: JQ were all your comments addressed?
Thread-Index: Ac7WkWYYNOo+a+nZSQ6ZEhBvsZRGrA==
Date: Thu, 31 Oct 2013 23:31:49 +0000
Message-ID: <9C213D38848B89428F46808B16F6F0860167CD62@xmb-aln-x04.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [171.71.223.71]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [eman] JQ were all your comments addressed?
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, 31 Oct 2013 23:31:57 -0000

Hi Juergen,

Hope you're doing well.=20
We have Rev 11 out and was hoping that we covered all your comments in this=
 revision.=20

The only open issue I can see is perhaps a format that was more suitable fo=
r device manufacturers in the expression of the model. Brad sent out a prop=
osal for that as a table format. That's an editorial change we can easily d=
o for a LC effort.

Please do let us know.

Thanks
Jp




From jparello@cisco.com  Thu Oct 31 16:34:37 2013
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 1286A21E8136 for ; Thu, 31 Oct 2013 16:34:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.448
X-Spam-Level: 
X-Spam-Status: No, score=-10.448 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bGUY9taN3UMM for ; Thu, 31 Oct 2013 16:34:31 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 2CF4121E812F for ; Thu, 31 Oct 2013 16:34:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=177; q=dns/txt; s=iport; t=1383262471; x=1384472071; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=uJ9Ob0JiGhmVxXOV26FV7kyjHnYcwvnEMljJMrgIt38=; b=UuiPOuSCxbSX+zItimZ+cRKidm8WPaTWavVmTEj5JBbnxEjebQCpZvZN LJXGJovGjx/1IHkFVizrvbtO8vHuw9OnF/FkWwNA6TlpeFIj+dkeqv7YQ Jz3uCWpQPclLU+LRQWq/3Bqtpc1P+8rfTi8KlTMEA05pMV/KDR8+iD0vs A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgIFAJDnclKtJV2b/2dsb2JhbABZgweBDL9ogSMWdIInAQQ6UQEqFEImAQQBGod+Abxwjx6DWIEOA6oTgyaCKg
X-IronPort-AV: E=Sophos;i="4.93,613,1378857600"; d="scan'208";a="279247879"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-7.cisco.com with ESMTP; 31 Oct 2013 23:34:31 +0000
Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r9VNYUXC030273 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 31 Oct 2013 23:34:30 GMT
Received: from xmb-aln-x04.cisco.com ([169.254.9.229]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.004; Thu, 31 Oct 2013 18:34:30 -0500
From: "John Parello (jparello)" 
To: Rolf Winter , "eman@ietf.org" 
Thread-Topic: RW Did we cover your comment?
Thread-Index: Ac7WkcYuWGTuVOYpSHyLSyvUrJSMnQ==
Date: Thu, 31 Oct 2013 23:34:29 +0000
Message-ID: <9C213D38848B89428F46808B16F6F0860167CD76@xmb-aln-x04.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [171.71.223.71]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [eman] RW Did we cover your comment?
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, 31 Oct 2013 23:34:37 -0000

Hi Rolf,

Thanks again for all the comments and feedback.

We have Rev 11 out and was hoping you had a chance to look at it and that w=
e covered all your feedback.

Jp


From jparello@cisco.com  Thu Oct 31 16:37:29 2013
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 3682821E8136 for ; Thu, 31 Oct 2013 16:37:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.486
X-Spam-Level: 
X-Spam-Status: No, score=-10.486 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Q7atbVsRAwv for ; Thu, 31 Oct 2013 16:37:22 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 1F32221E8130 for ; Thu, 31 Oct 2013 16:37:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=298; q=dns/txt; s=iport; t=1383262638; x=1384472238; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=zGLYHRTnv5Q5SmLBokznYql0BNfs68wH3FVkpfDLUOg=; b=cd4e8KyBDyi2ujwEObmc4TPzWkHz4BT6lESAhPXr5cK3hrAp1ItHarNP IRBj0KBfcd3h5x8nNLektmnVUJbc/8dUH75+p0dx95l2TsgF0E2d/OSQG z4sZqO4igdQU1a44VNRC+hT3y3ohC2LF06LgrL/d1bSh35PeRjuSQWhos 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgIFAPLoclKtJXG8/2dsb2JhbABZgweBDL9ogSMWdIInAQQ6UQEqFEImAQQBGod+Abxpjx6DWIEOA6oTgyaCKg
X-IronPort-AV: E=Sophos;i="4.93,613,1378857600"; d="scan'208";a="279261421"
Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-5.cisco.com with ESMTP; 31 Oct 2013 23:37:16 +0000
Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r9VNbGl8020347 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 31 Oct 2013 23:37:16 GMT
Received: from xmb-aln-x04.cisco.com ([169.254.9.229]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.004; Thu, 31 Oct 2013 18:37:16 -0500
From: "John Parello (jparello)" 
To: "Bruce Nordman (bnordman@lbl.gov)" , "eman@ietf.org" 
Thread-Topic: BN Any items we should look at?
Thread-Index: Ac7Wkim/jAKQ+ddATf2oCb5BML8A8A==
Date: Thu, 31 Oct 2013 23:37:16 +0000
Message-ID: <9C213D38848B89428F46808B16F6F0860167CD8A@xmb-aln-x04.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [171.71.223.71]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [eman] BN Any items we should look at?
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, 31 Oct 2013 23:37:29 -0000

HI Bruce,

Thanks for your previous review on -09. I think given our approach we cover=
ed everything we could. We've looked at your feedback and text and feel con=
fident we have all the areas covered.

If there's any specific review of Rev -11  please do let us know.

Thanks again!
Jp


From jparello@cisco.com  Thu Oct 31 16:52:37 2013
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 BA51E21E812F for ; Thu, 31 Oct 2013 16:52:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.509
X-Spam-Level: 
X-Spam-Status: No, score=-10.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AMQCx1whyLdD for ; Thu, 31 Oct 2013 16:52:31 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 9FF1F11E80F7 for ; Thu, 31 Oct 2013 16:52:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1099; q=dns/txt; s=iport; t=1383263552; x=1384473152; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=hiv/8Zthvb4arRD3NlueQWuANktNornJzJGvz6VMMNk=; b=aRRotHD4zL/2os3DNOt6g7ps/NKrNpPpst9GFuDuVrzhlOko2iTQgkAp zKRT11VqT7LVxVzVo6vzabmqxMRcuFjSV6CQQqnQ6fJAyL7FGY2oqh1kd onpGkfkfYNuAfs0qCAEuISesHNKWJ3jYUdZdXmHOHC5O6Rf6MnsXzrfyp U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgQHAH/sclKtJV2b/2dsb2JhbABPCoMHgQy/aIEjFm0HgicBBDpRASoUQiYBBBsSh2wBmwihZY4MC4EHg1iBDgOqE4Mmgio
X-IronPort-AV: E=Sophos;i="4.93,613,1378857600"; d="scan'208";a="279251967"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-7.cisco.com with ESMTP; 31 Oct 2013 23:52:31 +0000
Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r9VNqUFg015579 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 31 Oct 2013 23:52:30 GMT
Received: from xmb-aln-x04.cisco.com ([169.254.9.229]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.02.0318.004; Thu, 31 Oct 2013 18:52:30 -0500
From: "John Parello (jparello)" 
To: "eman@ietf.org" 
Thread-Topic: @Chairs : Liaison work with ETSI
Thread-Index: Ac7WlEXoUOOAh1/dSyiO6N2UoxErlQ==
Date: Thu, 31 Oct 2013 23:52:29 +0000
Message-ID: <9C213D38848B89428F46808B16F6F0860167CDB2@xmb-aln-x04.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [171.71.223.71]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [eman] @Chairs : Liaison work with ETSI
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, 31 Oct 2013 23:52:37 -0000

Hi Chairs,

Benoit and I had a call with some of the members of (European Telecommunica=
tion Standards Institute) ETSI who are working on the Green Abstraction Lay=
er. (GAL) This was w.r.t. our liaison with them.

I don't know all of the procedures with a liaison etc but we met to make su=
re the work was aligned.

We reviewed their GAL spec and they intern reviewed the framework. The good=
 news was there was a lot of synergy. We gave four items that they could (a=
nd did) incorporate in their draft. So that was a good vote on our approach

They incorporated 4 items:

1) (GAL) Resource ID would map to (EMAN) RFC 4133
2) (GAL) Power measurement would have a (EMAN) value and exponent
3) (GAL) Power measurement would include (EMAN) caliber
4) (GAL) Two-dimensional Power States would map to an (EMAN) array of state=
s=20

For us that means we can identify, report power, and use states in a simila=
r way that won't clash semantically.

I'm not sure what to answer further to the groups so what do the chairs and=
 AD think is the next steps?

Thanks
Jp
=20