From chrisv@cyberswitching.com Wed Feb 23 21:11:59 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D1B03A69A6 for ; Wed, 23 Feb 2011 21:11:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.766 X-Spam-Level: X-Spam-Status: No, score=-5.766 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_ASCII_ART_SPACINGc=0.833, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ek04pZjWVhtw for ; Wed, 23 Feb 2011 21:11:54 -0800 (PST) Received: from p01c12o142.mxlogic.net (p01c12o142.mxlogic.net [208.65.145.65]) by core3.amsl.com (Postfix) with ESMTP id AD9B73A69B9 for ; Wed, 23 Feb 2011 21:11:52 -0800 (PST) Received: from unknown [207.47.28.34] (EHLO mail03.cyberswitching.local) by p01c12o142.mxlogic.net(mxl_mta-6.9.0-1) with ESMTP id 8c8e56d4.0.58485.00-363.104356.p01c12o142.mxlogic.net (envelope-from ); Wed, 23 Feb 2011 22:12:41 -0700 (MST) X-MXL-Hash: 4d65e8c94872d2b4-221ebd046374ca333b88666642d3c07c9371c762 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CBD3E1.553D1092" Date: Wed, 23 Feb 2011 21:11:45 -0800 Message-ID: <68FBE0F3CE97264395875AC1C468F22CECD6D2@mail03.cyberswitching.local> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Draft proposal for consideration at upcoming meeting Thread-Index: AcvT33ahNQArPQpQQTqqr3Y4tSG4+Q== From: "Chris Verges" To: X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [207.47.28.34] X-AnalysisOut: [v=1.0 c=1 a=hefADBN2CKkA:10 a=BLceEmwcHowA:10 a=1Eql4bHns2] X-AnalysisOut: [NoxN2V9ejGkg==:17 a=rtnlvjx5aC94Lh3nD_cA:9 a=DK_ZniTqllOWq] X-AnalysisOut: [fnroM0A:7 a=Q9fxj2G9kh2xEuOk28a5Dca1gP0A:4 a=CjuIK1q_8ugA:] X-AnalysisOut: [10 a=48vgC7mUAAAA:8 a=wzgqfsuUAAAA:8 a=rqrk_YMJAAAA:8 a=iG] X-AnalysisOut: [bCS3zQAAAA:8 a=IGgMue6PAAAA:8 a=o1s277WF0uHrvBUuwwEA:9 a=U] X-AnalysisOut: [-fwIxEV67xlEZx6nQYA:7 a=C9dT_RXk-puoQbLCeeHbUulqU0MA:4 a=d] X-AnalysisOut: [PUdj-Wgp4EA:10 a=Xaae3rE281oA:10 a=S1v_fH3hkpUA:10 a=fMlXq] X-AnalysisOut: [2aaNVkA:10 a=yvfu_RGVus0A:10 a=LeoLkt2gfmojbtW5:21 a=A6ucp] X-AnalysisOut: [_ue1O-0xVS7:21] Subject: [eman] Draft proposal for consideration at upcoming meeting X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2011 05:11:59 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBD3E1.553D1092 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, The eman mailing list has been silent for several weeks now, and I began to wonder whether the existing proposals were continuing to be developed and changed based on the objections and feedback noted on the mailing list and from the Beijing meeting last year. As an implementer, the current drafts raise some serious concerns about both usability and maintainability going forward. (These concerns are documented in the attached document.) Attached is a new draft for the agenda at the upcoming Prague meeting. This new document aims to combine the best aspects of the existing proposals into a single document and to create a new schema that should be more workable for a wider variety of entities (servers, switches, PDUs, etc.) It was easier to write a new draft than to try and change the original ones. I will be unable to attend Prague in person due to other work commitments, but will attend virtually via the Jabber session. If someone familiar with the working group's proceedings could please let me know what is needed to proceed under these conditions, I would be most appreciative. Thanks, Chris ------_=_NextPart_001_01CBD3E1.553D1092 Content-Type: text/plain; name="draft-verges-eman-separate-modules-mib-00.txt" Content-Transfer-Encoding: base64 Content-Description: draft-verges-eman-separate-modules-mib-00.txt Content-Disposition: attachment; filename="draft-verges-eman-separate-modules-mib-00.txt" CgoKRW5lcmd5IE1hbmFnZW1lbnQgV29ya2luZyBHcm91cCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgQy4gVmVyZ2VzCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIEN5YmVyIFN3aXRjaGluZywgSW5jLgpJbnRlbmRlZCBzdGF0dXM6IFN0YW5k YXJkcyBUcmFjayAgICAgICAgICAgICAgICAgICAgICAgRmVicnVhcnkgMjMsIDIwMTEKRXhwaXJl czogQXVndXN0IDI3LCAyMDExCgoKIEVuZXJneSBNb25pdG9yaW5nIGFuZCBNYW5hZ2VtZW50IG9m IE5ldHdvcmtlZCBFbnRpdGllcyB1c2luZyBTTk1QIGFuZAogICAgICAgICAgICAgICAgICAgICAg Um9sZS1TcGVjaWZpYyBTcGFyc2UgVGFibGVzCiAgICAgICAgICAgICAgIGRyYWZ0LXZlcmdlcy1l bWFuLXNlcGFyYXRlLW1vZHVsZXMtbWliLTAwCgpBYnN0cmFjdAoKICAgVGhpcyBkb2N1bWVudCBk ZWZpbmVzIGEgc3Vic2V0IG9mIHRoZSBNYW5hZ2VtZW50IEluZm9ybWF0aW9uIEJhc2UKICAgKE1J QikgZm9yIHBvd2VyIGFuZCBlbmVyZ3kgbW9uaXRvcmluZyBvZiBkZXZpY2VzLiAgVGhlIG1vZHVs ZQogICBhZGRyZXNzZXMgZGV2aWNlcyBpZGVudGlmaWNhdGlvbiwgY29udGV4dCBpbmZvcm1hdGlv biwgYW5kIHRoZQogICByZWxhdGlvbnNoaXAgYmV0d2VlbiByZXBvcnRpbmcgZGV2aWNlcywgcmVt b3RlIGRldmljZXMsIGFuZAogICBtb25pdG9yaW5nIHByb2Jlcy4KCiAgIFRoaXMgbWVtbyBkZWZp bmVzIGEgcG9ydGlvbiBvZiB0aGUgTWFuYWdlbWVudCBJbmZvcm1hdGlvbiBCYXNlIChNSUIpCiAg IGZvciB1c2Ugd2l0aCBuZXR3b3JrIG1hbmFnZW1lbnQgcHJvdG9jb2xzLiAgSW4gcGFydGljdWxh ciBpdCBkZWZpbmVzCiAgIG9iamVjdHMgZm9yIG1hbmFnaW5nIHRoZSBwb3dlciB1c2FnZSBvZiBh IG5ldHdvcmsgZW50aXR5LgoKICAgVGhlIGVuZXJneSBtYW5hZ2VtZW50IHNjaGVtYSBpcyBzcGxp dCBpbnRvIG9uZSBjb3JlIHRhYmxlIHRvCiAgIGVudW1lcmF0ZSB0aGUgZW50aXRpZXMgYmVpbmcg bWFuYWdlZCBhbmQgbnVtZXJvdXMgc3BhcnNlIHRhYmxlCiAgIGV4dGVuc2lvbnMgdGhhdCBhZGQg cm9sZS1zcGVjaWZpYyBmdW5jdGlvbmFsaXR5IHdoZXJlIGFwcHJvcHJpYXRlLgoKU3RhdHVzIG9m IFRoaXMgTWVtbwoKICAgVGhpcyBJbnRlcm5ldC1EcmFmdCBpcyBzdWJtaXR0ZWQgaW4gZnVsbCBj b25mb3JtYW5jZSB3aXRoIHRoZQogICBwcm92aXNpb25zIG9mIEJDUCA3OCBhbmQgQkNQIDc5LgoK ICAgSW50ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5nIGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQg RW5naW5lZXJpbmcKICAgVGFzayBGb3JjZSAoSUVURikuICBOb3RlIHRoYXQgb3RoZXIgZ3JvdXBz IG1heSBhbHNvIGRpc3RyaWJ1dGUKICAgd29ya2luZyBkb2N1bWVudHMgYXMgSW50ZXJuZXQtRHJh ZnRzLiAgVGhlIGxpc3Qgb2YgY3VycmVudCBJbnRlcm5ldC0KICAgRHJhZnRzIGlzIGF0IGh0dHA6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kcmFmdHMvY3VycmVudC8uCgogICBJbnRlcm5ldC1EcmFm dHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBtYXhpbXVtIG9mIHNpeCBtb250aHMK ICAgYW5kIG1heSBiZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90aGVyIGRv Y3VtZW50cyBhdCBhbnkKICAgdGltZS4gIEl0IGlzIGluYXBwcm9wcmlhdGUgdG8gdXNlIEludGVy bmV0LURyYWZ0cyBhcyByZWZlcmVuY2UKICAgbWF0ZXJpYWwgb3IgdG8gY2l0ZSB0aGVtIG90aGVy IHRoYW4gYXMgIndvcmsgaW4gcHJvZ3Jlc3MuIgoKICAgVGhpcyBJbnRlcm5ldC1EcmFmdCB3aWxs IGV4cGlyZSBvbiBBdWd1c3QgMjcsIDIwMTEuCgpDb3B5cmlnaHQgTm90aWNlCgogICBDb3B5cmln aHQgKGMpIDIwMTEgSUVURiBUcnVzdCBhbmQgdGhlIHBlcnNvbnMgaWRlbnRpZmllZCBhcyB0aGUK ICAgZG9jdW1lbnQgYXV0aG9ycy4gIEFsbCByaWdodHMgcmVzZXJ2ZWQuCgoKCgpWZXJnZXMgICAg ICAgICAgICAgICAgICAgRXhwaXJlcyBBdWd1c3QgMjcsIDIwMTEgICAgICAgICAgICAgICAgW1Bh Z2UgMV0KDApJbnRlcm5ldC1EcmFmdCAgZHJhZnQtdmVyZ2VzLWVtYW4tc2VwYXJhdGUtbW9kdWxl cy1taWItMDAgIEZlYnJ1YXJ5IDIwMTEKCgogICBUaGlzIGRvY3VtZW50IGlzIHN1YmplY3QgdG8g QkNQIDc4IGFuZCB0aGUgSUVURiBUcnVzdCdzIExlZ2FsCiAgIFByb3Zpc2lvbnMgUmVsYXRpbmcg dG8gSUVURiBEb2N1bWVudHMKICAgKGh0dHA6Ly90cnVzdGVlLmlldGYub3JnL2xpY2Vuc2UtaW5m bykgaW4gZWZmZWN0IG9uIHRoZSBkYXRlIG9mCiAgIHB1YmxpY2F0aW9uIG9mIHRoaXMgZG9jdW1l bnQuICBQbGVhc2UgcmV2aWV3IHRoZXNlIGRvY3VtZW50cwogICBjYXJlZnVsbHksIGFzIHRoZXkg ZGVzY3JpYmUgeW91ciByaWdodHMgYW5kIHJlc3RyaWN0aW9ucyB3aXRoIHJlc3BlY3QKICAgdG8g dGhpcyBkb2N1bWVudC4gIENvZGUgQ29tcG9uZW50cyBleHRyYWN0ZWQgZnJvbSB0aGlzIGRvY3Vt ZW50IG11c3QKICAgaW5jbHVkZSBTaW1wbGlmaWVkIEJTRCBMaWNlbnNlIHRleHQgYXMgZGVzY3Jp YmVkIGluIFNlY3Rpb24gNC5lIG9mCiAgIHRoZSBUcnVzdCBMZWdhbCBQcm92aXNpb25zIGFuZCBh cmUgcHJvdmlkZWQgd2l0aG91dCB3YXJyYW50eSBhcwogICBkZXNjcmliZWQgaW4gdGhlIFNpbXBs aWZpZWQgQlNEIExpY2Vuc2UuCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK CgoKClZlcmdlcyAgICAgICAgICAgICAgICAgICBFeHBpcmVzIEF1Z3VzdCAyNywgMjAxMSAgICAg ICAgICAgICAgICBbUGFnZSAyXQoMCkludGVybmV0LURyYWZ0ICBkcmFmdC12ZXJnZXMtZW1hbi1z ZXBhcmF0ZS1tb2R1bGVzLW1pYi0wMCAgRmVicnVhcnkgMjAxMQoKClRhYmxlIG9mIENvbnRlbnRz CgogICAxLiAgSW50cm9kdWN0aW9uIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gIDQKICAgMi4gIEVuZXJneSBNYW5hZ2VtZW50IERvY3VtZW50IE92ZXJ2 aWV3ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA0CiAgIDMuICBSZWxhdGlvbnNoaXAgdG8g T3RoZXIgRU1BTiBQcm9wb3NhbHMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNQogICA0LiAg VGhlIEludGVybmV0LVN0YW5kYXJkIE1hbmFnZW1lbnQgRnJhbWV3b3JrIC4gLiAuIC4gLiAuIC4g LiAuIC4gIDgKICAgNS4gIENvbnZlbnRpb25zICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuICA4CiAgIDYuICBTdHJ1Y3R1cmUgb2YgdGhlIEVNQU4tQ09S RS1NSUIgTW9kdWxlICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgOAogICAgIDYuMS4gIFRleHR1 YWwgQ29udmVudGlvbnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDgK ICAgICAgIDYuMS4xLiAgRW1hbkVudGl0eVJvbGUgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuICA4CiAgICAgICA2LjEuMi4gIEVtYW5FbnRpdHlDYXBhYmlsaXRpZXMgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgOAogICAgICAgNi4xLjMuICBUaG91c2FuZHRo cyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDkKICAgICAgIDYu MS40LiAgVW5pdE11bHRpcGxpZXIgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuICA5CiAgICAgNi4yLiAgVGhlIE5vdGlmaWNhdGlvbnMgU3VidHJlZSAgLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAgOQogICAgIDYuMy4gIFRoZSBUYWJsZSBTdHJ1Y3R1cmVzIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDkKICAgNy4gIFN0cnVjdHVyZSBv ZiB0aGUgRU1BTi1EQVRBLU1JQiBNb2R1bGUgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDEwCiAg ICAgNy4xLiAgVGV4dHVhbCBDb252ZW50aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAxMQogICAgIDcuMi4gIFRoZSBOb3RpZmljYXRpb25zIFN1YnRyZWUgIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTEKICAgICA3LjMuICBUaGUgVGFibGUgU3RydWN0 dXJlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDExCiAgIDguICBTdHJ1 Y3R1cmUgb2YgdGhlIEVNQU4tQ09OVFJPTC1NSUIgTW9kdWxlIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAxMgogICAgIDguMS4gIFRleHR1YWwgQ29udmVudGlvbnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gMTIKICAgICA4LjIuICBUaGUgTm90aWZpY2F0aW9ucyBTdWJ0cmVl ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDEyCiAgICAgOC4zLiAgVGhlIFRhYmxl IFN0cnVjdHVyZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMgogICA5 LiAgU3RydWN0dXJlIG9mIHRoZSBFTUFOLUNPTlRFWFQtTUlCIE1vZHVsZSAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gMTMKICAgICA5LjEuICBUZXh0dWFsIENvbnZlbnRpb25zICAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDEzCiAgICAgOS4yLiAgVGhlIE5vdGlmaWNhdGlvbnMg U3VidHJlZSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMwogICAgIDkuMy4gIFRo ZSBUYWJsZSBTdHJ1Y3R1cmVzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g MTMKICAgMTAuIFN0cnVjdHVyZSBvZiB0aGUgRU1BTi1IRUFMVEgtTUlCIE1vZHVsZSAgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIDE0CiAgICAgMTAuMS4gVGV4dHVhbCBDb252ZW50aW9ucyAgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxNAogICAgIDEwLjIuIFRoZSBOb3RpZmlj YXRpb25zIFN1YnRyZWUgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTQKICAgICAx MC4zLiBUaGUgVGFibGUgU3RydWN0dXJlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIDE0CiAgIDExLiBTdHJ1Y3R1cmUgb2YgdGhlIEVNQU4tTExEUC1NSUIgTW9kdWxlICAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxNAogICAgIDExLjEuIFRleHR1YWwgQ29udmVudGlvbnMg IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTQKICAgICAxMS4yLiBUaGUg Tm90aWZpY2F0aW9ucyBTdWJ0cmVlICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE0 CiAgICAgMTEuMy4gVGhlIFRhYmxlIFN0cnVjdHVyZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAxNAogICAxMi4gUmVsYXRpb25zaGlwIHRvIE90aGVyIE1JQiBNb2R1bGVz ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTQKICAgICAxMi4xLiBSZWxhdGlvbnNoaXAg dG8gdGhlIFtURU1QTEFURSBUT0RPXSBNSUIgIC4gLiAuIC4gLiAuIC4gLiAuIDE1CiAgICAgMTIu Mi4gTUlCIG1vZHVsZXMgcmVxdWlyZWQgZm9yIElNUE9SVFMgLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAxNQogICAxMy4gRGVmaW5pdGlvbnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gMTUKICAgMTQuIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zICAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDM0CiAgIDE1LiBJQU5BIENvbnNp ZGVyYXRpb25zICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAzNQog ICAxNi4gQ29udHJpYnV0b3JzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gMzUKICAgMTcuIFJlZmVyZW5jZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDM1CiAgICAgMTcuMS4gTm9ybWF0aXZlIFJlZmVy ZW5jZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAzNQogICAgIDE3LjIu IEluZm9ybWF0aXZlIFJlZmVyZW5jZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gMzYKICAgICAxNy4zLiBVUkwgUmVmZXJlbmNlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIDM3CiAgIEFwcGVuZGl4IEEuICBBY2tub3dsZWRnZW1lbnRzICAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAzNwoKCgoKVmVyZ2VzICAgICAgICAg ICAgICAgICAgIEV4cGlyZXMgQXVndXN0IDI3LCAyMDExICAgICAgICAgICAgICAgIFtQYWdlIDNd CgwKSW50ZXJuZXQtRHJhZnQgIGRyYWZ0LXZlcmdlcy1lbWFuLXNlcGFyYXRlLW1vZHVsZXMtbWli LTAwICBGZWJydWFyeSAyMDExCgoKMS4gIEludHJvZHVjdGlvbgoKICAgVGhpcyBtZW1vIGRlZmlu ZXMgYSBwb3J0aW9uIG9mIHRoZSBNYW5hZ2VtZW50IEluZm9ybWF0aW9uIEJhc2UgKE1JQikKICAg Zm9yIHVzZSB3aXRoIG5ldHdvcmsgbWFuYWdlbWVudCBwcm90b2NvbHMgZm9yIHBvd2VyIGFuZCBl bmVyZ3kKICAgbW9uaXRvcmluZyBvZiBuZXR3b3JrIGRldmljZXMgYW5kIGRldmljZXMgYXR0YWNo ZWQgdG8gdGhlIG5ldHdvcmssIGFzCiAgIHNwZWNpZmllZCBpbiBFbmVyZ3kgTWFuYWdlbWVudCBG cmFtZXdvcmsgW0VNQU4tRk1XS10sIHdoaWNoIGluIHR1cm4sCiAgIGlzIGJhc2VkIG9uIFJlcXVp cmVtZW50cyBmb3IgUG93ZXIgTW9uaXRvcmluZyBbRU1BTi1SRVFdLgoKICAgVGhpcyBtb2R1bGUn cyBzcGVjaWFsIGZvY3VzIGlzIG9uIG1vbml0b3JpbmcgZW5lcmd5LWF3YXJlIG5ldHdvcmtzCiAg IGFuZCBkZXZpY2VzLiAgVGhlIG1vZHVsZSBhZGRyZXNzZXMgZW51bWVyYXRpb24gb2YgdGhlIGVu dGl0aWVzIGJlaW5nCiAgIG1hbmFnZWQsIHJlcG9ydGluZyBvZiBlbmVyZ3kgZGF0YSwgY29udHJv bCBvZiB0aGUgcG93ZXIgc3RhdGUsCiAgIG1hcHBpbmcgdG8gcGh5c2ljYWwgYW5kIGxvZ2ljYWwg KGJ1c2luZXNzKSBjb250ZXh0cywgYW5kIG1vbml0b3JpbmcKICAgb2Ygc2VsZi1yZXBvcnRlZCBo ZWFsdGguCgoyLiAgRW5lcmd5IE1hbmFnZW1lbnQgRG9jdW1lbnQgT3ZlcnZpZXcKCiAgIFRoZSBF TUFOIHN0YW5kYXJkcyBwcm92aWRlcyBuZXR3b3JrIGFkbWluaXN0cmF0b3JzIHdpdGggZW5lcmd5 CiAgIG1hbmFnZW1lbnQuICBUaGlzIGRvY3VtZW50IGlzIGJhc2VkIG9uIEVuZXJneSBNYW5hZ2Vt ZW50IEZyYW1ld29yawogICBbRU1BTi1GTVdLXSwgd2hpY2ggaW4gdHVybiwgaXMgYmFzZWQgb24g UmVxdWlyZW1lbnRzIGZvciBQb3dlcgogICBNb25pdG9yaW5nIFtFTUFOLVJFUV0uCgogICBUaGUg RU1BTi1NSUIgY29udGFpbnMgZml2ZSBrZXkgc3Vic2NoZW1hcyB3aGljaCBhcmUgZ2l2ZW4gdGhl aXIgb3duCiAgIHJlZmVyZW5jZXMgZm9yIGRpc2N1c3Npb24gcHVycG9zZXM6IEVNQU4tQ09SRS1N SUIsIEVNQU4tREFUQS1NSUIsCiAgIEVNQU4tQ09OVFJPTC1NSUIsIEVNQU4tQ09OVEVYVC1NSUIs IGFuZCBFTUFOLUxMRFAtTUlCLgoKICAgICAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0t LS0tLS0tLS0rCiAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IEVNQU4tQ09SRS1NSUIgfAog ICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLSsKICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgfAogICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLSsgICAg ICAgICB8ICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLSsKICAgICAgICAgIHwgRU1BTi1EQVRB LU1JQiB8LS0tLS0tLS0tKy0tLS0tLS0tLXwgRU1BTi1DT05UUk9MLU1JQiB8CiAgICAgICAgICAr LS0tLS0tLS0tLS0tLS0tKyAgICAgICAgIHwgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tKwog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICAgICAgICArLS0tLS0tLS0t LS0tLS0tKyAgICAgICAgIHwgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tKwogICAgICAgICAg fCBFTUFOLUxMRFAtTUlCIHwtLS0tLS0tLS0rLS0tLS0tLS0tfCBFTUFOLUNPTlRFWFQtTUlCIHwK ICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0rICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0t LS0tLS0tLS0rCgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBGaWd1cmUgMQoKICAg VGhlIENvcmUgTUlCIFtFTUFOLUNPUkUtTUlCXSBkZXNjcmliZWQgaW4gU2VjdGlvbiA2IGNvbnRh aW5zIHRoZSBjb3JlCiAgIGxpc3Qgb2YgZW50aXRpZXMgdGhhdCBhcmUgdG8gYmUgbWFuYWdlZCB1 c2luZyB0aGUgcmVzdCBvZiB0aGlzCiAgIGZyYW1ld29yay4gIEl0IGlzIHNlcGFyYXRlZCBmcm9t IGFueSByb2xlLXNwZWNpZmljIGZ1bmN0aW9uYWxpdHkgc28KICAgdGhhdCB2ZW5kb3Itc3BlY2lm aWMgZXh0ZW5zaW9ucyBhbmQgb3RoZXIgZnV0dXJlIGV4dGVuc2lvbnMgbWF5IGJlCiAgIGRldmVs b3BlZCBpbmRlcGVuZGVudCBmcm9tIHRoZSBjb3JlIGluZGV4LgoKICAgVGhlIEVuZXJneSBEYXRh IE1JQiBbRU1BTi1EQVRBLU1JQl0gZGVzY3JpYmVkIGluIFNlY3Rpb24gNyBjb250YWlucwogICB0 aGUgcm9sZS1zcGVjaWZpYyBleHRlbnNpb25zIG5lZWRlZCB0byByZXBvcnQgcG93ZXIgYW5kIGVu ZXJneSB1c2FnZQogICBmb3IgYW4gZW50aXR5LiAgVGhpcyBNSUIgcHJvdmlkZXMgdGhlIGRldGFp bGVkIHByb3BlcnRpZXMgb2YgdGhlCgoKClZlcmdlcyAgICAgICAgICAgICAgICAgICBFeHBpcmVz IEF1Z3VzdCAyNywgMjAxMSAgICAgICAgICAgICAgICBbUGFnZSA0XQoMCkludGVybmV0LURyYWZ0 ICBkcmFmdC12ZXJnZXMtZW1hbi1zZXBhcmF0ZS1tb2R1bGVzLW1pYi0wMCAgRmVicnVhcnkgMjAx MQoKCiAgIGFjdHVhbCBlbmVyZ3kgcmF0ZSAocG93ZXIpIGFuZCBvZiBhY2N1bXVsYXRlZCBlbmVy Z3ksIGFsb25nIHdpdGggdGhlCiAgIHBvd2VyIHF1YWxpdHkuICBFTUFOLURBVEEtTUlCIGlzIGEg c3BhcnNlLXRhYmxlIGV4dGVuc2lvbiB0byBFTUFOLQogICBDT1JFLU1JQi4KCiAgIFRoZSBFbmVy Z3kgQ29udHJvbCBNSUIgW0VNQU4tQ09OVFJPTC1NSUJdIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDgK ICAgY29udGFpbnMgdGhlIHJvbGUtc3BlY2lmaWMgZXh0ZW5zaW9ucyBuZWVkZWQgdG8gbW9uaXRv ciBhbmQgY29udHJvbAogICBwb3dlciBzdGF0ZXMgZm9yIGFuIGVudGl0eS4gIFRoaXMgTUlCIHBy b3ZpZGVzIHRoZSBjdXJyZW50IHBvd2VyCiAgIHN0YXRlLCBwb3dlciBzdGF0ZSB0cmFuc2l0aW9u cywgYW5kIHBvd2VyIHN0YXRlIHN0YXRpc3RpY3MuCgogICBUaGUgRW5lcmd5IENvbnRleHQgTUlC IFtFTUFOLUNPTlRFWFQtTUlCXSBkZXNjcmliZWQgaW4gU2VjdGlvbiA5CiAgIGNvbnRhaW5zIHRo ZSByb2xlLXNwZWNpZmljIGV4dGVuc2lvbnMgbmVlZGVkIHRvIGVzdGFibGlzaCBwaHlzaWNhbAog ICBhbmQgbG9naWNhbCAoYnVzaW5lc3MpIGNvbnRleHQgZm9yIGFuIGVudGl0eS4gIFRoaXMgTUlC IHByb3ZpZGVzIGEKICAgZ2VuZXJpYyBtZWNoYW5pc20gdG8gY3JlYXRlIGEgY2xhc3NpZmljYXRp b24gY2F0ZWdvcnksIG1hcCBlbnRpdGllcwogICBpbnRvIHRoZSBwcm9wZXIgY2F0ZWdvcmllcywg YW5kIGFzc29jaWF0ZSBwcmljaW5nIGRhdGEgd2l0aCBlYWNoCiAgIGNhdGVnb3J5LgoKICAgVGhl IEVuZXJneSBMTERQIE1JQiBbRU1BTi1MTERQLU1JQl0gZGVzY3JpYmVkIGluIFNlY3Rpb24gMTEg Y29udGFpbnMKICAgdGhlIHJvbGUtc3BlY2lmaWMgZXh0ZW5zaW9ucyBuZWVkZWQgdG8gbGluayB0 aGUgZW50aXR5IHdpdGggaXRzCiAgIGFzc29jaWF0ZWQgTGluayBMYXllciBEaXNjb3ZlcnkgUHJv dG9jb2wgKExMRFApIGluZm9ybWF0aW9uLgoKMy4gIFJlbGF0aW9uc2hpcCB0byBPdGhlciBFTUFO IFByb3Bvc2FscwoKICAgQXQgdGhlIHRpbWUgb2YgdGhpcyB3cml0aW5nLCB0d28gb3RoZXIgTUlC IGRyYWZ0cyBhcmUgYmVpbmcKICAgY29uc2lkZXJlZCBieSB0aGUgRU1BTiB3b3JraW5nIGdyb3Vw OiBbUEFSRUxMT10vW0NMQUlTRV0gYW5kCiAgIFtRVUlUVEVLXS4gIFRoZSBNSUIgcHJvcG9zZWQg aGVyZSBjb21iaW5lcyBhc3BlY3RzIG9mIGJvdGggaW4gYSBtb3JlCiAgIGdlbmVyaWMgc3RydWN0 dXJlLCB3aGlsZSBzdGlsbCBtZWV0aW5nIGFsbCByZXF1aXJlbWVudHMgb2YKICAgW0VNQU4tUkVR XS4gIChGb3IgdGhlIHB1cnBvc2VzIG9mIHRoaXMgZXhwbGFuYXRpb24sIFtQQVJFTExPXSBhbmQK ICAgW0NMQUlTRV0gYXJlIHJlZmVyZW5jZWQgYXMgYSBzaW5nbGUgZ3JvdXAgb2YgdGlnaHRseSBy ZWxhdGVkIGRyYWZ0cwogICB0aGF0IG11c3QgYmUgY29uc2lkZXJlZCB0b2dldGhlci4pCgogICBJ biBbUEFSRUxMT10gYW5kIFtDTEFJU0VdLCB0aGUgcHJpbWFyeSBzdHJ1Y3R1cmUgaXMgY2VudGVy ZWQgYXJvdW5kCiAgIHBtVGFibGUuICBFbnRpdGllcyBhcmUgZGVmaW5lZCBieSBzZXBhcmF0ZSBy b3dzIGluIHRoZSB0YWJsZQogICBzdHJ1Y3R1cmUsIGJ1dCB0aGUgc3RydWN0dXJlIHRpZ2h0bHkg Y291cGxlcyB0aGUgZW50aXR5IGRlZmluaXRpb24KICAgd2l0aCBjb250ZXh0LXJlbGF0ZWQgYXR0 cmlidXRlcyBvZiB0aGUgZW50aXR5J3MgdXNlLiAgRm9yIGV4YW1wbGU6CgogICBvICBwbURvbWFp bk5hbWUgZGVmaW5lcyBhIHNpbmdsZSBjb250ZXh0IGZvciBhbiBlbnRpdHkuICBXaGlsZSB0aGUK ICAgICAgaW50ZW50aW9uIGlzIHRoYXQgcG1Eb21haW5OYW1lIHByaW1hcmlseSBkZXNjcmliZSBh IHBoeXNpY2FsCiAgICAgIHJlbGF0aW9uc2hpcCB0aGF0IHRoZSBlbnRpdHkgbWF5IHNoYXJlIHdp dGggb3RoZXIgZW50aXRpZXMgKGxpa2UKICAgICAgYmVpbmcgY29ubmVjdGVkIHRvIHRoZSBzYW1l IGJyYW5jaCBjaXJjdWl0KSwgaXQgZG9lcyBub3QgYWxsb3cgZm9yCiAgICAgIG90aGVyIGdyb3Vw aW5ncyBkdWUgdG8gdGhlIG9uZS10by1vbmUgcmVsYXRpb25zaGlwIGJldHdlZW4KICAgICAgcG1E b21haW5OYW1lIGFuZCBwbUluZGV4LiAgSWYgc3VjaCBncm91cGluZ3Mgd2VyZSBhZGRlZCBhdCBh IGxhdGVyCiAgICAgIHRpbWUgdXNpbmcgYSBzcGFyc2UgdGFibGUgZXh0ZW5zaW9uLCBtYW55IGF0 dHJpYnV0ZXMgKGxpa2UKICAgICAgcG1Sb2xlRGVzY3JpcHRpb24sIHBtS2V5d29yZHMsIGFuZCBw bUltcG9ydGFuY2UpIHdvdWxkIG5lZWQgdG8gYmUKICAgICAgZHVwbGljYXRlZCBpbiB0aGUgc3Bh cnNlIHRhYmxlLCByZXN1bHRpbmcgaW4gdGhlIHNhbWUgdHlwZSBvZgogICAgICBpbmZvcm1hdGlv biBsaXZpbmcgaW4gc2VwYXJhdGUgT0lEIHN1YnRyZWVzLgoKICAgbyAgVGhlIExMRFAgaW5mb3Jt YXRpb24gZGVmaW5lZCBieSBwbUxsZHBQb3J0TnVtYmVyLCBwbUV0aFBvcnRJbmRleCwKICAgICAg YW5kIHBtRXRoUG9ydEdycEluZGV4IGFyZSB2ZXJ5IHNwZWNpZmljIHRvIG5ldHdvcmtpbmcgZXF1 aXBtZW50CgoKClZlcmdlcyAgICAgICAgICAgICAgICAgICBFeHBpcmVzIEF1Z3VzdCAyNywgMjAx MSAgICAgICAgICAgICAgICBbUGFnZSA1XQoMCkludGVybmV0LURyYWZ0ICBkcmFmdC12ZXJnZXMt ZW1hbi1zZXBhcmF0ZS1tb2R1bGVzLW1pYi0wMCAgRmVicnVhcnkgMjAxMQoKCiAgICAgIHN1Y2gg YXMgcm91dGVycyBhbmQgc3dpdGNoZXMuICBTaW5jZSBzdWNoIGluZm9ybWF0aW9uIGlzIG9wdGlv bmFsCiAgICAgIGZvciBvdGhlciBlcXVpcG1lbnQgKGxpa2Ugc2VydmVycyBhbmQgaW50ZWxsaWdl bnQgcG93ZXIKICAgICAgZGlzdHJpYnV0aW9uIHVuaXRzKSwgdGhlIExMRFAgcHJvcGVydGllcyBz aG91bGQgYmUgc3BsaXQgaW50byBhCiAgICAgIHNlcGFyYXRlIHNwYXJzZSB0YWJsZSB0byBtYWtl IHRoZSBjb3VwbGluZyBsb29zZXIgYW5kIGluY3JlYXNlIE1JQgogICAgICBtYWludGFpbmFiaWxp dHkgYXMgaXQgY29udGludWVzIHRvIGJlIGV4cGFuZGVkIGluIHRoZSBmdXR1cmUuCgogICBvICBU aGUgY29udHJvbCBtZWNoYW5pc20gZGVmaW5lZCBieSBwbVBvd2VyTGV2ZWxUYWJsZSBmb3JjZXMg YSBzaW5nbGUKICAgICAgaW50ZXJmYWNlIGZvciBwb3dlciBjb250cm9sLCBvbiBhbiBhcmJpdHJh cnkgMC0xMiBzY2FsZS4gIFdoaWxlCiAgICAgIHRoZSBhdXRob3JzIGhhdmUgbWFpbnRhaW5lZCBv biB0aGUgbWFpbGluZyBsaXN0IHRoYXQgdGhlCiAgICAgIHBtUG93ZXJMZXZlbE1hcHBpbmdUYWJs ZSBjYW4gYmUgdXNlZCB0byBtYXAgb3RoZXIgbWVjaGFuaXNtcyBzdWNoCiAgICAgIGFzIEFDUEkg b3IgRE1URiwgc3VjaCBhIHN0cnVjdHVyZSBmb3JjZXMgdGhlIGVuZCB1c2VyIHRvIG1hcCB0aGVp cgogICAgICBvd24gdXNlIG9udG8gdGhlIHNjaGVtYSwgcmF0aGVyIHRoYW4gdGhlIHNjaGVtYSBz dXBwb3J0aW5nIHRoZQogICAgICBvcGVyYXRpb24gZGVzaXJlZCBieSB0aGUgZW5kIHVzZXIuCgog ICBvICBUaGUgY29tcGxleCBwb3dlciBkYXRhIHJlcG9ydGluZyBzdHJ1Y3R1cmUgZGVmaW5lZCBi eQogICAgICBwbUFDUHdyUXVhbGl0eVRhYmxlLCBwbUFDUHdyUXVhbGl0eVBoYXNlVGFibGUsIGV0 Yy4gYXR0ZW1wdHMgdG8KICAgICAgbGluayB0b28gbXVjaCBjb250ZXh0IGF3YXJlbmVzcyBvZiB0 aGUgZGF0YSBpbnRvIHRoZSBzY2hlbWEKICAgICAgaXRzZWxmLCByZXN1bHRpbmcgaW4gYSBibG9h dGVkIGFuZCBjdW1iZXJzb21lIHN5c3RlbS4gIElmIGFuIGVuZAogICAgICB1c2VyIHdhbnRlZCB0 byBvYnRhaW4gZGF0YSB1cGRhdGVzLCBzZXZlcmFsIE9JRCB0cmVlcyB3b3VsZCBuZWVkCiAgICAg IHRvIGJlIHdhbGtlZCBzaW11bHRhbmVvdXNseSBpbiBvcmRlciB0byBmdWxseSB1bmRlcnN0YW5k IHRoZSBkYXRhLgoKICAgW1FVSVRURUtdIGFzc3VtZXMgdGhhdCBhbGwgZW50aXRpZXMgdGhhdCB3 aWxsIGV2ZXIgYmUgbW9kZWxlZCBtdXN0IGJlCiAgIHBoeXNpY2FsIGluIG5hdHVyZSwgc28gdXNl cyBFTlRJVFktTUlCIGFzIGEgY29yZSBtb2RlbC4gIFRoaXMgcmVzdWx0cwogICBpbiBhbiBleHRy ZW1lbHkgc2ltcGxlIE1JQiBzY2hlbWEgdGhhdCBjYW5ub3QgYWRlcXVhdGVseSBtZWV0IHRoZQog ICByZXF1aXJlbWVudHMgb2YgbmV0d29yayBzd2l0Y2hlcyB0aGF0IHJlcG9ydCBwb3dlciBvbiBi ZWhhbGYgb2YgUG9FCiAgIGRldmljZXMgb3IgaW50ZWxsaWdlbnQgcG93ZXIgZGlzdHJpYnV0aW9u IHVuaXRzIChpUERVJ3MpLiAgRm9yCiAgIGV4YW1wbGU6CgogICBvICBHaXZlbiBFTlRJVFktTUlC J3MgbmF0dXJhbCBzdHJ1Y3R1cmUgdG8gZW51bWVyYXRlIGJvdGggcGh5c2ljYWwKICAgICAgYW5k IGxvZ2ljYWwgZW50aXRpZXMgb2YgYSBzeXN0ZW0sIHRoZSBhdHRyYWN0aW9uIHRvIHJlLXVzZSB0 aGlzCiAgICAgIHN0cnVjdHVyZSBpcyBhcHBhcmVudC4gIEhvd2V2ZXIsIEVOVElUWS1NSUIgZGlz dGluZ3Vpc2hlcyBwaHlzaWNhbAogICAgICBhbmQgbG9naWNhbCBlbnRpdGllcyBieSBjb250YWlu aW5nIHR3byBNSUIgdGFibGVzLCBvbmUgZm9yIGVhY2gKICAgICAgY2F0ZWdvcnkuICBUaGUgcmVz dWx0IGlzIHRoYXQgc3BhcnNlIHRhYmxlIGV4dGVuc2lvbnMgKHN1Y2ggYXMKICAgICAgcG93ZXJT dGF0ZVRhYmxlIGFuZCBlbmVyZ3lDb25zdW1wVGFibGUpIG11c3QgY2hvb3NlIHdoZXRoZXIgdG8K ICAgICAgbGluayB0byBlbnRQaHlzaWNhbFRhYmxlIG9yIGVudExvZ2ljYWxUYWJsZS4gIEZvciBh IHNlcnZlciBvcgogICAgICBvdGhlciBkZXZpY2VzIHRoYXQgYXJlIHJlbGF0aXZlbHkgc2ltcGxl IGluIHBvd2VyIGRpc3RyaWJ1dGlvbgogICAgICBkZXNpZ24sIGFsbCBjb21wb25lbnRzIGJlaW5n IG1vZGVsZWQgYXJlIGdlbmVyYWxseSBwaHlzaWNhbCwgc28KICAgICAgZW50UGh5c2ljYWxUYWJs ZSBtYWtlcyBzZW5zZS4gIEhvd2V2ZXIsIGZvciBpbnRlbGxpZ2VudCBwb3dlcgogICAgICBkaXN0 cmlidXRpb24gdW5pdHMsIGEgbWFqb3IgbGltaXRhdGlvbiBpcyByZWFjaGVkLiAgU29tZSBpUERV J3MsCiAgICAgIGZvciBleGFtcGxlLCBzdXBwb3J0ICJnYW5naW5nIiBvZiBvdXRsZXRzIGludG8g YSBsb2dpY2FsIGVudGl0eQogICAgICBmb3IgbWFuYWdlbWVudCBwdXJwb3Nlcy4gIFRvIHJlcHJl c2VudCBzdWNoIGEgY29sbGVjdGlvbiBpbgogICAgICBlbnRQaHlzaWNhbFRhYmxlIHdvdWxkIG1p c3VzZSB0aGUgY29yZSByYXRpb25hbGUgYmVoaW5kCiAgICAgIGVudFBoeXNpY2FsVGFibGUuICBP bmUgc29sdXRpb24gdGhhdCB3b3VsZCB1c2UgRU5USVRZLU1JQiB0byBzb2x2ZQogICAgICB0aGlz IHByb2JsZW0gd291bGQgYmUgdG8gaGF2ZSB0d28gb2YgZXZlcnl0aGluZyBpbiBbUVVJVFRFS10s IG9uZQogICAgICBmb3IgcGh5c2ljYWwgZW50aXRpZXMgYW5kIG9uZSBmb3IgbG9naWNhbCBlbnRp dGllcy4gIEJ1dCB0aGlzIGlzCiAgICAgIG5vdCBhbiBpZGVhbCBzb2x1dGlvbiwgYXMgaXQgYm90 aCBidXJkZW5zIHRoZSBlbmQgdXNlciBhbmQgdGhlCiAgICAgIGltcGxlbWVudGluZyB2ZW5kb3Iu CgoKCgpWZXJnZXMgICAgICAgICAgICAgICAgICAgRXhwaXJlcyBBdWd1c3QgMjcsIDIwMTEgICAg ICAgICAgICAgICAgW1BhZ2UgNl0KDApJbnRlcm5ldC1EcmFmdCAgZHJhZnQtdmVyZ2VzLWVtYW4t c2VwYXJhdGUtbW9kdWxlcy1taWItMDAgIEZlYnJ1YXJ5IDIwMTEKCgogICBUaGlzIGRyYWZ0IGF0 dGVtcHRzIHRvIGNvcnJlY3QgdGhvc2UgcHJvYmxlbXMgdGhyb3VnaCB0aGUgdXNlIG9mCiAgIHNl dmVyYWwgc3BlY2lmaWMgY2hhbmdlczoKCiAgIDEuICBEZWZpbmUgYm90aCBwaHlzaWNhbCBhbmQg bG9naWNhbCBlbnRpdGllcyB0aGF0IGFyZSBwb3dlci1yZWxhdGVkCiAgICAgICBpbiBhIHN0YW5k YWxvbmUgdGFibGUuICBJZiBhIHBvd2VyIGVudGl0eSBzaG91bGQgYmUgcmVsYXRlZCB0byBhbgog ICAgICAgZW50aXR5IGRlZmluZWQgYnkgRU5USVRZLU1JQiwgdGhlIHZhbHVlIG9mIHRoZSBpbmRl eCBjYW4gYmUKICAgICAgIHBsYWNlZCBpbnRvIGVtYW5FbnRpdHlQaHlzaWNhbElkIG9yIGVtYW5F bnRpdHlMb2dpY2FsSWQgYXMKICAgICAgIGFwcHJvcHJpYXRlOyBvdGhlcndpc2UsIHRoZSB2YWx1 ZSBzaG91bGQgYmUgemVybyBmb3IgdGhlIHVudXNlZAogICAgICAgY29sdW1uKHMpLgoKICAgMi4g IFNpbWlsYXIgdG8gW1FVSVRURUtdLCBzcGFyc2UgdGFibGVzIHRoYXQgaGF2ZSBhIG5hcnJvd2x5 IGRlZmluZWQKICAgICAgIHNjb3BlIGV4dGVuZCBvZmYgdGhpcyBjb3JlIGVudGl0eSBsaXN0LiAg VGhpcyBhbGxvd3MgZm9yIGFuIGVuZAogICAgICAgdXNlciB0byB3YWxrIGEgc2luZ2xlIHNwYXJz ZSB0YWJsZSB0byBvYnRhaW4gYWxsIGRhdGEgdXBkYXRlcwogICAgICAgcmVsYXRlZCB0byBvbmUg Z3JvdXA6IGRhdGEsIGNvbnRyb2wvc3RhdGUsIExMRFAgaW5mb3JtYXRpb24sIGV0Yy4KCiAgIDMu ICBQb3dlciBlbnRpdGllcyBhcmUgZGVmaW5lZCBhcyBvbmUgb2YgdHdvIHR5cGVzOiBzaW1wbGUg b3IKICAgICAgIGNvbXBsZXguICBBIHNpbXBsZSBlbnRpdHkgY2FuIGJlIGZ1bGx5IGRlc2NyaWJl ZCBieSBhIHNpbmdsZSBkYXRhCiAgICAgICByb3cgb3IgY29udHJvbC9zdGF0ZSByb3cuICBBIGNv bXBsZXggZW50aXR5IGNhbiBiZSBkZWNvbnN0cnVjdGVkCiAgICAgICBpbnRvIG11bHRpcGxlIHNp bXBsZSBlbnRpdGllcy4gIEFuIGV4YW1wbGUgb2YgYSBzaW1wbGUgZW50aXR5CiAgICAgICB3b3Vs ZCBiZSBhIHNpbmdsZSBwaGFzZSBBQyBwb3dlciBtZXRlciwgd2hpbGUgYSBjb21wbGV4IGVudGl0 eQogICAgICAgd291bGQgYmUgYSB0aHJlZSBwaGFzZSBBQyBwb3dlciBtZXRlci4gIChBIHRocmVl IHBoYXNlIG1ldGVyIGNhbgogICAgICAgYmUgdGhvdWdodCBvZiBhcyBiZWluZyBjb21wcmlzZWQg YnkgdGhyZWUgb3IgZm91ciBpbmRpdmlkdWFsCiAgICAgICBzaW5nbGUgcGhhc2UgbWV0ZXJzIHdp dGggcGhhc2UgcmVsYXRpb25zaGlwIGluZm9ybWF0aW9uIGFkZGVkLikKICAgICAgIFRoZSByZXN1 bHQgaXMgYSBzaW1wbGlmaWVkIE1JQiB0cmVlIHdpdGggYSBzaW5nbGUgImRhdGEiIHRyZWUgYW5k CiAgICAgICBhIHNpbmdsZSAiY29udHJvbCIgdHJlZSB0aGF0IGNhbiBiZSBhY2Nlc3NlZCBhbmQg dW5kZXJzdG9vZCB3aXRoCiAgICAgICBhIHNpbmdsZSB0YWJsZSB3YWxrLgoKICAgNC4gIE11bHRp cGxlIGNvbnRyb2wgbWVjaGFuaXNtcyBhcmUgc3VwcG9ydGVkIHNvIHRoYXQgZW5kIHVzZXJzIGNh bgogICAgICAgdGhpbmsgaW4gd2hhdGV2ZXIgdGVybXMgYXJlIGZhbWlsaWFyIHRvIHRoZW0uICBG b3IgZXhhbXBsZSwgaWYgYW4KICAgICAgIGVuZCB1c2VyIGlzIG1vcmUgZmFtaWxpYXIgd2l0aCBB Q1BJIGxldmVscyB0aGFuIERNVEYgUG93ZXIgU3RhdGUKICAgICAgIGxldmVscywgdGhleSBjYW4g dXNlIHRoZSBlbWFuQWNwaUNvbnRyb2wgb2JqZWN0LiAgSWYgdGhleSB3b3JrCiAgICAgICBtb3Jl IHdpdGggdGhlIERNVEYsIHRoZXkgY2FuIHVzZSB0aGUgZW1hbkRtdGZDb250cm9sIG9iamVjdC4g IE9yCiAgICAgICBpZiB0aGV5IHRoaW5rIG1vcmUgaW4gdGVybXMgb2YgYSBwZXJjZW50YWdlIHNj YWxlLCB0aGV5IGNhbiB1c2UKICAgICAgIHRoZSBlbWFuUGVyY2VudGFnZUNvbnRyb2wgb2JqZWN0 LiAgSXQgaXMgdXAgdG8gdGhlIGltcGxlbWVudGluZwogICAgICAgdmVuZG9yIHRvIGZpZ3VyZSBv dXQgaG93IHRvIHJlbGF0ZSB0aGVzZSBkaWZmZXJlbnQgY29udHJvbAogICAgICAgbWVjaGFuaXNt cyB3aXRoIGVhY2ggb3RoZXIgaW4gYSB3YXkgdGhhdCBtYWtlcyBzZW5zZSB0byB0aGUKICAgICAg IGFnZW50J3MgY29yZSBwdXJwb3NlLiAgRXhwb3NpbmcgZGlmZmVyZW50IGludGVyZmFjZXMgb25s eQogICAgICAgc2ltcGxpZmllcyB0aGUgcHJvY2VzcyBmb3IgdGhlIGVuZCB1c2VyLgoKICAgNS4g IENvbnRleHQgZm9yIGFuIGVudGl0eSBpcyBub3QgY29uc2lkZXJlZCBhIGNvcmUgY29uY2VwdCBm b3IKICAgICAgIGRlZmluaW5nIHdoYXQgYW4gZW50aXR5IGlzLCBidXQgaXMgaW5zdGVhZCBhIHNw YXJzZSB0YWJsZQogICAgICAgZXh0ZW5zaW9uLiAgQm90aCBwaHlzaWNhbCBjb250ZXh0cyAobGlr ZSBicmFuY2ggY2lyY3VpdHMpIGFuZAogICAgICAgbG9naWNhbCBjb250ZXh0cyAobGlrZSBvd25l cnNoaXAgYnkgYSBjb21tb24gYnVzaW5lc3MgdW5pdCkgYXJlCiAgICAgICBlbmFibGVkIGluIHRo ZSBzYW1lIGNvbnRleHQgdHJlZSwgYWxsb3dpbmcgdGhlIHVzZXIgdG8gYWNjZXNzIGEKICAgICAg IHNpbmdsZSB0YWJsZSB0aGF0IGNvbnRhaW5zIGFsbCBvZiB0aGUgY29udGV4dCBpbmZvcm1hdGlv biwKICAgICAgIHJlZ2FyZGxlc3Mgb2YgdGhlIGNvbnRleHQgdHlwZS4KCiAgIFRoZSBlbmQgcmVz dWx0IGlzIGEgZGVzaWduIHdoaWNoIGhhcyBsb3cgY291cGxpbmcgYW5kIGhpZ2ggY29oZXNpb24s CgoKClZlcmdlcyAgICAgICAgICAgICAgICAgICBFeHBpcmVzIEF1Z3VzdCAyNywgMjAxMSAgICAg ICAgICAgICAgICBbUGFnZSA3XQoMCkludGVybmV0LURyYWZ0ICBkcmFmdC12ZXJnZXMtZW1hbi1z ZXBhcmF0ZS1tb2R1bGVzLW1pYi0wMCAgRmVicnVhcnkgMjAxMQoKCiAgIHRoYXQgd2lsbCBhbGxv dyB0aGUgSUVURiB0byBjb250aW51ZSB0byBncm93IGFuZCBleHBhbmQgaXQgYXMgdGhlCiAgIFNt YXJ0IEdyaWQgYW5kIG90aGVyIHBvd2VyLXJlbGF0ZWQgdGVjaG5vbG9naWVzIGNvbnRpbnVlIHRv IG1hdHVyZQogICBhbmQgZGV2ZWxvcC4KCjQuICBUaGUgSW50ZXJuZXQtU3RhbmRhcmQgTWFuYWdl bWVudCBGcmFtZXdvcmsKCiAgIEZvciBhIGRldGFpbGVkIG92ZXJ2aWV3IG9mIHRoZSBkb2N1bWVu dHMgdGhhdCBkZXNjcmliZSB0aGUgY3VycmVudAogICBJbnRlcm5ldC1TdGFuZGFyZCBNYW5hZ2Vt ZW50IEZyYW1ld29yaywgcGxlYXNlIHJlZmVyIHRvIHNlY3Rpb24gNyBvZgogICBSRkMgMzQxMCBb UkZDMzQxMF0uCgogICBNYW5hZ2VkIG9iamVjdHMgYXJlIGFjY2Vzc2VkIHZpYSBhIHZpcnR1YWwg aW5mb3JtYXRpb24gc3RvcmUsIHRlcm1lZAogICB0aGUgTWFuYWdlbWVudCBJbmZvcm1hdGlvbiBC YXNlIG9yIE1JQi4gIE1JQiBvYmplY3RzIGFyZSBnZW5lcmFsbHkKICAgYWNjZXNzZWQgdGhyb3Vn aCB0aGUgU2ltcGxlIE5ldHdvcmsgTWFuYWdlbWVudCBQcm90b2NvbCAoU05NUCkuCiAgIE9iamVj dHMgaW4gdGhlIE1JQiBhcmUgZGVmaW5lZCB1c2luZyB0aGUgbWVjaGFuaXNtcyBkZWZpbmVkIGlu IHRoZQogICBTdHJ1Y3R1cmUgb2YgTWFuYWdlbWVudCBJbmZvcm1hdGlvbiAoU01JKS4gIFRoaXMg bWVtbyBzcGVjaWZpZXMgYSBNSUIKICAgbW9kdWxlIHRoYXQgaXMgY29tcGxpYW50IHRvIHRoZSBT TUl2Miwgd2hpY2ggaXMgZGVzY3JpYmVkIGluIFNURCA1OCwKICAgUkZDIDI1NzggW1JGQzI1Nzhd LCBTVEQgNTgsIFJGQyAyNTc5IFtSRkMyNTc5XSBhbmQgU1REIDU4LCBSRkMgMjU4MAogICBbUkZD MjU4MF0uCgo1LiAgQ29udmVudGlvbnMKCiAgIFRoZSBrZXkgd29yZHMgIk1VU1QiLCAiTVVTVCBO T1QiLCAiUkVRVUlSRUQiLCAiU0hBTEwiLCAiU0hBTEwgTk9UIiwKICAgIlNIT1VMRCIsICJTSE9V TEQgTk9UIiwgIlJFQ09NTUVOREVEIiwgIk1BWSIsIGFuZCAiT1BUSU9OQUwiIGluIHRoaXMKICAg ZG9jdW1lbnQgYXJlIHRvIGJlIGludGVycHJldGVkIGFzIGRlc2NyaWJlZCBpbiBSRkMgMjExOSBb UkZDMjExOV0uCgo2LiAgU3RydWN0dXJlIG9mIHRoZSBFTUFOLUNPUkUtTUlCIE1vZHVsZQoKICAg VGhlIHByaW1hcnkgc3RydWN0dXJlIGluIEVNQU4tQ09SRS1NSUIgaXMgdGhlIGVtYW5FbnRpdHlU YWJsZS4gIFRoaXMKICAgc3RydWN0dXJlIGNvbXByaXNlcyBhIGxpc3Qgb2YgZW50aXRpZXMgdGhh dCBhcmUgdG8gYmUgbWFuYWdlZCB1bmRlcgogICB0aGUgRU1BTiBzY2hlbWFzLiAgVGhlIGxpc3Qg aXMgaGllcmFyY2hpY2FsIGluIG5hdHVyZSwgd2hlcmUgZW50aXRpZXMKICAgbWF5IGhhdmUgcGFy ZW50L2NoaWxkIHJlbGF0aW9uc2hpcHMuCgo2LjEuICBUZXh0dWFsIENvbnZlbnRpb25zCgo2LjEu MS4gIEVtYW5FbnRpdHlSb2xlCgogICBUaGlzIHRleHR1YWwgY29udmVudGlvbiBzcGVjaWZpZXMg dGhlIHR5cGUgb2YgZW50aXR5IGJlaW5nIGRlc2NyaWJlZC4KICAgRm9yIGV4YW1wbGUsIHRoZSBl bnRpdHkgY2FuIGVpdGhlciBiZSBhIG1ldGVyIHJlcG9ydGluZyBvbiBiZWhhbGYgb2YKICAgYW4g YW5vdGhlciBkZXZpY2Ugb3IgYSBjb25zdW1lciByZXBvcnRpbmcgaXRzIG93biB1c2UuICBPdGhl ciBlbnRpdHkKICAgdHlwZXMgbWF5IGJlIGRlZmluZWQgYXMgZnV0dXJlIGV4dGVuc2lvbnMuCgo2 LjEuMi4gIEVtYW5FbnRpdHlDYXBhYmlsaXRpZXMKCiAgIFRoaXMgdGV4dHVhbCBjb252ZW50aW9u IHNwZWNpZmllcyB0aGUgRU1BTi1zcGVjaWZpYyBjYXBhYmlsaXRpZXMgdGhhdAogICB0aGUgZW50 aXR5IGlzIGNhcGFibGUgb2Ygc3VwcG9ydGluZywgYXMgYSBTTUl2MiBCSVRTIGV4dGVuc2lvbi4g IEVhY2gKICAgcm9sZS1zcGVjaWZpYyBleHRlbnNpb24gaXMgcmVwcmVzZW50ZWQgYXMgb25lIGJp dCwgYW5kIGVudGl0aWVzIHdoaWNoCiAgIHN1cHBvcnQgYSByb2xlIGV4dGVuc2lvbiBtdXN0IGFk dmVydGlzZSB0aGF0IGNhcGFiaWxpdHkgYnkgc2V0dGluZwogICB0aGUgY29ycmVzcG9uZGluZyBi aXQuCgoKClZlcmdlcyAgICAgICAgICAgICAgICAgICBFeHBpcmVzIEF1Z3VzdCAyNywgMjAxMSAg ICAgICAgICAgICAgICBbUGFnZSA4XQoMCkludGVybmV0LURyYWZ0ICBkcmFmdC12ZXJnZXMtZW1h bi1zZXBhcmF0ZS1tb2R1bGVzLW1pYi0wMCAgRmVicnVhcnkgMjAxMQoKCjYuMS4zLiAgVGhvdXNh bmR0aHMKCiAgIFRoaXMgdGV4dHVhbCBjb252ZW50aW9uIHNwZWNpZmllcyBhIGZpeGVkIHBvaW50 IGRlY2ltYWwgdmFsdWUgdXAgdG8gYQogICAxMF4oLTMpIHByZWNpc2lvbiAoMC4wMDEpLiAgQmFz ZWQgb24gYW4gSW50ZWdlcjMyIGRhdGEgdHlwZSwgdGhpcwogICB0ZXh0dWFsIGNvbnZlbnRpb24g c3VwcG9ydHMgZnJvbSAtMiwxNDcsNDgzLjY0NyB0byArMiwxNDcsNDgzLjY0Ny4KCjYuMS40LiAg VW5pdE11bHRpcGxpZXIKCiAgIFRoaXMgdGV4dHVhbCBjb252ZW50aW9uIGlzIGFuIGludGVnZXIg dmFsdWUgdGhhdCByZXByZXNlbnRzIHRoZSBJRUVFCiAgIDYxODUwIEFubmV4IEEgdW5pdHMgbXVs dGlwbGllciBhc3NvY2lhdGVkIHdpdGggdGhlIGludGVnZXIgdW5pdHMgdXNlZAogICB0byBtZWFz dXJlIHRoZSBwb3dlciBvciBlbmVyZ3kuCgogICBGb3IgZXhhbXBsZSwgYSBVbml0TXVsdGlwbGll ciBvZiAtMyBjb3JyZXNwb25kcyB3aXRoIGEgdW5pdCBzY2FsZSBvZgogICAibWlsbGkiLCAxMF4t My4KCiAgIFdoZW4gdXNlZCBpbiBjb21iaW5hdGlvbiB3aXRoIGEgVGhvdXNhbmR0aHMgVEMgdmFs dWUgb2YgMTIzNCwgZm9yCiAgIGV4YW1wbGUsIGEgVW5pdE11bHRpcGxpZXIgb2YgdW5pdCgwKSB3 b3VsZCByZXN1bHQgaW4gdGhlIHZhbHVlIGJlaW5nCiAgIGVxdWl2YWxlbnQgdG8gdGhlIG9yaWdp bmFsIGludGVudCBiZWhpbmQgdGhlIFRob3VzYW5kdGhzIFRDICgxLjIzNCkuCiAgIENoYW5naW5n IHRoZSBVbml0TXVsdGlwbGllciB0byBtaWxsaSgtMykgd291bGQgcmVzdWx0IGluIHRoZSB2YWx1 ZQogICBiZWluZyBlcXVpdmFsZW50IHRvIDAuMDAxMjM0LiAgTGlrZXdpc2UsIGNoYW5naW5nIHRv IGtpbG8oMykgd291bGQKICAgcmVzdWx0IGluIHRoZSB2YWx1ZSBiZWluZyAxLDIzNC4wMDAuCgo2 LjIuICBUaGUgTm90aWZpY2F0aW9ucyBTdWJ0cmVlCgogICBFTUFOLUNPUkUtTUlCIGltcGxlbWVu dHMgbm8gbm90aWZpY2F0aW9ucyBhdCB0aGlzIHRpbWUuCgo2LjMuICBUaGUgVGFibGUgU3RydWN0 dXJlcwoKICAgVGhlIGhlYXJ0IG9mIHRoZSBlbnRpcmUgcm9sZS1zcGVjaWZpYyBleHRlbnNpb24g c2NoZW1hIGlzIHRoZSBsaXN0IG9mCiAgIGVudGl0aWVzIGluIGVtYW5FbnRpdHlUYWJsZS4gIEFu IGVudGl0eSBpbiB0aGlzIGxpc3QgbWF5IGJlIHNpbXBsZQogICAoZGVzY3JpYmVkIGluIGFuZCBv ZiBpdHNlbGYpIG9yIGNvbXBsZXggKGRlc2NyaWJlZCBieSBzZXZlcmFsIGNoaWxkCiAgIGVudGl0 aWVzLikKCiAgIEZvciBleGFtcGxlLCBjb25zaWRlciBhIHN0YW5kYXJkIGNvbXB1dGVyIHdvcmtz dGF0aW9uIHdpdGggYSBzaW5nbGUKICAgQUMvREMgcG93ZXIgc3VwcGx5LiAgVGhlIGVtYW5FbnRp dHlUYWJsZSB0byBkZXNjcmliZSB0aGlzIHNjZW5hcmlvCiAgIG1pZ2h0IGNvbnRhaW4gdGhlIGZv bGxvd2luZzoKCiAgICAgICAgICAgICArLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0t LS0tLSstLS0tLS0tLSsKICAgICAgICAgICAgIHwgSWR4IHwgTmFtZSAgICAgICAgICAgIHwgVHlw ZSAgICAgICAgfCBQYXJlbnQgfAogICAgICAgICAgICAgKy0tLS0tKy0tLS0tLS0tLS0tLS0tLS0t Ky0tLS0tLS0tLS0tLS0rLS0tLS0tLS0rCiAgICAgICAgICAgICB8IDEgICB8IFBDIFBvd2VyIFN1 cHBseSB8IGNvbnN1bWVyKDEpIHwgMCAgICAgIHwKICAgICAgICAgICAgICstLS0tLSstLS0tLS0t LS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tKy0tLS0tLS0tKwoKICAgICAgICAgICAgICAgIFRhYmxl IDE6IFNpbXBsZSBlbnRpdGllcyBpbiBlbWFuRW50aXR5VGFibGUKCiAgIENvbXBsZXggZW50aXRp ZXMgY2FuIGJlIGRlc2NyaWJlZCB1c2luZyB0aGUgc2FtZSBzY2hlbWEgYnkgZGVzY3JpYmluZwog ICBhIHNldCBvZiBzaW1wbGUgY2hpbGQgZW50aXRpZXMuICBGb3IgZXhhbXBsZSwgY29uc2lkZXIg YW4gaW5nZWxsaWVudAogICBwb3dlciBkaXN0cmlidXRpb24gdW5pdCB3aXRoIG9uZSB0aHJlZS1w aGFzZSBpbnB1dCBjb3JkIGFuZCB0aHJlZQoKCgpWZXJnZXMgICAgICAgICAgICAgICAgICAgRXhw aXJlcyBBdWd1c3QgMjcsIDIwMTEgICAgICAgICAgICAgICAgW1BhZ2UgOV0KDApJbnRlcm5ldC1E cmFmdCAgZHJhZnQtdmVyZ2VzLWVtYW4tc2VwYXJhdGUtbW9kdWxlcy1taWItMDAgIEZlYnJ1YXJ5 IDIwMTEKCgogICBzaW5nbGUtcGhhc2UgYmFua3Mgb2YgdHdvIG91dGxldHMgZWFjaDoKCiAgICAg ICAgICstLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tKy0tLS0t LS0tKwogICAgICAgICB8IElkeCB8IE5hbWUgICAgICAgICAgICAgICAgICAgICB8IFR5cGUgICAg ICAgIHwgUGFyZW50IHwKICAgICAgICAgKy0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t Ky0tLS0tLS0tLS0tLS0rLS0tLS0tLS0rCiAgICAgICAgIHwgMSAgIHwgSW50ZXJuYWwgTklDICAg ICAgICAgICAgIHwgY29uc3VtZXIoMCkgfCAwICAgICAgfAogICAgICAgICB8IDIgICB8IElucHV0 IENvcmQgMSAtIDNQSCBERUxUQSB8IG1ldGVyKDEpICAgIHwgMCAgICAgIHwKICAgICAgICAgfCAz ICAgfCBJbnB1dCBDb3JkIDEgLSBMaW5lIEEgICAgfCBtZXRlcigxKSAgICB8IDIgICAgICB8CiAg ICAgICAgIHwgNCAgIHwgSW5wdXQgQ29yZCAxIC0gTGluZSBCICAgIHwgbWV0ZXIoMSkgICAgfCAy ICAgICAgfAogICAgICAgICB8IDUgICB8IElucHV0IENvcmQgMSAtIExpbmUgQyAgICB8IG1ldGVy KDEpICAgIHwgMiAgICAgIHwKICAgICAgICAgfCA2ICAgfCBCYW5rIDEgLSBMaW5lIEFCICAgICAg ICAgfCBtZXRlcigxKSAgICB8IDAgICAgICB8CiAgICAgICAgIHwgNyAgIHwgQmFuayAyIC0gTGlu ZSBCQyAgICAgICAgIHwgbWV0ZXIoMSkgICAgfCAwICAgICAgfAogICAgICAgICB8IDggICB8IEJh bmsgMyAtIExpbmUgQ0EgICAgICAgICB8IG1ldGVyKDEpICAgIHwgMCAgICAgIHwKICAgICAgICAg fCA5ICAgfCBPdXRsZXQgMSAgICAgICAgICAgICAgICAgfCBtZXRlcigxKSAgICB8IDAgICAgICB8 CiAgICAgICAgIHwgMTAgIHwgT3V0bGV0IDIgICAgICAgICAgICAgICAgIHwgbWV0ZXIoMSkgICAg fCAwICAgICAgfAogICAgICAgICB8IC4uLiB8IC4uLiAgICAgICAgICAgICAgICAgICAgICB8IC4u LiAgICAgICAgIHwgLi4uICAgIHwKICAgICAgICAgKy0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tKy0tLS0tLS0tLS0tLS0rLS0tLS0tLS0rCgogICAgICAgICAgICAgICBUYWJsZSAyOiBD b21wbGV4IGVudGl0aWVzIGluIGVtYW5FbnRpdHlUYWJsZQoKICAgSW4gdGhlIGFib3ZlIGV4YW1w bGUsIG5vdGUgaG93IHRoZSBjb21wbGV4IGVudGl0eSBvZiB0aGUgdGhyZWUtcGhhc2UKICAgaW5w dXQgY29yZCBpcyBzdWJkaXZpZGVkIGludG8gc2VwYXJhdGUgc2ltcGxlIGVudGl0aWVzIHRoYXQg YXJlIHRoZQogICBpbmRpdmlkdWFsIGxpbmVzIGluIHRoZSBpbnB1dCBjb3JkLiAgVGhpcyBhbGxv d3MgZWFjaCBlbnRpdHkgKHRoZQogICBpbnB1dCBjb3JkIGJ1bmRsZSBhbmQgZWFjaCBvZiBpdHMg bGluZXMpIHRvIGJlIGFkZHJlc3NlZCBzZXBhcmF0ZWx5LAogICBpZiBkZXNpcmVkLCBieSByb2xl LXNwZWNpZmljIGV4dGVuc2lvbnMgYW5kIGVudGVycHJpc2Utc3BlY2lmaWMKICAgZXh0ZW5zaW9u cy4KCiAgIEluIGRlY2lkaW5nIHdoZXRoZXIgYW4gZW50aXR5IGlzIHNpbXBsZSBvciBjb21wbGV4 LCBhbiBpbXBsZW1lbnRpbmcKICAgdmVuZG9yIHNob3VsZCBjb25zaWRlciB0aGUgaW1wYWN0IG9m IHVzaW5nIGVpdGhlciB0eXBlIG9uIHRoZSByb2xlLQogICBzcGVjaWZpYyBzdWJzY2hlbWFzIHRo YXQgdGhlIGVudGl0eSB3aWxsIGltcGxlbWVudC4gIEZvciBleGFtcGxlLCBhCiAgIHNlcnZlciBj YW4gYmUgbW9kZWxlZCBhcyBlaXRoZXIgYSBzaW1wbGUgZW50aXR5ICh0aGUgc2VydmVyIGFzIGEK ICAgc2luZ2xlLCBzaW1wbGUgZW50aXR5KSBvciBhcyBhIGNvbXBsZXggZW50aXR5ICh0aGUgc2Vy dmVyIGFzIGFuCiAgIGFnZ3JlZ2F0aW9uIG9mIHBvd2VyIHN1cHBsaWVzLCBpbnRlcm5hbCBiYXR0 ZXJpZXMsIHByb2Nlc3NvcnMsIGV0Yy4pCiAgIEJvdGggY2hvaWNlcyBhcmUgZXF1YWxseSB2YWxp ZCwgYW5kIHRoZSBpbXBsZW1lbnRpbmcgYWdlbnQgc2hvdWxkCiAgIGNob29zZSB0aGUgb25lIHRo YXQgbWFrZXMgdGhlIG1vc3Qgc2Vuc2UgZm9yIHRoZSBlbmQgdXNlcnMgdGhhdCBpdAogICBzZXJ2 ZXMuCgogICBUb3AtbGV2ZWwgZW50aXRpZXMgc2hvdWxkIHNldCB0aGVpciBlbWFuRW50aXR5UGFy ZW50IHRvIHplcm8gKDApIGlmCiAgIHRoZSBlbnRpdHkgaGFzIG5vIHBhcmVudC4gIFRoZSBlbWFu RW50aXR5UGFyZW50IGNvbHVtbiByZWZlcnMgdG8gdGhlCiAgIGVtYW5FbnRpdHlJbmRleCBvZiB0 aGUgcGFyZW50IGVudGl0eS4KCiAgIElmIGEgcm93IGlzIGFkZGVkIG9yIGRlbGV0ZWQsIHRoZSBj b3JyZXNwb25kaW5nIHJvbGUtc3BlY2lmaWMKICAgZXh0ZW5zaW9ucyBzaG91bGQgbGlrZXdpc2Ug dXBkYXRlIHRvIHJlZmxlY3QgdGhlIG5ldyBzdGF0ZS4KCjcuICBTdHJ1Y3R1cmUgb2YgdGhlIEVN QU4tREFUQS1NSUIgTW9kdWxlCgogICBFTUFOLURBVEEtTUlCIGJ1aWxkcyBvbiBFTUFOLUNPUkUt TUlCIGJ5IHByb3ZpZGluZyBwb3dlciBhbmQgZW5lcmd5CiAgIGRhdGEgZm9yIGVudGl0aWVzIHRo YXQgc3VwcG9ydCBpdC4gIEVudGl0aWVzIHdoaWNoIGltcGxlbWVudCBFTUFOLQoKCgpWZXJnZXMg ICAgICAgICAgICAgICAgICAgRXhwaXJlcyBBdWd1c3QgMjcsIDIwMTEgICAgICAgICAgICAgICBb UGFnZSAxMF0KDApJbnRlcm5ldC1EcmFmdCAgZHJhZnQtdmVyZ2VzLWVtYW4tc2VwYXJhdGUtbW9k dWxlcy1taWItMDAgIEZlYnJ1YXJ5IDIwMTEKCgogICBEQVRBLU1JQiBtdXN0IHNldCB0aGUgaW5z dGFudCgwKSBhbmQvb3IgaGlzdG9yaWNhbCgxKSBjYXBhYmlsaXRpZXMKICAgYml0cyBhcHByb3By aWF0ZWx5LgoKNy4xLiAgVGV4dHVhbCBDb252ZW50aW9ucwoKICAgUGhhc2VPZmZzZXQgc3BlY2lm aWVzIHRoZSBwaGFzZSBhbmdsZSBvZmZzZXQgb2YgdGhlIGVudGl0eSdzIHZvbHRhZ2UKICAgd2F2 ZSByZWxhdGl2ZSB0byB6ZXJvICgwKSBkZWdyZWVzLiAgSW4gYSB0eXBpY2FsIHRocmVlLXBoYXNl IHN5c3RlbSwKICAgTGluZSBBTiBpcyAwIGRlZ3JlZXMsIEJOIGlzIDEyMCBkZWdyZWVzLCBhbmQg Q04gaXMgMjQwIGRlZ3JlZXMsIGZvcgogICBleGFtcGxlLiAgTmVnYXRpdmUgdmFsdWVzIGNhbiBp bmRpY2F0ZSBhIHBvc2l0aXZlIG9yIG5lZ2F0aXZlCiAgIHJvdGF0aW9uLgoKICAgRGF0YUFjY3Vy YWN5IHNwZWNpZmllcyB0aGUgYWNjdXJhY3kgb2YgdGhlIGRhdGEgYXMgYSBwZXJjZW50YWdlLgog ICBUaGlzIGRhdGEgdHlwZSBpcyBiYXNlZCBvbiB0aGUgSUVDIGNsYXNzaWZpY2F0aW9uIG9mIHBv d2VyIG1ldGVycwogICAoMi4wJSwgMS4wJSwgMC41JSwgZXRjLikgIEEgRGF0YUFjY3VyYWN5IHZh bHVlIG9mIDE1MCBjb3JyZXNwb25kcwogICB3aXRoIGFuIGFjY3VyYWN5IG9mIDEuNSUuCgogICBE YXRhQ2FsaWJlciBzcGVjaWZpZXMgdGhlIGNhbGliZXIgb2YgdGhlIGRhdGEsIHdoZXRoZXIgaXQg aXMKICAgdW5rbm93bigwKSBvciBhY3R1YWwoMSkgb3IgZXN0aW1hdGVkKDIpIG9yIHByZXN1bWVk KDMpLiAgSWYgdGhlIGRhdGEKICAgaXMgbWVhc3VyZWQsIGZvciBleGFtcGxlLCB0aGUgY2FsaWJl ciBpcyAiYWN0dWFsLiIKCjcuMi4gIFRoZSBOb3RpZmljYXRpb25zIFN1YnRyZWUKCiAgIEVNQU4t REFUQS1NSUIgaW1wbGVtZW50cyBubyBub3RpZmljYXRpb25zIGF0IHRoaXMgdGltZS4KCjcuMy4g IFRoZSBUYWJsZSBTdHJ1Y3R1cmVzCgogICBUaGUgZGF0YSByZXByZXNlbnRlZCBpbiBlbWFuSW5z dGFudERhdGFUYWJsZSByZXByZXNlbnRzIHRoZQogICBpbnN0YW50YW5lb3VzIGRhdGEgZm9yIGFu IGVudGl0eS4gIFRvIHVzZSB0aGlzIHRhYmxlLCBhbiBpbXBsZW1lbnRpbmcKICAgZW50aXR5IG11 c3Qgc2V0IHRoZSBpbnN0YW50KDApIGNhcGFiaWxpdHkgYml0LiAgQWxsIGRhdGEgaW4gdGhpcwog ICB0YWJsZSBpcyAibm9ybWFsaXplZCIgdG8gc2luZ2xlLXBoYXNlIEFDIG9yIERDIGZvcm1hdCB0 byBlbnN1cmUKICAgY29uc2lzdGVuY3kgaW4gdGhlIGRhdGEgcmV0dXJuZWQgYW5kIHNpbXBsaWNp dHkgb2YgdGhpcmQtcGFydHkKICAgc3lzdGVtcyB0aGF0IHdpbGwgYmUgdXNpbmcgdGhlIGRhdGEg cmV0dXJuZWQgYnkgdGhlIEVNQU4gYWdlbnQuCgogICBGb3IgZXhhbXBsZSwgY29uc2lkZXIgbW9k ZWxpbmcgdGhlIGluc3RhbnRhbmVvdXMgZGF0YSBmb3IgdGhlIHRocmVlLQogICBwaGFzZSBpbnB1 dCBjb3JkIGVudGl0eSBkZXNjcmliZWQgZWFybGllciBpbiBUYWJsZSAyOgoKICAgKy0tLS0tKy0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLSstLS0tLS0tLS0rLS0tLS0tLS0tLS0t LS0rCiAgIHwgSWR4IHwgKE5hbWUpICAgICAgICAgICAgICAgICAgIHwgVm9sdGFnZSB8IEN1cnJl bnQgfCBBY3RpdmUgUG93ZXIgfAogICArLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0r LS0tLS0tLS0tKy0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLSsKICAgfCAyICAgfCBJbnB1dCBDb3Jk IDEgLSAzUEggREVMVEEgfCAyMDguODMwIHwgIDMzLjQ4MSB8ICAgIDYsOTkxLjg0OCB8CiAgIHwg MyAgIHwgSW5wdXQgQ29yZCAxIC0gTGluZSBBICAgIHwgMjA1LjM1MCB8ICAxNC45MDAgfCAgICAz LDA1OS43MTUgfAogICB8IDQgICB8IElucHV0IENvcmQgMSAtIExpbmUgQiAgICB8IDIxMi4wMzEg fCAgIDcuNDU1IHwgICAgMSw1ODAuNjkxIHwKICAgfCA1ICAgfCBJbnB1dCBDb3JkIDEgLSBMaW5l IEMgICAgfCAyMDkuMTEwIHwgIDExLjI0NSB8ICAgIDIsMzUxLjQ0MiB8CiAgICstLS0tLSstLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0rLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0t KwoKICAgICBUaGUgY29tcGxleCBpbnB1dCBjb3JkIGRhdGEgZW50cnkgcmVmbGVjdHMgdGhlIHBy b3BlciB0aHJlZS1waGFzZQogICAgICAgICAgcG93ZXIgYW5kIHRoZSBzaW5nbGUtcGhhc2UtZXF1 aXZhbGVudCB2b2x0YWdlL2N1cnJlbnQuCgoKCgpWZXJnZXMgICAgICAgICAgICAgICAgICAgRXhw aXJlcyBBdWd1c3QgMjcsIDIwMTEgICAgICAgICAgICAgICBbUGFnZSAxMV0KDApJbnRlcm5ldC1E cmFmdCAgZHJhZnQtdmVyZ2VzLWVtYW4tc2VwYXJhdGUtbW9kdWxlcy1taWItMDAgIEZlYnJ1YXJ5 IDIwMTEKCgogICAgICAgICAgICAgVGFibGUgMzogSW5zdGFudGFuZW91cyBkYXRhIGZvciBjb21w bGV4IGVudGl0aWVzCgogICBJZiBhbiBlbnRpdHkgZG9lcyBub3Qgc3VwcG9ydCBvbmUgb2YgdGhl IGRhdGEgdHlwZXMgKGV4LiBoYXJtb25pYwogICBkaXN0b3J0aW9uKSwgdGhhdCBjb2x1bW4gbWF5 IG9wdGlvbmFsbHkgYmUgb21taXR0ZWQgZm9yIHRoZSBlbnRpdHkncwogICByb3cuCgo4LiAgU3Ry dWN0dXJlIG9mIHRoZSBFTUFOLUNPTlRST0wtTUlCIE1vZHVsZQoKICAgRU1BTi1DT05UUk9MLU1J QiBidWlsZHMgb24gRU1BTi1DT1JFLU1JQiBieSBwcm92aWRpbmcgcG93ZXIgc3RhdGUKICAgY29u dHJvbCBmb3IgZW50aXRpZXMgdGhhdCBzdXBwb3J0IGl0LiAgU2luY2Ugc2V2ZXJhbCBkaWZmZXJl bnQgcG93ZXIKICAgc3RhdGUgbWVjaGFuaXNtcyBhcmUgY3VycmVudGx5IGluIHVzZSBvbiB2YXJp b3VzIHN5c3RlbXMsIEVNQU4tCiAgIENPTlRST0wtTUlCIG9mZmVycyBhIHdheSBmb3IgYW4gZW50 aXR5IHRvIGludGVyZmFjZSB3aXRoIGFsbCBvZiB0aGUKICAgbWVjaGFuaXNtcywgYWxsb3dpbmcg Ym90aCB0aGUgaW1wbGVtZW50aW5nIGFnZW50IGFuZCBlbmQgdXNlciB0aGUKICAgZmxleGliaWxp dHkgdG8gY2hvb3NlIHRoZSBiZXN0IG1lY2hhbmlzbSBmb3IgdGhlaXIgcHVycG9zZS4gIEVudGl0 aWVzCiAgIHdoaWNoIGltcGxlbWVudCBFTUFOLUNPTlRST0wtTUlCIG11c3Qgc2V0IHRoZSBhY3Bp KDIpLCBwZXJjZW50KDMpCiAgIGFuZC9vciBkbXRmKDcpIGNhcGFiaWxpdGllcyBiaXRzIGFwcHJv cHJpYXRlbHkuCgo4LjEuICBUZXh0dWFsIENvbnZlbnRpb25zCgogICBBY3BpU3RhdGUgc3BlY2lm aWVzIHRoZSBzZXZlbiBwb3dlciB1c2FnZSBzdGF0ZXMgZGVmaW5lZCBieSB0aGUKICAgQWR2YW5j ZWQgQ29uZmlndXJhdGlvbiBhbmQgUG93ZXIgSW50ZXJmYWNlIHN0YW5kYXJkIFtBQ1BJXS4KCiAg IFBlcmNlbnRhZ2Ugc3BlY2lmaWVzIGEgZ3JhZGlhdGVkIHNjYWxlIGZyb20gMCUgKG9mZikgdG8g MTAwJSAoZnVsbC0KICAgcG93ZXIpLgoKICAgRG10ZlBvd2VyU3RhdGUgc3BlY2lmaWVzIHRoZSBm aWZ0ZWVuIHBvd2VyIHVzYWdlIHN0YXRlcyBkZWZpbmVkIGJ5CiAgIHRoZSBEaXN0cmlidXRlZCBN YW5hZ2VtZW50IFRhc2sgRm9yY2UgW0RTUDEwMjddLgoKOC4yLiAgVGhlIE5vdGlmaWNhdGlvbnMg U3VidHJlZQoKICAgRU1BTi1DT05UUk9MLU1JQiBpbXBsZW1lbnRzIG5vIG5vdGlmaWNhdGlvbnMg YXQgdGhpcyB0aW1lLgoKOC4zLiAgVGhlIFRhYmxlIFN0cnVjdHVyZXMKCiAgIFRoZSBjb250cm9s IG1lY2hhbmlzbXMgaW4gZW1hbkNvbnRyb2xUYWJsZSBhbGxvdyBhIGVuZCB1c2VyIHRvIHF1ZXJ5 CiAgIGFuZCBjaGFuZ2UgdGhlIHBvd2VyIHN0YXRlIG9mIHRoZSBlbnRpdHkuICBUbyB1c2UgZW1h bkFjcGlDb250cm9sLCBhbgogICBpbXBsZW1lbnRpbmcgZW50aXR5IG11c3Qgc2V0IHRoZSBhY3Bp KDIpIGNhcGFiaWxpdHkgYml0LiAgVG8gdXNlCiAgIGVtYW5QZXJjZW50YWdlQ29udHJvbCwgYW4g aW1wbGVtZW50aW5nIGVudGl0eSBtdXN0IHNldCB0aGUKICAgcGVyY2VudGFnZSgzKSBjYXBhYmls aXR5IGJpdC4gIFRvIHVzZSBlbWFuRG10ZkNvbnRyb2wsIGFuCiAgIGltcGxlbWVudGluZyBlbnRp dHkgbXVzdCBzZXQgdGhlIGRtdGYoNykgY2FwYWJpbGl0eSBiaXQuCgogICBXaXRoIG9uZSBleGNl cHRpb24sIHRoZSBpbXBsZW1lbnRpbmcgZW50aXR5IHdpbGwgZGVjaWRlIGhvdyB0byBtYXAKICAg dGhlIGRpZmZlcmVudCBjb250cm9sIG1lY2hhbmlzbXMgdG8gZWFjaCBvdGhlciwgYmFzZWQgb24g d2hhdCBpcwogICBhcHByb3ByaWF0ZSBmb3IgdGhlIGVudGl0eS4gIEZvciBleGFtcGxlLCBjb25z aWRlciBhIHN0YW5kYXJkIG5ldHdvcmsKICAgd29ya3N0YXRpb246CgoKCgoKClZlcmdlcyAgICAg ICAgICAgICAgICAgICBFeHBpcmVzIEF1Z3VzdCAyNywgMjAxMSAgICAgICAgICAgICAgIFtQYWdl IDEyXQoMCkludGVybmV0LURyYWZ0ICBkcmFmdC12ZXJnZXMtZW1hbi1zZXBhcmF0ZS1tb2R1bGVz LW1pYi0wMCAgRmVicnVhcnkgMjAxMQoKCiAgICAgICAgICAgICAgICAgICAgICAgICAgICstLS0t LS0rLS0tLS0tLS0tLS0tKwogICAgICAgICAgICAgICAgICAgICAgICAgICB8IEFDUEkgfCBQZXJj ZW50YWdlIHwKICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLSstLS0tLS0tLS0tLS0r CiAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgZzBzMCB8ICAgICAgIDEwMCUgfAogICAgICAg ICAgICAgICAgICAgICAgICAgICB8IGcxczEgfCAgICAgICAgNzUlIHwKICAgICAgICAgICAgICAg ICAgICAgICAgICAgfCBnMXMyIHwgICAgICAgIDY2JSB8CiAgICAgICAgICAgICAgICAgICAgICAg ICAgIHwgZzFzMyB8ICAgICAgICAzMCUgfAogICAgICAgICAgICAgICAgICAgICAgICAgICB8IGcx czQgfCAgICAgICAgIDElIHwKICAgICAgICAgICAgICAgICAgICAgICAgICAgfCBnMnM1IHwgICAg ICAgICA1JSB8CiAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgZzMgICB8ICAgICAgICAgMCUg fAogICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tKy0tLS0tLS0tLS0tLSsKCiAgICAg IFRhYmxlIDQ6IE1hcHBpbmcgb2YgQUNQSSBhbmQgUGVyY2VudGFnZSBDb250cm9sIE1lY2hhbmlz bXMgZm9yCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFdvcmtzdGF0aW9uIFhZWgoKICAg VGhlIGZsZXhpYmlsaXR5IG9mIHN1cHBvcnRpbmcgc2V2ZXJhbCBkaWZmZXJlbnQgY29udHJvbCBt ZWNoYW5pc21zIGF0CiAgIHRoZSBzYW1lIHRpbWUgbWVhbnMgdGhhdCB2ZW5kb3JzIHdobyBpbXBs ZW1lbnQgRU1BTi1DT05UUk9MLU1JQgogICBzaG91bGQgY2FyZWZ1bGx5IGNvbnNpZGVyIHRoZSBt YXBwaW5nIGZvciB0aGUgdmFyaW91cyBtZWNoYW5pc21zIGZvcgogICB0aGVpciBwcm9kdWN0LiAg VGhlIGV4Y2VwdGlvbiBpcyB3aGVuIGFuIGVudGl0eSBpbXBsZW1lbnRzIGJvdGgKICAgYWNwaSgy KSBhbmQgZG10Zig3KS4gIFRoZSBsaW5rIGJldHdlZW4gdGhlc2Ugc3RhdGVzIGRlZmluZWQgaW4K ICAgW0RTUDEwMjddIFRhYmxlIDMgbXVzdCBiZSBvYnNlcnZlZCB0byBlbnN1cmUgZW50aXR5IGNv bXBsaWFuY2UgdG8gdGhlCiAgIEFDUEkgYW5kIERNVEYgc3RhbmRhcmRzLgoKOS4gIFN0cnVjdHVy ZSBvZiB0aGUgRU1BTi1DT05URVhULU1JQiBNb2R1bGUKCiAgIEVNQU4tQ09OVEVYVC1NSUIgYnVp bGRzIG9uIEVNQU4tQ09SRS1NSUIgYnkgcHJvdmlkaW5nIGNvbnRleHQgYmVoaW5kCiAgIHRoZSBw b3dlciB1c2Ugb2YgYW4gZW50aXR5LiAgRW50aXRpZXMgd2hpY2ggaW1wbGVtZW50IEVNQU4tQ09O VEVYVC0KICAgTUlCIG11c3Qgc2V0IHRoZSBjb250ZXh0KDUpIGNhcGFiaWxpdHkgYml0IGFwcHJv cHJpYXRlbHkuCgo5LjEuICBUZXh0dWFsIENvbnZlbnRpb25zCgogICBDb250ZXh0VHlwZSBzcGVj aWZpZXMgd2hhdCB0eXBlIG9mIGNvbnRleHQgaXMgYmVpbmcgZGVmaW5lZCAtLQogICBwaHlzaWNh bCgxKSBvciBsb2dpY2FsKDIpLiAgQSBwaHlzaWNhbCBjb250ZXh0IGlzIG9uZSB3aGVyZSB0aGUK ICAgZW50aXRpZXMgYXJlIHJlbGF0ZWQgZWxlY3RyaWNhbGx5LCBsaWtlIGEgY29tbW9uIGJyYW5j aCBjaXJjdWl0IG9yCiAgIHRyYW5zZm9ybWVyLiAgQSBsb2dpY2FsIGNvbnRleHQgaXMgb25lIHdo ZXJlIHRoZSBlbnRpdGllcyBhcmUgcmVsYXRlZAogICBpbiBzb21lIG90aGVyIHdheSwgc3VjaCBh cyBvd25lcnNoaXAgb3IgaW50ZW5kZWQgdXNlLgoKOS4yLiAgVGhlIE5vdGlmaWNhdGlvbnMgU3Vi dHJlZQoKICAgRU1BTi1DT05URVhULU1JQiBpbXBsZW1lbnRzIG5vIG5vdGlmaWNhdGlvbnMgYXQg dGhpcyB0aW1lLgoKOS4zLiAgVGhlIFRhYmxlIFN0cnVjdHVyZXMKCiAgIGVtYW5Db250ZXh0VGFi bGUgaXMgYSBsaXN0IG9mIGFsbCBjb250ZXh0cyBrbm93biBieSB0aGUgYWdlbnQuICBUaGlzCiAg IGFsbG93cyBjb250ZXh0cyB0byBiZSBsaXN0ZWQgb25jZSBhbmQgcmV1c2VkIGJ5IHNldmVyYWwg ZW50aXRpZXMgaWYKICAgc3VjaCBhIG1hcHBpbmcgbWFrZXMgc2Vuc2UuCgogICBlbWFuQ29udGV4 dE1hcHBpbmdUYWJsZSBjcmVhdGVzIGEgbGluayBiZXR3ZWVuIGNvbnRleHRzIGFuZCBlbnRpdGll cy4KCgoKVmVyZ2VzICAgICAgICAgICAgICAgICAgIEV4cGlyZXMgQXVndXN0IDI3LCAyMDExICAg ICAgICAgICAgICAgW1BhZ2UgMTNdCgwKSW50ZXJuZXQtRHJhZnQgIGRyYWZ0LXZlcmdlcy1lbWFu LXNlcGFyYXRlLW1vZHVsZXMtbWliLTAwICBGZWJydWFyeSAyMDExCgoKICAgSXQgdXNlcyBhIHNp bmdsZSBlbnRyeSwgZW1hbkNvbnRleHRNYXBwaW5nUm93U3RhdHVzLCB0byBkZXRlcm1pbmUKICAg d2hldGhlciB0aGUgbWFwcGluZyBpcyBhY3RpdmUuICBNYXBwaW5ncyBjYW4gYmUgYWRkZWQgdGhy b3VnaAogICAnY3JlYXRlQW5kR28nIG9yICdjcmVhdGVBbmRXYWl0JyBhbmQgY2FuIGJlIHJlbW92 ZWQgdGhyb3VnaAogICAnZGVzdHJveScuCgoxMC4gIFN0cnVjdHVyZSBvZiB0aGUgRU1BTi1IRUFM VEgtTUlCIE1vZHVsZQoKMTAuMS4gIFRleHR1YWwgQ29udmVudGlvbnMKCiAgIFRCRAoKMTAuMi4g IFRoZSBOb3RpZmljYXRpb25zIFN1YnRyZWUKCiAgIEVNQU4tSEVBTFRILU1JQiBpbXBsZW1lbnRz IG5vIG5vdGlmaWNhdGlvbnMgYXQgdGhpcyB0aW1lLgoKMTAuMy4gIFRoZSBUYWJsZSBTdHJ1Y3R1 cmVzCgogICBUQkQKCjExLiAgU3RydWN0dXJlIG9mIHRoZSBFTUFOLUxMRFAtTUlCIE1vZHVsZQoK MTEuMS4gIFRleHR1YWwgQ29udmVudGlvbnMKCiAgIFRoZSB2YXJpb3VzIHRleHR1YWwgY29udmVu dGlvbnMgaW1wbGVtZW50ZWQgYnkgdGhpcyBNSUIgYXJlIGZ1bGx5CiAgIGRlc2NyaWJlZCBpbiB0 aGUgTUlCIGl0c2VsZi4KCjExLjIuICBUaGUgTm90aWZpY2F0aW9ucyBTdWJ0cmVlCgogICBFTUFO LUxMRFAtTUlCIGltcGxlbWVudHMgbm8gbm90aWZpY2F0aW9ucyBhdCB0aGlzIHRpbWUuCgoxMS4z LiAgVGhlIFRhYmxlIFN0cnVjdHVyZXMKCiAgIGVtYW5MbGRwVGFibGUgcHJvdmlkZXMgTExEUC1z cGVjaWZpYyBpbmZvcm1hdGlvbiBmb3IgYW4gZW50aXR5LgoKMTIuICBSZWxhdGlvbnNoaXAgdG8g T3RoZXIgTUlCIE1vZHVsZXMKCiAgIFtbYW5jaG9yMjk6IFtURU1QTEFURSBUT0RPXTogVGhlIG5h cnJhdGl2ZSBwYXJ0IHNob3VsZCBpbmNsdWRlIGEKICAgc2VjdGlvbiB0aGF0IHNwZWNpZmllcyB0 aGUgcmVsYXRpb25zaGlwIChpZiBhbnkpIG9mIHRoZSBNSUIgbW9kdWxlcwogICBjb250YWluZWQg aW4gdGhpcyBpbnRlcm5ldCBkcmFmdHMgdG8gb3RoZXIgc3RhbmRhcmRzLCBwYXJ0aWN1bGFybHkg dG8KICAgc3RhbmRhcmRzIGNvbnRhaW5pbmcgb3RoZXIgTUlCIG1vZHVsZXMuICBJZiB0aGUgTUlC IG1vZHVsZXMgZGVmaW5lZAogICBieSB0aGUgc3BlY2lmaWNhdGlvbiBpbXBvcnQgZGVmaW5pdGlv bnMgZnJvbSBvdGhlciBNSUIgbW9kdWxlcyBvciBhcmUKICAgYWx3YXlzIGltcGxlbWVudGVkIGlu IGNvbmp1bmN0aW9uIHdpdGggb3RoZXIgTUlCIG1vZHVsZXMsIHRoZW4gdGhvc2UKICAgZmFjdHMg c2hvdWxkIGJlIG5vdGVkIGluIHRoZSBuYXJyYXRhaXZlIHNlY3Rpb24sIGFzIHNob3VsZCBhbnkK ICAgc3BlY2lhbCBpbnRlcnByZXRhdGlvbnMgb2Ygb2JqZWN0cyBpbiBvdGhlciBNSUIgbW9kdWxl cy4gIE5vdGUgdGhhdAogICBjaXRhdGlvbnMgbWF5IE5PVCBiZSBwdXQgaW50byB0aGUgTUlCIG1v ZHVsZSBwb3J0aW9ucyBvZiB0aGUgaW50ZXJuZXQKICAgZHJhZnQsIGJ1dCBkb2N1bWVudHMgdXNl ZCBmb3IgSW1wb3J0ZWQgaXRlbXMgYXJlIE5vcm1hdGl2ZQogICByZWZlcmVuY2VzLCBzbyB0aGUg Y2l0YXRpb25zIHNob3VsZCBleGlzdCBpbiB0aGUgbmFycmF0aXZlIHNlY3Rpb24gb2YKICAgdGhl IGludGVybmV0IGRyYWZ0LiAgVGhlIHByZWZlcnJlZCB3YXkgdG8gZmlsbCBpbiBhIFJFRkVSRU5D RSBjbGF1c2UKCgoKVmVyZ2VzICAgICAgICAgICAgICAgICAgIEV4cGlyZXMgQXVndXN0IDI3LCAy MDExICAgICAgICAgICAgICAgW1BhZ2UgMTRdCgwKSW50ZXJuZXQtRHJhZnQgIGRyYWZ0LXZlcmdl cy1lbWFuLXNlcGFyYXRlLW1vZHVsZXMtbWliLTAwICBGZWJydWFyeSAyMDExCgoKICAgaW4gYSBN SUIgbW9kdWxlIGlzIG9mIHRoZSBmb3JtOiAiR3VpZGVsaW5lcyBmb3IgV3JpdGluZyBhbiBJQU5B CiAgIENvbnNpZGVyYXRpb25zIFNlY3Rpb24gaW4gUkZDcyIsIFJGQzI0MzQsIHNlY3Rpb24gMi4z Ll1dCgoxMi4xLiAgUmVsYXRpb25zaGlwIHRvIHRoZSBbVEVNUExBVEUgVE9ET10gTUlCCgogICBb W2FuY2hvcjMxOiBFeGFtcGxlOiBUaGUgSW50ZXJmYWNlIE1JQiBbUkZDMjg2M10gcmVxdWlyZXMg dGhhdCBhbnkKICAgTUlCIG1vZHVsZSB3aGljaCBpcyBhbiBhZGp1bmN0IG9mIHRoZSBJbnRlcmZh Y2UgTUlCIGNsYXJpZnkgc3BlY2lmaWMKICAgYXJlYXMgd2l0aGluIHRoZSBJbnRlcmZhY2UgTUlC LiAgVGhlc2UgYXJlYXMgd2VyZSBpbnRlbnRpb25hbGx5IGxlZnQKICAgdmFndWUgaW4gdGhlIElu dGVyZmFjZSBNSUIgdG8gYXZvaWQgb3Zlci1jb25zdHJhaW5pbmcgdGhlIE1JQiwKICAgdGhlcmVi eSBwcmVjbHVkaW5nIG1hbmFnZW1lbnQgb2YgY2VydGFpbiBtZWRpYS10eXBlcy4gIFNlY3Rpb24g NCBvZgogICBbUkZDMjg2M10gZW51bWVyYXRlcyBzZXZlcmFsIGFyZWFzIHdoaWNoIGEgbWVkaWEt c3BlY2lmaWMgTUlCIG11c3QKICAgY2xhcmlmeS4gIFRoZSBpbXBsZW1lbnRvciBpcyByZWZlcnJl ZCB0byBbUkZDMjg2M10gaW4gb3JkZXIgdG8KICAgdW5kZXJzdGFuZCB0aGUgZ2VuZXJhbCBpbnRl bnQgb2YgdGhlc2UgYXJlYXMuXV0KCjEyLjIuICBNSUIgbW9kdWxlcyByZXF1aXJlZCBmb3IgSU1Q T1JUUwoKICAgW1thbmNob3IzMzogW1RFTVBMQVRFIFRPRE9dOiBDaXRhdGlvbnMgYXJlIG5vdCBw ZXJtaXR0ZWQgd2l0aGluIGEgTUlCCiAgIG1vZHVsZSwgYnV0IGFueSBtb2R1bGUgbWVudGlvbmVk IGluIGFuIElNUE9SVFMgY2xhdXNlIG9yIGRvY3VtZW50CiAgIG1lbnRpb25lZCBpbiBhIFJFRkVS RU5DRSBjbGF1c2UgaXMgYSBOb3JtYXRpdmUgcmVmZXJlbmNlLCBhbmQgbXVzdCBiZQogICBjaXRl ZCBzb21lcGxhY2Ugd2l0aGluIHRoZSBuYXJyYXRpdmUgc2VjdGlvbnMuICBJZiB0aGVyZSBhcmUg aW1wb3J0ZWQKICAgaXRlbXMgaW4gdGhlIE1JQiBtb2R1bGUsIHN1Y2ggYXMgVGV4dHVhbCBDb252 ZW50aW9ucywgdGhhdCBhcmUgbm90CiAgIGFscmVhZHkgY2l0ZWQsIHRoZXkgY2FuIGJlIGNpdGVk IGluIHRleHQgaGVyZS4gIFNpbmNlIHJlbGF0aW9uc2hpcHMKICAgdG8gb3RoZXIgTUlCIG1vZHVs ZXMgc2hvdWxkIGJlIGRlc2NyaWJlZCBpbiB0aGUgbmFycmF0aXZlIHRleHQsIHRoaXMKICAgc2Vj dGlvbiBpcyB0eXBpY2FsbHkgdXNlZCB0byBjaXRlIG1vZHVsZXMgZnJvbSB3aGljaCBUZXh0dWFs CiAgIENvbnZlbnRpb25zIGFyZSBpbXBvcnRlZC4gIEV4YW1wbGU6ICJUaGUgZm9sbG93aW5nIE1J QiBtb2R1bGUgSU1QT1JUUwogICBvYmplY3RzIGZyb20gU05NUHYyLVNNSSBbUkZDMjU3OF0sIFNO TVB2Mi1UQyBbUkZDMjU3OV0sIFNOTVB2Mi1DT05GCiAgIFtSRkMyNTgwXSwgYW5kIElGLU1JQiBb UkZDMjg2M10uIl1dCgoxMy4gIERlZmluaXRpb25zCgpFTUFOLU1JQiBERUZJTklUSU9OUyA6Oj0g QkVHSU4KCklNUE9SVFMKICAgIE1PRFVMRS1JREVOVElUWSwgT0JKRUNULVRZUEUsIE5PVElGSUNB VElPTi1UWVBFLAogICAgSW50ZWdlcjMyLCBVbnNpZ25lZDMyLCBtaWItMgogICAgRlJPTSBTTk1Q djItU01JCgogICAgU25tcEFkbWluU3RyaW5nCiAgICBGUk9NIFNOTVAtRlJBTUVXT1JLLU1JQgoK ICAgIFRFWFRVQUwtQ09OVkVOVElPTiwgUm93U3RhdHVzLCBUaW1lSW50ZXJ2YWwsCiAgICBUcnV0 aFZhbHVlCiAgICBGUk9NIFNOTVB2Mi1UQwoKICAgIE1PRFVMRS1DT01QTElBTkNFLCBPQkpFQ1Qt R1JPVVAsIE5PVElGSUNBVElPTi1HUk9VUAogICAgRlJPTSBTTk1QdjItQ09ORgoKICAgIFBoeXNp Y2FsSW5kZXhPclplcm8KCgoKVmVyZ2VzICAgICAgICAgICAgICAgICAgIEV4cGlyZXMgQXVndXN0 IDI3LCAyMDExICAgICAgICAgICAgICAgW1BhZ2UgMTVdCgwKSW50ZXJuZXQtRHJhZnQgIGRyYWZ0 LXZlcmdlcy1lbWFuLXNlcGFyYXRlLW1vZHVsZXMtbWliLTAwICBGZWJydWFyeSAyMDExCgoKICAg IEZST00gRU5USVRZLU1JQjsKCmVtYW4gTU9EVUxFLUlERU5USVRZCiAgICBMQVNULVVQREFURUQg ICAgIjIwMTEwMjExMDAwMFoiCiAgICBPUkdBTklaQVRJT04gICAgIkN5YmVyIFN3aXRjaGluZywg SW5jLiIKICAgIENPTlRBQ1QtSU5GTyAgICAiaHR0cDovL3d3dy5jeWJlcnN3aXRjaGluZy5jb20i CiAgICBERVNDUklQVElPTiAgICAgIlRoZSBNSUIgZm9yIHJlcG9ydGluZyBhbmQgbWFuYWdpbmcg cG93ZXIgdXNhZ2Ugb2YKICAgICAgICAgICAgICAgICAgICBuZXR3b3JrZWQgZW50aXRpZXMgdGhy b3VnaCBTTk1QLiIKICAgIFJFVklTSU9OICAgICAgICAiMjAxMTAyMTEwMDAwWiIKICAgIERFU0NS SVBUSU9OICAgICAiSW5pdGlhbCBkcmFmdCByZWxlYXNlLiIKICAgIDo6PSB7IG1pYi0yIFhYWCB9 CgpFbWFuRW50aXR5Um9sZSA6Oj0gVEVYVFVBTC1DT05WRU5USU9OCiAgICBTVEFUVVMgICAgICAg ICAgY3VycmVudAogICAgREVTQ1JJUFRJT04gICAgICJTcGVjaWZpZXMgdGhlIHR5cGUgb2YgZW50 aXR5LiIKICAgIFNZTlRBWCAgICAgICAgICBJTlRFR0VSIHsKICAgICAgICAgICAgICAgICAgICAg ICAgbWV0ZXIoMCksCiAgICAgICAgICAgICAgICAgICAgICAgIGNvbnN1bWVyKDEpCiAgICAgICAg ICAgICAgICAgICAgfQoKRW1hbkVudGl0eUNhcGFiaWxpdGllcyA6Oj0gVEVYVFVBTC1DT05WRU5U SU9OCiAgICBTVEFUVVMgICAgICAgICAgY3VycmVudAogICAgREVTQ1JJUFRJT04gICAgICJTcGVj aWZpZXMgdGhlIGNhcGFiaWxpdGllcyBvZiB0aGUgZW50aXR5LiIKICAgIFNZTlRBWCAgICAgICAg ICBCSVRTIHsKICAgICAgICAgICAgICAgICAgICAgICAgaW5zdGFudCgwKSwgICAgIC0tIGluc3Rh bnQgZGF0YSByZXBvcnRpbmcKICAgICAgICAgICAgICAgICAgICAgICAgaGlzdG9yaWNhbCgxKSwg IC0tIGhpc3RvcmljYWwgZGF0YSByZXBvcnRpbmcKICAgICAgICAgICAgICAgICAgICAgICAgYWNw aSgyKSwgICAgICAgIC0tIEFDUEktYmFzZWQgY29udHJvbAogICAgICAgICAgICAgICAgICAgICAg ICBwZXJjZW50KDMpLCAgICAgLS0gUGVyY2VudGFnZS1iYXNlZCBjb250cm9sCiAgICAgICAgICAg ICAgICAgICAgICAgIGhlYWx0aCg0KSwgICAgICAtLSBoZWFsdGggcmVwb3J0aW5nCiAgICAgICAg ICAgICAgICAgICAgICAgIGNvbnRleHQoNSksICAgICAtLSBjb250ZXh0IGF3YXJlbmVzcwogICAg ICAgICAgICAgICAgICAgICAgICBsbGRwKDYpLCAgICAgICAgLS0gTExEUCBhd2FyZW5lc3MKICAg ICAgICAgICAgICAgICAgICAgICAgZG10Zig3KSAgICAgICAgIC0tIERNVEYgUG93ZXIgU3RhdGUg Y29udHJvbAogICAgICAgICAgICAgICAgICAgIH0KClRob3VzYW5kdGhzIDo6PSBURVhUVUFMLUNP TlZFTlRJT04KICAgIERJU1BMQVktSElOVCAgICAiZC0zIgogICAgU1RBVFVTICAgICAgICAgIGN1 cnJlbnQKICAgIERFU0NSSVBUSU9OICAgICAiU3BlY2lmaWVzIGEgdmFsdWUgYXMgMTBeKC0zKSBw cmVjaXNpb24uIgogICAgU1lOVEFYICAgICAgICAgIEludGVnZXIzMgoKVW5pdE11bHRpcGxpZXIg Ojo9IFRFWFRVQUwtQ09OVkVOVElPTgogICAgU1RBVFVTICAgICAgICAgIGN1cnJlbnQKICAgIERF U0NSSVBUSU9OICAgICAiVGhlIFVuaXQgTXVsdGlwbGllciBpcyBhbiBpbnRlZ2VyIHZhbHVlIHRo YXQKICAgICAgICAgICAgICAgICAgICByZXByZXNlbnRzIHRoZSBJRUVFIDYxODUwIEFubmV4IEEg dW5pdHMgbXVsdGlwbGllcgogICAgICAgICAgICAgICAgICAgIGFzc29jaWF0ZWQgd2l0aCB0aGUg aW50ZWdlciB1bml0cyB1c2VkIHRvIG1lYXN1cmUKICAgICAgICAgICAgICAgICAgICB0aGUgcG93 ZXIgb3IgZW5lcmd5LgoKICAgICAgICAgICAgICAgICAgICBGb3IgZXhhbXBsZSwgd2hlbiB1c2Vk IHdpdGggcG1Qb3dlclVuaXRNdWx0aXBsaWVyLAoKCgpWZXJnZXMgICAgICAgICAgICAgICAgICAg RXhwaXJlcyBBdWd1c3QgMjcsIDIwMTEgICAgICAgICAgICAgICBbUGFnZSAxNl0KDApJbnRlcm5l dC1EcmFmdCAgZHJhZnQtdmVyZ2VzLWVtYW4tc2VwYXJhdGUtbW9kdWxlcy1taWItMDAgIEZlYnJ1 YXJ5IDIwMTEKCgogICAgICAgICAgICAgICAgICAgIC0zIHJlcHJlc2VudHMgMTBeLTMgb3IgbWls bGl3YXR0cy4iCiAgICBSRUZFUkVOQ0UgICAgICAgIlRoZSBJbnRlcm5hdGlvbmFsIFN5c3RlbSBv ZiBVbml0cyAoU0kpLCBOYXRpb25hbAogICAgICAgICAgICAgICAgICAgIEluc3RpdHV0ZSBvZiBT dGFuZGFyZHMgYW5kIFRlY2hub2xvZ3ksIFNwZWMuIFB1YmwuCiAgICAgICAgICAgICAgICAgICAg MzMwLCBBdWd1c3QgMTk5MS4iCiAgICBTWU5UQVggICAgICAgICAgSU5URUdFUiB7CiAgICAgICAg ICAgICAgICAgICAgICAgIHlvY3RvKC0yNCksICAgLS0gMTBeLTI0CiAgICAgICAgICAgICAgICAg ICAgICAgIHplcHRvKC0yMSksICAgLS0gMTBeLTIxCiAgICAgICAgICAgICAgICAgICAgICAgIGF0 dG8oLTE4KSwgICAgLS0gMTBeLTE4CiAgICAgICAgICAgICAgICAgICAgICAgIGZlbXRvKC0xNSks ICAgLS0gMTBeLTE1CiAgICAgICAgICAgICAgICAgICAgICAgIHBpY28oLTEyKSwgICAgLS0gMTBe LTEyCiAgICAgICAgICAgICAgICAgICAgICAgIG5hbm8oLTkpLCAgICAgLS0gMTBeLTkKICAgICAg ICAgICAgICAgICAgICAgICAgbWljcm8oLTYpLCAgICAtLSAxMF4tNgogICAgICAgICAgICAgICAg ICAgICAgICBtaWxsaSgtMyksICAgIC0tIDEwXi0zCiAgICAgICAgICAgICAgICAgICAgICAgIHVu aXRzKDApLCAgICAgLS0gMTBeMAogICAgICAgICAgICAgICAgICAgICAgICBraWxvKDMpLCAgICAg IC0tIDEwXjMKICAgICAgICAgICAgICAgICAgICAgICAgbWVnYSg2KSwgICAgICAtLSAxMF42CiAg ICAgICAgICAgICAgICAgICAgICAgIGdpZ2EoOSksICAgICAgLS0gMTBeOQogICAgICAgICAgICAg ICAgICAgICAgICB0ZXJhKDEyKSwgICAgIC0tIDEwXjEyCiAgICAgICAgICAgICAgICAgICAgICAg IHBldGEoMTUpLCAgICAgLS0gMTBeMTUKICAgICAgICAgICAgICAgICAgICAgICAgZXhhKDE4KSwg ICAgICAtLSAxMF4xOAogICAgICAgICAgICAgICAgICAgICAgICB6ZXR0YSgyMSksICAgIC0tIDEw XjIxCiAgICAgICAgICAgICAgICAgICAgICAgIHlvdHRhKDI0KSAgICAgLS0gMTBeMjQKICAgICAg ICAgICAgICAgICAgICB9CgplbWFuQ29yZSBPQkpFQ1QgSURFTlRJRklFUgogICAgOjo9IHsgZW1h biAxIH0KCmVtYW5FbnRpdHlUYWJsZSBPQkpFQ1QtVFlQRQogICAgU1lOVEFYICAgICAgICAgIFNF UVVFTkNFIE9GIEVtYW5FbnRpdHlFbnRyeQogICAgTUFYLUFDQ0VTUyAgICAgIG5vdC1hY2Nlc3Np YmxlCiAgICBTVEFUVVMgICAgICAgICAgY3VycmVudAogICAgREVTQ1JJUFRJT04gICAgICJBIHRh YmxlIG9mIGFsbCBwb3dlciBlbnRpdGllcyBiZWluZyBtYW5hZ2VkLiIKICAgIDo6PSB7IGVtYW5D b3JlIDEgfQoKZW1hbkVudGl0eUVudHJ5IE9CSkVDVC1UWVBFCiAgICBTWU5UQVggICAgICAgICAg RW1hbkVudGl0eUVudHJ5CiAgICBNQVgtQUNDRVNTICAgICAgbm90LWFjY2Vzc2libGUKICAgIFNU QVRVUyAgICAgICAgICBjdXJyZW50CiAgICBERVNDUklQVElPTiAgICAgIkEgcG93ZXIgZW50aXR5 LiIKICAgIElOREVYICAgICAgICAgICB7IGVtYW5FbnRpdHlJbmRleCB9CiAgICA6Oj0geyBlbWFu RW50aXR5VGFibGUgMSB9CgpFbWFuRW50aXR5RW50cnkgOjo9CiAgICBTRVFVRU5DRSB7CiAgICAg ICAgZW1hbkVudGl0eUluZGV4ICAgICAgICAgICAgICAgICBVbnNpZ25lZDMyLAogICAgICAgIGVt YW5FbnRpdHlOYW1lICAgICAgICAgICAgICAgICAgU25tcEFkbWluU3RyaW5nLAogICAgICAgIGVt YW5FbnRpdHlBbGlhcyAgICAgICAgICAgICAgICAgU25tcEFkbWluU3RyaW5nLAogICAgICAgIGVt YW5FbnRpdHlUeXBlICAgICAgICAgICAgICAgICAgRW1hbkVudGl0eVJvbGUsCgoKClZlcmdlcyAg ICAgICAgICAgICAgICAgICBFeHBpcmVzIEF1Z3VzdCAyNywgMjAxMSAgICAgICAgICAgICAgIFtQ YWdlIDE3XQoMCkludGVybmV0LURyYWZ0ICBkcmFmdC12ZXJnZXMtZW1hbi1zZXBhcmF0ZS1tb2R1 bGVzLW1pYi0wMCAgRmVicnVhcnkgMjAxMQoKCiAgICAgICAgZW1hbkVudGl0eUNhcGFiaWxpdGll cyAgICAgICAgICBFbWFuRW50aXR5Q2FwYWJpbGl0aWVzLAogICAgICAgIGVtYW5FbnRpdHlQYXJl bnQgICAgICAgICAgICAgICAgVW5zaWduZWQzMiwKICAgICAgICBlbWFuRW50aXR5UGh5c2ljYWxJ ZCAgICAgICAgICAgIFBoeXNpY2FsSW5kZXhPclplcm8sCiAgICAgICAgZW1hbkVudGl0eUxvZ2lj YWxJZCAgICAgICAgICAgICBJbnRlZ2VyMzIKICAgIH0KCmVtYW5FbnRpdHlJbmRleCBPQkpFQ1Qt VFlQRQogICAgU1lOVEFYICAgICAgICAgIFVuc2lnbmVkMzIKICAgIE1BWC1BQ0NFU1MgICAgICBu b3QtYWNjZXNzaWJsZQogICAgU1RBVFVTICAgICAgICAgIGN1cnJlbnQKICAgIERFU0NSSVBUSU9O ICAgICAiVGhlIGluZGV4IG9mIHRoZSBlbnRyeSBpbiB0aGUgdGFibGUuIgogICAgOjo9IHsgZW1h bkVudGl0eUVudHJ5IDEgfQoKZW1hbkVudGl0eU5hbWUgT0JKRUNULVRZUEUKICAgIFNZTlRBWCAg ICAgICAgICBTbm1wQWRtaW5TdHJpbmcKICAgIE1BWC1BQ0NFU1MgICAgICByZWFkLW9ubHkKICAg IFNUQVRVUyAgICAgICAgICBjdXJyZW50CiAgICBERVNDUklQVElPTiAgICAgIlRoZSBuYW1lIG9m IHRoZSBlbnRpdHkuIgogICAgOjo9IHsgZW1hbkVudGl0eUVudHJ5IDIgfQoKZW1hbkVudGl0eUFs aWFzIE9CSkVDVC1UWVBFCiAgICBTWU5UQVggICAgICAgICAgU25tcEFkbWluU3RyaW5nCiAgICBN QVgtQUNDRVNTICAgICAgcmVhZC13cml0ZQogICAgU1RBVFVTICAgICAgICAgIGN1cnJlbnQKICAg IERFU0NSSVBUSU9OICAgICAiVGhlIHVzZXItZGVmaW5lZCBhbGlhcyBvZiB0aGUgZW50aXR5LiIK ICAgIDo6PSB7IGVtYW5FbnRpdHlFbnRyeSAzIH0KCmVtYW5FbnRpdHlUeXBlIE9CSkVDVC1UWVBF CiAgICBTWU5UQVggICAgICAgICAgRW1hbkVudGl0eVJvbGUKICAgIE1BWC1BQ0NFU1MgICAgICBy ZWFkLW9ubHkKICAgIFNUQVRVUyAgICAgICAgICBjdXJyZW50CiAgICBERVNDUklQVElPTiAgICAg IlRoZSB0eXBlIG9mIGVudGl0eSBiZWluZyBtb2RlbGVkLiIKICAgIDo6PSB7IGVtYW5FbnRpdHlF bnRyeSA0IH0KCmVtYW5FbnRpdHlDYXBhYmlsaXRpZXMgT0JKRUNULVRZUEUKICAgIFNZTlRBWCAg ICAgICAgICBFbWFuRW50aXR5Q2FwYWJpbGl0aWVzCiAgICBNQVgtQUNDRVNTICAgICAgcmVhZC1v bmx5CiAgICBTVEFUVVMgICAgICAgICAgY3VycmVudAogICAgREVTQ1JJUFRJT04gICAgICJBIGxp c3Qgb2YgY2FwYWJpbGl0aWVzIHN1cHBvcnRlZCBieSB0aGlzIGVudGl0eS4iCiAgICA6Oj0geyBl bWFuRW50aXR5RW50cnkgNSB9CgplbWFuRW50aXR5UGFyZW50IE9CSkVDVC1UWVBFCiAgICBTWU5U QVggICAgICAgICAgVW5zaWduZWQzMgogICAgTUFYLUFDQ0VTUyAgICAgIHJlYWQtb25seQogICAg U1RBVFVTICAgICAgICAgIGN1cnJlbnQKICAgIERFU0NSSVBUSU9OICAgICAiVGhlIGluZGV4IG9m IHRoZSBlbnRpdHkncyBwYXJlbnQgaW4gdGhlIHRhYmxlLiIKICAgOjo9IHsgZW1hbkVudGl0eUVu dHJ5IDYgfQoKCgoKVmVyZ2VzICAgICAgICAgICAgICAgICAgIEV4cGlyZXMgQXVndXN0IDI3LCAy MDExICAgICAgICAgICAgICAgW1BhZ2UgMThdCgwKSW50ZXJuZXQtRHJhZnQgIGRyYWZ0LXZlcmdl cy1lbWFuLXNlcGFyYXRlLW1vZHVsZXMtbWliLTAwICBGZWJydWFyeSAyMDExCgoKZW1hbkVudGl0 eVBoeXNpY2FsSWQgT0JKRUNULVRZUEUKICAgIFNZTlRBWCAgICAgICAgICBQaHlzaWNhbEluZGV4 T3JaZXJvCiAgICBNQVgtQUNDRVNTICAgICAgcmVhZC1vbmx5CiAgICBTVEFUVVMgICAgICAgICAg Y3VycmVudAogICAgREVTQ1JJUFRJT04gICAgICJUaGUgaW5kZXggb2YgdGhlIGVudGl0eSdzIGVu dHJ5IGluCiAgICAgICAgICAgICAgICAgICAgZW50UGh5c2ljYWxUYWJsZSwgb3IgemVybyAoMCkg aWYgdW51c2VkLiIKICAgOjo9IHsgZW1hbkVudGl0eUVudHJ5IDcgfQoKZW1hbkVudGl0eUxvZ2lj YWxJZCBPQkpFQ1QtVFlQRQogICAgU1lOVEFYICAgICAgICAgIEludGVnZXIzMgogICAgTUFYLUFD Q0VTUyAgICAgIHJlYWQtb25seQogICAgU1RBVFVTICAgICAgICAgIGN1cnJlbnQKICAgIERFU0NS SVBUSU9OICAgICAiVGhlIGluZGV4IG9mIHRoZSBlbnRpdHkncyBlbnRyeSBpbgogICAgICAgICAg ICAgICAgICAgIGVudExvZ2ljYWxUYWJsZSwgb3IgemVybyAoMCkgaWYgdW51c2VkLiIKICAgOjo9 IHsgZW1hbkVudGl0eUVudHJ5IDggfQoKLS0KLS0gRU1BTiBEYXRhIEFkZC1PbgotLQoKZW1hbkRh dGEgT0JKRUNUIElERU5USUZJRVIKICAgIDo6PSB7IGVtYW4gMiB9CgpQZXJjZW50YWdlRGlzdG9y dGlvbiA6Oj0gVEVYVFVBTC1DT05WRU5USU9OCiAgICBESVNQTEFZLUhJTlQgICAgImQtMyIKICAg IFNUQVRVUyAgICAgICAgICBjdXJyZW50CiAgICBERVNDUklQVElPTiAgICAgIlNwZWNpZmllcyB0 aGUgZGlzdG9ydGlvbiBhcyBhIHRlbnRoIG9mIGEgcGVyY2VudAogICAgICAgICAgICAgICAgICAg ICgwLjElKS4iCiAgICBTWU5UQVggICAgICAgICAgVW5zaWduZWQzMiAoMC4uMTAwMCkKClBoYXNl T2Zmc2V0IDo6PSBURVhUVUFMLUNPTlZFTlRJT04KICAgIERJU1BMQVktSElOVCAgICAiZCIKICAg IFNUQVRVUyAgICAgICAgICBjdXJyZW50CiAgICBERVNDUklQVElPTiAgICAgIlNwZWNpZmllcyB0 aGUgcGhhc2Ugb2Zmc2V0LiIKICAgIFNZTlRBWCAgICAgICAgICBJbnRlZ2VyMzIgKC0zNjAuLjM2 MCkKCkRhdGFBY2N1cmFjeSA6Oj0gVEVYVFVBTC1DT05WRU5USU9OCiAgICBESVNQTEFZLUhJTlQg ICAgImQtNCIKICAgIFNUQVRVUyAgICAgICAgICBjdXJyZW50CiAgICBERVNDUklQVElPTiAgICAg IlNwZWNpZmllcyB0aGUgZGF0YSBhY2N1cmFjeSBhcyBhIGh1bmRyZWR0aCBvZiBhCiAgICAgICAg ICAgICAgICAgICAgcGVyY2VudCAoZXguIDAuMDAwMSBvciAwLjAxJSkuIgogICAgU1lOVEFYICAg ICAgSW50ZWdlcjMyICgtMTAwMDAuLjEwMDAwKQoKRGF0YUNhbGliZXIgOjo9IFRFWFRVQUwtQ09O VkVOVElPTgogICAgU1RBVFVTICAgICAgICAgIGN1cnJlbnQKICAgIERFU0NSSVBUSU9OICAgICAi U3BlY2lmaWVzIHRoZSBkYXRhIGNhbGliZXIuIgogICAgU1lOVEFYICAgICAgICAgIElOVEVHRVIg ewogICAgICAgICAgICAgICAgICAgICAgICB1bmtub3duKDApLAoKCgpWZXJnZXMgICAgICAgICAg ICAgICAgICAgRXhwaXJlcyBBdWd1c3QgMjcsIDIwMTEgICAgICAgICAgICAgICBbUGFnZSAxOV0K DApJbnRlcm5ldC1EcmFmdCAgZHJhZnQtdmVyZ2VzLWVtYW4tc2VwYXJhdGUtbW9kdWxlcy1taWIt MDAgIEZlYnJ1YXJ5IDIwMTEKCgogICAgICAgICAgICAgICAgICAgICAgICBhY3R1YWwoMSksCiAg ICAgICAgICAgICAgICAgICAgICAgIGVzdGltYXRlZCgyKSwKICAgICAgICAgICAgICAgICAgICAg ICAgcHJlc3VtZWQoMykKICAgICAgICAgICAgICAgICAgICB9CgpQb3dlclR5cGUgOjo9IFRFWFRV QUwtQ09OVkVOVElPTgogICAgU1RBVFVTICAgICAgICAgIGN1cnJlbnQKICAgIERFU0NSSVBUSU9O ICAgICAiU3BlY2lmaWVzIHRoZSB0eXBlIG9mIHBvd2VyLiIKICAgIFNZTlRBWCAgICAgICAgICBJ TlRFR0VSIHsKICAgICAgICAgICAgICAgICAgICAgICAgdW5rbm93bigwKSwKICAgICAgICAgICAg ICAgICAgICAgICAgYWMoMSksCiAgICAgICAgICAgICAgICAgICAgICAgIGRjKDIpCiAgICAgICAg ICAgICAgICAgICAgfQoKRW1hbkRhdGFUeXBlIDo6PSBURVhUVUFMLUNPTlZFTlRJT04KICAgIFNU QVRVUyAgICAgICAgICBjdXJyZW50CiAgICBERVNDUklQVElPTiAgICAgIlNwZWNpZmllcyB0aGUg ZGF0YSB0eXBlIHRvIHVzZSBmb3IgYW4gYWxlcnQKICAgICAgICAgICAgICAgICAgICBjb21wYXJp c29uLiIKICAgIFNZTlRBWCAgICAgICAgICBJTlRFR0VSIHsKICAgICAgICAgICAgICAgICAgICAg ICAgdW5rbm93bigwKSwKICAgICAgICAgICAgICAgICAgICAgICAgdW5kZWZpbmVkKDEpLAogICAg ICAgICAgICAgICAgICAgICAgICBjdXJyZW50KDIpLAogICAgICAgICAgICAgICAgICAgICAgICB2 b2x0YWdlKDMpLAogICAgICAgICAgICAgICAgICAgICAgICBhY3RpdmVwb3dlcig0KSwKICAgICAg ICAgICAgICAgICAgICAgICAgcmVhY3RpdmVwb3dlcig1KSwKICAgICAgICAgICAgICAgICAgICAg ICAgYXBwYXJlbnRwb3dlcig2KSwKICAgICAgICAgICAgICAgICAgICAgICAgZnJlcXVlbmN5KDcp LAogICAgICAgICAgICAgICAgICAgICAgICBwb3dlcmZhY3Rvcig4KQogICAgICAgICAgICAgICAg ICAgIH0KCkNvbXBhcmlzb25PcGVyYXRvciA6Oj0gVEVYVFVBTC1DT05WRU5USU9OCiAgICBTVEFU VVMgICAgICAgICAgY3VycmVudAogICAgREVTQ1JJUFRJT04gICAgICJTcGVjaWZpZXMgYSBjb21w YXJpc29uIG9wZXJhdG9yLiIKICAgIFNZTlRBWCAgICAgICAgICBJTlRFR0VSIHsKICAgICAgICAg ICAgICAgICAgICAgICAgdW5rbm93bigwKSwKICAgICAgICAgICAgICAgICAgICAgICAgdW5kZWZp bmVkKDEpLAogICAgICAgICAgICAgICAgICAgICAgICBlcXVhbCgyKSwKICAgICAgICAgICAgICAg ICAgICAgICAgbm90ZXF1YWwoMyksCiAgICAgICAgICAgICAgICAgICAgICAgIGdyZWF0ZXIoNCks CiAgICAgICAgICAgICAgICAgICAgICAgIGdyZWF0ZXJvcmVxdWFsKDUpLAogICAgICAgICAgICAg ICAgICAgICAgICBsZXNzKDYpLAogICAgICAgICAgICAgICAgICAgICAgICBsZXNzb3JlcXVhbCg3 KQogICAgICAgICAgICAgICAgICAgIH0KCkFsZXJ0U2V2ZXJpdHkgOjo9IFRFWFRVQUwtQ09OVkVO VElPTgogICAgU1RBVFVTICAgICAgICAgIGN1cnJlbnQKICAgIERFU0NSSVBUSU9OICAgICAiU3Bl Y2lmaWVzIGEgc2V2ZXJpdHkgbGV2ZWwgZm9yIGFuIGFsZXJ0LiIKICAgIFNZTlRBWCAgICAgICAg ICBJTlRFR0VSIHsKCgoKVmVyZ2VzICAgICAgICAgICAgICAgICAgIEV4cGlyZXMgQXVndXN0IDI3 LCAyMDExICAgICAgICAgICAgICAgW1BhZ2UgMjBdCgwKSW50ZXJuZXQtRHJhZnQgIGRyYWZ0LXZl cmdlcy1lbWFuLXNlcGFyYXRlLW1vZHVsZXMtbWliLTAwICBGZWJydWFyeSAyMDExCgoKICAgICAg ICAgICAgICAgICAgICAgICAgZW1lcmdlbmN5KDApLAogICAgICAgICAgICAgICAgICAgICAgICBh bGVydCgxKSwKICAgICAgICAgICAgICAgICAgICAgICAgY3JpdGljYWwoMiksCiAgICAgICAgICAg ICAgICAgICAgICAgIGVycm9yKDMpLAogICAgICAgICAgICAgICAgICAgICAgICB3YXJuaW5nKDQp LAogICAgICAgICAgICAgICAgICAgICAgICBub3RpY2UoNSksCiAgICAgICAgICAgICAgICAgICAg ICAgIGluZm9ybWF0aW9uYWwoNiksCiAgICAgICAgICAgICAgICAgICAgICAgIGRlYnVnKDcpCiAg ICAgICAgICAgICAgICAgICAgfQoKZW1hbkluc3RhbnREYXRhVGFibGUgT0JKRUNULVRZUEUKICAg IFNZTlRBWCAgICAgICAgICBTRVFVRU5DRSBPRiBFbWFuSW5zdGFudERhdGFFbnRyeQogICAgTUFY LUFDQ0VTUyAgICAgIG5vdC1hY2Nlc3NpYmxlCiAgICBTVEFUVVMgICAgICAgICAgY3VycmVudAog ICAgREVTQ1JJUFRJT04gICAgICJBIHNwYXJzZSB0YWJsZSBvZiBhbiBlbnRpdHkncyBwb3dlciBk YXRhLiIKICAgIDo6PSB7IGVtYW5EYXRhIDEgfQoKZW1hbkluc3RhbnREYXRhRW50cnkgT0JKRUNU LVRZUEUKICAgIFNZTlRBWCAgICAgICAgICBFbWFuSW5zdGFudERhdGFFbnRyeQogICAgTUFYLUFD Q0VTUyAgICAgIG5vdC1hY2Nlc3NpYmxlCiAgICBTVEFUVVMgICAgICAgICAgY3VycmVudAogICAg REVTQ1JJUFRJT04gICAgICJUaGUgcmVhbC10aW1lIHBvd2VyIGRhdGEgZm9yIGFuIGVudGl0eS4i CiAgICBJTkRFWCAgICAgICAgICAgeyBlbWFuRW50aXR5SW5kZXggfQogICAgOjo9IHsgZW1hbklu c3RhbnREYXRhVGFibGUgMSB9CgpFbWFuSW5zdGFudERhdGFFbnRyeSA6Oj0KICAgIFNFUVVFTkNF IHsKICAgICAgICBlbWFuSW5zdGFudEFtcGVyYWdlICAgICAgICAgICAgIFRob3VzYW5kdGhzLAog ICAgICAgIGVtYW5JbnN0YW50Vm9sdGFnZSAgICAgICAgICAgICAgVGhvdXNhbmR0aHMsCiAgICAg ICAgZW1hbkluc3RhbnRQb3dlclVuaXQgICAgICAgICAgICBVbml0TXVsdGlwbGllciwKICAgICAg ICBlbWFuSW5zdGFudEFjdGl2ZVBvd2VyICAgICAgICAgIFRob3VzYW5kdGhzLAogICAgICAgIGVt YW5JbnN0YW50UmVhY3RpdmVQb3dlciAgICAgICAgVGhvdXNhbmR0aHMsCiAgICAgICAgZW1hbklu c3RhbnRBcHBhcmVudFBvd2VyICAgICAgICBUaG91c2FuZHRocywKICAgICAgICBlbWFuSW5zdGFu dFBvd2VyRmFjdG9yICAgICAgICAgIFRob3VzYW5kdGhzLAogICAgICAgIGVtYW5JbnN0YW50RnJl cXVlbmN5ICAgICAgICAgICAgVGhvdXNhbmR0aHMsCiAgICAgICAgZW1hbkluc3RhbnRIYXJtb25p Y0Rpc3RvcnRpb24gICBQZXJjZW50YWdlRGlzdG9ydGlvbiwKICAgICAgICBlbWFuSW5zdGFudFBo YXNlT2Zmc2V0ICAgICAgICAgIFBoYXNlT2Zmc2V0CiAgICB9CgplbWFuSW5zdGFudEFtcGVyYWdl IE9CSkVDVC1UWVBFCiAgICBTWU5UQVggICAgICAgICAgVGhvdXNhbmR0aHMKICAgIE1BWC1BQ0NF U1MgICAgICByZWFkLW9ubHkKICAgIFNUQVRVUyAgICAgICAgICBjdXJyZW50CiAgICBERVNDUklQ VElPTiAgICAgIlRoZSBpbnN0YW50YW5lb3VzIFJNUyBhbXBlcmFnZS4iCiAgICA6Oj0geyBlbWFu SW5zdGFudERhdGFFbnRyeSAxIH0KCmVtYW5JbnN0YW50Vm9sdGFnZSBPQkpFQ1QtVFlQRQogICAg U1lOVEFYICAgICAgICAgIFRob3VzYW5kdGhzCgoKClZlcmdlcyAgICAgICAgICAgICAgICAgICBF eHBpcmVzIEF1Z3VzdCAyNywgMjAxMSAgICAgICAgICAgICAgIFtQYWdlIDIxXQoMCkludGVybmV0 LURyYWZ0ICBkcmFmdC12ZXJnZXMtZW1hbi1zZXBhcmF0ZS1tb2R1bGVzLW1pYi0wMCAgRmVicnVh cnkgMjAxMQoKCiAgICBNQVgtQUNDRVNTICAgICAgcmVhZC1vbmx5CiAgICBTVEFUVVMgICAgICAg ICAgY3VycmVudAogICAgREVTQ1JJUFRJT04gICAgICJUaGUgaW5zdGFudGFuZW91cyBSTVMgdm9s dGFnZS4iCiAgICA6Oj0geyBlbWFuSW5zdGFudERhdGFFbnRyeSAyIH0KCmVtYW5JbnN0YW50UG93 ZXJVbml0IE9CSkVDVC1UWVBFCiAgICBTWU5UQVggICAgICAgICAgVW5pdE11bHRpcGxpZXIKICAg IE1BWC1BQ0NFU1MgICAgICByZWFkLW9ubHkKICAgIFNUQVRVUyAgICAgICAgICBjdXJyZW50CiAg ICBERVNDUklQVElPTiAgICAgIlRoZSB1bml0IHNjYWxlIHVzZWQgZm9yIGVtYW5JbnN0YW50QWN0 aXZlUG93ZXIsCiAgICAgICAgICAgICAgICAgICAgZW1hbkluc3RhbnRSZWFjdGl2ZVBvd2VyLCBh bmQKICAgICAgICAgICAgICAgICAgICBlbWFuSW5zdGFudEFwcGFyZW50UG93ZXIuIgogICAgOjo9 IHsgZW1hbkluc3RhbnREYXRhRW50cnkgMyB9CgplbWFuSW5zdGFudEFjdGl2ZVBvd2VyIE9CSkVD VC1UWVBFCiAgICBTWU5UQVggICAgICAgICAgVGhvdXNhbmR0aHMKICAgIE1BWC1BQ0NFU1MgICAg ICByZWFkLW9ubHkKICAgIFNUQVRVUyAgICAgICAgICBjdXJyZW50CiAgICBERVNDUklQVElPTiAg ICAgIlRoZSBpbnN0YW50YW5lb3VzIHdhdHRhZ2UuIgogICAgOjo9IHsgZW1hbkluc3RhbnREYXRh RW50cnkgNCB9CgplbWFuSW5zdGFudFJlYWN0aXZlUG93ZXIgT0JKRUNULVRZUEUKICAgIFNZTlRB WCAgICAgICAgICBUaG91c2FuZHRocwogICAgTUFYLUFDQ0VTUyAgICAgIHJlYWQtb25seQogICAg U1RBVFVTICAgICAgICAgIGN1cnJlbnQKICAgIERFU0NSSVBUSU9OICAgICAiVGhlIGluc3RhbnRh bmVvdXMgdm9sdC1hbXBzIChyZWFjdGl2ZSkuIgogICAgOjo9IHsgZW1hbkluc3RhbnREYXRhRW50 cnkgNSB9CgplbWFuSW5zdGFudEFwcGFyZW50UG93ZXIgT0JKRUNULVRZUEUKICAgIFNZTlRBWCAg ICAgICAgICBUaG91c2FuZHRocwogICAgTUFYLUFDQ0VTUyAgICAgIHJlYWQtb25seQogICAgU1RB VFVTICAgICAgICAgIGN1cnJlbnQKICAgIERFU0NSSVBUSU9OICAgICAiVGhlIGluc3RhbnRhbmVv dXMgdm9sdC1hbXBzLiIKICAgIDo6PSB7IGVtYW5JbnN0YW50RGF0YUVudHJ5IDYgfQoKZW1hbklu c3RhbnRQb3dlckZhY3RvciBPQkpFQ1QtVFlQRQogICAgU1lOVEFYICAgICAgICAgIFRob3VzYW5k dGhzCiAgICBNQVgtQUNDRVNTICAgICAgcmVhZC1vbmx5CiAgICBTVEFUVVMgICAgICAgICAgY3Vy cmVudAogICAgREVTQ1JJUFRJT04gICAgICJUaGUgaW5zdGFudGFuZW91cyBwb3dlciBmYWN0b3Iu IgogICAgOjo9IHsgZW1hbkluc3RhbnREYXRhRW50cnkgNyB9CgplbWFuSW5zdGFudEZyZXF1ZW5j eSBPQkpFQ1QtVFlQRQogICAgU1lOVEFYICAgICAgICAgIFRob3VzYW5kdGhzCiAgICBNQVgtQUND RVNTICAgICAgcmVhZC1vbmx5CiAgICBTVEFUVVMgICAgICAgICAgY3VycmVudAogICAgREVTQ1JJ UFRJT04gICAgICJUaGUgaW5zdGFudGFuZW91cyBmcmVxdWVuY3kuIgogICAgOjo9IHsgZW1hbklu c3RhbnREYXRhRW50cnkgOCB9CgoKClZlcmdlcyAgICAgICAgICAgICAgICAgICBFeHBpcmVzIEF1 Z3VzdCAyNywgMjAxMSAgICAgICAgICAgICAgIFtQYWdlIDIyXQoMCkludGVybmV0LURyYWZ0ICBk cmFmdC12ZXJnZXMtZW1hbi1zZXBhcmF0ZS1tb2R1bGVzLW1pYi0wMCAgRmVicnVhcnkgMjAxMQoK CmVtYW5JbnN0YW50SGFybW9uaWNEaXN0b3J0aW9uIE9CSkVDVC1UWVBFCiAgICBTWU5UQVggICAg ICAgICAgUGVyY2VudGFnZURpc3RvcnRpb24KICAgIE1BWC1BQ0NFU1MgICAgICByZWFkLW9ubHkK ICAgIFNUQVRVUyAgICAgICAgICBjdXJyZW50CiAgICBERVNDUklQVElPTiAgICAgIlRoZSBpbnN0 YW50YW5lb3VzIGhhcm1vbmljIGRpc3RvcnRpb24uIgogICAgOjo9IHsgZW1hbkluc3RhbnREYXRh RW50cnkgOSB9CgplbWFuSW5zdGFudFBoYXNlT2Zmc2V0IE9CSkVDVC1UWVBFCiAgICBTWU5UQVgg ICAgICAgICAgUGhhc2VPZmZzZXQKICAgIE1BWC1BQ0NFU1MgICAgICByZWFkLW9ubHkKICAgIFNU QVRVUyAgICAgICAgICBjdXJyZW50CiAgICBERVNDUklQVElPTiAgICAgIlRoZSBpbnN0YW50YW5l b3VzIHBoYXNlIG9mZnNldC4iCiAgICA6Oj0geyBlbWFuSW5zdGFudERhdGFFbnRyeSAxMCB9Cgpl bWFuRGF0YVByb3BlcnR5VGFibGUgT0JKRUNULVRZUEUKICAgIFNZTlRBWCAgICAgICAgICBTRVFV RU5DRSBPRiBFbWFuRGF0YVByb3BlcnR5RW50cnkKICAgIE1BWC1BQ0NFU1MgICAgICBub3QtYWNj ZXNzaWJsZQogICAgU1RBVFVTICAgICAgICAgIGN1cnJlbnQKICAgIERFU0NSSVBUSU9OICAgICAi QSBzcGFyc2UgdGFibGUgb2YgYW4gZW50aXR5J3MgZGF0YSBhdHRyaWJ1dGVzLiIKICAgIDo6PSB7 IGVtYW5EYXRhIDIgfQoKZW1hbkRhdGFQcm9wZXJ0eUVudHJ5IE9CSkVDVC1UWVBFCiAgICBTWU5U QVggICAgICAgICAgRW1hbkRhdGFQcm9wZXJ0eUVudHJ5CiAgICBNQVgtQUNDRVNTICAgICAgbm90 LWFjY2Vzc2libGUKICAgIFNUQVRVUyAgICAgICAgICBjdXJyZW50CiAgICBERVNDUklQVElPTiAg ICAgIlRoZSBwb3dlciBkYXRhIGF0dHJpYnV0ZXMgZm9yIGFuIGVudGl0eS4iCiAgICBJTkRFWCAg ICAgICAgICAgeyBlbWFuRW50aXR5SW5kZXggfQogICAgOjo9IHsgZW1hbkRhdGFQcm9wZXJ0eVRh YmxlIDEgfQoKRW1hbkRhdGFQcm9wZXJ0eUVudHJ5IDo6PQogICAgU0VRVUVOQ0UgewogICAgICAg IGVtYW5EYXRhQWNjdXJhY3kgICAgICAgICAgICAgICAgRGF0YUFjY3VyYWN5LAogICAgICAgIGVt YW5EYXRhQ2FsaWJlciAgICAgICAgICAgICAgICAgRGF0YUNhbGliZXIsCiAgICAgICAgZW1hbk5h bWVwbGF0ZVBvd2VyVW5pdCAgICAgICAgICBVbml0TXVsdGlwbGllciwKICAgICAgICBlbWFuTmFt ZXBsYXRlTWF4UG93ZXIgICAgICAgICAgIFRob3VzYW5kdGhzLAogICAgICAgIGVtYW5OYW1lcGxh dGVNYXhDdXJyZW50ICAgICAgICAgVGhvdXNhbmR0aHMsCiAgICAgICAgZW1hbk5hbWVwbGF0ZU1h eFZvbHRhZ2UgICAgICAgICBUaG91c2FuZHRocywKICAgICAgICBlbWFuTmFtZXBsYXRlTWluUG93 ZXIgICAgICAgICAgIFRob3VzYW5kdGhzLAogICAgICAgIGVtYW5OYW1lcGxhdGVNaW5DdXJyZW50 ICAgICAgICAgVGhvdXNhbmR0aHMsCiAgICAgICAgZW1hbk5hbWVwbGF0ZU1pblZvbHRhZ2UgICAg ICAgICBUaG91c2FuZHRocywKICAgICAgICBlbWFuUG93ZXJUeXBlICAgICAgICAgICAgICAgICAg IFBvd2VyVHlwZQogICAgfQoKZW1hbkRhdGFBY2N1cmFjeSBPQkpFQ1QtVFlQRQogICAgU1lOVEFY ICAgICAgICAgIERhdGFBY2N1cmFjeQogICAgTUFYLUFDQ0VTUyAgICAgIHJlYWQtb25seQogICAg U1RBVFVTICAgICAgICAgIGN1cnJlbnQKICAgIERFU0NSSVBUSU9OICAgICAiVGhlIGFjY3VyYWN5 IG9mIHRoZSBwb3dlciBkYXRhIHJlcG9ydGVkLiIKCgoKVmVyZ2VzICAgICAgICAgICAgICAgICAg IEV4cGlyZXMgQXVndXN0IDI3LCAyMDExICAgICAgICAgICAgICAgW1BhZ2UgMjNdCgwKSW50ZXJu ZXQtRHJhZnQgIGRyYWZ0LXZlcmdlcy1lbWFuLXNlcGFyYXRlLW1vZHVsZXMtbWliLTAwICBGZWJy dWFyeSAyMDExCgoKICAgIDo6PSB7IGVtYW5EYXRhUHJvcGVydHlFbnRyeSAxIH0KCmVtYW5EYXRh Q2FsaWJlciBPQkpFQ1QtVFlQRQogICAgU1lOVEFYICAgICAgICAgIERhdGFDYWxpYmVyCiAgICBN QVgtQUNDRVNTICAgICAgcmVhZC1vbmx5CiAgICBTVEFUVVMgICAgICAgICAgY3VycmVudAogICAg REVTQ1JJUFRJT04gICAgICJUaGUgY2FsaWJlciBvZiB0aGUgcG93ZXIgZGF0YSByZXBvcnRlZC4i CiAgICA6Oj0geyBlbWFuRGF0YVByb3BlcnR5RW50cnkgMiB9CgplbWFuTmFtZXBsYXRlUG93ZXJV bml0IE9CSkVDVC1UWVBFCiAgICBTWU5UQVggICAgICAgICAgVW5pdE11bHRpcGxpZXIKICAgIE1B WC1BQ0NFU1MgICAgICByZWFkLW9ubHkKICAgIFNUQVRVUyAgICAgICAgICBjdXJyZW50CiAgICBE RVNDUklQVElPTiAgICAgIlRoZSB1bml0IHNjYWxlIHVzZWQgZm9yCiAgICAgICAgICAgICAgICAg ICAgZW1hbk5hbWVwbGF0ZVtNYXh8TWluXVBvd2VyLiIKICAgIDo6PSB7IGVtYW5EYXRhUHJvcGVy dHlFbnRyeSAzIH0KCmVtYW5OYW1lcGxhdGVNYXhQb3dlciBPQkpFQ1QtVFlQRQogICAgU1lOVEFY ICAgICAgICAgIFRob3VzYW5kdGhzCiAgICBNQVgtQUNDRVNTICAgICAgcmVhZC1vbmx5CiAgICBT VEFUVVMgICAgICAgICAgY3VycmVudAogICAgREVTQ1JJUFRJT04gICAgICJUaGUgbWF4aW11bSBu YW1lcGxhdGUgcG93ZXIgcmF0aW5nLiIKICAgIDo6PSB7IGVtYW5EYXRhUHJvcGVydHlFbnRyeSA0 IH0KCmVtYW5OYW1lcGxhdGVNYXhDdXJyZW50IE9CSkVDVC1UWVBFCiAgICBTWU5UQVggICAgICAg ICAgVGhvdXNhbmR0aHMKICAgIE1BWC1BQ0NFU1MgICAgICByZWFkLW9ubHkKICAgIFNUQVRVUyAg ICAgICAgICBjdXJyZW50CiAgICBERVNDUklQVElPTiAgICAgIlRoZSBtYXhpbXVtIG5hbWVwbGF0 ZSBjdXJyZW50IHJhdGluZy4iCiAgICA6Oj0geyBlbWFuRGF0YVByb3BlcnR5RW50cnkgNSB9Cgpl bWFuTmFtZXBsYXRlTWF4Vm9sdGFnZSBPQkpFQ1QtVFlQRQogICAgU1lOVEFYICAgICAgICAgIFRo b3VzYW5kdGhzCiAgICBNQVgtQUNDRVNTICAgICAgcmVhZC1vbmx5CiAgICBTVEFUVVMgICAgICAg ICAgY3VycmVudAogICAgREVTQ1JJUFRJT04gICAgICJUaGUgbWF4aW11bSBuYW1lcGxhdGUgdm9s dGFnZSByYXRpbmcuIgogICAgOjo9IHsgZW1hbkRhdGFQcm9wZXJ0eUVudHJ5IDYgfQoKZW1hbk5h bWVwbGF0ZU1pblBvd2VyIE9CSkVDVC1UWVBFCiAgICBTWU5UQVggICAgICAgICAgVGhvdXNhbmR0 aHMKICAgIE1BWC1BQ0NFU1MgICAgICByZWFkLW9ubHkKICAgIFNUQVRVUyAgICAgICAgICBjdXJy ZW50CiAgICBERVNDUklQVElPTiAgICAgIlRoZSBtaW5pbXVtIG5hbWVwbGF0ZSBwb3dlciByYXRp bmcuIgogICAgOjo9IHsgZW1hbkRhdGFQcm9wZXJ0eUVudHJ5IDcgfQoKZW1hbk5hbWVwbGF0ZU1p bkN1cnJlbnQgT0JKRUNULVRZUEUKICAgIFNZTlRBWCAgICAgICAgICBUaG91c2FuZHRocwogICAg TUFYLUFDQ0VTUyAgICAgIHJlYWQtb25seQoKCgpWZXJnZXMgICAgICAgICAgICAgICAgICAgRXhw aXJlcyBBdWd1c3QgMjcsIDIwMTEgICAgICAgICAgICAgICBbUGFnZSAyNF0KDApJbnRlcm5ldC1E cmFmdCAgZHJhZnQtdmVyZ2VzLWVtYW4tc2VwYXJhdGUtbW9kdWxlcy1taWItMDAgIEZlYnJ1YXJ5 IDIwMTEKCgogICAgU1RBVFVTICAgICAgICAgIGN1cnJlbnQKICAgIERFU0NSSVBUSU9OICAgICAi VGhlIG1pbmltdW0gbmFtZXBsYXRlIGN1cnJlbnQgcmF0aW5nLiIKICAgIDo6PSB7IGVtYW5EYXRh UHJvcGVydHlFbnRyeSA4IH0KCmVtYW5OYW1lcGxhdGVNaW5Wb2x0YWdlIE9CSkVDVC1UWVBFCiAg ICBTWU5UQVggICAgICAgICAgVGhvdXNhbmR0aHMKICAgIE1BWC1BQ0NFU1MgICAgICByZWFkLW9u bHkKICAgIFNUQVRVUyAgICAgICAgICBjdXJyZW50CiAgICBERVNDUklQVElPTiAgICAgIlRoZSBt aW5pbXVtIG5hbWVwbGF0ZSB2b2x0YWdlIHJhdGluZy4iCiAgICA6Oj0geyBlbWFuRGF0YVByb3Bl cnR5RW50cnkgOSB9CgplbWFuUG93ZXJUeXBlIE9CSkVDVC1UWVBFCiAgICBTWU5UQVggICAgICAg ICAgUG93ZXJUeXBlCiAgICBNQVgtQUNDRVNTICAgICAgcmVhZC1vbmx5CiAgICBTVEFUVVMgICAg ICAgICAgY3VycmVudAogICAgREVTQ1JJUFRJT04gICAgICJUaGUgcG93ZXIgdHlwZSBmb3IgdGhl IGVudGl0eS4iCiAgICA6Oj0geyBlbWFuRGF0YVByb3BlcnR5RW50cnkgMTAgfQoKZW1hbkRhdGFB bGVydFRhYmxlIE9CSkVDVC1UWVBFCiAgICBTWU5UQVggICAgICAgICAgU0VRVUVOQ0UgT0YgRW1h bkRhdGFBbGVydEVudHJ5CiAgICBNQVgtQUNDRVNTICAgICAgbm90LWFjY2Vzc2libGUKICAgIFNU QVRVUyAgICAgICAgICBjdXJyZW50CiAgICBERVNDUklQVElPTiAgICAgIkEgc3BhcnNlIHRhYmxl IG9mIGFuIGVudGl0eSdzIGRhdGEgYWxlcnRzLiIKICAgIDo6PSB7IGVtYW5EYXRhIDMgfQoKZW1h bkRhdGFBbGVydEVudHJ5IE9CSkVDVC1UWVBFCiAgICBTWU5UQVggICAgICAgICAgRW1hbkRhdGFB bGVydEVudHJ5CiAgICBNQVgtQUNDRVNTICAgICAgbm90LWFjY2Vzc2libGUKICAgIFNUQVRVUyAg ICAgICAgICBjdXJyZW50CiAgICBERVNDUklQVElPTiAgICAgIlRoZSBwb3dlciBkYXRhIGFsZXJ0 IGZvciBhbiBlbnRpdHkuIgogICAgSU5ERVggICAgICAgICAgIHsgZW1hbkVudGl0eUluZGV4LCBl bWFuRGF0YUFsZXJ0SW5kZXggfQogICAgOjo9IHsgZW1hbkRhdGFBbGVydFRhYmxlIDEgfQoKRW1h bkRhdGFBbGVydEVudHJ5IDo6PQogICAgU0VRVUVOQ0UgewogICAgICAgIGVtYW5EYXRhQWxlcnRJ bmRleCAgICAgICAgICAgICAgVW5zaWduZWQzMiwKICAgICAgICBlbWFuRGF0YUFsZXJ0TmFtZSAg ICAgICAgICAgICAgIFNubXBBZG1pblN0cmluZywKICAgICAgICBlbWFuRGF0YUFsZXJ0RW5hYmxl ZCAgICAgICAgICAgIFRydXRoVmFsdWUsCiAgICAgICAgZW1hbkRhdGFBbGVydENvbXBhcmVPbiAg ICAgICAgICBFbWFuRGF0YVR5cGUsCiAgICAgICAgZW1hbkRhdGFBbGVydENvbXBhcmlzb24gICAg ICAgICBDb21wYXJpc29uT3BlcmF0b3IsCiAgICAgICAgZW1hbkRhdGFBbGVydFZhbHVlICAgICAg ICAgICAgICBUaG91c2FuZHRocywKICAgICAgICBlbWFuRGF0YUFsZXJ0VW5pdCAgICAgICAgICAg ICAgIFVuaXRNdWx0aXBsaWVyLAogICAgICAgIGVtYW5EYXRhQWxlcnREZWxheSAgICAgICAgICAg ICAgVGltZUludGVydmFsLAogICAgICAgIGVtYW5EYXRhQWxlcnRTZXZlcml0eSAgICAgICAgICAg QWxlcnRTZXZlcml0eSwKICAgICAgICBlbWFuRGF0YUFsZXJ0Um93U3RhdHVzICAgICAgICAgIFJv d1N0YXR1cwogICAgfQoKZW1hbkRhdGFBbGVydEluZGV4IE9CSkVDVC1UWVBFCgoKClZlcmdlcyAg ICAgICAgICAgICAgICAgICBFeHBpcmVzIEF1Z3VzdCAyNywgMjAxMSAgICAgICAgICAgICAgIFtQ YWdlIDI1XQoMCkludGVybmV0LURyYWZ0ICBkcmFmdC12ZXJnZXMtZW1hbi1zZXBhcmF0ZS1tb2R1 bGVzLW1pYi0wMCAgRmVicnVhcnkgMjAxMQoKCiAgICBTWU5UQVggICAgICAgICAgVW5zaWduZWQz MgogICAgTUFYLUFDQ0VTUyAgICAgIG5vdC1hY2Nlc3NpYmxlCiAgICBTVEFUVVMgICAgICAgICAg Y3VycmVudAogICAgREVTQ1JJUFRJT04gICAgICJUaGUgbmFtZSBvZiB0aGUgYWxlcnQgY29uZGl0 aW9uLiIKICAgIDo6PSB7IGVtYW5EYXRhQWxlcnRFbnRyeSAxIH0KCmVtYW5EYXRhQWxlcnROYW1l IE9CSkVDVC1UWVBFCiAgICBTWU5UQVggICAgICAgICAgU25tcEFkbWluU3RyaW5nCiAgICBNQVgt QUNDRVNTICAgICAgcmVhZC1jcmVhdGUKICAgIFNUQVRVUyAgICAgICAgICBjdXJyZW50CiAgICBE RVNDUklQVElPTiAgICAgIlRoZSBuYW1lIG9mIHRoZSBhbGVydCBjb25kaXRpb24uIgogICAgOjo9 IHsgZW1hbkRhdGFBbGVydEVudHJ5IDIgfQoKZW1hbkRhdGFBbGVydEVuYWJsZWQgT0JKRUNULVRZ UEUKICAgIFNZTlRBWCAgICAgICAgICBUcnV0aFZhbHVlCiAgICBNQVgtQUNDRVNTICAgICAgcmVh ZC1jcmVhdGUKICAgIFNUQVRVUyAgICAgICAgICBjdXJyZW50CiAgICBERVNDUklQVElPTiAgICAg IlRoZSBmbGFnIHRvIGluZGljYXRlIHdoZXRoZXIgdGhlIGFsZXJ0IGlzIGVuYWJsZWQuIgogICAg Ojo9IHsgZW1hbkRhdGFBbGVydEVudHJ5IDMgfQoKZW1hbkRhdGFBbGVydENvbXBhcmVPbiBPQkpF Q1QtVFlQRQogICAgU1lOVEFYICAgICAgICAgIEVtYW5EYXRhVHlwZQogICAgTUFYLUFDQ0VTUyAg ICAgIHJlYWQtY3JlYXRlCiAgICBTVEFUVVMgICAgICAgICAgY3VycmVudAogICAgREVTQ1JJUFRJ T04gICAgICJUaGUgZGF0YSB0eXBlIHRvIGNvbXBhcmUgYWdhaW5zdCBmb3IgdGhlIGFsZXJ0LiIK ICAgIDo6PSB7IGVtYW5EYXRhQWxlcnRFbnRyeSA0IH0KCmVtYW5EYXRhQWxlcnRDb21wYXJpc29u IE9CSkVDVC1UWVBFCiAgICBTWU5UQVggICAgICAgICAgQ29tcGFyaXNvbk9wZXJhdG9yCiAgICBN QVgtQUNDRVNTICAgICAgcmVhZC1jcmVhdGUKICAgIFNUQVRVUyAgICAgICAgICBjdXJyZW50CiAg ICBERVNDUklQVElPTiAgICAgIlRoZSBjb21wYXJpc29uIG9wZXJhdGlvbiB0byBwZXJmb3JtIGZv ciB0aGUgYWxlcnQuIgogICAgOjo9IHsgZW1hbkRhdGFBbGVydEVudHJ5IDUgfQoKZW1hbkRhdGFB bGVydFZhbHVlIE9CSkVDVC1UWVBFCiAgICBTWU5UQVggICAgICAgICAgVGhvdXNhbmR0aHMKICAg IE1BWC1BQ0NFU1MgICAgICByZWFkLWNyZWF0ZQogICAgU1RBVFVTICAgICAgICAgIGN1cnJlbnQK ICAgIERFU0NSSVBUSU9OICAgICAiVGhlIHZhbHVlIHRvIGNvbXBhcmUgYWdhaW5zdCBmb3IgdGhl IGFsZXJ0LiIKICAgIDo6PSB7IGVtYW5EYXRhQWxlcnRFbnRyeSA2IH0KCmVtYW5EYXRhQWxlcnRV bml0IE9CSkVDVC1UWVBFCiAgICBTWU5UQVggICAgICAgICAgVW5pdE11bHRpcGxpZXIKICAgIE1B WC1BQ0NFU1MgICAgICByZWFkLW9ubHkKICAgIFNUQVRVUyAgICAgICAgICBjdXJyZW50CiAgICBE RVNDUklQVElPTiAgICAgIlRoZSB1bml0IHNjYWxlIHVzZWQgZm9yIGVtYW5EYXRhQWxlcnRWYWx1 ZS4iCiAgICA6Oj0geyBlbWFuRGF0YUFsZXJ0RW50cnkgNyB9CgoKCgpWZXJnZXMgICAgICAgICAg ICAgICAgICAgRXhwaXJlcyBBdWd1c3QgMjcsIDIwMTEgICAgICAgICAgICAgICBbUGFnZSAyNl0K DApJbnRlcm5ldC1EcmFmdCAgZHJhZnQtdmVyZ2VzLWVtYW4tc2VwYXJhdGUtbW9kdWxlcy1taWIt MDAgIEZlYnJ1YXJ5IDIwMTEKCgplbWFuRGF0YUFsZXJ0RGVsYXkgT0JKRUNULVRZUEUKICAgIFNZ TlRBWCAgICAgICAgICBUaW1lSW50ZXJ2YWwKICAgIE1BWC1BQ0NFU1MgICAgICByZWFkLWNyZWF0 ZQogICAgU1RBVFVTICAgICAgICAgIGN1cnJlbnQKICAgIERFU0NSSVBUSU9OICAgICAiVGhlIHRp bWUgZGVsYXkgdG8gd2FpdCBhZnRlciB0aGUgYWxlcnQgY29uZGl0aW9uIGlzCiAgICAgICAgICAg ICAgICAgICAgdHJpZ2dlcmVkIGJ1dCBiZWZvcmUgdHJpZ2dlcmluZyB0aGUgYWxlcnQuIgogICAg Ojo9IHsgZW1hbkRhdGFBbGVydEVudHJ5IDggfQoKZW1hbkRhdGFBbGVydFNldmVyaXR5IE9CSkVD VC1UWVBFCiAgICBTWU5UQVggICAgICAgICAgQWxlcnRTZXZlcml0eQogICAgTUFYLUFDQ0VTUyAg ICAgIHJlYWQtb25seQogICAgU1RBVFVTICAgICAgICAgIGN1cnJlbnQKICAgIERFU0NSSVBUSU9O ICAgICAiVGhlIHNldmVyaXR5IG9mIHRoZSBhbGVydCB3aGVuIHRyaWdnZXJlZC4iCiAgICA6Oj0g eyBlbWFuRGF0YUFsZXJ0RW50cnkgOSB9CgplbWFuRGF0YUFsZXJ0Um93U3RhdHVzIE9CSkVDVC1U WVBFCiAgICBTWU5UQVggICAgICAgICAgUm93U3RhdHVzCiAgICBNQVgtQUNDRVNTICAgICAgcmVh ZC1jcmVhdGUKICAgIFNUQVRVUyAgICAgICAgICBjdXJyZW50CiAgICBERVNDUklQVElPTiAgICAg IlRoZSBtZWNoYW5pc20gdG8gbWFuYWdlIGR5bmFtaWMgYWxlcnQgZW50cmllcy4iCiAgICA6Oj0g eyBlbWFuRGF0YUFsZXJ0RW50cnkgMTAgfQoKZW1hbkRhdGFUcmFwVmFyaWFibGVzIE9CSkVDVCBJ REVOVElGSUVSCiAgICA6Oj0geyBlbWFuRGF0YSA0IH0KCmVtYW5EYXRhQWxlcnRUcmlnZ2VyZWRW YWx1ZSBPQkpFQ1QtVFlQRQogICAgU1lOVEFYICAgICAgICAgIFRob3VzYW5kdGhzCiAgICBNQVgt QUNDRVNTICAgICAgcmVhZC1vbmx5CiAgICBTVEFUVVMgICAgICAgICAgY3VycmVudAogICAgREVT Q1JJUFRJT04gICAgICJUaGUgYWN0dWFsIHZhbHVlIHdoZW4gdGhlIGFsZXJ0IGNvbmRpdGlvbgog ICAgICAgICAgICAgICAgICAgIHRyaWdnZXJlZC4iCiAgICA6Oj0geyBlbWFuRGF0YVRyYXBWYXJp YWJsZXMgMSB9CgplbWFuRGF0YVRyYXBzIE9CSkVDVCBJREVOVElGSUVSCiAgICA6Oj0geyBlbWFu RGF0YSA1IH0KCmVtYW5EYXRhVHJhcHNSZXZlcnNpYmxlIE9CSkVDVCBJREVOVElGSUVSCiAgICA6 Oj0geyBlbWFuRGF0YVRyYXBzIDAgfQoKZW1hbkRhdGFBbGVydE5vdGlmaWNhdGlvbiBOT1RJRklD QVRJT04tVFlQRQogICAgT0JKRUNUUyAgICAgICAgIHsKICAgICAgICAgICAgICAgICAgICAgICAg ZW1hbkRhdGFBbGVydE5hbWUsCiAgICAgICAgICAgICAgICAgICAgICAgIGVtYW5EYXRhQWxlcnRT ZXZlcml0eSwKICAgICAgICAgICAgICAgICAgICAgICAgZW1hbkRhdGFBbGVydFZhbHVlLAogICAg ICAgICAgICAgICAgICAgICAgICBlbWFuRGF0YUFsZXJ0VW5pdCwKICAgICAgICAgICAgICAgICAg ICAgICAgZW1hbkRhdGFBbGVydFRyaWdnZXJlZFZhbHVlCiAgICAgICAgICAgICAgICAgICAgfQog ICAgU1RBVFVTICAgICAgICAgIGN1cnJlbnQKCgoKVmVyZ2VzICAgICAgICAgICAgICAgICAgIEV4 cGlyZXMgQXVndXN0IDI3LCAyMDExICAgICAgICAgICAgICAgW1BhZ2UgMjddCgwKSW50ZXJuZXQt RHJhZnQgIGRyYWZ0LXZlcmdlcy1lbWFuLXNlcGFyYXRlLW1vZHVsZXMtbWliLTAwICBGZWJydWFy eSAyMDExCgoKICAgIERFU0NSSVBUSU9OICAgICAiU2VudCB0byBub3RpZnkgYSB0aGlyZC1wYXJ0 eSBhYm91dCBhbiBhbGVydAogICAgICAgICAgICAgICAgICAgIGNvbmRpdGlvbiB0cmlnZ2VyaW5n LiIKICAgIDo6PSB7IGVtYW5EYXRhVHJhcHNSZXZlcnNpYmxlIDEgfQoKLS0KLS0gRU1BTiBDb250 cm9sIEFkZC1PbgotLQoKZW1hbkNvbnRyb2wgT0JKRUNUIElERU5USUZJRVIKICAgIDo6PSB7IGVt YW4gNSB9CgpBY3BpU3RhdGUgOjo9IFRFWFRVQUwtQ09OVkVOVElPTgogICAgU1RBVFVTICAgICAg ICAgIGN1cnJlbnQKICAgIERFU0NSSVBUSU9OICAgICAiU3BlY2lmaWVzIHRoZSBzdGF0ZXMgc3Bl Y2lmaWVkIGJ5IHRoZSBBQ1BJCiAgICAgICAgICAgICAgICAgICAgc3RhbmRhcmQuIgogICAgU1lO VEFYICAgICAgICAgIElOVEVHRVIgewogICAgICAgICAgICAgICAgICAgICAgICBnMHMwKDApLAog ICAgICAgICAgICAgICAgICAgICAgICBnMXMxKDEpLAogICAgICAgICAgICAgICAgICAgICAgICBn MXMyKDIpLAogICAgICAgICAgICAgICAgICAgICAgICBnMXMzKDMpLAogICAgICAgICAgICAgICAg ICAgICAgICBnMXM0KDQpLAogICAgICAgICAgICAgICAgICAgICAgICBnMnM1KDUpLAogICAgICAg ICAgICAgICAgICAgICAgICBnMyg2KQogICAgICAgICAgICAgICAgICAgIH0KCkRtdGZQb3dlclN0 YXRlIDo6PSBURVhUVUFMLUNPTlZFTlRJT04KICAgIFNUQVRVUyAgICAgICAgICBjdXJyZW50CiAg ICBERVNDUklQVElPTiAgICAgIlNwZWNpZmllcyB0aGUgc3RhdGVzIHNwZWNpZmllZCBieSB0aGUg RE1URgogICAgICAgICAgICAgICAgICAgIERTUDEwMjcgc3RhbmRhcmQuICBUaGUgc3RhdGUgcG93 ZXJjeWNsZWhhcmQoOSkKICAgICAgICAgICAgICAgICAgICBpcyBhIHRyYW5zaXRpb24gc3RhdGUg Zm9yIG9mZmhhcmQoNikgZm9sbG93ZWQgYnkKICAgICAgICAgICAgICAgICAgICBvbigyKSwgc28g aXMgYSB3cml0ZS1vbmx5IG9wZXJhdGlvbiB0byBzaW1wbGlmeSB0aGUKICAgICAgICAgICAgICAg ICAgICBTTk1QIGNsaWVudCBpbnRlcmFjdGlvbiB3aXRoIGFuIGFnZW50LiIKICAgIFNZTlRBWCAg ICAgICAgICBJTlRFR0VSIHsKICAgICAgICAgICAgICAgICAgICAgICAgb24oMiksCiAgICAgICAg ICAgICAgICAgICAgICAgIHNsZWVwbGlnaHQoMyksCiAgICAgICAgICAgICAgICAgICAgICAgIHNs ZWVwZGVlcCg0KSwKICAgICAgICAgICAgICAgICAgICAgICAgcG93ZXJjeWNsZXNvZnQoNSksCiAg ICAgICAgICAgICAgICAgICAgICAgIG9mZmhhcmQoNiksCiAgICAgICAgICAgICAgICAgICAgICAg IGhpYmVybmF0ZSg3KSwKICAgICAgICAgICAgICAgICAgICAgICAgb2Zmc29mdCg4KSwKICAgICAg ICAgICAgICAgICAgICAgICAgcG93ZXJjeWNsZWhhcmQoOSksCiAgICAgICAgICAgICAgICAgICAg ICAgIG1hc3RlcmJ1c3Jlc2V0KDEwKSwKICAgICAgICAgICAgICAgICAgICAgICAgZGlhZ2ludGVy cnVwdCgxMSksCiAgICAgICAgICAgICAgICAgICAgICAgIG9mZnNvZnRncmFjZWZ1bCgxMiksCiAg ICAgICAgICAgICAgICAgICAgICAgIG9mZmhhcmRncmFjZWZ1bCgxMyksCiAgICAgICAgICAgICAg ICAgICAgICAgIG1hc3RlcmJ1c3Jlc2V0Z3JhY2VmdWwoMTQpLAogICAgICAgICAgICAgICAgICAg ICAgICBwb3dlcmN5Y2xlb2Zmc29mdGdyYWNlZnVsKDE1KSwKICAgICAgICAgICAgICAgICAgICAg ICAgcG93ZXJjeWNsZW9mZmhhcmRncmFjZWZ1bCgxNikKCgoKVmVyZ2VzICAgICAgICAgICAgICAg ICAgIEV4cGlyZXMgQXVndXN0IDI3LCAyMDExICAgICAgICAgICAgICAgW1BhZ2UgMjhdCgwKSW50 ZXJuZXQtRHJhZnQgIGRyYWZ0LXZlcmdlcy1lbWFuLXNlcGFyYXRlLW1vZHVsZXMtbWliLTAwICBG ZWJydWFyeSAyMDExCgoKICAgICAgICAgICAgICAgICAgICB9CgpQZXJjZW50YWdlIDo6PSBURVhU VUFMLUNPTlZFTlRJT04KICAgIERJU1BMQVktSElOVCAgICAiZCIKICAgIFNUQVRVUyAgICAgICAg ICBjdXJyZW50CiAgICBERVNDUklQVElPTiAgICAgIlNwZWNpZmllcyBhIHBlcmNlbnRhZ2UgdmFs dWUuIgogICAgU1lOVEFYICAgICAgICAgIFVuc2lnbmVkMzIgKDAuLjEwMCkKCmVtYW5Db250cm9s VGFibGUgT0JKRUNULVRZUEUKICAgIFNZTlRBWCAgICAgICAgICBTRVFVRU5DRSBPRiBFbWFuQ29u dHJvbEVudHJ5CiAgICBNQVgtQUNDRVNTICAgICAgbm90LWFjY2Vzc2libGUKICAgIFNUQVRVUyAg ICAgICAgICBjdXJyZW50CiAgICBERVNDUklQVElPTiAgICAgIkEgc3BhcnNlIHRhYmxlIG9mIGFs bCB0aGUgZW50aXR5J3MgY29udHJvbAogICAgICAgICAgICAgICAgICAgIG1lY2hhbmlzbXMuIgog ICAgOjo9IHsgZW1hbkNvbnRyb2wgMSB9CgplbWFuQ29udHJvbEVudHJ5IE9CSkVDVC1UWVBFCiAg ICBTWU5UQVggICAgICAgICAgRW1hbkNvbnRyb2xFbnRyeQogICAgTUFYLUFDQ0VTUyAgICAgIG5v dC1hY2Nlc3NpYmxlCiAgICBTVEFUVVMgICAgICAgICAgY3VycmVudAogICAgREVTQ1JJUFRJT04g ICAgICJUaGUgY29udHJvbCBtZWNoYW5pc21zIGZvciBhbiBlbnRpdHkuIgogICAgSU5ERVggICAg ICAgICAgIHsgZW1hbkVudGl0eUluZGV4IH0KICAgIDo6PSB7IGVtYW5Db250cm9sVGFibGUgMSB9 CgpFbWFuQ29udHJvbEVudHJ5IDo6PQogICAgU0VRVUVOQ0UgewogICAgICAgIGVtYW5BY3BpQ29u dHJvbCAgICAgICAgICAgICAgICAgQWNwaVN0YXRlLAogICAgICAgIGVtYW5QZXJjZW50YWdlQ29u dHJvbCAgICAgICAgICAgUGVyY2VudGFnZSwKICAgICAgICBlbWFuRG10ZkNvbnRyb2wgICAgICAg ICAgICAgICAgIERtdGZQb3dlclN0YXRlCiAgICB9CgplbWFuQWNwaUNvbnRyb2wgT0JKRUNULVRZ UEUKICAgIFNZTlRBWCAgICAgICAgICBBY3BpU3RhdGUKICAgIE1BWC1BQ0NFU1MgICAgICByZWFk LXdyaXRlCiAgICBTVEFUVVMgICAgICAgICAgY3VycmVudAogICAgREVTQ1JJUFRJT04gICAgICJU aGUgY3VycmVudCBBQ1BJIHN0YXRlIG9mIHRoZSBlbnRpdHkuIgogICAgOjo9IHsgZW1hbkNvbnRy b2xFbnRyeSAxIH0KCmVtYW5QZXJjZW50YWdlQ29udHJvbCBPQkpFQ1QtVFlQRQogICAgU1lOVEFY ICAgICAgICAgIFBlcmNlbnRhZ2UKICAgIE1BWC1BQ0NFU1MgICAgICByZWFkLXdyaXRlCiAgICBT VEFUVVMgICAgICAgICAgY3VycmVudAogICAgREVTQ1JJUFRJT04gICAgICJUaGUgY3VycmVudCBz dGF0ZSBvZiB0aGUgZW50aXR5IGFzIGV4cHJlc3NlZCBieSBhCiAgICAgICAgICAgICAgICAgICAg cGVyY2VudGFnZSBvZiBpdHMgZnVsbCBydW5uaW5nIGNhcGFjaXR5LiIKICAgIDo6PSB7IGVtYW5D b250cm9sRW50cnkgMiB9CgplbWFuRG10ZkNvbnRyb2wgT0JKRUNULVRZUEUKICAgIFNZTlRBWCAg ICAgICAgICBEbXRmUG93ZXJTdGF0ZQoKCgpWZXJnZXMgICAgICAgICAgICAgICAgICAgRXhwaXJl cyBBdWd1c3QgMjcsIDIwMTEgICAgICAgICAgICAgICBbUGFnZSAyOV0KDApJbnRlcm5ldC1EcmFm dCAgZHJhZnQtdmVyZ2VzLWVtYW4tc2VwYXJhdGUtbW9kdWxlcy1taWItMDAgIEZlYnJ1YXJ5IDIw MTEKCgogICAgTUFYLUFDQ0VTUyAgICAgIHJlYWQtd3JpdGUKICAgIFNUQVRVUyAgICAgICAgICBj dXJyZW50CiAgICBERVNDUklQVElPTiAgICAgIlRoZSBjdXJyZW50IERNVEYgcG93ZXIgc3RhdGUg b2YgdGhlIGVudGl0eS4iCiAgICA6Oj0geyBlbWFuQ29udHJvbEVudHJ5IDMgfQoKLS0KLS0gRU1B TiBDb250ZXh0IEFkZC1PbgotLQoKZW1hbkNvbnRleHQgT0JKRUNUIElERU5USUZJRVIKICAgIDo6 PSB7IGVtYW4gNCB9CgpDb250ZXh0VHlwZSA6Oj0gVEVYVFVBTC1DT05WRU5USU9OCiAgICBTVEFU VVMgICAgICAgICAgY3VycmVudAogICAgREVTQ1JJUFRJT04gICAgICJTcGVjaWZpZXMgdGhlIHR5 cGUgb2YgY29udGV4dC4iCiAgICBTWU5UQVggICAgICAgICAgSU5URUdFUiB7CiAgICAgICAgICAg ICAgICAgICAgICAgIHBoeXNpY2FsKDEpLAogICAgICAgICAgICAgICAgICAgICAgICBsb2dpY2Fs KDIpCiAgICAgICAgICAgICAgICAgICAgfQoKZW1hbkNvbnRleHRUYWJsZSBPQkpFQ1QtVFlQRQog ICAgU1lOVEFYICAgICAgICAgIFNFUVVFTkNFIE9GIEVtYW5Db250ZXh0RW50cnkKICAgIE1BWC1B Q0NFU1MgICAgICBub3QtYWNjZXNzaWJsZQogICAgU1RBVFVTICAgICAgICAgIGN1cnJlbnQKICAg IERFU0NSSVBUSU9OICAgICAiQSBzcGFyc2UgdGFibGUgb2YgYWxsIHRoZSBlbnRpdHkncyB1c2Fn ZSBjb250ZXh0cy4iCiAgICA6Oj0geyBlbWFuQ29udGV4dCAxIH0KCmVtYW5Db250ZXh0RW50cnkg T0JKRUNULVRZUEUKICAgIFNZTlRBWCAgICAgICAgICBFbWFuQ29udGV4dEVudHJ5CiAgICBNQVgt QUNDRVNTICAgICAgbm90LWFjY2Vzc2libGUKICAgIFNUQVRVUyAgICAgICAgICBjdXJyZW50CiAg ICBERVNDUklQVElPTiAgICAgIkEgcGh5c2ljYWwgb3IgbG9naWNhbCBjb250ZXh0IHRvIGRlc2Ny aWJlIHRoZSBwb3dlcgogICAgICAgICAgICAgICAgICAgIHVzYWdlIG9mIGFuIGVudGl0eS4iCiAg ICBJTkRFWCAgICAgICAgICAgeyBlbWFuQ29udGV4dEluZGV4IH0KICAgIDo6PSB7IGVtYW5Db250 ZXh0VGFibGUgMSB9CgpFbWFuQ29udGV4dEVudHJ5IDo6PQogICAgU0VRVUVOQ0UgewogICAgICAg IGVtYW5Db250ZXh0SW5kZXggICAgICAgICAgICAgICAgVW5zaWduZWQzMiwKICAgICAgICBlbWFu Q29udGV4dE5hbWUgICAgICAgICAgICAgICAgIFNubXBBZG1pblN0cmluZywKICAgICAgICBlbWFu Q29udGV4dFR5cGUgICAgICAgICAgICAgICAgIENvbnRleHRUeXBlCiAgICB9CgplbWFuQ29udGV4 dEluZGV4IE9CSkVDVC1UWVBFCiAgICBTWU5UQVggICAgICAgICAgVW5zaWduZWQzMgogICAgTUFY LUFDQ0VTUyAgICAgIG5vdC1hY2Nlc3NpYmxlCiAgICBTVEFUVVMgICAgICAgICAgY3VycmVudAog ICAgREVTQ1JJUFRJT04gICAgICJUaGUgaW5kZXggZm9yIHRoZSBjb250ZXh0IG9mIHRoZSBlbnRp dHkuIgoKCgpWZXJnZXMgICAgICAgICAgICAgICAgICAgRXhwaXJlcyBBdWd1c3QgMjcsIDIwMTEg ICAgICAgICAgICAgICBbUGFnZSAzMF0KDApJbnRlcm5ldC1EcmFmdCAgZHJhZnQtdmVyZ2VzLWVt YW4tc2VwYXJhdGUtbW9kdWxlcy1taWItMDAgIEZlYnJ1YXJ5IDIwMTEKCgogICAgOjo9IHsgZW1h bkNvbnRleHRFbnRyeSAxIH0KCmVtYW5Db250ZXh0TmFtZSBPQkpFQ1QtVFlQRQogICAgU1lOVEFY ICAgICAgICAgIFNubXBBZG1pblN0cmluZwogICAgTUFYLUFDQ0VTUyAgICAgIHJlYWQtY3JlYXRl CiAgICBTVEFUVVMgICAgICAgICAgY3VycmVudAogICAgREVTQ1JJUFRJT04gICAgICJUaGUgaWRl bnRpZmllciBmb3IgdGhlIGNvbnRleHQgb2YgdGhlIGVudGl0eS4iCiAgICA6Oj0geyBlbWFuQ29u dGV4dEVudHJ5IDIgfQoKZW1hbkNvbnRleHRUeXBlIE9CSkVDVC1UWVBFCiAgICBTWU5UQVggICAg ICAgICAgQ29udGV4dFR5cGUKICAgIE1BWC1BQ0NFU1MgICAgICByZWFkLWNyZWF0ZQogICAgU1RB VFVTICAgICAgICAgIGN1cnJlbnQKICAgIERFU0NSSVBUSU9OICAgICAiVGhlIHR5cGUgb2YgdGhl IGNvbnRleHQuIgogICAgOjo9IHsgZW1hbkNvbnRleHRFbnRyeSAzIH0KCmVtYW5Db250ZXh0TWFw cGluZ1RhYmxlIE9CSkVDVC1UWVBFCiAgICBTWU5UQVggICAgICAgICAgU0VRVUVOQ0UgT0YgRW1h bkNvbnRleHRNYXBwaW5nRW50cnkKICAgIE1BWC1BQ0NFU1MgICAgICBub3QtYWNjZXNzaWJsZQog ICAgU1RBVFVTICAgICAgICAgIGN1cnJlbnQKICAgIERFU0NSSVBUSU9OICAgICAiQSBzcGFyc2Ug dGFibGUgdGhhdCBtYXBzIGFuIGVudGl0eSB0byBhIGNvbnRleHQuIgogICAgOjo9IHsgZW1hbkNv bnRleHQgMyB9CgplbWFuQ29udGV4dE1hcHBpbmdFbnRyeSBPQkpFQ1QtVFlQRQogICAgU1lOVEFY ICAgICAgICAgIEVtYW5Db250ZXh0TWFwcGluZ0VudHJ5CiAgICBNQVgtQUNDRVNTICAgICAgbm90 LWFjY2Vzc2libGUKICAgIFNUQVRVUyAgICAgICAgICBjdXJyZW50CiAgICBERVNDUklQVElPTiAg ICAgIkEgc2ltcGxlIG1hcHBpbmcgbWVjaGFuaXNtIHRvIGxpbmsgYSBjb250ZXh0IHRvIGFuCiAg ICAgICAgICAgICAgICAgICAgZW50aXR5LiIKICAgIElOREVYICAgICAgICAgICB7IGVtYW5Db250 ZXh0SW5kZXgsIGVtYW5FbnRpdHlJbmRleCB9CiAgICA6Oj0geyBlbWFuQ29udGV4dE1hcHBpbmdU YWJsZSAxIH0KCkVtYW5Db250ZXh0TWFwcGluZ0VudHJ5IDo6PQogICAgU0VRVUVOQ0UgewogICAg ICAgIGVtYW5Db250ZXh0TWFwcGluZ1Jvd1N0YXR1cyAgICAgUm93U3RhdHVzCiAgICB9CgplbWFu Q29udGV4dE1hcHBpbmdSb3dTdGF0dXMgT0JKRUNULVRZUEUKICAgIFNZTlRBWCAgICAgICAgICBS b3dTdGF0dXMKICAgIE1BWC1BQ0NFU1MgICAgICByZWFkLWNyZWF0ZQogICAgU1RBVFVTICAgICAg ICAgIGN1cnJlbnQKICAgIERFU0NSSVBUSU9OICAgICAiVGhpcyBvYmplY3QgZmFjaWxpdGF0ZXMg dGhlIGFkZGl0aW9uIGFuZCBkZWxldGlvbgogICAgICAgICAgICAgICAgICAgIG9mIGEgY29uY2Vw dHVhbCByb3cgbWFwcGluZyBpbiB0aGUgdGFibGUuIgogICAgOjo9IHsgZW1hbkNvbnRleHRNYXBw aW5nRW50cnkgMSB9CgotLQotLSBFTUFOIExMRFAgQWRkLU9uCi0tCgoKClZlcmdlcyAgICAgICAg ICAgICAgICAgICBFeHBpcmVzIEF1Z3VzdCAyNywgMjAxMSAgICAgICAgICAgICAgIFtQYWdlIDMx XQoMCkludGVybmV0LURyYWZ0ICBkcmFmdC12ZXJnZXMtZW1hbi1zZXBhcmF0ZS1tb2R1bGVzLW1p Yi0wMCAgRmVicnVhcnkgMjAxMQoKCmVtYW5MbGRwIE9CSkVDVCBJREVOVElGSUVSCiAgICA6Oj0g eyBlbWFuIDYgfQoKTGxkcFV1aWQgOjo9IFRFWFRVQUwtQ09OVkVOVElPTgogICAgRElTUExBWS1I SU5UICAgICIxNmEiCiAgICBTVEFUVVMgICAgICAgICAgY3VycmVudAogICAgREVTQ1JJUFRJT04g ICAgICJTcGVjaWZpZXMgYSBVbml2ZXJzYWxseSBVbmlxdWUgSWRlbnRpZmllci4iCiAgICBSRUZF UkVOQ0UgICAgICAgIklFVEYgUkZDIDQxMjIiCiAgICBTWU5UQVggICAgICAgICAgT0NURVQgU1RS SU5HIChTSVpFICgxNikpCgpMbGRwUG9ydEluZGV4T3JaZXJvIDo6PSBURVhUVUFMLUNPTlZFTlRJ T04KICAgIERJU1BMQVktSElOVCAgICAiZCIKICAgIFNUQVRVUyAgICAgICAgICBjdXJyZW50CiAg ICBERVNDUklQVElPTiAgICAgIlRoaXMgdGV4dHVhbCBjb252ZW50aW9uIGlzIGFuIGV4dGVuc2lv biBvZiB0aGUKICAgICAgICAgICAgICAgICAgICBwZXRoUHNlUG9ydEluZGV4IGNvbnZlbnRpb24s IHdoaWNoIGRlZmluZXMgYSBncmVhdGVyCiAgICAgICAgICAgICAgICAgICAgdGhhbiB6ZXJvIHZh bHVlIHVzZWQgdG8gaWRlbnRpZnkgYSBwb3dlciBFdGhlcm5ldAogICAgICAgICAgICAgICAgICAg IFBTRSBwb3J0LiAgVGhpcyBleHRlbnNpb24gcGVybWl0cyB0aGUgYWRkaXRpb25hbAogICAgICAg ICAgICAgICAgICAgIHZhbHVlIG9mIHplcm8uICBUaGUgc2VtYW50aWNzIG9mIHRoZSB2YWx1ZSB6 ZXJvIGFyZQogICAgICAgICAgICAgICAgICAgIG9iamVjdC1zcGVjaWZpYyBhbmQgbXVzdCwgdGhl cmVmb3JlLCBiZSBkZWZpbmVkIGFzCiAgICAgICAgICAgICAgICAgICAgcGFydCBvZiB0aGUgZGVz Y3JpcHRpb24gb2YgYW55IG9iamVjdCB0aGF0IHVzZXMgdGhpcwogICAgICAgICAgICAgICAgICAg IHN5bnRheC4gIEV4YW1wbGVzIG9mIHRoZSB1c2FnZSBvZiB0aGlzIGV4dGVuc2lvbiBhcmUKICAg ICAgICAgICAgICAgICAgICBzaXR1YXRpb25zIHdoZXJlIG5vbmUgb3IgYWxsIHBoeXNpY2FsIGVu dGl0aWVzIG5lZWQKICAgICAgICAgICAgICAgICAgICB0byBiZSByZWZlcmVuY2VkLiIKICAgIFNZ TlRBWCAgICAgICAgICBJbnRlZ2VyMzIgKDAuLjIxNDc0ODM2NDcpCgpMbGRwUG9ydEdyb3VwSW5k ZXhPclplcm8gOjo9IFRFWFRVQUwtQ09OVkVOVElPTgogICAgRElTUExBWS1ISU5UICAgICJkIgog ICAgU1RBVFVTICAgICAgICAgIGN1cnJlbnQKICAgIERFU0NSSVBUSU9OICAgICAiVGhpcyB0ZXh0 dWFsIGNvbnZlbnRpb24gaXMgYW4gZXh0ZW5zaW9uIG9mIHRoZQogICAgICAgICAgICAgICAgICAg IHBldGhQc2VQb3J0R3JvdXBJbmRleCBjb252ZW50aW9uLCB3aGljaCBkZWZpbmVzIGEKICAgICAg ICAgICAgICAgICAgICBncmVhdGVyIHRoYW4gemVybyB2YWx1ZSB1c2VkIHRvIGlkZW50aWZ5IGdy b3VwCiAgICAgICAgICAgICAgICAgICAgY29udGFpbmluZyB0aGUgcG9ydCB0byB3aGljaCBhIHBv d2VyIEV0aGVybmV0IFBTRSBpcwogICAgICAgICAgICAgICAgICAgIGNvbm5lY3RlZC4gIFRoaXMg ZXh0ZW5zaW9uIHBlcm1pdHMgdGhlIGFkZGl0aW9uYWwKICAgICAgICAgICAgICAgICAgICB2YWx1 ZSBvZiB6ZXJvLiAgVGhlIHNlbWFudGljcyBvZiB0aGUgdmFsdWUgemVybyBhcmUKICAgICAgICAg ICAgICAgICAgICBvYmplY3Qtc3BlY2lmaWMgYW5kIG11c3QsIHRoZXJlZm9yZSwgYmUgZGVmaW5l ZCBhcwogICAgICAgICAgICAgICAgICAgIHBhcnQgb2YgdGhlIGRlc2NyaXB0aW9uIG9mIGFueSBv YmplY3QgdGhhdCB1c2VzIHRoaXMKICAgICAgICAgICAgICAgICAgICBzeW50YXguICBFeGFtcGxl cyBvZiB0aGUgdXNhZ2Ugb2YgdGhpcyBleHRlbnNpb24gYXJlCiAgICAgICAgICAgICAgICAgICAg c2l0dWF0aW9ucyB3aGVyZSBub25lIG9yIGFsbCBwaHlzaWNhbCBlbnRpdGllcyBuZWVkCiAgICAg ICAgICAgICAgICAgICAgdG8gYmUgcmVmZXJlbmNlZC4iCiAgICBTWU5UQVggICAgICAgICAgSW50 ZWdlcjMyICgwLi4yMTQ3NDgzNjQ3KQoKTGxkcFBvcnROdW1iZXJPclplcm8gOjo9IFRFWFRVQUwt Q09OVkVOVElPTgogICAgRElTUExBWS1ISU5UICAgICJkIgogICAgU1RBVFVTICAgICAgICAgIGN1 cnJlbnQKICAgIERFU0NSSVBUSU9OICAgICAiVGhpcyB0ZXh0dWFsIGNvbnZlbnRpb24gaXMgYW4g ZXh0ZW5zaW9uIG9mIHRoZQogICAgICAgICAgICAgICAgICAgIExsZHBQb3J0TnVtYmVyIGNvbnZl bnRpb24gc3BlY2lmaWVkIGluIHRoZSBMTERQIE1JQiwKICAgICAgICAgICAgICAgICAgICB3aGlj aCBkZWZpbmVzIGEgZ3JlYXRlciB0aGFuIHplcm8gdmFsdWUgdXNlZCB0bwogICAgICAgICAgICAg ICAgICAgIHVuaXF1ZWx5IGlkZW50aWZ5IGVhY2ggcG9ydCBjb250YWluZWQgaW4gdGhlIGNoYXNz aXMKCgoKVmVyZ2VzICAgICAgICAgICAgICAgICAgIEV4cGlyZXMgQXVndXN0IDI3LCAyMDExICAg ICAgICAgICAgICAgW1BhZ2UgMzJdCgwKSW50ZXJuZXQtRHJhZnQgIGRyYWZ0LXZlcmdlcy1lbWFu LXNlcGFyYXRlLW1vZHVsZXMtbWliLTAwICBGZWJydWFyeSAyMDExCgoKICAgICAgICAgICAgICAg ICAgICAodGhhdCBpcyBrbm93biB0byB0aGUgTExEUCBhZ2VudCkgYnkgYSBwb3J0IG51bWJlci4K ICAgICAgICAgICAgICAgICAgICBUaGlzIGV4dGVuc2lvbiBwZXJtaXRzIHRoZSBhZGRpdGlvbmFs IHZhbHVlIG9mIHplcm8uCiAgICAgICAgICAgICAgICAgICAgVGhlIHNlbWFudGljcyBvZiB0aGUg dmFsdWUgemVybyBhcmUgb2JqZWN0LXNwZWNpZmljCiAgICAgICAgICAgICAgICAgICAgYW5kIG11 c3QsIHRoZXJlZm9yZSwgYmUgZGVmaW5lZCBhcyBwYXJ0IG9mIHRoZQogICAgICAgICAgICAgICAg ICAgIGRlc2NyaXB0aW9uIG9mIGFueSBvYmplY3QgdGhhdCB1c2VzIHRoaXMgc3ludGF4LgogICAg ICAgICAgICAgICAgICAgIEV4YW1wbGVzIG9mIHRoZSB1c2FnZSBvZiB0aGlzIGV4dGVuc2lvbiBh cmUKICAgICAgICAgICAgICAgICAgICBzaXR1YXRpb25zIHdoZXJlIG5vbmUgb3IgYWxsIHBoeXNp Y2FsIGVudGl0aWVzIG5lZWQKICAgICAgICAgICAgICAgICAgICB0byBiZSByZWZlcmVuY2VkLiIK ICAgIFNZTlRBWCAgICAgICAgICBJbnRlZ2VyMzIgKDAuLjQwOTYpCgplbWFuTGxkcFRhYmxlIE9C SkVDVC1UWVBFCiAgICBTWU5UQVggICAgICAgICAgU0VRVUVOQ0UgT0YgRW1hbkxsZHBFbnRyeQog ICAgTUFYLUFDQ0VTUyAgICAgIG5vdC1hY2Nlc3NpYmxlCiAgICBTVEFUVVMgICAgICAgICAgY3Vy cmVudAogICAgREVTQ1JJUFRJT04gICAgICJBIHNwYXJzZSB0YWJsZSBvZiBhbGwgdGhlIGVudGl0 eSdzIExMRFAKICAgICAgICAgICAgICAgICAgICBpbmZvcm1hdGlvbi4iCiAgICA6Oj0geyBlbWFu TGxkcCAxIH0KCmVtYW5MbGRwRW50cnkgT0JKRUNULVRZUEUKICAgIFNZTlRBWCAgICAgICAgICBF bWFuTGxkcEVudHJ5CiAgICBNQVgtQUNDRVNTICAgICAgbm90LWFjY2Vzc2libGUKICAgIFNUQVRV UyAgICAgICAgICBjdXJyZW50CiAgICBERVNDUklQVElPTiAgICAgIlRoZSBMTERQIGluZm9ybWF0 aW9uIGZvciBhbiBlbnRpdHkuIgogICAgSU5ERVggICAgICAgICAgIHsgZW1hbkVudGl0eUluZGV4 IH0KICAgIDo6PSB7IGVtYW5MbGRwVGFibGUgMSB9CgpFbWFuTGxkcEVudHJ5IDo6PQogICAgU0VR VUVOQ0UgewogICAgICAgIGVtYW5MbGRwVXVpZCAgICAgICAgICAgICAgICAgICAgTGxkcFV1aWQs CiAgICAgICAgZW1hbkxsZHBQaHlzaWNhbEluZGV4ICAgICAgICAgICBQaHlzaWNhbEluZGV4T3Ja ZXJvLAogICAgICAgIGVtYW5MbGRwUG9ydEluZGV4ICAgICAgICAgICAgICAgTGxkcFBvcnRJbmRl eE9yWmVybywKICAgICAgICBlbWFuTGxkcFBvcnRHcm91cEluZGV4ICAgICAgICAgIExsZHBQb3J0 R3JvdXBJbmRleE9yWmVybywKICAgICAgICBlbWFuTGxkcFBvcnQgICAgICAgICAgICAgICAgICAg IExsZHBQb3J0TnVtYmVyT3JaZXJvCiAgICB9CgplbWFuTGxkcFV1aWQgT0JKRUNULVRZUEUKICAg IFNZTlRBWCAgICAgICAgICBMbGRwVXVpZAogICAgTUFYLUFDQ0VTUyAgICAgIHJlYWQtb25seQog ICAgU1RBVFVTICAgICAgICAgIGN1cnJlbnQKICAgIERFU0NSSVBUSU9OICAgICAiVGhlIFVVSUQg b2YgdGhlIGVudGl0eS4iCiAgICA6Oj0geyBlbWFuTGxkcEVudHJ5IDEgfQoKZW1hbkxsZHBQaHlz aWNhbEluZGV4IE9CSkVDVC1UWVBFCiAgICBTWU5UQVggICAgICAgICAgUGh5c2ljYWxJbmRleE9y WmVybwogICAgTUFYLUFDQ0VTUyAgICAgIHJlYWQtb25seQogICAgU1RBVFVTICAgICAgICAgIGN1 cnJlbnQKICAgIERFU0NSSVBUSU9OICAgICAiVGhlIHBoeXNpY2FsIGluZGV4IG9mIHRoZSBlbnRp dHkgaW4KICAgICAgICAgICAgICAgICAgICBFTlRJVFktTUlCOjplbnRQaHlzaWNhbFRhYmxlLiIK CgoKVmVyZ2VzICAgICAgICAgICAgICAgICAgIEV4cGlyZXMgQXVndXN0IDI3LCAyMDExICAgICAg ICAgICAgICAgW1BhZ2UgMzNdCgwKSW50ZXJuZXQtRHJhZnQgIGRyYWZ0LXZlcmdlcy1lbWFuLXNl cGFyYXRlLW1vZHVsZXMtbWliLTAwICBGZWJydWFyeSAyMDExCgoKICAgIDo6PSB7IGVtYW5MbGRw RW50cnkgMiB9CgplbWFuTGxkcFBvcnRJbmRleCBPQkpFQ1QtVFlQRQogICAgU1lOVEFYICAgICAg ICAgIExsZHBQb3J0SW5kZXhPclplcm8KICAgIE1BWC1BQ0NFU1MgICAgICByZWFkLW9ubHkKICAg IFNUQVRVUyAgICAgICAgICBjdXJyZW50CiAgICBERVNDUklQVElPTiAgICAgIlRoZSBwb3J0IGlu ZGV4IG9mIHRoZSBlbnRpdHkuIgogICAgOjo9IHsgZW1hbkxsZHBFbnRyeSAzIH0KCmVtYW5MbGRw UG9ydEdyb3VwSW5kZXggT0JKRUNULVRZUEUKICAgIFNZTlRBWCAgICAgICAgICBMbGRwUG9ydEdy b3VwSW5kZXhPclplcm8KICAgIE1BWC1BQ0NFU1MgICAgICByZWFkLW9ubHkKICAgIFNUQVRVUyAg ICAgICAgICBjdXJyZW50CiAgICBERVNDUklQVElPTiAgICAgIlRoZSBwb3J0IGdyb3VwIGluZGV4 IG9mIHRoZSBlbnRpdHkuIgogICAgOjo9IHsgZW1hbkxsZHBFbnRyeSA0IH0KCmVtYW5MbGRwUG9y dCBPQkpFQ1QtVFlQRQogICAgU1lOVEFYICAgICAgICAgIExsZHBQb3J0TnVtYmVyT3JaZXJvCiAg ICBNQVgtQUNDRVNTICAgICAgcmVhZC1vbmx5CiAgICBTVEFUVVMgICAgICAgICAgY3VycmVudAog ICAgREVTQ1JJUFRJT04gICAgICJUaGUgcG9ydCBudW1iZXIgb2YgdGhlIGVudGl0eS4iCiAgICA6 Oj0geyBlbWFuTGxkcEVudHJ5IDUgfQoKRU5ECgoxNC4gIFNlY3VyaXR5IENvbnNpZGVyYXRpb25z CgogICBUaGVyZSBhcmUgYSBudW1iZXIgb2YgbWFuYWdlbWVudCBvYmplY3RzIGRlZmluZWQgaW4g dGhpcyBNSUIgbW9kdWxlCiAgIHdpdGggYSBNQVgtQUNDRVNTIGNsYXVzZSBvZiByZWFkLXdyaXRl IGFuZC9vciByZWFkLWNyZWF0ZS4gIFN1Y2gKICAgb2JqZWN0cyBtYXkgYmUgY29uc2lkZXJlZCBz ZW5zaXRpdmUgb3IgdnVsbmVyYWJsZSBpbiBzb21lIG5ldHdvcmsKICAgZW52aXJvbm1lbnRzLiAg VGhlIHN1cHBvcnQgZm9yIFNFVCBvcGVyYXRpb25zIGluIGEgbm9uLXNlY3VyZQogICBlbnZpcm9u bWVudCB3aXRob3V0IHByb3BlciBwcm90ZWN0aW9uIGNhbiBoYXZlIGEgbmVnYXRpdmUgZWZmZWN0 IG9uCiAgIG5ldHdvcmsgb3BlcmF0aW9ucy4gIFRoZXNlIGFyZSB0aGUgdGFibGVzIGFuZCBvYmpl Y3RzIGFuZCB0aGVpcgogICBzZW5zaXRpdml0eS92dWxuZXJhYmlsaXR5OgoKICAgbyAgZW1hbkNv bnRyb2xUYWJsZSAtIHdyaXRlIGFjY2VzcyB0byB0aGUgZW50cmllcyBpbiB0aGlzIHRhYmxlCiAg ICAgIGFsbG93cyBhbiBleHRlcm5hbCB1c2VyIHRvIGNoYW5nZSB0aGUgcG93ZXIgc3RhdGUgb2Yg dGhlIGVudGl0eS4KICAgICAgSWYgbm90IHByb3Blcmx5IGNvbmZpZ3VyZWQgYW5kIHNlY3VyZWQs IHRoaXMgY291bGQgcmVzdWx0IGluCiAgICAgIGVxdWlwbWVudCBiZWluZyBwb3dlcmVkIGRvd24g YWNjaWRlbnRhbGx5IG9yIG1hbGljaW91c2x5LgoKICAgU29tZSBvZiB0aGUgcmVhZGFibGUgb2Jq ZWN0cyBpbiB0aGlzIE1JQiBtb2R1bGUgKGkuZS4sIG9iamVjdHMgd2l0aCBhCiAgIE1BWC1BQ0NF U1Mgb3RoZXIgdGhhbiBub3QtYWNjZXNzaWJsZSkgbWF5IGJlIGNvbnNpZGVyZWQgc2Vuc2l0aXZl IG9yCiAgIHZ1bG5lcmFibGUgaW4gc29tZSBuZXR3b3JrIGVudmlyb25tZW50cy4gIEl0IGlzIHRo dXMgaW1wb3J0YW50IHRvCiAgIGNvbnRyb2wgZXZlbiBHRVQgYW5kL29yIE5PVElGWSBhY2Nlc3Mg dG8gdGhlc2Ugb2JqZWN0cyBhbmQgcG9zc2libHkKICAgdG8gZXZlbiBlbmNyeXB0IHRoZSB2YWx1 ZXMgb2YgdGhlc2Ugb2JqZWN0cyB3aGVuIHNlbmRpbmcgdGhlbSBvdmVyCiAgIHRoZSBuZXR3b3Jr IHZpYSBTTk1QLiAgVGhlc2UgYXJlIHRoZSB0YWJsZXMgYW5kIG9iamVjdHMgYW5kIHRoZWlyCiAg IHNlbnNpdGl2aXR5L3Z1bG5lcmFiaWxpdHk6CgoKCgpWZXJnZXMgICAgICAgICAgICAgICAgICAg RXhwaXJlcyBBdWd1c3QgMjcsIDIwMTEgICAgICAgICAgICAgICBbUGFnZSAzNF0KDApJbnRlcm5l dC1EcmFmdCAgZHJhZnQtdmVyZ2VzLWVtYW4tc2VwYXJhdGUtbW9kdWxlcy1taWItMDAgIEZlYnJ1 YXJ5IDIwMTEKCgogICBvICBOb25lIGF0IHRoaXMgdGltZQoKICAgU05NUCB2ZXJzaW9ucyBwcmlv ciB0byBTTk1QdjMgZGlkIG5vdCBpbmNsdWRlIGFkZXF1YXRlIHNlY3VyaXR5LgogICBFdmVuIGlm IHRoZSBuZXR3b3JrIGl0c2VsZiBpcyBzZWN1cmUgKGZvciBleGFtcGxlIGJ5IHVzaW5nIElQc2Vj KSwKICAgZXZlbiB0aGVuLCB0aGVyZSBpcyBubyBjb250cm9sIGFzIHRvIHdobyBvbiB0aGUgc2Vj dXJlIG5ldHdvcmsgaXMKICAgYWxsb3dlZCB0byBhY2Nlc3MgYW5kIEdFVC9TRVQgKHJlYWQvY2hh bmdlL2NyZWF0ZS9kZWxldGUpIHRoZSBvYmplY3RzCiAgIGluIHRoaXMgTUlCIG1vZHVsZS4KCiAg IEl0IGlzIFJFQ09NTUVOREVEIHRoYXQgaW1wbGVtZW50ZXJzIGNvbnNpZGVyIHRoZSBzZWN1cml0 eSBmZWF0dXJlcyBhcwogICBwcm92aWRlZCBieSB0aGUgU05NUHYzIGZyYW1ld29yayAoc2VlIFtS RkMzNDEwXSwgc2VjdGlvbiA4KSwKICAgaW5jbHVkaW5nIGZ1bGwgc3VwcG9ydCBmb3IgdGhlIFNO TVB2MyBjcnlwdG9ncmFwaGljIG1lY2hhbmlzbXMgKGZvcgogICBhdXRoZW50aWNhdGlvbiBhbmQg cHJpdmFjeSkuCgogICBGdXJ0aGVyLCBkZXBsb3ltZW50IG9mIFNOTVAgdmVyc2lvbnMgcHJpb3Ig dG8gU05NUHYzIGlzIE5PVAogICBSRUNPTU1FTkRFRC4gIEluc3RlYWQsIGl0IGlzIFJFQ09NTUVO REVEIHRvIGRlcGxveSBTTk1QdjMgYW5kIHRvCiAgIGVuYWJsZSBjcnlwdG9ncmFwaGljIHNlY3Vy aXR5LiAgSXQgaXMgdGhlbiBhIGN1c3RvbWVyL29wZXJhdG9yCiAgIHJlc3BvbnNpYmlsaXR5IHRv IGVuc3VyZSB0aGF0IHRoZSBTTk1QIGVudGl0eSBnaXZpbmcgYWNjZXNzIHRvIGFuCiAgIGluc3Rh bmNlIG9mIHRoaXMgTUlCIG1vZHVsZSBpcyBwcm9wZXJseSBjb25maWd1cmVkIHRvIGdpdmUgYWNj ZXNzIHRvCiAgIHRoZSBvYmplY3RzIG9ubHkgdG8gdGhvc2UgcHJpbmNpcGFscyAodXNlcnMpIHRo YXQgaGF2ZSBsZWdpdGltYXRlCiAgIHJpZ2h0cyB0byBpbmRlZWQgR0VUIG9yIFNFVCAoY2hhbmdl L2NyZWF0ZS9kZWxldGUpIHRoZW0uCgoxNS4gIElBTkEgQ29uc2lkZXJhdGlvbnMKCiAgIFRoZSBN SUIgbW9kdWxlIGluIHRoaXMgZG9jdW1lbnQgdXNlcyB0aGUgZm9sbG93aW5nIElBTkEtYXNzaWdu ZWQKICAgT0JKRUNUIElERU5USUZJRVIgdmFsdWVzIHJlY29yZGVkIGluIHRoZSBTTUkgTnVtYmVy cyByZWdpc3RyeToKCgogICAgICAgIERlc2NyaXB0b3IgICAgICAgIE9CSkVDVCBJREVOVElGSUVS IHZhbHVlCiAgICAgICAgLS0tLS0tLS0tLSAgICAgICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0K ICAgICAgICBlbWFuICAgICAgICAgICAgICB7IG1pYi0yIFhYWCB9CgoxNi4gIENvbnRyaWJ1dG9y cwoKICAgQSBzcGVjaWFsIHRoYW5rcyB0byBKb2huIFBhcmVsbG8sIEJyYWQgU2Nob2VuaW5nLCBh bmQgQnJ1Y2UgTm9yZG1hbgogICBmb3IgdGhlaXIgaGVscCBhbmQgZmVlZGJhY2sgZHVyaW5nIHRo ZSBkZXZlbG9wbWVudCBvZiB0aGlzIGRyYWZ0LgoKMTcuICBSZWZlcmVuY2VzCgoxNy4xLiAgTm9y bWF0aXZlIFJlZmVyZW5jZXMKCiAgIFtSRkMyMTE5XSAgICAgICBCcmFkbmVyLCBTLiwgIktleSB3 b3JkcyBmb3IgdXNlIGluIFJGQ3MgdG8gSW5kaWNhdGUKICAgICAgICAgICAgICAgICAgIFJlcXVp cmVtZW50IExldmVscyIsIEJDUCAxNCwgUkZDIDIxMTksIE1hcmNoIDE5OTcuCgogICBbUkZDMjU3 OF0gICAgICAgTWNDbG9naHJpZSwgSy4sIEVkLiwgUGVya2lucywgRC4sIEVkLiwgYW5kIEouCiAg ICAgICAgICAgICAgICAgICBTY2hvZW53YWVsZGVyLCBFZC4sICJTdHJ1Y3R1cmUgb2YgTWFuYWdl bWVudAogICAgICAgICAgICAgICAgICAgSW5mb3JtYXRpb24gVmVyc2lvbiAyIChTTUl2MikiLCBT VEQgNTgsIFJGQyAyNTc4LAogICAgICAgICAgICAgICAgICAgQXByaWwgMTk5OS4KCgoKClZlcmdl cyAgICAgICAgICAgICAgICAgICBFeHBpcmVzIEF1Z3VzdCAyNywgMjAxMSAgICAgICAgICAgICAg IFtQYWdlIDM1XQoMCkludGVybmV0LURyYWZ0ICBkcmFmdC12ZXJnZXMtZW1hbi1zZXBhcmF0ZS1t b2R1bGVzLW1pYi0wMCAgRmVicnVhcnkgMjAxMQoKCiAgIFtSRkMyNTc5XSAgICAgICBNY0Nsb2do cmllLCBLLiwgRWQuLCBQZXJraW5zLCBELiwgRWQuLCBhbmQgSi4KICAgICAgICAgICAgICAgICAg IFNjaG9lbndhZWxkZXIsIEVkLiwgIlRleHR1YWwgQ29udmVudGlvbnMgZm9yIFNNSXYyIiwKICAg ICAgICAgICAgICAgICAgIFNURCA1OCwgUkZDIDI1NzksIEFwcmlsIDE5OTkuCgogICBbUkZDMjU4 MF0gICAgICAgTWNDbG9naHJpZSwgSy4sIFBlcmtpbnMsIEQuLCBhbmQgSi4gU2Nob2Vud2FlbGRl ciwKICAgICAgICAgICAgICAgICAgICJDb25mb3JtYW5jZSBTdGF0ZW1lbnRzIGZvciBTTUl2MiIs IFNURCA1OCwgUkZDIDI1ODAsCiAgICAgICAgICAgICAgICAgICBBcHJpbCAxOTk5LgoKMTcuMi4g IEluZm9ybWF0aXZlIFJlZmVyZW5jZXMKCiAgIFtSRkMyMjIzXSAgICAgICBQb3N0ZWwsIEouIGFu ZCBKLiBSZXlub2xkcywgIkluc3RydWN0aW9ucyB0byBSRkMKICAgICAgICAgICAgICAgICAgIEF1 dGhvcnMiLCBSRkMgMjIyMywgT2N0b2JlciAxOTk3LgoKICAgW1JGQzM0MTBdICAgICAgIENhc2Us IEouLCBNdW5keSwgUi4sIFBhcnRhaW4sIEQuLCBhbmQgQi4gU3Rld2FydCwKICAgICAgICAgICAg ICAgICAgICJJbnRyb2R1Y3Rpb24gYW5kIEFwcGxpY2FiaWxpdHkgU3RhdGVtZW50cyBmb3IKICAg ICAgICAgICAgICAgICAgIEludGVybmV0LVN0YW5kYXJkIE1hbmFnZW1lbnQgRnJhbWV3b3JrIiwg UkZDIDM0MTAsCiAgICAgICAgICAgICAgICAgICBEZWNlbWJlciAyMDAyLgoKICAgW1JGQzI2Mjld ICAgICAgIFJvc2UsIE0uLCAiV3JpdGluZyBJLURzIGFuZCBSRkNzIHVzaW5nIFhNTCIsCiAgICAg ICAgICAgICAgICAgICBSRkMgMjYyOSwgSnVuZSAxOTk5LgoKICAgW1JGQzQxODFdICAgICAgIEhl YXJkLCBDLiwgIkd1aWRlbGluZXMgZm9yIEF1dGhvcnMgYW5kIFJldmlld2VycyBvZgogICAgICAg ICAgICAgICAgICAgTUlCIERvY3VtZW50cyIsIEJDUCAxMTEsIFJGQyA0MTgxLCBTZXB0ZW1iZXIg MjAwNS4KCiAgIFtFTkVSR1ktQVdBUkVdICBDbGFpc2UsIEIuIGFuZCBKLiBQYXJlbGxvLCAiRW5l cmd5LWF3YXJlIE5ldHdvcmtzIGFuZAogICAgICAgICAgICAgICAgICAgRGV2aWNlcyBNSUIiLCBk cmFmdC1pZXRmLWVtYW4tZW5lcmd5LWF3YXJlLTAwICh3b3JrCiAgICAgICAgICAgICAgICAgICBp biBwcm9ncmVzcyksIERlY2VtYmVyIDIwMTAsIDxFTkVSR1ktQVdBUkU+LgoKICAgW0VNQU4tUkVR XSAgICAgIFF1aXR0ZWssIEouLCBXaW50ZXIsIFIuLCBEaWV0eiwgVC4sIENsYWlzZSwgQi4sIGFu ZAogICAgICAgICAgICAgICAgICAgTS4gQ2hhbmRyYW1vdWxpLCAiUmVxdWlyZW1lbnRzIGZvciBQ b3dlciBNb25pdG9yaW5nIiwKICAgICAgICAgICAgICAgICAgIGRyYWZ0LWlldGYtZW1hbi1yZXF1 aXJlbWVudHMtMDAgKHdvcmsgaW4gcHJvZ3Jlc3MpLAogICAgICAgICAgICAgICAgICAgRGVjZW1i ZXIgMjAxMCwgPEVNQU4tUkVRPi4KCiAgIFtFTUFOLUZNV0tdICAgICBDbGFpc2UsIEIuLCBQYXJl bGxvLCBKLiwgU2Nob2VuaW5nLCBCLiwgYW5kIEouCiAgICAgICAgICAgICAgICAgICBRdWl0dGVr LCAiRW5lcmd5IE1hbmFnZW1lbnQgRnJhbWV3b3JrIiwKICAgICAgICAgICAgICAgICAgIGRyYWZ0 LWlldGYtZW1hbi1mcmFtZXdvcmstMDAgKHdvcmsgaW4gcHJvZ3Jlc3MpLAogICAgICAgICAgICAg ICAgICAgRGVjZW1iZXIgMjAxMCwgPEVNQU4tRk1XSz4uCgogICBbRU1BTi1BU10gICAgICAgVHlj aG9uLCBFLiwgTGFoZXJ0eSwgTS4sIGFuZCBCLiBTY2hvZW5pbmcsICJFbmVyZ3kKICAgICAgICAg ICAgICAgICAgIE1hbmFnZW1lbnQgKEVNQU4pIEFwcGxpY2FiaWxpdHkgU3RhdGVtZW50IiwKICAg ICAgICAgICAgICAgICAgIGRyYWZ0LXR5Y2hvbi1lbWFuLWFwcGxpY2FiaWxpdHktc3RhdGVtZW50 LTAwICh3b3JrIGluCiAgICAgICAgICAgICAgICAgICBwcm9ncmVzcyksIE9jdG9iZXIgMjAxMCwg PEVNQU4tQVM+LgoKICAgW1FVSVRURUtdICAgICAgIFF1aXR0ZWssIEouLCBXaW50ZXIsIFIuLCBE aWV0eiwgVC4sIGFuZCBELiBEdWRrb3dza2ksCiAgICAgICAgICAgICAgICAgICAiRGVmaW5pdGlv biBvZiBNYW5hZ2VkIE9iamVjdHMgZm9yIEVuZXJneQogICAgICAgICAgICAgICAgICAgTWFuYWdl bWVudCIsIGRyYWZ0LXF1aXR0ZWstcG93ZXItbWliLTAxICh3b3JrIGluCiAgICAgICAgICAgICAg ICAgICBwcm9ncmVzcyksIEFwcmlsIDIwMTAsIDxRVUlUVEVLPi4KCgoKClZlcmdlcyAgICAgICAg ICAgICAgICAgICBFeHBpcmVzIEF1Z3VzdCAyNywgMjAxMSAgICAgICAgICAgICAgIFtQYWdlIDM2 XQoMCkludGVybmV0LURyYWZ0ICBkcmFmdC12ZXJnZXMtZW1hbi1zZXBhcmF0ZS1tb2R1bGVzLW1p Yi0wMCAgRmVicnVhcnkgMjAxMQoKCiAgIFtQQVJFTExPXSAgICAgICBQYXJlbGxvLCBKLiBhbmQg Qi4gQ2xhaXNlLCAiRW5lcmd5LWF3YXJlIE5ldHdvcmtzIGFuZAogICAgICAgICAgICAgICAgICAg RGV2aWNlcyBNSUIiLAogICAgICAgICAgICAgICAgICAgZHJhZnQtcGFyZWxsby1lbWFuLWVuZXJn eS1hd2FyZS1taWItMDAgKHdvcmsgaW4KICAgICAgICAgICAgICAgICAgIHByb2dyZXNzKSwgT2N0 b2JlciAyMDEwLCA8UEFSRUxMTz4uCgogICBbQ0xBSVNFXSAgICAgICAgQ2xhaXNlLCBCLiwgQ2hh bmRyYW1vdWxpLCBNLiwgUGFyZWxsbywgSi4sIGFuZCBCLgogICAgICAgICAgICAgICAgICAgU2No b2VuaW5nLCAiUG93ZXIgYW5kIEVuZXJneSBNb25pdG9yaW5nIE1JQiIsCiAgICAgICAgICAgICAg ICAgICBkcmFmdC1jbGFpc2UtZW5lcmd5LW1vbml0b3JpbmctbWliLTA2ICh3b3JrIGluCiAgICAg ICAgICAgICAgICAgICBwcm9ncmVzcyksIE9jdG9iZXIgMjAxMCwgPENMQUlTRT4uCgoxNy4zLiAg VVJMIFJlZmVyZW5jZXMKCiAgIFtpZGd1aWRlbGluZXNdICBJRVRGIEludGVybmV0IERyYWZ0cyBl ZGl0b3IsCiAgICAgICAgICAgICAgICAgICAiaHR0cDovL3d3dy5pZXRmLm9yZy9pZXRmLzFpZC1n dWlkZWxpbmVzLnR4dCIuCgogICBbaWRuaXRzXSAgICAgICAgSUVURiBJbnRlcm5ldCBEcmFmdHMg ZWRpdG9yLAogICAgICAgICAgICAgICAgICAgImh0dHA6Ly93d3cuaWV0Zi5vcmcvSUQtQ2hlY2ts aXN0Lmh0bWwiLgoKICAgW3htbDJyZmNdICAgICAgIFhNTDJSRkMgdG9vbHMgYW5kIGRvY3VtZW50 YXRpb24sCiAgICAgICAgICAgICAgICAgICAiaHR0cDovL3htbC5yZXNvdXJjZS5vcmciLgoKICAg W29wc10gICAgICAgICAgIHRoZSBJRVRGIE9QUyBBcmVhLCAiaHR0cDovL3d3dy5vcHMuaWV0Zi5v cmciLgoKICAgW2lldGZdICAgICAgICAgIElFVEYgVG9vbHMgVGVhbSwgImh0dHA6Ly90b29scy5p ZXRmLm9yZyIuCgogICBbRFNQMTAyN10gICAgICAgRGlzdHJpYnV0ZWQgTWFuYWdlbWVudCBUYXNr IEZvcmNlLCAiaHR0cDovLwogICAgICAgICAgICAgICAgICAgd3d3LmRtdGYub3JnL3NpdGVzL2Rl ZmF1bHQvZmlsZXMvc3RhbmRhcmRzL2RvY3VtZW50cy8KICAgICAgICAgICAgICAgICAgIERTUDEw MjdfMS4wLjEucGRmIiwgMjAwOC4KCiAgIFtBQ1BJXSAgICAgICAgICBBZHZhbmNlZCBDb25maWd1 cmF0aW9uIGFuZCBQb3dlciBJbnRlcmZhY2UsCiAgICAgICAgICAgICAgICAgICAiaHR0cDovL3d3 dy5hY3BpLmluZm8vc3BlYy5odG0iLCAyMDEwLgoKQXBwZW5kaXggQS4gIEFja25vd2xlZGdlbWVu dHMKCiAgIFRCRAoKQXV0aG9yJ3MgQWRkcmVzcwoKICAgQ2hyaXMgVmVyZ2VzCiAgIEN5YmVyIFN3 aXRjaGluZywgSW5jLgogICAyMDUwIFJpbmd3b29kIEF2ZW51ZQogICBTYW4gSm9zZSwgQ2FsaWZv cm5pYSA5NTEzMQogICBVU0EKCiAgIFBob25lOiArMSA0MDggNDM2IDk4MzAKICAgRU1haWw6IGNo cmlzdkBjeWJlcnN3aXRjaGluZy5jb20KCgoKCgpWZXJnZXMgICAgICAgICAgICAgICAgICAgRXhw aXJlcyBBdWd1c3QgMjcsIDIwMTEgICAgICAgICAgICAgICBbUGFnZSAzN10KDAo= ------_=_NextPart_001_01CBD3E1.553D1092-- From dromasca@avaya.com Thu Feb 24 03:05:25 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFEBE3A6A7D for ; Thu, 24 Feb 2011 03:05:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id czpfbOsCi2+I for ; Thu, 24 Feb 2011 03:05:25 -0800 (PST) Received: from p-us1-iereast-outbound-tmp.us1.avaya.com (nj300815-nj-outbound.net.avaya.com [135.11.29.16]) by core3.amsl.com (Postfix) with ESMTP id 223E83A69EE for ; Thu, 24 Feb 2011 03:05:24 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEBAO/JZU2HCzI1/2dsb2JhbACXU45Sc6NjApkzhWAEj3M X-IronPort-AV: E=Sophos;i="4.62,215,1297054800"; d="scan'208";a="60594369" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 24 Feb 2011 06:06:13 -0500 X-IronPort-AV: E=Sophos;i="4.62,215,1297054800"; d="scan'208";a="604638505" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 24 Feb 2011 06:05:38 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 24 Feb 2011 12:05:27 +0100 Message-ID: In-Reply-To: <68FBE0F3CE97264395875AC1C468F22CECD6D2@mail03.cyberswitching.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] Draft proposal for consideration at upcoming meeting Thread-Index: AcvT33ahNQArPQpQQTqqr3Y4tSG4+QAMlhUQ References: <68FBE0F3CE97264395875AC1C468F22CECD6D2@mail03.cyberswitching.local> From: "Romascanu, Dan (Dan)" To: "Chris Verges" , Subject: Re: [eman] Draft proposal for consideration at upcoming meeting X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2011 11:05:26 -0000 Hi Chris, The WG chairs will certainly provide you more detailed advice - but to start, first you need to submit the Internet-Draft (before 3/7 which is Internet Draft Cut-off for initial documents (-00)) and ask them to put you on the agenda of the WG meeting. It would be good to find somebody who attends the meeting to present on your behalf, and you can follow the audio-stream and respond on jabber to questions from the room.=20 I hope this helps, Dan > -----Original Message----- > From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On=20 > Behalf Of Chris Verges > Sent: Thursday, February 24, 2011 7:12 AM > To: eman@ietf.org > Subject: [eman] Draft proposal for consideration at upcoming meeting >=20 > Dear all, >=20 > The eman mailing list has been silent for several weeks now,=20 > and I began to wonder whether the existing proposals were=20 > continuing to be developed and changed based on the=20 > objections and feedback noted on the mailing list and from=20 > the Beijing meeting last year. As an implementer, the=20 > current drafts raise some serious concerns about both=20 > usability and maintainability going forward. (These concerns=20 > are documented in the attached document.) >=20 > Attached is a new draft for the agenda at the upcoming Prague meeting. > This new document aims to combine the best aspects of the=20 > existing proposals into a single document and to create a new=20 > schema that should be more workable for a wider variety of=20 > entities (servers, switches, PDUs, etc.) It was easier to=20 > write a new draft than to try and change the original ones. >=20 > I will be unable to attend Prague in person due to other work=20 > commitments, but will attend virtually via the Jabber=20 > session. If someone familiar with the working group's=20 > proceedings could please let me know what is needed to=20 > proceed under these conditions, I would be most appreciative. >=20 > Thanks, > Chris >=20 From bclaise@cisco.com Thu Feb 24 08:19:30 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D0373A63CB for ; Thu, 24 Feb 2011 08:19:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.848 X-Spam-Level: X-Spam-Status: No, score=-2.848 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jS+wO5m6KXir for ; Thu, 24 Feb 2011 08:19:29 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id A3CEC3A676A for ; Thu, 24 Feb 2011 08:19:28 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p1OG90Nm015785; Thu, 24 Feb 2011 17:09:00 +0100 (CET) Received: from [10.55.43.53] (ams-bclaise-8714.cisco.com [10.55.43.53]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p1OG8uKl007840; Thu, 24 Feb 2011 17:08:57 +0100 (CET) Message-ID: <4D668298.6060209@cisco.com> Date: Thu, 24 Feb 2011 17:08:56 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Chris Verges References: <68FBE0F3CE97264395875AC1C468F22CECD6D2@mail03.cyberswitching.local> In-Reply-To: <68FBE0F3CE97264395875AC1C468F22CECD6D2@mail03.cyberswitching.local> Content-Type: multipart/alternative; boundary="------------070101010701090308010608" Cc: eman@ietf.org Subject: Re: [eman] Draft proposal for consideration at upcoming meeting X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2011 16:19:30 -0000 This is a multi-part message in MIME format. --------------070101010701090308010608 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Chris, > Dear all, > > The eman mailing list has been silent for several weeks now, and I began > to wonder whether the existing proposals were continuing to be developed > and changed based on the objections and feedback noted on the mailing > list and from the Beijing meeting last year. To be frank, the mailing list being so silent, is also a concern to me. I know that some work is being done in the background, but this lacks visibility. Hence you're valid concern... > As an implementer, the > current drafts raise some serious concerns about both usability and > maintainability going forward. (These concerns are documented in the > attached document.) > > Attached is a new draft for the agenda at the upcoming Prague meeting. > This new document aims to combine the best aspects of the existing > proposals into a single document and to create a new schema that should > be more workable for a wider variety of entities (servers, switches, > PDUs, etc.) It was easier to write a new draft than to try and change > the original ones. Thanks for your work on this one. Much appreciated. Here is a proposal. - Can we please get some feedback on the EMAN requirement drafts, on the mailing list. We want to make sure that we solve the right problem. As you categorized yourself as an implementer, your feedback is extremely important. You know, even a message such as: "I read it and it makes sense!" would be useful. - From there, if we agree, we should be looking at the framework, because the different MIB modules are based on the content of the framework. And for the framework, if we could start with the terminology. I've seen two emails on this terminology. Any other views? > I will be unable to attend Prague in person due to other work > commitments, but will attend virtually via the Jabber session. If > someone familiar with the working group's proceedings could please let > me know what is needed to proceed under these conditions, I would be > most appreciative. If nobody else proposes himself, one of the two chairs will do it. Regards, Benoit. > Thanks, > Chris > > > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman --------------070101010701090308010608 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Chris,

Dear all,

The eman mailing list has been silent for several weeks now, and I began
to wonder whether the existing proposals were continuing to be developed
and changed based on the objections and feedback noted on the mailing
list and from the Beijing meeting last year.
To be frank, the mailing list being so silent, is also a concern to me.
I know that some work is being done in the background, but this lacks visibility. Hence you're valid concern...
As an implementer, the
current drafts raise some serious concerns about both usability and
maintainability going forward.  (These concerns are documented in the
attached document.)

Attached is a new draft for the agenda at the upcoming Prague meeting.
This new document aims to combine the best aspects of the existing
proposals into a single document and to create a new schema that should
be more workable for a wider variety of entities (servers, switches,
PDUs, etc.)  It was easier to write a new draft than to try and change
the original ones.
Thanks for your work on this one. Much appreciated.

Here is a proposal.
- Can we please get some feedback on the EMAN requirement drafts, on the mailing list.
  We want to make sure that we solve the right problem.
  As you categorized yourself as an implementer, your feedback is extremely important.
  You know, even a message such as: "I read it and it makes sense!" would be useful.
- From there, if we agree, we should be looking at the framework, because the different MIB modules are based on the content of the framework.
  And for the framework, if we could start with the terminology. I've seen two emails on this terminology. Any other views?
I will be unable to attend Prague in person due to other work
commitments, but will attend virtually via the Jabber session.  If
someone familiar with the working group's proceedings could please let
me know what is needed to proceed under these conditions, I would be
most appreciative.
If nobody else proposes himself, one of the two chairs will do it.

Regards, Benoit.
Thanks,
Chris


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

--------------070101010701090308010608-- From jparello@cisco.com Thu Feb 24 09:03:37 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F06643A63CB for ; Thu, 24 Feb 2011 09:03:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HQLYmgGf0ylg for ; Thu, 24 Feb 2011 09:03:36 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 00D513A6765 for ; Thu, 24 Feb 2011 09:03:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jparello@cisco.com; l=2975; q=dns/txt; s=iport; t=1298567066; x=1299776666; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=WSh0IJG1eDxlv/JsIxp7iyfeEJdLRkuHU4HNYSOiMQI=; b=erGwikKh7/v3aLYxoXW8iYIVoc+0CCpwNcBenAS2qZFLLIbxNPrJDmpH ILenzoZa0ysxoGHIiTe20FiH5CgsfuXDjom36ND2z5Coi94AW1wVkyJ7y d9HzCvYKHDnVkpzOzmMRrsoY1ryiyeIU+iBdA2vCMByzW2vYQjyRhtXk0 k=; X-IronPort-AV: E=Sophos;i="4.62,219,1297036800"; d="scan'208";a="269954144" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 24 Feb 2011 17:04:26 +0000 Received: from [10.10.10.4] ([10.21.87.87]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p1OH4P3L009616; Thu, 24 Feb 2011 17:04:25 GMT Message-ID: <4D668F99.7090004@cisco.com> Date: Thu, 24 Feb 2011 09:04:25 -0800 From: john parello User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Mielke, William F (Bill)" References: <4D247CD7.1080102@cisco.com> <0DEE3BCEE44BFD4EBC3B7DC009C8E7922506E73D48@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> In-Reply-To: <0DEE3BCEE44BFD4EBC3B7DC009C8E7922506E73D48@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: eman mailing list , Juergen Quittek Subject: Re: [eman] Issue 1: terminology: PowerMonitor X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2011 17:03:37 -0000 Hi William, Juergen, This make sense and we will add the notion of a managed node or managed object in addition to the power monitor. John On 1/27/11 1:50 PM, Mielke, William F (Bill) wrote: > For what it is worth I agree with Juergen on this point. The term Power > Monitor should be applied only to those entities which provide the > monitoring. Whether those entities are themselves producers or consumers of > power seems incidental to the concept of being a monitor. I like Juergen's > definitions below. > > Cheers, > > William F. Mielke > Alcatel-Lucent > Distinguished Member of Technical Staff > 6200 East Broad Street > Room: 4B01-1V > Columbus, OH 43213-1530 > Email: Bill.Mielke@alcatel-lucent.com > Phone: 614 367 5628 > Fax: 614 367 5965 > > "Live like you're going to die tomorrow. > Learn like you're going to live forever." > > - Albert Einstein > > > >> -----Original Message----- >> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On >> Behalf Of Juergen Quittek >> Sent: Wednesday, January 12, 2011 5:35 AM >> To: Benoit Claise; eman mailing list >> Subject: Re: [eman] Issue 1: terminology: PowerMonitor >> >> Dear all, >> >> I have a few comments on eman terminology. I will send them >> in separate >> emails. Here is the first one on the term PowerMonitor. >> >>> Power Monitor >>> >>> A Power Monitor is a component within a system of components >>> that provides power, draws power, or reports energy consumption >>> on behalf of another Power Monitor. >> >> I think that power monitor is a good term for a component >> that is capable of >> providing power information on its own or other devices power. >> >> However, the current definition also calls a device a Power >> Monitor that is >> just an energy consumer, even if the device does not have any >> capability for >> power monitoring or reporting. With this definition EVERY >> node in a network >> for which we manage energy is a Power Monitor. The right term >> for this is >> "managed node". >> >> Here is my proposal for the definition of a power monitor: >> >> Power Monitor >> >> A power monitor has access to energy-related information concerning >> powered devices and is able to report this information to energy >> management systems. >> >> This may be extended with further properties of power >> monitors, such as >> >> The power monitor may also provide information on identities and >> properties of powered devices to the management system. >> >> A power monitor may store energy-related information and >> process it, >> for example, for aggregating information or for extracting >> statistics >> that are provided to the management system. >> >> == >> Juergen >> >> >> >> _______________________________________________ >> eman mailing list >> eman@ietf.org >> https://www.ietf.org/mailman/listinfo/eman From Michael.Suchoff@raritan.com Thu Feb 24 12:13:08 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71D593A6802 for ; Thu, 24 Feb 2011 12:13:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.598 X-Spam-Level: X-Spam-Status: No, score=-1.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eg8X+P-yNF9E for ; Thu, 24 Feb 2011 12:13:01 -0800 (PST) Received: from fig.raritan.com (fig.raritan.com [12.144.63.197]) by core3.amsl.com (Postfix) with ESMTP id 5C4B13A6807 for ; Thu, 24 Feb 2011 12:13:00 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01CBD45F.59ECE5F7" Date: Thu, 24 Feb 2011 15:13:42 -0500 Message-ID: <9C329342B62B87498B92834DEC9FF51E0BB8B031@fig.raritan.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: feedback on drafts Thread-Index: AcvUX1VdsDHMwuXMTkir2QnCvAqJBA== From: "Michael Suchoff" To: Subject: [eman] feedback on drafts X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2011 20:13:08 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBD45F.59ECE5F7 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CBD45F.59ECE5F7" ------_=_NextPart_002_01CBD45F.59ECE5F7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, =20 I have been a silent observer of this group for about a month. =20 By way of introduction, I am a principal engineer at Raritan. Raritan manufactures rack power distribution units and is an industry leader in outlet level metered rack PDUs. Our products contain a billing grade AC energy metering chip for each outlet and our devices contain a networked SNMP agent. Raritan also develops and sells SNMP data center power management software - and our management software is designed to work with any vendor's PDU - not just our own. I learned of this group through our client Cisco that outfits their data centers with our PDUs and power management software. =20 As an "implementer" of AC energy management products and as someone that has experience with many vendors' implementation of SNMP energy management, here are two thoughts on the MIBs produced by the eman ietf group. =20 1. Timestamps =20 When taking power measurements, there is no indication of the time when the measurement occurred. The major vendors of metered power distribution units and panel energy meters all include time stamped data logs. These data logs typically contain 100+ time stamped measurements per sensor (voltage/current/power, etc.). =20 The proposed MIBs do not take time of measurement into consideration and this will be a problem. Assume we want to get readings on an hourly basis from an SNMP manager that must communicate with many thousands of devices. Without data logging, it isn't possible to get accurately get timed measurements due to the variable delay times in the manager, network and agents. Our experience supporting every major vendor's PDU SNMP agent indicates variable SNMP GET delays of 2-45 seconds. =20 2. AC Power Terminology =20 There is a bit of a lack of understanding of AC power in the MIBs. Here are some examples: =20 * AC power is not an RMS measurement, it is an average reading. AC power is sinusoidal at 2x the AC line frequency, so use of the term "instantaneous AC power" is misleading and power meters do not report it. * Voltage & current RMS measurements are by definition averaged values, they are not "instantaneous RMS" measurements * 3-phase PDUs are not black and white either Wye or Delta. In North American 208V systems, power distribution units contain a combination of delta wired circuits (208V) and wye wired circuits (120V). * The nameplate MIB objects use names such as "max voltage" and have fixed single numeric values. Actual device nameplate values follow the UL (or IEC) 60950-1 conventions and are rated (not max) ranges (not single values). Example: "Rated Voltage: "190-240V 3-phase". * There are many IEC and ANSI standards for AC energy meters. The attempts in the MIB to define energy metering accuracy are nonstandard. * A major concern in AC data center management is detection of tripped circuit breakers (or blown fuses). The MIB contains no modeling for over current devices. =20 I hope the above are taken as constructive help. I mean no disrespect to the members that have put in long hours developing the MIBs. I am available to help improve the group's efforts. =20 Regards, Michael Suchoff Principal Engineer=20 =20 Raritan * 801 Jones Franklin Rd * Raleigh, NC 27606 USA Tel: 1.919.851.3663 ext.1371 michael.suchoff@raritan.com Visit our blog: blog.raritan.com =20 =20 ------_=_NextPart_002_01CBD45F.59ECE5F7 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,

 

I have been a silent observer of this group for about = a month.

 

By way of introduction, I am a principal engineer at = Raritan.  Raritan manufactures rack power distribution units and is an industry = leader in outlet level metered rack PDUs.  Our products contain a billing = grade AC energy metering chip for each outlet and our devices contain a networked = SNMP agent.  Raritan also develops and sells SNMP data center power = management software – and our management software is designed to work with = any vendor’s PDU – not just our own.  I learned of this = group through our client Cisco that outfits their data centers with our PDUs = and power management software.

 

As an “implementer” of AC energy = management products and as someone that has experience with many vendors’ implementation of SNMP energy management, here are two thoughts on the = MIBs produced by the eman ietf group.

 

  1. Timestamps=

 

When taking power measurements, there is no = indication of the time when the measurement occurred.  The major vendors of metered = power distribution units and panel energy meters all include time stamped data = logs.  These data logs typically contain 100+ time stamped measurements per sensor (voltage/current/power, etc.).

 

The proposed MIBs do not take time of measurement = into consideration and this will be a problem.  Assume we want to get = readings on an hourly basis from an SNMP manager that must communicate with many thousands of devices.  Without data logging, it isn’t = possible to get accurately get timed measurements due to the variable delay times in = the manager, network and agents.  Our experience supporting every major = vendor’s PDU SNMP agent indicates variable SNMP GET delays of 2-45 = seconds.

 

  1. AC Power = Terminology

 

There is a bit of a lack of understanding of AC power = in the MIBs.  Here are some examples:

 

·         AC power is not an RMS = measurement, it is an average reading.  AC power is sinusoidal at 2x the AC line frequency, so use of the term “instantaneous AC power” is misleading and power meters do not report = it.

·         Voltage & current RMS measurements are by definition averaged values, they are not = “instantaneous RMS” measurements

·         3-phase PDUs are not black = and white either Wye or Delta.  In North American 208V systems, power = distribution units contain a combination of delta wired circuits (208V) and wye wired circuits (120V).

·         The nameplate MIB objects = use names such as “max voltage” and have fixed single numeric values. =  Actual device nameplate values follow the UL (or IEC) 60950-1 conventions and = are rated (not max) ranges (not single values).  Example:  = “Rated Voltage: “190-240V 3-phase”.

·         There are many IEC and ANSI standards for AC energy meters.  The attempts in the MIB to define = energy metering accuracy are nonstandard.

·         A major concern in AC data = center management is detection of tripped circuit breakers (or blown fuses). =  The MIB contains no modeling for over current = devices.

 

I hope the above are taken as constructive help. I = mean no disrespect to the members that have put in long hours developing the = MIBs.  I am available to help improve the group’s = efforts.

 

Regards,

<= font size=3D2 color=3Dgray face=3DArial>Michael Suchoff
Principal = Engineer 

 

Raritan • 801 Jones Franklin Rd • Raleigh, NC 27606 USA
Tel: 1.919.851.3663 ext.1371

michael.suchoff@raritan.com

Visit our blog: blog.raritan.com

 

------_=_NextPart_002_01CBD45F.59ECE5F7-- ------_=_NextPart_001_01CBD45F.59ECE5F7 Content-Type: image/jpeg; name="image001.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image001.jpg Content-Location: image001.jpg /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCAAtAKADASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD0W88S 6NJaSoblm3IVwsbAnI6AkYBrlvt2hf8APDUP+/w/xrp7zWs2sofRbwjY27fGAuMdznpXJ/23Z/8A QDs/1rvox0dk/vPGxVRtq7X3MdqttEtlb6jpskwt5CVcO5ZkYHofqP8APNTrDYabYW76p9pluLhT IEjkxsXtnJ71PJewwaD9oj0l447l1DRNkxblIIYHqM4x6cfm7Vr63haK6uNJaaS5UMWuMhUHQKAP T8+atSk7LXd9dTBwjFuSavZdHZX62IrPU9BjvYnWG9jKsCGaTIHPUgHJFdba65pt7OILa43yMDgb GGccnkjFcZYa3afbYduhwBt42+XktnP8IPU12NnqpubgRf2ZdwbgTvkjCqMepzWFePdPbudmEm3p db9Eed65DNeeNriyjmaMzXKopJOFLYGf1qTUbLXfB9xDMt8SkhO1o3YoxHVWU0zV7pLHx5NdurOs N0rsB1IUg4FTeINeuPF09vZ2FjLtjYsqj5mZjxk44AFcp6Z6Jouo/wBqaRbXuADKmWUdmHBH5g1o VwWsatP4R0Gx0e1dRemPe74BCAk5wD3JJA+lULZ/GttZ/wBrCSaSEruZJHDkr67DyB345pDPTKK8 48OeItXvItWa4vWcwWMksZKr8rAcNwKo6brnivWWksbS6eR3AYt8qlFGc/NgYzke/FAHS+NtD1bV zamwO+OLcHj3hcE4w3PB/pU2p61d+FNB09Z4hdzkCORmcjkLnOcc+lYGs6h4i8P6Vp8U19LHcyvM XJZXJUFdvJz6n86g8YSajcafpNzcSM9tLaxsCSvzSlcscDnofpTEegaNqB1XSbe+aMRmZSxQHIHJ HX8K0K820XVdY0LQzfXeXsTFts0JTDOW44HzYADHn0qvYXHjHXne9tLmYqjYyHVEz/dCnAP+c0hn qNFeY6f4k1+bxLbWl3ctGGnSOWLYoHUAjGOM0XHiLxC/ii5sLK6dybmSKKNlXaBuZR27Dnn0oA9O ory3UL7xT4Z1CJry+eXzBvCl96OAeVwen6da9LtLlbu0huFGFmRXA9MjNAGLdX+vrbyldJiUhTgi cMRx1xjn6Vz/APa/if8A59X/APAb/wCtXczx+dA8YdkLqVDqcMMjqPesX/hGJ/8AoOah/wB/K6Kd SKTukedXoVG1ytv7jDvtRvrPSlmvW/066I2IwAEcakH7vYkj/OKlur/VTFFe6SHkt7kbmjEYfy3H BAGOAev51euPBkVy4e41K7lcDALsGIHpk1JF4R+yx7INWvYlJyVR8DPrgVpz07Lv6aGHsa7bVnay tqrmVaap4mN1GGsmZSwBDQhQfq2OPrXS2Vzq8k4W6sIoosHLrNuI9OKhtvD81vcxytrF9IEYMUaT KtjsR6VtZwKxqTUtkjrw9GcFeTfzPLL+JLj4iNDKodJL1FZT0ZSQCKG+0+CPFRKhngJyB/z0jY9P qP5iuxk8G2sniAawbqYSiZZtgA25BBx644q5r3h618QwRxzs0bRMWSRANwB6jnsePyrI7ThfHTrN rNrqEbeZb3FujRsOjAE5H6j867k+JNI/sg3v2qLyvLz5e4b84+7jrntVOPwZZjSDps9xNPEH3xMw AaJj12kdj6dKzrb4a2iT77i/kljHRFQKT9Tk0gOe8KsGj11lG0HTJiB6Vr/DFQZtSbHIWMZ+pb/C trTPBFppiXax3c0gu7doG3AfKrdSPerXh7wzB4ea4MFxJL54UNvAGNuemPrQI5z4n/f03/dl/wDZ ah8W/wDImaD/ANcl/wDRYrqfEPhmDxC1uZ7iSLyAwXYAc7sdc/Smal4Vt9U0qy0+W5ljSzVVVkxl sKF5/KmM5XWIJJPhzpUqAlYny+OwJYA/n/OtrwTrNgPDsdq9xFDNblg6uwUkFiQ3PUc/pW9aaNbW 2jLpUmZ7dUKNvHLAknt9a5mb4aWrzl4tQljhJzsMYZgPTdn+lAGLNf2+pfEWG5tiDE1yiqw6NtwC fxxTtIGfic+f+fy4/k9dLa+AtPs9ThvILidfJdGVDgglcdT15xU9p4QtbXxC2srcytK0ry7CBty2 7I9eN1IDD+J339P/AN2T/wBlrqNHu7eHRtPjkmRHa3j2oxAJyAB+tReIfDMHiFoDNcSReSGC7ADn OOufpSS+GbWUW8bTSFYYRCR3ZQMdexI/xGDzQBpalM1vptzPGQHiidlJGcEKSKyrbWZZLC41WUZh hXaIBgOWBAZmz90nsvp9a25oUuYJIJASkilWGeoIwapSaRZSFmMbDzYgjhXI3AYxn1I9etAEP9su kzWz2bi6LqqRBwQ25SwJbtgK2eO3emrr6BpUltnWSJWBTIO5lKjaD3zvUg/7VXJtKtrqRppAwlfa d6sQylc4IPbqfzqMaPZBocozNDIZg7OSxc9ye/QfkPSgB9lqcd6f3cbALCkrEn7pbPyn3GDmqCeI ZXiVxpsmJLc3KZkXlBjdn0PIwO+e1aVpY29n53kqR57mR8sTyeuPQe1NXSrRESNUbbHbG2Ubj/qz jI+vyjmgCp/bgcGVbZzaJIsbzbgMM23+HqQCwBP14NR/8JEEhSR7YIs0rJCZJQobaSGYnHyjjjqT mrSaNZ+YCBIEDKxjDnazAAAkdzwPyFPOk2zQxRrvj8py8bI5DKWJ3YPoc9KAJbK8W9sEu41YeYpI VuoI4I/MVg2uuX0miOHdW1ByohO0AMHG4Nj/AGQGz/uV0EVssbcSStlAh3uW4Geee/vVePR7GOSC RYjut4jFGdx4Xp+eM8+5oAoweINkFgJ9sklwkPmFZFDKz4AO30yfb8alh13zRE8lq8MMyuY3Mi8l ckg+gIBwc9u1SroFijJs81VUx/IJDtLR42sR3I2j8qkfRrGa1S2eMmKIMqruPRhg/wA6AKkPiBbh vKitxJOZFRUSUFW3KWzux0AU54/OmP4mjjAV7crKGcNHJKq42NtOD3JPQfyqtr622i2IvfKmuJWn RS7Tsrg7WwQw6cEjGMEGptD06C60q2vN00Usu6UOkhDBZGyUJ/iHTk9xnigC9c6vHClnIkeVvMFH dtirkAgEkcE54Hc1ANankmRIrF2813jiYyAAshO4njgYBweenSr93p0N9AIZmk8sDBVXIDjjhvXp SR6fbRGFkQgwuzp8x4L5z/6EaAKDeI4AttJ5a7ZlUlTIu9NzbR8vcA98j2zTE16d2tZvsey2ljeR i7gttUAlhj6njvx0qyPD1ggAUSquVyiyEKxU5UkdyMVMdJtTHbRhWVbdSqYY8qRgqfUGgDPj8TpI o2WzSSOUCKkinO5toDHopBxke9akf24zAymEQsuSi5LKcdM9CPwqGPSreGNU3zOkZWRFeQkLtOQB 7Vbt4xHH5YZ2C55dixPPqaAP/9k= ------_=_NextPart_001_01CBD45F.59ECE5F7-- From ietf@quittek.at Thu Feb 24 23:35:23 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26D0C3A691E for ; Thu, 24 Feb 2011 23:35:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RlyEWy+rT2BC for ; Thu, 24 Feb 2011 23:35:20 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.10]) by core3.amsl.com (Postfix) with ESMTP id 014903A6828 for ; Thu, 24 Feb 2011 23:35:19 -0800 (PST) Received: from n-0711.office.hd (mito.netlab.nec.de [195.37.70.39]) by mrelayeu.kundenserver.de (node=mreu0) with ESMTP (Nemesis) id 0LwEDC-1Q6hXT0igY-0186AY; Fri, 25 Feb 2011 08:36:10 +0100 References: <9C329342B62B87498B92834DEC9FF51E0BB8B031@fig.raritan.com> In-Reply-To: <9C329342B62B87498B92834DEC9FF51E0BB8B031@fig.raritan.com> Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-1-337105538 Message-Id: From: Juergen Quittek Date: Fri, 25 Feb 2011 08:36:08 +0100 To: Michael Suchoff X-Mailer: Apple Mail (2.1082) X-Provags-ID: V02:K0:GKY+Y1RKx1lj9yEhIsSM25p1Y4cnWni27d56nq2K6A5 azSntNhnR/byaKVuNEWullYj+AmYXYN9WZEmr3G1UPrJodfx83 6lbhoGyQE6Mo9FnJdgJmoPzXIRNYSFP0Nw1Nok2LQ/w0O7qrUZ 0qf16vd48isYSoLB7S7lgRInQPBtMbSo1hQDIQUqVLUumZDnjx w3FoXFwaOUYF7CZrpo4mw== Cc: eman@ietf.org Subject: Re: [eman] feedback on drafts X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 07:35:23 -0000 --Apple-Mail-1-337105538 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Dear Michael, Thanks a lot for becoming active on this list. Your comments are very helpful. Are the MIB module that you are using publicly available? If yes, could you give us a pointer to them? It would be great if we could study them and learn from them. Thanks, Juergen =20 Am 24.02.2011 um 21:13 schrieb Michael Suchoff: > All, > =20 > I have been a silent observer of this group for about a month. > =20 > By way of introduction, I am a principal engineer at Raritan. Raritan = manufactures rack power distribution units and is an industry leader in = outlet level metered rack PDUs. Our products contain a billing grade AC = energy metering chip for each outlet and our devices contain a networked = SNMP agent. Raritan also develops and sells SNMP data center power = management software =96 and our management software is designed to work = with any vendor=92s PDU =96 not just our own. I learned of this group = through our client Cisco that outfits their data centers with our PDUs = and power management software. > =20 > As an =93implementer=94 of AC energy management products and as = someone that has experience with many vendors=92 implementation of SNMP = energy management, here are two thoughts on the MIBs produced by the = eman ietf group. > =20 > Timestamps > =20 > When taking power measurements, there is no indication of the time = when the measurement occurred. The major vendors of metered power = distribution units and panel energy meters all include time stamped data = logs. These data logs typically contain 100+ time stamped measurements = per sensor (voltage/current/power, etc.). > =20 > The proposed MIBs do not take time of measurement into consideration = and this will be a problem. Assume we want to get readings on an hourly = basis from an SNMP manager that must communicate with many thousands of = devices. Without data logging, it isn=92t possible to get accurately = get timed measurements due to the variable delay times in the manager, = network and agents. Our experience supporting every major vendor=92s = PDU SNMP agent indicates variable SNMP GET delays of 2-45 seconds. > =20 > AC Power Terminology > =20 > There is a bit of a lack of understanding of AC power in the MIBs. = Here are some examples: > =20 > =B7 AC power is not an RMS measurement, it is an average = reading. AC power is sinusoidal at 2x the AC line frequency, so use of = the term =93instantaneous AC power=94 is misleading and power meters do = not report it. > =B7 Voltage & current RMS measurements are by definition = averaged values, they are not =93instantaneous RMS=94 measurements > =B7 3-phase PDUs are not black and white either Wye or Delta. = In North American 208V systems, power distribution units contain a = combination of delta wired circuits (208V) and wye wired circuits = (120V). > =B7 The nameplate MIB objects use names such as =93max = voltage=94 and have fixed single numeric values. Actual device = nameplate values follow the UL (or IEC) 60950-1 conventions and are = rated (not max) ranges (not single values). Example: =93Rated Voltage: = =93190-240V 3-phase=94. > =B7 There are many IEC and ANSI standards for AC energy = meters. The attempts in the MIB to define energy metering accuracy are = nonstandard. > =B7 A major concern in AC data center management is detection = of tripped circuit breakers (or blown fuses). The MIB contains no = modeling for over current devices. > =20 > I hope the above are taken as constructive help. I mean no disrespect = to the members that have put in long hours developing the MIBs. I am = available to help improve the group=92s efforts. > =20 > Regards, > Michael Suchoff > Principal Engineer=20 > > Raritan =95 801 Jones Franklin Rd =95 Raleigh, NC 27606 USA > Tel: 1.919.851.3663 ext.1371 > michael.suchoff@raritan.com > Visit our blog: blog.raritan.com > =20 > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman --Apple-Mail-1-337105538 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Dear Michael,

Thanks a lot for = becoming active on this list.
Your comments are very = helpful.

Are the MIB module that you are using = publicly available?
If yes, could you give us a pointer to = them?
It would be great if we could study them and learn from = them.

Thanks,

 &nbs= p;  Juergen

 
Am = 24.02.2011 um 21:13 schrieb Michael Suchoff:

I = have been a silent observer of this group for about a = month.
By = way of introduction, I am a principal engineer at Raritan.  Raritan = manufactures rack power distribution units and is an industry leader in = outlet level metered rack PDUs.  Our products contain a billing = grade AC energy metering chip for each outlet and our devices contain a = networked SNMP agent.  Raritan also develops and sells SNMP data = center power management software =96 and our management software is = designed to work with any vendor=92s PDU =96 not just our own.  I = learned of this group through our client Cisco that outfits their data = centers with our PDUs and power management = software.
As = an =93implementer=94 of AC energy management products and as someone = that has experience with many vendors=92 implementation of SNMP energy = management, here are two thoughts on the MIBs produced by the eman ietf = group.
  • Timestamps
    •  
    When taking power measurements, there is no = indication of the time when the measurement occurred.  The major = vendors of metered power distribution units and panel energy meters all = include time stamped data logs.  These data logs typically contain = 100+ time stamped measurements per sensor (voltage/current/power, = etc.).
    The = proposed MIBs do not take time of measurement into consideration and = this will be a problem.  Assume we want to get readings on an = hourly basis from an SNMP manager that must communicate with many = thousands of devices.  Without data logging, it isn=92t possible to = get accurately get timed measurements due to the variable delay times in = the manager, network and agents.  Our experience supporting every = major vendor=92s PDU SNMP agent indicates variable SNMP GET delays of = 2-45 seconds.
  • AC Power = Terminology
    •  
    =B7 <= /font>AC power is not an RMS measurement, it is an = average reading.  AC power is sinusoidal at 2x the AC line = frequency, so use of the term =93instantaneous AC power=94 is misleading = and power meters do not report it.
    =B7 <= /font>Voltage & current RMS measurements are by = definition averaged values, they are not =93instantaneous RMS=94 = measurements
    =B7         <= /font>3-phase PDUs are not black and white either Wye or = Delta.  In North American 208V systems, power distribution units = contain a combination of delta wired circuits (208V) and wye wired = circuits (120V).
    =B7         <= /font>The nameplate MIB objects use names such as =93max = voltage=94 and have fixed single numeric values.  Actual device = nameplate values follow the UL (or IEC) 60950-1 conventions and are = rated (not max) ranges (not single values).  Example:  =93Rated = Voltage: =93190-240V 3-phase=94.
    =B7 <= /font>There are many IEC and ANSI standards for AC = energy meters.  The attempts in the MIB to define energy metering = accuracy are nonstandard.
    =B7 <= /font>A major concern in AC data center management is = detection of tripped circuit breakers (or blown fuses).  The MIB = contains no modeling for over current = devices.
    I = hope the above are taken as constructive help. I mean no disrespect to = the members that have put in long hours developing the MIBs.  I am = available to help improve the group=92s = efforts.
    Michael = Suchoff
    Principal = Engineer 
    Raritan =95 801 = Jones Franklin Rd =95 Raleigh, NC 27606 USA
    Tel: = 1.919.851.3663 ext.1371
    Visit our = blog: eman@ietf.org
    In-Reply-To: <68FBE0F3CE97264395875AC1C468F22CECD6D2@mail03.cyberswitching.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] Draft proposal for consideration at upcoming meeting Thread-Index: AcvT33ahNQArPQpQQTqqr3Y4tSG4+QA8S2Nw References: <68FBE0F3CE97264395875AC1C468F22CECD6D2@mail03.cyberswitching.local> From: "Mouli Chandramouli (moulchan)" To: "Chris Verges" , X-OriginalArrivalTime: 25 Feb 2011 10:36:57.0662 (UTC) FILETIME=[ED6D6DE0:01CBD4D7] Subject: Re: [eman] Draft proposal for consideration at upcoming meeting X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 10:36:08 -0000 Hi Chris, Thanks for your email which has infused energy in the email list.=20 I read your draft and I have some comments and questions.=20 Based on the EMAN Charter, there was a requirement that there shall 2 areas of work.=20 3. Energy-aware Networks and Devices MIB document=20 4. Power and Energy Monitoring MIB document=20 Our drafts http://www.ietf.org/id/draft-ietf-eman-energy-aware-mib-00.txt, http://tools.ietf.org/html/draft-claise-energy-monitoring-mib-06 are work items based on the WG charter goals.=20 In summary, your proposed MIB module has concepts from our MIB proposal (pmPowerCategory, pmPowerAccuracy, pmPowerNameplate, pmPowerType, ...).=20 Our new MIB draft that we are working on shall be posted in a few days has a new proposal for PowerStates -=20 There are some new additions in terms of EmanDataAlertEntry and EmanContextEntry and a simplified proposal for PowerStates and a new grouping of LLDP Indices in EmanLldpEntry.=20 EmanDataAlertEntry - Alerts from a power monitoring sense are quite useful at an aggregate level, when there electrical overload, which may cause potential circuit breaks. Since the index is emanEntityIndex is it useful to have alerts for power at an entity level ? Routers have alerts when the heat dissipation exceeds a threshold and the router is shutdown.=20 According to the requirements draft, https://wiki.tools.ietf.org/html/draft-ietf-eman-requirements-00 it was required to keep track of additional statistics - total time spent in each state, power consumption in each state, ....In addition to power consumption, Energy measurement is also another requirement.=20 We are working on a revised MIB draft that shall be posted soon, and that contains a proposal for a modified PowerState modeling of entities. The detailed MIB structure of the PowerQuality MIB module is based on the IEC 61850 standard.=20 Regarding the NamePlate Power consumption we have provided only the Maximum value in Watts. As you have pointed it may be useful provide the Volts and Amperes etc. The reason for the choice of pmPowerNamePlate was, in the absence of actual measurement, atleast we atleast have the worst case power consumption of the device that can be useful for planning purposes. However, not sure of the minimum value of NamePlate from a network management point of view.=20 Thanks Mouli -----Original Message----- From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Chris Verges Sent: Thursday, February 24, 2011 10:42 AM To: eman@ietf.org Subject: [eman] Draft proposal for consideration at upcoming meeting Dear all, The eman mailing list has been silent for several weeks now, and I began to wonder whether the existing proposals were continuing to be developed and changed based on the objections and feedback noted on the mailing list and from the Beijing meeting last year. As an implementer, the current drafts raise some serious concerns about both usability and maintainability going forward. (These concerns are documented in the attached document.) Attached is a new draft for the agenda at the upcoming Prague meeting. This new document aims to combine the best aspects of the existing proposals into a single document and to create a new schema that should be more workable for a wider variety of entities (servers, switches, PDUs, etc.) It was easier to write a new draft than to try and change the original ones. I will be unable to attend Prague in person due to other work commitments, but will attend virtually via the Jabber session. If someone familiar with the working group's proceedings could please let me know what is needed to proceed under these conditions, I would be most appreciative. Thanks, Chris From chrisv@cyberswitching.com Fri Feb 25 07:26:38 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDA033A69E9 for ; Fri, 25 Feb 2011 07:26:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.183 X-Spam-Level: X-Spam-Status: No, score=-6.183 tagged_above=-999 required=5 tests=[AWL=0.417, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ezNUZm+YzoQd for ; Fri, 25 Feb 2011 07:26:37 -0800 (PST) Received: from p01c12o144.mxlogic.net (p01c12o144.mxlogic.net [208.65.145.67]) by core3.amsl.com (Postfix) with ESMTP id B4A0E3A69E8 for ; Fri, 25 Feb 2011 07:26:36 -0800 (PST) Received: from unknown [207.47.28.34] (EHLO mail03.cyberswitching.local) by p01c12o144.mxlogic.net(mxl_mta-6.9.0-1) with ESMTP id 16ac76d4.0.4043.00-393.8992.p01c12o144.mxlogic.net (envelope-from ); Fri, 25 Feb 2011 08:27:29 -0700 (MST) X-MXL-Hash: 4d67ca61793dea8c-e5a72087eb002b7f6dfabbf95ba00abd21b82566 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 25 Feb 2011 07:27:15 -0800 Message-ID: <68FBE0F3CE97264395875AC1C468F22CECD798@mail03.cyberswitching.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] Draft proposal for consideration at upcoming meeting Thread-Index: AcvT33ahNQArPQpQQTqqr3Y4tSG4+QA8S2NwAAsEKlA= References: <68FBE0F3CE97264395875AC1C468F22CECD6D2@mail03.cyberswitching.local> From: "Chris Verges" To: "Mouli Chandramouli \(moulchan\)" , X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [207.47.28.34] X-AnalysisOut: [v=1.0 c=1 a=A1bLCTiLF8kA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel] X-AnalysisOut: [0A:10 a=1Eql4bHns2NoxN2V9ejGkg==:17 a=wzgqfsuUAAAA:8 a=sWp] X-AnalysisOut: [msl2pAAAA:8 a=tx5B84syAAAA:8 a=cwoZddJ_AAAA:8 a=AUd_NHdVAA] X-AnalysisOut: [AA:8 a=48vgC7mUAAAA:8 a=u7Q_VACzLqnpd_w_sHcA:9 a=2SoAFxYr4] X-AnalysisOut: [wx0OnqEE1EA:7 a=LByGEJ4hQgKrFiufnivzu3IXNwQA:4 a=CjuIK1q_8] X-AnalysisOut: [ugA:10 a=JfD0Fch1gWkA:10 a=lZB815dzVvQA:10 a=Vfj7Kcky2gLg4] X-AnalysisOut: [1DW:21 a=yC6hZRqqzGPMlVhr:21] Subject: Re: [eman] Draft proposal for consideration at upcoming meeting X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 15:26:38 -0000 Hi Mouli, Thanks for the feedback. I'm not entirely sure what was a comment and what was a question, so I'll address what I can. Please let me know if I missed something. My draft combines charter items #3 and #4 into the same draft document, with #3 being handled by the EMAN-CORE-MIB components and #4 by EMAN-DATA-MIB. Yes, it does share concepts with both the Cisco MIBs (Claise/Parello) and Quittek's MIB, as I mentioned in Section 3. I don't balk at the concepts that those MIB proposals have introduced, just the organization. If the existing proposals will change, I would love to see what those changes will be. The document that I recently published tries to encompass what such a structure should look like to ensure that it works with PDUs and generic energy devices. Obviously, my goal is to have a MIB set that works with intelligent PDUs from vendors like Cyber Switching, Raritan, etc. and the current MIBs lack sufficient structure and/or are extremely complex for end users who have to consume the data. All PDUs will send alerts (high current thresholds, low current thresholds, Virtual Circuit Breaker, etc.) for the unit as a whole, individual banks, and individual outlets. So for complex devices like an intelligent PDU, having alerts defined for each component is essential. But more critically, we should not be thinking of a MIB schema in terms of what we need for today's devices, but rather in terms of what we need for tomorrow's. A router today might currently only send 1 alert, but if we define the MIB design in terms of this, you lose the ability to change your router's feature set to break that down further later. The core focus and purpose of this draft is not to nail down every detail described in the requirements document. The point is to setup a core framework that can then be extended through role-specific add-ons for historical state transitions, kWh measurements over time, etc. In short, you can add on an emanControlDeltaUsageTable sparse table to capture the "delta" between any two states and the current state. But it isn't tied specifically to data reporting, control, or the core definition of an entity. The existing proposals are so highly coupled that there exists no flexibility for change in the future without potentially breaking backwards compatibility. Nameplate ratings are often written in terms of a range: 120V/240V 4A/2A. Such a description mapped to the nameplate schema in my draft would be:=20 Maximum voltage =3D 240V Maximum amperage =3D 2A Minimum voltage =3D 120V Minimum amperage =3D 4A The two go together as a set. You are correct in that the "max/min" nomenclature IS confusing, though I don't know of a better way off the top of my head. Any suggestions for what wording might be better to use here? I did consider having "NameplateRating" simply be an SnmpAdminString and just capture things as a string rather than trying to break it down as numbers. To address a common question that I'm hearing, all PDU vendors provide their MIBs for public consumption. Here's a short list: http://www.cyberswitching.com/zip/CYBERSWITCHING-MIBS-v4.2.0.zip http://www.raritan.com/support/dominion-px/1.3.5/MIB/PX131MIB.zip ftp://ftp.servertech.com/pub/SNMP/sentry3/ http://www.apc.com/tools/download/index.cfm (firmware upgrades - mib / register for login) Thanks, Chris -----Original Message----- From: Mouli Chandramouli (moulchan) [mailto:moulchan@cisco.com]=20 Sent: Friday, February 25, 2011 2:37 AM To: Chris Verges; eman@ietf.org Subject: RE: [eman] Draft proposal for consideration at upcoming meeting Hi Chris, Thanks for your email which has infused energy in the email list.=20 I read your draft and I have some comments and questions.=20 Based on the EMAN Charter, there was a requirement that there shall 2 areas of work.=20 3. Energy-aware Networks and Devices MIB document=20 4. Power and Energy Monitoring MIB document=20 Our drafts http://www.ietf.org/id/draft-ietf-eman-energy-aware-mib-00.txt, http://tools.ietf.org/html/draft-claise-energy-monitoring-mib-06 are work items based on the WG charter goals.=20 In summary, your proposed MIB module has concepts from our MIB proposal (pmPowerCategory, pmPowerAccuracy, pmPowerNameplate, pmPowerType, ...).=20 Our new MIB draft that we are working on shall be posted in a few days has a new proposal for PowerStates -=20 There are some new additions in terms of EmanDataAlertEntry and EmanContextEntry and a simplified proposal for PowerStates and a new grouping of LLDP Indices in EmanLldpEntry.=20 EmanDataAlertEntry - Alerts from a power monitoring sense are quite useful at an aggregate level, when there electrical overload, which may cause potential circuit breaks. Since the index is emanEntityIndex is it useful to have alerts for power at an entity level ? Routers have alerts when the heat dissipation exceeds a threshold and the router is shutdown.=20 According to the requirements draft, https://wiki.tools.ietf.org/html/draft-ietf-eman-requirements-00 it was required to keep track of additional statistics - total time spent in each state, power consumption in each state, ....In addition to power consumption, Energy measurement is also another requirement.=20 We are working on a revised MIB draft that shall be posted soon, and that contains a proposal for a modified PowerState modeling of entities. The detailed MIB structure of the PowerQuality MIB module is based on the IEC 61850 standard.=20 Regarding the NamePlate Power consumption we have provided only the Maximum value in Watts. As you have pointed it may be useful provide the Volts and Amperes etc. The reason for the choice of pmPowerNamePlate was, in the absence of actual measurement, atleast we atleast have the worst case power consumption of the device that can be useful for planning purposes. However, not sure of the minimum value of NamePlate from a network management point of view.=20 Thanks Mouli -----Original Message----- From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Chris Verges Sent: Thursday, February 24, 2011 10:42 AM To: eman@ietf.org Subject: [eman] Draft proposal for consideration at upcoming meeting Dear all, The eman mailing list has been silent for several weeks now, and I began to wonder whether the existing proposals were continuing to be developed and changed based on the objections and feedback noted on the mailing list and from the Beijing meeting last year. As an implementer, the current drafts raise some serious concerns about both usability and maintainability going forward. (These concerns are documented in the attached document.) Attached is a new draft for the agenda at the upcoming Prague meeting. This new document aims to combine the best aspects of the existing proposals into a single document and to create a new schema that should be more workable for a wider variety of entities (servers, switches, PDUs, etc.) It was easier to write a new draft than to try and change the original ones. I will be unable to attend Prague in person due to other work commitments, but will attend virtually via the Jabber session. If someone familiar with the working group's proceedings could please let me know what is needed to proceed under these conditions, I would be most appreciative. Thanks, Chris From moulchan@cisco.com Fri Feb 25 08:16:56 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B9B23A69ED for ; Fri, 25 Feb 2011 08:16:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wwb32h7IvMdV for ; Fri, 25 Feb 2011 08:16:54 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 32E643A63D2 for ; Fri, 25 Feb 2011 08:16:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=moulchan@cisco.com; l=9168; q=dns/txt; s=iport; t=1298650667; x=1299860267; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=QaL4+4eXP/FpFUUaFS0F6VP96Ze1KIcixjyMryQ+D3o=; b=KF5KUDggKqzS4DASp0E6mRiQKjPrTTmAsL/8K/Cxkkvt32zm6TLiqJ/A WJLZwUyPsMHKkwMYNdJ+o/FamkmLMazOH+oMyy4KYlaCZvz4D/5wgBhdJ SPZpG07oJIBmZVm3cj2dF6+l9bpBwuTmQle1GGGjZNoF137PKvSVMdRMz w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcBAENlZ02tJV2b/2dsb2JhbACXbI5RdKFOm2yDGQGCRgSFEIpRgwo X-IronPort-AV: E=Sophos;i="4.62,226,1297036800"; d="scan'208";a="219996308" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rtp-iport-1.cisco.com with ESMTP; 25 Feb 2011 16:17:46 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p1PGHk78005262; Fri, 25 Feb 2011 16:17:46 GMT Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 25 Feb 2011 10:17:46 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 25 Feb 2011 10:17:41 -0600 Message-ID: In-Reply-To: <68FBE0F3CE97264395875AC1C468F22CECD798@mail03.cyberswitching.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] Draft proposal for consideration at upcoming meeting Thread-Index: AcvT33ahNQArPQpQQTqqr3Y4tSG4+QA8S2NwAAsEKlAAAfOxsA== References: <68FBE0F3CE97264395875AC1C468F22CECD6D2@mail03.cyberswitching.local> <68FBE0F3CE97264395875AC1C468F22CECD798@mail03.cyberswitching.local> From: "Mouli Chandramouli (moulchan)" To: "Chris Verges" , X-OriginalArrivalTime: 25 Feb 2011 16:17:46.0169 (UTC) FILETIME=[89AFFA90:01CBD507] Subject: Re: [eman] Draft proposal for consideration at upcoming meeting X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 16:16:56 -0000 Hi Chris, Comments in line. =20 Thanks Mouli -----Original Message----- From: Chris Verges [mailto:chrisv@cyberswitching.com]=20 Sent: Friday, February 25, 2011 8:57 PM To: Mouli Chandramouli (moulchan); eman@ietf.org Subject: RE: [eman] Draft proposal for consideration at upcoming meeting Hi Mouli, Thanks for the feedback. I'm not entirely sure what was a comment and what was a question, so I'll address what I can. Please let me know if I missed something. My draft combines charter items #3 and #4 into the same draft document, with #3 being handled by the EMAN-CORE-MIB components and #4 by EMAN-DATA-MIB. =20 YCM> Until the Anaheim IETF meeting, we did have an integrated MIB module.=20 YCM> Based on the EMAN WG Charter, it was decided to make those two MIB modules.=20 YCM> The MIB modules are also designed in such a way monitoring MIB can be used=20 YCM> independent of the energy-aware MIB.=20 Yes, it does share concepts with both the Cisco MIBs (Claise/Parello) and Quittek's MIB, as I mentioned in Section 3. I don't balk at the concepts that those MIB proposals have introduced, just the organization. If the existing proposals will change, I would love to see what those changes will be. The document that I recently published tries to encompass what such a structure should look like to ensure that it works with PDUs and generic energy devices. Obviously, my goal is to have a MIB set that works with intelligent PDUs from vendors like Cyber Switching, Raritan, etc. and the current MIBs lack sufficient structure and/or are extremely complex for end users who have to consume the data. YCM> It would be useful to be specific instead of a generic comment - lack of structure. YCM> There is a lot of detail and those need to be covered. If there are redundant data YCM> it is possible reexamine/reorganize those MIB variables.=20 All PDUs will send alerts (high current thresholds, low current thresholds, Virtual Circuit Breaker, etc.) for the unit as a whole, individual banks, and individual outlets. So for complex devices like an intelligent PDU, having alerts defined for each component is essential. =20 YCM> Yes, I agree. High and low alerts may be useful at a PDU level.=20 YCM> But a box level and the sub-components of a box, it may not be useful to have alerts.=20 But more critically, we should not be thinking of a MIB schema in terms of what we need for today's devices, but rather in terms of what we need for tomorrow's. A router today might currently only send 1 alert, but if we define the MIB design in terms of this, you lose the ability to change your router's feature set to break that down further later. YCM> As you have pointed, it may be possible to have such high and low threshold alerts for network devices, YCM> Right now, one of the goals is to have the basic functionality of standardized power monitoring in network devices.=20 The core focus and purpose of this draft is not to nail down every detail described in the requirements document. The point is to setup a core framework that can then be extended through role-specific add-ons for historical state transitions, kWh measurements over time, etc. =20 YCM> The question is which comes first - requirements - to nail down which problem we are trying to solve.=20 YCM> Then once we agree on the problem scope, the appropriate solution can be provided.=20 YCM> It may be more useful to add those specific areas of monitoring to the requirements. In short, you can add on an emanControlDeltaUsageTable sparse table to capture the "delta" between any two states and the current state. But it isn't tied specifically to data reporting, control, or the core definition of an entity. The existing proposals are so highly coupled that there exists no flexibility for change in the future without potentially breaking backwards compatibility. Nameplate ratings are often written in terms of a range: 120V/240V 4A/2A. Such a description mapped to the nameplate schema in my draft would be:=20 Maximum voltage =3D 240V Maximum amperage =3D 2A Minimum voltage =3D 120V Minimum amperage =3D 4A The two go together as a set. You are correct in that the "max/min" nomenclature IS confusing, though I don't know of a better way off the top of my head. Any suggestions for what wording might be better to use here? I did consider having "NameplateRating" simply be an SnmpAdminString and just capture things as a string rather than trying to break it down as numbers. To address a common question that I'm hearing, all PDU vendors provide their MIBs for public consumption. Here's a short list: http://www.cyberswitching.com/zip/CYBERSWITCHING-MIBS-v4.2.0.zip http://www.raritan.com/support/dominion-px/1.3.5/MIB/PX131MIB.zip ftp://ftp.servertech.com/pub/SNMP/sentry3/ http://www.apc.com/tools/download/index.cfm (firmware upgrades - mib / register for login) YCM> Thanks for the PDU references.=20 Thanks, Chris -----Original Message----- From: Mouli Chandramouli (moulchan) [mailto:moulchan@cisco.com]=20 Sent: Friday, February 25, 2011 2:37 AM To: Chris Verges; eman@ietf.org Subject: RE: [eman] Draft proposal for consideration at upcoming meeting Hi Chris, Thanks for your email which has infused energy in the email list.=20 I read your draft and I have some comments and questions.=20 Based on the EMAN Charter, there was a requirement that there shall 2 areas of work.=20 3. Energy-aware Networks and Devices MIB document=20 4. Power and Energy Monitoring MIB document=20 Our drafts http://www.ietf.org/id/draft-ietf-eman-energy-aware-mib-00.txt, http://tools.ietf.org/html/draft-claise-energy-monitoring-mib-06 are work items based on the WG charter goals.=20 In summary, your proposed MIB module has concepts from our MIB proposal (pmPowerCategory, pmPowerAccuracy, pmPowerNameplate, pmPowerType, ...).=20 Our new MIB draft that we are working on shall be posted in a few days has a new proposal for PowerStates -=20 There are some new additions in terms of EmanDataAlertEntry and EmanContextEntry and a simplified proposal for PowerStates and a new grouping of LLDP Indices in EmanLldpEntry.=20 EmanDataAlertEntry - Alerts from a power monitoring sense are quite useful at an aggregate level, when there electrical overload, which may cause potential circuit breaks. Since the index is emanEntityIndex is it useful to have alerts for power at an entity level ? Routers have alerts when the heat dissipation exceeds a threshold and the router is shutdown.=20 According to the requirements draft, https://wiki.tools.ietf.org/html/draft-ietf-eman-requirements-00 it was required to keep track of additional statistics - total time spent in each state, power consumption in each state, ....In addition to power consumption, Energy measurement is also another requirement.=20 We are working on a revised MIB draft that shall be posted soon, and that contains a proposal for a modified PowerState modeling of entities. The detailed MIB structure of the PowerQuality MIB module is based on the IEC 61850 standard.=20 Regarding the NamePlate Power consumption we have provided only the Maximum value in Watts. As you have pointed it may be useful provide the Volts and Amperes etc. The reason for the choice of pmPowerNamePlate was, in the absence of actual measurement, atleast we atleast have the worst case power consumption of the device that can be useful for planning purposes. However, not sure of the minimum value of NamePlate from a network management point of view.=20 Thanks Mouli -----Original Message----- From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Chris Verges Sent: Thursday, February 24, 2011 10:42 AM To: eman@ietf.org Subject: [eman] Draft proposal for consideration at upcoming meeting Dear all, The eman mailing list has been silent for several weeks now, and I began to wonder whether the existing proposals were continuing to be developed and changed based on the objections and feedback noted on the mailing list and from the Beijing meeting last year. As an implementer, the current drafts raise some serious concerns about both usability and maintainability going forward. (These concerns are documented in the attached document.) Attached is a new draft for the agenda at the upcoming Prague meeting. This new document aims to combine the best aspects of the existing proposals into a single document and to create a new schema that should be more workable for a wider variety of entities (servers, switches, PDUs, etc.) It was easier to write a new draft than to try and change the original ones. I will be unable to attend Prague in person due to other work commitments, but will attend virtually via the Jabber session. If someone familiar with the working group's proceedings could please let me know what is needed to proceed under these conditions, I would be most appreciative. Thanks, Chris From chrisv@cyberswitching.com Sat Feb 26 22:47:11 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B63BA3A690A for ; Sat, 26 Feb 2011 22:47:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.391 X-Spam-Level: X-Spam-Status: No, score=-6.391 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pQaaXR9TvXu8 for ; Sat, 26 Feb 2011 22:47:08 -0800 (PST) Received: from p01c12o148.mxlogic.net (p01c12o148.mxlogic.net [208.65.145.71]) by core3.amsl.com (Postfix) with ESMTP id 0795F3A6907 for ; Sat, 26 Feb 2011 22:47:06 -0800 (PST) Received: from unknown [207.47.28.34] (EHLO mail03.cyberswitching.local) by p01c12o148.mxlogic.net(mxl_mta-6.9.0-1) with ESMTP id 3a3f96d4.0.135009.00-359.191918.p01c12o148.mxlogic.net (envelope-from ); Sat, 26 Feb 2011 23:48:04 -0700 (MST) X-MXL-Hash: 4d69f3a44ba299ac-a50dcbf15a86ae4ba4811295563ccaf7295eb24e Received: from cslinux-build01.localdomain ([10.0.2.250]) by mail03.cyberswitching.local with Microsoft SMTPSVC(6.0.3790.4675); Sat, 26 Feb 2011 22:47:37 -0800 Received: by cslinux-build01.localdomain (Postfix, from userid 1000) id 3234B2F6001; Sat, 26 Feb 2011 22:48:03 -0800 (PST) Date: Sat, 26 Feb 2011 22:48:03 -0800 From: chrisv@cyberswitching.com To: "Mouli Chandramouli (moulchan)" Message-ID: <20110227064702.GA11411@cslinux-build01.cyberswitching.local> References: <68FBE0F3CE97264395875AC1C468F22CECD6D2@mail03.cyberswitching.local> <68FBE0F3CE97264395875AC1C468F22CECD798@mail03.cyberswitching.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-OriginalArrivalTime: 27 Feb 2011 06:47:37.0178 (UTC) FILETIME=[385DB3A0:01CBD64A] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [207.47.28.34] X-AnalysisOut: [v=1.0 c=1 a=A1bLCTiLF8kA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel] X-AnalysisOut: [0A:10 a=1Eql4bHns2NoxN2V9ejGkg==:17 a=wzgqfsuUAAAA:8 a=48v] X-AnalysisOut: [gC7mUAAAA:8 a=sWpmsl2pAAAA:8 a=tx5B84syAAAA:8 a=cwoZddJ_AA] X-AnalysisOut: [AA:8 a=J622mu3NV6qCu75ocmQA:9 a=Ez4CO8Njjpyfv-754vgA:7 a=o] X-AnalysisOut: [gFg1cfDu8ojdJhC5uijAvF4p8gA:4 a=CjuIK1q_8ugA:10 a=yvfu_RGV] X-AnalysisOut: [us0A:10 a=lZB815dzVvQA:10 a=NwjVQZkk2dCJVfPk:21 a=1x9lAEXv] X-AnalysisOut: [w0RLa2xP:21] Cc: eman@ietf.org Subject: Re: [eman] Draft proposal for consideration at upcoming meeting X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Feb 2011 06:47:12 -0000 Hi Mouli, Comments inline, some parts clipped for readability. On Fri, Feb 25, 2011 at 10:17:41AM -0600, Mouli Chandramouli (moulchan) wrote: > Comments in line. > > -----Original Message----- > From: Chris Verges [mailto:chrisv@cyberswitching.com] > Sent: Friday, February 25, 2011 8:57 PM > To: Mouli Chandramouli (moulchan); eman@ietf.org > Subject: RE: [eman] Draft proposal for consideration at upcoming meeting > > My draft combines charter items #3 and #4 into the same draft document, > with #3 being handled by the EMAN-CORE-MIB components and #4 by > EMAN-DATA-MIB. > > YCM> Until the Anaheim IETF meeting, we did have an integrated MIB > YCM> module. Based on the EMAN WG Charter, it was decided to make > YCM> those two MIB modules. The MIB modules are also designed in > YCM> such a way monitoring MIB can be used independent of the > YCM> energy-aware MIB. I'm not quite sure how to respond to this. I interpret this to say that the core group of people who wrote the EMAN WG Charter were the same people who wrote the energy-aware MIB and the power-monitoring MIB, and that they ensured consistency in these three documents. Is that a fair statement? I am very confused at your statement regarding the independence of the two MIBs (energy-aware and energy-monitoring.) The pmIndex OID was defined in energy-aware and referenced in energy-monitoring, so I'm not quite sure how these are independent; it seems more than energy-monitoring is highly dependent on energy-aware. Please feel free to shed light on my misunderstanding. > Yes, it does share concepts with both the Cisco MIBs > (Claise/Parello) and Quittek's MIB, as I mentioned in Section 3. I > don't balk at the concepts that those MIB proposals have introduced, > just the organization. If the existing proposals will change, I would > love to see what those changes will be. The document that I recently > published tries to encompass what such a structure should look like to > ensure that it works with PDUs and generic energy devices. Obviously, > my goal is to have a MIB set that works with intelligent PDUs from > vendors like Cyber Switching, Raritan, etc. and the current MIBs lack > sufficient structure and/or are extremely complex for end users who have > to consume the data. > > YCM> It would be useful to be specific instead of a generic comment - > YCM> lack of structure. Plainly and specifically, ENERGY-AWARE-MIB seems to be a direct dump of Cisco EnergyWise. The pmTable structure closely links the definition of an power entity object with certain decorator properties that aren't critical to the core notion of the entity. Some examples are pmDomainName, pmLldpPortNumber, etc. I felt that I was very specific in Section 3 ("Relationship to Other EMAN Proposals") in the draft that I uploaded. Was there a particular point to that section that you would like to rebut? > YCM> There is a lot of detail and those need to be covered. If there are > YCM> redundant data it is possible reexamine/reorganize those MIB variables. The issue is not one of redundancy, but one of necessity -- or more properly, one of "un-necessity." As I read the energy-aware and power-monitoring drafts, a single question keeps coming up in my mind: "Is this aspect of the proposal really necessary?" First and foremost, I think that a "core" list of entities is required. I think that all three draft proposals share this concept based on certain similarities. In my draft proposal, it's covered by emanEntityTable. This table includes only the properties that are absolutely essential for defining what the entity is. I am proposing the core set of attributes: emanEntityIndex emanEntityName emanEntityAlias emanEntityType emanEntityCapabilities emanEntityParent emanEntityPhysicalId emanEntityLogicalId Any entity, whether a switchport or a server or a PDU outlet, requires these attributes be defined in order to identify the entity uniquely. All other attributes are "decoration." Instantaneous "power" data, control mechanisms, historical "energy" data, domain/keywords/importance (i.e. "context" information) -- these are all highly specific to particular entities. Some entities may offer control mechanisms (ACPI/DMTF power transitions, for example). Others may offer power/energy data (intelligent PDUs, for example.) Some may do both at the same time. My proposal is that these properties be split off into separate sparse tables (at a minimum) or even separate MIB modules that can be defined in piece-meal fashion as the EMAN WG develops a better understanding of the use cases surrounding the individual components. The current proposals are monolithic in their approach, by tightly coupling identifing details with optional decoration. The draft that I uploaded attempts to break this coupling, make it looser, and therefore more flexible for change in the future. At least, that is the goal, and I would welcome insight into how to make it more flexible. > All PDUs will send alerts (high current thresholds, low current > thresholds, Virtual Circuit Breaker, etc.) for the unit as a whole, > individual banks, and individual outlets. So for complex devices like > an intelligent PDU, having alerts defined for each component is > essential. > > YCM> Yes, I agree. High and low alerts may be useful at a PDU level. > YCM> But a box level and the sub-components of a box, it may not be > YCM> useful to have alerts. My proposal allows for the flexibility to selectively choose what features to enable/disable at the level desired. If you only want alerts on the router level, fine. If you need alerts at the outlet level, you can do that, too. More critically, however, your comment has gotten me to wonder whether you are intending to support PDUs in the EMAN standards. Since a PDU's entire function is to help perform "Energy Management," I assumed that PDUs along with servers and switches would be the core targets for the EMAN standards, and so the standards would need to be written in a way that offer the flexibility to address ALL categories. Please let me know if you feel the scope of the EMAN group is different than my understanding, as this would be a core point to address before anything else. > But more critically, we should not be thinking of a MIB > schema in terms of what we need for today's devices, but rather in terms > of what we need for tomorrow's. A router today might currently only > send 1 alert, but if we define the MIB design in terms of this, you lose > the ability to change your router's feature set to break that down > further later. > > YCM> As you have pointed, it may be possible to have such high and low > YCM> threshold alerts for network devices, Right now, one of the goals > YCM> is to have the basic functionality of standardized power monitoring > YCM> in network devices. > > The core focus and purpose of this draft is not to nail down every > detail described in the requirements document. The point is to setup a > core framework that can then be extended through role-specific add-ons > for historical state transitions, kWh measurements over time, etc. > > YCM> The question is which comes first - requirements - to nail down > YCM> which problem we are trying to solve. > YCM> Then once we agree on the problem scope, the appropriate solution > YCM> can be provided. > YCM> It may be more useful to add those specific areas of monitoring to > YCM> the requirements. I agree that nailing down requirements first is required. I would even go so far as to say that requirements will change over time, and that we will miss some "latent" requirements just due to the natural way of things in projects as complex as this. So I urgently believe that the core definition of what it means to be an entity needs to be so detached from all of the "decorations" surrounding it, so that we can address specific points as our understanding further develops. > ...(lines snipped)... > > To address a common question that I'm hearing, all PDU vendors provide > their MIBs for public consumption. Here's a short list: > > http://www.cyberswitching.com/zip/CYBERSWITCHING-MIBS-v4.2.0.zip > > http://www.raritan.com/support/dominion-px/1.3.5/MIB/PX131MIB.zip > > ftp://ftp.servertech.com/pub/SNMP/sentry3/ > > http://www.apc.com/tools/download/index.cfm (firmware upgrades - mib / > register for login) > > YCM> Thanks for the PDU references. Please take a look, as these four companies have been addressing energy management of complex systems for over 50+ years (combined experience.) I think of a PDU as a hierarchical dissection of the following objects, based on the way that power flows through the internal construction: PDU |-- Network/Overhead Logic |-- Input X | |-- Bank Y | | |-- Outlet Z | | `-- ... | `-- ... `-- ... Each node in this hierarchy can have power/energy data, state/control ability, etc. They are all related to each other, too, in the power flow. A server can be broken down similarly: Server |-- Network/Overhead Logic |-- Power Supply X `-- ... A PoE-based switch follows a similar pattern: Switch |-- Network/Overhead Logic |-- Ethernet Port X `-- ... (Each "..." line reflects a repetition of the line/subtree immediately above it.) Given this commonality in structure and objective, it makes sense to address all of these entities in a way that allows us to manage power independently of what type of entity it is. Power is the central concept here, not PDUs or switches or servers. Reflect power, and you will create a model that is universally useful. Thanks, Chris From moulchan@cisco.com Sun Feb 27 09:52:26 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6EC7D3A6A18 for ; Sun, 27 Feb 2011 09:52:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RUo6z6IV1aAu for ; Sun, 27 Feb 2011 09:52:24 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id CADC93A6950 for ; Sun, 27 Feb 2011 09:52:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=moulchan@cisco.com; l=11531; q=dns/txt; s=iport; t=1298829202; x=1300038802; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=oQgNtRIdoaGavrtNUftHuCS67vkqe1vFcgj0Ubx7W2U=; b=Q1XxMtGlv/kAy8fOUzGXknPvHwmcmOurbR6BQgjxUYTHvTSJ6cNn/sDf BpndZzucHBOo1ci9IJ4PfqgBJ1dFYNHa46FNV9IStymfAdZOWe9GZd9Lc HRz5gvkDA/Z6lbCOrwefCIlO5R+QXZy9Tqq0wyNWr40ljGdv6VVfhMxZ7 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvUAAIYeak2tJV2c/2dsb2JhbACXco5SdJ48mkOCdggMDwGCRwSFEIpRgwuGAw X-IronPort-AV: E=Sophos;i="4.62,235,1297036800"; d="scan'208";a="220489431" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rtp-iport-1.cisco.com with ESMTP; 27 Feb 2011 17:53:21 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id p1RHrLZh022833; Sun, 27 Feb 2011 17:53:21 GMT Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 27 Feb 2011 11:53:21 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 27 Feb 2011 11:53:17 -0600 Message-ID: In-Reply-To: <20110227064702.GA11411@cslinux-build01.cyberswitching.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] Draft proposal for consideration at upcoming meeting Thread-Index: AcvWSkmawaNoGxZPRnOujpESjupCBwAWPBGQ References: <68FBE0F3CE97264395875AC1C468F22CECD6D2@mail03.cyberswitching.local> <68FBE0F3CE97264395875AC1C468F22CECD798@mail03.cyberswitching.local> <20110227064702.GA11411@cslinux-build01.cyberswitching.local> From: "Mouli Chandramouli (moulchan)" To: X-OriginalArrivalTime: 27 Feb 2011 17:53:21.0309 (UTC) FILETIME=[38EC64D0:01CBD6A7] Cc: eman@ietf.org Subject: Re: [eman] Draft proposal for consideration at upcoming meeting X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Feb 2011 17:52:26 -0000 Hi Chris,=20 Comments inline.=20 Thanks Mouli -----Original Message----- From: chrisv@cyberswitching.com [mailto:chrisv@cyberswitching.com]=20 Sent: Sunday, February 27, 2011 12:18 PM To: Mouli Chandramouli (moulchan) Cc: eman@ietf.org Subject: Re: [eman] Draft proposal for consideration at upcoming meeting Hi Mouli, Comments inline, some parts clipped for readability. On Fri, Feb 25, 2011 at 10:17:41AM -0600, Mouli Chandramouli (moulchan) wrote: > Comments in line. > > -----Original Message----- > From: Chris Verges [mailto:chrisv@cyberswitching.com] > Sent: Friday, February 25, 2011 8:57 PM > To: Mouli Chandramouli (moulchan); eman@ietf.org > Subject: RE: [eman] Draft proposal for consideration at upcoming meeting > > My draft combines charter items #3 and #4 into the same draft document, > with #3 being handled by the EMAN-CORE-MIB components and #4 by > EMAN-DATA-MIB. > > YCM> Until the Anaheim IETF meeting, we did have an integrated MIB > YCM> module. Based on the EMAN WG Charter, it was decided to make > YCM> those two MIB modules. The MIB modules are also designed in > YCM> such a way monitoring MIB can be used independent of the > YCM> energy-aware MIB. I'm not quite sure how to respond to this. I interpret this to say that the core group of people who wrote the EMAN WG Charter were the same people who wrote the energy-aware MIB and the power-monitoring MIB, and that they ensured consistency in these three documents. Is that a fair statement? YCM>>> No, it is not an accurate statement. As I had mentioned before, it is actually the other way around.=20 YCM>>> Based on the WG Charter, the MIB documents had to be reorganized. The WG charter was formulated and circulated to all for comments.=20 I am very confused at your statement regarding the independence of the two MIBs (energy-aware and energy-monitoring.) The pmIndex OID was defined in energy-aware and referenced in energy-monitoring, so I'm not quite sure how these are independent; it seems more than energy-monitoring is highly dependent on energy-aware. Please feel free to shed light on my misunderstanding. YCM>>> Please stay tuned for the MIB document to be published.=20 > Yes, it does share concepts with both the Cisco MIBs > (Claise/Parello) and Quittek's MIB, as I mentioned in Section 3. I > don't balk at the concepts that those MIB proposals have introduced, > just the organization. If the existing proposals will change, I would > love to see what those changes will be. The document that I recently > published tries to encompass what such a structure should look like to > ensure that it works with PDUs and generic energy devices. Obviously, > my goal is to have a MIB set that works with intelligent PDUs from > vendors like Cyber Switching, Raritan, etc. and the current MIBs lack > sufficient structure and/or are extremely complex for end users who have > to consume the data. > > YCM> It would be useful to be specific instead of a generic comment - > YCM> lack of structure. Plainly and specifically, ENERGY-AWARE-MIB seems to be a direct dump of Cisco EnergyWise. The pmTable structure closely links the definition of an power entity object with certain decorator properties that aren't critical to the core notion of the entity. Some examples are pmDomainName, pmLldpPortNumber, etc. I felt that I was very specific in Section 3 ("Relationship to Other EMAN Proposals") in the draft that I uploaded. Was there a particular point to that section that you would like to rebut? YCM>>> I read your draft which says that pmLldpPortNumber may not be needed for PDUs. > YCM> There is a lot of detail and those need to be covered. If there are > YCM> redundant data it is possible reexamine/reorganize those MIB variables. The issue is not one of redundancy, but one of necessity -- or more properly, one of "un-necessity." As I read the energy-aware and power-monitoring drafts, a single question keeps coming up in my mind: "Is this aspect of the proposal really necessary?" YCM>>>I read your draft which says that pmLldpPortNumber may not be needed for PDUs. Fair point.=20 YCM>>> Beyond that you seem to be questioning the why the 2 drafts are split. Please read comment on WG Charter.=20 First and foremost, I think that a "core" list of entities is required. I think that all three draft proposals share this concept based on certain similarities. In my draft proposal, it's covered by emanEntityTable. This table includes only the properties that are absolutely essential for defining what the entity is. I am proposing the core set of attributes: emanEntityIndex emanEntityName emanEntityAlias emanEntityType emanEntityCapabilities emanEntityParent emanEntityPhysicalId emanEntityLogicalId YCM>>> emanEntityIndex - pmIndex=20 YCM>>> emanEntityName - pmName=20 YCM>>> Most of these attributes you have proposed are already present in the energy-aware MIB except for Entity Capabilities and LogicalId. Any entity, whether a switchport or a server or a PDU outlet, requires these attributes be defined in order to identify the entity uniquely. All other attributes are "decoration." Instantaneous "power" data, control mechanisms, historical "energy" data, domain/keywords/importance (i.e. "context" information) -- these are all highly specific to particular entities. Some entities may offer control mechanisms (ACPI/DMTF power transitions, for example). Others may offer power/energy data (intelligent PDUs, for example.) Some may do both at the same time. My proposal is that these properties be split off into separate sparse tables (at a minimum) or even separate MIB modules that can be defined in piece-meal fashion as the EMAN WG develops a better understanding of the use cases surrounding the individual components. The current proposals are monolithic in their approach, by tightly coupling identifing details with optional decoration. The draft that I uploaded attempts to break this coupling, make it looser, and therefore more flexible for change in the future. At least, that is the goal, and I would welcome insight into how to make it more flexible. YCM>>> I do not follow this terminology - monolithic, decoration .... > All PDUs will send alerts (high current thresholds, low current > thresholds, Virtual Circuit Breaker, etc.) for the unit as a whole, > individual banks, and individual outlets. So for complex devices like > an intelligent PDU, having alerts defined for each component is > essential. > > YCM> Yes, I agree. High and low alerts may be useful at a PDU level. > YCM> But a box level and the sub-components of a box, it may not be > YCM> useful to have alerts. My proposal allows for the flexibility to selectively choose what features to enable/disable at the level desired. If you only want alerts on the router level, fine. If you need alerts at the outlet level, you can do that, too. More critically, however, your comment has gotten me to wonder whether you are intending to support PDUs in the EMAN standards. Since a PDU's entire function is to help perform "Energy Management," I assumed that PDUs along with servers and switches would be the core targets for the EMAN standards, and so the standards would need to be written in a way that offer the flexibility to address ALL categories. Please let me know if you feel the scope of the EMAN group is different than my understanding, as this would be a core point to address before anything else. YCM>>> If a device is energy-aware that would be part of the WG charter I think.=20 YCM>>> I am a contributor with a networking hat and I want to add my 2 cents.=20 > But more critically, we should not be thinking of a MIB > schema in terms of what we need for today's devices, but rather in terms > of what we need for tomorrow's. A router today might currently only > send 1 alert, but if we define the MIB design in terms of this, you lose > the ability to change your router's feature set to break that down > further later. > > YCM> As you have pointed, it may be possible to have such high and low > YCM> threshold alerts for network devices, Right now, one of the goals > YCM> is to have the basic functionality of standardized power monitoring > YCM> in network devices. > > The core focus and purpose of this draft is not to nail down every > detail described in the requirements document. The point is to setup a > core framework that can then be extended through role-specific add-ons > for historical state transitions, kWh measurements over time, etc. > > YCM> The question is which comes first - requirements - to nail down > YCM> which problem we are trying to solve. > YCM> Then once we agree on the problem scope, the appropriate solution > YCM> can be provided. > YCM> It may be more useful to add those specific areas of monitoring to > YCM> the requirements. I agree that nailing down requirements first is required. I would even go so far as to say that requirements will change over time, and that we will miss some "latent" requirements just due to the natural way of things in projects as complex as this. So I urgently believe that the core definition of what it means to be an entity needs to be so detached from all of the "decorations" surrounding it, so that we can address specific points as our understanding further develops. YCM>>> In a sense, from your MIB, it is possible to infer some additional requirements from the PDU point of view.=20 YCM>>> We shall discuss those at the WG meeting.=20 > ...(lines snipped)... > > To address a common question that I'm hearing, all PDU vendors provide > their MIBs for public consumption. Here's a short list: > > http://www.cyberswitching.com/zip/CYBERSWITCHING-MIBS-v4.2.0.zip > > http://www.raritan.com/support/dominion-px/1.3.5/MIB/PX131MIB.zip > > ftp://ftp.servertech.com/pub/SNMP/sentry3/ > > http://www.apc.com/tools/download/index.cfm (firmware upgrades - mib / > register for login) > > YCM> Thanks for the PDU references. Please take a look, as these four companies have been addressing energy management of complex systems for over 50+ years (combined experience.) I think of a PDU as a hierarchical dissection of the following objects, based on the way that power flows through the internal construction: PDU |-- Network/Overhead Logic |-- Input X | |-- Bank Y | | |-- Outlet Z | | `-- ... | `-- ... `-- ... Each node in this hierarchy can have power/energy data, state/control ability, etc. They are all related to each other, too, in the power flow. A server can be broken down similarly: Server |-- Network/Overhead Logic |-- Power Supply X `-- ... A PoE-based switch follows a similar pattern: Switch |-- Network/Overhead Logic |-- Ethernet Port X `-- ... (Each "..." line reflects a repetition of the line/subtree immediately above it.) Given this commonality in structure and objective, it makes sense to address all of these entities in a way that allows us to manage power independently of what type of entity it is. Power is the central concept here, not PDUs or switches or servers. Reflect power, and you will create a model that is universally useful. Thanks, Chris From chrisv@cyberswitching.com Sun Feb 27 12:40:09 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DEDB3A67D2 for ; Sun, 27 Feb 2011 12:40:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.46 X-Spam-Level: X-Spam-Status: No, score=-6.46 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p44XCbInlq7O for ; Sun, 27 Feb 2011 12:40:05 -0800 (PST) Received: from p01c12o144.mxlogic.net (p01c12o144.mxlogic.net [208.65.145.67]) by core3.amsl.com (Postfix) with ESMTP id E8E2D3A67B0 for ; Sun, 27 Feb 2011 12:40:04 -0800 (PST) Received: from unknown [207.47.28.34] (EHLO mail03.cyberswitching.local) by p01c12o144.mxlogic.net(mxl_mta-6.9.0-1) with ESMTP id fd6ba6d4.0.166642.00-388.213488.p01c12o144.mxlogic.net (envelope-from ); Sun, 27 Feb 2011 13:41:03 -0700 (MST) X-MXL-Hash: 4d6ab6df1c40264b-15f116f9534773a6e93561117cfd8335b7e41bb5 Received: from cslinux-build01.localdomain ([10.0.2.250]) by mail03.cyberswitching.local with Microsoft SMTPSVC(6.0.3790.4675); Sun, 27 Feb 2011 12:40:31 -0800 Received: by cslinux-build01.localdomain (Postfix, from userid 1000) id CAB722F6001; Sun, 27 Feb 2011 12:41:02 -0800 (PST) Date: Sun, 27 Feb 2011 12:41:02 -0800 From: chrisv@cyberswitching.com To: "Mouli Chandramouli (moulchan)" Message-ID: <20110227204051.GA25373@cslinux-build01.cyberswitching.local> References: <68FBE0F3CE97264395875AC1C468F22CECD6D2@mail03.cyberswitching.local> <68FBE0F3CE97264395875AC1C468F22CECD798@mail03.cyberswitching.local> <20110227064702.GA11411@cslinux-build01.cyberswitching.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-OriginalArrivalTime: 27 Feb 2011 20:40:31.0576 (UTC) FILETIME=[936DAD80:01CBD6BE] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [207.47.28.34] X-AnalysisOut: [v=1.0 c=1 a=A1bLCTiLF8kA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel] X-AnalysisOut: [0A:10 a=1Eql4bHns2NoxN2V9ejGkg==:17 a=8pif782wAAAA:8 a=JJP] X-AnalysisOut: [MC6x9idP6q5EYLtoA:9 a=Npeuf_pxC1S1uGMtB5oA:7 a=YUNigd_zdcg] X-AnalysisOut: [wbNR4DGFfpzPiTWIA:4 a=CjuIK1q_8ugA:10 a=BNuzWudny77NnbQ8:2] X-AnalysisOut: [1 a=QAhXtqBMRaJQ0yAy:21] Cc: eman@ietf.org Subject: Re: [eman] Draft proposal for consideration at upcoming meeting X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Feb 2011 20:40:09 -0000 On Sun, Feb 27, 2011 at 11:53:17AM -0600, Mouli Chandramouli (moulchan) wrote: > I am very confused at your statement regarding the independence of the > two MIBs (energy-aware and energy-monitoring.) The pmIndex OID was > defined in energy-aware and referenced in energy-monitoring, so I'm not > quite sure how these are independent; it seems more than > energy-monitoring is highly dependent on energy-aware. Please feel free > to shed light on my misunderstanding. > > YCM>>> Please stay tuned for the MIB document to be published. While I will certainly review any updates to the existing drafts, I invite feedback regarding the draft that I have already published as it relates to the proposed changes that you are integrating into your draft update. When Parello published his drafts, he requested that we review them. I did, and gave criticism similar to what I've been describing here. We met for dinner, and I again shared my concerns. When it looked like nothing had been done for nearly 3 months to address them, I published a draft to force these issues to be addressed. My draft specifically highlights the concerns and proposes a solution. I'm tired of "staying tuned" for you guys to implement these changes and propose a second rev. When you actually do publish it, I'm happy to review, as I've done for all of the drafts published so far. I ask that you give me the same courtesy and professionalism and return the favor. How, specifically, is my draft different than what you will be proposing? How do you feel it needs to be changed to bring it in-line with your ideal MIB schema? > Plainly and specifically, ENERGY-AWARE-MIB seems to be a direct dump of > Cisco EnergyWise. The pmTable structure closely links the definition of > an power entity object with certain decorator properties that aren't > critical to the core notion of the entity. Some examples are > pmDomainName, pmLldpPortNumber, etc. I felt that I was very specific in > Section 3 ("Relationship to Other EMAN Proposals") in the draft that I > uploaded. Was there a particular point to that section that you would > like to rebut? > > YCM>>> I read your draft which says that pmLldpPortNumber may not be > needed for PDUs. Is this a point with which you disagree or simply a statement? > The issue is not one of redundancy, but one of necessity -- or more > properly, one of "un-necessity." As I read the energy-aware and > power-monitoring drafts, a single question keeps coming up in my mind: > "Is this aspect of the proposal really necessary?" > > YCM>>>I read your draft which says that pmLldpPortNumber may not be > needed for PDUs. Fair point. > YCM>>> Beyond that you seem to be questioning the why the 2 drafts are > split. Please read comment on WG Charter. There seems to be a miscommunication, then. I'm not arguing why there are two drafts. I'm arguing that the internal MIB structuring described in those two drafts isn't ideal. I'll comment on the MIB structure defined in the Charter: it put the cart before the horse. To think that all devices could be covered by three MIBs -- energy-aware, power-monitoring, and battery -- is presumptuous. Not only is this organization unflexible, but it doesn't reflect an adequate focus on the needs of intelligent PDUs, Smart Grid equipment, or other non-server/switch equipment. Be open to the notion that the Charter may need to change, or else you're solving the wrong problem. > First and foremost, I think that a "core" list of entities is required. > I think that all three draft proposals share this concept based on > certain similarities. In my draft proposal, it's covered by > emanEntityTable. This table includes only the properties that are > absolutely essential for defining what the entity is. I am proposing > the core set of attributes: > > emanEntityIndex > emanEntityName > emanEntityAlias > emanEntityType > emanEntityCapabilities > emanEntityParent > emanEntityPhysicalId > emanEntityLogicalId > > YCM>>> emanEntityIndex - pmIndex > YCM>>> emanEntityName - pmName > YCM>>> Most of these attributes you have proposed are already present > in the energy-aware MIB except for Entity Capabilities and LogicalId. My point is that the energy-aware MIB contains MORE than just this, and it shouldn't. The features supported by energy-aware need to be pared down to a more core subset, as I've done in my draft proposal. > Any entity, whether a switchport or a server or a PDU outlet, requires > these attributes be defined in order to identify the entity uniquely. > > All other attributes are "decoration." Instantaneous "power" data, > control mechanisms, historical "energy" data, domain/keywords/importance > (i.e. "context" information) -- these are all highly specific to > particular entities. Some entities may offer control mechanisms > (ACPI/DMTF power transitions, for example). Others may offer > power/energy data (intelligent PDUs, for example.) Some may do both at > the same time. My proposal is that these properties be split off into > separate sparse tables (at a minimum) or even separate MIB modules that > can be defined in piece-meal fashion as the EMAN WG develops a better > understanding of the use cases surrounding the individual components. > > The current proposals are monolithic in their approach, by tightly > coupling identifing details with optional decoration. The draft that I > uploaded attempts to break this coupling, make it looser, and therefore > more flexible for change in the future. At least, that is the goal, and > I would welcome insight into how to make it more flexible. > > YCM>>> I do not follow this terminology - monolithic, decoration .... monolithic - http://en.wikipedia.org/wiki/Monolithic_system A software system is called "monolithic" if it has a monolithic architecture, in which functionally distinguishable aspects (for example data input and output, data processing, error handling, and the user interface), are not architecturally separate components but are all interwoven. decorator - http://en.wikipedia.org/wiki/Decorator_pattern In object-oriented programming, the decorator pattern is a design pattern that allows new/additional behaviour to be added to an existing object dynamically. The decorator pattern can be used to make it possible to extend (decorate) the functionality of a certain object at runtime, independently of other instances of the same class, provided some groundwork is done at design time. coupling - http://en.wikipedia.org/wiki/Coupling_%28computer_programming%29 In computer science, coupling or dependency is the degree to which each program module relies on each one of the other modules. Coupling is usually contrasted with cohesion. Low coupling often correlates with high cohesion, and vice versa. The software quality metrics of coupling and cohesion were invented by Larry Constantine, an original developer of Structured Design[1] who was also an early proponent of these concepts (see also SSADM). Low coupling is often a sign of a well-structured computer system and a good design, and when combined with high cohesion, supports the general goals of high readability and maintainability. Tightly coupled systems tend to exhibit the following developmental characteristics, which are often seen as disadvantages: 1. A change in one module usually forces a ripple effect of changes in other modules. 2. Assembly of modules might require more effort and/or time due to the increased inter-module dependency. 3. A particular module might be harder to reuse and/or test because dependent modules must be included. cohesion - http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 In computer programming, cohesion is a measure of how strongly-related the functionality expressed by the source code of a software module is. Methods of measuring cohesion vary from qualitative measures classifying the source text being analyzed using a rubric with a hermeneutics approach to quantitative measures which examine textual characteristics of the source code to arrive at a numerical cohesion score. Cohesion is an ordinal type of measurement and is usually expressed as "high cohesion" or "low cohesion" when being discussed. Modules with high cohesion tend to be preferable because high cohesion is associated with several desirable traits of software including robustness, reliability, reusability, and understandability whereas low cohesion is associated with undesirable traits such as being difficult to maintain, difficult to test, difficult to reuse, and even difficult to understand. Cohesion is often contrasted with coupling, a different concept. Nonetheless high cohesion often correlates with loose coupling, and vice versa. The software quality metrics of coupling and cohesion were invented by Larry Constantine [1] based on characteristics of "good" programming practices that reduced maintenance and modification costs. Typically, monolithic systems tend to be highly coupled, which makes for horrible maintenance cycles. A single change might ripple through the entire system, causing incremental changes in seemingly disparate subsystems. I highly recommend "Design Patterns" by Gamma, Helm, Johnson, and Vlissides (the Gang of Four) and "Patterns of Enterprise Application Architecture" by Fowler. The basic pattern that I'm following: +-------------+ +-----------+ | PowerObject | | Decorator | +-------------+ +-----------+ | |<>--------| | +-------------+ +-----------+ | | | | +-------------+ +-----------+ Replace "Decorator" with "PowerData", "AcpiControl", "DmtfPowerStateControl", "PercentageControl", "LldpInfo", "EnergyWiseContext", etc. The point is to say that such add-on feature sets should be sparse table extensions, not integrated into the core entity table. > More critically, however, your comment has gotten me to wonder whether > you are intending to support PDUs in the EMAN standards. Since a PDU's > entire function is to help perform "Energy Management," I assumed that > PDUs along with servers and switches would be the core targets for the > EMAN standards, and so the standards would need to be written in a way > that offer the flexibility to address ALL categories. Please let me > know if you feel the scope of the EMAN group is different than my > understanding, as this would be a core point to address before anything > else. > > YCM>>> If a device is energy-aware that would be part of the WG charter > YCM>>> I think. > YCM>>> I am a contributor with a networking hat and I want to add my 2 > YCM>>> cents. This is a good start to being on the same page, then. If we all agree that the deliverables from the EMAN WG are to support energy management for all networked devices that consume, meter, and control electricity, then we've established a commitment to ensuring flexibility in the design to cover not only the use cases that we think of today but also the ones that could arise in the future. > YCM>>> In a sense, from your MIB, it is possible to infer some > YCM>>> additional requirements from the PDU point of view. > YCM>>> We shall discuss those at the WG meeting. Let's discuss them _before_ the WG meeting. Given that I won't be present at the meeting, no reason we can't dive into it electronically. Thanks, Chris From Quittek@neclab.eu Mon Feb 28 01:00:47 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7B933A6AE6 for ; Mon, 28 Feb 2011 01:00:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w50+Psyf6pHT for ; Mon, 28 Feb 2011 01:00:47 -0800 (PST) Received: from smtp0.netlab.nec.de (smtp0.netlab.nec.de [195.37.70.40]) by core3.amsl.com (Postfix) with ESMTP id EBEF83A6AE2 for ; Mon, 28 Feb 2011 01:00:46 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 48D4C28000189 for ; Mon, 28 Feb 2011 10:03:02 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office.hd) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gN2O9RE0wMZ0 for ; Mon, 28 Feb 2011 10:03:02 +0100 (CET) Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 2C08D2800017B for ; Mon, 28 Feb 2011 10:02:57 +0100 (CET) Received: from DAPHNIS.office.hd ([169.254.2.136]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0270.001; Mon, 28 Feb 2011 10:01:40 +0100 From: Juergen Quittek To: eman mailing list Thread-Topic: New Version Notification for draft-quittek-eman-reference-model-01 Thread-Index: AQHL1yYc/Ie75MWblEuVn9Y92YuqXw== Date: Mon, 28 Feb 2011 09:01:39 +0000 Message-ID: In-Reply-To: <20110228082402.2D4543A692A@core3.amsl.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 x-originating-ip: [10.7.0.92] Content-Type: text/plain; charset="us-ascii" Content-ID: <8F37C985CA4FA043BD70F3D62A6729CD@office.hd> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [eman] FW: New Version Notification for draft-quittek-eman-reference-model-01 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 09:00:47 -0000 Dear all, I just posted an update of the draft on the EMAN reference model. Please find it at http://tools.ietf.org/html/draft-quittek-eman-reference-model-01 Bruce joined as an author and improved it a lot. The idea for this work is getting a better understanding of what we what we are working on in the EMAN WG by clearly defining the components of energy management and their interactions. It is still work in progress. Your input is highly appreciated. There is a list of open issues at the end of the draft, but certainly there are more issues to be pointed at. Please have a look at it and send us your comments. Thanks, Juergen Am 28.02.11 09:24 schrieb "IETF I-D Submission Tool" unter : > >A new version of I-D, draft-quittek-eman-reference-model-01.txt has been >successfully submitted by Juergen Quittek and posted to the IETF >repository. > >Filename: draft-quittek-eman-reference-model >Revision: 01 >Title: Reference Model for Energy Management >Creation_date: 2011-02-28 >WG ID: Independent Submission >Number_of_pages: 31 > >Abstract: >This memo discusses suggest a reference model for energy consumption >monitoring and control. It defines entities involved in energy >management, their roles, and relationships among them. Considered >entities include powered devices, power monitors, and power >controllers, and energy management systems. > =20 > =20 > > >The IETF Secretariat. > > From Quittek@neclab.eu Mon Feb 28 04:06:33 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC50A3A69C1 for ; Mon, 28 Feb 2011 04:06:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zh2Bm72JLL8N for ; Mon, 28 Feb 2011 04:06:32 -0800 (PST) Received: from smtp0.netlab.nec.de (smtp0.netlab.nec.de [195.37.70.40]) by core3.amsl.com (Postfix) with ESMTP id 8C69F3A684F for ; Mon, 28 Feb 2011 04:06:32 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id E1AE128000189 for ; Mon, 28 Feb 2011 13:08:48 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office.hd) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pRWyr2eojc77 for ; Mon, 28 Feb 2011 13:08:48 +0100 (CET) Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by smtp0.netlab.nec.de (Postfix) with ESMTP id C18682800017B for ; Mon, 28 Feb 2011 13:08:43 +0100 (CET) Received: from DAPHNIS.office.hd ([169.254.2.136]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0270.001; Mon, 28 Feb 2011 13:07:27 +0100 From: Juergen Quittek To: eman mailing list Thread-Topic: modeling power states Thread-Index: AQHL10AQEO6KgxJClUmx3jb0i6rbxw== Date: Mon, 28 Feb 2011 12:07:26 +0000 Message-ID: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 x-originating-ip: [10.1.2.219] Content-Type: text/plain; charset="us-ascii" Content-ID: <9423F1DB5BE2814F829C70B05B5D93CD@office.hd> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [eman] modeling power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 12:06:34 -0000 Dear all, We have two proposals for a Power/Energy MIB module: - draft-claise-energy-monitoring-mib-06 - draft-quittek-power-mib-02 Among the authors of both documents we are currently trying to merge them. But there are some open issues that should be discussed on the mailing list. Here is the probably biggest of them: modeling power states. For simplifying energy management we want to introduce the concept of power states (aka power levels). A power state will indicate roughly how much power a device consumes. Examples for simple power states are off, sleep, and operational states. In the envisioned EMAN MIB modules, a power state is characterized by a descriptive name and the device's expected power input in this state (max/min/average). Power states are not a new concept. The DMTF has already defined a set of power states and there is the Other standards bodies as the DMTF (Distributed Management Task Force) and there is the ACPI (Advanced Configuration and Power Interface) for PC motherboards. And there may be more than these out there. I listed some DMTF and ACPI states at the end of this message. An easy solution for EMAN would be just adopting one of these sets. However, there are issues with the ones we looked at. ACPI was developed for PC motherboards and is quite PC-centric. Also it defines states that seem to be superfluous, because so far, almost no one has implemented them. Also the DMTF model seems to have a narrower scope than envisioned by the EMAN WG. At some point in time, the EMAN WG hast to make a decision, which power state model to adopt. Here is a set of alternatives. The first four have fixed sets of power states. Option 1: fixed minimum Just support three power states (off, sleep (stand-by), operational) This has clear semantics, but there are several people claiming it's too restrictive. Option 2: fixed DMTF Just use the states defined by DMTF. Might be too much focussed n PCs. Option 3: fixed ACPI Just use the states defined by ACPI. Might be too much focussed n PCs. Option 4: fixed EMAN Define a new fixed set of power levels within the EMAN WG. Option 5: IANA-registered power states Have power states be registered at IANA. We would start with registering (off, sleep, operational, the DMTF set, and the ACPI set. Manufacturers can then register further ones. =20 There has been discussions pointing out that these fixed sets may not be sufficient, particularly if non-IT equipment should also be covered. For being more open, the idea to support user-defined or manufacturer-defined power states of devices has been developed. In such a state, for example, certain components of a device may be switched off or put to sleep. Which ones are switched off in which state is to be defined by the user/operator/manufacturer and may be chosen such that operational needs are met. Again, there are several proposals how to do this. All of them favor a two-level approach that distinguishes between rather flexible functional power states and rather fixed basic power states. Functional power states would be defined by the manufacturer, operator, or user. These would be the power states that would be reported by a device. However, in order to better define the semantics of functional power states, Each of these would be mapped to exactly one basic power states. This means that a property of any functional state would be the basic state it maps to. Basic power states would be fixed, such as the ones used in options 1-5. An easy example would be functional power states defined by user/operator/manufacturer with each state indicating whether it is an off state, a sleep state or an operational state. Here are the corresponding options: Option 6: flexible functional states mapped to a fixed set of basic states States could be defined flexibly. But each state would indicate a basic state to which it corresponds. Basic states could be either basic (off/sleep/operational) or the DMTF set or the ACPI set Option 7: flexible functional states mapped to a IANA registered set of basic states This is like Option 6, but basic states would be registered at IANA and can be extended. We would register all DMTF and ACPI states and probably some more at IANA. Manufacturers could add more. Option 8: IANA-registered sets of functional states, only three basic states The main reasoning behind this option is that is should always be clear whether a power state is an off state, a sleep state, or an operational state. Therefore, only these three basic states are supported. This would be in line with an instance of Option 6. However, this option has an extension for the functional states. It suggests that for customizing devices in order to be compliant with given management systems, for example a DMTF-based system, it should be possible to restrict functional power states to a given set that is registered at IANA. An example would be the DMTF states. We would register a flag at IANA that indicates we are using DMTF states only. This would signal the management application that all power state IDs are in line with power state numbering as defined by IANA. Analogously, ACPI and further sets could be registered at IANA. A fallback to Option 6 could be realized by registering a set number of 0 at IANA that does not impose any limit for functional states. Obviously, there are more possible options. If you think there is a better one, please send it to this list. I know this discussion is not easy, but we have to have it in order to make the right decision in the EMAN WG. Please take some time and think about what you consider to be the best way to go. And of course send questions on the issue. Thanks. Juergen DMTF (Distributed Management Task Force) power states: - 2 (Power On) - 3 (Sleep - Light) - 4 (Sleep - Deep) - 5 (Power Cycle (Off Soft)) - 6 (Power Off - Hard) - 7 (Hibernate) - 8 (Power Off - Soft) - 9 (Power Cycle (Off Hard)) - 10 (Master Bus Reset) - 11 (Diagnostic Interrupt (NMI)) - 12 (Power Off - Soft Graceful) - 13 (Power Off - Hard Graceful) - 14 (Master Bus Reset Graceful) - 15 (Power Cycle (Off - Soft Graceful)) - 16 (Power Cycle (Off - Hard Graceful)) ACPI (Advanced Configuration and Power Interface Specification) power states for PC motherboards: - G3-S5 (Off-Hard) - G2-S5 (Off-Soft) - G1-S4 (Hibernate) - G1-S3 (Sleep-Deep) - G1-S2 (Sleep-Light) - G1-S1 (Sleep-Light) - G0-S0-P5 - G0-S0-P4 - G0-S0-P3 - G0-S0-P2 - G0-S0-P2 - G0-S0-P2 From jparello@cisco.com Mon Feb 28 09:22:47 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15E0D3A69FC for ; Mon, 28 Feb 2011 09:22:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LWZMzSDLHVqM for ; Mon, 28 Feb 2011 09:22:45 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 06E973A6957 for ; Mon, 28 Feb 2011 09:22:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jparello@cisco.com; l=9198; q=dns/txt; s=iport; t=1298913826; x=1300123426; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=PHtGzJ0uybG55GrbHFMxSSNKVU//5ULFxJ1X6OJkL1s=; b=VcZj2aFFKMNG/VTRqD/rwpU83kuERvdX11+oPdidtHidnmWtykhdxORe XcUClza5qzKT7wyM2uDNsXdXR6VQKEafJpUvp6gB43TNOOA+9T8L0MCjX exZ2nGJWHxjMwaWXp2QMCxgCRu0Jmnhm8m7tmoJuv2MWMNYC4zLuxFelp 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvEAAMRoa02rR7Ht/2dsb2JhbACXc45UdKECmzmFYQSFD4pR X-IronPort-AV: E=Sophos;i="4.62,241,1297036800"; d="scan'208";a="411258386" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 28 Feb 2011 17:23:45 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p1SHNj1t012772; Mon, 28 Feb 2011 17:23:45 GMT Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 28 Feb 2011 09:23:45 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 28 Feb 2011 09:22:44 -0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] modeling power states Thread-Index: AQHL10AQEO6KgxJClUmx3jb0i6rbx5QXI7jw References: From: "John Parello (jparello)" To: "Juergen Quittek" , "eman mailing list" X-OriginalArrivalTime: 28 Feb 2011 17:23:45.0679 (UTC) FILETIME=[40FA81F0:01CBD76C] Subject: Re: [eman] modeling power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 17:22:47 -0000 Thanks Juergen for summarizing this.=20 I think the stall we've seen on the proposals is directly related to not converging on an agreement for power states and parent child aggregation. We've asked this question on the list before with no dialogue and our conversations have come down to two differences The proposal submitted, by verges, quittek, parello, claise are very similar. The similarities are in data elements and only vary by partitioning (ie class). The only differences exist in two items 1) Power states / Interfaces 2) Parent Child relationship (or aggregator as specified in references) IMO any work in EMAN must contain the addition of an IETF power interface as described in claise architecture (or some compromise as you listed with IANA interfaces). It must also contain the addition of parent/child/aggregator relationship for non SNMP energy management. Without those two additions the work in this group can easily be covered by two additions to existing SNMP objects. First would be adding energy related fields (watts units or Kwh) to the sensor mib. The seconds would be to add better the context information (see energy aware proposal) to the entity mib. A simple on/off/standby state already exists in oper status. So in short without an IETF EMAN set of power states / interfaces to unify or map to the states from other orgs as you listed, *and* the ability to monitor/aggregate non SNMP devices - the work here can easily be absorbed into the sensor and entity mibs with minor additions. The experience I've personally had with energy management and running code with exactly these additions has shown that manufacturers can build sophisticated energy management systems and devices for many different network connected devices with a converged set of states and the parent child relationship.=20 Having run a program which adds these features I'm strongly in favor of a solution that has a unified power interface and the concept of a parent / child to allow for non-snmp management of power. Jp =20 -----Original Message----- From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Juergen Quittek Sent: Monday, February 28, 2011 4:07 AM To: eman mailing list Subject: [eman] modeling power states Dear all, We have two proposals for a Power/Energy MIB module: - draft-claise-energy-monitoring-mib-06 - draft-quittek-power-mib-02 Among the authors of both documents we are currently trying to merge them. But there are some open issues that should be discussed on the mailing list. Here is the probably biggest of them: modeling power states. For simplifying energy management we want to introduce the concept of power states (aka power levels). A power state will indicate roughly how much power a device consumes. Examples for simple power states are off, sleep, and operational states. In the envisioned EMAN MIB modules, a power state is characterized by a descriptive name and the device's expected power input in this state (max/min/average). Power states are not a new concept. The DMTF has already defined a set of power states and there is the Other standards bodies as the DMTF (Distributed Management Task Force) and there is the ACPI (Advanced Configuration and Power Interface) for PC motherboards. And there may be more than these out there. I listed some DMTF and ACPI states at the end of this message. An easy solution for EMAN would be just adopting one of these sets. However, there are issues with the ones we looked at. ACPI was developed for PC motherboards and is quite PC-centric. Also it defines states that seem to be superfluous, because so far, almost no one has implemented them. Also the DMTF model seems to have a narrower scope than envisioned by the EMAN WG. At some point in time, the EMAN WG hast to make a decision, which power state model to adopt. Here is a set of alternatives. The first four have fixed sets of power states. Option 1: fixed minimum Just support three power states (off, sleep (stand-by), operational) This has clear semantics, but there are several people claiming it's too restrictive. Option 2: fixed DMTF Just use the states defined by DMTF. Might be too much focussed n PCs. Option 3: fixed ACPI Just use the states defined by ACPI. Might be too much focussed n PCs. Option 4: fixed EMAN Define a new fixed set of power levels within the EMAN WG. Option 5: IANA-registered power states Have power states be registered at IANA. We would start with registering (off, sleep, operational, the DMTF set, and the ACPI set. Manufacturers can then register further ones. =20 There has been discussions pointing out that these fixed sets may not be sufficient, particularly if non-IT equipment should also be covered. For being more open, the idea to support user-defined or manufacturer-defined power states of devices has been developed. In such a state, for example, certain components of a device may be switched off or put to sleep. Which ones are switched off in which state is to be defined by the user/operator/manufacturer and may be chosen such that operational needs are met. Again, there are several proposals how to do this. All of them favor a two-level approach that distinguishes between rather flexible functional power states and rather fixed basic power states. Functional power states would be defined by the manufacturer, operator, or user. These would be the power states that would be reported by a device. However, in order to better define the semantics of functional power states, Each of these would be mapped to exactly one basic power states. This means that a property of any functional state would be the basic state it maps to. Basic power states would be fixed, such as the ones used in options 1-5. An easy example would be functional power states defined by user/operator/manufacturer with each state indicating whether it is an off state, a sleep state or an operational state. Here are the corresponding options: Option 6: flexible functional states mapped to a fixed set of basic states States could be defined flexibly. But each state would indicate a basic state to which it corresponds. Basic states could be either basic (off/sleep/operational) or the DMTF set or the ACPI set Option 7: flexible functional states mapped to a IANA registered set of basic states This is like Option 6, but basic states would be registered at IANA and can be extended. We would register all DMTF and ACPI states and probably some more at IANA. Manufacturers could add more. Option 8: IANA-registered sets of functional states, only three basic states The main reasoning behind this option is that is should always be clear whether a power state is an off state, a sleep state, or an operational state. Therefore, only these three basic states are supported. This would be in line with an instance of Option 6. However, this option has an extension for the functional states. It suggests that for customizing devices in order to be compliant with given management systems, for example a DMTF-based system, it should be possible to restrict functional power states to a given set that is registered at IANA. An example would be the DMTF states. We would register a flag at IANA that indicates we are using DMTF states only. This would signal the management application that all power state IDs are in line with power state numbering as defined by IANA. Analogously, ACPI and further sets could be registered at IANA. A fallback to Option 6 could be realized by registering a set number of 0 at IANA that does not impose any limit for functional states. Obviously, there are more possible options. If you think there is a better one, please send it to this list. I know this discussion is not easy, but we have to have it in order to make the right decision in the EMAN WG. Please take some time and think about what you consider to be the best way to go. And of course send questions on the issue. Thanks. Juergen DMTF (Distributed Management Task Force) power states: - 2 (Power On) - 3 (Sleep - Light) - 4 (Sleep - Deep) - 5 (Power Cycle (Off Soft)) - 6 (Power Off - Hard) - 7 (Hibernate) - 8 (Power Off - Soft) - 9 (Power Cycle (Off Hard)) - 10 (Master Bus Reset) - 11 (Diagnostic Interrupt (NMI)) - 12 (Power Off - Soft Graceful) - 13 (Power Off - Hard Graceful) - 14 (Master Bus Reset Graceful) - 15 (Power Cycle (Off - Soft Graceful)) - 16 (Power Cycle (Off - Hard Graceful)) ACPI (Advanced Configuration and Power Interface Specification) power states for PC motherboards: - G3-S5 (Off-Hard) - G2-S5 (Off-Soft) - G1-S4 (Hibernate) - G1-S3 (Sleep-Deep) - G1-S2 (Sleep-Light) - G1-S1 (Sleep-Light) - G0-S0-P5 - G0-S0-P4 - G0-S0-P3 - G0-S0-P2 - G0-S0-P2 - G0-S0-P2 _______________________________________________ eman mailing list eman@ietf.org https://www.ietf.org/mailman/listinfo/eman From Quittek@neclab.eu Mon Feb 28 12:55:32 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 389E53A6CA4 for ; Mon, 28 Feb 2011 12:55:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m26ZAYwj00Sr for ; Mon, 28 Feb 2011 12:55:31 -0800 (PST) Received: from smtp0.netlab.nec.de (smtp0.netlab.nec.de [195.37.70.40]) by core3.amsl.com (Postfix) with ESMTP id 666893A6C58 for ; Mon, 28 Feb 2011 12:55:31 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id BA44F28000190 for ; Mon, 28 Feb 2011 21:57:48 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office.hd) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RIlWLVFwjdsm for ; Mon, 28 Feb 2011 21:57:48 +0100 (CET) Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 9F6342800017B for ; Mon, 28 Feb 2011 21:57:43 +0100 (CET) Received: from DAPHNIS.office.hd ([169.254.2.136]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0270.001; Mon, 28 Feb 2011 21:56:27 +0100 From: Juergen Quittek To: eman mailing list Thread-Topic: New Version Notification for draft-quittek-eman-battery-mib-00 Thread-Index: AQHL12NnbDj14PR1r06mkxa4uPya/JQXZQaA Date: Mon, 28 Feb 2011 20:56:26 +0000 Message-ID: In-Reply-To: <20110228161906.614153A6A06@core3.amsl.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 x-originating-ip: [10.7.0.92] Content-Type: text/plain; charset="us-ascii" Content-ID: <3DA7F4B83B69D549B3AC1980A592EA20@office.hd> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [eman] FW: New Version Notification for draft-quittek-eman-battery-mib-00 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 20:55:32 -0000 Dear all, We have posted a first version of a draft on battery monitoring. It has been extracted from draft-quittek-power-mib-02 and updated. We propose this document to become an EMAN WG document according to our milestone to publish Battery MIB draft. The document still has a few open issues that are listed in section 7: - Battery temperature Is there a need to report the temperature of the battery? The UPS MIB does so with object upsBatteryTemperature. - Scale of the charge percentage Should object batteryCurrentChargePercentage report the percentage of the current charge with respect to the nominal battery capacity or with respect to the remaining capacity? - Define Charging Cycle The draft is not clear about what a charging cycle is. Is there any commonly accpted definition of it? - Define Battery States 'full' and 'empty' Is a battery 'full' if it is charged 99%? When is it empty? Is it full if it has reached remaining capacity or only if it has achieved nominal capacity? - batteryTable Indexing Shall we link the index to the pmIndex in the POWER-AWARE-MIB? I do not think that any of these issues is a major one, and I look forward to discussing on them. Thanks, Juergen Am 28.02.11 17:19 schrieb "IETF I-D Submission Tool" unter : > >A new version of I-D, draft-quittek-eman-battery-mib-00.txt has been >successfully submitted by Juergen Quittek and posted to the IETF >repository. > >Filename: draft-quittek-eman-battery-mib >Revision: 00 >Title: Definiton of Managed Objects for Battery Monitoring >Creation_date: 2011-02-28 >WG ID: Independent Submission >Number_of_pages: 20 > >Abstract: >This memo defines a portion of the Management Information Base (MIB) >for use with network management protocols in the Internet community. >In particular, it defines managed objects that provide information on >the status of batteries in managed devices. > =20 > =20 > > >The IETF Secretariat. > > From ietf@quittek.at Mon Feb 28 13:07:27 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18E583A6837 for ; Mon, 28 Feb 2011 13:07:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pra6AW4frvX2 for ; Mon, 28 Feb 2011 13:07:25 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by core3.amsl.com (Postfix) with ESMTP id 503B53A67D2 for ; Mon, 28 Feb 2011 13:07:25 -0800 (PST) Received: from [10.7.0.92] (mito.netlab.nec.de [195.37.70.39]) by mrelayeu.kundenserver.de (node=mrbap0) with ESMTP (Nemesis) id 0M2FfQ-1QArjN0R9g-00s9Hx; Mon, 28 Feb 2011 22:08:22 +0100 References: In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii Message-Id: <174E5326-01EC-4641-8F3A-FF2C06D2024A@quittek.at> Content-Transfer-Encoding: quoted-printable From: Juergen Quittek Date: Mon, 28 Feb 2011 22:08:20 +0100 To: "John Parello (jparello)" X-Mailer: Apple Mail (2.1082) X-Provags-ID: V02:K0:zYVlC7qBLhlAQC8RvBIPuLBSlBtJOGUo3N6PzJr7N1T iVnR8pMgbPiNXRxaKN7AQgIGkyK+kUalWB6jvQbnBLaeGorxjg 1eA7zqd9LYzugh6e2YG/uqBWza1RAMnVBRKhwedGkhq9GLL1RS zjMVOeYRBDFaRakvVf/hv2lBv1b/eZl5MzBgUEKIUB/GES11Vl vxZRg6nU2aK325eJeXHJA== Cc: eman mailing list Subject: Re: [eman] modeling power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 21:07:27 -0000 Hi John, Thanks for your comments. Please find replies inline. Am 28.02.2011 um 18:22 schrieb John Parello (jparello): > Thanks Juergen for summarizing this.=20 >=20 > I think the stall we've seen on the proposals is directly related to = not > converging on an agreement for power states and parent child > aggregation. >=20 > We've asked this question on the list before with no dialogue and our > conversations have come down to two differences >=20 > The proposal submitted, by verges, quittek, parello, claise are very > similar. The similarities are in data elements and only vary by > partitioning (ie class). The only differences exist in two items >=20 > 1) Power states / Interfaces > 2) Parent Child relationship (or aggregator as specified in = references) >=20 > IMO any work in EMAN must contain the addition of an IETF power > interface as described in claise architecture (or some compromise as = you > listed with IANA interfaces). It must also contain the addition of > parent/child/aggregator relationship for non SNMP energy management. You say we MUST adopt the power states from the claise architecture=20 and we MUST adopt the parent/child concept. The reasons you give for this in the paragraphs below are - Otherwise we would not need an EMAN WG. - This helps manufacturers to build sophisticated energy management = systems. I would not accept the first one as a technical argument,=20 On your second argument I would reply that providing good interfaces for building sophisticated applications is certainly an objective=20 of our work in EMAN, but probably not the one with top priority. Thanks, Juergen =20 > Without those two additions the work in this group can easily be = covered > by two additions to existing SNMP objects. First would be adding = energy > related fields (watts units or Kwh) to the sensor mib. The seconds = would > be to add better the context information (see energy aware proposal) = to > the entity mib. A simple on/off/standby state already exists in oper > status. >=20 > So in short without an IETF EMAN set of power states / interfaces to > unify or map to the states from other orgs as you listed, *and* the > ability to monitor/aggregate non SNMP devices - the work here can = easily > be absorbed into the sensor and entity mibs with minor additions. >=20 > The experience I've personally had with energy management and running > code with exactly these additions has shown that manufacturers can = build > sophisticated energy management systems and devices for many different > network connected devices with a converged set of states and the = parent > child relationship.=20 >=20 > Having run a program which adds these features I'm strongly in favor = of > a solution that has a unified power interface and the concept of a > parent / child to allow for non-snmp management of power. >=20 > Jp >=20 >=20 > -----Original Message----- > From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf = Of > Juergen Quittek > Sent: Monday, February 28, 2011 4:07 AM > To: eman mailing list > Subject: [eman] modeling power states >=20 > Dear all, >=20 > We have two proposals for a Power/Energy MIB module: >=20 > - draft-claise-energy-monitoring-mib-06 > - draft-quittek-power-mib-02 >=20 > Among the authors of both documents we are currently trying to merge > them. > But there are some open issues that should be discussed on the mailing > list. Here is the probably biggest of them: modeling power states. >=20 > For simplifying energy management we want to introduce the concept of > power states (aka power levels). A power state will indicate roughly > how > much power a device consumes. Examples for simple power states are = off, > sleep, and operational states. >=20 > In the envisioned EMAN MIB modules, a power state is characterized by = a > descriptive name and the device's expected power input in this state > (max/min/average). >=20 > Power states are not a new concept. The DMTF has already defined a = set > of > power states and there is the Other standards bodies as the DMTF > (Distributed Management Task Force) and there is the ACPI (Advanced > Configuration and Power Interface) for PC motherboards. And there may > be > more than these out there. I listed some DMTF and ACPI states at the > end > of this message. >=20 > An easy solution for EMAN would be just adopting one of these sets. > However, there are issues with the ones we looked at. ACPI was > developed > for PC motherboards and is quite PC-centric. Also it defines states > that > seem to be superfluous, because so far, almost no one has implemented > them. Also the DMTF model seems to have a narrower scope than > envisioned > by the EMAN WG. >=20 > At some point in time, the EMAN WG hast to make a decision, which = power > state model to adopt. Here is a set of alternatives. The first four > have > fixed sets of power states. >=20 > Option 1: fixed minimum > Just support three power states (off, sleep (stand-by), operational) > This has clear semantics, but there are several people claiming it's = too > restrictive. >=20 > Option 2: fixed DMTF > Just use the states defined by DMTF. > Might be too much focussed n PCs. >=20 > Option 3: fixed ACPI > Just use the states defined by ACPI. > Might be too much focussed n PCs. >=20 >=20 >=20 > Option 4: fixed EMAN > Define a new fixed set of power levels within the EMAN WG. >=20 > Option 5: IANA-registered power states > Have power states be registered at IANA. > We would start with registering (off, sleep, operational, the DMTF = set, > and the ACPI set. > Manufacturers can then register further ones. >=20 >=20 > There has been discussions pointing out that these fixed sets may not = be > sufficient, particularly if non-IT equipment should also be covered. >=20 > For being more open, the idea to support user-defined or > manufacturer-defined power states of devices has been developed. In > such > a state, for example, certain components of a device may be switched = off > or put to sleep. Which ones are switched off in which state is to be > defined by the user/operator/manufacturer and may be chosen such that > operational needs are met. >=20 > Again, there are several proposals how to do this. All of them favor = a > two-level approach that distinguishes between rather flexible = functional > power states and rather fixed basic power states. Functional power > states > would be defined by the manufacturer, operator, or user. These would = be > the power states that would be reported by a device. However, in = order > to > better define the semantics of functional power states, Each of these > would be mapped to exactly one basic power states. This means that a > property of any functional state would be the basic state it maps to. > Basic power states would be fixed, such as the ones used in options = 1-5. > An easy example would be functional power states defined by > user/operator/manufacturer with each state indicating whether it is an > off > state, a sleep state or an operational state. >=20 > Here are the corresponding options: >=20 > Option 6: flexible functional states mapped to a fixed set of basic > states > States could be defined flexibly. But each state would indicate a = basic > state to which it corresponds. Basic states could be either basic > (off/sleep/operational) or the DMTF set or the ACPI set >=20 > Option 7: flexible functional states mapped to a IANA registered set = of > basic states > This is like Option 6, but basic states would be registered at IANA = and > can be extended. We would register all DMTF and ACPI states and > probably > some more at IANA. Manufacturers could add more. >=20 > Option 8: IANA-registered sets of functional states, only three basic > states > The main reasoning behind this option is that is should always be = clear > whether a power state is an off state, a sleep state, or an = operational > state. Therefore, only these three basic states are supported. This > would be in line with an instance of Option 6. However, this option = has > an extension for the functional states. It suggests that for > customizing > devices in order to be compliant with given management systems, for > example a DMTF-based system, it should be possible to restrict > functional > power states to a given set that is registered at IANA. An example > would > be the DMTF states. We would register a flag at IANA that indicates = we > are using DMTF states only. This would signal the management > application > that all power state IDs are in line with power state numbering as > defined > by IANA. Analogously, ACPI and further sets could be registered at > IANA. > A fallback to Option 6 could be realized by registering a set number = of > 0 > at IANA that does not impose any limit for functional states. >=20 > Obviously, there are more possible options. If you think there is a > better one, please send it to this list. >=20 > I know this discussion is not easy, but we have to have it in order to > make the right decision in the EMAN WG. Please take some time and = think > about what you consider to be the best way to go. And of course send > questions on the issue. >=20 > Thanks. >=20 > Juergen >=20 >=20 > DMTF (Distributed Management Task Force) power states: > - 2 (Power On) > - 3 (Sleep - Light) > - 4 (Sleep - Deep) > - 5 (Power Cycle (Off Soft)) > - 6 (Power Off - Hard) > - 7 (Hibernate) > - 8 (Power Off - Soft) > - 9 (Power Cycle (Off Hard)) > - 10 (Master Bus Reset) > - 11 (Diagnostic Interrupt (NMI)) > - 12 (Power Off - Soft Graceful) > - 13 (Power Off - Hard Graceful) > - 14 (Master Bus Reset Graceful) > - 15 (Power Cycle (Off - Soft Graceful)) > - 16 (Power Cycle (Off - Hard Graceful)) >=20 > ACPI (Advanced Configuration and Power Interface Specification) power > states for PC motherboards: > - G3-S5 (Off-Hard) > - G2-S5 (Off-Soft) > - G1-S4 (Hibernate) > - G1-S3 (Sleep-Deep) > - G1-S2 (Sleep-Light) > - G1-S1 (Sleep-Light) > - G0-S0-P5 > - G0-S0-P4 > - G0-S0-P3 > - G0-S0-P2 > - G0-S0-P2 > - G0-S0-P2 >=20 >=20 >=20 >=20 > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman From jparello@cisco.com Mon Feb 28 15:57:31 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 834073A6CA5 for ; Mon, 28 Feb 2011 15:57:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uQQ+gD0pJams for ; Mon, 28 Feb 2011 15:57:29 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id B29323A6828 for ; Mon, 28 Feb 2011 15:57:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jparello@cisco.com; l=11454; q=dns/txt; s=iport; t=1298937511; x=1300147111; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=l0oJOdl6w9VQVSyM0qUvhP3XpKplPl0v0KH5B4L9nJU=; b=TsJzJHpVmkrFezinMXWl1lnlTz1IorFW0nWWtCZg7Fbkl2bHuZc/AqDx YMOdIxZmLv1A807nsAprm5rraleKD+/6yuGS9IbLY92HEantCCc0yHvu0 oSgkJY5xK9SdZzZEGqoDrY2taOly70oz6YZne8MVBnJEjqfrwjJmitfSp U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvoAAN7Ea02rR7Hu/2dsb2JhbACXc45UdJ9km2WFYQSFEopR X-IronPort-AV: E=Sophos;i="4.62,243,1297036800"; d="scan'208";a="336544645" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 28 Feb 2011 23:58:30 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p1SNwU1V009127; Mon, 28 Feb 2011 23:58:30 GMT Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 28 Feb 2011 15:58:30 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 28 Feb 2011 15:54:43 -0800 Message-ID: In-Reply-To: <174E5326-01EC-4641-8F3A-FF2C06D2024A@quittek.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] modeling power states Thread-Index: AcvXi6UhUsOqmp74SDCvXeSQVwt7cgAFnfYg References: <174E5326-01EC-4641-8F3A-FF2C06D2024A@quittek.at> From: "John Parello (jparello)" To: "Juergen Quittek" X-OriginalArrivalTime: 28 Feb 2011 23:58:30.0913 (UTC) FILETIME=[667A6710:01CBD7A3] Cc: eman mailing list Subject: Re: [eman] modeling power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 23:57:31 -0000 Hi Juergen, Thanks that's where we disagree :) IMO it is a technical argument. Without adding an common interface for devices *and* the ability to manage devices attached to a communication network you can achieve your goals with simple data models added to sensor, entity and even UPS mib. Interface vs implementation abstraction, retrieval, all partitioning of data is a technical decision. It's not a business, time to market or artistic argument. I'll leave the debate to the rest of the group as you can see where my opinion goes. Looking forward to feedback! Jp -----Original Message----- From: Juergen Quittek [mailto:ietf@quittek.at]=20 Sent: Monday, February 28, 2011 1:08 PM To: John Parello (jparello) Cc: eman mailing list Subject: Re: [eman] modeling power states Hi John, Thanks for your comments. Please find replies inline. Am 28.02.2011 um 18:22 schrieb John Parello (jparello): > Thanks Juergen for summarizing this.=20 >=20 > I think the stall we've seen on the proposals is directly related to not > converging on an agreement for power states and parent child > aggregation. >=20 > We've asked this question on the list before with no dialogue and our > conversations have come down to two differences >=20 > The proposal submitted, by verges, quittek, parello, claise are very > similar. The similarities are in data elements and only vary by > partitioning (ie class). The only differences exist in two items >=20 > 1) Power states / Interfaces > 2) Parent Child relationship (or aggregator as specified in references) >=20 > IMO any work in EMAN must contain the addition of an IETF power > interface as described in claise architecture (or some compromise as you > listed with IANA interfaces). It must also contain the addition of > parent/child/aggregator relationship for non SNMP energy management. You say we MUST adopt the power states from the claise architecture=20 and we MUST adopt the parent/child concept. The reasons you give for this in the paragraphs below are - Otherwise we would not need an EMAN WG. - This helps manufacturers to build sophisticated energy management systems. I would not accept the first one as a technical argument,=20 On your second argument I would reply that providing good interfaces for building sophisticated applications is certainly an objective=20 of our work in EMAN, but probably not the one with top priority. Thanks, Juergen =20 > Without those two additions the work in this group can easily be covered > by two additions to existing SNMP objects. First would be adding energy > related fields (watts units or Kwh) to the sensor mib. The seconds would > be to add better the context information (see energy aware proposal) to > the entity mib. A simple on/off/standby state already exists in oper > status. >=20 > So in short without an IETF EMAN set of power states / interfaces to > unify or map to the states from other orgs as you listed, *and* the > ability to monitor/aggregate non SNMP devices - the work here can easily > be absorbed into the sensor and entity mibs with minor additions. >=20 > The experience I've personally had with energy management and running > code with exactly these additions has shown that manufacturers can build > sophisticated energy management systems and devices for many different > network connected devices with a converged set of states and the parent > child relationship.=20 >=20 > Having run a program which adds these features I'm strongly in favor of > a solution that has a unified power interface and the concept of a > parent / child to allow for non-snmp management of power. >=20 > Jp >=20 >=20 > -----Original Message----- > From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of > Juergen Quittek > Sent: Monday, February 28, 2011 4:07 AM > To: eman mailing list > Subject: [eman] modeling power states >=20 > Dear all, >=20 > We have two proposals for a Power/Energy MIB module: >=20 > - draft-claise-energy-monitoring-mib-06 > - draft-quittek-power-mib-02 >=20 > Among the authors of both documents we are currently trying to merge > them. > But there are some open issues that should be discussed on the mailing > list. Here is the probably biggest of them: modeling power states. >=20 > For simplifying energy management we want to introduce the concept of > power states (aka power levels). A power state will indicate roughly > how > much power a device consumes. Examples for simple power states are off, > sleep, and operational states. >=20 > In the envisioned EMAN MIB modules, a power state is characterized by a > descriptive name and the device's expected power input in this state > (max/min/average). >=20 > Power states are not a new concept. The DMTF has already defined a set > of > power states and there is the Other standards bodies as the DMTF > (Distributed Management Task Force) and there is the ACPI (Advanced > Configuration and Power Interface) for PC motherboards. And there may > be > more than these out there. I listed some DMTF and ACPI states at the > end > of this message. >=20 > An easy solution for EMAN would be just adopting one of these sets. > However, there are issues with the ones we looked at. ACPI was > developed > for PC motherboards and is quite PC-centric. Also it defines states > that > seem to be superfluous, because so far, almost no one has implemented > them. Also the DMTF model seems to have a narrower scope than > envisioned > by the EMAN WG. >=20 > At some point in time, the EMAN WG hast to make a decision, which power > state model to adopt. Here is a set of alternatives. The first four > have > fixed sets of power states. >=20 > Option 1: fixed minimum > Just support three power states (off, sleep (stand-by), operational) > This has clear semantics, but there are several people claiming it's too > restrictive. >=20 > Option 2: fixed DMTF > Just use the states defined by DMTF. > Might be too much focussed n PCs. >=20 > Option 3: fixed ACPI > Just use the states defined by ACPI. > Might be too much focussed n PCs. >=20 >=20 >=20 > Option 4: fixed EMAN > Define a new fixed set of power levels within the EMAN WG. >=20 > Option 5: IANA-registered power states > Have power states be registered at IANA. > We would start with registering (off, sleep, operational, the DMTF set, > and the ACPI set. > Manufacturers can then register further ones. >=20 >=20 > There has been discussions pointing out that these fixed sets may not be > sufficient, particularly if non-IT equipment should also be covered. >=20 > For being more open, the idea to support user-defined or > manufacturer-defined power states of devices has been developed. In > such > a state, for example, certain components of a device may be switched off > or put to sleep. Which ones are switched off in which state is to be > defined by the user/operator/manufacturer and may be chosen such that > operational needs are met. >=20 > Again, there are several proposals how to do this. All of them favor a > two-level approach that distinguishes between rather flexible functional > power states and rather fixed basic power states. Functional power > states > would be defined by the manufacturer, operator, or user. These would be > the power states that would be reported by a device. However, in order > to > better define the semantics of functional power states, Each of these > would be mapped to exactly one basic power states. This means that a > property of any functional state would be the basic state it maps to. > Basic power states would be fixed, such as the ones used in options 1-5. > An easy example would be functional power states defined by > user/operator/manufacturer with each state indicating whether it is an > off > state, a sleep state or an operational state. >=20 > Here are the corresponding options: >=20 > Option 6: flexible functional states mapped to a fixed set of basic > states > States could be defined flexibly. But each state would indicate a basic > state to which it corresponds. Basic states could be either basic > (off/sleep/operational) or the DMTF set or the ACPI set >=20 > Option 7: flexible functional states mapped to a IANA registered set of > basic states > This is like Option 6, but basic states would be registered at IANA and > can be extended. We would register all DMTF and ACPI states and > probably > some more at IANA. Manufacturers could add more. >=20 > Option 8: IANA-registered sets of functional states, only three basic > states > The main reasoning behind this option is that is should always be clear > whether a power state is an off state, a sleep state, or an operational > state. Therefore, only these three basic states are supported. This > would be in line with an instance of Option 6. However, this option has > an extension for the functional states. It suggests that for > customizing > devices in order to be compliant with given management systems, for > example a DMTF-based system, it should be possible to restrict > functional > power states to a given set that is registered at IANA. An example > would > be the DMTF states. We would register a flag at IANA that indicates we > are using DMTF states only. This would signal the management > application > that all power state IDs are in line with power state numbering as > defined > by IANA. Analogously, ACPI and further sets could be registered at > IANA. > A fallback to Option 6 could be realized by registering a set number of > 0 > at IANA that does not impose any limit for functional states. >=20 > Obviously, there are more possible options. If you think there is a > better one, please send it to this list. >=20 > I know this discussion is not easy, but we have to have it in order to > make the right decision in the EMAN WG. Please take some time and think > about what you consider to be the best way to go. And of course send > questions on the issue. >=20 > Thanks. >=20 > Juergen >=20 >=20 > DMTF (Distributed Management Task Force) power states: > - 2 (Power On) > - 3 (Sleep - Light) > - 4 (Sleep - Deep) > - 5 (Power Cycle (Off Soft)) > - 6 (Power Off - Hard) > - 7 (Hibernate) > - 8 (Power Off - Soft) > - 9 (Power Cycle (Off Hard)) > - 10 (Master Bus Reset) > - 11 (Diagnostic Interrupt (NMI)) > - 12 (Power Off - Soft Graceful) > - 13 (Power Off - Hard Graceful) > - 14 (Master Bus Reset Graceful) > - 15 (Power Cycle (Off - Soft Graceful)) > - 16 (Power Cycle (Off - Hard Graceful)) >=20 > ACPI (Advanced Configuration and Power Interface Specification) power > states for PC motherboards: > - G3-S5 (Off-Hard) > - G2-S5 (Off-Soft) > - G1-S4 (Hibernate) > - G1-S3 (Sleep-Deep) > - G1-S2 (Sleep-Light) > - G1-S1 (Sleep-Light) > - G0-S0-P5 > - G0-S0-P4 > - G0-S0-P3 > - G0-S0-P2 > - G0-S0-P2 > - G0-S0-P2 >=20 >=20 >=20 >=20 > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman From chrisv@cyberswitching.com Mon Feb 28 21:05:01 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1E303A6DA7 for ; Mon, 28 Feb 2011 21:05:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.495 X-Spam-Level: X-Spam-Status: No, score=-6.495 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S5h9CMcVmsvB for ; Mon, 28 Feb 2011 21:05:00 -0800 (PST) Received: from p01c12o142.mxlogic.net (p01c12o142.mxlogic.net [208.65.145.65]) by core3.amsl.com (Postfix) with ESMTP id C28783A6DA3 for ; Mon, 28 Feb 2011 21:04:59 -0800 (PST) Received: from unknown [207.47.28.34] (EHLO mail03.cyberswitching.local) by p01c12o142.mxlogic.net(mxl_mta-6.9.0-1) with ESMTP id 9be7c6d4.0.20981.00-359.32729.p01c12o142.mxlogic.net (envelope-from ); Mon, 28 Feb 2011 22:06:02 -0700 (MST) X-MXL-Hash: 4d6c7eba715126d8-60a0a637f0fdd3bced01ae77e4d2c4b1ee021ab8 Received: from cslinux-build01.localdomain ([10.0.2.250]) by mail03.cyberswitching.local with Microsoft SMTPSVC(6.0.3790.4675); Mon, 28 Feb 2011 21:05:16 -0800 Received: by cslinux-build01.localdomain (Postfix, from userid 1000) id 5C3B92F6001; Mon, 28 Feb 2011 21:06:01 -0800 (PST) Date: Mon, 28 Feb 2011 21:06:01 -0800 From: chrisv@cyberswitching.com To: "John Parello (jparello)" Message-ID: <20110301050601.GA2638@cslinux-build01.cyberswitching.local> References: <174E5326-01EC-4641-8F3A-FF2C06D2024A@quittek.at> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-OriginalArrivalTime: 01 Mar 2011 05:05:16.0386 (UTC) FILETIME=[40FEB420:01CBD7CE] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [207.47.28.34] X-AnalysisOut: [v=1.0 c=1 a=mrxgWj59b9sA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel] X-AnalysisOut: [0A:10 a=1Eql4bHns2NoxN2V9ejGkg==:17 a=yMhMjlubAAAA:8 a=F54] X-AnalysisOut: [ivu-ZAAAA:8 a=n3MJN0c7AAAA:20 a=i79aPfO6N8EO3YZNrl0A:9 a=I] X-AnalysisOut: [2rr4H11z9XiEpfjokUA:7 a=BA3NHn2aftpRenQztLyRTpRP3W8A:4 a=C] X-AnalysisOut: [juIK1q_8ugA:10 a=EftC3F1FOVIA:10 a=nsQ3bZYW9x8A:10] Cc: eman mailing list Subject: Re: [eman] modeling power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 05:05:01 -0000 Hi John and Juergen, > > Without those two additions the work in this group can easily be covered > > by two additions to existing SNMP objects. First would be adding energy > > related fields (watts units or Kwh) to the sensor mib. The seconds would > > be to add better the context information (see energy aware proposal) to > > the entity mib. A simple on/off/standby state already exists in oper > > status. > > > > So in short without an IETF EMAN set of power states / interfaces to > > unify or map to the states from other orgs as you listed, *and* the > > ability to monitor/aggregate non SNMP devices - the work here can easily > > be absorbed into the sensor and entity mibs with minor additions. I disagree with the argument that ENTITY-MIB can be extended to support power data properly. ENTITY-MIB contains an inherent flaw, in that it separates physical and logical entities into distinct buckets that cannot overlap in sparse tables. WHEN -- not if -- the IETF decides to provide a meter hook for logical entities (individual programs, virtual machines on a shared server, etc.), an EMAN schema based on ENTITY-MIB would have to be forked to support this. That duplication of effort is pointless. And I say "when" because it's a matter of time. Lots of people are already working on this problem because there is a huge amount of money involved: 30-second internet search: http://research.microsoft.com/apps/pubs/default.aspx?id=120435 The IETF exists to enable others' innovation and interoperability in those pursuits. It is not our responsibility to debate the merits of this undertaking. It is, however, our duty to acknowledge this pursuit and prepare to integrate it into schema. So while it's good to make a nod to the predecessor ENTITY-MIB, I urge us to make a structural break from it. > > IMO any work in EMAN must contain the addition of an IETF power > > interface as described in claise architecture (or some compromise as you > > listed with IANA interfaces). It must also contain the addition of > > parent/child/aggregator relationship for non SNMP energy management. > > You say we MUST adopt the power states from the claise architecture > and we MUST adopt the parent/child concept. > > The reasons you give for this in the paragraphs below are > - Otherwise we would not need an EMAN WG. > - This helps manufacturers to build sophisticated energy management > systems. > > I would not accept the first one as a technical argument, > On your second argument I would reply that providing good interfaces > for building sophisticated applications is certainly an objective > of our work in EMAN, but probably not the one with top priority. I agree with John's first point ("otherwise EMAN wouldn't exist") in the light that, even though it may not yet be fully and properly articulated, there is a sense that EMAN is needed because the existing solution architecture just doesn't quite do what is needed. I mean, why does your MIB draft exist? You see a problem and have tried to solve it because a solution doesn't yet exist. Here's a structural example to illustrate the point: Using ENTITY-MIB and extending it to include kW, kWh, etc. sensor types, the data COULD be represented. For a single intelligent power supply on a server that monitors voltage, amperage, real power, apparent power, power factor, and frequency, we'd have 6 entities enumerated in ENTITY-MIB. And all of this would need to be tied together logically into a "Power Supply" concept, so that'd be another entity -- 7 in total. For a single server, sure, fine, do-able. Tiny scale. What about a 24-outlet PDU? Or a 84-circuit panelboard? http://www.kondra.com/circuit/circuit.html Eaton Branch Circuit Monitoring Whitepaper: http://tinyurl.com/5rpmhrp Managing 168 entities on a PDU or 588 entities on a panelboard is a ridiculous burden on the user who is consuming the agent's data. "Bonding" these entities that are a common purpose reduces the magnitude by a factor of 7, and simplifies the conceptual use of the framework. Users don't need to think in terms of "voltage sensor for Outlet 1" but instead can refer to that same data as "Outlet 1's voltage." Juergen, it seems like you're so busy focused on a conceptual model that real-world usability may be getting sacrificed. Each of your examples only reflects a single entity at a time. Why not kick up the examples a notch and model something like an intelligent PDU with the following properties? 1. 24 outlets, single phase 2. 6 banks (4 outlets per bank), single phase 3. 2 inputs (3 banks per input), three phase 4. "Ganged" outlets (multiple outlets that are managed as one construct) 5. High current alerts, low current alerts, circuit breaker alerts, high voltage alerts (spikes), low voltage alerts (sags) -- all of which can be applied to a physical entity or a logical entity (like an outlet "gang") 6. Internal network card and metering logic 7. Outlets "owned" by different users (think co-location facility, "context") 8. Manage power via 5 different interface modalities/mechanisms 9. Except for the existence of the outlets/banks/inputs/"gangs", all other properties are potentially optional I challenge you -- everyone participating in the EMAN list -- to model this level of complexity. If your MIB can withstand this, it's a good MIB (IMO, of course). Thanks, Chris From bnordman@lbl.gov Mon Feb 28 22:51:46 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B3143A6CF7 for ; Mon, 28 Feb 2011 22:51:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.232 X-Spam-Level: X-Spam-Status: No, score=-5.232 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MXYZdgI2M1lI for ; Mon, 28 Feb 2011 22:51:44 -0800 (PST) Received: from ironport4.lbl.gov (ironport4.lbl.gov [128.3.41.45]) by core3.amsl.com (Postfix) with ESMTP id 7E86B3A6CEF for ; Mon, 28 Feb 2011 22:51:44 -0800 (PST) X-Ironport-SBRS: 5.3 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkUCACImbE3RVdy0mWdsb2JhbACCTZtsAYgICBYBAgEICwoHESWgMJpagxiCSQSFEocNiFA6 X-IronPort-AV: E=Sophos;i="4.62,245,1297065600"; d="scan'208";a="35337084" Received: from mail-vx0-f180.google.com ([209.85.220.180]) by ironport4.lbl.gov with ESMTP; 28 Feb 2011 22:52:46 -0800 Received: by vxc38 with SMTP id 38so5179475vxc.39 for ; Mon, 28 Feb 2011 22:52:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.167.36 with SMTP id zl4mr342456vdb.34.1298962365532; Mon, 28 Feb 2011 22:52:45 -0800 (PST) Received: by 10.52.155.40 with HTTP; Mon, 28 Feb 2011 22:52:45 -0800 (PST) In-Reply-To: References: Date: Mon, 28 Feb 2011 22:52:45 -0800 Message-ID: From: Bruce Nordman To: Juergen Quittek Content-Type: multipart/alternative; boundary=bcaec53f97f55fc966049d663ec9 Cc: eman mailing list Subject: Re: [eman] modeling power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 06:51:47 -0000 --bcaec53f97f55fc966049d663ec9 Content-Type: text/plain; charset=ISO-8859-1 Juergen has provided a good summary and comprehensive set of options. I think several of the points he makes bear emphasis. One is the distinction between (basic) power states, and functionality differences within such states. It is tempting to want to put all of this onto one linear scale of states, and sometimes that works. However, many functionalities are essentially not on the same dimension as the basic power state one, so do not well match to it. An example is battery charging, which can occur in on, sleep, or off. Another point is that going beyond a few basic states inevitably makes the list specific to narrow groups of products and/or to specific implementations, and so is not universal. With all this, not surprisingly I favor option 1, or 6-8, with the latter ones recognizing this distinction between power states and functional states. For DMTF, this is a mixture of power states, and transition states and/or commands, so I think not a good source when we are just talking about power states. For ACPI, my understanding is that in practice, S1 and S2 are not used, so the number of actual states is fewer than appears. I do think that there may be a fourth basic state of "Ready", which would apply more to appliances than to electronic devices. --Bruce On Mon, Feb 28, 2011 at 4:07 AM, Juergen Quittek wrote: > Dear all, > > We have two proposals for a Power/Energy MIB module: > > - draft-claise-energy-monitoring-mib-06 > - draft-quittek-power-mib-02 > > Among the authors of both documents we are currently trying to merge them. > But there are some open issues that should be discussed on the mailing > list. Here is the probably biggest of them: modeling power states........ > > -- *Bruce Nordman* Lawrence Berkeley National Laboratory eetd.lbl.gov/ea/nordman BNordman@LBL.gov 510-486-7089 m: 510-501-7943 --bcaec53f97f55fc966049d663ec9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Juergen has provided a good summary and comprehensive set of options.
    I think several of the points he makes bear emphasis.
    One is the disti= nction between (basic) power states,
    and functionality differences withi= n such states.
    It is tempting to want to put all of this onto one linear
    scale of state= s, and sometimes that works. =A0However,
    many functionalities are essent= ially not on the same
    dimension as the basic power state one, so do not<= br> well match to it. =A0An example is battery charging, which
    can occur in = on, sleep, or off.

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

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

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

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

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

    --Bruce

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

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

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

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


    --
    Bruce N= ordman
    Lawrence Berkel= ey National Laboratory
    eetd.lbl.gov/ea/nordman
    BNordman@LBL.gov
    510-486-7089
    m: 510-501-7943

    --bcaec53f97f55fc966049d663ec9--