From internet-drafts@ietf.org Wed Jan 8 12:09:03 2014 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 970881AE15A; Wed, 8 Jan 2014 12:09:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id afvuJIjfxrli; Wed, 8 Jan 2014 12:09:02 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F6E01AE0AE; Wed, 8 Jan 2014 12:09:02 -0800 (PST) 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.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140108200902.10911.46380.idtracker@ietfa.amsl.com> Date: Wed, 08 Jan 2014 12:09:02 -0800 Cc: eman@ietf.org Subject: [eman] I-D Action: draft-ietf-eman-battery-mib-11.txt X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.15 List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 20:09:03 -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 Monitor= ing Authors : Juergen Quittek Rolf Winter Thomas Dietz Filename : draft-ietf-eman-battery-mib-11.txt Pages : 34 Date : 2014-01-08 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-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-eman-battery-mib-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 Quittek@neclab.eu Wed Jan 8 12:15:35 2014 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AE891AE185 for ; Wed, 8 Jan 2014 12:15:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.14 X-Spam-Level: X-Spam-Status: No, score=-3.14 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.538, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hh2s_FLD1Gig for ; Wed, 8 Jan 2014 12:15:33 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 3E40A1AE176 for ; Wed, 8 Jan 2014 12:15:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 1402F106800; Wed, 8 Jan 2014 21:04:20 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IHuywPu1lDyh; Wed, 8 Jan 2014 21:04:20 +0100 (CET) X-ENC: Last-Hop-TLS-encrypted X-ENC: Last-Hop-TLS-encrypted Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailer1.neclab.eu (Postfix) with ESMTPS id EDB811067C8; Wed, 8 Jan 2014 21:04:09 +0100 (CET) Received: from DAPHNIS.office.hd ([169.254.2.18]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Wed, 8 Jan 2014 21:15:13 +0100 From: Juergen Quittek To: "eman-chairs@tools.ietf.org" Thread-Topic: New Version Notification for draft-ietf-eman-battery-mib-11.txt Thread-Index: AQHPDK2BB3esn8QvEUmgGrLa1e7rjJp7Qc2Q Date: Wed, 8 Jan 2014 20:15:12 +0000 Message-ID: <9AB93E4127C26F4BA7829DEFDCE5A6E8688C7EF6@DAPHNIS.office.hd> References: <20140108200902.10911.86199.idtracker@ietfa.amsl.com> In-Reply-To: <20140108200902.10911.86199.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.202] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "eman@ietf.org" Subject: [eman] FW: New Version Notification for draft-ietf-eman-battery-mib-11.txt X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 08 Jan 2014 20:15:35 -0000 RGVhciBXRyBjaGFpcnMsDQoNCldlICh0aGUgYXV0aG9ycykgaGF2ZSBqdXN0IHVwbG9hZGVkIGEg cmV2aXNpb24gb2YgdGhlIEJBVFRFUlktTUlCIG1vZHVsZSB0aGF0IGhhcyBhbiBlbXB0eSBsaXN0 IG9mIG9wZW4gaXNzdWVzLiBUaGVyZSBhcmUgbm8gdGVjaG5pY2FsIGNoYW5nZXMgY29tcGFyZWQg dG8gdGhlIHByZXZpb3VzIHZlcnNpb24sIG9ubHkgY2xhcmlmaWNhdGlvbnMsIHNvbWUgb2YgdGhl bSBhbHJlYWR5IGJhc2VkIG9uIGltcGxlbWVudGVyIGZlZWRiYWNrLg0KDQpXZSB0aGluayB0aGF0 IHRoZSBkcmFmdCBpcyByZWFkeSBmb3IgV0dMQy4NCg0KQ2hlZXJzLA0KICAgIEp1ZXJnZW4gDQoN Cj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogaW50ZXJuZXQtZHJhZnRzQGll dGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXQ0KPiBTZW50OiBNaXR0d29j aCwgOC4gSmFudWFyIDIwMTQgMjE6MDkNCj4gVG86IFJvbGYgV2ludGVyOyBUaG9tYXMgRGlldHo7 IEp1ZXJnZW4gUXVpdHRlazsgVGhvbWFzIERpZXR6OyBSb2xmIFdpbnRlcjsNCj4gSnVlcmdlbiBR dWl0dGVrDQo+IFN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaWV0 Zi1lbWFuLWJhdHRlcnktbWliLTExLnR4dA0KPiANCj4gDQo+IEEgbmV3IHZlcnNpb24gb2YgSS1E LCBkcmFmdC1pZXRmLWVtYW4tYmF0dGVyeS1taWItMTEudHh0DQo+IGhhcyBiZWVuIHN1Y2Nlc3Nm dWxseSBzdWJtaXR0ZWQgYnkgSnVlcmdlbiBRdWl0dGVrIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYN Cj4gcmVwb3NpdG9yeS4NCj4gDQo+IE5hbWU6CQlkcmFmdC1pZXRmLWVtYW4tYmF0dGVyeS1taWIN Cj4gUmV2aXNpb246CTExDQo+IFRpdGxlOgkJRGVmaW5pdGlvbiBvZiBNYW5hZ2VkIE9iamVjdHMg Zm9yIEJhdHRlcnkgTW9uaXRvcmluZw0KPiBEb2N1bWVudCBkYXRlOgkyMDE0LTAxLTA3DQo+IEdy b3VwOgkJZW1hbg0KPiBQYWdlczoJCTM0DQo+IFVSTDogICAgICAgICAgICBodHRwOi8vd3d3Lmll dGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLWVtYW4tYmF0dGVyeS1taWItDQo+IDEx LnR4dA0KPiBTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtaWV0Zi1lbWFuLWJhdHRlcnktbWliLw0KPiBIdG1saXplZDogICAgICAgaHR0cDovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1lbWFuLWJhdHRlcnktbWliLTExDQo+IERpZmY6 ICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLWVt YW4tYmF0dGVyeS1taWItMTENCj4gDQo+IEFic3RyYWN0Og0KPiAgICBUaGlzIG1lbW8gZGVmaW5l cyBhIHBvcnRpb24gb2YgdGhlIE1hbmFnZW1lbnQgSW5mb3JtYXRpb24gQmFzZSAoTUlCKQ0KPiAg ICBmb3IgdXNlIHdpdGggbmV0d29yayBtYW5hZ2VtZW50IHByb3RvY29scyBpbiB0aGUgSW50ZXJu ZXQgY29tbXVuaXR5Lg0KPiAgICBJbiBwYXJ0aWN1bGFyLCBpdCBkZWZpbmVzIG1hbmFnZWQgb2Jq ZWN0cyB0aGF0IHByb3ZpZGUgaW5mb3JtYXRpb24gb24NCj4gICAgdGhlIHN0YXR1cyBvZiBiYXR0 ZXJpZXMgaW4gbWFuYWdlZCBkZXZpY2VzLg0KPiANCj4gDQo+IA0KPiANCj4gUGxlYXNlIG5vdGUg dGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3Vi bWlzc2lvbg0KPiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxh YmxlIGF0IHRvb2xzLmlldGYub3JnLg0KPiANCj4gVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K From tnadeau@lucidvision.com Wed Jan 8 17:22:02 2014 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C3591ADF62 for ; Wed, 8 Jan 2014 17:22:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rb_YMdt1__yD for ; Wed, 8 Jan 2014 17:22:00 -0800 (PST) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 893D11ADF65 for ; Wed, 8 Jan 2014 17:21:59 -0800 (PST) Received: from [10.90.119.191] (mobile-166-137-185-108.mycingular.net [166.137.185.108]) by lucidvision.com (Postfix) with ESMTP id 40F6826AC13E; Wed, 8 Jan 2014 20:21:49 -0500 (EST) References: <20140108200902.10911.86199.idtracker@ietfa.amsl.com> <9AB93E4127C26F4BA7829DEFDCE5A6E8688C7EF6@DAPHNIS.office.hd> Mime-Version: 1.0 (1.0) In-Reply-To: <9AB93E4127C26F4BA7829DEFDCE5A6E8688C7EF6@DAPHNIS.office.hd> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (11B554a) From: "Thomas D. Nadeau" Date: Wed, 8 Jan 2014 17:21:45 -0800 To: Juergen Quittek Cc: "eman@ietf.org" , "eman-chairs@tools.ietf.org" Subject: Re: [eman] FW: New Version Notification for draft-ietf-eman-battery-mib-11.txt X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 09 Jan 2014 01:22:02 -0000 > On Jan 8, 2014, at 12:15 PM, Juergen Quittek wrote: >=20 > Dear WG chairs, >=20 > We (the authors) have just uploaded a revision of the BATTERY-MIB module t= hat has an empty list of open issues. yessss! ;) > There are no technical changes compared to the previous version, only clar= ifications, some of them already based on implementer feedback. >=20 > We think that the draft is ready for WGLC. cool. I'll call it after I see the pub update. Tom=20 >=20 > Cheers, > Juergen=20 >=20 >> -----Original Message----- >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> Sent: Mittwoch, 8. Januar 2014 21:09 >> To: Rolf Winter; Thomas Dietz; Juergen Quittek; Thomas Dietz; Rolf Winter= ; >> Juergen Quittek >> Subject: New Version Notification for draft-ietf-eman-battery-mib-11.txt >>=20 >>=20 >> A new version of I-D, draft-ietf-eman-battery-mib-11.txt >> has been successfully submitted by Juergen Quittek and posted to the IETF >> repository. >>=20 >> Name: draft-ietf-eman-battery-mib >> Revision: 11 >> Title: Definition of Managed Objects for Battery Monitoring >> Document date: 2014-01-07 >> Group: eman >> Pages: 34 >> URL: http://www.ietf.org/internet-drafts/draft-ietf-eman-batte= ry-mib- >> 11.txt >> Status: https://datatracker.ietf.org/doc/draft-ietf-eman-battery-= mib/ >> Htmlized: http://tools.ietf.org/html/draft-ietf-eman-battery-mib-11= >> Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-eman-batter= y-mib-11 >>=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 >>=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 >> The IETF Secretariat >=20 > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman >=20 From tnadeau@lucidvision.com Thu Jan 9 12:33:59 2014 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 870FD1AE403 for ; Thu, 9 Jan 2014 12:33:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5G8EBu-3K-Uf for ; Thu, 9 Jan 2014 12:33:58 -0800 (PST) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id D5F181AE16D for ; Thu, 9 Jan 2014 12:33:57 -0800 (PST) Received: from [192.168.1.108] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id DC4C226AD8D0; Thu, 9 Jan 2014 15:33:47 -0500 (EST) From: Thomas Nadeau Content-Type: multipart/signed; boundary="Apple-Mail=_8956E16B-569E-4235-8397-267375A0BB8B"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Thu, 9 Jan 2014 09:48:40 -0800 Message-Id: <35D4667C-0D12-4312-8885-2FD9A222274E@lucidvision.com> To: eman mailing list Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) X-Mailer: Apple Mail (2.1827) Cc: draft-ietf-eman-battery-mib@tools.ietf.org Subject: [eman] IPR Poll on draft-ietf-eman-battery-mib-11 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 09 Jan 2014 20:33:59 -0000 --Apple-Mail=_8956E16B-569E-4235-8397-267375A0BB8B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii This mail starts the IPR poll on draft-ietf-eman-battery-mib. Are you aware of any IPR that applies to = draft-ietf-eman-energy-aware-mib? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as a document author or contributor please respond to this email explicitly regardless of whether or not you are aware of any = relevant IPR. *The response needs to be sent to the EMAN wg mailing list.* The document will not advance to the next stage until a response has been received from each author and contributor. If you are on the EMAN WG email list but are not listed as an author or contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. Thank you, Nevil and Tom, EMAN WG Chairs =09 --Apple-Mail=_8956E16B-569E-4235-8397-267375A0BB8B 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 iQIcBAEBCgAGBQJSzuD4AAoJEPcO+I7eiUJZytcP/0CMr0hF76vurePBUYG1WUoV a3Ym1EqEZwsnoEwiyLjVh8kiglnGSzKb8zAtnHmleqVFWoUMrFX2UjFq/juwsh/7 yu4W4v70q6C7QWBufZdlkjG6QhaVH96JsGG9l6j/MsBuKvFnQrUkTYSdgAVmoprf cQwiauFmGqAc4NNTWIBN/+tv/vIhYVntJeZyGAO775p7lrZKKrmxev7QvxAQLw5g wKxZ40vLk39an8KdDErNbu/CB377k9W4h/xlG4t9sIlxAyBXov3VFTzAHgmklidv KsBNd67+se7AfmKjk8v8Eb8ULLCofkCgAZ8XVSsffe1cf4mmgMmQ5IsNUVJaOPml Ynel7shn0nv+bB9+oSN37l6aArOZP/r3rJY1FoYVYsZWwY/dkhIwTUim7ngxaiyQ jhFuqvPQJInro9CmFM93HY3T2tVp+dEqKOcU36Ai0adfI712ikzFdCmHR1lPccpC 8hYTQZ67djb32m5GiiUzHFXI5onU6ejLJhMU4kiHsqfIjwCvSWtqtwNCRdlReJjL eRghg8DQ7Ea5DQ5wAt3GmIr8CEq9jc3PRblUFW5Lkb1kgymaz1jOqlLCHXNJXpOH OpNTCIGdtwdydY5XgiMbRFAhdLIBYqdhIirbhMRjCCPBrjBbmYSaesjxK56essoK nptc7qgFSFu3hDr/e9iv =Mslg -----END PGP SIGNATURE----- --Apple-Mail=_8956E16B-569E-4235-8397-267375A0BB8B-- From tnadeau@lucidvision.com Thu Jan 9 12:34:00 2014 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7617A1AE16D for ; Thu, 9 Jan 2014 12:34:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YmJEEA5jWRJl for ; Thu, 9 Jan 2014 12:33:59 -0800 (PST) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id E245E1AE192 for ; Thu, 9 Jan 2014 12:33:58 -0800 (PST) Received: from [192.168.1.108] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 0CBDB26AD8DC; Thu, 9 Jan 2014 15:33:49 -0500 (EST) From: Thomas Nadeau Content-Type: multipart/signed; boundary="Apple-Mail=_1C5BA17D-C9EC-4EC1-8E74-6F9999F0323D"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Thu, 9 Jan 2014 09:54:21 -0800 Message-Id: To: eman mailing list Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) X-Mailer: Apple Mail (2.1827) Cc: draft-ietf-eman-battery-mib@tools.ietf.org Subject: [eman] Working Group Last Call for draft-ietf-eman-battery-mib-11 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 09 Jan 2014 20:34:00 -0000 --Apple-Mail=_1C5BA17D-C9EC-4EC1-8E74-6F9999F0323D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The starts the Working Group Last call on = draft-ietf-eman-battery-mib-11 that completes on Friday, January 24 at = 8AM EDT. Please send comments by responding to this message by no later = than this date.=20 Thanks, Tom and Nevil --Apple-Mail=_1C5BA17D-C9EC-4EC1-8E74-6F9999F0323D 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 iQIcBAEBCgAGBQJSzuJNAAoJEPcO+I7eiUJZ4hAP+QF4wd4ZEHbbvOpkwbG/NC5k bHGtq7oPSnMn0c7QyXhsK9fBjvE1aBKb8zmFbQwwQlQWuGjMI4liHXt6l3hrUd3o J3JvlGtN5f4aIJPYO3YkKl1zglq20g0JumKJvKv/svfSTHwc0EQKALf7YS2gmzgR Yj6EcNGwnGzvuz1ftYhhzvV0psHn+XgpV9Dn7B5IAQLU6PpfJuAC4DRWxAkWNePe QPXk/nAUGqZgFgtcjvIy1v9CfLJwVlUtaodRT/QeLk3A3M7KSnw5sGp408/WPdPS Q/fQUz3QEEB6t1XodaRk+fAUinjcDAdd/gdmlPDJEwX+YbgU25HeGZF5gI65XqVe lgNUgQzQMhn89Slm6OZ1+tToSNfgjYdofVygGnH+dckmZ72rn3IRcz6u7e5F7agL wWV7xOEPVVH68osvt+HtJ6WHil2mKXkwwDBfsmFcyPnhlZFKmGIlPStkIoBiySBC Cw9G9JuWN4sm1ZCfYzala4SLnxh3rqXgq+sh9js/5WWK7+/m0IsOCS7zqsg5Dy25 XclLie73LQQKGA10e7uAfHieZddzZ4+M9V+3WoKEFKVcyk1xxrOOGTpb85Ikjc3C WnTh9Dc2S7uiSz/BO4JSxR81mSZ8pkKUPII/QNhTv3VTsTAm9JD9ryD6uejYcjXf /N7vjCopf/fOvh081Sjx =sRdx -----END PGP SIGNATURE----- --Apple-Mail=_1C5BA17D-C9EC-4EC1-8E74-6F9999F0323D-- From Rolf.Winter@neclab.eu Fri Jan 10 03:43:15 2014 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F6D31ADFBC for ; Fri, 10 Jan 2014 03:43:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.14 X-Spam-Level: X-Spam-Status: No, score=-3.14 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.538, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qqPKlzuwP-yL for ; Fri, 10 Jan 2014 03:43:13 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 5B71D1ACD00 for ; Fri, 10 Jan 2014 03:43:13 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id C2BCE10687F for ; Fri, 10 Jan 2014 12:31:50 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id caxS9IYcyEeC for ; Fri, 10 Jan 2014 12:31:50 +0100 (CET) X-ENC: Last-Hop-TLS-encrypted X-ENC: Last-Hop-TLS-encrypted Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailer1.neclab.eu (Postfix) with ESMTPS id 98ED910687C for ; Fri, 10 Jan 2014 12:31:45 +0100 (CET) Received: from HYDRA.office.hd ([169.254.4.218]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Fri, 10 Jan 2014 12:42:56 +0100 From: Rolf Winter To: eman mailing list Thread-Topic: [eman] IPR Poll on draft-ietf-eman-battery-mib-11 Thread-Index: AQHPDXoqzUtxDuo7UU6XkoohMBAKDpp91vfA Date: Fri, 10 Jan 2014 11:42:56 +0000 Message-ID: <791AD3077F94194BB2BDD13565B6295D63B70315@Hydra.office.hd> References: <35D4667C-0D12-4312-8885-2FD9A222274E@lucidvision.com> In-Reply-To: <35D4667C-0D12-4312-8885-2FD9A222274E@lucidvision.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.196] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [eman] IPR Poll on draft-ietf-eman-battery-mib-11 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 10 Jan 2014 11:43:15 -0000 I am not aware of any IPR that applies to this document. NEC Europe Ltd | Registered Office: Athene, Odyssey Business Park, West End= Road, London, HA4 6QE, GB | Registered in England 2832014 > -----Original Message----- > From: eman [mailto:eman-bounces@ietf.org] On Behalf Of Thomas Nadeau > Sent: Donnerstag, 9. Januar 2014 18:49 > To: eman mailing list > Cc: draft-ietf-eman-battery-mib@tools.ietf.org > Subject: [eman] IPR Poll on draft-ietf-eman-battery-mib-11 >=20 >=20 > This mail starts the IPR poll on draft-ietf-eman-battery-mib. >=20 > Are you aware of any IPR that applies to draft-ietf-eman-energy-aware- > mib? >=20 > If so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3979, 4879, 3669 and 5378 for more details). >=20 > If you are listed as a document author or contributor please respond to > this email explicitly regardless of whether or not you are aware of any > relevant IPR. *The response needs to be sent to the EMAN wg mailing > list.* The document will not advance to the next stage until a response > has been received from each author and contributor. >=20 > If you are on the EMAN WG email list but are not listed as an author or > contributor, then please explicitly respond only if you are aware of > any IPR that has not yet been disclosed in conformance with IETF rules. >=20 > Thank you, >=20 > Nevil and Tom, EMAN WG Chairs >=20 From internet-drafts@ietf.org Sat Jan 11 17:10:15 2014 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B099D1A1F7B; Sat, 11 Jan 2014 17:10:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eolFaEX0sNRc; Sat, 11 Jan 2014 17:10:13 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6415C1ADBCD; Sat, 11 Jan 2014 17:10:12 -0800 (PST) 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.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140112011012.17251.59255.idtracker@ietfa.amsl.com> Date: Sat, 11 Jan 2014 17:10:12 -0800 Cc: eman@ietf.org Subject: [eman] I-D Action: draft-ietf-eman-framework-12.txt X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.15 List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jan 2014 01:10:15 -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 Authors : John Parello Benoit Claise Brad Schoening Juergen Quittek Filename : draft-ietf-eman-framework-12.txt Pages : 57 Date : 2014-01-11 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-12 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-eman-framework-12 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 tnadeau@lucidvision.com Mon Jan 13 07:12:51 2014 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 097CA1AE1D5; Mon, 13 Jan 2014 07:12:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BY15kfXGai_u; Mon, 13 Jan 2014 07:12:49 -0800 (PST) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id BEDD61AE1E1; Mon, 13 Jan 2014 07:12:40 -0800 (PST) Received: from [192.168.1.115] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 8CB6D26B2F85; Mon, 13 Jan 2014 10:12:29 -0500 (EST) Content-Type: multipart/signed; boundary="Apple-Mail=_F65514E3-433E-429E-BCAF-DFDDCB650C28"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Thomas Nadeau In-Reply-To: Date: Mon, 13 Jan 2014 10:12:28 -0500 Message-Id: <6EA2D6B2-EB15-4DDE-8128-81ED97BB05B1@lucidvision.com> References: <18241430.1388083851066.JavaMail.root@mswamui-valley.atl.sa.earthlink.net> To: "MIB Doctors (E-mail)" , eman mailing list X-Mailer: Apple Mail (2.1827) Subject: [eman] A single OID versus multiple OIDs for EMAN MIBs X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 13 Jan 2014 15:12:51 -0000 --Apple-Mail=_F65514E3-433E-429E-BCAF-DFDDCB650C28 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Speaking as a MIB Doctor and EMAN co-chair, I want to call = consensus so that we could close on this issue and so that the MIBs in = question can be progressed as well as give direct to any future EMAN = MIBs. The consensus was that we would use the recommendations from = RFC2578 instead of falling under a single "eman MIB root" OID. To this = end, I am directing the various MIB editors to please restructure their = OID assignments accordingly by rooting under the IANA management tree. =20= This is the relevant text from RFC 4181 section 4.5 for = reference. The value assigned to the MODULE-IDENTITY descriptor MUST be unique and (for IETF standards-track MIB modules) SHOULD reside under the mgmt subtree [RFC2578]. Most often it will be an IANA-assigned value directly under mib-2 [RFC2578], although for media-specific MIB modules that extend the IF-MIB [RFC2863] it is customary to use an IANA-assigned value under transmission [RFC2578]. In the past, some IETF working groups have made their own assignments from subtrees delegated to them by IANA, but that practice has proven problematic and is NOT RECOMMENDED. Thanks, --Tom --Apple-Mail=_F65514E3-433E-429E-BCAF-DFDDCB650C28 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 iQIcBAEBCgAGBQJS1AJcAAoJEPcO+I7eiUJZz+cP/RwAitCdKecELyRHIsCnlPwX hRb8DoVfVTMfhpIV/9mVmkKS8x/aINogcWYmvKnpoomrH5AOm6T/5Uz+TUqO+v9l noSQAiCPtt/L2794+C0YWmGwWvfZBblvJSvmsdJ4A9C/uIDQ++Woxjfln2Efo2NW BI+POwOqZ6JG60SZNXhbUIFJlSgR4YmoyunqS1A0/H8Z1Iv8LbetqyKiEeh4H7Pn HTLSD+fg+fqhV5MfoeEgssv8lKgFSWJyCbb3PK2trYspKvCn1amETxGHkyMzLoGL ktpWtv1l0zvwUldu/6MkX6jgW/Js3jpp4XqGj19kzZzk4UXPyStpZ7m5juyc915o BxQ5M6pEK/JyJur/HQ+n1zSbjHYrx404GY5Ee/ptWedFVXerJmOe+Kspt7R70lAC gaLHpvTBQX55SPeJPjV74KNUiXC/Yv1hYtcJ6HfY+vqFDmDZ37wrBqBS3fKypOk2 KvEtBb5fj5TOl+pqzCDYgU7NDr6boMEI5bLPnaUL/DeVhyBdencbmmMCWpCI8isA 8tPpa3DNEABB1vrY9t6GMl/SCzhGs/oY2W9XUj2Y5pm9emYqAzD/Ia3QUd6Gqh46 QLnF3xGR5IF1C3xctNJADR0IE3WX/22fd612zvsbmhfOutUxtTlggfkx+9I2qzJl BWNnmIOGD9LKAoJHuE9p =PwU5 -----END PGP SIGNATURE----- --Apple-Mail=_F65514E3-433E-429E-BCAF-DFDDCB650C28-- From Quittek@neclab.eu Tue Jan 14 03:43:29 2014 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B63B51AE06A for ; Tue, 14 Jan 2014 03:43:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.14 X-Spam-Level: X-Spam-Status: No, score=-3.14 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.538, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qUWjI1Z_RpsS for ; Tue, 14 Jan 2014 03:43:27 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 7FD0F1AE04D for ; Tue, 14 Jan 2014 03:43:27 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 0C9611068E6; Tue, 14 Jan 2014 12:31:46 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6+kUc7hGjLLB; Tue, 14 Jan 2014 12:31:45 +0100 (CET) X-ENC: Last-Hop-TLS-encrypted X-ENC: Last-Hop-TLS-encrypted Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailer1.neclab.eu (Postfix) with ESMTPS id E212C1068E5; Tue, 14 Jan 2014 12:31:30 +0100 (CET) Received: from DAPHNIS.office.hd ([169.254.2.18]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Tue, 14 Jan 2014 12:43:00 +0100 From: Juergen Quittek To: Thomas Nadeau , eman mailing list Thread-Topic: [eman] IPR Poll on draft-ietf-eman-battery-mib-11 Thread-Index: AQHPDXoqgVenu3AnikCVzW/elomnVpqEH+lg Date: Tue, 14 Jan 2014 11:42:59 +0000 Message-ID: <9AB93E4127C26F4BA7829DEFDCE5A6E8688D1023@DAPHNIS.office.hd> References: <35D4667C-0D12-4312-8885-2FD9A222274E@lucidvision.com> In-Reply-To: <35D4667C-0D12-4312-8885-2FD9A222274E@lucidvision.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.213] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-eman-battery-mib@tools.ietf.org" Subject: Re: [eman] IPR Poll on draft-ietf-eman-battery-mib-11 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 14 Jan 2014 11:43:29 -0000 Dear Tom and Nevil, As an author I am not aware of any IPR that applies to draft-ietf-eman-batt= ery-mib-11 and that has not yet been filed for this draft. Juergen > -----Original Message----- > From: eman [mailto:eman-bounces@ietf.org] On Behalf Of Thomas Nadeau > Sent: Donnerstag, 9. Januar 2014 18:49 > To: eman mailing list > Cc: draft-ietf-eman-battery-mib@tools.ietf.org > Subject: [eman] IPR Poll on draft-ietf-eman-battery-mib-11 >=20 >=20 > This mail starts the IPR poll on draft-ietf-eman-battery-mib. >=20 > Are you aware of any IPR that applies to draft-ietf-eman-energy-aware-mib= ? >=20 > If so, has this IPR been disclosed in compliance with IETF IPR rules (see= RFCs > 3979, 4879, 3669 and 5378 for more details). >=20 > If you are listed as a document author or contributor please respond to t= his > email explicitly regardless of whether or not you are aware of any releva= nt IPR. > *The response needs to be sent to the EMAN wg mailing list.* The document > will not advance to the next stage until a response has been received fro= m each > author and contributor. >=20 > If you are on the EMAN WG email list but are not listed as an author or > contributor, then please explicitly respond only if you are aware of any = IPR that > has not yet been disclosed in conformance with IETF rules. >=20 > Thank you, >=20 > Nevil and Tom, EMAN WG Chairs >=20 From bclaise@cisco.com Fri Jan 17 06:24:34 2014 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A9381AE0D6 for ; Fri, 17 Jan 2014 06:24:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.14 X-Spam-Level: X-Spam-Status: No, score=-8.14 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YRpdW9gfhXzh for ; Fri, 17 Jan 2014 06:24:31 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id 5C8FF1AE0D1 for ; Fri, 17 Jan 2014 06:24:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11375; q=dns/txt; s=iport; t=1389968658; x=1391178258; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=81S7qhNxnVv5KBPFRg1XrmRAbHJFoGD4DlXYlZoNIhc=; b=AK3ltTKthyolH7TW/s7hzPs4Wn5Brz6qU58SdU2xsUhaLknbk2QIOvaC 5w9BKkT1+u6p0Or0yoMFhuRDPvsWHcsatUL8Egv+T1FPEQrKzRdVb59iL rsIF1cCKGBEV3HmesCacmsbYduwTI1nEMNxRe+HzudYm8l7lZFLzLOAgY 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjAFAJFf2FKQ/khL/2dsb2JhbABWA4MLOLtngQ8WdIImAQEEAQEBGhs2BAYRCwcaFgQLCQMCAQIBFTAGAQwGAgEBiAANxTQXjh0RAQI+FxGEJwSUO4NmgTGFFYtRgW+BPzuBNQ X-IronPort-AV: E=Sophos;i="4.95,670,1384300800"; d="scan'208";a="3773839" Received: from ams-core-2.cisco.com ([144.254.72.75]) by aer-iport-1.cisco.com with ESMTP; 17 Jan 2014 14:24:16 +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 s0HEOFjd001220; Fri, 17 Jan 2014 14:24:15 GMT Message-ID: <52D93D0F.9000109@cisco.com> Date: Fri, 17 Jan 2014 15:24:15 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Alan Luchuk , eman@ietf.org References: <201312301853.NAA03279@adminfs.snmp.com> In-Reply-To: <201312301853.NAA03279@adminfs.snmp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib-13 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 17 Jan 2014 14:24:34 -0000 Dear Alan, Let me answer your comments on the draft-ietf-eman-energy-aware-mib. The ones on draft-ietf-eman-energy-monitoring-mib will follow in a separate email. > Hello, > > Here are comments about draft-ietf-eman-energy-monitoring-mib-08 and > draft-ietf-eman-energy-aware-mib-13. Due to the holidays, I was unable > to get these sent to the WG E-mail list sooner. > > > Regarding draft-ietf-eman-energy-aware-mib-13: > ---------------------------------------------- > > Section 5, Page 6: > > The UML on Page 6 _looks_ incorrect. It _looks_ like the eoRelationTable > is subordinate to, or a child of, the eoEntry. I'm not sure how the > actual relationship specified in the MIB is _supposed_ to be represented > in UML. Good catch. Corrected. > > > Page 22: > > The eoRelationID in the eoRelationTable is "read-only". In many cases, > I do not see how an energy object can determine the eoRelationID to the > Energy Objects to which it is connected, so I _think_ the eoRelationID > must be configured by the EnMS. I _think_ the eoRelationID should be > a read-write object like the eoRelationship object. Yes, that's an obvious mistake. Thinking about it some more, I believe that we need a rowStatus textual convention in order to create new entries in there. > > As an example, consider a manageable, metering power distribution > unit (PDU), I don't see how it can autodiscover and populate the > eoRelationID of the energy objects to which it is connected. The useful- > ness of the eoRelationID MIB object is reduced if it is only populated > in devices where it can be autodiscovered. > > > Regarding draft-ietf-eman-energy-monitoring-mib-08: > --------------------------------------------------- > > Section 5, 3rd paragraph, Page 6: > > "entity4CRCompliance. This compliance requires that the > following 3 MIB objects from ENTITY-MIB [RFC6933] > (entPhysicalIndex, entPhysicalName and entPhysicalUUID) MUST be > implemented." > > I think entPhysicalClass should be included in this list. There are > other references to the entity4CRCompliance in this draft that need the > same update. Good catch. Also corrected in the draft-ietf-eman-energy-aware-mib Regards, Benoit > > > Section 5, Page 7: > > | +-- r-n INTEGER eoMeasurementCaliber(5) > > I think the above should be eoPowerMeasurementCaliber(5). > > | +-- r-n Interger32 eoPowerStateMaxPower(2) > > Change "Interger32" to Integer. > > | +-- r-n Integer32 eoEnergyParametersIntervalMode(5) > > I think the type of "eoEnergyParametersIntervalMode" should be INTEGER. > > > Section 5, Page 8: > > I suggest changing "powerAttributesMIB" to "POWER-ATTRIBUTES-MIB" for > for consistency with previous text that references the ENERGY-OBJECT-MIB > and POWER-ATTRIBUTES-MIB. > > A quick summary of the function of each of the tables in the POWER- > ATTRIBUTES-MIB, similar to the quick summary of each of the tables in > the ENERGY-OBJECT-MIB (on Page 6) might be helpful and consisent. > > > | +-- r-n Interger32 eoACPwrAttributesAvgVoltage(2) > > | +-- r-n Interger32 > | eoACPwrAttributesTotalActivePower(7) > > Change "Interger32" to Integer. > > In the diagram for the eoACPwrAttributesEntry, after eoACPwrAttributes- > ThdAmpheres, the eoACPwrAttributesThdVoltage object is missing. > > Also, here, and several places in the document, "Ampheres" is referenced. > Not sure if "Ampheres" is intentional, but "Amperes" might be preferable. > It might be good to do a case-insensitive search for "ampheres". > > > Section 5, Page 9: > > +-- eoACPwrAttributesDelPhaseEntry(1) > | | [entPhysicalIndex, eoPhaseIndex] > | | > | +-- r-n Integer32 > | | eoACPwrAttributesDelPhaseToNextPhaseVoltage(1) > | +-- r-n Integer32 > | | eoACPwrAttributesDelThdPhaseToNextPhaseVoltage(2) > | +-- r-n Integer32 > eoACPwrAttributesDelThdCurrent(3) > > I think the column numbers 1, 2, and 3, are incorrect. The actual column > numbers in the MIB are 2, 3, and 4. Perhaps the MIB table should be fixed > so the column numbers are 1, 2, and 3. > > > Section 5, Page 12. > > At the very top, in the diagram for the eoACPwrAttributesEntry, after > eoACPwrAttributesThdAmpheres, the eoACPwrAttributesThdVoltage object > is missing. > > > Section 5.4, Page 15: > > I suggest changing "powerAttributesMIB" to "POWER-ATTRIBUTES-MIB" for > for consistency with previous text that references the ENERGY-OBJECT-MIB > and POWER-ATTRIBUTES-MIB. > > > Section 6, Page 20: > > This section references the EMAN-MON-MIB. I think this should be > ENERGY-OBJECT-MIB. > > > Section 9, Page 27: > > This section references the "energyObjectMIBObject". Not sure what this > is. > > > In the MIBs, adding eye-catching comments between the tables would ease > visually identifying where each MIB table begins. > > > Page 37, "eoPowerOperState" MIB object: > > The second paragraph of the DESCRIPTION clause reads: "Possible values > of eoPowerAdminState...". I think "eoPowerAdminState" should be changed > to "eoPowerOperState." > > > Page 38, "eoPowerStateTable": > > The text reads: > > This table has an expansion-dependent relationship on the > eoPowerTable, containing rows describing each Power State > for the corresponding Energy Object. For every Energy > Object in the eoPowerTable, there is a corresponding > entry in this table." > > Not sure I correctly understand this table, but should the second sentence > read something like: "For every Energy Object in the eoPowerTable, there > is a corresponding set of entries in this table, one entry for each power > state supported by the Energy Object." > > > Page 38, "eoPowerStateEntry": > > In the DESCRIPTION clause, the state numbers and state names do not match > any documented enumerations for the IANAPowerStateSet textual convention. > Should the existing values be replaced with: > > eman(1024), -- indicates EMAN set > emanmechoff(1025), > emansoftoff(1026), > emanhibernate(1027), > emansleep(1028), > emanstandby(1029), > emanready(1030), > emanlowMinus(1031), > emanlow(1032), > emanmediumMinus(1033), > emanmedium(1034), > emanhighMinus(1035), > emanhigh(1036) > > > Page 45, "eoEnergyStored": > > The first sentence of the DESCRIPTION clause reads: > > "This object indicates the resultant of the energy consumed..." > > Perhaps the following text would be clearer: > > "This object indicates the difference of the energy consumed..." > ^^^^^^^^^^ > > > Page 46, "eoEnergyMaxConsumed": > > The DESCRIPTION text reads: > > "This object is the maximum energy ever observed in > eoEnergyConsumed since the monitoring started. This value > is specified in the common billing units of watt-hours > with the magnitude of watt-hours (kW-Hr, MW-Hr, etc.) > indicated separately in eoEnergyUnitMultiplier." > > Does this mean that the eoEnergyMaxConsumed value must be retained > across reboots, and thus must be stored in non-volatile memory? > > > Page 48/49/54, where "entity4CRCompliance" is listed: > > I believe the "entPhysicalClass" object must be added to the lists of > MIB objects (entPhysicalIndex, entPhysicalName and entPhysicalUUID). > > > Page 56, "eoACPwrAttributesAvgCurrent": > > It might be niced to expand the DESCRIPTION clause so that it more > precisely specifies the significance of this, perhaps similar to the > DESCRIPTION clause for "eoACPwrAttributesAvgVoltage". > > > Page 56, "eoACPwrAttributesFrequency": > > The UNITS clause does not match the comment after the SYNTAX clause. > > eoACPwrAttributesFrequency OBJECT-TYPE > SYNTAX Integer32 (4500..6500) -- UNITS 0.01 Hertz > UNITS "hertz" > > > Would it be useful or helpful to have UnitsMultiplier companion objects for > the following objects? > > Page 58, "eoACPwrAttributesThdAmpheres": > Page 60, "eoACPwrAttributesPhaseAvgCurrent": > Page 62, "eoACPwrAttributesDelPhaseToNextPhaseVoltage": > Page 63, "eoACPwrAttributesWyePhaseToNeutralVoltage": > Page 64, "eoACPwrAttributesWyePhaseCurrent": > > > Page 59, "eoACPwrAttributesPhaseEntry": > > Under the DESCRIPTION clause, it might be helpful to add a comment that > indicates the phase-to-phase voltages are in separate tables. > > When I first encountered the "eoACPwrAttributesPhaseEntry", I wondered > about the voltages until I read further in the MIB and found the > eoACPwrAttributesDelPhaseTable and the eoACPwrAttributesWyePhaseTable. > > > > Page 60, "eoACPwrAttributesPhaseActivePower", > "eoACPwrAttributesPhaseReactivePower", > "eoACPwrAttributesPhaseApparentPower": > > Expanding the DESCRIPTION clauses to note these are scaled by the > eoACPwrAttributesPowerUnitMultiplier might be helpful, but the > DESCRIPTION clause for the "eoACPwrAttributesPowerUnitMultiplier" > does note this scaling relationship. > > > Page 61, "eoACPwrAttributesPhaseImpedance": > > Are the UNITS of "volt-amperes" correct? > > > > Page 62/63, "eoACPwrAttributesDelPhaseToNextPhaseVoltage", > "eoACPwrAttributesDelThdPhaseToNextPhaseVoltage", > "eoACPwrAttributesDelThdCurrent": > > The last SID values for these objects are 2, 3, and 4, which distinctly > does NOT match the values shown in the figure on Page 9, which shows > the last SID values as 1, 2, and 3. > > > Page 74, Section 13: > > [EMAN-AWARE-MIB] J. Parello, B. Claise and M. Chandramoili, > "draft-ietf-eman-energy-aware-mib-11 ", work in > progress, November 2013. > > Does it matter, or should this reference draft 13, > draft-ietf-eman-energy-aware-mib-13? > > > Regards, > --Alan > > ------------------------------------------------------------------------------ > Alan Luchuk SNMP Research, Inc. Voice: +1 865 573 1434 > Senior Software Engineer 3001 Kimberlin Heights Road FAX: +1 865 573 9197 > luchuk at snmp.com Knoxville, TN 37920-9716 http://www.snmp.com/ > ------------------------------------------------------------------------------ > > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman > . > From bclaise@cisco.com Fri Jan 17 08:20:34 2014 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9D131AE123 for ; Fri, 17 Jan 2014 08:20:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.038 X-Spam-Level: X-Spam-Status: No, score=-10.038 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fw-IK80mQ8-n for ; Fri, 17 Jan 2014 08:20:30 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id 144D01AE11E for ; Fri, 17 Jan 2014 08:20:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=43454; q=dns/txt; s=iport; t=1389975617; x=1391185217; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=OjKTtUoKyXP5psA4aaZyWPSE71R4yByJPPlwyUXGW8A=; b=QiWXISGUcPUvYocLZeDhMbD/K0qTDBqpigjsaDa5ObMBgi8m2UFYnqoi YTeC6hmD8lrmpQEOHmdSmoqaAG3vFI8g+CPuo2jp8pSBtayDutosGm0YG lWo3hY+FaEjup8CvJ3e848JmvPXbWpU2VdcnkyfORga9EMW2FLQru83gh M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjYFAJFf2FKQ/khM/2dsb2JhbABPAQmDCziJMbI2gQ8WdIIlAQEBAwEBAQEXAQIKRwQGBgcECxEEAQEKFgEBAgQHCQMCAQIBFR8JCAYBDAQCAgEBBRKHYQgNxTQXjiMBBAYBAQEsKQaEMgSBU4NYjk6EKIZGhXOFXoFvgT87BIEpCBc X-IronPort-AV: E=Sophos;i="4.95,674,1384300800"; d="scan'208,217";a="3779263" Received: from ams-core-3.cisco.com ([144.254.72.76]) by aer-iport-1.cisco.com with ESMTP; 17 Jan 2014 16:20:14 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s0HGKD9W032370; Fri, 17 Jan 2014 16:20:13 GMT Message-ID: <52D9583D.6020603@cisco.com> Date: Fri, 17 Jan 2014 17:20:13 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Juergen Quittek , eman mailing list References: <5298B7FA.1010509@cisco.com> <52A5A9FA.80101@cisco.com> <52A5C2A6.9000501@cisco.com> <52AB8777.9060704@cisco.com> <653A4764-315C-4671-B0DA-389553CB3E29@lucidvision.com> <9AB93E4127C26F4BA7829DEFDCE5A6E8688B2E6C@DAPHNIS.office.hd> In-Reply-To: <9AB93E4127C26F4BA7829DEFDCE5A6E8688B2E6C@DAPHNIS.office.hd> Content-Type: multipart/alternative; boundary="------------000704020606000704010904" Subject: Re: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib-13 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 17 Jan 2014 16:20:34 -0000 This is a multi-part message in MIME format. --------------000704020606000704010904 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Juergen, Thanks for your thorough review. > Dear all, > > Below please find my comments on draft-ietf-eman-energy-aware-mib-13 titled "Energy Object Context MIB". I will send comments on draft-ietf-eman-energy-monitoring-mib-08 in a separate message. > > ================== > Technical comments: > ================== > > 1) Section 5.1, 3rd paragraph: Since you are already very precise about this MUST, I would add that the name MUST NOT have length zero. Not sure this is correct. RFC 6933 allows a zero-length string. See the second paragraph below. entPhysicalName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "The textual name of the physical entity. The value of this object should be the name of the component as assigned by the local device and should be suitable for use in commands entered at the device's `console'. This might be a text name (e.g., `console') or a simple component number (e.g., port or module number, such as `1'), depending on the physical component naming syntax of the device. If there is no local name, or if this object is otherwise not applicable, then this object contains a zero-length string. Note that the value of entPhysicalName for two physical entities will be the same in the event that the console interface does not distinguish between them, e.g., slot-1 and the card in slot-1." ::= { entPhysicalEntry 7 } However, this sentence below is badly expressed Every Energy Object MUST have a printable name assigned to it. This sentence actually means that if an assigned name is used, it must be a printable one. However, I wonder if this that sentence is needed at all, because we overrule the entPhysicalName definition from the ENTITY-V4 RFC. On top of that, with SnmpAdminString, we should be good, no? from http://www.ietf.org/rfc/rfc3411.txt, SnmpAdminString ::= TEXTUAL-CONVENTION DISPLAY-HINT "255t" STATUS current DESCRIPTION "An octet string containing administrative information,_preferably in human-readable form_. To facilitate internationalization, this information is represented using the ISO/IEC IS 10646-1 character set, encoded as an octet string using the UTF-8 transformation format described in [RFC2279]. Since additional code points are added by amendments to the 10646 standard from time to time, implementations must be prepared to encounter any code point from 0x00000000 to 0x7fffffff. Byte sequences that do not correspond to the valid UTF-8 encoding of a code point or are outside this range are prohibited. The use of control codes should be avoided. When it is necessary to represent a newline, the control code sequence CR LF should be used. The use of leading or trailing white space should be avoided. For code points not directly supported by user interface hardware or software, an alternative means of entry and display, such as hexadecimal, may be provided. For information encoded in 7-bit US-ASCII, the UTF-8 encoding is identical to the US-ASCII encoding. UTF-8 may require multiple bytes to represent a single character / code point; thus the length of this object in octets may be different from the number of characters encoded. Similarly, size constraints refer to the number of encoded octets, not the number of characters represented by an encoding. Note that when this TC is used for an object that is used or envisioned to be used as an index, then a SIZE restriction MUST be specified so that the number of sub-identifiers for any object instance does not exceed the limit of 128, as defined by [RFC3416]. Note that the size of an SnmpAdminString object is measured in octets, not characters. " SYNTAX OCTET STRING (SIZE (0..255)) Proposal, to make it clear that printable names are really a plus: OLD: "Every Energy Object MUST have a printable name assigned to it" NEW: "While entPhysicalName does allow zero-length name, every Energy Object should have a printable name assigned to it" > > 2) Section 5.1, one but last paragraph: "Each Energy Object MUST belong to a single Energy Management Domain or in other words, an Energy Object cannot belong to more than one Energy Management Domain." This is more strict than in the framework where we say an EO "should" not belong to more than one domain. However, as we have discussed several times, there are management systems that use more than one domain (different to EnergyWise). I do not see a good reason to declare that their model is wrong. Thus, we can recommend "make it as EnergWise from Cisco does it" with the "should" clause that we have in the framework, but we should not fully exclude other solutions with a "must" clause. See also comment 7). Thanks for catching this discrepancy. The framework mentions on one side: The Energy Object (Class) contains a string attribute to indicate membership in an Energy Management Domain. It's true that this framework sentence contradicts this: An Energy Object should be a member of a single Energy Management Domain therefore one attribute is provided. This last sentence doesn't reflect what was discussed at http://www.ietf.org/mail-archive/web/eman/current/msg02033.html 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. And, most importantly, http://www.ietf.org/mail-archive/web/eman/current/msg02037.html, which is the outcome of the authors call, supervised by Nevil: *** 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 better 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 The framework should correct this sentence: OLD: An Energy Object should be a member of a single Energy Management Domain therefore one attribute is provided. NEW: An Energy Object must be a member of a single Energy Management Domain therefore one attribute is provided. > > 3) Section 5.3, 2nd and 3rd paragraph: > Both paragraphs need more explanation and you need to make them consistent with the text in the MIB modules. For LLDP you say "If the LLDP MIB is implemented". Why don't you have a similar statement for the PoE MIB? You talk about "the" Energy Object SNMP agent. However, EOs may not have SNMP agents, for example, if they are just a power interface. And it is not specified which of the potentially numerous instances of lldpLocPortNum objects of a device should be reported. Ack, will provide some new text > > 4) Section 5.4, 4th paragraph: > "Since the communication between the Energy Objects may not be > SNMP and is left to the choice of the device manufacturer, an > Energy Object can have additional MIB objects that can be used > for easier identification by the EnMS." > Two comments on this sentence: > A) It is not very obvious if SNMP is not available, it makes sense to use MIB objects. Please clarify this. > B) Please note that the choice is not only with the manufacturer. Even if the manufacturer builds in SNMP, the operator may choose to disable it ;-) This is a badly written sentence. Proposal: remove "Since the communication between the Energy Objects may not be SNMP and is left to the choice of the device manufacturer" > > 5) Section 6, DESCRIPTION clause of object eoEthPortIndex: > What "attached device" are you talking about? > Why is it relevant for the specification of this object, if that a certain MIB module "should" be implemented on that device? Does it make any different for the DESCRIPTION of this object whether or not this MIB module is implemented on the attached device? I do not see why and thus recommend removing the statement "PoE MIB should be instantiated on the device." New text will be proposed. > > 6) Section 6, DESCRIPTION clause of object eoMgmtDNSName: > There may be more than one DNS name associated to a single IP address: > "the DNS name" -> "a DNS name" fixed > > 7) Section 6, DESCRIPTION clause of object eoDomainName: > Please insert as second sentence: "If the energy object has been assigned to multiple domains, then they are represented in this object as comma-separated list.", see comment 2). See point 2. > > 8) Section 6, SYNTAX clause of object eoPowerCategory: > Some devices match more than one category, for example a UPS is a store and a distributor at the same time, and to be precise, also a consumer. A PoE Switch is a consumer and a distributor, some devices switch between consumer and producer, etc. We can support all of this if we change the syntax from INTEGER to BITS. See point 2, for the justification, discussed at the [EMAN-FMWK] time, on why not to do this. > > 9) Section 6, DESCRIPTION clause of object eoAlternateKey: > There is a contradiction between having this object with MAX-ACCESS read-write and stating " This object specifies a manufacturer defined string". If the manufacturer defines the string, there is no need to write it. I suggest allowing the operator to set the value of this document. The use of the "manufacturer" word is a poor choice. This corresponds to section 5.3: The eoAlternateKey alternate key object specifies a manufacturer defined string that can be used to identify the Energy Object. Since an EnMS may need to correlate objects across management systems, this alternate key is provided to facilitate such a link. This optional value is intended as a foreign key or alternate identifier for a manufacturer or EnMS to use to correlate the unique Energy Object Id in other systems or namespaces. If an alternate key is not available or is not applicable then the value is the zero-length string. Proposal: change to "alternate" In section 5.3 OLD: The eoAlternateKey alternate key object specifies a manufacturer defined string that can be used to identify the Energy Object. NEW: The eoAlternateKey object specifies an alternate key string that can be used to identify the Energy Object. OLD: eoAlternateKey OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-write STATUS current DESCRIPTION "This object specifies a manufacturer defined string that can be used to identify the Energy Object. NEW: eoAlternateKey OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-write STATUS current DESCRIPTION "This object specifies an alternate key string > > 10) Section 6, DESCRIPTION clause of object eoRelationID: > I recommend adding a sentence to the DESCRIPTION clause, that preferable the value of an entPhysicalUUID from the Entity MIB should be used for values of this object. ok. > > 11) Section 6, Conformance of ENERGY-OBJECT-CONTEXT-MIB module: > The dependence of compliance with entity4CRCompliance is stated in the GROUP DESCRIPTION clauses. In our case, this is not the right place. There is a dependency on entity4CRCompliance independent of which group is implemented. Hence, these statements need to be moved from the GROUP DESCRIPTION clauses to the module compliance DESCRIPTION clauses of energyObjectContextMIBFullCompliance and energyObjectContextMIBReadOnlyCompliance. That makes sense. > > 12) Section 6, Conformance of ENERGY-OBJECT-CONTEXT-MIB module: > We state in other places that implementation of the Entity MIB compliant with entity4CRCompliance is a must. But in the conformance section of the ENERGY-OBJECT-CONTEXT-MIB the dependency on entity4CRCompliance is stated as "should". This need to be changed to a "must" or "required." Good catch. > > 13) Section 6, DESCRIPTION clause of TC IANAEnergyRelationship: > For interoperability, the description need to be clear. As this TC is stated, there are two points unclear to me: > A) " The enumeration 'poweredBy' is applicable if the > Energy Object A is poweredBy Energy Object B. > The enumeration 'powering' is applicable if the > Energy Object A is powering Energy Object B." > If the TC is used, how do I know which object is A and which is B? Is it that the DESCRIPTION clauses of objects of this type must refer to object A and object B? OLD: IANAEnergyRelationship ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "An enumerated value specifies the type of relationship between Energy Objects. NEW: IANAEnergyRelationship ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "An enumerated value specifying the type of relationship between an Energy Object A, on which the relationship is specified, with the Energy Object B, characterized by the UUID." > B) "if the Energy Object A is aggregating Energy Object B" > There is no place in this document where there is explained what aggregating means. Part of section 5.4, we refer to [EMAN-FMWK], which defines the aggregation relationship as a summation. I guess you want some more text in this section 5.4? > > ================= > Editorial comments: > ================= All these will be taken care of. Thanks again. Regards, Benoit. > > 14) Abstract, last two lines: > "relationships between reporting devices, remote devices, and monitoring devices.": The enumeration of "reporting devices", "monitoring devices", and "remote devices" is inappropriate because it does not reflect the list of relationships discussed by the draft: poweredBy, meteredBy, aggregatedBy. > > 15) Section 1. Introduction, 2nd paragraph, last two lines: > "Identification" -> "identification" > "Context" -> "context" > "Relationships" -> "relationships" > > 16) Section 1.1, 3rd paragraph, line 1: > "A second MIB module required by the [EMAN-FMWK]": There is no MIB module required by the EMAN framework. It seems you wanted to say: "A second MIB module meeting EMAN requirements given by [RFC6988]". > > 17) Entire Section 3 > This section is completely redundant. It mainly repeats sentences of section 1.1. Remove this section and merge sentences you want to keep into section 1.1 > > 18) Section 5, 3rd paragraph, first sentence: > The sentence is not grammatically correct, please fix. Also semantic correction seems to be needed. You don't mention "identification" as focus of the first table. > > 19) Section 5, sentence before Figure 1: > "The following UML diagram illustrates the relationship of the > MIB objects in the eoTable, eoRelationTable that describe the > identity, context and relationship of an Energy Object." > You should mention that you UML diagram furthermore contains objects from the Entity MIB. > > 20) Section 5, figure 1: > There is a dotted line at the lower left that goes nowhere. Please cut it. > > 21) Section 5, grouping of MIB objects is inconsistent. > In Figure 1 you have three groups: "Context", "Identification", "Relationships", where "Identifications" has three subgroups. The sentence below the figure emphasizes this grouping. However, the following subsections 5.1-5.4 are grouped differently. 5.1 is titled "Identification" but covers only a third of the objects under "Identification" in Figure 1. Section 5.2 is consistently with Figure 1 covering context information. Section 5.3 covers PoE and LLDP identification. Sections 5.4 is called "Relationships" but covers not just the objects under "Relationships" in Figure 1, but also objects from under "Identification" in Figure 1. Here is a clean-up needed. Please split the last sentence from section 5.4. It firs much better in section 5.3. > > 22) Section 5, enumeration under Figure 1: > Please note that subsection 5.5 is not another group of MIB objects but refers to objects in subsection 5.1. The sentence above the enumeration implies that each numbered item would be a group of objects. > > 23) Section 5.1, 2nd paragraph, line 7: > What is "primary Energy Object information"? > > 24) Section 5.4, 2nd paragraph, last sentence: > "It is important to notice, that it is possible that" -> "Obviously," > "not have an" -> "not have any" > > 25) Section 5.4, 4th paragraph > The entire paragraph is in the wrong subsection. It rather belongs to subsection 5.1 or 5.3. > > 26) Section 6, DESCRIPTION clause of object eoEthPortGrpIndex: > See comment 5). There is a full stop missing at the end of the second sentence. > > 27) Section 6, OBJECTS clause of GROUP energyObjectRelationTableGroup: > The comment "Note that object eoRelationIndex is not included since it is not-accessible" is not really needed. Almost every Conformance section has such objects and usually this comment is omitted. > > Cheers, > Juergen > > >> -----Original Message----- >> From: eman [mailto:eman-bounces@ietf.org] On Behalf Of Thomas Nadeau >> Sent: Montag, 16. Dezember 2013 16:56 >> To: eman mailing list >> Subject: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib-08 >> and draft-ietf-eman-energy-aware-mib-13 >> >> >> As agreed at the last WG meeting, with the EMAN Framework >> completing its WG LC the chairs would like to initiate a WG LC on draft-ietf- >> eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib-13. >> The WG LC will end on Dec 30 at 8AM EDT. >> >> Thank you, >> >> Nevil and Tom >> > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman > . > --------------000704020606000704010904 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi Juergen,

Thanks for your thorough review.
Dear all,

Below please find my comments on draft-ietf-eman-energy-aware-mib-13 titled "Energy Object Context MIB". I will send comments on draft-ietf-eman-energy-monitoring-mib-08 in a separate message.

==================
Technical comments:
==================

1) Section 5.1, 3rd paragraph: Since you are already very precise about this MUST, I would add that the name MUST NOT have length zero.
Not sure this is correct. RFC 6933 allows a zero-length string. See the second paragraph below.
entPhysicalName OBJECT-TYPE
    SYNTAX      SnmpAdminString
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
            "The textual name of the physical entity.  The value of this
            object should be the name of the component as assigned by
            the local device and should be suitable for use in commands
            entered at the device's `console'.  This might be a text
            name (e.g., `console') or a simple component number (e.g.,
            port or module number, such as `1'), depending on the
            physical component naming syntax of the device.

            If there is no local name, or if this object is otherwise
            not applicable, then this object contains a zero-length
            string.

            Note that the value of entPhysicalName for two physical
            entities will be the same in the event that the console
            interface does not distinguish between them, e.g., slot-1
            and the card in slot-1."
    ::= { entPhysicalEntry 7 }

However, this sentence below is badly expressed
  Every Energy Object MUST have a printable name assigned to it.
This sentence actually means that if an assigned name is used, it must be a printable one.
However, I wonder if this that sentence is needed at all, because we overrule the entPhysicalName definition from the ENTITY-V4 RFC.
On top of that, with SnmpAdminString, we should be good, no?

from http://www.ietf.org/rfc/rfc3411.txt, 
SnmpAdminString ::= TEXTUAL-CONVENTION
    DISPLAY-HINT "255t"
    STATUS       current
    DESCRIPTION "An octet string containing administrative
                 information, preferably in human-readable form.

                 To facilitate internationalization, this
                 information is represented using the ISO/IEC
                 IS 10646-1 character set, encoded as an octet
                 string using the UTF-8 transformation format
                 described in [RFC2279].

                 Since additional code points are added by
                 amendments to the 10646 standard from time
                 to time, implementations must be prepared to
                 encounter any code point from 0x00000000 to
                 0x7fffffff.  Byte sequences that do not
                 correspond to the valid UTF-8 encoding of a
                 code point or are outside this range are
                 prohibited.

                 The use of control codes should be avoided.

                 When it is necessary to represent a newline,
                 the control code sequence CR LF should be used.
                 The use of leading or trailing white space should
                 be avoided.

                 For code points not directly supported by user
                 interface hardware or software, an alternative
                 means of entry and display, such as hexadecimal,
                 may be provided.

                 For information encoded in 7-bit US-ASCII,
                 the UTF-8 encoding is identical to the
                 US-ASCII encoding.

                 UTF-8 may require multiple bytes to represent a
                 single character / code point; thus the length
                 of this object in octets may be different from
                 the number of characters encoded.  Similarly,
                 size constraints refer to the number of encoded
                 octets, not the number of characters represented
                 by an encoding.

                 Note that when this TC is used for an object that
                 is used or envisioned to be used as an index, then
                 a SIZE restriction MUST be specified so that the
                 number of sub-identifiers for any object instance
                 does not exceed the limit of 128, as defined by
                 [RFC3416].

                 Note that the size of an SnmpAdminString object is
                 measured in octets, not characters.
                "
    SYNTAX       OCTET STRING (SIZE (0..255))

Proposal, to make it clear that printable names are really a plus:
OLD:
	 "Every Energy Object MUST have a printable name assigned to it"
NEW:
	 "While entPhysicalName does allow zero-length name, every Energy 
         Object should have a printable name assigned to it"


2) Section 5.1, one but last paragraph: "Each Energy Object MUST belong to a single Energy Management Domain or in other words, an Energy Object cannot belong to more than one Energy Management Domain." This is more strict than in the framework where we say an EO "should" not belong to more than one domain. However, as we have discussed several times, there are management systems that use more than one domain (different to EnergyWise). I do not see a good reason to declare that their model is wrong. Thus, we can recommend "make it as EnergWise from Cisco does it" with the "should" clause that we have in the framework, but we should not fully exclude other solutions with a "must" clause. See also comment 7).
Thanks for catching this discrepancy.
The framework mentions on one side:
        The Energy Object (Class) contains a string attribute to
        indicate membership in an Energy Management Domain.
It's true that this framework sentence contradicts this:
        An Energy Object should be a member of a single Energy
        Management Domain therefore one attribute is provided.
This last sentence doesn't reflect what was discussed at
http://www.ietf.org/mail-archive/web/eman/current/msg02033.html
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.

And, most importantly, http://www.ietf.org/mail-archive/web/eman/current/msg02037.html, which is the outcome of the authors call, supervised by Nevil:
*** 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 better 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

The framework should correct this sentence:
OLD:
        An Energy Object should be a member of a single Energy
        Management Domain therefore one attribute is provided.
NEW:
        An Energy Object must be a member of a single Energy
        Management Domain therefore one attribute is provided.


3) Section 5.3, 2nd and 3rd paragraph:
Both paragraphs need more explanation and you need to make them consistent with the text in the MIB modules. For LLDP you say "If the LLDP MIB is implemented". Why don't you have a similar statement for the PoE MIB? You talk about "the" Energy Object SNMP agent. However, EOs may not have SNMP agents, for example, if they are just a power interface. And it is not specified which of the potentially numerous instances of lldpLocPortNum objects of a device should be reported.
Ack, will provide some new text 

4) Section 5.4, 4th paragraph:
"Since the communication between the Energy Objects may not be 
SNMP and is left to the choice of the device manufacturer, an 
Energy Object can have additional MIB objects that can be used 
for easier identification by the EnMS."
Two comments on this sentence:
A) It is not very obvious if SNMP is not available, it makes sense to use MIB objects. Please clarify this.
B) Please note that the choice is not only with the manufacturer. Even if the manufacturer builds in SNMP, the operator may choose to disable it ;-)
This is a badly written sentence.
Proposal: remove
"Since the communication between the Energy Objects may not be 
SNMP and is left to the choice of the device manufacturer" 

5) Section 6, DESCRIPTION clause of object eoEthPortIndex:
What "attached device" are you talking about?
Why is it relevant for the specification of this object, if that a certain MIB module "should" be implemented on that device? Does it make any different for the DESCRIPTION of this object whether or not this MIB module is implemented on the attached device? I do not see why and thus recommend removing the statement "PoE MIB should be instantiated on the device."
New text will be proposed. 

6) Section 6, DESCRIPTION clause of object eoMgmtDNSName:
There may be more than one DNS name associated to a single IP address:
"the DNS name" -> "a DNS name"
fixed

7) Section 6, DESCRIPTION clause of object eoDomainName:
Please insert as second sentence: "If the energy object has been assigned to multiple domains, then they are represented in this object as comma-separated list.", see comment 2).
See point 2. 

8) Section 6, SYNTAX clause of object eoPowerCategory:
Some devices match more than one category, for example a UPS is a store and a distributor at the same time, and to be precise, also a consumer. A PoE Switch is a consumer and a distributor, some devices switch between consumer and producer, etc. We can support all of this if we change the syntax from INTEGER to BITS.
See point 2, for the justification, discussed at the [EMAN-FMWK] time, on why not to do this. 

9) Section 6, DESCRIPTION clause of object eoAlternateKey:
There is a contradiction between having this object with MAX-ACCESS read-write and stating " This object specifies a manufacturer defined string". If the manufacturer defines the string, there is no need to write it. I suggest allowing the operator to set the value of this document.
The use of the "manufacturer" word is a poor choice.
This corresponds to section 5.3:
        The eoAlternateKey alternate key object specifies a manufacturer
        defined string that can be used to identify the Energy Object.
        Since an EnMS may need to correlate objects across management    
        systems, this alternate key is provided to facilitate such a
        link.  This optional value is intended as a foreign key or
        alternate identifier for a manufacturer or EnMS to use to
        correlate the unique Energy Object Id in other systems or
        namespaces. If an alternate key is not available or is not
        applicable then the value is the zero-length string.

Proposal: change to "alternate"

In section 5.3
OLD:
        The eoAlternateKey alternate key object specifies a manufacturer
        defined string that can be used to identify the Energy Object.
NEW:
        The eoAlternateKey object specifies an alternate key string
        that can be used to identify the Energy Object.
OLD:
      eoAlternateKey OBJECT-TYPE
            SYNTAX          SnmpAdminString
            MAX-ACCESS      read-write
            STATUS          current
            DESCRIPTION
               "This object specifies a manufacturer defined string that
               can be used to identify the Energy Object.
NEW:
      eoAlternateKey OBJECT-TYPE
            SYNTAX          SnmpAdminString
            MAX-ACCESS      read-write
            STATUS          current
            DESCRIPTION
               "This object specifies an alternate key string



10) Section 6, DESCRIPTION clause of object eoRelationID:
I recommend adding a sentence to the DESCRIPTION clause, that preferable the value of an entPhysicalUUID from the Entity MIB should be used for values of this object.
ok.

11) Section 6, Conformance of ENERGY-OBJECT-CONTEXT-MIB module: 
The dependence of compliance with entity4CRCompliance is stated in the GROUP DESCRIPTION clauses. In our case, this is not the right place. There is a dependency on entity4CRCompliance  independent of which group is implemented. Hence, these statements need to be moved from the GROUP DESCRIPTION clauses to the module compliance DESCRIPTION clauses of energyObjectContextMIBFullCompliance and energyObjectContextMIBReadOnlyCompliance.
That makes sense.

12) Section 6, Conformance of ENERGY-OBJECT-CONTEXT-MIB module:
We state in other places that implementation of the Entity MIB compliant with entity4CRCompliance is a must. But in the conformance section of the ENERGY-OBJECT-CONTEXT-MIB the dependency on entity4CRCompliance is stated as "should". This need to be changed to a "must" or "required."
Good catch.

13) Section 6, DESCRIPTION clause of TC IANAEnergyRelationship:
For interoperability, the description need to be clear. As this TC is stated, there are two points unclear to me:
A) " The enumeration 'poweredBy' is applicable if the  
       Energy Object A is poweredBy Energy Object B. 
       The enumeration 'powering' is applicable if the  
       Energy Object A is powering Energy Object B."
If the TC is used, how do I know which object is A and which is B? Is it that the DESCRIPTION clauses of objects of this type must refer to object A and object B?
OLD:
        IANAEnergyRelationship ::= TEXTUAL-CONVENTION
            STATUS            current
            DESCRIPTION
                    "An enumerated value specifies the type of
                     relationship between Energy Objects.
NEW:
        IANAEnergyRelationship ::= TEXTUAL-CONVENTION
            STATUS            current
            DESCRIPTION
                    "An enumerated value specifying the type of
                    relationship between an Energy Object A, on which 
                    the relationship is specified, with the Energy Object B, 
                    characterized by the UUID."

B) "if the Energy Object A is aggregating Energy Object B"
There is no place in this document where there is explained what aggregating means.
Part of section 5.4, we refer to [EMAN-FMWK], which defines the aggregation relationship as a summation. I guess you want some more text in this section 5.4?

=================
Editorial comments:
=================
All these will be taken care of.

Thanks again.

Regards, Benoit.

14) Abstract, last two lines:
"relationships between reporting devices, remote devices, and monitoring devices.": The enumeration of "reporting devices", "monitoring devices", and "remote devices" is inappropriate because it does not reflect the list of relationships discussed by the draft: poweredBy, meteredBy, aggregatedBy.

15) Section 1. Introduction, 2nd paragraph, last two lines:
"Identification" -> "identification"
"Context" -> "context"
"Relationships" -> "relationships"

16) Section 1.1, 3rd paragraph, line 1:
"A second MIB module required by the [EMAN-FMWK]": There is no MIB module required by the EMAN framework. It seems you wanted to say: "A second MIB module meeting EMAN requirements given by [RFC6988]".

17) Entire Section 3
This section is completely redundant. It mainly repeats sentences of section 1.1. Remove this section and merge sentences you want to keep into section 1.1

18) Section 5, 3rd paragraph, first sentence:
The sentence is not grammatically correct, please fix. Also semantic correction seems to be needed. You don't mention "identification" as focus of the first table.

19) Section 5, sentence before Figure 1:
"The following UML diagram illustrates the relationship of the 
MIB objects in the eoTable, eoRelationTable that describe the 
identity, context and relationship of an Energy Object."
You should mention that you UML diagram furthermore contains objects from the Entity MIB.

20) Section 5, figure 1:
There is a dotted line at the lower left that goes nowhere. Please cut it.

21) Section 5, grouping of MIB objects is inconsistent.
In Figure 1 you have three groups: "Context", "Identification", "Relationships", where "Identifications" has three subgroups. The sentence below the figure emphasizes this grouping. However, the following subsections 5.1-5.4 are grouped differently. 5.1 is titled "Identification" but covers only a third of the objects under "Identification" in Figure 1. Section 5.2 is consistently with Figure 1 covering context information. Section 5.3 covers PoE and LLDP identification. Sections 5.4 is called "Relationships" but covers not just the objects under "Relationships" in Figure 1, but also objects from under "Identification" in Figure 1. Here is a clean-up needed. Please split the last sentence from section 5.4. It firs much better in section 5.3.

22) Section 5, enumeration under Figure 1:
Please note that subsection 5.5 is not another group of MIB objects but refers to objects in subsection 5.1. The sentence above the enumeration implies that each numbered item would be a group of objects.

23) Section 5.1, 2nd paragraph, line 7:
What is "primary Energy Object information"? 

24) Section 5.4, 2nd paragraph, last sentence:
"It is important to notice, that it is possible that" -> "Obviously,"
"not have an" -> "not have any"

25) Section 5.4, 4th paragraph
The entire paragraph is in the wrong subsection. It rather belongs to subsection 5.1 or 5.3.

26) Section 6, DESCRIPTION clause of object eoEthPortGrpIndex:
See comment 5). There is a full stop missing at the end of the second sentence.

27) Section 6, OBJECTS clause of GROUP energyObjectRelationTableGroup:
The comment "Note that object eoRelationIndex is not included since it is not-accessible" is not really needed. Almost every Conformance section has such objects and usually this comment is omitted.

Cheers,
    Juergen



-----Original Message-----
From: eman [mailto:eman-bounces@ietf.org] On Behalf Of Thomas Nadeau
Sent: Montag, 16. Dezember 2013 16:56
To: eman mailing list
Subject: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib-08
and draft-ietf-eman-energy-aware-mib-13


	As agreed at the last WG meeting, with the EMAN Framework
completing its WG LC the chairs would like to initiate a WG LC on draft-ietf-
eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib-13.
The WG LC will end on Dec 30 at 8AM EDT.

	Thank you,

	Nevil and Tom


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

--------------000704020606000704010904-- From bclaise@cisco.com Fri Jan 17 08:23:20 2014 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5935C1AE13F for ; Fri, 17 Jan 2014 08:23:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.039 X-Spam-Level: X-Spam-Status: No, score=-10.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4du5lwkvk5jD for ; Fri, 17 Jan 2014 08:23:16 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id C1C611AE135 for ; Fri, 17 Jan 2014 08:23:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12624; q=dns/txt; s=iport; t=1389975783; x=1391185383; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=vMPDdC9+PRWD3FFh2MFZ18hECBm89L/9Ylvo3aKHVvs=; b=mgRewBJHK1u+q932r5IpLxzDZ3WmVYADGXAJVN7/0Hf/kiwWNC328ZHf o8tIOpVf81GI4Cmf3rE7FwLgbY/dh26OI8xtNOj4JoLRylrRE5DDOAeAi zdpyYfezdMZHibsGzBHY+q7HCxlnCSkSN2oDtC34lpfex3u7zIoWillF/ c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjEFAJFf2FKQ/khM/2dsb2JhbABQCYMLOLtngQ8WdIIlAQEBAwEBAQEaCgsBBTYEBg0ECxEEAQEKFgQEBwkDAgECARUfCQgGAQwGAgEBF4dhCA3FNBMEjh0HCgECDww6BoQyAQOFK45OhCiGRoVzhV6Bb4E/O4E1 X-IronPort-AV: E=Sophos;i="4.95,674,1384300800"; d="scan'208";a="3110042" Received: from ams-core-3.cisco.com ([144.254.72.76]) by aer-iport-2.cisco.com with ESMTP; 17 Jan 2014 16:23:02 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s0HGN1Sw000705; Fri, 17 Jan 2014 16:23:01 GMT Message-ID: <52D958E5.2060706@cisco.com> Date: Fri, 17 Jan 2014 17:23:01 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Juergen Quittek , eman mailing list References: <5298B7FA.1010509@cisco.com> <52A5A9FA.80101@cisco.com> <52A5C2A6.9000501@cisco.com> <52AB8777.9060704@cisco.com> <653A4764-315C-4671-B0DA-389553CB3E29@lucidvision.com> <9AB93E4127C26F4BA7829DEFDCE5A6E8688B2E6C@DAPHNIS.office.hd> <9AB93E4127C26F4BA7829DEFDCE5A6E8688B330D@DAPHNIS.office.hd> In-Reply-To: <9AB93E4127C26F4BA7829DEFDCE5A6E8688B330D@DAPHNIS.office.hd> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib-13 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 17 Jan 2014 16:23:20 -0000 Jürgen, > Dear all, > > There are two more comments on draft-ietf-eman-energy-aware-mib-13 that I missed to include in my previous email. > > One is editorial and one is technical: > > Editorial: MIB modules description > It is just once mentioned that there are two MIB modules in this draft (Section 1.1, first sentence. The draft starts discussing the ENERGY-OBJECT-CONTEXT-MIB module and sometimes uses "this MIB modules" to refer to it. When the discussion of the other MIB module starts in the middle of section 5.4 it would be helpful adding a statement reminding the reader that this module is included in the draft as well. For example by changing in section 5.4, 3rd paragraph > OLD > The IANA Energy Relationship MIB module specifies the first > version of the IANA-maintained definitions of relationships > NEW > The IANA Energy Relationship MIB module in Section 6 below specifies the first > version of the IANA-maintained definitions of relationships Yes. > > Technical: object eoPowerInterfaceType > I wonder why object eoPowerInterfaceType is included in the ENERGY-OBJECT-CONTEXT-MIB and not in the ENERGY-OBJECT-MIB itself. This object does not provide context, identity, or relationship information, but rather a technical property of a power interface, such as the nominal voltage or the number of AC phases. Why is it in this MIB module. Wouldn't it fit much better in the other one? I guess it depends on how we look at inlet/outlet: is this context information or technical property. No strong feeling about that one. What do the others think? Regards, Benoit > > Cheers, > Juergen > > >> -----Original Message----- >> From: eman [mailto:eman-bounces@ietf.org] On Behalf Of Juergen Quittek >> Sent: Montag, 30. Dezember 2013 13:05 >> To: eman mailing list >> Subject: Re: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib- >> 08 and draft-ietf-eman-energy-aware-mib-13 >> >> Dear all, >> >> Below please find my comments on draft-ietf-eman-energy-aware-mib-13 >> titled "Energy Object Context MIB". I will send comments on draft-ietf-eman- >> energy-monitoring-mib-08 in a separate message. >> >> ================== >> Technical comments: >> ================== >> >> 1) Section 5.1, 3rd paragraph: Since you are already very precise about this >> MUST, I would add that the name MUST NOT have length zero. >> >> 2) Section 5.1, one but last paragraph: "Each Energy Object MUST belong to a >> single Energy Management Domain or in other words, an Energy Object cannot >> belong to more than one Energy Management Domain." This is more strict >> than in the framework where we say an EO "should" not belong to more than >> one domain. However, as we have discussed several times, there are >> management systems that use more than one domain (different to >> EnergyWise). I do not see a good reason to declare that their model is wrong. >> Thus, we can recommend "make it as EnergWise from Cisco does it" with the >> "should" clause that we have in the framework, but we should not fully exclude >> other solutions with a "must" clause. See also comment 7). >> >> 3) Section 5.3, 2nd and 3rd paragraph: >> Both paragraphs need more explanation and you need to make them consistent >> with the text in the MIB modules. For LLDP you say "If the LLDP MIB is >> implemented". Why don't you have a similar statement for the PoE MIB? You >> talk about "the" Energy Object SNMP agent. However, EOs may not have SNMP >> agents, for example, if they are just a power interface. And it is not specified >> which of the potentially numerous instances of lldpLocPortNum objects of a >> device should be reported. >> >> 4) Section 5.4, 4th paragraph: >> "Since the communication between the Energy Objects may not be SNMP and is >> left to the choice of the device manufacturer, an Energy Object can have >> additional MIB objects that can be used for easier identification by the EnMS." >> Two comments on this sentence: >> A) It is not very obvious if SNMP is not available, it makes sense to use MIB >> objects. Please clarify this. >> B) Please note that the choice is not only with the manufacturer. Even if the >> manufacturer builds in SNMP, the operator may choose to disable it ;-) >> >> 5) Section 6, DESCRIPTION clause of object eoEthPortIndex: >> What "attached device" are you talking about? >> Why is it relevant for the specification of this object, if that a certain MIB >> module "should" be implemented on that device? Does it make any different >> for the DESCRIPTION of this object whether or not this MIB module is >> implemented on the attached device? I do not see why and thus recommend >> removing the statement "PoE MIB should be instantiated on the device." >> >> 6) Section 6, DESCRIPTION clause of object eoMgmtDNSName: >> There may be more than one DNS name associated to a single IP address: >> "the DNS name" -> "a DNS name" >> >> 7) Section 6, DESCRIPTION clause of object eoDomainName: >> Please insert as second sentence: "If the energy object has been assigned to >> multiple domains, then they are represented in this object as comma-separated >> list.", see comment 2). >> >> 8) Section 6, SYNTAX clause of object eoPowerCategory: >> Some devices match more than one category, for example a UPS is a store and >> a distributor at the same time, and to be precise, also a consumer. A PoE >> Switch is a consumer and a distributor, some devices switch between consumer >> and producer, etc. We can support all of this if we change the syntax from >> INTEGER to BITS. >> >> 9) Section 6, DESCRIPTION clause of object eoAlternateKey: >> There is a contradiction between having this object with MAX-ACCESS read- >> write and stating " This object specifies a manufacturer defined string". If the >> manufacturer defines the string, there is no need to write it. I suggest allowing >> the operator to set the value of this document. >> >> 10) Section 6, DESCRIPTION clause of object eoRelationID: >> I recommend adding a sentence to the DESCRIPTION clause, that preferable >> the value of an entPhysicalUUID from the Entity MIB should be used for values >> of this object. >> >> 11) Section 6, Conformance of ENERGY-OBJECT-CONTEXT-MIB module: >> The dependence of compliance with entity4CRCompliance is stated in the >> GROUP DESCRIPTION clauses. In our case, this is not the right place. There is a >> dependency on entity4CRCompliance independent of which group is >> implemented. Hence, these statements need to be moved from the GROUP >> DESCRIPTION clauses to the module compliance DESCRIPTION clauses of >> energyObjectContextMIBFullCompliance and >> energyObjectContextMIBReadOnlyCompliance. >> >> 12) Section 6, Conformance of ENERGY-OBJECT-CONTEXT-MIB module: >> We state in other places that implementation of the Entity MIB compliant with >> entity4CRCompliance is a must. But in the conformance section of the ENERGY- >> OBJECT-CONTEXT-MIB the dependency on entity4CRCompliance is stated as >> "should". This need to be changed to a "must" or "required." >> >> 13) Section 6, DESCRIPTION clause of TC IANAEnergyRelationship: >> For interoperability, the description need to be clear. As this TC is stated, there >> are two points unclear to me: >> A) " The enumeration 'poweredBy' is applicable if the >> Energy Object A is poweredBy Energy Object B. >> The enumeration 'powering' is applicable if the >> Energy Object A is powering Energy Object B." >> If the TC is used, how do I know which object is A and which is B? Is it that the >> DESCRIPTION clauses of objects of this type must refer to object A and object >> B? >> B) "if the Energy Object A is aggregating Energy Object B" >> There is no place in this document where there is explained what aggregating >> means. >> >> ================= >> Editorial comments: >> ================= >> >> 14) Abstract, last two lines: >> "relationships between reporting devices, remote devices, and monitoring >> devices.": The enumeration of "reporting devices", "monitoring devices", and >> "remote devices" is inappropriate because it does not reflect the list of >> relationships discussed by the draft: poweredBy, meteredBy, aggregatedBy. >> >> 15) Section 1. Introduction, 2nd paragraph, last two lines: >> "Identification" -> "identification" >> "Context" -> "context" >> "Relationships" -> "relationships" >> >> 16) Section 1.1, 3rd paragraph, line 1: >> "A second MIB module required by the [EMAN-FMWK]": There is no MIB >> module required by the EMAN framework. It seems you wanted to say: "A >> second MIB module meeting EMAN requirements given by [RFC6988]". >> >> 17) Entire Section 3 >> This section is completely redundant. It mainly repeats sentences of section 1.1. >> Remove this section and merge sentences you want to keep into section 1.1 >> >> 18) Section 5, 3rd paragraph, first sentence: >> The sentence is not grammatically correct, please fix. Also semantic correction >> seems to be needed. You don't mention "identification" as focus of the first >> table. >> >> 19) Section 5, sentence before Figure 1: >> "The following UML diagram illustrates the relationship of the MIB objects in >> the eoTable, eoRelationTable that describe the identity, context and >> relationship of an Energy Object." >> You should mention that you UML diagram furthermore contains objects from >> the Entity MIB. >> >> 20) Section 5, figure 1: >> There is a dotted line at the lower left that goes nowhere. Please cut it. >> >> 21) Section 5, grouping of MIB objects is inconsistent. >> In Figure 1 you have three groups: "Context", "Identification", "Relationships", >> where "Identifications" has three subgroups. The sentence below the figure >> emphasizes this grouping. However, the following subsections 5.1-5.4 are >> grouped differently. 5.1 is titled "Identification" but covers only a third of the >> objects under "Identification" in Figure 1. Section 5.2 is consistently with Figure >> 1 covering context information. Section 5.3 covers PoE and LLDP identification. >> Sections 5.4 is called "Relationships" but covers not just the objects under >> "Relationships" in Figure 1, but also objects from under "Identification" in >> Figure 1. Here is a clean-up needed. Please split the last sentence from section >> 5.4. It firs much better in section 5.3. >> >> 22) Section 5, enumeration under Figure 1: >> Please note that subsection 5.5 is not another group of MIB objects but refers >> to objects in subsection 5.1. The sentence above the enumeration implies that >> each numbered item would be a group of objects. >> >> 23) Section 5.1, 2nd paragraph, line 7: >> What is "primary Energy Object information"? >> >> 24) Section 5.4, 2nd paragraph, last sentence: >> "It is important to notice, that it is possible that" -> "Obviously," >> "not have an" -> "not have any" >> >> 25) Section 5.4, 4th paragraph >> The entire paragraph is in the wrong subsection. It rather belongs to subsection >> 5.1 or 5.3. >> >> 26) Section 6, DESCRIPTION clause of object eoEthPortGrpIndex: >> See comment 5). There is a full stop missing at the end of the second sentence. >> >> 27) Section 6, OBJECTS clause of GROUP energyObjectRelationTableGroup: >> The comment "Note that object eoRelationIndex is not included since it is not- >> accessible" is not really needed. Almost every Conformance section has such >> objects and usually this comment is omitted. >> >> Cheers, >> Juergen >> >> >>> -----Original Message----- >>> From: eman [mailto:eman-bounces@ietf.org] On Behalf Of Thomas Nadeau >>> Sent: Montag, 16. Dezember 2013 16:56 >>> To: eman mailing list >>> Subject: [eman] WG Last Call for >>> draft-ietf-eman-energy-monitoring-mib-08 >>> and draft-ietf-eman-energy-aware-mib-13 >>> >>> >>> As agreed at the last WG meeting, with the EMAN Framework >> completing >>> its WG LC the chairs would like to initiate a WG LC on draft-ietf- >>> eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib-13. >>> The WG LC will end on Dec 30 at 8AM EDT. >>> >>> Thank you, >>> >>> Nevil and Tom >>> >> _______________________________________________ >> eman mailing list >> eman@ietf.org >> https://www.ietf.org/mailman/listinfo/eman > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman > . > From tnadeau@lucidvision.com Fri Jan 17 10:24:02 2014 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A1601A1F4A for ; Fri, 17 Jan 2014 10:24:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FHYjvxJza0B4 for ; Fri, 17 Jan 2014 10:23:59 -0800 (PST) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id DB5C71A1F64 for ; Fri, 17 Jan 2014 10:23:55 -0800 (PST) Received: from [192.168.1.111] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 398BC26BB28E; Fri, 17 Jan 2014 13:23:43 -0500 (EST) Content-Type: multipart/signed; boundary="Apple-Mail=_2648797D-B68D-40D0-92B5-3D4C7C7FFEA7"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Thomas Nadeau In-Reply-To: Date: Fri, 17 Jan 2014 13:23:41 -0500 Message-Id: References: <18241430.1388083851066.JavaMail.root@mswamui-valley.atl.sa.earthlink.net> To: eman mailing list X-Mailer: Apple Mail (2.1827) Subject: [eman] A single OID versus multiple OIDs for EMAN MIBs X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 17 Jan 2014 18:24:02 -0000 --Apple-Mail=_2648797D-B68D-40D0-92B5-3D4C7C7FFEA7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii [Benoit Asked me to resend this] Speaking as a MIB Doctor and EMAN co-chair, I want to call = consensus so that we could close on this issue and so that the MIBs in = question can be progressed as well as give direct to any future EMAN = MIBs. The consensus was that we would use the recommendations from = RFC2578 instead of falling under a single "eman MIB root" OID. To this = end, I am directing the various MIB editors to please restructure their = OID assignments accordingly by rooting under the IANA management tree. =20= This is the relevant text from RFC 4181 section 4.5 for = reference. The value assigned to the MODULE-IDENTITY descriptor MUST be unique and (for IETF standards-track MIB modules) SHOULD reside under the mgmt subtree [RFC2578]. Most often it will be an IANA-assigned value directly under mib-2 [RFC2578], although for media-specific MIB modules that extend the IF-MIB [RFC2863] it is customary to use an IANA-assigned value under transmission [RFC2578]. In the past, some IETF working groups have made their own assignments from subtrees delegated to them by IANA, but that practice has proven problematic and is NOT RECOMMENDED. Thanks, --Tom --Apple-Mail=_2648797D-B68D-40D0-92B5-3D4C7C7FFEA7 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 iQIcBAEBCgAGBQJS2XUtAAoJEPcO+I7eiUJZboQP/26L8vWAf35iwSHlEb7c5Xh3 X74yObogMMyr8ULDQkycfOB9cTAYXLTbvFST9GP6idbJJVnp40W+SLPAcTKuTdCW KXolHrJAhHcr1/aUkW4ca5Oyw4KYZL9xp8xuHxXoacDFzeKdlsyNKxUFvLkzhVgB D7TibFOU4RvqiGunNwyIcS992Bz0xcbyLjMQI7280k7ntbg4LEGWZnPmaYiPVBPc 3S50L9zCFv1hsEe9Y+lq+di0YhY/fiGH3Jn12srMoM4kru1cuDfhUqbDC1MUu7/s 5g4I3mfRbaW2shmFs3tbDDhOyVd3ZcvKYzFQXokhwwm5NhcMWjlInUSppjc1foC6 e2U8re3rMlLZdnEztjauuPRr+ZbDRnSaG2lx8MmXknTVUcpiHRLOy7xm+uc5ayFk 6RFUOMXL1ohJYYVNBohd3P6hA4yJjk9yB7035rjuJAP61VkepvetLLdMG8GEfRZN iKwgJeOFzUEx2tKPS/kiW9KMjpLMuFF54YPtoz5PTZ70mjmQ9rJX9TYxXKBZ/sQ9 tUOVS5vjPWXM48PnX9IlmB5rNJOfB1PA6kcchjGMR4T9j804hJbJD7MO+JBBVGSG WWcpJzkW6NNHLxg3yUC4yY+W0P368L5QiXhjoo/3GaB94l9G7fOevb4Jzzp0yEAA msiHbfoOjcH5zgJffmTj =nDCj -----END PGP SIGNATURE----- --Apple-Mail=_2648797D-B68D-40D0-92B5-3D4C7C7FFEA7-- From bclaise@cisco.com Sun Jan 19 02:19:24 2014 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DDD91ADBF7 for ; Sun, 19 Jan 2014 02:19:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.639 X-Spam-Level: X-Spam-Status: No, score=-8.639 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x9ieBhnrz9p4 for ; Sun, 19 Jan 2014 02:19:22 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id 80D271ADBE5 for ; Sun, 19 Jan 2014 02:19:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1396; q=dns/txt; s=iport; t=1390126749; x=1391336349; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=ZtHwM3orb//d0f7QugHU2OsTtn1VxX9OK7DV43YBHH8=; b=KNEcQ65x7jHZ0NmiGP5qmjIJ9jurRBeq4tdJZHbClrDYjKQUdYaeo/0g MHbDC3QAzYpl9VHFW+DFnpdWe3zxAseLNLw/JBAaNEsrVOtYmzy3R1ma9 Arw2gkDRLiUNMrR+w02HEp8S60+LVzbLTF7Q4RvOOqt6BxXSPNDOOPSIP I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYFALOl21KQ/khL/2dsb2JhbABQCYMLvESBBhZ0giYBAQQ4QBELDhMWDwkDAgECAUUGAQwIAQGIAcQbF44dBwoBV4Q4AQOYIoZHi1GDLjuBLAUEFw X-IronPort-AV: E=Sophos;i="4.95,684,1384300800"; d="scan'208";a="3845106" Received: from ams-core-2.cisco.com ([144.254.72.75]) by aer-iport-1.cisco.com with ESMTP; 19 Jan 2014 10:19:08 +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 s0JAJ8bJ015264; Sun, 19 Jan 2014 10:19:08 GMT Message-ID: <52DBA69C.2010807@cisco.com> Date: Sun, 19 Jan 2014 11:19:08 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Thomas Nadeau , eman mailing list References: <18241430.1388083851066.JavaMail.root@mswamui-valley.atl.sa.earthlink.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [eman] A single OID versus multiple OIDs for EMAN MIBs X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 19 Jan 2014 10:19:24 -0000 Thank you Tom. Not sure why, but I didn't receive the first email on Jan 13th, even if I see it in the archive. Regards, Benoit > [Benoit Asked me to resend this] > > Speaking as a MIB Doctor and EMAN co-chair, I want to call consensus so that we could close on this issue and so that the MIBs in question can be progressed as well as give direct to any future EMAN MIBs. The consensus was that we would use the recommendations from RFC2578 instead of falling under a single "eman MIB root" OID. To this end, I am directing the various MIB editors to please restructure their OID assignments accordingly by rooting under the IANA management tree. > > This is the relevant text from RFC 4181 section 4.5 for reference. > > The value assigned to the MODULE-IDENTITY descriptor MUST be unique > and (for IETF standards-track MIB modules) SHOULD reside under the > mgmt subtree [RFC2578]. Most often it will be an IANA-assigned > value directly under mib-2 [RFC2578], although for media-specific > MIB modules that extend the IF-MIB [RFC2863] it is customary to use > an IANA-assigned value under transmission [RFC2578]. In the past, > some IETF working groups have made their own assignments from > subtrees delegated to them by IANA, but that practice has proven > problematic and is NOT RECOMMENDED. > > > Thanks, > > --Tom > From internet-drafts@ietf.org Mon Jan 20 09:52:48 2014 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43E861A01E9; Mon, 20 Jan 2014 09:52:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y6aW2xsT_n4F; Mon, 20 Jan 2014 09:52:47 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DD90E1A0218; Mon, 20 Jan 2014 09:52:45 -0800 (PST) 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.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140120175245.17335.12957.idtracker@ietfa.amsl.com> Date: Mon, 20 Jan 2014 09:52:45 -0800 Cc: eman@ietf.org Subject: [eman] I-D Action: draft-ietf-eman-framework-13.txt X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.15 List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2014 17:52:48 -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 Authors : John Parello Benoit Claise Brad Schoening Juergen Quittek Filename : draft-ietf-eman-framework-13.txt Pages : 57 Date : 2014-01-20 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-13 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-eman-framework-13 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 Jan 20 15:26:22 2014 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D88341A01CB; Mon, 20 Jan 2014 15:26:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gvKStgS-TxkA; Mon, 20 Jan 2014 15:26:21 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F6B21A026C; Mon, 20 Jan 2014 15:26:19 -0800 (PST) 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.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140120232619.11580.77967.idtracker@ietfa.amsl.com> Date: Mon, 20 Jan 2014 15:26:19 -0800 Cc: eman@ietf.org Subject: [eman] I-D Action: draft-ietf-eman-framework-14.txt X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.15 List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2014 23:26:23 -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 Authors : Benoit Claise Brad Schoening Juergen Quittek Filename : draft-ietf-eman-framework-14.txt Pages : 57 Date : 2014-01-20 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-14 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-eman-framework-14 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 blueroofmusic@gmail.com Mon Jan 20 17:55:09 2014 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 801B11A025B for ; Mon, 20 Jan 2014 17:55:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ix6Xg6Vv0Sb2 for ; Mon, 20 Jan 2014 17:55:07 -0800 (PST) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 3930F1A0002 for ; Mon, 20 Jan 2014 17:55:07 -0800 (PST) Received: by mail-ie0-f181.google.com with SMTP id tq11so7382947ieb.12 for ; Mon, 20 Jan 2014 17:55:07 -0800 (PST) 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=bfnwJ8k7oLMtiozAcatdUs7RdBdjlymNjUZIvvRchHw=; b=B8xieyTl70ZC8jE4SZDhb1ufZ3W9QKfA6kYrD6eUbGnWqKgCEJ527tg0C+6w+wwQBr 3O0Beyg0BhtsDKzW1iMZkldpavqytyoP+O5xrZxJlm371aHh/MRFRF5K4dkpwll7c+Se 9veIjCnCFnH29ZjkZN8a0zO35JIXJH34HSEIwHwVoQWlerz5Y0M1uGlK64SWDFK3bRUX +nY1PRws+U5ogC6aydJdckURryMKD/qTaOtsSa3o7wALHXfcSGSGaH8jt3fcZIo4o8dc 1GxnQ44XkDzm52rBGFpTacIi1OSsRuiWpWjMAtYuDL3T9gA+R7pHDcQLv7Kt9WdOFChN Q8jA== X-Received: by 10.42.227.195 with SMTP id jb3mr16193086icb.27.1390269307124; Mon, 20 Jan 2014 17:55:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.1.206 with HTTP; Mon, 20 Jan 2014 17:54:47 -0800 (PST) In-Reply-To: <20140120232619.11580.77967.idtracker@ietfa.amsl.com> References: <20140120232619.11580.77967.idtracker@ietfa.amsl.com> From: Ira McDonald Date: Mon, 20 Jan 2014 20:54:47 -0500 Message-ID: To: Ira McDonald Content-Type: multipart/alternative; boundary=001a1133df8e31849b04f0714c3f Cc: eman mailing list Subject: Re: [eman] I-D Action: draft-ietf-eman-framework-14.txt X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 21 Jan 2014 01:55:09 -0000 --001a1133df8e31849b04f0714c3f Content-Type: text/plain; charset=ISO-8859-1 Hi, Um...I don't think expiration of October 30, 2015 is six months after January 20th, 2014 - might want to fix this more carefully in the next draft. Cheers, - Ira Ira McDonald (Musician / Software Architect) Co-Chair - TCG Trusted Mobility Solutions WG Chair - Linux Foundation Open Printing WG Secretary - IEEE-ISTO Printer Working Group Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG IETF Designated Expert - IPP & Printer MIB Blue Roof Music / High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto: blueroofmusic@gmail.com Winter 579 Park Place Saline, MI 48176 734-944-0094 Summer PO Box 221 Grand Marais, MI 49839 906-494-2434 On Mon, Jan 20, 2014 at 6:26 PM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Energy Management Working Group of the > IETF. > > Title : Energy Management Framework > Authors : Benoit Claise > Brad Schoening > Juergen Quittek > Filename : draft-ietf-eman-framework-14.txt > Pages : 57 > Date : 2014-01-20 > > 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-14 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-eman-framework-14 > > > 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/ > > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman > --001a1133df8e31849b04f0714c3f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

Um...I don't thin= k expiration of October 30, 2015 is six months after
January 20th,= 2014 - might want to fix this more carefully in the next
draft.

Cheers,
- Ira


Ira McDonald (Musician / Software Archite= ct)
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - Linux Founda= tion Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Int= ernet Printing Protocol WG
IETF Designated Expert - IPP & Printer MI= B
Blue Roof Music / High North Inc
http:= //sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthincmailto: blue= roofmusic@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 Mon, Jan 20, 2014 at 6:26 PM, <internet-drafts@ietf.org> wrote:

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

=A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Energy Management Framework
=A0 =A0 =A0 =A0 Authors =A0 =A0 =A0 =A0 : Benoit Claise
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Brad Schoening
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Juergen Quittek
=A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-eman-framework-14.txt<= br> =A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 57
=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2014-01-20

Abstract:
=A0 =A0 =A0 =A0This document defines a framework for Energy Management for<= br> =A0 =A0 =A0 =A0devices and device components within or connected to
=A0 =A0 =A0 =A0communication networks. =A0The framework presents a physical=
=A0 =A0 =A0 =A0reference model and information model. The information
=A0 =A0 =A0 =A0model consists of an Energy Management Domain as a set of =A0 =A0 =A0 =A0Energy Objects. Each Energy Object can be attributed with =A0 =A0 =A0 =A0identity, classification, and context. =A0Energy Objects can=
=A0 =A0 =A0 =A0be monitored and controlled with respect to power, Power
=A0 =A0 =A0 =A0State, energy, demand, Power Attributes, and battery.
=A0 =A0 =A0 =A0Additionally the framework models relationships and
=A0 =A0 =A0 =A0capabilities between Energy Objects.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-eman-framework/<= /a>

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-eman-framework-14

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-eman-frame= work-14


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
ht= tps://www.ietf.org/mailman/listinfo/eman

--001a1133df8e31849b04f0714c3f-- From tnadeau@lucidvision.com Mon Jan 20 17:57:36 2014 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 215281A025B for ; Mon, 20 Jan 2014 17:57:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.434 X-Spam-Level: X-Spam-Status: No, score=-2.434 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kP7aDNkKcj2m for ; Mon, 20 Jan 2014 17:57:34 -0800 (PST) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 861151A0002 for ; Mon, 20 Jan 2014 17:57:33 -0800 (PST) Received: from [192.168.1.100] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id C326F26BFCE6; Mon, 20 Jan 2014 20:57:32 -0500 (EST) Content-Type: multipart/signed; boundary="Apple-Mail=_25A37A9C-AFD3-4BBD-A463-6B2526D329F6"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Thomas Nadeau In-Reply-To: Date: Mon, 20 Jan 2014 20:57:32 -0500 Message-Id: <9F49F1BE-ABAE-44F2-BF52-F457738517D5@lucidvision.com> References: <20140120232619.11580.77967.idtracker@ietfa.amsl.com> To: Ira McDonald X-Mailer: Apple Mail (2.1827) Cc: eman mailing list Subject: Re: [eman] I-D Action: draft-ietf-eman-framework-14.txt X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 21 Jan 2014 01:57:36 -0000 --Apple-Mail=_25A37A9C-AFD3-4BBD-A463-6B2526D329F6 Content-Type: multipart/alternative; boundary="Apple-Mail=_A78A1341-16E3-4001-AD78-23A1FB35A022" --Apple-Mail=_A78A1341-16E3-4001-AD78-23A1FB35A022 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Good catch, but I think the RFC editor can fix that as a minor = edit.=20 --Tom On Jan 20, 2014:8:54 PM, at 8:54 PM, Ira McDonald = wrote: > Hi, >=20 > Um...I don't think expiration of October 30, 2015 is six months after > January 20th, 2014 - might want to fix this more carefully in the next > draft. >=20 > Cheers, > - Ira >=20 >=20 > Ira McDonald (Musician / Software Architect) > Co-Chair - TCG Trusted Mobility Solutions WG > Chair - Linux Foundation Open Printing WG > Secretary - IEEE-ISTO Printer Working Group > Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG > IETF Designated Expert - IPP & Printer MIB > Blue Roof Music / High North Inc > http://sites.google.com/site/blueroofmusic > http://sites.google.com/site/highnorthinc > mailto: blueroofmusic@gmail.com > Winter 579 Park Place Saline, MI 48176 734-944-0094 > Summer PO Box 221 Grand Marais, MI 49839 906-494-2434 >=20 >=20 >=20 > On Mon, Jan 20, 2014 at 6:26 PM, wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Energy Management Working Group of = the IETF. >=20 > Title : Energy Management Framework > Authors : Benoit Claise > Brad Schoening > Juergen Quittek > Filename : draft-ietf-eman-framework-14.txt > Pages : 57 > Date : 2014-01-20 >=20 > 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. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-eman-framework/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-eman-framework-14 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-eman-framework-14 >=20 >=20 > 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. >=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 >=20 > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman --Apple-Mail=_A78A1341-16E3-4001-AD78-23A1FB35A022 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1

Good catch, but I think the RFC editor can fix that as a minor edit. 

--Tom


On Jan 20, 2014:8:54 PM, at 8:54 PM, Ira McDonald <blueroofmusic@gmail.com> wrote:

Hi,

Um...I don't think expiration of October 30, 2015 is six months after
January 20th, 2014 - might want to fix this more carefully in the next
draft.

Cheers,
- Ira


Ira McDonald (Musician / Software Architect)
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music / High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto: blueroofmusic@gmail.com
Winter  579 Park Place  Saline, MI  48176  734-944-0094
Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434



On Mon, Jan 20, 2014 at 6:26 PM, <internet-drafts@ietf.org> wrote:

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

        Title           : Energy Management Framework
        Authors         : Benoit Claise
                          Brad Schoening
                          Juergen Quittek
        Filename        : draft-ietf-eman-framework-14.txt
        Pages           : 57
        Date            : 2014-01-20

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-14

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-eman-framework-14


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/

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

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

--Apple-Mail=_A78A1341-16E3-4001-AD78-23A1FB35A022-- --Apple-Mail=_25A37A9C-AFD3-4BBD-A463-6B2526D329F6 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 iQIcBAEBCgAGBQJS3dQMAAoJEPcO+I7eiUJZ2eEP/RCwuhT8fKyPInjzqTA29NKw 8FlEEwjOXaJbpQ8fKJLVgLffqgDC0JS6mxxn6LTGIo515xSKP86PCcGr8yuz1Px6 qJe/vJpeokbVFcpt5VtJVQ4GKozrrrVi77E/6FJngcPGSZrVZJCjMkJtoP1yVZi2 Nv97JdHt7W/OAaCOihaWiZ3keqnMSWfK7W4TIHOkjyODuHI2Tp8zi1Ex157O/X8k h8hiaSgEaFghYRTfkgxUp0fHZMFBjF0Y8qN0ipaTRIjgpyyLVJWglNOxWgf4sHhY fbczh+rdHlQ4h4bHE4WWUc73019WWDtlS19S0of8kfVmVXT/mcaYzqPC2Br+qyry xOBpOv0ggLONrlM859UHvkjnt1pa80J2egITpxOOHSfKcQXqTi8vaNrNvWVyDljE J+ydeuv6RsQhz6usgWGpFECy69piMGTEJpON/MulgAuEg57R2WlB3i3V3djuU9L9 DTSTc5nLM3/+VKAB5eQugWM5UIU2pKPfRy1H1Qr3JNn6gh9SqYBDuRSZkZGqWsWT UvS8U9tcSSGfG+X+/H59JTy60kZppWsMOTaQUiQShEs6DCjdfQG7981NH/38hbG2 d8tIVQwRo1zny8LTjoSNeq4lj/8foqkISz/sk5tvx1VlkACBFPAXlSFIMqmfJSGe H0YJAN3dUvy6MbSbwxL6 =l+0y -----END PGP SIGNATURE----- --Apple-Mail=_25A37A9C-AFD3-4BBD-A463-6B2526D329F6-- From bclaise@cisco.com Tue Jan 21 02:05:11 2014 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6931A1A02C1 for ; Tue, 21 Jan 2014 02:05:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.036 X-Spam-Level: X-Spam-Status: No, score=-10.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Ki45W5VaTXw for ; Tue, 21 Jan 2014 02:05:09 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id 678B01A00A4 for ; Tue, 21 Jan 2014 02:05:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2737; q=dns/txt; s=iport; t=1390298709; x=1391508309; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=xD4YpNNVCXa5Mc/Z/JqbEP1+kkOGv3TCeEdrlu6JsEA=; b=NnjHjYVPU3H/Kf8I7d42JQKemcwOGH0ItDq0aPDGa7iD5X/iu5XMHvBs A5d5JqyO5oGhA0EdP9aMHqZiPI7kDD2ZFhbAeWbkrgL1SjFmIWdqeiSkU LWHFUinyFKHF1WfdB/zCR11TC7PvvVJM6CyZsgUb/NlbwiUt2Zhqwy1zE s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8FAGhF3lKQ/khR/2dsb2JhbABZgws4vDaBDxZ0giUBAQEDAQEBARoVAQU2Cg0ECxEEAQEKFgQEBwkDAgECARUfCQgGAQwGAgEBh3kIDcN6EwSOJ18GhDIBA5gihkeLUYFvgT87gSw X-IronPort-AV: E=Sophos;i="4.95,695,1384300800"; d="scan'208";a="3936203" Received: from ams-core-1.cisco.com ([144.254.72.81]) by aer-iport-1.cisco.com with ESMTP; 21 Jan 2014 10:05:08 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s0LA58wO018374; Tue, 21 Jan 2014 10:05:08 GMT Message-ID: <52DE4654.7010904@cisco.com> Date: Tue, 21 Jan 2014 11:05:08 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Juergen Quittek , eman mailing list References: <5298B7FA.1010509@cisco.com> <52A5A9FA.80101@cisco.com> <52A5C2A6.9000501@cisco.com> <52AB8777.9060704@cisco.com> <653A4764-315C-4671-B0DA-389553CB3E29@lucidvision.com> <9AB93E4127C26F4BA7829DEFDCE5A6E8688B333E@DAPHNIS.office.hd> In-Reply-To: <9AB93E4127C26F4BA7829DEFDCE5A6E8688B333E@DAPHNIS.office.hd> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib-13 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 21 Jan 2014 10:05:11 -0000 Hi Jürgen, > Dear all, > > Here are my last two comments for this WGLC. Both concerns the conformance section of the ENERGY-OBJECT-MIB module in draft-ietf-eman-energy-monitoring-mib-08: > > 1. I may have missed a point here: Why is the Entity MIB not mandatory anymore to implement? It is just two additional objects, since entPhysicalIndex from this MIB is needed anyway. Particularly, we considered the UUID provided by this MIB essential for our framework. I don't understand this point. We have right now Every Energy Object MUST implement the unique index, entPhysicalIndex, entPhysicalName and entPhysicalUUID from the ENTITY MIB [RFC6933]. Module Compliance with respect to entity4CRCompliance of ENTITY-MIB should be supported which require a limited number of objects supported (entPhysicalClass, entPhysicalName, entPhysicalUUID). Btw, we miss the entPhysicalClass in the first setence. Will be corrected. Or maybe you meant that we must have a MUST in the second sentence? Every Energy Object MUST implement the unique index, entPhysicalIndex, entPhysicalClass, entPhysicalName, and entPhysicalUUID from the ENTITY MIB [RFC6933]. Module Compliance with respect to entity4CRCompliance of ENTITY-MIB MUST be supported which require a limited number of objects supported (entPhysicalIndex, entPhysicalClass, entPhysicalName, entPhysicalUUID). Note: these 2 sentences are somehow redundant. We might improve this if you want. > > 2. Why is the module compliance dependency on the Entity MIB repeated in the DESCRIPTION clauses of all optional groups within a MODULE-COMPLIANCE declaration? I think It is fully sufficient to have it stated in the top DESCRIPTION clause of the MODULE-COMPLIANCE declaration. Does it make any sense to repeat it for optional groups? Yes. Regards, Benoit > > Cheers, > Juergen > > >> -----Original Message----- >> From: eman [mailto:eman-bounces@ietf.org] On Behalf Of Thomas Nadeau >> Sent: Montag, 16. Dezember 2013 16:56 >> To: eman mailing list >> Subject: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib-08 >> and draft-ietf-eman-energy-aware-mib-13 >> >> >> As agreed at the last WG meeting, with the EMAN Framework >> completing its WG LC the chairs would like to initiate a WG LC on draft-ietf- >> eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib-13. >> The WG LC will end on Dec 30 at 8AM EDT. >> >> Thank you, >> >> Nevil and Tom >> > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman > From bclaise@cisco.com Tue Jan 21 03:48:48 2014 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BAEC1A009A for ; Tue, 21 Jan 2014 03:48:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.035 X-Spam-Level: X-Spam-Status: No, score=-10.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vj6IoW3hReL2 for ; Tue, 21 Jan 2014 03:48:46 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id 3DEAA1A0061 for ; Tue, 21 Jan 2014 03:48:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11111; q=dns/txt; s=iport; t=1390304925; x=1391514525; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=hPTjxOIV+y1sKQNdw6RKJqODuWEBrnYY/W0iI0tVo+E=; b=iMmrtX41P7FoVMK6VmP6WHj1ZrsCu9TlkrfQ/OW11SPuJlv6nBu8a2Uu tZ4wJD4J6VcCn2XLCI/jXUKltjnBUrygf1NapU1P3ju4hxvYZRod2/qDV sHjeaFkiYygQn6tGWqxzOrwWA2Td3PbetNntlpFiF4hEbyta/8TuY3IT1 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlMFAL5d3lKQ/khL/2dsb2JhbABQBgODCzhQu2yBExZ0giUBAQEEAQEBaAMEBgEQCxgJFggHCQMCAQIBDwYfEQYNAQUCAQEFEodWAxEIBb4ZDYVWF4xrgSwNDT4QBwkIhCcEjj2HeYFsgTKFFYYWhTuDLjs X-IronPort-AV: E=Sophos;i="4.95,696,1384300800"; d="scan'208,217";a="3272266" Received: from ams-core-2.cisco.com ([144.254.72.75]) by aer-iport-2.cisco.com with ESMTP; 21 Jan 2014 11:48:44 +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 s0LBmivI031808; Tue, 21 Jan 2014 11:48:44 GMT Message-ID: <52DE5E9C.2060200@cisco.com> Date: Tue, 21 Jan 2014 12:48:44 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Ira McDonald References: <20140120232619.11580.77967.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------080703050908070508040705" Cc: eman mailing list Subject: Re: [eman] I-D Action: draft-ietf-eman-framework-14.txt X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 21 Jan 2014 11:48:48 -0000 This is a multi-part message in MIME format. --------------080703050908070508040705 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Thanks Ira, Done in the new temp version. Regards, Benoit > Hi, > > Um...I don't think expiration of October 30, 2015 is six months after > January 20th, 2014 - might want to fix this more carefully in the next > draft. > > Cheers, > - Ira > > > Ira McDonald (Musician / Software Architect) > Co-Chair - TCG Trusted Mobility Solutions WG > Chair - Linux Foundation Open Printing WG > Secretary - IEEE-ISTO Printer Working Group > Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG > IETF Designated Expert - IPP & Printer MIB > Blue Roof Music / High North Inc > http://sites.google.com/site/blueroofmusic > http://sites.google.com/site/highnorthinc > mailto: blueroofmusic@gmail.com > Winter 579 Park Place Saline, MI 48176 734-944-0094 > Summer PO Box 221 Grand Marais, MI 49839 906-494-2434 > > > > On Mon, Jan 20, 2014 at 6:26 PM, > wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Energy Management Working Group > of the IETF. > > Title : Energy Management Framework > Authors : Benoit Claise > Brad Schoening > Juergen Quittek > Filename : draft-ietf-eman-framework-14.txt > Pages : 57 > Date : 2014-01-20 > > 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-14 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-eman-framework-14 > > > 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/ > > _______________________________________________ > 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 --------------080703050908070508040705 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Thanks Ira,

Done in the new temp version.

Regards, Benoit
Hi,

Um...I don't think expiration of October 30, 2015 is six months after
January 20th, 2014 - might want to fix this more carefully in the next
draft.

Cheers,
- Ira


Ira McDonald (Musician / Software Architect)
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music / High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto: blueroofmusic@gmail.com
Winter  579 Park Place  Saline, MI  48176  734-944-0094
Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434



On Mon, Jan 20, 2014 at 6:26 PM, <internet-drafts@ietf.org> wrote:

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

        Title           : Energy Management Framework
        Authors         : Benoit Claise
                          Brad Schoening
                          Juergen Quittek
        Filename        : draft-ietf-eman-framework-14.txt
        Pages           : 57
        Date            : 2014-01-20

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-14

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-eman-framework-14


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/

_______________________________________________
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

--------------080703050908070508040705-- From moulchan@cisco.com Tue Jan 21 04:40:45 2014 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA1B91A00C7 for ; Tue, 21 Jan 2014 04:40:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.035 X-Spam-Level: X-Spam-Status: No, score=-10.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3n1dt2PjCR8i for ; Tue, 21 Jan 2014 04:40:43 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) by ietfa.amsl.com (Postfix) with ESMTP id A1F651A00C3 for ; Tue, 21 Jan 2014 04:40:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=29551; q=dns/txt; s=iport; t=1390308042; x=1391517642; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=NwBwkPh+nc6xipZ9vdV/szneA2yeQEfFmMJLc3HYrlU=; b=VKjbSm0/2qFJQjyK0JvzxaPjljVDaAyXVXZc7n6jSEG63V5Y1HEWhTv2 2VjHv7aHx+lR9UGUax7nZYA4AWCOZXvuSLr0sBtrDrMIbKxWvh38qygcG g+d5kDhbK6eBKbulYfh+g5dtrFzwr7qA3hPWdRuH1m140DdDnKkhnChoY g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AigFADZq3lKtJXHA/2dsb2JhbABQCYJHRDhWu2qBDhZ0giUBAQEDAQEBARpRBAwHBAIBCBEEAQEhAQIEBycLFAkIAgQBEgmHdAgNxAAXjiQKAQEBIyEGCgECBIQyBJgikhiBb4E+gXE5 X-IronPort-AV: E=Sophos;i="4.95,696,1384300800"; d="scan'208,217";a="14340381" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by alln-iport-3.cisco.com with ESMTP; 21 Jan 2014 12:40:42 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id s0LCegV9004758 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 21 Jan 2014 12:40:42 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.39]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0123.003; Tue, 21 Jan 2014 06:40:41 -0600 From: "Mouli Chandramouli (moulchan)" To: "karagian@cs.utwente.nl" , "eman@ietf.org" Thread-Topic: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib-13 Thread-Index: AQHPFqX+V4Fbg5lprEei1KNCb1b8VQ== Date: Tue, 21 Jan 2014 12:40:40 +0000 Message-ID: References: <5298B7FA.1010509@cisco.com> <52A5A9FA.80101@cisco.com> <52A5C2A6.9000501@cisco.com> <52AB8777.9060704@cisco.com> <653A4764-315C-4671-B0DA-389553CB3E29@lucidvision.com> <5339BC8D-660B-4659-96DC-C0170E124134@lucidvision.com> <9AB93E4127C26F4BA7829DEFDCE5A6E8688B32A5@DAPHNIS.office.hd> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.142.100.79] Content-Type: multipart/alternative; boundary="_000_CF0466C51CFE4moulchanciscocom_" MIME-Version: 1.0 Subject: Re: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib-13 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 21 Jan 2014 12:40:45 -0000 --_000_CF0466C51CFE4moulchanciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Georgios, We are addressing the comments with respect to draft-ietf-eman-energy-aware= -mib-13. Replies inline. Thanks Mouli Hi all, Sorry for the delay on providing comments on time for the WGLC of draft-iet= f-eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib-13. Here are my comments! Many of the comments that I wanted to send are similar to the ones sent by = Juergen Quittek. Therefore, I will send only the ones that are different! =3D> Regarding: draft-ietf-eman-energy-aware-mib-13: Comment_1: Section 5, page 6 shows the entries/attributes (MIB objects) of= the eaTable and eoRelationTable. In Figure 1 the UML diagram illustrates t= he relationship of the MIB objects in the eatable and eoRelationTable. Howe= ver not all entries (MIB objects) depicted in eaTable and eoRelationTable (= page 6) are shown in the UML diagrams. Please elaborate on this in the text= . ycm>> The UML diagram has been updated. Comment_2: In section 5.2, page 20 is mentioned: =93The Energy Object can b= e classified as consuming power or supplying power to other devices or that= Energy Object can perform both of those functions, ..=94. However, in the = formal MIB definition on page 20, eoPowerCategory can get the values: consu= mer (0), producer(1), meter(2), distributor(3) or store(4). From what I can= see no value is provided for the situation that the energy object can perf= orm both functions consumer and producer. ycm>> This point has been discussed at length and the approach that we ha= ve taken is to use a vector for the Keywords to allow for further defining = context you describe. We proposed scalar for the PRIMARY category. ycm>> Please refer to http://www.ietf.org/mail-archive/web/eman/current/= msg02033.html =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D =3D> Regarding draft-ietf-eman-energy-monitoring-mib-08: Comment_1:Section 5: It is not clear what is the relation between the ENERG= Y-OBJECT-MIB MIB module tables, the associated UML diagram given in Figure = 1 and the text other subsections (5.1, 5.2, 5.3, 5.4, 5.5 and 5.6.).. Pleas= e make this relation clear. Comment_2: The same holds for the powerAttributeMIB MIB module tables, UML = diagram given in Figure 2 and subsections (5.1, 5.2, 5.3, 5.4, 5.5 and 5.6.= ). Comment_3: The description of the powerAttributeMIB MIB module tables on pa= ge 8 is too short. A similar description as the one described for the ENERG= Y-OBJECT-MIB MIB module tables in page 6 could be also provided, Comment_4: Some parts of the UML diagram given in Figure 2 as representing = the relations in the powerAttributeMIB are (probabl) part of the ENERGY-OB= JECT-MIB. These are the Energy ParametersTable and EnergyTable. Comment_5: not all entries (MIB objects) depicted in the ENERGY-OBJECT-MIB = MIB module tables are shown in the UML diagram depicted in Fgure 1.Please e= laborate. Comment_6: the same holds for powerAttributeMIB MIB module tables and the = UML diagram depicted in Figure 2. Comment_7: Maybe the title of Section 5.1 should be: Enetgy Object Identity= , instead of Energy Object Information? Comment_8: The description of the vertical axis used in Figure 3 is not cle= ar to me. Are both horizontal axis and vertical axis representing time. Reg= arding the vertical axis you might want to say that the vertical axis repre= sents the amount of measured power ? Comment_9: The description of Figure 4 is not clear to me. You might includ= e at the right sde of the figure and for each window the term S+L, so (S1+L= , S2+L, S3+L and S4+L). You can then explain that the value of the EoEnergy= Consumed is obtained at these time intervals (Sx+L).. Comment_10: Section 6 is very important and its importance should be emphas= ized more clearly in the Introduction. Comment_11: In Section 6 the term EMAN-MON-MIB is used for the first time. = I considered that it referes to this document. Please emphasize that in the= text. Comment_12: Section 8 provides an example for the implementation of the Ene= rgy Object, including the Energy Object relationships. Is it possible to pr= ovide an example of the IANAEnergyRelationship (in particular regaring aggr= egation) defined in [ENERGY-AWARE-MIB]. Comment_13: Are the MIB objects defined in this draft complying with the me= chanisms defined by SMIv2 [RFC2578, RFC2579, RFC2580? If yes, please emphas= ize this in the document! Best regards, Georgios Karagiannis ________________________________ Van: eman [eman-bounces@ietf.org] namens Thom= as Nadeau [tnadeau@lucidvision.com] Verzonden: maandag 30 december 2013 20:52 To: Juergen Quittek Cc: eman mailing list Onderwerp: Re: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mi= b-08 and draft-ietf-eman-energy-aware-mib-13 The note said 8AM EDT. *) Anyways, send over your comments ASAP. --Tom On Dec 30, 2013:1:46 PM, at 1:46 PM, Juergen Quittek > wrote: > Hi Tom, > I missed the fact that the deadline is already in the morning of today. I= thought I had the full day today for sending them. There are still some co= mments that I planned to send this evening. I will send them asap and hope = they will be OK even if a few hours late. > Thanks, > Juergen > >> -----Original Message----- >> From: eman [mailto:eman-bounces@ietf.org] On Behalf Of Thomas Nadeau >> Sent: Montag, 30. Dezember 2013 14:44 >> To: eman mailing list >> Subject: Re: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-m= ib- >> 08 and draft-ietf-eman-energy-aware-mib-13 >> >> >> WG, >> >> This concludes the WG LC on the MIBs. We have received just one se= t >> of comments from the WG and one set of comments regarding the OID >> numbering. Would the document editors please address these and republish >> the drafts ASAP so that we can proceed with progressing the drafts? >> >> Cheers and Happy Holidays, >> >> Tom >> >> >>> >>> As agreed at the last WG meeting, with the EMAN Framework >> completing its WG LC the chairs would like to initiate a WG LC on draft-= ietf- >> eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib-13. >> The WG LC will end on Dec 30 at 8AM EDT. >>> >>> Thank you, >>> >>> Nevil and Tom >>> >>> >>> _______________________________________________ >>> eman mailing list >>> eman@ietf.org >>> https://www.ietf.org/mailman/listinfo/eman > > --_000_CF0466C51CFE4moulchanciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi  Georgios,
<= br>
W= e are addressing the comments with respect to draft-ietf-eman-en= ergy-aware-mib-13.
<= br>
R= eplies inline. 
<= br>
T= hanks
Mouli

.EmailQuote { BORDER-LEFT: #800000 2px solid; PADDING-LEFT: 4pt; MARGIN-LEFT: 1pt }

Hi all,

 

Sorry for the delay on providing comments on time for the WGLC of = draft-ietf-eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib-13.

 

Here are my comments!

Many of the comments that I wanted to send are similar to the ones= sent by Juergen Quittek. Therefore, I will send only the ones that are different!

 

=3D> Regarding: draft-ietf-eman-energy-aware-mib-13:=

 

Comment_1: Section 5, page 6 shows the entries/attributes  (MIB objects) of the eaTable= and eoRelationTable. In Figure 1 the UML diagram illustrates the relations= hip of the MIB objects in the eatable and eoRelationTable. However not all = entries (MIB objects) depicted in eaTable and eoRelationTable (page 6) are shown in the UML diagrams. Please elabora= te on this in the text.

ycm>>  The UML diagram has been updated. 

 

Co= mment_2: In section 5.2, page 20 is mentioned: =93The Energy Object can be = classified as consuming power or supplying power to other devices or that E= nergy Object can perform both of those functions, ..=94. However, in the formal MIB definition on page 20, eoPowerCategory c= an get the values: consumer (0), producer(1), meter(2), distributor(3) or s= tore(4). From what I can see no value is provided for the situation that th= e energy object can perform both functions consumer and producer.

 

 ycm>> This point has been discussed at length  and the ap= proach that we have taken is to use = a vector for the Keywords to allow for further defining context you describ= e. We proposed scalar for the PRIMARY category. 



=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D

 

=3D> Regarding draft-ietf-eman-energy-monitoring-mib-08:

 

Comment_1:Section 5: It is not clear what is the relation between = the ENERGY-OBJECT-MIB MIB module tables, the associated UML diagram given in Figure 1 and the text other subsections (5= .1, 5.2, 5.3, 5.4, 5.5 and 5.6.).. Please make this relation clear.

 

Comment_2: The same holds for the powerAttributeMIB MIB module tab= les, UML diagram given in Figure 2 and subsections (5.1, 5.2, 5.3, 5.4, 5.5 and 5.6.).

 

Comment_3: The description of the powerAttributeMIB MIB module tab= les on page 8 is too short. A similar description as the one described for the ENERGY-OBJECT-MIB MIB module tables in page 6= could be also provided,

 

Comment_4: Some parts of the UML diagram given in Figure 2 as repr= esenting the relations in the powerAttributeMIB are (probabl)  part of the E= NERGY-OBJECT-MIB. These are the Energy ParametersTable and EnergyTable.

 

Comment_5: not all entries (MIB objects) depicted in the ENERGY-OB= JECT-MIB MIB module tables are shown in the UML diagram depicted in Fgure 1.Please elaborate.=

 

Comment_6: the same holds for powerAttributeMIB MIB module tables  and the UML diagram depicted= in Figure 2.

 

Comment_7: Maybe the title of Section 5.1 should be: Enetgy Object= Identity, instead of Energy Object Information?

 

Comment_8: The description of the vertical axis used in Figure 3 i= s not clear to me. Are both horizontal axis and vertical axis representing time. Regarding the vertical axis you might= want to say that the vertical axis represents the amount of measured power= ?

 

Comment_9: The description of Figure 4 is not clear to me. You mig= ht include at the right sde of the figure and for each window the term S+L, so (S1+L, S2+L, S3+L and S4&= #43;L). You can then explain that the value of the EoEnergyConsumed is obta= ined at these time intervals (Sx+L)..

 

Comment_10: Section 6 is very important and its importance should = be emphasized more clearly in the Introduction.

 

Comment_11: In Section 6 the term EMAN-MON-MIB is used for the fir= st time. I considered that it referes to this document. Please emphasize that in the text.

 

Comment_12: Section 8 provides an example for the implementation o= f the Energy Object, including the Energy Object relationships. Is it possible to provide an example of the IANAEnergyRelat= ionship (in particular regaring aggregation) defined in [ENERGY-AWARE-MIB].=

 

Comment_13: Are the MIB objects defined in this draft complying wi= th the mechanisms defined by SMIv2 [RFC2578, RFC2579, RFC2580? If yes, please emphasize this in the document!

 

Best regards,

Georgios Karagiannis

 

 

 

Van: eman [eman-bounces= @ietf.org] namens Thomas Nadeau [tnadeau@lucidvision.com]
Verzonden: maandag 30 december 2013 20:52
To: Juergen Quittek
Cc: eman mailing list
Onderwerp: Re: [eman] WG Last Call for draft-ietf-eman-energy-monito= ring-mib-08 and draft-ietf-eman-energy-aware-mib-13


        The note said 8AM EDT. *)

        Anyways, send over your comments= ASAP.

        --Tom


On Dec 30, 2013:1:46 PM, at 1:46 PM, Juergen Quittek <Quittek@neclab.eu> wrote:

> Hi Tom,
> I missed the fact that the deadline is already in the morning of today= . I thought I had the full day today for sending them. There are still some= comments that I planned to send this evening. I will send them asap and ho= pe they will be OK even if a few hours late.
> Thanks,
>    Juergen
>
>> -----Original Message-----
>> From: eman [mailto:eman-bounces@ietf.org] On Behalf Of Thomas Nadeau
>> Sent: Montag, 30. Dezember 2013 14:44
>> To: eman mailing list
>> Subject: Re: [eman] WG Last Call for draft-ietf-eman-energy-monito= ring-mib-
>> 08 and draft-ietf-eman-energy-aware-mib-13
>>
>>
>>       WG,
>>
>>       This concludes the WG LC on th= e MIBs. We have received just one set
>> of comments from the WG and one set of comments regarding the OID<= br> >> numbering. Would the document editors please address these and rep= ublish
>> the drafts ASAP so that we can proceed with progressing the drafts= ?
>>
>>       Cheers and Happy Holidays,
>>
>>       Tom
>>
>>
>>>
>>>      As agreed at the last WG meeting= , with the EMAN Framework
>> completing its WG LC the chairs would like to initiate a WG LC on = draft-ietf-
>> eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib= -13.
>> The WG LC will end on Dec 30 at 8AM EDT.
>>>
>>>      Thank you,
>>>
>>>      Nevil and Tom
>>>
>>>
>>> _______________________________________________
>>> eman mailing list
>>> eman@ietf.org
>>> https://www.ietf.org/mailman/listinfo/eman
>
>

--_000_CF0466C51CFE4moulchanciscocom_-- From tnadeau@lucidvision.com Tue Jan 21 12:52:47 2014 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 939B01A01D1; Tue, 21 Jan 2014 12:52:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.398 X-Spam-Level: X-Spam-Status: No, score=0.398 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FM_ASCII_ART_SPACINGc=0.833, J_CHICKENPOX_91=0.6, RP_MATCHES_RCVD=-0.535] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8LU5CuACcfji; Tue, 21 Jan 2014 12:52:41 -0800 (PST) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 6400A1A0168; Tue, 21 Jan 2014 12:52:40 -0800 (PST) Received: from [192.168.1.110] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 9DC9D26C166B; Tue, 21 Jan 2014 15:52:39 -0500 (EST) From: Thomas Nadeau Content-Type: multipart/signed; boundary="Apple-Mail=_0AC5826E-9193-4682-89FF-BAB8B559FEE3"; protocol="application/pgp-signature"; micalg=pgp-sha512 Message-Id: <8F88CD1C-C5F1-497D-8643-538E7D1C3BDF@lucidvision.com> Date: Tue, 21 Jan 2014 15:52:38 -0500 To: "MIB Doctors (E-mail)" , eman mailing list Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) X-Mailer: Apple Mail (2.1827) Subject: [eman] MIB Doctor Review of draft-ietf-eman-energy-aware-mib-13 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 21 Jan 2014 20:52:47 -0000 --Apple-Mail=_0AC5826E-9193-4682-89FF-BAB8B559FEE3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, I reviewed this draft as part of the MIB Doctor review on = Tuesday, January 21, 2014. My comments inline begin with TOM: General Comments on the draft: 1) There are a number of warnings in the id-nits run. Please check = and correct these. 2) I found a number of references inside of DESCRIPTION clauses. = Remember that once the MIB is stripped out of this draft, those = references have no meaning. Please either add a Reference clause below, = or use an RFC/IEEE number that can easily be found. Please go through = every place where there is a reference in a DESCRIPTION clause and make = this correction as I will not comment on each and every one. 3) I generally like to include a comment after each MIB in the = IMPORTS clause stating which RFC it comes from. It is a good habit since = not all MIB modules are easily found for compilation. 4) The EMAN WG and MIB Doctors consensus was to root all MIB modules = under transmission, rather than under the single OID energyMIB. These = modules still use the older approach, so please correct them. 5) Here is the output from smilint on each of the modules. I do not = have access to smicng, so this is the best I could do for compilation. = As you can see there are a number of nits that are found that should be = corrected such as importing values that are unused. Please fix these.=20 IANA-ENERGY-RELATION-MIB: [server:libsmi-0.4.8/mibs/ietf] tnadeau% smilint -l 6 -i namelength-32 = ./SNMPv2-TC ./SNMPv2-SMI ./SNMPv2-CONF ./SNMP-FRAMEWORK-MIB = ./INET-ADDRESS-MIB ./ENTITY-MIB ./UUID-TC-MIB ./IANA-ENERGY-RELATION-MIB ./SNMPv2-SMI:1: [5] {module-already-loaded} warning: module `SNMPv2-SMI' = is already loaded, aborting parser on this file ./SNMPv2-CONF:4: [2] {import-failed} identifier `ObjectSyntax' cannot be = imported from module `SNMPv2-SMI' ./SNMP-FRAMEWORK-MIB:275: [5] {integer-misuse} warning: use Integer32 = instead of INTEGER in SMIv2 ./SNMP-FRAMEWORK-MIB:349: [5] {integer-misuse} warning: use Integer32 = instead of INTEGER in SMIv2 ./SNMP-FRAMEWORK-MIB:458: [5] {identifier-case-match} warning: = identifier `snmpEngineID' differs from `SnmpEngineID' only in case ./SNMP-FRAMEWORK-MIB:91: [6] {previous-definition} info: previous = definition of `SnmpEngineID' ./SNMP-FRAMEWORK-MIB:471: [5] {integer-misuse} warning: use Integer32 = instead of INTEGER in SMIv2 ./SNMP-FRAMEWORK-MIB:481: [5] {integer-misuse} warning: use Integer32 = instead of INTEGER in SMIv2 ./SNMP-FRAMEWORK-MIB:496: [5] {integer-misuse} warning: use Integer32 = instead of INTEGER in SMIv2 ./IANA-ENERGY-RELATION-MIB:38: [1] {object-identifier-unknown} unknown = object identifier label `energyMIB' ./IANA-ENERGY-RELATION-MIB:3: [5] {import-unused} warning: identifier = `mib-2' imported from module `SNMPv2-SMI' is never used [server:libsmi-0.4.8/mibs/ietf] tnadeau%=20 ENERGY-OBJECT-CONTEXT-MIB: [server:libsmi-0.4.8/mibs/ietf] tnadeau% smilint -l 6 -i namelength-32 = ./SNMPv2-TC ./SNMPv2-SMI ./SNMPv2-CONF ./SNMP-FRAMEWORK-MIB = ./INET-ADDRESS-MIB ./ENTITY-MIB ./UUID-TC-MIB ./IANA-ENERGY-RELATION-MIB = ./ENERGY-OBJECT-CONTEXT-MIB ./SNMPv2-SMI:1: [5] {module-already-loaded} warning: module `SNMPv2-SMI' = is already loaded, aborting parser on this file ./SNMPv2-CONF:4: [2] {import-failed} identifier `ObjectSyntax' cannot be = imported from module `SNMPv2-SMI' ./SNMP-FRAMEWORK-MIB:275: [5] {integer-misuse} warning: use Integer32 = instead of INTEGER in SMIv2 ./SNMP-FRAMEWORK-MIB:349: [5] {integer-misuse} warning: use Integer32 = instead of INTEGER in SMIv2 ./SNMP-FRAMEWORK-MIB:458: [5] {identifier-case-match} warning: = identifier `snmpEngineID' differs from `SnmpEngineID' only in case ./SNMP-FRAMEWORK-MIB:91: [6] {previous-definition} info: previous = definition of `SnmpEngineID' ./SNMP-FRAMEWORK-MIB:471: [5] {integer-misuse} warning: use Integer32 = instead of INTEGER in SMIv2 ./SNMP-FRAMEWORK-MIB:481: [5] {integer-misuse} warning: use Integer32 = instead of INTEGER in SMIv2 ./SNMP-FRAMEWORK-MIB:496: [5] {integer-misuse} warning: use Integer32 = instead of INTEGER in SMIv2 ./IANA-ENERGY-RELATION-MIB:38: [1] {object-identifier-unknown} unknown = object identifier label `energyMIB' ./IANA-ENERGY-RELATION-MIB:3: [5] {import-unused} warning: identifier = `mib-2' imported from module `SNMPv2-SMI' is never used ./ENERGY-OBJECT-CONTEXT-MIB:79: [1] {object-identifier-unknown} unknown = object identifier label `energyMIB' ./ENERGY-OBJECT-CONTEXT-MIB:6: [5] {import-unused} warning: identifier = `mib-2' imported from module `SNMPv2-SMI' is never used ./ENERGY-OBJECT-CONTEXT-MIB:9: [5] {import-unused} warning: identifier = `TruthValue' imported from module `SNMPv2-TC' is never used [server:libsmi-0.4.8/mibs/ietf] tnadeau%=20 Network Working Group J. Parello=20 Internet-Draft B. Claise=20 Intended Status: Standards Track Mouli Chandramouli=20 Expires: June 13, 2014 Cisco Systems, Inc.=20 December 13, 2013 =20= =20 =20 =20 Energy Object Context MIB =20 draft-ietf-eman-energy-aware-mib-13=20 Status of this Memo=20 This Internet-Draft is submitted to IETF in full conformance=20 with the provisions of BCP 78 and BCP 79. =20 =20 Internet-Drafts are working documents of the Internet=20 Engineering Task Force (IETF), its areas, and its working=20 groups. Note that other groups may also distribute working=20 documents as Internet-Drafts. =20 =20 Internet-Drafts are draft documents valid for a maximum of six=20= months and may be updated, replaced, or obsoleted by other=20 documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work=20= in progress." =20 =20 The list of current Internet-Drafts can be accessed at=20 http://www.ietf.org/ietf/1id-abstracts.txt =20 =20 The list of Internet-Draft Shadow Directories can be accessed at=20= http://www.ietf.org/shadow.html=20 =20 This Internet-Draft will expire on June 13, 2014. = =20 =20 Expires June 13, 2014 [Page 1]=20= =0C Internet-Draft < Energy Object Context MIB > December 2013=20= =20 Copyright Notice=20 =20 Copyright (c) 2012 IETF Trust and the persons identified as the=20= document authors. All rights reserved.=20 =20 This document is subject to BCP 78 and the IETF Trust's Legal=20 Provisions Relating to IETF Documents=20 (http://trustee.ietf.org/license-info) in effect on the date of=20= publication of this document. Please review these documents=20 carefully, as they describe your rights and restrictions with=20 respect to this document. Code Components extracted from this=20 document must include Simplified BSD License text as described=20= in Section 4.e of the Trust Legal Provisions and are provided=20 without warranty as described in the Simplified BSD License.=20 =20 =20 Abstract=20 This document defines a subset of a Management Information Base=20= (MIB) for energy management of devices. The module addresses=20 device identification, context information, and the=20 relationships between reporting devices, remote devices, and=20 monitoring devices.=20 =20 Conventions used in this document=20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",=20 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT=20 RECOMMENDED", "MAY", and "OPTIONAL" in this document are to=20 be interpreted as described in RFC 2119 [RFC2119].=20 =20 =20 =20 Table of Contents=20 =20 1. Introduction............................................... 3=20= 1.1. Energy Management Document Overview....................3=20= 2. The Internet-Standard Management Framework................. 4=20= 3. Requirements and Use Cases................................. 4=20= 4. Terminology................................................ 4=20= 5. Architecture Concepts Applied to the MIB Module............ 6=20= 5.1 Energy Object Identification............................8=20= 5.2 Energy Object Context...................................9=20= 5.3 Links to Other Identifiers.............................10=20= 5.4 Energy Object Relationships............................11=20= 5.5 Energy Object Identity Persistence.....................12=20= 6. MIB Definitions........................................... 12=20= =20 =20 Expires June 13, 2014 [Page 2]=20= =20 =0C Internet-Draft < Energy Object Context MIB > December 2013=20= =20 7. Implementation Status..................................... 27=20= 8. Security Considerations................................... 28=20= 9. IANA Considerations....................................... 29=20= 10. Acknowledgement.......................................... 29=20= 11. References............................................... 30=20= 11.1. Normative References.................................30=20= 11.2. Informative References...............................31=20= =20 =20 1. Introduction=20 The EMAN standards provide a specification for Energy=20 Management. This document defines a subset of a Management=20 Information Base (MIB) for use with network management protocols=20= for Energy monitoring of network devices and devices attached to=20= the network and possibly extending to devices in the industrial=20= automation setting with a network interface. =20 =20 The focus of the MIB module specified in this document is on the=20= identification of Energy Objects and reporting the context and=20= relationships of Energy Objects as defined in [EMAN-FMWK]. The=20= module addresses Energy Object Identification, Energy Object=20 Context, and Energy Object Relationships.=20 =20 =20 1.1. Energy Management Document Overview=20 This document specifies the Energy Object Context (ENERGY- OBJECT-CONTEXT-MIB) and IANA Energy Relationship (IANA-ENERGY- RELATION-MIB) modules. The Energy Object Context MIB module=20 specifies MIB objects for identification of Energy Objects, and=20= reporting context and relationship of an Energy Object. The IANA=20= Energy Relationship MIB module specifies the first version of=20 the IANA-maintained definitions of relationships between Energy=20= Objects.=20 =20 This document is based on the Energy Management Framework [EMAN- FMWK] and meets the requirements on identification of Energy=20 Objects and their context and relationships as specified in the=20= Energy Management requirements [RFC6988].=20 =20 A second MIB module required by the [EMAN-FMWK], the Power and=20= Energy Monitoring MIB [EMAN-MON-MIB], monitors the Energy=20 Objects for Power States, for the Power and Energy consumption.=20= Power State monitoring includes: retrieving Power States, Power=20= State properties, current Power State, Power State transitions,=20= and Power State statistics. In addition, this MIB module=20 =20 =20 Expires June 13, 2014 [Page 3]=20= =20 =0C Internet-Draft < Energy Object Context MIB > December 2013=20= =20 provides the Power Characteristics properties of the Power and=20= Energy, along with optional characteristics.=20 =20 The applicability statement document [EMAN-AS] provides the list=20= of use cases, and describes the common aspects of between=20 existing Energy standards and the EMAN standard, and shows how=20= the EMAN framework relates to other frameworks.=20 =20 =20 2. The Internet-Standard Management Framework=20 For a detailed overview of the documents that describe the=20 current Internet-Standard Management Framework, please refer to=20= section 7 of RFC 3410 [RFC3410].=20 =20 Managed objects are accessed via a virtual information store,=20 termed the Management Information Base or MIB. MIB objects are=20= generally accessed through the Simple Network Management=20 Protocol (SNMP). Objects in the MIB are defined using the=20 mechanisms defined in the Structure of Management Information=20 (SMI). This memo specifies MIB modules that are compliant with=20= SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58,=20= RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580].=20 =20 =20 3. Requirements and Use Cases=20 Firstly, to illustrate the importance of energy monitoring in=20 networks and secondly to list some of the important areas to be=20= addressed by the Energy Management Framework, several use cases=20= and network scenarios are presented in the EMAN applicability=20 statement document [EMAN-AS]. In addition, for each scenario,=20 the target devices for energy management, and how those devices=20= powered and metered are also presented. To address the network=20= scenarios, requirements for power and energy monitoring for=20 networking devices are specified in [RFC6988]. Based on the=20 requirements [RFC6988], the [EMAN-FMWK] presents a solution=20 approach. =20 =20 Accordingly, the scope of the MIB modules in this document is in=20= accordance to the requirements specified in [RFC6988] and the=20 concepts from [EMAN-FMWK]. =20 =20 =20 4. Terminology=20 =20 =20 =20 Expires June 13, 2014 [Page 4]=20= =20 =0C Internet-Draft < Energy Object Context MIB > December 2013=20= =20 Please refer to [EMAN-FMWK] for the definitions of the following=20= terminology used in this draft:=20 =20 Energy Management =20 =20 Energy Management System (EnMS) =20 TOM: This is not a great acronym as Element Management System (EMS) is = commonly used. =20 Energy Monitoring =20 =20 Energy Control =20 =20 electrical equipment =20 =20 non-electrical equipment (mechanical equipment) =20 =20 device =20 =20 component =20 =20 power inlet =20 =20 power outlet =20 =20 energy =20 =20 power =20 =20 demand =20 =20 provide energy =20 =20 receive energy =20 =20 meter (energy meter) =20 =20 battery =20 =20 Power Interface =20 =20 Nameplate Power =20 =20 Power Attributes =20 =20 Power Quality =20 =20 Power State =20 =20 Power State Set =20 =20 =20 Expires June 13, 2014 [Page 5]=20= =20 =0C Internet-Draft < Energy Object Context MIB > December 2013=20= =20 =20 =20 5. Architecture Concepts Applied to the MIB Module=20 This section describes the basic concepts specified in the=20 Energy Management Architecture [EMAN-FMWK], with specific=20 information related to the MIB modules specified in this=20 document.=20 =20 The Energy Object Context (ENERGY-OBJECT-CONTEXT-MIB) MIB module=20= in this document specifies MIB objects for identification of=20 Energy Objects, and reporting context and relationship of an=20 Energy Object. The managed objects are contained in two tables=20= eoTable and eoRelationTable.=20 =20 The first table eoTable focuses on link to the other MIB=20 modules, context of the Energy Object. The second table=20 eoRelationTable specifies the relationships between Energy=20 Objects. This is a simplified representation of relationship=20 between Energy Objects. =20 =20 +- eoTable(2)=20 |=20 +- eoEntry(1) [entPhysicalIndex]=20 | | =20 | +-- r-n PethPsePortIndexOrZero eoEthPortIndex(1)=20 | +-- r-n PethPsePortGroupIndexOrZero eoEthPortGrpIndex(2)=20= | +-- r-n LldpPortNumberOrZero eoLldpPortNumber(3)=20= | +-- rwn MacAddress eoMgmtMacAddress(4)=20= | +-- r-n InetAddressType eoMgmtAddressType(5)=20= | +-- r-n InetAddress eoMgmtAddress(6)=20 | +-- r-n SnmpAdminString eoMgmtDNSName(7)=20 | +-- rwn SnmpAdminString eoDomainName(8)=20 | +-- rwn SnmpAdminString eoRoleDescription(9)=20= | +-- rwn EnergyObjectKeywordList eoKeywords(10)=20 | +-- rwn Integer32 eoImportance(11)=20 | +-- r-n INTEGER eoPowerCategory(12)=20= | +-- rwn SnmpAdminString eoAlternateKey(13)=20 | +-- r-n INTEGER eoPowerInterfaceType(14)=20= TOM: I am having a hard time understanding what the XXX field before the = object types means here. I guess I understand the r =3D=3D read and w =3D=3D= write but what is "n"? I'd suggest just removing this column = altogether. Whether or not the objec tis read/write/whatever doesn't = seem important; what you want to get across here is the overall = structure/tree of things. | +- eoRelationTable(2)=20 | | =20 | +- eoRelationEntry(1) [entPhysicalIndex,=20 eoRelationIndex]=20 | | |=20 | | +-- --n Integer32 eoRelationIndex(1) =20= | | +-- --n UUIDorZero eoRelationID(2)=20 =20 =20 Expires June 13, 2014 [Page 6]=20= =20 =0C Internet-Draft < Energy Object Context MIB > December 2013=20= =20 | | +-- rwn IANAEnergyRelationship =20 eoRelationship(3)=20 =20 The following UML diagram illustrates the relationship of the=20 MIB objects in the eoTable, eoRelationTable that describe the=20 identity, context and relationship of an Energy Object. =20 =20 =20 +--------------------------+=20 | EO Context Information |=20 | ------------------------ | =20 | eoRoleDescription |=20 | eoKeywords | =20 | eoImportance |=20 | eoPowerCategory |=20 | eoPowerInterfaceType | =20 +--------------------------+ =20 | =20 | =20 v =20 +-----------------------------+ =20 |---> | EO Identification |=20 | |_---------------------------- |=20 TOM: Is the ^^^ a typo? | | entPhysicalIndex (*) |=20 | | entPhysicalName (*) |=20 | | entPhysicalUUID (*) |=20 | | |=20 | | eoEthPortIndex (**) |=20 | | eoEthPortGrpIndex (**) |=20 | | eoLldpPortNumber (***) |=20 | | eoAlternateKey |=20 | | |=20 | | eoMgmtMacAddress (optional) |=20 | | eoMgmtAddressType (optional) |=20 | | eoMgmtAddress (optional) |=20 | | eoMgmtDNSName (optional) |=20 | | eoDomainName |=20 | +------------------------------+ =20 | =20 | +------------------------------+=20 |---- | EO Relationship |=20 | | ---------------------------- | =20 | | eoRelationIndex |=20 | | eoRelationID | =20 | | IANAEnergyRelationship |=20 | +------------------------------+ =20 =20 =20 =20 =20 Expires June 13, 2014 [Page 7]=20= =20 =0C Internet-Draft < Energy Object Context MIB > December 2013=20= =20 =20 =20 (*) Compliance with the ENTITY MIB V4 [RFC6933]=20 (**) Link with the Power over Ethernet MIB [RFC3621]=20 (***) Link with LLDP MIBs [LLDP-MIB] [LLDP-MED-MIB]=20 =20 =20 Figure 1: MIB Objects Grouping=20 =20 =20 As displayed in figure 1, the MIB objects can be classified in=20= different logical grouping of MIB objects. =20 TOM: grouping -> groupings =20 1) The Energy Object Identification. See Section 5.1 "Energy=20 Object Identification". Devices and their sub-components are=20= characterized by the power-related attributes of a physical=20 entity present in the ENTITY MIB [RFC6933].=20 2) The Context Information. See Section 5.2 "Energy Object=20 Context"=20 3) The links to other MIB modules. See Section 5.3 "Links to=20 other Identifiers" =20 4) The Energy Object Relationships specific information. See=20 Section 5.4=20 5) The Energy Object Identity Persistence. See Section 5.5=20 "Energy Object Identity Persistence"=20 =20 =20 5.1 Energy Object Identification =20 Refer to the "Energy Object Information" section in [EMAN-FMWK]=20= for background information about Energy Objects. =20 =20 Every Energy Object MUST implement the unique index,=20 entPhysicalIndex, entPhysicalName and entPhysicalUUID from the=20= ENTITY MIB [RFC6933]. Module Compliance with respect to=20 entity4CRCompliance of ENTITY-MIB should be supported which=20 require a limited number of objects supported (entPhysicalClass,=20= entPhysicalName, entPhysicalUUID). entPhysicalIndex is used as=20= index for the primary Energy Object information in the ENERGY- OBJECT-CONTEXT-MIB module.=20 =20 Every Energy Object MUST have a printable name assigned to it.=20= TOM: Can you be more specific with "printable"? Do you mean ASCII = etc...?=20 Energy Objects MUST implement the entPhysicalName object=20 specified in the ENTITY-MIB [RFC6933], which must contain the=20 Energy Object name. =20 =20 =20 Expires June 13, 2014 [Page 8]=20= =20 =0C Internet-Draft < Energy Object Context MIB > December 2013=20= =20 For the ENERGY-OBJECT-CONTEXT-MIB compliance, every Energy=20 Object instance MUST implement the entPhysicalUUID from the=20 ENTITY MIB [RFC6933]. =20 As displayed in [RFC4122], the following is an example of the=20 string representation of a UUID as a URN: urn:uuid:f81d4fae- 7dec-11d0-a765-00a0c91e6bf6. =20 For example, to understand the relationship between Energy=20 Object Components and Energy Objects, the ENTITY-MIB physical=20 containment tree [RFC6933] MUST be implemented.=20 =20 A second example deals with one of the ENTITY-MIB extensions: if=20= the Energy Object temperature is required, the managed objects=20= from the ENTITY-SENSOR-MIB [RFC3433] should be supported.=20 =20 Each Energy Object MUST belong to a single Energy Management=20 Domain or in other words, an Energy Object cannot belong to more=20= than one Energy Management Domain. Refer to the "Energy=20 Management Domain" section in [EMAN-FMWK] for background=20 TOM: At present the EMAN-FMWK states that it SHOULD belong to a single = domain; this is inconsistent. information. The eoDomainName, which is an element of the=20 eoTable, is a read-write MIB object. The Energy Management=20 Domain should map 1-1 with a metered or sub-metered portion of=20= TOM: The framework uses "1:1"; perhaps you should use that too? the network. The Energy Management Domain MUST be configured on=20= the Energy Object. The Energy Object MAY inherit the some of the=20= domain parameters (possibly domain name, some of the context=20 information such as role or keywords, importance) from the=20 Energy Object or the Energy Management Domain MAY be configured=20= directly in an Energy Object. =20 =20 When an Energy Object acts as a Power Aggregator, the Energy=20 Objects for which Power should be aggregated MUST be members of=20= the same Energy Management Domain, specified by the eoDomainName=20= MIB Object. =20 TOM: Again, the MUST is inconsistent with the Framework at the present = time. =20 5.2 Energy Object Context=20 Refer to the "Energy Object Context" section in [EMAN-FMWK] for=20= background information.=20 =20 An Energy Object must provide a value for eoImportance in the=20 range of 1...100 to help differentiate the use or relative value=20= of the device. The importance range is from 1 (least important)=20= to 100 (most important). The default importance value is 1. =20 =20 =20 =20 Expires June 13, 2014 [Page 9]=20= =20 =0C Internet-Draft < Energy Object Context MIB > December 2013=20= =20 An Energy Object can provide a set of eoKeywords. These keywords=20= are a list of tags that can be used for grouping and summary=20 reporting within or between Energy Management Domains.=20 =20 An Energy Object can have Power Interfaces and those interfaces=20= can be classified as Power Inlet, Power Outlet or both. =20 =20 An Energy Object can be classified based on the physical=20 properties of the Energy Object. That Energy Object can be=20 classified as consuming power or supplying power to other=20 devices or that Energy Object can perform both of those=20 functions and finally, an Energy Object can be a passive meter. = =20 =20 Additionally, an Energy Object can provide an eoRoleDescription=20= string that indicates the purpose the Energy Object serves in=20 the network.=20 =20 =20 5.3 Links to Other Identifiers =20 While the entPhysicalIndex is the primary index for all MIB=20 objects in the ENERGY-OBJECT-CONTEXT-MIB module, the Energy=20 Management Systems (EnMS) must be able to make the link with the=20= TOM: Do you really mean (all caps) MUST here? identifier(s) in other supported MIB modules.=20 =20 If the Energy Object is a Power over Ethernet (PoE) port, and if=20= the Power over Ethernet MIB [RFC3621] is supported by the Energy=20= Object SNMP agent, then the Energy Object eoethPortIndex and=20 eoethPortGrpIndex MUST contain the values of pethPsePortIndex=20 and pethPsePortGroupIndex [RFC3621]. =20 =20 The Energy Object eoLldpPortNumber MUST contain the=20 lldpLocPortNum from the LLDP MIB [LLDP-MIB], if the LLDP-MED =20 MIB is supported on the Energy Object SNMP agent.=20 =20 The intent behind the links to the other MIB module=20 identifier(s) is to correlate the instances in the different MIB=20= modules. This will allow the ENERGY-OBJECT-CONTEXT-MIB module to=20= reference other MIB modules in cases where the Power over=20 Ethernet and the LLDP MIB modules are supported by the SNMP=20 agent. Some use cases may not implement any of these two MIB=20 TOM: I think you mean something like, "...may not implement either of = these MIB ..." modules for the Energy Objects. However, in situation where any=20= of these two MIB modules are implemented, the EnMS must be able=20= to correlate the instances in the different MIB modules.=20 =20 The eoAlternateKey alternate key object specifies a manufacturer=20= defined string that can be used to identify the Energy Object. =20= Since an EnMS may need to correlate objects across management=20 =20 =20 Expires June 13, 2014 [Page 10]=20= =20 =0C Internet-Draft < Energy Object Context MIB > December 2013=20= =20 systems, this alternate key is provided to facilitate such a=20 link. This optional value is intended as a foreign key or=20 alternate identifier for a manufacturer or EnMS to use to=20 correlate the unique Energy Object Id in other systems or=20 namespaces. If an alternate key is not available or is not=20 applicable then the value is the zero-length string.=20 TOM: Do you want to use MUST here to indicate that it MUST be the = zero-length string?=20 =20 =20 5.4 Energy Object Relationships=20 Refer to the "Energy Object Relationships" section in [EMAN- FMWK] for the definition and background information.=20 In order to link two Energy Objects a separate table=20 (eoRelationTable) has been introduced in this MIB module. The=20 following relationships between Energy objects have been=20 considered in the eoRelationTable. =20 =20 =20 Metering Relationship -> meteredBy/metering=20 =20 =20 Power Source Relationship -> poweredBy/powering=20 =20 =20 Aggregation Relationship -> aggregatedBy/aggregating =20 =20 Each Energy object can have one or more Energy Object=20 relationships with other Energy Objects. The relations between=20= Energy Objects are specified in eoRelationTable. The=20 relationship between the Energy Objects is specified with an=20 arbitrary index and the UUID of the remote Energy Object. The=20 UUID MUST comply to the RFC 4122 specifications. It is=20 important to note that it is possible that an Energy Object may=20= TOM: may -> might not have an Energy Object relationship with other Energy=20 Objects. =20 =20 The IANA Energy Relationship MIB module specifies the first=20 version of the IANA-maintained definitions of relationships=20 between Energy Objects, as textual conventions. This way, for=20 Energy Relationships, new textual conventions can be specified,=20= without updating the primary Energy Object Context MIB module.=20= =20 Since the communication between the Energy Objects may not be=20 SNMP and is left to the choice of the device manufacturer, an=20 Energy Object can have additional MIB objects that can be used=20= for easier identification by the EnMS. The optional objects=20 eoMgmtMacAddress, eoMgmtAddressType eoMgmtDNSName can be used to=20= help identify the relationship between the Energy Objects and=20 other NMS objects. These objects can be used as an alternate=20 =20 =20 Expires June 13, 2014 [Page 11]=20= =20 =0C Internet-Draft < Energy Object Context MIB > December 2013=20= =20 key to help link the Energy Object with other keyed information=20= that may be stored within the EnMS(s). For the optional objects=20= that may not be included in some vendor implementations, the=20 expected behavior when those objects are polled is a response=20 noSuchInstance.=20 =20 =20 5.5 Energy Object Identity Persistence=20 In some situations, the Energy Object identity information=20 should be persistent even after a device reload. For example, in=20= a static setup where a switch monitors a series of connected PoE=20= phones, there is a clear benefit for the EnMS if the Energy=20 Object Identification and all associated information persist, as=20= it saves a network discovery. However, in other situations,=20 such as a wireless access point monitoring the mobile user PCs,=20= there is not much advantage to persist the Energy Object=20 Information. The identity information of an Energy Object=20 should be persisted and there is value in the writable MIB=20 objects persisted.=20 =20 =20 6. MIB Definitions=20 =20 -- ************************************************************=20= -- =20 -- =20 -- This MIB is used for describing the identity and the =20 -- context information of Energy Objects in network =20 TOM: "in network" -> "in a network" ? -- =20 -- =20 -- *************************************************************=20= =20 =20 ENERGY-OBJECT-CONTEXT-MIB DEFINITIONS ::=3D BEGIN=20 =20 IMPORTS=20 MODULE-IDENTITY,=20 OBJECT-TYPE,=20 mib-2,=20 Integer32=20 FROM SNMPv2-SMI =20 TEXTUAL-CONVENTION, MacAddress, TruthValue=20 FROM SNMPv2-TC=20 MODULE-COMPLIANCE,=20 OBJECT-GROUP=20 =20 =20 Expires June 13, 2014 [Page 12]=20= =20 =0C Internet-Draft < Energy Object Context MIB > December 2013=20= =20 FROM SNMPv2-CONF=20 SnmpAdminString=20 FROM SNMP-FRAMEWORK-MIB =20 InetAddressType, InetAddress=20 FROM INET-ADDRESS-MIB =20 entPhysicalIndex=20 FROM ENTITY-MIB =20 TOM: I generally like to include a comment after each MIB stating which = RFC it comes from. It is a good habit since not all MIB modules are = easily found for compilation. UUIDorZero=20 FROM UUID-TC-MIB =20 TOM: You should include a reference to RFC6933 here IANAEnergyRelationship=20 FROM IANA-ENERGY-RELATION-MIB; =20 =20 energyObjectContextMIB MODULE-IDENTITY=20 LAST-UPDATED "201312130000Z"=20 =20 ORGANIZATION "IETF EMAN Working Group"=20 CONTACT-INFO=20 "WG Charter:=20 http://datatracker.ietf.org/wg/eman/charter/=20 =20 Mailing Lists:=20 General Discussion: eman@ietf.org=20 To Subscribe: https://www.ietf.org/mailman/listinfo/eman=20= Archive: http://www.ietf.org/mail-archive/web/eman=20 Editors: =20 John Parello =20 Cisco Systems, Inc. =20 3550 Cisco Way =20 San Jose, California 95134 =20 US =20 Phone: +1 408 525 2339 =20 Email: jparello@cisco.com =20 =20 =20 Benoit Claise=20 Cisco Systems, Inc.=20 De Kleetlaan 6a b1=20 Degem 1831=20 Belgium=20 Phone: +32 2 704 5622=20 Email: bclaise@cisco.com=20 =20 =20 Mouli Chandramouli=20 =20 =20 Expires June 13, 2014 [Page 13]=20= =20 =0C Internet-Draft < Energy Object Context MIB > December 2013=20= =20 Cisco Systems, Inc.=20 Sarjapur Outer Ring Road=20 Bangalore 560103=20 IN=20 Phone: +91 80 4429 2409=20 Email: moulchan@cisco.com"=20 =20 =20 DESCRIPTION=20 "This MIB is used for describing the identity and the =20 context information of Energy Objects"=20 REVISION=20 "201312130000Z"=20 DESCRIPTION=20 "Initial version, published as RFC YYY."=20 =20 =20 ::=3D { energyMIB 1 } =20 TOM: I believe that the WG (and MIB doctors) decided to root these MIBs = under transmission, as usual. Please replace this with a note to the RFC = editor and IANA asking for such an assignment. =20 energyObjectContextMIBNotifs OBJECT IDENTIFIER=20 ::=3D { energyObjectContextMIB 0 }=20 =20 energyObjectContextMIBObjects OBJECT IDENTIFIER=20 ::=3D { energyObjectContextMIB 1 }=20 =20 energyObjectContextMIBConform OBJECT IDENTIFIER=20 ::=3D { energyObjectContextMIB 2 }=20 =20 =20 -- Textual Conventions=20 TOM: The naming of all of these objects is unusual. The "PethPse" prefix = in particular. Typically MIB variables and tables are somehow related to = the module/table they are contained in. It would be burdensome to = rename every thing in the module at this point, so I would be happy if = you simply defined what these prefixes meant for the uninitiated reader. = =20 =20 PethPsePortIndexOrZero ::=3D TEXTUAL-CONVENTION=20 DISPLAY-HINT "d"=20 STATUS current=20 DESCRIPTION=20 "This textual convention is an extension of the=20 pethPsePortIndex convention, which defines a greater than=20= zero value used to identify a power Ethernet PSE port. =20= This extension permits the additional value of zero. The=20= semantics of the value zero are object-specific and must,=20= therefore, be defined as part of the description of any=20= object that uses this syntax. Examples of the usage of=20= this extension are situations where none or all physical=20= entities need to be referenced."=20 SYNTAX Integer32 (0..2147483647)=20 =20 =20 Expires June 13, 2014 [Page 14]=20= =20 =0C Internet-Draft < Energy Object Context MIB > December 2013=20= =20 =20 PethPsePortGroupIndexOrZero ::=3D TEXTUAL-CONVENTION=20 DISPLAY-HINT "d"=20 STATUS current=20 DESCRIPTION=20 "This textual convention is an extension of the=20 pethPsePortGroupIndex convention from the Power Over=20 Ethernet MIB [RFC3621], which defines a greater than zero=20= value used to identify group containing the port to which=20= a power Ethernet PSE is connected. This extension=20 permits the additional value of zero. The semantics of=20= the value zero are object-specific and must, therefore,=20= be defined as part of the description of any object that=20= uses this syntax. Examples of the usage of this=20 extension are situations where none or all physical=20 entities need to be referenced."=20 SYNTAX Integer32 (0..2147483647)=20 =20 LldpPortNumberOrZero ::=3D TEXTUAL-CONVENTION =20 DISPLAY-HINT "d" =20 STATUS current =20 DESCRIPTION =20 "This textual convention is an extension of the=20 LldpPortNumber convention specified in the LLDP MIB,=20 which defines a greater than zero value used to uniquely=20= identify each port contained in the chassis (that is=20 known to the LLDP agent) by a port number. This=20 extension permits the additional value of zero. The=20 semantics of the value zero are object-specific and must,=20= therefore, be defined as part of the description of any=20= object that uses this syntax. Examples of the usage of=20= this extension are situations where none or all physical=20= entities need to be referenced."=20 SYNTAX Integer32(0..4096)=20 =20 EnergyObjectKeywordList ::=3D TEXTUAL-CONVENTION=20 STATUS current=20 DESCRIPTION=20 "A list of keywords that can be used to group Energy=20 Objects for reporting or searching. If multiple keywords=20= are present, then this string will contain all the=20 keywords separated by the ',' character. All alphanumeric=20= =20 =20 Expires June 13, 2014 [Page 15]=20= =20 =0C Internet-Draft < Energy Object Context MIB > December 2013=20= =20 characters and symbols (other than a comma), such as #,=20= (, $, !, and &, are allowed. White spaces before and=20 after the commas are ignored, as well as within a keyword=20= itself. =20 =20 For example, if an Energy Object were to be tagged with=20= the keyword values 'hospitality' and 'guest', then the=20 keyword list will be 'hospitality,guest'."=20 SYNTAX OCTET STRING (SIZE (0..2048))=20 =20 -- Objects=20 =20 eoTable OBJECT-TYPE=20 SYNTAX SEQUENCE OF EoEntry =20 MAX-ACCESS not-accessible=20 STATUS current=20 DESCRIPTION=20 "This table lists Energy Objects."=20 ::=3D { energyObjectContextMIBObjects 1 }=20 =20 eoEntry OBJECT-TYPE=20 SYNTAX EoEntry=20 MAX-ACCESS not-accessible=20 STATUS current=20 DESCRIPTION=20 "An entry describes the attributes of an Energy Object. =20= Whenever a new Energy Object is added or an existing=20 Energy Object is deleted, a row in the eoTable is added=20= or deleted."=20 =20 INDEX {entPhysicalIndex }=20 ::=3D { eoTable 1 }=20 =20 EoEntry ::=3D SEQUENCE {=20 eoEthPortIndex PethPsePortIndexOrZero,=20 eoEthPortGrpIndex PethPsePortGroupIndexOrZero,=20= eoLldpPortNumber LldpPortNumberOrZero,=20 eoMgmtMacAddress MacAddress,=20 eoMgmtAddressType InetAddressType,=20 eoMgmtAddress InetAddress,=20 eoMgmtDNSName SnmpAdminString,=20 eoDomainName SnmpAdminString,=20 eoRoleDescription SnmpAdminString,=20 eoKeywords EnergyObjectKeywordList,=20 eoImportance Integer32,=20 eoPowerCategory INTEGER,=20 #TOM: You should not use INTEGER; use Integer32 instead. =20 Expires June 13, 2014 [Page 16]=20= =20 =0C Internet-Draft < Energy Object Context MIB > December 2013=20= =20 eoAlternateKey SnmpAdminString, =20 eoPowerInterfaceType INTEGER=20 #TOM: You should not use INTEGER; use Integer32 instead. } =20 =20 eoEthPortIndex OBJECT-TYPE =20 SYNTAX PethPsePortIndexOrZero=20 MAX-ACCESS read-only=20 STATUS current=20 DESCRIPTION =20 "This variable uniquely identifies the power Ethernet=20 port to which the attached device is connected [RFC3621].=20= In addition, PoE MIB should be instantiated on the=20 device. If such a power Ethernet port cannot be specified=20= or is not known then the object is zero."=20 ::=3D { eoEntry 1 }=20 TOM: Should this have a DEFVAL of 0? =20 eoEthPortGrpIndex OBJECT-TYPE =20 SYNTAX PethPsePortGroupIndexOrZero=20 MAX-ACCESS read-only=20 STATUS current=20 DESCRIPTION=20 "This variable uniquely identifies the group containing=20= the port to which a power Ethernet PSE is connected=20 [RFC3621]. In addition, PoE MIB should be instantiated on=20= the device. If such a group cannot be specified or is not=20= known then the object is zero."=20 ::=3D { eoEntry 2 }=20 =20 eoLldpPortNumber OBJECT-TYPE =20 SYNTAX LldpPortNumberOrZero=20 MAX-ACCESS read-only=20 STATUS current=20 DESCRIPTION=20 "This variable uniquely identifies the port component=20 (contained in the local chassis with the LLDP agent) as=20 defined by the lldpLocPortNum in the [LLDP-MIB] and=20 [LLDP-MED-MIB]. In addition, LLDP MIB should be=20 TOM: These references should not be used inline. Remember that once the = MIB is stripped out of this draft, those references have no meaning. = Please either add a Reference clause below, or use an RFC/IEEE number = that can easily be found. Please go through every place where there is = a reference in a DESCRIPTION clause and make this correction as I will = not comment on each and every one. instantiated on the device If such a port number cannot=20 be specified or is not known then the object is zero."=20 ::=3D { eoEntry 3 }=20 =20 eoMgmtMacAddress OBJECT-TYPE=20 SYNTAX MacAddress =20 MAX-ACCESS read-only=20 STATUS current=20 DESCRIPTION=20 "This object specifies a MAC address of the Energy=20 Object." =20 =20 =20 Expires June 13, 2014 [Page 17]=20= =20 =0C Internet-Draft < Energy Object Context MIB > December 2013=20= =20 ::=3D { eoEntry 4 }=20 =20 eoMgmtAddressType OBJECT-TYPE=20 SYNTAX InetAddressType=20 MAX-ACCESS read-only=20 STATUS current=20 DESCRIPTION=20 "This object specifies the eoMgmtAddress type, i.e. an=20 IPv4 address or an IPv6 address. This object MUST be=20 populated when eoMgmtAddress is populated." =20 ::=3D { eoEntry 5 }=20 =20 eoMgmtAddress OBJECT-TYPE=20 SYNTAX InetAddress=20 MAX-ACCESS read-only=20 STATUS current=20 DESCRIPTION=20 "This object specifies the management address as an IPv4=20= address or IPv6 address of Energy Object. The IP address=20= type, i.e. IPv4 or IPv6, is determined by the=20 eoMgmtAddressType value. This object can be used as an=20 alternate key to help link the Energy Object with other=20 keyed information that may be stored within the EnMS(s)." =20= ::=3D { eoEntry 6 }=20 =20 eoMgmtDNSName OBJECT-TYPE=20 SYNTAX SnmpAdminString=20 MAX-ACCESS read-only=20 STATUS current=20 DESCRIPTION=20 "This object specifies the DNS name of the eoMgmtAddress.=20= This object can be used as an alternate key to help link=20= the Energy Object with other keyed information that may=20= be stored within the EnMS(s)."=20 ::=3D { eoEntry 7 }=20 TOM: Is there anything you want to say about any (suggested) format for = this string? =20 eoDomainName OBJECT-TYPE=20 SYNTAX SnmpAdminString=20 MAX-ACCESS read-write=20 STATUS current=20 DESCRIPTION=20 "This object specifies the name of an Energy Management=20= Domain for the Energy Object. This object specifies a=20 zero-length string value if no Energy Management Domain=20= name is configured. The value of eoDomainName must remain=20= constant at least from one re-initialization of the=20 entity local management system to the next re- initialization." =20 =20 =20 Expires June 13, 2014 [Page 18]=20= =20 =0C Internet-Draft < Energy Object Context MIB > December 2013=20= =20 ::=3D { eoEntry 8 }=20 TOM: Should this be an empty string by default so that it is set into a = known state? =20 eoRoleDescription OBJECT-TYPE=20 SYNTAX SnmpAdminString=20 MAX-ACCESS read-write=20 STATUS current=20 DESCRIPTION=20 "This object specifies an administratively assigned name=20= to indicate the purpose an Energy Object serves in the=20 network.=20 =20 For example, we can have a phone deployed to a lobby with=20= eoRoleDescription as 'Lobby phone'.=20 =20 This object specifies the value is the zero-length string=20= TOM: specifies THAT the value... value if no role description is configured.=20 The value of eoRoleDescription must remain constant at=20 least from one re-initialization of the entity local =20 management system to the next re-initialization. " =20 ::=3D { eoEntry 9 } =20 =20 eoKeywords OBJECT-TYPE=20 SYNTAX EnergyObjectKeywordList=20 MAX-ACCESS read-write=20 STATUS current=20 DESCRIPTION=20 "This object specifies a list of keywords that can be=20 used to group Energy Objects for reporting or searching. =20= The value is the zero-length string if no keywords have=20= been configured. If multiple keywords are present, then=20= this string will contain all the keywords separated by=20 the ',' character. For example, if an Energy Object were=20= to be tagged with the keyword values 'hospitality' and=20 'guest', then the keyword list will be=20 'hospitality,guest'. =20 =20 If write access is implemented and a value is written=20 into the instance, the agent must retain the supplied=20 value in the eoKeywords instance associated with=20 the same physical entity for as long as that entity=20 remains instantiated. This includes instantiations=20 across all re-initializations/reboots of the local=20 management agent. " =20 ::=3D { eoEntry 10 }=20 =20 eoImportance OBJECT-TYPE=20 SYNTAX Integer32 (1..100)=20 MAX-ACCESS read-write=20 =20 =20 Expires June 13, 2014 [Page 19]=20= =20 =0C Internet-Draft < Energy Object Context MIB > December 2013=20= =20 STATUS current=20 DESCRIPTION =20 "This object specifies a ranking of how important the=20 Energy Object is (on a scale of 1 to 100) compared with=20= other Energy Objects in the same Energy Management=20 Domain. The ranking should provide a business or=20 operational context for the Energy Object as compared to=20= other similar Energy Objects. This ranking could be used=20= as input for policy-based network management. =20 =20 =20 Although network managers must establish their own=20 ranking, the following is a broad recommendation:=20 =20 90 to 100 Emergency response =20 80 to 90 Executive or business critical =20 70 to 79 General or Average =20 60 to 69 Staff or support =20 40 to 59 Public or guest =20 1 to 39 Decorative or hospitality=20 =20 The value of eoImportance must remain constant at least=20= from one re-initialization of the entity local =20 management system to the next re-initialization. "=20 DEFVAL { 1 } =20 ::=3D { eoEntry 11 }=20 =20 eoPowerCategory OBJECT-TYPE=20 SYNTAX INTEGER {=20 #TOM: You should not use INTEGER; use Integer32 instead. consumer(0),=20 producer(1), =20 meter(2),=20 distributor(3),=20 store(4)=20 }=20 MAX-ACCESS read-only=20 STATUS current=20 DESCRIPTION=20 "This object describes the Energy Object category, which=20= indicates the expected behavior or physical property of=20= the Energy Object, based on its design. An Energy Object=20= can be a consumer(0), producer(1), meter(2),=20 distributor(3) or store(4). =20 =20 In some cases, a meter is required to measure the power=20= consumption. In such a case, this meter Energy Object=20 category is meter(2). If a device is functioning as a=20 distributor of Energy that category of the Energy Object=20= =20 =20 Expires June 13, 2014 [Page 20]=20= =20 =0C Internet-Draft < Energy Object Context MIB > December 2013=20= =20 is distributor (3). If a device is a store of electric=20 Energy the category of the device can be store (4). " =20 ::=3D { eoEntry 12 }=20 TOM: These definitions are a bit recursive. Is there perhaps a better = reference (i.e.: the framework or somethign) that better = defines/describes these? =20 eoAlternateKey OBJECT-TYPE=20 SYNTAX SnmpAdminString=20 MAX-ACCESS read-write =20 STATUS current=20 DESCRIPTION=20 "This object specifies a manufacturer defined string that=20= can be used to identify the Energy Object. Since Energy=20= Management Systems (EnMS) and Network Management Systems=20= (NMS) may need to correlate objects across management=20 systems, this alternate key is provided to provide such a=20= link. This optional value is intended as a foreign key or=20= alternate identifier for a manufacturer or EnMS/NMS to=20 use to correlate the unique Energy Object Id in other=20 systems or namespaces. If an alternate key is not=20 available or is not applicable then the value is the=20 zero-length string. =20 The value of eoAlternateKey must remain constant at =20 least from one re-initialization of the entity local =20 management system to the next re-initialization. " =20 ::=3D { eoEntry 13 }=20 =20 eoPowerInterfaceType OBJECT-TYPE=20 SYNTAX INTEGER {=20 #TOM: You should not use INTEGER; use Integer32 instead. inlet(0),=20 outlet(1), =20 both(2) =20 }=20 MAX-ACCESS read-only=20 STATUS current=20 DESCRIPTION=20 "This object describes the Power Interface for an Energy=20= Object. A Power Interface is an interface at which a=20 Energy Object is connected to a power transmission=20 medium, at which it can in turn receive power, provide=20 power, or both. A Power Interface type can be an inlet(0)=20= or outlet(1) or both(2), respectively." =20 TOM: Not sure "respectively" adds anything to the last sentence. Also, = are these states defined in the framework and if so, should there be a = reference? ::=3D { eoEntry 14 }=20 =20 eoRelationTable OBJECT-TYPE=20 SYNTAX SEQUENCE OF EoRelationEntry =20 MAX-ACCESS not-accessible=20 STATUS current=20 DESCRIPTION=20 =20 =20 Expires June 13, 2014 [Page 21]=20= =20 =0C Internet-Draft < Energy Object Context MIB > December 2013=20= =20 "This table describes the relationships between Energy=20 Objects."=20 TOM: This is a rather terse definition of the table. Can you add = anything else here? ::=3D { energyObjectContextMIBObjects 2 }=20 =20 =20 eoRelationEntry OBJECT-TYPE=20 SYNTAX EoRelationEntry=20 MAX-ACCESS not-accessible=20 STATUS current=20 DESCRIPTION=20 "An entry in this table describes the relationship=20 between Energy objects."=20 INDEX { entPhysicalIndex, eoRelationIndex }=20 ::=3D { eoRelationTable 1 }=20 =20 =20 EoRelationEntry ::=3D SEQUENCE {=20 eoRelationIndex Integer32,=20 eoRelationID UUIDorZero,=20 eoRelationship IANAEnergyRelationship = =20 }=20 =20 eoRelationIndex OBJECT-TYPE=20 SYNTAX Integer32 (0..2147483647) =20 MAX-ACCESS not-accessible=20 STATUS current=20 DESCRIPTION=20 "This object is an arbitrary index to identify the Energy=20= Object related to another Energy Object" =20 ::=3D { eoRelationEntry 1 }=20 =20 eoRelationID OBJECT-TYPE=20 SYNTAX UUIDorZero=20 MAX-ACCESS read-only=20 STATUS current=20 DESCRIPTION=20 "This object specifies the Universally Unique Identifier=20= (UUID) of the peer (other) Energy Object. The UUID must=20 comply the specifications of UUID in UUID-TC-MIB. =20 =20 If UUID of the energy object is unknown or non-existent, =20= the eoRelationID will be set to a zero-length string =20 instead."=20 =20 REFERENCE=20 "RFC 6933, Entity MIB - version 4, May 2013 "=20 ::=3D { eoRelationEntry 2 }=20 =20 =20 Expires June 13, 2014 [Page 22]=20= =20 =0C Internet-Draft < Energy Object Context MIB > December 2013=20= =20 =20 eoRelationship OBJECT-TYPE=20 SYNTAX IANAEnergyRelationship=20 MAX-ACCESS read-write =20 STATUS current=20 DESCRIPTION=20 "This object describes the relations between Energy=20 objects. For each Energy object, the relations between=20 the other Energy objects are specified using the bitmap." =20= ::=3D { eoRelationEntry 3 }=20 =20 -- Conformance=20 =20 energyObjectContextMIBCompliances OBJECT IDENTIFIER=20 ::=3D { energyObjectContextMIBConform 1 }=20 =20 energyObjectContextMIBGroups OBJECT IDENTIFIER=20 ::=3D { energyObjectContextMIBConform 2 }=20 =20 energyObjectContextMIBFullCompliance MODULE-COMPLIANCE=20 STATUS current=20 DESCRIPTION=20 "When this MIB is implemented with support for=20 read-write, then such an implementation can =20 claim full compliance. Such devices can then =20 be both monitored and configured with this MIB."=20 MODULE -- this module=20 MANDATORY-GROUPS {=20 energyObjectContextMIBTableGroup, =20 energyObjectRelationTableGroup =20 }=20 =20 GROUP energyObjectOptionalMIBTableGroup=20 DESCRIPTION=20 "A compliant implementation does not have to =20 implement. Module Compliance of ENTITY-MIB =20 with respect to entity4CRCompliance should =20 be supported. "=20 ::=3D { energyObjectContextMIBCompliances 1 }=20 =20 =20 energyObjectContextMIBReadOnlyCompliance MODULE-COMPLIANCE=20 STATUS current=20 DESCRIPTION=20 "When this MIB is implemented without support for=20 read-write (i.e. in read-only mode), then such an =20 implementation can claim read-only compliance. =20 =20 =20 Expires June 13, 2014 [Page 23]=20= =20 =0C Internet-Draft < Energy Object Context MIB > December 2013=20= =20 Such a device can then be monitored but cannot be =20 Configured with this MIB. =20 Module Compliance of ENTITY-MIB with respect to =20 entity4CRCompliance should be supported."=20 MODULE -- this module=20 =20 MANDATORY-GROUPS {=20 energyObjectContextMIBTableGroup, =20 energyObjectRelationTableGroup=20 }=20 =20 GROUP energyObjectOptionalMIBTableGroup=20 DESCRIPTION=20 "A compliant implementation does not have to implement =20 the managed objects in this GROUP. =20 Module Compliance of ENTITY-MIB =20 with respect to entity4CRCompliance should =20 be supported. "=20 ::=3D { energyObjectContextMIBCompliances 2 }=20 =20 -- Units of Conformance=20 =20 energyObjectContextMIBTableGroup OBJECT-GROUP=20 OBJECTS { =20 eoDomainName,=20 eoRoleDescription,=20 eoAlternateKey,=20 eoKeywords,=20 eoImportance,=20 eoPowerCategory,=20 eoPowerInterfaceType =20 } =20 STATUS current=20 DESCRIPTION=20 "This group contains the collection of all the objects=20= related to the EnergyObject. =20 Module Compliance of ENTITY-MIB =20 with respect to entity4CRCompliance should =20 be supported. "=20 ::=3D { energyObjectContextMIBGroups 1 }=20 =20 energyObjectOptionalMIBTableGroup OBJECT-GROUP=20 OBJECTS { =20 eoEthPortIndex,=20 eoEthPortGrpIndex,=20 eoLldpPortNumber,=20 eoMgmtMacAddress,=20 eoMgmtAddressType,=20 =20 =20 Expires June 13, 2014 [Page 24]=20= =20 =0C Internet-Draft < Energy Object Context MIB > December 2013=20= =20 eoMgmtAddress,=20 eoMgmtDNSName =20 } =20 STATUS current=20 DESCRIPTION=20 "This group contains the collection of all the objects=20= related to the Energy Object."=20 ::=3D { energyObjectContextMIBGroups 2 }=20 =20 energyObjectRelationTableGroup OBJECT-GROUP=20 OBJECTS { =20 -- Note that object eoRelationIndex is not=20= -- included since it is not-accessible=20 =20 eoRelationID, =20 eoRelationship=20 } =20 STATUS current=20 DESCRIPTION=20 "This group contains the collection of all objects=20 specifying the relationship between Energy Objects."=20 ::=3D { energyObjectContextMIBGroups 3 }=20 =20 END=20 =20 =20 IANA-ENERGY-RELATION-MIB DEFINITIONS ::=3D BEGIN=20 IMPORTS=20 MODULE-IDENTITY, mib-2=20 FROM SNMPv2-SMI=20 TEXTUAL-CONVENTION=20 FROM SNMPv2-TC;=20 =20 ianaEnergyRelationMIB MODULE-IDENTITY=20 LAST-UPDATED "201312130000Z" -- December 13, 2013=20 ORGANIZATION "IANA"=20 CONTACT-INFO " =20 Internet Assigned Numbers Authority=20 Postal: ICANN=20 4676 Admiralty Way, Suite 330=20 Marina del Rey, CA 90292=20 Tel: +1-310-823-9358=20 EMail: iana&iana.org"=20 =20 =20 DESCRIPTION=20 "This MIB module defines a TEXTUAL-CONVENTION that=20 describes the relationships between Energy Objects.=20 =20 =20 Expires June 13, 2014 [Page 25]=20= =20 =0C Internet-Draft < Energy Object Context MIB > December 2013=20= =20 =20 Copyright (C) The IETF Trust (2013).=20 =20 The initial version of this MIB module was published in=20= RFC YYY; for full legal notices see the RFC itself.=20 Supplementary information may be available at=20 http://www.ietf.org/copyrights/ianamib.html"=20 =20 =20 REVISION "201312130000Z" -- December 13, 2013=20 DESCRIPTION "Initial version of this MIB as published in=20= RFC YYY." =20 ::=3D { energyMIB 2 }=20 TOM: Re-root this OID and insert a note to IANA/RFC Editor here. = Generally for experimental MIBs you put in a dummy number here like = transmission XXX so it won't compile. =20 -- RFC Editor, please replace YYY with the IANA allocation=20= -- for this MIB module and YYY with the number of the =20 -- approved RFC=20 =20 -- Textual Conventions =20 =20 IANAEnergyRelationship ::=3D TEXTUAL-CONVENTION=20 STATUS current=20 DESCRIPTION=20 "An enumerated value specifies the type of =20 relationship between Energy Objects.=20 =20 The enumeration 'poweredBy' is applicable if the =20 Energy Object A is poweredBy Energy Object B.=20 =20 The enumeration 'powering' is applicable if the =20 Energy Object A is powering Energy Object B.=20 =20 The enumeration 'meteredBy' is applicable if the =20 Energy Object A is meteredBy Energy Object B.=20 =20 The enumeration 'metering' is applicable if the =20 Energy Object A is metering Energy Object B.=20 =20 =20 The enumeration 'aggregatedBy' is applicable if the =20= Energy Object A is aggregatedBy Energy Object B.=20 =20 The enumeration 'aggregating' is applicable if the =20= Energy Object A is aggregating Energy Object B."=20 =20 SYNTAX INTEGER {=20 #TOM: You should not use INTEGER; use Integer32 instead. poweredBy(1), -- power relationship =20 powering(2),=20 =20 =20 Expires June 13, 2014 [Page 26]=20= =20 =0C Internet-Draft < Energy Object Context MIB > December 2013=20= =20 meteredBy(3), -- meter relationship =20 metering(4), =20 aggregatedBy(5), -- aggregation relationship =20= aggregating(6) =20 }=20 TOM: Should there be a reference here to where these values are actually = defined? =20 END=20 =20 =20 7. Implementation Status=20 [Note to RFC Editor: Please remove this section and the=20 reference to [RFC6982] before publication.]=20 =20 This section records the status of known implementations of the=20= EMAN-Monitoring MIB at the time of posting of this Internet- Draft, and is based on a proposal described in [RFC6982].=20 =20 The description of implementations in this section is intended=20 to assist the IETF in its decision processes in progressing=20 drafts to RFCs. =20 =20 11.1 SNMP Research =20 =20 Organization: SNMP Research, Inc.=20 =20 Maturity: Prototype based upon early drafts of the MIBs. =20 We anticipate updating it to more recent =20 documents as development schedules allow.=20 =20 Coverage: Code was generated to implement all MIB objects =20 in ENTITY-MIB (Version 4), =20 ENERGY-OBJECT-CONTEXT-MIB,=20 ENERGY-OBJECT-MIB, =20 POWER-CHARACTERISTICS-MIB,=20 and BATTERY-MIB.=20 =20 Implementation experience: The documents are implementable.=20 =20 Comments: Technical comments about the =20 ENERGY-OBJECT-CONTEXT-MIB,=20 ENERGY-OBJECT-MIB, and =20 BATTERY-MIB =20 were submitted to the EMAN Working Group =20 E-mail list. =20 =20 Licensing: Proprietary, royalty licensing=20 =20 =20 =20 Expires June 13, 2014 [Page 27]=20= =20 =0C Internet-Draft < Energy Object Context MIB > December 2013=20= =20 Contact: Alan Luchuk, luchuk at snmp.com=20 =20 URL: http://www.snmp.com/=20 =20 =20 11.2 Python=20 =20 Priyanka Rao mentioned on the mailing list=20 (http://www.ietf.org/mail-archive/web/eman/current/msg02063.html)=20= That she has got an python implementation.=20 =20 =20 =20 8. Security Considerations =20 Some of the readable objects in these MIB modules (i.e., objects=20= with a MAX-ACCESS other than not-accessible) may be considered=20= sensitive or vulnerable in some network environments. It is=20 thus important to control even GET and/or NOTIFY access to these=20= objects and possibly to even encrypt the values of these objects=20= when sending them over the network via SNMP. =20 =20 There are a number of management objects defined in these MIB=20 modules with a MAX-ACCESS clause of read-write and/or read- create. Such objects MAY be considered sensitive or vulnerable=20= in some network environments. The support for SET operations in=20= a non-secure environment without proper protection can have a=20 negative effect on network operations. The following are the=20 tables and objects and their sensitivity/vulnerability:=20 =20 . Unauthorized changes to the eoDomainName, entPhysicalName,=20= eoRoleDescription, eoKeywords, and/or eoImportance MAY=20 disrupt power and energy collection, and therefore any=20 predefined policies defined in the network.=20 =20 =20 SNMP versions prior to SNMPv3 did not include adequate security.=20= Even if the network itself is secure (for example, by using=20 IPsec), there is still no secure control over who on the secure=20= network is allowed to access and GET/SET=20 (read/change/create/delete) the objects in these MIB modules.=20 =20 =20 It is RECOMMENDED that implementers consider the security=20 features as provided by the SNMPv3 framework (see [RFC3410],=20 section 8), including full support for the SNMPv3 cryptographic=20= mechanisms (for authentication and privacy).=20 =20 =20 Expires June 13, 2014 [Page 28]=20= =20 =0C Internet-Draft < Energy Object Context MIB > December 2013=20= =20 =20 Further, deployment of SNMP versions prior to SNMPv3 is NOT=20 RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to=20= enable cryptographic security. It is then a customer/operator=20= responsibility to ensure that the SNMP entity giving access to=20= an instance of these MIB modules is properly configured to give=20= access to the objects only to those principals (users) that have=20= legitimate rights to GET or SET (change/create/delete) them.=20 =20 =20 9. IANA Considerations=20 TOM: The WG agreed to not root these modules under energyMIB, and = instead root each one under transmission on their own. Please correct = this. The MIB modules in this document uses the following IANA- TOM: uses -> use assigned OBJECT IDENTIFIER values recorded in the SMI Number=20 registry. =20 Descriptor OBJECT IDENTIFIER value=20 ---------- -----------------------=20 energyMIB { mib-2 XXX }=20 Editor's Note (to be removed prior to publication): IANA is=20 requested to assign a value for "XXX" under the 'mib-2' subtree=20= and to record the assignment in the SMI Numbers registry. When=20= the assignment has been made, the RFC Editor is asked to replace=20= "XXX" (here and in the MIB module) with the assigned value and=20= to remove this note.=20 This document defines the first version of the IANA-maintained=20= IANA-ENERGY-RELATION-MIB module, maintained by IANA, which allow=20= new definitions of relationships between Energy Objects. A=20 Specification Required as defined in RFC 5226 [RFC5226], is=20 REQUIRED for each modification or addition of the energy=20 relationships.=20 =20 10. Acknowledgement =20 We would like to thank Juergen Quittek and Juergen Schoenwalder=20= for their suggestions on the new design of eoRelationTable which=20= was a proposed solution for the open issue on the representation=20= of Energy Object as a UUIDlist. =20 =20 Many thanks to Juergen Quittek for many comments on the wording,=20= text and design of the MIB thus resulting in an improved draft. =20= =20 =20 =20 Expires June 13, 2014 [Page 29]=20= =20 =0C Internet-Draft < Energy Object Context MIB > December 2013=20= =20 Many thanks to Alan Luchuk for the review of the MIB and his=20 comments.=20 =20 In addition the authors thank Bill Mielke for his multiple=20 reviews, Brad Schoening and Juergen Schoenwaelder for their=20 suggestions and Michael Brown for dramatically improving this=20 draft.=20 =20 And finally thanks the EMAN WG chairs: Nevil Brownlee and Tom=20 Nadeau. =20 =20 11. References=20 11.1. Normative References=20 =20 [RFC2119] S. Bradner, Key words for use in RFCs to Indicate=20 Requirement Levels, BCP 14, RFC 2119, March 1997.=20 =20 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J.=20 Schoenwaelder, Ed., "Structure of Management=20 Information Version 2 (SMIv2)", STD 58, RFC 2578, April=20= 1999.=20 =20 [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J.=20 Schoenwaelder, Ed., "Textual Conventions for SMIv2",=20 STD 58, RFC 2579, April 1999.=20 =20 [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder,=20 "Conformance Statements for SMIv2", STD 58, RFC 2580,=20 April 1999.=20 =20 [RFC3621] Berger, A., and D. Romascanu, "Power Ethernet MIB",=20 RFC3621, December 2003.=20 =20 =20 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally=20= Unique IDentifier (UUID) URN Namespace ", RFC 4122,=20 July 2005.=20 =20 [RFC6933] Bierman, A. Romascanu,D. Quittek, J. and M.=20 Chandramouli, "Entity MIB (Version 4)", RFC 6933, May=20 2013.=20 =20 [LLDP-MIB] IEEE 802.1AB-2005, "Management Information Base=20 module for LLDP configuration, statistics, local system=20= data and remote systems data components", May 2005.=20 =20 =20 =20 Expires June 13, 2014 [Page 30]=20= =20 =0C Internet-Draft < Energy Object Context MIB > December 2013=20= =20 [LLDP-MED-MIB] ANSI/TIA-1057, "The LLDP Management Information=20= Base extension module for TIA-TR41.4 media endpoint=20 discovery information", July 2005.=20 =20 [EMAN-MON-MIB] M. Chandramouli, Schoening, B., Quittek, J.,=20 Dietz, T., and B. Claise "Power and Energy Monitoring=20= MIB", draft-ietf-eman-energy-monitoring-mib-07, October=20= 2013.=20 =20 =20 11.2. Informative References=20 =20 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart,=20 "Introduction and Applicability Statements for Internet=20= Standard Management Framework", RFC 3410, December=20 2002.=20 =20 [RFC3433] Bierman, A., Romascanu, D., and K.C. Norseth, "Entity=20= Sensor Management Information Base", RFC 3433, December=20= 2002.=20 =20 [RFC5226] Narten, T. Alverstrand, H., A. and K. McCloghrie,=20 "Guidelines for Writing an IANA Considerations Section=20= in RFCs ", BCP 26, RFC 5226, May 2008.=20 =20 [RFC6988] Quittek, J., Winter, R., Dietz, T., Claise, B., and M.=20= Chandramouli, "Requirements for Energy Management", RFC=20= 6988, September 2013.=20 =20 [EMAN-FMWK] Claise, B., Parello, J., Schoening, B., and J.=20 Quittek, "Energy Management Framework", draft-ietf- eman-framework-11, work in progress, November 2013.=20 =20 [EMAN-AS] Schoening, B., Chandramouli, M, and B. Nordman,=20 "Energy Management (EMAN) Applicability Statement",=20 draft-ietf-eman-applicability-statement-04.txt, work in=20= progress, October 2013.=20 =20 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of=20 Running Code: The Implementation Status Section", RFC=20 6982, July 2013.=20 =20 Authors' Addresses=20 =20 Benoit Claise=20 Cisco Systems, Inc.=20 De Kleetlaan 6a b1=20 =20 =20 Expires June 13, 2014 [Page 31]=20= =20 =0C Internet-Draft < Energy Object Context MIB > December 2013=20= =20 Diegem 1813=20 BE=20 =20 Phone: +32 2 704 5622=20 Email: bclaise@cisco.com=20 =20 =20 John Parello=20 Cisco Systems, Inc.=20 3550 Cisco Way =20 San Jose, California 95134 =20 US=20 =20 Phone: +1 408 525 2339=20 Email: jparello@cisco.com=20 =20 =20 Mouli Chandramouli=20 Cisco Systems, Inc.=20 Sarjapur Outer Ring Road=20 Bangalore 560103 =20 IN=20 =20 Phone: +91 80 4429 2409 =20 Email: moulchan@cisco.com=20 =20 =20 =20 Expires June 13, 2014 [Page 32]=20= =20 --Apple-Mail=_0AC5826E-9193-4682-89FF-BAB8B559FEE3 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 iQIcBAEBCgAGBQJS3t4WAAoJEPcO+I7eiUJZAMQQAKWbnfsrBRTs24MUwGVbja9M 2djLOKvdANB7+dWB9yQGQb2+3S4XcS1sOXKmN5YMhl3IgkEwuAHTjSYRjgPgJ3XV i1DmfvlFeytYVWVuURw12MdXKP1hrXyHKml5pQvCgeiMhP/ey9dEjnqaRgNFcPPr j8NrTDVmwLulATVt8McbP8l/AwKTe8Vd1fPf2GlkYaFhZg45gid89vB+Ciylizts Q/8wmBIHsMD93HQjABS/xC3vcM8LBmABIDeGVR8CtoMfXw0HvinjpDluhTIHqWxx CgskoRrRpIIxlnvTX+A4OL4m0p5qfrsqmdzY7El+xEjB8pW4wn3jOMjqlaWpTV8R YA1uQW1pHtqD1jwiG2cyR3Rhr40nKh7Cqv1wbzZ22RRwcqq5wtKBnOn1yUVOQySe lM1rzDy9rsjinJ28jmkFxLtA+lLs7qMT3kn+Oued482Trmgsa1CR8WiAzbxtNK/x ZNi/0b+rnQKxJYutCYfr106YB/py/biKcUKp9BYkR4UAphC6CxiRXy60VGNcKQ2Z VK7FKUa36mZ1m5VvLY3wlYJmcyjfIVnKvqR+VskpayviWg5AO85YhBaL6oBdYHDB fl3r4or6XBnFwhhbE5x/+aZNt7hgxFgf4AQ/efz6VxXIxhsUJe/y0MeJXtVaQNN5 0I452CNQL+W4Tr44/LYd =PqwB -----END PGP SIGNATURE----- --Apple-Mail=_0AC5826E-9193-4682-89FF-BAB8B559FEE3-- From jparello@cisco.com Tue Jan 21 13:25:43 2014 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 652541A0263; Tue, 21 Jan 2014 13:25:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.036 X-Spam-Level: X-Spam-Status: No, score=-10.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PLuLnmkF2s4r; Tue, 21 Jan 2014 13:25:40 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id ABF061A0356; Tue, 21 Jan 2014 13:25:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=434; q=dns/txt; s=iport; t=1390339540; x=1391549140; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=YmDH/GtRPLjrDw4u7MXS+sOfjaJZzXzLconFQklFhTg=; b=CsRWP++1XXa0enzXLzRA2+puYVRv6zuuiXsz7jXsu5qPY1mmf84OErwu Ncnly4HT8ERxzgn+Xv8vUY4htHMKvxp1ndYAZqp00Cbv/46YTBvq4GV3n wJyjUOhaiGYGnP/4HOFaFqhWrZwmnshYigZXqyqFk/SWlVVZO7zwTcww/ s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhMLAHrl3lKtJV2d/2dsb2JhbABagwu1YYcfgRYWdIImAQEEOj8QAgEIDigQMiUCBA4FiAXDCxeOTDMHgySBFASYIpIYgy0 X-IronPort-AV: E=Sophos;i="4.95,697,1384300800"; d="scan'208";a="14478614" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-8.cisco.com with ESMTP; 21 Jan 2014 21:25:40 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s0LLPek5003494 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 21 Jan 2014 21:25:40 GMT Received: from xmb-aln-x04.cisco.com ([169.254.9.10]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0123.003; Tue, 21 Jan 2014 15:25:40 -0600 From: "John Parello (jparello)" To: Thomas Nadeau Thread-Topic: [eman] MIB Doctor Review of draft-ietf-eman-energy-aware-mib-13 Thread-Index: AQHPFurCuxcWU93Os0WLCEyAtjrnYpqPsNOX Date: Tue, 21 Jan 2014 21:25:39 +0000 Message-ID: <3E9885B4-9E4C-482E-99B0-A879BC169091@cisco.com> References: <8F88CD1C-C5F1-497D-8643-538E7D1C3BDF@lucidvision.com> In-Reply-To: <8F88CD1C-C5F1-497D-8643-538E7D1C3BDF@lucidvision.com> 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: "MIB Doctors \(E-mail\)" , eman mailing list Subject: Re: [eman] MIB Doctor Review of draft-ietf-eman-energy-aware-mib-13 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 21 Jan 2014 21:25:43 -0000 Hi Tom Thanks. Still going through the comments. For the first one regarding EnMS = acronym. That's was discussed at length and we adopted it since ISO50001 us= ed that to describe a management system for energy (as opposed to NMS) Not great but what's in use. Jp Sent from my iPad=20 (expect ridiculous spelling mistakes)=20 On Jan 21, 2014, at 9:52 PM, "Thomas Nadeau" wrot= e: >=20 From tnadeau@lucidvision.com Tue Jan 21 13:29:07 2014 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2A1C1A0381; Tue, 21 Jan 2014 13:29:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 33vTEdiPvBcz; Tue, 21 Jan 2014 13:29:04 -0800 (PST) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 3D8831A038E; Tue, 21 Jan 2014 13:29:03 -0800 (PST) Received: from [192.168.1.110] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id AF9DB26C177C; Tue, 21 Jan 2014 16:29:02 -0500 (EST) Content-Type: multipart/signed; boundary="Apple-Mail=_613FDD3E-22E2-4ABA-B6FD-553BAA257E10"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Thomas Nadeau In-Reply-To: <3E9885B4-9E4C-482E-99B0-A879BC169091@cisco.com> Date: Tue, 21 Jan 2014 16:29:02 -0500 Message-Id: <3CC2391F-03E9-4060-8AD0-124074DDE480@lucidvision.com> References: <8F88CD1C-C5F1-497D-8643-538E7D1C3BDF@lucidvision.com> <3E9885B4-9E4C-482E-99B0-A879BC169091@cisco.com> To: "John Parello (jparello)" X-Mailer: Apple Mail (2.1827) Cc: "MIB Doctors \(E-mail\)" , eman mailing list Subject: Re: [eman] MIB Doctor Review of draft-ietf-eman-energy-aware-mib-13 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 21 Jan 2014 21:29:07 -0000 --Apple-Mail=_613FDD3E-22E2-4ABA-B6FD-553BAA257E10 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii That is cool,but please put in a reference and (brief) = explanation into the text somewhere. To the casual or new reader, it is = not obvious. *) --Tom > Hi Tom >=20 > Thanks. Still going through the comments. For the first one regarding = EnMS acronym. That's was discussed at length and we adopted it since = ISO50001 used that to describe a management system for energy (as = opposed to NMS) >=20 > Not great but what's in use. >=20 > Jp >=20 > Sent from my iPad=20 > (expect ridiculous spelling mistakes)=20 >=20 > On Jan 21, 2014, at 9:52 PM, "Thomas Nadeau" = wrote: >=20 >>=20 >=20 --Apple-Mail=_613FDD3E-22E2-4ABA-B6FD-553BAA257E10 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 iQIcBAEBCgAGBQJS3uaeAAoJEPcO+I7eiUJZEiUP/jMRSKjymoXFfg6GmBcHc+uw yCkLAmAuy9KDYY0KK3Q1IvA//hVntU5QH6RDzWhHJsLOg5iuZpKyANFkCtI2pFyP ttnMQH1xwAt9iRdi6eWUagR+xUuT1daTYFA/94ExOnYTzgt7SLZHHaky07vDUaN1 RBiAZbom4ik8FmPxGOUCo5o6dmog7f7irBheYR/INzbl9uPsCpVfn64iV+saUPBq Z+bf/ictZRnEdJkHmHoN4MxCDgpCDUbP360Scf6M2i6Wi0raCbARViOd5bgSE34h hmpN0Idta9he4PB6uoP1SZmOtetIEg1t2/sBwclwsGA4yBf81RGBs47Put22K3Zd ERpGhj9IriGfz/4UlhhtEC/kMAzG2dH5xrE+aQaDT0WAkyKnRRg9gkAaKBX3BhrM ZMdrCWNirFRGGpQXfG2pbpk+cL89u41L3l9YpEa9I9u6HOJffzCQRIIzrDRcetlx mPkVQDMP2Z4QAXF3gCV+6cbkYqO9a+HcdqDifmNFNUvfxRwJ3qo5LIRoNvUKNt2u PK1T3U9ssd+F06zbQEtP8slP07HQJolR8HVmtS46hTaP+NPOvSPqo4GAiNunDE0E KbGg3kiarqLdhDJ5c43u/ExygaRB5o4358dHlRUVMrD2TdBLyXO13ltmwSTUpJ5i 3AlPM54SSOJyZ4qF5lly =bqSx -----END PGP SIGNATURE----- --Apple-Mail=_613FDD3E-22E2-4ABA-B6FD-553BAA257E10-- From jparello@cisco.com Tue Jan 21 13:38:05 2014 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AA461A0393 for ; Tue, 21 Jan 2014 13:38:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.035 X-Spam-Level: X-Spam-Status: No, score=-10.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZAyiaTDTnQH7 for ; Tue, 21 Jan 2014 13:38:02 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) by ietfa.amsl.com (Postfix) with ESMTP id 0A15C1A0381 for ; Tue, 21 Jan 2014 13:38:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8286; q=dns/txt; s=iport; t=1390340282; x=1391549882; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=6e6y+jiwZa8Qfk2RbA+LFAV5CW/vIC36ydeNBocI8do=; b=ixRFG2BkVwYvNOmMLoVC4uJp5rOjz9EipU6IPKxLJAgl0NyY1fMYPGCZ 7pHG0LQ72RQU3M9Wp39LzfAL4tGFgX3d/Mv16EzQogGpct4eyAoBAteby WRA0Cvpq2Zpg0nvDKu/gS6LFPEhKp8Xp1lGGPqZF3ZlqP/h6uDKNRLTG8 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmAPABXo3lKtJV2Z/2dsb2JhbABagws4s3aBM4cfgRYWdIImAQEEeRACAQgOHxIHMhQRAgQOBYgFDcJ1F45/BwqDGoEUBJgigTKQZoMt X-IronPort-AV: E=Sophos;i="4.95,697,1384300800"; d="scan'208,217";a="14478019" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-7.cisco.com with ESMTP; 21 Jan 2014 21:38:01 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s0LLc1Y7030594 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 21 Jan 2014 21:38:01 GMT Received: from xmb-aln-x04.cisco.com ([169.254.9.10]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0123.003; Tue, 21 Jan 2014 15:38:01 -0600 From: "John Parello (jparello)" To: Thomas Nadeau Thread-Topic: [eman] MIB Doctor Review of draft-ietf-eman-energy-aware-mib-13 Thread-Index: AQHPFurCuxcWU93Os0WLCEyAtjrnYpqPsNOXgABlhwD//53tnw== Date: Tue, 21 Jan 2014 21:38:00 +0000 Message-ID: References: <8F88CD1C-C5F1-497D-8643-538E7D1C3BDF@lucidvision.com> <3E9885B4-9E4C-482E-99B0-A879BC169091@cisco.com>, <3CC2391F-03E9-4060-8AD0-124074DDE480@lucidvision.com> In-Reply-To: <3CC2391F-03E9-4060-8AD0-124074DDE480@lucidvision.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_AD8ED75882B646ECAB7624BF42775C5Aciscocom_" MIME-Version: 1.0 Cc: eman mailing list Subject: Re: [eman] MIB Doctor Review of draft-ietf-eman-energy-aware-mib-13 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 21 Jan 2014 21:38:05 -0000 --_000_AD8ED75882B646ECAB7624BF42775C5Aciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ok we have all that in the framework and that should just be copied over. This is what we have in framework: """ 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. """ Jp Sent from my iPad (expect ridiculous spelling mistakes) On Jan 21, 2014, at 10:29 PM, "Thomas Nadeau" > wrote: That is cool,but please put in a reference and (brief) explanation into = the text somewhere. To the casual or new reader, it is not obvious. *) --Tom Hi Tom Thanks. Still going through the comments. For the first one regarding EnMS = acronym. That's was discussed at length and we adopted it since ISO50001 us= ed that to describe a management system for energy (as opposed to NMS) Not great but what's in use. Jp Sent from my iPad (expect ridiculous spelling mistakes) On Jan 21, 2014, at 9:52 PM, "Thomas Nadeau" > wrote: --_000_AD8ED75882B646ECAB7624BF42775C5Aciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ok we have all that in the framework and that should just be copied over.
This is what we have in fra= mework:

"""
 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. 
"""<=
/pre>

Jp
Sent from my iPad 
(expect ridiculous spelling mistakes) 

On Jan 21, 2014, at 10:29 PM, "Thomas Nadeau" <tnadeau@lucidvision.com> wrote:


   That is cool,but please put in a reference and (brief) e= xplanation into the text somewhere. To the casual or new reader, it is not = obvious. *)

   --Tom


Hi Tom

Thanks. Still going through the comments. F= or the first one regarding EnMS acronym. That's was discussed at length and= we adopted it since ISO50001 used that to describe a management system for= energy (as opposed to NMS)

Not great but what's in use.

Jp

Sent from my iPad
(expect ridiculous spelling mistakes)

On Jan 21, 2014, at 9:52 PM, "Thomas N= adeau" <tnadeau@lucidvis= ion.com> wrote:




--_000_AD8ED75882B646ECAB7624BF42775C5Aciscocom_-- From tnadeau@lucidvision.com Tue Jan 21 13:53:19 2014 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B93591A03C7 for ; Tue, 21 Jan 2014 13:53:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.434 X-Spam-Level: X-Spam-Status: No, score=-2.434 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zg-WJKiVNpaq for ; Tue, 21 Jan 2014 13:53:18 -0800 (PST) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 75A7C1A03C0 for ; Tue, 21 Jan 2014 13:53:17 -0800 (PST) Received: from [192.168.1.110] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 0764E26C1857; Tue, 21 Jan 2014 16:53:17 -0500 (EST) Content-Type: multipart/signed; boundary="Apple-Mail=_392BD728-0D0F-424C-9454-E9BCBFD65272"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Thomas Nadeau In-Reply-To: Date: Tue, 21 Jan 2014 16:53:16 -0500 Message-Id: References: <8F88CD1C-C5F1-497D-8643-538E7D1C3BDF@lucidvision.com> <3E9885B4-9E4C-482E-99B0-A879BC169091@cisco.com>, <3CC2391F-03E9-4060-8AD0-124074DDE480@lucidvision.com> To: "John Parello (jparello)" X-Mailer: Apple Mail (2.1827) Cc: eman mailing list Subject: Re: [eman] MIB Doctor Review of draft-ietf-eman-energy-aware-mib-13 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 21 Jan 2014 21:53:19 -0000 --Apple-Mail=_392BD728-0D0F-424C-9454-E9BCBFD65272 Content-Type: multipart/alternative; boundary="Apple-Mail=_389BF444-102B-40B4-9018-5CCE341737C7" --Apple-Mail=_389BF444-102B-40B4-9018-5CCE341737C7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Or instead of copy/paste, just put in a reference to it.=20 --Tom >=20 > Ok we have all that in the framework and that should just be copied = over. > This is what we have in framework: >=20 > """ > Energy Management System (EnMS) >=20 > An Energy Management System is a combination of hardware and software = used to administer a network with the primary purpose of energy = management.=20 >=20 > 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.=20 > """ > Jp >=20 >=20 >=20 > Sent from my iPad=20 > (expect ridiculous spelling mistakes)=20 >=20 > On Jan 21, 2014, at 10:29 PM, "Thomas Nadeau" = wrote: >=20 >>=20 >> That is cool,but please put in a reference and (brief) explanation = into the text somewhere. To the casual or new reader, it is not obvious. = *) >>=20 >> --Tom >>=20 >>=20 >>> Hi Tom >>>=20 >>> Thanks. Still going through the comments. For the first one = regarding EnMS acronym. That's was discussed at length and we adopted it = since ISO50001 used that to describe a management system for energy (as = opposed to NMS) >>>=20 >>> Not great but what's in use. >>>=20 >>> Jp >>>=20 >>> Sent from my iPad=20 >>> (expect ridiculous spelling mistakes)=20 >>>=20 >>> On Jan 21, 2014, at 9:52 PM, "Thomas Nadeau" = wrote: >>>=20 >>>>=20 >>>=20 >>=20 --Apple-Mail=_389BF444-102B-40B4-9018-5CCE341737C7 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii

Or instead of copy/paste, just put in a reference to it. 

--Tom


Ok we have all that in the framework and that should just be copied over.
This is what we have in framework:

"""
 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. 
"""
Jp



Sent from my iPad 
(expect ridiculous spelling mistakes) 

On Jan 21, 2014, at 10:29 PM, "Thomas Nadeau" <tnadeau@lucidvision.com> wrote:


   That is cool,but please put in a reference and (brief) explanation into the text somewhere. To the casual or new reader, it is not obvious. *)

   --Tom


Hi Tom

Thanks. Still going through the comments. For the first one regarding EnMS acronym. That's was discussed at length and we adopted it since ISO50001 used that to describe a management system for energy (as opposed to NMS)

Not great but what's in use.

Jp

Sent from my iPad
(expect ridiculous spelling mistakes)

On Jan 21, 2014, at 9:52 PM, "Thomas Nadeau" <tnadeau@lucidvision.com> wrote:





--Apple-Mail=_389BF444-102B-40B4-9018-5CCE341737C7-- --Apple-Mail=_392BD728-0D0F-424C-9454-E9BCBFD65272 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 iQIcBAEBCgAGBQJS3uxMAAoJEPcO+I7eiUJZVhYQAIrPneLaBdpubWxc19wvOPZT ZcfdNHxp35awGJEMa74pSpnr0xmmD6WZfu59uujz54L4nc00zVAF74zif5/5GFrD Uxy1Wk3XkIiIQQQC/Zl5fhAmhADgLqQUE9cT7lcSbqXjFDAKstYCRoHOwfaIMq4A LtzcGM+iejtjSXtDBlbUcLeMmvLV2iUOiW1FMnA18lF9R96iIt7BOcKFjyYFZBfi p3qJdXkb3KiP7xH6ixrJjXn4u2/Q70+Z4m+ansU/EfmEOvBa78MJM4DBjlV9h3Qd 3kiV0S/puq8y1aSZlMHO96goXJlG43u4RgOqDMzkNN/5wNSawBra6ogEuxXJGeyL MBPEv3SMvEM+wmdX4liYGZmG+nKfhZZuxFT56d2wGyvROZaXb8z4/e1bu3lAw5am JLNxQ/gRi5o0wrBceQx2HIdnnL1B5z0y4EHzB/PuSom+3hUnVKiIP4wWNmnNFf6P UCSsxQATX4//Uet1LfAL8b5Dqb6oYRQLetaOW6UZxxRjkKL0OWXH9w+zzlVoKeaB DGiN0Fzbtom8esv3Rq8Q+epFuR+CRNQmYH4vcV270/EN0RKRw90jyL95JLy/Amc/ nTROcM7JE4LP/CyCkQN2LEBSJwGyMwebM7tSQgBx8H/kbc3bRWCX72lSlpGbz2rs DMNoyDYJT2RBz2YDlNNY =RaUB -----END PGP SIGNATURE----- --Apple-Mail=_392BD728-0D0F-424C-9454-E9BCBFD65272-- From karagian@cs.utwente.nl Wed Jan 22 01:54:36 2014 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 541391A0231 for ; Wed, 22 Jan 2014 01:54:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BBDFuyAtFUCe for ; Wed, 22 Jan 2014 01:54:31 -0800 (PST) Received: from out44-ams.mf.surf.net (out44-ams.mf.surf.net [145.0.1.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2BD4D1A0099 for ; Wed, 22 Jan 2014 01:54:31 -0800 (PST) Received: from EXEDGE02.ad.utwente.nl (exedge02.ad.utwente.nl [130.89.5.49]) by outgoing2-ams.mf.surf.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id s0M9sI7G011614; Wed, 22 Jan 2014 10:54:18 +0100 Received: from EXHUB01.ad.utwente.nl (130.89.4.228) by EXEDGE02.ad.utwente.nl (130.89.5.49) with Microsoft SMTP Server (TLS) id 14.2.328.9; Wed, 22 Jan 2014 10:54:24 +0100 Received: from EXMBX23.ad.utwente.nl ([169.254.3.41]) by EXHUB01.ad.utwente.nl ([130.89.4.228]) with mapi id 14.02.0328.009; Wed, 22 Jan 2014 10:54:18 +0100 From: To: , Thread-Topic: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib-13 Thread-Index: AQHPFqYCyzwAn0rSikWUPCud5c186pqQgk/Q Date: Wed, 22 Jan 2014 09:54:17 +0000 Message-ID: References: <5298B7FA.1010509@cisco.com> <52A5A9FA.80101@cisco.com> <52A5C2A6.9000501@cisco.com> <52AB8777.9060704@cisco.com> <653A4764-315C-4671-B0DA-389553CB3E29@lucidvision.com> <5339BC8D-660B-4659-96DC-C0170E124134@lucidvision.com> <9AB93E4127C26F4BA7829DEFDCE5A6E8688B32A5@DAPHNIS.office.hd> In-Reply-To: Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.89.12.129] Content-Type: multipart/alternative; boundary="_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F41C364EXMBX23adutwent_" MIME-Version: 1.0 X-Bayes-Prob: 0.0001 (Score 0, tokens from: @@RPTN) X-CanIt-Geo: ip=130.89.5.49; country=NL; region=15; city=Enschede; latitude=52.2195; longitude=6.8912; http://maps.google.com/maps?q=52.2195,6.8912&z=6 X-CanItPRO-Stream: utwente-out:default (inherits from utwente:default, base:default) X-Canit-Stats-ID: 0vLgVSimR - d3f7157ffa22 - 20140122 (trained as not-spam) X-Scanned-By: CanIt (www . roaringpenguin . com) Subject: Re: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib-13 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 22 Jan 2014 09:54:36 -0000 --_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F41C364EXMBX23adutwent_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Mouli, Thanks for your answers! Best regards, Georgios From: Mouli Chandramouli (moulchan) [mailto:moulchan@cisco.com] Sent: dinsdag 21 januari 2014 13:41 To: Karagiannis, G. (EWI); eman@ietf.org Subject: Re: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib-= 08 and draft-ietf-eman-energy-aware-mib-13 Hi Georgios, We are addressing the comments with respect to draft-ietf-eman-energy-aware= -mib-13. Replies inline. Thanks Mouli Hi all, Sorry for the delay on providing comments on time for the WGLC of draft-iet= f-eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib-13. Here are my comments! Many of the comments that I wanted to send are similar to the ones sent by = Juergen Quittek. Therefore, I will send only the ones that are different! =3D> Regarding: draft-ietf-eman-energy-aware-mib-13: Comment_1: Section 5, page 6 shows the entries/attributes (MIB objects) of= the eaTable and eoRelationTable. In Figure 1 the UML diagram illustrates t= he relationship of the MIB objects in the eatable and eoRelationTable. Howe= ver not all entries (MIB objects) depicted in eaTable and eoRelationTable (= page 6) are shown in the UML diagrams. Please elaborate on this in the text= . ycm>> The UML diagram has been updated. Comment_2: In section 5.2, page 20 is mentioned: "The Energy Object can be = classified as consuming power or supplying power to other devices or that E= nergy Object can perform both of those functions, ..". However, in the form= al MIB definition on page 20, eoPowerCategory can get the values: consumer = (0), producer(1), meter(2), distributor(3) or store(4). From what I can see= no value is provided for the situation that the energy object can perform = both functions consumer and producer. ycm>> This point has been discussed at length and the approach that we ha= ve taken is to use a vector for the Keywords to allow for further defining = context you describe. We proposed scalar for the PRIMARY category. ycm>> Please refer to http://www.ietf.org/mail-archive/web/eman/current/= msg02033.html =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D =3D> Regarding draft-ietf-eman-energy-monitoring-mib-08: Comment_1:Section 5: It is not clear what is the relation between the ENERG= Y-OBJECT-MIB MIB module tables, the associated UML diagram given in Figure = 1 and the text other subsections (5.1, 5.2, 5.3, 5.4, 5.5 and 5.6.).. Pleas= e make this relation clear. Comment_2: The same holds for the powerAttributeMIB MIB module tables, UML = diagram given in Figure 2 and subsections (5.1, 5.2, 5.3, 5.4, 5.5 and 5.6.= ). Comment_3: The description of the powerAttributeMIB MIB module tables on pa= ge 8 is too short. A similar description as the one described for the ENERG= Y-OBJECT-MIB MIB module tables in page 6 could be also provided, Comment_4: Some parts of the UML diagram given in Figure 2 as representing = the relations in the powerAttributeMIB are (probabl) part of the ENERGY-OB= JECT-MIB. These are the Energy ParametersTable and EnergyTable. Comment_5: not all entries (MIB objects) depicted in the ENERGY-OBJECT-MIB = MIB module tables are shown in the UML diagram depicted in Fgure 1.Please e= laborate. Comment_6: the same holds for powerAttributeMIB MIB module tables and the = UML diagram depicted in Figure 2. Comment_7: Maybe the title of Section 5.1 should be: Enetgy Object Identity= , instead of Energy Object Information? Comment_8: The description of the vertical axis used in Figure 3 is not cle= ar to me. Are both horizontal axis and vertical axis representing time. Reg= arding the vertical axis you might want to say that the vertical axis repre= sents the amount of measured power ? Comment_9: The description of Figure 4 is not clear to me. You might includ= e at the right sde of the figure and for each window the term S+L, so (S1+L= , S2+L, S3+L and S4+L). You can then explain that the value of the EoEnergy= Consumed is obtained at these time intervals (Sx+L).. Comment_10: Section 6 is very important and its importance should be emphas= ized more clearly in the Introduction. Comment_11: In Section 6 the term EMAN-MON-MIB is used for the first time. = I considered that it referes to this document. Please emphasize that in the= text. Comment_12: Section 8 provides an example for the implementation of the Ene= rgy Object, including the Energy Object relationships. Is it possible to pr= ovide an example of the IANAEnergyRelationship (in particular regaring aggr= egation) defined in [ENERGY-AWARE-MIB]. Comment_13: Are the MIB objects defined in this draft complying with the me= chanisms defined by SMIv2 [RFC2578, RFC2579, RFC2580? If yes, please emphas= ize this in the document! Best regards, Georgios Karagiannis ________________________________ Van: eman [eman-bounces@ietf.org] namens Thom= as Nadeau [tnadeau@lucidvision.com] Verzonden: maandag 30 december 2013 20:52 To: Juergen Quittek Cc: eman mailing list Onderwerp: Re: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mi= b-08 and draft-ietf-eman-energy-aware-mib-13 The note said 8AM EDT. *) Anyways, send over your comments ASAP. --Tom On Dec 30, 2013:1:46 PM, at 1:46 PM, Juergen Quittek > wrote: > Hi Tom, > I missed the fact that the deadline is already in the morning of today. I= thought I had the full day today for sending them. There are still some co= mments that I planned to send this evening. I will send them asap and hope = they will be OK even if a few hours late. > Thanks, > Juergen > >> -----Original Message----- >> From: eman [mailto:eman-bounces@ietf.org] On Behalf Of Thomas Nadeau >> Sent: Montag, 30. Dezember 2013 14:44 >> To: eman mailing list >> Subject: Re: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-m= ib- >> 08 and draft-ietf-eman-energy-aware-mib-13 >> >> >> WG, >> >> This concludes the WG LC on the MIBs. We have received just one se= t >> of comments from the WG and one set of comments regarding the OID >> numbering. Would the document editors please address these and republish >> the drafts ASAP so that we can proceed with progressing the drafts? >> >> Cheers and Happy Holidays, >> >> Tom >> >> >>> >>> As agreed at the last WG meeting, with the EMAN Framework >> completing its WG LC the chairs would like to initiate a WG LC on draft-= ietf- >> eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib-13. >> The WG LC will end on Dec 30 at 8AM EDT. >>> >>> Thank you, >>> >>> Nevil and Tom >>> >>> >>> _______________________________________________ >>> eman mailing list >>> eman@ietf.org >>> https://www.ietf.org/mailman/listinfo/eman > > --_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F41C364EXMBX23adutwent_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Mouli,

 <= /p>

Thanks for your answers!<= o:p>

 <= /p>

Best regards,<= /span>

Georgios

 <= /p>

 <= /p>

From: Mouli Chandramouli (moulchan) [mailto:moulchan@cisco.= com]
Sent: dinsdag 21 januari 2014 13:41
To: Karagiannis, G. (EWI); eman@ietf.org
Subject: Re: [eman] WG Last Call for draft-ietf-eman-energy-monitori= ng-mib-08 and draft-ietf-eman-energy-aware-mib-13

 

Hi  Geor= gios,

 

We are addressing the comments with respect t= o draft-ietf-eman-energy-aware-mib-13.=

 

Replies inline. 

 

Thanks

Mouli

 

Hi all,

 

Sorry for the delay on providing comments on time for the WGLC of d= raft-ietf-eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mi= b-13.

 

Here are my comments!


Many of the comments that I wanted to send are similar to the ones = sent by Juergen Quittek. Therefore, I will send only the ones that are diff= erent!

 

=3D> Regarding: draft-ietf-eman-energy-aware-mib-13:

 

Comment_1: Section 5, page 6 shows the entries/attributes  (MI= B objects) of the eaTable and eoRelationTable. In Figure 1 the UML diagram = illustrates the relationship of the MIB objects in the eatable and eoRelationTable. However not all entries (MIB objects) = depicted in eaTable and eoRelationTable (page 6) are shown in the UML diagr= ams. Please elaborate on this in the text.

 

ycm>>  The UML d= iagram has been updated. 

 =

Comment_2: In= section 5.2, page 20 is mentioned: “The Energy Object can be classif= ied as consuming power or supplying power to other devices or that Energy Object can perform both of those functions, ..”. However, in = the formal MIB definition on page 20, eoPowerCategory can get the values: c= onsumer (0), producer(1), meter(2), distributor(3) or store(4). From what I= can see no value is provided for the situation that the energy object can perform both functions consumer and p= roducer.

 =

 ycm>= > This point has been discussed at length  and the approach&nb= sp;that we have taken is to use a vector for the Keywords to allow for further defining context you de= scribe. We proposed scalar for the PRIMARY category. 

 

 

 

=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D

 =

=3D> Regarding draft-ietf-eman-energy-monitoring-mib-08:<= span style=3D"color:black">

 

Comment_1:Section 5: It is not clear what is the relation between t= he ENERGY-OBJECT-MIB MIB module tables, the associated UML diagram given in= Figure 1 and the text other subsections (5.1, 5.2, 5.3, 5.4, 5.5 and 5.6.).. Please make this relation clear.

 

Comment_2: The same holds for the powerAttributeMIB MIB module tabl= es, UML diagram given in Figure 2 and subsections (5.1, 5.2, 5.3, 5.4, 5.5 = and 5.6.).

 

Comment_3: The description of the powerAttributeMIB MIB module tabl= es on page 8 is too short. A similar description as the one described for t= he ENERGY-OBJECT-MIB MIB module tables in page 6 could be also provided,<= /o:p>

 

Comment_4: Some parts of the UML diagram given in Figure 2 as repre= senting the relations in the powerAttributeMIB are (probabl)  part of = the ENERGY-OBJECT-MIB. These are the Energy ParametersTable and EnergyTable.

 

Comment_5: not all entries (MIB objects) depicted in the ENERGY-OBJ= ECT-MIB MIB module tables are shown in the UML diagram depicted in Fgure 1.= Please elaborate.

 

Comment_6: the same holds for powerAttributeMIB MIB module tables&n= bsp; and the UML diagram depicted in Figure 2.

 

Comment_7: Maybe the title of Section 5.1 should be: Enetgy Object = Identity, instead of Energy Object Information?

 

Comment_8: The description of the vertical axis used in Figure 3 is= not clear to me. Are both horizontal axis and vertical axis representing t= ime. Regarding the vertical axis you might want to say that the vertical axis represents the amount of measured power= ?

 

Comment_9: The description of Figure 4 is not clear to me. You migh= t include at the right sde of the figure and for each window the term S+= ;L, so (S1+L, S2+L, S3+L and S4+L). You can then explain that the value of the EoEnergyConsumed is obtained at these t= ime intervals (Sx+L)..

 

Comment_10: Section 6 is very important and its importance should b= e emphasized more clearly in the Introduction.

 

Comment_11: In Section 6 the term EMAN-MON-MIB is used for the firs= t time. I considered that it referes to this document. Please emphasize tha= t in the text.

 

Comment_12: Section 8 provides an example for the implementation of= the Energy Object, including the Energy Object relationships. Is it possib= le to provide an example of the IANAEnergyRelationship (in particular regaring aggregation) defined in [ENERGY-AWARE-MIB].=

 

Comment_13: Are the MIB objects defined in this draft complying wit= h the mechanisms defined by SMIv2 [RFC2578, RFC2579, RFC2580? If yes, pleas= e emphasize this in the document!

 

Best regards,<= /p>

Georgios Karagiannis<= /span>

 

 

 

Van: eman [eman-bounces@ietf.org] namens Thomas Nadeau [tnadeau@l= ucidvision.com]
Verzonden: maandag 30 december 2013 20:52
To: Juergen Quittek
Cc: eman mailing list
Onderwerp: Re: [eman] WG Last Call for draft-ietf-eman-energy-monito= ring-mib-08 and draft-ietf-eman-energy-aware-mib-13


        The note said 8AM EDT. *)

        Anyways, send over your comments= ASAP.

        --Tom


On Dec 30, 2013:1:46 PM, at 1:46 PM, Juergen Quittek <Quittek@neclab.eu> wrote:

> Hi Tom,
> I missed the fact that the deadline is already in the morning of today= . I thought I had the full day today for sending them. There are still some= comments that I planned to send this evening. I will send them asap and ho= pe they will be OK even if a few hours late.
> Thanks,
>    Juergen
>
>> -----Original Message-----
>> From: eman [mailto:eman-bounces@ietf.org] On Behalf Of Thomas Nadeau
>> Sent: Montag, 30. Dezember 2013 14:44
>> To: eman mailing list
>> Subject: Re: [eman] WG Last Call for draft-ietf-eman-energy-monito= ring-mib-
>> 08 and draft-ietf-eman-energy-aware-mib-13
>>
>>
>>       WG,
>>
>>       This concludes the WG LC on th= e MIBs. We have received just one set
>> of comments from the WG and one set of comments regarding the OID<= br> >> numbering. Would the document editors please address these and rep= ublish
>> the drafts ASAP so that we can proceed with progressing the drafts= ?
>>
>>       Cheers and Happy Holidays,
>>
>>       Tom
>>
>>
>>>
>>>      As agreed at the last WG meeting= , with the EMAN Framework
>> completing its WG LC the chairs would like to initiate a WG LC on = draft-ietf-
>> eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib= -13.
>> The WG LC will end on Dec 30 at 8AM EDT.
>>>
>>>      Thank you,
>>>
>>>      Nevil and Tom
>>>
>>>
>>> _______________________________________________
>>> eman mailing list
>>> eman@ietf.org
>>> https://www.ietf.org/mailman/listinfo/eman
>
>

--_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F41C364EXMBX23adutwent_-- From bclaise@cisco.com Wed Jan 22 02:28:46 2014 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 633331A01EB; Wed, 22 Jan 2014 02:28:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.036 X-Spam-Level: X-Spam-Status: No, score=-10.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ov3xDaFfxAyz; Wed, 22 Jan 2014 02:28:45 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id B025B1A041E; Wed, 22 Jan 2014 02:28:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=688; q=dns/txt; s=iport; t=1390386524; x=1391596124; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=Pn06Md1bWeiic0gx14nQ3W0XbDgCTHYP4d2QMxqhs30=; b=S5aAqRoNPd32xsOohM9PfgeSsMMbq2FuI03uPo7WC6yfsash5TtbXGNr OYY38GeOdbpgX4qj0td0Ay27uTD1RFVhqEx8EU6XSYgSPRF2ypYpv0crH vJrqIx7sRrPBv3VYxmFb4P3G5AOvZrpC2Ab5G68Vyi53sb/H5oAPTPaRb U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak8PAPGc31KQ/khL/2dsb2JhbABbgws4tRKHH4ERFnSCJQEBAQQBAQE1NgoRCxgJFg8JAwIBAgEVMAYBDAYCAQGIAQ3BSxMEjwOEOAEDmCKGR4tRgy47 X-IronPort-AV: E=Sophos;i="4.95,698,1384300800"; d="scan'208";a="4002805" Received: from ams-core-2.cisco.com ([144.254.72.75]) by aer-iport-1.cisco.com with ESMTP; 22 Jan 2014 10:28:43 +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 s0MAShvg028399; Wed, 22 Jan 2014 10:28:43 GMT Message-ID: <52DF9D5B.2060405@cisco.com> Date: Wed, 22 Jan 2014 11:28:43 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "Bert Wijnen (IETF)" , Thomas Nadeau , "MIB Doctors (E-mail)" , eman mailing list References: <8F88CD1C-C5F1-497D-8643-538E7D1C3BDF@lucidvision.com> <52DF8186.3020705@bwijnen.net> In-Reply-To: <52DF8186.3020705@bwijnen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [eman] [MIB-DOCTORS] MIB Doctor Review of draft-ietf-eman-energy-aware-mib-13 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 22 Jan 2014 10:28:46 -0000 On 22/01/2014 09:29, Bert Wijnen (IETF) wrote: > > > On 21/01/14 21:52, Thomas Nadeau wrote: >> 4) The EMAN WG and MIB Doctors consensus was to root all MIB >> modules under transmission, rather than under the single OID >> energyMIB. These modules still use the older approach, so please >> correct them. > > EMAN MIB Modules under "transmission" ???? > That sounds weird to me. I would think under mib-2 mib-2 is what's currently in the draft, like the ENTITY-MIB v4, RFC 6933. Regards, Benoit > > Bert > _______________________________________________ > MIB-DOCTORS mailing list > MIB-DOCTORS@ietf.org > https://www.ietf.org/mailman/listinfo/mib-doctors > From tnadeau@lucidvision.com Wed Jan 22 05:07:45 2014 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B6641A00F2; Wed, 22 Jan 2014 05:07:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CkaZ_k6N7tRm; Wed, 22 Jan 2014 05:07:44 -0800 (PST) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 69EFA1A00F8; Wed, 22 Jan 2014 05:07:44 -0800 (PST) Received: from [192.168.1.103] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 8D0B826C282C; Wed, 22 Jan 2014 08:07:43 -0500 (EST) References: <8F88CD1C-C5F1-497D-8643-538E7D1C3BDF@lucidvision.com> <52DF8186.3020705@bwijnen.net> Mime-Version: 1.0 (1.0) In-Reply-To: <52DF8186.3020705@bwijnen.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <3E6D350F-AB46-4992-A3E3-D2CBDCCD82EE@lucidvision.com> X-Mailer: iPad Mail (11B554a) From: "Thomas D. Nadeau" Date: Wed, 22 Jan 2014 08:07:43 -0500 To: "Bert Wijnen (IETF)" Cc: "MIB Doctors \(E-mail\)" , eman mailing list Subject: Re: [eman] [MIB-DOCTORS] MIB Doctor Review of draft-ietf-eman-energy-aware-mib-13 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 22 Jan 2014 13:07:45 -0000 That is a good catch Bert. You are right - its mib-2! --Tom > On Jan 22, 2014, at 3:29 AM, "Bert Wijnen (IETF)" w= rote: >=20 >=20 >=20 >> On 21/01/14 21:52, Thomas Nadeau wrote: >> 4) The EMAN WG and MIB Doctors consensus was to root all MIB modules u= nder transmission, rather than under the single OID energyMIB. These modules= still use the older approach, so please correct them. >=20 > EMAN MIB Modules under "transmission" ???? > That sounds weird to me. I would think under mib-2 >=20 > Bert >=20 From tnadeau@lucidvision.com Wed Jan 22 05:08:59 2014 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E7791A00F8; Wed, 22 Jan 2014 05:08:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cq7rAGOUW9Do; Wed, 22 Jan 2014 05:08:58 -0800 (PST) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 2198B1A00F2; Wed, 22 Jan 2014 05:08:58 -0800 (PST) Received: from [192.168.1.103] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 8F34A26C284A; Wed, 22 Jan 2014 08:08:57 -0500 (EST) References: <8F88CD1C-C5F1-497D-8643-538E7D1C3BDF@lucidvision.com> <52DF8186.3020705@bwijnen.net> <52DF9D5B.2060405@cisco.com> Mime-Version: 1.0 (1.0) In-Reply-To: <52DF9D5B.2060405@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPad Mail (11B554a) From: "Thomas D. Nadeau" Date: Wed, 22 Jan 2014 08:08:57 -0500 To: Benoit Claise Cc: "MIB Doctors \(E-mail\)" , eman mailing list , "Bert Wijnen \(IETF\)" Subject: Re: [eman] [MIB-DOCTORS] MIB Doctor Review of draft-ietf-eman-energy-aware-mib-13 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 22 Jan 2014 13:08:59 -0000 Yes mib-2 is correct. I was confused on that one. > On Jan 22, 2014, at 5:28 AM, Benoit Claise wrote: >=20 >> On 22/01/2014 09:29, Bert Wijnen (IETF) wrote: >>=20 >>=20 >>> On 21/01/14 21:52, Thomas Nadeau wrote: >>> 4) The EMAN WG and MIB Doctors consensus was to root all MIB modules u= nder transmission, rather than under the single OID energyMIB. These modules= still use the older approach, so please correct them. >>=20 >> EMAN MIB Modules under "transmission" ???? >> That sounds weird to me. I would think under mib-2 > mib-2 is what's currently in the draft, like the ENTITY-MIB v4, RFC 6933. >=20 > Regards, Benoit >>=20 >> Bert >> _______________________________________________ >> MIB-DOCTORS mailing list >> MIB-DOCTORS@ietf.org >> https://www.ietf.org/mailman/listinfo/mib-doctors >=20 >=20 From bertietf@bwijnen.net Wed Jan 22 00:30:03 2014 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CC3B1A037A; Wed, 22 Jan 2014 00:30:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TW36SXbqD2yJ; Wed, 22 Jan 2014 00:30:01 -0800 (PST) Received: from koko.ripe.net (koko.ripe.net [193.0.19.72]) by ietfa.amsl.com (Postfix) with ESMTP id 41E9A1A02A4; Wed, 22 Jan 2014 00:30:00 -0800 (PST) Received: from nene.ripe.net ([193.0.23.10]) by koko.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1W5tCA-0000Zm-9b; Wed, 22 Jan 2014 09:29:59 +0100 Received: from kitten.ipv6.ripe.net ([2001:67c:2e8:1::c100:1f0] helo=Macintosh.local) by nene.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1W5tCA-0007VH-6w; Wed, 22 Jan 2014 09:29:58 +0100 Message-ID: <52DF8186.3020705@bwijnen.net> Date: Wed, 22 Jan 2014 09:29:58 +0100 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Thomas Nadeau , "MIB Doctors (E-mail)" , eman mailing list References: <8F88CD1C-C5F1-497D-8643-538E7D1C3BDF@lucidvision.com> In-Reply-To: <8F88CD1C-C5F1-497D-8643-538E7D1C3BDF@lucidvision.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4e17f817ccb232e04e9c4c2328ec5f9a3 X-Mailman-Approved-At: Wed, 22 Jan 2014 06:15:49 -0800 Subject: Re: [eman] [MIB-DOCTORS] MIB Doctor Review of draft-ietf-eman-energy-aware-mib-13 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 22 Jan 2014 08:30:03 -0000 On 21/01/14 21:52, Thomas Nadeau wrote: > 4) The EMAN WG and MIB Doctors consensus was to root all MIB modules under transmission, rather than under the single OID energyMIB. These modules still use the older approach, so please correct them. EMAN MIB Modules under "transmission" ???? That sounds weird to me. I would think under mib-2 Bert From tnadeau@lucidvision.com Thu Jan 23 14:39:19 2014 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16F2C1A0462; Thu, 23 Jan 2014 14:39:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.433 X-Spam-Level: * X-Spam-Status: No, score=1.433 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FILL_THIS_FORM=0.001, FILL_THIS_FORM_FRAUD_PHISH=0.334, FM_ASCII_ART_SPACINGc=0.833, RP_MATCHES_RCVD=-0.535] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EUMCrKlRGyk6; Thu, 23 Jan 2014 14:39:04 -0800 (PST) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 408181A0442; Thu, 23 Jan 2014 14:39:03 -0800 (PST) Received: from [192.168.1.110] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id EEDEC26C631B; Thu, 23 Jan 2014 17:39:01 -0500 (EST) From: Thomas Nadeau Content-Type: multipart/signed; boundary="Apple-Mail=_1FF83778-F8C8-4C81-8F8F-5BFE8EF6EA6D"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Thu, 23 Jan 2014 17:39:01 -0500 Message-Id: To: draft-ietf-eman-energy-monitoring-mib@tools.ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) X-Mailer: Apple Mail (2.1827) Cc: "MIB Doctors \(E-mail\)" , list eman mailing Subject: [eman] MIB Doctor Review of draft-ietf-eman-energy-monitoring-mib X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 23 Jan 2014 22:39:19 -0000 --Apple-Mail=_1FF83778-F8C8-4C81-8F8F-5BFE8EF6EA6D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I reviewed this draft as part of the MIB Doctor review on = Thursday, January 23, 2014. My comments inline begin with TOM: General Comments on the draft: 1) There are a number of id-nits warnings and one major error that = will cause it to not pass: ** Obsolete normative reference: RFC 4133 (Obsoleted by RFC 6933)=20= 2) In general, please go through the MIB modules and verify that the = Integer32 values are indeed ok to be negative values or change them to = Unsigned. For example, there are many instances where you used Integer32 = for things like watts or amps where negative values do not make sense, = to me at least.=20 3) There are a number of warnings in the smilint run. Please check = and correct these.=20 IANA-POWERSTATE-SET-MIB: [server:libsmi-0.4.8/mibs/ietf] tnadeau% smilint -l 6 -i namelength-32 = ./SNMPv2-TC ./SNMPv2-SMI ./SNMPv2-CONF ./SNMP-FRAMEWORK-MIB = ./INET-ADDRESS-MIB ./ENTITY-MIB ./UUID-TC-MIB ./IANA-ENERGY-RELATION-MIB = ./IANA-POWERSTATE-SET-MIB ./SNMPv2-SMI:1: [5] {module-already-loaded} warning: module `SNMPv2-SMI' = is already loaded, aborting parser on this file ./SNMPv2-CONF:4: [2] {import-failed} identifier `ObjectSyntax' cannot be = imported from module `SNMPv2-SMI' ./SNMP-FRAMEWORK-MIB:275: [5] {integer-misuse} warning: use Integer32 = instead of INTEGER in SMIv2 ./SNMP-FRAMEWORK-MIB:349: [5] {integer-misuse} warning: use Integer32 = instead of INTEGER in SMIv2 ./SNMP-FRAMEWORK-MIB:458: [5] {identifier-case-match} warning: = identifier `snmpEngineID' differs from `SnmpEngineID' only in case ./SNMP-FRAMEWORK-MIB:91: [6] {previous-definition} info: previous = definition of `SnmpEngineID' ./SNMP-FRAMEWORK-MIB:471: [5] {integer-misuse} warning: use Integer32 = instead of INTEGER in SMIv2 ./SNMP-FRAMEWORK-MIB:481: [5] {integer-misuse} warning: use Integer32 = instead of INTEGER in SMIv2 ./SNMP-FRAMEWORK-MIB:496: [5] {integer-misuse} warning: use Integer32 = instead of INTEGER in SMIv2 ./IANA-ENERGY-RELATION-MIB:38: [1] {object-identifier-unknown} unknown = object identifier label `energyMIB' ./IANA-ENERGY-RELATION-MIB:3: [5] {import-unused} warning: identifier = `mib-2' imported from module `SNMPv2-SMI' is never used ./IANA-POWERSTATE-SET-MIB:39: [1] {object-identifier-unknown} unknown = object identifier label `energyMIB' ./IANA-POWERSTATE-SET-MIB:4: [5] {import-unused} warning: identifier = `mib-2' imported from module `SNMPv2-SMI' is never used ENERGY-OBJECT-MIB: [server:libsmi-0.4.8/mibs/ietf] tnadeau% smilint -l 6 -i namelength-32 = ./SNMPv2-TC ./SNMPv2-SMI ./SNMPv2-CONF ./SNMP-FRAMEWORK-MIB = ./INET-ADDRESS-MIB ./ENTITY-MIB ./UUID-TC-MIB ./IANA-ENERGY-RELATION-MIB = ./IANA-POWERSTATE-SET-MIB ./ENERGY-OBJECT-MIB ./SNMPv2-SMI:1: [5] {module-already-loaded} warning: module `SNMPv2-SMI' = is already loaded, aborting parser on this file ./SNMPv2-CONF:4: [2] {import-failed} identifier `ObjectSyntax' cannot be = imported from module `SNMPv2-SMI' ./SNMP-FRAMEWORK-MIB:275: [5] {integer-misuse} warning: use Integer32 = instead of INTEGER in SMIv2 ./SNMP-FRAMEWORK-MIB:349: [5] {integer-misuse} warning: use Integer32 = instead of INTEGER in SMIv2 ./SNMP-FRAMEWORK-MIB:458: [5] {identifier-case-match} warning: = identifier `snmpEngineID' differs from `SnmpEngineID' only in case ./SNMP-FRAMEWORK-MIB:91: [6] {previous-definition} info: previous = definition of `SnmpEngineID' ./SNMP-FRAMEWORK-MIB:471: [5] {integer-misuse} warning: use Integer32 = instead of INTEGER in SMIv2 ./SNMP-FRAMEWORK-MIB:481: [5] {integer-misuse} warning: use Integer32 = instead of INTEGER in SMIv2 ./SNMP-FRAMEWORK-MIB:496: [5] {integer-misuse} warning: use Integer32 = instead of INTEGER in SMIv2 ./IANA-ENERGY-RELATION-MIB:38: [1] {object-identifier-unknown} unknown = object identifier label `energyMIB' ./IANA-ENERGY-RELATION-MIB:3: [5] {import-unused} warning: identifier = `mib-2' imported from module `SNMPv2-SMI' is never used ./IANA-POWERSTATE-SET-MIB:39: [1] {object-identifier-unknown} unknown = object identifier label `energyMIB' ./IANA-POWERSTATE-SET-MIB:4: [5] {import-unused} warning: identifier = `mib-2' imported from module `SNMPv2-SMI' is never used ./ENERGY-OBJECT-MIB:111: [1] {object-identifier-unknown} unknown object = identifier label `energyMIB' ./ENERGY-OBJECT-MIB:620: [5] {index-element-accessible} warning: index = element `eoEnergyParametersIndex' of row `eoEnergyParametersEntry' = should be not-accessible in SMIv2 MIB ./ENERGY-OBJECT-MIB:7: [5] {import-unused} warning: identifier `mib-2' = imported from module `SNMPv2-SMI' is never used ./ENERGY-OBJECT-MIB:10: [5] {import-unused} warning: identifier = `DisplayString' imported from module `SNMPv2-TC' is never used [server:libsmi-0.4.8/mibs/ietf] tnadeau%=20 POWER-ATTRIBTUES-MIB: /ENERGY-OBJECT-MIB:111: [1] {object-identifier-unknown} unknown object = identifier label `energyMIB' ./ENERGY-OBJECT-MIB:620: [5] {index-element-accessible} warning: index = element `eoEnergyParametersIndex' of row `eoEnergyParametersEntry' = should be not-accessible in SMIv2 MIB ./ENERGY-OBJECT-MIB:7: [5] {import-unused} warning: identifier `mib-2' = imported from module `SNMPv2-SMI' is never used ./ENERGY-OBJECT-MIB:10: [5] {import-unused} warning: identifier = `DisplayString' imported from module `SNMPv2-TC' is never used ./POWER-ATTRIBTUES-MIB:111: [1] {object-identifier-unknown} unknown = object identifier label `energyMIB' ./POWER-ATTRIBTUES-MIB:6: [5] {import-unused} warning: identifier = `mib-2' imported from module `SNMPv2-SMI' is never used ./POWER-ATTRIBTUES-MIB:14: [5] {import-unused} warning: identifier = `OwnerString' imported from module `RMON-MIB' is never used [server:libsmi-0.4.8/mibs/ietf] tnadeau%=20 2) The modules still assume they are under the energyMIB common = OID; please add notes to the RFC editor/IANA for the proper assignment. Network Working Group M. Chandramouli=20 B. Claise=20 Internet-Draft Cisco Systems, Inc.=20 Intended Status: Standards Track B. Schoening=20 Expires: June 13, 2014 Independent Consultant=20 J. Quittek=20 T. Dietz=20 NEC Europe Ltd.=20 December 13, 2013=20 =20 =20 Power and Energy Monitoring MIB=20 draft-ietf-eman-energy-monitoring-mib-08=20 Status of this Memo=20 This Internet-Draft is submitted to IETF in full conformance=20 with the provisions of BCP 78 and BCP 79. =20 =20 Internet-Drafts are working documents of the Internet=20 Engineering Task Force (IETF), its areas, and its working=20 groups. Note that other groups may also distribute working=20 documents as Internet-Drafts. =20 =20 Internet-Drafts are draft documents valid for a maximum of six=20= months and may be updated, replaced, or obsoleted by other=20 documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as =20 "work in progress." =20 =20 The list of current Internet-Drafts can be accessed at=20 http://www.ietf.org/ietf/1id-abstracts.txt =20 =20 The list of Internet-Draft Shadow Directories can be accessed =20= at http://www.ietf.org/shadow.html =20 =20 This Internet-Draft will expire on June 2014. = =20 =20 Expires June 13, 2014 [Page 1]=20= =0C Internet-Draft December 2013=20= =20 =20 Copyright Notice=20 =20 Copyright (c) 2013 IETF Trust and the persons identified as the=20= document authors. All rights reserved.=20 =20 This document is subject to BCP 78 and the IETF Trust's Legal=20 Provisions Relating to IETF Documents=20 (http://trustee.ietf.org/license-info) in effect on the date of=20= publication of this document. Please review these documents=20 carefully, as they describe your rights and restrictions with=20 respect to this document. Code Components extracted from this=20= document must include Simplified BSD License text as described=20= in Section 4.e of the Trust Legal Provisions and are provided=20 without warranty as described in the Simplified BSD License.=20 =20 =20 Abstract=20 This document defines a subset of the Management Information=20 Base (MIB) for power and energy monitoring of devices. =20 =20 Conventions used in this document=20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL=20 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED"=20= "MAY", and "OPTIONAL" in this document are to be interpreted as=20= described in RFC 2119 [RFC2119].=20 =20 =20 =20 Table of Contents=20 =20 1. Introduction............................................. 3=20= 2. The Internet-Standard Management Framework............... 4=20= 3. Use Cases................................................ 4=20= 4. Terminology.............................................. 4=20= 5. Architecture Concepts Applied to the MIB Modules......... 5=20= 5.1. Energy Object Information............................. 12=20= 5.2. Power State........................................... 13=20= 5.2.1. Power State Set................................14=20= 5.3. Energy Object Usage Information....................... 14=20= 5.4. Optional Power Usage Attributes....................... 15=20= 5.5. Optional Energy Measurement........................... 15=20= 5.6. Fault Management...................................... 19=20= 6. Discovery............................................... 20=20= 7. Link with the other IETF MIBs........................... 21=20= =20 =20 Expires June 13, 2014 [Page 2]=20= =20 =0C Internet-Draft December 2013=20= =20 7.1. Link with the ENTITY-MIB and the ENTITY-SENSOR MIB..21=20= 7.2. Link with the ENTITY-STATE MIB......................22=20= 7.3. Link with the POWER-OVER-ETHERNET MIB...............22=20= 7.4. Link with the UPS MIB...............................23=20= 7.5. Link with the LLDP and LLDP-MED MIBs................24=20= 8. Implementation Scenario................................. 25=20= 9. Structure of the MIB.................................... 27=20= 10. MIB Definitions........................................ 28=20= 11. Implementation Status.................................. 69=20= 11.1. SNMP Research........................................ 70=20= 11.2. Cisco Systems........................................ 70=20= 12. Security Considerations................................ 71=20= 13. IANA Considerations.................................... 72=20= 14. Contributors........................................... 73=20= 12. Acknowledgment......................................... 73=20= 13. References............................................. 74=20= 13.1. Normative References...............................74=20= 13.2. Informative References.............................75=20= =20 =20 =20 1. Introduction=20 This document defines a subset of the Management Information=20 Base (MIB) for use in energy management of devices within or=20 connected to communication networks. The MIB modules in this=20 document are designed to provide a model for energy management,=20= which includes monitoring for Power State and energy consumption=20= of networked elements. This MIB takes into account the Energy=20= Management Framework [EMAN-FMWK], which in turn, is based on the=20= Requirements for Energy Management [RFC6988].=20 =20 Energy management is applicable to devices in communication=20 networks. Target devices for this specification include (but are=20= not limited to): routers, switches, Power over Ethernet (PoE)=20 endpoints, protocol gateways for building management systems,=20 intelligent meters, home energy gateways, hosts and servers,=20 sensor proxies, etc. Target devices and the use cases for Energy=20= Management are discussed in Energy Management Applicability=20 Statement [EMAN-AS].=20 =20 Where applicable, device monitoring extends to the individual=20 components of the device and to any attached dependent devices.=20= For example: A device can contain components that are=20 independent from a power-state point of view, such as line=20 cards, processor cards, hard drives. A device can also have=20 =20 =20 Expires June 13, 2014 [Page 3]=20= =20 =0C Internet-Draft December 2013=20= =20 dependent attached devices, such as a switch with PoE endpoints=20= or a power distribution unit with attached endpoints.=20 =20 =20 =20 2. The Internet-Standard Management Framework=20 For a detailed overview of the documents that describe the=20 current Internet-Standard Management Framework, please refer to=20= section 7 of RFC 3410 [RFC3410].=20 TOM: Generally speaking, I prefer to just include [RFC3410] here. = Repeating it is...well, redundant. =20 Managed objects are accessed via a virtual information store,=20 termed the Management Information Base or MIB. MIB objects are=20= generally accessed through the Simple Network Management=20 Protocol (SNMP). Objects in the MIB are defined using the=20 mechanisms defined in the Structure of Management Information=20 (SMI). This memo specifies MIB modules that are compliant to=20 SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58,=20= RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580].=20 =20 =20 3. Use Cases=20 Requirements for power and energy monitoring for networking=20 devices are specified in [RFC6988]. The requirements in=20 [RFC6988] cover devices typically found in communications=20 networks, such as switches, routers, and various connected=20 endpoints. For a power monitoring architecture to be useful, it=20= should also apply to facility meters, power distribution units,=20= gateway proxies for commercial building control, home automation=20= devices, and devices that interface with the utility and/or=20 smart grid. Accordingly, the scope of the MIB modules in this=20= document is broader than that specified in [RFC6988]. Several=20 use cases for Energy Management have been identified in the=20 "Energy Management (EMAN) Applicability Statement" [EMAN-AS]. An=20= illustrative example scenario is presented in Section 8. =20 =20 =20 4. Terminology=20 TOM: Rather than just repeating the terms here, where you typically show = their definition, I suggest just refering to the framework and cutting = the section down unless something is newly defined here. Please refer to [EMAN-FMWK] for the definitions of the=20 following terminology used in this draft. =20 =20 Energy Management =20 =20 Energy Management System (EnMS) =20 =20 =20 =20 Expires June 13, 2014 [Page 4]=20= =20 =0C Internet-Draft December 2013=20= =20 Energy Monitoring =20 =20 Energy Control =20 =20 electrical equipment =20 =20 non-electrical equipment (mechanical equipment) =20 =20 device =20 =20 component =20 =20 power inlet =20 =20 power outlet =20 =20 energy =20 =20 power =20 =20 demand =20 =20 provide energy =20 =20 receive energy =20 =20 meter (energy meter) =20 =20 battery =20 =20 Power Interface =20 =20 Nameplate Power =20 =20 Power Attributes =20 =20 Power Quality =20 =20 Power State =20 =20 Power State Set =20 =20 =20 5. Architecture Concepts Applied to the MIB Modules=20 This section describes the concepts specified in the Energy=20 Management Framework [EMAN-FMWK] that pertain to power usage,=20 with specific information related to the MIB module specified in=20= =20 =20 Expires June 13, 2014 [Page 5]=20= =20 =0C Internet-Draft December 2013=20= =20 this document. This subsection maps to the different concepts=20= developed in the Energy Management Framework [EMAN-FMWK].=20 =20 The Energy Monitoring MIB has 2 independent MIB modules ENERGY- OBJECT-MIB and POWER-ATTRIBUTES-MIB. The first MIB module=20 ENERGY-OBJECT-MIB is focused on measurement of power and energy.=20= The second MIB module POWER-ATTRIBUTES-MIB is focused on Power=20= Attributes measurements for Energy Objects.=20 =20 Devices and their sub-components can be modeled using the=20 containment tree of the ENTITY-MIB [RFC6933]. In addition,=20 ENERGY-OBJECT-CONTEXT-MIB MIB module [EMAN-AWARE-MIB] provides a=20= framework for modeling the relationship between Energy Objects.=20= It is conceivable to have implementations of ENERGY-OBJECT- CONTEXT-MIB and ENERGY-OBJECT-MIB for modeling the relationships=20= between Energy Objects and also monitoring the Energy=20 consumption of those Energy Objects. In some situations, it is=20= possible to have implementation of ENERGY-OBJECT-MIB along=20 ENTITY-MIB V4 [RFC6933] with the Module compliance of=20 entity4CRCompliance. This compliance requires that the=20 following 3 MIB objects from ENTITY-MIB [RFC6933]=20 (entPhysicalIndex, entPhysicalName and entPhysicalUUID) MUST be=20= implemented.=20 =20 The ENERGY-OBJECT-MIB MIB module consists of five tables. =20 The first table is the eoMeterCapabilitiesTable. It indicates=20= the instrumentation available for each Energy Object. Thus, the=20= entries in this table indicate to the EnMS which other tables=20 from the ENERGY-OBJECT-MIB and POWER-ATTRIBUTES-MIB are=20 available for each Energy Object. The eoMeterCapabilitiesTable=20= is indexed by entPhysicalIndex [RFC6933].=20 =20 The second table is the eoPowerTable. It returns the power=20 consumption of each Energy Object, as well as the units, sign,=20= measurement accuracy, and related objects. The eoPowerTable is=20= indexed by entPhysicalIndex.=20 =20 The third table is the eoPowerStateTable. For each Energy=20 Object, it provides information and statistics about the=20 supported Power States. The eoPowerStateTable is indexed by=20 entPhysicalIndex and eoPowerStateIndex.=20 =20 The fourth table is the eoEnergyParametersTable. The entries in=20= this table configure the parameters of energy and demand=20 measurement collection. This table is indexed by=20 eoEnergyParametersIndex. =20 =20 =20 =20 Expires June 13, 2014 [Page 6]=20= =20 =0C Internet-Draft December 2013=20= =20 The fifth table is the eoEnergyTable. The entries in this table=20= provide the log the energy and demand information. This table=20= is indexed by eoEnergyParametersIndex.=20 =20 =20 eoMeterCapabilitiesTable(1)=20 |=20 +---eoMeterCapabilitiesEntry(1)[entPhysicalIndex] =20 | |=20 | +---r-n BITS eoMeterCapability=20 | =20 =20 eoPowerTable(2)=20 |=20 +---eoPowerEntry(1) [entPhysicalIndex]=20 | | =20 | +---r-n Integer32 eoPower(1)=20 | +-- r-n Integer32 eoPowerNamePlate(2)=20 | +-- r-n UnitMultiplier eoPowerUnitMultiplier(3)=20 | +-- r-n Integer32 eoPowerAccuracy(4)=20 | +-- r-n INTEGER eoMeasurementCaliber(5)=20 | +-- r-n INTEGER eoPowerCurrentType(6)=20 | +-- r-n INTEGER eoPowerOrigin(7)=20 | +-- rwn IANAPowerStateSet eoPowerAdminState(8)=20 | +-- r-n IANAPowerStateSet eoPowerOperState(9)=20 | +-- r-n OwnerString eoPowerStateEnterReason(10)=20 | =20 | =20 +---eoPowerStateTable(3)=20 | +--eoPowerStateEntry(1)=20 | | [entPhysicalIndex, eoPowerStateIndex] =20 | |=20 | +-- --n IANAPowerStateSet eoPowerStateIndex(1)=20 | +-- r-n Interger32 eoPowerStateMaxPower(2)=20 | +-- r-n UnitMultiplier =20 | eoPowerStatePowerUnitMultiplier(3)=20 | +-- r-n TimeTicks eoPowerStateTotalTime(4)=20 | +-- r-n Counter32 eoPowerStateEnterCount(5)=20 |=20 =20 +eoEnergyParametersTable(4)=20 +---eoEnergyParametersEntry(1) [eoEnergyParametersIndex]=20 | =20 | +-- --n PhysicalIndex eoEnergyObjectIndex(1)=20 | + r-n Integer32 eoEnergyParametersIndex(2) =20= | +-- r-n TimeInterval eoEnergyParametersIntervalLength(3)=20= | +-- r-n Integer32 eoEnergyParametersIntervalNumber(4)=20= | +-- r-n Integer32 eoEnergyParametersIntervalMode(5)=20 =20 =20 Expires June 13, 2014 [Page 7]=20= =20 =0C Internet-Draft December 2013=20= =20 | +-- r-n TimeInterval eoEnergyParametersIntervalWindow(6)=20= | +-- r-n Integer32 eoEnergyParametersSampleRate(7)=20 | +-- r-n RowStatus eoEnergyParametersStatus(8)=20 | =20 +eoEnergyTable(5)=20 +---eoEnergyEntry(1) =20 | [eoEnergyParametersIndex,eoEnergyCollectionStartTime]=20 | =20 | +-- r-n TimeTicks eoEnergyCollectionStartTime(1)=20 | +-- r-n Integer32 eoEnergyConsumed(2)=20 | +-- r-n Integer32 eoEnergyProvided(3) =20 | +-- r-n Integer32 eoEnergyStored(4)=20 | +-- r-n UnitMultiplier eoEnergyUnitMultiplier(5)=20 | +-- r-n Integer32 eoEnergyAccuracy(6)=20 | +-- r-n Integer32 eoEnergyMaxConsumed(7)=20 | +-- r-n Integer32 eoEnergyMaxProduced(8)=20 | +-- r-n TimeTicks eoEnergyDiscontinuityTime(9)=20 =20 =20 The powerAttributesMIB consists of four tables.=20 eoACPwrAttributesTable is indexed by entPhysicalIndex.=20 eoACPwrAttributesPhaseTable is indexed by entPhysicalIndex and=20= eoPhaseIndex. eoACPwrAttributesWyePhaseTable and=20 eoACPwrAttributesDelPhaseTable are indexed by entPhysicalIndex=20= and eoPhaseIndex.=20 =20 eoACPwrAttributesTable(1)=20 |=20 +---eoACPwrAttributesEntry(1) [ entPhysicalIndex]=20 | |=20 | +---r-n INTEGER eoACPwrAttributesConfiguration(1)=20 | +-- r-n Interger32 eoACPwrAttributesAvgVoltage(2)=20 | +-- r-n Integer32 eoACPwrAttributesAvgCurrent(3)=20 | +-- r-n Integer32 eoACPwrAttributesFrequency(4)=20 | +-- r-n UnitMultiplier =20 | eoACPwrAttributesPowerUnitMultiplier(5)=20 | +-- r-n Integer32 eoACPwrAttributesPowerAccuracy(6)=20 | +-- r-n Interger32 =20 | eoACPwrAttributesTotalActivePower(7)=20 | +-- r-n Integer32 =20 | eoACPwrAttributesTotalReactivePower(8)=20 | +-- r-n Integer32 =20 | eoACPwrAttributesTotalApparentPower(9)=20 | +-- r-n Integer32 =20 | eoACPwrAttributesTotalPowerFactor(10)=20 | +-- r-n Integer32 eoACPwrAttributesThdAmpheres(11)=20 | =20 +eoACPwrAttributesPhaseTable(2)=20 =20 =20 Expires June 13, 2014 [Page 8]=20= =20 =0C Internet-Draft December 2013=20= =20 +---EoACPwrAttributesPhaseEntry(1)=20 | | [ entPhysicalIndex, eoPhaseIndex]=20 | |=20 | +-- r-n Integer32 eoPhaseIndex(1)=20 | +-- r-n Integer32 =20 | | eoACPwrAttributesPhaseAvgCurrent(2)=20 | +-- r-n Integer32 =20 | | eoACPwrAttributesPhaseActivePower(3)=20 | +-- r-n Integer32 =20 | | eoACPwrAttributesPhaseReactivePower(4)=20 | +-- r-n Integer32 =20 | | eoACPwrAttributesPhaseApparentPower(5)=20 | +-- r-n Integer32 =20 | | eoACPwrAttributesPhasePowerFactor(6)=20 | +-- r-n Integer32 =20 | | eoACPwrAttributesPhaseImpedance(7)=20 | |=20 +eoACPwrAttributesDelPhaseTable(3)=20 +-- eoACPwrAttributesDelPhaseEntry(1) =20 | | [entPhysicalIndex, eoPhaseIndex]=20 | | =20 | +-- r-n Integer32=20 | | eoACPwrAttributesDelPhaseToNextPhaseVoltage(1)=20 | +-- r-n Integer32 =20 | | eoACPwrAttributesDelThdPhaseToNextPhaseVoltage(2)=20 | +-- r-n Integer32 =20 eoACPwrAttributesDelThdCurrent(3)=20 | |=20 +eoACPwrAttributesWyePhaseTable(4)=20 +-- eoACPwrAttributesWyePhaseEntry(1) =20 | | [entPhysicalIndex, eoPhaseIndex]=20 | | =20 | +-- r-n Integer32 =20 | | eoACPwrAttributesWyePhaseToNeutralVoltage(1)=20 | +-- r-n Integer32 =20 | | eoACPwrAttributesWyePhaseCurrent(2)=20 | +-- r-n Integer32=20 | | eoACPwrAttributesWyeThdPhaseToNeutralVoltage(3)=20 | .=20 =20 =20 A UML representation of the MIB objects in the two MIB modules=20= ENERGY-OBJECT-MIB and POWER-ATTRIBUTES-MIB are presented. =20 =20 =20 +-------------------------+ =20 | Energy Object State | =20 | ----------------------- | =20 =20 =20 Expires June 13, 2014 [Page 9]=20= =20 =0C Internet-Draft December 2013=20= =20 | eoPowerAdminState | =20 | eoPowerOperState | =20 | eoPowerStateEnterReason | =20 +-------------------------+=20 |=20 |=20 v =20 +-----------------------+=20 |---> | Energy Object ID (*) |=20 | | --------------------- |=20 | | entPhysicalIndex |=20 | | entPhysicalName |=20 | | entPhysicalUUID |=20 | +-----------------------+=20 | =20 | +-----------------------------+=20 |---- | Energy Object Measurement |=20 | | --------------------------- |=20 | | eoPower |=20 | | eoPowerUnitMultiplier |=20 | | eoPowerAccuracy |=20 | +-----------------------------+=20 | =20 | +---------------------------+=20 |---- | Energy Object Attributes |=20 | | ------------------------- |=20 | | eoPowerNamePlate |=20 | | eoPowerMeasurementCaliber |=20 | | eoPowerCurrentType |=20 | | eoPowerOrigin |=20 | +---------------------------+=20 | =20 | +---------------------------------+ =20 |---- | Energy Object State Statistics | =20 |-------------------------------- | =20 | eoPowerStateMaxPower | =20 | eoPowerStatePowerUnitMultiplier |=20 | eoPowerStateTotalTime |=20 | eoPowerStateEnterCount | =20 +---------------------------------+ =20 =20 Figure 1:UML diagram for energyObjectMIB =20 =20 (*) Compliance with the ENERGY-OBJECT-CONTEXT-MIB=20 =20 =20 +----------------------------------+ =20 | Energy ParametersTable |=20 =20 =20 Expires June 13, 2014 [Page 10]=20= =20 =0C Internet-Draft December 2013=20= =20 | -------------------------------- | =20 | eoEnergyObjectIndex |=20 | eoEnergyParametersIndex |=20 | eoEnergyParametersIntervalLength |=20 | eoEnergyParametersIntervalNumber |=20 | eoEnergyParametersIntervalMode |=20 | eoEnergyParametersIntervalWindow |=20 | eoEnergyParametersSampleRate |=20 | eoEnergyParametersStatus | =20 +----------------------------------+ =20 |=20 V =20 +----------------------------------+ =20 | Energy Table | = =20 | -------------------------------- | = =20 | eoEnergyCollectionStartTime | = =20 | eoEnergyConsumed |=20 | eoEnergyProvided |=20 | eoEnergyStored |=20 | eoEnergyUnitMultiplier |=20 | eoEnergyAccuracy | =20 | eoEnergyMaxConsumed |=20 | eoEnergyMaxProduced | =20 | eoDiscontinuityTime | =20 +----------------------------------+ =20 =20 =20 =20 =20 +-----------------------+=20 |---> | Energy Object ID (*) |=20 | | --------------------- |=20 | | entPhysicalIndex |=20 | | entPhysicalName |=20 | | entPhysicalUUID |=20 | +-----------------------+=20 | =20 | +--------------------------------------+ =20 |---- | Power Attributes | =20 | | ------------------------------------ | =20 | | eoACPwrAttributesConfiguration |=20 | | eoACPwrAttributesAvgVoltage |=20 | | eoACPwrAttributesAvgCurrent |=20 | | eoACPwrAttributesFrequency |=20 | | eoACPwrAttributesPowerUnitMultiplier |=20 | | eoACPwrAttributesPowerAccuracy |=20 | | eoACPwrAttributesTotalActivePower |=20 | | eoACPwrAttributesTotalReactivePower |=20 =20 =20 Expires June 13, 2014 [Page 11]=20= =20 =0C Internet-Draft December 2013=20= =20 | | eoACPwrAttributesTotalApparentPower |=20 | | eoACPwrAttributesTotalPowerFactor | =20 | | eoACPwrAttributesThdAmpheres |=20 | +--------------------------------------+ =20 | =20 | =20 | +--------------------------------------+=20 |---- | Power Phase Attributes | =20 | | ------------------------------------ |=20 | | eoPhaseIndex |=20 | | eoACPwrAttributesPhaseAvgCurrent |=20 | | eoACPwrAttributesPhaseActivePower |=20 | | eoACPwrAttributesPhaseReactivePower | =20 | | eoACPwrAttributesPhaseApparentPower | =20 | | eoACPwrAttributesPhasePowerFactor |=20 | | eoACPwrAttributesPhaseImpedance |=20 | +--------------------------------------+ =20 | =20 | =20 | +------------------------------------------------+=20 |---- | AC Input DEL Configuration |=20 | | ---------------------------------------------- |=20 | | eoACPwrAttributesDelPhaseToNextPhaseVoltage |=20 | | eoACPwrAttributesDelThdPhaseToNextPhaseVoltage |=20 | | eoACPwrAttributesDelThdCurrent |=20 | +------------------------------------------------+ =20 | =20 |=20 | +----------------------------------------------+ =20 |---- | AC Input WYE Configuration |=20 | -------------------------------------------- |=20 | eoACPwrAttributesWyePhaseToNeutralVoltage |=20 | eoACPwrAttributesWyePhaseCurrent |=20 | eoACPwrAttributesWyeThdPhaseToNeutralVoltage |=20 +----------------------------------------------+ =20 =20 Figure 2: UML diagram for the powerAttributesMIB =20 =20 (*) Compliance with the ENERGY-OBJECT-CONTEXT-MIB=20 =20 5.1. Energy Object Information=20 The Energy Object identity information is specified in the=20 ENERGY-OBJECT-CONTEXT-MIB MIB module [EMAN-AWARE-MIB] primary=20 table, i.e. the eoTable. In this table, the context of the=20 Energy Object such as domain, role description, importance are=20= specified. In addition, the ENERGY-OBJECT-CONTEXT-MIB module=20 =20 =20 Expires June 13, 2014 [Page 12]=20= =20 =0C Internet-Draft December 2013=20= =20 specifies the relationship between Energy Objects. There are=20 several possible relationships between Energy Objects such as=20 meteredBy, metering, poweredBy, powering, aggregatedBy, and=20 aggregating as defined in the IANA-ENERGY-RELATION-MIB MIB=20 module [EMAN-AWARE-MIB]. =20 =20 5.2. Power State=20 An Energy Object may have energy conservation modes called Power=20= States. Between the ON and OFF states of a device, there can be=20= several intermediate energy saving modes. Those energy saving=20= modes are called as Power States. =20 =20 Power States, which represent universal states of power=20 management of an Energy Object, are specified by the=20 eoPowerState MIB object. The actual Power State is specified by=20= the eoPowerOperState MIB object, while the eoPowerAdminState MIB=20= object specifies the Power State requested for the Energy=20 Object. The difference between the values of eoPowerOperState=20= and eoPowerAdminState can be attributed that the Energy Object=20= is busy transitioning from eoPowerAdminState into the=20 eoPowerOperState, at which point it will update the content of=20= eoPowerOperState. In addition, the possible reason for change=20= in Power State is reported in eoPowerStateEnterReason. =20 Regarding eoPowerStateEnterReason, management stations and=20 Energy Objects should support any format of the owner string=20 dictated by the local policy of the organization. It is=20 suggested that this name contain at least the reason for the=20 transition change, and one or more of the following: IP address,=20= management station name, network manager's name, location, or=20 phone number.=20 =20 The MIB objects eoPowerOperState, eoPowerAdminState , and=20 eoPowerStateEnterReason are contained in the eoPowerTable MIB=20 table.=20 =20 The eoPowerStateTable table enumerates the maximum power usage=20= in watts, for every single supported Power State of each Power=20= State Set supported by the Energy Object. In addition,=20 PowerStateTable provides additional statistics:=20 eoPowerStateEnterCount, the number of times an entity has=20 visited a particular Power State, and eoPowerStateTotalTime, the=20= total time spent in a particular Power State of an Energy=20 Object. =20 =20 =20 =20 =20 Expires June 13, 2014 [Page 13]=20= =20 =0C Internet-Draft December 2013=20= =20 5.2.1. Power State Set=20 There are several standards and implementations of Power State=20= Sets. An Energy Object can support one or multiple Power State=20= Set implementation(s) concurrently. =20 =20 There are currently three Power State Sets advocated: =20 =20 IEEE1621 - [IEEE1621]=20 DMTF - [DMTF]=20 EMAN - [EMAN-FMWK]=20 =20 The Power State Sets, along with each Power State within the=20 Power Set are listed in [EMAN-FMWK]. =20 =20 5.3. Energy Object Usage Information=20 For an Energy Object, power usage is reported using eoPower. =20 The magnitude of measurement is based on the=20 eoPowerUnitMultiplier MIB variable, based on the UnitMultiplier=20= Textual Convention (TC). Power measurement magnitude should=20 conform to the IEC 62053-21 [IEC.62053-21] and IEC 62053-22=20 [IEC.62053-22] definition of unit multiplier for the SI (System=20= International) units of measure. Measured values are=20 represented in SI units obtained by BaseValue * 10 raised to the=20= power of the scale. =20 =20 For example, if current power usage of an Energy Object is 3, it=20= could be 3 W, 3 mW, 3 KW, or 3 MW, depending on the value of=20 eoPowerUnitMultiplier. Note that other measurements throughout=20= the two MIB modules in this document use the same mechanism,=20 including eoPowerStatePowerUnitMultiplier,=20 eoEnergyUnitMultiplier, and=20 eoACPwrAttributesPowerUnitMultiplier.=20 =20 In addition to knowing the usage and magnitude, it is useful to=20= know how a eoPower measurement was obtained. An NMS can use=20 this to account for the accuracy and nature of the reading=20 between different implementations. For this eoPowerOrigin=20 describes whether the measurements were made at the device=20 itself or from a remote source. The eoPowerMeasurementCaliber=20= describes the method that was used to measure the power and can=20= distinguish actual or estimated values. There may be devices in=20= the network, which may not be able to measure or report power=20 consumption. For those devices, the object=20 eoPowerMeasurementCaliber shall report that measurement=20 mechanism is "unavailable" and the eoPower measurement shall be=20= "0". =20 =20 =20 Expires June 13, 2014 [Page 14]=20= =20 =0C Internet-Draft December 2013=20= =20 =20 The nameplate power rating of an Energy Object is specified in=20= eoPowerNameplate MIB object.=20 =20 =20 5.4. Optional Power Usage Attributes =20 The optional powerAttributesMIB MIB module can be implemented to=20= further describe power usage attributes measurement. The=20 powerAttributesMIB MIB module adheres closely to the IEC 61850=20= 7-2 standard to describe AC measurements. =20 =20 The powerAttributesMIB MIB module contains a primary table, the=20= eoACPwrAttributesTable table, that defines power attributes=20 measurements for supported entPhysicalIndex entities, as a=20 sparse extension of the eoPowerTable (with entPhysicalIndex as=20= primary index). This eoACPwrAttributesTable table contains such=20= information as the configuration (single phase, DEL 3 phases,=20 WYE 3 phases), voltage, frequency, power accuracy, total=20 active/reactive power/apparent power, amperage, and voltage. =20 =20 In case of 3-phase power, the eoACPwrAttributesPhaseTable=20 additional table is populated with Power Attributes measurements=20= per phase (so double indexed by the entPhysicalIndex and=20 eoPhaseIndex). This table, which describes attributes common to=20= both WYE and DEL configurations, contains the average current,=20= active/reactive/apparent power, power factor, and impedance.=20 =20 In case of 3-phase power with a DEL configuration, the=20 eoACPwrAttributesDelPhaseTable table describes the phase-to- phase power attributes measurements, i.e., voltage and current.=20= =20 In case of 3-phase power with a WYE configuration, the=20 eoACPwrAttributesWyePhaseTable table describes the phase-to- neutral power attributes measurements, i.e., voltage and=20 current.=20 =20 5.5. Optional Energy Measurement=20 It is relevant to measure energy and demand only when there are=20= actual power measurements obtained from measurement hardware. If=20= the eoPowerMeasurementCaliber MIB object has values of=20 unavailable, unknown, estimated, or presumed, then the energy=20 and demand values are not useful.=20 =20 Two tables are introduced to characterize energy measurement of=20= an Energy Object: eoEnergyTable and eoEnergyParametersTable. =20 Both energy and demand information can be represented via the=20 =20 =20 Expires June 13, 2014 [Page 15]=20= =20 =0C Internet-Draft December 2013=20= =20 eoEnergyTable. Energy information will be an accumulation with=20= no interval. Demand information can be represented. =20 The eoEnergyParametersTable consists of the parameters defining =20= eoEnergyParametersIndex an index of that specifies the setting=20= for collection of energy measurements for an Energy Object,=20 eoEnergyObjectIndex linked to the entPhysicalIndex of the=20 Energy Object, the duration of measurement intervals in seconds,=20= (eoEnergyParametersIntervalLength), the number of successive=20 intervals to be stored in the eoEnergyTable,=20 (eoEnergyParametersIntervalNumber), the type of measurement=20 technique (eoEnergyParametersIntervalMode), and a sample rate=20 used to calculate the average (eoEnergyParametersSampleRate). =20= Judicious choice of the sampling rate will ensure accurate=20 measurement of energy while not imposing an excessive polling=20 burden.=20 =20 There are three eoEnergyParametersIntervalMode types used for=20 energy measurement collection: period, sliding, and total. The=20= choices of the three different modes of collection are based on=20= IEC standard 61850-7-4. Note that multiple=20 eoEnergyParametersIntervalMode types MAY be configured=20 simultaneously. It is important to note that for a given Energy=20= Object, multiple modes (periodic, total, sliding window) of=20 energy measurement collection can be configured with the use of=20= eoEnergyParametersIndex. However, simultaneous measurement in=20= multiple modes for a given Energy Object depends on the Energy=20= Object capability. =20 =20 These three eoEnergyParametersIntervalMode types are illustrated=20= by the following three figures, for which:=20 =20 - The horizontal axis represents the current time, with the=20 symbol <--- L ---> expressing the=20 eoEnergyParametersIntervalLength, and the=20 eoEnergyCollectionStartTime is represented by S1, S2, S3, S4,=20 ..., Sx where x is the value of=20 eoEnergyParametersIntervalNumber.=20 =20 - The vertical axis represents the time interval of sampling and=20= the value of eoEnergyConsumed can be obtained at the end of the=20= sampling period. The symbol =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D = denotes the duration of=20 the sampling period. =20 =20 =20 | | | =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D | =20 |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D | | = | =20 | | | |=20 | |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D | = |=20 =20 =20 Expires June 13, 2014 [Page 16]=20= =20 =0C Internet-Draft December 2013=20= =20 | | | |=20 | <--- L ---> | <--- L ---> | <--- L ---> |=20 | | | |=20 S1 S2 S3 S4=20 =20 Figure 3 : Period eoEnergyParametersIntervalMode=20 =20 A eoEnergyParametersIntervalMode type of 'period' specifies non- overlapping periodic measurements. Therefore, the next=20 eoEnergyCollectionStartTime is equal to the previous=20 eoEnergyCollectionStartTime plus=20 eoEnergyParametersIntervalLength. S2=3DS1+L; S3=3DS2+L, ...=20 =20 =20 |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D | = =20 | | =20 | <--- L ---> | =20 | | =20 | |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D | =20= | | |=20 | | <--- L ---> | =20 | | | =20 | | |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D | =20= | | | | =20 | | | <--- L ---> | =20 | | | | =20 | | | |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D = | =20 | | | | | =20 | | | | <--- L ---> |=20 S1 | | | |=20 | | | |=20 | | | |=20 S2 | | |=20 | | |=20 | | |=20 S3 | |=20 | |=20 | |=20 S4=20 =20 Figure 4 : Sliding eoEnergyParametersIntervalMode=20 =20 A eoEnergyParametersIntervalMode type of 'sliding' specifies=20 overlapping periodic measurements.=20 =20 =20 =20 | |=20 =20 =20 Expires June 13, 2014 [Page 17]=20= =20 =0C Internet-Draft December 2013=20= =20 |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D |=20 | |=20 | |=20 | |=20 | <--- Total length ---> |=20 | |=20 S1 =20 =20 Figure 5 : Total eoEnergyParametersIntervalMode=20 =20 A eoEnergyParametersIntervalMode type of 'total' specifies a=20 continuous measurement since the last reset. The value of=20 eoEnergyParametersIntervalNumber should be (1) one and=20 eoEnergyParametersIntervalLength is ignored.=20 =20 The eoEnergyParametersStatus is used to start and stop energy=20 usage logging. The status of this variable is "active" when all=20= the objects in eoEnergyParametersTable are appropriate which in=20= turn indicates if eoEnergyTable entries exist or not.=20 =20 The eoEnergyTable consists of energy measurements in=20 eoEnergyConsumed, eoEnergyProvided and eoEnergyStored, the units=20= of the measured energy eoEnergyUnitMultiplier, and the maximum=20= observed energy within a window eoEnergyMaxConsumed,=20 eoEnergyMaxProduced. =20 =20 Measurements of the total energy consumed by an Energy Object=20 may suffer from interruptions in the continuous measurement of=20= energy consumption. In order to indicate such interruptions,=20 the object eoEnergyDiscontinuityTime is provided for indicating=20= the time of the last interruption of total energy measurement. =20= eoEnergyDiscontinuityTime shall indicate the sysUpTime [RFC3418]=20= when the device was reset. =20 =20 The following example illustrates the eoEnergyTable and=20 eoEnergyParametersTable:=20 =20 First, in order to estimate energy, a time interval to sample=20 energy should be specified, i.e.=20 eoEnergyParametersIntervalLength can be set to "900 seconds" or=20= 15 minutes and the number of consecutive intervals over which=20 the maximum energy is calculated=20 (eoEnergyParametersIntervalNumber) as "10". The sampling rate=20= internal to the Energy Object for measurement of power usage=20 (eoEnergyParametersSampleRate) can be "1000 milliseconds", as=20 set by the Energy Object as a reasonable value. Then, the=20 eoEnergyParametersStatus is set to active (value 1) to indicate=20= =20 =20 Expires June 13, 2014 [Page 18]=20= =20 =0C Internet-Draft December 2013=20= =20 that the Energy Object should start monitoring the usage per the=20= eoEnergyTable.=20 =20 The indices for the eoEnergyTable are eoEnergyParametersIndex=20 which identifies the index for the setting of energy measurement=20= collection Energy Object, and eoEnergyCollectionStartTime, which=20= denotes the start time of the energy measurement interval based=20= on sysUpTime [RFC3418]. The value of eoEnergyComsumed is the=20 measured energy consumption over the time interval specified=20 (eoEnergyParametersIntervalLength) based on the Energy Object=20 internal sampling rate (eoEnergyParametersSampleRate). While=20 choosing the values for the eoEnergyParametersIntervalLength and=20= eoEnergyParametersSampleRate, it is recommended to take into=20 consideration either the network element resources adequate to=20= process and store the sample values, and the mechanism used to=20= calculate the eoEnergyConsumed. The units are derived from=20 eoEnergyUnitMultiplier. For example, eoEnergyConsumed can be=20 "100" with eoEnergyUnitMultiplier equal to 0, the measured=20 energy consumption of the Energy Object is 100 watt-hours. The=20= eoEnergyMaxConsumed is the maximum energy observed and that can=20= be "150 watt-hours".=20 =20 The eoEnergyTable has a buffer to retain a certain number of=20 intervals, as defined by eoEnergyParametersIntervalNumber. =20 If the default value of "10" is kept, then the eoEnergyTable=20 contains 10 energy measurements, including the maximum. =20 =20 Here is a brief explanation of how the maximum energy can be=20 calculated. The first observed energy measurement value is=20 taken to be the initial maximum. With each subsequent=20 measurement, based on numerical comparison, maximum energy may=20= be updated. The maximum value is retained as long as the=20 measurements are taking place. Based on periodic polling of=20 this table, an NMS could compute the maximum over a longer=20 period, i.e. a month, 3 months, or a year.=20 =20 5.6. Fault Management=20 [RFC6988] specifies requirements about Power States such as "the=20= current Power State" , "the time of the last state change", "the=20= total time spent in each state", "the number of transitions to=20= each state" etc. Some of these requirements are fulfilled=20 explicitly by MIB objects such as eoPowerOperState,=20 eoPowerStateTotalTime and eoPowerStateEnterCount. Some of the=20= other requirements are met via the SNMP NOTIFICATION mechanism. =20= eoPowerStateChange SNMP notification which is generated when the=20= =20 =20 Expires June 13, 2014 [Page 19]=20= =20 =0C Internet-Draft December 2013=20= =20 value(s) of ,eoPowerStateIndex, eoPowerOperState,=20 TOM: Odd spacing of the comma above. eoPowerAdminState have changed. =20 =20 =20 6. Discovery=20 It is foreseen that most Energy Objects will require the=20 implementation of the ENERGY-OBJECT-CONTEXT-MIB MIB [EMAN-AWARE- MIB] as a prerequisite for this MIB module. In such a case,=20 eoPowerTable of the EMAN-MON-MIB is a sparse extension of the=20 eoTable of ENERGY-OBJECT-CONTEXT-MIB. Every Energy Object MUST=20= implement entPhysicalIndex, entPhysicalUUID and entPhysicalName=20= from the ENTITY-MIB [RFC6933]. As the primary index for the=20 Energy Object, entPhysicalIndex is used: It characterizes the=20 Energy Object in the ENERGY-OBJECT-MIB and the POWER-ATTRIBUTES- MIB MIB modules (this document).=20 The NMS must first poll the ENERGY-OBJECT-CONTEXT-MIB MIB module=20= [EMAN-AWARE-MIB], if available, in order to discover all the=20 Energy Objects and the relationships between those Energy=20 Objects. In the ENERGY-OBJECT-CONTEXT-MIB module tables, the=20 Energy Objects are indexed by the entPhysicalIndex.=20 =46rom there, the NMS must poll the eoPowerStateTable (specified=20= in the ENERGY-OBJECT-MIB module in this document), which=20 enumerates, amongst other things, the maximum power usage. As=20= the entries in eoPowerStateTable table are indexed by the =20 Energy Object ( entPhysicalIndex), by the Power State Set=20 (eoPowerStateIndex), the maximum power usage is discovered per =20= Energy Object, and the power usage per Power State of the Power=20= State Set. In other words, polling the eoPowerStateTable allows=20= the discovery of each Power State within every Power State Set=20= supported by the Energy Object. =20 If the Energy Object has an Aggregation Relationship with=20 another Energy Object, the MIB module would be populated with=20 the Energy Object relationship information, which have their own=20= Energy Object index value (entPhysicalIndex). However, the=20 Energy Object relationship must be discovered thanks to the=20 ENERGY-OBJECT-CONTEXT-MIB module. =20 Finally, the NMS can monitor the power attributes thanks to the=20= powerAttributesMIB MIB module, which reuses the entPhysicalIndex=20= to index the Energy Object.=20 =20 =20 =20 Expires June 13, 2014 [Page 20]=20= =20 =0C Internet-Draft December 2013=20= =20 7. Link with the other IETF MIBs=20 =20 7.1. Link with the ENTITY-MIB and the ENTITY-SENSOR MIB =20 RFC 4133 [RFC4133] defines the ENTITY-MIB module that lists the=20= physical entities of a networking device (router, switch, etc.)=20= and those physical entities indexed by entPhysicalIndex. =46rom=20= an energy-management standpoint, the physical entities that=20 consume or produce energy are of interest.=20 =20 RFC 3433 [RFC3433] defines the ENTITY-SENSOR MIB module that=20 provides a standardized way of obtaining information (current=20 value of the sensor, operational status of the sensor, and the=20= data units precision) from sensors embedded in networking=20 devices. Sensors are associated with each index of=20 entPhysicalIndex of the ENTITY-MIB [RFC4133]. While the focus=20= of the Power and Energy Monitoring MIB is on measurement of=20 power usage of networking equipment indexed by the ENTITY-MIB,=20= this MIB proposes a customized power scale for power measurement=20= and different Power States of networking equipment, and=20 functionality to configure the Power States.=20 =20 The Energy Objects are modeled by the entPhysicalIndex through=20= the entPhysicalEntity MIB object specified in the eoTable in the=20= ENERGY-OBJECT-CONTEXT-MIB MIB module [EMAN-AWARE-MIB]. =20 The ENTITY-SENSOR MIB [RFC3433] does not have the ANSI C12.x=20 accuracy classes required for electricity (i.e., 1%, 2%, 0.5%=20 accuracy classes). Indeed, entPhySensorPrecision [RFC3433]=20 represents "The number of decimal places of precision in fixed- point sensor values returned by the associated entPhySensorValue=20= object". The ANSI and IEC Standards are used for power=20 measurement and these standards require that we use an accuracy=20= class, not the scientific-number precision model specified in=20 RFC3433. The eoPowerAccuracy MIB object models this accuracy. =20= Note that eoPowerUnitMultipler represents the scale factor per=20= IEC 62053-21 [IEC.62053-21] and IEC 62053-22 [IEC.62053-22],=20 which is a more logical representation for power measurements=20 (compared to entPhySensorScale), with the mantissa and the=20 exponent values X * 10 ^ Y.=20 Power measurements specifying the qualifier 'UNITS' for each=20 measured value in watts are used in the LLDP-EXT-MED-MIB, POE=20 [RFC3621], and UPS [RFC1628] MIBs. The same 'UNITS' qualifier=20= is used for the power measurement values. =20 =20 =20 =20 Expires June 13, 2014 [Page 21]=20= =20 =0C Internet-Draft December 2013=20= =20 One cannot assume that the ENTITY-MIB and ENTITY-SENSOR MIB are=20= implemented for all Energy Objects that need to be monitored. A=20= typical example is a converged building gateway, monitoring=20 several other devices in the building, doing the proxy between=20= SNMP and a protocol like BACNET. Another example is the home=20 energy controller. In such cases, the eoPhysicalEntity value=20 contains the zero value, thanks to PhysicalIndexOrZero textual=20= convention.=20 =20 The eoPower is similar to entPhySensorValue [RFC3433] and the=20 eoPowerUnitMultipler is similar to entPhySensorScale.=20 =20 =20 7.2. Link with the ENTITY-STATE MIB =20 For each entity in the ENTITY-MIB [RFC4133], the ENTITY-STATE=20 MIB [RFC4268] specifies the operational states (entStateOper:=20 unknown, enabled, disabled, testing), the alarm (entStateAlarm:=20= unknown, underRepair, critical, major, minor, warning,=20 indeterminate) and the possible values of standby states =20 (entStateStandby: unknown, hotStandby, coldStandby,=20 providingService).=20 =20 =46rom a power monitoring point of view, in contrast to the = entity=20 operational states of entities, Power States are required, as=20 proposed in the Power and Energy Monitoring MIB module. Those=20= Power States can be mapped to the different operational states=20= in the ENTITY-STATE MIB, if a formal mapping is required. For=20= example, the entStateStandby "unknown", "hotStandby",=20 "coldStandby", states could map to the Power State "unknown",=20 "ready", "standby", respectively, while the entStateStandby=20 "providingService" could map to any "low" to "high" Power State.=20= =20 =20 7.3. Link with the POWER-OVER-ETHERNET MIB=20 Power-over-Ethernet MIB [RFC3621] provides an energy monitoring=20= and configuration framework for power over Ethernet devices. =20 The RFC introduces a concept of a port group on a switch to=20 define power monitoring and management policy and does not use=20= the entPhysicalIndex as the index. Indeed, the=20 pethMainPseConsumptionPower is indexed by the=20 pethMainPseGroupIndex, which has no mapping with the=20 entPhysicalIndex. =20 =20 One cannot assume that the Power-over-Ethernet MIB is=20 implemented for all Energy Objects that need to be monitored. =20= =20 =20 Expires June 13, 2014 [Page 22]=20= =20 =0C Internet-Draft December 2013=20= =20 A typical example is a converged building gateway, monitoring=20 several other devices in the building, doing the proxy between=20= SNMP and a protocol like BACNET. Another example is the home=20 energy controller. In such cases, the eoethPortIndex and=20 eoethPortGrpIndex values contain the zero value, thanks to new=20= PethPsePortIndexOrZero and textual PethPsePortGroupIndexOrZero=20= conventions.=20 =20 However, if the Power-over-Ethernet MIB [RFC3621] is supported,=20= the Energy Object eoethPortIndex and eoethPortGrpIndex contain=20= the pethPsePortIndex and pethPsePortGroupIndex, respectively.=20 =20 As a consequence, the entPhysicalIndex MIB object has been kept=20= as the unique Energy Object index.=20 =20 Note that, even though the Power-over-Ethernet MIB [RFC3621] was=20= created after the ENTITY-SENSOR MIB [RFC3433], it does not reuse=20= the precision notion from the ENTITY-SENSOR MIB, i.e. the=20 entPhySensorPrecision MIB object.=20 =20 =20 7.4. Link with the UPS MIB=20 To protect against unexpected power disruption, data centers and=20= buildings make use of Uninterruptible Power Supplies (UPS). To=20= protect critical assets, a UPS can be restricted to a particular=20= subset or domain of the network. UPS usage typically lasts only=20= for a finite period of time, until normal power supply is=20 restored. Planning is required to decide on the capacity of the=20= UPS based on output power and duration of probable power outage. = =20 To properly provision UPS power in a data center or building, it=20= is important to first understand the total demand required to=20 support all the entities in the site. This demand can be=20 assessed and monitored via the Power and Energy Monitoring MIB. =20= UPS MIB [RFC1628] provides information on the state of the UPS=20= network. Implementation of the UPS MIB is useful at the=20 aggregate level of a data center or a building. The MIB module=20= contains several groups of variables:=20 - upsIdent: Identifies the UPS entity (name, model, etc.). =20 - upsBattery group: Indicates the battery state=20 (upsbatteryStatus, upsEstimatedMinutesRemaining, etc.)=20 - upsInput group: Characterizes the input load to the UPS=20 (number of input lines, voltage, current, etc.).=20 =20 =20 Expires June 13, 2014 [Page 23]=20= =20 =0C Internet-Draft December 2013=20= =20 - upsOutput: Characterizes the output from the UPS (number of=20 output lines, voltage, current, etc.)=20 - upsAlarms: Indicates the various alarm events. =20 The measurement of power in the UPS MIB is in Volts, Amperes and=20= Watts. The units of power measurement are RMS volts and RMS=20 Amperes. They are not based on the EntitySensorDataScale and=20 EntitySensorDataPrecision of ENTITY-SENSOR-MIB.=20 Both the Power and Energy Monitoring MIB and the UPS MIB may be=20= implemented on the same UPS SNMP agent, without conflict. In=20 this case, the UPS device itself is the Energy Object and any=20= of the UPS meters or submeters are the Energy Objects with a=20 possible relationship as defined in [EMAN-FMWK].=20 =20 7.5. Link with the LLDP and LLDP-MED MIBs=20 The LLDP Protocol is a Data Link Layer protocol used by network=20= devices to advertise their identities, capabilities, and=20 interconnections on a LAN network. =20 =20 The Media Endpoint Discovery is an enhancement of LLDP, known as=20= LLDP-MED. The LLDP-MED enhancements specifically address voice=20= applications. LLDP-MED covers 6 basic areas: capability=20 discovery, LAN speed and duplex discovery, network policy=20 discovery, location identification discovery, inventory=20 discovery, and power discovery. =20 =20 Of particular interest to the current MIB module is the power=20 discovery, which allows the endpoint device (such as a PoE=20 phone) to convey power requirements to the switch. In power=20 discovery, LLDP-MED has four Type Length Values (TLVs): power=20 type, power source, power priority and power value. =20 Respectively, those TLVs provide information related to the type=20= of power (power sourcing entity versus powered device), how the=20= device is powered (from the line, from a backup source, from=20 external power source, etc.), the power priority (how important=20= is it that this device has power?), and how much power the=20 device needs.=20 =20 The power priority specified in the LLDP-MED MIB [LLDP-MED-MIB]=20= actually comes from the Power-over-Ethernet MIB [RFC3621]. If=20 the Power-over-Ethernet MIB [RFC3621] is supported, the exact=20 value from the pethPsePortPowerPriority [RFC3621] is copied over=20= in the lldpXMedRemXPoEPDPowerPriority [LLDP-MED-MIB]; otherwise=20= the value in lldpXMedRemXPoEPDPowerPriority is "unknown". =46rom=20= the Power and Energy Monitoring MIB, it is possible to identify=20= =20 =20 Expires June 13, 2014 [Page 24]=20= =20 =0C Internet-Draft December 2013=20= =20 the pethPsePortPowerPriority [RFC3621], thanks to the=20 eoethPortIndex and eoethPortGrpIndex.=20 =20 The lldpXMedLocXPoEPDPowerSource [LLDP-MED-MIB] is similar to=20 eoPowerOrigin in indicating if the power for an attached device=20= is local or from a remote device. If the LLDP-MED MIB is=20 supported, the following mapping can be applied to the=20 eoPowerOrigin: lldpXMedLocXPoEPDPowerSource fromPSE(2) and=20 local(3) can be mapped to remote(2) and self(1), respectively.=20= =20 8. Implementation Scenario=20 This section provides an illustrative example scenario for the=20= implementation of the Energy Object, including Energy Object=20 relationships. =20 =20 Example Scenario of a campus network: Switch with PoE Endpoints=20= with further connected devices. =20 =20 The campus network consists of switches that provide LAN=20 connectivity. The switch with PoE ports is located in wiring=20 closet. PoE IP phones are connected to the switch. The IP=20 phones draw power from the PoE ports of the switch. In=20 addition, a PC is daisy-chained from the IP phone for LAN=20 connectivity. =20 =20 The IP phone consumes power from the PoE switch, while the PC=20 consumes power from the wall outlet. =20 =20 The switch has implementations of ENTITY-MIB [RFC6933] and=20 ENERGY-OBJECT-CONTEXT-MIB MIB [EMAN-AWARE-MIB]. while the PC=20 has an implementation of the ENTITY-MIB with=20 entity4CRCompliance, and an implementation of ENERGY-OBJECT- CONTEXT-MIB MIB [EMAN-AWARE-MIB]. The switch has the following=20= attributes, entPhysicalIndex "1", and entPhysicalUUID "UUID=20 1000". The power usage of the switch is "440 Watts".=20 =20 The PoE switch port has the following attributes: The switch=20 port has entPhysicalIndex "3", and entPhysicalUUID is "UUID=20 1000:3". The power metered at the POE switch port is "12=20 watts". In this example, the POE switch port has an Energy=20 Object relationship with the switch with Energy Object index=20 "1000".=20 =20 The attributes of the PC are given below. The PC has an=20 entPhysicalIndex "7" and its entPhysicalUUID is "UUID 1000:57 ". = =20 The PC has an Energy Object relationship with the switch port=20 =20 =20 Expires June 13, 2014 [Page 25]=20= =20 =0C Internet-Draft December 2013=20= =20 whose entPhysicalUUID is "UUID 1000:3". The power usage of the=20= PC is "120 Watts" and is communicated to the switch port. =20 =20 The IP phone draws power from the switch, while the PC has LAN=20= connectivity from the phone, but is powered from the wall=20 outlet. However, the Energy Object switch sends power control=20= messages to both the Energy Object (IP phone and PC) and the=20 attached remote Energy Objects react to those messages.=20 =20 =20 |-------------------------------------------------------|=20 | Switch |=20 |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D|=20 | Switch | Switch | | Switch |=20 | entPhyIndx | UUID | | eoPower |=20 | =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D |=20 | 1 | UUID 1000 | null | 440 |=20 | =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D |=20 | |=20 | SWITCH PORT |=20 | =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D |=20 | | Switch | Switch | Switch | Switch |=20 | | Port | Port | UUID | Port |=20 | | entPhyIndx | UUID | | eoPower |=20 | =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D |=20 | | 3 | UUID 1000:3 | 1000 | 12 |=20 | =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D|=20 | ^ |=20 | | |=20 |-----------------------------------|-------------------|=20 |=20 |=20 POE IP PHONE |=20 |=20 |=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=20 | IP phone | IP phone | Port | IP phone | =20 | entPhyIndx | UUID | UUID | eoPower |=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D =20 | Null | UUID 1000:31| UUID 1000:3 | 12 |=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=20 |=20 |=20 PC connected to switch via IP phone |=20 |=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=20 | PC | PC | Port | PC |=20 |entPhyIndx | UUID | UUID | eoPower |=20 =20 =20 Expires June 13, 2014 [Page 26]=20= =20 =0C Internet-Draft December 2013=20= =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=20 | 7 | UUID 1000:57| UUID 1000:3 | 120 | =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=20 =20 Figure 6: Example scenario =20 =20 =20 9. Structure of the MIB=20 The primary MIB object in this MIB module is the=20 energyObjectMIBObject. The eoPowerTable table of=20 energyObjectMIBObject describes the power measurement attributes=20= of an Energy Object entity. The notion of identity of the device=20= in terms of uniquely identification of the Energy Object and its=20= relationship to other entities in the network are addressed in=20= [EMAN-AWARE-MIB]. =20 =20 Logically, this MIB module is a sparse extension of the=20 ENERGY-OBJECT-CONTEXT-MIB module [EMAN-AWARE-MIB]. Thus the=20 following requirements which are applied to [EMAN-AWARE-MIB] are=20= also applicable. As a requirement for this MIB module, [EMAN- AWARE-MIB] should be implemented and as Module Compliance of=20 ENTITY-MIB V4 [RFC6933] with respect to entity4CRCompliance=20 should be supported which requires 3 MIB objects=20 (entPhysicalIndex, entPhysicalName and entPhysicalUUID ) MUST be=20= implemented. =20 =20 eoMeterCapabilitiesTable is useful to enable applications to=20 determine the capabilities supported by the local management=20 agent. This table indicates the energy monitoring MIB groups=20 that are supported by the local management system. By reading=20 the value of this object, it is possible for applications to=20 know which tables contain the information and are usable without=20= walking through the table and querying every element which=20 involves a trial-and-error process.=20 =20 The power measurement of an Energy Object contains information=20= describing its power usage (eoPower) and its current Power State=20= (eoPowerOperState). In addition to power usage, additional=20 information describing the units of measurement=20 (eoPowerAccuracy, eoPowerUnitMultiplier), how power usage=20 measurement was obtained (eoPowerMeasurementCaliber), the=20 source of power (eoPowerOrigin) and the type of power=20 (eoPowerCurrentTtype) are described.=20 =20 =20 =20 Expires June 13, 2014 [Page 27]=20= =20 =0C Internet-Draft December 2013=20= =20 An Energy Object may contain an optional eoPowerAttributes table=20= that describes the electrical characteristics associated with=20 the current Power State and usage.=20 =20 An Energy Object may contain an optional eoEnergyTable to=20 describe energy measurement information over time.=20 =20 An Energy Object may also contain optional battery information=20= associated with this entity. =20 =20 =20 =20 10. MIB Definitions=20 =20 -- ************************************************************=20= -- =20 -- =20 -- This MIB is used to monitor power usage of network=20 -- devices=20 -- =20 -- *************************************************************=20= =20 ENERGY-OBJECT-MIB DEFINITIONS ::=3D BEGIN=20 =20 IMPORTS=20 MODULE-IDENTITY,=20 OBJECT-TYPE,=20 NOTIFICATION-TYPE,=20 mib-2,=20 Integer32, Counter32, TimeTicks =20 FROM SNMPv2-SMI=20 TEXTUAL-CONVENTION, DisplayString, RowStatus, TimeInterval,=20= TimeStamp, TruthValue =20 FROM SNMPv2-TC =20 MODULE-COMPLIANCE, NOTIFICATION-GROUP, OBJECT-GROUP=20 FROM SNMPv2-CONF=20 OwnerString=20 FROM RMON-MIB=20 entPhysicalIndex, PhysicalIndex=20 FROM ENTITY-MIB =20 IANAPowerStateSet =20 FROM IANA-POWERSTATE-SET-MIB;=20 =20 =20 energyObjectMIB MODULE-IDENTITY=20 LAST-UPDATED "201312130000Z" -- 13 December 2013=20 =20 =20 =20 Expires June 13, 2014 [Page 28]=20= =20 =0C Internet-Draft December 2013=20= =20 ORGANIZATION "IETF EMAN Working Group"=20 CONTACT-INFO=20 "WG charter:=20 http://datatracker.ietf.org/wg/eman/charter/=20 =20 Mailing Lists:=20 General Discussion: eman@ietf.org=20 To Subscribe: =20 https://www.ietf.org/mailman/listinfo/eman=20 Archive: =20 http://www.ietf.org/mail-archive/web/eman=20 Editors:=20 Mouli Chandramouli=20 Cisco Systems, Inc.=20 Sarjapur Outer Ring Road=20 Bangalore 560103=20 IN=20 Phone: +91 80 4429 2409 =20 Email: moulchan@cisco.com=20 Benoit Claise=20 Cisco Systems, Inc.=20 De Kleetlaan 6a b1=20 Degem 1831=20 Belgium=20 Phone: +32 2 704 5622=20 Email: bclaise@cisco.com=20 Brad Schoening=20 44 Rivers Edge Drive=20 Little Silver, NJ 07739=20 US=20 Email: brad.schoening@verizon.net=20 Juergen Quittek=20 NEC Europe Ltd.=20 NEC Laboratories Europe=20 Network Research Division=20 Kurfuersten-Anlage 36=20 Heidelberg 69115=20 DE=20 Phone: +49 6221 4342-115=20 Email: quittek@neclab.eu=20 =20 =20 Expires June 13, 2014 [Page 29]=20= =20 =0C Internet-Draft December 2013=20= =20 Thomas Dietz=20 NEC Europe Ltd.=20 NEC Laboratories Europe=20 Network Research Division=20 Kurfuersten-Anlage 36=20 69115 Heidelberg=20 DE=20 Phone: +49 6221 4342-128=20 Email: Thomas.Dietz@nw.neclab.eu"=20 DESCRIPTION=20 "This MIB is used to monitor power and energy in =20 devices. =20 =20 This table sparse extension of the eoTable =20 from the ENERGY-OBJECT-CONTEXT-MIB. As a requirement =20 [EMAN-AWARE-MIB] must be implemented.=20 =20 =20 Module Compliance of ENTITY-MIB v4=20 with respect to entity4CRCompliance should =20 be supported which requires implementation =20 of 3 MIB objects (entPhysicalIndex, =20 entPhysicalName and entPhysicalUUID)."=20 =20 REVISION=20 "201312130000Z" -- 13 December 2013 =20 =20 DESCRIPTION=20 "Initial version, published as RFC YYY."=20 =20 ::=3D { energyMIB 3 }=20 =20 =20 energyObjectMIBNotifs OBJECT IDENTIFIER=20 ::=3D { energyObjectMIB 0 }=20 =20 energyObjectMIBObjects OBJECT IDENTIFIER=20 ::=3D { energyObjectMIB 1 }=20 =20 energyObjectMIBConform OBJECT IDENTIFIER=20 ::=3D { energyObjectMIB 2 }=20 =20 =20 -- Textual Conventions=20 =20 =20 UnitMultiplier ::=3D TEXTUAL-CONVENTION=20 =20 =20 Expires June 13, 2014 [Page 30]=20= =20 =0C Internet-Draft December 2013=20= =20 STATUS current=20 DESCRIPTION =20 "The Unit Multiplier is an integer value that represents=20= the IEEE 61850 Annex A units multiplier associated with=20= the integer units used to measure the power or energy. =20= =20 For example, when used with eoPowerUnitMultiplier, -3=20 represents 10^-3 or milliwatts."=20 REFERENCE=20 "The International System of Units (SI),=20 National Institute of Standards and Technology,=20 Spec. Publ. 330, August 1991."=20 SYNTAX INTEGER {=20 yocto(-24), -- 10^-24=20 zepto(-21), -- 10^-21=20 atto(-18), -- 10^-18=20 femto(-15), -- 10^-15=20 pico(-12), -- 10^-12=20 nano(-9), -- 10^-9=20 micro(-6), -- 10^-6=20 milli(-3), -- 10^-3=20 units(0), -- 10^0=20 kilo(3), -- 10^3=20 mega(6), -- 10^6=20 giga(9), -- 10^9=20 tera(12), -- 10^12=20 peta(15), -- 10^15=20 exa(18), -- 10^18=20 zetta(21), -- 10^21=20 yotta(24) -- 10^24=20 }=20 =20 -- Objects=20 =20 =20 =20 eoMeterCapabilitiesTable OBJECT-TYPE=20 SYNTAX SEQUENCE OF EoMeterCapabilitiesEntry =20 MAX-ACCESS not-accessible=20 STATUS current=20 DESCRIPTION=20 "This table is useful for helping applications determine the=20 monitoring capabilities supported by the local management=20 agents. It is possible for applications to know which tables =20= are usable without going through a trial-and-error process."=20 ::=3D { energyObjectMIBObjects 1 }=20 =20 =20 =20 =20 Expires June 13, 2014 [Page 31]=20= =20 =0C Internet-Draft December 2013=20= =20 eoMeterCapabilitiesEntry OBJECT-TYPE=20 SYNTAX EoMeterCapabilitiesEntry=20 MAX-ACCESS not-accessible=20 STATUS current=20 DESCRIPTION=20 "An entry describes the metering capability of an Energy=20 Object."=20 INDEX { entPhysicalIndex } =20 ::=3D { eoMeterCapabilitiesTable 1 }=20 =20 =20 EoMeterCapabilitiesEntry ::=3D SEQUENCE {=20 eoMeterCapability BITS=20 }=20 =20 eoMeterCapability OBJECT-TYPE=20 SYNTAX BITS {=20 none(0), =20 powermetering(1), -- power measurement =20 energymetering(2), -- energy measurement=20 powerattributes(3) -- power attributes =20 }=20 MAX-ACCESS read-only=20 STATUS current=20 DESCRIPTION =20 "An indication of the Energy monitoring capabilities supported=20= by this agent. This object use a BITS syntax and indicate the=20= MIB groups supported by the probe. By reading the value of this=20= object, it is possible to determine the MIB tables supported. "=20= ::=3D { eoMeterCapabilitiesEntry 1 }=20 =20 =20 eoPowerTable OBJECT-TYPE=20 SYNTAX SEQUENCE OF EoPowerEntry =20 MAX-ACCESS not-accessible=20 STATUS current=20 DESCRIPTION=20 "This table lists Energy Objects."=20 ::=3D { energyObjectMIBObjects 2 }=20 =20 =20 eoPowerEntry OBJECT-TYPE=20 SYNTAX EoPowerEntry=20 MAX-ACCESS not-accessible=20 STATUS current=20 DESCRIPTION=20 "An entry describes the power usage of an Energy Object."=20= =20 =20 =20 Expires June 13, 2014 [Page 32]=20= =20 =0C Internet-Draft December 2013=20= =20 INDEX { entPhysicalIndex } =20 ::=3D { eoPowerTable 1 }=20 =20 =20 EoPowerEntry ::=3D SEQUENCE {=20 =20 eoPower Integer32,=20 eoPowerNameplate Integer32,=20 eoPowerUnitMultiplier UnitMultiplier,=20 eoPowerAccuracy Integer32, = =20 eoPowerMeasurementCaliber INTEGER,=20 eoPowerCurrentType INTEGER,=20 eoPowerOrigin INTEGER,=20 eoPowerAdminState IANAPowerStateSet, =20 eoPowerOperState IANAPowerStateSet, =20 eoPowerStateEnterReason OwnerString=20 }=20 =20 =20 =20 eoPower OBJECT-TYPE=20 SYNTAX Integer32=20 TOM: Should this be limited to positives only? You can't have negative = watts can you? UNITS "Watts"=20 MAX-ACCESS read-only=20 STATUS current=20 DESCRIPTION=20 "This object indicates the power measured for the Energy=20= Object. For alternating current, this value is obtained=20= as an average over fixed number of AC cycles. . This=20 value is specified in SI units of watts with the=20 magnitude of watts (milliwatts, kilowatts, etc.)=20 indicated separately in eoPowerUnitMultiplier. The=20 accuracy of the measurement is specfied in=20 eoPowerAccuracy. The direction of power flow is indicated=20= by the sign on eoPower. If the Energy Object is consuming=20= power, the eoPower value will be positive. If the Energy=20= Object is producing power, the eoPower value will be=20 negative. =20 =20 The eoPower MUST be less than or equal to the maximum=20 power that can be consumed at the power state specified=20= by eoPowerState.=20 =20 The eoPowerMeasurementCaliber object specifies how the=20 usage value reported by eoPower was obtained. The eoPower=20= value must report 0 if the eoPowerMeasurementCaliber is=20= 'unavailable'. For devices that can not measure or=20 report power, this option can be used." =20 =20 =20 Expires June 13, 2014 [Page 33]=20= =20 =0C Internet-Draft December 2013=20= =20 ::=3D { eoPowerEntry 1 }=20 =20 =20 eoPowerNameplate OBJECT-TYPE=20 SYNTAX Integer32=20 TOM: Should this be limited to positives only? UNITS "Watts"=20 MAX-ACCESS read-only=20 STATUS current=20 DESCRIPTION=20 "This object indicates the rated maximum consumption for=20= the fully populated Energy Object. The nameplate power=20= requirements are the maximum power numbers and, in almost=20= TOM: "maximum power numbers given in Watts..." all cases, are well above the expected operational=20 consumption. The eoPowerNameplate is widely used for=20 power provisioning. This value is specified in either=20 units of watts or voltage and current. The units are=20 therefore SI watts or equivalent Volt-Amperes with the=20 magnitude (milliwatts, kilowatts, etc.) indicated=20 TOM: So here you say "SI watts" so should the UNITS above be "SI Watts"? separately in eoPowerUnitMultiplier." =20 ::=3D { eoPowerEntry 2 }=20 =20 eoPowerUnitMultiplier OBJECT-TYPE=20 SYNTAX UnitMultiplier=20 MAX-ACCESS read-only=20 STATUS current=20 DESCRIPTION=20 "The magnitude of watts for the usage value in eoPower=20 and eoPowerNameplate." =20 ::=3D { eoPowerEntry 3 }=20 =20 eoPowerAccuracy OBJECT-TYPE=20 SYNTAX Integer32 (0..10000)=20 UNITS "hundredths of percent"=20 MAX-ACCESS read-only=20 STATUS current=20 DESCRIPTION=20 "This object indicates a percentage value, in 100ths of a=20= percent, representing the assumed accuracy of the usage=20= reported by eoPower. For example: The value 1010 means=20 the reported usage is accurate to +/- 10.1 percent. This=20= value is zero if the accuracy is unknown or not=20 applicable based upon the measurement method.=20 =20 ANSI and IEC define the following accuracy classes for=20 power measurement:=20 IEC 62053-22 60044-1 class 0.1, 0.2, 0.5, 1 3.=20 ANSI C12.20 class 0.2, 0.5"=20 ::=3D { eoPowerEntry 4 }=20 =20 =20 Expires June 13, 2014 [Page 34]=20= =20 =0C Internet-Draft December 2013=20= =20 =20 =20 eoPowerMeasurementCaliber OBJECT-TYPE=20 SYNTAX INTEGER {=20 unavailable(1) , =20 unknown(2), =20 actual(3) ,=20 estimated(4), =20 static(5) }=20 MAX-ACCESS read-only=20 STATUS current=20 DESCRIPTION=20 "This object specifies how the usage value reported by=20 eoPower was obtained:=20 =20 - unavailable(1): Indicates that the usage is not=20 available. In such a case, the eoPower value must be 0=20 for devices that can not measure or report power this=20 option can be used.=20 =20 - unknown(2): Indicates that the way the usage was=20 determined is unknown. In some cases, entities report=20 aggregate power on behalf of another device. In such=20 cases it is not known whether the usage reported is=20 actual(2), estimated(3) or presumed (4).=20 =20 - actual(3): Indicates that the reported usage was=20 measured by the entity through some hardware or direct=20 physical means. The usage data reported is not presumed=20= (4) or estimated (3) but is the measured consumption=20 rate. =20 - estimated(4): Indicates that the usage was not=20 determined by physical measurement. The value is a=20 derivation based upon the device type, state, and/or=20 current utilization using some algorithm or heuristic. It=20= is presumed that the entity's state and current=20 configuration were used to compute the value. =20 =20 - static(5): Indicates that the usage was not determined=20= by physical measurement, algorithm or derivation. The=20 usage was reported based upon external tables,=20 specifications, and/or model information. For example, a=20= PC Model X draws 200W, while a PC Model Y draws 210W"=20 =20 ::=3D { eoPowerEntry 5 }=20 =20 eoPowerCurrentType OBJECT-TYPE=20 =20 =20 Expires June 13, 2014 [Page 35]=20= =20 =0C Internet-Draft December 2013=20= =20 SYNTAX INTEGER {=20 ac(1),=20 dc(2),=20 unknown(3)=20 }=20 MAX-ACCESS read-only=20 STATUS current=20 DESCRIPTION=20 "This object indicates whether the eoPower for the =20 Energy Object reports alternating current AC(1), direct=20= current DC(2), or that the current type is unknown(3)." =20= ::=3D { eoPowerEntry 6 }=20 =20 eoPowerOrigin OBJECT-TYPE=20 SYNTAX INTEGER {=20 self (1), =20 remote (2) =20 }=20 MAX-ACCESS read-only=20 STATUS current=20 DESCRIPTION=20 "This object indicates the source of power measurement=20 and can be useful when modeling the power usage of=20 attached devices. The power measurement can be performed=20= by the entity itself or the power measurement of the=20 entity can be reported by another trusted entity using a=20= protocol extension. A value of self(1) indicates the=20 measurement is performed by the entity, whereas remote(2)=20= indicates that the measurement was performed by another=20= entity." =20 ::=3D { eoPowerEntry 7 }=20 =20 eoPowerAdminState OBJECT-TYPE=20 SYNTAX IANAPowerStateSet =20 MAX-ACCESS read-write=20 STATUS current=20 DESCRIPTION=20 "This object specifies the desired Power State and the=20= Power State Set for the Energy Object. Note that=20 other(0) is not a Power State Set and unknown(255) is=20 not a Power State as such, but simply an indication that=20= the Power State of the Energy Object is unknown.=20 Possible values of eoPowerAdminState within the Power=20 State Set are registered at IANA. =20 A current list of assignments can be found at=20 =20 RFC-EDITOR: please check the location after IANA"=20 ::=3D { eoPowerEntry 8 }=20 =20 =20 Expires June 13, 2014 [Page 36]=20= =20 =0C Internet-Draft December 2013=20= =20 =20 eoPowerOperState OBJECT-TYPE=20 SYNTAX IANAPowerStateSet =20 MAX-ACCESS read-only=20 STATUS current=20 DESCRIPTION=20 =20 =20 "This object specifies the current operational Power=20 State and the Power State Set for the Energy Object.=20 other(0) is not a Power State Set and unknown(255) is=20 not a Power State as such, but simply an indication that=20= the Power State of the Energy Object is unknown.=20 =20 Possible values of eoPowerAdminState within the Power=20 State Set are registered at IANA. =20 A current list of assignments can be found at=20 =20 RFC-EDITOR: please check the location after IANA"=20 =20 ::=3D { eoPowerEntry 9 }=20 =20 eoPowerStateEnterReason OBJECT-TYPE=20 SYNTAX OwnerString=20 MAX-ACCESS read-write=20 STATUS current=20 DESCRIPTION=20 "This string object describes the reason for the=20 eoPowerAdminState =20 transition Alternatively, this string may contain with=20= the entity that configured this Energy Object to this=20 Power State." =20 DEFVAL { "" }=20 ::=3D { eoPowerEntry 10 }=20 =20 eoPowerStateTable OBJECT-TYPE=20 SYNTAX SEQUENCE OF EoPowerStateEntry =20 MAX-ACCESS not-accessible=20 STATUS current=20 DESCRIPTION=20 "This table enumerates the maximum power usage, in watts,=20= for every single supported Power State of each Energy=20 Object.=20 =20 This table has an expansion-dependent relationship on the=20= eoPowerTable, containing rows describing each Power State=20= for the corresponding Energy Object. For every Energy=20 =20 =20 Expires June 13, 2014 [Page 37]=20= =20 =0C Internet-Draft December 2013=20= =20 Object in the eoPowerTable, there is a corresponding=20 entry in this table."=20 ::=3D { energyObjectMIBObjects 3 }=20 =20 eoPowerStateEntry OBJECT-TYPE=20 SYNTAX EoPowerStateEntry=20 MAX-ACCESS not-accessible=20 STATUS current=20 DESCRIPTION=20 "A eoPowerStateEntry extends a corresponding=20 eoPowerEntry. This entry displays max usage values at=20 every single possible Power State supported by the Energy=20= Object. =20 For example, given the values of a Energy Object =20 corresponding to a maximum usage of 0 W at the =20 state 1 (mechoff), 8 W at state 6 (ready), 11 W at state=20= 9 (mediumMinus),and 11 W at state 12 (high):=20 =20 State MaxUsage Units=20 1 (mechoff 0 W =20 2 (softoff) 0 W =20 3 (hibernate) 0 W =20 4 (sleep) 0 W =20 5 (standby) 0 W =20 6 (ready) 8 W =20 7 (lowMinus) 8 W =20 8 (low) 11 W =20 9 (mediumMinus) 11 W=20 10 (medium) 11 W =20 11 (highMinus) 11 W=20 12 (high) 11 W =20 =20 Furthermore, this table extends to return the total time=20= in each Power State, along with the number of times a=20 particular Power State was entered."=20 =20 INDEX { entPhysicalIndex, = =20 eoPowerStateIndex =20= } =20 ::=3D { eoPowerStateTable 1 }=20 =20 EoPowerStateEntry ::=3D SEQUENCE {=20 eoPowerStateIndex IANAPowerStateSet, =20 eoPowerStateMaxPower Integer32,=20 eoPowerStatePowerUnitMultiplier UnitMultiplier, =20= eoPowerStateTotalTime TimeTicks,=20 eoPowerStateEnterCount Counter32=20 }=20 TOM: Should this table have a StorageType object to indicate volitility = state? =20 =20 Expires June 13, 2014 [Page 38]=20= =20 =0C Internet-Draft December 2013=20= =20 =20 eoPowerStateIndex OBJECT-TYPE =20 SYNTAX IANAPowerStateSet =20 MAX-ACCESS not-accessible=20 STATUS current=20 DESCRIPTION=20 " =20 This object specifies the index of the Power State of=20 the Energy Object within a Power State Set. The=20 semantics of the specific Power State can be obtained=20 from the Power State Set definition."=20 ::=3D { eoPowerStateEntry 1 }=20 =20 =20 eoPowerStateMaxPower OBJECT-TYPE=20 SYNTAX Integer32=20 UNITS "Watts"=20 MAX-ACCESS read-only=20 STATUS current=20 DESCRIPTION=20 "This object indicates the maximum power for the Energy=20= Object at the particular Power State. This value is=20 specified in SI units of watts with the magnitude of the=20= units (milliwatts, kilowatts, etc.) indicated separately=20= in eoPowerStatePowerUnitMultiplier. If the maximum power=20= is not known for a certain Power State, then the value is=20= encoded as 0xFFFF.=20 =20 For Power States not enumerated, the value of=20 eoPowerStateMaxPower might be interpolated by using the=20= next highest supported Power State." =20 ::=3D { eoPowerStateEntry 2 }=20 =20 eoPowerStatePowerUnitMultiplier OBJECT-TYPE=20 SYNTAX UnitMultiplier =20 MAX-ACCESS read-only=20 STATUS current=20 DESCRIPTION=20 "The magnitude of watts for the usage value in=20 eoPowerStateMaxPower." =20 ::=3D { eoPowerStateEntry 3 }=20 =20 eoPowerStateTotalTime OBJECT-TYPE=20 SYNTAX TimeTicks=20 MAX-ACCESS read-only=20 STATUS current=20 DESCRIPTION=20 "This object indicates the total time in hundredth=20 =20 =20 Expires June 13, 2014 [Page 39]=20= =20 =0C Internet-Draft December 2013=20= =20 of second that the Energy Object has been in this power=20 state since the last reset, as specified in the=20 sysUpTime."=20 ::=3D { eoPowerStateEntry 4 }=20 =20 eoPowerStateEnterCount OBJECT-TYPE=20 SYNTAX Counter32=20 MAX-ACCESS read-only=20 STATUS current=20 DESCRIPTION=20 "This object indicates how often the Energy =20 Object has=20 entered this power state, since the last reset of the=20 device as specified in the sysUpTime."=20 ::=3D { eoPowerStateEntry 5 }=20 =20 =20 eoEnergyParametersTable OBJECT-TYPE=20 SYNTAX SEQUENCE OF EoEnergyParametersEntry=20 MAX-ACCESS not-accessible=20 STATUS current=20 DESCRIPTION=20 "This table is used to configure the parameters for=20 Energy measurement collection in the table =20 eoEnergyTable. This table allows the configuration of=20 different measurement settings on the same Energy Object.=20= Implementation of this table only sense for Energy=20 Objects that an eoPowerMeasurementCaliber of actual(3)." = =20 ::=3D { energyObjectMIBObjects 4 }=20 eoEnergyParametersEntry OBJECT-TYPE=20 SYNTAX EoEnergyParametersEntry=20 MAX-ACCESS not-accessible=20 STATUS current=20 DESCRIPTION=20 "An entry controls an energy measurement in=20 eoEnergyTable."=20 INDEX { eoEnergyObjectIndex, eoEnergyParametersIndex } =20 ::=3D { eoEnergyParametersTable 1 }=20 =20 EoEnergyParametersEntry ::=3D SEQUENCE {=20 eoEnergyObjectIndex PhysicalIndex,=20 eoEnergyParametersIndex Integer32,=20 eoEnergyParametersIntervalLength TimeInterval,=20 eoEnergyParametersIntervalNumber Integer32,=20 eoEnergyParametersIntervalMode INTEGER,=20 eoEnergyParametersIntervalWindow TimeInterval,=20 eoEnergyParametersSampleRate Integer32,=20 =20 =20 Expires June 13, 2014 [Page 40]=20= =20 =0C Internet-Draft December 2013=20= =20 eoEnergyParametersStatus RowStatus=20 }=20 =20 eoEnergyObjectIndex OBJECT-TYPE=20 SYNTAX PhysicalIndex=20 MAX-ACCESS not-accessible=20 STATUS current=20 DESCRIPTION=20 "The unique value, to identify the specific Energy Object=20= on which the measurement is applied, the same index used=20= in the eoPowerTable to identify the Energy Object."=20 ::=3D { eoEnergyParametersEntry 1 }=20 =20 eoEnergyParametersIndex OBJECT-TYPE =20 SYNTAX Integer32 (0..2147483647) =20 MAX-ACCESS read-create=20 TOM: This value should not be accessible as it is an index. Its = max-access should be "not-accessible". STATUS current=20 DESCRIPTION=20 "This object specifies the index of the Energy=20 Parameters setting for collection of energy measurements=20= for an Energy Object. An Energy Object can have multiple=20= eoEnergyParametersIndex, depending on the capability of=20= the Energy Object"=20 ::=3D { eoEnergyParametersEntry 2 }=20 TOM: Is the value of 0 as the index representative of some special state = or value? Generally we do not allow 0 as a value unless there is a good = reason for this.=20 =20 eoEnergyParametersIntervalLength OBJECT-TYPE=20 SYNTAX TimeInterval=20 MAX-ACCESS read-create=20 STATUS current=20 DESCRIPTION=20 "This object indicates the length of time in hundredth of=20= seconds over which to compute the average=20 eoEnergyConsumed measurement in the eoEnergyTable table.=20= The computation is based on the Energy Object's internal=20= sampling rate of power consumed or produced by the Energy=20= Object. The sampling rate is the rate at which the Energy=20= Object can read the power usage and may differ based on=20= device capabilities. The average energy consumption is=20 then computed over the length of the interval." =20 DEFVAL { 90000 }=20 ::=3D { eoEnergyParametersEntry 3 }=20 =20 eoEnergyParametersIntervalNumber OBJECT-TYPE=20 SYNTAX Integer32=20 TOM: Should this be limited to positives only? MAX-ACCESS read-create=20 STATUS current=20 DESCRIPTION=20 =20 =20 Expires June 13, 2014 [Page 41]=20= =20 =0C Internet-Draft December 2013=20= =20 =20 "The number of intervals maintained in the eoEnergyTable.=20= Each interval is characterized by a specific=20 eoEnergyCollectionStartTime, used as an index to the=20 table eoEnergyTable. Whenever the maximum number of=20 entries is reached, the measurement over the new interval=20= replaces the oldest measurement. There is one exception=20= to this rule: when the eoEnergyMaxConsumed and/or=20 eoEnergyMaxProduced are in (one of) the two oldest=20 measurement(s), they are left untouched and the next=20 oldest measurement is replaced." =20 DEFVAL { 10 } =20 ::=3D { eoEnergyParametersEntry 4 }=20 =20 eoEnergyParametersIntervalMode OBJECT-TYPE=20 SYNTAX INTEGER {=20 period(1),=20 sliding(2),=20 total(3)=20 }=20 MAX-ACCESS read-create=20 STATUS current=20 DESCRIPTION=20 "A control object to define the mode of interval calculation=20= for the computation of the average eoEnergyConsumed or=20 eoEnergyProvided measurement in the eoEnergyTable table. =20= =20 A mode of period(1) specifies non-overlapping periodic=20 measurements.=20 =20 A mode of sliding(2) specifies overlapping sliding windows=20= where the interval between the start of one interval and=20= the next is defined in eoEnergyParametersIntervalWindow.=20= =20 A mode of total(3) specifies non-periodic measurement. In=20= this mode only one interval is used as this is a=20 continuous measurement since the last reset. The value of=20= eoEnergyParametersIntervalNumber should be (1) one and=20 eoEnergyParametersIntervalLength is ignored. " =20 ::=3D { eoEnergyParametersEntry 5 }=20 =20 eoEnergyParametersIntervalWindow OBJECT-TYPE=20 SYNTAX TimeInterval=20 MAX-ACCESS read-create=20 STATUS current=20 DESCRIPTION=20 "The length of the duration window between the starting=20 time of one sliding window and the next starting time in=20 =20 =20 Expires June 13, 2014 [Page 42]=20= =20 =0C Internet-Draft December 2013=20= =20 hundredth of seconds, in order to compute the average of=20 eoEnergyConsumed, eoEnergyProvided measurements in the=20 eoEnergyTable table. This is valid only when the=20 eoEnergyParametersIntervalMode is sliding(2). The=20 eoEnergyParametersIntervalWindow value should be a multiple=20= of eoEnergyParametersSampleRate."=20 ::=3D { eoEnergyParametersEntry 6 }=20 =20 eoEnergyParametersSampleRate OBJECT-TYPE=20 SYNTAX Integer32=20 TOM: Should this be limited to positives only? UNITS "Milliseconds"=20 MAX-ACCESS read-create=20 STATUS current=20 DESCRIPTION=20 "The sampling rate, in milliseconds, at which the Energy=20= Object should poll power usage in order to compute the=20 average eoEnergyConsumed, eoEnergyProvided measurements=20= in the table eoEnergyTable. The Energy Object should=20 initially set this sampling rate to a reasonable value,=20= i.e., a compromise between intervals that will provide=20 good accuracy by not being too long, but not so short=20 that they affect the Energy Object performance by=20 requesting continuous polling. If the sampling rate is=20 unknown, the value 0 is reported. The sampling rate=20 should be selected so that=20 eoEnergyParametersIntervalWindow is a multiple of=20 eoEnergyParametersSampleRate."=20 DEFVAL { 1000 } =20 ::=3D { eoEnergyParametersEntry 7 }=20 =20 eoEnergyParametersStatus OBJECT-TYPE=20 SYNTAX RowStatus=20 MAX-ACCESS read-create=20 STATUS current=20 DESCRIPTION=20 "The status of this row. The eoEnergyParametersStatus is=20= used to start or stop energy usage logging. An entry=20 status may not be active(1) unless all objects in the=20 entry have an appropriate value. If this object is not=20 equal to active(1), all associated usage-data logged into=20= the eoEnergyTable will be deleted. The data can be=20 destroyed by setting up the eoEnergyParametersStatus to=20 destroy(2)."=20 ::=3D {eoEnergyParametersEntry 8 }=20 =20 eoEnergyTable OBJECT-TYPE=20 =20 =20 Expires June 13, 2014 [Page 43]=20= =20 =0C Internet-Draft December 2013=20= =20 SYNTAX SEQUENCE OF EoEnergyEntry =20 MAX-ACCESS not-accessible=20 STATUS current=20 DESCRIPTION=20 "This table lists Energy Object energy measurements. =20 Entries in this table are only created if the=20 corresponding value of object eoPowerMeasurementCaliber=20= is active(3), i.e., if the power is actually metered."=20 ::=3D { energyObjectMIBObjects 5 }=20 =20 eoEnergyEntry OBJECT-TYPE=20 SYNTAX EoEnergyEntry=20 MAX-ACCESS not-accessible=20 STATUS current=20 DESCRIPTION=20 "An entry describing energy measurements."=20 INDEX { eoEnergyParametersIndex, =20 eoEnergyCollectionStartTime }=20 ::=3D { eoEnergyTable 1 }=20 EoEnergyEntry ::=3D SEQUENCE {=20 eoEnergyCollectionStartTime TimeTicks,=20 eoEnergyConsumed Integer32, =20 eoEnergyProvided Integer32, =20 eoEnergyStored Integer32,=20 eoEnergyUnitMultiplier UnitMultiplier,=20 eoEnergyAccuracy Integer32,=20 eoEnergyMaxConsumed Integer32,=20 eoEnergyMaxProduced Integer32,=20 eoEnergyDiscontinuityTime TimeStamp =20 }=20 =20 eoEnergyCollectionStartTime OBJECT-TYPE=20 SYNTAX TimeTicks=20 UNITS "hundredths of seconds"=20 MAX-ACCESS not-accessible=20 STATUS current=20 DESCRIPTION=20 "The time (in hundredths of a second) since the=20 network management portion of the system was last=20 re-initialized, as specified in the sysUpTime [RFC3418].=20= This object specifies the start time of the energy=20 measurement sample. " =20 ::=3D { eoEnergyEntry 1 }=20 =20 eoEnergyConsumed OBJECT-TYPE=20 SYNTAX Integer32=20 TOM: Should this be limited to positives only? =20 Expires June 13, 2014 [Page 44]=20= =20 =0C Internet-Draft December 2013=20= =20 UNITS "Watt-hours"=20 MAX-ACCESS read-only=20 STATUS current=20 DESCRIPTION=20 "This object indicates the energy consumed in units of watt- hours for the Energy Object over the defined interval. =20 This value is specified in the common billing units of watt- hours with the magnitude of watt-hours (kW-Hr, MW-Hr, etc.) =20 indicated separately in eoEnergyUnitMultiplier." =20 ::=3D { eoEnergyEntry 2 }=20 =20 =20 eoEnergyProvided OBJECT-TYPE=20 SYNTAX Integer32=20 TOM: Should this be limited to positives only? UNITS "Watt-hours"=20 MAX-ACCESS read-only=20 STATUS current=20 DESCRIPTION=20 "This object indicates the energy produced in units of watt- hours for the Energy Object over the defined interval. =20 This value is specified in the common billing units of watt- hours with the magnitude of watt-hours (kW-Hr, MW-Hr, etc.) =20 indicated separately in eoEnergyUnitMultiplier." =20 ::=3D { eoEnergyEntry 3 }=20 =20 eoEnergyStored OBJECT-TYPE=20 SYNTAX Integer32=20 TOM: Should this be limited to positives only? UNITS "Watt-hours"=20 MAX-ACCESS read-only=20 STATUS current=20 DESCRIPTION=20 "This object indicates the resultant of the energy consumed and=20= energy produced for an Energy Object in units of watt-hours for =20= the Energy Object over the defined interval. This value is=20 specified in the common billing units of watt-hours =20 with the magnitude of watt-hours (kW-Hr, MW-Hr, etc.) =20 indicated separately in eoEnergyUnitMultiplier." =20 ::=3D { eoEnergyEntry 4 }=20 =20 eoEnergyUnitMultiplier OBJECT-TYPE=20 SYNTAX UnitMultiplier=20 MAX-ACCESS read-only=20 STATUS current=20 DESCRIPTION=20 "This object is the magnitude of watt-hours for the=20 energy field in eoEnergyConsumed, eoEnergyProvided,=20 eoEnergyStored, eoEnergyMaxConsumed, and=20 eoEnergyMaxProduced ." =20 =20 =20 Expires June 13, 2014 [Page 45]=20= =20 =0C Internet-Draft December 2013=20= =20 ::=3D { eoEnergyEntry 5 }=20 =20 =20 =20 eoEnergyAccuracy OBJECT-TYPE=20 SYNTAX Integer32 (0..10000)=20 UNITS "hundredths of percent"=20 MAX-ACCESS read-only=20 STATUS current=20 DESCRIPTION=20 "This object indicates a percentage value, in 100ths of a=20 percent, representing the presumed accuracy of Energy usage=20 reporting. eoEnergyAccuracy is applicable to all Energy=20 measurements in the eoEnergyTable.=20 =20 For example: 1010 means the reported usage is accurate to +/-=20 10.1 percent.=20 This value is zero if the accuracy is unknown."=20 =20 ::=3D { eoEnergyEntry 6 }=20 =20 eoEnergyMaxConsumed OBJECT-TYPE=20 SYNTAX Integer32=20 TOM: Should this be limited to positives only? UNITS "Watt-hours"=20 MAX-ACCESS read-only=20 STATUS current=20 DESCRIPTION=20 "This object is the maximum energy ever observed in=20 eoEnergyConsumed since the monitoring started. This value=20= is specified in the common billing units of watt-hours=20 with the magnitude of watt-hours (kW-Hr, MW-Hr, etc.)=20= indicated separately in eoEnergyUnitMultiplier." =20 ::=3D { eoEnergyEntry 7 }=20 =20 =20 eoEnergyMaxProduced OBJECT-TYPE=20 SYNTAX Integer32=20 TOM: Should this be a positive number only? UNITS "Watt-hours"=20 MAX-ACCESS read-only=20 STATUS current=20 DESCRIPTION=20 "This object is the maximum energy ever observed in=20 eoEnergyEnergyProduced since the monitoring started. This=20= value is specified in the units of watt-hours with the=20 magnitude of watt-hours (kW-Hr, MW-Hr, etc.) indicated=20= separately in eoEnergyEnergyUnitMultiplier." =20 ::=3D { eoEnergyEntry 8 }=20 =20 =20 =20 Expires June 13, 2014 [Page 46]=20= =20 =0C Internet-Draft December 2013=20= =20 =20 eoEnergyDiscontinuityTime OBJECT-TYPE=20 SYNTAX TimeStamp=20 MAX-ACCESS read-only=20 STATUS current=20 DESCRIPTION=20 =20 "The value of sysUpTime [RFC3418] on the most recent=20 occasion at which any one or more of this entity's energy=20= counters in this table suffered a discontinuity: =20 eoEnergyConsumed, eoEnergyProvided or eoEnergyStored. If=20= no such discontinuities have occurred since the last re- initialization of the local management subsystem, then=20 this object contains a zero value."=20 ::=3D { eoEnergyEntry 9 }=20 =20 -- Notifications=20 =20 =20 eoPowerEnableStatusNotification OBJECT-TYPE=20 SYNTAX TruthValue=20 MAX-ACCESS read-write=20 STATUS current=20 DESCRIPTION "This variable indicates whether the =20 system produces the following notifications:=20 TOM: notifications -> notification as there is only one. eoPowerStateChange.=20 =20 A false value will prevent these notifications=20 from being generated."=20 DEFVAL { false } =20 ::=3D { energyObjectMIBNotifs 1 }=20 =20 =20 eoPowerStateChange NOTIFICATION-TYPE=20 OBJECTS {eoPowerAdminState, eoPowerOperState,=20 eoPowerStateEnterReason}=20 STATUS current=20 DESCRIPTION=20 "The SNMP entity generates the eoPowerStateChange when=20= the value(s) of eoPowerAdminState or eoPowerOperState, =20= in the context of the Power State Set, have changed for=20= the Energy Object represented by the entPhysicalIndex."=20= ::=3D { energyObjectMIBNotifs 2 }=20 =20 -- Conformance=20 =20 energyObjectMIBCompliances OBJECT IDENTIFIER=20 ::=3D { energyObjectMIBConform 1 }=20 =20 =20 Expires June 13, 2014 [Page 47]=20= =20 =0C Internet-Draft December 2013=20= =20 =20 energyObjectMIBGroups OBJECT IDENTIFIER=20 ::=3D { energyObjectMIBConform 2 }=20 =20 =20 energyObjectMIBFullCompliance MODULE-COMPLIANCE=20 STATUS current=20 DESCRIPTION=20 "When this MIB is implemented with support for=20 read-create, then such an implementation can =20 claim full compliance. Such devices can then =20 be both monitored and configured with this MIB.=20 =20 Module Compliance of [RFC6933]=20 with respect to entity4CRCompliance should =20 be supported which requires implementation =20 of 3 MIB objects (entPhysicalIndex, =20 entPhysicalName and entPhysicalUUID)."=20 =20 MODULE -- this module=20 MANDATORY-GROUPS {=20 energyObjectMIBTableGroup,=20 energyObjectMIBStateTableGroup,=20 eoPowerEnableStatusNotificationGroup,=20 energyObjectMIBNotifGroup=20 }=20 =20 GROUP energyObjectMIBEnergyTableGroup =20 =20 DESCRIPTION "A compliant implementation does not =20 have to implement. =20 =20 Module Compliance of [RFC6933] =20 with respect to entity4CRCompliance should =20 be supported which requires implementation =20 of 3 MIB objects (entPhysicalIndex, =20 entPhysicalName and entPhysicalUUID)."=20 =20 =20 GROUP energyObjectMIBEnergyParametersTableGroup=20 =20 DESCRIPTION "A compliant implementation does not =20 have to implement. =20 =20 Module Compliance of {RFC6933] =20 with respect to entity4CRCompliance should =20 be supported which requires implementation =20 of 3 MIB objects (entPhysicalIndex, =20 =20 =20 Expires June 13, 2014 [Page 48]=20= =20 =0C Internet-Draft December 2013=20= =20 entPhysicalName and entPhysicalUUID)."=20 =20 =20 GROUP energyObjectMIBMeterCapabilitiesTableGroup =20 =20 DESCRIPTION "A compliant implementation does not =20 have to implement. =20 =20 Module Compliance of [RFC6933] =20 with respect to entity4CRCompliance should =20 be supported which requires implementation =20 of 3 MIB objects (entPhysicalIndex, =20 entPhysicalName and entPhysicalUUID)."=20 =20 =20 ::=3D { energyObjectMIBCompliances 1 }=20 =20 energyObjectMIBReadOnlyCompliance MODULE-COMPLIANCE=20 STATUS current=20 DESCRIPTION=20 "When this MIB is implemented without support for=20 read-create (i.e. in read-only mode), then such an =20 implementation can claim read-only compliance. Such a =20= device can then be monitored but cannot be =20 configured with this MIB. =20 =20 Module Compliance of [RFC6933] =20 with respect to entity4CRCompliance should =20 be supported which requires implementation =20 of 3 MIB objects (entPhysicalIndex, =20 entPhysicalName and entPhysicalUUID)."=20 =20 MODULE -- this module=20 MANDATORY-GROUPS {=20 energyObjectMIBTableGroup,=20 energyObjectMIBStateTableGroup, =20 energyObjectMIBNotifGroup=20 }=20 =20 OBJECT eoPowerOperState=20 MIN-ACCESS read-only=20 DESCRIPTION=20 "Write access is not required." =20 ::=3D { energyObjectMIBCompliances 2 }=20 =20 -- Units of Conformance=20 =20 energyObjectMIBTableGroup OBJECT-GROUP=20 =20 =20 Expires June 13, 2014 [Page 49]=20= =20 =0C Internet-Draft December 2013=20= =20 OBJECTS {=20 eoPower,=20 eoPowerNameplate,=20 eoPowerUnitMultiplier,=20 eoPowerAccuracy, =20= eoPowerMeasurementCaliber,=20 eoPowerCurrentType,=20 eoPowerOrigin,=20 eoPowerAdminState,=20 eoPowerOperState, =20 eoPowerStateEnterReason = =20 } =20 STATUS current=20 DESCRIPTION=20 "This group contains the collection of all the objects=20= related to the Energy Object."=20 ::=3D { energyObjectMIBGroups 1 }=20 =20 energyObjectMIBStateTableGroup OBJECT-GROUP=20 OBJECTS {=20 eoPowerStateMaxPower,=20 eoPowerStatePowerUnitMultiplier,=20 eoPowerStateTotalTime, = =20 eoPowerStateEnterCount =20 }=20 STATUS current=20 DESCRIPTION=20 "This group contains the collection of all the =20= objects related to the Power State."=20 ::=3D { energyObjectMIBGroups 2 }=20 =20 =20 energyObjectMIBEnergyParametersTableGroup OBJECT-GROUP=20 OBJECTS {=20 =20 eoEnergyParametersIndex,=20 eoEnergyParametersIntervalLength,=20 eoEnergyParametersIntervalNumber,=20 eoEnergyParametersIntervalMode,=20 eoEnergyParametersIntervalWindow,=20 eoEnergyParametersSampleRate,=20 eoEnergyParametersStatus=20 } =20 STATUS current=20 DESCRIPTION=20 "This group contains the collection of all the objects=20= related to the configuration of the Energy Table."=20 =20 =20 Expires June 13, 2014 [Page 50]=20= =20 =0C Internet-Draft December 2013=20= =20 ::=3D { energyObjectMIBGroups 3 }=20 =20 =20 energyObjectMIBEnergyTableGroup OBJECT-GROUP=20 OBJECTS {=20 -- Note that object =20 -- eoEnergyCollectionStartTime is not=20 -- included since it is not-accessible=20= =20 eoEnergyConsumed,=20 eoEnergyProvided,=20 eoEnergyStored, =20 eoEnergyUnitMultiplier,=20 eoEnergyAccuracy, =20 eoEnergyMaxConsumed,=20 eoEnergyMaxProduced,=20 eoEnergyDiscontinuityTime =20 } =20 STATUS current=20 DESCRIPTION=20 "This group contains the collection of all the objects=20= related to the Energy Table."=20 ::=3D { energyObjectMIBGroups 4 }=20 =20 =20 energyObjectMIBMeterCapabilitiesTableGroup OBJECT-GROUP=20 OBJECTS {=20 eoMeterCapability =20 } =20 STATUS current=20 DESCRIPTION=20 "This group contains the object indicating the=20 capability of the Energy Object"=20 ::=3D { energyObjectMIBGroups 5 }=20 =20 eoPowerEnableStatusNotificationGroup OBJECT-GROUP=20 OBJECTS { eoPowerEnableStatusNotification }=20 STATUS current=20 DESCRIPTION "The collection of objects which are used=20= to enable notification."=20 ::=3D { energyObjectMIBGroups 6 }=20 =20 energyObjectMIBNotifGroup NOTIFICATION-GROUP=20 NOTIFICATIONS {=20 eoPowerStateChange=20 }=20 STATUS current=20 DESCRIPTION "This group contains the notifications for=20 =20 =20 Expires June 13, 2014 [Page 51]=20= =20 =0C Internet-Draft December 2013=20= =20 the power and energy monitoring MIB Module."=20= ::=3D { energyObjectMIBGroups 7 }=20 =20 =20 END=20 =20 =20 =20 -- ************************************************************=20= -- =20 -- This MIB module is used to monitor power attributes of =20 -- networked devices with measurements.=20 --=20 -- This MIB module is an extension of energyObjectMIB module.=20 -- =20 -- *************************************************************=20= =20 =20 POWER-ATTRIBUTES-MIB DEFINITIONS ::=3D BEGIN=20 =20 IMPORTS=20 MODULE-IDENTITY,=20 OBJECT-TYPE,=20 mib-2,=20 Integer32 =20 FROM SNMPv2-SMI=20 MODULE-COMPLIANCE,=20 OBJECT-GROUP=20 FROM SNMPv2-CONF=20 UnitMultiplier =20 FROM ENERGY-OBJECT-MIB=20 OwnerString=20 FROM RMON-MIB=20 entPhysicalIndex=20 FROM ENTITY-MIB; =20 =20 powerAttributesMIB MODULE-IDENTITY=20 =20 LAST-UPDATED "201312130000Z" -- 13 December 2013 =20 =20 ORGANIZATION "IETF EMAN Working Group"=20 CONTACT-INFO=20 "WG charter:=20 http://datatracker.ietf.org/wg/eman/charter/=20 =20 Mailing Lists:=20 General Discussion: eman@ietf.org=20 =20 =20 Expires June 13, 2014 [Page 52]=20= =20 =0C Internet-Draft December 2013=20= =20 To Subscribe: =20 https://www.ietf.org/mailman/listinfo/eman=20 Archive: =20 http://www.ietf.org/mail-archive/web/eman=20 Editors:=20 Mouli Chandramouli=20 Cisco Systems, Inc.=20 Sarjapur Outer Ring Road=20 Bangalore 560103=20 IN=20 Phone: +91 80 4429 2409 =20 Email: moulchan@cisco.com=20 Benoit Claise=20 Cisco Systems, Inc.=20 De Kleetlaan 6a b1=20 Degem 1831=20 Belgium=20 Phone: +32 2 704 5622=20 Email: bclaise@cisco.com=20 Brad Schoening=20 44 Rivers Edge Drive=20 Little Silver, NJ 07739=20 US=20 Email: brad.schoening@verizon.net=20 Juergen Quittek=20 NEC Europe Ltd.=20 NEC Laboratories Europe=20 Network Research Division=20 Kurfuersten-Anlage 36=20 Heidelberg 69115=20 DE=20 Phone: +49 6221 4342-115=20 Email: quittek@neclab.eu=20 Thomas Dietz=20 NEC Europe Ltd.=20 NEC Laboratories Europe=20 Network Research Division=20 Kurfuersten-Anlage 36=20 69115 Heidelberg=20 DE=20 =20 =20 Expires June 13, 2014 [Page 53]=20= =20 =0C Internet-Draft December 2013=20= =20 Phone: +49 6221 4342-128=20 Email: Thomas.Dietz@nw.neclab.eu"=20 DESCRIPTION=20 "This MIB is used to report AC power attributes in=20 devices. The table is a sparse augmentation of the=20 eoPowerTable table from the energyObjectMIB module.=20= Both three-phase and single-phase power=20 configurations are supported. =20 =20 As a requirement for this MIB module,=20 [EMAN-AWARE-MIB] should be implemented. =20 =20 Module Compliance of ENTITY-MIB v4=20 with respect to entity4CRCompliance should =20 be supported which requires implementation =20 of 3 MIB objects (entPhysicalIndex, =20 entPhysicalName and entPhysicalUUID)."=20 =20 REVISION=20 =20 "201312130000Z" -- 13 December 2013=20 =20 DESCRIPTION=20 "Initial version, published as RFC YYY."=20 =20 ::=3D { energyMIB 4 }=20 =20 =20 powerAttributesMIBConform OBJECT IDENTIFIER=20 ::=3D { powerAttributesMIB 0 }=20 =20 =20 powerAttributesMIBObjects OBJECT IDENTIFIER=20 ::=3D { powerAttributesMIB 1 }=20 =20 -- Objects=20 =20 =20 eoACPwrAttributesTable OBJECT-TYPE=20 SYNTAX SEQUENCE OF EoACPwrAttributesEntry=20 MAX-ACCESS not-accessible=20 STATUS current=20 DESCRIPTION=20 "This table defines power attributes measurements for=20 supported entPhysicalIndex entities. It is a sparse=20 extension of the eoPowerTable."=20 ::=3D { powerAttributesMIBObjects 1 }=20 =20 =20 Expires June 13, 2014 [Page 54]=20= =20 =0C Internet-Draft December 2013=20= =20 =20 eoACPwrAttributesEntry OBJECT-TYPE=20 SYNTAX EoACPwrAttributesEntry=20 MAX-ACCESS not-accessible=20 STATUS current=20 DESCRIPTION=20 "This is a sparse extension of the eoPowerTable with=20 entries for power attributes measurements or=20 configuration. Each measured value corresponds to an=20 attribute in IEC 61850-7-4 for non-phase measurements=20 within the object MMUX."=20 =20 INDEX {entPhysicalIndex }=20 ::=3D { eoACPwrAttributesTable 1 }=20 =20 EoACPwrAttributesEntry ::=3D SEQUENCE {=20 eoACPwrAttributesConfiguration INTEGER, =20 eoACPwrAttributesAvgVoltage Integer32,=20 eoACPwrAttributesAvgCurrent Integer32,=20 eoACPwrAttributesFrequency Integer32,=20 eoACPwrAttributesPowerUnitMultiplier UnitMultiplier,=20 eoACPwrAttributesPowerAccuracy Integer32,=20 eoACPwrAttributesTotalActivePower Integer32,=20 eoACPwrAttributesTotalReactivePower Integer32,=20 eoACPwrAttributesTotalApparentPower Integer32,=20 eoACPwrAttributesTotalPowerFactor Integer32, =20 eoACPwrAttributesThdAmpheres Integer32,=20 eoACPwrAttributesThdVoltage Integer32=20 }=20 =20 eoACPwrAttributesConfiguration OBJECT-TYPE=20 SYNTAX INTEGER { =20 sngl(1), =20 del(2), =20 wye(3)=20 }=20 MAX-ACCESS read-only=20 STATUS current=20 DESCRIPTION=20 "Configuration describes the physical configurations=20 of the power supply lines:=20 =20 * alternating current, single phase (SNGL)=20 * alternating current, three phase delta (DEL)=20 * alternating current, three phase Y (WYE)=20 =20 Three-phase configurations can be either connected in=20= a triangular delta (DEL) or star Y (WYE) system. WYE=20= =20 =20 Expires June 13, 2014 [Page 55]=20= =20 =0C Internet-Draft December 2013=20= =20 systems have a shared neutral voltage, while DEL=20 systems do not. Each phase is offset 120 degrees to=20 each other."=20 ::=3D { eoACPwrAttributesEntry 1 }=20 =20 eoACPwrAttributesAvgVoltage OBJECT-TYPE=20 SYNTAX Integer32=20 UNITS "0.1 Volt AC"=20 MAX-ACCESS read-only=20 STATUS current=20 DESCRIPTION=20 "A measured value for average of the voltage measured=20 over an integral number of AC cycles For a 3-phase=20 system, this is the average voltage (V1+V2+V3)/3. IEC=20= 61850-7-4 measured value attribute 'Vol'"=20 ::=3D { eoACPwrAttributesEntry 2 }=20 =20 eoACPwrAttributesAvgCurrent OBJECT-TYPE=20 SYNTAX Integer32=20 TOM: Should this be limited to positive numbers only? I can't see how = you could have negative avg amps. UNITS "Ampheres"=20 MAX-ACCESS read-only=20 STATUS current=20 DESCRIPTION=20 "A measured value of the current per phase. IEC 61850- 7-4 attribute 'Amp'"=20 ::=3D { eoACPwrAttributesEntry 3 }=20 =20 eoACPwrAttributesFrequency OBJECT-TYPE=20 SYNTAX Integer32 (4500..6500) -- UNITS 0.01 Hertz=20= UNITS "hertz"=20 MAX-ACCESS read-only=20 STATUS current=20 DESCRIPTION=20 "A measured value for the basic frequency of the AC=20 circuit. IEC 61850-7-4 attribute 'Hz'."=20 ::=3D { eoACPwrAttributesEntry 4 }=20 =20 eoACPwrAttributesPowerUnitMultiplier OBJECT-TYPE=20 SYNTAX UnitMultiplier=20 MAX-ACCESS read-only=20 STATUS current=20 DESCRIPTION=20 "The magnitude of watts for the usage value in=20 eoACPwrAttributesTotalActivePower,=20 eoACPwrAttributesTotalReactivePower =20 and eoACPwrAttributesTotalApparentPower measurements. =20= For 3-phase power systems, this will also include =20 =20 =20 Expires June 13, 2014 [Page 56]=20= =20 =0C Internet-Draft December 2013=20= =20 eoACPwrAttributesPhaseActivePower,=20 eoACPwrAttributesPhaseReactivePower and=20 eoACPwrAttributesPhaseApparentPower" =20 ::=3D { eoACPwrAttributesEntry 5 }=20 =20 eoACPwrAttributesPowerAccuracy OBJECT-TYPE=20 SYNTAX Integer32 (0..10000)=20 UNITS "hundredths of percent"=20 MAX-ACCESS read-only=20 STATUS current=20 DESCRIPTION=20 "This object indicates a percentage value, in 100ths of=20= a percent, representing the presumed accuracy of=20 active, reactive, and apparent power usage reporting.=20 For example: 1010 means the reported usage is accurate=20= to +/- 10.1 percent. This value is zero if the=20 accuracy is unknown.=20 =20 ANSI and IEC define the following accuracy classes for=20= power measurement: IEC 62053-22 & 60044-1 class 0.1,=20 0.2, 0.5, 1 & 3.=20 ANSI C12.20 class 0.2 & 0.5"=20 ::=3D { eoACPwrAttributesEntry 6 }=20 =20 eoACPwrAttributesTotalActivePower OBJECT-TYPE=20 SYNTAX Integer32=20 TOM: Should this be limited to positives only? UNITS " watts"=20 MAX-ACCESS read-only=20 STATUS current=20 DESCRIPTION=20 "A measured value of the actual power delivered to or=20 consumed by the load. IEC 61850-7-4 attribute 'TotW'."=20= ::=3D { eoACPwrAttributesEntry 7 }=20 =20 eoACPwrAttributesTotalReactivePower OBJECT-TYPE=20 SYNTAX Integer32=20 TOM: Should this be limited to positive numbers only? I can't see how = you could have negative amps. UNITS "volt-amperes reactive"=20 MAX-ACCESS read-only=20 STATUS current=20 DESCRIPTION=20 "A mesured value of the reactive portion of the=20 apparent power. IEC 61850-7-4 attribute 'TotVAr'."=20 ::=3D { eoACPwrAttributesEntry 8 }=20 =20 eoACPwrAttributesTotalApparentPower OBJECT-TYPE=20 SYNTAX Integer32 =20 TOM: Should this be limited to positive numbers only? I can't see how = you could have negative amps. UNITS "volt-amperes"=20 MAX-ACCESS read-only=20 =20 =20 Expires June 13, 2014 [Page 57]=20= =20 =0C Internet-Draft December 2013=20= =20 STATUS current=20 DESCRIPTION=20 "A measured value of the voltage and current which=20 determines the apparent power. The apparent power is=20 the vector sum of real and reactive power. =20 =20 Note: watts and volt-ampheres are equivalent units and=20= may be combined. IEC 61850-7-4 attribute 'TotVA'."=20 ::=3D { eoACPwrAttributesEntry 9 }=20 =20 eoACPwrAttributesTotalPowerFactor OBJECT-TYPE=20 SYNTAX Integer32 (-10000..10000)=20 UNITS "hundredths of percent"=20 MAX-ACCESS read-only=20 STATUS current=20 DESCRIPTION=20 "A measured value ratio of the real power flowing to=20 the load versus the apparent power. It is dimensionless=20= and expressed here as a percentage value in 100ths of a=20= percent. A power factor of 100% indicates there is no=20 inductance load and thus no reactive power. Power=20 Factor can be positive or negative, where the sign=20 should be in lead/lag (IEEE) form. IEC 61850-7-4=20 attribute 'TotPF'."=20 ::=3D { eoACPwrAttributesEntry 10 }=20 =20 eoACPwrAttributesThdAmpheres OBJECT-TYPE=20 SYNTAX Integer32 (0..10000)=20 UNITS "hundredths of percent"=20 MAX-ACCESS read-only=20 STATUS current=20 DESCRIPTION=20 "A calculated value for the current total harmonic=20 distortion (THD). Method of calculation is not=20 specified. IEC 61850-7-4 attribute 'ThdAmp'."=20 ::=3D { eoACPwrAttributesEntry 11 }=20 =20 eoACPwrAttributesThdVoltage OBJECT-TYPE=20 SYNTAX Integer32 (0..10000)=20 UNITS "hundredths of percent"=20 MAX-ACCESS read-only=20 STATUS current=20 DESCRIPTION=20 "A calculated value for the voltage total harmonic=20 distortion (THD). Method of calculation is not=20 specified. IEC 61850-7-4 attribute 'ThdVol'."=20 ::=3D { eoACPwrAttributesEntry 12 }=20 =20 =20 =20 Expires June 13, 2014 [Page 58]=20= =20 =0C Internet-Draft December 2013=20= =20 eoACPwrAttributesPhaseTable OBJECT-TYPE=20 SYNTAX SEQUENCE OF EoACPwrAttributesPhaseEntry=20 MAX-ACCESS not-accessible=20 STATUS current=20 DESCRIPTION=20 "This table describes 3-phase power attributes=20 measurements. It is a sparse extension of the=20 eoACPwrAttributesTable."=20 ::=3D { powerAttributesMIBObjects 2 }=20 =20 =20 eoACPwrAttributesPhaseEntry OBJECT-TYPE=20 SYNTAX EoACPwrAttributesPhaseEntry=20 MAX-ACCESS not-accessible=20 STATUS current=20 DESCRIPTION=20 "An entry describes common 3-phase power attributes=20 measurements.=20 =20 This optional table describes 3-phase power attributes=20= measurements, with three entries for each supported=20 entPhysicalIndex entity. Entities having single phase=20= power shall not have any entities. =20 =20 This table describes attributes common to both WYE and=20= DEL. Entities having single phase power shall not have=20= any entries here. It is a sparse extension of the=20 eoACPwrAttributesTable. =20 =20 These attributes correspond to IEC 61850-7.4 MMXU phase=20= measurements."=20 INDEX { entPhysicalIndex, eoPhaseIndex }=20 ::=3D { eoACPwrAttributesPhaseTable 1 }=20 =20 EoACPwrAttributesPhaseEntry ::=3D SEQUENCE {=20 eoPhaseIndex Integer32,=20 eoACPwrAttributesPhaseAvgCurrent Integer32,=20 eoACPwrAttributesPhaseActivePower Integer32,=20 eoACPwrAttributesPhaseReactivePower Integer32,=20 eoACPwrAttributesPhaseApparentPower Integer32,=20 eoACPwrAttributesPhasePowerFactor Integer32, =20= eoACPwrAttributesPhaseImpedance Integer32 =20 }=20 =20 eoPhaseIndex OBJECT-TYPE=20 SYNTAX Integer32 (0..359)=20 MAX-ACCESS not-accessible=20 STATUS current=20 =20 =20 Expires June 13, 2014 [Page 59]=20= =20 =0C Internet-Draft December 2013=20= =20 DESCRIPTION=20 "A phase angle typically corresponding to 0, 120, 240."=20= ::=3D { eoACPwrAttributesPhaseEntry 1 }=20 =20 eoACPwrAttributesPhaseAvgCurrent OBJECT-TYPE=20 SYNTAX Integer32=20 TOM: Should this be limited to positives only? Can't have negative = current. UNITS "Ampheres"=20 MAX-ACCESS read-only=20 STATUS current=20 DESCRIPTION=20 "A measured value of the current per phase. IEC 61850- 7-4 attribute 'A'"=20 ::=3D { eoACPwrAttributesPhaseEntry 2 }=20 =20 eoACPwrAttributesPhaseActivePower OBJECT-TYPE=20 SYNTAX Integer32=20 TOM: Should this be limited to positives only? UNITS " watts"=20 MAX-ACCESS read-only=20 STATUS current=20 DESCRIPTION=20 "A measured value of the actual power delivered to or=20 consumed by the load. IEC 61850-7-4 attribute 'W'"=20 ::=3D { eoACPwrAttributesPhaseEntry 3 }=20 =20 eoACPwrAttributesPhaseReactivePower OBJECT-TYPE=20 SYNTAX Integer32=20 TOM: Should this be limited to positives only? UNITS "volt-amperes reactive"=20 MAX-ACCESS read-only=20 STATUS current=20 DESCRIPTION=20 "A measured value of the reactive portion of the=20 apparent power. IEC 61850-7-4 attribute 'VAr'"=20 ::=3D { eoACPwrAttributesPhaseEntry 4 }=20 =20 eoACPwrAttributesPhaseApparentPower OBJECT-TYPE=20 SYNTAX Integer32 =20 TOM: Should this be limited to positives only? UNITS "volt-amperes"=20 MAX-ACCESS read-only=20 STATUS current=20 DESCRIPTION=20 "A measured value of the voltage and current determines=20= the apparent power. Active plus reactive power equals=20= the total apparent power.=20 =20 Note: Watts and volt-ampheres are equivalent units and=20= may be combined. IEC 61850-7-4 attribute 'VA'."=20 ::=3D { eoACPwrAttributesPhaseEntry 5 }=20 =20 =20 =20 Expires June 13, 2014 [Page 60]=20= =20 =0C Internet-Draft December 2013=20= =20 eoACPwrAttributesPhasePowerFactor OBJECT-TYPE=20 SYNTAX Integer32 (-10000..10000)=20 UNITS "hundredths of percent"=20 MAX-ACCESS read-only=20 STATUS current=20 DESCRIPTION=20 "A measured value ratio of the real power flowing to=20 the load versus the apparent power for this phase. IEC=20= 61850-7-4 attribute 'PF'. Power Factor can be positive=20= or negative where the sign should be in lead/lag (IEEE)=20= form."=20 ::=3D { eoACPwrAttributesPhaseEntry 6 }=20 =20 eoACPwrAttributesPhaseImpedance OBJECT-TYPE=20 SYNTAX Integer32 =20 TOM: Should this be limited to positives only? UNITS "volt-amperes"=20 MAX-ACCESS read-only=20 STATUS current=20 DESCRIPTION=20 "A measured value of the impedance. IEC 61850-7-4 attribute=20 'Z'."=20 ::=3D { eoACPwrAttributesPhaseEntry 7 }=20 =20 eoACPwrAttributesDelPhaseTable OBJECT-TYPE=20 SYNTAX SEQUENCE OF EoACPwrAttributesDelPhaseEntry =20= MAX-ACCESS not-accessible=20 STATUS current=20 DESCRIPTION=20 "This table describes DEL configuration phase-to-phase=20 power attributes measurements. This is a sparse=20 extension of the eoACPwrAttributesPhaseTable."=20 ::=3D { powerAttributesMIBObjects 3 }=20 =20 eoACPwrAttributesDelPhaseEntry OBJECT-TYPE=20 SYNTAX EoACPwrAttributesDelPhaseEntry=20 MAX-ACCESS not-accessible=20 STATUS current=20 DESCRIPTION=20 "An entry describes power attributes attributes of a=20 phase in a DEL 3-phase power system. Voltage=20 measurements are provided both relative to each other=20 and zero.=20 =20 Measured values are from IEC 61850-7-2 MMUX and THD from=20= MHAI objects.=20 =20 =20 =20 Expires June 13, 2014 [Page 61]=20= =20 =0C Internet-Draft December 2013=20= =20 For phase-to-phase measurements, the eoPhaseIndex is=20 compared against the following phase at +120 degrees. =20 Thus, the possible values are:=20 =20 eoPhaseIndex Next Phase Angle=20 0 120=20 120 240=20 240 0 =20 "=20 INDEX { entPhysicalIndex, eoPhaseIndex}=20 ::=3D { eoACPwrAttributesDelPhaseTable 1}=20 =20 EoACPwrAttributesDelPhaseEntry ::=3D SEQUENCE {=20 eoACPwrAttributesDelPhaseToNextPhaseVoltage Integer32,=20= eoACPwrAttributesDelThdPhaseToNextPhaseVoltage Integer32,=20= eoACPwrAttributesDelThdCurrent Integer32=20 }=20 =20 eoACPwrAttributesDelPhaseToNextPhaseVoltage OBJECT-TYPE=20 SYNTAX Integer32=20 TOM: Should this be limited to positives only? UNITS "0.1 Volt AC"=20 MAX-ACCESS read-only=20 STATUS current=20 DESCRIPTION=20 "A measured value of phase to next phase voltages, where=20= the next phase is IEC 61850-7-4 attribute 'PPV'."=20 ::=3D { eoACPwrAttributesDelPhaseEntry 2 }=20 =20 eoACPwrAttributesDelThdPhaseToNextPhaseVoltage OBJECT-TYPE=20 SYNTAX Integer32 (0..10000)=20 TOM: Should this be limited to positives only? UNITS "hundredths of percent"=20 MAX-ACCESS read-only=20 STATUS current=20 DESCRIPTION=20 "A calculated value for the voltage total harmonic=20 disortion for phase to next phase. Method of calculation=20= is not specified. IEC 61850-7-4 attribute 'ThdPPV'."=20 ::=3D { eoACPwrAttributesDelPhaseEntry 3 }=20 =20 eoACPwrAttributesDelThdCurrent OBJECT-TYPE=20 SYNTAX Integer32 (0..10000)=20 UNITS "hundredths of percent"=20 MAX-ACCESS read-only=20 STATUS current=20 DESCRIPTION =20 "A calculated value for the voltage total harmonic=20 disortion (THD) for phase to phase. Method of=20 calculation is not specified. =20 =20 =20 Expires June 13, 2014 [Page 62]=20= =20 =0C Internet-Draft December 2013=20= =20 IEC 61850-7-4 attribute 'ThdPPV'."=20 ::=3D { eoACPwrAttributesDelPhaseEntry 4 }=20 =20 eoACPwrAttributesWyePhaseTable OBJECT-TYPE=20 SYNTAX SEQUENCE OF EoACPwrAttributesWyePhaseEntry =20= MAX-ACCESS not-accessible=20 STATUS current=20 DESCRIPTION=20 "This table describes WYE configuration phase-to-neutral=20= power attributes measurements. This is a sparse=20 extension of the eoACPwrAttributesPhaseTable."=20 ::=3D { powerAttributesMIBObjects 4 }=20 =20 eoACPwrAttributesWyePhaseEntry OBJECT-TYPE=20 SYNTAX EoACPwrAttributesWyePhaseEntry=20 MAX-ACCESS not-accessible=20 STATUS current=20 DESCRIPTION=20 "This table describes measurements of WYE configuration=20= TOM: would be nice to decode WHY for the reader. with phase to neutral power attributes attributes. Three=20= entries are required for each supported entPhysicalIndex=20= entry. Voltage measurements are relative to neutral.=20 =20 This is a sparse extension of the=20 eoACPwrAttributesPhaseTable.=20 =20 Each entry describes power attributes attributes of one=20= phase of a WYE 3-phase power system.=20 =20 Measured values are from IEC 61850-7-2 MMUX and THD from=20= MHAI objects."=20 INDEX { entPhysicalIndex, eoPhaseIndex }=20 ::=3D { eoACPwrAttributesWyePhaseTable 1}=20 =20 EoACPwrAttributesWyePhaseEntry ::=3D SEQUENCE {=20 eoACPwrAttributesWyePhaseToNeutralVoltage Integer32,=20 eoACPwrAttributesWyePhaseCurrent Integer32,=20= eoACPwrAttributesWyeThdPhaseToNeutralVoltage Integer32=20= }=20 =20 eoACPwrAttributesWyePhaseToNeutralVoltage OBJECT-TYPE=20 SYNTAX Integer32=20 UNITS "0.1 Volt AC"=20 MAX-ACCESS read-only=20 STATUS current=20 DESCRIPTION=20 "A measured value of phase to neutral voltage. IEC=20 61850-7-4 attribute 'PhV'."=20 =20 =20 Expires June 13, 2014 [Page 63]=20= =20 =0C Internet-Draft December 2013=20= =20 ::=3D { eoACPwrAttributesWyePhaseEntry 1 }=20 =20 eoACPwrAttributesWyePhaseCurrent OBJECT-TYPE=20 SYNTAX Integer32=20 UNITS "0.1 ampheres AC"=20 MAX-ACCESS read-only=20 STATUS current=20 DESCRIPTION=20 "A measured value of phase currents. IEC 61850-7-4=20 attribute 'A'."=20 ::=3D { eoACPwrAttributesWyePhaseEntry 2 }=20 =20 eoACPwrAttributesWyeThdPhaseToNeutralVoltage OBJECT-TYPE=20 SYNTAX Integer32 (0..10000)=20 UNITS "hundredths of percent"=20 MAX-ACCESS read-only=20 STATUS current=20 DESCRIPTION=20 "A calculated value of the voltage total harmonic=20 distortion (THD) for phase to neutral. IEC 61850-7-4=20 attribute 'ThdPhV'."=20 ::=3D { eoACPwrAttributesWyePhaseEntry 3 }=20 =20 -- Conformance=20 =20 =20 powerAttributesMIBCompliances OBJECT IDENTIFIER=20 ::=3D { powerAttributesMIB 2 }=20 =20 powerAttributesMIBGroups OBJECT IDENTIFIER=20 ::=3D { powerAttributesMIB 3 }=20 =20 =20 powerAttributesMIBFullCompliance MODULE-COMPLIANCE=20 STATUS current=20 DESCRIPTION=20 "When this MIB is implemented with support for read-create, = =20 then such an implementation can claim full compliance. =20 Such devices can then be both monitored and configured with = =20 this MIB. =20 =20 Module Compliance of [RFC6933] with respect to=20 entity4CRCompliance should be supported which requires=20 implementation of 3 MIB objects (entPhysicalIndex,=20 entPhysicalName and entPhysicalUUID)."=20 =20 =20 MODULE -- this module=20 =20 =20 Expires June 13, 2014 [Page 64]=20= =20 =0C Internet-Draft December 2013=20= =20 MANDATORY-GROUPS {=20 powerACPwrAttributesMIBTableGroup=20 }=20 =20 =20 GROUP powerACPwrAttributesOptionalMIBTableGroup=20 DESCRIPTION=20 "A compliant implementation does not have =20 to implement."=20 =20 =20 GROUP powerACPwrAttributesPhaseMIBTableGroup=20 DESCRIPTION=20 "A compliant implementation does not have to=20 implement."=20 =20 GROUP powerACPwrAttributesDelPhaseMIBTableGroup =20= DESCRIPTION=20 "A compliant implementation does not have to=20 implement."=20 =20 GROUP powerACPwrAttributesWyePhaseMIBTableGroup=20 DESCRIPTION=20 "A compliant implementation does not have to=20 implement."=20 =20 =20 ::=3D { powerAttributesMIBCompliances 1 }=20 =20 =20 =20 -- Units of Conformance=20 =20 powerACPwrAttributesMIBTableGroup OBJECT-GROUP=20 OBJECTS {=20 -- Note that object entPhysicalIndex is NOT =20 -- included since it is not-accessible=20 =20 eoACPwrAttributesAvgVoltage,=20 eoACPwrAttributesAvgCurrent,=20 eoACPwrAttributesFrequency,=20 eoACPwrAttributesPowerUnitMultiplier,=20 eoACPwrAttributesPowerAccuracy,=20 eoACPwrAttributesTotalActivePower,=20 eoACPwrAttributesTotalReactivePower,=20 eoACPwrAttributesTotalApparentPower,=20 eoACPwrAttributesTotalPowerFactor=20 } =20 =20 =20 Expires June 13, 2014 [Page 65]=20= =20 =0C Internet-Draft December 2013=20= =20 STATUS current=20 DESCRIPTION=20 "This group contains the collection of all the power=20 attributes objects related to the Energy Object."=20 ::=3D { powerAttributesMIBGroups 1 }=20 =20 powerACPwrAttributesOptionalMIBTableGroup OBJECT-GROUP=20 OBJECTS {=20 eoACPwrAttributesConfiguration,=20 eoACPwrAttributesThdAmpheres,=20 eoACPwrAttributesThdVoltage=20 } =20 STATUS current=20 DESCRIPTION=20 "This group contains the collection of all the power=20 attributes objects related to the Energy Object."=20 ::=3D { powerAttributesMIBGroups 2 }=20 =20 =20 powerACPwrAttributesPhaseMIBTableGroup OBJECT-GROUP=20 OBJECTS {=20 -- Note that object entPhysicalIndex is = =20 -- NOT included since it is =20 -- not-accessible=20 eoACPwrAttributesPhaseAvgCurrent,=20 eoACPwrAttributesPhaseActivePower,=20 eoACPwrAttributesPhaseReactivePower,=20 eoACPwrAttributesPhaseApparentPower,=20 eoACPwrAttributesPhasePowerFactor, =20 eoACPwrAttributesPhaseImpedance =20 }=20 STATUS current=20 DESCRIPTION=20 "This group contains the collection of all 3-phase power=20= attributes objects related to the Power State."=20 ::=3D { powerAttributesMIBGroups 3 }=20 =20 powerACPwrAttributesDelPhaseMIBTableGroup OBJECT-GROUP=20 OBJECTS {=20 -- Note that object entPhysicalIndex and =20 -- eoPhaseIndex are NOT included=20 -- since they are not-accessible=20 eoACPwrAttributesDelPhaseToNextPhaseVoltage ,=20 eoACPwrAttributesDelThdPhaseToNextPhaseVoltage,=20= eoACPwrAttributesDelThdCurrent=20 }=20 STATUS current=20 DESCRIPTION=20 =20 =20 Expires June 13, 2014 [Page 66]=20= =20 =0C Internet-Draft December 2013=20= =20 "This group contains the collection of all power=20 characteristic attributes of a phase in a DEL 3-phase=20 power system."=20 ::=3D { powerAttributesMIBGroups 4 }=20 =20 powerACPwrAttributesWyePhaseMIBTableGroup OBJECT-GROUP=20 OBJECTS {=20 -- Note that object entPhysicalIndex and =20= -- eoPhaseIndex are NOT included=20 -- since they are not-accessible=20 eoACPwrAttributesWyePhaseToNeutralVoltage,=20 eoACPwrAttributesWyePhaseCurrent,=20 eoACPwrAttributesWyeThdPhaseToNeutralVoltage=20 }=20 STATUS current=20 DESCRIPTION=20 "This group contains the collection of all WYE=20 configuration phase-to-neutral power attributes=20 measurements."=20 ::=3D { powerAttributesMIBGroups 5 }=20 =20 =20 END=20 =20 =20 =20 =20 =20 IANA-POWERSTATE-SET-MIB DEFINITIONS ::=3D BEGIN=20 IMPORTS=20 MODULE-IDENTITY, mib-2=20 FROM SNMPv2-SMI=20 TEXTUAL-CONVENTION=20 FROM SNMPv2-TC;=20 =20 ianaPowerStateSetMIB MODULE-IDENTITY=20 LAST-UPDATED "201312130000Z" -- December 13, 2013=20 ORGANIZATION "IANA"=20 CONTACT-INFO " =20 Internet Assigned Numbers Authority=20 Postal: ICANN=20 4676 Admiralty Way, Suite 330=20 Marina del Rey, CA 90292=20 Tel: +1-310-823-9358=20 EMail: iana&iana.org"=20 =20 =20 =20 =20 Expires June 13, 2014 [Page 67]=20= =20 =0C Internet-Draft December 2013=20= =20 DESCRIPTION=20 "This MIB module defines a TEXTUAL-CONVENTION that=20 describes the relationships between Energy Objects.=20 =20 Copyright (C) The IETF Trust (2013).=20 =20 The initial version of this MIB module was published in=20 RFC YYY; for full legal notices see the RFC itself.=20 Supplementary information may be available at=20 http://www.ietf.org/copyrights/ianamib.html"=20 =20 =20 REVISION "201312130000Z" -- December 13, 2013=20 DESCRIPTION "Initial version of this MIB as published in=20 RFC YYY." =20 ::=3D { energyMIB 5 }=20 =20 -- RFC Editor, please replace YYY with the IANA allocation=20 -- for this MIB module and YYY with the number of the =20 -- approved RFC=20 =20 -- Textual Conventions =20 =20 =20 IANAPowerStateSet::=3D TEXTUAL-CONVENTION =20 STATUS current =20 DESCRIPTION =20 =20 "IANAPowerState is a textual convention that describes =20= Power State Sets and Power State Set Values an Energy Object =20= supports. IANA has created a registry of Power State supported=20= by an Energy Object and IANA shall administer the list of =20 Power State Sets and Power States.=20 =20 The textual convention assumes that Power States in a power=20 state set are limited to 255 distinct values. For a Power=20 State Set S, the named number with the value S * 256 is=20 allocated to indicate the Power State set. For a Power State X=20= in the Power State S, the named number with the value S * 256=20= + X + 1 is allocated to represent the Power State."=20 =20 REFERENCE =20 "http://www.iana.org/assignments/eman =20 =20 RFC EDITOR NOTE: please change the previous URL if this is =20= not the correct one after IANA assigned it." =20 =20 SYNTAX INTEGER {=20 =20 =20 Expires June 13, 2014 [Page 68]=20= =20 =0C Internet-Draft December 2013=20= =20 =20 other(0), -- indicates other set=20 unknown(255), -- unknown =20 =20 ieee1621(256), -- indicates IEEE1621 set=20 ieee1621On(257),=20 ieee1621Off(258),=20 ieee1621Sleep(259),=20 =20 dmtf(512), -- indicates DMTF set=20 dmtfOn(513),=20 dmtfSleepLight(514),=20 dmtfSleepDeep(515),=20 dmtfOffHard(516),=20 dmtfOffSoft(517),=20 dmtfHibernate(518),=20 dmtfPowerOffSoft(519),=20 dmtfPowerOffHard(520),=20 dmtfMasterBusReset(521),=20 dmtfDiagnosticInterrapt(522),=20 dmtfOffSoftGraceful(523),=20 dmtfOffHardGraceful(524),=20 dmtfMasterBusResetGraceful(525),=20 dmtfPowerCycleOffSoftGraceful(526),=20 dmtfPowerCycleHardGraceful(527),=20 =20 eman(1024), -- indicates EMAN set=20 emanmechoff(1025),=20 emansoftoff(1026), =20 emanhibernate(1027), =20 emansleep(1028),=20 emanstandby(1029),=20 emanready(1030), =20 emanlowMinus(1031), =20 emanlow(1032),=20 emanmediumMinus(1033),=20 emanmedium(1034), =20 emanhighMinus(1035), =20 emanhigh(1036) =20 }=20 =20 END=20 =20 =20 11. Implementation Status =20 =20 =20 =20 Expires June 13, 2014 [Page 69]=20= =20 =0C Internet-Draft December 2013=20= =20 [Note to RFC Editor: Please remove this section and the=20 reference to [RFC6982] before publication.]=20 =20 This section records the status of known implementations of the=20= EMAN-Monitoring MIB at the time of posting of this Internet- Draft, and is based on a proposal described in [RFC6982].=20 =20 The description of implementations in this section is intended=20= to assist the IETF in its decision processes in progressing=20 drafts to RFCs. =20 =20 11.1. SNMP Research =20 =20 Organization: SNMP Research, Inc.=20 =20 Maturity: Prototype based upon early drafts of the MIBs. =20= We anticipate updating it to more recent =20 documents as development schedules allow.=20 =20 Coverage: Code was generated to implement all MIB objects = =20 in ENTITY-MIB (Version 4), =20 ENERGY-OBJECT-CONTEXT-MIB,=20 ENERGY-OBJECT-MIB,=20 POWER-ATTRIBUTES-MIB, =20 and BATTERY-MIB.=20 =20 Implementation experience: The documents are implementable.=20= =20 Comments: Technical comments about the =20 ENERGY-OBJECT-CONTEXT-MIB,=20 ENERGY-OBJECT-MIB, and =20 BATTERY-MIB =20 were submitted to the EMAN Working Group =20 E-mail list. =20 =20 Licensing: Proprietary, royalty licensing=20 =20 Contact: Alan Luchuk, luchuk at snmp.com=20 =20 URL: http://www.snmp.com/=20 =20 =20 11.2. Cisco Systems=20 =20 Organization: Cisco Systems, Inc.=20 =20 =20 =20 Expires June 13, 2014 [Page 70]=20= =20 =0C Internet-Draft December 2013=20= =20 Maturity: Prototype based upon early version drafts of =20= the MIBs. We anticipate updating the MIB =20 modules as when the drafts are updated. =20 =20 Coverage: Code was generated to implement all MIB objects=20= in the ENTITY-MIB (Version 4), and =20 ENERGY-OBJECT-MIB.=20 =20 Implementation experience: The MIB modules are implemented=20= on Cisco router platforms to measure and report=20= router energy measurements. The documents are =20= implementable.=20 =20 Licensing: Proprietary =20 =20 URL: http://www.cisco.com =20 =20 =20 12. Security Considerations=20 Some of the readable objects in these MIB modules (i.e., objects=20= with a MAX-ACCESS other than not-accessible) may be considered=20= sensitive or vulnerable in some network environments. It is=20 thus important to control even GET and/or NOTIFY access to these=20= objects and possibly to even encrypt the values of these objects=20= when sending them over the network via SNMP. =20 =20 There are a number of management objects defined in these MIB=20 modules with a MAX-ACCESS clause of read-write and/or read- create. Such objects MAY be considered sensitive or vulnerable=20= in some network environments. The support for SET operations in=20= a non-secure environment without proper protection can have a=20 negative effect on network operations. The following are the=20 tables and objects and their sensitivity/vulnerability:=20 =20 - Unauthorized changes to the eoPowerOperState (via=20 theeoPowerAdminState ) MAY disrupt the power settings of the=20= differentEnergy Objects, and therefore the state of=20 functionality of the respective Energy Objects.=20 - Unauthorized changes to the eoEnergyParametersTable MAY=20 disrupt energy measurement in the eoEnergyTable table. =20 =20 SNMP versions prior to SNMPv3 did not include adequate security.=20= Even if the network itself is secure (for example, by using=20 IPsec), there is still no secure control over who on the secure=20= network is allowed to access and GET/SET=20 (read/change/create/delete) the objects in these MIB modules.=20 =20 =20 =20 Expires June 13, 2014 [Page 71]=20= =20 =0C Internet-Draft December 2013=20= =20 It is RECOMMENDED that implementers consider the security=20 features as provided by the SNMPv3 framework (see [RFC3410],=20 section 8), including full support for the SNMPv3 cryptographic=20= mechanisms (for authentication and privacy).=20 =20 Further, deployment of SNMP versions prior to SNMPv3 is NOT=20 RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to=20= enable cryptographic security. It is then a customer/operator=20= responsibility to ensure that the SNMP entity giving access to=20= an instance of these MIB modules is properly configured to give=20= access to the objects only to those principals (users) that have=20= legitimate rights to GET or SET (change/create/delete) them.=20 =20 13. IANA Considerations=20 Additions to the ENERGY-OBJECT-MIB MIB and POWER-ATTRIBUTES-MIB=20= MIB modules are subject to Expert Review [RFC5226], i.e., review=20= by one of a group of experts designated by an IETF Area=20 Director. The group of experts MUST check the requested MIB=20 objects for completeness and accuracy of the description. =20 Requests for MIB objects that duplicate the functionality of=20 existing objects SHOULD be declined. The smallest available=20 OIDs SHOULD be assigned to the new MIB objects. The=20 specification of new MIB objects SHOULD follow the structure=20 specified in Section 10. and MUST be published using a well- TOM: The period after 10 is unnecessary. established and persistent publication medium. =20 =20 13.1. IANA Registration of new Power State Set=20 The initial set of Power State Sets are specified in [EMAN- FMWK]. IANA maintains a Textual Convention IANAPowerStateSet=20 with the initial set of Power State Sets and the Power States=20 within those Power State Sets as proposed in the [EMAN-FMWK].=20 The current version of IANAPowerStateSet Textual convention can=20= be accessed http://www.iana.org/assignments/IANAPowerStateSet.=20= New Assignments (and potential deprecation) to Power State Sets=20= shall be administered by IANA and the guidelines and=20 procedures are specified in [EMAN-FMWK], and will, as a=20 consequence, the IANAPowerStateSet Textual Convention should be=20= updated. =20 =20 13.1.1. IANA Registration of the IEEE1621 Power State Set=20 =20 =20 Expires June 13, 2014 [Page 72]=20= =20 =0C Internet-Draft December 2013=20= =20 The Internet Assigned Numbers Authority (IANA) has created a new=20= registry for IEEE1621 Power State Set identifiers and filled it=20= with the initial list in the Textual Convention=20 IANAPowerStateSet. =20 =20 Guidelines for new assignments (or potentially deprecation) for=20= IEEE1621 Power State Set are specified in [EMAN-FMWK].=20 13.1.2. IANA Registration of the DMTF Power State Set=20 The Internet Assigned Numbers Authority (IANA) has created a new=20= registry for DMTF Power State Set identifiers and filled it in=20= the Textual Convention IANAPowerStateSet.=20 Guidelines for new assignments (or potentially deprecation) for=20= DMTF Power State Set are specified in [EMAN-FMWK].=20 13.1.3. IANA Registration of the EMAN Power State Set=20 The Internet Assigned Numbers Authority (IANA) has created a new=20= registry for EMAN Power State Set identifiers and filled it in=20= the Textual Convention IANAPowerStateSet.=20 Guidelines for new assignments (or potentially deprecation) for=20= EMAN Power State Set are specified in [EMAN-FMWK].=20 14. Contributors=20 This document results from the merger of two initial proposals.=20= The following persons made significant contributions either in=20= one of the initial proposals or in this document.=20 =20 John Parello=20 =20 Rolf Winter=20 =20 Dominique Dudkowski=20 =20 12. Acknowledgment=20 The authors would like to thank Shamita Pisal for her prototype=20= of this MIB module, and her valuable feedback. The authors=20 would like to Michael Brown for improving the text dramatically.=20= =20 =20 =20 Expires June 13, 2014 [Page 73]=20= =20 =0C Internet-Draft December 2013=20= =20 The authors would like to thank Juergen Schoenwalder for=20 proposing the design of the Textual Convention for=20 IANAPowerStateSet and Ira McDonald for his feedback. Thanks for=20= the many comments on the design of the EnergyTable from Minoru=20= Teraoka and Hiroto Ogaki.=20 =20 Many thanks to Alan Luchuk for the detailed review of the MIB=20 and his comments.=20 =20 And finally, thanks to the EMAN chairs: Nevil Brownlee and Tom=20= Nadeau.=20 =20 =20 13. References=20 13.1. Normative References=20 [RFC2119] S. Bradner, Key words for use in RFCs to Indicate=20 Requirement Levels, BCP 14, RFC 2119, March 1997.=20 =20 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J.=20 Schoenwaelder, Ed., "Structure of Management=20 Information Version 2 (SMIv2)", STD 58, RFC 2578, April=20= 1999.=20 =20 [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J.=20 Schoenwaelder, Ed., "Textual Conventions for SMIv2",=20 STD 58, RFC 2579, April 1999.=20 =20 [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder,=20 "Conformance Statements for SMIv2", STD 58, RFC 2580,=20 April 1999.=20 =20 [RFC3621] Berger, A., and D. Romascanu, "Power Ethernet MIB",=20 RFC3621, December 2003.=20 =20 [RFC4133] Bierman, A. and K. McCloghrie, "Entity MIB (Version=20= 3)", RFC 4133, August 2005.=20 =20 [EMAN-AWARE-MIB] J. Parello, B. Claise and M. Chandramoili,=20 "draft-ietf-eman-energy-aware-mib-11 ", work in=20 progress, November 2013.=20 =20 [LLDP-MED-MIB] ANSI/TIA-1057, "The LLDP Management Information=20= Base extension module for TIA-TR41.4 media endpoint=20 discovery information", July 2005.=20 =20 =20 =20 =20 Expires June 13, 2014 [Page 74]=20= =20 =0C Internet-Draft December 2013=20= =20 =20 13.2. Informative References=20 =20 [RFC1628] S. Bradner, "UPS Management Information Base", RFC=20 1628, May 1994 =20 =20 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart,=20 "Introduction and Applicability Statements for Internet=20= Standard Management Framework ", RFC 3410, December=20 2002.=20 =20 [RFC3418] Presun, R., Case, J., McCloghrie, K., Rose, M, and S.=20= Waldbusser, "Management Information Base (MIB) for the=20= Simple Network Management Protocol (SNMP)", RFC3418,=20 December 2002.=20 =20 [RFC3433] Bierman, A., Romascanu, D., and K. Norseth, "Entity=20= Sensor Management Information Base", RFC 3433, December=20= 2002.=20 =20 [RFC4268] Chisholm, S. and D. Perkins, "Entity State MIB", RFC=20= 4268, November 2005.=20 =20 [RFC5226] Narten, T. Alverstrand, H., A. and K. McCloghrie,=20 "Guidelines for Writing an IANA Considerations Section=20= in RFCs ", BCP 26, RFC 5226, May 2008.=20 =20 [RFC6933] A. Bierman, D. Romascanu, J. Quittek and M.=20 Chandramouli " Entity MIB (Version 4)", RFC 6933, May=20 2013. =20 =20 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of=20 Running Code: The Implementation Status Section", RFC=20 6982, July 2013.=20 =20 [RFC6988] Quittek, J., Winter, R., Dietz, T., Claise, B., and M.=20= Chandramouli, " Requirements for Energy Management",=20 RFC 6988, September 2013. =20 =20 [EMAN-FMWK] Parello, J. Claise, B., Schoening, B. and Quittek,=20= J., "Energy Management Framework", draft-ietf-eman- framework-11, October 2013.=20 =20 [EMAN-AS] Schoening, B., Chandramouli, M. and Nordman, B.=20 "Energy Management (EMAN) Applicability Statement",=20 draft-ietf-eman-applicability-statement-04, October=20 2013.=20 =20 =20 Expires June 13, 2014 [Page 75]=20= =20 =0C Internet-Draft December 2013=20= =20 =20 [ACPI] "Advanced Configuration and Power Interface=20 Specification",http://www.acpi.info/DOWNLOADS/ACPIspec3 0b.pdf =20 =20 [DMTF] "Power State Management Profile DMTF DSP1027 Version=20 2.0" December 2009 =20 http://www.dmtf.org/sites/default/files/standards/docum ents/DSP1027_2.0.0.pdf=20 =20 [IEEE1621] "Standard for User Interface Elements in Power=20 Control of Electronic Devices Employed in=20 Office/Consumer Environments", IEEE 1621, December=20 2004. =20 =20 [IEC.61850-7-4] International Electrotechnical Commission,=20 "Communication networks and systems for power utility=20 automation Part 7-4: Basic communication structure=20 Compatible logical node classes and data object=20 classes", 2010.=20 =20 [IEC.62053-21] International Electrotechnical Commission,=20 "Electricity metering equipment (a.c.) Particular=20 requirements Part 22: Static meters for active energy =20= (classes 1 and 2)", 2003.=20 =20 [IEC.62053-22]International Electrotechnical Commission,=20 "Electricity metering equipment (a.c.) Particular=20 requirements Part 22: Static meters for active energy =20= (classes 0,2 S and 0,5 S)", 2003.=20 =20 =20 Authors' Addresses=20 =20 =20 Mouli Chandramouli=20 Cisco Systems, Inc.=20 Sarjapur Outer Ring Road=20 Bangalore 560103=20 IN=20 =20 Phone: +91 80 4429 2409 =20 Email: moulchan@cisco.com=20 =20 =20 Benoit Claise=20 Cisco Systems, Inc.=20 De Kleetlaan 6a b1=20 =20 =20 Expires June 13, 2014 [Page 76]=20= =20 =0C Internet-Draft December 2013=20= =20 Diegem 1813=20 BE=20 =20 Phone: +32 2 704 5622=20 Email: bclaise@cisco.com=20 =20 =20 Brad Schoening=20 44 Rivers Edge Drive=20 Little Silver, NJ 07739=20 US=20 Email: brad.schoening@verizon.net=20 =20 =20 Juergen Quittek=20 NEC Europe Ltd.=20 NEC Laboratories Europe=20 Network Research Division=20 Kurfuersten-Anlage 36=20 Heidelberg 69115=20 DE=20 =20 Phone: +49 6221 4342-115=20 Email: quittek@neclab.eu=20 =20 =20 Thomas Dietz=20 NEC Europe Ltd.=20 NEC Laboratories Europe=20 Network Research Division=20 Kurfuersten-Anlage 36=20 Heidelberg 69115=20 DE=20 =20 Phone: +49 6221 4342-128=20 Email: Thomas.Dietz@neclab.eu=20 =20 =20 =20 Expires June 13, 2014 [Page 77]=20= =20 --Apple-Mail=_1FF83778-F8C8-4C81-8F8F-5BFE8EF6EA6D 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 iQIcBAEBCgAGBQJS4ZoFAAoJEPcO+I7eiUJZFdMP/0zYCq/ChYTJwF1nUtVcBevU vMvs7OpXNFBuF6ANxDztZrfcN2Rg5nx5ou8K7ZG/dV9ePXUUOKtDi68avgm1S7PR ndFY44JxPjZMPtJBI1EBTYATlaZxWWSSaAN3tmS8RbLM8AtMoHaFkTM4ELVzYPvZ qQyixoWKI40gWPlIXq3vD4tmtu+MjBoAg9aQlcVfL5MRTQSmOYwARFk+0Lrl1yJ+ YT8QZHdIBkQDkND+Osc2ei4aLD9qyExoj2NNJytrouvpVJeBQiImXLUBqd/NfZTX 5ho3AUxmzJeGZhCJH5vz9itQYZhEnqQhQV7XISpNPRsrxQCtpHUhJDYxIYiOkB6v I/c4hnPvudEzlfMzaAfAa5efKVXTvMGq/XdHsOPrJKNK496OFy6f2Bqvunw71/yQ dDudsRCcx38QDp0Yhpq9AHNQWI552PDcM4DLpj42ZynlBcYZMSgFZZRkNgb2doze OgamLwTGfHlOX9NUL9/SePLa1nMvdtgxi1Mqpr2LNOsrNTyOODIdC+B0kwJkSZZn 06H5aako7ymmgq08C2pgo8ybrrxw5D3iuZFUa0aKTdPhkXUkTNqZ8vjN8f/EzPMl TpPRd2CIvo50axx/xvOqFXw4JR2eBsaGGCN41Agmo7WD9VvG8BUl8cuxrk+5BS5h OHBjmAtdDFWFV4LdqNYd =q5LJ -----END PGP SIGNATURE----- --Apple-Mail=_1FF83778-F8C8-4C81-8F8F-5BFE8EF6EA6D-- From bclaise@cisco.com Fri Jan 24 02:47:37 2014 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 511B21A018D for ; Fri, 24 Jan 2014 02:47:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.035 X-Spam-Level: X-Spam-Status: No, score=-10.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CDA57gYuyvP4 for ; Fri, 24 Jan 2014 02:47:35 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id 92D1E1A01BA for ; Fri, 24 Jan 2014 02:47:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11794; q=dns/txt; s=iport; t=1390560454; x=1391770054; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=hFLGx7tpbn8cjo9AVqb9Kp0b3My+igMNAm6fQ4ZVBg4=; b=YD67buofXm8enV1xnbXStSaUoecvb5eD5dh9QsVaBo5E5+C5WC89AcN+ t2dTl7mkC3+P6DqjCg1n3iPekeAWkjgvVcc6N7YXv0pWHk/GQXsrR3qYS IFmOx4EtrwzVwFCkfXqnom2AmmIb44heUUYnmvsLz24IvhezTd8DBO2r6 o=; X-IronPort-AV: E=Sophos;i="4.95,712,1384300800"; d="scan'208,217";a="3453298" Received: from ams-core-1.cisco.com ([144.254.72.81]) by aer-iport-2.cisco.com with ESMTP; 24 Jan 2014 10:47:33 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s0OAlWM8031849; Fri, 24 Jan 2014 10:47:32 GMT Message-ID: <52E244C4.10600@cisco.com> Date: Fri, 24 Jan 2014 11:47:32 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Thomas Nadeau , "John Parello (jparello)" References: <8F88CD1C-C5F1-497D-8643-538E7D1C3BDF@lucidvision.com> <3E9885B4-9E4C-482E-99B0-A879BC169091@cisco.com>, <3CC2391F-03E9-4060-8AD0-124074DDE480@lucidvision.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050000080300090504010702" Cc: eman mailing list Subject: Re: [eman] MIB Doctor Review of draft-ietf-eman-energy-aware-mib-13 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 24 Jan 2014 10:47:37 -0000 This is a multi-part message in MIME format. --------------050000080300090504010702 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Tom, > > Or instead of copy/paste, just put in a reference to it. Not sure what else you want, next to: Please refer to [EMAN-FMWK] for the definitions of the following terminology used in this draft: Regards, Benoit > > --Tom > >> >> Ok we have all that in the framework and that should just be copied over. >> This is what we have in framework: >> >> """ >> 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. >> """ >> Jp >> >> >> >> Sent from my iPad >> (expect ridiculous spelling mistakes) >> >> On Jan 21, 2014, at 10:29 PM, "Thomas Nadeau" >> > wrote: >> >>> >>> That is cool,but please put in a reference and (brief) >>> explanation into the text somewhere. To the casual or new reader, it >>> is not obvious. *) >>> >>> --Tom >>> >>> >>>> Hi Tom >>>> >>>> Thanks. Still going through the comments. For the first one >>>> regarding EnMS acronym. That's was discussed at length and we >>>> adopted it since ISO50001 used that to describe a management system >>>> for energy (as opposed to NMS) >>>> >>>> Not great but what's in use. >>>> >>>> Jp >>>> >>>> Sent from my iPad >>>> (expect ridiculous spelling mistakes) >>>> >>>> On Jan 21, 2014, at 9:52 PM, "Thomas Nadeau" >>>> > wrote: >>>> >>>>> >>>> >>> > > > > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman --------------050000080300090504010702 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi Tom,

Or instead of copy/paste, just put in a reference to it.
Not sure what else you want, next to:
       Please refer to [EMAN-FMWK] for the definitions of the following 
        terminology used in this draft:
Regards, Benoit

--Tom


Ok we have all that in the framework and that should just be copied over.
This is what we have in framework:

"""
 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. 
"""
Jp
Sent from my iPad 
(expect ridiculous spelling mistakes) 

On Jan 21, 2014, at 10:29 PM, "Thomas Nadeau" <tnadeau@lucidvision.com> wrote:


   That is cool,but please put in a reference and (brief) explanation into the text somewhere. To the casual or new reader, it is not obvious. *)

   --Tom


Hi Tom

Thanks. Still going through the comments. For the first one regarding EnMS acronym. That's was discussed at length and we adopted it since ISO50001 used that to describe a management system for energy (as opposed to NMS)

Not great but what's in use.

Jp

Sent from my iPad
(expect ridiculous spelling mistakes)

On Jan 21, 2014, at 9:52 PM, "Thomas Nadeau" <tnadeau@lucidvision.com> wrote:







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

--------------050000080300090504010702-- From bclaise@cisco.com Fri Jan 24 03:14:43 2014 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DF621A0265; Fri, 24 Jan 2014 03:14:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.035 X-Spam-Level: X-Spam-Status: No, score=-10.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kNuV3ffwncyc; Fri, 24 Jan 2014 03:14:40 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id AF4D41A029B; Fri, 24 Jan 2014 03:14:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17578; q=dns/txt; s=iport; t=1390562075; x=1391771675; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=SmxysjEkgHRULLjm7zMmQ2tXJTpnhsfIYQCAWJuokV8=; b=Mwtsrj2OOL+sohrLFL1cGCg7AijeuVP0wzu53JbIZmKTOBmsGsax/sDB qU3X97R/7zpQq/M1DLGgxj4Wd/8Z3S8krIfq9jmzcWC5bW4052fN/wgfp iRTno5scnbjUsg+e2/lMNKFW9BHAi5EYTOzhK4sA7fBh2Wqcic5sYH/tI A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnIJAD5K4lKQ/khN/2dsb2JhbABQBAaDDDi1bocfgQwWdIIlAQEBAwF4EQsOExYPCQMCAQIBRQYBDAgBAYd5CA3HexcGAY4dBQkLSoQ4BJgmgTKFFYtXgy47gS0 X-IronPort-AV: E=Sophos;i="4.95,712,1384300800"; d="scan'208,217";a="3454678" Received: from ams-core-4.cisco.com ([144.254.72.77]) by aer-iport-2.cisco.com with ESMTP; 24 Jan 2014 11:14:33 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s0OBEXAg027480; Fri, 24 Jan 2014 11:14:33 GMT Message-ID: <52E24B19.7000606@cisco.com> Date: Fri, 24 Jan 2014 12:14:33 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Thomas Nadeau , "MIB Doctors (E-mail)" , eman mailing list References: <8F88CD1C-C5F1-497D-8643-538E7D1C3BDF@lucidvision.com> In-Reply-To: <8F88CD1C-C5F1-497D-8643-538E7D1C3BDF@lucidvision.com> Content-Type: multipart/alternative; boundary="------------030503090106020909090300" Subject: Re: [eman] [MIB-DOCTORS] MIB Doctor Review of draft-ietf-eman-energy-aware-mib-13 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 24 Jan 2014 11:14:43 -0000 This is a multi-part message in MIME format. --------------030503090106020909090300 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Tom, > > > Every Energy Object MUST have a printable name assigned to it. > > TOM: Can you be more specific with "printable"? Do you mean ASCII etc...? This is direct cut and paste from the framework. We had bound to SnmpAdminString, which says UTF-8 Type SnmpAdminString Status current MIB SNMP-FRAMEWORK-MIB ; - View Supporting Images Description "An octet string containing administrative information, preferably in human-readable form. To facilitate internationalization, this information is represented using the ISO/IEC IS 10646-1 character set, encoded as an octet string using the UTF-8 transformation format described in [RFC2279]. Since additional code points are added by amendments to the 10646 standard from time to time, implementations must be prepared to encounter any code point from 0x00000000 to 0x7fffffff. Byte sequences that do not correspond to the valid UTF-8 encoding of a code point or are outside this range are prohibited. The use of control codes should be avoided. When it is necessary to represent a newline, the control code sequence CR LF should be used. The use of leading or trailing white space should be avoided. For code points not directly supported by user interface hardware or software, an alternative means of entry and display, such as hexadecimal, may be provided. For information encoded in 7-bit US-ASCII, the UTF-8 encoding is identical to the US-ASCII encoding. UTF-8 may require multiple bytes to represent a single character / code point; thus the length of this object in octets may be different from the number of characters encoded. Similarly, size constraints refer to the number of encoded octets, not the number of characters represented by an encoding. Note that when this TC is used for an object that is used or envisioned to be used as an index, then a SIZE restriction MUST be specified so that the number of sub-identifiers for any object instance does not exceed the limit of 128, as defined by [RFC3416]. Do you want us to mention UTF-8? > > 5.3 Links to Other Identifiers > > While the entPhysicalIndex is the primary index for all MIB > objects in the ENERGY-OBJECT-CONTEXT-MIB module, the Energy > Management Systems (EnMS) must be able to make the link with the > > TOM: Do you really mean (all caps) MUST here? RFC 6988: 4.4. Using Entity Identifiers of Existing MIB Modules The standard must provide means for reusing entity identifiers from existing standards, including at least the following: o the entPhysicalIndex in the Entity MIB module [RFC6933] o the LldpPortNumber in the LLDP MIB module [IEEE-802.1AB] and in the LLDP-MED MIB module [ANSI-TIA-1057] o the pethPsePortIndex and the pethPsePortGroupIndex in the Power Ethernet MIB [RFC3621] Generic means for reusing other entity identifiers must be provided. So a MUST is right. > > modules for the Energy Objects. However, in situation where any > of these two MIB modules are implemented, the EnMS must be able > to correlate the instances in the different MIB modules. > > The eoAlternateKey alternate key object specifies a manufacturer > defined string that can be used to identify the Energy Object. > Since an EnMS may need to correlate objects across management > > > Expires June 13, 2014 [Page 10] > > Internet-Draft < Energy Object Context MIB > December 2013 > > systems, this alternate key is provided to facilitate such a > link. This optional value is intended as a foreign key or > alternate identifier for a manufacturer or EnMS to use to > correlate the unique Energy Object Id in other systems or > namespaces. If an alternate key is not available or is not > applicable then the value is the zero-length string. > > TOM: Do you want to use MUST here to indicate that it MUST be the zero-length string? Ok. > > > -- Textual Conventions > > TOM: The naming of all of these objects is unusual. The "PethPse" prefix in particular. Typically MIB variables and tables are somehow related to the module/table they are contained in. It would be burdensome to rename every thing in the module at this point, so I would be happy if you simply defined what these prefixes meant for the uninitiated reader. The logic was: PethPsePortIndexOrZero is taken from the existing pethPsePortIndex TC PethPsePortGroupIndexOrZero is taken from the exiting pethPsePortGroupIndex TC > > eoMgmtDNSName OBJECT-TYPE > SYNTAX SnmpAdminString > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "This object specifies the DNS name of the eoMgmtAddress. > This object can be used as an alternate key to help link > the Energy Object with other keyed information that may > be stored within the EnMS(s)." > ::= { eoEntry 7 } > > TOM: Is there anything you want to say about any (suggested) format for this string? We will search for an existing DNS MIB and copy it > > eoDomainName OBJECT-TYPE > SYNTAX SnmpAdminString > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "This object specifies the name of an Energy Management > Domain for the Energy Object. This object specifies a > zero-length string value if no Energy Management Domain > name is configured. The value of eoDomainName must remain > constant at least from one re-initialization of the > entity local management system to the next re- > initialization." > > > Expires June 13, 2014 [Page 18] > > Internet-Draft < Energy Object Context MIB > December 2013 > > ::= { eoEntry 8 } > > TOM: Should this be an empty string by default so that it is set into a known state? Make sense Regards, Benoit --------------030503090106020909090300 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi Tom,
    
          
        Every Energy Object MUST have a printable name assigned to it. 

TOM: Can you be more specific with "printable"?  Do you mean ASCII etc...?
This is direct cut and paste from the framework.
We had bound to SnmpAdminString, which says UTF-8
Type SnmpAdminString
Status current
MIB SNMP-FRAMEWORK-MIB ;   -   View Supporting Images
Description "An octet string containing administrative
information, preferably in human-readable form.

To facilitate internationalization, this
information is represented using the ISO/IEC
IS 10646-1 character set, encoded as an octet
string using the UTF-8 transformation format
described in [RFC2279].

Since additional code points are added by
amendments to the 10646 standard from time
to time, implementations must be prepared to
encounter any code point from 0x00000000 to
0x7fffffff. Byte sequences that do not
correspond to the valid UTF-8 encoding of a
code point or are outside this range are
prohibited.

The use of control codes should be avoided.

When it is necessary to represent a newline,
the control code sequence CR LF should be used.


The use of leading or trailing white space should
be avoided.

For code points not directly supported by user
interface hardware or software, an alternative
means of entry and display, such as hexadecimal,
may be provided.

For information encoded in 7-bit US-ASCII,
the UTF-8 encoding is identical to the
US-ASCII encoding.

UTF-8 may require multiple bytes to represent a
single character / code point; thus the length
of this object in octets may be different from
the number of characters encoded. Similarly,
size constraints refer to the number of encoded
octets, not the number of characters represented
by an encoding.

Note that when this TC is used for an object that
is used or envisioned to be used as an index, then
a SIZE restriction MUST be specified so that the
number of sub-identifiers for any object instance
does not exceed the limit of 128, as defined by
[RFC3416].

Do you want us to mention UTF-8?
         
     5.3 Links to Other Identifiers    

        While the entPhysicalIndex is the primary index for all MIB 
        objects in the ENERGY-OBJECT-CONTEXT-MIB module, the Energy 
        Management Systems (EnMS) must be able to make the link with the 

TOM: Do you really mean (all caps) MUST here?
RFC 6988:
4.4.  Using Entity Identifiers of Existing MIB Modules

   The standard must provide means for reusing entity identifiers from
   existing standards, including at least the following:

   o  the entPhysicalIndex in the Entity MIB module [RFC6933]

   o  the LldpPortNumber in the LLDP MIB module [IEEE-802.1AB] and in
      the LLDP-MED MIB module [ANSI-TIA-1057]

   o  the pethPsePortIndex and the pethPsePortGroupIndex in the Power
      Ethernet MIB [RFC3621]

   Generic means for reusing other entity identifiers must be provided.
So a MUST is right.

        modules for the Energy Objects. However, in situation where any 
        of these two MIB modules are implemented, the EnMS must be able 
        to correlate the instances in the different MIB modules. 
         
        The eoAlternateKey alternate key object specifies a manufacturer 
        defined string that can be used to identify the Energy Object.  
        Since an EnMS may need to correlate objects across management 
      
      
     <Parello, Claise>       Expires  June 13, 2014           [Page 10] 
         
     Internet-Draft   < Energy Object Context MIB >     December 2013 
      
        systems, this alternate key is provided to facilitate such a 
        link.  This optional value is intended as a foreign key or 
        alternate identifier for a manufacturer or EnMS to use to 
        correlate the unique Energy Object Id in other systems or 
        namespaces. If an alternate key is not available or is not 
        applicable then the value is the zero-length string. 

TOM: Do you want to use MUST here to indicate that it MUST be the zero-length string?
Ok.
         
                                    
        -- Textual Conventions 

TOM: The naming of all of these objects is unusual. The "PethPse" prefix in particular. Typically MIB variables and tables are somehow related to the module/table they are contained in.  It would be burdensome to rename every thing in the module at this point, so I would be happy if you simply defined what these prefixes meant for the uninitiated reader.
The logic was:   
PethPsePortIndexOrZero is taken from the existing pethPsePortIndex TC
PethPsePortGroupIndexOrZero is taken from the exiting pethPsePortGroupIndex TC

      
        eoMgmtDNSName OBJECT-TYPE 
            SYNTAX          SnmpAdminString 
            MAX-ACCESS      read-only 
            STATUS          current 
            DESCRIPTION 
               "This object specifies the DNS name of the eoMgmtAddress. 
               This object can be used as an alternate key to help link 
               the Energy Object with other keyed information that may 
               be stored within the EnMS(s)." 
            ::= { eoEntry 7  } 

TOM: Is there anything you want to say about any (suggested) format for this string?
We will search for an existing DNS MIB and copy it
      
        eoDomainName OBJECT-TYPE 
            SYNTAX          SnmpAdminString 
            MAX-ACCESS      read-write 
            STATUS          current 
            DESCRIPTION 
               "This object specifies the name of an Energy Management 
               Domain for the Energy Object.  This object specifies a 
               zero-length string value if no Energy Management Domain 
               name is configured. The value of eoDomainName must remain 
               constant at least from one re-initialization of the 
               entity local management system to the next re-
               initialization."  
      
      
     <Parello, Claise>       Expires  June 13, 2014           [Page 18] 
         
     Internet-Draft   < Energy Object Context MIB >     December 2013 
      
            ::= { eoEntry 8   } 

TOM: Should this be an empty string by default so that it is set into a known state?
Make sense

Regards, Benoit
--------------030503090106020909090300-- From Quittek@neclab.eu Fri Jan 24 04:22:20 2014 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81EDB1A02B8 for ; Fri, 24 Jan 2014 04:22:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.137 X-Spam-Level: X-Spam-Status: No, score=-3.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pf0kxYGRGKyN for ; Fri, 24 Jan 2014 04:22:19 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id A59A91A027A for ; Fri, 24 Jan 2014 04:22:18 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 1489B106A36; Fri, 24 Jan 2014 13:22:17 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G3Lqoy193njk; Fri, 24 Jan 2014 13:22:17 +0100 (CET) X-ENC: Last-Hop-TLS-encrypted X-ENC: Last-Hop-TLS-encrypted Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailer1.neclab.eu (Postfix) with ESMTPS id E7B21106A34; Fri, 24 Jan 2014 13:22:01 +0100 (CET) Received: from DAPHNIS.office.hd ([169.254.2.144]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Fri, 24 Jan 2014 13:22:01 +0100 From: Juergen Quittek To: Thomas Nadeau , eman mailing list Thread-Topic: [eman] Working Group Last Call for draft-ietf-eman-battery-mib-11 Thread-Index: AQHPDXorFJdG/N58S0KYOwhu1MuGCpqT2EDQ Date: Fri, 24 Jan 2014 12:22:01 +0000 Message-ID: <9AB93E4127C26F4BA7829DEFDCE5A6E86890E0F4@DAPHNIS.office.hd> References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.2.165] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-eman-battery-mib@tools.ietf.org" Subject: Re: [eman] Working Group Last Call for draft-ietf-eman-battery-mib-11 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 24 Jan 2014 12:22:20 -0000 Hi all, I received a comment from an implementer who is not on this mailing list. H= e has a case where the use of object batteryIdentifier is not clear. =20 Some batteries are identified by the combination of a model number and a se= rial number, such as, for example, in the battery information model of ACPI= . The issues is that it is not clear how to map these two objects to the si= ngle string-type object batteryIdentifier. Only providing the serial number= as value of the batteryIdentifier may not be sufficient, because some batt= ery serial numbers are unique only in combination with their model number. My proposal for addressing this issue is making the following change: OLD (in DESCRIPTION clause of object batteryIdentifier) The identifier is useful when batteries are removed and re-installed in the same or other devices. Then the device or the network management system can trace batteries and achieve continuity of battery monitoring. If the battery identifier cannot be represented using the ISO/IEC IS 10646-1 character set, then a hexadecimal encoding of a binary representation of the battery identifier must be used. NEW The identifier is useful when batteries are removed and re-installed in the same or other devices. Then the device or the network management system can trace batteries and achieve continuity of battery monitoring. If the battery is identified by more than one value, for example= , by a model number and a serial number, then the value of this object is a concatenation of these values, separated by the colo= n symbol ":". The values should be ordered that a more significant value comes before a less significant one. In the example above, the (more significant) model number would be first, the serial would follow: ":". If the battery identifier cannot be represented using the ISO/IEC IS 10646-1 character set, then a hexadecimal encoding of a binary representation of the entire battery identifier must be used. END Cheers, Juergen > -----Original Message----- > From: eman [mailto:eman-bounces@ietf.org] On Behalf Of Thomas Nadeau > Sent: Donnerstag, 9. Januar 2014 18:54 > To: eman mailing list > Cc: draft-ietf-eman-battery-mib@tools.ietf.org > Subject: [eman] Working Group Last Call for draft-ietf-eman-battery-mib-1= 1 >=20 >=20 > The starts the Working Group Last call on draft-ietf-eman-battery-mib- > 11 that completes on Friday, January 24 at 8AM EDT. Please send comments > by responding to this message by no later than this date. >=20 > Thanks, >=20 > Tom and Nevil >=20 From tnadeau@lucidvision.com Fri Jan 24 07:22:58 2014 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 888581A03EF for ; Fri, 24 Jan 2014 07:22:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.434 X-Spam-Level: X-Spam-Status: No, score=-2.434 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OYtBUVuVNz0b for ; Fri, 24 Jan 2014 07:22:54 -0800 (PST) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 3D0ED1A044D for ; Fri, 24 Jan 2014 07:22:54 -0800 (PST) Received: from [192.168.1.110] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id EE56726C74BB; Fri, 24 Jan 2014 10:22:52 -0500 (EST) Content-Type: multipart/signed; boundary="Apple-Mail=_66EBF5B2-ADE4-4C31-B4A3-FF22BFF731C2"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Thomas Nadeau In-Reply-To: <52E244C4.10600@cisco.com> Date: Fri, 24 Jan 2014 10:22:52 -0500 Message-Id: <525D306B-A103-4E04-88A6-0E7477002647@lucidvision.com> References: <8F88CD1C-C5F1-497D-8643-538E7D1C3BDF@lucidvision.com> <3E9885B4-9E4C-482E-99B0-A879BC169091@cisco.com>, <3CC2391F-03E9-4060-8AD0-124074DDE480@lucidvision.com> <52E244C4.10600@cisco.com> To: Benoit Claise X-Mailer: Apple Mail (2.1827) Cc: eman mailing list Subject: Re: [eman] MIB Doctor Review of draft-ietf-eman-energy-aware-mib-13 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 24 Jan 2014 15:22:58 -0000 --Apple-Mail=_66EBF5B2-ADE4-4C31-B4A3-FF22BFF731C2 Content-Type: multipart/alternative; boundary="Apple-Mail=_65414599-A1BB-45B7-818C-AEF793BBDC0E" --Apple-Mail=_65414599-A1BB-45B7-818C-AEF793BBDC0E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Jan 24, 2014:5:47 AM, at 5:47 AM, Benoit Claise = wrote: > Hi Tom, >>=20 >> Or instead of copy/paste, just put in a reference to it.=20 > Not sure what else you want, next to: > Please refer to [EMAN-FMWK] for the definitions of the = following=20 > terminology used in this draft:=20 I was suggesting that just copying/pasting terms without their = definitions wasn't very useful - at least to me a new reader of the = draft. I simply opened the Framework and looked up some of the = definitions. So with that in mind, I was suggesting that you eliminate = the terms and simply put a reference to the EMAN-FMWK there. --Tom > Regards, Benoit >>=20 >> --Tom >>=20 >>>=20 >>> Ok we have all that in the framework and that should just be copied = over. >>> This is what we have in framework: >>>=20 >>> """ >>> 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.=20 >>> 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.=20 >>> """ >>> Jp >>> Sent from my iPad=20 >>> (expect ridiculous spelling mistakes)=20 >>>=20 >>> On Jan 21, 2014, at 10:29 PM, "Thomas Nadeau" = wrote: >>>=20 >>>>=20 >>>> That is cool,but please put in a reference and (brief) = explanation into the text somewhere. To the casual or new reader, it is = not obvious. *) >>>>=20 >>>> --Tom >>>>=20 >>>>=20 >>>>> Hi Tom >>>>>=20 >>>>> Thanks. Still going through the comments. For the first one = regarding EnMS acronym. That's was discussed at length and we adopted it = since ISO50001 used that to describe a management system for energy (as = opposed to NMS) >>>>>=20 >>>>> Not great but what's in use. >>>>>=20 >>>>> Jp >>>>>=20 >>>>> Sent from my iPad=20 >>>>> (expect ridiculous spelling mistakes)=20 >>>>>=20 >>>>> On Jan 21, 2014, at 9:52 PM, "Thomas Nadeau" = wrote: >>>>>=20 >>>>>>=20 >>>>>=20 >>>>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> eman mailing list >> eman@ietf.org >> https://www.ietf.org/mailman/listinfo/eman >=20 --Apple-Mail=_65414599-A1BB-45B7-818C-AEF793BBDC0E Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1
On Jan 24, 2014:5:47 AM, at 5:47 AM, Benoit Claise <bclaise@cisco.com> wrote:

Hi Tom,

Or instead of copy/paste, just put in a reference to it.
Not sure what else you want, next to:
       Please refer to [EMAN-FMWK] for the definitions of the following 
        terminology used in this draft:

I was suggesting that just copying/pasting terms without their definitions wasn't very useful - at least to me a new reader of the draft. I simply opened the Framework and looked up some of the definitions.  So with that in mind, I was suggesting that you eliminate the terms and simply put a reference to the EMAN-FMWK there.

--Tom


Regards, Benoit

--Tom


Ok we have all that in the framework and that should just be copied over.
This is what we have in framework:

"""
 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. 
"""
Jp
Sent from my iPad 
(expect ridiculous spelling mistakes) 

On Jan 21, 2014, at 10:29 PM, "Thomas Nadeau" <tnadeau@lucidvision.com> wrote:


   That is cool,but please put in a reference and (brief) explanation into the text somewhere. To the casual or new reader, it is not obvious. *)

   --Tom


Hi Tom

Thanks. Still going through the comments. For the first one regarding EnMS acronym. That's was discussed at length and we adopted it since ISO50001 used that to describe a management system for energy (as opposed to NMS)

Not great but what's in use.

Jp

Sent from my iPad
(expect ridiculous spelling mistakes)

On Jan 21, 2014, at 9:52 PM, "Thomas Nadeau" <tnadeau@lucidvision.com> wrote:







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


--Apple-Mail=_65414599-A1BB-45B7-818C-AEF793BBDC0E-- --Apple-Mail=_66EBF5B2-ADE4-4C31-B4A3-FF22BFF731C2 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 iQIcBAEBCgAGBQJS4oVMAAoJEPcO+I7eiUJZzIEP/RMbwIOdafMO/UiI0iHqUwMJ 81Cy7hFTOqThYbQaGymbY0AJdMhwgPYBWifFhjM1MuOct+KD+eyW1C1RtPyMdBay EoZvtTMoASx9t/yVWxJTkRmoSsROuxKaEczy2iDyujYiOb7WQ5eTNJ22WsZtcte0 PjTxm44Jq8EBy8ESX8o+om3aAOHCy4vWzxg61UfxOGPcNfeIKPdCX6xn40j04UZ+ 8LMGJeqGuSD+nh2kIN/GMK4pjceHE5Kv8XiHQ1LjCdtb8SEgcmWnm9FXMUiI8H7d Z6bbFmWm9XLzQIaHFVDlyjBu53XUaX/vklryVXT0q2vfAjKSyD93XmIsnQGsjXPG UTIrhi9X+TohOwUh3Xg5ygBMC/11jABIfbLyG26hmtCVgohknMaoEiZYHEnYwv3g 2hl4dEoSelZGdvV9fQdMapBopZE7wvhh7il65eNFS3/X6virOmuwKYoiH46pfGQV 2mtmWcjgx1KdFIPzTPDe449jbiPEeqEkY2B4IdOvWcTFXXErmrKzuYZxo/Z0aLbx k97vzsnfbRugc+FdqFdtUKv9VJWEeQeQtaYkQjbVSl3UqjN08Yg0SgpcpesVwyUj DOIzHJH9yHfGcmgMO3cp1pVx++j9aHdy3iZeIblVYiPZ2RD4KbwaqrUPvmy18Tp3 6qRFKc2M0HcGTbgBj85g =gr2d -----END PGP SIGNATURE----- --Apple-Mail=_66EBF5B2-ADE4-4C31-B4A3-FF22BFF731C2-- From tnadeau@lucidvision.com Fri Jan 24 07:24:55 2014 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DADD71A0294; Fri, 24 Jan 2014 07:24:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.434 X-Spam-Level: X-Spam-Status: No, score=-2.434 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s9Zj9h0UW_G3; Fri, 24 Jan 2014 07:24:52 -0800 (PST) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 324991A0025; Fri, 24 Jan 2014 07:24:52 -0800 (PST) Received: from [192.168.1.110] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id DA3D826C74E2; Fri, 24 Jan 2014 10:24:50 -0500 (EST) Content-Type: multipart/signed; boundary="Apple-Mail=_8C6B50A9-C3F9-4708-A116-24726350493E"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Thomas Nadeau In-Reply-To: <52E24B19.7000606@cisco.com> Date: Fri, 24 Jan 2014 10:24:50 -0500 Message-Id: <82AC2C0C-7EBF-45AE-B2C4-818BE6CB5C9E@lucidvision.com> References: <8F88CD1C-C5F1-497D-8643-538E7D1C3BDF@lucidvision.com> <52E24B19.7000606@cisco.com> To: Benoit Claise X-Mailer: Apple Mail (2.1827) Cc: "MIB Doctors \(E-mail\)" , eman mailing list Subject: Re: [eman] [MIB-DOCTORS] MIB Doctor Review of draft-ietf-eman-energy-aware-mib-13 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 24 Jan 2014 15:24:56 -0000 --Apple-Mail=_8C6B50A9-C3F9-4708-A116-24726350493E Content-Type: multipart/alternative; boundary="Apple-Mail=_17A2F8BB-5A2F-417F-8D29-629AFB9506CF" --Apple-Mail=_17A2F8BB-5A2F-417F-8D29-629AFB9506CF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Jan 24, 2014:6:14 AM, at 6:14 AM, Benoit Claise = wrote: > Hi Tom, >> =20 >> =20 >> Every Energy Object MUST have a printable name assigned to = it.=20 >>=20 >> TOM: Can you be more specific with "printable"? Do you mean ASCII = etc...?=20 > This is direct cut and paste from the framework. > We had bound to SnmpAdminString, which says UTF-8 That is the kicker - make sure its a UTF-8 encoding specified in = the description. Right now it reads like a free-form string is ok unless = you go to the trouble of looking up the reference below.=20 >=20 > Type SnmpAdminString > Status current > MIB SNMP-FRAMEWORK-MIB ; - View Supporting Images > Description "An octet string containing administrative > information, preferably in human-readable form. >=20 > To facilitate internationalization, this > information is represented using the ISO/IEC > IS 10646-1 character set, encoded as an octet > string using the UTF-8 transformation format > described in [RFC2279]. >=20 > Since additional code points are added by > amendments to the 10646 standard from time > to time, implementations must be prepared to > encounter any code point from 0x00000000 to > 0x7fffffff. Byte sequences that do not > correspond to the valid UTF-8 encoding of a > code point or are outside this range are > prohibited. >=20 > The use of control codes should be avoided. >=20 > When it is necessary to represent a newline, > the control code sequence CR LF should be used. >=20 >=20 > The use of leading or trailing white space should > be avoided. >=20 > For code points not directly supported by user > interface hardware or software, an alternative > means of entry and display, such as hexadecimal, > may be provided. >=20 > For information encoded in 7-bit US-ASCII, > the UTF-8 encoding is identical to the > US-ASCII encoding. >=20 > UTF-8 may require multiple bytes to represent a > single character / code point; thus the length > of this object in octets may be different from > the number of characters encoded. Similarly, > size constraints refer to the number of encoded > octets, not the number of characters represented > by an encoding. >=20 > Note that when this TC is used for an object that > is used or envisioned to be used as an index, then > a SIZE restriction MUST be specified so that the > number of sub-identifiers for any object instance > does not exceed the limit of 128, as defined by > [RFC3416]. > Do you want us to mention UTF-8? >> =20 >> 5.3 Links to Other Identifiers =20 >>=20 >> While the entPhysicalIndex is the primary index for all MIB=20= >> objects in the ENERGY-OBJECT-CONTEXT-MIB module, the Energy=20= >> Management Systems (EnMS) must be able to make the link with = the=20 >>=20 >> TOM: Do you really mean (all caps) MUST here? > RFC 6988: > 4.4. Using Entity Identifiers of Existing MIB Modules >=20 > The standard must provide means for reusing entity identifiers from > existing standards, including at least the following: >=20 > o the entPhysicalIndex in the Entity MIB module [RFC6933] >=20 > o the LldpPortNumber in the LLDP MIB module [IEEE-802.1AB] and in > the LLDP-MED MIB module [ANSI-TIA-1057] >=20 > o the pethPsePortIndex and the pethPsePortGroupIndex in the Power > Ethernet MIB [RFC3621] >=20 > Generic means for reusing other entity identifiers must be = provided. > So a MUST is right. >>=20 >> modules for the Energy Objects. However, in situation where = any=20 >> of these two MIB modules are implemented, the EnMS must be = able=20 >> to correlate the instances in the different MIB modules.=20 >> =20 >> The eoAlternateKey alternate key object specifies a = manufacturer=20 >> defined string that can be used to identify the Energy = Object. =20 >> Since an EnMS may need to correlate objects across management=20= >> =20 >> =20 >> Expires June 13, 2014 [Page = 10]=20 >> =20 >> =0C Internet-Draft < Energy Object Context MIB > December = 2013=20 >> =20 >> systems, this alternate key is provided to facilitate such a=20= >> link. This optional value is intended as a foreign key or=20 >> alternate identifier for a manufacturer or EnMS to use to=20 >> correlate the unique Energy Object Id in other systems or=20 >> namespaces. If an alternate key is not available or is not=20 >> applicable then the value is the zero-length string.=20 >>=20 >> TOM: Do you want to use MUST here to indicate that it MUST be the = zero-length string?=20 > Ok. >> =20 >> =20 >> -- Textual Conventions=20 >>=20 >> TOM: The naming of all of these objects is unusual. The "PethPse" = prefix in particular. Typically MIB variables and tables are somehow = related to the module/table they are contained in. It would be = burdensome to rename every thing in the module at this point, so I would = be happy if you simply defined what these prefixes meant for the = uninitiated reader. =20 > The logic was: =20 > PethPsePortIndexOrZero is taken from the existing pethPsePortIndex TC > PethPsePortGroupIndexOrZero is taken from the exiting = pethPsePortGroupIndex TC OK.=20 >=20 >> =20 >> eoMgmtDNSName OBJECT-TYPE=20 >> SYNTAX SnmpAdminString=20 >> MAX-ACCESS read-only=20 >> STATUS current=20 >> DESCRIPTION=20 >> "This object specifies the DNS name of the = eoMgmtAddress.=20 >> This object can be used as an alternate key to help = link=20 >> the Energy Object with other keyed information that = may=20 >> be stored within the EnMS(s)."=20 >> ::=3D { eoEntry 7 }=20 >>=20 >> TOM: Is there anything you want to say about any (suggested) format = for this string? > We will search for an existing DNS MIB and copy it >> =20 >> eoDomainName OBJECT-TYPE=20 >> SYNTAX SnmpAdminString=20 >> MAX-ACCESS read-write=20 >> STATUS current=20 >> DESCRIPTION=20 >> "This object specifies the name of an Energy = Management=20 >> Domain for the Energy Object. This object specifies a=20= >> zero-length string value if no Energy Management = Domain=20 >> name is configured. The value of eoDomainName must = remain=20 >> constant at least from one re-initialization of the=20 >> entity local management system to the next re- >> initialization." =20 >> =20 >> =20 >> Expires June 13, 2014 [Page = 18]=20 >> =20 >> =0C Internet-Draft < Energy Object Context MIB > December = 2013=20 >> =20 >> ::=3D { eoEntry 8 }=20 >>=20 >> TOM: Should this be an empty string by default so that it is set into = a known state? > Make sense >=20 > Regards, Benoit --Apple-Mail=_17A2F8BB-5A2F-417F-8D29-629AFB9506CF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
On Jan 24, 2014:6:14 AM, at 6:14 AM, = Benoit Claise <bclaise@cisco.com> = wrote:

=20 =20
Hi Tom,
   =20
         =20
        Every Energy Object MUST have a printable name assigned to it.=20=


TOM: Can you be more specific with "printable"?  Do you mean ASCII =
etc...?
This is direct cut and paste from the framework.
We had bound to SnmpAdminString, which says = UTF-8

That is = the kicker - make sure its a UTF-8 encoding specified in the = description. Right now it reads like a free-form string is ok unless you = go to the trouble of looking up the reference = below. 


Type SnmpAdminString
Status current
MIB = SNMP-FRAMEWORK-MIB ;   -   View Supporting Images
Description "An octet = string containing administrative
information, preferably in human-readable form.

To facilitate internationalization, this
information is represented using the ISO/IEC
IS 10646-1 character set, encoded as an octet
string using the UTF-8 transformation format
described in [RFC2279].

Since additional code points are added by
amendments to the 10646 standard from time
to time, implementations must be prepared to
encounter any code point from 0x00000000 to
0x7fffffff. Byte sequences that do not
correspond to the valid UTF-8 encoding of a
code point or are outside this range are
prohibited.

The use of control codes should be avoided.

When it is necessary to represent a newline,
the control code sequence CR LF should be used.


The use of leading or trailing white space should
be avoided.

For code points not directly supported by user
interface hardware or software, an alternative
means of entry and display, such as hexadecimal,
may be provided.

For information encoded in 7-bit US-ASCII,
the UTF-8 encoding is identical to the
US-ASCII encoding.

UTF-8 may require multiple bytes to represent a
single character / code point; thus the length
of this object in octets may be different from
the number of characters encoded. Similarly,
size constraints refer to the number of encoded
octets, not the number of characters represented
by an encoding.

Note that when this TC is used for an object that
is used or envisioned to be used as an index, then
a SIZE restriction MUST be specified so that the
number of sub-identifiers for any object instance
does not exceed the limit of 128, as defined by
[RFC3416].

Do you want us to mention UTF-8?
        =20
     5.3 Links to Other Identifiers   =20

        While the entPhysicalIndex is the primary index for all MIB=20
        objects in the ENERGY-OBJECT-CONTEXT-MIB module, the Energy=20
        Management Systems (EnMS) must be able to make the link with the=20=


TOM: Do you really mean (all caps) MUST here?
RFC 6988:
4.4.  Using Entity Identifiers of =
Existing MIB Modules

   The standard must provide means for reusing entity identifiers from
   existing standards, including at least the following:

   o  the entPhysicalIndex in the Entity MIB module [RFC6933]

   o  the LldpPortNumber in the LLDP MIB module [IEEE-802.1AB] and in
      the LLDP-MED MIB module [ANSI-TIA-1057]

   o  the pethPsePortIndex and the pethPsePortGroupIndex in the Power
      Ethernet MIB [RFC3621]

   Generic means for reusing other entity identifiers must be =
provided.
So a MUST is right.
        modules for the Energy Objects. However, in situation where any=20=

        of these two MIB modules are implemented, the EnMS must be able=20=

        to correlate the instances in the different MIB modules.=20
        =20
        The eoAlternateKey alternate key object specifies a manufacturer=20=

        defined string that can be used to identify the Energy Object. =20=

        Since an EnMS may need to correlate objects across management=20
     =20
     =20
     <Parello, Claise>       Expires  June 13, 2014           =
[Page 10]=20
        =20
=0C     Internet-Draft   < Energy Object Context MIB >     =
December 2013=20
     =20
        systems, this alternate key is provided to facilitate such a=20
        link.  This optional value is intended as a foreign key or=20
        alternate identifier for a manufacturer or EnMS to use to=20
        correlate the unique Energy Object Id in other systems or=20
        namespaces. If an alternate key is not available or is not=20
        applicable then the value is the zero-length string.=20

TOM: Do you want to use MUST here to indicate that it MUST be the =
zero-length string?
Ok.
        =20
                                   =20
        -- Textual Conventions=20

TOM: The naming of all of these objects is unusual. The "PethPse" prefix =
in particular. Typically MIB variables and tables are somehow related to =
the module/table they are contained in.  It would be burdensome to =
rename every thing in the module at this point, so I would be happy if =
you simply defined what these prefixes meant for the uninitiated reader. =
The logic was:   
PethPsePortIndexOrZero is taken from the existing =
pethPsePortIndex TC
PethPsePortGroupIndexOrZero is taken from the exiting =
pethPsePortGroupIndex =
TC

= OK. 



     =20
        eoMgmtDNSName OBJECT-TYPE=20
            SYNTAX          SnmpAdminString=20
            MAX-ACCESS      read-only=20
            STATUS          current=20
            DESCRIPTION=20
               "This object specifies the DNS name of the eoMgmtAddress.=20=

               This object can be used as an alternate key to help link=20=

               the Energy Object with other keyed information that may=20=

               be stored within the EnMS(s)."=20
            ::=3D { eoEntry 7  }=20

TOM: Is there anything you want to say about any (suggested) format for =
this string?
We will search for an existing DNS MIB and copy it
     =20
        eoDomainName OBJECT-TYPE=20
            SYNTAX          SnmpAdminString=20
            MAX-ACCESS      read-write=20
            STATUS          current=20
            DESCRIPTION=20
               "This object specifies the name of an Energy Management=20=

               Domain for the Energy Object.  This object specifies a=20
               zero-length string value if no Energy Management Domain=20=

               name is configured. The value of eoDomainName must remain=20=

               constant at least from one re-initialization of the=20
               entity local management system to the next re-
               initialization." =20
     =20
     =20
     <Parello, Claise>       Expires  June 13, 2014           =
[Page 18]=20
        =20
=0C     Internet-Draft   < Energy Object Context MIB >     =
December 2013=20
     =20
            ::=3D { eoEntry 8   }=20

TOM: Should this be an empty string by default so that it is set into a =
known state?
Make sense

Regards, Benoit

= --Apple-Mail=_17A2F8BB-5A2F-417F-8D29-629AFB9506CF-- --Apple-Mail=_8C6B50A9-C3F9-4708-A116-24726350493E 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 iQIcBAEBCgAGBQJS4oXDAAoJEPcO+I7eiUJZHDwQAIsyUBQ9dXWy7oW7smrjImdB bD/nwG/vqDx7q9lc4jmf9v8w30AKQjhmmqJ6Qi72ycRuWDvWW8HxwEC0nMf99OWF ABNLPeUUjt7TtAwKx0jpXUa26kQkhnkRYhvzrOXnn2xdNO1J6XqOUmugRBzym7cP 7LE9ZCvWejbSmln+5iHfiqCFrMonWa4+Cl4zJ8X2u30czcpFohgJntQBMMvl5CIi wR8VXPRQmfM0wxHdbcuvJL31WkBLe9dX9ih9rzplenrUi32WHlX2zyoEi8xhXqzV WUCTD/cbySnH3XpuSjVd4eMPp4/MERKB6mJzvA7uVmQ5sEacNJAVvoOuSUWBt0Xu 5BxVrDzgMcNv3sucSAiRh/weAgB6MZypTcyXoPPXbXrAGKtm4affmtfGxrofd88W aTLS7u1qUdGCbyVhLTXJQxZM7dpY4VCLM9MvWl55U2XxPe9Kq2iewlDVzlFTPXoZ mAZISCWgRwXBnvoBDYWpBggkjX/2xjo6qIQFLj/+PH0LeVRkn5Nzonu6nW5/iXNd /L89fEc3GwdrZVB334sHq6o3lsuy6bzwqaoRh0r5Pe1rtEgVOQovC4vBo0R+Xwf+ m/KsfwJyie1pnwaCRY9VPrTTSeet1VG95s5NMYA4Nv93b///2w9Mji5ETasCJHUD VcFucSnqJwPwwtjWGO+K =NR8V -----END PGP SIGNATURE----- --Apple-Mail=_8C6B50A9-C3F9-4708-A116-24726350493E-- From j.schoenwaelder@jacobs-university.de Fri Jan 24 08:31:29 2014 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 742801A0026; Fri, 24 Jan 2014 08:31:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.785 X-Spam-Level: X-Spam-Status: No, score=-2.785 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fsmluQtPZnn9; Fri, 24 Jan 2014 08:31:27 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 1A7F11A0023; Fri, 24 Jan 2014 08:31:27 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 81D9820074; Fri, 24 Jan 2014 17:31:25 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id fidXlu4KWafH; Fri, 24 Jan 2014 17:31:25 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 42BF32005B; Fri, 24 Jan 2014 17:31:24 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id C3EFA2ACD1C2; Fri, 24 Jan 2014 17:31:21 +0100 (CET) Date: Fri, 24 Jan 2014 17:31:21 +0100 From: Juergen Schoenwaelder To: Thomas Nadeau Message-ID: <20140124163121.GD58781@elstar.local> Mail-Followup-To: Thomas Nadeau , Benoit Claise , "MIB Doctors (E-mail)" , eman mailing list References: <8F88CD1C-C5F1-497D-8643-538E7D1C3BDF@lucidvision.com> <52E24B19.7000606@cisco.com> <82AC2C0C-7EBF-45AE-B2C4-818BE6CB5C9E@lucidvision.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <82AC2C0C-7EBF-45AE-B2C4-818BE6CB5C9E@lucidvision.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "MIB Doctors \(E-mail\)" , eman mailing list Subject: Re: [eman] [MIB-DOCTORS] MIB Doctor Review of draft-ietf-eman-energy-aware-mib-13 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 16:31:29 -0000 On Fri, Jan 24, 2014 at 10:24:50AM -0500, Thomas Nadeau wrote: > > > This is direct cut and paste from the framework. > > We had bound to SnmpAdminString, which says UTF-8 > > That is the kicker - make sure its a UTF-8 encoding specified in the description. Right now it reads like a free-form string is ok unless you go to the trouble of looking up the reference below. > To the defense of the authors, SnmpAdminString is pretty widely used in SNMP land and I do not recall we generally tend to repeat saying it is a UTF-8 encoded string when it is used. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From tnadeau@lucidvision.com Fri Jan 24 09:20:57 2014 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0895E1A004B; Fri, 24 Jan 2014 09:20:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XEshlE6EYhqi; Fri, 24 Jan 2014 09:20:55 -0800 (PST) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 23CE11A0047; Fri, 24 Jan 2014 09:20:55 -0800 (PST) Received: from [192.168.1.110] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id C4D2626C79F3; Fri, 24 Jan 2014 12:20:53 -0500 (EST) Content-Type: multipart/signed; boundary="Apple-Mail=_69263DF1-381D-4E84-B041-5B94499D4C51"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Thomas Nadeau In-Reply-To: <20140124163121.GD58781@elstar.local> Date: Fri, 24 Jan 2014 12:20:53 -0500 Message-Id: References: <8F88CD1C-C5F1-497D-8643-538E7D1C3BDF@lucidvision.com> <52E24B19.7000606@cisco.com> <82AC2C0C-7EBF-45AE-B2C4-818BE6CB5C9E@lucidvision.com> <20140124163121.GD58781@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1827) Cc: "MIB Doctors \(E-mail\)" , eman mailing list Subject: Re: [eman] [MIB-DOCTORS] MIB Doctor Review of draft-ietf-eman-energy-aware-mib-13 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 24 Jan 2014 17:20:57 -0000 --Apple-Mail=_69263DF1-381D-4E84-B041-5B94499D4C51 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jan 24, 2014:11:31 AM, at 11:31 AM, Juergen Schoenwaelder = wrote: > On Fri, Jan 24, 2014 at 10:24:50AM -0500, Thomas Nadeau wrote: >>=20 >>> This is direct cut and paste from the framework. >>> We had bound to SnmpAdminString, which says UTF-8 >>=20 >> That is the kicker - make sure its a UTF-8 encoding specified in = the description. Right now it reads like a free-form string is ok unless = you go to the trouble of looking up the reference below.=20 >>=20 >=20 > To the defense of the authors, SnmpAdminString is pretty widely used > in SNMP land and I do not recall we generally tend to repeat saying it > is a UTF-8 encoded string when it is used. Good point. I am %50/%50 on whether its needed to augment the = text. --Tom >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 >=20 --Apple-Mail=_69263DF1-381D-4E84-B041-5B94499D4C51 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 iQIcBAEBCgAGBQJS4qD1AAoJEPcO+I7eiUJZ7SgP/iLz5ipRGFg3Q6eqRrs7pbGc cfDy3gN6fzJUBasBbQPDIV0LkM+lvsRMLi5sExpus9UZlTEyjhSdSlnC3czF7Cwd B99+y4f4Of99r3ZDK8IWtHqitL9jlOKYl24/aJw0Ipx9m6QyQZ3/XVt7hP30NXy4 PTXq8TxOENyfNUkUj57mjVNbgn7k1xkYUsa729Xhk4A2biStjdyXJ0Mu5cqkenJ3 aEbIJJojWAxFerUOeXc9fmLpkTwtTC3ZtBwye+K7aN2LwCrxS85xgC5LMsb0rZIS riQTR7SI2iw3J2+wmBExmVty9FI0L5qBp4Mn0nYn+IyJGb92EL2Hr0K6+BcSaZzw AwRMag1q8beLiZlRYMM+WTdm0rMK59grWyLKfTU04724RXAsfXBOdwknPIEoBwRZ OYmJEYikX4CXfwtq9KDGISoc0TQjV2yzvebNqxwZEVu5PRvBNmRa+v88sHSjEirh VmAKF+ymgNiT9cbNanGqERLBICLYybRyKAiMbebfuwLwiZwhQMxf5b82YhZ99n5f 2uzTUOb4jfBpVo50AOwWbmLmQPlP5XowIdmVHyg9udKvHAwsyccNz0dlk+Veucx4 OOvjDMusz1D5Jb1V2HBuHyBCpjyayWKuUmv+HpnXTFnjSKMeBiwGUWuEcrg6a4Va +SbwSU1QR1Km5dI53sto =rvCK -----END PGP SIGNATURE----- --Apple-Mail=_69263DF1-381D-4E84-B041-5B94499D4C51-- From randy_presuhn@mindspring.com Fri Jan 24 10:59:38 2014 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C76E81A0175; Fri, 24 Jan 2014 10:59:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O23TjXYSv2rx; Fri, 24 Jan 2014 10:59:37 -0800 (PST) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by ietfa.amsl.com (Postfix) with ESMTP id 849E41A009A; Fri, 24 Jan 2014 10:59:37 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=mtqqX7kf9gTDIYmHRsqtbQNi6YvnWCBVzErBNQJWdT+YNYvXII+bIEZgOJ/Fq/lJ; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.30.226.130] (helo=oemcomputer) by elasmtp-junco.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1W6lyO-0007cB-W4; Fri, 24 Jan 2014 13:59:25 -0500 Message-ID: <00c501cf1936$e4f19640$6b01a8c0@oemcomputer> From: "Randy Presuhn" To: "Thomas Nadeau" , "Benoit Claise" References: <8F88CD1C-C5F1-497D-8643-538E7D1C3BDF@lucidvision.com> <52E24B19.7000606@cisco.com> <82AC2C0C-7EBF-45AE-B2C4-818BE6CB5C9E@lucidvision.com> Date: Fri, 24 Jan 2014 11:02:55 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88891b749bef7332bbc8ff9cbdec71f7635f8ad52d7dca20bb0350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.30.226.130 Cc: "MIB Doctors \(E-mail\)" , eman mailing list Subject: Re: [eman] [MIB-DOCTORS] MIB Doctor Review ofdraft-ietf-eman-energy-aware-mib-13 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 24 Jan 2014 18:59:38 -0000 Hi - > From: "Thomas Nadeau" > To: "Benoit Claise" > Cc: "MIB Doctors (E-mail)" ; "eman mailing list" > Sent: Friday, January 24, 2014 7:24 AM > Subject: Re: [MIB-DOCTORS] MIB Doctor Review ofdraft-ietf-eman-energy-aware-mib-13 ... > That is the kicker - make sure its a UTF-8 encoding specified > in the description. Right now it reads like a free-form string is > ok unless you go to the trouble of looking up the reference below. ... > Type SnmpAdminString I don't think it makes much sense for an OBJECT-TYPE making use of a TEXTUAL-CONVENTION to repeat material from the DESCRIPTION of the latter. That really defeats one of the motivations for using TEXTUAL- CONVENTIONs in the first place. However, there's another problem, one particularly relevant for INDEX objects: SnmpAdminString is arguably under-specified in that it does not specify the normalization form. If one wants to find information using a user-entered index value without having to go poking about in multiple places in the table (alternate "spellings" if you will), this matters. Randy From tnadeau@lucidvision.com Fri Jan 24 13:24:35 2014 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 623DA1A013C; Fri, 24 Jan 2014 13:24:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.862 X-Spam-Level: * X-Spam-Status: No, score=1.862 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FM_ASCII_ART_SPACINGc=0.833, FRT_LITTLE=1.555, RP_MATCHES_RCVD=-0.535, T_FRT_LITTLE=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3-g2gs2zQUq3; Fri, 24 Jan 2014 13:24:28 -0800 (PST) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id D85DF1A0161; Fri, 24 Jan 2014 13:24:27 -0800 (PST) Received: from [192.168.1.110] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id CEEEA26C8173; Fri, 24 Jan 2014 16:24:25 -0500 (EST) From: Thomas Nadeau Content-Type: multipart/signed; boundary="Apple-Mail=_0FE2FDBD-8ED9-4CB7-99F4-EA5F7BFC53D8"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Fri, 24 Jan 2014 16:24:24 -0500 Message-Id: To: draft-ietf-eman-battery-mib@tools.ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) X-Mailer: Apple Mail (2.1827) Cc: "MIB Doctors \(E-mail\)" , eman mailing list Subject: [eman] MIB-Doctor Review of draft-ietf-eman-battery-mib-11 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 24 Jan 2014 21:24:35 -0000 --Apple-Mail=_0FE2FDBD-8ED9-4CB7-99F4-EA5F7BFC53D8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I reviewed this draft as part of the MIB Doctor review on = Friday, January 24, 2014. In general the MIB is in good shape. I have some questions/comments = inline begin with TOM: General Comments on the draft: 1) My run of id-nits produced no errors and a few warnings that can = be ignored. 2) In general, please go through the MIB modules and verify that the = Integer32 values are indeed ok to be negative values or change them to = Unsigned. For example, there are many instances where you used Integer32 = for things like watts or amps where negative values do not make sense, = to me at least.=20 3) There were no warnings or errors in the smilint run. [server:libsmi-0.4.8/mibs/ietf] tnadeau% smilint -l 6 -i namelength-32 = ./SNMPv2-TC ./SNMPv2-SMI ./SNMPv2-CONF ./SNMP-FRAMEWORK-MIB = ./INET-ADDRESS-MIB ./ENTITY-MIB ./UUID-TC-MIB ./IANA-ENERGY-RELATION-MIB = ./IANA-POWERSTATE-SET-MIB ./ENERGY-OBJECT-MIB ./POWER-ATTRIBTUES-MIB = ./BATTERY-MIB ./SNMPv2-SMI:1: [5] {module-already-loaded} warning: module `SNMPv2-SMI' = is already loaded, aborting parser on this file ./SNMPv2-CONF:4: [2] {import-failed} identifier `ObjectSyntax' cannot be = imported from module `SNMPv2-SMI' ./SNMP-FRAMEWORK-MIB:275: [5] {integer-misuse} warning: use Integer32 = instead of INTEGER in SMIv2 ./SNMP-FRAMEWORK-MIB:349: [5] {integer-misuse} warning: use Integer32 = instead of INTEGER in SMIv2 ./SNMP-FRAMEWORK-MIB:458: [5] {identifier-case-match} warning: = identifier `snmpEngineID' differs from `SnmpEngineID' only in case ./SNMP-FRAMEWORK-MIB:91: [6] {previous-definition} info: previous = definition of `SnmpEngineID' ./SNMP-FRAMEWORK-MIB:471: [5] {integer-misuse} warning: use Integer32 = instead of INTEGER in SMIv2 ./SNMP-FRAMEWORK-MIB:481: [5] {integer-misuse} warning: use Integer32 = instead of INTEGER in SMIv2 ./SNMP-FRAMEWORK-MIB:496: [5] {integer-misuse} warning: use Integer32 = instead of INTEGER in SMIv2 ./IANA-ENERGY-RELATION-MIB:38: [1] {object-identifier-unknown} unknown = object identifier label `energyMIB' ./IANA-ENERGY-RELATION-MIB:3: [5] {import-unused} warning: identifier = `mib-2' imported from module `SNMPv2-SMI' is never used ./IANA-POWERSTATE-SET-MIB:39: [1] {object-identifier-unknown} unknown = object identifier label `energyMIB' ./IANA-POWERSTATE-SET-MIB:4: [5] {import-unused} warning: identifier = `mib-2' imported from module `SNMPv2-SMI' is never used ./ENERGY-OBJECT-MIB:111: [1] {object-identifier-unknown} unknown object = identifier label `energyMIB' ./ENERGY-OBJECT-MIB:620: [5] {index-element-accessible} warning: index = element `eoEnergyParametersIndex' of row `eoEnergyParametersEntry' = should be not-accessible in SMIv2 MIB ./ENERGY-OBJECT-MIB:7: [5] {import-unused} warning: identifier `mib-2' = imported from module `SNMPv2-SMI' is never used ./ENERGY-OBJECT-MIB:10: [5] {import-unused} warning: identifier = `DisplayString' imported from module `SNMPv2-TC' is never used ./POWER-ATTRIBTUES-MIB:111: [1] {object-identifier-unknown} unknown = object identifier label `energyMIB' ./POWER-ATTRIBTUES-MIB:6: [5] {import-unused} warning: identifier = `mib-2' imported from module `SNMPv2-SMI' is never used ./POWER-ATTRIBTUES-MIB:14: [5] {import-unused} warning: identifier = `OwnerString' imported from module `RMON-MIB' is never use =20= Network Working Group J. Quittek Internet-Draft R. Winter Intended status: Standards Track T. Dietz Expires: July 11, 2014 NEC Europe Ltd. January 7, 2014 Definition of Managed Objects for Battery Monitoring draft-ietf-eman-battery-mib-11 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. 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). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on July 11, 2014. Copyright Notice Copyright (c) 2014 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. Quittek, et al. Expires July 11, 2014 [Page 1] =20 Internet-Draft Battery MIB January 2014 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. The Internet-Standard Management Framework . . . . . . . . . . 4 3. Design of the Battery MIB Module . . . . . . . . . . . . . . . 5 3.1. MIB Module Structure . . . . . . . . . . . . . . . . . . . 5 3.2. Battery Technologies . . . . . . . . . . . . . . . . . . . 7 3.3. Battery Identification . . . . . . . . . . . . . . . . . . 8 3.4. Charging Cycles . . . . . . . . . . . . . . . . . . . . . 8 4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 29 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 6.1. SMI Object Identifier Registration . . . . . . . . . . . . 31 6.2. Battery Technology Registration . . . . . . . . . . . . . 31 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 8.1. Normative References . . . . . . . . . . . . . . . . . . . 32 8.2. Informative References . . . . . . . . . . . . . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 Quittek, et al. Expires July 11, 2014 [Page 2] =20 Internet-Draft Battery MIB January 2014 1. Introduction Today, more and more managed devices contain batteries that supply them with power when disconnected from electrical power distribution grids. Common examples are nomadic and mobile devices, such as notebook computers, netbooks, and smart phones. The status of batteries in such a device, particularly the charging status is typically controlled by automatic functions that act locally on the device and manually by users of the device. In addition to this, there is a need to monitor battery status of these devices by network management systems. This document defines a portion of the Management Information Base (MIB) that provides a means for monitoring batteries in or attached to managed devices. The Battery MIB module defined in Section 4 meets the requirements for monitoring the status of batteries specified in RFC 6988 [RFC6988]. The Battery MIB module provides for monitoring the battery status. According to the framework for energy management [I-D.ietf-eman-framework] it is an Energy Managed Object, and thus, MIB modules such as the Power and Energy Monitoring MIB [I-D.ietf-eman-energy-monitoring-mib] could in principle be implemented for batteries. The Battery MIB extends the more generic aspects of energy management by adding battery-specific information. Amongst other things, the Battery MIB enables the monitoring of: o the current charge of a battery, o the age of a battery (charging cycles), o the state of a battery (e.g. being re-charged), o last usage of a battery, o maximum energy provided by a battery (remaining and total capacity). Further, means are provided for battery-powered devices to send notifications when the current battery charge has dropped below a certain threshold to inform the management system of needed replacement. The same applies to the age of a battery. Many battery-driven devices have existing instrumentation for monitoring the battery status, because this is already needed for local control of the battery by the device. This reduces the effort for implementing the managed objects defined in this document. For many devices only additional software will be needed but no additional hardware instrumentation for battery monitoring. Since there are a lot of devices in use that contain more than one battery, means for battery monitoring defined in this document Quittek, et al. Expires July 11, 2014 [Page 3] =20 Internet-Draft Battery MIB January 2014 support addressing multiple batteries within a single device. Also, batteries today often come in packages that can include identification and might contain additional hardware and firmware. The former allows tracing a battery and allows continuous monitoring even if the battery is e.g. installed in another device. The firmware version is useful information as the battery behavior might be different for different firmware versions. Not explicitly in scope of definitions in this document are very small backup batteries, such as for example, batteries used on PC motherboard to run the clock circuit and retain configuration memory while the system is turned off. Other means may be required for reporting on these batteries. However, the MIB module defined in Section 3.1 can be used for this purpose. A traditional type of managed device containing batteries is an Uninterruptible Power Supply (UPS) system; these supply other devices with electrical energy when the main power supply fails. There is already a MIB module for managing UPS systems defined in RFC 1628 [RFC1628]. The UPS MIB module includes managed objects for monitoring the batteries contained in an UPS system. However, the information provided by the UPS MIB objects is limited and tailored the particular needs of UPS systems. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies MIB modules that are compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58,RFC 2580 [RFC2580]. Quittek, et al. Expires July 11, 2014 [Page 4] =20 Internet-Draft Battery MIB January 2014 3. Design of the Battery MIB Module 3.1. MIB Module Structure The Battery MIB module defined in this document defines objects for reporting information about batteries. All managed objects providing information of the status of a battery are contained in a single table called batteryTable. The batteryTable contains one conceptual row per battery. Batteries are indexed by the entPhysicalIndex of the entPhysicalTable defined in the ENTITY-MIB module [RFC6933]. An implementation of the ENTITY-MIB module complying with the entity4CRCompliance MODULE- COMPLIANCE statement is required for compliant implementations of the BATTERY-MIB module. If batteries are replaced with the replacing battery using the same physical connector as the replaced battery had used, then the replacing battery SHOULD be indexed with the same value of object entPhysicalIndex as the replaced battery. The kind of entity in the entPhysicalTable of the Entity MIB module is indicated by the value of enumeration object entPhysicalClass. All batteries SHOULD have the value of object entPhysicalClass set to battery(14) in their row of the entPhysicalTable. The batteryTable contains three groups of objects. The first group (OIDs ending with 1-10) provides information on static properties of the battery. The second group of objects (OIDs ending with 11-18) provides information on the current battery state, if it is charging or discharging, how much it is charged, its remaining capacity, the number of experienced charging cycles, etc. Quittek, et al. Expires July 11, 2014 [Page 5] =20 Internet-Draft Battery MIB January 2014 batteryTable(1) +--batteryEntry(1) [entPhysicalIndex] +-- r-n SnmpAdminString batteryIdentifier(1) +-- r-n SnmpAdminString batteryFirmwareVersion(2) +-- r-n Enumeration batteryType(3) +-- r-n Unsigned32 batteryTechnology(4) +-- r-n Unsigned32 batteryDesignVoltage(5) +-- r-n Unsigned32 batteryNumberOfCells(6) +-- r-n Unsigned32 batteryDesignCapacity(7) +-- r-n Unsigned32 batteryMaxChargingCurrent(8) +-- r-n Unsigned32 batteryTrickleChargingCurrent(9) +-- r-n Unsigned32 batteryActualCapacity(10) +-- r-n Unsigned32 batteryChargingCycleCount(11) +-- r-n DateAndTime batteryLastChargingCycleTime(12) +-- r-n Enumeration batteryChargingOperState(13) +-- rwn Enumeration batteryChargingAdminState(14) +-- r-n Unsigned32 batteryActualCharge(15) +-- r-n Unsigned32 batteryActualVoltage(16) +-- r-n Integer32 batteryActualCurrent(17) +-- r-n Integer32 batteryTemperature(18) +-- r-n SnmpAdminString batteryCellIdentifier(19) +-- rwn Unsigned32 batteryAlarmLowCharge(20) +-- rwn Unsigned32 batteryAlarmLowVoltage(21) +-- rwn Unsigned32 batteryAlarmLowCapacity(22) +-- rwn Unsigned32 batteryAlarmHighCycleCount(23) +-- rwn Integer32 batteryAlarmHighTemperature(24) +-- rwn Integer32 batteryAlarmLowTemperature(25) The third group of objects in this table (OIDs ending with 20-25) indicates thresholds which can be used to raise an alarm if a property of the battery exceeds one of them. Raising an alarm may include sending a notification. The Battery MIB defines seven notifications for indicating 1. a battery charging state change that was not triggered by writing to object batteryChargingAdminState, 2. a low battery charging state, 3. a critical battery that cannot be used anymore for power supply, 4. an aged battery that may need to be replaced, 5. a battery exceed a temperature threshold, 6. a battery that has been connected, 7. disconnection of one or more batteries. Notifications 2.-5. can use object batteryCellIdentifier to indicate a specific cell or a set of cells within the battery that have triggered the notification. Quittek, et al. Expires July 11, 2014 [Page 6] =20 Internet-Draft Battery MIB January 2014 3.2. Battery Technologies Static information in the batteryTable includes battery type and technology. The battery type distinguishes primary (not rechargeable) batteries from rechargeable (secondary) batteries and capacitors. The battery technology describes the actual technology of a battery, which typically is a chemical technology. Since battery technologies are subject of intensive research and widely used technologies are often replaced by successor technologies within an few years, the list of battery technologies was not chosen as a fixed list. Instead, IANA has created a registry for battery technologies at http://www.iana.org/assignments/eman where numbers are assigned to battery technologies (TBD). The table below shows battery technologies known today that are in commercial use with the numbers assigned to them by IANA. New entries can be added to the IANA registry if new technologies are developed or if missing technologies are identified. Note that there exists a huge number of battery types that are not listed in the IANA registry. Many of them are experimental or cannot be used in an economically useful way. New entries should be added to the IANA registry only if the respective technologies are in commercial use and relevant to standardized battery monitoring over the Internet. +----------------------------+----------+ | battery technology | assigned | | | number | +----------------------------+----------+ | Unknown | 1 | | Other | 2 | | Zinc-carbon | 3 | | Zinc chloride | 4 | | Nickel oxyhydroxide | 5 | | Lithium-copper oxide | 6 | | Lithium-iron disulfide | 7 | | Lithium-manganese dioxide | 8 | | Zinc-air | 9 | | Silver oxide | 10 | | Alkaline | 11 | | Lead acid | 12 | | Nickel-cadmium | 13 | | Nickel-metal hybride | 14 | | Nickel-zinc | 15 | | Lithium-ion | 16 | | Lithium polymer | 17 | | Double layer capacitor | 18 | +----------------------------+----------+ Quittek, et al. Expires July 11, 2014 [Page 7] =20 Internet-Draft Battery MIB January 2014 3.3. Battery Identification There are two identifiers to be used: The entPhysicalUUID defined in the ENTITY-MIB [RFC6933] module and the batteryIdentifier defined in this module. A battery is linked to an entPhysicalUUID through the shared entPhysicalIndex. The batteryIdentifier uniquely identifies the battery itself while the entPhysicalUUID identifies the slot of the device in which the battery is (currently) contained. For a non-replaceable battery both identifiers are always linked to the same physical battery. But for batteries that can be replaced, the identifiers have different functions. The entPhysicalUUID is always the same for a certain battery slot of a containing device even if the contained battery is replaced by another one. The batteryIdentifier is a representation of the battery identifier set by the battery manufacturer. It is tied to the battery and usually cannot be changed. Many manufacturers deliver not just plain batteries but battery packages including additional hardware and firmware. Typically, these modules include an battery identifier that can by retrieved by a device in which a battery has been installed. The value of the object batteryIdentifier is an exact representation of this identifier. The batteryIdentifier is useful when batteries are removed and re-installed in the same device or in other devices. Then the device or the network management system can trace batteries and achieve continuity of battery monitoring. 3.4. Charging Cycles The lifetime of a battery can be approximated using the measure of charging cycles. A commonly used definition of a charging cycle is the amount of discharge equal to the design (or nominal) capacity of the battery [SBS]. This means that a single charging cycle may include several steps of partial charging and discharging until the amount of discharging has reached the design capacity of the battery. After that the next charging cycle immediately starts. 4. Definitions BATTERY-MIB DEFINITIONS ::=3D BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, mib-2, Integer32, Unsigned32 Quittek, et al. Expires July 11, 2014 [Page 8] =20 Internet-Draft Battery MIB January 2014 FROM SNMPv2-SMI -- RFC2578 SnmpAdminString FROM SNMP-FRAMEWORK-MIB -- RFC3411 DateAndTime FROM SNMPv2-TC -- RFC2579 MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF -- RFC2580 entPhysicalIndex FROM ENTITY-MIB -- RFC6933 Unsigned64TC FROM APPLICATION-MIB; -- RFC2564 batteryMIB MODULE-IDENTITY LAST-UPDATED "201401071200Z" -- 07 January 2014 ORGANIZATION "IETF EMAN Working Group" CONTACT-INFO "General Discussion: eman@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/eman Archive: http://www.ietf.org/mail-archive/web/eman Editor: Juergen Quittek NEC Europe Ltd. NEC Laboratories Europe Kurfuersten-Anlage 36 69115 Heidelberg Germany Tel: +49 6221 4342-115 Email: quittek@neclab.eu" DESCRIPTION "This MIB module defines a set of objects for monitoring batteries of networked devices and of their components. Copyright (c) 2010 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info). This version of this MIB module is part of RFC yyyy; see the RFC itself for full legal notices." -- replace yyyy with actual RFC number & remove this notice Quittek, et al. Expires July 11, 2014 [Page 9] =20 Internet-Draft Battery MIB January 2014 -- Revision history REVISION "201401071200Z" -- 07 January 2014 DESCRIPTION "Initial version, published as RFC yyyy." -- replace yyyy with actual RFC number & remove this notice ::=3D { mib-2 zzz } -- zzz to be assigned by IANA. --****************************************************************** -- Top Level Structure of the MIB module --****************************************************************** batteryNotifications OBJECT IDENTIFIER ::=3D { batteryMIB 0 } batteryObjects OBJECT IDENTIFIER ::=3D { batteryMIB 1 } batteryConformance OBJECT IDENTIFIER ::=3D { batteryMIB 2 } --=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D -- 1. Object Definitions --=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D -------------------------------------------------------------------- -- 1.1. Battery Table -------------------------------------------------------------------- batteryTable OBJECT-TYPE SYNTAX SEQUENCE OF BatteryEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table provides information on batteries. It contains one conceptual row per battery. TOM: Is this a set of batteries per managed device? Batteries are indexed by the entPhysicalIndex of the entPhysicalTable defined in the ENTITY-MIB (RFC6933). For implementations of the BATTERY-MIB an implementation of the ENTITY-MIB complying with the entity4CRCompliance MODULE-COMPLIANCE statement of the ENTITY-MIB is required. If batteries are replaced with the replacing battery using the same physical connector as the replaced battery had used, then the replacing battery SHOULD be indexed with the same value of object entPhysicalIndex as the replaced battery." ::=3D { batteryObjects 1 } batteryEntry OBJECT-TYPE Quittek, et al. Expires July 11, 2014 [Page 10] =20 Internet-Draft Battery MIB January 2014 SYNTAX BatteryEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry providing information on a battery." INDEX { entPhysicalIndex } ::=3D { batteryTable 1 } BatteryEntry ::=3D SEQUENCE { batteryIdentifier SnmpAdminString, batteryFirmwareVersion SnmpAdminString, batteryType INTEGER, batteryTechnology Unsigned32, batteryDesignVoltage Unsigned32, batteryNumberOfCells Unsigned32, batteryDesignCapacity Unsigned32, batteryMaxChargingCurrent Unsigned32, batteryTrickleChargingCurrent Unsigned32, batteryActualCapacity Unsigned32, batteryChargingCycleCount Unsigned32, batteryLastChargingCycleTime DateAndTime, batteryChargingOperState INTEGER, batteryChargingAdminState INTEGER, batteryActualCharge Unsigned64TC, batteryActualVoltage Unsigned32, batteryActualCurrent Integer32, batteryTemperature Integer32, batteryCellIdentifier SnmpAdminString, batteryAlarmLowCharge Unsigned32, batteryAlarmLowVoltage Unsigned32, batteryAlarmLowCapacity Unsigned32, batteryAlarmHighCycleCount Unsigned32, batteryAlarmHighTemperature Integer32, batteryAlarmLowTemperature Integer32 } batteryIdentifier OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains an identifier for the battery. Many manufacturers deliver not only simple batteries but battery packages including additional hardware and firmware. Typically, these modules include an identifier that can be retrieved by a device in which a battery has been installed. Quittek, et al. Expires July 11, 2014 [Page 11] =20 Internet-Draft Battery MIB January 2014 The identifier is useful when batteries are removed and re-installed in the same or other devices. Then the device or the network management system can trace batteries and achieve continuity of battery monitoring. If the battery identifier cannot be represented using the ISO/IEC IS 10646-1 character set, then a hexadecimal encoding of a binary representation of the battery identifier must be used. The value of this object must be an empty string if there is no battery identifier or if the battery identifier is unknown." ::=3D { batteryEntry 1 } batteryFirmwareVersion OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the version number of the firmware that is included in a battery module. Many manufacturers deliver not pure batteries but battery packages including additional hardware and firmware. Since the behavior of the battery may change with the firmware, it may be useful to retrieve the firmware version number. The value of this object must be an empty string if there is no firmware or if the version number of the firmware is unknown." ::=3D { batteryEntry 2 } batteryType OBJECT-TYPE SYNTAX INTEGER { unknown(1), other(2), primary(3), rechargeable(4), capacitor(5) } MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the type of battery. It distinguishes between primary (not rechargeable) Quittek, et al. Expires July 11, 2014 [Page 12] =20 Internet-Draft Battery MIB January 2014 batteries, rechargeable (secondary) batteries and capacitors which are not really batteries but often used in the same way as a battery. The value other(2) can be used if the battery type is known but none of the ones above. Value unknown(1) is to be used if the type of battery cannot be determined." ::=3D { batteryEntry 3 } batteryTechnology OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the technology used by the battery. Numbers identifying battery types are registered at IANA. A current list of assignments can be found at . Value 0 (unknown) MUST be used if the type of battery cannot be determined. Value 1 (other) can be used if the battery type is known but not one of the types already registered at IANA." ::=3D { batteryEntry 4 } batteryDesignVoltage OBJECT-TYPE SYNTAX Unsigned32 UNITS "millivolt" MAX-ACCESS read-only STATUS current DESCRIPTION "This object provides the design (or nominal) voltage of the battery in units of millivolt (mV). Note that the design voltage is a constant value and typically different from the actual voltage of the battery. A value of 0 indicates that the design voltage is unknown." ::=3D { batteryEntry 5 } batteryNumberOfCells OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the number of cells contained in the battery. Quittek, et al. Expires July 11, 2014 [Page 13] =20 Internet-Draft Battery MIB January 2014 A value of 0 indicates that the number of cells is unknown." ::=3D { batteryEntry 6 } batteryDesignCapacity OBJECT-TYPE SYNTAX Unsigned32 UNITS "milliampere hours" MAX-ACCESS read-only STATUS current DESCRIPTION "This object provides the design (or nominal) capacity of the battery in units of milliampere hours (mAh). Note that the design capacity is a constant value and typically different from the actual capacity of the battery. Usually, this is a value provided by the manufacturer of the battery. A value of 0 indicates that the design capacity is unknown." ::=3D { batteryEntry 7 } batteryMaxChargingCurrent OBJECT-TYPE SYNTAX Unsigned32 UNITS "milliampere" MAX-ACCESS read-only STATUS current DESCRIPTION "This object provides the maximal current to be used for charging the battery in units of milliampere (mA). Note that the maximal charging current may not lead to optimal charge of the battery and that some batteries can only be charged with the maximal current for a limited amount of time. A value of 0 indicates that the maximal charging current is unknown." ::=3D { batteryEntry 8 } batteryTrickleChargingCurrent OBJECT-TYPE SYNTAX Unsigned32 UNITS "milliampere" MAX-ACCESS read-only STATUS current DESCRIPTION "This object provides the recommended current to be used for trickle charging the battery in units of milliampere (mA). Quittek, et al. Expires July 11, 2014 [Page 14] =20 Internet-Draft Battery MIB January 2014 Typically, this is a value recommended by the manufacturer of the battery or by the manufacturer of the charging circuit. A value of 0 indicates that the recommended trickle charging current is unknown." ::=3D { batteryEntry 9 } batteryActualCapacity OBJECT-TYPE SYNTAX Unsigned32 UNITS "milliampere hours" MAX-ACCESS read-only STATUS current DESCRIPTION "This object provides the actual capacity of the battery in units of milliampere hours (mAh). Typically, the actual capacity of a battery decreases with time and with usage of the battery. It is usually lower than the design capacity Note that the actual capacity needs to be measured and is typically an estimate based on observed discharging and charging cycles of the battery. A value of 'ffffffff'H indicates that the actual capacity cannot be determined." ::=3D { batteryEntry 10 } batteryChargingCycleCount OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the number of completed charging cycles that the battery underwent. In line with the Smart Battery Data Specification Revision 1.1, a charging cycle is defined as the process of discharging the battery by a total amount equal to the battery design capacity as given by object batteryDesignCapacity. A charging cycle may include several steps of charging and discharging the battery until the discharging amount given by batteryDesignCapacity has been reached. As soon as a charging cycle has been completed the next one starts immediately independent of the battery's current charge at the end of the cycle. For batteries of type primary(1) the value of this object is Quittek, et al. Expires July 11, 2014 [Page 15] =20 Internet-Draft Battery MIB January 2014 always 0. A value of 'ffffffff'H indicates that the number of charging cycles cannot be determined." ::=3D { batteryEntry 11 } batteryLastChargingCycleTime OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The date and time of the last charging cycle. The value '0000000000000000'H is returned if the battery has not been charged yet or if the last charging time cannot be determined. For batteries of type primary(1) the value of this object is always '0000000000000000'H." ::=3D { batteryEntry 12 } batteryChargingOperState OBJECT-TYPE SYNTAX INTEGER { unknown(1), charging(2), fastCharging(3), maintainingCharge(4), noCharging(5), discharging(6) } MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the current charging state of the battery. Value unknown(1) indicates that the charging state of the battery cannot be determined. Value charging(2) indicates that the battery is being charged in a way that the charge of the battery increases. Value fastCharging(3) indicated that the battery is being charged rapidly, i.e. faster than in the charging(2) state. If multiple fast charging states exist, all of these states are indicated by fastCharging(3). Value maintainingCharge(4) indicates that the battery is being charged with a low current that compensates Quittek, et al. Expires July 11, 2014 [Page 16] =20 Internet-Draft Battery MIB January 2014 self-discharging. This includes trickle charging, float charging and other methods for maintaining the current charge of a battery. Value noCharging(5) indicates that the battery is not being charged or discharged by electric current between the battery and electric circuits external to the battery. Note that the battery may still be subject to self-discharging. Value discharging(6) indicates that the battery is being discharged and that the charge of the battery decreases." ::=3D { batteryEntry 13 } batteryChargingAdminState OBJECT-TYPE SYNTAX INTEGER { charging(2), fastCharging(3), maintainingCharge(4), noCharging(5), discharging(6), notSet(7) } MAX-ACCESS read-write STATUS current DESCRIPTION "The value of this object indicates the desired status of the charging state of the battery. The real state is indicated by object batteryChargingOperState. See the definition of object batteryChargingOperState for a description of the values. When this object is initialized by an implementation of the BATTERY-MIB module, its value is set to notSet(7). However, a SET request can only set this object to either charging(2), fastCharging(3), maintainingCharge(4), noCharging(5), or discharging(6). Attempts to set this object to notSet(7) will always fail with an 'inconsistentValue' error. In case multiple fast charging states exist, the battery logic can choose an appropriate fast charging state - preferably the fastest. When the batteryChargingAdminState object is set, then the BATTERY-MIB implementation must try to set the battery to the indicated state. The result will be indicated by object batteryChargingOperState. Quittek, et al. Expires July 11, 2014 [Page 17] =20 Internet-Draft Battery MIB January 2014 Due to operational conditions and limitations of the implementation of the BATTERY-MIB module, changing the battery status according to a set value of object batteryChargingAdminState may not be possible. Setting the value of object batteryChargingAdminState may result in not changing the state of the battery to this value or even in setting the charging state to another value. For example, setting batteryChargingAdminState to value fastCharging(3) may have no effect when the battery logic is not allowing fast charging due to temperature constraints." ::=3D { batteryEntry 14 } batteryActualCharge OBJECT-TYPE SYNTAX Unsigned64TC UNITS "milliampere hours" MAX-ACCESS read-only STATUS current DESCRIPTION "This object provides the actual charge of the battery in units of milliampere hours (mAh). Note that the actual charge needs to be measured and is typically an estimate based on observed discharging and charging cycles of the battery. A value of 'ffffffff'H indicates that the actual charge cannot be determined." ::=3D { batteryEntry 15 } batteryActualVoltage OBJECT-TYPE SYNTAX Unsigned32 UNITS "millivolt" MAX-ACCESS read-only STATUS current DESCRIPTION "This object provides the actual voltage of the battery in units of millivolt (mV). A value of 'ffffffff'H indicates that the actual voltage cannot be determined." ::=3D { batteryEntry 16 } batteryActualCurrent OBJECT-TYPE SYNTAX Integer32 UNITS "milliampere" Quittek, et al. Expires July 11, 2014 [Page 18] =20 Internet-Draft Battery MIB January 2014 MAX-ACCESS read-only STATUS current DESCRIPTION "This object provides the actual charging or discharging current of the battery in units of milliampere (mA). Charging current is represented by positive values, discharging current is represented by negative values. A value of '7fffffff'H indicates that the actual current cannot be determined." ::=3D { batteryEntry 17 } batteryTemperature OBJECT-TYPE SYNTAX Integer32 UNITS "deci-degrees Celsius" MAX-ACCESS read-only STATUS current DESCRIPTION "The ambient temperature at or near the battery. TOM: Is there some spec that defines what "near" means? A value of '7fffffff'H indicates that the temperature cannot be determined." ::=3D { batteryEntry 18 } batteryCellIdentifier OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object identifies one or more cells of a battery. The format of the cell identifier may vary between different implementations. It should uniquely identify one or more cells of the indexed battery. This object can be used for batteries, such as, for example, lithium polymer batteries for which battery controllers monitor cells individually. This object is used by notifications of type batteryLowNotification, batteryTemperatureNotification, batteryCriticalNotification, and batteryAgingNotification. These notifications can use the value of this object to indicate the event that triggered the generation of the notification in more details by specifying a single cell or a set of cells within the battery which are specifically addressed by the notification. An example use case for this object is a single cell in a Quittek, et al. Expires July 11, 2014 [Page 19] =20 Internet-Draft Battery MIB January 2014 battery that exceeds the temperature indicated by object batteryAlarmHighTemperature. In such a case, a batteryTemperatureNotification can be generated that not just indicates the battery for which the temperature is exceeded but also the particular cell. The initial value of this object is the empty string. The value of this object is set at each time a batteryLowNotification, a batteryTemperatureNotification, a batteryCriticalNotification, or a batteryAgingNotification is generated. When a notification is generated that does not indicate a specific cell or set of cells, the value of this object is set to the empty string." ::=3D { batteryEntry 19 } batteryAlarmLowCharge OBJECT-TYPE SYNTAX Unsigned32 UNITS "milliampere hours" MAX-ACCESS read-write STATUS current DESCRIPTION "This object provides the lower threshold value for object batteryActualCharge. If the value of object batteryActualCharge falls below this threshold, a low battery alarm will be raised. The alarm procedure may include generating a batteryLowNotification. This object should be set to a value such that when the batteryLowNotification is generated, the battery is still sufficiently charged to keep the device(s) that it powers operational for a time long enough to take actions before the powered device(s) enter a 'sleep' or 'off' state. A value of 0 indicates that no alarm will be raised for any value of object batteryActualCharge." ::=3D { batteryEntry 20 } batteryAlarmLowVoltage OBJECT-TYPE SYNTAX Unsigned32 UNITS "millivolt" MAX-ACCESS read-write STATUS current DESCRIPTION "This object provides the lower threshold value for object batteryActualVoltage. If the value of object batteryActualVoltage falls below this threshold, Quittek, et al. Expires July 11, 2014 [Page 20] =20 Internet-Draft Battery MIB January 2014 a low battery alarm will be raised. The alarm procedure may include generating a batteryLowNotification. This object should be set to a value such that when the batteryLowNotification is generated, the battery is still sufficiently charged to keep the device(s) that it powers operational for a time long enough to take actions before the powered device(s) enter a 'sleep' or 'off' state. A value of 0 indicates that no alarm will be raised for any value of object batteryActualVoltage." ::=3D { batteryEntry 21 } batteryAlarmLowCapacity OBJECT-TYPE SYNTAX Unsigned32 UNITS "milliampere hours" MAX-ACCESS read-write STATUS current DESCRIPTION "This object provides the lower threshold value for object batteryActualCapacity. If the value of object batteryActualCapacity falls below this threshold, a battery aging alarm will be raised. The alarm procedure may include generating a batteryAgingNotification. A value of 0 indicates that no alarm will be raised for any value of object batteryActualCapacity." ::=3D { batteryEntry 22 } batteryAlarmHighCycleCount OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-write STATUS current DESCRIPTION "This object provides the upper threshold value for object batteryChargingCycleCount. If the value of object batteryChargingCycleCount rises above this threshold, a battery aging alarm will be raised. The alarm procedure may include generating a batteryAgingNotification. A value of 0 indicates that no alarm will be raised for any value of object batteryChargingCycleCount." TOM: Is there any sort of holding time period over which an alarm = should be not emitted? I can imagine a case where a battery is charged, = discharged, etc... and just goes above and below this threshold causing = a lot of notifications to be emitted. Another option would be to add = variable that defines X numebr of notifications per time period. ::=3D { batteryEntry 23 } batteryAlarmHighTemperature OBJECT-TYPE SYNTAX Integer32 UNITS "deci-degrees Celsius" MAX-ACCESS read-write Quittek, et al. Expires July 11, 2014 [Page 21] =20 Internet-Draft Battery MIB January 2014 STATUS current DESCRIPTION "This object provides the upper threshold value for object batteryTemperature. If the value of object batteryTemperature rises above this threshold, a battery high temperature alarm will be raised. The alarm procedure may include generating a batteryTemperatureNotification. A value of '7fffffff'H indicates that no alarm will be raised for any value of object batteryTemperature." ::=3D { batteryEntry 24 } batteryAlarmLowTemperature OBJECT-TYPE SYNTAX Integer32 UNITS "deci-degrees Celsius" MAX-ACCESS read-write STATUS current DESCRIPTION "This object provides the lower threshold value for object batteryTemperature. If the value of object batteryTemperature falls below this threshold, a battery low temperature alarm will be raised. The alarm procedure may include generating a batteryTemperatureNotification. A value of '7fffffff'H indicates that no alarm will be raised for any value of object batteryTemperature." ::=3D { batteryEntry 25 } --=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D -- 2. Notifications --=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D batteryChargingStateNotification NOTIFICATION-TYPE OBJECTS { batteryChargingOperState } STATUS current DESCRIPTION "This notification can be generated when a charging state of the battery (indicated by the value of object batteryChargingOperState) is triggered by an event other than a write action to object batteryChargingAdminState. Such an event may, for example, be triggered by a local battery controller." ::=3D { batteryNotifications 1 } batteryLowNotification NOTIFICATION-TYPE Quittek, et al. Expires July 11, 2014 [Page 22] =20 Internet-Draft Battery MIB January 2014 OBJECTS { batteryActualCharge, batteryActualVoltage, batteryCellIdentifier } STATUS current DESCRIPTION "This notification can be generated when the current charge (batteryActualCharge) or the current voltage (batteryActualVoltage) of the battery falls below a threshold defined by object batteryAlarmLowCharge or object batteryAlarmLowVoltage, respectively. Note that typically, this notification is generated in a state where the battery is still sufficiently charged to keep the device(s) that it powers operational for some time. If the charging state of the battery has become critical, i.e., the device(s) powered by the battery must go to a 'sleep' or 'off' state, then the batteryCriticalNotification should be used instead. The notification should not be sent again before the current voltage or the current charge becomes higher than the respective thresholds through charging before falling below the thresholds again. If the low charge or voltage has been detected for a single cell or a set of cells of the battery and not for the entire battery, then object batteryCellIdentifier should be set to a value that identifies the cell or set of cells. Otherwise, the value of object batteryCellIdentifier should be set to the empty string when this notification is generated." ::=3D { batteryNotifications 2 } batteryCriticalNotification NOTIFICATION-TYPE OBJECTS { batteryActualCharge, batteryActualVoltage, batteryCellIdentifier } STATUS current DESCRIPTION "This notification can be generated when the current charge of the battery falls so low that it cannot provide a sufficient power supply function for regular operation of the powered device(s). The battery needs to be charged before it can be used for regular power supply again. The Quittek, et al. Expires July 11, 2014 [Page 23] =20 Internet-Draft Battery MIB January 2014 battery may still provide sufficient power for a 'sleep' mode of powered device(s) or for a transition into an 'off' mode. The notification should not be sent again before the battery charge has increased to a non-critical value. If the critical state is caused a single cell or a set of cells of the battery, then object batteryCellIdentifier should be set to a value that identifies the cell or set of cells. Otherwise, the value of object batteryCellIdentifier should be set to the empty string when this notification is generated." ::=3D { batteryNotifications 3 } batteryTemperatureNotification NOTIFICATION-TYPE OBJECTS { batteryTemperature, batteryCellIdentifier } STATUS current DESCRIPTION "This notification can be generated when the measured temperature (batteryTemperature) rises above the threshold defined by object batteryAlarmHighTemperature or falls below the threshold defined by object batteryAlarmLowTemperature. If the low or high temperature has been detected for a single cell or a set of cells of the battery and not for the entire battery, then object batteryCellIdentifier should be set to a value that identifies the cell or set of cells. Otherwise, the value of object batteryCellIdentifier should be set to the empty string when this notification is generated." ::=3D { batteryNotifications 4 } TOM: The same comment about rate limiting as above. I can see when a = battery is failing this value could float just about and below this = value causing numerious notifications to be issued. Have you considered = such cases? batteryAgingNotification NOTIFICATION-TYPE OBJECTS { batteryActualCapacity, batteryChargingCycleCount, batteryCellIdentifier } STATUS current DESCRIPTION "This notification can be generated when the actual capacity (batteryActualCapacity) falls below a threshold defined by object batteryAlarmLowCapacity Quittek, et al. Expires July 11, 2014 [Page 24] =20 Internet-Draft Battery MIB January 2014 or when the charging cycle count of the battery (batteryChargingCycleCount) exceeds the threshold defined by object batteryAlarmHighCycleCount. If the aging has been detected for a single cell or a set of cells of the battery and not for the entire battery, then object batteryCellIdentifier should be set to a value that identifies the cell or set of cells. Otherwise, the value of object batteryCellIdentifier should be set to the empty string when this notification is generated." ::=3D { batteryNotifications 5 } batteryConnectedNotification NOTIFICATION-TYPE OBJECTS { batteryIdentifier } STATUS current DESCRIPTION "This notification can be generated when it has been detected that a battery has been connected. The battery can be identified by the value of object batteryIdentifier as well as by the value of index entPhysicalIndex that is contained in the OID of object batteryIdentifier." ::=3D { batteryNotifications 6 } batteryDisconnectedNotification NOTIFICATION-TYPE STATUS current DESCRIPTION "This notification can be generated when it has been detected that one or more batteries have been disconnected." ::=3D { batteryNotifications 7 } --=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D -- 3. Conformance Information --=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D batteryCompliances OBJECT IDENTIFIER ::=3D { batteryConformance 1 } batteryGroups OBJECT IDENTIFIER ::=3D { batteryConformance 2 } -------------------------------------------------------------------- -- 3.1. Compliance Statements -------------------------------------------------------------------- batteryCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for implementations of the Quittek, et al. Expires July 11, 2014 [Page 25] =20 Internet-Draft Battery MIB January 2014 BATTERY-MIB module. A compliant implementation MUST implement the objects defined in the mandatory groups batteryDescriptionGroup and batteryStatusGroup. Note that compliance with this compliance statement requires compliance with the entity4CRCompliance MODULE-COMPLIANCE statement of the ENTITY-MIB (RFC6933)." MODULE -- this module MANDATORY-GROUPS { batteryDescriptionGroup, batteryStatusGroup } GROUP batteryAlarmThresholdsGroup DESCRIPTION "A compliant implementation does not have to implement the batteryAlarmThresholdsGroup." GROUP batteryNotificationsGroup DESCRIPTION "A compliant implementation does not have to implement the batteryNotificationsGroup." GROUP batteryPerCellNotificationsGroup DESCRIPTION "A compliant implementation does not have to implement the batteryPerCellNotificationsGroup." GROUP batteryAdminGroup DESCRIPTION "A compliant implementation does not have to implement the batteryAdminGroup." OBJECT batteryAlarmLowCharge MIN-ACCESS read-only DESCRIPTION "A compliant implementation is not required to support set operations to this object." OBJECT batteryAlarmLowVoltage MIN-ACCESS read-only DESCRIPTION "A compliant implementation is not required to support set operations to this object." Quittek, et al. Expires July 11, 2014 [Page 26] =20 Internet-Draft Battery MIB January 2014 OBJECT batteryAlarmLowCapacity MIN-ACCESS read-only DESCRIPTION "A compliant implementation is not required to support set operations to this object." OBJECT batteryAlarmHighCycleCount MIN-ACCESS read-only DESCRIPTION "A compliant implementation is not required to support set operations to this object." OBJECT batteryTemperatureNotification MIN-ACCESS read-only DESCRIPTION "A compliant implementation is not required to support set operations to this object." ::=3D { batteryCompliances 1 } -------------------------------------------------------------------- -- 3.2. MIB Grouping -------------------------------------------------------------------- batteryDescriptionGroup OBJECT-GROUP OBJECTS { batteryIdentifier, batteryFirmwareVersion, batteryType, batteryTechnology, batteryDesignVoltage, batteryNumberOfCells, batteryDesignCapacity, batteryMaxChargingCurrent, batteryTrickleChargingCurrent } STATUS current DESCRIPTION "A compliant implementation MUST implement the objects contained in this group." ::=3D { batteryGroups 1 } batteryStatusGroup OBJECT-GROUP OBJECTS { batteryActualCapacity, batteryChargingCycleCount, batteryLastChargingCycleTime, batteryChargingOperState, Quittek, et al. Expires July 11, 2014 [Page 27] =20 Internet-Draft Battery MIB January 2014 batteryActualCharge, batteryActualVoltage, batteryActualCurrent, batteryTemperature } STATUS current DESCRIPTION "A compliant implementation MUST implement the objects contained in this group." ::=3D { batteryGroups 2 } batteryAdminGroup OBJECT-GROUP OBJECTS { batteryChargingAdminState } STATUS current DESCRIPTION "A compliant implementation does not have to implement the object contained in this group." ::=3D { batteryGroups 3 } batteryAlarmThresholdsGroup OBJECT-GROUP OBJECTS { batteryAlarmLowCharge, batteryAlarmLowVoltage, batteryAlarmLowCapacity, batteryAlarmHighCycleCount, batteryAlarmHighTemperature, batteryAlarmLowTemperature } STATUS current DESCRIPTION "A compliant implementation does not have to implement the objects contained in this group." ::=3D { batteryGroups 4 } batteryNotificationsGroup NOTIFICATION-GROUP NOTIFICATIONS { batteryChargingStateNotification, batteryLowNotification, batteryCriticalNotification, batteryAgingNotification, batteryTemperatureNotification, batteryConnectedNotification, batteryDisconnectedNotification } STATUS current DESCRIPTION Quittek, et al. Expires July 11, 2014 [Page 28] =20 Internet-Draft Battery MIB January 2014 "A compliant implementation does not have to implement the notifications contained in this group." ::=3D { batteryGroups 5 } batteryPerCellNotificationsGroup OBJECT-GROUP OBJECTS { batteryCellIdentifier } STATUS current DESCRIPTION "A compliant implementation does not have to implement the object contained in this group." ::=3D { batteryGroups 6 } END 5. Security Considerations There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. These are the tables and objects and their sensitivity/vulnerability: o batteryChargingAdminState Setting the battery charging state can be beneficial for an operator for various reasons such as charging batteries when the price of electricity is low. However, setting the charging state can be used by an attacker to discharge batteries of devices and thereby switching these devices off if they are powered solely by batteries. In particular, if the batteryAlarmLowCharge and batteryAlarmLowVoltage can also be set, this attack will go unnoticed (i.e. no notifications are sent). o batteryAlarmLowCharge and batteryAlarmLowVoltage These objects set the threshold for an alarm to be raised when the battery charge or voltage falls below the corresponding one of them. An attacker setting one of these alarm values can switch off the alarm by setting it to the 'off' value 0 or modify the alarm behavior by setting it to any other value. The result may be loss of data if the battery runs empty without warning to a recipient expecting such a notification. o batteryAlarmLowCapacity and batteryAlarmHighCycleCount These objects set the threshold for an alarm to be raised when the battery becomes older and less performant than required for stable operation. An attacker setting this alarm value can switch off Quittek, et al. Expires July 11, 2014 [Page 29] =20 Internet-Draft Battery MIB January 2014 the alarm by setting it to the 'off' value 0 or modify the alarm behavior by setting it to any other value. This may either lead to a costly replacement of a working battery or too old or too weak batteries being used. The consequence of the latter could e.g. be that a battery cannot provide power long enough between two scheduled charging actions causing the powered device to shut down and potentially lose data. o batteryAlarmHighTemperature and batteryAlarmLowTemperature These objects set thresholds for an alarm to be raised when the battery rises above/falls below them. An attacker setting one of these alarm values can switch off these alarms by setting them to the 'off' value '7fffffff'H or modify the alarm behavior by setting them to any other value. The result may e.g. be an unnecessary shutdown of a device if batteryAlarmHighTemperature is set to too low or damage to the device by too high temperatures if switched off or set to too high values or by damage to the battery when it e.g. is being charged. Batteries can also be damaged e.g. in an attempt to charge them at too low temperatures. Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects and their sensitivity/vulnerability: All potentially sensible or vulnerable objects of this MIB module are in the batteryTable. In general, there are no serious operational vulnerabilities foreseen in case of an unauthorized read access to this table. However, privacy issues need to be considered. It may be a trade secret of the operator o how many batteries are installed in a managed node (batteryIndex) o how old these batteries are (batteryActualCapacity and batteryChargingCycleCount) o when the next replacement cycle for batteries can be expected (batteryAlarmLowCapacity and batteryAlarmHighCycleCount) o what battery type and make are used with which firmware version (batteryIdentifier, batteryFirmwareVersion, batteryType, and batteryTechnology) SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPsec), there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. Quittek, et al. Expires July 11, 2014 [Page 30] =20 Internet-Draft Battery MIB January 2014 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 this MIB module 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. 6. IANA Considerations 6.1. SMI Object Identifier Registration The Battery MIB module defined in this document uses the following IANA-assigned OBJECT IDENTIFIER value recorded in the SMI Numbers registry: Descriptor OBJECT IDENTIFIER value ---------- ----------------------- batteryMIB { mib-2 xxx } [NOTE for IANA: Please allocate an object identifier at http://www.iana.org/assignments/smi-numbers for object batteryMIB.] 6.2. Battery Technology Registration Object batteryTechnology defined in Section 4 reports battery technologies. Eighteen values for battery technologies have initially been defined. They are listed in a table in Section 3.2. For ensuring extensibility of this list, IANA has created a registry for battery technologies at http://www.iana.org/assignments/eman and filled it with the initial list given in Section 3.2. New assignments of numbers for battery technologies will be administered by IANA through Expert Review ([RFC5226]). Experts must check for sufficient relevance of a battery technology to be added. [NOTE for IANA: Please create a new registry under http://www.iana.org/assignments/eman for battery types. Please fill the registry with values from the table in Section 3.2] Quittek, et al. Expires July 11, 2014 [Page 31] =20 Internet-Draft Battery MIB January 2014 7. Acknowledgements We would like to thank Steven Chew and Bill Mielke for their valuable input. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC6933] Bierman, A., Romascanu, D., Quittek, J., and M. Chandramouli, "Entity MIB (Version 4)", RFC 6933, May 2013. 8.2. Informative References [RFC6988] Quittek, J., Chandramouli, M., Winter, R., Dietz, T., and B. Claise, "Requirements for Energy Management", RFC 6988, September 2013. [I-D.ietf-eman-framework] Parello, J., Claise, B., Schoening, B., and J. Quittek, "Energy Management Framework", draft-ietf-eman-framework-11 (work in progress), October 2013. [I-D.ietf-eman-energy-monitoring-mib] Chandramouli, M., Schoening, B., Quittek, J., Dietz, T., and B. Claise, "Power and Energy Monitoring MIB", Quittek, et al. Expires July 11, 2014 [Page 32] =20 Internet-Draft Battery MIB January 2014 draft-ietf-eman-energy-monitoring-mib-07 (work in progress), October 2013. [RFC1628] Case, J., "UPS Management Information Base", RFC 1628, May 1994. [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. [SBS] "Smart Battery Data Specification", Revision 1.1, December 1998. Authors' Addresses Juergen Quittek NEC Europe Ltd. NEC Laboratories Europe Network Research Division Kurfuersten-Anlage 36 Heidelberg 69115 DE Phone: +49 6221 4342-115 Email: quittek@neclab.eu Rolf Winter NEC Europe Ltd. NEC Laboratories Europe Network Research Division Kurfuersten-Anlage 36 Heidelberg 69115 DE Phone: +49 6221 4342-121 Email: Rolf.Winter@neclab.eu Quittek, et al. Expires July 11, 2014 [Page 33] =20 Internet-Draft Battery MIB January 2014 Thomas Dietz NEC Europe Ltd. NEC Laboratories Europe Network Research Division Kurfuersten-Anlage 36 Heidelberg 69115 DE Phone: +49 6221 4342-128 Email: Thomas.Dietz@neclab.eu Quittek, et al. Expires July 11, 2014 [Page 34] Html markup produced by rfcmarkup 1.106, available from = http://tools.ietf.org/tools/rfcmarkup/=20 --Apple-Mail=_0FE2FDBD-8ED9-4CB7-99F4-EA5F7BFC53D8 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 iQIcBAEBCgAGBQJS4toIAAoJEPcO+I7eiUJZPWoP/1VTQokcr+mWtEeV/ZChVuAb FoDCiNHNRwdUb5eoq+xSM+grhx5QsZ0BeEDf96FiQBUJv6A+axrj0rRsVWDIZPZc r84+ruDUbpjAnkRoSX5/PmacAnwOTNLrpMAO9tx3Xt+vnJHEVZs74F+ubXhnAXQE girXby7FQv5Gy/kdF5toHuahfrEg2/sJU/WmejMp3HNKwMAP3y4DT7ObZXWQ998a L98w11suOtP789NVe+OB+xIL+/dQvQjXIKmdPqPGEwziXtX2Nrc/3h2QuSeEdVU+ Nt0jJ6s1ioVayDGVkBZcZE4cJl5kEl15Oddz/ZOmFQPieeXnRUqvleFWBzgnvWiV IvIcAZamxk1JIJATPRup6qRm3Zm4PViriFxzb83IVwKd2GiG+SPSHLDd+pUIhQX6 px437Od/7V6BJ5hc2BmJqtX0mDKRf0Fh9/gegxVLeZI+0rM06uKovvI/QUuGAmIm 6O0LuGM8GihBOLmi7h/CyH21VptUEjwfgg3vm9rO1u3/BxHeIuSMx25C3p45UOLt lX2vJa2qYPMnRnVodVee8m9vSJfKfOaLiYlH0a096XJP7RE5VMwRSZn22KTy2Th0 KiFcFzBiMq3rNJ3d3uXHJKfN69m8cylXN2jtdw6Z8fHJp18TbN37xTmuMAZtTeir d28mumBXbmPMYfNaJTVR =kPdp -----END PGP SIGNATURE----- --Apple-Mail=_0FE2FDBD-8ED9-4CB7-99F4-EA5F7BFC53D8-- From bclaise@cisco.com Fri Jan 24 15:04:08 2014 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B85D1A01F0 for ; Fri, 24 Jan 2014 15:04:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.035 X-Spam-Level: X-Spam-Status: No, score=-10.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2AXt1DyUWc6m for ; Fri, 24 Jan 2014 15:04:05 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id E85B31A0154 for ; Fri, 24 Jan 2014 15:04:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16419; q=dns/txt; s=iport; t=1390604644; x=1391814244; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=iJhFdEJNhWdo+pqeSjlq5jMwYhvf+x2AOvYYH64IitE=; b=LmFhPlJ16sLLv81zqP01ju+6wtSPbFQhjtvrr54ogfZGyo/ypyOnBd0s RtANXkhPVnfXcfeRi3EtDFFnWdZcFD8oBaoVyQsd8/qkCVa0LD0b0K2e0 ekOqwvtLI1OIJU5zZDD2ByiA2PinqZKqzcuBwElrzdVBnzs478qMjqYqt g=; X-IronPort-AV: E=Sophos;i="4.95,715,1384300800"; d="scan'208,217";a="3481687" Received: from ams-core-4.cisco.com ([144.254.72.77]) by aer-iport-2.cisco.com with ESMTP; 24 Jan 2014 23:04:03 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s0ON41HV002617; Fri, 24 Jan 2014 23:04:02 GMT Message-ID: <52E2F161.7010202@cisco.com> Date: Sat, 25 Jan 2014 00:04:01 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Thomas Nadeau References: <8F88CD1C-C5F1-497D-8643-538E7D1C3BDF@lucidvision.com> <3E9885B4-9E4C-482E-99B0-A879BC169091@cisco.com>, <3CC2391F-03E9-4060-8AD0-124074DDE480@lucidvision.com> <52E244C4.10600@cisco.com> <525D306B-A103-4E04-88A6-0E7477002647@lucidvision.com> In-Reply-To: <525D306B-A103-4E04-88A6-0E7477002647@lucidvision.com> Content-Type: multipart/alternative; boundary="------------080307030601060406080505" Cc: eman mailing list Subject: Re: [eman] MIB Doctor Review of draft-ietf-eman-energy-aware-mib-13 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 24 Jan 2014 23:04:08 -0000 This is a multi-part message in MIME format. --------------080307030601060406080505 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 24/01/2014 16:22, Thomas Nadeau wrote: > > On Jan 24, 2014:5:47 AM, at 5:47 AM, Benoit Claise > wrote: > >> Hi Tom, >>> >>> Or instead of copy/paste, just put in a reference to it. >> Not sure what else you want, next to: >> Please refer to [EMAN-FMWK] for the definitions of the following >> terminology used in this draft: > > I was suggesting that just copying/pasting terms without their > definitions wasn't very useful - at least to me a new reader of the > draft. I simply opened the Framework and looked up some of the > definitions. So with that in mind, I was suggesting that you > eliminate the terms and simply put a reference to the EMAN-FMWK there. What about something like RFC 6615? 4. Terminology The definitions of basic terms such as IP Traffic Flow, Exporting Process, Collecting Process, Observation Points, etc. can be found in the IPFIX protocol document [RFC5101]. The issue is that we need to list all the terms, as not all terms from the terminology section in [EMAN-FMWK] are capitalized. Regards, Benoit > > --Tom > > >> Regards, Benoit >>> >>> --Tom >>> >>>> >>>> Ok we have all that in the framework and that should just be copied >>>> over. >>>> This is what we have in framework: >>>> >>>> """ >>>> 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. >>>> """ >>>> Jp >>>> >>>> >>>> >>>> Sent from my iPad >>>> (expect ridiculous spelling mistakes) >>>> >>>> On Jan 21, 2014, at 10:29 PM, "Thomas Nadeau" >>>> > wrote: >>>> >>>>> >>>>> That is cool,but please put in a reference and (brief) >>>>> explanation into the text somewhere. To the casual or new reader, >>>>> it is not obvious. *) >>>>> >>>>> --Tom >>>>> >>>>> >>>>>> Hi Tom >>>>>> >>>>>> Thanks. Still going through the comments. For the first one >>>>>> regarding EnMS acronym. That's was discussed at length and we >>>>>> adopted it since ISO50001 used that to describe a management >>>>>> system for energy (as opposed to NMS) >>>>>> >>>>>> Not great but what's in use. >>>>>> >>>>>> Jp >>>>>> >>>>>> Sent from my iPad >>>>>> (expect ridiculous spelling mistakes) >>>>>> >>>>>> On Jan 21, 2014, at 9:52 PM, "Thomas Nadeau" >>>>>> > wrote: >>>>>> >>>>>>> >>>>>> >>>>> >>> >>> >>> >>> _______________________________________________ >>> eman mailing list >>> eman@ietf.org >>> https://www.ietf.org/mailman/listinfo/eman >> > --------------080307030601060406080505 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 24/01/2014 16:22, Thomas Nadeau wrote:

On Jan 24, 2014:5:47 AM, at 5:47 AM, Benoit Claise <bclaise@cisco.com> wrote:

Hi Tom,

Or instead of copy/paste, just put in a reference to it.
Not sure what else you want, next to:
       Please refer to [EMAN-FMWK] for the definitions of the following 
        terminology used in this draft:

I was suggesting that just copying/pasting terms without their definitions wasn't very useful - at least to me a new reader of the draft. I simply opened the Framework and looked up some of the definitions.  So with that in mind, I was suggesting that you eliminate the terms and simply put a reference to the EMAN-FMWK there.
What about something like RFC 6615?
4.  Terminology

   The definitions of basic terms such as IP Traffic Flow, Exporting
   Process, Collecting Process, Observation Points, etc. can be found in
   the IPFIX protocol document [RFC5101].
The issue is that we need to list all the terms, as not all terms from the terminology section in [EMAN-FMWK] are capitalized.

Regards, Benoit

--Tom


Regards, Benoit

--Tom


Ok we have all that in the framework and that should just be copied over.
This is what we have in framework:

"""
 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. 
"""
Jp
Sent from my iPad 
(expect ridiculous spelling mistakes) 

On Jan 21, 2014, at 10:29 PM, "Thomas Nadeau" <tnadeau@lucidvision.com> wrote:


   That is cool,but please put in a reference and (brief) explanation into the text somewhere. To the casual or new reader, it is not obvious. *)

   --Tom


Hi Tom

Thanks. Still going through the comments. For the first one regarding EnMS acronym. That's was discussed at length and we adopted it since ISO50001 used that to describe a management system for energy (as opposed to NMS)

Not great but what's in use.

Jp

Sent from my iPad
(expect ridiculous spelling mistakes)

On Jan 21, 2014, at 9:52 PM, "Thomas Nadeau" <tnadeau@lucidvision.com> wrote:







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



--------------080307030601060406080505-- From tnadeau@lucidvision.com Sat Jan 25 07:39:51 2014 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44F931A00F2 for ; Sat, 25 Jan 2014 07:39:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.434 X-Spam-Level: X-Spam-Status: No, score=-2.434 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 60n-hL2iGOgM for ; Sat, 25 Jan 2014 07:39:48 -0800 (PST) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 8AED41A037D for ; Sat, 25 Jan 2014 07:39:48 -0800 (PST) Received: from [192.168.1.110] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 5E22526C9084; Sat, 25 Jan 2014 10:39:46 -0500 (EST) Content-Type: multipart/signed; boundary="Apple-Mail=_9C98BD7C-1434-49DF-927D-3915A479D426"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Thomas Nadeau In-Reply-To: <52E2F161.7010202@cisco.com> Date: Sat, 25 Jan 2014 10:39:46 -0500 Message-Id: References: <8F88CD1C-C5F1-497D-8643-538E7D1C3BDF@lucidvision.com> <3E9885B4-9E4C-482E-99B0-A879BC169091@cisco.com>, <3CC2391F-03E9-4060-8AD0-124074DDE480@lucidvision.com> <52E244C4.10600@cisco.com> <525D306B-A103-4E04-88A6-0E7477002647@lucidvision.com> <52E2F161.7010202@cisco.com> To: Benoit Claise X-Mailer: Apple Mail (2.1827) Cc: eman mailing list Subject: Re: [eman] MIB Doctor Review of draft-ietf-eman-energy-aware-mib-13 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jan 2014 15:39:51 -0000 --Apple-Mail=_9C98BD7C-1434-49DF-927D-3915A479D426 Content-Type: multipart/alternative; boundary="Apple-Mail=_98676797-84DC-42C5-BB5F-81070D63B3E4" --Apple-Mail=_98676797-84DC-42C5-BB5F-81070D63B3E4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Jan 24, 2014:6:04 PM, at 6:04 PM, Benoit Claise = wrote: > On 24/01/2014 16:22, Thomas Nadeau wrote: >>=20 >> On Jan 24, 2014:5:47 AM, at 5:47 AM, Benoit Claise = wrote: >>=20 >>> Hi Tom, >>>>=20 >>>> Or instead of copy/paste, just put in a reference to it.=20 >>> Not sure what else you want, next to: >>> Please refer to [EMAN-FMWK] for the definitions of the = following=20 >>> terminology used in this draft:=20 >>=20 >> I was suggesting that just copying/pasting terms without their = definitions wasn't very useful - at least to me a new reader of the = draft. I simply opened the Framework and looked up some of the = definitions. So with that in mind, I was suggesting that you eliminate = the terms and simply put a reference to the EMAN-FMWK there. > What about something like RFC 6615? > 4. Terminology >=20 > The definitions of basic terms such as IP Traffic Flow, Exporting > Process, Collecting Process, Observation Points, etc. can be found = in > the IPFIX protocol document [RFC5101]. > The issue is that we need to list all the terms, as not all terms from = the terminology section in [EMAN-FMWK] are capitalized. Cool. --Tom >=20 > Regards, Benoit >>=20 >> --Tom >>=20 >>=20 >>> Regards, Benoit >>>>=20 >>>>=20 >>>> --Tom >>>>=20 >>>>>=20 >>>>> Ok we have all that in the framework and that should just be = copied over. >>>>> This is what we have in framework: >>>>>=20 >>>>> """ >>>>> 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.=20 >>>>> 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.=20 >>>>> """ >>>>> Jp >>>>> Sent from my iPad=20 >>>>> (expect ridiculous spelling mistakes)=20 >>>>>=20 >>>>> On Jan 21, 2014, at 10:29 PM, "Thomas Nadeau" = wrote: >>>>>=20 >>>>>>=20 >>>>>> That is cool,but please put in a reference and (brief) = explanation into the text somewhere. To the casual or new reader, it is = not obvious. *) >>>>>>=20 >>>>>> --Tom >>>>>>=20 >>>>>>=20 >>>>>>> Hi Tom >>>>>>>=20 >>>>>>> Thanks. Still going through the comments. For the first one = regarding EnMS acronym. That's was discussed at length and we adopted it = since ISO50001 used that to describe a management system for energy (as = opposed to NMS) >>>>>>>=20 >>>>>>> Not great but what's in use. >>>>>>>=20 >>>>>>> Jp >>>>>>>=20 >>>>>>> Sent from my iPad=20 >>>>>>> (expect ridiculous spelling mistakes)=20 >>>>>>>=20 >>>>>>> On Jan 21, 2014, at 9:52 PM, "Thomas Nadeau" = wrote: >>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> eman mailing list >>>> eman@ietf.org >>>> https://www.ietf.org/mailman/listinfo/eman >>>=20 >>=20 >=20 --Apple-Mail=_98676797-84DC-42C5-BB5F-81070D63B3E4 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1
On Jan 24, 2014:6:04 PM, at 6:04 PM, Benoit Claise <bclaise@cisco.com> wrote:

On 24/01/2014 16:22, Thomas Nadeau wrote:

On Jan 24, 2014:5:47 AM, at 5:47 AM, Benoit Claise <bclaise@cisco.com> wrote:

Hi Tom,

Or instead of copy/paste, just put in a reference to it.
Not sure what else you want, next to:
       Please refer to [EMAN-FMWK] for the definitions of the following 
        terminology used in this draft:

I was suggesting that just copying/pasting terms without their definitions wasn't very useful - at least to me a new reader of the draft. I simply opened the Framework and looked up some of the definitions.  So with that in mind, I was suggesting that you eliminate the terms and simply put a reference to the EMAN-FMWK there.
What about something like RFC 6615?
4.  Terminology

   The definitions of basic terms such as IP Traffic Flow, Exporting
   Process, Collecting Process, Observation Points, etc. can be found in
   the IPFIX protocol document [RFC5101].
The issue is that we need to list all the terms, as not all terms from the terminology section in [EMAN-FMWK] are capitalized.

Cool.

--Tom



Regards, Benoit

--Tom


Regards, Benoit

--Tom


Ok we have all that in the framework and that should just be copied over.
This is what we have in framework:

"""
 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. 
"""
Jp
Sent from my iPad 
(expect ridiculous spelling mistakes) 

On Jan 21, 2014, at 10:29 PM, "Thomas Nadeau" <tnadeau@lucidvision.com> wrote:


   That is cool,but please put in a reference and (brief) explanation into the text somewhere. To the casual or new reader, it is not obvious. *)

   --Tom


Hi Tom

Thanks. Still going through the comments. For the first one regarding EnMS acronym. That's was discussed at length and we adopted it since ISO50001 used that to describe a management system for energy (as opposed to NMS)

Not great but what's in use.

Jp

Sent from my iPad
(expect ridiculous spelling mistakes)

On Jan 21, 2014, at 9:52 PM, "Thomas Nadeau" <tnadeau@lucidvision.com> wrote:







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




--Apple-Mail=_98676797-84DC-42C5-BB5F-81070D63B3E4-- --Apple-Mail=_9C98BD7C-1434-49DF-927D-3915A479D426 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 iQIcBAEBCgAGBQJS49rCAAoJEPcO+I7eiUJZnYsP/0bFY/LLV+1lmX5v5u7W9rEe rSTZo9A2IBdcOaYkgYKfLEGAbUTcdgLjAEKcq1osuWnQMbRVfSS5M/yY6vsK12aI nmVTxcnzT9w5a8GvaWKfRZ8NYCbk9igm2I6iYi3Povnx4g016gw/t1CdSGXhKFEq bONIkk22DuIH+iRtfmAqn3FKMGTehccB7Ov/01rnHSFVY1w7O0GI3EOspyTk9fFI fiRcDMeAEH3kp44Pi2Wx/p1Stl4+T/VN9pKxAGbuEh/PgnatBPSpAMW3/Hj+WTX4 KprZXXz/lWvnQPupCC51WfJP+U48DVWU6+1HqspaUtR7Ahg+v7TEKxpOSTD7oITR fgXc4hpdKDTbw+qxPNCLUTllzubgGHpadnFX5yxp5lAglr7WYSUwY6mLA0AUZpF+ hEkMtsuW6rTOIwnBt/XTN7Mr3gYq9kH9dRBtQITOZMKbysx8dBNyXzNFfFDxSd2E kO5bSI3SvOnZzBwduhQA3rmcqYk2R0jyLZx/0PU62wCsSpU9E3A+SrdAWvgPCex6 fOgussk05eQvUA/gTEtDf4UjZZJVx6bHZLAOlZ43LMmv4EYyPMfqkdjTGrmM8zCo fW5pFy6md3yq1c1r55K3POHUQXK5RSKXsDOGMJC3NYuKJ3mur1HblnVJ/2df16iG y8fMrYPjkIA+Ul+b6JEf =uquM -----END PGP SIGNATURE----- --Apple-Mail=_9C98BD7C-1434-49DF-927D-3915A479D426-- From Quittek@neclab.eu Mon Jan 27 08:15:06 2014 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D260A1A02B2 for ; Mon, 27 Jan 2014 08:15:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.137 X-Spam-Level: X-Spam-Status: No, score=-3.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Kyh10IUm_cE for ; Mon, 27 Jan 2014 08:15:00 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 07C2F1A025D for ; Mon, 27 Jan 2014 08:15:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 8F6DE106A68; Mon, 27 Jan 2014 17:14:57 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id slbiLtwPQ-WB; Mon, 27 Jan 2014 17:14:57 +0100 (CET) X-ENC: Last-Hop-TLS-encrypted X-ENC: Last-Hop-TLS-encrypted Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailer1.neclab.eu (Postfix) with ESMTPS id 69554106A61; Mon, 27 Jan 2014 17:14:47 +0100 (CET) Received: from DAPHNIS.office.hd ([169.254.2.144]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Mon, 27 Jan 2014 17:14:47 +0100 From: Juergen Quittek To: Benoit Claise , eman mailing list Thread-Topic: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib-13 Thread-Index: AQHPE6AHmAOXF01vlk+Ral4ysbWZOpqYxLyQ Date: Mon, 27 Jan 2014 16:14:46 +0000 Message-ID: <9AB93E4127C26F4BA7829DEFDCE5A6E8689109AC@DAPHNIS.office.hd> References: <5298B7FA.1010509@cisco.com> <52A5A9FA.80101@cisco.com> <52A5C2A6.9000501@cisco.com> <52AB8777.9060704@cisco.com> <653A4764-315C-4671-B0DA-389553CB3E29@lucidvision.com> <9AB93E4127C26F4BA7829DEFDCE5A6E8688B2E6C@DAPHNIS.office.hd> <52D9583D.6020603@cisco.com> In-Reply-To: <52D9583D.6020603@cisco.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.2.165] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib-13 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 27 Jan 2014 16:15:07 -0000 Hi Benoit, Thank you for your replies on all technical comments. I have two issues with the replies. One is stated in the email=20 below, the other one will come in a separate email. Energy Management Domain =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The eman framework states: "An Energy Object should=20 be a member of a single Energy Management Domain". Now and draft-ietf-eman-energy-aware-mib sharpens this to "Each Energy Object MUST belong to a single Energy=20 Management Domain". This change from "should" to "MUST" is inappropriate. The situation is that Cisco's EnergyWise uses a single domain=20 while some other products use multiple domains. We went=20 on with the recommendation for a single domain in the=20 framework because of the positive experience with=20 EnergyWise and no reported complaints on this from=20 EnergyWise customers. But no technical argument was ever given for restricting a device to be member of a single domain only. In contrary,=20 I reported from applications of the multiple domain approach=20 without anyone challenging this technically. The compromise in the framework was to recommend the=20 EnergyWise approach but not to completely exclude competing=20 approaches. With a change from "should" to "must" you changed a lot in=20 this game. I do not see any _technical_ reason for this step. In my comments I suggested a way that only needs a small=20 modification of one object's DESCRIPTION clause to be open for other implementations using multiple domains. My proposal still kept the recommendation for using a single domain only (even in the absence of a technical reason for this) but showed how to act if you have a strong need for multiple ones. I propose to stay with the compromise achieved in the framework document and leave the door open for implementations that have (as RFC 2119 says) "valid reasons in particular circumstances" to choose a multi-domain approach. Best regards, Juergen > -----Original Message----- > From: Benoit Claise [mailto:bclaise@cisco.com] > Sent: Freitag, 17. Januar 2014 17:20 > To: Juergen Quittek; eman mailing list > Subject: Re: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mi= b- > 08 and draft-ietf-eman-energy-aware-mib-13 >=20 > Hi Juergen, >=20 > Thanks for your thorough review. >=20 > Dear all, >=20 > Below please find my comments on draft-ietf-eman-energy-aware- > mib-13 titled "Energy Object Context MIB". I will send comments on draft-= ietf- > eman-energy-monitoring-mib-08 in a separate message. >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Technical comments: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > 1) Section 5.1, 3rd paragraph: Since you are already very precise > about this MUST, I would add that the name MUST NOT have length zero. >=20 > Not sure this is correct. RFC 6933 allows a zero-length string. See the s= econd > paragraph below. >=20 > entPhysicalName OBJECT-TYPE > SYNTAX SnmpAdminString > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The textual name of the physical entity. The value of this > object should be the name of the component as assigned by > the local device and should be suitable for use in commands > entered at the device's `console'. This might be a text > name (e.g., `console') or a simple component number (e.g., > port or module number, such as `1'), depending on the > physical component naming syntax of the device. >=20 > If there is no local name, or if this object is otherwise > not applicable, then this object contains a zero-length > string. >=20 > Note that the value of entPhysicalName for two physical > entities will be the same in the event that the console > interface does not distinguish between them, e.g., slot-1 > and the card in slot-1." > ::=3D { entPhysicalEntry 7 } >=20 > However, this sentence below is badly expressed >=20 > Every Energy Object MUST have a printable name assigned to it. > This sentence actually means that if an assigned name is used, it must be= a > printable one. > However, I wonder if this that sentence is needed at all, because we over= rule > the entPhysicalName definition from the ENTITY-V4 RFC. >=20 > On top of that, with SnmpAdminString, we should be good, no? >=20 > from http://www.ietf.org/rfc/rfc3411.txt, > SnmpAdminString ::=3D TEXTUAL-CONVENTION > DISPLAY-HINT "255t" > STATUS current > DESCRIPTION "An octet string containing administrative > information, preferably in human-readable form. >=20 > To facilitate internationalization, this > information is represented using the ISO/IEC > IS 10646-1 character set, encoded as an octet > string using the UTF-8 transformation format > described in [RFC2279]. >=20 > Since additional code points are added by > amendments to the 10646 standard from time > to time, implementations must be prepared to > encounter any code point from 0x00000000 to > 0x7fffffff. Byte sequences that do not > correspond to the valid UTF-8 encoding of a > code point or are outside this range are > prohibited. >=20 > The use of control codes should be avoided. >=20 > When it is necessary to represent a newline, > the control code sequence CR LF should be used. > The use of leading or trailing white space should > be avoided. >=20 > For code points not directly supported by user > interface hardware or software, an alternative > means of entry and display, such as hexadecimal, > may be provided. >=20 > For information encoded in 7-bit US-ASCII, > the UTF-8 encoding is identical to the > US-ASCII encoding. >=20 > UTF-8 may require multiple bytes to represent a > single character / code point; thus the length > of this object in octets may be different from > the number of characters encoded. Similarly, > size constraints refer to the number of encoded > octets, not the number of characters represented > by an encoding. >=20 > Note that when this TC is used for an object that > is used or envisioned to be used as an index, then > a SIZE restriction MUST be specified so that the > number of sub-identifiers for any object instance > does not exceed the limit of 128, as defined by > [RFC3416]. >=20 > Note that the size of an SnmpAdminString object is > measured in octets, not characters. > " > SYNTAX OCTET STRING (SIZE (0..255)) >=20 > Proposal, to make it clear that printable names are really a plus: > OLD: > "Every Energy Object MUST have a printable name assigned to it" > NEW: > "While entPhysicalName does allow zero-length name, every Energy > Object should have a printable name assigned to it" >=20 >=20 >=20 > 2) Section 5.1, one but last paragraph: "Each Energy Object MUST > belong to a single Energy Management Domain or in other words, an Energy > Object cannot belong to more than one Energy Management Domain." This is > more strict than in the framework where we say an EO "should" not belong = to > more than one domain. However, as we have discussed several times, there > are management systems that use more than one domain (different to > EnergyWise). I do not see a good reason to declare that their model is wr= ong. > Thus, we can recommend "make it as EnergWise from Cisco does it" with the > "should" clause that we have in the framework, but we should not fully > exclude other solutions with a "must" clause. See also comment 7). >=20 > Thanks for catching this discrepancy. > The framework mentions on one side: >=20 > The Energy Object (Class) contains a string attribute to > indicate membership in an Energy Management Domain. > It's true that this framework sentence contradicts this: >=20 > An Energy Object should be a member of a single Energy > Management Domain therefore one attribute is provided. >=20 > This last sentence doesn't reflect what was discussed at > http://www.ietf.org/mail-archive/web/eman/current/msg02033.html >=20 >=20 > 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. >=20 >=20 > And, most importantly, http://www.ietf.org/mail- > archive/web/eman/current/msg02037.html, which is the outcome of the > authors call, supervised by Nevil: >=20 >=20 > *** Scalar vs Vector > Category - overloaded if vectore { cons, prod, meter, distributo= r, > store } > Primary is better received > ex: car { biz, pleasure, commute } > Role - need semantic not vector > Location? (new) - clearly not vector but semantic like rfc4776 > better 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 >=20 >=20 > The framework should correct this sentence: > OLD: >=20 > An Energy Object should be a member of a single Energy > Management Domain therefore one attribute is provided. > NEW: >=20 > An Energy Object must be a member of a single Energy > Management Domain therefore one attribute is provided. >=20 >=20 >=20 > 3) Section 5.3, 2nd and 3rd paragraph: > Both paragraphs need more explanation and you need to make them > consistent with the text in the MIB modules. For LLDP you say "If the LLD= P MIB > is implemented". Why don't you have a similar statement for the PoE MIB? > You talk about "the" Energy Object SNMP agent. However, EOs may not have > SNMP agents, for example, if they are just a power interface. And it is n= ot > specified which of the potentially numerous instances of lldpLocPortNum > objects of a device should be reported. >=20 > Ack, will provide some new text >=20 >=20 >=20 > 4) Section 5.4, 4th paragraph: > "Since the communication between the Energy Objects may not be > SNMP and is left to the choice of the device manufacturer, an > Energy Object can have additional MIB objects that can be used > for easier identification by the EnMS." > Two comments on this sentence: > A) It is not very obvious if SNMP is not available, it makes sense to us= e > MIB objects. Please clarify this. > B) Please note that the choice is not only with the manufacturer. Even > if the manufacturer builds in SNMP, the operator may choose to disable it= ;-) >=20 > This is a badly written sentence. > Proposal: remove >=20 >=20 > "Since the communication between the Energy Objects may not be > SNMP and is left to the choice of the device manufacturer" >=20 >=20 >=20 > 5) Section 6, DESCRIPTION clause of object eoEthPortIndex: > What "attached device" are you talking about? > Why is it relevant for the specification of this object, if that a certa= in > MIB module "should" be implemented on that device? Does it make any > different for the DESCRIPTION of this object whether or not this MIB modu= le is > implemented on the attached device? I do not see why and thus recommend > removing the statement "PoE MIB should be instantiated on the device." >=20 > New text will be proposed. >=20 >=20 >=20 > 6) Section 6, DESCRIPTION clause of object eoMgmtDNSName: > There may be more than one DNS name associated to a single IP > address: > "the DNS name" -> "a DNS name" >=20 > fixed >=20 >=20 >=20 >=20 > 7) Section 6, DESCRIPTION clause of object eoDomainName: > Please insert as second sentence: "If the energy object has been > assigned to multiple domains, then they are represented in this object as > comma-separated list.", see comment 2). >=20 > See point 2. >=20 >=20 >=20 > 8) Section 6, SYNTAX clause of object eoPowerCategory: > Some devices match more than one category, for example a UPS is a > store and a distributor at the same time, and to be precise, also a consu= mer. A > PoE Switch is a consumer and a distributor, some devices switch between > consumer and producer, etc. We can support all of this if we change the > syntax from INTEGER to BITS. >=20 > See point 2, for the justification, discussed at the [EMAN-FMWK] time, on= why > not to do this. >=20 >=20 >=20 > 9) Section 6, DESCRIPTION clause of object eoAlternateKey: > There is a contradiction between having this object with MAX-ACCESS > read-write and stating " This object specifies a manufacturer defined str= ing". If > the manufacturer defines the string, there is no need to write it. I sugg= est > allowing the operator to set the value of this document. >=20 > The use of the "manufacturer" word is a poor choice. > This corresponds to section 5.3: >=20 > The eoAlternateKey alternate key object specifies a manufacturer > defined string that can be used to identify the Energy Object. > Since an EnMS may need to correlate objects across management > systems, this alternate key is provided to facilitate such a > link. This optional value is intended as a foreign key or > alternate identifier for a manufacturer or EnMS to use to > correlate the unique Energy Object Id in other systems or > namespaces. If an alternate key is not available or is not > applicable then the value is the zero-length string. >=20 > Proposal: change to "alternate" >=20 > In section 5.3 > OLD: >=20 > The eoAlternateKey alternate key object specifies a manufacturer > defined string that can be used to identify the Energy Object. > NEW: > The eoAlternateKey object specifies an alternate key string > that can be used to identify the Energy Object. > OLD: >=20 > eoAlternateKey OBJECT-TYPE > SYNTAX SnmpAdminString > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "This object specifies a manufacturer defined string that > can be used to identify the Energy Object. > NEW: >=20 > eoAlternateKey OBJECT-TYPE > SYNTAX SnmpAdminString > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "This object specifies an alternate key string >=20 >=20 >=20 >=20 > 10) Section 6, DESCRIPTION clause of object eoRelationID: > I recommend adding a sentence to the DESCRIPTION clause, that > preferable the value of an entPhysicalUUID from the Entity MIB should be > used for values of this object. >=20 > ok. >=20 >=20 >=20 >=20 > 11) Section 6, Conformance of ENERGY-OBJECT-CONTEXT-MIB module: > The dependence of compliance with entity4CRCompliance is stated in > the GROUP DESCRIPTION clauses. In our case, this is not the right place. = There > is a dependency on entity4CRCompliance independent of which group is > implemented. Hence, these statements need to be moved from the GROUP > DESCRIPTION clauses to the module compliance DESCRIPTION clauses of > energyObjectContextMIBFullCompliance and > energyObjectContextMIBReadOnlyCompliance. >=20 > That makes sense. >=20 >=20 >=20 >=20 > 12) Section 6, Conformance of ENERGY-OBJECT-CONTEXT-MIB module: > We state in other places that implementation of the Entity MIB > compliant with entity4CRCompliance is a must. But in the conformance sect= ion > of the ENERGY-OBJECT-CONTEXT-MIB the dependency on > entity4CRCompliance is stated as "should". This need to be changed to a > "must" or "required." >=20 > Good catch. >=20 >=20 >=20 >=20 > 13) Section 6, DESCRIPTION clause of TC IANAEnergyRelationship: > For interoperability, the description need to be clear. As this TC is > stated, there are two points unclear to me: > A) " The enumeration 'poweredBy' is applicable if the > Energy Object A is poweredBy Energy Object B. > The enumeration 'powering' is applicable if the > Energy Object A is powering Energy Object B." > If the TC is used, how do I know which object is A and which is B? Is it > that the DESCRIPTION clauses of objects of this type must refer to object= A and > object B? >=20 > OLD: >=20 > IANAEnergyRelationship ::=3D TEXTUAL-CONVENTION > STATUS current > DESCRIPTION > "An enumerated value specifies the type of > relationship between Energy Objects. > NEW: >=20 > IANAEnergyRelationship ::=3D TEXTUAL-CONVENTION > STATUS current > DESCRIPTION > "An enumerated value specifying the type of > relationship between an Energy Object A, on which > the relationship is specified, with the Energy Object= B, > characterized by the UUID." >=20 >=20 > B) "if the Energy Object A is aggregating Energy Object B" > There is no place in this document where there is explained what > aggregating means. >=20 > Part of section 5.4, we refer to [EMAN-FMWK], which defines the aggregati= on > relationship as a summation. I guess you want some more text in this sect= ion > 5.4? >=20 >=20 >=20 >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Editorial comments: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > All these will be taken care of. >=20 > Thanks again. >=20 > Regards, Benoit. >=20 >=20 >=20 >=20 > 14) Abstract, last two lines: > "relationships between reporting devices, remote devices, and > monitoring devices.": The enumeration of "reporting devices", "monitoring > devices", and "remote devices" is inappropriate because it does not refle= ct > the list of relationships discussed by the draft: poweredBy, meteredBy, > aggregatedBy. >=20 > 15) Section 1. Introduction, 2nd paragraph, last two lines: > "Identification" -> "identification" > "Context" -> "context" > "Relationships" -> "relationships" >=20 > 16) Section 1.1, 3rd paragraph, line 1: > "A second MIB module required by the [EMAN-FMWK]": There is no > MIB module required by the EMAN framework. It seems you wanted to say: "A > second MIB module meeting EMAN requirements given by [RFC6988]". >=20 > 17) Entire Section 3 > This section is completely redundant. It mainly repeats sentences of > section 1.1. Remove this section and merge sentences you want to keep int= o > section 1.1 >=20 > 18) Section 5, 3rd paragraph, first sentence: > The sentence is not grammatically correct, please fix. Also semantic > correction seems to be needed. You don't mention "identification" as focu= s of > the first table. >=20 > 19) Section 5, sentence before Figure 1: > "The following UML diagram illustrates the relationship of the > MIB objects in the eoTable, eoRelationTable that describe the > identity, context and relationship of an Energy Object." > You should mention that you UML diagram furthermore contains > objects from the Entity MIB. >=20 > 20) Section 5, figure 1: > There is a dotted line at the lower left that goes nowhere. Please cut > it. >=20 > 21) Section 5, grouping of MIB objects is inconsistent. > In Figure 1 you have three groups: "Context", "Identification", > "Relationships", where "Identifications" has three subgroups. The sentenc= e > below the figure emphasizes this grouping. However, the following > subsections 5.1-5.4 are grouped differently. 5.1 is titled "Identificatio= n" but > covers only a third of the objects under "Identification" in Figure 1. Se= ction > 5.2 is consistently with Figure 1 covering context information. Section 5= .3 > covers PoE and LLDP identification. Sections 5.4 is called "Relationships= " but > covers not just the objects under "Relationships" in Figure 1, but also o= bjects > from under "Identification" in Figure 1. Here is a clean-up needed. Pleas= e split > the last sentence from section 5.4. It firs much better in section 5.3. >=20 > 22) Section 5, enumeration under Figure 1: > Please note that subsection 5.5 is not another group of MIB objects > but refers to objects in subsection 5.1. The sentence above the enumerati= on > implies that each numbered item would be a group of objects. >=20 > 23) Section 5.1, 2nd paragraph, line 7: > What is "primary Energy Object information"? >=20 > 24) Section 5.4, 2nd paragraph, last sentence: > "It is important to notice, that it is possible that" -> "Obviously," > "not have an" -> "not have any" >=20 > 25) Section 5.4, 4th paragraph > The entire paragraph is in the wrong subsection. It rather belongs to > subsection 5.1 or 5.3. >=20 > 26) Section 6, DESCRIPTION clause of object eoEthPortGrpIndex: > See comment 5). There is a full stop missing at the end of the second > sentence. >=20 > 27) Section 6, OBJECTS clause of GROUP > energyObjectRelationTableGroup: > The comment "Note that object eoRelationIndex is not included since > it is not-accessible" is not really needed. Almost every Conformance sect= ion > has such objects and usually this comment is omitted. >=20 > Cheers, > Juergen >=20 >=20 >=20 > -----Original Message----- > From: eman [mailto:eman-bounces@ietf.org] On Behalf Of > Thomas Nadeau > Sent: Montag, 16. Dezember 2013 16:56 > To: eman mailing list > Subject: [eman] WG Last Call for draft-ietf-eman-energy- > monitoring-mib-08 > and draft-ietf-eman-energy-aware-mib-13 >=20 >=20 > As agreed at the last WG meeting, with the EMAN > Framework > completing its WG LC the chairs would like to initiate a WG LC > on draft-ietf- > eman-energy-monitoring-mib-08 and draft-ietf-eman-energy- > aware-mib-13. > The WG LC will end on Dec 30 at 8AM EDT. >=20 > Thank you, >=20 > Nevil and Tom >=20 >=20 >=20 > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman > . >=20 >=20 From tnadeau@lucidvision.com Mon Jan 27 08:48:46 2014 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E25C1A035D for ; Mon, 27 Jan 2014 08:48:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.434 X-Spam-Level: X-Spam-Status: No, score=-2.434 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xtem_mqA8PrO for ; Mon, 27 Jan 2014 08:48:40 -0800 (PST) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 103F41A035B for ; Mon, 27 Jan 2014 08:48:40 -0800 (PST) Received: from [192.168.1.110] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id AAC5326CB9A7; Mon, 27 Jan 2014 11:48:37 -0500 (EST) Content-Type: multipart/signed; boundary="Apple-Mail=_099A62C6-097D-4963-99A5-47AECFC23EC3"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Thomas Nadeau In-Reply-To: <52DC578D.30105@cisco.com> Date: Mon, 27 Jan 2014 11:48:36 -0500 Message-Id: References: <52D9583D.6020603@cisco.com> <52DC578D.30105@cisco.com> To: eman mailing list X-Mailer: Apple Mail (2.1827) Cc: eman-chairs@tools.ietf.org Subject: Re: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib-13 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 27 Jan 2014 16:48:46 -0000 --Apple-Mail=_099A62C6-097D-4963-99A5-47AECFC23EC3 Content-Type: multipart/alternative; boundary="Apple-Mail=_C3478EB4-DEF6-4884-A611-533ABF567C10" --Apple-Mail=_C3478EB4-DEF6-4884-A611-533ABF567C10 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii =09 EMAN WG, Nevil, Benoit and I have discussed this issue at length. Given = the 11:45th hour on this document, we independently went=20 through the history of the document as well as the various LC comments = to see if there was a simple and quick=20 solution to the point Juergen raised during the LC. It seems that the = language of MUST or SHOULD makes a=20 big difference at the MIB level and/or makes the MIBs not-conforming = with the Framework depending on what we decide to do here. There does seem to be some history behind this one, whereby the = document was changed to a SHOULD from a MUST.=20 Just a little background on the matter: The current framework contains a SHOULD in section 6.3.6 that is = kind of contradicted by the "recommended ... 1:1" text above it.=20 One way or another, these need to be made consistent and = painfully obvious: 6.3.6. Context: Domain=20 =20 =20 =20 Claise et al. Expires October 30 2015 [Page 17]=20 =20 Internet-Draft EMAN Framework January 2014=20 =20 The Energy Object (Class) contains a string attribute to=20 indicate membership in an Energy Management Domain. An=20 Energy Management Domain can be any collection of Energy=20 Objects in a deployment, but it is recommended to map 1:1=20 with a metered or sub-metered portion of the site. =20 =20 In building management, a meter refers to the meter=20 provided by the utility used for billing and measuring=20 power to an entire building or unit within a building. A=20 sub-meter refers to a customer- or user-installed meter=20 that is not used by the utility to bill but is instead used=20 to get measurements from sub portions of a building.=20 =20 An Energy Object should be a member of a single Energy=20 Management Domain therefore one attribute is provided.=20 In order conform to the framework, The Energy-Mon MIB has = Section 6, DESCRIPTION clause of object eoDomainName: Please insert as second sentence: "If the energy object = has been assigned to multiple domains, then they are represented in this = object as comma-separated list.", see comment 2). The issue here is that comma-separated string is a pain as the = NMS has to check every string for comma. But the alternatives are far = more messy. Based on the above, this point we believe there is one option = that will sort this situation out: Change the "should" to a "must" as well as the "recommended" to = a "must" in the framework. That makes the framework itself consistent=20 without any doubt as to there being a single domain per object. This = also fixes the issue above with the MIB.=20 --Tom =09 > -------- Original Message -------- > Subject: Re: [eman] WG Last Call for = draft-ietf-eman-energy-monitoring-mib-08 and = draft-ietf-eman-energy-aware-mib-13 > Date: Fri, 17 Jan 2014 17:20:13 +0100 > From: Benoit Claise > To: Juergen Quittek , eman mailing list = >=20 > Hi Juergen, >=20 > Thanks for your thorough review. >> Dear all, >>=20 >> Below please find my comments on draft-ietf-eman-energy-aware-mib-13 = titled "Energy Object Context MIB". I will send comments on = draft-ietf-eman-energy-monitoring-mib-08 in a separate message. >>=20 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> Technical comments: >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >> 1) Section 5.1, 3rd paragraph: Since you are already very precise = about this MUST, I would add that the name MUST NOT have length zero. > Not sure this is correct. RFC 6933 allows a zero-length string. See = the second paragraph below. > entPhysicalName OBJECT-TYPE > SYNTAX SnmpAdminString > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The textual name of the physical entity. The value of = this > object should be the name of the component as assigned by > the local device and should be suitable for use in = commands > entered at the device's `console'. This might be a text > name (e.g., `console') or a simple component number (e.g., > port or module number, such as `1'), depending on the > physical component naming syntax of the device. >=20 > If there is no local name, or if this object is otherwise > not applicable, then this object contains a zero-length > string. >=20 > Note that the value of entPhysicalName for two physical > entities will be the same in the event that the console > interface does not distinguish between them, e.g., slot-1 > and the card in slot-1." > ::=3D { entPhysicalEntry 7 } >=20 > However, this sentence below is badly expressed > Every Energy Object MUST have a printable name assigned to it. > This sentence actually means that if an assigned name is used, it must = be a printable one. > However, I wonder if this that sentence is needed at all, because we = overrule the entPhysicalName definition from the ENTITY-V4 RFC. > On top of that, with SnmpAdminString, we should be good, no? >=20 > from http://www.ietf.org/rfc/rfc3411.txt,=20 > SnmpAdminString ::=3D TEXTUAL-CONVENTION > DISPLAY-HINT "255t" > STATUS current > DESCRIPTION "An octet string containing administrative > information, preferably in human-readable form. >=20 > To facilitate internationalization, this > information is represented using the ISO/IEC > IS 10646-1 character set, encoded as an octet > string using the UTF-8 transformation format > described in [RFC2279]. >=20 > Since additional code points are added by > amendments to the 10646 standard from time > to time, implementations must be prepared to > encounter any code point from 0x00000000 to > 0x7fffffff. Byte sequences that do not > correspond to the valid UTF-8 encoding of a > code point or are outside this range are > prohibited. >=20 > The use of control codes should be avoided. >=20 > When it is necessary to represent a newline, > the control code sequence CR LF should be used. > The use of leading or trailing white space should > be avoided. >=20 > For code points not directly supported by user > interface hardware or software, an alternative > means of entry and display, such as hexadecimal, > may be provided. >=20 > For information encoded in 7-bit US-ASCII, > the UTF-8 encoding is identical to the > US-ASCII encoding. >=20 > UTF-8 may require multiple bytes to represent a > single character / code point; thus the length > of this object in octets may be different from > the number of characters encoded. Similarly, > size constraints refer to the number of encoded > octets, not the number of characters represented > by an encoding. >=20 > Note that when this TC is used for an object that > is used or envisioned to be used as an index, then > a SIZE restriction MUST be specified so that the > number of sub-identifiers for any object instance > does not exceed the limit of 128, as defined by > [RFC3416]. >=20 > Note that the size of an SnmpAdminString object is > measured in octets, not characters. > " > SYNTAX OCTET STRING (SIZE (0..255)) >=20 > Proposal, to make it clear that printable names are really a plus: > OLD: > "Every Energy Object MUST have a printable name assigned to it" > NEW: > "While entPhysicalName does allow zero-length name, every = Energy=20 > Object should have a printable name assigned to it" >> 2) Section 5.1, one but last paragraph: "Each Energy Object MUST = belong to a single Energy Management Domain or in other words, an Energy = Object cannot belong to more than one Energy Management Domain." This is = more strict than in the framework where we say an EO "should" not belong = to more than one domain. However, as we have discussed several times, = there are management systems that use more than one domain (different to = EnergyWise). I do not see a good reason to declare that their model is = wrong. Thus, we can recommend "make it as EnergWise from Cisco does it" = with the "should" clause that we have in the framework, but we should = not fully exclude other solutions with a "must" clause. See also comment = 7). > Thanks for catching this discrepancy. > The framework mentions on one side: > The Energy Object (Class) contains a string attribute to > indicate membership in an Energy Management Domain.=20 > It's true that this framework sentence contradicts this: > An Energy Object should be a member of a single Energy > Management Domain therefore one attribute is provided. >=20 > This last sentence doesn't reflect what was discussed at > http://www.ietf.org/mail-archive/web/eman/current/msg02033.html > 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. >=20 > And, most importantly, = http://www.ietf.org/mail-archive/web/eman/current/msg02037.html, which = is the outcome of the authors call, supervised by Nevil: > *** 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 = better 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 >=20 > The framework should correct this sentence: > OLD: > An Energy Object should be a member of a single Energy > Management Domain therefore one attribute is provided. > NEW: > An Energy Object must be a member of a single Energy > Management Domain therefore one attribute is provided. >> 3) Section 5.3, 2nd and 3rd paragraph: >> Both paragraphs need more explanation and you need to make them = consistent with the text in the MIB modules. For LLDP you say "If the = LLDP MIB is implemented". Why don't you have a similar statement for the = PoE MIB? You talk about "the" Energy Object SNMP agent. However, EOs may = not have SNMP agents, for example, if they are just a power interface. = And it is not specified which of the potentially numerous instances of = lldpLocPortNum objects of a device should be reported. > Ack, will provide some new text >>=20 >> 4) Section 5.4, 4th paragraph: >> "Since the communication between the Energy Objects may not be=20 >> SNMP and is left to the choice of the device manufacturer, an=20 >> Energy Object can have additional MIB objects that can be used=20 >> for easier identification by the EnMS." >> Two comments on this sentence: >> A) It is not very obvious if SNMP is not available, it makes sense to = use MIB objects. Please clarify this. >> B) Please note that the choice is not only with the manufacturer. = Even if the manufacturer builds in SNMP, the operator may choose to = disable it ;-) > This is a badly written sentence. > Proposal: remove > "Since the communication between the Energy Objects may not be=20 > SNMP and is left to the choice of the device manufacturer"=20 >> 5) Section 6, DESCRIPTION clause of object eoEthPortIndex: >> What "attached device" are you talking about? >> Why is it relevant for the specification of this object, if that a = certain MIB module "should" be implemented on that device? Does it make = any different for the DESCRIPTION of this object whether or not this MIB = module is implemented on the attached device? I do not see why and thus = recommend removing the statement "PoE MIB should be instantiated on the = device." > New text will be proposed. >>=20 >> 6) Section 6, DESCRIPTION clause of object eoMgmtDNSName: >> There may be more than one DNS name associated to a single IP = address: >> "the DNS name" -> "a DNS name" > fixed >> 7) Section 6, DESCRIPTION clause of object eoDomainName: >> Please insert as second sentence: "If the energy object has been = assigned to multiple domains, then they are represented in this object = as comma-separated list.", see comment 2). > See point 2. >>=20 >> 8) Section 6, SYNTAX clause of object eoPowerCategory: >> Some devices match more than one category, for example a UPS is a = store and a distributor at the same time, and to be precise, also a = consumer. A PoE Switch is a consumer and a distributor, some devices = switch between consumer and producer, etc. We can support all of this if = we change the syntax from INTEGER to BITS. > See point 2, for the justification, discussed at the [EMAN-FMWK] time, = on why not to do this. >>=20 >> 9) Section 6, DESCRIPTION clause of object eoAlternateKey: >> There is a contradiction between having this object with MAX-ACCESS = read-write and stating " This object specifies a manufacturer defined = string". If the manufacturer defines the string, there is no need to = write it. I suggest allowing the operator to set the value of this = document. > The use of the "manufacturer" word is a poor choice. > This corresponds to section 5.3: > The eoAlternateKey alternate key object specifies a = manufacturer > defined string that can be used to identify the Energy Object. > Since an EnMS may need to correlate objects across management = =20 > systems, this alternate key is provided to facilitate such a > link. This optional value is intended as a foreign key or > alternate identifier for a manufacturer or EnMS to use to > correlate the unique Energy Object Id in other systems or > namespaces. If an alternate key is not available or is not > applicable then the value is the zero-length string. >=20 > Proposal: change to "alternate" >=20 > In section 5.3 > OLD: > The eoAlternateKey alternate key object specifies a = manufacturer > defined string that can be used to identify the Energy Object. > NEW: > The eoAlternateKey object specifies an alternate key string > that can be used to identify the Energy Object. > OLD: > eoAlternateKey OBJECT-TYPE > SYNTAX SnmpAdminString > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "This object specifies a manufacturer defined string = that > can be used to identify the Energy Object. > NEW: > eoAlternateKey OBJECT-TYPE > SYNTAX SnmpAdminString > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "This object specifies an alternate key string >=20 >> 10) Section 6, DESCRIPTION clause of object eoRelationID: >> I recommend adding a sentence to the DESCRIPTION clause, that = preferable the value of an entPhysicalUUID from the Entity MIB should be = used for values of this object. > ok. >> 11) Section 6, Conformance of ENERGY-OBJECT-CONTEXT-MIB module:=20 >> The dependence of compliance with entity4CRCompliance is stated in = the GROUP DESCRIPTION clauses. In our case, this is not the right place. = There is a dependency on entity4CRCompliance independent of which group = is implemented. Hence, these statements need to be moved from the GROUP = DESCRIPTION clauses to the module compliance DESCRIPTION clauses of = energyObjectContextMIBFullCompliance and = energyObjectContextMIBReadOnlyCompliance. > That makes sense. >> 12) Section 6, Conformance of ENERGY-OBJECT-CONTEXT-MIB module: >> We state in other places that implementation of the Entity MIB = compliant with entity4CRCompliance is a must. But in the conformance = section of the ENERGY-OBJECT-CONTEXT-MIB the dependency on = entity4CRCompliance is stated as "should". This need to be changed to a = "must" or "required." > Good catch. >> 13) Section 6, DESCRIPTION clause of TC IANAEnergyRelationship: >> For interoperability, the description need to be clear. As this TC is = stated, there are two points unclear to me: >> A) " The enumeration 'poweredBy' is applicable if the =20 >> Energy Object A is poweredBy Energy Object B.=20 >> The enumeration 'powering' is applicable if the =20 >> Energy Object A is powering Energy Object B." >> If the TC is used, how do I know which object is A and which is B? Is = it that the DESCRIPTION clauses of objects of this type must refer to = object A and object B? > OLD: > IANAEnergyRelationship ::=3D TEXTUAL-CONVENTION > STATUS current > DESCRIPTION > "An enumerated value specifies the type of > relationship between Energy Objects. > NEW: > IANAEnergyRelationship ::=3D TEXTUAL-CONVENTION > STATUS current > DESCRIPTION > "An enumerated value specifying the type of > relationship between an Energy Object A, on which=20= > the relationship is specified, with the Energy = Object B,=20 > characterized by the UUID." >> B) "if the Energy Object A is aggregating Energy Object B" >> There is no place in this document where there is explained what = aggregating means. > Part of section 5.4, we refer to [EMAN-FMWK], which defines the = aggregation relationship as a summation. I guess you want some more text = in this section 5.4? >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> Editorial comments: >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > All these will be taken care of. >=20 > Thanks again. >=20 > Regards, Benoit. >> 14) Abstract, last two lines: >> "relationships between reporting devices, remote devices, and = monitoring devices.": The enumeration of "reporting devices", = "monitoring devices", and "remote devices" is inappropriate because it = does not reflect the list of relationships discussed by the draft: = poweredBy, meteredBy, aggregatedBy. >>=20 >> 15) Section 1. Introduction, 2nd paragraph, last two lines: >> "Identification" -> "identification" >> "Context" -> "context" >> "Relationships" -> "relationships" >>=20 >> 16) Section 1.1, 3rd paragraph, line 1: >> "A second MIB module required by the [EMAN-FMWK]": There is no MIB = module required by the EMAN framework. It seems you wanted to say: "A = second MIB module meeting EMAN requirements given by [RFC6988]". >>=20 >> 17) Entire Section 3 >> This section is completely redundant. It mainly repeats sentences of = section 1.1. Remove this section and merge sentences you want to keep = into section 1.1 >>=20 >> 18) Section 5, 3rd paragraph, first sentence: >> The sentence is not grammatically correct, please fix. Also semantic = correction seems to be needed. You don't mention "identification" as = focus of the first table. >>=20 >> 19) Section 5, sentence before Figure 1: >> "The following UML diagram illustrates the relationship of the=20 >> MIB objects in the eoTable, eoRelationTable that describe the=20 >> identity, context and relationship of an Energy Object." >> You should mention that you UML diagram furthermore contains objects = from the Entity MIB. >>=20 >> 20) Section 5, figure 1: >> There is a dotted line at the lower left that goes nowhere. Please = cut it. >>=20 >> 21) Section 5, grouping of MIB objects is inconsistent. >> In Figure 1 you have three groups: "Context", "Identification", = "Relationships", where "Identifications" has three subgroups. The = sentence below the figure emphasizes this grouping. However, the = following subsections 5.1-5.4 are grouped differently. 5.1 is titled = "Identification" but covers only a third of the objects under = "Identification" in Figure 1. Section 5.2 is consistently with Figure 1 = covering context information. Section 5.3 covers PoE and LLDP = identification. Sections 5.4 is called "Relationships" but covers not = just the objects under "Relationships" in Figure 1, but also objects = from under "Identification" in Figure 1. Here is a clean-up needed. = Please split the last sentence from section 5.4. It firs much better in = section 5.3. >>=20 >> 22) Section 5, enumeration under Figure 1: >> Please note that subsection 5.5 is not another group of MIB objects = but refers to objects in subsection 5.1. The sentence above the = enumeration implies that each numbered item would be a group of objects. >>=20 >> 23) Section 5.1, 2nd paragraph, line 7: >> What is "primary Energy Object information"?=20 >>=20 >> 24) Section 5.4, 2nd paragraph, last sentence: >> "It is important to notice, that it is possible that" -> "Obviously," >> "not have an" -> "not have any" >>=20 >> 25) Section 5.4, 4th paragraph >> The entire paragraph is in the wrong subsection. It rather belongs to = subsection 5.1 or 5.3. >>=20 >> 26) Section 6, DESCRIPTION clause of object eoEthPortGrpIndex: >> See comment 5). There is a full stop missing at the end of the second = sentence. >>=20 >> 27) Section 6, OBJECTS clause of GROUP = energyObjectRelationTableGroup: >> The comment "Note that object eoRelationIndex is not included since = it is not-accessible" is not really needed. Almost every Conformance = section has such objects and usually this comment is omitted. >>=20 >> Cheers, >> Juergen >>=20 >>=20 >>> -----Original Message----- >>> From: eman [mailto:eman-bounces@ietf.org] On Behalf Of Thomas Nadeau >>> Sent: Montag, 16. Dezember 2013 16:56 >>> To: eman mailing list >>> Subject: [eman] WG Last Call for = draft-ietf-eman-energy-monitoring-mib-08 >>> and draft-ietf-eman-energy-aware-mib-13 >>>=20 >>>=20 >>> As agreed at the last WG meeting, with the EMAN Framework >>> completing its WG LC the chairs would like to initiate a WG LC on = draft-ietf- >>> eman-energy-monitoring-mib-08 and = draft-ietf-eman-energy-aware-mib-13. >>> The WG LC will end on Dec 30 at 8AM EDT. >>>=20 >>> Thank you, >>>=20 >>> Nevil and Tom >>>=20 >> _______________________________________________ >> eman mailing list >> eman@ietf.org >> https://www.ietf.org/mailman/listinfo/eman >> . >>=20 >=20 >=20 >=20 > --Apple-Mail=_C3478EB4-DEF6-4884-A611-533ABF567C10 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
EMAN = WG,

Nevil, Benoit and I have = discussed this issue at length. Given the 11:45th hour on this document, = we independently went 
through the history of the = document as well as the various LC comments to see if there was a simple = and quick 
solution to the point Juergen raised during = the LC. It seems that the language of MUST or SHOULD makes = a 
big difference at the MIB level and/or makes the MIBs = not-conforming with the Framework depending on what we decide to = do
here.  There does seem to be some history behind = this one, whereby the document was changed to a SHOULD from a = MUST. 

Just a little background on the = matter:

The current framework contains a = SHOULD in section 6.3.6 that is kind of contradicted by the "recommended = ... 1:1" text above it. 

One way = or another, these need to be made consistent and painfully = obvious:

 6.3.6. Context: =
Domain=20
       =20

    =20
    =20
    Claise et al.          Expires October 30 2015      [Page 17]=20
       =20

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


In order = conform to the framework, The Energy-Mon MIB has Section 6, = DESCRIPTION clause of object = eoDomainName:

Please insert as second = sentence: "If the energy object has been assigned to
= multiple domains, then they are represented in this object as = comma-separated
list.", see comment = 2).

The issue here is that = comma-separated string is a pain as the NMS has to check every string = for comma. But the alternatives are far more = messy.


Based on = the above, this point we believe there is one option that will sort = this situation out:

Change = the "should" to a "must" as well as the "recommended" to a "must" in the = framework. That makes the framework itself = consistent 
without any doubt as to there being a single = domain per object. This also fixes the issue above with the = MIB. 

= --Tom




=
-------- Original Message --------
Subject: Re: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib-13
Date: Fri, 17 Jan 2014 17:20:13 +0100
From: Benoit Claise <bclaise@cisco.com>
To: = Juergen Quittek <Quittek@neclab.eu>, eman = mailing list <eman@ietf.org>


Hi Juergen,

Thanks for your thorough review.
Dear all,

Below please find my comments on draft-ietf-eman-energy-aware-mib-13 =
titled "Energy Object Context MIB". I will send comments on =
draft-ietf-eman-energy-monitoring-mib-08 in a separate message.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Technical comments:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

1) Section 5.1, 3rd paragraph: Since you are already very precise about =
this MUST, I would add that the name MUST NOT have length zero.
Not sure this is correct. RFC 6933 allows a zero-length string. See the second paragraph below.
entPhysicalName OBJECT-TYPE
    SYNTAX      SnmpAdminString
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
            "The textual name of the physical entity.  The value of this
            object should be the name of the component as assigned by
            the local device and should be suitable for use in commands
            entered at the device's `console'.  This might be a text
            name (e.g., `console') or a simple component number (e.g.,
            port or module number, such as `1'), depending on the
            physical component naming syntax of the device.

            If there is no local name, or if this object is otherwise
            not applicable, then this object contains a zero-length
            string.

            Note that the value of entPhysicalName for two physical
            entities will be the same in the event that the console
            interface does not distinguish between them, e.g., slot-1
            and the card in slot-1."
    ::=3D { entPhysicalEntry 7 }

However, this sentence below is badly expressed
  Every Energy Object MUST have a printable =
name assigned to it.
This sentence actually means that if an assigned name is used, it must be a printable one.
However, I wonder if this that sentence is needed at all, because we overrule the entPhysicalName definition from the ENTITY-V4 = RFC.
On top of that, with SnmpAdminString, we should be =
good, no?

from http://www.ietf.org/rfc/rfc34=
11.txt,=20
SnmpAdminString ::=3D TEXTUAL-CONVENTION
    DISPLAY-HINT "255t"
    STATUS       current
    DESCRIPTION "An octet string containing administrative
                 information, preferably in human-readable form.

                 To facilitate internationalization, this
                 information is represented using the ISO/IEC
                 IS 10646-1 character set, encoded as an octet
                 string using the UTF-8 transformation format
                 described in [RFC2279].

                 Since additional code points are added by
                 amendments to the 10646 standard from time
                 to time, implementations must be prepared to
                 encounter any code point from 0x00000000 to
                 0x7fffffff.  Byte sequences that do not
                 correspond to the valid UTF-8 encoding of a
                 code point or are outside this range are
                 prohibited.

                 The use of control codes should be avoided.

                 When it is necessary to represent a newline,
                 the control code sequence CR LF should be used.
                 The use of leading or trailing white space should
                 be avoided.

                 For code points not directly supported by user
                 interface hardware or software, an alternative
                 means of entry and display, such as hexadecimal,
                 may be provided.

                 For information encoded in 7-bit US-ASCII,
                 the UTF-8 encoding is identical to the
                 US-ASCII encoding.

                 UTF-8 may require multiple bytes to represent a
                 single character / code point; thus the length
                 of this object in octets may be different from
                 the number of characters encoded.  Similarly,
                 size constraints refer to the number of encoded
                 octets, not the number of characters represented
                 by an encoding.

                 Note that when this TC is used for an object that
                 is used or envisioned to be used as an index, then
                 a SIZE restriction MUST be specified so that the
                 number of sub-identifiers for any object instance
                 does not exceed the limit of 128, as defined by
                 [RFC3416].

                 Note that the size of an SnmpAdminString object is
                 measured in octets, not characters.
                "
    SYNTAX       OCTET STRING (SIZE (0..255))

Proposal, to make it clear that printable names are really a plus:
OLD:
	 "Every Energy Object MUST have a printable name assigned =
to it"
NEW:
	 "While entPhysicalName does allow zero-length name, every =
Energy=20
         Object should have a printable name assigned to it"

2) Section 5.1, one but last paragraph: "Each =
Energy Object MUST belong to a single Energy Management Domain or in =
other words, an Energy Object cannot belong to more than one Energy =
Management Domain." This is more strict than in the framework where we =
say an EO "should" not belong to more than one domain. However, as we =
have discussed several times, there are management systems that use more =
than one domain (different to EnergyWise). I do not see a good reason to =
declare that their model is wrong. Thus, we can recommend "make it as =
EnergWise from Cisco does it" with the "should" clause that we have in =
the framework, but we should not fully exclude other solutions with a =
"must" clause. See also comment 7).
Thanks for catching this discrepancy.
The framework mentions on one side:
        The Energy Object (Class) contains =
a string attribute to
        indicate membership in an Energy Management Domain.
It's true that this framework sentence contradicts this:
        An Energy Object should be a member =
of a single Energy
        Management Domain therefore one attribute is provided.
This last sentence doesn't reflect what was discussed at
h= ttp://www.ietf.org/mail-archive/web/eman/current/msg02033.html
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.

And, most importantly, h= ttp://www.ietf.org/mail-archive/web/eman/current/msg02037.html, which is the outcome of the authors call, supervised by Nevil:
*** 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 better 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

The framework should correct this sentence:
OLD:
        An Energy Object should be a member =
of a single Energy
        Management Domain therefore one attribute is provided.
NEW:
        An Energy Object must be a member =
of a single Energy
        Management Domain therefore one attribute is provided.

3) Section 5.3, 2nd and 3rd paragraph:
Both paragraphs need more explanation and you need to make them =
consistent with the text in the MIB modules. For LLDP you say "If the =
LLDP MIB is implemented". Why don't you have a similar statement for the =
PoE MIB? You talk about "the" Energy Object SNMP agent. However, EOs may =
not have SNMP agents, for example, if they are just a power interface. =
And it is not specified which of the potentially numerous instances of =
lldpLocPortNum objects of a device should be reported.
Ack, will provide some new text 
4) Section 5.4, 4th paragraph:
"Since the communication between the Energy Objects may not be=20
SNMP and is left to the choice of the device manufacturer, an=20
Energy Object can have additional MIB objects that can be used=20
for easier identification by the EnMS."
Two comments on this sentence:
A) It is not very obvious if SNMP is not available, it makes sense to =
use MIB objects. Please clarify this.
B) Please note that the choice is not only with the manufacturer. Even =
if the manufacturer builds in SNMP, the operator may choose to disable =
it ;-)
This is a badly written sentence.
Proposal: remove
"Since the communication between the Energy =
Objects may not be=20
SNMP and is left to the choice of the device manufacturer" 
5) Section 6, DESCRIPTION clause of object =
eoEthPortIndex:
What "attached device" are you talking about?
Why is it relevant for the specification of this object, if that a =
certain MIB module "should" be implemented on that device? Does it make =
any different for the DESCRIPTION of this object whether or not this MIB =
module is implemented on the attached device? I do not see why and thus =
recommend removing the statement "PoE MIB should be instantiated on the =
device."
New text will be proposed. 
6) Section 6, DESCRIPTION clause of object =
eoMgmtDNSName:
There may be more than one DNS name associated to a single IP address:
"the DNS name" -> "a DNS name"
fixed
7) Section 6, DESCRIPTION clause of object =
eoDomainName:
Please insert as second sentence: "If the energy object has been =
assigned to multiple domains, then they are represented in this object =
as comma-separated list.", see comment 2).
See point 2. 
8) Section 6, SYNTAX clause of object =
eoPowerCategory:
Some devices match more than one category, for example a UPS is a store =
and a distributor at the same time, and to be precise, also a consumer. =
A PoE Switch is a consumer and a distributor, some devices switch =
between consumer and producer, etc. We can support all of this if we =
change the syntax from INTEGER to BITS.
See point 2, for the justification, discussed at the [EMAN-FMWK] time, on why not to do this. 
9) Section 6, DESCRIPTION clause of object =
eoAlternateKey:
There is a contradiction between having this object with MAX-ACCESS =
read-write and stating " This object specifies a manufacturer defined =
string". If the manufacturer defines the string, there is no need to =
write it. I suggest allowing the operator to set the value of this =
document.
The use of the "manufacturer" word is a poor choice.
This corresponds to section 5.3:
        The eoAlternateKey alternate key =
object specifies a manufacturer
        defined string that can be used to identify the Energy Object.
        Since an EnMS may need to correlate objects across management   =20=

        systems, this alternate key is provided to facilitate such a
        link.  This optional value is intended as a foreign key or
        alternate identifier for a manufacturer or EnMS to use to
        correlate the unique Energy Object Id in other systems or
        namespaces. If an alternate key is not available or is not
        applicable then the value is the zero-length string.

Proposal: change to "alternate"

In section 5.3
OLD:
        The eoAlternateKey alternate key =
object specifies a manufacturer
        defined string that can be used to identify the Energy Object.
NEW:
        The eoAlternateKey object specifies an alternate key string
        that can be used to identify the Energy Object.
OLD:
      eoAlternateKey OBJECT-TYPE
            SYNTAX          SnmpAdminString
            MAX-ACCESS      read-write
            STATUS          current
            DESCRIPTION
               "This object specifies a manufacturer defined string that
               can be used to identify the Energy Object.
NEW:
      eoAlternateKey OBJECT-TYPE
            SYNTAX          SnmpAdminString
            MAX-ACCESS      read-write
            STATUS          current
            DESCRIPTION
               "This object specifies an alternate key string


10) Section 6, DESCRIPTION clause of object =
eoRelationID:
I recommend adding a sentence to the DESCRIPTION clause, that preferable =
the value of an entPhysicalUUID from the Entity MIB should be used for =
values of this object.
ok.
11) Section 6, Conformance of =
ENERGY-OBJECT-CONTEXT-MIB module:=20
The dependence of compliance with entity4CRCompliance is stated in the =
GROUP DESCRIPTION clauses. In our case, this is not the right place. =
There is a dependency on entity4CRCompliance  independent of which group =
is implemented. Hence, these statements need to be moved from the GROUP =
DESCRIPTION clauses to the module compliance DESCRIPTION clauses of =
energyObjectContextMIBFullCompliance and =
energyObjectContextMIBReadOnlyCompliance.
That makes sense.
12) Section 6, Conformance of =
ENERGY-OBJECT-CONTEXT-MIB module:
We state in other places that implementation of the Entity MIB compliant =
with entity4CRCompliance is a must. But in the conformance section of =
the ENERGY-OBJECT-CONTEXT-MIB the dependency on entity4CRCompliance is =
stated as "should". This need to be changed to a "must" or =
"required."
Good catch.
13) Section 6, DESCRIPTION clause of TC =
IANAEnergyRelationship:
For interoperability, the description need to be clear. As this TC is =
stated, there are two points unclear to me:
A) " The enumeration 'poweredBy' is applicable if the =20
       Energy Object A is poweredBy Energy Object B.=20
       The enumeration 'powering' is applicable if the =20
       Energy Object A is powering Energy Object B."
If the TC is used, how do I know which object is A and which is B? Is it =
that the DESCRIPTION clauses of objects of this type must refer to =
object A and object B?
OLD:
        IANAEnergyRelationship ::=3D =
TEXTUAL-CONVENTION
            STATUS            current
            DESCRIPTION
                    "An enumerated value specifies the type of
                     relationship between Energy Objects.
NEW:
        IANAEnergyRelationship ::=3D =
TEXTUAL-CONVENTION
            STATUS            current
            DESCRIPTION
                    "An enumerated value specifying the type of
                    relationship between an Energy Object A, on which=20
                    the relationship is specified, with the Energy =
Object B,=20
                    characterized by the UUID."

B) "if the Energy Object A is aggregating Energy =
Object B"
There is no place in this document where there is explained what =
aggregating means.
Part of section 5.4, we refer to [EMAN-FMWK], which defines the aggregation relationship as a summation. I guess you want some more text in this section 5.4?
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

Editorial comments:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
All these will be taken care of.

Thanks again.

Regards, Benoit.
14) Abstract, last two lines:
"relationships between reporting devices, remote devices, and monitoring =
devices.": The enumeration of "reporting devices", "monitoring devices", =
and "remote devices" is inappropriate because it does not reflect the =
list of relationships discussed by the draft: poweredBy, meteredBy, =
aggregatedBy.

15) Section 1. Introduction, 2nd paragraph, last two lines:
"Identification" -> "identification"
"Context" -> "context"
"Relationships" -> "relationships"

16) Section 1.1, 3rd paragraph, line 1:
"A second MIB module required by the [EMAN-FMWK]": There is no MIB =
module required by the EMAN framework. It seems you wanted to say: "A =
second MIB module meeting EMAN requirements given by [RFC6988]".

17) Entire Section 3
This section is completely redundant. It mainly repeats sentences of =
section 1.1. Remove this section and merge sentences you want to keep =
into section 1.1

18) Section 5, 3rd paragraph, first sentence:
The sentence is not grammatically correct, please fix. Also semantic =
correction seems to be needed. You don't mention "identification" as =
focus of the first table.

19) Section 5, sentence before Figure 1:
"The following UML diagram illustrates the relationship of the=20
MIB objects in the eoTable, eoRelationTable that describe the=20
identity, context and relationship of an Energy Object."
You should mention that you UML diagram furthermore contains objects =
from the Entity MIB.

20) Section 5, figure 1:
There is a dotted line at the lower left that goes nowhere. Please cut =
it.

21) Section 5, grouping of MIB objects is inconsistent.
In Figure 1 you have three groups: "Context", "Identification", =
"Relationships", where "Identifications" has three subgroups. The =
sentence below the figure emphasizes this grouping. However, the =
following subsections 5.1-5.4 are grouped differently. 5.1 is titled =
"Identification" but covers only a third of the objects under =
"Identification" in Figure 1. Section 5.2 is consistently with Figure 1 =
covering context information. Section 5.3 covers PoE and LLDP =
identification. Sections 5.4 is called "Relationships" but covers not =
just the objects under "Relationships" in Figure 1, but also objects =
from under "Identification" in Figure 1. Here is a clean-up needed. =
Please split the last sentence from section 5.4. It firs much better in =
section 5.3.

22) Section 5, enumeration under Figure 1:
Please note that subsection 5.5 is not another group of MIB objects but =
refers to objects in subsection 5.1. The sentence above the enumeration =
implies that each numbered item would be a group of objects.

23) Section 5.1, 2nd paragraph, line 7:
What is "primary Energy Object information"?=20

24) Section 5.4, 2nd paragraph, last sentence:
"It is important to notice, that it is possible that" -> "Obviously,"
"not have an" -> "not have any"

25) Section 5.4, 4th paragraph
The entire paragraph is in the wrong subsection. It rather belongs to =
subsection 5.1 or 5.3.

26) Section 6, DESCRIPTION clause of object eoEthPortGrpIndex:
See comment 5). There is a full stop missing at the end of the second =
sentence.

27) Section 6, OBJECTS clause of GROUP energyObjectRelationTableGroup:
The comment "Note that object eoRelationIndex is not included since it =
is not-accessible" is not really needed. Almost every Conformance =
section has such objects and usually this comment is omitted.

Cheers,
    Juergen



-----Original Message-----
From: eman [mailto:eman-bounces@ietf.org] =
On Behalf Of Thomas Nadeau
Sent: Montag, 16. Dezember 2013 16:56
To: eman mailing list
Subject: [eman] WG Last Call for =
draft-ietf-eman-energy-monitoring-mib-08
and draft-ietf-eman-energy-aware-mib-13


	As agreed at the last WG meeting, with the EMAN Framework
completing its WG LC the chairs would like to initiate a WG LC on =
draft-ietf-
eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib-13.
The WG LC will end on Dec 30 at 8AM EDT.

	Thank you,

	Nevil and Tom


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



<Attached Message = Part.txt>

= --Apple-Mail=_C3478EB4-DEF6-4884-A611-533ABF567C10-- --Apple-Mail=_099A62C6-097D-4963-99A5-47AECFC23EC3 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 iQIcBAEBCgAGBQJS5o3kAAoJEPcO+I7eiUJZO0cP/0A/WuGRUOYZ05SaOmQAUlc1 YSO6OHmefakBHmgP7M1ImoplMnTKlQUqN01ypJtIbvfJrD5Co3Mds+Bc94IJoxCw j69P7w1GnFYlQV+ZRFwsNWPOJj0/CSWjj2zuCwRXlent1bPXlWNxUd4rkf33kpIU +bjGBkXwR6RrGEpPci0rsnq6SbWJd1vf3NwPgGEg7UwHCsKGOdJIPBbNwnGs+yL+ G3ThUrZOH+5CL3qlD/GTSxobEymu/Qvs5/RRjaqL52tb2qRRKClneFMWE2sb6n6X Le3DXDThpEeziFCcY/iGrwj8IXn7MrENlhUWtai449eXgDs1fgoDfUaa8SpVj5JQ J2MtHvTnsAcvgKi4XYoaaDRd2UyRfDmyOqET60NnmNdCV1S1fXsHSQFFPnmWrh7j 6DUzDw80r8dXWX5amv5YZdSmW8QKl68RhtrFZsBPL8IyZHGdAa0srFKDY5qqovFG 2Lu88tdOw3l0C39Rg7i6MjyvYzFBGQQqVm0ZF9v+dXy2MSUz1ia+6BNynrFOFkT4 YvT81bc9xgAbi5qxEwfb7eZn6USNYMqqowxycrC8xT28bLPRub5Q+HU67i4hq1br FbFNAaZUIGr8XsboDA3U3bGfeJB6wVjuEypUpQYj11WYE2PxHvctMkozQogImqrV 9bhKIuPc8jc4Mfhzr0rs =yPhf -----END PGP SIGNATURE----- --Apple-Mail=_099A62C6-097D-4963-99A5-47AECFC23EC3-- From tnadeau@lucidvision.com Mon Jan 27 10:09:48 2014 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 040151A015A for ; Mon, 27 Jan 2014 10:09:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.434 X-Spam-Level: X-Spam-Status: No, score=-2.434 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TVPnbcB_OhUW for ; Mon, 27 Jan 2014 10:09:39 -0800 (PST) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id A33101A001E for ; Mon, 27 Jan 2014 10:09:38 -0800 (PST) Received: from [192.168.1.110] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 4FB4426CBC55; Mon, 27 Jan 2014 13:09:36 -0500 (EST) Content-Type: multipart/signed; boundary="Apple-Mail=_72D6692C-5FD4-4750-A9C6-DE00E84494BC"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Thomas Nadeau In-Reply-To: Date: Mon, 27 Jan 2014 13:09:36 -0500 Message-Id: <61843172-E68A-419B-96B7-648D689F0738@lucidvision.com> References: <52D9583D.6020603@cisco.com> <52DC578D.30105@cisco.com> To: eman mailing list X-Mailer: Apple Mail (2.1827) Cc: eman-chairs@tools.ietf.org Subject: Re: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib-13 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 27 Jan 2014 18:09:48 -0000 --Apple-Mail=_72D6692C-5FD4-4750-A9C6-DE00E84494BC Content-Type: multipart/alternative; boundary="Apple-Mail=_03E2BB18-8BC4-421B-A0BD-56266304ACBE" --Apple-Mail=_03E2BB18-8BC4-421B-A0BD-56266304ACBE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Apologies, but I should have said that Benoit's involvement here = was only as a contributor. --tom On Jan 27, 2014:11:48 AM, at 11:48 AM, Thomas Nadeau = wrote: > =09 > EMAN WG, >=20 > Nevil, Benoit and I have discussed this issue at length. Given = the 11:45th hour on this document, we independently went=20 > through the history of the document as well as the various LC comments = to see if there was a simple and quick=20 > solution to the point Juergen raised during the LC. It seems that the = language of MUST or SHOULD makes a=20 > big difference at the MIB level and/or makes the MIBs not-conforming = with the Framework depending on what we decide to do > here. There does seem to be some history behind this one, whereby the = document was changed to a SHOULD from a MUST.=20 >=20 > Just a little background on the matter: >=20 > The current framework contains a SHOULD in section 6.3.6 that is = kind of contradicted by the "recommended ... 1:1" text above it.=20 >=20 > One way or another, these need to be made consistent and = painfully obvious: >=20 > 6.3.6. Context: Domain=20 > =20 >=20 > =20 > =20 > Claise et al. Expires October 30 2015 [Page 17]=20 > =20 >=20 > Internet-Draft EMAN Framework January 2014=20 > =20 > The Energy Object (Class) contains a string attribute to=20 > indicate membership in an Energy Management Domain. An=20 > Energy Management Domain can be any collection of Energy=20 > Objects in a deployment, but it is recommended to map 1:1=20 > with a metered or sub-metered portion of the site. =20 > =20 > In building management, a meter refers to the meter=20 > provided by the utility used for billing and measuring=20 > power to an entire building or unit within a building. A=20 > sub-meter refers to a customer- or user-installed meter=20 > that is not used by the utility to bill but is instead used=20 > to get measurements from sub portions of a building.=20 > =20 > An Energy Object should be a member of a single Energy=20 > Management Domain therefore one attribute is provided.=20 >=20 >=20 > In order conform to the framework, The Energy-Mon MIB has = Section 6, DESCRIPTION clause of object eoDomainName: >=20 > Please insert as second sentence: "If the energy object = has been assigned to > multiple domains, then they are represented in this = object as comma-separated > list.", see comment 2). >=20 > The issue here is that comma-separated string is a pain as the = NMS has to check every string for comma. But the alternatives are far = more messy. >=20 >=20 > Based on the above, this point we believe there is one option = that will sort this situation out: >=20 > Change the "should" to a "must" as well as the "recommended" to = a "must" in the framework. That makes the framework itself consistent=20 > without any doubt as to there being a single domain per object. This = also fixes the issue above with the MIB.=20 >=20 > --Tom >=20 >=20 >=20 >=20 > =09 >> -------- Original Message -------- >> Subject: Re: [eman] WG Last Call for = draft-ietf-eman-energy-monitoring-mib-08 and = draft-ietf-eman-energy-aware-mib-13 >> Date: Fri, 17 Jan 2014 17:20:13 +0100 >> From: Benoit Claise >> To: Juergen Quittek , eman mailing list = >>=20 >> Hi Juergen, >>=20 >> Thanks for your thorough review. >>> Dear all, >>>=20 >>> Below please find my comments on draft-ietf-eman-energy-aware-mib-13 = titled "Energy Object Context MIB". I will send comments on = draft-ietf-eman-energy-monitoring-mib-08 in a separate message. >>>=20 >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> Technical comments: >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>=20 >>> 1) Section 5.1, 3rd paragraph: Since you are already very precise = about this MUST, I would add that the name MUST NOT have length zero. >> Not sure this is correct. RFC 6933 allows a zero-length string. See = the second paragraph below. >> entPhysicalName OBJECT-TYPE >> SYNTAX SnmpAdminString >> MAX-ACCESS read-only >> STATUS current >> DESCRIPTION >> "The textual name of the physical entity. The value of = this >> object should be the name of the component as assigned by >> the local device and should be suitable for use in = commands >> entered at the device's `console'. This might be a text >> name (e.g., `console') or a simple component number = (e.g., >> port or module number, such as `1'), depending on the >> physical component naming syntax of the device. >>=20 >> If there is no local name, or if this object is otherwise >> not applicable, then this object contains a zero-length >> string. >>=20 >> Note that the value of entPhysicalName for two physical >> entities will be the same in the event that the console >> interface does not distinguish between them, e.g., slot-1 >> and the card in slot-1." >> ::=3D { entPhysicalEntry 7 } >>=20 >> However, this sentence below is badly expressed >> Every Energy Object MUST have a printable name assigned to it. >> This sentence actually means that if an assigned name is used, it = must be a printable one. >> However, I wonder if this that sentence is needed at all, because we = overrule the entPhysicalName definition from the ENTITY-V4 RFC. >> On top of that, with SnmpAdminString, we should be good, no? >>=20 >> from http://www.ietf.org/rfc/rfc3411.txt,=20 >> SnmpAdminString ::=3D TEXTUAL-CONVENTION >> DISPLAY-HINT "255t" >> STATUS current >> DESCRIPTION "An octet string containing administrative >> information, preferably in human-readable form. >>=20 >> To facilitate internationalization, this >> information is represented using the ISO/IEC >> IS 10646-1 character set, encoded as an octet >> string using the UTF-8 transformation format >> described in [RFC2279]. >>=20 >> Since additional code points are added by >> amendments to the 10646 standard from time >> to time, implementations must be prepared to >> encounter any code point from 0x00000000 to >> 0x7fffffff. Byte sequences that do not >> correspond to the valid UTF-8 encoding of a >> code point or are outside this range are >> prohibited. >>=20 >> The use of control codes should be avoided. >>=20 >> When it is necessary to represent a newline, >> the control code sequence CR LF should be used. >> The use of leading or trailing white space should >> be avoided. >>=20 >> For code points not directly supported by user >> interface hardware or software, an alternative >> means of entry and display, such as hexadecimal, >> may be provided. >>=20 >> For information encoded in 7-bit US-ASCII, >> the UTF-8 encoding is identical to the >> US-ASCII encoding. >>=20 >> UTF-8 may require multiple bytes to represent a >> single character / code point; thus the length >> of this object in octets may be different from >> the number of characters encoded. Similarly, >> size constraints refer to the number of encoded >> octets, not the number of characters represented >> by an encoding. >>=20 >> Note that when this TC is used for an object that >> is used or envisioned to be used as an index, then >> a SIZE restriction MUST be specified so that the >> number of sub-identifiers for any object instance >> does not exceed the limit of 128, as defined by >> [RFC3416]. >>=20 >> Note that the size of an SnmpAdminString object is >> measured in octets, not characters. >> " >> SYNTAX OCTET STRING (SIZE (0..255)) >>=20 >> Proposal, to make it clear that printable names are really a plus: >> OLD: >> "Every Energy Object MUST have a printable name assigned to it" >> NEW: >> "While entPhysicalName does allow zero-length name, every = Energy=20 >> Object should have a printable name assigned to it" >>> 2) Section 5.1, one but last paragraph: "Each Energy Object MUST = belong to a single Energy Management Domain or in other words, an Energy = Object cannot belong to more than one Energy Management Domain." This is = more strict than in the framework where we say an EO "should" not belong = to more than one domain. However, as we have discussed several times, = there are management systems that use more than one domain (different to = EnergyWise). I do not see a good reason to declare that their model is = wrong. Thus, we can recommend "make it as EnergWise from Cisco does it" = with the "should" clause that we have in the framework, but we should = not fully exclude other solutions with a "must" clause. See also comment = 7). >> Thanks for catching this discrepancy. >> The framework mentions on one side: >> The Energy Object (Class) contains a string attribute to >> indicate membership in an Energy Management Domain.=20 >> It's true that this framework sentence contradicts this: >> An Energy Object should be a member of a single Energy >> Management Domain therefore one attribute is provided. >>=20 >> This last sentence doesn't reflect what was discussed at >> http://www.ietf.org/mail-archive/web/eman/current/msg02033.html >> 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. >>=20 >> And, most importantly, = http://www.ietf.org/mail-archive/web/eman/current/msg02037.html, which = is the outcome of the authors call, supervised by Nevil: >> *** 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 = better 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 >>=20 >> The framework should correct this sentence: >> OLD: >> An Energy Object should be a member of a single Energy >> Management Domain therefore one attribute is provided. >> NEW: >> An Energy Object must be a member of a single Energy >> Management Domain therefore one attribute is provided. >>> 3) Section 5.3, 2nd and 3rd paragraph: >>> Both paragraphs need more explanation and you need to make them = consistent with the text in the MIB modules. For LLDP you say "If the = LLDP MIB is implemented". Why don't you have a similar statement for the = PoE MIB? You talk about "the" Energy Object SNMP agent. However, EOs may = not have SNMP agents, for example, if they are just a power interface. = And it is not specified which of the potentially numerous instances of = lldpLocPortNum objects of a device should be reported. >> Ack, will provide some new text >>>=20 >>> 4) Section 5.4, 4th paragraph: >>> "Since the communication between the Energy Objects may not be=20 >>> SNMP and is left to the choice of the device manufacturer, an=20 >>> Energy Object can have additional MIB objects that can be used=20 >>> for easier identification by the EnMS." >>> Two comments on this sentence: >>> A) It is not very obvious if SNMP is not available, it makes sense = to use MIB objects. Please clarify this. >>> B) Please note that the choice is not only with the manufacturer. = Even if the manufacturer builds in SNMP, the operator may choose to = disable it ;-) >> This is a badly written sentence. >> Proposal: remove >> "Since the communication between the Energy Objects may not be=20 >> SNMP and is left to the choice of the device manufacturer"=20 >>> 5) Section 6, DESCRIPTION clause of object eoEthPortIndex: >>> What "attached device" are you talking about? >>> Why is it relevant for the specification of this object, if that a = certain MIB module "should" be implemented on that device? Does it make = any different for the DESCRIPTION of this object whether or not this MIB = module is implemented on the attached device? I do not see why and thus = recommend removing the statement "PoE MIB should be instantiated on the = device." >> New text will be proposed. >>>=20 >>> 6) Section 6, DESCRIPTION clause of object eoMgmtDNSName: >>> There may be more than one DNS name associated to a single IP = address: >>> "the DNS name" -> "a DNS name" >> fixed >>> 7) Section 6, DESCRIPTION clause of object eoDomainName: >>> Please insert as second sentence: "If the energy object has been = assigned to multiple domains, then they are represented in this object = as comma-separated list.", see comment 2). >> See point 2. >>>=20 >>> 8) Section 6, SYNTAX clause of object eoPowerCategory: >>> Some devices match more than one category, for example a UPS is a = store and a distributor at the same time, and to be precise, also a = consumer. A PoE Switch is a consumer and a distributor, some devices = switch between consumer and producer, etc. We can support all of this if = we change the syntax from INTEGER to BITS. >> See point 2, for the justification, discussed at the [EMAN-FMWK] = time, on why not to do this. >>>=20 >>> 9) Section 6, DESCRIPTION clause of object eoAlternateKey: >>> There is a contradiction between having this object with MAX-ACCESS = read-write and stating " This object specifies a manufacturer defined = string". If the manufacturer defines the string, there is no need to = write it. I suggest allowing the operator to set the value of this = document. >> The use of the "manufacturer" word is a poor choice. >> This corresponds to section 5.3: >> The eoAlternateKey alternate key object specifies a = manufacturer >> defined string that can be used to identify the Energy = Object. >> Since an EnMS may need to correlate objects across management = =20 >> systems, this alternate key is provided to facilitate such a >> link. This optional value is intended as a foreign key or >> alternate identifier for a manufacturer or EnMS to use to >> correlate the unique Energy Object Id in other systems or >> namespaces. If an alternate key is not available or is not >> applicable then the value is the zero-length string. >>=20 >> Proposal: change to "alternate" >>=20 >> In section 5.3 >> OLD: >> The eoAlternateKey alternate key object specifies a = manufacturer >> defined string that can be used to identify the Energy = Object. >> NEW: >> The eoAlternateKey object specifies an alternate key string >> that can be used to identify the Energy Object. >> OLD: >> eoAlternateKey OBJECT-TYPE >> SYNTAX SnmpAdminString >> MAX-ACCESS read-write >> STATUS current >> DESCRIPTION >> "This object specifies a manufacturer defined string = that >> can be used to identify the Energy Object. >> NEW: >> eoAlternateKey OBJECT-TYPE >> SYNTAX SnmpAdminString >> MAX-ACCESS read-write >> STATUS current >> DESCRIPTION >> "This object specifies an alternate key string >>=20 >>> 10) Section 6, DESCRIPTION clause of object eoRelationID: >>> I recommend adding a sentence to the DESCRIPTION clause, that = preferable the value of an entPhysicalUUID from the Entity MIB should be = used for values of this object. >> ok. >>> 11) Section 6, Conformance of ENERGY-OBJECT-CONTEXT-MIB module:=20 >>> The dependence of compliance with entity4CRCompliance is stated in = the GROUP DESCRIPTION clauses. In our case, this is not the right place. = There is a dependency on entity4CRCompliance independent of which group = is implemented. Hence, these statements need to be moved from the GROUP = DESCRIPTION clauses to the module compliance DESCRIPTION clauses of = energyObjectContextMIBFullCompliance and = energyObjectContextMIBReadOnlyCompliance. >> That makes sense. >>> 12) Section 6, Conformance of ENERGY-OBJECT-CONTEXT-MIB module: >>> We state in other places that implementation of the Entity MIB = compliant with entity4CRCompliance is a must. But in the conformance = section of the ENERGY-OBJECT-CONTEXT-MIB the dependency on = entity4CRCompliance is stated as "should". This need to be changed to a = "must" or "required." >> Good catch. >>> 13) Section 6, DESCRIPTION clause of TC IANAEnergyRelationship: >>> For interoperability, the description need to be clear. As this TC = is stated, there are two points unclear to me: >>> A) " The enumeration 'poweredBy' is applicable if the =20 >>> Energy Object A is poweredBy Energy Object B.=20 >>> The enumeration 'powering' is applicable if the =20 >>> Energy Object A is powering Energy Object B." >>> If the TC is used, how do I know which object is A and which is B? = Is it that the DESCRIPTION clauses of objects of this type must refer to = object A and object B? >> OLD: >> IANAEnergyRelationship ::=3D TEXTUAL-CONVENTION >> STATUS current >> DESCRIPTION >> "An enumerated value specifies the type of >> relationship between Energy Objects. >> NEW: >> IANAEnergyRelationship ::=3D TEXTUAL-CONVENTION >> STATUS current >> DESCRIPTION >> "An enumerated value specifying the type of >> relationship between an Energy Object A, on which=20= >> the relationship is specified, with the Energy = Object B,=20 >> characterized by the UUID." >>> B) "if the Energy Object A is aggregating Energy Object B" >>> There is no place in this document where there is explained what = aggregating means. >> Part of section 5.4, we refer to [EMAN-FMWK], which defines the = aggregation relationship as a summation. I guess you want some more text = in this section 5.4? >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> Editorial comments: >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> All these will be taken care of. >>=20 >> Thanks again. >>=20 >> Regards, Benoit. >>> 14) Abstract, last two lines: >>> "relationships between reporting devices, remote devices, and = monitoring devices.": The enumeration of "reporting devices", = "monitoring devices", and "remote devices" is inappropriate because it = does not reflect the list of relationships discussed by the draft: = poweredBy, meteredBy, aggregatedBy. >>>=20 >>> 15) Section 1. Introduction, 2nd paragraph, last two lines: >>> "Identification" -> "identification" >>> "Context" -> "context" >>> "Relationships" -> "relationships" >>>=20 >>> 16) Section 1.1, 3rd paragraph, line 1: >>> "A second MIB module required by the [EMAN-FMWK]": There is no MIB = module required by the EMAN framework. It seems you wanted to say: "A = second MIB module meeting EMAN requirements given by [RFC6988]". >>>=20 >>> 17) Entire Section 3 >>> This section is completely redundant. It mainly repeats sentences of = section 1.1. Remove this section and merge sentences you want to keep = into section 1.1 >>>=20 >>> 18) Section 5, 3rd paragraph, first sentence: >>> The sentence is not grammatically correct, please fix. Also semantic = correction seems to be needed. You don't mention "identification" as = focus of the first table. >>>=20 >>> 19) Section 5, sentence before Figure 1: >>> "The following UML diagram illustrates the relationship of the=20 >>> MIB objects in the eoTable, eoRelationTable that describe the=20 >>> identity, context and relationship of an Energy Object." >>> You should mention that you UML diagram furthermore contains objects = from the Entity MIB. >>>=20 >>> 20) Section 5, figure 1: >>> There is a dotted line at the lower left that goes nowhere. Please = cut it. >>>=20 >>> 21) Section 5, grouping of MIB objects is inconsistent. >>> In Figure 1 you have three groups: "Context", "Identification", = "Relationships", where "Identifications" has three subgroups. The = sentence below the figure emphasizes this grouping. However, the = following subsections 5.1-5.4 are grouped differently. 5.1 is titled = "Identification" but covers only a third of the objects under = "Identification" in Figure 1. Section 5.2 is consistently with Figure 1 = covering context information. Section 5.3 covers PoE and LLDP = identification. Sections 5.4 is called "Relationships" but covers not = just the objects under "Relationships" in Figure 1, but also objects = from under "Identification" in Figure 1. Here is a clean-up needed. = Please split the last sentence from section 5.4. It firs much better in = section 5.3. >>>=20 >>> 22) Section 5, enumeration under Figure 1: >>> Please note that subsection 5.5 is not another group of MIB objects = but refers to objects in subsection 5.1. The sentence above the = enumeration implies that each numbered item would be a group of objects. >>>=20 >>> 23) Section 5.1, 2nd paragraph, line 7: >>> What is "primary Energy Object information"?=20 >>>=20 >>> 24) Section 5.4, 2nd paragraph, last sentence: >>> "It is important to notice, that it is possible that" -> = "Obviously," >>> "not have an" -> "not have any" >>>=20 >>> 25) Section 5.4, 4th paragraph >>> The entire paragraph is in the wrong subsection. It rather belongs = to subsection 5.1 or 5.3. >>>=20 >>> 26) Section 6, DESCRIPTION clause of object eoEthPortGrpIndex: >>> See comment 5). There is a full stop missing at the end of the = second sentence. >>>=20 >>> 27) Section 6, OBJECTS clause of GROUP = energyObjectRelationTableGroup: >>> The comment "Note that object eoRelationIndex is not included since = it is not-accessible" is not really needed. Almost every Conformance = section has such objects and usually this comment is omitted. >>>=20 >>> Cheers, >>> Juergen >>>=20 >>>=20 >>>> -----Original Message----- >>>> From: eman [mailto:eman-bounces@ietf.org] On Behalf Of Thomas = Nadeau >>>> Sent: Montag, 16. Dezember 2013 16:56 >>>> To: eman mailing list >>>> Subject: [eman] WG Last Call for = draft-ietf-eman-energy-monitoring-mib-08 >>>> and draft-ietf-eman-energy-aware-mib-13 >>>>=20 >>>>=20 >>>> As agreed at the last WG meeting, with the EMAN Framework >>>> completing its WG LC the chairs would like to initiate a WG LC on = draft-ietf- >>>> eman-energy-monitoring-mib-08 and = draft-ietf-eman-energy-aware-mib-13. >>>> The WG LC will end on Dec 30 at 8AM EDT. >>>>=20 >>>> Thank you, >>>>=20 >>>> Nevil and Tom >>>>=20 >>> _______________________________________________ >>> eman mailing list >>> eman@ietf.org >>> https://www.ietf.org/mailman/listinfo/eman >>> . >>>=20 >>=20 >>=20 >>=20 >> >=20 --Apple-Mail=_03E2BB18-8BC4-421B-A0BD-56266304ACBE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

Apologies, but I should have = said that Benoit's involvement here was only as a = contributor.

= --tom


On Jan 27, 2014:11:48 AM, = at 11:48 AM, Thomas Nadeau <tnadeau@lucidvision.com> = wrote:

EMAN = WG,

Nevil, Benoit and I have = discussed this issue at length. Given the 11:45th hour on this document, = we independently went 
through the history of the = document as well as the various LC comments to see if there was a simple = and quick 
solution to the point Juergen raised during = the LC. It seems that the language of MUST or SHOULD makes = a 
big difference at the MIB level and/or makes the MIBs = not-conforming with the Framework depending on what we decide to = do
here.  There does seem to be some history behind = this one, whereby the document was changed to a SHOULD from a = MUST. 

Just a little background on the = matter:

The current framework contains a = SHOULD in section 6.3.6 that is kind of contradicted by the "recommended = ... 1:1" text above it. 

One way = or another, these need to be made consistent and painfully = obvious:

 6.3.6. Context: =
Domain=20
       =20

    =20
    =20
    Claise et al.          Expires October 30 2015      [Page 17]=20
       =20

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


In order = conform to the framework, The Energy-Mon MIB has Section 6, = DESCRIPTION clause of object = eoDomainName:

Please insert as second = sentence: "If the energy object has been assigned to
= multiple domains, then they are represented in this object as = comma-separated
list.", see comment = 2).

The issue here is that = comma-separated string is a pain as the NMS has to check every string = for comma. But the alternatives are far more = messy.


Based on = the above, this point we believe there is one option that will sort = this situation out:

Change = the "should" to a "must" as well as the "recommended" to a "must" in the = framework. That makes the framework itself = consistent 
without any doubt as to there being a single = domain per object. This also fixes the issue above with the = MIB. 

= --Tom




=
-------- Original Message --------
Subject: Re: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib-13
Date: Fri, 17 Jan 2014 17:20:13 +0100
From: Benoit Claise <bclaise@cisco.com>
To: = Juergen Quittek <Quittek@neclab.eu>, eman = mailing list <eman@ietf.org>


Hi Juergen,

Thanks for your thorough review.
Dear all,

Below please find my comments on draft-ietf-eman-energy-aware-mib-13 =
titled "Energy Object Context MIB". I will send comments on =
draft-ietf-eman-energy-monitoring-mib-08 in a separate message.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Technical comments:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

1) Section 5.1, 3rd paragraph: Since you are already very precise about =
this MUST, I would add that the name MUST NOT have length zero.
Not sure this is correct. RFC 6933 allows a zero-length string. See the second paragraph below.
entPhysicalName OBJECT-TYPE
    SYNTAX      SnmpAdminString
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
            "The textual name of the physical entity.  The value of this
            object should be the name of the component as assigned by
            the local device and should be suitable for use in commands
            entered at the device's `console'.  This might be a text
            name (e.g., `console') or a simple component number (e.g.,
            port or module number, such as `1'), depending on the
            physical component naming syntax of the device.

            If there is no local name, or if this object is otherwise
            not applicable, then this object contains a zero-length
            string.

            Note that the value of entPhysicalName for two physical
            entities will be the same in the event that the console
            interface does not distinguish between them, e.g., slot-1
            and the card in slot-1."
    ::=3D { entPhysicalEntry 7 }

However, this sentence below is badly expressed
  Every Energy Object MUST have a printable =
name assigned to it.
This sentence actually means that if an assigned name is used, it must be a printable one.
However, I wonder if this that sentence is needed at all, because we overrule the entPhysicalName definition from the ENTITY-V4 = RFC.
On top of that, with SnmpAdminString, we should be =
good, no?

from http://www.ietf.org/rfc/rfc34=
11.txt,=20
SnmpAdminString ::=3D TEXTUAL-CONVENTION
    DISPLAY-HINT "255t"
    STATUS       current
    DESCRIPTION "An octet string containing administrative
                 information, preferably in human-readable form.

                 To facilitate internationalization, this
                 information is represented using the ISO/IEC
                 IS 10646-1 character set, encoded as an octet
                 string using the UTF-8 transformation format
                 described in [RFC2279].

                 Since additional code points are added by
                 amendments to the 10646 standard from time
                 to time, implementations must be prepared to
                 encounter any code point from 0x00000000 to
                 0x7fffffff.  Byte sequences that do not
                 correspond to the valid UTF-8 encoding of a
                 code point or are outside this range are
                 prohibited.

                 The use of control codes should be avoided.

                 When it is necessary to represent a newline,
                 the control code sequence CR LF should be used.
                 The use of leading or trailing white space should
                 be avoided.

                 For code points not directly supported by user
                 interface hardware or software, an alternative
                 means of entry and display, such as hexadecimal,
                 may be provided.

                 For information encoded in 7-bit US-ASCII,
                 the UTF-8 encoding is identical to the
                 US-ASCII encoding.

                 UTF-8 may require multiple bytes to represent a
                 single character / code point; thus the length
                 of this object in octets may be different from
                 the number of characters encoded.  Similarly,
                 size constraints refer to the number of encoded
                 octets, not the number of characters represented
                 by an encoding.

                 Note that when this TC is used for an object that
                 is used or envisioned to be used as an index, then
                 a SIZE restriction MUST be specified so that the
                 number of sub-identifiers for any object instance
                 does not exceed the limit of 128, as defined by
                 [RFC3416].

                 Note that the size of an SnmpAdminString object is
                 measured in octets, not characters.
                "
    SYNTAX       OCTET STRING (SIZE (0..255))

Proposal, to make it clear that printable names are really a plus:
OLD:
	 "Every Energy Object MUST have a printable name assigned =
to it"
NEW:
	 "While entPhysicalName does allow zero-length name, every =
Energy=20
         Object should have a printable name assigned to it"

2) Section 5.1, one but last paragraph: "Each =
Energy Object MUST belong to a single Energy Management Domain or in =
other words, an Energy Object cannot belong to more than one Energy =
Management Domain." This is more strict than in the framework where we =
say an EO "should" not belong to more than one domain. However, as we =
have discussed several times, there are management systems that use more =
than one domain (different to EnergyWise). I do not see a good reason to =
declare that their model is wrong. Thus, we can recommend "make it as =
EnergWise from Cisco does it" with the "should" clause that we have in =
the framework, but we should not fully exclude other solutions with a =
"must" clause. See also comment 7).
Thanks for catching this discrepancy.
The framework mentions on one side:
        The Energy Object (Class) contains =
a string attribute to
        indicate membership in an Energy Management Domain.
It's true that this framework sentence contradicts this:
        An Energy Object should be a member =
of a single Energy
        Management Domain therefore one attribute is provided.
This last sentence doesn't reflect what was discussed at
h= ttp://www.ietf.org/mail-archive/web/eman/current/msg02033.html
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.

And, most importantly, h= ttp://www.ietf.org/mail-archive/web/eman/current/msg02037.html, which is the outcome of the authors call, supervised by Nevil:
*** 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 better 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

The framework should correct this sentence:
OLD:
        An Energy Object should be a member =
of a single Energy
        Management Domain therefore one attribute is provided.
NEW:
        An Energy Object must be a member =
of a single Energy
        Management Domain therefore one attribute is provided.

3) Section 5.3, 2nd and 3rd paragraph:
Both paragraphs need more explanation and you need to make them =
consistent with the text in the MIB modules. For LLDP you say "If the =
LLDP MIB is implemented". Why don't you have a similar statement for the =
PoE MIB? You talk about "the" Energy Object SNMP agent. However, EOs may =
not have SNMP agents, for example, if they are just a power interface. =
And it is not specified which of the potentially numerous instances of =
lldpLocPortNum objects of a device should be reported.
Ack, will provide some new text 
4) Section 5.4, 4th paragraph:
"Since the communication between the Energy Objects may not be=20
SNMP and is left to the choice of the device manufacturer, an=20
Energy Object can have additional MIB objects that can be used=20
for easier identification by the EnMS."
Two comments on this sentence:
A) It is not very obvious if SNMP is not available, it makes sense to =
use MIB objects. Please clarify this.
B) Please note that the choice is not only with the manufacturer. Even =
if the manufacturer builds in SNMP, the operator may choose to disable =
it ;-)
This is a badly written sentence.
Proposal: remove
"Since the communication between the Energy =
Objects may not be=20
SNMP and is left to the choice of the device manufacturer" 
5) Section 6, DESCRIPTION clause of object =
eoEthPortIndex:
What "attached device" are you talking about?
Why is it relevant for the specification of this object, if that a =
certain MIB module "should" be implemented on that device? Does it make =
any different for the DESCRIPTION of this object whether or not this MIB =
module is implemented on the attached device? I do not see why and thus =
recommend removing the statement "PoE MIB should be instantiated on the =
device."
New text will be proposed. 
6) Section 6, DESCRIPTION clause of object =
eoMgmtDNSName:
There may be more than one DNS name associated to a single IP address:
"the DNS name" -> "a DNS name"
fixed
7) Section 6, DESCRIPTION clause of object =
eoDomainName:
Please insert as second sentence: "If the energy object has been =
assigned to multiple domains, then they are represented in this object =
as comma-separated list.", see comment 2).
See point 2. 
8) Section 6, SYNTAX clause of object =
eoPowerCategory:
Some devices match more than one category, for example a UPS is a store =
and a distributor at the same time, and to be precise, also a consumer. =
A PoE Switch is a consumer and a distributor, some devices switch =
between consumer and producer, etc. We can support all of this if we =
change the syntax from INTEGER to BITS.
See point 2, for the justification, discussed at the [EMAN-FMWK] time, on why not to do this. 
9) Section 6, DESCRIPTION clause of object =
eoAlternateKey:
There is a contradiction between having this object with MAX-ACCESS =
read-write and stating " This object specifies a manufacturer defined =
string". If the manufacturer defines the string, there is no need to =
write it. I suggest allowing the operator to set the value of this =
document.
The use of the "manufacturer" word is a poor choice.
This corresponds to section 5.3:
        The eoAlternateKey alternate key =
object specifies a manufacturer
        defined string that can be used to identify the Energy Object.
        Since an EnMS may need to correlate objects across management   =20=

        systems, this alternate key is provided to facilitate such a
        link.  This optional value is intended as a foreign key or
        alternate identifier for a manufacturer or EnMS to use to
        correlate the unique Energy Object Id in other systems or
        namespaces. If an alternate key is not available or is not
        applicable then the value is the zero-length string.

Proposal: change to "alternate"

In section 5.3
OLD:
        The eoAlternateKey alternate key =
object specifies a manufacturer
        defined string that can be used to identify the Energy Object.
NEW:
        The eoAlternateKey object specifies an alternate key string
        that can be used to identify the Energy Object.
OLD:
      eoAlternateKey OBJECT-TYPE
            SYNTAX          SnmpAdminString
            MAX-ACCESS      read-write
            STATUS          current
            DESCRIPTION
               "This object specifies a manufacturer defined string that
               can be used to identify the Energy Object.
NEW:
      eoAlternateKey OBJECT-TYPE
            SYNTAX          SnmpAdminString
            MAX-ACCESS      read-write
            STATUS          current
            DESCRIPTION
               "This object specifies an alternate key string


10) Section 6, DESCRIPTION clause of object =
eoRelationID:
I recommend adding a sentence to the DESCRIPTION clause, that preferable =
the value of an entPhysicalUUID from the Entity MIB should be used for =
values of this object.
ok.
11) Section 6, Conformance of =
ENERGY-OBJECT-CONTEXT-MIB module:=20
The dependence of compliance with entity4CRCompliance is stated in the =
GROUP DESCRIPTION clauses. In our case, this is not the right place. =
There is a dependency on entity4CRCompliance  independent of which group =
is implemented. Hence, these statements need to be moved from the GROUP =
DESCRIPTION clauses to the module compliance DESCRIPTION clauses of =
energyObjectContextMIBFullCompliance and =
energyObjectContextMIBReadOnlyCompliance.
That makes sense.
12) Section 6, Conformance of =
ENERGY-OBJECT-CONTEXT-MIB module:
We state in other places that implementation of the Entity MIB compliant =
with entity4CRCompliance is a must. But in the conformance section of =
the ENERGY-OBJECT-CONTEXT-MIB the dependency on entity4CRCompliance is =
stated as "should". This need to be changed to a "must" or =
"required."
Good catch.
13) Section 6, DESCRIPTION clause of TC =
IANAEnergyRelationship:
For interoperability, the description need to be clear. As this TC is =
stated, there are two points unclear to me:
A) " The enumeration 'poweredBy' is applicable if the =20
       Energy Object A is poweredBy Energy Object B.=20
       The enumeration 'powering' is applicable if the =20
       Energy Object A is powering Energy Object B."
If the TC is used, how do I know which object is A and which is B? Is it =
that the DESCRIPTION clauses of objects of this type must refer to =
object A and object B?
OLD:
        IANAEnergyRelationship ::=3D =
TEXTUAL-CONVENTION
            STATUS            current
            DESCRIPTION
                    "An enumerated value specifies the type of
                     relationship between Energy Objects.
NEW:
        IANAEnergyRelationship ::=3D =
TEXTUAL-CONVENTION
            STATUS            current
            DESCRIPTION
                    "An enumerated value specifying the type of
                    relationship between an Energy Object A, on which=20
                    the relationship is specified, with the Energy =
Object B,=20
                    characterized by the UUID."

B) "if the Energy Object A is aggregating Energy =
Object B"
There is no place in this document where there is explained what =
aggregating means.
Part of section 5.4, we refer to [EMAN-FMWK], which defines the aggregation relationship as a summation. I guess you want some more text in this section 5.4?
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

Editorial comments:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
All these will be taken care of.

Thanks again.

Regards, Benoit.
14) Abstract, last two lines:
"relationships between reporting devices, remote devices, and monitoring =
devices.": The enumeration of "reporting devices", "monitoring devices", =
and "remote devices" is inappropriate because it does not reflect the =
list of relationships discussed by the draft: poweredBy, meteredBy, =
aggregatedBy.

15) Section 1. Introduction, 2nd paragraph, last two lines:
"Identification" -> "identification"
"Context" -> "context"
"Relationships" -> "relationships"

16) Section 1.1, 3rd paragraph, line 1:
"A second MIB module required by the [EMAN-FMWK]": There is no MIB =
module required by the EMAN framework. It seems you wanted to say: "A =
second MIB module meeting EMAN requirements given by [RFC6988]".

17) Entire Section 3
This section is completely redundant. It mainly repeats sentences of =
section 1.1. Remove this section and merge sentences you want to keep =
into section 1.1

18) Section 5, 3rd paragraph, first sentence:
The sentence is not grammatically correct, please fix. Also semantic =
correction seems to be needed. You don't mention "identification" as =
focus of the first table.

19) Section 5, sentence before Figure 1:
"The following UML diagram illustrates the relationship of the=20
MIB objects in the eoTable, eoRelationTable that describe the=20
identity, context and relationship of an Energy Object."
You should mention that you UML diagram furthermore contains objects =
from the Entity MIB.

20) Section 5, figure 1:
There is a dotted line at the lower left that goes nowhere. Please cut =
it.

21) Section 5, grouping of MIB objects is inconsistent.
In Figure 1 you have three groups: "Context", "Identification", =
"Relationships", where "Identifications" has three subgroups. The =
sentence below the figure emphasizes this grouping. However, the =
following subsections 5.1-5.4 are grouped differently. 5.1 is titled =
"Identification" but covers only a third of the objects under =
"Identification" in Figure 1. Section 5.2 is consistently with Figure 1 =
covering context information. Section 5.3 covers PoE and LLDP =
identification. Sections 5.4 is called "Relationships" but covers not =
just the objects under "Relationships" in Figure 1, but also objects =
from under "Identification" in Figure 1. Here is a clean-up needed. =
Please split the last sentence from section 5.4. It firs much better in =
section 5.3.

22) Section 5, enumeration under Figure 1:
Please note that subsection 5.5 is not another group of MIB objects but =
refers to objects in subsection 5.1. The sentence above the enumeration =
implies that each numbered item would be a group of objects.

23) Section 5.1, 2nd paragraph, line 7:
What is "primary Energy Object information"?=20

24) Section 5.4, 2nd paragraph, last sentence:
"It is important to notice, that it is possible that" -> "Obviously,"
"not have an" -> "not have any"

25) Section 5.4, 4th paragraph
The entire paragraph is in the wrong subsection. It rather belongs to =
subsection 5.1 or 5.3.

26) Section 6, DESCRIPTION clause of object eoEthPortGrpIndex:
See comment 5). There is a full stop missing at the end of the second =
sentence.

27) Section 6, OBJECTS clause of GROUP energyObjectRelationTableGroup:
The comment "Note that object eoRelationIndex is not included since it =
is not-accessible" is not really needed. Almost every Conformance =
section has such objects and usually this comment is omitted.

Cheers,
    Juergen



-----Original Message-----
From: eman [mailto:eman-bounces@ietf.org] =
On Behalf Of Thomas Nadeau
Sent: Montag, 16. Dezember 2013 16:56
To: eman mailing list
Subject: [eman] WG Last Call for =
draft-ietf-eman-energy-monitoring-mib-08
and draft-ietf-eman-energy-aware-mib-13


	As agreed at the last WG meeting, with the EMAN Framework
completing its WG LC the chairs would like to initiate a WG LC on =
draft-ietf-
eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib-13.
The WG LC will end on Dec 30 at 8AM EDT.

	Thank you,

	Nevil and Tom


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



<Attached Message = Part.txt>


= --Apple-Mail=_03E2BB18-8BC4-421B-A0BD-56266304ACBE-- --Apple-Mail=_72D6692C-5FD4-4750-A9C6-DE00E84494BC 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 iQIcBAEBCgAGBQJS5qDgAAoJEPcO+I7eiUJZ2h0P/2XLsxskDTKa+Db9uzcHZP2d T4HzlAKOTDGkWEPwlJoFmaGDzhpwwxwK8zENF9yt28W9gj35uYJLsM4ctRN8I+Ug jZWah0MYNZn7zHssiLWApj0TCGLGCUBUzbDmpI2PY0m2nAiPqrC2mnqk5xqwcbNB GiQCEt2zcmHd04MYjUZduWZEASL3HBlsKDgbKpRxzXYgB2lMMHfM5OUKAOi3ctpM MEial3lpBHLa0KCyHyPwPESLZsfzFB5BQ8nUHCZRFylK66iFs6WcC5MHdpkUx7sS BX3ZgMlYdMB43AwS7mdYhnfb3H8JpeWRdjV67sONmlIxC1vFxvrc5t0Ye2wZ8g25 Xz0qu8xPbhvs27kL/Kr86lUW33LoKQQFDS9XIxAoC/W8Un3hxLeRPHLqJR4AXper s/uB1oknL/t8fQv7MJ1MywUsuaRS/J7JmoO9rMNqi4RAzmdO/A6fMTtrkE3eod7Z ZHCvNjdIldHhH33FJxENifpPZeN2sDsbo8q8b8dCu2y606FScUkqdL5cJJwfua+7 KjcVGwI1l/PXU0RqU7QHEzDgMoqoPQVYdaRueD3vB+W9313I3zdVmA+CNqPW/1zK IXReIAybd7ItwalnDprIdUei2FodjJaun9sIug3PbBWop2cfgJe4Hf+l0QGEfdRr YtW1i0CKHdE/cV/ih3/t =ASR+ -----END PGP SIGNATURE----- --Apple-Mail=_72D6692C-5FD4-4750-A9C6-DE00E84494BC-- From tnadeau@lucidvision.com Mon Jan 27 10:26:32 2014 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E4E31A02BA for ; Mon, 27 Jan 2014 10:26:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jLSaGOaM3Ctz for ; Mon, 27 Jan 2014 10:26:27 -0800 (PST) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 5B1231A001E for ; Mon, 27 Jan 2014 10:26:27 -0800 (PST) Received: from [192.168.1.110] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 00D2926CBD96; Mon, 27 Jan 2014 13:26:24 -0500 (EST) Content-Type: multipart/signed; boundary="Apple-Mail=_E971151C-84E6-4513-B5D3-CD9F0D722744"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Thomas Nadeau In-Reply-To: <9AB93E4127C26F4BA7829DEFDCE5A6E8689109AC@DAPHNIS.office.hd> Date: Mon, 27 Jan 2014 13:26:23 -0500 Message-Id: <9D31D002-BEF7-4416-80E1-65792226280D@lucidvision.com> References: <5298B7FA.1010509@cisco.com> <52A5A9FA.80101@cisco.com> <52A5C2A6.9000501@cisco.com> <52AB8777.9060704@cisco.com> <653A4764-315C-4671-B0DA-389553CB3E29@lucidvision.com> <9AB93E4127C26F4BA7829DEFDCE5A6E8688B2E6C@DAPHNIS.office.hd> <52D9583D.6020603@cisco.com> <9AB93E4127C26F4BA7829DEFDCE5A6E8689109AC@DAPHNIS.office.hd> To: Juergen Quittek X-Mailer: Apple Mail (2.1827) Cc: eman mailing list Subject: Re: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib-13 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 27 Jan 2014 18:26:32 -0000 --Apple-Mail=_E971151C-84E6-4513-B5D3-CD9F0D722744 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Juergen, Apologies but our emails crossed inflight it seems.=20 > Hi Benoit, >=20 > Thank you for your replies on all technical comments. >=20 > I have two issues with the replies. One is stated in the email=20 > below, the other one will come in a separate email. >=20 > Energy Management Domain > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > The eman framework states: "An Energy Object should=20 > be a member of a single Energy Management Domain". >=20 > Now and draft-ietf-eman-energy-aware-mib sharpens this to > "Each Energy Object MUST belong to a single Energy=20 > Management Domain". >=20 > This change from "should" to "MUST" is inappropriate. >=20 > The situation is that Cisco's EnergyWise uses a single domain=20 > while some other products use multiple domains. We went=20 > on with the recommendation for a single domain in the=20 > framework because of the positive experience with=20 > EnergyWise and no reported complaints on this from=20 > EnergyWise customers. >=20 > But no technical argument was ever given for restricting a > device to be member of a single domain only. In contrary,=20 > I reported from applications of the multiple domain approach=20 > without anyone challenging this technically. >=20 > The compromise in the framework was to recommend the=20 > EnergyWise approach but not to completely exclude competing=20 > approaches. >=20 > With a change from "should" to "must" you changed a lot in=20 > this game. I do not see any _technical_ reason for this step. >=20 > In my comments I suggested a way that only needs a small=20 > modification of one object's DESCRIPTION clause to be open > for other implementations using multiple domains. My proposal > still kept the recommendation for using a single domain only > (even in the absence of a technical reason for this) but showed > how to act if you have a strong need for multiple ones. >=20 > I propose to stay with the compromise achieved in the framework > document and leave the door open for implementations that > have (as RFC 2119 says) "valid reasons in particular circumstances" > to choose a multi-domain approach. As I pointed out in my email just now, there are a number of implications to the proposed change as well as the currently=20 misaligned state of things. After the chairs reviewed the situation in detail including the history of the compromise, we felt that=20 the consensus for the approach was in fact to go with a single=20 domain. The reasoning was simple: the compromise that was made quite a long time ago to converge on the single domain approach. It seems that=20= the text in the Framework was not aligned with this decision.=20 This is my in my previous email the chairs asked that The Framework=20 document be changed to use MUST (and aligned the other sentence with=20 the 1:1 comment", as well as align the text in the MIB. Tom/Nevil >=20 > Best regards, > Juergen >=20 >=20 >> -----Original Message----- >> From: Benoit Claise [mailto:bclaise@cisco.com] >> Sent: Freitag, 17. Januar 2014 17:20 >> To: Juergen Quittek; eman mailing list >> Subject: Re: [eman] WG Last Call for = draft-ietf-eman-energy-monitoring-mib- >> 08 and draft-ietf-eman-energy-aware-mib-13 >>=20 >> Hi Juergen, >>=20 >> Thanks for your thorough review. >>=20 >> Dear all, >>=20 >> Below please find my comments on draft-ietf-eman-energy-aware- >> mib-13 titled "Energy Object Context MIB". I will send comments on = draft-ietf- >> eman-energy-monitoring-mib-08 in a separate message. >>=20 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> Technical comments: >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >> 1) Section 5.1, 3rd paragraph: Since you are already very = precise >> about this MUST, I would add that the name MUST NOT have length zero. >>=20 >> Not sure this is correct. RFC 6933 allows a zero-length string. See = the second >> paragraph below. >>=20 >> entPhysicalName OBJECT-TYPE >> SYNTAX SnmpAdminString >> MAX-ACCESS read-only >> STATUS current >> DESCRIPTION >> "The textual name of the physical entity. The value of = this >> object should be the name of the component as assigned by >> the local device and should be suitable for use in = commands >> entered at the device's `console'. This might be a text >> name (e.g., `console') or a simple component number (e.g., >> port or module number, such as `1'), depending on the >> physical component naming syntax of the device. >>=20 >> If there is no local name, or if this object is otherwise >> not applicable, then this object contains a zero-length >> string. >>=20 >> Note that the value of entPhysicalName for two physical >> entities will be the same in the event that the console >> interface does not distinguish between them, e.g., slot-1 >> and the card in slot-1." >> ::=3D { entPhysicalEntry 7 } >>=20 >> However, this sentence below is badly expressed >>=20 >> Every Energy Object MUST have a printable name assigned to it. >> This sentence actually means that if an assigned name is used, it = must be a >> printable one. >> However, I wonder if this that sentence is needed at all, because we = overrule >> the entPhysicalName definition from the ENTITY-V4 RFC. >>=20 >> On top of that, with SnmpAdminString, we should be good, no? >>=20 >> from http://www.ietf.org/rfc/rfc3411.txt, >> SnmpAdminString ::=3D TEXTUAL-CONVENTION >> DISPLAY-HINT "255t" >> STATUS current >> DESCRIPTION "An octet string containing administrative >> information, preferably in human-readable form. >>=20 >> To facilitate internationalization, this >> information is represented using the ISO/IEC >> IS 10646-1 character set, encoded as an octet >> string using the UTF-8 transformation format >> described in [RFC2279]. >>=20 >> Since additional code points are added by >> amendments to the 10646 standard from time >> to time, implementations must be prepared to >> encounter any code point from 0x00000000 to >> 0x7fffffff. Byte sequences that do not >> correspond to the valid UTF-8 encoding of a >> code point or are outside this range are >> prohibited. >>=20 >> The use of control codes should be avoided. >>=20 >> When it is necessary to represent a newline, >> the control code sequence CR LF should be used. >> The use of leading or trailing white space should >> be avoided. >>=20 >> For code points not directly supported by user >> interface hardware or software, an alternative >> means of entry and display, such as hexadecimal, >> may be provided. >>=20 >> For information encoded in 7-bit US-ASCII, >> the UTF-8 encoding is identical to the >> US-ASCII encoding. >>=20 >> UTF-8 may require multiple bytes to represent a >> single character / code point; thus the length >> of this object in octets may be different from >> the number of characters encoded. Similarly, >> size constraints refer to the number of encoded >> octets, not the number of characters represented >> by an encoding. >>=20 >> Note that when this TC is used for an object that >> is used or envisioned to be used as an index, then >> a SIZE restriction MUST be specified so that the >> number of sub-identifiers for any object instance >> does not exceed the limit of 128, as defined by >> [RFC3416]. >>=20 >> Note that the size of an SnmpAdminString object is >> measured in octets, not characters. >> " >> SYNTAX OCTET STRING (SIZE (0..255)) >>=20 >> Proposal, to make it clear that printable names are really a plus: >> OLD: >> "Every Energy Object MUST have a printable name assigned to it" >> NEW: >> "While entPhysicalName does allow zero-length name, every = Energy >> Object should have a printable name assigned to it" >>=20 >>=20 >>=20 >> 2) Section 5.1, one but last paragraph: "Each Energy Object MUST >> belong to a single Energy Management Domain or in other words, an = Energy >> Object cannot belong to more than one Energy Management Domain." This = is >> more strict than in the framework where we say an EO "should" not = belong to >> more than one domain. However, as we have discussed several times, = there >> are management systems that use more than one domain (different to >> EnergyWise). I do not see a good reason to declare that their model = is wrong. >> Thus, we can recommend "make it as EnergWise from Cisco does it" with = the >> "should" clause that we have in the framework, but we should not = fully >> exclude other solutions with a "must" clause. See also comment 7). >>=20 >> Thanks for catching this discrepancy. >> The framework mentions on one side: >>=20 >> The Energy Object (Class) contains a string attribute to >> indicate membership in an Energy Management Domain. >> It's true that this framework sentence contradicts this: >>=20 >> An Energy Object should be a member of a single Energy >> Management Domain therefore one attribute is provided. >>=20 >> This last sentence doesn't reflect what was discussed at >> http://www.ietf.org/mail-archive/web/eman/current/msg02033.html >>=20 >>=20 >> 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. >>=20 >>=20 >> And, most importantly, http://www.ietf.org/mail- >> archive/web/eman/current/msg02037.html, which is the outcome of the >> authors call, supervised by Nevil: >>=20 >>=20 >> *** 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 >> better 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 >>=20 >>=20 >> The framework should correct this sentence: >> OLD: >>=20 >> An Energy Object should be a member of a single Energy >> Management Domain therefore one attribute is provided. >> NEW: >>=20 >> An Energy Object must be a member of a single Energy >> Management Domain therefore one attribute is provided. >>=20 >>=20 >>=20 >> 3) Section 5.3, 2nd and 3rd paragraph: >> Both paragraphs need more explanation and you need to make them >> consistent with the text in the MIB modules. For LLDP you say "If the = LLDP MIB >> is implemented". Why don't you have a similar statement for the PoE = MIB? >> You talk about "the" Energy Object SNMP agent. However, EOs may not = have >> SNMP agents, for example, if they are just a power interface. And it = is not >> specified which of the potentially numerous instances of = lldpLocPortNum >> objects of a device should be reported. >>=20 >> Ack, will provide some new text >>=20 >>=20 >>=20 >> 4) Section 5.4, 4th paragraph: >> "Since the communication between the Energy Objects may not be >> SNMP and is left to the choice of the device manufacturer, an >> Energy Object can have additional MIB objects that can be used >> for easier identification by the EnMS." >> Two comments on this sentence: >> A) It is not very obvious if SNMP is not available, it makes = sense to use >> MIB objects. Please clarify this. >> B) Please note that the choice is not only with the = manufacturer. Even >> if the manufacturer builds in SNMP, the operator may choose to = disable it ;-) >>=20 >> This is a badly written sentence. >> Proposal: remove >>=20 >>=20 >> "Since the communication between the Energy Objects may not be >> SNMP and is left to the choice of the device manufacturer" >>=20 >>=20 >>=20 >> 5) Section 6, DESCRIPTION clause of object eoEthPortIndex: >> What "attached device" are you talking about? >> Why is it relevant for the specification of this object, if that = a certain >> MIB module "should" be implemented on that device? Does it make any >> different for the DESCRIPTION of this object whether or not this MIB = module is >> implemented on the attached device? I do not see why and thus = recommend >> removing the statement "PoE MIB should be instantiated on the = device." >>=20 >> New text will be proposed. >>=20 >>=20 >>=20 >> 6) Section 6, DESCRIPTION clause of object eoMgmtDNSName: >> There may be more than one DNS name associated to a single IP >> address: >> "the DNS name" -> "a DNS name" >>=20 >> fixed >>=20 >>=20 >>=20 >>=20 >> 7) Section 6, DESCRIPTION clause of object eoDomainName: >> Please insert as second sentence: "If the energy object has been >> assigned to multiple domains, then they are represented in this = object as >> comma-separated list.", see comment 2). >>=20 >> See point 2. >>=20 >>=20 >>=20 >> 8) Section 6, SYNTAX clause of object eoPowerCategory: >> Some devices match more than one category, for example a UPS is = a >> store and a distributor at the same time, and to be precise, also a = consumer. A >> PoE Switch is a consumer and a distributor, some devices switch = between >> consumer and producer, etc. We can support all of this if we change = the >> syntax from INTEGER to BITS. >>=20 >> See point 2, for the justification, discussed at the [EMAN-FMWK] = time, on why >> not to do this. >>=20 >>=20 >>=20 >> 9) Section 6, DESCRIPTION clause of object eoAlternateKey: >> There is a contradiction between having this object with = MAX-ACCESS >> read-write and stating " This object specifies a manufacturer defined = string". If >> the manufacturer defines the string, there is no need to write it. I = suggest >> allowing the operator to set the value of this document. >>=20 >> The use of the "manufacturer" word is a poor choice. >> This corresponds to section 5.3: >>=20 >> The eoAlternateKey alternate key object specifies a = manufacturer >> defined string that can be used to identify the Energy Object. >> Since an EnMS may need to correlate objects across management >> systems, this alternate key is provided to facilitate such a >> link. This optional value is intended as a foreign key or >> alternate identifier for a manufacturer or EnMS to use to >> correlate the unique Energy Object Id in other systems or >> namespaces. If an alternate key is not available or is not >> applicable then the value is the zero-length string. >>=20 >> Proposal: change to "alternate" >>=20 >> In section 5.3 >> OLD: >>=20 >> The eoAlternateKey alternate key object specifies a = manufacturer >> defined string that can be used to identify the Energy Object. >> NEW: >> The eoAlternateKey object specifies an alternate key string >> that can be used to identify the Energy Object. >> OLD: >>=20 >> eoAlternateKey OBJECT-TYPE >> SYNTAX SnmpAdminString >> MAX-ACCESS read-write >> STATUS current >> DESCRIPTION >> "This object specifies a manufacturer defined string = that >> can be used to identify the Energy Object. >> NEW: >>=20 >> eoAlternateKey OBJECT-TYPE >> SYNTAX SnmpAdminString >> MAX-ACCESS read-write >> STATUS current >> DESCRIPTION >> "This object specifies an alternate key string >>=20 >>=20 >>=20 >>=20 >> 10) Section 6, DESCRIPTION clause of object eoRelationID: >> I recommend adding a sentence to the DESCRIPTION clause, that >> preferable the value of an entPhysicalUUID from the Entity MIB should = be >> used for values of this object. >>=20 >> ok. >>=20 >>=20 >>=20 >>=20 >> 11) Section 6, Conformance of ENERGY-OBJECT-CONTEXT-MIB module: >> The dependence of compliance with entity4CRCompliance is stated = in >> the GROUP DESCRIPTION clauses. In our case, this is not the right = place. There >> is a dependency on entity4CRCompliance independent of which group is >> implemented. Hence, these statements need to be moved from the GROUP >> DESCRIPTION clauses to the module compliance DESCRIPTION clauses of >> energyObjectContextMIBFullCompliance and >> energyObjectContextMIBReadOnlyCompliance. >>=20 >> That makes sense. >>=20 >>=20 >>=20 >>=20 >> 12) Section 6, Conformance of ENERGY-OBJECT-CONTEXT-MIB module: >> We state in other places that implementation of the Entity MIB >> compliant with entity4CRCompliance is a must. But in the conformance = section >> of the ENERGY-OBJECT-CONTEXT-MIB the dependency on >> entity4CRCompliance is stated as "should". This need to be changed to = a >> "must" or "required." >>=20 >> Good catch. >>=20 >>=20 >>=20 >>=20 >> 13) Section 6, DESCRIPTION clause of TC IANAEnergyRelationship: >> For interoperability, the description need to be clear. As this = TC is >> stated, there are two points unclear to me: >> A) " The enumeration 'poweredBy' is applicable if the >> Energy Object A is poweredBy Energy Object B. >> The enumeration 'powering' is applicable if the >> Energy Object A is powering Energy Object B." >> If the TC is used, how do I know which object is A and which is = B? Is it >> that the DESCRIPTION clauses of objects of this type must refer to = object A and >> object B? >>=20 >> OLD: >>=20 >> IANAEnergyRelationship ::=3D TEXTUAL-CONVENTION >> STATUS current >> DESCRIPTION >> "An enumerated value specifies the type of >> relationship between Energy Objects. >> NEW: >>=20 >> IANAEnergyRelationship ::=3D TEXTUAL-CONVENTION >> STATUS current >> DESCRIPTION >> "An enumerated value specifying the type of >> relationship between an Energy Object A, on which >> the relationship is specified, with the Energy = Object B, >> characterized by the UUID." >>=20 >>=20 >> B) "if the Energy Object A is aggregating Energy Object B" >> There is no place in this document where there is explained what >> aggregating means. >>=20 >> Part of section 5.4, we refer to [EMAN-FMWK], which defines the = aggregation >> relationship as a summation. I guess you want some more text in this = section >> 5.4? >>=20 >>=20 >>=20 >>=20 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> Editorial comments: >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >> All these will be taken care of. >>=20 >> Thanks again. >>=20 >> Regards, Benoit. >>=20 >>=20 >>=20 >>=20 >> 14) Abstract, last two lines: >> "relationships between reporting devices, remote devices, and >> monitoring devices.": The enumeration of "reporting devices", = "monitoring >> devices", and "remote devices" is inappropriate because it does not = reflect >> the list of relationships discussed by the draft: poweredBy, = meteredBy, >> aggregatedBy. >>=20 >> 15) Section 1. Introduction, 2nd paragraph, last two lines: >> "Identification" -> "identification" >> "Context" -> "context" >> "Relationships" -> "relationships" >>=20 >> 16) Section 1.1, 3rd paragraph, line 1: >> "A second MIB module required by the [EMAN-FMWK]": There is no >> MIB module required by the EMAN framework. It seems you wanted to = say: "A >> second MIB module meeting EMAN requirements given by [RFC6988]". >>=20 >> 17) Entire Section 3 >> This section is completely redundant. It mainly repeats = sentences of >> section 1.1. Remove this section and merge sentences you want to keep = into >> section 1.1 >>=20 >> 18) Section 5, 3rd paragraph, first sentence: >> The sentence is not grammatically correct, please fix. Also = semantic >> correction seems to be needed. You don't mention "identification" as = focus of >> the first table. >>=20 >> 19) Section 5, sentence before Figure 1: >> "The following UML diagram illustrates the relationship of the >> MIB objects in the eoTable, eoRelationTable that describe the >> identity, context and relationship of an Energy Object." >> You should mention that you UML diagram furthermore contains >> objects from the Entity MIB. >>=20 >> 20) Section 5, figure 1: >> There is a dotted line at the lower left that goes nowhere. = Please cut >> it. >>=20 >> 21) Section 5, grouping of MIB objects is inconsistent. >> In Figure 1 you have three groups: "Context", "Identification", >> "Relationships", where "Identifications" has three subgroups. The = sentence >> below the figure emphasizes this grouping. However, the following >> subsections 5.1-5.4 are grouped differently. 5.1 is titled = "Identification" but >> covers only a third of the objects under "Identification" in Figure = 1. Section >> 5.2 is consistently with Figure 1 covering context information. = Section 5.3 >> covers PoE and LLDP identification. Sections 5.4 is called = "Relationships" but >> covers not just the objects under "Relationships" in Figure 1, but = also objects >> from under "Identification" in Figure 1. Here is a clean-up needed. = Please split >> the last sentence from section 5.4. It firs much better in section = 5.3. >>=20 >> 22) Section 5, enumeration under Figure 1: >> Please note that subsection 5.5 is not another group of MIB = objects >> but refers to objects in subsection 5.1. The sentence above the = enumeration >> implies that each numbered item would be a group of objects. >>=20 >> 23) Section 5.1, 2nd paragraph, line 7: >> What is "primary Energy Object information"? >>=20 >> 24) Section 5.4, 2nd paragraph, last sentence: >> "It is important to notice, that it is possible that" -> = "Obviously," >> "not have an" -> "not have any" >>=20 >> 25) Section 5.4, 4th paragraph >> The entire paragraph is in the wrong subsection. It rather = belongs to >> subsection 5.1 or 5.3. >>=20 >> 26) Section 6, DESCRIPTION clause of object eoEthPortGrpIndex: >> See comment 5). There is a full stop missing at the end of the = second >> sentence. >>=20 >> 27) Section 6, OBJECTS clause of GROUP >> energyObjectRelationTableGroup: >> The comment "Note that object eoRelationIndex is not included = since >> it is not-accessible" is not really needed. Almost every Conformance = section >> has such objects and usually this comment is omitted. >>=20 >> Cheers, >> Juergen >>=20 >>=20 >>=20 >> -----Original Message----- >> From: eman [mailto:eman-bounces@ietf.org] On Behalf Of >> Thomas Nadeau >> Sent: Montag, 16. Dezember 2013 16:56 >> To: eman mailing list >> Subject: [eman] WG Last Call for draft-ietf-eman-energy- >> monitoring-mib-08 >> and draft-ietf-eman-energy-aware-mib-13 >>=20 >>=20 >> As agreed at the last WG meeting, with the EMAN >> Framework >> completing its WG LC the chairs would like to initiate a = WG LC >> on draft-ietf- >> eman-energy-monitoring-mib-08 and = draft-ietf-eman-energy- >> aware-mib-13. >> The WG LC will end on Dec 30 at 8AM EDT. >>=20 >> Thank you, >>=20 >> Nevil and Tom >>=20 >>=20 >>=20 >> _______________________________________________ >> eman mailing list >> eman@ietf.org >> https://www.ietf.org/mailman/listinfo/eman >> . >>=20 >>=20 >=20 > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman >=20 --Apple-Mail=_E971151C-84E6-4513-B5D3-CD9F0D722744 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 iQIcBAEBCgAGBQJS5qTQAAoJEPcO+I7eiUJZTVQP+gMk4rSVArVtotnpbNyFGbf7 EWXqbr8ntiiSAf0Oz15v7hcfQxK6yGWkjBDkBSF2qGcUVbOu7Ko6sjr1GXuh51kS w+R8VYg/27pAAeix2un7eUtlyA8GguXMnNGALAIqWHYgr20lpvd6sX2+VSlKlK6g 9sKSU0Q0F9cJXr1evAg2rO1o7Gz5v03DgU0sGtr2+m1vCVS4hCvscATZsXJzGk7O zckYr1XHfQLsyRhbbqOrVzTeJTO2yHchDIKbzsxQ36VEy6tPtV0PnbPGGGq4xeRL In+6s8qxKrEDv2sbE4KdowoYCUXVOBy3tE+9b6lCBq2tEY1X4JNfEWhSgTX84RNt y8EVawcdNbiY7Dhj7+Rj1ZKxWzkLNO+rcjoB4TVVKDUh/LWHAxjjShTxA6jnNPPa m6ijbvln45t+WicfmPPUv33y8ObRDvmS2p9zr6MME03k8LvOXbN2Wsx6yV1aOqBI duTaUtgVNF1SGNpNkapzAX2LFoHwhKa5plNOhQ4p2QEIAX8GoGlQs3QkRq95LplP aOzDq82Oo7Ev1x2Dr8JCihk0tuRN0VDqt8mFBrM3nyXgtKFGwu4sO3XFGkr7cXlz efhBshxNojXPG/Z2CzV571QoGNnmhuuICIPG0ESlyNimrr7eE8BciYja/TD8Os2q h5HNvTiO/Ng+LslZTHg0 =mz6N -----END PGP SIGNATURE----- --Apple-Mail=_E971151C-84E6-4513-B5D3-CD9F0D722744-- From n.brownlee@auckland.ac.nz Mon Jan 27 12:46:06 2014 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F8CD1A029E for ; Mon, 27 Jan 2014 12:46:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7vMx7EFNdc67 for ; Mon, 27 Jan 2014 12:46:00 -0800 (PST) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id E5CF81A00F6 for ; Mon, 27 Jan 2014 12:45:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1390855558; x=1422391558; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=Xjr53EDUMQ27cWzd1MS1uVJU2jY7WzKHLRKrIsuVP5s=; b=TJUOtBpuKjCKnaPvEL97r853hLHWChJy/34rLyyIgQB1TiHg2g+jj+/p TPfh5LIXb9pvR1cvl/bKOiTCj5ojbbB4Dyk7n4iP6yvG6BuVwisKLidIJ LNAwkdplMl6Lt+PuhMEW0VyLmjUb3keAQcljEwYhBkLvZ+gfAm2rIokj2 0=; X-IronPort-AV: E=Sophos;i="4.95,731,1384254000"; d="scan'208";a="231103085" 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; 28 Jan 2014 09:45:54 +1300 Message-ID: <52E6C581.70000@auckland.ac.nz> Date: Tue, 28 Jan 2014 09:45:53 +1300 From: Nevil Brownlee User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: eman mailing list References: <52D9583D.6020603@cisco.com> <52DC578D.30105@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [eman] MIB WG Last calls and the EMAN Framework X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 27 Jan 2014 20:46:06 -0000 Hi EMAN WG: A brief note to make this point clear ... From the WGLC comments on the MIBs, it's become clear that allowing MIB objects to belong to more than one Energy Management Domain will make it complicated to implement the MIBs than we'd like. Tom summarised two possible solutions to this for me: > 1) Change the "should" to a "must" as well as the "recommended" > to a "must" in the framework. That makes the framework itself > consistent without any doubt as to there being a single domain per > object. > > 2) Leave the framework as is, but require the MIB to handle objects > belonging to multiple domains. As was mentioned, it currently is > implemented as a free-form string. The text above regarding making > it comma-separated is difficult for implementations, but is not > the end of the world. Things could also be enhanced if we added a > variable called NumDomainsype and would indicate the number of > domains present, and hence the number of commas to search for. Of > course, then there are the corner cases to check for etc ... > The best way to implement this sort of thing is via a sparse > table, but that is water under the bridge now I suppose. Of these, I consider that (1) is much the simplest. Therefore, I'd like - as WG co-chair - to see the Framework changed so that using a single energy Management Domain is definitely a MUST. I realise that it's very late to make such a change, but I feel that it's overall better for EMAN. Does anyone on the EMAN list have any strong objection to this change? All feedback is - as always - welcome. Also, please note that although Benoit has provided helpful commentary on this recently, he did so simply as a document author. My propsal above (Framework change to MUST) is this is a WG Chair decision. Cheers, Nevil On 28/01/14 5:48 AM, Thomas Nadeau wrote: > > EMAN WG, > > Nevil, Benoit and I have discussed this issue at length. Given the 11:45th hour on this document, we independently went > through the history of the document as well as the various LC comments to see if there was a simple and quick > solution to the point Juergen raised during the LC. It seems that the language of MUST or SHOULD makes a > big difference at the MIB level and/or makes the MIBs not-conforming with the Framework depending on what we decide to do > here. There does seem to be some history behind this one, whereby the document was changed to a SHOULD from a MUST. > > Just a little background on the matter: > > The current framework contains a SHOULD in section 6.3.6 that is kind of contradicted by the "recommended ... 1:1" text above it. > > One way or another, these need to be made consistent and painfully obvious: > > 6.3.6. Context: Domain > > > > > Claise et al. Expires October 30 2015 [Page 17] > > > Internet-Draft EMAN Framework January 2014 > > The Energy Object (Class) contains a string attribute to > indicate membership in an Energy Management Domain. An > Energy Management Domain can be any collection of Energy > Objects 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. > > > In order conform to the framework, The Energy-Mon MIB has Section 6, DESCRIPTION clause of object eoDomainName: > > Please insert as second sentence: "If the energy object has been assigned to > multiple domains, then they are represented in this object as comma-separated > list.", see comment 2). > > The issue here is that comma-separated string is a pain as the NMS has to check every string for comma. But the alternatives are far more messy. > > > Based on the above, this point we believe there is one option that will sort this situation out: > > Change the "should" to a "must" as well as the "recommended" to a "must" in the framework. That makes the framework itself consistent > without any doubt as to there being a single domain per object. This also fixes the issue above with the MIB. > > --Tom > > > > > >> -------- Original Message -------- >> Subject: Re: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib-13 >> Date: Fri, 17 Jan 2014 17:20:13 +0100 >> From: Benoit Claise >> To: Juergen Quittek , eman mailing list >> >> Hi Juergen, >> >> Thanks for your thorough review. >>> Dear all, >>> >>> Below please find my comments on draft-ietf-eman-energy-aware-mib-13 titled "Energy Object Context MIB". I will send comments on draft-ietf-eman-energy-monitoring-mib-08 in a separate message. >>> >>> ================== >>> Technical comments: >>> ================== >>> >>> 1) Section 5.1, 3rd paragraph: Since you are already very precise about this MUST, I would add that the name MUST NOT have length zero. >> Not sure this is correct. RFC 6933 allows a zero-length string. See the second paragraph below. >> entPhysicalName OBJECT-TYPE >> SYNTAX SnmpAdminString >> MAX-ACCESS read-only >> STATUS current >> DESCRIPTION >> "The textual name of the physical entity. The value of this >> object should be the name of the component as assigned by >> the local device and should be suitable for use in commands >> entered at the device's `console'. This might be a text >> name (e.g., `console') or a simple component number (e.g., >> port or module number, such as `1'), depending on the >> physical component naming syntax of the device. >> >> If there is no local name, or if this object is otherwise >> not applicable, then this object contains a zero-length >> string. >> >> Note that the value of entPhysicalName for two physical >> entities will be the same in the event that the console >> interface does not distinguish between them, e.g., slot-1 >> and the card in slot-1." >> ::= { entPhysicalEntry 7 } >> >> However, this sentence below is badly expressed >> Every Energy Object MUST have a printable name assigned to it. >> This sentence actually means that if an assigned name is used, it must be a printable one. >> However, I wonder if this that sentence is needed at all, because we overrule the entPhysicalName definition from the ENTITY-V4 RFC. >> On top of that, with SnmpAdminString, we should be good, no? >> >> from http://www.ietf.org/rfc/rfc3411.txt, >> SnmpAdminString ::= TEXTUAL-CONVENTION >> DISPLAY-HINT "255t" >> STATUS current >> DESCRIPTION "An octet string containing administrative >> information, preferably in human-readable form. >> >> To facilitate internationalization, this >> information is represented using the ISO/IEC >> IS 10646-1 character set, encoded as an octet >> string using the UTF-8 transformation format >> described in [RFC2279]. >> >> Since additional code points are added by >> amendments to the 10646 standard from time >> to time, implementations must be prepared to >> encounter any code point from 0x00000000 to >> 0x7fffffff. Byte sequences that do not >> correspond to the valid UTF-8 encoding of a >> code point or are outside this range are >> prohibited. >> >> The use of control codes should be avoided. >> >> When it is necessary to represent a newline, >> the control code sequence CR LF should be used. >> The use of leading or trailing white space should >> be avoided. >> >> For code points not directly supported by user >> interface hardware or software, an alternative >> means of entry and display, such as hexadecimal, >> may be provided. >> >> For information encoded in 7-bit US-ASCII, >> the UTF-8 encoding is identical to the >> US-ASCII encoding. >> >> UTF-8 may require multiple bytes to represent a >> single character / code point; thus the length >> of this object in octets may be different from >> the number of characters encoded. Similarly, >> size constraints refer to the number of encoded >> octets, not the number of characters represented >> by an encoding. >> >> Note that when this TC is used for an object that >> is used or envisioned to be used as an index, then >> a SIZE restriction MUST be specified so that the >> number of sub-identifiers for any object instance >> does not exceed the limit of 128, as defined by >> [RFC3416]. >> >> Note that the size of an SnmpAdminString object is >> measured in octets, not characters. >> " >> SYNTAX OCTET STRING (SIZE (0..255)) >> >> Proposal, to make it clear that printable names are really a plus: >> OLD: >> "Every Energy Object MUST have a printable name assigned to it" >> NEW: >> "While entPhysicalName does allow zero-length name, every Energy >> Object should have a printable name assigned to it" >>> 2) Section 5.1, one but last paragraph: "Each Energy Object MUST belong to a single Energy Management Domain or in other words, an Energy Object cannot belong to more than one Energy Management Domain." This is more strict than in the framework where we say an EO "should" not belong to more than one domain. However, as we have discussed several times, there are management systems that use more than one domain (different to EnergyWise). I do not see a good reason to declare that their model is wrong. Thus, we can recommend "make it as EnergWise from Cisco does it" with the "should" clause that we have in the framework, but we should not fully exclude other solutions with a "must" clause. See also comment 7). >> Thanks for catching this discrepancy. >> The framework mentions on one side: >> The Energy Object (Class) contains a string attribute to >> indicate membership in an Energy Management Domain. >> It's true that this framework sentence contradicts this: >> An Energy Object should be a member of a single Energy >> Management Domain therefore one attribute is provided. >> >> This last sentence doesn't reflect what was discussed at >> http://www.ietf.org/mail-archive/web/eman/current/msg02033.html >> 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. >> >> And, most importantly, http://www.ietf.org/mail-archive/web/eman/current/msg02037.html, which is the outcome of the authors call, supervised by Nevil: >> *** 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 better 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 >> >> The framework should correct this sentence: >> OLD: >> An Energy Object should be a member of a single Energy >> Management Domain therefore one attribute is provided. >> NEW: >> An Energy Object must be a member of a single Energy >> Management Domain therefore one attribute is provided. >>> 3) Section 5.3, 2nd and 3rd paragraph: >>> Both paragraphs need more explanation and you need to make them consistent with the text in the MIB modules. For LLDP you say "If the LLDP MIB is implemented". Why don't you have a similar statement for the PoE MIB? You talk about "the" Energy Object SNMP agent. However, EOs may not have SNMP agents, for example, if they are just a power interface. And it is not specified which of the potentially numerous instances of lldpLocPortNum objects of a device should be reported. >> Ack, will provide some new text >>> >>> 4) Section 5.4, 4th paragraph: >>> "Since the communication between the Energy Objects may not be >>> SNMP and is left to the choice of the device manufacturer, an >>> Energy Object can have additional MIB objects that can be used >>> for easier identification by the EnMS." >>> Two comments on this sentence: >>> A) It is not very obvious if SNMP is not available, it makes sense to use MIB objects. Please clarify this. >>> B) Please note that the choice is not only with the manufacturer. Even if the manufacturer builds in SNMP, the operator may choose to disable it ;-) >> This is a badly written sentence. >> Proposal: remove >> "Since the communication between the Energy Objects may not be >> SNMP and is left to the choice of the device manufacturer" >>> 5) Section 6, DESCRIPTION clause of object eoEthPortIndex: >>> What "attached device" are you talking about? >>> Why is it relevant for the specification of this object, if that a certain MIB module "should" be implemented on that device? Does it make any different for the DESCRIPTION of this object whether or not this MIB module is implemented on the attached device? I do not see why and thus recommend removing the statement "PoE MIB should be instantiated on the device." >> New text will be proposed. >>> >>> 6) Section 6, DESCRIPTION clause of object eoMgmtDNSName: >>> There may be more than one DNS name associated to a single IP address: >>> "the DNS name" -> "a DNS name" >> fixed >>> 7) Section 6, DESCRIPTION clause of object eoDomainName: >>> Please insert as second sentence: "If the energy object has been assigned to multiple domains, then they are represented in this object as comma-separated list.", see comment 2). >> See point 2. >>> >>> 8) Section 6, SYNTAX clause of object eoPowerCategory: >>> Some devices match more than one category, for example a UPS is a store and a distributor at the same time, and to be precise, also a consumer. A PoE Switch is a consumer and a distributor, some devices switch between consumer and producer, etc. We can support all of this if we change the syntax from INTEGER to BITS. >> See point 2, for the justification, discussed at the [EMAN-FMWK] time, on why not to do this. >>> >>> 9) Section 6, DESCRIPTION clause of object eoAlternateKey: >>> There is a contradiction between having this object with MAX-ACCESS read-write and stating " This object specifies a manufacturer defined string". If the manufacturer defines the string, there is no need to write it. I suggest allowing the operator to set the value of this document. >> The use of the "manufacturer" word is a poor choice. >> This corresponds to section 5.3: >> The eoAlternateKey alternate key object specifies a manufacturer >> defined string that can be used to identify the Energy Object. >> Since an EnMS may need to correlate objects across management >> systems, this alternate key is provided to facilitate such a >> link. This optional value is intended as a foreign key or >> alternate identifier for a manufacturer or EnMS to use to >> correlate the unique Energy Object Id in other systems or >> namespaces. If an alternate key is not available or is not >> applicable then the value is the zero-length string. >> >> Proposal: change to "alternate" >> >> In section 5.3 >> OLD: >> The eoAlternateKey alternate key object specifies a manufacturer >> defined string that can be used to identify the Energy Object. >> NEW: >> The eoAlternateKey object specifies an alternate key string >> that can be used to identify the Energy Object. >> OLD: >> eoAlternateKey OBJECT-TYPE >> SYNTAX SnmpAdminString >> MAX-ACCESS read-write >> STATUS current >> DESCRIPTION >> "This object specifies a manufacturer defined string that >> can be used to identify the Energy Object. >> NEW: >> eoAlternateKey OBJECT-TYPE >> SYNTAX SnmpAdminString >> MAX-ACCESS read-write >> STATUS current >> DESCRIPTION >> "This object specifies an alternate key string >> >>> 10) Section 6, DESCRIPTION clause of object eoRelationID: >>> I recommend adding a sentence to the DESCRIPTION clause, that preferable the value of an entPhysicalUUID from the Entity MIB should be used for values of this object. >> ok. >>> 11) Section 6, Conformance of ENERGY-OBJECT-CONTEXT-MIB module: >>> The dependence of compliance with entity4CRCompliance is stated in the GROUP DESCRIPTION clauses. In our case, this is not the right place. There is a dependency on entity4CRCompliance independent of which group is implemented. Hence, these statements need to be moved from the GROUP DESCRIPTION clauses to the module compliance DESCRIPTION clauses of energyObjectContextMIBFullCompliance and energyObjectContextMIBReadOnlyCompliance. >> That makes sense. >>> 12) Section 6, Conformance of ENERGY-OBJECT-CONTEXT-MIB module: >>> We state in other places that implementation of the Entity MIB compliant with entity4CRCompliance is a must. But in the conformance section of the ENERGY-OBJECT-CONTEXT-MIB the dependency on entity4CRCompliance is stated as "should". This need to be changed to a "must" or "required." >> Good catch. >>> 13) Section 6, DESCRIPTION clause of TC IANAEnergyRelationship: >>> For interoperability, the description need to be clear. As this TC is stated, there are two points unclear to me: >>> A) " The enumeration 'poweredBy' is applicable if the >>> Energy Object A is poweredBy Energy Object B. >>> The enumeration 'powering' is applicable if the >>> Energy Object A is powering Energy Object B." >>> If the TC is used, how do I know which object is A and which is B? Is it that the DESCRIPTION clauses of objects of this type must refer to object A and object B? >> OLD: >> IANAEnergyRelationship ::= TEXTUAL-CONVENTION >> STATUS current >> DESCRIPTION >> "An enumerated value specifies the type of >> relationship between Energy Objects. >> NEW: >> IANAEnergyRelationship ::= TEXTUAL-CONVENTION >> STATUS current >> DESCRIPTION >> "An enumerated value specifying the type of >> relationship between an Energy Object A, on which >> the relationship is specified, with the Energy Object B, >> characterized by the UUID." >>> B) "if the Energy Object A is aggregating Energy Object B" >>> There is no place in this document where there is explained what aggregating means. >> Part of section 5.4, we refer to [EMAN-FMWK], which defines the aggregation relationship as a summation. I guess you want some more text in this section 5.4? >>> ================= >>> Editorial comments: >>> ================= >> All these will be taken care of. >> >> Thanks again. >> >> Regards, Benoit. >>> 14) Abstract, last two lines: >>> "relationships between reporting devices, remote devices, and monitoring devices.": The enumeration of "reporting devices", "monitoring devices", and "remote devices" is inappropriate because it does not reflect the list of relationships discussed by the draft: poweredBy, meteredBy, aggregatedBy. >>> >>> 15) Section 1. Introduction, 2nd paragraph, last two lines: >>> "Identification" -> "identification" >>> "Context" -> "context" >>> "Relationships" -> "relationships" >>> >>> 16) Section 1.1, 3rd paragraph, line 1: >>> "A second MIB module required by the [EMAN-FMWK]": There is no MIB module required by the EMAN framework. It seems you wanted to say: "A second MIB module meeting EMAN requirements given by [RFC6988]". >>> >>> 17) Entire Section 3 >>> This section is completely redundant. It mainly repeats sentences of section 1.1. Remove this section and merge sentences you want to keep into section 1.1 >>> >>> 18) Section 5, 3rd paragraph, first sentence: >>> The sentence is not grammatically correct, please fix. Also semantic correction seems to be needed. You don't mention "identification" as focus of the first table. >>> >>> 19) Section 5, sentence before Figure 1: >>> "The following UML diagram illustrates the relationship of the >>> MIB objects in the eoTable, eoRelationTable that describe the >>> identity, context and relationship of an Energy Object." >>> You should mention that you UML diagram furthermore contains objects from the Entity MIB. >>> >>> 20) Section 5, figure 1: >>> There is a dotted line at the lower left that goes nowhere. Please cut it. >>> >>> 21) Section 5, grouping of MIB objects is inconsistent. >>> In Figure 1 you have three groups: "Context", "Identification", "Relationships", where "Identifications" has three subgroups. The sentence below the figure emphasizes this grouping. However, the following subsections 5.1-5.4 are grouped differently. 5.1 is titled "Identification" but covers only a third of the objects under "Identification" in Figure 1. Section 5.2 is consistently with Figure 1 covering context information. Section 5.3 covers PoE and LLDP identification. Sections 5.4 is called "Relationships" but covers not just the objects under "Relationships" in Figure 1, but also objects from under "Identification" in Figure 1. Here is a clean-up needed. Please split the last sentence from section 5.4. It firs much better in section 5.3. >>> >>> 22) Section 5, enumeration under Figure 1: >>> Please note that subsection 5.5 is not another group of MIB objects but refers to objects in subsection 5.1. The sentence above the enumeration implies that each numbered item would be a group of objects. >>> >>> 23) Section 5.1, 2nd paragraph, line 7: >>> What is "primary Energy Object information"? >>> >>> 24) Section 5.4, 2nd paragraph, last sentence: >>> "It is important to notice, that it is possible that" -> "Obviously," >>> "not have an" -> "not have any" >>> >>> 25) Section 5.4, 4th paragraph >>> The entire paragraph is in the wrong subsection. It rather belongs to subsection 5.1 or 5.3. >>> >>> 26) Section 6, DESCRIPTION clause of object eoEthPortGrpIndex: >>> See comment 5). There is a full stop missing at the end of the second sentence. >>> >>> 27) Section 6, OBJECTS clause of GROUP energyObjectRelationTableGroup: >>> The comment "Note that object eoRelationIndex is not included since it is not-accessible" is not really needed. Almost every Conformance section has such objects and usually this comment is omitted. >>> >>> Cheers, >>> Juergen >>> >>> >>>> -----Original Message----- >>>> From: eman [mailto:eman-bounces@ietf.org] On Behalf Of Thomas Nadeau >>>> Sent: Montag, 16. Dezember 2013 16:56 >>>> To: eman mailing list >>>> Subject: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib-08 >>>> and draft-ietf-eman-energy-aware-mib-13 >>>> >>>> >>>> As agreed at the last WG meeting, with the EMAN Framework >>>> completing its WG LC the chairs would like to initiate a WG LC on draft-ietf- >>>> eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib-13. >>>> The WG LC will end on Dec 30 at 8AM EDT. >>>> >>>> Thank you, >>>> >>>> Nevil and Tom >>>> >>> _______________________________________________ >>> 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 brads@coraid.com Mon Jan 27 21:52:57 2014 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AFC21A0199 for ; Mon, 27 Jan 2014 21:52:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id th3QqnU98mm4 for ; Mon, 27 Jan 2014 21:52:54 -0800 (PST) Received: from server506.appriver.com (server506e.appriver.com [50.56.144.35]) by ietfa.amsl.com (Postfix) with ESMTP id 4CE541A00FF for ; Mon, 27 Jan 2014 21:52:54 -0800 (PST) X-Note-AR-ScanTimeLocal: 1/27/2014 11:52:51 PM 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-36/SG:2 1/27/2014 11:52:48 PM X-GBUdb-Analysis: 0, 10.242.229.139, Ugly c=1 p=-0.970382 Source White X-Signature-Violations: 0-0-0-4836-c X-Note-419: 0 ms. Fail:1 Chk:1347 of 1347 total X-Note: SCH-CT/SI:1-1347/SG:1 1/27/2014 11:52:47 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: G327 G328 G329 G330 G334 G335 G445 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 147544534; Mon, 27 Jan 2014 23:52:51 -0600 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; Mon, 27 Jan 2014 23:52:50 -0600 From: Brad Schoening To: Juergen Quittek , eman mailing list Thread-Topic: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib-13 Thread-Index: AQHPG+0tpS6rr1XnlUCE8LfKL9ID9w== Date: Tue, 28 Jan 2014 05:52:50 +0000 Message-ID: In-Reply-To: <9AB93E4127C26F4BA7829DEFDCE5A6E8688B333E@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="us-ascii" Content-ID: <56934D43A45D4B4381DF8CF48DB3A74D@fwd6.exghost.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib-13 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 28 Jan 2014 05:52:57 -0000 I've updated the doc to address Juergen's 2nd point. But, is there consensus on MUST vs SHOULD for Entity MIB support? On 12/30/13 2:33 PM, "Juergen Quittek" wrote: >Dear all, > >Here are my last two comments for this WGLC. Both concerns the >conformance section of the ENERGY-OBJECT-MIB module in >draft-ietf-eman-energy-monitoring-mib-08: > >1. I may have missed a point here: Why is the Entity MIB not mandatory >anymore to implement? It is just two additional objects, since >entPhysicalIndex from this MIB is needed anyway. Particularly, we >considered the UUID provided by this MIB essential for our framework. > >2. Why is the module compliance dependency on the Entity MIB repeated in >the DESCRIPTION clauses of all optional groups within a MODULE-COMPLIANCE >declaration? I think It is fully sufficient to have it stated in the top >DESCRIPTION clause of the MODULE-COMPLIANCE declaration. Does it make any >sense to repeat it for optional groups? > >Cheers, > Juergen > > >> -----Original Message----- >> From: eman [mailto:eman-bounces@ietf.org] On Behalf Of Thomas Nadeau >> Sent: Montag, 16. Dezember 2013 16:56 >> To: eman mailing list >> Subject: [eman] WG Last Call for >>draft-ietf-eman-energy-monitoring-mib-08 >> and draft-ietf-eman-energy-aware-mib-13 >>=20 >>=20 >> As agreed at the last WG meeting, with the EMAN Framework >> completing its WG LC the chairs would like to initiate a WG LC on >>draft-ietf- >> eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib-13. >> The WG LC will end on Dec 30 at 8AM EDT. >>=20 >> Thank you, >>=20 >> Nevil and Tom >>=20 > >_______________________________________________ >eman mailing list >eman@ietf.org >https://www.ietf.org/mailman/listinfo/eman From tnadeau@lucidvision.com Tue Jan 28 07:03:40 2014 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B2311A0379 for ; Tue, 28 Jan 2014 07:03:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Na__Qy30dsrV for ; Tue, 28 Jan 2014 07:03:38 -0800 (PST) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 1C4FC1A008E for ; Tue, 28 Jan 2014 07:03:38 -0800 (PST) Received: from [192.168.1.110] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 5A4EC26CDB95; Tue, 28 Jan 2014 10:03:35 -0500 (EST) Content-Type: multipart/signed; boundary="Apple-Mail=_B8FDDFA2-C5A3-42FA-BDFE-CA0C72C1E383"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Thomas Nadeau In-Reply-To: Date: Tue, 28 Jan 2014 10:03:35 -0500 Message-Id: References: To: Brad Schoening X-Mailer: Apple Mail (2.1827) Cc: eman mailing list Subject: Re: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib-13 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 28 Jan 2014 15:03:40 -0000 --Apple-Mail=_B8FDDFA2-C5A3-42FA-BDFE-CA0C72C1E383 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Brad/EMAN WG, As both Nevil and I noted yesterday, we both consider that there=20= is sufficient consensus to have the Framework changed so that using a = single=20 Energy Management Domain is written as a MUST in the documents. As = chairs we=20 are directing the editors of the draft to please make this change so = that the=20 MIBs and the Framework will be aligned.=20 We both I understand that it is very, very late in the game to=20= make this change, but this needs to happen to keep the ball rolling = forward=20 for EMAN and all of the existing implementations. Under the = circumstances,=20 we also understand that this might have taken people by surprise, and = thus=20 while we do not want to re-open the debate/discussion that happened = around=20 this issue a while back now, we would still like to ask the WG if anyone = on=20 the EMAN list has a strong objection to this change or how it should be = made=20 to the drafts. Please chime in ASAP. If we do not hear anything by = Friday,=20 January 31, 2014 at 8AM EDT, we will proceed forward as directed. --Tom On Jan 28, 2014:12:52 AM, at 12:52 AM, Brad Schoening = wrote: >=20 >=20 > I've updated the doc to address Juergen's 2nd point. But, is there > consensus on MUST vs SHOULD for Entity MIB support? >=20 >=20 >=20 > On 12/30/13 2:33 PM, "Juergen Quittek" wrote: >=20 >> Dear all, >>=20 >> Here are my last two comments for this WGLC. Both concerns the >> conformance section of the ENERGY-OBJECT-MIB module in >> draft-ietf-eman-energy-monitoring-mib-08: >>=20 >> 1. I may have missed a point here: Why is the Entity MIB not = mandatory >> anymore to implement? It is just two additional objects, since >> entPhysicalIndex from this MIB is needed anyway. Particularly, we >> considered the UUID provided by this MIB essential for our framework. >>=20 >> 2. Why is the module compliance dependency on the Entity MIB repeated = in >> the DESCRIPTION clauses of all optional groups within a = MODULE-COMPLIANCE >> declaration? I think It is fully sufficient to have it stated in the = top >> DESCRIPTION clause of the MODULE-COMPLIANCE declaration. Does it make = any >> sense to repeat it for optional groups? >>=20 >> Cheers, >> Juergen >>=20 >>=20 >>> -----Original Message----- >>> From: eman [mailto:eman-bounces@ietf.org] On Behalf Of Thomas Nadeau >>> Sent: Montag, 16. Dezember 2013 16:56 >>> To: eman mailing list >>> Subject: [eman] WG Last Call for >>> draft-ietf-eman-energy-monitoring-mib-08 >>> and draft-ietf-eman-energy-aware-mib-13 >>>=20 >>>=20 >>> As agreed at the last WG meeting, with the EMAN Framework >>> completing its WG LC the chairs would like to initiate a WG LC on >>> draft-ietf- >>> eman-energy-monitoring-mib-08 and = draft-ietf-eman-energy-aware-mib-13. >>> The WG LC will end on Dec 30 at 8AM EDT. >>>=20 >>> Thank you, >>>=20 >>> Nevil and Tom >>>=20 >>=20 >> _______________________________________________ >> eman mailing list >> eman@ietf.org >> https://www.ietf.org/mailman/listinfo/eman >=20 > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman >=20 --Apple-Mail=_B8FDDFA2-C5A3-42FA-BDFE-CA0C72C1E383 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 iQIcBAEBCgAGBQJS58bHAAoJEPcO+I7eiUJZkLYQAK1cVIpnMTzkA18aJw/BcAKY DkAmV1DTR1qas9UhruJsa+nAEKsTd4WRd8xrKe2O46DXyymGfIlbg75ka5ZCtG53 BI+mYoPbvHolcmW7vEZn3xEx1Q6Eu8wGYSd1pSWzhr0SME1LFIPbJ7Rhe8DF9TlO Rxu/WvQERTeD5ksUZov7tZGI11aFAJ1PpKiYfTPrBirZN7xk218VpoxjdneKbwaG 86+JIqeDsIBdEB0ETtieC2d0gpJDvKCXqEh4Cf7dKCCdz6D7Q37tf11THtqCjq10 q6wjSEpgzLf1g1V+9qtD+J9zlDCbY2tKlduaH7ryDh43GaHiMnNF2iGO7Jk+/FOL k5b4LqpSctWYyTHl6FK2i5S51PxWFaZ2ufHUH3FJU6Lg3KpE2fJg933XzX2PawF7 rbDn6/lSgZvBtaHfm/zh1n2I+pM/vCZbXRo6AGG+5nOZ74WCILfEWICy1lgAjuSv 1SBpoX5wYWcP4ZkBjisbPcJ0W2HT0Z/d2cbz1JWB4NaIEZGmqvCJwlH2wbgkc7EV KCP4EQtLBDWlfFAwFZLnYXNaKN6JUOjI3BNxAYKBuBct0QMuec4B39U8yGlz5TE5 EYbq0sh9MCg0ChN2F1E66XG5DqFXAZiMY/Jmd+Xs61WgbBATJc/lYG5bk6vCYRxN 2lgJV0o7GyiM3IDfsN+t =VP4i -----END PGP SIGNATURE----- --Apple-Mail=_B8FDDFA2-C5A3-42FA-BDFE-CA0C72C1E383-- From Quittek@neclab.eu Wed Jan 29 15:42:23 2014 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFA7A1A03F9 for ; Wed, 29 Jan 2014 15:42:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.137 X-Spam-Level: X-Spam-Status: No, score=-3.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lJiF5HyARBYk for ; Wed, 29 Jan 2014 15:42:20 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 3BD201A03D6 for ; Wed, 29 Jan 2014 15:42:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id A3430106AC3; Thu, 30 Jan 2014 00:42:16 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vRQqtVw4xV1U; Thu, 30 Jan 2014 00:42:16 +0100 (CET) X-ENC: Last-Hop-TLS-encrypted X-ENC: Last-Hop-TLS-encrypted Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailer1.neclab.eu (Postfix) with ESMTPS id 8110C106AB5; Thu, 30 Jan 2014 00:42:01 +0100 (CET) Received: from DAPHNIS.office.hd ([169.254.2.144]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Thu, 30 Jan 2014 00:41:40 +0100 From: Juergen Quittek To: Thomas Nadeau , eman mailing list Thread-Topic: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib-13 Thread-Index: AQHPHDodmAOXF01vlk+Ral4ysbWZOpqcRqCw Date: Wed, 29 Jan 2014 23:41:39 +0000 Message-ID: <9AB93E4127C26F4BA7829DEFDCE5A6E868913FC9@DAPHNIS.office.hd> References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.0.214] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib-13 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 29 Jan 2014 23:42:24 -0000 Hi Tom, You are right. This is really comes as a surprise.=20 I have an objection. Please see my reasons below. 0. (just formal) You ask for changing the framework draft in an email that = has two drafts in the subject line, but not the framework draft. A clearer = indication of this email would have been particularly recommendable, since = you told us at the last meeting that you are not willing to accept further = change requests to this draft. 1. Having a device limited to a single domain membership is a limitation/fe= ature of Cisco's EnergyWise for which in all the long discussions we had in= past year never any technical reason was given (although it was asked for = multiple times). In the contrary, I gave use cases where it is REQUIRED to = have two or more domains. An obvious example is a highly reliable server th= at has dual power supply. Its two power supply lines SHOULD be in different= domains in order to be better protected from local power supply failures. = This server should be given means to report via the MIB that it is member o= f two domains. 2. The compromise we had was RECOMMENDING to use the same limitation as Ene= rgyWise has it even though we know other systems do not have that limitatio= ns and even though technical reason exists rather against the limitation th= an for it. The proposed change to MUST makes all other (potentially superio= r) approaches violating the standard. Why shall we do so without ANY techni= cal reason? What would be the reason for such a decision? 3. The suggestion I made does NOT require any modifications of existing SNM= P agents that implement one of the recent versions of the MIB modules in dr= aft-ietf-eman-energy-aware-mib. It also does not affect any code transmitti= ng information using the EMAN information model as specified in the framewo= rk. The domain information is still kept in a single string. It only gives = a little bit of freedom to how this string can be interpreted when processi= ng it, particularly when writing it to a management data base supporting ei= ther single or multiple domains per device. 4. To make the story even more surprising, the concept of a "domain" is not= defined in a very interoperable way. The framework does not give the conce= pt of a domain any more semantics than=20 "An Energy Management Domain can be any collection of Energy Objects in= a deployment."=20 How to structure domains is completely left to the operator. Why are we on = one hand so open with the semantics of a "domain" and on the other hand so = strict when it comes to the number of domain memberships an energy object m= ay have? 5. You say you request the change to keep the ball rolling. But you propose= the opposite: to make a step back to the already closed framework draft an= d open it again. The way to keep the ball rolling would be to just apply ch= anges to the still open documents we are currently discussing. Juergen > -----Original Message----- > From: Thomas Nadeau [mailto:tnadeau@lucidvision.com] > Sent: Dienstag, 28. Januar 2014 16:04 > To: Brad Schoening > Cc: Juergen Quittek; eman mailing list > Subject: Re: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mi= b- > 08 and draft-ietf-eman-energy-aware-mib-13 >=20 >=20 > Hi Brad/EMAN WG, >=20 > As both Nevil and I noted yesterday, we both consider that there is > sufficient consensus to have the Framework changed so that using a single > Energy Management Domain is written as a MUST in the documents. As chairs > we are directing the editors of the draft to please make this change so t= hat > the MIBs and the Framework will be aligned. >=20 > We both I understand that it is very, very late in the game to make this > change, but this needs to happen to keep the ball rolling forward for EMA= N > and all of the existing implementations. Under the circumstances, we als= o > understand that this might have taken people by surprise, and thus while = we > do not want to re-open the debate/discussion that happened around this > issue a while back now, we would still like to ask the WG if anyone on th= e > EMAN list has a strong objection to this change or how it should be made = to > the drafts. Please chime in ASAP. If we do not hear anything by Friday, J= anuary > 31, 2014 at 8AM EDT, we will proceed forward as directed. >=20 > --Tom >=20 >=20 > On Jan 28, 2014:12:52 AM, at 12:52 AM, Brad Schoening > wrote: >=20 > > > > > > I've updated the doc to address Juergen's 2nd point. But, is there > > consensus on MUST vs SHOULD for Entity MIB support? > > > > > > > > On 12/30/13 2:33 PM, "Juergen Quittek" wrote: > > > >> Dear all, > >> > >> Here are my last two comments for this WGLC. Both concerns the > >> conformance section of the ENERGY-OBJECT-MIB module in > >> draft-ietf-eman-energy-monitoring-mib-08: > >> > >> 1. I may have missed a point here: Why is the Entity MIB not > >> mandatory anymore to implement? It is just two additional objects, > >> since entPhysicalIndex from this MIB is needed anyway. Particularly, > >> we considered the UUID provided by this MIB essential for our framewor= k. > >> > >> 2. Why is the module compliance dependency on the Entity MIB repeated > >> in the DESCRIPTION clauses of all optional groups within a > >> MODULE-COMPLIANCE declaration? I think It is fully sufficient to have > >> it stated in the top DESCRIPTION clause of the MODULE-COMPLIANCE > >> declaration. Does it make any sense to repeat it for optional groups? > >> > >> Cheers, > >> Juergen > >> > >> > >>> -----Original Message----- > >>> From: eman [mailto:eman-bounces@ietf.org] On Behalf Of Thomas > Nadeau > >>> Sent: Montag, 16. Dezember 2013 16:56 > >>> To: eman mailing list > >>> Subject: [eman] WG Last Call for > >>> draft-ietf-eman-energy-monitoring-mib-08 > >>> and draft-ietf-eman-energy-aware-mib-13 > >>> > >>> > >>> As agreed at the last WG meeting, with the EMAN Framework > >>> completing its WG LC the chairs would like to initiate a WG LC on > >>> draft-ietf- > >>> eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib- > 13. > >>> The WG LC will end on Dec 30 at 8AM EDT. > >>> > >>> Thank you, > >>> > >>> Nevil and Tom > >>> > >> > >> _______________________________________________ > >> eman mailing list > >> eman@ietf.org > >> https://www.ietf.org/mailman/listinfo/eman > > > > _______________________________________________ > > eman mailing list > > eman@ietf.org > > https://www.ietf.org/mailman/listinfo/eman > > From karagian@cs.utwente.nl Wed Jan 29 22:31:31 2014 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED2531A03B1 for ; Wed, 29 Jan 2014 22:31:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D2T-D39dqSdD for ; Wed, 29 Jan 2014 22:31:26 -0800 (PST) Received: from out41-ams.mf.surf.net (out41-ams.mf.surf.net [145.0.1.41]) by ietfa.amsl.com (Postfix) with ESMTP id 6E1AB1A02F3 for ; Wed, 29 Jan 2014 22:31:26 -0800 (PST) Received: from EXEDGE02.ad.utwente.nl (exedge02.ad.utwente.nl [130.89.5.49]) by outgoing2-ams.mf.surf.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id s0U6VL0r017408; Thu, 30 Jan 2014 07:31:21 +0100 Received: from EXHUB02.ad.utwente.nl (130.89.4.229) by EXEDGE02.ad.utwente.nl (130.89.5.49) with Microsoft SMTP Server (TLS) id 14.2.328.9; Thu, 30 Jan 2014 07:31:21 +0100 Received: from EXMBX23.ad.utwente.nl ([169.254.3.41]) by EXHUB02.ad.utwente.nl ([130.89.4.229]) with mapi id 14.02.0328.009; Thu, 30 Jan 2014 07:31:21 +0100 From: To: Thread-Topic: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib-13 Thread-Index: AQHPHUvEgRJuGxPV9EuHqVzSGOSTU5qczlqZgAAA36E= Date: Thu, 30 Jan 2014 06:31:20 +0000 Message-ID: References: , <9AB93E4127C26F4BA7829DEFDCE5A6E868913FC9@DAPHNIS.office.hd> In-Reply-To: <9AB93E4127C26F4BA7829DEFDCE5A6E868913FC9@DAPHNIS.office.hd> Accept-Language: nl-NL, en-US Content-Language: nl-NL X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mimectl: Produced By Microsoft Exchange V14.2.247.1 x-originating-ip: [86.91.134.3] Content-Type: multipart/alternative; boundary="_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F41D7E6EXMBX23adutwent_" MIME-Version: 1.0 X-Bayes-Prob: 0.0001 (Score 0, tokens from: utwente-out:default, base:default, @@RPTN) X-CanIt-Geo: ip=130.89.5.49; country=NL; region=15; city=Enschede; latitude=52.2195; longitude=6.8912; http://maps.google.com/maps?q=52.2195,6.8912&z=6 X-CanItPRO-Stream: utwente-out:default (inherits from utwente:default, base:default) X-Canit-Stats-ID: 0vLk6vlCl - 9802fd1a9e47 - 20140130 (trained as not-spam) X-Scanned-By: CanIt (www . roaringpenguin . com) Cc: eman@ietf.org Subject: Re: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib-13 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 30 Jan 2014 06:31:31 -0000 --_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F41D7E6EXMBX23adutwent_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Tom, I agree with the objections mentioned by Juergen in the below email, and in= particular with the recommendation: "The way to keep the ball rolling would be to just apply changes to the sti= ll open documents we are currently discussing." Best regards, Georgios ________________________________ Van: eman [eman-bounces@ietf.org] namens Juergen Quittek [Quittek@neclab.eu= ] Verzonden: donderdag 30 januari 2014 0:41 To: Thomas Nadeau; eman mailing list Onderwerp: Re: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mi= b-08 and draft-ietf-eman-energy-aware-mib-13 Hi Tom, You are right. This is really comes as a surprise. I have an objection. Please see my reasons below. 0. (just formal) You ask for changing the framework draft in an email that = has two drafts in the subject line, but not the framework draft. A clearer = indication of this email would have been particularly recommendable, since = you told us at the last meeting that you are not willing to accept further = change requests to this draft. 1. Having a device limited to a single domain membership is a limitation/fe= ature of Cisco's EnergyWise for which in all the long discussions we had in= past year never any technical reason was given (although it was asked for = multiple times). In the contrary, I gave use cases where it is REQUIRED to = have two or more domains. An obvious example is a highly reliable server th= at has dual power supply. Its two power supply lines SHOULD be in different= domains in order to be better protected from local power supply failures. = This server should be given means to report via the MIB that it is member o= f two domains. 2. The compromise we had was RECOMMENDING to use the same limitation as Ene= rgyWise has it even though we know other systems do not have that limitatio= ns and even though technical reason exists rather against the limitation th= an for it. The proposed change to MUST makes all other (potentially superio= r) approaches violating the standard. Why shall we do so without ANY techni= cal reason? What would be the reason for such a decision? 3. The suggestion I made does NOT require any modifications of existing SNM= P agents that implement one of the recent versions of the MIB modules in dr= aft-ietf-eman-energy-aware-mib. It also does not affect any code transmitti= ng information using the EMAN information model as specified in the framewo= rk. The domain information is still kept in a single string. It only gives = a little bit of freedom to how this string can be interpreted when processi= ng it, particularly when writing it to a management data base supporting ei= ther single or multiple domains per device. 4. To make the story even more surprising, the concept of a "domain" is not= defined in a very interoperable way. The framework does not give the conce= pt of a domain any more semantics than "An Energy Management Domain can be any collection of Energy Objects in= a deployment." How to structure domains is completely left to the operator. Why are we on = one hand so open with the semantics of a "domain" and on the other hand so = strict when it comes to the number of domain memberships an energy object m= ay have? 5. You say you request the change to keep the ball rolling. But you propose= the opposite: to make a step back to the already closed framework draft an= d open it again. The way to keep the ball rolling would be to just apply ch= anges to the still open documents we are currently discussing. Juergen > -----Original Message----- > From: Thomas Nadeau [mailto:tnadeau@lucidvision.com] > Sent: Dienstag, 28. Januar 2014 16:04 > To: Brad Schoening > Cc: Juergen Quittek; eman mailing list > Subject: Re: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mi= b- > 08 and draft-ietf-eman-energy-aware-mib-13 > > > Hi Brad/EMAN WG, > > As both Nevil and I noted yesterday, we both consider that there i= s > sufficient consensus to have the Framework changed so that using a single > Energy Management Domain is written as a MUST in the documents. As chairs > we are directing the editors of the draft to please make this change so t= hat > the MIBs and the Framework will be aligned. > > We both I understand that it is very, very late in the game to mak= e this > change, but this needs to happen to keep the ball rolling forward for EMA= N > and all of the existing implementations. Under the circumstances, we als= o > understand that this might have taken people by surprise, and thus while = we > do not want to re-open the debate/discussion that happened around this > issue a while back now, we would still like to ask the WG if anyone on th= e > EMAN list has a strong objection to this change or how it should be made = to > the drafts. Please chime in ASAP. If we do not hear anything by Friday, J= anuary > 31, 2014 at 8AM EDT, we will proceed forward as directed. > > --Tom > > > On Jan 28, 2014:12:52 AM, at 12:52 AM, Brad Schoening > wrote: > > > > > > > I've updated the doc to address Juergen's 2nd point. But, is there > > consensus on MUST vs SHOULD for Entity MIB support? > > > > > > > > On 12/30/13 2:33 PM, "Juergen Quittek" wrote: > > > >> Dear all, > >> > >> Here are my last two comments for this WGLC. Both concerns the > >> conformance section of the ENERGY-OBJECT-MIB module in > >> draft-ietf-eman-energy-monitoring-mib-08: > >> > >> 1. I may have missed a point here: Why is the Entity MIB not > >> mandatory anymore to implement? It is just two additional objects, > >> since entPhysicalIndex from this MIB is needed anyway. Particularly, > >> we considered the UUID provided by this MIB essential for our framewor= k. > >> > >> 2. Why is the module compliance dependency on the Entity MIB repeated > >> in the DESCRIPTION clauses of all optional groups within a > >> MODULE-COMPLIANCE declaration? I think It is fully sufficient to have > >> it stated in the top DESCRIPTION clause of the MODULE-COMPLIANCE > >> declaration. Does it make any sense to repeat it for optional groups? > >> > >> Cheers, > >> Juergen > >> > >> > >>> -----Original Message----- > >>> From: eman [mailto:eman-bounces@ietf.org] On Behalf Of Thomas > Nadeau > >>> Sent: Montag, 16. Dezember 2013 16:56 > >>> To: eman mailing list > >>> Subject: [eman] WG Last Call for > >>> draft-ietf-eman-energy-monitoring-mib-08 > >>> and draft-ietf-eman-energy-aware-mib-13 > >>> > >>> > >>> As agreed at the last WG meeting, with the EMAN Framework > >>> completing its WG LC the chairs would like to initiate a WG LC on > >>> draft-ietf- > >>> eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib- > 13. > >>> The WG LC will end on Dec 30 at 8AM EDT. > >>> > >>> Thank you, > >>> > >>> Nevil and Tom > >>> > >> > >> _______________________________________________ > >> 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 --_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F41D7E6EXMBX23adutwent_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <5755D65389D88A4D83B257B884645386@exchange.utwente.nl> Content-Transfer-Encoding: quoted-printable

Hi Tom,

 

I agree with the objections mentioned by Juergen in the below email, and= in particular with the recommendation:

"The way to keep the ball rolling would be to just apply changes to= the still open documents we are currently discussing."

 

Best regards,

Georgios


 

 

Van: eman [eman-bounces@ietf.org] namens Juergen Quittek [Quitte= k@neclab.eu]
Verzonden: donderdag 30 januari 2014 0:41
To: Thomas Nadeau; eman mailing list
Onderwerp: Re: [eman] WG Last Call for draft-ietf-eman-energy-monito= ring-mib-08 and draft-ietf-eman-energy-aware-mib-13

Hi Tom,

You are right. This is really comes as a surprise.
I have an objection. Please see my reasons below.

0. (just formal) You ask for changing the framework draft in an email that = has two drafts in the subject line, but not the framework draft. A clearer = indication of this email would have been particularly recommendable, since = you told us at the last meeting that you are not willing to accept further change requests to this draft.<= br>
1. Having a device limited to a single domain membership is a limitation/fe= ature of Cisco's EnergyWise for which in all the long discussions we had in= past year never any technical reason was given (although it was asked for = multiple times). In the contrary, I gave use cases where it is REQUIRED to have two or more domains. An obvi= ous example is a highly reliable server that has dual power supply. Its two= power supply lines SHOULD be in different domains in order to be better pr= otected from local power supply failures. This server should be given means to report via the MIB that it = is member of two domains.

2. The compromise we had was RECOMMENDING to use the same limitation as Ene= rgyWise has it even though we know other systems do not have that limitatio= ns and even though technical reason exists rather against the limitation th= an for it. The proposed change to MUST makes all other (potentially superior) approaches violating the stand= ard. Why shall we do so without ANY technical reason? What would be the rea= son for such a decision?

3. The suggestion I made does NOT require any modifications of existing SNM= P agents that implement one of the recent versions of the MIB modules in dr= aft-ietf-eman-energy-aware-mib. It also does not affect any code transmitti= ng information using the EMAN information model as specified in the framework. The domain information is still kept = in a single string. It only gives a little bit of freedom to how this strin= g can be interpreted when processing it, particularly when writing it to a = management data base supporting either single or multiple domains per device.

4. To make the story even more surprising, the concept of a "domain&qu= ot; is not defined in a very interoperable way. The framework does not give= the concept of a domain any more semantics than
    "An Energy Management Domain can be any collection = of Energy Objects in a deployment."
How to structure domains is completely left to the operator. Why are we on = one hand so open with the semantics of a "domain" and on the othe= r hand so strict when it comes to the number of domain memberships an energ= y object may have?

5. You say you request the change to keep the ball rolling. But you propose= the opposite: to make a step back to the already closed framework draft an= d open it again. The way to keep the ball rolling would be to just apply ch= anges to the still open documents we are currently discussing.

    Juergen


> -----Original Message-----
> From: Thomas Nadeau [mailto:tnadeau@lucidvision.com]
> Sent: Dienstag, 28. Januar 2014 16:04
> To: Brad Schoening
> Cc: Juergen Quittek; eman mailing list
> Subject: Re: [eman] WG Last Call for draft-ietf-eman-energy-monitoring= -mib-
> 08 and draft-ietf-eman-energy-aware-mib-13
>
>
>        Hi Brad/EMAN WG,
>
>        As both Nevil and I noted ye= sterday, we both consider that there is
> sufficient consensus to have the Framework changed so that using a sin= gle
> Energy Management Domain is written as a MUST in the documents. As cha= irs
> we are directing the editors of the draft to please make this change s= o that
> the MIBs and the Framework will be aligned.
>
>        We both I understand that it= is very, very late in the game to make this
> change, but this needs to happen to keep the ball rolling forward for = EMAN
> and all of the existing implementations.  Under the circumstances= , we also
> understand that this might have taken people by surprise, and thus whi= le we
> do not want to re-open the debate/discussion that happened around this=
> issue a while back now, we would still like to ask the WG if anyone on= the
> EMAN list has a strong objection to this change or how it should be ma= de to
> the drafts. Please chime in ASAP. If we do not hear anything by Friday= , January
> 31, 2014 at 8AM EDT, we will proceed forward as directed.
>
>        --Tom
>
>
> On Jan 28, 2014:12:52 AM, at 12:52 AM, Brad Schoening
> <brads@coraid.com> wrote:
>
> >
> >
> > I've updated the doc to address Juergen's 2nd point.  But, i= s there
> > consensus on MUST vs SHOULD for Entity MIB support?
> >
> >
> >
> > On 12/30/13 2:33 PM, "Juergen Quittek" <Quittek@necl= ab.eu> wrote:
> >
> >> Dear all,
> >>
> >> Here are my last two comments for this WGLC. Both concerns th= e
> >> conformance section of the ENERGY-OBJECT-MIB module in
> >> draft-ietf-eman-energy-monitoring-mib-08:
> >>
> >> 1. I may have missed a point here: Why is the Entity MIB not<= br> > >> mandatory anymore to implement? It is just two additional obj= ects,
> >> since entPhysicalIndex from this MIB is needed anyway. Partic= ularly,
> >> we considered the UUID provided by this MIB essential for our= framework.
> >>
> >> 2. Why is the module compliance dependency on the Entity MIB = repeated
> >> in the DESCRIPTION clauses of all optional groups within a > >> MODULE-COMPLIANCE declaration? I think It is fully sufficient= to have
> >> it stated in the top DESCRIPTION clause of the MODULE-COMPLIA= NCE
> >> declaration. Does it make any sense to repeat it for optional= groups?
> >>
> >> Cheers,
> >>   Juergen
> >>
> >>
> >>> -----Original Message-----
> >>> From: eman [mailto:eman-bounces@ietf.org] On Behalf Of Thomas
> Nadeau
> >>> Sent: Montag, 16. Dezember 2013 16:56
> >>> To: eman mailing list
> >>> Subject: [eman] WG Last Call for
> >>> draft-ietf-eman-energy-monitoring-mib-08
> >>> and draft-ietf-eman-energy-aware-mib-13
> >>>
> >>>
> >>>    As agreed at the last WG meeting, with = the EMAN Framework
> >>> completing its WG LC the chairs would like to initiate a = WG LC on
> >>> draft-ietf-
> >>> eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-= aware-mib-
> 13.
> >>> The WG LC will end on Dec 30 at 8AM EDT.
> >>>
> >>>    Thank you,
> >>>
> >>>    Nevil and Tom
> >>>
> >>
> >> _______________________________________________
> >> 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
--_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F41D7E6EXMBX23adutwent_-- From joelja@bogus.com Thu Jan 30 08:09:43 2014 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EBC41A03E7 for ; Thu, 30 Jan 2014 08:09:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iuiRmA9z_Sv6 for ; Thu, 30 Jan 2014 08:09:40 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id B85541A03D4 for ; Thu, 30 Jan 2014 08:09:40 -0800 (PST) Received: from mb-aye.local (c-50-174-18-221.hsd1.ca.comcast.net [50.174.18.221]) (authenticated bits=0) by nagasaki.bogus.com (8.14.7/8.14.7) with ESMTP id s0UG9ZD6068663 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 30 Jan 2014 16:09:36 GMT (envelope-from joelja@bogus.com) Message-ID: <52EA793A.3030801@bogus.com> Date: Thu, 30 Jan 2014 08:09:30 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:27.0) Gecko/20100101 Thunderbird/27.0 MIME-Version: 1.0 To: Juergen Quittek , Thomas Nadeau , eman mailing list References: <9AB93E4127C26F4BA7829DEFDCE5A6E868913FC9@DAPHNIS.office.hd> In-Reply-To: <9AB93E4127C26F4BA7829DEFDCE5A6E868913FC9@DAPHNIS.office.hd> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jMeTpxvlwWoxV8IkRswsXrImJWO0KoH9n" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (nagasaki.bogus.com [147.28.0.81]); Thu, 30 Jan 2014 16:09:37 +0000 (UTC) Subject: Re: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib-13 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 30 Jan 2014 16:09:43 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --jMeTpxvlwWoxV8IkRswsXrImJWO0KoH9n Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 1/29/14, 3:41 PM, Juergen Quittek wrote: > Hi Tom, >=20 > You are right. This is really comes as a surprise. I have an > objection. Please see my reasons below. >=20 > 0. (just formal) You ask for changing the framework draft in an email > that has two drafts in the subject line, but not the framework draft. > A clearer indication of this email would have been particularly > recommendable, since you told us at the last meeting that you are not > willing to accept further change requests to this draft. Just as a quick observation. If we have a problem with the document then we should fix it. WG chairs have pretty wide latitude to determine when something is done with respect to the next stages, It is unlikely all things consider that it will emerge for IETF lc and IESG review without further editoral change/ so if we have problems that we anticipate having to address there, then perhaps we should do that now= =2E > 1. Having a device limited to a single domain membership is a > limitation/feature of Cisco's EnergyWise for which in all the long > discussions we had in past year never any technical reason was given > (although it was asked for multiple times). In the contrary, I gave > use cases where it is REQUIRED to have two or more domains. An > obvious example is a highly reliable server that has dual power > supply. Its two power supply lines SHOULD be in different domains in > order to be better protected from local power supply failures. This > server should be given means to report via the MIB that it is member > of two domains. It seems like the question is should the MUST reflect the current status of the mibs or not? if that's the question, then, is there some reason we should be tolerant of a discrepancy between the two? Latitude for implementers is fine and dandy (and may well be necessary) but if you can't express the element you've modeled in the monitoring that seems like an issue that needs to be reconciled either in the framework or in the mib. > 2. The compromise we had was RECOMMENDING to use the same limitation > as EnergyWise has it even though we know other systems do not have > that limitations and even though technical reason exists rather > against the limitation than for it. The proposed change to MUST makes > all other (potentially superior) approaches violating the standard. > Why shall we do so without ANY technical reason? What would be the > reason for such a decision? >=20 > 3. The suggestion I made does NOT require any modifications of > existing SNMP agents that implement one of the recent versions of the > MIB modules in draft-ietf-eman-energy-aware-mib. It also does not > affect any code transmitting information using the EMAN information > model as specified in the framework. The domain information is still > kept in a single string. It only gives a little bit of freedom to how > this string can be interpreted when processing it, particularly when > writing it to a management data base supporting either single or > multiple domains per device. >=20 > 4. To make the story even more surprising, the concept of a "domain" > is not defined in a very interoperable way. The framework does not > give the concept of a domain any more semantics than "An Energy > Management Domain can be any collection of Energy Objects in a > deployment." How to structure domains is completely left to the > operator. Why are we on one hand so open with the semantics of a > "domain" and on the other hand so strict when it comes to the number > of domain memberships an energy object may have? >=20 > 5. You say you request the change to keep the ball rolling. But you > propose the opposite: to make a step back to the already closed > framework draft and open it again. The way to keep the ball rolling > would be to just apply changes to the still open documents we are > currently discussing. >=20 > Juergen >=20 >=20 >> -----Original Message----- From: Thomas Nadeau >> [mailto:tnadeau@lucidvision.com] Sent: Dienstag, 28. Januar 2014 >> 16:04 To: Brad Schoening Cc: Juergen Quittek; eman mailing list=20 >> Subject: Re: [eman] WG Last Call for >> draft-ietf-eman-energy-monitoring-mib- 08 and >> draft-ietf-eman-energy-aware-mib-13 >>=20 >>=20 >> Hi Brad/EMAN WG, >>=20 >> As both Nevil and I noted yesterday, we both consider that there >> is sufficient consensus to have the Framework changed so that using >> a single Energy Management Domain is written as a MUST in the >> documents. As chairs we are directing the editors of the draft to >> please make this change so that the MIBs and the Framework will be >> aligned. >>=20 >> We both I understand that it is very, very late in the game to make >> this change, but this needs to happen to keep the ball rolling >> forward for EMAN and all of the existing implementations. Under >> the circumstances, we also understand that this might have taken >> people by surprise, and thus while we do not want to re-open the >> debate/discussion that happened around this issue a while back now, >> we would still like to ask the WG if anyone on the EMAN list has a >> strong objection to this change or how it should be made to the >> drafts. Please chime in ASAP. If we do not hear anything by Friday, >> January 31, 2014 at 8AM EDT, we will proceed forward as directed. >>=20 >> --Tom >>=20 >>=20 >> On Jan 28, 2014:12:52 AM, at 12:52 AM, Brad Schoening=20 >> wrote: >>=20 >>>=20 >>>=20 >>> I've updated the doc to address Juergen's 2nd point. But, is >>> there consensus on MUST vs SHOULD for Entity MIB support? >>>=20 >>>=20 >>>=20 >>> On 12/30/13 2:33 PM, "Juergen Quittek" >>> wrote: >>>=20 >>>> Dear all, >>>>=20 >>>> Here are my last two comments for this WGLC. Both concerns the=20 >>>> conformance section of the ENERGY-OBJECT-MIB module in=20 >>>> draft-ietf-eman-energy-monitoring-mib-08: >>>>=20 >>>> 1. I may have missed a point here: Why is the Entity MIB not=20 >>>> mandatory anymore to implement? It is just two additional >>>> objects, since entPhysicalIndex from this MIB is needed anyway. >>>> Particularly, we considered the UUID provided by this MIB >>>> essential for our framework. >>>>=20 >>>> 2. Why is the module compliance dependency on the Entity MIB >>>> repeated in the DESCRIPTION clauses of all optional groups >>>> within a MODULE-COMPLIANCE declaration? I think It is fully >>>> sufficient to have it stated in the top DESCRIPTION clause of >>>> the MODULE-COMPLIANCE declaration. Does it make any sense to >>>> repeat it for optional groups? >>>>=20 >>>> Cheers, Juergen >>>>=20 >>>>=20 >>>>> -----Original Message----- From: eman >>>>> [mailto:eman-bounces@ietf.org] On Behalf Of Thomas >> Nadeau >>>>> Sent: Montag, 16. Dezember 2013 16:56 To: eman mailing list=20 >>>>> Subject: [eman] WG Last Call for=20 >>>>> draft-ietf-eman-energy-monitoring-mib-08 and >>>>> draft-ietf-eman-energy-aware-mib-13 >>>>>=20 >>>>>=20 >>>>> As agreed at the last WG meeting, with the EMAN Framework=20 >>>>> completing its WG LC the chairs would like to initiate a WG >>>>> LC on draft-ietf- eman-energy-monitoring-mib-08 and >>>>> draft-ietf-eman-energy-aware-mib- >> 13. >>>>> The WG LC will end on Dec 30 at 8AM EDT. >>>>>=20 >>>>> Thank you, >>>>>=20 >>>>> Nevil and Tom >>>>>=20 >>>>=20 >>>> _______________________________________________ eman mailing >>>> list eman@ietf.org https://www.ietf.org/mailman/listinfo/eman >>>=20 >>> _______________________________________________ eman mailing >>> list eman@ietf.org https://www.ietf.org/mailman/listinfo/eman >>>=20 >=20 > _______________________________________________ eman mailing list=20 > eman@ietf.org https://www.ietf.org/mailman/listinfo/eman >=20 --jMeTpxvlwWoxV8IkRswsXrImJWO0KoH9n Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLqeToACgkQ8AA1q7Z/VrJ+mQCfflgnFNso71jEgFJLHXOguG9L 7i8AnjxHXRGDa7qvIyfNAT0iD8G3WYgB =nPuO -----END PGP SIGNATURE----- --jMeTpxvlwWoxV8IkRswsXrImJWO0KoH9n-- From brads@coraid.com Thu Jan 30 08:59:16 2014 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F4E91A045A for ; Thu, 30 Jan 2014 08:59:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a22vkBLcw6jk for ; Thu, 30 Jan 2014 08:59:14 -0800 (PST) Received: from server506.appriver.com (server506a.appriver.com [50.56.144.13]) by ietfa.amsl.com (Postfix) with ESMTP id BB0EB1A044C for ; Thu, 30 Jan 2014 08:59:13 -0800 (PST) X-Note-AR-ScanTimeLocal: 1/30/2014 10:59:10 AM X-Policy: GLOBAL - coraid.com X-Policy: GLOBAL - coraid.com X-Policy: GLOBAL - coraid.com X-Primary: brads@coraid.com X-Note: This Email was scanned by AppRiver SecureTide X-Virus-Scan: V- X-Note-SnifferID: 0 X-Note: TCH-CT/SI:0-78/SG:2 1/30/2014 10:58:23 AM X-GBUdb-Analysis: 0, 10.242.229.139, Ugly c=1 p=-0.974422 Source White X-Signature-Violations: 0-0-0-8438-c X-Note-419: 31.2014 ms. Fail:1 Chk:1347 of 1347 total X-Note: SCH-CT/SI:1-1347/SG:1 1/30/2014 10:59:04 AM 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: G327 G328 G329 G330 G334 G335 G445 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 148225574; Thu, 30 Jan 2014 10:59:10 -0600 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; Thu, 30 Jan 2014 10:59:09 -0600 From: Brad Schoening To: Thomas Nadeau Thread-Topic: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib-13 Thread-Index: AQHPG+0tpS6rr1XnlUCE8LfKL9ID95qaoPaAgAK+1YA= Date: Thu, 30 Jan 2014 16:59:09 +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: text/plain; charset="us-ascii" Content-ID: <52B582B738A220419F99F1D08F6F3498@fwd6.exghost.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: eman mailing list Subject: Re: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib-13 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 30 Jan 2014 16:59:16 -0000 Hi Thomas, Just wanted to clarify that I was inquiring about a separate issue from this one about single or multiple domains. That issue had to do with Entity-MIB support, and after further review, I've updated the MIB on that issue along the lines Juergen recommended. Regards, Brad On 1/28/14 7:03 AM, "Thomas Nadeau" wrote: > > Hi Brad/EMAN WG, > > As both Nevil and I noted yesterday, we both consider that there >is sufficient consensus to have the Framework changed so that using a >single=20 >Energy Management Domain is written as a MUST in the documents. As chairs >we=20 >are directing the editors of the draft to please make this change so that >the=20 >MIBs and the Framework will be aligned. > > We both I understand that it is very, very late in the game to >make this change, but this needs to happen to keep the ball rolling >forward=20 >for EMAN and all of the existing implementations. Under the >circumstances,=20 >we also understand that this might have taken people by surprise, and >thus=20 >while we do not want to re-open the debate/discussion that happened >around=20 >this issue a while back now, we would still like to ask the WG if anyone >on=20 >the EMAN list has a strong objection to this change or how it should be >made=20 >to the drafts. Please chime in ASAP. If we do not hear anything by >Friday,=20 >January 31, 2014 at 8AM EDT, we will proceed forward as directed. > > --Tom > > >On Jan 28, 2014:12:52 AM, at 12:52 AM, Brad Schoening >wrote: > >>=20 >>=20 >> I've updated the doc to address Juergen's 2nd point. But, is there >> consensus on MUST vs SHOULD for Entity MIB support? >>=20 >>=20 >>=20 >> On 12/30/13 2:33 PM, "Juergen Quittek" wrote: >>=20 >>> Dear all, >>>=20 >>> Here are my last two comments for this WGLC. Both concerns the >>> conformance section of the ENERGY-OBJECT-MIB module in >>> draft-ietf-eman-energy-monitoring-mib-08: >>>=20 >>> 1. I may have missed a point here: Why is the Entity MIB not mandatory >>> anymore to implement? It is just two additional objects, since >>> entPhysicalIndex from this MIB is needed anyway. Particularly, we >>> considered the UUID provided by this MIB essential for our framework. >>>=20 >>> 2. Why is the module compliance dependency on the Entity MIB repeated >>>in >>> the DESCRIPTION clauses of all optional groups within a >>>MODULE-COMPLIANCE >>> declaration? I think It is fully sufficient to have it stated in the >>>top >>> DESCRIPTION clause of the MODULE-COMPLIANCE declaration. Does it make >>>any >>> sense to repeat it for optional groups? >>>=20 >>> Cheers, >>> Juergen >>>=20 >>>=20 >>>> -----Original Message----- >>>> From: eman [mailto:eman-bounces@ietf.org] On Behalf Of Thomas Nadeau >>>> Sent: Montag, 16. Dezember 2013 16:56 >>>> To: eman mailing list >>>> Subject: [eman] WG Last Call for >>>> draft-ietf-eman-energy-monitoring-mib-08 >>>> and draft-ietf-eman-energy-aware-mib-13 >>>>=20 >>>>=20 >>>> As agreed at the last WG meeting, with the EMAN Framework >>>> completing its WG LC the chairs would like to initiate a WG LC on >>>> draft-ietf- >>>> eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib-13. >>>> The WG LC will end on Dec 30 at 8AM EDT. >>>>=20 >>>> Thank you, >>>>=20 >>>> Nevil and Tom >>>>=20 >>>=20 >>> _______________________________________________ >>> eman mailing list >>> eman@ietf.org >>> https://www.ietf.org/mailman/listinfo/eman >>=20 >> _______________________________________________ >> eman mailing list >> eman@ietf.org >> https://www.ietf.org/mailman/listinfo/eman >>=20 > From brads@coraid.com Thu Jan 30 09:42:12 2014 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A66E51A0438 for ; Thu, 30 Jan 2014 09:42:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kNE3Uc3fk8ox for ; Thu, 30 Jan 2014 09:42:11 -0800 (PST) Received: from server506.appriver.com (server506a.appriver.com [50.56.144.13]) by ietfa.amsl.com (Postfix) with ESMTP id 4F16D1A03F3 for ; Thu, 30 Jan 2014 09:42:11 -0800 (PST) X-Note-AR-ScanTimeLocal: 1/30/2014 11:42:07 AM X-Policy: GLOBAL - coraid.com X-Policy: GLOBAL - coraid.com X-Policy: GLOBAL - coraid.com X-Primary: brads@coraid.com X-Note: This Email was scanned by AppRiver SecureTide X-Virus-Scan: V- X-Note-SnifferID: 0 X-Note: TCH-CT/SI:0-128/SG:2 1/30/2014 11:41:24 AM X-GBUdb-Analysis: 0, 10.242.229.139, Ugly c=1 p=-0.973651 Source White X-Signature-Violations: 0-0-0-4957-c X-Note-419: 0 ms. Fail:0 Chk:1347 of 1347 total X-Note: SCH-CT/SI:0-1347/SG:1 1/30/2014 11:42:06 AM 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: G327 G328 G329 G330 G334 G335 G445 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 148244636; Thu, 30 Jan 2014 11:42:07 -0600 Received: from DAGN05C-E6.exg6.exghost.com ([169.254.3.11]) by HT04-E6.exg6.exghost.com ([50.56.144.22]) with mapi id 14.03.0158.001; Thu, 30 Jan 2014 11:42:07 -0600 From: Brad Schoening To: Juergen Quittek , Thomas Nadeau , eman mailing list Thread-Topic: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib-13 Thread-Index: AQHPG+0tpS6rr1XnlUCE8LfKL9ID95qaoPaAgAIjFICAAKfBAA== Date: Thu, 30 Jan 2014 17:42:06 +0000 Message-ID: In-Reply-To: <9AB93E4127C26F4BA7829DEFDCE5A6E868913FC9@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="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib-13 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 30 Jan 2014 17:42:12 -0000 Juergen, In your dual power supply example, I would think of these as three domains: supplyA, supplyB and supplyAB. The new domain supplyAB is a high-reliabliy domain. You don't mention what the power policy of this new combined domain is, but there could be several choices for supplyAB. Consider a more complicated example, you have a chassis with three power supply modules. There are at least three different policies that could be applied: - Power module redundancy - total power allowed is one less than the number of supply modules E.g., total power is 2 x. - Power module redundancy with throttling - total power allowed is equal to available power, but requires consumers to throttle down if one module fails. E.g., total power is between 2x and 3x. - Basic power w/o redundancy - total power allowed is equal to all available power with no redundancy. E.g., total power is 3x. Combining power domains likely always invokes a policy and thus in the eman model, creates a new domain. This approach is compatible with the chairs suggestion of MUST. Regards, Brad On 1/29/14 3:41 PM, "Juergen Quittek" wrote: >1. Having a device limited to a single domain membership is a >limitation/feature of Cisco's EnergyWise for which in all the long >discussions we had in past year never any technical reason was given >(although it was asked for multiple times). In the contrary, I gave use >cases where it is REQUIRED to have two or more domains. An obvious >example is a highly reliable server that has dual power supply. Its two >power supply lines SHOULD be in different domains in order to be better >protected from local power supply failures. This server should be given >means to report via the MIB that it is member of two domains. From tnadeau@lucidvision.com Thu Jan 30 10:55:39 2014 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 054D61A0435 for ; Thu, 30 Jan 2014 10:55:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y8iEWBU5VcFb for ; Thu, 30 Jan 2014 10:55:37 -0800 (PST) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id C142D1A0072 for ; Thu, 30 Jan 2014 10:55:36 -0800 (PST) Received: from [192.168.1.110] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 32D3A26D2609; Thu, 30 Jan 2014 13:55:33 -0500 (EST) Content-Type: multipart/signed; boundary="Apple-Mail=_A3E40184-F119-4110-9F52-036CD6ABEF73"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Thomas Nadeau In-Reply-To: Date: Thu, 30 Jan 2014 13:55:32 -0500 Message-Id: <8E986408-5C3F-4466-A58E-C4A473B7B066@lucidvision.com> References: To: Brad Schoening X-Mailer: Apple Mail (2.1827) Cc: eman mailing list Subject: Re: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib-13 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 30 Jan 2014 18:55:39 -0000 --Apple-Mail=_A3E40184-F119-4110-9F52-036CD6ABEF73 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Brad, On Jan 30, 2014:11:59 AM, at 11:59 AM, Brad Schoening = wrote: > Hi Thomas, >=20 > Just wanted to clarify that I was inquiring about a separate issue = from > this one about single or multiple domains. >=20 > That issue had to do with Entity-MIB support, and after further = review, > I've updated the MIB on that issue along the lines Juergen = recommended. OK cool. Apologies, but I thought you were asking about the = other issue. *) --Tom >=20 > Regards, >=20 > Brad >=20 >=20 >=20 > On 1/28/14 7:03 AM, "Thomas Nadeau" wrote: >=20 >>=20 >> Hi Brad/EMAN WG, >>=20 >> As both Nevil and I noted yesterday, we both consider that there >> is sufficient consensus to have the Framework changed so that using a >> single=20 >> Energy Management Domain is written as a MUST in the documents. As = chairs >> we=20 >> are directing the editors of the draft to please make this change so = that >> the=20 >> MIBs and the Framework will be aligned. >>=20 >> We both I understand that it is very, very late in the game to >> make this change, but this needs to happen to keep the ball rolling >> forward=20 >> for EMAN and all of the existing implementations. Under the >> circumstances,=20 >> we also understand that this might have taken people by surprise, and >> thus=20 >> while we do not want to re-open the debate/discussion that happened >> around=20 >> this issue a while back now, we would still like to ask the WG if = anyone >> on=20 >> the EMAN list has a strong objection to this change or how it should = be >> made=20 >> to the drafts. Please chime in ASAP. If we do not hear anything by >> Friday,=20 >> January 31, 2014 at 8AM EDT, we will proceed forward as directed. >>=20 >> --Tom >>=20 >>=20 >> On Jan 28, 2014:12:52 AM, at 12:52 AM, Brad Schoening = >> wrote: >>=20 >>>=20 >>>=20 >>> I've updated the doc to address Juergen's 2nd point. But, is there >>> consensus on MUST vs SHOULD for Entity MIB support? >>>=20 >>>=20 >>>=20 >>> On 12/30/13 2:33 PM, "Juergen Quittek" wrote: >>>=20 >>>> Dear all, >>>>=20 >>>> Here are my last two comments for this WGLC. Both concerns the >>>> conformance section of the ENERGY-OBJECT-MIB module in >>>> draft-ietf-eman-energy-monitoring-mib-08: >>>>=20 >>>> 1. I may have missed a point here: Why is the Entity MIB not = mandatory >>>> anymore to implement? It is just two additional objects, since >>>> entPhysicalIndex from this MIB is needed anyway. Particularly, we >>>> considered the UUID provided by this MIB essential for our = framework. >>>>=20 >>>> 2. Why is the module compliance dependency on the Entity MIB = repeated >>>> in >>>> the DESCRIPTION clauses of all optional groups within a >>>> MODULE-COMPLIANCE >>>> declaration? I think It is fully sufficient to have it stated in = the >>>> top >>>> DESCRIPTION clause of the MODULE-COMPLIANCE declaration. Does it = make >>>> any >>>> sense to repeat it for optional groups? >>>>=20 >>>> Cheers, >>>> Juergen >>>>=20 >>>>=20 >>>>> -----Original Message----- >>>>> From: eman [mailto:eman-bounces@ietf.org] On Behalf Of Thomas = Nadeau >>>>> Sent: Montag, 16. Dezember 2013 16:56 >>>>> To: eman mailing list >>>>> Subject: [eman] WG Last Call for >>>>> draft-ietf-eman-energy-monitoring-mib-08 >>>>> and draft-ietf-eman-energy-aware-mib-13 >>>>>=20 >>>>>=20 >>>>> As agreed at the last WG meeting, with the EMAN Framework >>>>> completing its WG LC the chairs would like to initiate a WG LC on >>>>> draft-ietf- >>>>> eman-energy-monitoring-mib-08 and = draft-ietf-eman-energy-aware-mib-13. >>>>> The WG LC will end on Dec 30 at 8AM EDT. >>>>>=20 >>>>> Thank you, >>>>>=20 >>>>> Nevil and Tom >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> eman mailing list >>>> eman@ietf.org >>>> https://www.ietf.org/mailman/listinfo/eman >>>=20 >>> _______________________________________________ >>> eman mailing list >>> eman@ietf.org >>> https://www.ietf.org/mailman/listinfo/eman >>>=20 >>=20 >=20 >=20 --Apple-Mail=_A3E40184-F119-4110-9F52-036CD6ABEF73 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 iQIcBAEBCgAGBQJS6qAkAAoJEPcO+I7eiUJZllQQAJu1QYEWfKACvmVTj8V6BLa4 UWbdBeC9S7qi/iOAMDLUldDVzqwo2qFINK6V85AgRd8OW+MvzzJVrrWRVyK2dkwh ovyFD+XqaeY9hU1RAZUzRI0UEds2R92rDe+Zj1e4vRz7nf91AzDeXi/qR8ZJtfLj PFgALLLDblPcK7YN4TotnAABq+tzeQCUpxsUoSoZSqSNsaZlQuSi2EWIeb0IQCdr S2fSmi49GM03xn2/7k6PSwkVd7Ie5jyVvL7zxTQPWotB4/0Ih2lqVyn/X8mfSeWP +gtbM/h5r61F22YQnX/bLnKZi0EoqhRx3JcwKdvcPt9FM3L/TPijHsluOzX85wks r/qfA2rSwu48Me0dS5F2czlkriIdzTOmHD/8D5EWfTkDpVa+EPF4PwLhKuGt+rO7 PQTGq4F82DUs3xTNTkYjaZDtxxjA5wZJXCiS+8+lzfpLzupLjwHOWV28Q9mkl8Jc RHLzIjChdFRSLbYlQsDVdIro+HRq3QCW2U3RDKekaOTCUettlggCxEW+vJgCAsrK hUPQtNOpDNdmYh/Ud/tcSbhB7F9k6viFBQyBErxsZA+znECHXslOifqSGredTVna 8qmChGBdpq5jPvxS2tmPngwTkQlbjAD2KVnoGCNs/jc/AZpSdo7tPWr2ABHi731s yLLhHbEhfMJlNp4eEHG5 =G0tR -----END PGP SIGNATURE----- --Apple-Mail=_A3E40184-F119-4110-9F52-036CD6ABEF73-- From jparello@cisco.com Thu Jan 30 11:40:47 2014 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BB9C1A0450 for ; Thu, 30 Jan 2014 11:40:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.036 X-Spam-Level: X-Spam-Status: No, score=-10.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DC47lconSaQQ for ; Thu, 30 Jan 2014 11:40:45 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) by ietfa.amsl.com (Postfix) with ESMTP id 3090F1A0296 for ; Thu, 30 Jan 2014 11:40:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3222; q=dns/txt; s=iport; t=1391110842; x=1392320442; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ylnfY2vivaVnEG9CYhk57Q3AEpGp89q3yIaReS1vGHU=; b=hczXds+TN4RdzSpOv1vUDMaUirBU8uIUOTvxLfyNI6312VbPVDdr/sTW UFPUL/1DZ+05sk/I5cSawug+PASBLHiUcgOG9cuOeCLFYHx9prmFJ0o+f 8kq3Oot7zv6p1NWhl0oRLlDAWpG/GktGjMzbDwKAAl17v0LbbP2/uhsZr Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AicFAIKp6lKtJXG+/2dsb2JhbABZgww4vXuBDBZ0giUBAQEDAQEBARodNAsFCwIBCBgeBQsnCyUCBA4FFIdpCA3MJRMEjioKGzMHAoMigRQElECDaJIfgW+BPoFo X-IronPort-AV: E=Sophos;i="4.95,751,1384300800"; d="scan'208";a="16790318" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by alln-iport-7.cisco.com with ESMTP; 30 Jan 2014 19:40:41 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id s0UJefPZ026968 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 30 Jan 2014 19:40:41 GMT Received: from xmb-aln-x04.cisco.com ([169.254.9.10]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0123.003; Thu, 30 Jan 2014 13:40:41 -0600 From: "John Parello (jparello)" To: Brad Schoening Thread-Topic: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib-13 Thread-Index: AQHPHUvDuHAOCWuIKk+6AFZjGPomhJqd7ywA//+8jJ0= Date: Thu, 30 Jan 2014 19:40:40 +0000 Message-ID: References: <9AB93E4127C26F4BA7829DEFDCE5A6E868913FC9@DAPHNIS.office.hd>, In-Reply-To: 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 mailing list Subject: Re: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib-13 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 30 Jan 2014 19:40:47 -0000 I agree with the chairs and our approach that the device/chassis is a scala= r domain not a vector. As agreed in the framework model. The complexity of power supplies (stack power for example) is handled by gr= ouping (keywords) not the management domain( i.e. community). MUST is the p= referred approach in practice. Our implementations and experience have found that no site ever used the do= main for this purpose but used groupings as Brad expressed below. Also the information model has been expressed as scalar not a vector for th= is field for some time and we have feedback and consensus on running code t= hat this is preferable. A change to SHOULD would mean we'd have to add attributes for size of field= /table to do a proper vector. That would mean soliciting feedback from imp= lementors that already are expecting / using this as a scalar. most are not= paying attention since wglc. Change the framework error not the modelling at this point please. Jp Sent from my iPad=20 (expect ridiculous spelling mistakes)=20 On Jan 30, 2014, at 9:42 AM, "Brad Schoening" wrote: > Juergen, >=20 > In your dual power supply example, I would think of these as three > domains: supplyA, supplyB and supplyAB. The new domain supplyAB is a > high-reliabliy domain. You don't mention what the power policy of this > new combined domain is, but there could be several choices for supplyAB. >=20 > Consider a more complicated example, you have a chassis with three power > supply modules. There are at least three different policies that could b= e > applied: >=20 > - Power module redundancy - total power allowed is one less than the > number of supply modules > E.g., total power is 2 x. >=20 > - Power module redundancy with throttling - total power allowed is equal > to available power, but > requires consumers to throttle down if one module fails. E.g., total > power is between 2x and 3x. >=20 > - Basic power w/o redundancy - total power allowed is equal to all > available power with no redundancy. E.g., total power is 3x. >=20 > Combining power domains likely always invokes a policy and thus in the > eman model, creates a new domain. >=20 > This approach is compatible with the chairs suggestion of MUST. >=20 > Regards, >=20 >=20 > Brad >=20 > On 1/29/14 3:41 PM, "Juergen Quittek" wrote: >=20 >> 1. Having a device limited to a single domain membership is a >> limitation/feature of Cisco's EnergyWise for which in all the long >> discussions we had in past year never any technical reason was given >> (although it was asked for multiple times). In the contrary, I gave use >> cases where it is REQUIRED to have two or more domains. An obvious >> example is a highly reliable server that has dual power supply. Its two >> power supply lines SHOULD be in different domains in order to be better >> protected from local power supply failures. This server should be given >> means to report via the MIB that it is member of two domains. >=20 > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman From tghose@juniper.net Thu Jan 30 11:43:38 2014 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ADF01A0456 for ; Thu, 30 Jan 2014 11:43:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KP57tuRsmdGC for ; Thu, 30 Jan 2014 11:43:35 -0800 (PST) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe004.messaging.microsoft.com [213.199.154.207]) by ietfa.amsl.com (Postfix) with ESMTP id EF8291A0450 for ; Thu, 30 Jan 2014 11:43:34 -0800 (PST) Received: from mail57-am1-R.bigfish.com (10.3.201.239) by AM1EHSOBE023.bigfish.com (10.3.207.145) with Microsoft SMTP Server id 14.1.225.22; Thu, 30 Jan 2014 19:43:31 +0000 Received: from mail57-am1 (localhost [127.0.0.1]) by mail57-am1-R.bigfish.com (Postfix) with ESMTP id 04D86800B5; Thu, 30 Jan 2014 19:43:31 +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: -24 X-BigFish: VPS-24(z579ehzbb2dI98dI9371I1432Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz1de098h1033IL8275bh8275dh1de097h186068hz2fh109h2a8h839h944hd25he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h2052h20b3h2216h22d0h2336h2438h2461h2487h24d7h2516h1155h) Received-SPF: pass (mail57-am1: 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:(10009001)(6009001)(479174003)(377454003)(51704005)(24454002)(189002)(199002)(76796001)(74876001)(80976001)(86362001)(77982001)(76786001)(92726001)(36756003)(74366001)(83322001)(59766001)(93516002)(93136001)(77096001)(19580405001)(83716003)(56816005)(90146001)(4396001)(94316002)(85306002)(54356001)(65816001)(74502001)(53806001)(74662001)(33656001)(47446002)(31966008)(19580395003)(81342001)(50986001)(87266001)(47976001)(92566001)(47736001)(49866001)(15975445006)(81686001)(82746002)(51856001)(56776001)(83072002)(80022001)(66066001)(74706001)(79102001)(85852003)(69226001)(63696002)(46102001)(54316002)(94946001)(2656002)(87936001)(76482001)(81816001)(81542001); DIR:OUT; SFP:1101; SCL:1; SRVR:BL2PR05MB195; H:BL2PR05MB195.namprd05.prod.outlook.com; CLIP:166.137.187.159; FPR:; InfoNoRecordsMX:1; A:1; LANG:en; Received: from mail57-am1 (localhost.localdomain [127.0.0.1]) by mail57-am1 (MessageSwitch) id 1391111008777387_26144; Thu, 30 Jan 2014 19:43:28 +0000 (UTC) Received: from AM1EHSMHS016.bigfish.com (unknown [10.3.201.253]) by mail57-am1.bigfish.com (Postfix) with ESMTP id B64953A004A; Thu, 30 Jan 2014 19:43:28 +0000 (UTC) Received: from BL2PRD0510HT002.namprd05.prod.outlook.com (157.56.240.101) by AM1EHSMHS016.bigfish.com (10.3.207.154) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 30 Jan 2014 19:43:28 +0000 Received: from BL2PR05MB195.namprd05.prod.outlook.com (10.242.198.149) by BL2PRD0510HT002.namprd05.prod.outlook.com (10.255.100.37) with Microsoft SMTP Server (TLS) id 14.16.395.1; Thu, 30 Jan 2014 19:43:25 +0000 Received: from BL2PR05MB195.namprd05.prod.outlook.com (10.242.198.149) by BL2PR05MB195.namprd05.prod.outlook.com (10.242.198.149) with Microsoft SMTP Server (TLS) id 15.0.859.15; Thu, 30 Jan 2014 19:43:23 +0000 Received: from BL2PR05MB195.namprd05.prod.outlook.com ([169.254.6.242]) by BL2PR05MB195.namprd05.prod.outlook.com ([169.254.6.242]) with mapi id 15.00.0859.020; Thu, 30 Jan 2014 19:43:23 +0000 From: Ted Ghose To: "John Parello (jparello)" Thread-Topic: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib-13 Thread-Index: AQHPHfOJ4jXv0ooRhUe8coBsWMxbhQ== Date: Thu, 30 Jan 2014 19:43:23 +0000 Message-ID: <4B082FB2-7EDC-4F5C-97B4-AD7027AF88DC@juniper.net> References: <9AB93E4127C26F4BA7829DEFDCE5A6E868913FC9@DAPHNIS.office.hd> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [166.137.187.159] x-forefront-prvs: 0107098B6C Content-Type: text/plain; charset="us-ascii" Content-ID: <761126B8A9C00E419D541F734FFEBFAB@junipernetworks.onmicrosoft.com> 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% Cc: eman mailing list Subject: Re: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib-13 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 30 Jan 2014 19:43:38 -0000 +1 -Ted- Sent from my iPhone > On Jan 30, 2014, at 11:40 AM, "John Parello (jparello)" wrote: >=20 > I agree with the chairs and our approach that the device/chassis is a sca= lar domain not a vector. As agreed in the framework model. >=20 > The complexity of power supplies (stack power for example) is handled by = grouping (keywords) not the management domain( i.e. community). MUST is the= preferred approach in practice. >=20 > Our implementations and experience have found that no site ever used the = domain for this purpose but used groupings as Brad expressed below. >=20 > Also the information model has been expressed as scalar not a vector for = this field for some time and we have feedback and consensus on running code= that this is preferable. >=20 > A change to SHOULD would mean we'd have to add attributes for size of fie= ld /table to do a proper vector. That would mean soliciting feedback from i= mplementors that already are expecting / using this as a scalar. most are n= ot paying attention since wglc. >=20 > Change the framework error not the modelling at this point please. >=20 > Jp >=20 >=20 > Sent from my iPad=20 > (expect ridiculous spelling mistakes)=20 >=20 >> On Jan 30, 2014, at 9:42 AM, "Brad Schoening" wrote: >>=20 >> Juergen, >>=20 >> In your dual power supply example, I would think of these as three >> domains: supplyA, supplyB and supplyAB. The new domain supplyAB is a >> high-reliabliy domain. You don't mention what the power policy of this >> new combined domain is, but there could be several choices for supplyAB. >>=20 >> Consider a more complicated example, you have a chassis with three power >> supply modules. There are at least three different policies that could = be >> applied: >>=20 >> - Power module redundancy - total power allowed is one less than the >> number of supply modules >> E.g., total power is 2 x. >>=20 >> - Power module redundancy with throttling - total power allowed is equal >> to available power, but >> requires consumers to throttle down if one module fails. E.g., total >> power is between 2x and 3x. >>=20 >> - Basic power w/o redundancy - total power allowed is equal to all >> available power with no redundancy. E.g., total power is 3x. >>=20 >> Combining power domains likely always invokes a policy and thus in the >> eman model, creates a new domain. >>=20 >> This approach is compatible with the chairs suggestion of MUST. >>=20 >> Regards, >>=20 >>=20 >> Brad >>=20 >>> On 1/29/14 3:41 PM, "Juergen Quittek" wrote: >>>=20 >>> 1. Having a device limited to a single domain membership is a >>> limitation/feature of Cisco's EnergyWise for which in all the long >>> discussions we had in past year never any technical reason was given >>> (although it was asked for multiple times). In the contrary, I gave use >>> cases where it is REQUIRED to have two or more domains. An obvious >>> example is a highly reliable server that has dual power supply. Its two >>> power supply lines SHOULD be in different domains in order to be better >>> protected from local power supply failures. This server should be given >>> means to report via the MIB that it is member of two domains. >>=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 From bnordman@lbl.gov Thu Jan 30 13:31:18 2014 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F33561A04CC for ; Thu, 30 Jan 2014 13:31:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.112 X-Spam-Level: X-Spam-Status: No, score=-4.112 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yI4z5g38jagZ for ; Thu, 30 Jan 2014 13:31:15 -0800 (PST) Received: from fe1.lbl.gov (fe1.lbl.gov [128.3.41.133]) by ietfa.amsl.com (Postfix) with ESMTP id 7A4941A046E for ; Thu, 30 Jan 2014 13:31:15 -0800 (PST) X-Ironport-SBRS: 4.8 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwDAJfD6lLRVdi2lGdsb2JhbABWA4JIfFe0UYhWgQQIFg4BAQEBBwsLCRIqgiYBAQQdVxULBAcwCyISAQUBHAYTiAUFn1StGheOND4XEYQnBIlJjl+BMo8AGCmDG4FfGw X-IronPort-AV: E=Sophos;i="4.95,752,1384329600"; d="scan'208";a="39112048" Received: from mail-qc0-f182.google.com ([209.85.216.182]) by fe1.lbl.gov with ESMTP; 30 Jan 2014 13:31:11 -0800 Received: by mail-qc0-f182.google.com with SMTP id c9so5943960qcz.27 for ; Thu, 30 Jan 2014 13:31:11 -0800 (PST) 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=fbvkMRNJtNV806DDkFwg63iBSc51Q/yBJD32mjWVvCs=; b=e++0LBc/Vgx27C4t9mqXXX6OlvQidptjQH7vPSxYZMH1bLPEnEBM73X18QrryfqVBP qK6q2+7UurDx9yadoi9UrlYKxG61dF0Cd9k2tHnD38GAyVnf050FxBYTxk8NG9JpFyI0 R0GCtCR2b2HzQv882CdhE0NSgSAnXY4XlBtRYt9iCJQLAfhxiBwIT+flpQLFreZg6OFv zpak+U6/JeiCofHev9o0k0XpATnUA6AySvksgAEgus/9jHrpHIVreJIgSIJQnpI2MXxX bcupo1QVTBlf7UMHb9MpfDg81klkeQefcdHZ2sXdFI1rBeK9I0YD0US9tSMA6dkMxnw+ gP4w== X-Gm-Message-State: ALoCoQkTcCH8SUQs9n/SkJNmYI37Iu1Rm6T6pSRn6QcbxujJv7/e/OrTzXxP4f9gbOYzMMu9QjdfWQ8imqbqhxIUBKK+n+kAX1vYNpwbOOSpBv+UASa2B82W3nNrFWbSexQueMZhvIzH X-Received: by 10.229.7.133 with SMTP id d5mr25878598qcd.10.1391117471547; Thu, 30 Jan 2014 13:31:11 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.229.7.133 with SMTP id d5mr25878581qcd.10.1391117471374; Thu, 30 Jan 2014 13:31:11 -0800 (PST) Received: by 10.140.29.229 with HTTP; Thu, 30 Jan 2014 13:31:11 -0800 (PST) In-Reply-To: <4B082FB2-7EDC-4F5C-97B4-AD7027AF88DC@juniper.net> References: <9AB93E4127C26F4BA7829DEFDCE5A6E868913FC9@DAPHNIS.office.hd> <4B082FB2-7EDC-4F5C-97B4-AD7027AF88DC@juniper.net> Date: Thu, 30 Jan 2014 13:31:11 -0800 Message-ID: From: Bruce Nordman To: eman mailing list Content-Type: multipart/alternative; boundary=001a1135ec94b8f44604f136c6c0 Subject: Re: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib-13 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 30 Jan 2014 21:31:18 -0000 --001a1135ec94b8f44604f136c6c0 Content-Type: text/plain; charset=ISO-8859-1 For the Domain issue, I have always believed that the Framework draft did not define the concept well. Since it is ambiguous in the Framework, it is not surprising that we are running into problems with it in later stages (the MIBs for example). The current Framework states (6.3.6): An Energy Management Domain can be any collection of Energy Objects in a deployment, but it is recommended to map 1:1 with a metered or sub-metered portion of the site. If one uses domain in the recommended fashion, then a device that receives power from two sources (each sub-metered) is definitely in two different domains. If one uses it differently, as is permitted, then many reasonable and useful usages require more than one domain. Another way to think about this is that it was a flawed idea in the first place that a device is in a domain at all. It is the power interface (or interfaces, for devices which receive supply from more than one) that is in the domain, not the device itself. An interface is more clearly in one domain. Different types of entities (devices, components, power interfaces) have different types of data available, so having domain only in the PI is quite reasonable. Thus, the correct answer to me for domain for a device is either zero or multiple. To recommend one as a compromise seeks OK. For a PI, only a single domain is needed. I second Juergen's line of reasoning that it is quite unnecessary and not justified to make the framework change to single at this time. Thanks, --Bruce -- *Bruce Nordman* Lawrence Berkeley National Laboratory *nordman.lbl.gov * BNordman@LBL.gov 510-486-7089 m: 510-501-7943 --001a1135ec94b8f44604f136c6c0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
For the Domain issue, I have always believed that the Fram= ework draft
did not define the concept well.=A0 Since it is ambiguous in= the Framework,
it is not surprising that we are running into problems w= ith it in later
stages (the MIBs for example).

The current Framework states (6.3.6):=

=A0=A0 An Energy Management Domain can be any collection of Energy<= br>=A0=A0 Objects in a deployment, but it is recommended to map 1:1
=A0= =A0 with a metered or sub-metered portion of the site.

If one uses domain in the recommended fashion, then a device that recei= ves
power from two sources (each sub-metered) is definitely in two diffe= rent
domains.
If one uses it differently, as is permitted, then many = reasonable
and useful usages require more than one domain.

Another way to think= about this is that it was a flawed idea in
the first place that a devic= e is in a domain at all.=A0 It is the
power interface (or interfaces, fo= r devices which receive supply
from more than one) that is in the domain, not the device itself.
An int= erface is more clearly in one domain.=A0 Different types of
entities (de= vices, components, power interfaces) have different
types of data availa= ble, so having domain only in the PI is quite
reasonable.

Thus, the correct answer to me for domain for a device i= s either
zero or multiple.=A0 To recommend one as a compromise seeks OK.=
For a PI, only a single domain is needed.

I second Juergen's= line of reasoning that it is quite unnecessary
and not justified to make the framework change to single at this time.
<= br>Thanks,

--Bruce

--
Bruce Nordman
= Lawrence Berkeley National Laboratory
nordman.lbl.gov
BNordman@LBL.gov
510-4= 86-7089
m: 510-501-7943
--001a1135ec94b8f44604f136c6c0-- From brads@coraid.com Thu Jan 30 14:08:03 2014 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2751F1A04DD for ; Thu, 30 Jan 2014 14:08:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JTQRi5qSCodl for ; Thu, 30 Jan 2014 14:07:59 -0800 (PST) Received: from server506.appriver.com (server506i.appriver.com [50.56.144.147]) by ietfa.amsl.com (Postfix) with ESMTP id AFEB91A04DA for ; Thu, 30 Jan 2014 14:07:59 -0800 (PST) X-Note-AR-ScanTimeLocal: 1/30/2014 4:07:55 PM 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 1/30/2014 4:06:57 PM X-GBUdb-Analysis: 0, 10.242.229.139, Ugly c=1 p=-0.989161 Source White X-Signature-Violations: 0-0-0-13092-c X-Note-419: 15.6003 ms. Fail:0 Chk:1347 of 1347 total X-Note: SCH-CT/SI:0-1347/SG:1 1/30/2014 4:07:41 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: G327 G328 G329 G330 G334 G335 G445 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 50325782; Thu, 30 Jan 2014 16:07:55 -0600 Received: from DAGN05C-E6.exg6.exghost.com ([169.254.3.11]) by HT04-E6.exg6.exghost.com ([50.56.144.22]) with mapi id 14.03.0158.001; Thu, 30 Jan 2014 16:07:55 -0600 From: Brad Schoening To: Bruce Nordman , eman mailing list Thread-Topic: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib-13 Thread-Index: AQHPG+0tpS6rr1XnlUCE8LfKL9ID95qaoPaAgAIjFICAAKfBAIAApz8AgAAAwoCAAB4fgP//hCMA Date: Thu, 30 Jan 2014 22:07:54 +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_CF100C4111207Abradscoraidcom_" MIME-Version: 1.0 Subject: Re: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib-13 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 30 Jan 2014 22:08:03 -0000 --_000_CF100C4111207Abradscoraidcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable "If one uses domain in the recommended fashion, then a device that receives power from two sources (each sub-metered) is definitely in two different domains." Or a new domain, which combines the two and has its own power policy. In w= hich case, a single domain suits our model quite well. Regards, Brad From: Bruce Nordman > Date: Thu, 30 Jan 2014 13:31:11 -0800 To: eman mailing list > Subject: Re: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib-= 08 and draft-ietf-eman-energy-aware-mib-13 For the Domain issue, I have always believed that the Framework draft did not define the concept well. Since it is ambiguous in the Framework, it is not surprising that we are running into problems with it in later stages (the MIBs for example). The current Framework states (6.3.6): An Energy Management Domain can be any collection of Energy Objects in a deployment, but it is recommended to map 1:1 with a metered or sub-metered portion of the site. If one uses domain in the recommended fashion, then a device that receives power from two sources (each sub-metered) is definitely in two different domains. If one uses it differently, as is permitted, then many reasonable and useful usages require more than one domain. Another way to think about this is that it was a flawed idea in the first place that a device is in a domain at all. It is the power interface (or interfaces, for devices which receive supply from more than one) that is in the domain, not the device itself. An interface is more clearly in one domain. Different types of entities (devices, components, power interfaces) have different types of data available, so having domain only in the PI is quite reasonable. Thus, the correct answer to me for domain for a device is either zero or multiple. To recommend one as a compromise seeks OK. For a PI, only a single domain is needed. I second Juergen's line of reasoning that it is quite unnecessary and not justified to make the framework change to single at this time. Thanks, --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 --_000_CF100C4111207Abradscoraidcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <3629CD40E812DB488C1BB3318E0FCCC7@fwd6.exghost.com> Content-Transfer-Encoding: quoted-printable
"= If one uses domain in the recommended fashion, then a device that receives<= /div> power from = two sources (each sub-metered) is definitely in two different
domain= s."

Or a new domain, which combines the two and has its own power policy. =  In which case, a single domain suits our model quite well.

Regards,

Brad

From: Bruce Nordman <bnordman@lbl.gov>
Date: Thu, 30 Jan 2014 13:31:11 -08= 00
To: eman mailing list <eman@ietf.org>
Subject: Re: [eman] WG Last Call fo= r draft-ietf-eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware= -mib-13

For the Domain issue, I have always believed that the Fram= ework draft
did not define the concept well.  Since it is ambiguous in the Framewo= rk,
it is not surprising that we are running into problems with it in later
stages (the MIBs for example).

The current Framework states (6.3.6):

   An Energy Management Domain can be any collection of Energy    Objects in a deployment, but it is recommended to map 1:1
   with a metered or sub-metered portion of the site.

If one uses domain in the recommended fashion, then a device that receives<= br> power from two sources (each sub-metered) is definitely in two different domains.
If one uses it differently, as is permitted, then many reasonable
and useful usages require more than one domain.

Another way to think about this is that it was a flawed idea in
the first place that a device is in a domain at all.  It is the
power interface (or interfaces, for devices which receive supply
from more than one) that is in the domain, not the device itself.
An interface is more clearly in one domain.  Different types of
entities (devices, components, power interfaces) have different
types of data available, so having domain only in the PI is quite
reasonable.

Thus, the correct answer to me for domain for a device is either
zero or multiple.  To recommend one as a compromise seeks OK.
For a PI, only a single domain is needed.

I second Juergen's line of reasoning that it is quite unnecessary
and not justified to make the framework change to single at this time.

Thanks,

--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 ht= tps://www.ietf.org/mailman/listinfo/eman --_000_CF100C4111207Abradscoraidcom_-- From jparello@cisco.com Thu Jan 30 21:48:55 2014 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96E2C1A0551 for ; Thu, 30 Jan 2014 21:48:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.035 X-Spam-Level: X-Spam-Status: No, score=-15.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kbAkxsFI3LBU for ; Thu, 30 Jan 2014 21:48:51 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 4EF6D1A0543 for ; Thu, 30 Jan 2014 21:48:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=27869; q=dns/txt; s=iport; t=1391147328; x=1392356928; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ERbX5c8AUoAGjm1aeDA5WQvNhmxZFLbjSMJ+9uabCPY=; b=mLJ5nqtCzYWfa8h3sLCfAorqdLMrsGmex0hecR7jJUYpKs+hB3Mq0MNs 97CIQsWBrXHSQYBDYwqCKTeExDJphsaBXVbeDN++nqN3gOTZNQ9AOfFZH RSCX/HC315lyKCCzdsIY1YwGGwoaYwSusWZNbBKYYhUCBEt+PxJaqb3Oa U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkgHANE461KtJXG+/2dsb2JhbABZgkpEOLRCiFOBDBYBdIN9AQEBBAEBARpRCwwEAgEIEQQBASEDBAcnCxQJCAIEDgWIBA3GVxeOMAoHAQIjJwQHAgSDHYETBJQzg2OBMJBkgW2BPoFoCRc X-IronPort-AV: E=Sophos;i="4.95,755,1384300800"; d="scan'208,217";a="297916640" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-9.cisco.com with ESMTP; 31 Jan 2014 05:48:46 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id s0V5mk8Q010723 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 31 Jan 2014 05:48:46 GMT Received: from xmb-aln-x04.cisco.com ([169.254.9.10]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0123.003; Thu, 30 Jan 2014 23:48:45 -0600 From: "John Parello (jparello)" To: Juergen Quittek Thread-Topic: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib-13 Thread-Index: AQHPHUvDuHAOCWuIKk+6AFZjGPomhJqeVZtE Date: Fri, 31 Jan 2014 05:48:43 +0000 Message-ID: References: , <9AB93E4127C26F4BA7829DEFDCE5A6E868913FC9@DAPHNIS.office.hd> In-Reply-To: <9AB93E4127C26F4BA7829DEFDCE5A6E868913FC9@DAPHNIS.office.hd> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_A0D9B6A8E8734668B3C4B2AC294B4FE0ciscocom_" MIME-Version: 1.0 Cc: eman mailing list Subject: Re: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib-13 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 31 Jan 2014 05:48:55 -0000 --_000_A0D9B6A8E8734668B3C4B2AC294B4FE0ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi JQ, Sorry I'm not seeing how point 1 is not covered. The domain attribute is on= an EnergyObject. Modeled as in case Case 3 of section 8.1 http://tools.ietf.org/html/draft-ietf-eman-framework-14#section-8.1 DeviceX.domain=3Dfoo DeviceX.PI1.domain=3Dbar DevixeX.PI2.domain=3Dbin Are you asking for a single power inlet to be required in two domains? Lets fix the typo in the framework and move on please. Jp Sent from my iPad (expect ridiculous spelling mistakes) On Jan 30, 2014, at 12:42 AM, "Juergen Quittek" > wrote: Hi Tom, You are right. This is really comes as a surprise. I have an objection. Please see my reasons below. 0. (just formal) You ask for changing the framework draft in an email that = has two drafts in the subject line, but not the framework draft. A clearer = indication of this email would have been particularly recommendable, since = you told us at the last meeting that you are not willing to accept further = change requests to this draft. 1. Having a device limited to a single domain membership is a limitation/fe= ature of Cisco's EnergyWise for which in all the long discussions we had in= past year never any technical reason was given (although it was asked for = multiple times). In the contrary, I gave use cases where it is REQUIRED to = have two or more domains. An obvious example is a highly reliable server th= at has dual power supply. Its two power supply lines SHOULD be in different= domains in order to be better protected from local power supply failures. = This server should be given means to report via the MIB that it is member o= f two domains. 2. The compromise we had was RECOMMENDING to use the same limitation as Ene= rgyWise has it even though we know other systems do not have that limitatio= ns and even though technical reason exists rather against the limitation th= an for it. The proposed change to MUST makes all other (potentially superio= r) approaches violating the standard. Why shall we do so without ANY techni= cal reason? What would be the reason for such a decision? 3. The suggestion I made does NOT require any modifications of existing SNM= P agents that implement one of the recent versions of the MIB modules in dr= aft-ietf-eman-energy-aware-mib. It also does not affect any code transmitti= ng information using the EMAN information model as specified in the framewo= rk. The domain information is still kept in a single string. It only gives = a little bit of freedom to how this string can be interpreted when processi= ng it, particularly when writing it to a management data base supporting ei= ther single or multiple domains per device. 4. To make the story even more surprising, the concept of a "domain" is not= defined in a very interoperable way. The framework does not give the conce= pt of a domain any more semantics than "An Energy Management Domain can be any collection of Energy Objects in = a deployment." How to structure domains is completely left to the operator. Why are we on = one hand so open with the semantics of a "domain" and on the other hand so = strict when it comes to the number of domain memberships an energy object m= ay have? 5. You say you request the change to keep the ball rolling. But you propose= the opposite: to make a step back to the already closed framework draft an= d open it again. The way to keep the ball rolling would be to just apply ch= anges to the still open documents we are currently discussing. Juergen -----Original Message----- From: Thomas Nadeau [mailto:tnadeau@lucidvision.com] Sent: Dienstag, 28. Januar 2014 16:04 To: Brad Schoening Cc: Juergen Quittek; eman mailing list Subject: Re: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib- 08 and draft-ietf-eman-energy-aware-mib-13 Hi Brad/EMAN WG, As both Nevil and I noted yesterday, we both consider that there is sufficient consensus to have the Framework changed so that using a single Energy Management Domain is written as a MUST in the documents. As chairs we are directing the editors of the draft to please make this change so tha= t the MIBs and the Framework will be aligned. We both I understand that it is very, very late in the game to make this change, but this needs to happen to keep the ball rolling forward for EMAN and all of the existing implementations. Under the circumstances, we also understand that this might have taken people by surprise, and thus while we do not want to re-open the debate/discussion that happened around this issue a while back now, we would still like to ask the WG if anyone on the EMAN list has a strong objection to this change or how it should be made to the drafts. Please chime in ASAP. If we do not hear anything by Friday, Jan= uary 31, 2014 at 8AM EDT, we will proceed forward as directed. --Tom On Jan 28, 2014:12:52 AM, at 12:52 AM, Brad Schoening > wrote: I've updated the doc to address Juergen's 2nd point. But, is there consensus on MUST vs SHOULD for Entity MIB support? On 12/30/13 2:33 PM, "Juergen Quittek" > wrote: Dear all, Here are my last two comments for this WGLC. Both concerns the conformance section of the ENERGY-OBJECT-MIB module in draft-ietf-eman-energy-monitoring-mib-08: 1. I may have missed a point here: Why is the Entity MIB not mandatory anymore to implement? It is just two additional objects, since entPhysicalIndex from this MIB is needed anyway. Particularly, we considered the UUID provided by this MIB essential for our framework. 2. Why is the module compliance dependency on the Entity MIB repeated in the DESCRIPTION clauses of all optional groups within a MODULE-COMPLIANCE declaration? I think It is fully sufficient to have it stated in the top DESCRIPTION clause of the MODULE-COMPLIANCE declaration. Does it make any sense to repeat it for optional groups? Cheers, Juergen -----Original Message----- From: eman [mailto:eman-bounces@ietf.org] On Behalf Of Thomas Nadeau Sent: Montag, 16. Dezember 2013 16:56 To: eman mailing list Subject: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib-13 As agreed at the last WG meeting, with the EMAN Framework completing its WG LC the chairs would like to initiate a WG LC on draft-ietf- eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib- 13. The WG LC will end on Dec 30 at 8AM EDT. Thank you, Nevil and Tom _______________________________________________ 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 --_000_A0D9B6A8E8734668B3C4B2AC294B4FE0ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi JQ,

Sorry I'm not seeing how point 1 is not covered. The domain attribute = is on an EnergyObject.

Modeled as in case Case 3 of section 8.1

DeviceX.domain=3Dfoo
DeviceX.PI1.domain=3Dbar
DevixeX.PI2.domain=3Dbin

Are you asking for a single power inlet to be required in two domains?=  

Lets fix the typo in the framework and move on please.
Jp



Sent from my iPad 
(expect ridiculous spelling mistakes) 

On Jan 30, 2014, at 12:42 AM, "Juergen Quittek" <Quittek@neclab.eu> wrote:

Hi Tom,

You are right. This is really comes as a surprise.
I have an objection. Please see my reasons below.

0. (just formal) You ask for changing the framework draft in an email= that has two drafts in the subject line, but not the framework draft. A cl= earer indication of this email would have been particularly recommendable, = since you told us at the last meeting that you are not willing to accept further change requests to this draft.<= /span>

1. Having a device limited to a single domain membership is a limitat= ion/feature of Cisco's EnergyWise for which in all the long discussions we = had in past year never any technical reason was given (although it was aske= d for multiple times). In the contrary, I gave use cases where it is REQUIRED to have two or more domains. An obvi= ous example is a highly reliable server that has dual power supply. Its two= power supply lines SHOULD be in different domains in order to be better pr= otected from local power supply failures. This server should be given means to report via the MIB that it = is member of two domains.

2. The compromise we had was RECOMMENDING to use the same limitation = as EnergyWise has it even though we know other systems do not have that lim= itations and even though technical reason exists rather against the limitat= ion than for it. The proposed change to MUST makes all other (potentially superior) approaches violating the st= andard. Why shall we do so without ANY technical reason? What would be the = reason for such a decision?

3. The suggestion I made does NOT require any modifications of existi= ng SNMP agents that implement one of the recent versions of the MIB modules= in draft-ietf-eman-energy-aware-mib. It also does not affect any code tran= smitting information using the EMAN information model as specified in the framework. The domain information is= still kept in a single string. It only gives a little bit of freedom to ho= w this string can be interpreted when processing it, particularly when writ= ing it to a management data base supporting either single or multiple domains per device.

4. To make the story even more surprising, the concept of a "dom= ain" is not defined in a very interoperable way. The framework does no= t give the concept of a domain any more semantics than
   "An Energy Management Domain can be any collec= tion of Energy Objects in a deployment."
How to structure domains is completely left to the operator. Why are = we on one hand so open with the semantics of a "domain" and on th= e other hand so strict when it comes to the number of domain memberships an= energy object may have?

5. You say you request the change to keep the ball rolling. But you p= ropose the opposite: to make a step back to the already closed framework dr= aft and open it again. The way to keep the ball rolling would be to just ap= ply changes to the still open documents we are currently discussing.

   Juergen


-----Original Message-----
From: Thomas Nadeau [mailto:tnadeau@lucidvision.com]
Sent: Dienstag, 28. Januar 2014 16:04
To: Brad Schoening
Cc: Juergen Quittek; eman mailing list
Subject: Re: [eman] WG Last Call for draft-= ietf-eman-energy-monitoring-mib-
08 and draft-ietf-eman-energy-aware-mib-13<= /span>


   Hi Brad/EMAN WG,

   As both Nevil and I noted yest= erday, we both consider that there is
sufficient consensus to have the Framework = changed so that using a single
Energy Management Domain is written as a MU= ST in the documents. As chairs
we are directing the editors of the draft t= o please make this change so that
the MIBs and the Framework will be aligned.=

   We both I understand that it i= s very, very late in the game to make this
change, but this needs to happen to keep th= e ball rolling forward for EMAN
and all of the existing implementations. &n= bsp;Under the circumstances, we also
understand that this might have taken peopl= e by surprise, and thus while we
do not want to re-open the debate/discussio= n that happened around this
issue a while back now, we would still like= to ask the WG if anyone on the
EMAN list has a strong objection to this ch= ange or how it should be made to
the drafts. Please chime in ASAP. If we do = not hear anything by Friday, January
31, 2014 at 8AM EDT, we will proceed forwar= d as directed.

   --Tom


On Jan 28, 2014:12:52 AM, at 12:52 AM, Brad= Schoening
<bra= ds@coraid.com> wrote:



I've updated the doc to address Juergen's 2= nd point.  But, is there
consensus on MUST vs SHOULD for Entity MIB = support?



On 12/30/13 2:33 PM, "Juergen Quittek&= quot; <Quittek@neclab.eu> wr= ote:

Dear all,

Here are my last two comments for this WGLC= . Both concerns the
conformance section of the ENERGY-OBJECT-MI= B module in
draft-ietf-eman-energy-monitoring-mib-08:

1. I may have missed a point here: Why is t= he Entity MIB not
mandatory anymore to implement? It is just = two additional objects,
since entPhysicalIndex from this MIB is nee= ded anyway. Particularly,
we considered the UUID provided by this MIB= essential for our framework.

2. Why is the module compliance dependency = on the Entity MIB repeated
in the DESCRIPTION clauses of all optional = groups within a
MODULE-COMPLIANCE declaration? I think It i= s fully sufficient to have
it stated in the top DESCRIPTION clause of = the MODULE-COMPLIANCE
declaration. Does it make any sense to repe= at it for optional groups?

Cheers,
 Juergen


-----Original Message-----
From: eman [mailto:eman-bounces@ietf.org] On Behalf Of Thomas
Nadeau
Sent: Montag, 16. Dezember 2013 16:56
To: eman mailing list
Subject: [eman] WG Last Call for
draft-ietf-eman-energy-monitoring-mib-08
and draft-ietf-eman-energy-aware-mib-13


   As agreed at the last WG meeti= ng, with the EMAN Framework
completing its WG LC the chairs would like = to initiate a WG LC on
draft-ietf-
eman-energy-monitoring-mib-08 and draft-iet= f-eman-energy-aware-mib-
13.
The WG LC will end on Dec 30 at 8AM EDT.

   Thank you,

   Nevil and Tom


___________________________________________= ____
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.ie= tf.org/mailman/listinfo/eman
--_000_A0D9B6A8E8734668B3C4B2AC294B4FE0ciscocom_-- From Thomas.Dietz@neclab.eu Fri Jan 31 00:16:22 2014 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B7CD1A056C for ; Fri, 31 Jan 2014 00:16:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.136 X-Spam-Level: X-Spam-Status: No, score=-3.136 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wZPp52T-f2xF for ; Fri, 31 Jan 2014 00:16:18 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 8DA3E1A056B for ; Fri, 31 Jan 2014 00:16:17 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 8718D106ADB; Fri, 31 Jan 2014 09:16:13 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wtgy8mDOtge4; Fri, 31 Jan 2014 09:16:13 +0100 (CET) X-ENC: Last-Hop-TLS-encrypted X-ENC: Last-Hop-TLS-encrypted Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailer1.neclab.eu (Postfix) with ESMTPS id 576F9106AC1; Fri, 31 Jan 2014 09:15:58 +0100 (CET) Received: from DAPHNIS.office.hd ([169.254.2.144]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Fri, 31 Jan 2014 09:15:37 +0100 From: Thomas Dietz To: Brad Schoening , Bruce Nordman , eman mailing list Thread-Topic: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib-13 Thread-Index: AQHPHUvOnytsgxxDl0udfN1WluowmJqdedQAgAAhIACAAADCgIAAHh+AgAAKQgCAALb5sA== Date: Fri, 31 Jan 2014 08:15:36 +0000 Message-ID: <75581E268A48F849916117B977D76D37688A1886@DAPHNIS.office.hd> References: In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.1.2.117] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0051_01CF1E64.FFCBC160" MIME-Version: 1.0 Subject: Re: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib-13 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 31 Jan 2014 08:16:23 -0000 ------=_NextPart_000_0051_01CF1E64.FFCBC160 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0052_01CF1E64.FFCBC160" ------=_NextPart_001_0052_01CF1E64.FFCBC160 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Brad, all, =20 first of all I second J=FCrgen=92s view that we should not artificially = limit ourselves if there is no technical reason. =20 And what the discussion below shows is exactly the reason for that. The definition of the domain leaves some room for interpretation. Thus, IMHO = it should be allowed to have an implementation of a domain that allows that objects are part of more than one domain. You could define the domain as = a sort of =93geographical domain=94 and have a building that get = controlled by the owner and some rental units that are controlled by the tenant. This = would imply that the same object are part of two different domain. And this example would match in my opinion the definition of domain in the = framework document. =20 Best Regards, =20 Thomas =20 --=20 Thomas Dietz NEC Europe Ltd., NEC Laboratories, Network Research Division, 69115 Heidelberg, Germany =20 NEC Europe Limited, Registered in England 2832014 Registered Office: Athene, Odyssey Business Park, West End Road, = London, HA4 6QE, GB =20 From: eman [mailto:eman-bounces@ietf.org] On Behalf Of Brad Schoening Sent: Thursday, January 30, 2014 11:08 PM To: Bruce Nordman; eman mailing list Subject: Re: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib-13 =20 "If one uses domain in the recommended fashion, then a device that = receives power from two sources (each sub-metered) is definitely in two different domains." =20 Or a new domain, which combines the two and has its own power policy. = In which case, a single domain suits our model quite well. =20 Regards, =20 Brad =20 From: Bruce Nordman > Date: Thu, 30 Jan 2014 13:31:11 -0800 To: eman mailing list > Subject: Re: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib-13 =20 For the Domain issue, I have always believed that the Framework draft did not define the concept well. Since it is ambiguous in the = Framework, it is not surprising that we are running into problems with it in later stages (the MIBs for example). The current Framework states (6.3.6): An Energy Management Domain can be any collection of Energy Objects in a deployment, but it is recommended to map 1:1 with a metered or sub-metered portion of the site. If one uses domain in the recommended fashion, then a device that = receives power from two sources (each sub-metered) is definitely in two different domains. If one uses it differently, as is permitted, then many reasonable and useful usages require more than one domain. Another way to think about this is that it was a flawed idea in the first place that a device is in a domain at all. It is the power interface (or interfaces, for devices which receive supply from more than one) that is in the domain, not the device itself. An interface is more clearly in one domain. Different types of entities (devices, components, power interfaces) have different types of data available, so having domain only in the PI is quite reasonable. Thus, the correct answer to me for domain for a device is either zero or multiple. To recommend one as a compromise seeks OK. For a PI, only a single domain is needed. I second Juergen's line of reasoning that it is quite unnecessary and not justified to make the framework change to single at this time. Thanks, --Bruce --=20 Bruce Nordman Lawrence Berkeley National Laboratory nordman.lbl.gov =20 BNordman@LBL.gov =20 510-486-7089 m: 510-501-7943 _______________________________________________ eman mailing list eman@ietf.org https://www.ietf.org/mailman/listinfo/eman=20 ------=_NextPart_001_0052_01CF1E64.FFCBC160 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dear Brad, all,

 

first of all I second J=FCrgen’s view that we should not = artificially limit ourselves if there is no technical = reason.

 

And what the discussion below shows is exactly the reason for that. = The definition of the domain leaves some room for interpretation. Thus, = IMHO it should be allowed to have an implementation of a domain that = allows that objects are part of more than one domain. You could define = the domain as a sort of “geographical domain” and have a = building that get controlled by the owner and some rental units that are = controlled by the tenant. This would imply that the same object are part = of two different domain. And this example would match in my opinion the = definition of domain in the framework document.

 

Best Regards,

 

Thomas

 

--

Thomas Dietz

NEC Europe Ltd., NEC Laboratories, Network Research Division, 69115 = Heidelberg, Germany

 

NEC Europe Limited, Registered in England = 2832014

Registered Office: Athene, Odyssey Business Park, West End =  Road, London, HA4 6QE, GB

 

From: eman = [mailto:eman-bounces@ietf.org] On Behalf Of Brad = Schoening
Sent: Thursday, January 30, 2014 11:08 = PM
To: Bruce Nordman; eman mailing list
Subject: Re: = [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib-08 and = draft-ietf-eman-energy-aware-mib-13

 

"If one uses domain in the recommended fashion, then a device that = receives

power from two sources (each sub-metered) is definitely in two = different

domains."

 

Or a new domain, which combines the two and has its own power policy. =  In which case, a single domain suits our model quite = well.

 

Regards,

 

Brad

 

From: Bruce Nordman <bnordman@lbl.gov>
Date: = Thu, 30 Jan 2014 13:31:11 -0800
To: eman mailing list = <eman@ietf.org>
Subject: = Re: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib-08 = and = draft-ietf-eman-energy-aware-mib-13

 

For the Domain issue, I have always believed that the Framework = draft
did not define the concept well.  Since it is ambiguous in = the Framework,
it is not surprising that we are running into problems = with it in later
stages (the MIBs for example).

The current = Framework states (6.3.6):

   An Energy Management = Domain can be any collection of Energy
   Objects in a = deployment, but it is recommended to map 1:1
   with a = metered or sub-metered portion of the site.

If one uses domain in = the recommended fashion, then a device that receives
power from two = sources (each sub-metered) is definitely in two = different
domains.
If one uses it differently, as is permitted, = then many reasonable
and useful usages require more than one = domain.

Another way to think about this is that it was a flawed = idea in
the first place that a device is in a domain at all.  It = is the
power interface (or interfaces, for devices which receive = supply
from more than one) that is in the domain, not the device = itself.
An interface is more clearly in one domain.  Different = types of
entities (devices, components, power interfaces) have = different
types of data available, so having domain only in the PI is = quite
reasonable.

Thus, the correct answer to me for domain = for a device is either
zero or multiple.  To recommend one as a = compromise seeks OK.
For a PI, only a single domain is = needed.

I second Juergen's line of reasoning that it is quite = unnecessary
and not justified to make the framework change to single = at this time.

Thanks,

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

------=_NextPart_001_0052_01CF1E64.FFCBC160-- ------=_NextPart_000_0051_01CF1E64.FFCBC160 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISXDCCA58w ggKHoAMCAQICASYwDQYJKoZIhvcNAQEFBQAwcTELMAkGA1UEBhMCREUxHDAaBgNVBAoTE0RldXRz Y2hlIFRlbGVrb20gQUcxHzAdBgNVBAsTFlQtVGVsZVNlYyBUcnVzdCBDZW50ZXIxIzAhBgNVBAMT GkRldXRzY2hlIFRlbGVrb20gUm9vdCBDQSAyMB4XDTk5MDcwOTEyMTEwMFoXDTE5MDcwOTIzNTkw MFowcTELMAkGA1UEBhMCREUxHDAaBgNVBAoTE0RldXRzY2hlIFRlbGVrb20gQUcxHzAdBgNVBAsT FlQtVGVsZVNlYyBUcnVzdCBDZW50ZXIxIzAhBgNVBAMTGkRldXRzY2hlIFRlbGVrb20gUm9vdCBD QSAyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqwujNeCLKRSxFIWvPBDkOW81XUqu 3ephjZVJ9G9koxpgZqSpQCKE2dSl5XiTDmgBrblNXDrO07ioQkDfz6O6gllqkhusHJraCCslJ/lp I0fx4Ossepv1EwLQfjR8wp48AFmr9doM9TI8K6xQ2tbD3oOUyqgMmTIOCEhWW2r72uFYWAFJX3JB PBUGAY5draq4k7TNnuun6GotUjTbOu9cdVHa2/Mx+e5xmDLEVBVEDPmbVe2t3xgIoKOGiknuUwWP GUzV3lh5m9JqHEKrxdWnz2gPluThYZh2YciRfNY+AOKRUIfhnQrmrZfSHcY6fcu82gM01Y5bAfVq B7cWtm5KfwIDAQABo0IwQDAdBgNVHQ4EFgQUMcN5G7r1U9cX4Il6LRdsCrMrnTMwDwYDVR0TBAgw BgEB/wIBBTAOBgNVHQ8BAf8EBAMCAQYwDQYJKoZIhvcNAQEFBQADggEBAJRkWa05ZOcp6xP+WsOL E1fIBCTwdHfAYONn++mJpoO/loJ8btTDPe+egG67KbSYerE7VOs5F0d+Go4L/B8xWTEEss4X8yzH YjZV4iLYiVW0mEiqZPrWHDbYRHhaWiM6V5f1ejBPrp9qTEsrjqAD4z7gqdTSe9KzqOJyPK2e/4BZ 5JtFtPY7sM05GZgy5eohYZDkMSGONLH3LzVKhRDa54o3Ib5ZY+DyhYgxU9RUFIVwefQuBncndS8f uIr5/sW62Dbkg+znZbe/Y1rzRq+BlDfUQYzWI9Yez/VoG0Rjolq6pzVZoeVwBZsOI1eZlAptujlj KIaS8xiE2PvRzwVWZFcwggQhMIIDCaADAgECAgIAxzANBgkqhkiG9w0BAQUFADBxMQswCQYDVQQG EwJERTEcMBoGA1UEChMTRGV1dHNjaGUgVGVsZWtvbSBBRzEfMB0GA1UECxMWVC1UZWxlU2VjIFRy dXN0IENlbnRlcjEjMCEGA1UEAxMaRGV1dHNjaGUgVGVsZWtvbSBSb290IENBIDIwHhcNMDYxMjE5 MTAyOTAwWhcNMTkwNjMwMjM1OTAwWjBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZOLVZlcmVp bjEQMA4GA1UECxMHREZOLVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xvYmFsIC0gRzAx MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA6ZvDZ4X5Da71jVTDllA1PWLpbkztlNcA W5UidNQg6zSP1uzAMQQLmYHiphTSUqAoI4SLdIkEXlvg4njBeMsWyyg1OXstkEXQ7aAAeny/Sg4b AMOG6VwrMRF7DPOCJEOMHDiLamgAmu7cT3ir0sYTm3at7t4m6O8Br3QPwQmi9mvOvdPNFDBP9eXj pMhim4IaAycwDQJlYE3t0QkjKpY1WCfTdsZxtpAdxO3/NYZ9bzOz2w/FEcKKg6GUXUFr2NIQ9Uz9 ylGs2b3vkoO72uuLFlZWQ8/h1RM9ph8nMM1JVNvJEzSacXXFbOqnC5j5IZ0nrz6jOTlIaoytyZn7 wxLyvQIDAQABo4HZMIHWMHAGA1UdHwRpMGcwZaBjoGGGX2h0dHA6Ly9wa2kudGVsZXNlYy5kZS9j Z2ktYmluL3NlcnZpY2UvYWZfRG93bmxvYWRBUkwuY3JsPy1jcmxfZm9ybWF0PVhfNTA5Ji1pc3N1 ZXI9RFRfUk9PVF9DQV8yMB0GA1UdDgQWBBRJt8bP6D0ff+pEexMp9/EKcD7eZDAfBgNVHSMEGDAW gBQxw3kbuvVT1xfgiXotF2wKsyudMzAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIB AjANBgkqhkiG9w0BAQUFAAOCAQEAO+Fad8BIF9ypGOyBr1qJ8L0okqbKWRgScOwo8ueuf5Ys5/Jd GTH2Eyt0vb2Asrn3Z8k5onk74RER7mt4kTN+O18mJ3VTZY4zY+7Pc8OwkiNJIVB1I6EfGOKUhT0/ M+l3II2iveahhSlA9j9zMlgNCWum2oVswD+7jWZkViROrg0/MjUBW+mMgtlyWU+xhoXxdIVW5cP4 XPON7kezUwVw5+VNimmDKOETCYaeXsjqWB4MH/mk1FoEaP0oPosCtli19qEsN1cAZ6sjaI1jpe+Z a1z9S1b2q0CHNNQRkmzsh8UKCwczcrRvDB1ULNhRx8y/MNNDcvEyv4zOSWOoAPfyHDCCBS8wggQX oAMCAQICBA0hCkcwDQYJKoZIhvcNAQEFBQAwWjELMAkGA1UEBhMCREUxEzARBgNVBAoTCkRGTi1W ZXJlaW4xEDAOBgNVBAsTB0RGTi1QS0kxJDAiBgNVBAMTG0RGTi1WZXJlaW4gUENBIEdsb2JhbCAt IEcwMTAeFw0wODEwMjQwODUyMDhaFw0xOTA2MzAwMDAwMDBaMIGQMQswCQYDVQQGEwJERTEYMBYG A1UEChMPTkVDIEV1cm9wZSBMdGQuMSAwHgYDVQQLExdORUMgTGFib3JhdG9yaWVzIEV1cm9wZTES MBAGA1UEAxMJTkVDTEFCLUNBMTEwLwYJKoZIhvcNAQkBFiJ6ZXJ0aWZpemllcnVuZ3NzdGVsbGVA bncubmVjbGFiLmV1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAnvIVsbURqjIOcbnf ruYkRceWOZpyvM2ebnYpbd1cP+zdWm6yR7HSO9ppOe1ZZFIasArqQpedPEFvcncSG94FRuW3ND4r Rcq08mbpUTmpWmXfdYlJpQezbsOHCWR74NXoEEbK6TPZIMFpJr6dzQDAxnRc7UOgO6JQ1V42Z39B PhIbPIWz64t8svafxbORmxulJn7F5zDLDcR1AEGyn+L9b645AGwapoKNh7cSQFTqdb6kGyPQjLWf tv09dvmBDKesrcyLZXuDWJ1LMeizSjUEygdSszNXD3gePgJaVaZDS3o923W5gAyPCTSxpAFj8XJ+ /7Ap5jJwYhjJgJ8khFR7JQIDAQABo4IBxDCCAcAwEgYDVR0TAQH/BAgwBgEB/wIBATALBgNVHQ8E BAMCAQYwHQYDVR0OBBYEFE8ch3od4C+Z9r4VqtE1nQ5K5ro2MB8GA1UdIwQYMBaAFEm3xs/oPR9/ 6kR7Eyn38QpwPt5kMC0GA1UdEQQmMCSBInplcnRpZml6aWVydW5nc3N0ZWxsZUBudy5uZWNsYWIu ZXUwgYgGA1UdHwSBgDB+MD2gO6A5hjdodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2dsb2JhbC1yb290 LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMD2gO6A5hjdodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2dsb2Jh bC1yb290LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIGiBggrBgEFBQcBAQSBlTCBkjBHBggrBgEFBQcw AoY7aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY2FjZXJ0L2NhY2Vy dC5jcnQwRwYIKwYBBQUHMAKGO2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2Ev cHViL2NhY2VydC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQBsMQ+dD0mmi48dgDU4R6Q/ eXcY0zQcHNp1Vu1s3kwO0WahWB0tiqVBodvfTAWG44xuw0I7NXSTwQ68FU5P0GIQnvRFZyVJlDjr SNlLYxjqfmgb+KVm67o383cZIuDakEE0f29kULIEn2fg/HsDiBAXTsb4I19XaN0TXLI+PMhU+GDp sGCJrydeugEV7qi15q8yymjSAsYgnrc2wJuXpyQ9r3qCtP6aedAPSHqOT8ga1dLT2YRZFs3vNm7T HSr5JJymWMbfpD6OcbRTnNAjSMDHwJxgRBAflA6WzDVm7fk4jiWyLvJwWTMk19t8QLiKG7D0nYvj cEUYyiOSE+SFUTEdMIIFXTCCBEWgAwIBAgIHFXEjuSzkIzANBgkqhkiG9w0BAQUFADCBkDELMAkG A1UEBhMCREUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVDIExhYm9yYXRv cmllcyBFdXJvcGUxEjAQBgNVBAMTCU5FQ0xBQi1DQTExMC8GCSqGSIb3DQEJARYiemVydGlmaXpp ZXJ1bmdzc3RlbGxlQG53Lm5lY2xhYi5ldTAeFw0xMzAzMjYxMzQ0MDlaFw0xNjAzMjUxMzQ0MDla MGAxCzAJBgNVBAYTAkRFMRgwFgYDVQQKEw9ORUMgRXVyb3BlIEx0ZC4xIDAeBgNVBAsTF05FQyBM YWJvcmF0b3JpZXMgRXVyb3BlMRUwEwYDVQQDEwxUaG9tYXMgRGlldHowggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQCpjbFMyLnXM7ssr9eAuoFSJd2fNyleLDl+BbAd4uaSuD6IacC4Cq/d e3tXtiuM1o5HefxvXMcgRArYdmhICR+Il4jJwHOcZyfKzlBbqtQrzUgbixiuqhDNCmhxoLMRTJtY aDIuoRqVXzqDjU1gWB+BAKIA2B7KzCCZtGnmd2QSAmZkSPL3X+FMQ64+5cTPijzOJ5dgX5mAdHX2 /OUWZ12NdrspIoxoKx3twk9tRVv9K30ehOFN7BV1aJfjEiEWCOGT5aE6dxle+ujn+U/TG8GIyfE6 uXCituRUM168X6CfzoSM8rE8bjXzTiy92bPtQmXIgW9Jn5sE+/hn7yV5BNIpAgMBAAGjggHpMIIB 5TAvBgNVHSAEKDAmMBEGDysGAQQBga0hgiwBAQQDADARBg8rBgEEAYGtIYIsAgEEAwAwCQYDVR0T BAIwADALBgNVHQ8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQW BBSfxN6vdKpCh8VajmMo3lQw21coTDAfBgNVHSMEGDAWgBRPHId6HeAvmfa+FarRNZ0OSua6NjAh BgNVHREEGjAYgRZUaG9tYXMuRGlldHpAbmVjbGFiLmV1MH0GA1UdHwR2MHQwOKA2oDSGMmh0dHA6 Ly9jZHAxLnBjYS5kZm4uZGUvbmVjbGFiLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMDigNqA0hjJodHRw Oi8vY2RwMi5wY2EuZGZuLmRlL25lY2xhYi1jYS9wdWIvY3JsL2NhY3JsLmNybDCBmAYIKwYBBQUH AQEEgYswgYgwQgYIKwYBBQUHMAKGNmh0dHA6Ly9jZHAxLnBjYS5kZm4uZGUvbmVjbGFiLWNhL3B1 Yi9jYWNlcnQvY2FjZXJ0LmNydDBCBggrBgEFBQcwAoY2aHR0cDovL2NkcDIucGNhLmRmbi5kZS9u ZWNsYWItY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQBeQruB47uM aISTpyfmtUw9p5FwiQJ6voD76MjHdSP5eR2Li/h/N1HQKi417Wztz55iI2H5Jywi38aIoYKDkByw NHZPgOgPcEBUG6p7vrbMaxFZrZvOWAm471kFgHnL+CeX80xujmfuxT2GnULYmq1KQaGzqWvXAgms mopuKE4D+O4tIhlPr9mmdBClrJ2vfwGfR0wf94LoA1SRYatmrpp7yrpWSQHYYcZ2dVF6HBVIGp14 rZW/tw9jKxoX39yoGOxRR60kew/58wPmS+O8BzvG0n9mAOwCmd8ZhiKrW18GZpJ0+TNi9zc+MJcv TFQS3SzT4qpe1BdI9bB+BoU8q7irMYIENTCCBDECAQEwgZwwgZAxCzAJBgNVBAYTAkRFMRgwFgYD VQQKEw9ORUMgRXVyb3BlIEx0ZC4xIDAeBgNVBAsTF05FQyBMYWJvcmF0b3JpZXMgRXVyb3BlMRIw EAYDVQQDEwlORUNMQUItQ0ExMTAvBgkqhkiG9w0BCQEWInplcnRpZml6aWVydW5nc3N0ZWxsZUBu dy5uZWNsYWIuZXUCBxVxI7ks5CMwCQYFKw4DAhoFAKCCAm0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTQwMTMxMDgxNTM1WjAjBgkqhkiG9w0BCQQxFgQU8gyQLOC6 oPaMoZol/qZG/K2+JvQwgasGCSqGSIb3DQEJDzGBnTCBmjALBglghkgBZQMEASowCwYJYIZIAWUD BAEWMAoGCCqGSIb3DQMHMAsGCWCGSAFlAwQBAjAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYI KoZIhvcNAwICAUAwDQYIKoZIhvcNAwICASgwBwYFKw4DAhowCwYJYIZIAWUDBAIDMAsGCWCGSAFl AwQCAjALBglghkgBZQMEAgEwga0GCSsGAQQBgjcQBDGBnzCBnDCBkDELMAkGA1UEBhMCREUxGDAW BgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVDIExhYm9yYXRvcmllcyBFdXJvcGUx EjAQBgNVBAMTCU5FQ0xBQi1DQTExMC8GCSqGSIb3DQEJARYiemVydGlmaXppZXJ1bmdzc3RlbGxl QG53Lm5lY2xhYi5ldQIHFXEjuSzkIzCBrwYLKoZIhvcNAQkQAgsxgZ+ggZwwgZAxCzAJBgNVBAYT AkRFMRgwFgYDVQQKEw9ORUMgRXVyb3BlIEx0ZC4xIDAeBgNVBAsTF05FQyBMYWJvcmF0b3JpZXMg RXVyb3BlMRIwEAYDVQQDEwlORUNMQUItQ0ExMTAvBgkqhkiG9w0BCQEWInplcnRpZml6aWVydW5n c3N0ZWxsZUBudy5uZWNsYWIuZXUCBxVxI7ks5CMwDQYJKoZIhvcNAQEBBQAEggEAFp0HRu8YwFRa y6okFXjA/Lr0Mrh98q6fmimmO8ALH3YaXQyhCqf75/eADc/Eh5Fjo7sILmHwCJt1A1WB5eoSwEn6 aR4UbXMlb3luc4JBnECmnP56LYL5uEDj2s6yMaW7GASZjWREVVbB/Xg0bVvcuxsBLl8jN5Tcl3uN XWIcyRTlRb1FqcMQ/a77HhAsvpAOzhEAlaOCj3JSgs8+lk6muxZDTAPCXwGIGLN8EhJCLg2nlab4 aLEbDCd5jEWRSoAtlnTUSqiCS7hAC5/tz6mNTCeoBDWUUmFZ0EYO8bkEsRAun6+FfTDWrNWNylv9 iD4L1HiAeHMfPvMni7El8V+HGQAAAAAAAA== ------=_NextPart_000_0051_01CF1E64.FFCBC160-- From moulchan@cisco.com Fri Jan 31 00:48:04 2014 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB9181A0578 for ; Fri, 31 Jan 2014 00:48:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.035 X-Spam-Level: X-Spam-Status: No, score=-10.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vPRWx3PuUhZZ for ; Fri, 31 Jan 2014 00:48:02 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id 025E11A0575 for ; Fri, 31 Jan 2014 00:48:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9740; q=dns/txt; s=iport; t=1391158078; x=1392367678; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=8nKDW087ap44rkxIxblWNm46L78mjRzX2gtyh7LqN7g=; b=ihqxefV2bqQpq5+XkWV51PDgP0mHTwNOSlvoc3SWIrHxB2mZurDHze+U rMiMtjuqY91Q8o+1lPDCkTXwy070hndXdJrCeIXVCOP5Z4/1RP+GLF+x1 7taq+x4go3wXAYsaytwT+CL1WSUIksBw3YT+fRW6c7KuGM6xUJuK2SznE M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai8FAMRi61KtJXG//2dsb2JhbABZgkhEOFe9NIEHFnSCJgEBBAEBARpRCxACAQg7BAcnCxQRAgQBDQUUh3ENzHgTBI4qCkoEBwKENgSUQYNokiGBb4E+gWhC X-IronPort-AV: E=Sophos;i="4.95,756,1384300800"; d="scan'208,217";a="16940561" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by alln-iport-6.cisco.com with ESMTP; 31 Jan 2014 08:47:56 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id s0V8lu01025543 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 31 Jan 2014 08:47:56 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.39]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0123.003; Fri, 31 Jan 2014 02:47:56 -0600 From: "Mouli Chandramouli (moulchan)" To: "John Parello (jparello)" , Brad Schoening Thread-Topic: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib-13 Thread-Index: AQHPHUvD2xOkY6/rPUySnTOIlHxvQ5qd7ywAgAAhIQCAATgnAA== Date: Fri, 31 Jan 2014 08:47:55 +0000 Message-ID: References: <9AB93E4127C26F4BA7829DEFDCE5A6E868913FC9@DAPHNIS.office.hd> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.143.24.252] Content-Type: multipart/alternative; boundary="_000_CF115FF61DB95moulchanciscocom_" MIME-Version: 1.0 Cc: eman mailing list Subject: Re: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib-13 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 31 Jan 2014 08:48:05 -0000 --_000_CF115FF61DB95moulchanciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree with the chairs and each energy object must belong to a single doma= in. The MIB modules that have been presented and reviewed many times over, hav= e also stressed the importance of 1-1 mapping between an Energy Object and= a domain. Keywords can be used as tags for other groupings of energy objects. Thanks Mouli I agree with the chairs and our approach that the device/chassis is a scala= r domain not a vector. As agreed in the framework model. The complexity of power supplies (stack power for example) is handled by gr= ouping (keywords) not the management domain( i.e. community). MUST is the p= referred approach in practice. Our implementations and experience have found that no site ever used the do= main for this purpose but used groupings as Brad expressed below. Also the information model has been expressed as scalar not a vector for th= is field for some time and we have feedback and consensus on running code t= hat this is preferable. A change to SHOULD would mean we'd have to add attributes for size of field= /table to do a proper vector. That would mean soliciting feedback from imp= lementors that already are expecting / using this as a scalar. most are not= paying attention since wglc. Change the framework error not the modelling at this point please. Jp Sent from my iPad (expect ridiculous spelling mistakes) On Jan 30, 2014, at 9:42 AM, "Brad Schoening" > wrote: Juergen, In your dual power supply example, I would think of these as three domains: supplyA, supplyB and supplyAB. The new domain supplyAB is a high-reliabliy domain. You don't mention what the power policy of this new combined domain is, but there could be several choices for supplyAB. Consider a more complicated example, you have a chassis with three power supply modules. There are at least three different policies that could be applied: - Power module redundancy - total power allowed is one less than the number of supply modules E.g., total power is 2 x. - Power module redundancy with throttling - total power allowed is equal to available power, but requires consumers to throttle down if one module fails. E.g., total power is between 2x and 3x. - Basic power w/o redundancy - total power allowed is equal to all available power with no redundancy. E.g., total power is 3x. Combining power domains likely always invokes a policy and thus in the eman model, creates a new domain. This approach is compatible with the chairs suggestion of MUST. Regards, Brad On 1/29/14 3:41 PM, "Juergen Quittek" > wrote: 1. Having a device limited to a single domain membership is a limitation/feature of Cisco's EnergyWise for which in all the long discussions we had in past year never any technical reason was given (although it was asked for multiple times). In the contrary, I gave use cases where it is REQUIRED to have two or more domains. An obvious example is a highly reliable server that has dual power supply. Its two power supply lines SHOULD be in different domains in order to be better protected from local power supply failures. This server should be given means to report via the MIB that it is member of two domains. _______________________________________________ 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_CF115FF61DB95moulchanciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <832AB06A8234C94CA9FB47B78CDAF171@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
I agree with the chairs and each energy object must belong to a single= domain.  

The MIB modules that have been presented and reviewed many times over,=  have also stressed the importance of 1-1 mapping between  an En= ergy Object and a domain.

Keywords can be used as tags for other groupings of energy objects.&nb= sp;

Thanks
Mouli 


I agree with the chairs and our approach that the device/chassis is a = scalar domain not a vector. As agreed in the framework model.

The complexity of power supplies (stack power for example) is handled = by grouping (keywords) not the management domain( i.e. community). MUST is = the preferred approach in practice.

Our implementations and experience have found that no site ever used t= he domain for this purpose but used groupings as Brad expressed below.

Also the information model has been expressed as scalar not a vector f= or this field for some time and we have feedback and consensus on running c= ode that this is preferable.

A change to SHOULD would mean we'd have to add attributes for size of = field /table to do a proper vector. That would mean soliciting feedback fro= m implementors that already are expecting / using this as a scalar. most ar= e not paying attention since wglc.

Change the framework error not the modelling at this point please.

Jp


Sent from my iPad
(expect ridiculous spelling mistakes)

On Jan 30, 2014, at 9:42 AM, "Brad Schoening" <brads@coraid.com> wrote:

Juergen,
In your dual power supply example, I would think of these as three
domains: supplyA, supplyB and supplyAB.  The new domain supp= lyAB is a
high-reliabliy domain.  You don't mention what the power pol= icy of this
new combined domain is, but there could be several choices for supplyA= B.
Consider a more complicated example, you have a chassis with three pow= er
supply modules.  There are at least three different policies= that could be
applied:
- Power module redundancy - total power allowed is one less than the
number of supply modules
  E.g., total power is 2 x.
- Power module redundancy with throttling - total power allowed is equ= al
to available power, but
  requires consumers to throttle down if one module fails.&n= bsp; E.g., total
power is between 2x and 3x.
- Basic power w/o redundancy - total power allowed is equal to all
available power with no redundancy.  E.g., total power is 3x= .
Combining power domains likely always invokes a policy and thus in the=
eman model, creates a new domain.
This approach is compatible with the chairs suggestion of MUST.
Regards,
Brad
On 1/29/14 3:41 PM, "Juergen Quittek" <Quittek@neclab.eu> wrote:
1. Having a device limited to a single domain membership is a
limitation/feature of Cisco's EnergyWise for which in all the long
discussions we had in past year never any technical reason was given
(although it was asked for multiple times). In the contrary, I gave us= e
cases where it is REQUIRED to have two or more domains. An obvious
example is a highly reliable server that has dual power supply. Its tw= o
power supply lines SHOULD be in different domains in order to be bette= r
protected from local power supply failures. This server should be give= n
means to report via the MIB that it is member of two domains.
_______________________________________________
eman mailing list
_______________________________________________
eman mailing list

--_000_CF115FF61DB95moulchanciscocom_-- From Rolf.Winter@neclab.eu Fri Jan 31 02:03:38 2014 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B9CC1A0476 for ; Fri, 31 Jan 2014 02:03:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.137 X-Spam-Level: X-Spam-Status: No, score=-3.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DMCaiIvx5hxh for ; Fri, 31 Jan 2014 02:03:36 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 854951A0574 for ; Fri, 31 Jan 2014 02:03:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 9ACC1106ADF; Fri, 31 Jan 2014 11:03:32 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IMC+qsqD6z5u; Fri, 31 Jan 2014 11:03:32 +0100 (CET) X-ENC: Last-Hop-TLS-encrypted X-ENC: Last-Hop-TLS-encrypted Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailer1.neclab.eu (Postfix) with ESMTPS id 7A086106ADB; Fri, 31 Jan 2014 11:03:22 +0100 (CET) Received: from DAPHNIS.office.hd ([169.254.2.144]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Fri, 31 Jan 2014 11:03:22 +0100 From: Rolf Winter To: Bruce Nordman , eman mailing list Thread-Topic: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib-13 Thread-Index: AQHPHUvOmiN19EE85Uifdy5vV1BN+pqdedQAgAAhIACAAADCgIAAHh+AgADhQwA= Date: Fri, 31 Jan 2014 10:03:22 +0000 Message-ID: <791AD3077F94194BB2BDD13565B6295D63BA7C48@DAPHNIS.office.hd> References: <9AB93E4127C26F4BA7829DEFDCE5A6E868913FC9@DAPHNIS.office.hd> <4B082FB2-7EDC-4F5C-97B4-AD7027AF88DC@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.209] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib-13 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 31 Jan 2014 10:03:38 -0000 I agree here. I think the changes are a) quite late and b) not in line with= the textual description of a domain. Have we gotten the some of the concep= ts all wrong/ill defined (something that was voiced before on the mailing l= ist)? I am also puzzled about process here. I think in the last meeting I w= as told that no further changes were allowed (I believe). Now we make furth= er changes.=20 NEC Europe Ltd | Registered Office: Athene, Odyssey Business Park, West End= Road, London, HA4 6QE, GB | Registered in England 2832014 > -----Original Message----- > From: eman [mailto:eman-bounces@ietf.org] On Behalf Of Bruce Nordman > Sent: Donnerstag, 30. Januar 2014 22:31 > To: eman mailing list > Subject: Re: [eman] WG Last Call for draft-ietf-eman-energy-monitoring- > mib-08 and draft-ietf-eman-energy-aware-mib-13 >=20 > For the Domain issue, I have always believed that the Framework draft > did not define the concept well. Since it is ambiguous in the > Framework, it is not surprising that we are running into problems with > it in later stages (the MIBs for example). >=20 > The current Framework states (6.3.6): >=20 > An Energy Management Domain can be any collection of Energy > Objects in a deployment, but it is recommended to map 1:1 > with a metered or sub-metered portion of the site. >=20 > If one uses domain in the recommended fashion, then a device that > receives power from two sources (each sub-metered) is definitely in two > different domains. > If one uses it differently, as is permitted, then many reasonable and > useful usages require more than one domain. >=20 > Another way to think about this is that it was a flawed idea in the > first place that a device is in a domain at all. It is the power > interface (or interfaces, for devices which receive supply from more > than one) that is in the domain, not the device itself. > An interface is more clearly in one domain. Different types of > entities (devices, components, power interfaces) have different types > of data available, so having domain only in the PI is quite reasonable. >=20 > Thus, the correct answer to me for domain for a device is either zero > or multiple. To recommend one as a compromise seeks OK. > For a PI, only a single domain is needed. >=20 > I second Juergen's line of reasoning that it is quite unnecessary and > not justified to make the framework change to single at this time. >=20 > Thanks, >=20 > --Bruce >=20 > -- >=20 > Bruce Nordman > Lawrence Berkeley National Laboratory > nordman.lbl.gov > BNordman@LBL.gov > 510-486-7089 > m: 510-501-7943 From brads@coraid.com Fri Jan 31 07:57:16 2014 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86FFF1A0280 for ; Fri, 31 Jan 2014 07:57:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8NGEKVqx7Uck for ; Fri, 31 Jan 2014 07:57:12 -0800 (PST) Received: from server506.appriver.com (server506j.appriver.com [50.56.144.148]) by ietfa.amsl.com (Postfix) with ESMTP id B771D1A03F5 for ; Fri, 31 Jan 2014 07:57:11 -0800 (PST) X-Note-AR-ScanTimeLocal: 1/31/2014 9:57:07 AM X-Policy: GLOBAL - coraid.com X-Policy: GLOBAL - coraid.com X-Policy: GLOBAL - coraid.com X-Primary: brads@coraid.com X-Note: This Email was scanned by AppRiver SecureTide X-Virus-Scan: V- X-Note-SnifferID: 0 X-Note: TCH-CT/SI:0-205/SG:5 1/31/2014 9:56:19 AM X-GBUdb-Analysis: 0, 10.242.229.139, Ugly c=1 p=-0.979385 Source White X-Signature-Violations: 0-0-0-32767-c X-Note-419: 31.2006 ms. Fail:1 Chk:1345 of 1345 total X-Note: SCH-CT/SI:1-1345/SG:1 1/31/2014 9:56:58 AM 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: G327 G328 G329 G330 G334 G335 G445 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 50448191; Fri, 31 Jan 2014 09:57:07 -0600 Received: from DAGN05C-E6.exg6.exghost.com ([169.254.3.11]) by HT06-E6.exg6.exghost.com ([10.242.230.113]) with mapi id 14.03.0158.001; Fri, 31 Jan 2014 09:57:07 -0600 From: Brad Schoening To: Thomas Dietz , Bruce Nordman , eman mailing list Thread-Topic: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib-13 Thread-Index: AQHPG+0tpS6rr1XnlUCE8LfKL9ID95qaoPaAgAIjFICAAKfBAIAApz8AgAAAwoCAAB4fgP//hCMAgAEv6QD///rTAA== Date: Fri, 31 Jan 2014 15:57:07 +0000 Message-ID: In-Reply-To: <75581E268A48F849916117B977D76D37688A1886@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: multipart/alternative; boundary="_000_CF1106A31127E5bradscoraidcom_" MIME-Version: 1.0 Subject: Re: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib-13 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 31 Jan 2014 15:57:16 -0000 --_000_CF1106A31127E5bradscoraidcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable HI Thomas, As Mouli mentioned in a separate email, the use case you mention can be add= ress with keywords. A single domain + keywords gives flexibility in charac= terizing your environment. Given this, I think the current single domain m= odel has shown it address all the specific concerns raised thus far. Best Regards, Brad Brad Schoening Engineering | Coraid Tel: +1 917 304 7190 brads@coraid.com | www.coraid.com Coraid: Redefining Storage From: Thomas Dietz > Date: Fri, 31 Jan 2014 08:15:36 +0000 To: Brad Schoening >, Bruce Nordm= an >, eman mailing list > Subject: RE: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib-= 08 and draft-ietf-eman-energy-aware-mib-13 Dear Brad, all, first of all I second J=FCrgen=92s view that we should not artificially lim= it ourselves if there is no technical reason. And what the discussion below shows is exactly the reason for that. The def= inition of the domain leaves some room for interpretation. Thus, IMHO it sh= ould be allowed to have an implementation of a domain that allows that obje= cts are part of more than one domain. You could define the domain as a sort= of =93geographical domain=94 and have a building that get controlled by th= e owner and some rental units that are controlled by the tenant. This would= imply that the same object are part of two different domain. And this exam= ple would match in my opinion the definition of domain in the framework doc= ument. Best Regards, Thomas -- Thomas Dietz NEC Europe Ltd., NEC Laboratories, Network Research Division, 69115 Heidelb= erg, Germany NEC Europe Limited, Registered in England 2832014 Registered Office: Athene, Odyssey Business Park, West End Road, London, H= A4 6QE, GB From: eman [mailto:eman-bounces@ietf.org] On Behalf Of Brad Schoening Sent: Thursday, January 30, 2014 11:08 PM To: Bruce Nordman; eman mailing list Subject: Re: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib-= 08 and draft-ietf-eman-energy-aware-mib-13 "If one uses domain in the recommended fashion, then a device that receives power from two sources (each sub-metered) is definitely in two different domains." Or a new domain, which combines the two and has its own power policy. In w= hich case, a single domain suits our model quite well. Regards, Brad From: Bruce Nordman > Date: Thu, 30 Jan 2014 13:31:11 -0800 To: eman mailing list > Subject: Re: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib-= 08 and draft-ietf-eman-energy-aware-mib-13 For the Domain issue, I have always believed that the Framework draft did not define the concept well. Since it is ambiguous in the Framework, it is not surprising that we are running into problems with it in later stages (the MIBs for example). The current Framework states (6.3.6): An Energy Management Domain can be any collection of Energy Objects in a deployment, but it is recommended to map 1:1 with a metered or sub-metered portion of the site. If one uses domain in the recommended fashion, then a device that receives power from two sources (each sub-metered) is definitely in two different domains. If one uses it differently, as is permitted, then many reasonable and useful usages require more than one domain. Another way to think about this is that it was a flawed idea in the first place that a device is in a domain at all. It is the power interface (or interfaces, for devices which receive supply from more than one) that is in the domain, not the device itself. An interface is more clearly in one domain. Different types of entities (devices, components, power interfaces) have different types of data available, so having domain only in the PI is quite reasonable. Thus, the correct answer to me for domain for a device is either zero or multiple. To recommend one as a compromise seeks OK. For a PI, only a single domain is needed. I second Juergen's line of reasoning that it is quite unnecessary and not justified to make the framework change to single at this time. Thanks, --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 --_000_CF1106A31127E5bradscoraidcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <75BF503485A7464EA86A52C6D28E859D@fwd6.exghost.com> Content-Transfer-Encoding: quoted-printable
HI Thomas,

As Mouli mentioned in a separate email, the use case you mention can b= e address with keywords.  A single domain + keywords gives flexibi= lity in characterizing your environment.  Given this, I think the curr= ent single domain model has shown it address all the specific concerns raised  thus far.

Best Regards,

Brad

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


From: Thomas Dietz <Thomas.Dietz@neclab.eu>
Date: Fri, 31 Jan 2014 08:15:36 = 3;0000
To: Brad Schoening <brads@coraid.com>, Bruce Nordman <bnordman@lbl.gov>, eman mailing list &l= t;eman@ietf.org>
Subject: RE: [eman] WG Last Call fo= r draft-ietf-eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware= -mib-13

Dear Brad, all,<= /p>

 

first of all I second J=FCrgen=92s= view that we should not artificially limit ourselves if there is no techni= cal reason.

 

And what the discussion below show= s is exactly the reason for that. The definition of the domain leaves some = room for interpretation. Thus, IMHO it should be allowed to have an implementation of a domain that allows tha= t objects are part of more than one domain. You could define the domain as = a sort of =93geographical domain=94 and have a building that get controlled= by the owner and some rental units that are controlled by the tenant. This would imply that the same object a= re part of two different domain. And this example would match in my opinion= the definition of domain in the framework document.

 

Best Regards,

 

Thomas

 

--

Thomas Dietz

NEC Europe Ltd., NEC Laboratories,= Network Research Division, 69115 Heidelberg, Germany

 

NEC Europe Limited, Registered in = England 2832014

Registered Office: Athene, Odyssey= Business Park, West End  Road, London, HA4 6QE, GB<= /p>

 

From: eman [mailto:eman-bounces@ietf.org] On Behalf Of Brad Schoening
Sent: Thursday, January 30, 2014 11:08 PM
To: Bruce Nordman; eman mailing list
Subject: Re: [eman] WG Last Call for draft-ietf-eman-energy-monitori= ng-mib-08 and draft-ietf-eman-energy-aware-mib-13

 

"If one uses domain in the recommended= fashion, then a device that receives

power from two sources (each sub-metered) i= s definitely in two different

domains."

 

Or a new domain, which combines the two and= has its own power policy.  In which case, a single domain suits our m= odel quite well.

 

Regards,

 

Brad

 

From: Bruce Nordman <bno= rdman@lbl.gov>
Date: Thu, 30 Jan 2014 13:31:11 -0800
To: eman mailing list <eman@ietf= .org>
Subject: Re: [eman] WG Last Call for draft-ietf-eman-energy-monitori= ng-mib-08 and draft-ietf-eman-energy-aware-mib-13

 

For the Domain issue, I have always believe= d that the Framework draft
did not define the concept well.  Since it is ambiguous in the Framewo= rk,
it is not surprising that we are running into problems with it in later
stages (the MIBs for example).

The current Framework states (6.3.6):

   An Energy Management Domain can be any collection of Energy    Objects in a deployment, but it is recommended to map 1:1
   with a metered or sub-metered portion of the site.

If one uses domain in the recommended fashion, then a device that receives<= br> power from two sources (each sub-metered) is definitely in two different domains.
If one uses it differently, as is permitted, then many reasonable
and useful usages require more than one domain.

Another way to think about this is that it was a flawed idea in
the first place that a device is in a domain at all.  It is the
power interface (or interfaces, for devices which receive supply
from more than one) that is in the domain, not the device itself.
An interface is more clearly in one domain.  Different types of
entities (devices, components, power interfaces) have different
types of data available, so having domain only in the PI is quite
reasonable.

Thus, the correct answer to me for domain for a device is either
zero or multiple.  To recommend one as a compromise seeks OK.
For a PI, only a single domain is needed.

I second Juergen's line of reasoning that it is quite unnecessary
and not justified to make the framework change to single at this time.

Thanks,

--Bruce

--

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

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

--_000_CF1106A31127E5bradscoraidcom_-- From bclaise@cisco.com Fri Jan 31 09:21:24 2014 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11C7F1A0420 for ; Fri, 31 Jan 2014 09:21:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.035 X-Spam-Level: X-Spam-Status: No, score=-10.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Scz-xGPrgmOs for ; Fri, 31 Jan 2014 09:21:21 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id 9530C1A0416 for ; Fri, 31 Jan 2014 09:21:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11143; q=dns/txt; s=iport; t=1391188877; x=1392398477; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=adf86OgFZfkD/6W0bHA5jRHpYN23QsNbN4rwSmjMtSQ=; b=ZfdZTodQnPDfm+r29UNFoJY3yYG3CZJ5GR4Z7QGSdfQMU3ZnYO/NO9oS ImheNVOdZ5F+1oM30lovV79B3XbRPZnDqRpJjHWZy5g8Lyb7MtnYpu7Y+ wiP7NaVE7i8gakIGyaGLkhG+KfyXUl924srP1wuOLMBiIMQo8n6OrKaEg 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFABHb61KQ/khL/2dsb2JhbABWA4MMOL4PgQwWdIIlAQEBBAEBARpRBgQNBAsRBAEBChYEBAcJAwIBAgEVHwkIBgEMBgIBAQWHfA3MdheOLgMBAQEsEhcGC4QnBJgqgTKFFotZgW+BPzuBNQ X-IronPort-AV: E=Sophos;i="4.95,759,1384300800"; d="scan'208,217";a="3821119" Received: from ams-core-2.cisco.com ([144.254.72.75]) by aer-iport-2.cisco.com with ESMTP; 31 Jan 2014 17:21:15 +0000 Received: from [10.60.67.88] (ams-bclaise-8917.cisco.com [10.60.67.88]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s0VHLF03015030; Fri, 31 Jan 2014 17:21:15 GMT Message-ID: <52EBDB8B.2000809@cisco.com> Date: Fri, 31 Jan 2014 18:21:15 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Rolf Winter , Bruce Nordman , eman mailing list References: <9AB93E4127C26F4BA7829DEFDCE5A6E868913FC9@DAPHNIS.office.hd> <4B082FB2-7EDC-4F5C-97B4-AD7027AF88DC@juniper.net> <791AD3077F94194BB2BDD13565B6295D63BA7C48@DAPHNIS.office.hd> In-Reply-To: <791AD3077F94194BB2BDD13565B6295D63BA7C48@DAPHNIS.office.hd> Content-Type: multipart/alternative; boundary="------------040506020906040303050709" Subject: Re: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib-13 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 31 Jan 2014 17:21:24 -0000 This is a multi-part message in MIME format. --------------040506020906040303050709 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, I support the chairs decision based on the following facts, which I mentioned already on the list. EMAN-FRAMEWORK: An Energy Object should be a member of a single Energy Management Domain therefore one attribute is provided. This sentence doesn't reflect what was discussed at http://www.ietf.org/mail-archive/web/eman/current/msg02033.html 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. And, most importantly, http://www.ietf.org/mail-archive/web/eman/current/msg02037.html, which is the outcome of the authors call, supervised by Nevil: *** 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 better 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 The information model is the key part of the framework. The domain was always a string, and is still a string in the latest version. A comma separated value in a string is a pain from a NMS point of view. If we needed a vector, it would have a vector in the information model. This also highlights the discrepancy in the EMAN-FMWK. I understand that this editorial mistake has got some consequences. The EMAN-FRAMEWORK authors are collectively responsible for this mistake. As one of them, sorry. Regards, Benoit > I agree here. I think the changes are a) quite late and b) not in line with the textual description of a domain. Have we gotten the some of the concepts all wrong/ill defined (something that was voiced before on the mailing list)? I am also puzzled about process here. I think in the last meeting I was told that no further changes were allowed (I believe). Now we make further changes. > > NEC Europe Ltd | Registered Office: Athene, Odyssey Business Park, West End Road, London, HA4 6QE, GB | Registered in England 2832014 > > >> -----Original Message----- >> From: eman [mailto:eman-bounces@ietf.org] On Behalf Of Bruce Nordman >> Sent: Donnerstag, 30. Januar 2014 22:31 >> To: eman mailing list >> Subject: Re: [eman] WG Last Call for draft-ietf-eman-energy-monitoring- >> mib-08 and draft-ietf-eman-energy-aware-mib-13 >> >> For the Domain issue, I have always believed that the Framework draft >> did not define the concept well. Since it is ambiguous in the >> Framework, it is not surprising that we are running into problems with >> it in later stages (the MIBs for example). >> >> The current Framework states (6.3.6): >> >> An Energy Management Domain can be any collection of Energy >> Objects in a deployment, but it is recommended to map 1:1 >> with a metered or sub-metered portion of the site. >> >> If one uses domain in the recommended fashion, then a device that >> receives power from two sources (each sub-metered) is definitely in two >> different domains. >> If one uses it differently, as is permitted, then many reasonable and >> useful usages require more than one domain. >> >> Another way to think about this is that it was a flawed idea in the >> first place that a device is in a domain at all. It is the power >> interface (or interfaces, for devices which receive supply from more >> than one) that is in the domain, not the device itself. >> An interface is more clearly in one domain. Different types of >> entities (devices, components, power interfaces) have different types >> of data available, so having domain only in the PI is quite reasonable. >> >> Thus, the correct answer to me for domain for a device is either zero >> or multiple. To recommend one as a compromise seeks OK. >> For a PI, only a single domain is needed. >> >> I second Juergen's line of reasoning that it is quite unnecessary and >> not justified to make the framework change to single at this time. >> >> Thanks, >> >> --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 > . > --------------040506020906040303050709 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Dear all,

I support the chairs decision based on the following facts, which I mentioned already on the list.

EMAN-FRAMEWORK:
        An Energy Object should be a member of a single Energy
        Management Domain therefore one attribute is provided.
This sentence doesn't reflect what was discussed at
http://www.ietf.org/mail-archive/web/eman/current/msg02033.html
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.

And, most importantly, http://www.ietf.org/mail-archive/web/eman/current/msg02037.html, which is the outcome of the authors call, supervised by Nevil:
*** 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 better 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
The information model is the key part of the framework. The domain was always a string, and is still a string in the latest version. A comma separated value in a string is a pain from a NMS point of view.  If we needed a vector, it would have a vector in the information model. This also highlights the discrepancy in the EMAN-FMWK.
I understand that this editorial mistake has got some consequences. The EMAN-FRAMEWORK authors are  collectively responsible for this mistake. As one of them, sorry.

Regards, Benoit
I agree here. I think the changes are a) quite late and b) not in line with the textual description of a domain. Have we gotten the some of the concepts all wrong/ill defined (something that was voiced before on the mailing list)? I am also puzzled about process here. I think in the last meeting I was told that no further changes were allowed (I believe). Now we make further changes. 

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



-----Original Message-----
From: eman [mailto:eman-bounces@ietf.org] On Behalf Of Bruce Nordman
Sent: Donnerstag, 30. Januar 2014 22:31
To: eman mailing list
Subject: Re: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-
mib-08 and draft-ietf-eman-energy-aware-mib-13

For the Domain issue, I have always believed that the Framework draft
did not define the concept well.  Since it is ambiguous in the
Framework, it is not surprising that we are running into problems with
it in later stages (the MIBs for example).

The current Framework states (6.3.6):

   An Energy Management Domain can be any collection of Energy
   Objects in a deployment, but it is recommended to map 1:1
   with a metered or sub-metered portion of the site.

If one uses domain in the recommended fashion, then a device that
receives power from two sources (each sub-metered) is definitely in two
different domains.
If one uses it differently, as is permitted, then many reasonable and
useful usages require more than one domain.

Another way to think about this is that it was a flawed idea in the
first place that a device is in a domain at all.  It is the power
interface (or interfaces, for devices which receive supply from more
than one) that is in the domain, not the device itself.
An interface is more clearly in one domain.  Different types of
entities (devices, components, power interfaces) have different types
of data available, so having domain only in the PI is quite reasonable.

Thus, the correct answer to me for domain for a device is either zero
or multiple.  To recommend one as a compromise seeks OK.
For a PI, only a single domain is needed.

I second Juergen's line of reasoning that it is quite unnecessary and
not justified to make the framework change to single at this time.

Thanks,

--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
.

--------------040506020906040303050709-- From bclaise@cisco.com Fri Jan 31 09:32:55 2014 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B8181A03E7 for ; Fri, 31 Jan 2014 09:32:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.036 X-Spam-Level: X-Spam-Status: No, score=-10.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Hq2KgAGGHfI for ; Fri, 31 Jan 2014 09:32:53 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id C4FFD1A0367 for ; Fri, 31 Jan 2014 09:32:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7402; q=dns/txt; s=iport; t=1391189569; x=1392399169; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=NVNnXzdQU5q6oeA9qq+u7f5JCfuc1aXl1TrebYuA64A=; b=LiRFpFBrwZtlpzcb+vpFKHdH/j+58NyhccljfH6cDq+HI1Hg+zDifcds 0F9mK6vEd72EJoIvbd+r5rBKLlDWjCUXURvog+NCx0b2yzp3Nvwy6aomR X4h5GQOc1tahnAB9Le6tZpCeMSF1PXJ+riUxWmnDrB+FMXdaSEcfmSu3x s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFAC7d61KQ/khR/2dsb2JhbABZgww4vg+BDBZ0giUBAQEEAQEBGhUBBTYDBw0ECxEEAQEBCRYEBAcJAwIBAgEVHwkIBgEMBgIBAYgBDcx4EwSOIAoHAQJVBoQyBJRCg2iGSItZgW+BPzuBLAkX X-IronPort-AV: E=Sophos;i="4.95,759,1384300800"; d="scan'208";a="4490229" Received: from ams-core-1.cisco.com ([144.254.72.81]) by aer-iport-1.cisco.com with ESMTP; 31 Jan 2014 17:32:48 +0000 Received: from [10.60.67.88] (ams-bclaise-8917.cisco.com [10.60.67.88]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s0VHWl7e030785; Fri, 31 Jan 2014 17:32:48 GMT Message-ID: <52EBDE3F.9050708@cisco.com> Date: Fri, 31 Jan 2014 18:32:47 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Juergen Quittek , Thomas Nadeau , eman mailing list References: <9AB93E4127C26F4BA7829DEFDCE5A6E868913FC9@DAPHNIS.office.hd> In-Reply-To: <9AB93E4127C26F4BA7829DEFDCE5A6E868913FC9@DAPHNIS.office.hd> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib-13 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 31 Jan 2014 17:32:55 -0000 Hi Jürgen, I would appreciate if you could stop referring to EnergyWise limitations, as this is a false statement. True, we have implementations: that project started in 2008. The tech lead for that project asked all of our partners (more than 100), and nobody wanted to have one device or energy objects part of one device (such as power supply) in multiple Energy Management Domains. So 6 years of experience and many implementations showed us it doesn't make sense. It's like we would manage line card 1 with snmp string1, and line card 2 with snmp string2. In EMAN, this could be done these days with the keywords. Regards, Benoit > Hi Tom, > > You are right. This is really comes as a surprise. > I have an objection. Please see my reasons below. > > 0. (just formal) You ask for changing the framework draft in an email that has two drafts in the subject line, but not the framework draft. A clearer indication of this email would have been particularly recommendable, since you told us at the last meeting that you are not willing to accept further change requests to this draft. > > 1. Having a device limited to a single domain membership is a limitation/feature of Cisco's EnergyWise for which in all the long discussions we had in past year never any technical reason was given (although it was asked for multiple times). > In the contrary, I gave use cases where it is REQUIRED to have two or more domains. An obvious example is a highly reliable server that has dual power supply. Its two power supply lines SHOULD be in different domains in order to be better protected from local power supply failures. This server should be given means to report via the MIB that it is member of two domains. > > 2. The compromise we had was RECOMMENDING to use the same limitation as EnergyWise has it even though we know other systems do not have that limitations and even though technical reason exists rather against the limitation than for it. The proposed change to MUST makes all other (potentially superior) approaches violating the standard. Why shall we do so without ANY technical reason? What would be the reason for such a decision? > > 3. The suggestion I made does NOT require any modifications of existing SNMP agents that implement one of the recent versions of the MIB modules in draft-ietf-eman-energy-aware-mib. It also does not affect any code transmitting information using the EMAN information model as specified in the framework. The domain information is still kept in a single string. It only gives a little bit of freedom to how this string can be interpreted when processing it, particularly when writing it to a management data base supporting either single or multiple domains per device. > > 4. To make the story even more surprising, the concept of a "domain" is not defined in a very interoperable way. The framework does not give the concept of a domain any more semantics than > "An Energy Management Domain can be any collection of Energy Objects in a deployment." > How to structure domains is completely left to the operator. Why are we on one hand so open with the semantics of a "domain" and on the other hand so strict when it comes to the number of domain memberships an energy object may have? > > 5. You say you request the change to keep the ball rolling. But you propose the opposite: to make a step back to the already closed framework draft and open it again. The way to keep the ball rolling would be to just apply changes to the still open documents we are currently discussing. > > Juergen > > >> -----Original Message----- >> From: Thomas Nadeau [mailto:tnadeau@lucidvision.com] >> Sent: Dienstag, 28. Januar 2014 16:04 >> To: Brad Schoening >> Cc: Juergen Quittek; eman mailing list >> Subject: Re: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib- >> 08 and draft-ietf-eman-energy-aware-mib-13 >> >> >> Hi Brad/EMAN WG, >> >> As both Nevil and I noted yesterday, we both consider that there is >> sufficient consensus to have the Framework changed so that using a single >> Energy Management Domain is written as a MUST in the documents. As chairs >> we are directing the editors of the draft to please make this change so that >> the MIBs and the Framework will be aligned. >> >> We both I understand that it is very, very late in the game to make this >> change, but this needs to happen to keep the ball rolling forward for EMAN >> and all of the existing implementations. Under the circumstances, we also >> understand that this might have taken people by surprise, and thus while we >> do not want to re-open the debate/discussion that happened around this >> issue a while back now, we would still like to ask the WG if anyone on the >> EMAN list has a strong objection to this change or how it should be made to >> the drafts. Please chime in ASAP. If we do not hear anything by Friday, January >> 31, 2014 at 8AM EDT, we will proceed forward as directed. >> >> --Tom >> >> >> On Jan 28, 2014:12:52 AM, at 12:52 AM, Brad Schoening >> wrote: >> >>> >>> I've updated the doc to address Juergen's 2nd point. But, is there >>> consensus on MUST vs SHOULD for Entity MIB support? >>> >>> >>> >>> On 12/30/13 2:33 PM, "Juergen Quittek" wrote: >>> >>>> Dear all, >>>> >>>> Here are my last two comments for this WGLC. Both concerns the >>>> conformance section of the ENERGY-OBJECT-MIB module in >>>> draft-ietf-eman-energy-monitoring-mib-08: >>>> >>>> 1. I may have missed a point here: Why is the Entity MIB not >>>> mandatory anymore to implement? It is just two additional objects, >>>> since entPhysicalIndex from this MIB is needed anyway. Particularly, >>>> we considered the UUID provided by this MIB essential for our framework. >>>> >>>> 2. Why is the module compliance dependency on the Entity MIB repeated >>>> in the DESCRIPTION clauses of all optional groups within a >>>> MODULE-COMPLIANCE declaration? I think It is fully sufficient to have >>>> it stated in the top DESCRIPTION clause of the MODULE-COMPLIANCE >>>> declaration. Does it make any sense to repeat it for optional groups? >>>> >>>> Cheers, >>>> Juergen >>>> >>>> >>>>> -----Original Message----- >>>>> From: eman [mailto:eman-bounces@ietf.org] On Behalf Of Thomas >> Nadeau >>>>> Sent: Montag, 16. Dezember 2013 16:56 >>>>> To: eman mailing list >>>>> Subject: [eman] WG Last Call for >>>>> draft-ietf-eman-energy-monitoring-mib-08 >>>>> and draft-ietf-eman-energy-aware-mib-13 >>>>> >>>>> >>>>> As agreed at the last WG meeting, with the EMAN Framework >>>>> completing its WG LC the chairs would like to initiate a WG LC on >>>>> draft-ietf- >>>>> eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib- >> 13. >>>>> The WG LC will end on Dec 30 at 8AM EDT. >>>>> >>>>> Thank you, >>>>> >>>>> Nevil and Tom >>>>> >>>> _______________________________________________ >>>> 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 > . >