From amontville@tripwire.com Mon Apr 9 11:33:18 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C57A921F87B0 for ; Mon, 9 Apr 2012 11:33:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9RvCCtB4zzdc for ; Mon, 9 Apr 2012 11:33:18 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe005.messaging.microsoft.com [213.199.154.143]) by ietfa.amsl.com (Postfix) with ESMTP id AAB9E21F878A for ; Mon, 9 Apr 2012 11:33:17 -0700 (PDT) Received: from mail99-db3-R.bigfish.com (10.3.81.225) by DB3EHSOBE005.bigfish.com (10.3.84.25) with Microsoft SMTP Server id 14.1.225.23; Mon, 9 Apr 2012 18:33:16 +0000 Received: from mail99-db3 (localhost [127.0.0.1]) by mail99-db3-R.bigfish.com (Postfix) with ESMTP id A00641A065A for ; Mon, 9 Apr 2012 18:33:16 +0000 (UTC) X-SpamScore: 1 X-BigFish: VPS1(zzzz1202hz31izz2dh2a8h668h839h944h) X-Forefront-Antispam-Report: CIP:174.47.84.216; KIP:(null); UIP:(null); IPV:NLI; H:PDXHB01.tripwire.com; RD:174-47-84-216.static.twtelecom.net; EFVD:NLI Received: from mail99-db3 (localhost.localdomain [127.0.0.1]) by mail99-db3 (MessageSwitch) id 1333996394975952_19616; Mon, 9 Apr 2012 18:33:14 +0000 (UTC) Received: from DB3EHSMHS018.bigfish.com (unknown [10.3.81.246]) by mail99-db3.bigfish.com (Postfix) with ESMTP id DFED91C0261 for ; Mon, 9 Apr 2012 18:33:14 +0000 (UTC) Received: from PDXHB01.tripwire.com (174.47.84.216) by DB3EHSMHS018.bigfish.com (10.3.87.118) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 9 Apr 2012 18:33:14 +0000 Received: from PDXHB01.tripwire.com (172.30.0.53) by PDXED01.tripwire.com (192.168.192.5) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 9 Apr 2012 11:42:49 -0700 Received: from PDXMB02.tripwire.com ([fe80::f997:7b65:8e64:438e]) by PDXHB01.tripwire.com ([fe80::d495:98d2:7df4:2154%11]) with mapi id 14.01.0355.002; Mon, 9 Apr 2012 11:33:12 -0700 From: Adam Montville To: "'sacm@ietf.org'" Thread-Topic: Status Update Request Thread-Index: AQHNFn84f7sr7kkdS02JMJ0z7pzzGQ== Date: Mon, 9 Apr 2012 18:33:11 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [172.30.0.234] x-exclaimer-md-config: 79afcaa7-fdf4-4fa6-abe0-afeaa4640a4f Content-Type: text/plain; charset="us-ascii" Content-ID: <4A607AB0094F98499931C8B91B5A0AD8@tripwire.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: tripwire.com Subject: [sacm] Status Update Request X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 18:33:18 -0000 All: The list seems to be rather quiet since the close of IETF 83 more than a week ago. Actions coming out of the side meeting held on March 24 included: 1. Use Case document first draft by middle of April 2. Use Case initial revision by end of April 3. Start of a charter discussion around middle of April (after first draft Use Case release) Dave Waltermire has offered to lead development of the Use Case document and Kent Landfield has offered to lead the subsequent charter discussion. Dave/Kent: Do either of you have an update you can share? Adam From david.waltermire@nist.gov Mon Apr 9 11:41:41 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A805821F86E8 for ; Mon, 9 Apr 2012 11:41:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pu8Zm7soBtX1 for ; Mon, 9 Apr 2012 11:41:40 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 4C47821F86D4 for ; Mon, 9 Apr 2012 11:41:40 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 9 Apr 2012 14:41:37 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Mon, 9 Apr 2012 14:41:39 -0400 From: "Waltermire, David A." To: Adam Montville , "'sacm@ietf.org'" Date: Mon, 9 Apr 2012 14:41:37 -0400 Thread-Topic: Status Update Request Thread-Index: AQHNFn84f7sr7kkdS02JMJ0z7pzzGZaS0atA Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_002_D7A0423E5E193F40BE6E94126930C4930B96C50980MBCLUSTERxcha_" MIME-Version: 1.0 Subject: Re: [sacm] Status Update Request X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 18:41:41 -0000 --_002_D7A0423E5E193F40BE6E94126930C4930B96C50980MBCLUSTERxcha_ Content-Type: text/plain; charset="us-ascii" Please find a skeleton I-D of the use case document attached with updates to the abstract based on the feedback to date. If there are no other comments on the abstract I'll start work on the introduction and we can start breaking out use cases and authors for each use case. Sincerely, Dave > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > Adam Montville > Sent: Monday, April 09, 2012 2:33 PM > To: 'sacm@ietf.org' > Subject: [sacm] Status Update Request > > All: > > The list seems to be rather quiet since the close of IETF 83 more than > a week ago. Actions coming out of the side meeting held on March 24 > included: > > 1. Use Case document first draft by middle of April 2. Use Case initial > revision by end of April 3. Start of a charter discussion around middle > of April (after first draft Use Case release) > > Dave Waltermire has offered to lead development of the Use Case > document and Kent Landfield has offered to lead the subsequent charter > discussion. > > Dave/Kent: Do either of you have an update you can share? > > Adam > > > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm --_002_D7A0423E5E193F40BE6E94126930C4930B96C50980MBCLUSTERxcha_ Content-Type: text/plain; name="draft-waltermire-sacm-use-cases-00-v1.txt" Content-Description: draft-waltermire-sacm-use-cases-00-v1.txt Content-Disposition: attachment; filename="draft-waltermire-sacm-use-cases-00-v1.txt"; size=10771; creation-date="Mon, 09 Apr 2012 14:37:34 GMT"; modification-date="Mon, 09 Apr 2012 14:37:35 GMT" Content-Transfer-Encoding: base64 CgoKTmV0d29yayBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg RC4gV2FsdGVybWlyZSwgRWQuCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTklTVApJbnRlbmRlZCBzdGF0dXM6IEluZm9y bWF0aW9uYWwgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEFwcmlsIDksIDIwMTIKRXhwaXJl czogT2N0b2JlciAxMSwgMjAxMgoKCiAgQW5hbHlzaXMgb2YgU2VjdXJpdHkgQXV0b21hdGlvbiBh bmQgQ29udGludW91cyBNb25pdG9yaW5nIChTQUNNKSBVc2UKICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgQ2FzZXMKICAgICAgICAgICAgICAgICAgIGRyYWZ0LXdhbHRlcm1pcmUtc2Fj bS11c2UtY2FzZXMtMDAKCkFic3RyYWN0CgogICBUaGlzIGRyYWZ0IGlkZW50aWZpZXMgZm91bmRh dGlvbmFsIHVzZSBjYXNlcywgZGVyaXZlZCBmdW5jdGlvbmFsCiAgIGNhcGFiaWxpdGllcyBhbmQg cmVxdWlyZW1lbnRzLCBhcmNoaXRlY3R1cmFsIGNvbXBvbmVudHMsIGFuZCB0aGUKICAgc3VwcG9y dGluZyBzdGFuZGFyZHMgbmVlZGVkIHRvIGRlZmluZSBhbiBpbnRlcm9wZXJhYmxlLCBhdXRvbWF0 aW9uCiAgIGluZnJhc3RydWN0dXJlIHJlcXVpcmVkIHRvIHN1cHBvcnQgdGltZWx5LCBhY2N1cmF0 ZSBhbmQgYWN0aW9uYWJsZQogICBzaXR1YXRpb25hbCBhd2FyZW5lc3Mgb3ZlciBhbiBvcmdhbml6 YXRpb24ncyBJVCBzeXN0ZW1zLiAgQXV0b21hdGlvbgogICB0b29scyBpbXBsZW1lbnRpbmcgYSBj b250aW51b3VzIG1vbml0b3JpbmcgYXBwcm9hY2ggd2lsbCB1dGlsaXplIHRoaXMKICAgaW5mcmFz dHJ1Y3R1cmUgdG9nZXRoZXIgd2l0aCBleGlzdGluZyBhbmQgZW1lcmdpbmcgZXZlbnQsIGluY2lk ZW50CiAgIGFuZCBuZXR3b3JrIG1hbmFnZW1lbnQgc3RhbmRhcmRzIHRvIHByb3ZpZGUgdmlzaWJp bGl0eSBpbnRvIHRoZSBzdGF0ZQogICBvZiBhc3NldHMsIHVzZXIgYWN0aXZpdGllcyBhbmQgbmV0 d29yayBiZWhhdmlvci4gIFN0YWtlaG9sZGVycyB3aWxsCiAgIGJlIGFibGUgdG8gdXNlIHRoZXNl IHRvb2xzIHRvIGFnZ3JlZ2F0ZSBhbmQgYW5hbHl6ZSByZWxldmFudCBzZWN1cml0eQogICBhbmQg b3BlcmF0aW9uYWwgZGF0YSB0byB1bmRlcnN0YW5kIHRoZSBvcmdhbml6YXRpb25zIHNlY3VyaXR5 CiAgIHBvc3R1cmUsIHF1YW50aWZ5IGJ1c2luZXNzIHJpc2ssIGFuZCBtYWtlIGluZm9ybWVkIGRl Y2lzaW9ucyB0aGF0CiAgIHN1cHBvcnQgb3JnYW5pemF0aW9uYWwgb2JqZWN0aXZlcyB3aGlsZSBw cm90ZWN0aW5nIGNyaXRpY2FsCiAgIGluZm9ybWF0aW9uLiAgT3JnYW5pemF0aW9ucyB3aWxsIGJl IGFibGUgdG8gdXNlIHRoZXNlIHRvb2xzIHRvCiAgIGF1Z21lbnQgYW5kIGF1dG9tYXRlIGluZm9y bWF0aW9uIHNoYXJpbmcgYWN0aXZpdGllcyB0byBjb2xsYWJvcmF0ZQogICB3aXRoIHBhcnRuZXJz IHRvIGlkZW50aWZ5IGFuZCBtaXRpZ2F0ZSB0aHJlYXRzLiAgT3RoZXIgYXV0b21hdGlvbgogICB0 b29scyB3aWxsIGJlIGFibGUgdG8gaW50ZWdyYXRlIHdpdGggdGhlc2UgY2FwYWJpbGl0aWVzIHRv IGVuZm9yY2UKICAgcG9saWNpZXMgYmFzZWQgb24gaHVtYW4gZGVjaXNpb25zIHRvIGhhcmRlbiBz eXN0ZW1zLCBwcmV2ZW50IG1pc3VzZQogICBhbmQgcmVkdWNlIHRoZSBvdmVyYWxsIGF0dGFjayBz dXJmYWNlLgoKU3RhdHVzIG9mIHRoaXMgTWVtbwoKICAgQnkgc3VibWl0dGluZyB0aGlzIEludGVy bmV0LURyYWZ0LCBlYWNoIGF1dGhvciByZXByZXNlbnRzIHRoYXQgYW55CiAgIGFwcGxpY2FibGUg cGF0ZW50IG9yIG90aGVyIElQUiBjbGFpbXMgb2Ygd2hpY2ggaGUgb3Igc2hlIGlzIGF3YXJlCiAg IGhhdmUgYmVlbiBvciB3aWxsIGJlIGRpc2Nsb3NlZCwgYW5kIGFueSBvZiB3aGljaCBoZSBvciBz aGUgYmVjb21lcwogICBhd2FyZSB3aWxsIGJlIGRpc2Nsb3NlZCwgaW4gYWNjb3JkYW5jZSB3aXRo IFNlY3Rpb24gNiBvZiBCQ1AgNzkuCgogICBJbnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9j dW1lbnRzIG9mIHRoZSBJbnRlcm5ldCBFbmdpbmVlcmluZwogICBUYXNrIEZvcmNlIChJRVRGKS4g IE5vdGUgdGhhdCBvdGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZQogICB3b3JraW5nIGRv Y3VtZW50cyBhcyBJbnRlcm5ldC1EcmFmdHMuICBUaGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0 LQogICBEcmFmdHMgaXMgYXQgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RyYWZ0cy9jdXJy ZW50Ly4KCiAgIEludGVybmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBh IG1heGltdW0gb2Ygc2l4IG1vbnRocwogICBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBv ciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1lbnRzIGF0IGFueQogICB0aW1lLiAgSXQgaXMgaW5h cHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZQogICBtYXRlcmlh bCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBwcm9ncmVzcy4iCgoKCldh bHRlcm1pcmUgICAgICAgICAgICAgIEV4cGlyZXMgT2N0b2JlciAxMSwgMjAxMiAgICAgICAgICAg ICAgICBbUGFnZSAxXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgU0FDTSBVc2UgQ2Fz ZXMgICAgICAgICAgICAgICAgICAgQXByaWwgMjAxMgoKCiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQg d2lsbCBleHBpcmUgb24gT2N0b2JlciAxMSwgMjAxMi4KCgpUYWJsZSBvZiBDb250ZW50cwoKICAg MS4gIEludHJvZHVjdGlvbiAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAzCiAgICAgMS4xLiAgUmVxdWlyZW1lbnRzIExhbmd1YWdlIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMwogICAyLiAgS2V5IENvbmNlcHRzICAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDMKICAgMy4gIFVzZSBD YXNlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAzCiAgICAgMy4xLiAgVXNlIENhc2UgMSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gMwogICAgIDMuMi4gIFVzZSBDYXNlIG4gIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDMKICAgNC4gIEZ1bmN0aW9uYWwgQ2Fw YWJpbGl0aWVzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAzCiAgICAg NC4xLiAgRnVuY3Rpb25hbCBDYXBhYmlsaXR5IDEgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gNAogICAgIDQuMi4gIEZ1bmN0aW9uYWwgQ2FwYWJpbGl0eSBuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDQKICAgNS4gIEZ1bmN0aW9uYWwgQ29tcG9uZW50cyAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA0CiAgIDYuICBEYXRhIEV4 Y2hhbmdlIE1vZGVscyBhbmQgQ29tbXVuaWNhdGlvbnMgUHJvdG9jb2xzIC4gLiAuIC4gLiAuIC4g NAogICA3LiAgSUFOQSBDb25zaWRlcmF0aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIDQKICAgOC4gIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA1CiAgIDkuICBSZWZlcmVuY2VzICAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNQogICAgIDku MS4gIE5vcm1hdGl2ZSBSZWZlcmVuY2VzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIDUKICAgICA5LjIuICBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzICAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA1CiAgIEFwcGVuZGl4IEEuICBBZGRpdGlvbmFsIFN0dWZm IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNQogICBBdXRob3IncyBBZGRy ZXNzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDUK ICAgSW50ZWxsZWN0dWFsIFByb3BlcnR5IGFuZCBDb3B5cmlnaHQgU3RhdGVtZW50cyAgLiAuIC4g LiAuIC4gLiAuIC4gLiA2CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCldhbHRlcm1pcmUgICAg ICAgICAgICAgIEV4cGlyZXMgT2N0b2JlciAxMSwgMjAxMiAgICAgICAgICAgICAgICBbUGFnZSAy XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgU0FDTSBVc2UgQ2FzZXMgICAgICAgICAg ICAgICAgICAgQXByaWwgMjAxMgoKCjEuICBJbnRyb2R1Y3Rpb24KCiAgIFByb3ZpZGUgYSBmZXcg cGFyYWdyYXBocyBkZWNvbXBvc2luZyB0aGUgYWJzdHJhY3QsIGV4cGxhaW5pbmcgaG93IHRoZQog ICBkb2N1bWVudCBpcyBvcmdhbml6ZWQuCgoxLjEuICBSZXF1aXJlbWVudHMgTGFuZ3VhZ2UKCiAg IFRoZSBrZXkgd29yZHMgIk1VU1QiLCAiTVVTVCBOT1QiLCAiUkVRVUlSRUQiLCAiU0hBTEwiLCAi U0hBTEwgTk9UIiwKICAgIlNIT1VMRCIsICJTSE9VTEQgTk9UIiwgIlJFQ09NTUVOREVEIiwgIk1B WSIsIGFuZCAiT1BUSU9OQUwiIGluIHRoaXMKICAgZG9jdW1lbnQgYXJlIHRvIGJlIGludGVycHJl dGVkIGFzIGRlc2NyaWJlZCBpbiBSRkMgMjExOSBbUkZDMjExOV0uCgoKMi4gIEtleSBDb25jZXB0 cwoKICAgRGVmaW5lL3JlZmVyZW5jZSB0aGUgbWFqb3IgY29uY2VwdHMgaW5jbHVkZWQgaW4gdGhp cyBkb2N1bWVudC4KCgozLiAgVXNlIENhc2VzCgogICBEZXNjcmliZSB1c2UgY2FzZXMsIG9uZSBw ZXIgc3ViLXNlY3Rpb24uCgogICBUaGluZ3MgdG8gY29uc2lkZXIgaW5jbHVkaW5nIChidXQgbm90 IGxpbWl0ZWQgdG8pOgoKICAgbyAgVXNhZ2UgU2NlbmVyaW9zIChlLmcuICBTZWN1cml0eSBDb250 cm9sIFZlcmlmaWNhdGlvbiwgRW5kcG9pbnQKICAgICAgRW5mb3JjZW1lbnQsIEluY2lkZW50IERl dGVjdGlvbiwgRm9yZW5zaWMgSW52ZXN0aWdhdGlvbiwgZXRjLikKCiAgIG8gIEluZm9ybWF0aW9u IERvbWFpbnMgKGUuZy4gY29uZmlndXJhdGlvbiwgdnVsbmVyYWJpbGl0eSwgZGlnaXRhbAogICAg ICBldmVudHMsIGV0Yy4pCgozLjEuICBVc2UgQ2FzZSAxCgogICBEZXNjcmliZSB0aGUgZmlyc3Qg dXNlIGNhc2UuCgozLjIuICBVc2UgQ2FzZSBuCgogICBEZXNjcmliZSB0aGUgbiB1c2UgY2FzZS4K Cgo0LiAgRnVuY3Rpb25hbCBDYXBhYmlsaXRpZXMKCiAgIERlY29tcG9zZSB0aGUgZnVuY3Rpb25h bCBjYXBhYmlsaXRpZXMgbmVlZGVkIHRvIHN1cHBvcnQgdGhlIHVzZQogICBjYXNlcywgb25lIHBl ciBzdWItc2VjdGlvbi4gIENyb3NzIHJlZmVyZW5jZSB0aGUgdXNlIGNhc2UKICAgZGVwZW5kZW5j aWVzIHdoZXJlIHRoZXkgZXhpc3QuCgogICBUaGluZ3MgdG8gY29uc2lkZXIgaW5jbHVkaW5nIChi dXQgbm90IGxpbWl0ZWQgdG8pOgoKICAgbyAgSW5mb3JtYXRpb24gVmlld3MvUmVwb3J0cyAoZS5n LiBzZWN1cml0eSBwb3N0dXJlLCBjb21wbGlhbmNlLAogICAgICBjb250cm9sIGVmZmVjdGl2ZW5l c3MpCgoKCldhbHRlcm1pcmUgICAgICAgICAgICAgIEV4cGlyZXMgT2N0b2JlciAxMSwgMjAxMiAg ICAgICAgICAgICAgICBbUGFnZSAzXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgU0FD TSBVc2UgQ2FzZXMgICAgICAgICAgICAgICAgICAgQXByaWwgMjAxMgoKCiAgIG8gIERhdGEgQ29s bGVjdGlvbiAoZS5nLiBjb25maWd1cmF0aW9uIHN0YXRlLCBzb2Z0d2FyZSBpbnZlbnRvcnksCiAg ICAgIHVzZXIgYW5kIG5ldHdvcmsgYmVoYXZpb3IpCgogICBvICBSZWZlcmVuY2UgSW5mb3JtYXRp b24gRm9ybWF0cyAoZS5nLiBjb250cm9sIGNhdGFsb2dzLAogICAgICBjb25maWd1cmF0aW9uIGJh c2VsaW5lcywgbWFsd2FyZSBjaGFyYWN0ZXJpc3RpY3MsIHZ1bG5lcmFiaWxpdHkKICAgICAgZGF0 YSkKCjQuMS4gIEZ1bmN0aW9uYWwgQ2FwYWJpbGl0eSAxCgogICBEZXNjcmliZSB0aGUgZmlyc3Qg Y2FwYWJpbGl0eS4KCjQuMi4gIEZ1bmN0aW9uYWwgQ2FwYWJpbGl0eSBuCgogICBEZXNjcmliZSB0 aGUgbiBjYXBhYmlsaXR5LgoKCjUuICBGdW5jdGlvbmFsIENvbXBvbmVudHMKCiAgIERlc2NyaWJl IHRoZSBhYnN0cmFjdCBmdW5jdGlvbmFsIGNvbXBvbmVudHMgbmVlZGVkIHRvIHByb3ZpZGUgdGhl CiAgIGNhcGFiaWxpdGllcyBkZXNjcmliZWQgaW4gdGhlIHByZXZpb3VzIHNlY3Rpb24uICBEZXNj cmliZSBhbnkKICAgcmVsYXRpb25zaGlwcyBiZXR3ZWVuIHRoZSBjb21wb25lbnRzIGFuZCBob3cg dGhleSBjYW4gYmUgY29tcG9zZWQgdG8KICAgYWRkcmVzcyBmdW5jdGlvbmFsIGNhcGFiaWxpdGll cy4gKHRoaXMgbWlnaHQgYmUgYmV0dGVyIGRlZmluZWQgaW4gdGhlCiAgIHByZXZpb3VzIHNlY3Rp b24uKQoKICAgVGhpbmdzIHRvIGNvbnNpZGVyIGluY2x1ZGluZyAoYnV0IG5vdCBsaW1pdGVkIHRv KToKCiAgIG8gIFRvcG9sb2dpZXMKCiAgIG8gIEZlZGVyYXRpb24gU3RyYXRlZ3kKCgo2LiAgRGF0 YSBFeGNoYW5nZSBNb2RlbHMgYW5kIENvbW11bmljYXRpb25zIFByb3RvY29scwoKICAgRG9jdW1l bnQgd2hlcmUgZXhpc3Rpbmcgd29yayBleGlzdHMsIHdoYXQgaXMgZGVmaW5lZCBieSBTRE9zLCBh bmQgYW55CiAgIGdhcHMgdGhhdCBjYW4gYmUgYWRkcmVzc2VkLiAgRm9yIGdhcHMgcHJvdmlkZSBp bnNpZ2h0IGludG8gd2hhdCB3b3VsZAogICBiZSBhIGdvb2QgZml0IGZvciBTQUNNIG9yIGFub3Ro ZXIgZXhpc3RpbmcgSUVURiBXRy4KCgo3LiAgSUFOQSBDb25zaWRlcmF0aW9ucwoKICAgVGhpcyBt ZW1vIGluY2x1ZGVzIG5vIHJlcXVlc3QgdG8gSUFOQS4KCiAgIEFsbCBkcmFmdHMgYXJlIHJlcXVp cmVkIHRvIGhhdmUgYW4gSUFOQSBjb25zaWRlcmF0aW9ucyBzZWN0aW9uIChzZWUKICAgdGhlIHVw ZGF0ZSBvZiBSRkMgMjQzNCBbSS1ELm5hcnRlbi1pYW5hLWNvbnNpZGVyYXRpb25zLXJmYzI0MzRi aXNdCiAgIGZvciBhIGd1aWRlKS4gIElmIHRoZSBkcmFmdCBkb2VzIG5vdCByZXF1aXJlIElBTkEg dG8gZG8gYW55dGhpbmcsIHRoZQogICBzZWN0aW9uIGNvbnRhaW5zIGFuIGV4cGxpY2l0IHN0YXRl bWVudCB0aGF0IHRoaXMgaXMgdGhlIGNhc2UgKGFzCiAgIGFib3ZlKS4gIElmIHRoZXJlIGFyZSBu byByZXF1aXJlbWVudHMgZm9yIElBTkEsIHRoZSBzZWN0aW9uIHdpbGwgYmUKICAgcmVtb3ZlZCBk dXJpbmcgY29udmVyc2lvbiBpbnRvIGFuIFJGQyBieSB0aGUgUkZDIEVkaXRvci4KCgoKV2FsdGVy bWlyZSAgICAgICAgICAgICAgRXhwaXJlcyBPY3RvYmVyIDExLCAyMDEyICAgICAgICAgICAgICAg IFtQYWdlIDRdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICBTQUNNIFVzZSBDYXNlcyAg ICAgICAgICAgICAgICAgICBBcHJpbCAyMDEyCgoKOC4gIFNlY3VyaXR5IENvbnNpZGVyYXRpb25z CgogICBBbGwgZHJhZnRzIGFyZSByZXF1aXJlZCB0byBoYXZlIGEgc2VjdXJpdHkgY29uc2lkZXJh dGlvbnMgc2VjdGlvbi4KICAgU2VlIFJGQyAzNTUyIFtSRkMzNTUyXSBmb3IgYSBndWlkZS4KCgo5 LiAgUmVmZXJlbmNlcwoKOS4xLiAgTm9ybWF0aXZlIFJlZmVyZW5jZXMKCiAgIFtSRkMyMTE5XSAg QnJhZG5lciwgUy4sICJLZXkgd29yZHMgZm9yIHVzZSBpbiBSRkNzIHRvIEluZGljYXRlCiAgICAg ICAgICAgICAgUmVxdWlyZW1lbnQgTGV2ZWxzIiwgQkNQIDE0LCBSRkMgMjExOSwgTWFyY2ggMTk5 Ny4KCiAgIFttaW5fcmVmXSAgYXV0aFN1ck5hbWUsIGF1dGhJbml0aWFscy4sICJNaW5pbWFsIFJl ZmVyZW5jZSIsIDIwMDYuCgo5LjIuICBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzCgogICBbSS1ELm5h cnRlbi1pYW5hLWNvbnNpZGVyYXRpb25zLXJmYzI0MzRiaXNdCiAgICAgICAgICAgICAgTmFydGVu LCBULiBhbmQgSC4gQWx2ZXN0cmFuZCwgIkd1aWRlbGluZXMgZm9yIFdyaXRpbmcgYW4KICAgICAg ICAgICAgICBJQU5BIENvbnNpZGVyYXRpb25zIFNlY3Rpb24gaW4gUkZDcyIsCiAgICAgICAgICAg ICAgZHJhZnQtbmFydGVuLWlhbmEtY29uc2lkZXJhdGlvbnMtcmZjMjQzNGJpcy0wOSAod29yayBp bgogICAgICAgICAgICAgIHByb2dyZXNzKSwgTWFyY2ggMjAwOC4KCiAgIFtSRkMzNTUyXSAgUmVz Y29ybGEsIEUuIGFuZCBCLiBLb3J2ZXIsICJHdWlkZWxpbmVzIGZvciBXcml0aW5nIFJGQwogICAg ICAgICAgICAgIFRleHQgb24gU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMiLCBCQ1AgNzIsIFJGQyAz NTUyLAogICAgICAgICAgICAgIEp1bHkgMjAwMy4KCgpBcHBlbmRpeCBBLiAgQWRkaXRpb25hbCBT dHVmZgoKICAgVGhpcyBiZWNvbWVzIGFuIEFwcGVuZGl4IGlmIG5lZWRlZC4KCgpBdXRob3IncyBB ZGRyZXNzCgogICBEYXZpZCBXYWx0ZXJtaXJlIChlZGl0b3IpCiAgIE5hdGlvbmFsIEluc3RpdHV0 ZSBvZiBTdGFuZGFyZHMgYW5kIFRlY2hub2xvZ3kKICAgMTAwIEJ1cmVhdSBEcml2ZQogICBHYWl0 aGVyc2J1cmcsIE1hcnlsYW5kICAyMDg3NwogICBVU0EKCiAgIFBob25lOgogICBFbWFpbDogZGF2 aWQud2FsdGVybWlyZUBuaXN0LmdvdgoKCgoKCgoKCldhbHRlcm1pcmUgICAgICAgICAgICAgIEV4 cGlyZXMgT2N0b2JlciAxMSwgMjAxMiAgICAgICAgICAgICAgICBbUGFnZSA1XQoMCkludGVybmV0 LURyYWZ0ICAgICAgICAgICAgICAgU0FDTSBVc2UgQ2FzZXMgICAgICAgICAgICAgICAgICAgQXBy aWwgMjAxMgoKCkZ1bGwgQ29weXJpZ2h0IFN0YXRlbWVudAoKICAgQ29weXJpZ2h0IChDKSBUaGUg SUVURiBUcnVzdCAoMjAxMikuCgogICBUaGlzIGRvY3VtZW50IGlzIHN1YmplY3QgdG8gdGhlIHJp Z2h0cywgbGljZW5zZXMgYW5kIHJlc3RyaWN0aW9ucwogICBjb250YWluZWQgaW4gQkNQIDc4LCBh bmQgZXhjZXB0IGFzIHNldCBmb3J0aCB0aGVyZWluLCB0aGUgYXV0aG9ycwogICByZXRhaW4gYWxs IHRoZWlyIHJpZ2h0cy4KCiAgIFRoaXMgZG9jdW1lbnQgYW5kIHRoZSBpbmZvcm1hdGlvbiBjb250 YWluZWQgaGVyZWluIGFyZSBwcm92aWRlZCBvbiBhbgogICAiQVMgSVMiIGJhc2lzIGFuZCBUSEUg Q09OVFJJQlVUT1IsIFRIRSBPUkdBTklaQVRJT04gSEUvU0hFIFJFUFJFU0VOVFMKICAgT1IgSVMg U1BPTlNPUkVEIEJZIChJRiBBTlkpLCBUSEUgSU5URVJORVQgU09DSUVUWSwgVEhFIElFVEYgVFJV U1QgQU5ECiAgIFRIRSBJTlRFUk5FVCBFTkdJTkVFUklORyBUQVNLIEZPUkNFIERJU0NMQUlNIEFM TCBXQVJSQU5USUVTLCBFWFBSRVNTCiAgIE9SIElNUExJRUQsIElOQ0xVRElORyBCVVQgTk9UIExJ TUlURUQgVE8gQU5ZIFdBUlJBTlRZIFRIQVQgVEhFIFVTRSBPRgogICBUSEUgSU5GT1JNQVRJT04g SEVSRUlOIFdJTEwgTk9UIElORlJJTkdFIEFOWSBSSUdIVFMgT1IgQU5ZIElNUExJRUQKICAgV0FS UkFOVElFUyBPRiBNRVJDSEFOVEFCSUxJVFkgT1IgRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBV UlBPU0UuCgoKSW50ZWxsZWN0dWFsIFByb3BlcnR5CgogICBUaGUgSUVURiB0YWtlcyBubyBwb3Np dGlvbiByZWdhcmRpbmcgdGhlIHZhbGlkaXR5IG9yIHNjb3BlIG9mIGFueQogICBJbnRlbGxlY3R1 YWwgUHJvcGVydHkgUmlnaHRzIG9yIG90aGVyIHJpZ2h0cyB0aGF0IG1pZ2h0IGJlIGNsYWltZWQg dG8KICAgcGVydGFpbiB0byB0aGUgaW1wbGVtZW50YXRpb24gb3IgdXNlIG9mIHRoZSB0ZWNobm9s b2d5IGRlc2NyaWJlZCBpbgogICB0aGlzIGRvY3VtZW50IG9yIHRoZSBleHRlbnQgdG8gd2hpY2gg YW55IGxpY2Vuc2UgdW5kZXIgc3VjaCByaWdodHMKICAgbWlnaHQgb3IgbWlnaHQgbm90IGJlIGF2 YWlsYWJsZTsgbm9yIGRvZXMgaXQgcmVwcmVzZW50IHRoYXQgaXQgaGFzCiAgIG1hZGUgYW55IGlu ZGVwZW5kZW50IGVmZm9ydCB0byBpZGVudGlmeSBhbnkgc3VjaCByaWdodHMuICBJbmZvcm1hdGlv bgogICBvbiB0aGUgcHJvY2VkdXJlcyB3aXRoIHJlc3BlY3QgdG8gcmlnaHRzIGluIFJGQyBkb2N1 bWVudHMgY2FuIGJlCiAgIGZvdW5kIGluIEJDUCA3OCBhbmQgQkNQIDc5LgoKICAgQ29waWVzIG9m IElQUiBkaXNjbG9zdXJlcyBtYWRlIHRvIHRoZSBJRVRGIFNlY3JldGFyaWF0IGFuZCBhbnkKICAg YXNzdXJhbmNlcyBvZiBsaWNlbnNlcyB0byBiZSBtYWRlIGF2YWlsYWJsZSwgb3IgdGhlIHJlc3Vs dCBvZiBhbgogICBhdHRlbXB0IG1hZGUgdG8gb2J0YWluIGEgZ2VuZXJhbCBsaWNlbnNlIG9yIHBl cm1pc3Npb24gZm9yIHRoZSB1c2Ugb2YKICAgc3VjaCBwcm9wcmlldGFyeSByaWdodHMgYnkgaW1w bGVtZW50ZXJzIG9yIHVzZXJzIG9mIHRoaXMKICAgc3BlY2lmaWNhdGlvbiBjYW4gYmUgb2J0YWlu ZWQgZnJvbSB0aGUgSUVURiBvbi1saW5lIElQUiByZXBvc2l0b3J5IGF0CiAgIGh0dHA6Ly93d3cu aWV0Zi5vcmcvaXByLgoKICAgVGhlIElFVEYgaW52aXRlcyBhbnkgaW50ZXJlc3RlZCBwYXJ0eSB0 byBicmluZyB0byBpdHMgYXR0ZW50aW9uIGFueQogICBjb3B5cmlnaHRzLCBwYXRlbnRzIG9yIHBh dGVudCBhcHBsaWNhdGlvbnMsIG9yIG90aGVyIHByb3ByaWV0YXJ5CiAgIHJpZ2h0cyB0aGF0IG1h eSBjb3ZlciB0ZWNobm9sb2d5IHRoYXQgbWF5IGJlIHJlcXVpcmVkIHRvIGltcGxlbWVudAogICB0 aGlzIHN0YW5kYXJkLiAgUGxlYXNlIGFkZHJlc3MgdGhlIGluZm9ybWF0aW9uIHRvIHRoZSBJRVRG IGF0CiAgIGlldGYtaXByQGlldGYub3JnLgoKCgoKCgoKCgoKCldhbHRlcm1pcmUgICAgICAgICAg ICAgIEV4cGlyZXMgT2N0b2JlciAxMSwgMjAxMiAgICAgICAgICAgICAgICBbUGFnZSA2XQoMCg== --_002_D7A0423E5E193F40BE6E94126930C4930B96C50980MBCLUSTERxcha_-- From amontville@tripwire.com Mon Apr 9 11:47:39 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D6C121F86F6 for ; Mon, 9 Apr 2012 11:47:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0t5HtjVw25SN for ; Mon, 9 Apr 2012 11:47:38 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe005.messaging.microsoft.com [216.32.181.185]) by ietfa.amsl.com (Postfix) with ESMTP id 72C9821F8495 for ; Mon, 9 Apr 2012 11:47:38 -0700 (PDT) Received: from mail70-ch1-R.bigfish.com (10.43.68.251) by CH1EHSOBE005.bigfish.com (10.43.70.55) with Microsoft SMTP Server id 14.1.225.23; Mon, 9 Apr 2012 18:47:37 +0000 Received: from mail70-ch1 (localhost [127.0.0.1]) by mail70-ch1-R.bigfish.com (Postfix) with ESMTP id 95EC21A007B; Mon, 9 Apr 2012 18:47:37 +0000 (UTC) X-SpamScore: -41 X-BigFish: VPS-41(zzbb2dI9371I542M1432N98dK148cMzz1202hzz1033IL8275dhz2dh2a8h668h839h944h) X-Forefront-Antispam-Report: CIP:174.47.84.216; KIP:(null); UIP:(null); IPV:NLI; H:PDXHB01.tripwire.com; RD:174-47-84-216.static.twtelecom.net; EFVD:NLI Received: from mail70-ch1 (localhost.localdomain [127.0.0.1]) by mail70-ch1 (MessageSwitch) id 1333997255936825_4634; Mon, 9 Apr 2012 18:47:35 +0000 (UTC) Received: from CH1EHSMHS009.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.230]) by mail70-ch1.bigfish.com (Postfix) with ESMTP id DF98920056; Mon, 9 Apr 2012 18:47:35 +0000 (UTC) Received: from PDXHB01.tripwire.com (174.47.84.216) by CH1EHSMHS009.bigfish.com (10.43.70.9) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 9 Apr 2012 18:47:34 +0000 Received: from PDXHB01.tripwire.com (172.30.0.53) by PDXED01.tripwire.com (192.168.192.5) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 9 Apr 2012 11:57:10 -0700 Received: from PDXMB02.tripwire.com ([fe80::f997:7b65:8e64:438e]) by PDXHB01.tripwire.com ([fe80::d495:98d2:7df4:2154%11]) with mapi id 14.01.0355.002; Mon, 9 Apr 2012 11:47:33 -0700 From: Adam Montville To: "Waltermire, David A." , "'sacm@ietf.org'" Thread-Topic: Status Update Request Thread-Index: AQHNFoE4f7sr7kkdS02JMJ0z7pzzGQ== Date: Mon, 9 Apr 2012 18:47:32 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [172.30.0.234] x-exclaimer-md-config: 79afcaa7-fdf4-4fa6-abe0-afeaa4640a4f Content-Type: text/plain; charset="us-ascii" Content-ID: <0118CB71CE7F974D9FC705BB04B864CC@tripwire.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: tripwire.com Subject: Re: [sacm] Status Update Request X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 18:47:39 -0000 Hi Dave, Thanks for sending this out. I like the abstract and the structure of the document so far, so no further comments from me on the abstract. Are you planning to create a first pass at a complete list of use cases for the document? Adam On 4/9/12 11:41 AM, "Waltermire, David A." wrote: >Please find a skeleton I-D of the use case document attached with updates >to the abstract based on the feedback to date. If there are no other >comments on the abstract I'll start work on the introduction and we can >start breaking out use cases and authors for each use case. > >Sincerely, >Dave > > >> -----Original Message----- >> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of >> Adam Montville >> Sent: Monday, April 09, 2012 2:33 PM >> To: 'sacm@ietf.org' >> Subject: [sacm] Status Update Request >>=20 >> All: >>=20 >> The list seems to be rather quiet since the close of IETF 83 more than >> a week ago. Actions coming out of the side meeting held on March 24 >> included: >>=20 >> 1. Use Case document first draft by middle of April 2. Use Case initial >> revision by end of April 3. Start of a charter discussion around middle >> of April (after first draft Use Case release) >>=20 >> Dave Waltermire has offered to lead development of the Use Case >> document and Kent Landfield has offered to lead the subsequent charter >> discussion. >>=20 >> Dave/Kent: Do either of you have an update you can share? >>=20 >> Adam >>=20 >>=20 >>=20 >> _______________________________________________ >> sacm mailing list >> sacm@ietf.org >> https://www.ietf.org/mailman/listinfo/sacm From david.waltermire@nist.gov Mon Apr 9 12:04:03 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BBE821F87AE for ; Mon, 9 Apr 2012 12:04:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.299 X-Spam-Level: X-Spam-Status: No, score=-5.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SqkIWkYDxwtM for ; Mon, 9 Apr 2012 12:04:02 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 827C421F8607 for ; Mon, 9 Apr 2012 12:04:02 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 9 Apr 2012 15:03:59 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Mon, 9 Apr 2012 15:04:01 -0400 From: "Waltermire, David A." To: Adam Montville , "'sacm@ietf.org'" Date: Mon, 9 Apr 2012 15:04:00 -0400 Thread-Topic: Status Update Request Thread-Index: AQHNFoE4f7sr7kkdS02JMJ0z7pzzGZaS2afg Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Subject: Re: [sacm] Status Update Request X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 19:04:03 -0000 I can take a stab at that. It will be useful at minimum to start some discussion. Dave > -----Original Message----- > From: Adam Montville [mailto:amontville@tripwire.com] > Sent: Monday, April 09, 2012 2:48 PM > To: Waltermire, David A.; 'sacm@ietf.org' > Subject: Re: Status Update Request > > Hi Dave, > > Thanks for sending this out. I like the abstract and the structure of > the document so far, so no further comments from me on the abstract. > Are you planning to create a first pass at a complete list of use cases > for the document? > > Adam > > On 4/9/12 11:41 AM, "Waltermire, David A." > wrote: > > >Please find a skeleton I-D of the use case document attached with > >updates to the abstract based on the feedback to date. If there are > no > >other comments on the abstract I'll start work on the introduction and > >we can start breaking out use cases and authors for each use case. > > > >Sincerely, > >Dave > > > > > >> -----Original Message----- > >> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf > >> Of Adam Montville > >> Sent: Monday, April 09, 2012 2:33 PM > >> To: 'sacm@ietf.org' > >> Subject: [sacm] Status Update Request > >> > >> All: > >> > >> The list seems to be rather quiet since the close of IETF 83 more > >> than a week ago. Actions coming out of the side meeting held on > >> March 24 > >> included: > >> > >> 1. Use Case document first draft by middle of April 2. Use Case > >> initial revision by end of April 3. Start of a charter discussion > >> around middle of April (after first draft Use Case release) > >> > >> Dave Waltermire has offered to lead development of the Use Case > >> document and Kent Landfield has offered to lead the subsequent > >> charter discussion. > >> > >> Dave/Kent: Do either of you have an update you can share? > >> > >> Adam > >> > >> > >> > >> _______________________________________________ > >> sacm mailing list > >> sacm@ietf.org > >> https://www.ietf.org/mailman/listinfo/sacm > From amontville@tripwire.com Mon Apr 9 12:09:47 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7177C21F87D8 for ; Mon, 9 Apr 2012 12:09:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kuQr1fmhqMPf for ; Mon, 9 Apr 2012 12:09:46 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe006.messaging.microsoft.com [216.32.181.186]) by ietfa.amsl.com (Postfix) with ESMTP id AB58921F878A for ; Mon, 9 Apr 2012 12:09:46 -0700 (PDT) Received: from mail223-ch1-R.bigfish.com (10.43.68.225) by CH1EHSOBE012.bigfish.com (10.43.70.62) with Microsoft SMTP Server id 14.1.225.23; Mon, 9 Apr 2012 19:09:46 +0000 Received: from mail223-ch1 (localhost [127.0.0.1]) by mail223-ch1-R.bigfish.com (Postfix) with ESMTP id 0EF3146025E; Mon, 9 Apr 2012 19:09:46 +0000 (UTC) X-SpamScore: -42 X-BigFish: VPS-42(zzbb2dI9371I542M1432N98dK4015I148cMzz1202hzz1033IL8275dhz2dh2a8h668h839h944h) X-Forefront-Antispam-Report: CIP:174.47.84.216; KIP:(null); UIP:(null); IPV:NLI; H:PDXHB01.tripwire.com; RD:174-47-84-216.static.twtelecom.net; EFVD:NLI Received: from mail223-ch1 (localhost.localdomain [127.0.0.1]) by mail223-ch1 (MessageSwitch) id 1333998584874149_32399; Mon, 9 Apr 2012 19:09:44 +0000 (UTC) Received: from CH1EHSMHS017.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.254]) by mail223-ch1.bigfish.com (Postfix) with ESMTP id C7D6D44005D; Mon, 9 Apr 2012 19:09:44 +0000 (UTC) Received: from PDXHB01.tripwire.com (174.47.84.216) by CH1EHSMHS017.bigfish.com (10.43.70.17) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 9 Apr 2012 19:09:44 +0000 Received: from PDXHB01.tripwire.com (172.30.0.53) by PDXED01.tripwire.com (192.168.192.5) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 9 Apr 2012 12:19:20 -0700 Received: from PDXMB02.tripwire.com ([fe80::f997:7b65:8e64:438e]) by PDXHB01.tripwire.com ([fe80::d495:98d2:7df4:2154%11]) with mapi id 14.01.0355.002; Mon, 9 Apr 2012 12:09:43 -0700 From: Adam Montville To: "Waltermire, David A." , "'sacm@ietf.org'" Thread-Topic: Status Update Request Thread-Index: AQHNFoE4f7sr7kkdS02JMJ0z7pzzGZaS2afggAAB9gA= Date: Mon, 9 Apr 2012 19:09:42 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [172.30.0.234] x-exclaimer-md-config: 79afcaa7-fdf4-4fa6-abe0-afeaa4640a4f Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: tripwire.com Subject: Re: [sacm] Status Update Request X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 19:09:47 -0000 Perfect! Thanks, Dave. Once that list is out, I think we can have a meaningful discussion about what we would like to have included, and then divide the work to get this initial draft done by mid April. Adam On 4/9/12 12:04 PM, "Waltermire, David A." wrote: >I can take a stab at that. It will be useful at minimum to start some >discussion. >Dave > >> -----Original Message----- >> From: Adam Montville [mailto:amontville@tripwire.com] >> Sent: Monday, April 09, 2012 2:48 PM >> To: Waltermire, David A.; 'sacm@ietf.org' >> Subject: Re: Status Update Request >>=20 >> Hi Dave, >>=20 >> Thanks for sending this out. I like the abstract and the structure of >> the document so far, so no further comments from me on the abstract. >> Are you planning to create a first pass at a complete list of use cases >> for the document? >>=20 >> Adam >>=20 >> On 4/9/12 11:41 AM, "Waltermire, David A." >> wrote: >>=20 >> >Please find a skeleton I-D of the use case document attached with >> >updates to the abstract based on the feedback to date. If there are >> no >> >other comments on the abstract I'll start work on the introduction and >> >we can start breaking out use cases and authors for each use case. >> > >> >Sincerely, >> >Dave >> > >> > >> >> -----Original Message----- >> >> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf >> >> Of Adam Montville >> >> Sent: Monday, April 09, 2012 2:33 PM >> >> To: 'sacm@ietf.org' >> >> Subject: [sacm] Status Update Request >> >> >> >> All: >> >> >> >> The list seems to be rather quiet since the close of IETF 83 more >> >> than a week ago. Actions coming out of the side meeting held on >> >> March 24 >> >> included: >> >> >> >> 1. Use Case document first draft by middle of April 2. Use Case >> >> initial revision by end of April 3. Start of a charter discussion >> >> around middle of April (after first draft Use Case release) >> >> >> >> Dave Waltermire has offered to lead development of the Use Case >> >> document and Kent Landfield has offered to lead the subsequent >> >> charter discussion. >> >> >> >> Dave/Kent: Do either of you have an update you can share? >> >> >> >> Adam >> >> >> >> >> >> >> >> _______________________________________________ >> >> sacm mailing list >> >> sacm@ietf.org >> >> https://www.ietf.org/mailman/listinfo/sacm >>=20 > > From tkeanini@ncircle.com Mon Apr 9 13:14:16 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30B2421F87FE for ; Mon, 9 Apr 2012 13:14:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BpsNe0b72MA7 for ; Mon, 9 Apr 2012 13:14:15 -0700 (PDT) Received: from mail.ncircle.com (mail.ncircle.com [76.247.119.150]) by ietfa.amsl.com (Postfix) with ESMTP id BFBD921F87FC for ; Mon, 9 Apr 2012 13:14:09 -0700 (PDT) Received: from corp-mail-sf.ncircle.com (fw-hive-gate-dmz.ncircle.com [76.247.119.129] (may be forged)) by mail.ncircle.com (8.14.4/8.14.4) with ESMTP id q39KE7Ju079703 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 9 Apr 2012 13:14:08 -0700 (PDT) (envelope-from tkeanini@ncircle.com) X-DKIM: OpenDKIM Filter v2.5.1 mail.ncircle.com q39KE7Ju079703 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ncircle.com; s=key1; t=1334002448; bh=rsFJk0b1TozelDiJYNqXGZ9URSj/t4kJXCmY+M3ZZZw=; h=Subject:Date:From:To; b=ZZlbkRm0jn3JJ6Iv2obPwhC42uEwdKywuraLNl7ZPfsM3Xk2eIXEc5cGtMUEVGWhn TMsTTvZrWYxfAENJHXGrQ== Received: from CORP-MAIL.ad.ncircle.com (192.168.75.90) by EXCH-SF-02.ad.ncircle.com (192.168.75.48) with Microsoft SMTP Server id 14.2.247.3; Mon, 9 Apr 2012 13:14:07 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 9 Apr 2012 13:14:07 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Status Update Request Thread-Index: AQHNFoE4f7sr7kkdS02JMJ0z7pzzGZaS2afggAATilA= From: Tim Keanini To: "Waltermire, David A." , Adam Montville , Subject: Re: [sacm] Status Update Request X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 20:19:22 -0000 We will certainly need a few ascii diagrams so let me share this link: http://www.asciiflow.com/ --tk -- Tim "TK" Keanini, CTO ... nCircle Inc. =20 -----Original Message----- From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Waltermire, David A. Sent: Monday, April 09, 2012 2:04 PM To: Adam Montville; 'sacm@ietf.org' Subject: Re: [sacm] Status Update Request I can take a stab at that. It will be useful at minimum to start some discussion. Dave > -----Original Message----- > From: Adam Montville [mailto:amontville@tripwire.com] > Sent: Monday, April 09, 2012 2:48 PM > To: Waltermire, David A.; 'sacm@ietf.org' > Subject: Re: Status Update Request >=20 > Hi Dave, >=20 > Thanks for sending this out. I like the abstract and the structure of > the document so far, so no further comments from me on the abstract. > Are you planning to create a first pass at a complete list of use=20 > cases for the document? >=20 > Adam >=20 > On 4/9/12 11:41 AM, "Waltermire, David A." > wrote: >=20 > >Please find a skeleton I-D of the use case document attached with=20 > >updates to the abstract based on the feedback to date. If there are > no > >other comments on the abstract I'll start work on the introduction=20 > >and we can start breaking out use cases and authors for each use case. > > > >Sincerely, > >Dave > > > > > >> -----Original Message----- > >> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On=20 > >> Behalf Of Adam Montville > >> Sent: Monday, April 09, 2012 2:33 PM > >> To: 'sacm@ietf.org' > >> Subject: [sacm] Status Update Request > >> > >> All: > >> > >> The list seems to be rather quiet since the close of IETF 83 more=20 > >> than a week ago. Actions coming out of the side meeting held on=20 > >> March 24 > >> included: > >> > >> 1. Use Case document first draft by middle of April 2. Use Case=20 > >> initial revision by end of April 3. Start of a charter discussion=20 > >> around middle of April (after first draft Use Case release) > >> > >> Dave Waltermire has offered to lead development of the Use Case=20 > >> document and Kent Landfield has offered to lead the subsequent=20 > >> charter discussion. > >> > >> Dave/Kent: Do either of you have an update you can share? > >> > >> Adam > >> > >> > >> > >> _______________________________________________ > >> sacm mailing list > >> sacm@ietf.org > >> https://www.ietf.org/mailman/listinfo/sacm >=20 _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm From william.polk@nist.gov Mon Apr 9 13:25:35 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BCB021F8803 for ; Mon, 9 Apr 2012 13:25:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y7dOk+-wYhRW for ; Mon, 9 Apr 2012 13:25:34 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id F414021F87DC for ; Mon, 9 Apr 2012 13:25:33 -0700 (PDT) Received: from WSXGHUB2.xchange.nist.gov (129.6.18.19) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 9 Apr 2012 16:25:18 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Mon, 9 Apr 2012 16:24:37 -0400 From: "Polk, William T." To: Tim Keanini , "Waltermire, David A." , Adam Montville , "sacm@ietf.org" Date: Mon, 9 Apr 2012 16:22:25 -0400 Thread-Topic: Status Update Request Thread-Index: AQHNFoE4f7sr7kkdS02JMJ0z7pzzGZaS2afggAATilCAAALBzQ== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Subject: Re: [sacm] Status Update Request X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 20:25:35 -0000 I wish someone would have told me this 14 RFCs ago.... Tim ________________________________________ From: sacm-bounces@ietf.org [sacm-bounces@ietf.org] On Behalf Of Tim Keanini [tkeanini@ncircle.com] Sent: Monday, April 09, 2012 4:14 PM To: Waltermire, David A.; Adam Montville; sacm@ietf.org Subject: Re: [sacm] Status Update Request We will certainly need a few ascii diagrams so let me share this link: http://www.asciiflow.com/ --tk -- Tim "TK" Keanini, CTO ... nCircle Inc. -----Original Message----- From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Waltermire, David A. Sent: Monday, April 09, 2012 2:04 PM To: Adam Montville; 'sacm@ietf.org' Subject: Re: [sacm] Status Update Request I can take a stab at that. It will be useful at minimum to start some discussion. Dave > -----Original Message----- > From: Adam Montville [mailto:amontville@tripwire.com] > Sent: Monday, April 09, 2012 2:48 PM > To: Waltermire, David A.; 'sacm@ietf.org' > Subject: Re: Status Update Request > > Hi Dave, > > Thanks for sending this out. I like the abstract and the structure of > the document so far, so no further comments from me on the abstract. > Are you planning to create a first pass at a complete list of use > cases for the document? > > Adam > > On 4/9/12 11:41 AM, "Waltermire, David A." > wrote: > > >Please find a skeleton I-D of the use case document attached with > >updates to the abstract based on the feedback to date. If there are > no > >other comments on the abstract I'll start work on the introduction > >and we can start breaking out use cases and authors for each use case. > > > >Sincerely, > >Dave > > > > > >> -----Original Message----- > >> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On > >> Behalf Of Adam Montville > >> Sent: Monday, April 09, 2012 2:33 PM > >> To: 'sacm@ietf.org' > >> Subject: [sacm] Status Update Request > >> > >> All: > >> > >> The list seems to be rather quiet since the close of IETF 83 more > >> than a week ago. Actions coming out of the side meeting held on > >> March 24 > >> included: > >> > >> 1. Use Case document first draft by middle of April 2. Use Case > >> initial revision by end of April 3. Start of a charter discussion > >> around middle of April (after first draft Use Case release) > >> > >> Dave Waltermire has offered to lead development of the Use Case > >> document and Kent Landfield has offered to lead the subsequent > >> charter discussion. > >> > >> Dave/Kent: Do either of you have an update you can share? > >> > >> Adam > >> > >> > >> > >> _______________________________________________ > >> sacm mailing list > >> sacm@ietf.org > >> https://www.ietf.org/mailman/listinfo/sacm > _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm From Kent_Landfield@mcafee.com Mon Apr 9 13:44:24 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D127F21F87E4 for ; Mon, 9 Apr 2012 13:44:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AKTKpRPfSO4a for ; Mon, 9 Apr 2012 13:44:23 -0700 (PDT) Received: from dalsmrelay2.nai.com (dalsmrelay2.nai.com [205.227.136.216]) by ietfa.amsl.com (Postfix) with ESMTP id 956C221F87CB for ; Mon, 9 Apr 2012 13:44:23 -0700 (PDT) Received: from DALEXHT2.corp.nai.org (unknown [10.64.5.52]) by dalsmrelay2.nai.com with smtp id 2a4d_00cf_a562f11f_9504_4de8_97c8_3fce34ed719c; Mon, 09 Apr 2012 15:44:16 -0500 Received: from AMERDALEXMB1.corp.nai.org ([fe80::b534:4a0d:1289:2d2d]) by DALEXHT2.corp.nai.org ([::1]) with mapi; Mon, 9 Apr 2012 15:42:28 -0500 From: To: , , , , Date: Mon, 9 Apr 2012 15:43:02 -0500 Thread-Topic: [sacm] Status Update Request Thread-Index: Ac0WkUc039HCnVBhSXaBPoFVpXFMkA== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CBA8C1FB307F9kentlandfieldmcafeecom_" MIME-Version: 1.0 Subject: Re: [sacm] Status Update Request X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 20:44:24 -0000 --_000_CBA8C1FB307F9kentlandfieldmcafeecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable What do you know=85. SACM is already being valuable. ;-) Kent Landfield Director Content Strategy, Architecture and Standards McAfee | An Intel Company 5000 Headquarters Dr. Plano, Texas 75024 Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: "Polk, William T." > Date: Mon, 9 Apr 2012 15:22:25 -0500 To: Tim Keanini >, David = Waltermire >, A= dam Montville >, "s= acm@ietf.org" > Subject: Re: [sacm] Status Update Request I wish someone would have told me this 14 RFCs ago.... Tim ________________________________________ From: sacm-bounces@ietf.org [sacm-bounces@iet= f.org] On Behalf Of Tim Keanini [tkeanini@nci= rcle.com] Sent: Monday, April 09, 2012 4:14 PM To: Waltermire, David A.; Adam Montville; sacm@ietf.org Subject: Re: [sacm] Status Update Request We will certainly need a few ascii diagrams so let me share this link: http://www.asciiflow.com/ --tk -- Tim "TK" Keanini, CTO ... nCircle Inc. -----Original Message----- From: sacm-bounces@ietf.org [mailto:sacm-boun= ces@ietf.org] On Behalf Of Waltermire, David A. Sent: Monday, April 09, 2012 2:04 PM To: Adam Montville; 'sacm@ietf.org' Subject: Re: [sacm] Status Update Request I can take a stab at that. It will be useful at minimum to start some discussion. Dave -----Original Message----- From: Adam Montville [mailto:amontville@tripwire.com] Sent: Monday, April 09, 2012 2:48 PM To: Waltermire, David A.; 'sacm@ietf.org' Subject: Re: Status Update Request Hi Dave, Thanks for sending this out. I like the abstract and the structure of the document so far, so no further comments from me on the abstract. Are you planning to create a first pass at a complete list of use cases for the document? Adam On 4/9/12 11:41 AM, "Waltermire, David A." > wrote: >Please find a skeleton I-D of the use case document attached with >updates to the abstract based on the feedback to date. If there are no >other comments on the abstract I'll start work on the introduction >and we can start breaking out use cases and authors for each use case. > >Sincerely, >Dave > > >> -----Original Message----- >> From: sacm-bounces@ietf.org [mailto:sacm-b= ounces@ietf.org] On >> Behalf Of Adam Montville >> Sent: Monday, April 09, 2012 2:33 PM >> To: 'sacm@ietf.org' >> Subject: [sacm] Status Update Request >> >> All: >> >> The list seems to be rather quiet since the close of IETF 83 more >> than a week ago. Actions coming out of the side meeting held on >> March 24 >> included: >> >> 1. Use Case document first draft by middle of April 2. Use Case >> initial revision by end of April 3. Start of a charter discussion >> around middle of April (after first draft Use Case release) >> >> Dave Waltermire has offered to lead development of the Use Case >> document and Kent Landfield has offered to lead the subsequent >> charter discussion. >> >> Dave/Kent: Do either of you have an update you can share? >> >> Adam >> >> >> >> _______________________________________________ >> sacm mailing list >> sacm@ietf.org >> https://www.ietf.org/mailman/listinfo/sacm _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm --_000_CBA8C1FB307F9kentlandfieldmcafeecom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
What do you= know=85.  SACM is already being valuable. ;-)

Ke= nt Landfield
Director Content Strategy, Architecture and Standards

McAfee | An Intel Company
5000 Headquar= ters Dr.Plano, T= exas 75024=

Direct: += ;1.972.963.7096 
Mobile: +1.817.637.8026
Web: www.mcafee.com
<= /div>

From:= "Polk, William T." <william.polk@nist.gov>
D= ate: Mon, 9 Apr 2012 15:22:25 -0500
To: Tim Keanini <tk= eanini@ncircle.com>, David Waltermire <david.waltermire@nist.gov>, Adam Montville <amontville@tripwire.com>, &= quot;sacm@ietf.org" <sacm@ietf.org>
Subject: Re: [sacm] Status Update Request
= I wish someone would have told me this 14 RFCs ago....

=
Tim
________________________________________

We will certainly need a few ascii diagrams so let me share this link= :

--tk

--
Ti= m "TK" Keanini, CTO    ...   &= nbsp;nCircle Inc.

-----Original Message-----
=
Subject: Re: [sacm] Status Update Re= quest

I can take a stab at that.  It wil= l be useful at minimum to start some
discussion.
Dave

-----Original Message-----
From: Adam Montville [mailto:amontville@tripwire.com]
Sent: Monday, April 09, 2012 2:48 PM
To: Waltermire, David A.;= 'sacm@ietf.org'
Subject: = Re: Status Update Request

Hi Dave,

=
Thanks for sending this out.  I like the abstract and= the structure of

the document so far, so no further commen= ts from me on the abstract.
Are you planning to create a first p= ass at a complete list of use
cases for the document?
=
Adam

On 4/9/12 11:41 AM, "Wa= ltermire, David A." <d= avid.waltermire@nist.gov>
wrote:

>Please find a skeleton I-D of the use case document attached with
>updates to the abstract based on the feedback to date. &nb= sp;If there are
no
>other comments on the abstract= I'll start work on the introduction
>and we can start breaki= ng out use cases and authors for each use
case.
>
= >Sincerely,
>Dave
>
>
>> -----Original Message-----
>= ;> Behalf Of Adam Montville
>> Sent: Monday, April 09, = 2012 2:33 PM
>> Subject: [sacm] Status Update Request
>>
>> All:
>>
= >> The list seems to be rather quiet since the close of IETF 83 more<= /div>
>> than a week ago.  Actions coming out of the s= ide meeting held on
>> March 24
>> includ= ed:
>>
>> 1. Use Case document first draf= t by middle of April 2. Use Case
>> initial revision by en= d of April 3. Start of a charter discussion
>> around midd= le of April (after first draft Use Case release)
>>
<= div> >> Dave Waltermire has offered to lead development of the Use Ca= se
>> document and Kent Landfield has offered to lead the = subsequent
>> charter discussion.
>>
>> Dave/Kent: Do either of you have an update you can share?
>>
>> Adam
>>
= >>
>>
>> __________________________= _____________________
>> sacm mailing list


_______________________________________________
sacm mailin= g list
https://www.ietf.= org/mailman/listinfo/sacm
___________________________________= ____________
sacm mailing list
_= ______________________________________________
= --_000_CBA8C1FB307F9kentlandfieldmcafeecom_-- From kathleen.moriarty@emc.com Mon Apr 9 15:05:31 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7239B21F881D for ; Mon, 9 Apr 2012 15:05:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hcVW105PSt1D for ; Mon, 9 Apr 2012 15:05:28 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 83C4821F881C for ; Mon, 9 Apr 2012 15:05:28 -0700 (PDT) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q39M5Ijw025180 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Apr 2012 18:05:26 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.221.251]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Mon, 9 Apr 2012 18:05:07 -0400 Received: from mxhub19.corp.emc.com (mxhub19.corp.emc.com [10.254.93.48]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q39M55WM032322; Mon, 9 Apr 2012 18:05:06 -0400 Received: from mx06a.corp.emc.com ([169.254.1.106]) by mxhub19.corp.emc.com ([10.254.93.48]) with mapi; Mon, 9 Apr 2012 18:05:06 -0400 From: To: , , , , , Date: Mon, 9 Apr 2012 18:05:04 -0400 Thread-Topic: [sacm] Status Update Request Thread-Index: Ac0WkUc039HCnVBhSXaBPoFVpXFMkAAC3tjQ Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_AE31510960917D478171C79369B660FA0E7CAAE9B0MX06Acorpemcc_" MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [sacm] Status Update Request X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 22:05:31 -0000 --_000_AE31510960917D478171C79369B660FA0E7CAAE9B0MX06Acorpemcc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Wow, I wish I knew about that sooner as well. Thanks, TK! Kathleen From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Ken= t_Landfield@McAfee.com Sent: Monday, April 09, 2012 4:43 PM To: william.polk@nist.gov; tkeanini@ncircle.com; david.waltermire@nist.gov;= amontville@tripwire.com; sacm@ietf.org Subject: Re: [sacm] Status Update Request What do you know.... SACM is already being valuable. ;-) Kent Landfield Director Content Strategy, Architecture and Standards McAfee | An Intel Company 5000 Headquarters Dr. Plano, Texas 75024 Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: "Polk, William T." > Date: Mon, 9 Apr 2012 15:22:25 -0500 To: Tim Keanini >, David = Waltermire >, A= dam Montville >, "s= acm@ietf.org" > Subject: Re: [sacm] Status Update Request I wish someone would have told me this 14 RFCs ago.... Tim ________________________________________ From: sacm-bounces@ietf.org [sacm-bounces@iet= f.org] On Behalf Of Tim Keanini [tkeanini@nci= rcle.com] Sent: Monday, April 09, 2012 4:14 PM To: Waltermire, David A.; Adam Montville; sacm@ietf.org Subject: Re: [sacm] Status Update Request We will certainly need a few ascii diagrams so let me share this link: http://www.asciiflow.com/ --tk -- Tim "TK" Keanini, CTO ... nCircle Inc. -----Original Message----- From: sacm-bounces@ietf.org [mailto:sacm-boun= ces@ietf.org] On Behalf Of Waltermire, David A. Sent: Monday, April 09, 2012 2:04 PM To: Adam Montville; 'sacm@ietf.org' Subject: Re: [sacm] Status Update Request I can take a stab at that. It will be useful at minimum to start some discussion. Dave -----Original Message----- From: Adam Montville [mailto:amontville@tripwire.com] Sent: Monday, April 09, 2012 2:48 PM To: Waltermire, David A.; 'sacm@ietf.org' Subject: Re: Status Update Request Hi Dave, Thanks for sending this out. I like the abstract and the structure of the document so far, so no further comments from me on the abstract. Are you planning to create a first pass at a complete list of use cases for the document? Adam On 4/9/12 11:41 AM, "Waltermire, David A." > wrote: >Please find a skeleton I-D of the use case document attached with >updates to the abstract based on the feedback to date. If there are no >other comments on the abstract I'll start work on the introduction >and we can start breaking out use cases and authors for each use case. > >Sincerely, >Dave > > >> -----Original Message----- >> From: sacm-bounces@ietf.org [mailto:sacm-b= ounces@ietf.org] On >> Behalf Of Adam Montville >> Sent: Monday, April 09, 2012 2:33 PM >> To: 'sacm@ietf.org' >> Subject: [sacm] Status Update Request >> >> All: >> >> The list seems to be rather quiet since the close of IETF 83 more >> than a week ago. Actions coming out of the side meeting held on >> March 24 >> included: >> >> 1. Use Case document first draft by middle of April 2. Use Case >> initial revision by end of April 3. Start of a charter discussion >> around middle of April (after first draft Use Case release) >> >> Dave Waltermire has offered to lead development of the Use Case >> document and Kent Landfield has offered to lead the subsequent >> charter discussion. >> >> Dave/Kent: Do either of you have an update you can share? >> >> Adam >> >> >> >> _______________________________________________ >> sacm mailing list >> sacm@ietf.org >> https://www.ietf.org/mailman/listinfo/sacm _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm --_000_AE31510960917D478171C79369B660FA0E7CAAE9B0MX06Acorpemcc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Wow, I wish I knew about that sooner as well.  <= /span>

 

Thanks, TK!

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F= 497D'> 

Kathleen=

 

From: sacm-bounces@ietf.org [mailto:sacm-bou= nces@ietf.org] On Behalf Of Kent_Landfield@McAfee.com
Sent: Monday, April 09, 2012 4:43 PM
To: william.polk@nist.gov; tkean= ini@ncircle.com; david.waltermire@nist.gov; amontville@tripwire.com; sacm@i= etf.org
Subject: Re: [sacm] Status Update Request

 

=

What do you know…. &= nbsp;SACM is already being valuable. ;-)

 

=

Kent Landfield
Director Content Strategy, Archi= tecture and Standards

McAfee | An Intel Company
5000 Headquarters Dr.
Plano, Texas 75024

Dir= ect: +1.972.963.7096 
Mobile:= +1.817.637.8026
Web: www.mcafee.com

 

From: "Polk, Willia= m T." <william.polk@nist.g= ov>
Date: Mon, 9 Apr 2012 15:22:25 -0500
To: Tim= Keanini <tkeanini@ncircle.com>, David Waltermire <d= avid.waltermire@nist.gov>, Adam Montville <amontville@tripwire.com>, "sacm@ietf.org" <sacm@ietf.org>
Subject: Re: [sacm] Status Update Reque= st

 

I wish someone would ha= ve told me this 14 RFCs ago....

 

Tim

______________= __________________________

<= p class=3DMsoNormal>Sent: Monday, April 09, 201= 2 4:14 PM

To: Waltermire, David A.; Adam Montville; sacm@ietf.org

Subject: Re: [sacm] Status Update = Request

 

<= span style=3D'color:black'>We will certainly need a few ascii diagrams so l= et me share this link:

=  

--tk

 

--

T= im "TK" Keanini, CTO    ...   =  nCircle Inc.

 

-----Original Message-----=

Waltermire, David A.

Sent: Monday, April 09, 2012 2:04 = PM

To: Adam Montville; 'sacm@ietf.o= rg'

Subject: Re: [sacm] Status Update Request

 

= I can take a stab at that.  It will be useful at minimum to start= some

discussion.

Dave

 

=

-= ----Original Message-----

From: Adam Montville [mailto:amontville@tripwire.com]=

Sent: Monda= y, April 09, 2012 2:48 PM

To: Waltermire, David A.; 'sacm@ietf.org'

Subject: Re: Status Update Reque= st

 

Hi Dave,

 

Thanks for sending this o= ut.  I like the abstract and the structure of

=  

the document so far, so no further comment= s from me on the abstract.

Are you planning to create a first pass at= a complete list of use

cases for the document?

=

 

Ad= am

 

On 4/9/12 11:41 AM, "Waltermire, David A." = <david.waltermire@nist.gov<= /a>>

=

>Sincerely,

= >Dave

> 

> 

>> -----Original M= essage-----

>> Behalf Of Adam Montville

= >> Sent: Monday, April 09, 2012 2:33 PM

>> To: 'sacm@ietf.org'

>> Subject: [sacm] = Status Update Request

= >> 

=

>> All:

>&g= t; 

>> The list seems to be rather quiet since the close= of IETF 83 more

>> than a week ago.  Actions coming = out of the side meeting held on

>> March 24

>> incl= uded:

>> 

>> 1. Use Case document first draft = by middle of April 2. Use Case

>> initial revision by end of Ap= ril 3. Start of a charter discussion

>> around middle of April = (after first draft Use Case release)

>> =

>> Da= ve Waltermire has offered to lead development of the Use Case

>>= ; document and Kent Landfield has offered to lead the subsequent=

>= > charter discussion.

>> 

>> Dave/Kent: Do = either of you have an update you can share?

>> =

>= > Adam

>> 

>> 

<= /div>

>>&nb= sp;

>> _______________________________________________

>>= ; sacm mailing list

 

_______________________________________________=

sacm mailing list

__________________________________= _____________

sacm mailing list

https://www.ietf.org/mailman/listinfo/sacm

<= /div>

________________= _______________________________

sacm mailing list

 

<= /html>= --_000_AE31510960917D478171C79369B660FA0E7CAAE9B0MX06Acorpemcc_-- From solin@farnamhallventures.com Mon Apr 9 15:38:30 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AC1C21F87F7 for ; Mon, 9 Apr 2012 15:38:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rrfDTA63J0ZO for ; Mon, 9 Apr 2012 15:38:28 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 258EF21F87F3 for ; Mon, 9 Apr 2012 15:38:27 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so7197907obb.31 for ; Mon, 09 Apr 2012 15:38:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type:x-gm-message-state; bh=Y+S9IAEQz7jQnm5BiJMiDoGnFMlKZi6W8u5TzSfd0D4=; b=JXqFa3sV64+6m9SbojJetwyGCg5TmV3KTkGJPpAmyl5avT92NeXxbetQGgunzq4l4m B8w/rBbzPRZqY2DupnMZMsKR5im9CImrd468GNY0AaYJJ6VR7st7mCFj1Xlf1O8/eVTG JYhHz4/nY1P++Nf7ruyvrw5X+D347U558dk8hwGEw3GAWUgJQuvMjnggU9csnUcj8+2L Bg6PPtQYZrLJlCItNb46BpdN0iMXTKTGwL2vXI8cg06WBj9A9GU4NrVGrEinv7Ctyes8 WPqVyL1o4KSD53KVI445vN3FR3ciMm57OxwEli1kEFWVsj6hiEB9SuxoFCIhtrg00bZG nHpA== Received: by 10.60.28.137 with SMTP id b9mr12835760oeh.57.1334011107271; Mon, 09 Apr 2012 15:38:27 -0700 (PDT) Received: from [192.168.0.113] (cpe-70-123-137-202.austin.res.rr.com. [70.123.137.202]) by mx.google.com with ESMTPS id hh2sm10247139obb.1.2012.04.09.15.38.25 (version=SSLv3 cipher=OTHER); Mon, 09 Apr 2012 15:38:26 -0700 (PDT) Sender: David Solin Message-ID: <4F8364DF.5090809@joval.org> Date: Mon, 09 Apr 2012 17:38:23 -0500 From: David Solin Organization: jOVAL User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: sacm@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------020108000708050905070409" X-Gm-Message-State: ALoCoQnVFtE6y6CNwEQM66HHtWHtANWeds2gklniFLgA/diGVK0xerx5XBnzIpbqxOvlNHKw6rEW Subject: Re: [sacm] Status Update Request X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 22:38:30 -0000 This is a multi-part message in MIME format. --------------020108000708050905070409 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit That is very neat, but I also have a question on the original topic... Was there any discussion at the meeting in Paris on Asset Identification vs. CIM, or has anyone identified a use-case for AI for which CIM is not appropriate? For the sake of making SACM easily adoptable by large enterprises with existing CMDB implementations, I strongly advocate abandoning AI in favor of CIM. I'd be happy to discuss how BMC, IBM, HP, CA, etc. have been making CIM the centerpiece of their systems management offerings for most of the past decade. Regards, --David Solin -- jOVAL.org: OVAL implemented in Java. /Scan any machine from any machine. For free!/ Learn More | Features | Download On 4/9/2012 3:43 PM, Kent_Landfield@McAfee.com wrote: > What do you know.... SACM is already being valuable. ;-) > > *Kent Landfield* > Director Content Strategy, Architecture and Standards > > *McAfee | An Intel Company* > 5000 Headquarters Dr. > Plano, Texas 75024 > > Direct: +1.972.963.7096 > Mobile: +1.817.637.8026 > *Web: *www.mcafee.com > > From: "Polk, William T." > > Date: Mon, 9 Apr 2012 15:22:25 -0500 > To: Tim Keanini >, > David Waltermire >, Adam Montville > >, > "sacm@ietf.org " > > Subject: Re: [sacm] Status Update Request > > I wish someone would have told me this 14 RFCs ago.... > > Tim > ________________________________________ > From: sacm-bounces@ietf.org > [sacm-bounces@ietf.org ] On Behalf > Of Tim Keanini [tkeanini@ncircle.com ] > Sent: Monday, April 09, 2012 4:14 PM > To: Waltermire, David A.; Adam Montville; sacm@ietf.org > > Subject: Re: [sacm] Status Update Request > > We will certainly need a few ascii diagrams so let me share this link: > http://www.asciiflow.com/ > > --tk > > -- > Tim "TK" Keanini, CTO ... nCircle Inc. > > -----Original Message----- > From: sacm-bounces@ietf.org > [mailto:sacm-bounces@ietf.org] On Behalf Of > Waltermire, David A. > Sent: Monday, April 09, 2012 2:04 PM > To: Adam Montville; 'sacm@ietf.org ' > Subject: Re: [sacm] Status Update Request > > I can take a stab at that. It will be useful at minimum to start some > discussion. > Dave > > -----Original Message----- > From: Adam Montville [mailto:amontville@tripwire.com] > Sent: Monday, April 09, 2012 2:48 PM > To: Waltermire, David A.; 'sacm@ietf.org > ' > Subject: Re: Status Update Request > > Hi Dave, > > Thanks for sending this out. I like the abstract and the > structure of > > > the document so far, so no further comments from me on the > abstract. > Are you planning to create a first pass at a complete list of use > cases for the document? > > Adam > > On 4/9/12 11:41 AM, "Waltermire, David A." > > > wrote: > > >Please find a skeleton I-D of the use case document attached with > >updates to the abstract based on the feedback to date. If > there are > no > >other comments on the abstract I'll start work on the introduction > >and we can start breaking out use cases and authors for each use > > case. > > > > >Sincerely, > >Dave > > > > > >> -----Original Message----- > >> From: sacm-bounces@ietf.org > [mailto:sacm-bounces@ietf.org] On > >> Behalf Of Adam Montville > >> Sent: Monday, April 09, 2012 2:33 PM > >> To: 'sacm@ietf.org ' > >> Subject: [sacm] Status Update Request > >> > >> All: > >> > >> The list seems to be rather quiet since the close of IETF 83 > more > >> than a week ago. Actions coming out of the side meeting held on > >> March 24 > >> included: > >> > >> 1. Use Case document first draft by middle of April 2. Use Case > >> initial revision by end of April 3. Start of a charter > discussion > >> around middle of April (after first draft Use Case release) > >> > >> Dave Waltermire has offered to lead development of the Use Case > >> document and Kent Landfield has offered to lead the subsequent > >> charter discussion. > >> > >> Dave/Kent: Do either of you have an update you can share? > >> > >> Adam > >> > >> > >> > >> _______________________________________________ > >> sacm mailing list > >> sacm@ietf.org > >> https://www.ietf.org/mailman/listinfo/sacm > > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > > > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm --------------020108000708050905070409 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit That is very neat, but I also have a question on the original topic...

Was there any discussion at the meeting in Paris on Asset Identification vs. CIM, or has anyone identified a use-case for AI for which CIM is not appropriate?  For the sake of making SACM easily adoptable by large enterprises with existing CMDB implementations, I strongly advocate abandoning AI in favor of CIM.  I'd be happy to discuss how BMC, IBM, HP, CA, etc. have been making CIM the centerpiece of their systems management offerings for most of the past decade.

Regards,
--David Solin


--

jOVAL.org: OVAL implemented in Java.
Scan any machine from any machine. For free!
Learn More | Features | Download



On 4/9/2012 3:43 PM, Kent_Landfield@McAfee.com wrote:
What do you know….  SACM is already being valuable. ;-)

Kent Landfield
Director Content Strategy, Architecture and Standards

McAfee | An Intel Company
5000 Headquarters Dr.
Plano, Texas 75024

Direct: +1.972.963.7096 
Mobile: +1.817.637.8026
Web: www.mcafee.com

From: "Polk, William T." <william.polk@nist.gov>
Date: Mon, 9 Apr 2012 15:22:25 -0500
To: Tim Keanini <tkeanini@ncircle.com>, David Waltermire <david.waltermire@nist.gov>, Adam Montville <amontville@tripwire.com>, "sacm@ietf.org" <sacm@ietf.org>
Subject: Re: [sacm] Status Update Request

I wish someone would have told me this 14 RFCs ago....

Tim
________________________________________
Sent: Monday, April 09, 2012 4:14 PM
To: Waltermire, David A.; Adam Montville; sacm@ietf.org
Subject: Re: [sacm] Status Update Request

We will certainly need a few ascii diagrams so let me share this link:

--tk

--
Tim "TK" Keanini, CTO    ...    nCircle Inc.

-----Original Message-----
Waltermire, David A.
Sent: Monday, April 09, 2012 2:04 PM
To: Adam Montville; 'sacm@ietf.org'
Subject: Re: [sacm] Status Update Request

I can take a stab at that.  It will be useful at minimum to start some
discussion.
Dave

-----Original Message-----
From: Adam Montville [mailto:amontville@tripwire.com]
Sent: Monday, April 09, 2012 2:48 PM
To: Waltermire, David A.; 'sacm@ietf.org'
Subject: Re: Status Update Request

Hi Dave,

Thanks for sending this out.  I like the abstract and the structure of

the document so far, so no further comments from me on the abstract.
Are you planning to create a first pass at a complete list of use
cases for the document?

Adam

On 4/9/12 11:41 AM, "Waltermire, David A." <david.waltermire@nist.gov>
wrote:

>Please find a skeleton I-D of the use case document attached with
>updates to the abstract based on the feedback to date.  If there are
no
>other comments on the abstract I'll start work on the introduction
>and we can start breaking out use cases and authors for each use
case.
>
>Sincerely,
>Dave
>
>
>> -----Original Message-----
>> Behalf Of Adam Montville
>> Sent: Monday, April 09, 2012 2:33 PM
>> Subject: [sacm] Status Update Request
>>
>> All:
>>
>> The list seems to be rather quiet since the close of IETF 83 more
>> than a week ago.  Actions coming out of the side meeting held on
>> March 24
>> included:
>>
>> 1. Use Case document first draft by middle of April 2. Use Case
>> initial revision by end of April 3. Start of a charter discussion
>> around middle of April (after first draft Use Case release)
>>
>> Dave Waltermire has offered to lead development of the Use Case
>> document and Kent Landfield has offered to lead the subsequent
>> charter discussion.
>>
>> Dave/Kent: Do either of you have an update you can share?
>>
>> Adam
>>
>>
>>
>> _______________________________________________
>> sacm mailing list


_______________________________________________
sacm mailing list
_______________________________________________
sacm mailing list
_______________________________________________
sacm mailing list

 

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


--------------020108000708050905070409-- From amontville@tripwire.com Mon Apr 9 16:01:37 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21BD221F8698 for ; Mon, 9 Apr 2012 16:01:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1kYWfQVTuUiG for ; Mon, 9 Apr 2012 16:01:36 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe003.messaging.microsoft.com [216.32.181.183]) by ietfa.amsl.com (Postfix) with ESMTP id 188B921F84C9 for ; Mon, 9 Apr 2012 16:01:35 -0700 (PDT) Received: from mail223-ch1-R.bigfish.com (10.43.68.238) by CH1EHSOBE009.bigfish.com (10.43.70.59) with Microsoft SMTP Server id 14.1.225.23; Mon, 9 Apr 2012 23:01:35 +0000 Received: from mail223-ch1 (localhost [127.0.0.1]) by mail223-ch1-R.bigfish.com (Postfix) with ESMTP id 0D3D74600A5; Mon, 9 Apr 2012 23:01:35 +0000 (UTC) X-SpamScore: -51 X-BigFish: VPS-51(zzbb2dI9371I9f17R542M1432N98dK148cMzz1202hzz1033IL8275bh8275dhz2dh2a8h668h839h946h) X-Forefront-Antispam-Report: CIP:174.47.84.216; KIP:(null); UIP:(null); IPV:NLI; H:PDXHB01.tripwire.com; RD:174-47-84-216.static.twtelecom.net; EFVD:NLI Received: from mail223-ch1 (localhost.localdomain [127.0.0.1]) by mail223-ch1 (MessageSwitch) id 1334012493541543_2624; Mon, 9 Apr 2012 23:01:33 +0000 (UTC) Received: from CH1EHSMHS019.bigfish.com (snatpool3.int.messaging.microsoft.com [10.43.68.225]) by mail223-ch1.bigfish.com (Postfix) with ESMTP id 75FF644005D; Mon, 9 Apr 2012 23:01:33 +0000 (UTC) Received: from PDXHB01.tripwire.com (174.47.84.216) by CH1EHSMHS019.bigfish.com (10.43.70.19) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 9 Apr 2012 23:01:32 +0000 Received: from PDXHB01.tripwire.com (172.30.0.53) by PDXED01.tripwire.com (192.168.192.5) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 9 Apr 2012 16:11:08 -0700 Received: from PDXMB02.tripwire.com ([fe80::f997:7b65:8e64:438e]) by PDXHB01.tripwire.com ([fe80::d495:98d2:7df4:2154%11]) with mapi id 14.01.0355.002; Mon, 9 Apr 2012 16:01:31 -0700 From: Adam Montville To: David Solin , "sacm@ietf.org" Thread-Topic: [sacm] Status Update Request Thread-Index: AQHNFo7sgNZE573VuE2gr5+p07KFmJaTavEAgAAgOoD//5EZgA== Date: Mon, 9 Apr 2012 23:01:31 +0000 Message-ID: In-Reply-To: <4F8364DF.5090809@joval.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [172.30.0.234] x-exclaimer-md-config: 79afcaa7-fdf4-4fa6-abe0-afeaa4640a4f Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: tripwire.com Subject: Re: [sacm] Status Update Request X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 23:01:37 -0000 Hi David, I would be interested in learning more about CIM and any benefit it may off= er our efforts. I anticipate that there will be many similar discussions a= long these lines, and we will all benefit from a deeper understanding of ex= isting standards/specifications, specifically where they overlap and where = they differ. In that spirit, can you provide more detail about where you see the overlap= between CIM and AI for the list? Regards, Adam From: David Solin > Organization: jOVAL Date: Mon, 9 Apr 2012 17:38:23 -0500 To: > Subject: Re: [sacm] Status Update Request That is very neat, but I also have a question on the original topic... Was there any discussion at the meeting in Paris on Asset Identification vs= . CIM, or has anyone identified a use-case for AI for which CIM is not appr= opriate? For the sake of making SACM easily adoptable by large enterprises= with existing CMDB implementations, I strongly advocate abandoning AI in f= avor of CIM. I'd be happy to discuss how BMC, IBM, HP, CA, etc. have been = making CIM the centerpiece of their systems management offerings for most o= f the past decade. Regards, --David Solin -- jOVAL.org: OVAL implemented in Java. Scan any machine from any machine. For free! Learn More | Features= | Download On 4/9/2012 3:43 PM, Kent_Landfield@McAfee.com wrote: What do you know=85. SACM is already being valuable. ;-) Kent Landfield Director Content Strategy, Architecture and Standards McAfee | An Intel Company 5000 Headquarters Dr. Plano, Texas 75024 Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: "Polk, William T." > Date: Mon, 9 Apr 2012 15:22:25 -0500 To: Tim Keanini >, David = Waltermire >, A= dam Montville >, "s= acm@ietf.org" > Subject: Re: [sacm] Status Update Request I wish someone would have told me this 14 RFCs ago.... Tim ________________________________________ From: sacm-bounces@ietf.org [sacm-bounces@iet= f.org] On Behalf Of Tim Keanini [tkeanini@nci= rcle.com] Sent: Monday, April 09, 2012 4:14 PM To: Waltermire, David A.; Adam Montville; sacm@ietf.org Subject: Re: [sacm] Status Update Request We will certainly need a few ascii diagrams so let me share this link: http://www.asciiflow.com/ --tk -- Tim "TK" Keanini, CTO ... nCircle Inc. -----Original Message----- From: sacm-bounces@ietf.org [mailto:sacm-boun= ces@ietf.org] On Behalf Of Waltermire, David A. Sent: Monday, April 09, 2012 2:04 PM To: Adam Montville; 'sacm@ietf.org' Subject: Re: [sacm] Status Update Request I can take a stab at that. It will be useful at minimum to start some discussion. Dave -----Original Message----- From: Adam Montville [mailto:amontville@tripwire.com] Sent: Monday, April 09, 2012 2:48 PM To: Waltermire, David A.; 'sacm@ietf.org' Subject: Re: Status Update Request Hi Dave, Thanks for sending this out. I like the abstract and the structure of the document so far, so no further comments from me on the abstract. Are you planning to create a first pass at a complete list of use cases for the document? Adam On 4/9/12 11:41 AM, "Waltermire, David A." > wrote: >Please find a skeleton I-D of the use case document attached with >updates to the abstract based on the feedback to date. If there are no >other comments on the abstract I'll start work on the introduction >and we can start breaking out use cases and authors for each use case. > >Sincerely, >Dave > > >> -----Original Message----- >> From: sacm-bounces@ietf.org [mailto:sacm-b= ounces@ietf.org] On >> Behalf Of Adam Montville >> Sent: Monday, April 09, 2012 2:33 PM >> To: 'sacm@ietf.org' >> Subject: [sacm] Status Update Request >> >> All: >> >> The list seems to be rather quiet since the close of IETF 83 more >> than a week ago. Actions coming out of the side meeting held on >> March 24 >> included: >> >> 1. Use Case document first draft by middle of April 2. Use Case >> initial revision by end of April 3. Start of a charter discussion >> around middle of April (after first draft Use Case release) >> >> Dave Waltermire has offered to lead development of the Use Case >> document and Kent Landfield has offered to lead the subsequent >> charter discussion. >> >> Dave/Kent: Do either of you have an update you can share? >> >> Adam >> >> >> >> _______________________________________________ >> sacm mailing list >> sacm@ietf.org >> https://www.ietf.org/mailman/listinfo/sacm _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm _______________________________________________ sacm mailing list sacm@ietf.orghttps://www.ietf.org/mailman/listinfo/sa= cm _______________________________________________ sacm mailing list sacm@ietf= .org https://www.ietf.org/mailman/listinfo/sacm From solin@farnamhallventures.com Mon Apr 9 18:09:00 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E68411E8074 for ; Mon, 9 Apr 2012 18:09:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ggOuLnq3wqJ3 for ; Mon, 9 Apr 2012 18:08:58 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id BA9D221F87A4 for ; Mon, 9 Apr 2012 18:08:58 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so7365034obb.31 for ; Mon, 09 Apr 2012 18:08:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:message-id:date:from:organization:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type:x-gm-message-state; bh=a8GQLZR4/xzUFmdvw+5LwN8VE1yHcxOE/7dS7pJBhpU=; b=TQ/TADS/lmILybAGvKqsY04fVTicL5Ul47SmVByAdB/JB1K6Wdka85fPQGL8gGMgmg NkPO0t4AmidVkTkkMhOW3MUcGERbRIpAovSl2DRdF9Tlk0ZC0nOBBjLJJOYxhdUdPs/F mgN9+f/3quOSho3s38cWhJ4xygHvCn9iw+eBp3Q7elGmE+mRAjFZj93DRiHSlkgCZtMu nTuou5HsFtTme8u2B/UmaZaXVD5x3//v/Wmk7GAQmJi3/b+92jUngC3F/rEQf8f/vOld ncxv0bJ2TJ4Q8+QZRgsnyEDfE632oB/hy1CHaaI174rtpkYTt6gf9oFRkJdNUYbMgp9w y17A== Received: by 10.182.136.41 with SMTP id px9mr13425734obb.21.1334020138067; Mon, 09 Apr 2012 18:08:58 -0700 (PDT) Received: from [192.168.0.113] (cpe-70-123-137-202.austin.res.rr.com. [70.123.137.202]) by mx.google.com with ESMTPS id r8sm14300478oer.6.2012.04.09.18.08.56 (version=SSLv3 cipher=OTHER); Mon, 09 Apr 2012 18:08:56 -0700 (PDT) Sender: David Solin Message-ID: <4F838826.7030709@joval.org> Date: Mon, 09 Apr 2012 20:08:54 -0500 From: David Solin Organization: jOVAL User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Adam Montville References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------090201070304080207080901" X-Gm-Message-State: ALoCoQm5x2i3CgO8e8mPTAI74YT09IjjBcYN0xnhNGLDL4MEIqPhQyF+GZUFB5C9+wLJ2Bwvh/Ve Cc: "sacm@ietf.org" Subject: Re: [sacm] Status Update Request X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 01:09:00 -0000 This is a multi-part message in MIME format. --------------090201070304080207080901 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi Adam, Certainly! NIST describes what AI is supposed to be all about as follows: "Asset identification plays an important role in an organization's ability to quickly correlate different sets of information about assets. This specification provides the necessary constructs to uniquely identify assets based on known identifiers and/or known information about the assets. This specification describes the purpose of asset identification, a data model for identifying assets, methods for identifying assets, and guidance on how to use asset identification. It also identifies a number of known use cases for asset identification." Large systems management vendors and their customers have had the same problem for many years. A vendor may sell a number of different products (which were developed by companies they acquired), such as an asset management system, an automation system, a change management system, a monitoring and event management system, a helpdesk system, and so on. Since, in the case of every large systems management product vendor, these products were developed independent of one-another, there has always been a fairly strong need to be able to correlate information between them. For instance, if a user creates a helpdesk ticket because he's having problem with email, there is a need for an IT administrator to be able to correlate events that might be happening on an Exchange Server, with an automated patch distribution job, with the owning organization for those assets (for chargeback purposes), and back to the helpdesk ticket -- so that response times established in service level agreements can be tracked and measured appropriately. The large ISVs have addressed this market need by taking direction from ITIL and creating (so-called) CMDB products. These products provide an authoritative system of record about (1) configuration items (AKA a CI; in ITIL, any object whose configuration must be managed independently of other CIs is a CI), and (2) relationships between CIs, particularly service models/service dependencies. The individual point products in a "solution" generally sync up with a "federated" CMDB using an ETL process, and must complete a two-way exchange of information that makes it possible to: (1) associate any item in the product with any item in the CMDB, and (2) vice-versa. (A number of factors -- scale, legacy install base, organizational inertia, individual point-product market requirements, interoperability with 3rd-party products, etc. -- make it more or less impossible for all the applications to use the same CMDB natively). So, while most of the information about CIs will still reside in the individual point products, at least the CMDB can function as a central registry containing all the IT services, their SLAs, their relationships to CIs, and CI asset (i.e., ownership) information. It seems to me, therefore, that any use-case that exists for Asset Identification must already exist for CMDBs. At the same time, while I am aware of no products currently using AI for any purpose, I am aware of several particularly large ones that include CMDBs (BMC/Remedy/BladeLogic, HP/Opsware, IBM/Tivoli, CA/Unicenter ... and all of their partners), and furthermore, every one of these CMDB products is based on a CIM schema. So there is a standard model for describing everything from services, to the objects and configurations upon which they depend, to their consumers. Given the breadth of the protocols included in SCAP, CIM would seem like a ready-made model that is not only capable of tying everything together, but with the added advantage of already being widely used in enterprise systems management product suites. If we do not use CIM natively for these purposes, we will need to create a bridge to translate from AI to CIM so that users will be able to correlate security automation information with assets and services that are already described in their CMDB systems. Best regards, --David Solin On 4/9/2012 6:01 PM, Adam Montville wrote: > Hi David, > > I would be interested in learning more about CIM and any benefit it may offer our efforts. I anticipate that there will be many similar discussions along these lines, and we will all benefit from a deeper understanding of existing standards/specifications, specifically where they overlap and where they differ. > > In that spirit, can you provide more detail about where you see the overlap between CIM and AI for the list? > > Regards, > > Adam > > From: David Solin> > Organization: jOVAL > Date: Mon, 9 Apr 2012 17:38:23 -0500 > To:> > Subject: Re: [sacm] Status Update Request > > That is very neat, but I also have a question on the original topic... > > Was there any discussion at the meeting in Paris on Asset Identification vs. CIM, or has anyone identified a use-case for AI for which CIM is not appropriate? For the sake of making SACM easily adoptable by large enterprises with existing CMDB implementations, I strongly advocate abandoning AI in favor of CIM. I'd be happy to discuss how BMC, IBM, HP, CA, etc. have been making CIM the centerpiece of their systems management offerings for most of the past decade. > > Regards, > --David Solin > > > -- > > jOVAL.org: OVAL implemented in Java. > Scan any machine from any machine. For free! > Learn More | Features | Download > > > On 4/9/2012 3:43 PM, Kent_Landfield@McAfee.com wrote: > What do you know…. SACM is already being valuable. ;-) > > Kent Landfield > Director Content Strategy, Architecture and Standards > > McAfee | An Intel Company > 5000 Headquarters Dr. > Plano, Texas 75024 > > Direct: +1.972.963.7096 > Mobile: +1.817.637.8026 > Web: www.mcafee.com > > From: "Polk, William T."> > Date: Mon, 9 Apr 2012 15:22:25 -0500 > To: Tim Keanini>, David Waltermire>, Adam Montville>, "sacm@ietf.org"> > Subject: Re: [sacm] Status Update Request > > I wish someone would have told me this 14 RFCs ago.... > > Tim > ________________________________________ > From: sacm-bounces@ietf.org [sacm-bounces@ietf.org] On Behalf Of Tim Keanini [tkeanini@ncircle.com] > Sent: Monday, April 09, 2012 4:14 PM > To: Waltermire, David A.; Adam Montville; sacm@ietf.org > Subject: Re: [sacm] Status Update Request > > We will certainly need a few ascii diagrams so let me share this link: > http://www.asciiflow.com/ > > --tk > > -- > Tim "TK" Keanini, CTO ... nCircle Inc. > > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > Waltermire, David A. > Sent: Monday, April 09, 2012 2:04 PM > To: Adam Montville; 'sacm@ietf.org' > Subject: Re: [sacm] Status Update Request > > I can take a stab at that. It will be useful at minimum to start some > discussion. > Dave > > -----Original Message----- > From: Adam Montville [mailto:amontville@tripwire.com] > Sent: Monday, April 09, 2012 2:48 PM > To: Waltermire, David A.; 'sacm@ietf.org' > Subject: Re: Status Update Request > > Hi Dave, > > Thanks for sending this out. I like the abstract and the structure of > > the document so far, so no further comments from me on the abstract. > Are you planning to create a first pass at a complete list of use > cases for the document? > > Adam > > On 4/9/12 11:41 AM, "Waltermire, David A."> > wrote: > >> Please find a skeleton I-D of the use case document attached with >> updates to the abstract based on the feedback to date. If there are > no >> other comments on the abstract I'll start work on the introduction >> and we can start breaking out use cases and authors for each use > case. >> Sincerely, >> Dave >> >> >>> -----Original Message----- >>> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On >>> Behalf Of Adam Montville >>> Sent: Monday, April 09, 2012 2:33 PM >>> To: 'sacm@ietf.org' >>> Subject: [sacm] Status Update Request >>> >>> All: >>> >>> The list seems to be rather quiet since the close of IETF 83 more >>> than a week ago. Actions coming out of the side meeting held on >>> March 24 >>> included: >>> >>> 1. Use Case document first draft by middle of April 2. Use Case >>> initial revision by end of April 3. Start of a charter discussion >>> around middle of April (after first draft Use Case release) >>> >>> Dave Waltermire has offered to lead development of the Use Case >>> document and Kent Landfield has offered to lead the subsequent >>> charter discussion. >>> >>> Dave/Kent: Do either of you have an update you can share? >>> >>> Adam >>> >>> >>> >>> _______________________________________________ >>> sacm mailing list >>> sacm@ietf.org >>> https://www.ietf.org/mailman/listinfo/sacm > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > > > > > _______________________________________________ > sacm mailing list > sacm@ietf.orghttps://www.ietf.org/mailman/listinfo/sacm > > > _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm > -- jOVAL.org: OVAL implemented in Java. /Scan any machine from any machine. For free!/ Learn More | Features | Download --------------090201070304080207080901 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Hi Adam,

Certainly!  NIST describes what AI is supposed to be all about as follows:

"Asset identification plays an important role in an organization's ability to quickly correlate different sets of information about assets. This specification provides the necessary constructs to uniquely identify assets based on known identifiers and/or known information about the assets. This specification describes the purpose of asset identification, a data model for identifying assets, methods for identifying assets, and guidance on how to use asset identification. It also identifies a number of known use cases for asset identification."

Large systems management vendors and their customers have had the same problem for many years.  A vendor may sell a number of different products (which were developed by companies they acquired), such as an asset management system, an automation system, a change management system, a monitoring and event management system, a helpdesk system, and so on.  Since, in the case of every large systems management product vendor, these products were developed independent of one-another, there has always been a fairly strong need to be able to correlate information between them.  For instance, if a user creates a helpdesk ticket because he's having problem with email, there is a need for an IT administrator to be able to correlate events that might be happening on an Exchange Server, with an automated patch distribution job, with the owning organization for those assets (for chargeback purposes), and back to the helpdesk ticket -- so that response times established in service level agreements can be tracked and measured appropriately.

The large ISVs have addressed this market need by taking direction from ITIL and creating (so-called) CMDB products.  These products provide an authoritative system of record about (1) configuration items (AKA a CI; in ITIL, any object whose configuration must be managed independently of other CIs is a CI), and (2) relationships between CIs, particularly service models/service dependencies.  The individual point products in a "solution" generally sync up with a "federated" CMDB using an ETL process, and must complete a two-way exchange of information that makes it possible to: (1) associate any item in the product with any item in the CMDB, and (2) vice-versa.  (A number of factors -- scale, legacy install base, organizational inertia, individual point-product market requirements, interoperability with 3rd-party products, etc. -- make it more or less impossible for all the applications to use the same CMDB natively).

So, while most of the information about CIs will still reside in the individual point products, at least the CMDB can function as a central registry containing all the IT services, their SLAs, their relationships to CIs, and CI asset (i.e., ownership) information.

It seems to me, therefore, that any use-case that exists for Asset Identification must already exist for CMDBs.  At the same time, while I am aware of no products currently using AI for any purpose, I am aware of several particularly large ones that include CMDBs (BMC/Remedy/BladeLogic, HP/Opsware, IBM/Tivoli, CA/Unicenter ... and all of their partners), and furthermore, every one of these CMDB products is based on a CIM schema.  So there is a standard model for describing everything from services, to the objects and configurations upon which they depend, to their consumers.  Given the breadth of the protocols included in SCAP, CIM would seem like a ready-made model that is not only capable of tying everything together, but with the added advantage of already being widely used in enterprise systems management product suites.

If we do not use CIM natively for these purposes, we will need to create a bridge to translate from AI to CIM so that users will be able to correlate security automation information with assets and services that are already described in their CMDB systems.

Best regards,
--David Solin

On 4/9/2012 6:01 PM, Adam Montville wrote: 
Hi David,

I would be interested in learning more about CIM and any benefit it may offer our efforts.  I anticipate that there will be many similar discussions along these lines, and we will all benefit from a deeper understanding of existing standards/specifications, specifically where they overlap and where they differ.

In that spirit, can you provide more detail about where you see the overlap between CIM and AI for the list?

Regards,

Adam

From: David Solin <david@joval.org<mailto:david@joval.org>>
Organization: jOVAL
Date: Mon, 9 Apr 2012 17:38:23 -0500
To: <sacm@ietf.org<mailto:sacm@ietf.org>>
Subject: Re: [sacm] Status Update Request

That is very neat, but I also have a question on the original topic...

Was there any discussion at the meeting in Paris on Asset Identification vs. CIM, or has anyone identified a use-case for AI for which CIM is not appropriate?  For the sake of making SACM easily adoptable by large enterprises with existing CMDB implementations, I strongly advocate abandoning AI in favor of CIM.  I'd be happy to discuss how BMC, IBM, HP, CA, etc. have been making CIM the centerpiece of their systems management offerings for most of the past decade.

Regards,
--David Solin


--

jOVAL.org: OVAL implemented in Java.
Scan any machine from any machine. For free!
Learn More<http://www.joval.org> | Features<http://www.joval.org/features/> | Download<http://www.joval.org/download/>


On 4/9/2012 3:43 PM, Kent_Landfield@McAfee.com<mailto:Kent_Landfield@McAfee.com> wrote:
What do you know….  SACM is already being valuable. ;-)

Kent Landfield
Director Content Strategy, Architecture and Standards

McAfee | An Intel Company
5000 Headquarters Dr.
Plano, Texas 75024

Direct: +1.972.963.7096
Mobile: +1.817.637.8026
Web: www.mcafee.com<http://www.mcafee.com/>

From: "Polk, William T." <william.polk@nist.gov<mailto:william.polk@nist.gov>>
Date: Mon, 9 Apr 2012 15:22:25 -0500
To: Tim Keanini <tkeanini@ncircle.com<mailto:tkeanini@ncircle.com>>, David Waltermire <david.waltermire@nist.gov<mailto:david.waltermire@nist.gov>>, Adam Montville <amontville@tripwire.com<mailto:amontville@tripwire.com>>, "sacm@ietf.org<mailto:sacm@ietf.org>" <sacm@ietf.org<mailto:sacm@ietf.org>>
Subject: Re: [sacm] Status Update Request

I wish someone would have told me this 14 RFCs ago....

Tim
________________________________________
From: sacm-bounces@ietf.org<mailto:sacm-bounces@ietf.org> [sacm-bounces@ietf.org<mailto:sacm-bounces@ietf.org>] On Behalf Of Tim Keanini [tkeanini@ncircle.com<mailto:tkeanini@ncircle.com>]
Sent: Monday, April 09, 2012 4:14 PM
To: Waltermire, David A.; Adam Montville; sacm@ietf.org<mailto:sacm@ietf.org>
Subject: Re: [sacm] Status Update Request

We will certainly need a few ascii diagrams so let me share this link:
http://www.asciiflow.com/

--tk

--
Tim "TK" Keanini, CTO    ...    nCircle Inc.

-----Original Message-----
From: sacm-bounces@ietf.org<mailto:sacm-bounces@ietf.org> [mailto:sacm-bounces@ietf.org] On Behalf Of
Waltermire, David A.
Sent: Monday, April 09, 2012 2:04 PM
To: Adam Montville; 'sacm@ietf.org<mailto:%27sacm@ietf.org>'
Subject: Re: [sacm] Status Update Request

I can take a stab at that.  It will be useful at minimum to start some
discussion.
Dave

-----Original Message-----
From: Adam Montville [mailto:amontville@tripwire.com]
Sent: Monday, April 09, 2012 2:48 PM
To: Waltermire, David A.; 'sacm@ietf.org<mailto:%27sacm@ietf.org>'
Subject: Re: Status Update Request

Hi Dave,

Thanks for sending this out.  I like the abstract and the structure of

the document so far, so no further comments from me on the abstract.
Are you planning to create a first pass at a complete list of use
cases for the document?

Adam

On 4/9/12 11:41 AM, "Waltermire, David A." <david.waltermire@nist.gov<mailto:david.waltermire@nist.gov>>
wrote:


Please find a skeleton I-D of the use case document attached with
updates to the abstract based on the feedback to date.  If there are

no

other comments on the abstract I'll start work on the introduction
and we can start breaking out use cases and authors for each use

case.

Sincerely,
Dave



-----Original Message-----
From: sacm-bounces@ietf.org<mailto:sacm-bounces@ietf.org> [mailto:sacm-bounces@ietf.org] On
Behalf Of Adam Montville
Sent: Monday, April 09, 2012 2:33 PM
To: 'sacm@ietf.org<mailto:%27sacm@ietf.org>'
Subject: [sacm] Status Update Request

All:

The list seems to be rather quiet since the close of IETF 83 more
than a week ago.  Actions coming out of the side meeting held on
March 24
included:

1. Use Case document first draft by middle of April 2. Use Case
initial revision by end of April 3. Start of a charter discussion
around middle of April (after first draft Use Case release)

Dave Waltermire has offered to lead development of the Use Case
document and Kent Landfield has offered to lead the subsequent
charter discussion.

Dave/Kent: Do either of you have an update you can share?

Adam



_______________________________________________
sacm mailing list
sacm@ietf.org<mailto:sacm@ietf.org>
https://www.ietf.org/mailman/listinfo/sacm


_______________________________________________
sacm mailing list
sacm@ietf.org<mailto:sacm@ietf.org>
https://www.ietf.org/mailman/listinfo/sacm
_______________________________________________
sacm mailing list
sacm@ietf.org<mailto:sacm@ietf.org>
https://www.ietf.org/mailman/listinfo/sacm
_______________________________________________
sacm mailing list
sacm@ietf.org<mailto:sacm@ietf.org>
https://www.ietf.org/mailman/listinfo/sacm




_______________________________________________
sacm mailing list
sacm@ietf.org<mailto:sacm@ietf.org>https://www.ietf.org/mailman/listinfo/sacm


_______________________________________________ sacm mailing list sacm@ietf.org<mailto:sacm@ietf.org> https://www.ietf.org/mailman/listinfo/sacm


--

jOVAL.org: OVAL implemented in Java.
Scan any machine from any machine. For free!
Learn More | Features | Download

--------------090201070304080207080901-- From tkeanini@ncircle.com Tue Apr 10 08:36:50 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C6A121F84D7 for ; Tue, 10 Apr 2012 08:36:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zzvaV3MF4Ku7 for ; Tue, 10 Apr 2012 08:36:45 -0700 (PDT) Received: from mail.ncircle.com (mail.ncircle.com [76.247.119.150]) by ietfa.amsl.com (Postfix) with ESMTP id A9E0F21F84D2 for ; Tue, 10 Apr 2012 08:36:43 -0700 (PDT) Received: from corp-mail-sf.ncircle.com (fw-hive-gate-dmz.ncircle.com [76.247.119.129] (may be forged)) by mail.ncircle.com (8.14.4/8.14.4) with ESMTP id q3AFaabv095225 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 10 Apr 2012 08:36:36 -0700 (PDT) (envelope-from tkeanini@ncircle.com) X-DKIM: OpenDKIM Filter v2.5.1 mail.ncircle.com q3AFaabv095225 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ncircle.com; s=key1; t=1334072202; bh=yyt5PHnwc+Hz5S0+coVu5jTKCCLzz09oFxpKDnWIpCg=; h=Subject:Date:In-Reply-To:References:From:To; b=YL4QOjjlVnHYo5E+kzjW1iJ+prcJvrJHfuO3VLK5ZEMtLv8Y+ywlGe3h9N0ruDQhe eILev6yvafWhzVcyjWh0A== Received: from CORP-MAIL.ad.ncircle.com (192.168.75.90) by EXCH-SF-02.ad.ncircle.com (192.168.75.48) with Microsoft SMTP Server id 14.2.283.3; Tue, 10 Apr 2012 08:36:36 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD172F.B65605FF" Date: Tue, 10 Apr 2012 08:36:34 -0700 Message-ID: In-Reply-To: <4F8364DF.5090809@joval.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sacm] Status Update Request Thread-Index: Ac0WoX9lXr/ZX41aQ5OKE4MqNzAujAAC0oXA References: <4F8364DF.5090809@joval.org> From: Tim Keanini To: David Solin , X-Scanned-By: MIMEDefang 2.72 on 76.247.119.150 Subject: Re: [sacm] Status Update Request X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 15:36:50 -0000 ------_=_NextPart_001_01CD172F.B65605FF Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable There are at least two considerations:=20 - Inter-domain multi-sensor data fusion and synthesis - Limitations of discovery (instance data resolution) =20 Inter-domain multi-sensor data fusion and synthesis This is for all practical purposes the inverse-functional-property or primary key syntax match problem. The metadata in AI is designed with the other SCAP metadata in mind whereas CIM was not and while they may share common keys like IP address to perform a join, more and more this is not a stable characteristic of the asset in either domain. Another consideration here is that CIM would not have in it something like a CPE identifier, very common key for synthesis across domains within the SCAP family. My suggestion here is that we not look for a single domain to identify an asset but to ensure that all the data domains (AI, CIM, etc) have in them enough boundary objects to "join" or synthesize multiple domains. We should ensure that all information domains have in it a rich set of stable characteristics that afford syntactical matching of the metadata for the purposes of Inter-domain multi-sensor data fusion and synthesis =20 =20 Limitations of discovery (instance data resolution): Authenticated and Unauthenticated Discovery=20 Remote automated scanning comes in at least two flavors, authenticated-scanning and unauthenticated-scanning. We must keep this in mind as we look to the design or borrow these metadata formats (AI, CIM, etc). Most if not all CMDB assumes the old network management mindset of nodes-under-management and node-not-under-management. The former having an agent installed or some authentication/authorization provided, the latter assumes an assessment of the target via its target surface in an unauthenticated manner. I raise this issue once again because OVAL for example makes no provision for the assessment to take place in an unauthenticated manner. We need to keep this in mind as we look to populate the metadata of AI as certain fields will only be valid for authenticated scanning or an agent. I'm a vendor that has both types of scanners and I must say that for reasons I will not get into here, customers deploy unauthenticated scanners across their entire enterprise and authenticated scanners in targeted scopes. I raise this issue because time and time again, customers come back to us with the unauthenticated scanners having much more identification of end-point assets than any other authenticated scanner. This is a sidebar but I wanted to share this experience having been a supplier of this technology for the past 12 years. =20 =20 =20 -- Tim "TK" Keanini, CTO ... nCircle Inc. ... mbl (415) 328-2722 ... =20 From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of David Solin Sent: Monday, April 09, 2012 5:38 PM To: sacm@ietf.org Subject: Re: [sacm] Status Update Request =20 That is very neat, but I also have a question on the original topic... Was there any discussion at the meeting in Paris on Asset Identification vs. CIM, or has anyone identified a use-case for AI for which CIM is not appropriate? For the sake of making SACM easily adoptable by large enterprises with existing CMDB implementations, I strongly advocate abandoning AI in favor of CIM. I'd be happy to discuss how BMC, IBM, HP, CA, etc. have been making CIM the centerpiece of their systems management offerings for most of the past decade. Regards, --David Solin --=20 jOVAL.org: OVAL implemented in Java. Scan any machine from any machine. For free! Learn More | Features | Download =20 On 4/9/2012 3:43 PM, Kent_Landfield@McAfee.com wrote:=20 What do you know.... SACM is already being valuable. ;-) =20 Kent Landfield Director Content Strategy, Architecture and Standards McAfee | An Intel Company 5000 Headquarters Dr. Plano, Texas 75024 Direct: +1.972.963.7096=20 Mobile: +1.817.637.8026 Web: www.mcafee.com =20 =20 From: "Polk, William T." > Date: Mon, 9 Apr 2012 15:22:25 -0500 To: Tim Keanini >, David Waltermire >, Adam Montville >, "sacm@ietf.org " > Subject: Re: [sacm] Status Update Request =20 I wish someone would have told me this 14 RFCs ago.... =20 Tim ________________________________________ From: sacm-bounces@ietf.org [sacm-bounces@ietf.org] On Behalf Of Tim Keanini [tkeanini@ncircle.com] Sent: Monday, April 09, 2012 4:14 PM To: Waltermire, David A.; Adam Montville; sacm@ietf.org Subject: Re: [sacm] Status Update Request =20 We will certainly need a few ascii diagrams so let me share this link: http://www.asciiflow.com/ =20 --tk =20 -- Tim "TK" Keanini, CTO ... nCircle Inc. =20 -----Original Message----- From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Waltermire, David A. Sent: Monday, April 09, 2012 2:04 PM To: Adam Montville; 'sacm@ietf.org ' Subject: Re: [sacm] Status Update Request =20 I can take a stab at that. It will be useful at minimum to start some discussion. Dave =20 -----Original Message----- From: Adam Montville [mailto:amontville@tripwire.com] Sent: Monday, April 09, 2012 2:48 PM To: Waltermire, David A.; 'sacm@ietf.org ' Subject: Re: Status Update Request =20 Hi Dave, =20 Thanks for sending this out. I like the abstract and the structure of =20 the document so far, so no further comments from me on the abstract. Are you planning to create a first pass at a complete list of use cases for the document? =20 Adam =20 On 4/9/12 11:41 AM, "Waltermire, David A." wrote: =20 >Please find a skeleton I-D of the use case document attached with >updates to the abstract based on the feedback to date. If there are no >other comments on the abstract I'll start work on the introduction >and we can start breaking out use cases and authors for each use case. >=20 >Sincerely, >Dave >=20 >=20 >> -----Original Message----- >> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On >> Behalf Of Adam Montville >> Sent: Monday, April 09, 2012 2:33 PM >> To: 'sacm@ietf.org ' >> Subject: [sacm] Status Update Request >>=20 >> All: >>=20 >> The list seems to be rather quiet since the close of IETF 83 more >> than a week ago. Actions coming out of the side meeting held on >> March 24 >> included: >>=20 >> 1. Use Case document first draft by middle of April 2. Use Case >> initial revision by end of April 3. Start of a charter discussion >> around middle of April (after first draft Use Case release) >>=20 >> Dave Waltermire has offered to lead development of the Use Case >> document and Kent Landfield has offered to lead the subsequent >> charter discussion. >>=20 >> Dave/Kent: Do either of you have an update you can share? >>=20 >> Adam >>=20 >>=20 >>=20 >> _______________________________________________ >> sacm mailing list >> sacm@ietf.org >> https://www.ietf.org/mailman/listinfo/sacm =20 =20 _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm =20 _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm =20 ------_=_NextPart_001_01CD172F.B65605FF Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

There are at least two considerations:

-          = Inter-domain multi-sensor data fusion and = synthesis

-          = Limitations of discovery (instance data = resolution)

 

Inter-domain multi-sensor data fusion and = synthesis

This is for all practical purposes the inverse-functional-property or = primary key syntax match problem.

The metadata in AI is designed with the other SCAP metadata in mind = whereas CIM was not and while they may share common keys like IP address = to perform a join, more and more this is not a stable characteristic of = the asset in either domain.  Another consideration here is that CIM = would not have in it something like a CPE identifier, very common key = for synthesis across domains within the SCAP family.  My suggestion = here is that we not look for a single domain to identify an asset but to = ensure that all the data domains (AI, CIM, etc) have in them enough = boundary objects to “join” or synthesize multiple = domains.  We should ensure that all information domains have in it = a rich set of stable characteristics that afford syntactical matching of = the metadata for the purposes of Inter-domain multi-sensor data fusion = and synthesis

 

 

Limitations of discovery (instance data resolution): Authenticated = and Unauthenticated Discovery

Remote automated scanning comes in at least two flavors, = authenticated-scanning and unauthenticated-scanning.  We must keep = this in mind as we look to the design or borrow these metadata formats = (AI, CIM, etc).  Most if not all CMDB assumes the old network = management mindset of nodes-under-management and = node-not-under-management.  The former having an agent installed or = some authentication/authorization provided, the latter assumes an = assessment of the target via its target surface in an unauthenticated = manner.  I raise this issue once again because OVAL for example = makes no provision for the assessment to take place in an = unauthenticated manner.   We need to keep this in mind as we = look to populate the metadata of AI as certain fields will only be valid = for authenticated scanning or an agent.  I’m a vendor that = has both types of scanners and I must say that for reasons I will not = get into here, customers deploy unauthenticated scanners across their = entire enterprise and authenticated scanners in targeted scopes.  I = raise this issue because time and time again, customers come back to us = with the unauthenticated scanners having much more identification of = end-point assets than any other authenticated scanner.  This is a = sidebar but I wanted to share this experience having been a supplier of = this technology for the past 12 years.  =   

 

 

--

Tim "TK" Keanini, CTO    = …    nCircle Inc.   …   = mbl (415) 328-2722  …

 

From: sacm-bounces@ietf.org = [mailto:sacm-bounces@ietf.= org] On Behalf Of David Solin
Sent: Monday, April = 09, 2012 5:38 PM
To: sacm@ietf.org
Subject: Re: = [sacm] Status Update Request

 

That is very neat, but I also have a = question on the original topic...

Was there any discussion at the = meeting in Paris on Asset Identification vs. CIM, or has anyone = identified a use-case for AI for which CIM is not appropriate?  For = the sake of making SACM easily adoptable by large enterprises with = existing CMDB implementations, I strongly advocate abandoning AI in = favor of CIM.  I'd be happy to discuss how BMC, IBM, HP, CA, etc. = have been making CIM the centerpiece of their systems management = offerings for most of the past decade.

Regards,
--David = Solin

-- =

jOVAL.org: OVAL implemented in Java.=
= Scan any machine from any machine. For free!=
= Learn More= | = Features= | = Download=



On 4/9/2012 = 3:43 PM, Kent_Landfield@McAfee.com = wrote:

What do you = know….  SACM is already being valuable. = ;-)

 

= Kent Landfield=
Director Content Strategy, = Architecture and Standards

McAfee | An Intel = Company
5000 = Headquarters Dr.
Plano, Texas = 75024

Direct: = +1.972.963.7096 
Mobile: = +1.817.637.8026
Web: www.mcafee.com=

 

From: = "Polk,= William T." <william.pol= k@nist.gov>
= Date: Mon, 9 Apr 2012 15:22:25 -0500
To: Tim Keanini = <tkeanini@nc= ircle.com>, = David Waltermire <david.walte= rmire@nist.gov>, Adam = Montville <amontville@= tripwire.com>, = "sacm@ietf.o= rg" = <sacm@ietf.o= rg>
= Subject: Re: [sacm] Status Update = Request

 

I wish someone would have told me this 14 RFCs = ago....

 

Tim

________________________________________

=

Sent: Monday, April 09, 2012 4:14 = PM

To: Waltermire, David = A.; Adam Montville; sacm@ietf.org

=

Subject: Re: [sacm] Status Update = Request

 

We will certainly need a few ascii diagrams so let me = share this link:

 

--tk

 

--

Tim = "TK" Keanini, = CTO    ...    nCircle = Inc.

 

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

Waltermire, = David A.

Sent: Monday, = April 09, 2012 2:04 PM

To: = Adam Montville; 'sacm@ietf.org'

=

Subject: Re: [sacm] Status Update = Request

 

I = can take a stab at that.  It will be useful at minimum to = start some

discussion.

Dave

 

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

From: Adam Montville [mailto:amontville@tripwire.com]

=

Subject: Re: Status Update = Request

 

Hi Dave,

 

Thanks for sending this out.  I like the = abstract and the structure of

 

the document so far, so no further comments from me on = the abstract.

Are you = planning to create a first pass at a complete list of = use

cases for the = document?

 

Adam

 

On 4/9/12 11:41 AM, "Waltermire, David A." = <david.waltermire@nist.gov&g= t;

wrote:

 

>Please find a skeleton I-D of the use case = document attached with

>updates to the abstract based on the feedback to = date.  If there are

no

>other comments on the abstract I'll start work on = the introduction

>and = we can start breaking out use cases and authors for each = use

case.

> 

>Sincerely,

>Dave

> 

> 

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

>> Behalf Of Adam = Montville

>> Sent: = Monday, April 09, 2012 2:33 PM

=

>> Subject: [sacm] Status Update = Request

>> 

>> All:

>> 

>> The list seems to be rather quiet since the = close of IETF 83 more

>> than a week ago.  Actions coming = out of the side meeting held on

>> March 24

>> included:

>> 

>> 1. Use Case document first draft by middle of = April 2. Use Case

>> = initial revision by end of April 3. Start of a charter = discussion

>> around = middle of April (after first draft Use Case = release)

>> 

>> Dave Waltermire has offered to lead = development of the Use Case

>> document and Kent Landfield has offered to = lead the subsequent

>> charter = discussion.

>> 

>> Dave/Kent: Do either of you have an update = you can share?

>> 

>> Adam

>> 

>> 

>> 

>> = _______________________________________________

=

>> sacm mailing = list

 

 

_______________________________________________

sacm mailing = list

_______________________________________________

sacm mailing = list

_______________________________________________

sacm mailing = list

 




_______________________=
________________________
sacm mailing =
list
sacm@ietf.org
https://www.ietf.org/=
mailman/listinfo/sacm

 

------_=_NextPart_001_01CD172F.B65605FF-- From solin@farnamhallventures.com Tue Apr 10 09:49:46 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26C5C11E8128 for ; Tue, 10 Apr 2012 09:49:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_27=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 66qAGxr-LLPt for ; Tue, 10 Apr 2012 09:49:42 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 83DEE11E8123 for ; Tue, 10 Apr 2012 09:49:41 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so2887obb.31 for ; Tue, 10 Apr 2012 09:49:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:message-id:date:from:organization:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type:x-gm-message-state; bh=JZGe8tJSKPYggcYlpclqDkQ2CrfCsDuIwmvihkwbgV4=; b=k6HP9lx9sQJoRBHHHzTLiQCCKUoBndVv0kIBPEzMbXQDmWackxKgz0/F0UwcmZSDNQ cwGq0osQzytfNREYozg8145oyo0jSJTvXWxEHoPeZV+wqXpbEEtkwmm3ZIiwa2EAqetN dbtKcCwlo/2dNbfjSCvdGiyoTcudRcR6BOD2x5oWotR4jpXbohtvA6bz1xjx4oD/zmqV acizdTDCwX7VbuoMBlUro+6AFTfsiZr/ynjw+dUabkIhqTXtWO6/bjn6yEpxcElJ8YIe dLeNlrd8Dv2BJbnrLggloGPVxMGGc2dpgZuq7P937t8XXpRGAtXioc+5XpnCpMwlEZdW DK/A== Received: by 10.182.53.106 with SMTP id a10mr16917824obp.43.1334076580637; Tue, 10 Apr 2012 09:49:40 -0700 (PDT) Received: from [192.168.0.113] (cpe-70-123-137-202.austin.res.rr.com. [70.123.137.202]) by mx.google.com with ESMTPS id yw3sm20296744obb.7.2012.04.10.09.49.38 (version=SSLv3 cipher=OTHER); Tue, 10 Apr 2012 09:49:39 -0700 (PDT) Sender: David Solin Message-ID: <4F84649F.1070406@joval.org> Date: Tue, 10 Apr 2012 11:49:35 -0500 From: David Solin Organization: jOVAL User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Tim Keanini References: <4F8364DF.5090809@joval.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040806040609070304000705" X-Gm-Message-State: ALoCoQnMNQGFI/42SNySkwjwaD2j5kbFHjEuv6szArpZ/wWrdQHitjco01v1E8Cz0D5LAxRzkNhh Cc: sacm@ietf.org Subject: Re: [sacm] Status Update Request X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 16:49:46 -0000 This is a multi-part message in MIME format. --------------040806040609070304000705 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Tim, Addressing the problem of uniqueness certainly does not require an entirely new data model. Existing CMDBs have to solve the problem of multiple discovery sources, as each product interacting with it is potentially another discovery source. BMC's Atrium CMDB, for instance, extends the CIM schema with a reconciliation ID that is used for this purpose, and I imagine that's probably not an uncommon solution. There's no reason we can't have an Asset Identification specification that consists purely of an extension of CIM -- where we can add, for instance, a CPE property to existing classes (e.g., OperatingSystem, DatabaseSystem ... or perhaps just to the System parent class?). Indeed, perhaps that's what you're suggesting? To my eye, the AI specification looks largely like a subset of CIM, except with the addition of the specialized ai:website object (which feels like it should be unnecessary). Why do we want to reinvent the wheel? Regards, --David On 4/10/2012 10:36 AM, Tim Keanini wrote: > > There are at least two considerations: > > -Inter-domain multi-sensor data fusion and synthesis > > -Limitations of discovery (instance data resolution) > > *Inter-domain multi-sensor data fusion and synthesis* > > This is for all practical purposes the inverse-functional-property or > primary key syntax match problem. > > The metadata in AI is designed with the other SCAP metadata in mind > whereas CIM was not and while they may share common keys like IP > address to perform a join, more and more this is not a stable > characteristic of the asset in either domain. Another consideration > here is that CIM would not have in it something like a CPE identifier, > very common key for synthesis across domains within the SCAP family. > My suggestion here is that we not look for a single domain to identify > an asset but to ensure that all the data domains (AI, CIM, etc) have > in them enough boundary objects to "join" or synthesize multiple > domains. We should ensure that all information domains have in it a > rich set of stable characteristics that afford syntactical matching of > the metadata for the purposes of Inter-domain multi-sensor data fusion > and synthesis > > *Limitations of discovery (instance data resolution): Authenticated > and Unauthenticated Discovery * > > Remote automated scanning comes in at least two flavors, > authenticated-scanning and unauthenticated-scanning. We must keep > this in mind as we look to the design or borrow these metadata formats > (AI, CIM, etc). Most if not all CMDB assumes the old network > management mindset of nodes-under-management and > node-not-under-management. The former having an agent installed or > some authentication/authorization provided, the latter assumes an > assessment of the target via its target surface in an unauthenticated > manner. I raise this issue once again because OVAL for example makes > no provision for the assessment to take place in an unauthenticated > manner. We need to keep this in mind as we look to populate the > metadata of AI as certain fields will only be valid for authenticated > scanning or an agent. I'm a vendor that has both types of scanners > and I must say that for reasons I will not get into here, customers > deploy unauthenticated scanners across their entire enterprise and > authenticated scanners in targeted scopes. I raise this issue because > time and time again, customers come back to us with the > unauthenticated scanners having much more identification of end-point > assets than any other authenticated scanner. This is a sidebar but I > wanted to share this experience having been a supplier of this > technology for the past 12 years. > > -- > > Tim "TK" Keanini, CTO ... nCircle Inc. ... mbl (415) > 328-2722 ... > > *From:*sacm-bounces@ietf.org > [mailto:sacm-bounces@ietf.org] > *On Behalf Of *David Solin > *Sent:* Monday, April 09, 2012 5:38 PM > *To:* sacm@ietf.org > *Subject:* Re: [sacm] Status Update Request > > That is very neat, but I also have a question on the original topic... > > Was there any discussion at the meeting in Paris on Asset > Identification vs. CIM, or has anyone identified a use-case for AI for > which CIM is not appropriate? For the sake of making SACM easily > adoptable by large enterprises with existing CMDB implementations, I > strongly advocate abandoning AI in favor of CIM. I'd be happy to > discuss how BMC, IBM, HP, CA, etc. have been making CIM the > centerpiece of their systems management offerings for most of the past > decade. > > Regards, > --David Solin > > -- > > jOVAL.org: OVAL implemented in Java. > /Scan any machine from any machine. For free!/ > Learn More | Features > | Download > > > > > On 4/9/2012 3:43 PM, Kent_Landfield@McAfee.com > wrote: > > What do you know.... SACM is already being valuable. ;-) > > *Kent Landfield* > Director Content Strategy, Architecture and Standards > > *McAfee | An Intel Company* > 5000 Headquarters Dr. > Plano, Texas 75024 > > Direct: +1.972.963.7096 > Mobile: +1.817.637.8026 > *Web: *www.mcafee.com > > *From: *"Polk, William T." > > *Date: *Mon, 9 Apr 2012 15:22:25 -0500 > *To: *Tim Keanini >, David Waltermire > >, Adam > Montville >, > "sacm@ietf.org " > > *Subject: *Re: [sacm] Status Update Request > > I wish someone would have told me this 14 RFCs ago.... > > Tim > > ________________________________________ > > From: sacm-bounces@ietf.org > [sacm-bounces@ietf.org ] On Behalf > Of Tim Keanini [tkeanini@ncircle.com ] > > Sent: Monday, April 09, 2012 4:14 PM > > To: Waltermire, David A.; Adam Montville; sacm@ietf.org > > > Subject: Re: [sacm] Status Update Request > > We will certainly need a few ascii diagrams so let me share this link: > > http://www.asciiflow.com/ > > --tk > > -- > > Tim "TK" Keanini, CTO ... nCircle Inc. > > -----Original Message----- > > From: sacm-bounces@ietf.org > [mailto:sacm-bounces@ietf.org] On Behalf Of > > Waltermire, David A. > > Sent: Monday, April 09, 2012 2:04 PM > > To: Adam Montville; 'sacm@ietf.org ' > > Subject: Re: [sacm] Status Update Request > > I can take a stab at that. It will be useful at minimum to start some > > discussion. > > Dave > > -----Original Message----- > > From: Adam Montville [mailto:amontville@tripwire.com] > > Sent: Monday, April 09, 2012 2:48 PM > > To: Waltermire, David A.; 'sacm@ietf.org > ' > > Subject: Re: Status Update Request > > Hi Dave, > > Thanks for sending this out. I like the abstract and the > structure of > > the document so far, so no further comments from me on the > abstract. > > Are you planning to create a first pass at a complete list of use > > cases for the document? > > Adam > > On 4/9/12 11:41 AM, "Waltermire, David A." > > > > wrote: > > >Please find a skeleton I-D of the use case document attached with > > >updates to the abstract based on the feedback to date. If > there are > > no > > >other comments on the abstract I'll start work on the > introduction > > >and we can start breaking out use cases and authors for each use > > case. > > > > > >Sincerely, > > >Dave > > > > > > > > >> -----Original Message----- > > >> From: sacm-bounces@ietf.org > [mailto:sacm-bounces@ietf.org] On > > >> Behalf Of Adam Montville > > >> Sent: Monday, April 09, 2012 2:33 PM > > >> To: 'sacm@ietf.org ' > > >> Subject: [sacm] Status Update Request > > >> > > >> All: > > >> > > >> The list seems to be rather quiet since the close of IETF > 83 more > > >> than a week ago. Actions coming out of the side meeting > held on > > >> March 24 > > >> included: > > >> > > >> 1. Use Case document first draft by middle of April 2. Use Case > > >> initial revision by end of April 3. Start of a charter > discussion > > >> around middle of April (after first draft Use Case release) > > >> > > >> Dave Waltermire has offered to lead development of the Use Case > > >> document and Kent Landfield has offered to lead the subsequent > > >> charter discussion. > > >> > > >> Dave/Kent: Do either of you have an update you can share? > > >> > > >> Adam > > >> > > >> > > >> > > >> _______________________________________________ > > >> sacm mailing list > > >> sacm@ietf.org > > >> https://www.ietf.org/mailman/listinfo/sacm > > _______________________________________________ > > sacm mailing list > > sacm@ietf.org > > https://www.ietf.org/mailman/listinfo/sacm > > _______________________________________________ > > sacm mailing list > > sacm@ietf.org > > https://www.ietf.org/mailman/listinfo/sacm > > _______________________________________________ > > sacm mailing list > > sacm@ietf.org > > https://www.ietf.org/mailman/listinfo/sacm > > > > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > -- jOVAL.org: OVAL implemented in Java. /Scan any machine from any machine. For free!/ Learn More | Features | Download --------------040806040609070304000705 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Tim,

Addressing the problem of uniqueness certainly does not require an entirely new data model.  Existing CMDBs have to solve the problem of multiple discovery sources, as each product interacting with it is potentially another discovery source.  BMC's Atrium CMDB, for instance, extends the CIM schema with a reconciliation ID that is used for this purpose, and I imagine that's probably not an uncommon solution.  There's no reason we can't have an Asset Identification specification that consists purely of an extension of CIM -- where we can add, for instance, a CPE property to existing classes (e.g., OperatingSystem, DatabaseSystem ... or perhaps just to the System parent class?).  Indeed, perhaps that's what you're suggesting?

To my eye, the AI specification looks largely like a subset of CIM, except with the addition of the specialized ai:website object (which feels like it should be unnecessary).  Why do we want to reinvent the wheel?

Regards,
--David

On 4/10/2012 10:36 AM, Tim Keanini wrote:

There are at least two considerations:

-          Inter-domain multi-sensor data fusion and synthesis

-          Limitations of discovery (instance data resolution)

 

Inter-domain multi-sensor data fusion and synthesis

This is for all practical purposes the inverse-functional-property or primary key syntax match problem.

The metadata in AI is designed with the other SCAP metadata in mind whereas CIM was not and while they may share common keys like IP address to perform a join, more and more this is not a stable characteristic of the asset in either domain.  Another consideration here is that CIM would not have in it something like a CPE identifier, very common key for synthesis across domains within the SCAP family.  My suggestion here is that we not look for a single domain to identify an asset but to ensure that all the data domains (AI, CIM, etc) have in them enough boundary objects to “join” or synthesize multiple domains.  We should ensure that all information domains have in it a rich set of stable characteristics that afford syntactical matching of the metadata for the purposes of Inter-domain multi-sensor data fusion and synthesis

 

 

Limitations of discovery (instance data resolution): Authenticated and Unauthenticated Discovery

Remote automated scanning comes in at least two flavors, authenticated-scanning and unauthenticated-scanning.  We must keep this in mind as we look to the design or borrow these metadata formats (AI, CIM, etc).  Most if not all CMDB assumes the old network management mindset of nodes-under-management and node-not-under-management.  The former having an agent installed or some authentication/authorization provided, the latter assumes an assessment of the target via its target surface in an unauthenticated manner.  I raise this issue once again because OVAL for example makes no provision for the assessment to take place in an unauthenticated manner.   We need to keep this in mind as we look to populate the metadata of AI as certain fields will only be valid for authenticated scanning or an agent.  I’m a vendor that has both types of scanners and I must say that for reasons I will not get into here, customers deploy unauthenticated scanners across their entire enterprise and authenticated scanners in targeted scopes.  I raise this issue because time and time again, customers come back to us with the unauthenticated scanners having much more identification of end-point assets than any other authenticated scanner.  This is a sidebar but I wanted to share this experience having been a supplier of this technology for the past 12 years.    

 

 

--

Tim "TK" Keanini, CTO    …    nCircle Inc.   …   mbl (415) 328-2722  …

 

From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of David Solin
Sent: Monday, April 09, 2012 5:38 PM
To: sacm@ietf.org
Subject: Re: [sacm] Status Update Request

 

That is very neat, but I also have a question on the original topic...

Was there any discussion at the meeting in Paris on Asset Identification vs. CIM, or has anyone identified a use-case for AI for which CIM is not appropriate?  For the sake of making SACM easily adoptable by large enterprises with existing CMDB implementations, I strongly advocate abandoning AI in favor of CIM.  I'd be happy to discuss how BMC, IBM, HP, CA, etc. have been making CIM the centerpiece of their systems management offerings for most of the past decade.

Regards,
--David Solin

--

jOVAL.org: OVAL implemented in Java.
Scan any machine from any machine. For free!
Learn More | Features | Download



On 4/9/2012 3:43 PM, Kent_Landfield@McAfee.com wrote:

What do you know….  SACM is already being valuable. ;-)

 

Kent Landfield
Director Content Strategy, Architecture and Standards

McAfee | An Intel Company
5000 Headquarters Dr.
Plano, Texas 75024

Direct: +1.972.963.7096 
Mobile: +1.817.637.8026
Web: www.mcafee.com

 

From: "Polk, William T." <william.polk@nist.gov>
Date: Mon, 9 Apr 2012 15:22:25 -0500
To: Tim Keanini <tkeanini@ncircle.com>, David Waltermire <david.waltermire@nist.gov>, Adam Montville <amontville@tripwire.com>, "sacm@ietf.org" <sacm@ietf.org>
Subject: Re: [sacm] Status Update Request

 

I wish someone would have told me this 14 RFCs ago....

 

Tim

________________________________________

Sent: Monday, April 09, 2012 4:14 PM

To: Waltermire, David A.; Adam Montville; sacm@ietf.org

Subject: Re: [sacm] Status Update Request

 

We will certainly need a few ascii diagrams so let me share this link:

 

--tk

 

--

Tim "TK" Keanini, CTO    ...    nCircle Inc.

 

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

Waltermire, David A.

Sent: Monday, April 09, 2012 2:04 PM

To: Adam Montville; 'sacm@ietf.org'

Subject: Re: [sacm] Status Update Request

 

I can take a stab at that.  It will be useful at minimum to start some

discussion.

Dave

 

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

From: Adam Montville [mailto:amontville@tripwire.com]

Sent: Monday, April 09, 2012 2:48 PM

To: Waltermire, David A.; 'sacm@ietf.org'

Subject: Re: Status Update Request

 

Hi Dave,

 

Thanks for sending this out.  I like the abstract and the structure of

 

the document so far, so no further comments from me on the abstract.

Are you planning to create a first pass at a complete list of use

cases for the document?

 

Adam

 

On 4/9/12 11:41 AM, "Waltermire, David A." <david.waltermire@nist.gov>

wrote:

 

>Please find a skeleton I-D of the use case document attached with

>updates to the abstract based on the feedback to date.  If there are

no

>other comments on the abstract I'll start work on the introduction

>and we can start breaking out use cases and authors for each use

case.

> 

>Sincerely,

>Dave

> 

> 

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

>> Behalf Of Adam Montville

>> Sent: Monday, April 09, 2012 2:33 PM

>> To: 'sacm@ietf.org'

>> Subject: [sacm] Status Update Request

>> 

>> All:

>> 

>> The list seems to be rather quiet since the close of IETF 83 more

>> than a week ago.  Actions coming out of the side meeting held on

>> March 24

>> included:

>> 

>> 1. Use Case document first draft by middle of April 2. Use Case

>> initial revision by end of April 3. Start of a charter discussion

>> around middle of April (after first draft Use Case release)

>> 

>> Dave Waltermire has offered to lead development of the Use Case

>> document and Kent Landfield has offered to lead the subsequent

>> charter discussion.

>> 

>> Dave/Kent: Do either of you have an update you can share?

>> 

>> Adam

>> 

>> 

>> 

>> _______________________________________________

>> sacm mailing list

 

 

_______________________________________________

sacm mailing list

_______________________________________________

sacm mailing list

_______________________________________________

sacm mailing list

 




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

 



--

jOVAL.org: OVAL implemented in Java.
Scan any machine from any machine. For free!
Learn More | Features | Download

--------------040806040609070304000705-- From david.waltermire@nist.gov Fri Apr 13 15:25:53 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8691311E810F for ; Fri, 13 Apr 2012 15:25:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.189 X-Spam-Level: X-Spam-Status: No, score=-5.189 tagged_above=-999 required=5 tests=[AWL=-0.344, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WaGZBxiZ9ZsY for ; Fri, 13 Apr 2012 15:25:52 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id B271F11E810C for ; Fri, 13 Apr 2012 15:25:51 -0700 (PDT) Received: from WSXGHUB2.xchange.nist.gov (129.6.18.19) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 13 Apr 2012 18:25:30 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Fri, 13 Apr 2012 18:24:41 -0400 From: "Waltermire, David A." To: "'sacm@ietf.org'" Date: Fri, 13 Apr 2012 18:26:06 -0400 Thread-Topic: Updated Use Case Draft with Use Cases Thread-Index: Ac0ZxGrmIeP9mQ7MQUOh6z9reX21zQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_004_D7A0423E5E193F40BE6E94126930C4930B96E7B183MBCLUSTERxcha_" MIME-Version: 1.0 Subject: [sacm] Updated Use Case Draft with Use Cases X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 22:25:53 -0000 --_004_D7A0423E5E193F40BE6E94126930C4930B96E7B183MBCLUSTERxcha_ Content-Type: multipart/alternative; boundary="_000_D7A0423E5E193F40BE6E94126930C4930B96E7B183MBCLUSTERxcha_" --_000_D7A0423E5E193F40BE6E94126930C4930B96E7B183MBCLUSTERxcha_ Content-Type: text/plain; charset="us-ascii" Please find an updated draft attached with roughed out introduction and use case sections that are still missing a good deal of content. It is my hope that the included use cases can be used as a starting point for discussion and refinement. They are intended to be fairly abstract and are based on the discussion archives from scap_interest and sacm. Many of these overlap with existing efforts in the IETF and other SDOs, but have aspects that have been discussed in this context. They are not listed in any priority order and are likely not comprehensive. I appologize in advance if I have missed any use cases that are critical to you or your organization. Please speak up if I have. ;-) Thoughts? Sincerely, David Waltermire --_000_D7A0423E5E193F40BE6E94126930C4930B96E7B183MBCLUSTERxcha_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXVzLWFzY2lpIj48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250 ZW50PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8q IEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEg TWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2Zv bnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyog U3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29O b3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXpl OjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCmE6bGluaywg c3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7 DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJs aW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBp bjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0K CXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1s PjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpl eHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVs YXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+PC9oZWFkPjxib2R5IGxhbmc9RU4tVVMgbGluaz1ibHVl IHZsaW5rPXB1cnBsZT48ZGl2IGNsYXNzPVdvcmRTZWN0aW9uMT48cCBjbGFzcz1Nc29Ob3JtYWw+ UGxlYXNlIGZpbmQgYW4gdXBkYXRlZCBkcmFmdCBhdHRhY2hlZCB3aXRoIHJvdWdoZWQgb3V0IGlu dHJvZHVjdGlvbiBhbmQgdXNlIGNhc2Ugc2VjdGlvbnMgdGhhdCBhcmUgc3RpbGwgbWlzc2luZyBh IGdvb2QgZGVhbCBvZiBjb250ZW50LiZuYnNwOyBJdCBpcyBteSBob3BlIHRoYXQgdGhlIGluY2x1 ZGVkIHVzZSBjYXNlcyBjYW4gYmUgdXNlZCBhcyBhIHN0YXJ0aW5nIHBvaW50IGZvciBkaXNjdXNz aW9uIGFuZCByZWZpbmVtZW50LiZuYnNwOyBUaGV5IGFyZSBpbnRlbmRlZCB0byBiZSBmYWlybHkg YWJzdHJhY3QgYW5kIGFyZSBiYXNlZCBvbiB0aGUgZGlzY3Vzc2lvbiBhcmNoaXZlcyBmcm9tIHNj YXBfaW50ZXJlc3QgYW5kIHNhY20uJm5ic3A7IE1hbnkgb2YgdGhlc2Ugb3ZlcmxhcCB3aXRoIGV4 aXN0aW5nIGVmZm9ydHMgaW4gdGhlIElFVEYgYW5kIG90aGVyIFNET3MsIGJ1dCBoYXZlIGFzcGVj dHMgdGhhdCBoYXZlIGJlZW4gZGlzY3Vzc2VkIGluIHRoaXMgY29udGV4dC4mbmJzcDsgVGhleSBh cmUgbm90IGxpc3RlZCBpbiBhbnkgcHJpb3JpdHkgb3JkZXIgYW5kIGFyZSBsaWtlbHkgbm90IGNv bXByZWhlbnNpdmUuJm5ic3A7IEkgYXBwb2xvZ2l6ZSBpbiBhZHZhbmNlIGlmIEkgaGF2ZSBtaXNz ZWQgYW55IHVzZSBjYXNlcyB0aGF0IGFyZSBjcml0aWNhbCB0byB5b3Ugb3IgeW91ciBvcmdhbml6 YXRpb24uJm5ic3A7IFBsZWFzZSBzcGVhayB1cCBpZiBJIGhhdmUuIDstKSA8bzpwPjwvbzpwPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PHAgY2xhc3M9TXNvTm9y bWFsPlRob3VnaHRzPzxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNw OzwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+U2luY2VyZWx5LDxvOnA+PC9vOnA+PC9wPjxw IGNsYXNzPU1zb05vcm1hbD5EYXZpZCBXYWx0ZXJtaXJlPG86cD48L286cD48L3A+PHAgY2xhc3M9 TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjwvYm9keT48L2h0bWw+ --_000_D7A0423E5E193F40BE6E94126930C4930B96E7B183MBCLUSTERxcha_-- --_004_D7A0423E5E193F40BE6E94126930C4930B96E7B183MBCLUSTERxcha_ Content-Type: text/plain; name="draft-waltermire-sacm-use-cases-00-v2.txt" Content-Description: draft-waltermire-sacm-use-cases-00-v2.txt Content-Disposition: attachment; filename="draft-waltermire-sacm-use-cases-00-v2.txt"; size=14703; creation-date="Fri, 13 Apr 2012 18:25:02 GMT"; modification-date="Fri, 13 Apr 2012 18:25:02 GMT" Content-Transfer-Encoding: base64 CgoKTmV0d29yayBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg RC4gV2FsdGVybWlyZSwgRWQuCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTklTVApJbnRlbmRlZCBzdGF0dXM6IEluZm9y bWF0aW9uYWwgICAgICAgICAgICAgICAgICAgICAgICAgICAgQXByaWwgMTQsIDIwMTIKRXhwaXJl czogT2N0b2JlciAxNiwgMjAxMgoKCiAgQW5hbHlzaXMgb2YgU2VjdXJpdHkgQXV0b21hdGlvbiBh bmQgQ29udGludW91cyBNb25pdG9yaW5nIChTQUNNKSBVc2UKICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgQ2FzZXMKICAgICAgICAgICAgICAgICAgIGRyYWZ0LXdhbHRlcm1pcmUtc2Fj bS11c2UtY2FzZXMtMDAKCkFic3RyYWN0CgogICBUaGlzIGRvY3VtZW50IGlkZW50aWZpZXMgZm91 bmRhdGlvbmFsIHVzZSBjYXNlcywgZGVyaXZlZCBmdW5jdGlvbmFsCiAgIGNhcGFiaWxpdGllcyBh bmQgcmVxdWlyZW1lbnRzLCBhcmNoaXRlY3R1cmFsIGNvbXBvbmVudHMsIGFuZCB0aGUKICAgc3Vw cG9ydGluZyBzdGFuZGFyZHMgbmVlZGVkIHRvIGRlZmluZSBhbiBpbnRlcm9wZXJhYmxlLCBhdXRv bWF0aW9uCiAgIGluZnJhc3RydWN0dXJlIHJlcXVpcmVkIHRvIHN1cHBvcnQgdGltZWx5LCBhY2N1 cmF0ZSBhbmQgYWN0aW9uYWJsZQogICBzaXR1YXRpb25hbCBhd2FyZW5lc3Mgb3ZlciBhbiBvcmdh bml6YXRpb24ncyBJVCBzeXN0ZW1zLiAgQXV0b21hdGlvbgogICB0b29scyBpbXBsZW1lbnRpbmcg YSBjb250aW51b3VzIG1vbml0b3JpbmcgYXBwcm9hY2ggd2lsbCB1dGlsaXplIHRoaXMKICAgaW5m cmFzdHJ1Y3R1cmUgdG9nZXRoZXIgd2l0aCBleGlzdGluZyBhbmQgZW1lcmdpbmcgZXZlbnQsIGlu Y2lkZW50CiAgIGFuZCBuZXR3b3JrIG1hbmFnZW1lbnQgc3RhbmRhcmRzIHRvIHByb3ZpZGUgdmlz aWJpbGl0eSBpbnRvIHRoZSBzdGF0ZQogICBvZiBhc3NldHMsIHVzZXIgYWN0aXZpdGllcyBhbmQg bmV0d29yayBiZWhhdmlvci4gIFN0YWtlaG9sZGVycyB3aWxsCiAgIGJlIGFibGUgdG8gdXNlIHRo ZXNlIHRvb2xzIHRvIGFnZ3JlZ2F0ZSBhbmQgYW5hbHl6ZSByZWxldmFudCBzZWN1cml0eQogICBh bmQgb3BlcmF0aW9uYWwgZGF0YSB0byB1bmRlcnN0YW5kIHRoZSBvcmdhbml6YXRpb25zIHNlY3Vy aXR5CiAgIHBvc3R1cmUsIHF1YW50aWZ5IGJ1c2luZXNzIHJpc2ssIGFuZCBtYWtlIGluZm9ybWVk IGRlY2lzaW9ucyB0aGF0CiAgIHN1cHBvcnQgb3JnYW5pemF0aW9uYWwgb2JqZWN0aXZlcyB3aGls ZSBwcm90ZWN0aW5nIGNyaXRpY2FsCiAgIGluZm9ybWF0aW9uLiAgT3JnYW5pemF0aW9ucyB3aWxs IGJlIGFibGUgdG8gdXNlIHRoZXNlIHRvb2xzIHRvCiAgIGF1Z21lbnQgYW5kIGF1dG9tYXRlIGlu Zm9ybWF0aW9uIHNoYXJpbmcgYWN0aXZpdGllcyB0byBjb2xsYWJvcmF0ZQogICB3aXRoIHBhcnRu ZXJzIHRvIGlkZW50aWZ5IGFuZCBtaXRpZ2F0ZSB0aHJlYXRzLiAgT3RoZXIgYXV0b21hdGlvbgog ICB0b29scyB3aWxsIGJlIGFibGUgdG8gaW50ZWdyYXRlIHdpdGggdGhlc2UgY2FwYWJpbGl0aWVz IHRvIGVuZm9yY2UKICAgcG9saWNpZXMgYmFzZWQgb24gaHVtYW4gZGVjaXNpb25zIHRvIGhhcmRl biBzeXN0ZW1zLCBwcmV2ZW50IG1pc3VzZQogICBhbmQgcmVkdWNlIHRoZSBvdmVyYWxsIGF0dGFj ayBzdXJmYWNlLgoKU3RhdHVzIG9mIHRoaXMgTWVtbwoKICAgQnkgc3VibWl0dGluZyB0aGlzIElu dGVybmV0LURyYWZ0LCBlYWNoIGF1dGhvciByZXByZXNlbnRzIHRoYXQgYW55CiAgIGFwcGxpY2Fi bGUgcGF0ZW50IG9yIG90aGVyIElQUiBjbGFpbXMgb2Ygd2hpY2ggaGUgb3Igc2hlIGlzIGF3YXJl CiAgIGhhdmUgYmVlbiBvciB3aWxsIGJlIGRpc2Nsb3NlZCwgYW5kIGFueSBvZiB3aGljaCBoZSBv ciBzaGUgYmVjb21lcwogICBhd2FyZSB3aWxsIGJlIGRpc2Nsb3NlZCwgaW4gYWNjb3JkYW5jZSB3 aXRoIFNlY3Rpb24gNiBvZiBCQ1AgNzkuCgogICBJbnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcg ZG9jdW1lbnRzIG9mIHRoZSBJbnRlcm5ldCBFbmdpbmVlcmluZwogICBUYXNrIEZvcmNlIChJRVRG KS4gIE5vdGUgdGhhdCBvdGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZQogICB3b3JraW5n IGRvY3VtZW50cyBhcyBJbnRlcm5ldC1EcmFmdHMuICBUaGUgbGlzdCBvZiBjdXJyZW50IEludGVy bmV0LQogICBEcmFmdHMgaXMgYXQgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RyYWZ0cy9j dXJyZW50Ly4KCiAgIEludGVybmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZv ciBhIG1heGltdW0gb2Ygc2l4IG1vbnRocwogICBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2Vk LCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1lbnRzIGF0IGFueQogICB0aW1lLiAgSXQgaXMg aW5hcHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZQogICBtYXRl cmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBwcm9ncmVzcy4iCgoK CldhbHRlcm1pcmUgICAgICAgICAgICAgIEV4cGlyZXMgT2N0b2JlciAxNiwgMjAxMiAgICAgICAg ICAgICAgICBbUGFnZSAxXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgU0FDTSBVc2Ug Q2FzZXMgICAgICAgICAgICAgICAgICAgQXByaWwgMjAxMgoKCiAgIFRoaXMgSW50ZXJuZXQtRHJh ZnQgd2lsbCBleHBpcmUgb24gT2N0b2JlciAxNiwgMjAxMi4KCgpUYWJsZSBvZiBDb250ZW50cwoK ICAgMS4gIEludHJvZHVjdGlvbiAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAzCiAgICAgMS4xLiAgUmVxdWlyZW1lbnRzIExhbmd1YWdlIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNAogICAyLiAgS2V5IENvbmNlcHRzICAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDQKICAgMy4gIFVz ZSBDYXNlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiA0CiAgICAgMy4xLiAgVUMxOiBBc3Nlc3NtZW50IGFuZCBFbmZvcmNlbWVudCBvZiBBY2Nl cHRhYmxlIFN0YXRlIC4gLiAuIC4gNAogICAgIDMuMi4gIFVDMjogQmVoYXZpb3JhbCBNb25pdG9y aW5nIGFuZCBFbmZvcmNlbWVudCAgLiAuIC4gLiAuIC4gLiAuIDQKICAgICAzLjMuICBVQzM6IFNl Y3VyaXR5IENvbnRyb2wgVmVyaWZpY2F0aW9uIGFuZCBNb25pdG9yaW5nIC4gLiAuIC4gLiA0CiAg ICAgMy40LiAgVUM0OiBTZWN1cmUgRXhjaGFuZ2Ugb2YgR292ZXJuYW5jZSwgUmlzayBhbmQKICAg ICAgICAgICBDb21wbGlhbmNlIChHUkMpIEluZm9ybWF0aW9uICAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiA0CiAgICAgMy41LiAgVUM1OiBBdXRvbWF0ZWQgRm9yZW5zaWNzIEludmVzdGln YXRpb24gIC4gLiAuIC4gLiAuIC4gLiAuIC4gNQogICA0LiAgRnVuY3Rpb25hbCBDYXBhYmlsbGl0 aWVzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDUKICAgICA0LjEuICBG dW5jdGlvbmFsIENhcGFiaWxpdHkgMSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiA1CiAgICAgNC4yLiAgRnVuY3Rpb25hbCBDYXBhYmlsaXR5IG4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gNQogICA1LiAgRnVuY3Rpb25hbCBDb21wb25lbnRzIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDUKICAgNi4gIERhdGEgRXhjaGFuZ2Ug TW9kZWxzIGFuZCBDb21tdW5pY2F0aW9ucyBQcm90b2NvbHMgLiAuIC4gLiAuIC4gLiA2CiAgIDcu ICBJQU5BIENvbnNpZGVyYXRpb25zIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gNgogICA4LiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDYKICAgOS4gIFJlZmVyZW5jZXMgIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA2CiAgICAgOS4xLiAgTm9y bWF0aXZlIFJlZmVyZW5jZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g NgogICAgIDkuMi4gIEluZm9ybWF0aXZlIFJlZmVyZW5jZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIDYKICAgQXBwZW5kaXggQS4gIEFkZGl0aW9uYWwgU3R1ZmYgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA3CiAgIEF1dGhvcidzIEFkZHJlc3MgIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNwogICBJbnRl bGxlY3R1YWwgUHJvcGVydHkgYW5kIENvcHlyaWdodCBTdGF0ZW1lbnRzICAuIC4gLiAuIC4gLiAu IC4gLiAuIDgKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgpXYWx0ZXJtaXJlICAgICAgICAgICAgICBF eHBpcmVzIE9jdG9iZXIgMTYsIDIwMTIgICAgICAgICAgICAgICAgW1BhZ2UgMl0KDApJbnRlcm5l dC1EcmFmdCAgICAgICAgICAgICAgIFNBQ00gVXNlIENhc2VzICAgICAgICAgICAgICAgICAgIEFw cmlsIDIwMTIKCgoxLiAgSW50cm9kdWN0aW9uCgogICBUaGlzIGRvY3VtZW50IGFkZHJlc3NlcyBm b3VuZGF0aW9uYWwgdXNlIGNhc2VzIHRvIGJlIGNvbnNpZGVyZWQgd2hlbgogICBlc3RhYmxpc2hp bmcgYSBjaGFydGVyIGZvciB0aGUgU2VjdXJpdHkgQXV0b21hdGlvbiBhbmQgQ29udGludW91cwog ICBNb25pdG9yaW5nIChTQUNNKSB3b3JraW5nIGdyb3VwIHdpdGhpbiB0aGUgSUVURi4gIFRoaXMg d29ya2luZyBncm91cAogICB3aWxsIGFkZHJlc3MgYSBwb3J0aW9uIG9mIHRoZSBzdGFuZGFyZHMg bmVlZGVkIHRvIGRlZmluZSBhbgogICBpbnRlcm9wZXJhYmxlLCBhdXRvbWF0aW9uIGluZnJhc3Ry dWN0dXJlIHJlcXVpcmVkIHRvIHN1cHBvcnQgdGltZWx5LAogICBhY2N1cmF0ZSBhbmQgYWN0aW9u YWJsZSBzaXR1YXRpb25hbCBhd2FyZW5lc3Mgb3ZlciBhbiBvcmdhbml6YXRpb24ncwogICBJVCBz eXN0ZW1zLiAgVGhpcyBkb2N1bWVudCB3aWxsIGVudW1lcmF0ZSB1c2UgY2FzZXMgYW5kIGJyZWFr IGRvd24KICAgcmVsYXRlZCBjb25jZXB0cyB0aGF0IGNyb3NzIG1hbnkgSVQgc2VjdXJpdHkgaW5m b3JtYXRpb24gZG9tYWlucy4KCiAgIFNlY3Rpb25zIFsuLi5dIG9mIHRoaXMgZG9jdW1lbnQgZm9j dXMgb246CgogICAgICBEZWZpbmluZyB0aGUga2V5IGNvbmNlcHRzIGFuZCB0ZXJtaW5vbG9neSB1 c2VkIHdpdGhpbiB0aGUgZG9jdW1lbnQKICAgICAgcHJvdmlkaW5nIGEgY29tbW9uIGZyYW1lIG9m IHJlZmVyZW5jZTsKCiAgICAgIElkZW50aWZ5aW5nIGZvdW5kYXRpb25hbCB1c2UgY2FzZXMgdGhh dCByZXByZXNlbnQgY2xhc3NlcyBvZgogICAgICBzdGFrZWhvbGRlcnMsIGdvYWxzLCBhbmQgdXNh Z2Ugc2NlbmFyaW9zOwoKICAgICAgQSBzZXQgb2YgZGVyaXZlZCBmdW5jdGlvbmFsIGNhcGFiaWxp dGllcyBhbmQgYXNzb2NpYXRlZAogICAgICByZXF1aXJlbWVudHMgdGhhdCBhcmUgbmVlZGVkIHRv IHN1cHBvcnQgdGhlIHVzZSBjYXNlczsKCiAgICAgIEEgYnJlYWsgZG93biBvZiBhcmNoaXRlY3R1 cmFsIGNvbXBvbmVudHMgdGhhdCBhZGRyZXNzIG9uZSBvciBtb3JlCiAgICAgIGZ1bmN0aW9uYWwg Y2FwYWJpbGl0aWVzIHRoYXQgY2FuIGJlIHVzZWQgaW4gdmFyaW91cyBjb21iaW5hdGlvbnMKICAg ICAgdG8gc3VwcG9ydCB0aGUgdXNlIGNhc2VzOyBhbmQKCiAgICAgIEFuIGludmVudG9yeSBvZiBl eGlzdGluZywgZW1lcmdpbmcsIGFuZCBuZWVkZWQgZGF0YSBleGNoYW5nZQogICAgICBtb2RlbHMg YW5kIGNvbW11bmljYXRpb25zIHByb3RvY29scyB0aGF0IGFyZSByZXF1aXJlZCB0byBzdXBwb3J0 CiAgICAgIGludGVyb3BlcmFiaWxpdHkgYmV0d2VlbiBhcmNoaXRlY3R1cmFsIGNvbXBvbmVudHMu CgogICBUaGUgc3RhbmRhcmRzIGlkZW50aWZpZWQgaW4gdGhpcyBkb2N1bWVudCBwcm92aWRlIGEg Zm91bmRhdGlvbiBmb3IKICAgY3JlYXRpbmcgaW50ZXJvcGVyYWJsZSBhdXRvbWF0aW9uIHRvb2xz IGFuZCBjb250aW51b3VzIG1vbml0b3JpbmcKICAgc29sdXRpb25zIHRoYXQgcHJvdmlkZSB2aXNp YmlsaXR5IGludG8gdGhlIHN0YXRlIG9mIGFzc2V0cywgdXNlcgogICBhY3Rpdml0aWVzLCBhbmQg bmV0d29yayBiZWhhdmlvci4gIFN0YWtlaG9sZGVycyB3aWxsIGJlIGFibGUgdG8gdXNlCiAgIHRo ZXNlIHRvb2xzIHRvIGFnZ3JlZ2F0ZSBhbmQgYW5hbHl6ZSByZWxldmFudCBzZWN1cml0eSBhbmQK ICAgb3BlcmF0aW9uYWwgZGF0YSB0byB1bmRlcnN0YW5kIHRoZSBvcmdhbml6YXRpb25zIHNlY3Vy aXR5IHBvc3R1cmUsCiAgIHF1YW50aWZ5IGJ1c2luZXNzIHJpc2ssIGFuZCBtYWtlIGluZm9ybWVk IGRlY2lzaW9ucyB0aGF0IHN1cHBvcnQKICAgb3JnYW5pemF0aW9uYWwgb2JqZWN0aXZlcyB3aGls ZSBwcm90ZWN0aW5nIGNyaXRpY2FsIGluZm9ybWF0aW9uLgogICBPcmdhbml6YXRpb25zIHdpbGwg YmUgYWJsZSB0byB1c2UgdGhlc2UgdG9vbHMgdG8gYXVnbWVudCBhbmQgYXV0b21hdGUKICAgaW5m b3JtYXRpb24gc2hhcmluZyBhY3Rpdml0aWVzIHRvIGNvbGxhYm9yYXRlIHdpdGggcGFydG5lcnMg dG8KICAgaWRlbnRpZnkgYW5kIG1pdGlnYXRlIHRocmVhdHMuICBPdGhlciBhdXRvbWF0aW9uIHRv b2xzIHdpbGwgYmUgYWJsZQogICB0byBpbnRlZ3JhdGUgd2l0aCB0aGVzZSBjYXBhYmlsaXRpZXMg dG8gZW5mb3JjZSBwb2xpY2llcyBiYXNlZCBvbgogICBodW1hbiBkZWNpc2lvbnMgdG8gaGFyZGVu IHN5c3RlbXMsIHByZXZlbnQgbWlzdXNlIGFuZCByZWR1Y2UgdGhlCiAgIG92ZXJhbGwgYXR0YWNr IHN1cmZhY2UuCgoKCgoKCgpXYWx0ZXJtaXJlICAgICAgICAgICAgICBFeHBpcmVzIE9jdG9iZXIg MTYsIDIwMTIgICAgICAgICAgICAgICAgW1BhZ2UgM10KDApJbnRlcm5ldC1EcmFmdCAgICAgICAg ICAgICAgIFNBQ00gVXNlIENhc2VzICAgICAgICAgICAgICAgICAgIEFwcmlsIDIwMTIKCgoxLjEu ICBSZXF1aXJlbWVudHMgTGFuZ3VhZ2UKCiAgIFRoZSBrZXkgd29yZHMgIk1VU1QiLCAiTVVTVCBO T1QiLCAiUkVRVUlSRUQiLCAiU0hBTEwiLCAiU0hBTEwgTk9UIiwKICAgIlNIT1VMRCIsICJTSE9V TEQgTk9UIiwgIlJFQ09NTUVOREVEIiwgIk1BWSIsIGFuZCAiT1BUSU9OQUwiIGluIHRoaXMKICAg ZG9jdW1lbnQgYXJlIHRvIGJlIGludGVycHJldGVkIGFzIGRlc2NyaWJlZCBpbiBSRkMgMjExOSBb UkZDMjExOV0uCgoKMi4gIEtleSBDb25jZXB0cwoKICAgRGVmaW5lL3JlZmVyZW5jZSB0aGUgbWFq b3IgY29uY2VwdHMgaW5jbHVkZWQgaW4gdGhpcyBkb2N1bWVudC4KCgozLiAgVXNlIENhc2VzCgog ICBEZXNjcmliZSB1c2UgY2FzZXMsIG9uZSBwZXIgc3ViLXNlY3Rpb24uCgogICBUaGluZ3MgdG8g Y29uc2lkZXIgaW5jbHVkaW5nIChidXQgbm90IGxpbWl0ZWQgdG8pOgoKICAgbyAgVXNhZ2Ugc2Nl bmFyaW9zIChlLmcuICBTZWN1cml0eSBDb250cm9sIFZlcmlmaWNhdGlvbiwgRW5kcG9pbnQKICAg ICAgRW5mb3JjZW1lbnQsIEluY2lkZW50IERldGVjdGlvbiwgRm9yZW5zaWMgSW52ZXN0aWdhdGlv biwgZXRjLikKCiAgIG8gIEluZm9ybWF0aW9uIERvbWFpbnMgKGUuZy4gY29uZmlndXJhdGlvbiwg dnVsbmVyYWJpbGl0eSwgZGlnaXRhbAogICAgICBldmVudHMsIGV0Yy4pCgozLjEuICBVQzE6IEFz c2Vzc21lbnQgYW5kIEVuZm9yY2VtZW50IG9mIEFjY2VwdGFibGUgU3RhdGUKCiAgIENvbnRyb2xs aW5nIGFjY2VzcyB0byBuZXR3b3JrcyBhbmQgc2VydmljZXMgYmFzZWQgb24gdGhlIGFzc2Vzc21l bnQKICAgYW5kIGFuYWx5c2lzIG9mIGhvc3QgYW5kL29yIG5ldHdvcmsgc3RhdGUgYmFzZWQgb24g bWFjaGluZQogICBwcm9jZXNzYWJsZSBjb250ZW50LgoKMy4yLiAgVUMyOiBCZWhhdmlvcmFsIE1v bml0b3JpbmcgYW5kIEVuZm9yY2VtZW50CgogICBDb250cm9sbGluZyBhY2Nlc3MgdG8gbmV0d29y a3MgYW5kIHNlcnZpY2VzIGJhc2VkIG9uIHRoZSBkZXRlY3Rpb24KICAgYW5kIGFuYWx5c2lzIG9m IGhvc3QgYW5kL29yIHVzZXIgYmVoYXZpb3IgdXNpbmcgYXV0b21hdGFibGUKICAgaW5mb3JtYXRp b24gZnJvbSB2YXJpb3VzIHNvdXJjZXMuCgozLjMuICBVQzM6IFNlY3VyaXR5IENvbnRyb2wgVmVy aWZpY2F0aW9uIGFuZCBNb25pdG9yaW5nCgogICBDb250aW51b3VzIGFzc2Vzc21lbnQgb2YgdGhl IGltcGxlbWVudGF0aW9uIGFuZCBlZmZlY3RpdmVuZXNzIG9mCiAgIHNlY3VyaXR5IGNvbnRyb2xz IGJhc2VkIG9uIG1hY2hpbmUgcHJvY2Vzc2FibGUgY29udGVudC4KCjMuNC4gIFVDNDogU2VjdXJl IEV4Y2hhbmdlIG9mIEdvdmVybmFuY2UsIFJpc2sgYW5kIENvbXBsaWFuY2UgKEdSQykKICAgICAg SW5mb3JtYXRpb24KCiAgIFNoYXJpbmcgc2VjdXJpdHkgYW5kL29yIG9wZXJhdGlvbmFsbHkgcmVs ZXZhbnQgaW5mb3JtYXRpb24gd2l0aGluIGFuZAogICBhY3Jvc3MgdHJ1c3QgYm91bmRhcmllcyB1 c2luZyBzZWN1cmUsIGF1dG9tYXRlZCBjb21tdW5pY2F0aW9uCiAgIGNoYW5uZWxzIGFuZCBmb3Jt YXRzLgoKCgoKV2FsdGVybWlyZSAgICAgICAgICAgICAgRXhwaXJlcyBPY3RvYmVyIDE2LCAyMDEy ICAgICAgICAgICAgICAgIFtQYWdlIDRdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICBT QUNNIFVzZSBDYXNlcyAgICAgICAgICAgICAgICAgICBBcHJpbCAyMDEyCgoKMy41LiAgVUM1OiBB dXRvbWF0ZWQgRm9yZW5zaWNzIEludmVzdGlnYXRpb24KCiAgIFJlbW90ZSBhbmQvb3IgbG9jYWwg Y29sbGVjdGlvbiBvZiBvcmdhbml6YXRpb25hbCwgbmV0d29yaywgYW5kL29yCiAgIGhvc3QgaW5m b3JtYXRpb24gZm9yIHRoZSBwdXJwb3NlIG9mIGluY2lkZW50IGludmVzdGlnYXRpb24gYW5kCiAg IHJlc3BvbnNlLgoKCjQuICBGdW5jdGlvbmFsIENhcGFiaWxsaXRpZXMKCiAgIERlY29tcG9zZSB0 aGUgZnVuY3Rpb25hbCBjYXBhYmlsaXRpZXMgbmVlZGVkIHRvIHN1cHBvcnQgdGhlIHVzZQogICBj YXNlcywgb25lIHBlciBzdWItc2VjdGlvbi4gIENyb3NzIHJlZmVyZW5jZSB0aGUgdXNlIGNhc2UK ICAgZGVwZW5kZW5jaWVzIHdoZXJlIHRoZXkgZXhpc3QuCgogICBUaGluZ3MgdG8gY29uc2lkZXIg aW5jbHVkaW5nIChidXQgbm90IGxpbWl0ZWQgdG8pOgoKICAgbyAgSW5mb3JtYXRpb24gVmlld3Mv UmVwb3J0cyAoZS5nLiBzZWN1cml0eSBwb3N0dXJlLCBjb21wbGlhbmNlLAogICAgICBjb250cm9s IGVmZmVjdGl2ZW5lc3MpCgogICBvICBEYXRhIENvbGxlY3Rpb24gKGUuZy4gY29uZmlndXJhdGlv biBzdGF0ZSwgc29mdHdhcmUgaW52ZW50b3J5LAogICAgICB1c2VyIGFuZCBuZXR3b3JrIGJlaGF2 aW9yKQoKICAgbyAgUmVmZXJlbmNlIEluZm9ybWF0aW9uIEZvcm1hdHMgKGUuZy4gY29udHJvbCBj YXRhbG9ncywKICAgICAgY29uZmlndXJhdGlvbiBiYXNlbGluZXMsIG1hbHdhcmUgY2hhcmFjdGVy aXN0aWNzLCB2dWxuZXJhYmlsaXR5CiAgICAgIGRhdGEpCgo0LjEuICBGdW5jdGlvbmFsIENhcGFi aWxpdHkgMQoKICAgRGVzY3JpYmUgdGhlIGZpcnN0IGNhcGFiaWxpdHkuCgo0LjIuICBGdW5jdGlv bmFsIENhcGFiaWxpdHkgbgoKICAgRGVzY3JpYmUgdGhlIG4gY2FwYWJpbGl0eS4KCgo1LiAgRnVu Y3Rpb25hbCBDb21wb25lbnRzCgogICBEZXNjcmliZSB0aGUgYWJzdHJhY3QgZnVuY3Rpb25hbCBj b21wb25lbnRzIG5lZWRlZCB0byBwcm92aWRlIHRoZQogICBjYXBhYmlsaXRpZXMgZGVzY3JpYmVk IGluIHRoZSBwcmV2aW91cyBzZWN0aW9uLiAgRGVzY3JpYmUgYW55CiAgIHJlbGF0aW9uc2hpcHMg YmV0d2VlbiB0aGUgY29tcG9uZW50cyBhbmQgaG93IHRoZXkgY2FuIGJlIGNvbXBvc2VkIHRvCiAg IGFkZHJlc3MgZnVuY3Rpb25hbCBjYXBhYmlsaXRpZXMuICh0aGlzIG1pZ2h0IGJlIGJldHRlciBk ZWZpbmVkIGluIHRoZQogICBwcmV2aW91cyBzZWN0aW9uLikKCiAgIFRoaW5ncyB0byBjb25zaWRl ciBpbmNsdWRpbmcgKGJ1dCBub3QgbGltaXRlZCB0byk6CgogICBvICBUb3BvbG9naWVzCgogICBv ICBGZWRlcmF0aW9uIFN0cmF0ZWd5CgoKCgpXYWx0ZXJtaXJlICAgICAgICAgICAgICBFeHBpcmVz IE9jdG9iZXIgMTYsIDIwMTIgICAgICAgICAgICAgICAgW1BhZ2UgNV0KDApJbnRlcm5ldC1EcmFm dCAgICAgICAgICAgICAgIFNBQ00gVXNlIENhc2VzICAgICAgICAgICAgICAgICAgIEFwcmlsIDIw MTIKCgo2LiAgRGF0YSBFeGNoYW5nZSBNb2RlbHMgYW5kIENvbW11bmljYXRpb25zIFByb3RvY29s cwoKICAgRG9jdW1lbnQgd2hlcmUgZXhpc3Rpbmcgd29yayBleGlzdHMsIHdoYXQgaXMgY3VycmVu dGx5IGRlZmluZWQgYnkKICAgU0RPcywgYW5kIGFueSBnYXBzIHRoYXQgc2hvdWxkIGJlIGFkZHJl c3NlZC4gIFBvaW50IHRvIGV4aXN0aW5nCiAgIGV2ZW50LCBpbmNpZGVudCBhbmQgbmV0d29yayBt YW5hZ2VtZW50IHN0YW5kYXJkcyB3aGVuIGF2YWlsYWJsZS4KICAgRGVzY3JpYmUgZW1lcmdpbmcg ZWZmb3J0cyB0aGF0IG1heSBiZSB1c2VkIGZvciB0aGUgY3JlYXRpb24gb2YgbmV3CiAgIHN0YW5k YXJkcy4gIEZvciBnYXBzIHByb3ZpZGUgaW5zaWdodCBpbnRvIHdoYXQgd291bGQgYmUgYSBnb29k IGZpdAogICBmb3IgU0FDTSBvciBhbm90aGVyIElFVEYgd29ya2luZyBncm91cHMuCgoKNy4gIElB TkEgQ29uc2lkZXJhdGlvbnMKCiAgIFRoaXMgbWVtbyBpbmNsdWRlcyBubyByZXF1ZXN0IHRvIElB TkEuCgogICBBbGwgZHJhZnRzIGFyZSByZXF1aXJlZCB0byBoYXZlIGFuIElBTkEgY29uc2lkZXJh dGlvbnMgc2VjdGlvbiAoc2VlCiAgIHRoZSB1cGRhdGUgb2YgUkZDIDI0MzQgW0ktRC5uYXJ0ZW4t aWFuYS1jb25zaWRlcmF0aW9ucy1yZmMyNDM0YmlzXQogICBmb3IgYSBndWlkZSkuICBJZiB0aGUg ZHJhZnQgZG9lcyBub3QgcmVxdWlyZSBJQU5BIHRvIGRvIGFueXRoaW5nLCB0aGUKICAgc2VjdGlv biBjb250YWlucyBhbiBleHBsaWNpdCBzdGF0ZW1lbnQgdGhhdCB0aGlzIGlzIHRoZSBjYXNlIChh cwogICBhYm92ZSkuICBJZiB0aGVyZSBhcmUgbm8gcmVxdWlyZW1lbnRzIGZvciBJQU5BLCB0aGUg c2VjdGlvbiB3aWxsIGJlCiAgIHJlbW92ZWQgZHVyaW5nIGNvbnZlcnNpb24gaW50byBhbiBSRkMg YnkgdGhlIFJGQyBFZGl0b3IuCgoKOC4gIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zCgogICBBbGwg ZHJhZnRzIGFyZSByZXF1aXJlZCB0byBoYXZlIGEgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgc2Vj dGlvbi4KICAgU2VlIFJGQyAzNTUyIFtSRkMzNTUyXSBmb3IgYSBndWlkZS4KCgo5LiAgUmVmZXJl bmNlcwoKOS4xLiAgTm9ybWF0aXZlIFJlZmVyZW5jZXMKCiAgIFtSRkMyMTE5XSAgQnJhZG5lciwg Uy4sICJLZXkgd29yZHMgZm9yIHVzZSBpbiBSRkNzIHRvIEluZGljYXRlCiAgICAgICAgICAgICAg UmVxdWlyZW1lbnQgTGV2ZWxzIiwgQkNQIDE0LCBSRkMgMjExOSwgTWFyY2ggMTk5Ny4KCiAgIFtt aW5fcmVmXSAgYXV0aFN1ck5hbWUsIGF1dGhJbml0aWFscy4sICJNaW5pbWFsIFJlZmVyZW5jZSIs IDIwMDYuCgo5LjIuICBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzCgogICBbSS1ELm5hcnRlbi1pYW5h LWNvbnNpZGVyYXRpb25zLXJmYzI0MzRiaXNdCiAgICAgICAgICAgICAgTmFydGVuLCBULiBhbmQg SC4gQWx2ZXN0cmFuZCwgIkd1aWRlbGluZXMgZm9yIFdyaXRpbmcgYW4KICAgICAgICAgICAgICBJ QU5BIENvbnNpZGVyYXRpb25zIFNlY3Rpb24gaW4gUkZDcyIsCiAgICAgICAgICAgICAgZHJhZnQt bmFydGVuLWlhbmEtY29uc2lkZXJhdGlvbnMtcmZjMjQzNGJpcy0wOSAod29yayBpbgogICAgICAg ICAgICAgIHByb2dyZXNzKSwgTWFyY2ggMjAwOC4KCiAgIFtSRkMzNTUyXSAgUmVzY29ybGEsIEUu IGFuZCBCLiBLb3J2ZXIsICJHdWlkZWxpbmVzIGZvciBXcml0aW5nIFJGQwogICAgICAgICAgICAg IFRleHQgb24gU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMiLCBCQ1AgNzIsIFJGQyAzNTUyLAogICAg ICAgICAgICAgIEp1bHkgMjAwMy4KCgoKV2FsdGVybWlyZSAgICAgICAgICAgICAgRXhwaXJlcyBP Y3RvYmVyIDE2LCAyMDEyICAgICAgICAgICAgICAgIFtQYWdlIDZdCgwKSW50ZXJuZXQtRHJhZnQg ICAgICAgICAgICAgICBTQUNNIFVzZSBDYXNlcyAgICAgICAgICAgICAgICAgICBBcHJpbCAyMDEy CgoKQXBwZW5kaXggQS4gIEFkZGl0aW9uYWwgU3R1ZmYKCiAgIFRoaXMgYmVjb21lcyBhbiBBcHBl bmRpeCBpZiBuZWVkZWQuCgoKQXV0aG9yJ3MgQWRkcmVzcwoKICAgRGF2aWQgV2FsdGVybWlyZSAo ZWRpdG9yKQogICBOYXRpb25hbCBJbnN0aXR1dGUgb2YgU3RhbmRhcmRzIGFuZCBUZWNobm9sb2d5 CiAgIDEwMCBCdXJlYXUgRHJpdmUKICAgR2FpdGhlcnNidXJnLCBNYXJ5bGFuZCAgMjA4NzcKICAg VVNBCgogICBQaG9uZToKICAgRW1haWw6IGRhdmlkLndhbHRlcm1pcmVAbmlzdC5nb3YKCgoKCgoK CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKV2FsdGVybWlyZSAgICAgICAgICAgICAgRXhw aXJlcyBPY3RvYmVyIDE2LCAyMDEyICAgICAgICAgICAgICAgIFtQYWdlIDddCgwKSW50ZXJuZXQt RHJhZnQgICAgICAgICAgICAgICBTQUNNIFVzZSBDYXNlcyAgICAgICAgICAgICAgICAgICBBcHJp bCAyMDEyCgoKRnVsbCBDb3B5cmlnaHQgU3RhdGVtZW50CgogICBDb3B5cmlnaHQgKEMpIFRoZSBJ RVRGIFRydXN0ICgyMDEyKS4KCiAgIFRoaXMgZG9jdW1lbnQgaXMgc3ViamVjdCB0byB0aGUgcmln aHRzLCBsaWNlbnNlcyBhbmQgcmVzdHJpY3Rpb25zCiAgIGNvbnRhaW5lZCBpbiBCQ1AgNzgsIGFu ZCBleGNlcHQgYXMgc2V0IGZvcnRoIHRoZXJlaW4sIHRoZSBhdXRob3JzCiAgIHJldGFpbiBhbGwg dGhlaXIgcmlnaHRzLgoKICAgVGhpcyBkb2N1bWVudCBhbmQgdGhlIGluZm9ybWF0aW9uIGNvbnRh aW5lZCBoZXJlaW4gYXJlIHByb3ZpZGVkIG9uIGFuCiAgICJBUyBJUyIgYmFzaXMgYW5kIFRIRSBD T05UUklCVVRPUiwgVEhFIE9SR0FOSVpBVElPTiBIRS9TSEUgUkVQUkVTRU5UUwogICBPUiBJUyBT UE9OU09SRUQgQlkgKElGIEFOWSksIFRIRSBJTlRFUk5FVCBTT0NJRVRZLCBUSEUgSUVURiBUUlVT VCBBTkQKICAgVEhFIElOVEVSTkVUIEVOR0lORUVSSU5HIFRBU0sgRk9SQ0UgRElTQ0xBSU0gQUxM IFdBUlJBTlRJRVMsIEVYUFJFU1MKICAgT1IgSU1QTElFRCwgSU5DTFVESU5HIEJVVCBOT1QgTElN SVRFRCBUTyBBTlkgV0FSUkFOVFkgVEhBVCBUSEUgVVNFIE9GCiAgIFRIRSBJTkZPUk1BVElPTiBI RVJFSU4gV0lMTCBOT1QgSU5GUklOR0UgQU5ZIFJJR0hUUyBPUiBBTlkgSU1QTElFRAogICBXQVJS QU5USUVTIE9GIE1FUkNIQU5UQUJJTElUWSBPUiBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVS UE9TRS4KCgpJbnRlbGxlY3R1YWwgUHJvcGVydHkKCiAgIFRoZSBJRVRGIHRha2VzIG5vIHBvc2l0 aW9uIHJlZ2FyZGluZyB0aGUgdmFsaWRpdHkgb3Igc2NvcGUgb2YgYW55CiAgIEludGVsbGVjdHVh bCBQcm9wZXJ0eSBSaWdodHMgb3Igb3RoZXIgcmlnaHRzIHRoYXQgbWlnaHQgYmUgY2xhaW1lZCB0 bwogICBwZXJ0YWluIHRvIHRoZSBpbXBsZW1lbnRhdGlvbiBvciB1c2Ugb2YgdGhlIHRlY2hub2xv Z3kgZGVzY3JpYmVkIGluCiAgIHRoaXMgZG9jdW1lbnQgb3IgdGhlIGV4dGVudCB0byB3aGljaCBh bnkgbGljZW5zZSB1bmRlciBzdWNoIHJpZ2h0cwogICBtaWdodCBvciBtaWdodCBub3QgYmUgYXZh aWxhYmxlOyBub3IgZG9lcyBpdCByZXByZXNlbnQgdGhhdCBpdCBoYXMKICAgbWFkZSBhbnkgaW5k ZXBlbmRlbnQgZWZmb3J0IHRvIGlkZW50aWZ5IGFueSBzdWNoIHJpZ2h0cy4gIEluZm9ybWF0aW9u CiAgIG9uIHRoZSBwcm9jZWR1cmVzIHdpdGggcmVzcGVjdCB0byByaWdodHMgaW4gUkZDIGRvY3Vt ZW50cyBjYW4gYmUKICAgZm91bmQgaW4gQkNQIDc4IGFuZCBCQ1AgNzkuCgogICBDb3BpZXMgb2Yg SVBSIGRpc2Nsb3N1cmVzIG1hZGUgdG8gdGhlIElFVEYgU2VjcmV0YXJpYXQgYW5kIGFueQogICBh c3N1cmFuY2VzIG9mIGxpY2Vuc2VzIHRvIGJlIG1hZGUgYXZhaWxhYmxlLCBvciB0aGUgcmVzdWx0 IG9mIGFuCiAgIGF0dGVtcHQgbWFkZSB0byBvYnRhaW4gYSBnZW5lcmFsIGxpY2Vuc2Ugb3IgcGVy bWlzc2lvbiBmb3IgdGhlIHVzZSBvZgogICBzdWNoIHByb3ByaWV0YXJ5IHJpZ2h0cyBieSBpbXBs ZW1lbnRlcnMgb3IgdXNlcnMgb2YgdGhpcwogICBzcGVjaWZpY2F0aW9uIGNhbiBiZSBvYnRhaW5l ZCBmcm9tIHRoZSBJRVRGIG9uLWxpbmUgSVBSIHJlcG9zaXRvcnkgYXQKICAgaHR0cDovL3d3dy5p ZXRmLm9yZy9pcHIuCgogICBUaGUgSUVURiBpbnZpdGVzIGFueSBpbnRlcmVzdGVkIHBhcnR5IHRv IGJyaW5nIHRvIGl0cyBhdHRlbnRpb24gYW55CiAgIGNvcHlyaWdodHMsIHBhdGVudHMgb3IgcGF0 ZW50IGFwcGxpY2F0aW9ucywgb3Igb3RoZXIgcHJvcHJpZXRhcnkKICAgcmlnaHRzIHRoYXQgbWF5 IGNvdmVyIHRlY2hub2xvZ3kgdGhhdCBtYXkgYmUgcmVxdWlyZWQgdG8gaW1wbGVtZW50CiAgIHRo aXMgc3RhbmRhcmQuICBQbGVhc2UgYWRkcmVzcyB0aGUgaW5mb3JtYXRpb24gdG8gdGhlIElFVEYg YXQKICAgaWV0Zi1pcHJAaWV0Zi5vcmcuCgoKCgoKCgoKCgoKV2FsdGVybWlyZSAgICAgICAgICAg ICAgRXhwaXJlcyBPY3RvYmVyIDE2LCAyMDEyICAgICAgICAgICAgICAgIFtQYWdlIDhdCgwK --_004_D7A0423E5E193F40BE6E94126930C4930B96E7B183MBCLUSTERxcha_-- From lnunez@c3isecurity.com Mon Apr 16 15:44:37 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5995921F85F1 for ; Mon, 16 Apr 2012 15:44:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KgLFrWCKw-Xb for ; Mon, 16 Apr 2012 15:44:36 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id D33F521F85EA for ; Mon, 16 Apr 2012 15:44:35 -0700 (PDT) Received: by ggmi1 with SMTP id i1so3176818ggm.31 for ; Mon, 16 Apr 2012 15:44:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=XrgEASCk75iFDhXByDrfOhSIGUeGFRWnnwrfaWULXLU=; b=H5cZ1R2ORGZaeK3yAcZzWqYlcb0QRdEjw7yDDZkPhrFPJA7RZiHhrOaVwjrnsye5Yv 24uF1QMcOFmKJQIysVYb7CP7FQcd130lmWymjKrUutDr5Igdm8Q7heqfaq3KUAyomAdw 9bKIpM1JduotiYQ0wPZoMCStoYoPf1/g30CPTojnbUdrS96tHVwTD1wgjSZMU/B9VKMv FPklMYiUN1EividWSlna5615pZfUJoLw2DBPCG/NOJPf/iJTPRgHVA+WgvqBv6e1i8xG yYMYjw7RDY71b15mdWoIWS1VhV3/ZyaoHioq7KQB/xCquUaubwx6gc67SWFUvO735So3 +A1A== Received: by 10.100.233.35 with SMTP id f35mr3263105anh.37.1334616275197; Mon, 16 Apr 2012 15:44:35 -0700 (PDT) Received: from [172.16.1.104] (cpe-066-057-025-190.nc.res.rr.com. [66.57.25.190]) by mx.google.com with ESMTPS id 34sm33657192anu.6.2012.04.16.15.44.32 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 16 Apr 2012 15:44:33 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_787FBBB9-7AC9-43C0-A176-8C5F1F332347" From: Luis Nunez In-Reply-To: <7F48813B48558A4BB5CB7BB714E5B5A91706E3@IMCMBX03.MITRE.ORG> Date: Mon, 16 Apr 2012 18:44:28 -0400 Message-Id: <870A23D4-BA94-4431-B613-F3D7734B8DB5@c3isecurity.com> References: <7F48813B48558A4BB5CB7BB714E5B5A91706E3@IMCMBX03.MITRE.ORG> To: "Barnum, Sean D." X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQnkDnG8+KXKPa5kxBW42J67EI6u4+9peF4pO7KjQKMl37vq9CEtqgDj5jF26BxpxPzZj93R Cc: idxwg@nicwg.org, mile@ietf.org, "Doug Wilson \(dallendoug@gmail.com\)" , sacm@ietf.org, "IPA-Masato Terada \(m-terada@ipa.go.jp\)" Subject: Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live on the website X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 22:44:37 -0000 --Apple-Mail=_787FBBB9-7AC9-43C0-A176-8C5F1F332347 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I like the inclusion of the network-centric objects. IPFIX (netflow) = will add an additional perspective from an incident information sharing = standpoint. =20 -ln On Apr 16, 2012, at 4:04 PM, Barnum, Sean D. wrote: > Hey everyone, > =20 > I just wanted to let you all know that CybOX v1.0 (Draft) content is = now live on the website. http://cybox.mitre.org > The release notes are provided inline below. > The key items of note are: > =B7 The release of two formal specifications for the CybOX = language (one for the core language and one for the defined objects) > =B7 The XML Schema has gone through extensive improvements for = expressiveness, clarity, consistency, efficiency, alignment to existing = normative references and documentation. > =B7 This release includes an initial set of language utilities: = a draft Snort -> CybOX transform, a draft OpenIOC -> CybOX transform, = and a set of Python bindings for the CybOX language. > =B7 The website now includes a small set of content examples. = This set will grow going forward. >=20 > This release involved a lot of hard work from a diverse group of = people. Thank you all for your contributions and effort. We could not = have done it without you. > We look forward to everyone=92s feedback and collaboration as we = continue to improve and mature the CybOX language. > =20 > Sean Barnum > =20 > =20 > =20 > CybOX v1.0 (Draft) Release Notes >=20 > The Version 1.0 (Draft) release of Cyber Observable eXpression = (CybOX=99) is intended as a draft release of an initial major version of = the CybOX Language that could be utilized for practical operational use = and integration into other standards efforts. This release consists of = three primary components: a pair of formal language specifications for = the core language content and defined objects content, a set of language = implementation XML schemas (core, common_types, and ~70 defined object = schemas), and a small initial set of language utilities including an = initial draft Snort->CybOX transform, an initial draft OpenIOC->CybOX = transform and a set of CybOX language Python bindings. Recognizing that = this is the first time that the formal language specifications will be = available for review and as such will likely generate feedback from new = stakeholders, this initial major version is being released as a =93draft=94= v1.0 with the expectation of cycles of new feedback and revision before = a =93final=94 v1.0 is released. > The CybOX v1.0 (Draft) XML schemas include a significant number of = changes from v0.7 to improve: > =B7 Clarity, documentation, and descriptive formality for = reference and implementation by other standards and users. > =B7 Consistency, simplicity, and efficiency. > =B7 Alignment (as appropriate) to existing normative references. > =B7 Expressiveness of the schema to better support the broad set = of use cases it targets (malware characterization, indicator and = incident data sharing, event management, etc.) including the addition of = an initial set of network-related defined objects. >=20 > Summary of changes from CybOX_v0.7 to CybOX_v1.0_(Draft): > Refinement of namespaces and schema locations for better effectiveness = and flexibility going forward. > Normalized all content according to an established set of naming = conventions. > Fully annotated all language items (types, attributes, elements, = etc.). > Moved several commonly leveraged types out of the core schema and into = common_types. > Achieved full typing of entire schema structure such that all = attributes and elements are definitively typed. > Changed all identifiers from ID and IDREF types to be QNames enabling = globally unique identifiers and flexibility for domain-specific users of = CybOX to define their own identifier syntax locally. > Reordered attributes and elements in numerous types to better reflect = common usage and priority. > Added major_version and minor_version attributes for core schema. > Added capability to characterize source of overall observable package = data and for individual observables. > Modified the logical composition structure such that any such = compositions are now contained within a Observable_Composition element = providing improved simplicity and modularity. > Removed the Delta element from ObservableType and relocated the = appropriate portions (Change, Trend, and Frequency) to appropriate = locations under Stateful_Measure and Event. > Added a Domain_Specific_Object_Attributes field to Object utilizing an = abstract type that will allow domain-specific use cases to add in their = own domain-specific attributes for Objects. > Added a Tool-Specific_Data field to ToolInformationType utilizing an = abstract type that will allow addition of tool-specific data. > Added an Indicators field to MeasureSourceType utilizing an abstract = type that will allow characterizing differing formats or standards of = indicators that may have led to the identification of the observable = data. > Enhanced the Hash structure to capture full fuzzy hashes in addition = to simple hashes > Added a new ExtractedFeaturesType that can be used to adorn differing = objects (e.g., files, memory, etc.) to capture extracted strings, = imports, functions and code snippets > Added a ByteRunsType to enable capture of byte runs within various = objects. > Added object_reference attribute to DefinedObjectType to better = support referencing of independently defined Objects from within another = Object definition. > Added a generic DataSegmentType to provide a relatively abstract way = of characterizing data segments that may be written/read/transmitted or = otherwise utilized in actions or defined in objects. > =B7 Added several new defined object schemas (API, Code, = Device, DNS_Record, Network_Flow, Network_Packet, Network_Route_Entry, = Network_Subnet, Unix_Network_Route_Entry) including an initial set of = network-centric defined objects. > Modified every defined object schema with added annotations as well as = minor and in some cases substantive changes to fix errors, improve = consistency and alignment with existing normative references, and to = improve expressiveness in support of the targeted use cases. > Detailed changes from CybOX_v0.7 to CybOX_v1.0_(Draft): > The level of changes within v1.0 (Draft) in the core schema, = common_types and the defined object schemas is too great to list every = change in these release notes. Detailed difference reports are available = for each individual schema = at:http://cybox.mitre.org/XMLSchema/release_notes/cybox_v1.0(draft)_diff_r= eports.zip > =20 > =20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Sean Barnum > Cyber Security Principal > The MITRE Corporation > Email: sbarnum@mitre.org > =20 > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile --Apple-Mail=_787FBBB9-7AC9-43C0-A176-8C5F1F332347 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I like the inclusion of the network-centric = objects.  IPFIX (netflow)  will add an additional perspective = from an incident information sharing standpoint. =  

-ln

On Apr 16, 2012, = at 4:04 PM, Barnum, Sean D. wrote:

Hey = everyone,
 
I just wanted to let you all know that CybOX v1.0 (Draft) = content is now live on the website. http://cybox.mitre.org
The release notes are provided inline = below.
The key items of note are:
=B7 The = release of two formal specifications for the CybOX language (one for the = core language and one for the defined objects)
=B7 The = XML Schema has gone through extensive improvements for expressiveness, = clarity, consistency, efficiency, alignment to existing normative = references and documentation.
        This = release includes an initial set of language utilities: a draft Snort = -> CybOX transform, a draft OpenIOC -> CybOX transform, and a set = of Python bindings for the CybOX language.

=B7 The = website now includes a small set of content examples. This set will grow = going forward.

This release involved a lot of = hard work from a diverse group of people. Thank you all for your = contributions and effort. We could not have done it without = you.
We look forward to everyone=92s feedback and = collaboration as we continue to improve and mature the CybOX = language.
 
Sean Barnum
 
 
 

CybOX v1.0 (Draft) Release = Notes

The Version 1.0 (Draft) release = of Cyber Observable eXpression (CybOX=99) is intended as a draft = release of an initial major version of the CybOX Language that could be = utilized for practical operational use and integration into other = standards efforts. This release consists of three primary components: a = pair of formal language specifications for the core language content and = defined objects content, a set of language implementation XML schemas = (core, common_types, and ~70 defined object schemas), and a small = initial set of language utilities including an initial draft = Snort->CybOX transform, an initial draft OpenIOC->CybOX transform = and a set of CybOX language Python bindings. Recognizing that this is = the first time that the formal language specifications will be available = for review and as such will likely generate feedback from new = stakeholders, this initial major version is being released as a =93draft=94= v1.0 with the expectation of cycles of new feedback and revision before = a =93final=94 v1.0 is released.
The CybOX v1.0 (Draft) XML schemas include a = significant number of changes from v0.7 to = improve:
=B7       =B7 =B7 =B7 Summary of changes from CybOX_v0.7 to = CybOX_v1.0_(Draft):
  • Refinement of namespaces and schema locations for = better effectiveness and flexibility going = forward.
  • Normalized all content according to an established set = of naming conventions.
  • Fully annotated all language items (types, attributes, = elements, etc.).
  • Moved several commonly leveraged types out of the core = schema and into common_types.
  • Achieved full typing of entire schema = structure such that all attributes and elements are definitively = typed.
  • Reordered attributes and elements in numerous types to = better reflect common usage and priority.
  • Added major_version and minor_version = attributes for core schema.
  • Added capability to characterize source of overall = observable package data and for individual = observables.
  • Modified the logical composition structure such that = any such compositions are now contained within a Observable_Composition = element providing improved simplicity and = modularity.
  • Removed the Delta element from ObservableType and = relocated the appropriate portions (Change, Trend, and Frequency) to = appropriate locations under Stateful_Measure and = Event.
  • Added = a Domain_Specific_Object_Attributes field to Object utilizing an = abstract type that will allow domain-specific use cases to add in their = own domain-specific attributes for Objects.
  • Added a Tool-Specific_Data field to = ToolInformationType utilizing an abstract type that will allow addition = of tool-specific data.
  • Added an Indicators field to MeasureSourceType = utilizing an abstract type that will allow characterizing differing = formats or standards of indicators that may have led to the = identification of the observable data.
  • Enhanced the Hash structure to capture full = fuzzy hashes in addition to simple hashes
  • Added a new ExtractedFeaturesType that can = be used to adorn differing objects (e.g., files, memory, etc.) to = capture extracted strings, imports, functions and code = snippets
  • Added a ByteRunsType to enable capture of byte runs = within various objects.
  • Added object_reference attribute to DefinedObjectType = to better support referencing of independently defined Objects from = within another Object definition.
  • Added a generic DataSegmentType to provide a = relatively abstract way of characterizing data segments that may be = written/read/transmitted or otherwise utilized in actions or defined in = objects.
        Added several new defined object schemas = (API, Code, Device, DNS_Record, Network_Flow, Network_Packet, = Network_Route_Entry, Network_Subnet, Unix_Network_Route_Entry) including = an initial set of network-centric defined = objects.
  • Modified every defined object schema with added = annotations as well as minor and in some cases substantive changes to = fix errors, improve consistency and alignment with existing normative = references, and to improve expressiveness in support of the targeted use = cases.
The = level of changes within v1.0 (Draft) in the core schema, common_types = and the defined object schemas is too great to list every change in = these release notes. Detailed difference reports are available for each = individual schema at: 
 
___________________________________________= ____
mile mailing list
In-Reply-To: <870A23D4-BA94-4431-B613-F3D7734B8DB5@c3isecurity.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sacm] [mile] CybOX v1.0 (Draft) is now released and live onthe website Thread-Index: Ac0cIoKxjmCQPFiRSeqrlJRFEHgaVQADFK2A References: <7F48813B48558A4BB5CB7BB714E5B5A91706E3@IMCMBX03.MITRE.ORG> <870A23D4-BA94-4431-B613-F3D7734B8DB5@c3isecurity.com> From: "Omar Santos (osantos)" To: "Luis Nunez" , "Barnum, Sean D." X-OriginalArrivalTime: 17 Apr 2012 00:17:19.0412 (UTC) FILETIME=[73B86F40:01CD1C2F] Cc: idxwg@nicwg.org, mile@ietf.org, dallendoug@gmail.com, sacm@ietf.org, m-terada@ipa.go.jp Subject: Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live onthe website X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 00:17:25 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD1C2F.7366A01F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I echo Luis' comments. It is good to see the inclusion of network objects. Quick question to the team related to your netflow comment. =20 I am looking at: http://cybox.mitre.org/XMLSchema/cybox_core_v1.0%28draft%29.xsd =20 ... and it looks that we renamed it to "Data Flow"? =20 Specifies the class of events dealing with data flow. =20 =20 What is the difference between that and "Packet Traffic"? =20 Specifies the class of events dealing with packet traffic. =20 =20 =20 =20 Regards, Omar Santos Incident Manager, PSIRT Security Research and Operations Cisco Systems, Inc. Email: os@cisco.com Phone: +1 919 392 8635 PGP Key: 0x3AF27EDC Cisco.com - http://www.cisco.com Cisco Security Advisories and Notices - http://www.cisco.com/go/psirt This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message. For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html =20 From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Luis Nunez Sent: Monday, April 16, 2012 6:44 PM To: Barnum, Sean D. Cc: idxwg@nicwg.org; mile@ietf.org; Doug Wilson (dallendoug@gmail.com); sacm@ietf.org; IPA-Masato Terada (m-terada@ipa.go.jp) Subject: Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live onthe website =20 I like the inclusion of the network-centric objects. IPFIX (netflow) will add an additional perspective from an incident information sharing standpoint. =20 =20 -ln =20 On Apr 16, 2012, at 4:04 PM, Barnum, Sean D. wrote: Hey everyone, =20 I just wanted to let you all know that CybOX v1.0 (Draft) content is now live on the website. http://cybox.mitre.org The release notes are provided inline below. The key items of note are: * The release of two formal specifications for the CybOX language (one for the core language and one for the defined objects) * The XML Schema has gone through extensive improvements for expressiveness, clarity, consistency, efficiency, alignment to existing normative references and documentation. * This release includes an initial set of language utilities: a draft Snort -> CybOX transform, a draft OpenIOC -> CybOX transform, and a set of Python bindings for the CybOX language. * The website now includes a small set of content examples. This set will grow going forward. This release involved a lot of hard work from a diverse group of people. Thank you all for your contributions and effort. We could not have done it without you. We look forward to everyone's feedback and collaboration as we continue to improve and mature the CybOX language. =20 Sean Barnum =20 =20 =20 CybOX v1.0 (Draft) Release Notes The Version 1.0 (Draft) release of Cyber Observable eXpression (CybOX(tm)) is intended as a draft release of an initial major version of the CybOX Language that could be utilized for practical operational use and integration into other standards efforts. This release consists of three primary components: a pair of formal language specifications for the core language content and defined objects content, a set of language implementation XML schemas (core, common_types, and ~70 defined object schemas), and a small initial set of language utilities including an initial draft Snort->CybOX transform, an initial draft OpenIOC->CybOX transform and a set of CybOX language Python bindings. Recognizing that this is the first time that the formal language specifications will be available for review and as such will likely generate feedback from new stakeholders, this initial major version is being released as a "draft" v1.0 with the expectation of cycles of new feedback and revision before a "final" v1.0 is released. The CybOX v1.0 (Draft) XML schemas include a significant number of changes from v0.7 to improve: * Clarity, documentation, and descriptive formality for reference and implementation by other standards and users. * Consistency, simplicity, and efficiency. * Alignment (as appropriate) to existing normative references. * Expressiveness of the schema to better support the broad set of use cases it targets (malware characterization, indicator and incident data sharing, event management, etc.) including the addition of an initial set of network-related defined objects. Summary of changes from CybOX_v0.7 to CybOX_v1.0_(Draft): * Refinement of namespaces and schema locations for better effectiveness and flexibility going forward. * Normalized all content according to an established set of naming conventions. * Fully annotated all language items (types, attributes, elements, etc.). * Moved several commonly leveraged types out of the core schema and into common_types. * Achieved full typing of entire schema structure such that all attributes and elements are definitively typed. * Changed all identifiers from ID and IDREF types to be QNames enabling globally unique identifiers and flexibility for domain-specific users of CybOX to define their own identifier syntax locally. * Reordered attributes and elements in numerous types to better reflect common usage and priority. * Added major_version and minor_version attributes for core schema. * Added capability to characterize source of overall observable package data and for individual observables. * Modified the logical composition structure such that any such compositions are now contained within a Observable_Composition element providing improved simplicity and modularity. * Removed the Delta element from ObservableType and relocated the appropriate portions (Change, Trend, and Frequency) to appropriate locations under Stateful_Measure and Event. * Added a Domain_Specific_Object_Attributes field to Object utilizing an abstract type that will allow domain-specific use cases to add in their own domain-specific attributes for Objects. * Added a Tool-Specific_Data field to ToolInformationType utilizing an abstract type that will allow addition of tool-specific data. * Added an Indicators field to MeasureSourceType utilizing an abstract type that will allow characterizing differing formats or standards of indicators that may have led to the identification of the observable data. * Enhanced the Hash structure to capture full fuzzy hashes in addition to simple hashes * Added a new ExtractedFeaturesType that can be used to adorn differing objects (e.g., files, memory, etc.) to capture extracted strings, imports, functions and code snippets * Added a ByteRunsType to enable capture of byte runs within various objects. * Added object_reference attribute to DefinedObjectType to better support referencing of independently defined Objects from within another Object definition. * Added a generic DataSegmentType to provide a relatively abstract way of characterizing data segments that may be written/read/transmitted or otherwise utilized in actions or defined in objects. * Added several new defined object schemas (API, Code, Device, DNS_Record, Network_Flow, Network_Packet, Network_Route_Entry, Network_Subnet, Unix_Network_Route_Entry) including an initial set of network-centric defined objects. * Modified every defined object schema with added annotations as well as minor and in some cases substantive changes to fix errors, improve consistency and alignment with existing normative references, and to improve expressiveness in support of the targeted use cases. Detailed changes from CybOX_v0.7 to CybOX_v1.0_(Draft): The level of changes within v1.0 (Draft) in the core schema, common_types and the defined object schemas is too great to list every change in these release notes. Detailed difference reports are available for each individual schema at:http://cybox.mitre.org/XMLSchema/release_notes/cybox_v1.0(draft)_diff _reports.zip =20 =20 =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Sean Barnum Cyber Security Principal The MITRE Corporation Email: sbarnum@mitre.org =20 _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile =20 ------_=_NextPart_001_01CD1C2F.7366A01F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I echo Luis’ comments. It is good to see the inclusion of = network objects. Quick question to the team related to your netflow = comment.

 

I am looking at:

= http://cybox.mitre.org/XMLSchema/cybox_core_v1.0%28draft%29.xsd<= /o:p>

 

… and it looks that we renamed it to “Data = Flow”?

 

<xs:enumeration = value=3D"Data Flow">

   <xs:annotation>

        = <xs:documentation>Specifies the class of events dealing with data = flow.</xs:documentation>

   </xs:annotation>

</xs:enumeration>

 

 

What is the difference between that and “Packet = Traffic”?

 

<xs:enumeration =
value=3D"Packet Traffic">
   =
<xs:annotation>
     =
<xs:documentation>Specifies the class of events dealing with =
packet =
traffic.</xs:documentation>
   =
</xs:annotation>
</xs:enumeration><=
/o:p>

 

 

 

 

Regards,

Omar Santos
Incident Manager, = PSIRT
Security Research and Operations
Cisco Systems, = Inc.
Email: os@cisco.com
Phone: +1 919 392 8635
PGP Key: = 0x3AF27EDC

Cisco.com - http://www.cisco.com
Cisco Security = Advisories and Notices - http://www.cisco.com/go/psirt

This email = may contain confidential and privileged material for the sole
use of = the intended recipient. Any review, use, distribution or
disclosure = by others is strictly prohibited. If you are not the = intended
recipient (or authorized to receive for the recipient), = please contact
the sender by reply email and delete all copies of = this message.

For corporate legal information go = to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html=

 

From:= = sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of = Luis Nunez
Sent: Monday, April 16, 2012 6:44 = PM
To: Barnum, Sean D.
Cc: idxwg@nicwg.org; = mile@ietf.org; Doug Wilson (dallendoug@gmail.com); sacm@ietf.org; = IPA-Masato Terada (m-terada@ipa.go.jp)
Subject: Re: [sacm] = [mile] CybOX v1.0 (Draft) is now released and live onthe = website

 

I like the = inclusion of the network-centric objects.  IPFIX (netflow) =  will add an additional perspective from an incident information = sharing standpoint.  

 

-ln

 

On = Apr 16, 2012, at 4:04 PM, Barnum, Sean D. wrote:



Hey = everyone,

 =

I just = wanted to let you all know that CybOX v1.0 (Draft) content is now live = on the website. http://cybox.mitre.org

The = release notes are provided inline = below.

The key = items of note are:

·        The = release of two formal specifications for the CybOX language (one for the = core language and one for the defined = objects)

·        The XML = Schema has gone through extensive improvements for expressiveness, = clarity, consistency, efficiency, alignment to existing normative = references and documentation.

·        This = release includes an initial set of language utilities: a draft Snort = -> CybOX transform, a draft OpenIOC -> CybOX transform, and a set = of Python bindings for the CybOX language.

·        The = website now includes a small set of content examples. This set will grow = going forward.

This = release involved a lot of hard work from a diverse group of people. = Thank you all for your contributions and effort. We could not have done = it without you.

We look = forward to everyone’s feedback and collaboration as we continue to = improve and mature the CybOX = language.

 =

Sean = Barnum

 =

 =

 =

CybOX v1.0 (Draft) Release = Notes

The Version = 1.0 (Draft) release of Cyber Observable eXpression (CybOX™) is intended as a draft release of an initial major version of = the CybOX Language that could be utilized for practical operational use = and integration into other standards efforts. This release consists of = three primary components: a pair of formal language specifications for = the core language content and defined objects content, a set of language = implementation XML schemas (core, common_types, and ~70 defined object = schemas), and a small initial set of language utilities including an = initial draft Snort->CybOX transform, an initial draft = OpenIOC->CybOX transform and a set of CybOX language Python bindings. = Recognizing that this is the first time that the formal language = specifications will be available for review and as such will likely = generate feedback from new stakeholders, this initial major version is = being released as a “draft” v1.0 with the expectation of = cycles of new feedback and revision before a “final” v1.0 is = released.=

The CybOX v1.0 (Draft) XML = schemas include a significant number of changes from v0.7 to = improve:=

·       Clarity, = documentation, and descriptive formality for reference and = implementation by other standards and users.=

·       Consistency, = simplicity, and efficiency.=

·       Alignment (as = appropriate) to existing normative references.=

·       Expressiveness of the = schema to better support the broad set of use cases it targets (malware = characterization, indicator and incident data sharing, event management, = etc.) including the addition of an initial set of network-related = defined objects.=

Summary of changes from CybOX_v0.7 = to CybOX_v1.0_(Draft):=

  • Refinement of = namespaces and schema locations for better effectiveness and flexibility = going forward.=
  • Normalized all content according to an established set of naming = conventions.=
  • Fully annotated all language items (types, attributes, elements, = etc.).=
  • Moved several commonly leveraged types out of the core schema and = into common_types.=
  • Achieved full typing of entire schema structure such that all = attributes and elements are definitively typed.=
  • Changed all identifiers from ID and IDREF types to be QNames = enabling globally unique identifiers and flexibility for domain-specific = users of CybOX to define their own identifier syntax locally.=
  • Reordered attributes and elements in numerous types to better = reflect common usage and priority.=
  • Added major_version and minor_version attributes for core = schema.=
  • Added capability to characterize source of overall observable = package data and for individual observables.=
  • Modified the logical composition structure such that any such = compositions are now contained within a Observable_Composition element = providing improved simplicity and modularity.=
  • Removed the Delta element from ObservableType and relocated the = appropriate portions (Change, Trend, and Frequency) to appropriate = locations under Stateful_Measure and Event.=
  • Added a Domain_Specific_Object_Attributes field to Object = utilizing an abstract type that will allow domain-specific use cases to = add in their own domain-specific attributes for Objects.=
  • Added a Tool-Specific_Data field to ToolInformationType utilizing = an abstract type that will allow addition of tool-specific data.=
  • Added an Indicators field to MeasureSourceType utilizing an = abstract type that will allow characterizing differing formats or = standards of indicators that may have led to the identification of the = observable data.=
  • Enhanced the Hash structure to capture full fuzzy hashes in = addition to simple hashes=
  • Added a new ExtractedFeaturesType that can be used to adorn = differing objects (e.g., files, memory, etc.) to capture extracted = strings, imports, functions and code snippets=
  • Added a ByteRunsType to enable capture of byte runs within various = objects.=
  • Added object_reference attribute to DefinedObjectType to better = support referencing of independently defined Objects from within another = Object definition.=
  • Added a generic DataSegmentType to provide a relatively abstract = way of characterizing data segments that may be written/read/transmitted = or otherwise utilized in actions or defined in objects.=

·        Added several new = defined object schemas (API, Code, Device, DNS_Record, Network_Flow, = Network_Packet, Network_Route_Entry, Network_Subnet, = Unix_Network_Route_Entry) including an initial set of network-centric = defined objects.

  • Modified every defined object schema = with added annotations as well as minor and in some cases substantive = changes to fix errors, improve consistency and alignment with existing = normative references, and to improve expressiveness in support of the = targeted use cases.=

Detailed changes from CybOX_v0.7 to = CybOX_v1.0_(Draft):=

The level of changes within = v1.0 (Draft) in the core schema, common_types and the defined object = schemas is too great to list every change in these release notes. = Detailed difference reports are available for each individual schema = at:http://cybox.mitre.org/XMLSchema/release_notes/cybox_v1.0= (draft)_diff_reports.zip

 =

 =

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

Sean Barnum=

Cyber Security Principal=

The MITRE Corporation=

 =

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

 

------_=_NextPart_001_01CD1C2F.7366A01F-- From osantos@cisco.com Mon Apr 16 20:32:20 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6515B21F84D2; Mon, 16 Apr 2012 20:32:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZVPfuWXnesrD; Mon, 16 Apr 2012 20:32:11 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 8FB3321F84D3; Mon, 16 Apr 2012 20:32:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=osantos@cisco.com; l=57863; q=dns/txt; s=iport; t=1334633530; x=1335843130; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=lBTF+/eOqv3KsCIZK70mE6lc+i4ha8Un3HWPizcP+10=; b=c/VxN7hXVItb/deW1Mpi0AaFaKfkdDOvfxTQrrav89jnZKDOMJ297uay Mplgjwpb5FTr9Dg2yLpnS56Tq5c8Q6FJU8FDT+I/UA4+uaWIswoPoF62e DgMnGvLaI5qGnxQHbr4mfxtZYD/jYwsGJss4BvuneMxiSEu9NJaiVUW93 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAOzjjE+tJV2b/2dsb2JhbABBA4JGpWUBiQqBB4IJAQEBBAEBAQ8BBwILBgMlGQQHDgICAQgRBAEBCwYQAQYBBgEaBgYfCQgCBAESCBqHXgMLC5lkliQNiVMEijODaYJGYwSIWo4kiiEGgxSBaYMFgT4 X-IronPort-AV: E=Sophos;i="4.75,432,1330905600"; d="scan'208,217";a="75243610" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-4.cisco.com with ESMTP; 17 Apr 2012 03:32:09 +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 q3H3W9pT030236; Tue, 17 Apr 2012 03:32:09 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); Mon, 16 Apr 2012 22:32:09 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD1C4A.AB41D122" Date: Mon, 16 Apr 2012 22:32:05 -0500 Message-ID: <953A2E460DBE7C43AC13E30B87C5B4FF080A1C00@XMB-RCD-106.cisco.com> In-Reply-To: <7F48813B48558A4BB5CB7BB714E5B5A9171B16@IMCMBX03.MITRE.ORG> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sacm] [mile] CybOX v1.0 (Draft) is now released and live onthe website Thread-Index: AQHNHC91EoahZz2AEEqd+yKyGmroMJaeWIaQgAAEUcA= References: <7F48813B48558A4BB5CB7BB714E5B5A91706E3@IMCMBX03.MITRE.ORG> <870A23D4-BA94-4431-B613-F3D7734B8DB5@c3isecurity.com> <953A2E460DBE7C43AC13E30B87C5B4FF080A1BAD@XMB-RCD-106.cisco.com> <7F48813B48558A4BB5CB7BB714E5B5A9171B16@IMCMBX03.MITRE.ORG> From: "Omar Santos (osantos)" To: "Barnum, Sean D." , "Luis Nunez" X-OriginalArrivalTime: 17 Apr 2012 03:32:09.0724 (UTC) FILETIME=[ABB07BC0:01CD1C4A] Cc: idxwg@nicwg.org, mile@ietf.org, dallendoug@gmail.com, sacm@ietf.org, m-terada@ipa.go.jp Subject: Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live onthe website X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 03:32:20 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD1C4A.AB41D122 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks for the clarification Sean. It does make sense.. =20 Regards, Omar=20 =20 From: Barnum, Sean D. [mailto:sbarnum@mitre.org]=20 Sent: Monday, April 16, 2012 11:29 PM To: Omar Santos (osantos); Luis Nunez Cc: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; m-terada@ipa.go.jp Subject: RE: [sacm] [mile] CybOX v1.0 (Draft) is now released and live onthe website =20 Thanks Omar. =20 To answer your question, first let me point out to other readers that the two entries that Omar is quoting here exist as values in an enumeration called EventTypeEnum which as its name implies contains a list of different labels for grouping types (or classes) of events to be used as low-granularity buckets for characterizing and classifying events. Other entries in this enumeration include things like "File Ops (CRUD)", "Process Mgt", "Authorization (ACL)", etc. =20 The "Packet Traffic" value is intended to characterize events dealing with network packet traffic as its name implies. The "Data Flow" value is intended to characterize events dealing with forms of data flow at a higher level of abstraction than just packet traffic. The relationship between these two values could be viewed as "Packet Traffic" being a more detailed form of "Data Flow" just as the values "App Layer Traffic" and "HTTP Layer Traffic", also in this enumeration, could be other levels in this same abstraction stack. The idea behind the varying levels of abstraction is to leave buckets large enough to capture a wide variety of potential event types (e.g. data flow events other than obvious things like packet traffic) but also enable the use of smaller more specific buckets when they are appropriate and commonly used. =20 Does this make sense?=20 =20 sean =20 From: Omar Santos (osantos) [mailto:osantos@cisco.com]=20 Sent: Monday, April 16, 2012 8:17 PM To: Luis Nunez; Barnum, Sean D. Cc: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; m-terada@ipa.go.jp Subject: RE: [sacm] [mile] CybOX v1.0 (Draft) is now released and live onthe website =20 I echo Luis' comments. It is good to see the inclusion of network objects. Quick question to the team related to your netflow comment. =20 I am looking at: http://cybox.mitre.org/XMLSchema/cybox_core_v1.0%28draft%29.xsd =20 ... and it looks that we renamed it to "Data Flow"? =20 Specifies the class of events dealing with data flow. =20 =20 What is the difference between that and "Packet Traffic"? =20 Specifies the class of events dealing with packet traffic. =20 =20 =20 =20 Regards, Omar Santos Incident Manager, PSIRT Security Research and Operations Cisco Systems, Inc. Email: os@cisco.com Phone: +1 919 392 8635 PGP Key: 0x3AF27EDC Cisco.com - http://www.cisco.com Cisco Security Advisories and Notices - http://www.cisco.com/go/psirt This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message. For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html =20 From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Luis Nunez Sent: Monday, April 16, 2012 6:44 PM To: Barnum, Sean D. Cc: idxwg@nicwg.org; mile@ietf.org; Doug Wilson (dallendoug@gmail.com); sacm@ietf.org; IPA-Masato Terada (m-terada@ipa.go.jp) Subject: Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live onthe website =20 I like the inclusion of the network-centric objects. IPFIX (netflow) will add an additional perspective from an incident information sharing standpoint. =20 =20 -ln =20 On Apr 16, 2012, at 4:04 PM, Barnum, Sean D. wrote: =20 Hey everyone, =20 I just wanted to let you all know that CybOX v1.0 (Draft) content is now live on the website. http://cybox.mitre.org The release notes are provided inline below. The key items of note are: * The release of two formal specifications for the CybOX language (one for the core language and one for the defined objects) * The XML Schema has gone through extensive improvements for expressiveness, clarity, consistency, efficiency, alignment to existing normative references and documentation. * This release includes an initial set of language utilities: a draft Snort -> CybOX transform, a draft OpenIOC -> CybOX transform, and a set of Python bindings for the CybOX language. * The website now includes a small set of content examples. This set will grow going forward. This release involved a lot of hard work from a diverse group of people. Thank you all for your contributions and effort. We could not have done it without you. We look forward to everyone's feedback and collaboration as we continue to improve and mature the CybOX language. =20 Sean Barnum =20 =20 =20 CybOX v1.0 (Draft) Release Notes The Version 1.0 (Draft) release of Cyber Observable eXpression (CybOX(tm)) is intended as a draft release of an initial major version of the CybOX Language that could be utilized for practical operational use and integration into other standards efforts. This release consists of three primary components: a pair of formal language specifications for the core language content and defined objects content, a set of language implementation XML schemas (core, common_types, and ~70 defined object schemas), and a small initial set of language utilities including an initial draft Snort->CybOX transform, an initial draft OpenIOC->CybOX transform and a set of CybOX language Python bindings. Recognizing that this is the first time that the formal language specifications will be available for review and as such will likely generate feedback from new stakeholders, this initial major version is being released as a "draft" v1.0 with the expectation of cycles of new feedback and revision before a "final" v1.0 is released. The CybOX v1.0 (Draft) XML schemas include a significant number of changes from v0.7 to improve: * Clarity, documentation, and descriptive formality for reference and implementation by other standards and users. * Consistency, simplicity, and efficiency. * Alignment (as appropriate) to existing normative references. * Expressiveness of the schema to better support the broad set of use cases it targets (malware characterization, indicator and incident data sharing, event management, etc.) including the addition of an initial set of network-related defined objects. Summary of changes from CybOX_v0.7 to CybOX_v1.0_(Draft): * Refinement of namespaces and schema locations for better effectiveness and flexibility going forward. * Normalized all content according to an established set of naming conventions. * Fully annotated all language items (types, attributes, elements, etc.). * Moved several commonly leveraged types out of the core schema and into common_types. * Achieved full typing of entire schema structure such that all attributes and elements are definitively typed. * Changed all identifiers from ID and IDREF types to be QNames enabling globally unique identifiers and flexibility for domain-specific users of CybOX to define their own identifier syntax locally. * Reordered attributes and elements in numerous types to better reflect common usage and priority. * Added major_version and minor_version attributes for core schema. * Added capability to characterize source of overall observable package data and for individual observables. * Modified the logical composition structure such that any such compositions are now contained within a Observable_Composition element providing improved simplicity and modularity. * Removed the Delta element from ObservableType and relocated the appropriate portions (Change, Trend, and Frequency) to appropriate locations under Stateful_Measure and Event. * Added a Domain_Specific_Object_Attributes field to Object utilizing an abstract type that will allow domain-specific use cases to add in their own domain-specific attributes for Objects. * Added a Tool-Specific_Data field to ToolInformationType utilizing an abstract type that will allow addition of tool-specific data. * Added an Indicators field to MeasureSourceType utilizing an abstract type that will allow characterizing differing formats or standards of indicators that may have led to the identification of the observable data. * Enhanced the Hash structure to capture full fuzzy hashes in addition to simple hashes * Added a new ExtractedFeaturesType that can be used to adorn differing objects (e.g., files, memory, etc.) to capture extracted strings, imports, functions and code snippets * Added a ByteRunsType to enable capture of byte runs within various objects. * Added object_reference attribute to DefinedObjectType to better support referencing of independently defined Objects from within another Object definition. * Added a generic DataSegmentType to provide a relatively abstract way of characterizing data segments that may be written/read/transmitted or otherwise utilized in actions or defined in objects. * Added several new defined object schemas (API, Code, Device, DNS_Record, Network_Flow, Network_Packet, Network_Route_Entry, Network_Subnet, Unix_Network_Route_Entry) including an initial set of network-centric defined objects. * Modified every defined object schema with added annotations as well as minor and in some cases substantive changes to fix errors, improve consistency and alignment with existing normative references, and to improve expressiveness in support of the targeted use cases. Detailed changes from CybOX_v0.7 to CybOX_v1.0_(Draft): The level of changes within v1.0 (Draft) in the core schema, common_types and the defined object schemas is too great to list every change in these release notes. Detailed difference reports are available for each individual schema at:http://cybox.mitre.org/XMLSchema/release_notes/cybox_v1.0(draft)_diff _reports.zip =20 =20 =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Sean Barnum Cyber Security Principal The MITRE Corporation Email: sbarnum@mitre.org =20 _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile =20 ------_=_NextPart_001_01CD1C4A.AB41D122 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks for the clarification Sean. It does make = sense..

 

Regards,

Omar

 

From:= = Barnum, Sean D. [mailto:sbarnum@mitre.org]
Sent: Monday, = April 16, 2012 11:29 PM
To: Omar Santos (osantos); Luis = Nunez
Cc: idxwg@nicwg.org; mile@ietf.org; = dallendoug@gmail.com; sacm@ietf.org; = m-terada@ipa.go.jp
Subject: RE: [sacm] [mile] CybOX v1.0 = (Draft) is now released and live onthe = website

 

Thanks Omar.

 

To answer your question, first let me point out to other readers that = the two entries that Omar is quoting here exist as values in an = enumeration called EventTypeEnum which as its name implies contains a = list of different labels for grouping types (or classes) of events to be = used as low-granularity buckets for characterizing and classifying = events.

Other entries in this enumeration include things like “File Ops = (CRUD)”, “Process Mgt”, “Authorization = (ACL)”, etc.

 

The “Packet Traffic” value is intended to characterize = events dealing with network packet traffic as its name = implies.

The “Data Flow” value is intended to characterize events = dealing with forms of data flow at a higher level of abstraction than = just packet traffic. The relationship between these two values could be = viewed as “Packet Traffic” being a more detailed form of = “Data Flow” just as the values “App Layer = Traffic” and “HTTP Layer Traffic”, also in this = enumeration, could be other levels in this same abstraction = stack.

The idea behind the varying levels of abstraction is to leave =  buckets large enough to capture a wide variety of potential event = types (e.g. data flow events other than obvious things like packet = traffic) but also enable the use of smaller more specific buckets when = they are appropriate and commonly used.

 

Does this make sense?

 

sean

 

From:= = Omar Santos (osantos) [mailto:osantos@cisco.com]=
Sent: Monday, April 16, 2012 8:17 PM
To: Luis = Nunez; Barnum, Sean D.
Cc: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; m-terada@ipa.go.jp
Subject:<= /b> RE: [sacm] [mile] CybOX v1.0 (Draft) is now released and live onthe = website

 

I echo Luis’ comments. It is good to see the inclusion of = network objects. Quick question to the team related to your netflow = comment.

 

I am looking at:

= http://cybox.mitre.org/XMLSchema/cybox_core_v1.0%28draft%29.xsd<= /o:p>

 

… and it looks that we renamed it to “Data = Flow”?

 

<xs:enumeration = value=3D"Data Flow">

   = <xs:annotation>

        = <xs:documentation>Specifies the class of events dealing with data = flow.</xs:documentation>

   = </xs:annotation>

</xs:enumeration>

 

 

What is the difference between that and “Packet = Traffic”?

 

<xs:enumeration value=3D"Packet =
Traffic">
   =
<xs:annotation>
     =
<xs:documentation>Specifies the class of events dealing with =
packet traffic.</xs:documentation>
   =
</xs:annotation>
</xs:enumeration>

 

 

 

 

Regards,

Omar Santos
Incident Manager, = PSIRT
Security Research and Operations
Cisco Systems, = Inc.
Email: os@cisco.com
Phone: +1 919 392 = 8635
PGP Key: 0x3AF27EDC

Cisco.com - http://www.cisco.com
Cisco Security = Advisories and Notices - http://www.cisco.com/go/psirt<= br>
This email may contain confidential and privileged material for = the sole
use of the intended recipient. Any review, use, distribution = or
disclosure by others is strictly prohibited. If you are not the = intended
recipient (or authorized to receive for the recipient), = please contact
the sender by reply email and delete all copies of = this message.

For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html=

 

From:= = sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.= org] On Behalf Of Luis Nunez
Sent: Monday, April = 16, 2012 6:44 PM
To: Barnum, Sean D.
Cc: idxwg@nicwg.org; mile@ietf.org; Doug Wilson (dallendoug@gmail.com); sacm@ietf.org; IPA-Masato Terada (m-terada@ipa.go.jp)
Subject:= Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live onthe = website

 

I like the inclusion of the network-centric = objects.  IPFIX (netflow)  will add an additional perspective = from an incident information sharing standpoint. =  

 

-ln

 

On Apr 16, 2012, at 4:04 = PM, Barnum, Sean D. wrote:

 

Hey = everyone,

 =

I just = wanted to let you all know that CybOX v1.0 (Draft) content is now live = on the website. http://cybox.mitre.org

The = release notes are provided inline = below.

The key = items of note are:

·        The = release of two formal specifications for the CybOX language (one for the = core language and one for the defined = objects)

·        The XML = Schema has gone through extensive improvements for expressiveness, = clarity, consistency, efficiency, alignment to existing normative = references and documentation.

·        This = release includes an initial set of language utilities: a draft Snort = -> CybOX transform, a draft OpenIOC -> CybOX transform, and a set = of Python bindings for the CybOX language.

·        The = website now includes a small set of content examples. This set will grow = going forward.

This = release involved a lot of hard work from a diverse group of people. = Thank you all for your contributions and effort. We could not have done = it without you.

We look = forward to everyone’s feedback and collaboration as we continue to = improve and mature the CybOX = language.

 =

Sean = Barnum

 =

 =

 =

CybOX v1.0 (Draft) Release = Notes

The Version 1.0 (Draft) release of Cyber = Observable eXpression (CybOX™) is intended as a draft release of an initial major version of = the CybOX Language that could be utilized for practical operational use = and integration into other standards efforts. This release consists of = three primary components: a pair of formal language specifications for = the core language content and defined objects content, a set of language = implementation XML schemas (core, common_types, and ~70 defined object = schemas), and a small initial set of language utilities including an = initial draft Snort->CybOX transform, an initial draft = OpenIOC->CybOX transform and a set of CybOX language Python bindings. = Recognizing that this is the first time that the formal language = specifications will be available for review and as such will likely = generate feedback from new stakeholders, this initial major version is = being released as a “draft” v1.0 with the expectation of = cycles of new feedback and revision before a “final” v1.0 is = released.=

The CybOX v1.0 (Draft) XML schemas include a = significant number of changes from v0.7 to improve:=

·       Clarity, = documentation, and descriptive formality for reference and = implementation by other standards and users.=

·       Consistency, = simplicity, and efficiency.=

·       Alignment (as = appropriate) to existing normative references.=

·       Expressiveness of the = schema to better support the broad set of use cases it targets (malware = characterization, indicator and incident data sharing, event management, = etc.) including the addition of an initial set of network-related = defined objects.=

Summary = of changes from CybOX_v0.7 to CybOX_v1.0_(Draft):=

·         = Refinement of namespaces and schema = locations for better effectiveness and flexibility going forward.=

·         = Normalized all content according to an = established set of naming conventions.=

·         = Fully annotated all language items = (types, attributes, elements, etc.).=

·         = Moved several commonly leveraged types = out of the core schema and into common_types.=

·         = Achieved full typing of entire schema = structure such that all attributes and elements are definitively = typed.=

·         = Changed all identifiers from ID and IDREF = types to be QNames enabling globally unique identifiers and flexibility = for domain-specific users of CybOX to define their own identifier syntax = locally.=

·         = Reordered attributes and elements in = numerous types to better reflect common usage and priority.=

·         = Added major_version and minor_version = attributes for core schema.=

·         = Added capability to characterize source = of overall observable package data and for individual observables.=

·         = Modified the logical composition = structure such that any such compositions are now contained within a = Observable_Composition element providing improved simplicity and = modularity.=

·         = Removed the Delta element from = ObservableType and relocated the appropriate portions (Change, Trend, = and Frequency) to appropriate locations under Stateful_Measure and = Event.=

·         = Added a Domain_Specific_Object_Attributes = field to Object utilizing an abstract type that will allow = domain-specific use cases to add in their own domain-specific attributes = for Objects.=

·         = Added a Tool-Specific_Data field to = ToolInformationType utilizing an abstract type that will allow addition = of tool-specific data.=

·         = Added an Indicators field to = MeasureSourceType utilizing an abstract type that will allow = characterizing differing formats or standards of indicators that may = have led to the identification of the observable data.=

·         = Enhanced the Hash structure to capture = full fuzzy hashes in addition to simple hashes=

·         = Added a new ExtractedFeaturesType that = can be used to adorn differing objects (e.g., files, memory, etc.) to = capture extracted strings, imports, functions and code snippets=

·         = Added a ByteRunsType to enable capture of = byte runs within various objects.=

·         = Added object_reference attribute to = DefinedObjectType to better support referencing of independently defined = Objects from within another Object definition.=

·         = Added a generic DataSegmentType to = provide a relatively abstract way of characterizing data segments that = may be written/read/transmitted or otherwise utilized in actions or = defined in objects.=

·        Added several new = defined object schemas (API, Code, Device, DNS_Record, Network_Flow, = Network_Packet, Network_Route_Entry, Network_Subnet, = Unix_Network_Route_Entry) including an initial set of network-centric = defined objects.

·         = Modified every defined object schema with = added annotations as well as minor and in some cases substantive changes = to fix errors, improve consistency and alignment with existing normative = references, and to improve expressiveness in support of the targeted use = cases.=

Detailed changes from CybOX_v0.7 to = CybOX_v1.0_(Draft):=

The level of changes within v1.0 (Draft) in = the core schema, common_types and the defined object schemas is too = great to list every change in these release notes. Detailed difference = reports are available for each individual schema at:http://cybox.mitre.org/XMLSchema/release_notes/cybox_v1.0= (draft)_diff_reports.zip

 =

 =

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

Sean Barnum=

Cyber Security Principal=

The MITRE Corporation=

 =

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

 

------_=_NextPart_001_01CD1C4A.AB41D122-- From osantos@cisco.com Mon Apr 16 20:57:25 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8A9911E8099; Mon, 16 Apr 2012 20:57:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dz98tcGQkW03; Mon, 16 Apr 2012 20:57:20 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 04CCF11E8081; Mon, 16 Apr 2012 20:57:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=osantos@cisco.com; l=81388; q=dns/txt; s=iport; t=1334635040; x=1335844640; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=VPVQvi+cR/8wAHuajOtt5x6iB4Lp73HzGwekOEcR6Fs=; b=R8wDoHFM2BbdkvvXIp6b2szzDR6FGJCLcxWR0JixU6+LURph1MWhjjvK IlineKRyw/A1mE1L0bjiC6P7Lohz6uTTmjSGy04Bx2d+WdknE55hukU11 citmI91qHuuJoGR14Z6+Xq37rahwtxgtgZgSpffXYso2vAHFwJx0DK9Oz 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYFAIvojE+tJXG9/2dsb2JhbABBA4JGgyCiRQGIEHqBB4IJAQEBBAEBAQ8BBwIHBAYDJRkEBw4CAgEIEQQBAQsGEAEGAQICAgEBGQYGHwkIAgQBEggah14DCwuZZ40QiRUNiVMEijODaYIRNWMEiFqOJIohBoMUgWmDBYE+ X-IronPort-AV: E=Sophos;i="4.75,432,1330905600"; d="scan'208,217";a="75235173" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-7.cisco.com with ESMTP; 17 Apr 2012 03:57:19 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id q3H3vJ2G009732; Tue, 17 Apr 2012 03:57:19 GMT Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 16 Apr 2012 22:57:19 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD1C4E.2F4B01A2" Date: Mon, 16 Apr 2012 22:57:15 -0500 Message-ID: <953A2E460DBE7C43AC13E30B87C5B4FF080A1C09@XMB-RCD-106.cisco.com> In-Reply-To: <69CE2DCD9DAC3D48B830E0723141170B02A39BD2@ZAU1UG-0308.DHSNET.DS1.DHS> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sacm] [mile] CybOX v1.0 (Draft) is now released and live onthe website Thread-Index: AQHNHC91EoahZz2AEEqd+yKyGmroMJaeWIaQgAAIZb+AAAIPgA== References: <7F48813B48558A4BB5CB7BB714E5B5A9171B16@IMCMBX03.MITRE.ORG> <69CE2DCD9DAC3D48B830E0723141170B02A39BD2@ZAU1UG-0308.DHSNET.DS1.DHS> From: "Omar Santos (osantos)" To: "Millar, Thomas" , , X-OriginalArrivalTime: 17 Apr 2012 03:57:19.0370 (UTC) FILETIME=[2F822EA0:01CD1C4E] Cc: idxwg@nicwg.org, mile@ietf.org, dallendoug@gmail.com, sacm@ietf.org, m-terada@ipa.go.jp Subject: Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live onthe website X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 03:57:25 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD1C4E.2F4B01A2 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBiZWxpZXZlIHRoYXQgd2hhdCBTZWFuIGlzIHNheWluZyBpcyB0aGF0IOKAnGRhdGEgZmxvd+KA nSBpcyBqdXN0IGEgdmFsdWUgdGhhdCBpcyBtZWFudCBmb3IgdXBwZXIgbGF5ZXIgcHJvdG9jb2xz LiBCdXQsIHlvdSBoYXZlIGEgZ29vZCBwb2ludC4gVHJhZGl0aW9uYWxseSwgYSDigJxmbG934oCd IGluIOKAnE5ldGZsb3figJ0gaXMgYmFzZWQgb24gYSBzZXQgb2YgNSBhbmQgdXAgdG8gNyBJUCBw YWNrZXQgYXR0cmlidXRlczoNCg0KIA0KDQotIElQIHNvdXJjZSBhZGRyZXNzDQoNCi0gSVAgZGVz dGluYXRpb24gYWRkcmVzcw0KDQotIFNvdXJjZSBwb3J0DQoNCi0gRGVzdGluYXRpb24gcG9ydA0K DQotIExheWVyIDMgcHJvdG9jb2wgdHlwZQ0KDQotIENsYXNzIG9mIFNlcnZpY2UNCg0KLSBSb3V0 ZXIgb3Igc3dpdGNoIGludGVyZmFjZQ0KDQogDQoNCkFsdGhvdWdoLCB0aGVyZSBpcyBhIGxvdCBt b3JlIHN1cHBvcnQgd2l0aCBOZXRmbG93IHZlcnNpb24gOToNCg0KaHR0cDovL3d3dy5jaXNjby5j b20vZW4vVVMvdGVjaG5vbG9naWVzL3RrNjQ4L3RrMzYyL3RlY2hub2xvZ2llc193aGl0ZV9wYXBl cjA5MTg2YTAwODAwYTNkYjlfcHM2NjAxX1Byb2R1Y3RzX1doaXRlX1BhcGVyLmh0bWwNCg0KIA0K DQogDQoNCiANCg0KUmVnYXJkcywNCg0KT21hciANCg0KIA0KDQpGcm9tOiBNaWxsYXIsIFRob21h cyBbbWFpbHRvOlRob21hcy5NaWxsYXJAaHEuZGhzLmdvdl0gDQpTZW50OiBNb25kYXksIEFwcmls IDE2LCAyMDEyIDExOjQ2IFBNDQpUbzogc2Jhcm51bUBtaXRyZS5vcmc7IE9tYXIgU2FudG9zIChv c2FudG9zKTsgbG51bmV6QGMzaXNlY3VyaXR5LmNvbQ0KQ2M6IGlkeHdnQG5pY3dnLm9yZzsgbWls ZUBpZXRmLm9yZzsgZGFsbGVuZG91Z0BnbWFpbC5jb207IHNhY21AaWV0Zi5vcmc7IG0tdGVyYWRh QGlwYS5nby5qcA0KU3ViamVjdDogUmU6IFtzYWNtXSBbbWlsZV0gQ3liT1ggdjEuMCAoRHJhZnQp IGlzIG5vdyByZWxlYXNlZCBhbmQgbGl2ZSBvbnRoZSB3ZWJzaXRlDQoNCiANCg0KSWYgImRhdGEg ZmxvdyIgaXMgYSBldXBoZW1pc20gZm9yICJuZXRmbG93IiBpcyB0aGVyZSBhbnkgcmVhc29uIG5v dCB0byBjYWxsIGl0IHRoYXQ/DQoNClRvbSBNaWxsYXIgDQpodHRwOi8vd3d3LnVzLWNlcnQuZ292 LyANCi0tLS0tLS0tLS0tLS0tLS0tLSANCk1pc3NpdCBtZSBSdWJ1cyBmcnV0aWNvc3VzOiANCjIw MiA2MzEgMTkxNSANCg0KIA0KDQpGcm9tOiBCYXJudW0sIFNlYW4gRC4gW21haWx0bzpzYmFybnVt QG1pdHJlLm9yZ10gDQpTZW50OiBNb25kYXksIEFwcmlsIDE2LCAyMDEyIDExOjI5IFBNDQpUbzog T21hciBTYW50b3MgKG9zYW50b3MpIDxvc2FudG9zQGNpc2NvLmNvbT47IEx1aXMgTnVuZXogPGxu dW5lekBjM2lzZWN1cml0eS5jb20+IA0KQ2M6IGlkeHdnQG5pY3dnLm9yZyA8aWR4d2dAbmljd2cu b3JnPjsgbWlsZUBpZXRmLm9yZyA8bWlsZUBpZXRmLm9yZz47IGRhbGxlbmRvdWdAZ21haWwuY29t IDxkYWxsZW5kb3VnQGdtYWlsLmNvbT47IHNhY21AaWV0Zi5vcmcgPHNhY21AaWV0Zi5vcmc+OyBt LXRlcmFkYUBpcGEuZ28uanAgPG0tdGVyYWRhQGlwYS5nby5qcD4gDQpTdWJqZWN0OiBSZTogW3Nh Y21dIFttaWxlXSBDeWJPWCB2MS4wIChEcmFmdCkgaXMgbm93IHJlbGVhc2VkIGFuZCBsaXZlIG9u dGhlIHdlYnNpdGUgDQogDQoNClRoYW5rcyBPbWFyLg0KDQogDQoNClRvIGFuc3dlciB5b3VyIHF1 ZXN0aW9uLCBmaXJzdCBsZXQgbWUgcG9pbnQgb3V0IHRvIG90aGVyIHJlYWRlcnMgdGhhdCB0aGUg dHdvIGVudHJpZXMgdGhhdCBPbWFyIGlzIHF1b3RpbmcgaGVyZSBleGlzdCBhcyB2YWx1ZXMgaW4g YW4gZW51bWVyYXRpb24gY2FsbGVkIEV2ZW50VHlwZUVudW0gd2hpY2ggYXMgaXRzIG5hbWUgaW1w bGllcyBjb250YWlucyBhIGxpc3Qgb2YgZGlmZmVyZW50IGxhYmVscyBmb3IgZ3JvdXBpbmcgdHlw ZXMgKG9yIGNsYXNzZXMpIG9mIGV2ZW50cyB0byBiZSB1c2VkIGFzIGxvdy1ncmFudWxhcml0eSBi dWNrZXRzIGZvciBjaGFyYWN0ZXJpemluZyBhbmQgY2xhc3NpZnlpbmcgZXZlbnRzLg0KDQpPdGhl ciBlbnRyaWVzIGluIHRoaXMgZW51bWVyYXRpb24gaW5jbHVkZSB0aGluZ3MgbGlrZSDigJxGaWxl IE9wcyAoQ1JVRCnigJ0sIOKAnFByb2Nlc3MgTWd04oCdLCDigJxBdXRob3JpemF0aW9uIChBQ0wp 4oCdLCBldGMuDQoNCiANCg0KVGhlIOKAnFBhY2tldCBUcmFmZmlj4oCdIHZhbHVlIGlzIGludGVu ZGVkIHRvIGNoYXJhY3Rlcml6ZSBldmVudHMgZGVhbGluZyB3aXRoIG5ldHdvcmsgcGFja2V0IHRy YWZmaWMgYXMgaXRzIG5hbWUgaW1wbGllcy4NCg0KVGhlIOKAnERhdGEgRmxvd+KAnSB2YWx1ZSBp cyBpbnRlbmRlZCB0byBjaGFyYWN0ZXJpemUgZXZlbnRzIGRlYWxpbmcgd2l0aCBmb3JtcyBvZiBk YXRhIGZsb3cgYXQgYSBoaWdoZXIgbGV2ZWwgb2YgYWJzdHJhY3Rpb24gdGhhbiBqdXN0IHBhY2tl dCB0cmFmZmljLiBUaGUgcmVsYXRpb25zaGlwIGJldHdlZW4gdGhlc2UgdHdvIHZhbHVlcyBjb3Vs ZCBiZSB2aWV3ZWQgYXMg4oCcUGFja2V0IFRyYWZmaWPigJ0gYmVpbmcgYSBtb3JlIGRldGFpbGVk IGZvcm0gb2Yg4oCcRGF0YSBGbG934oCdIGp1c3QgYXMgdGhlIHZhbHVlcyDigJxBcHAgTGF5ZXIg VHJhZmZpY+KAnSBhbmQg4oCcSFRUUCBMYXllciBUcmFmZmlj4oCdLCBhbHNvIGluIHRoaXMgZW51 bWVyYXRpb24sIGNvdWxkIGJlIG90aGVyIGxldmVscyBpbiB0aGlzIHNhbWUgYWJzdHJhY3Rpb24g c3RhY2suDQoNClRoZSBpZGVhIGJlaGluZCB0aGUgdmFyeWluZyBsZXZlbHMgb2YgYWJzdHJhY3Rp b24gaXMgdG8gbGVhdmUgIGJ1Y2tldHMgbGFyZ2UgZW5vdWdoIHRvIGNhcHR1cmUgYSB3aWRlIHZh cmlldHkgb2YgcG90ZW50aWFsIGV2ZW50IHR5cGVzIChlLmcuIGRhdGEgZmxvdyBldmVudHMgb3Ro ZXIgdGhhbiBvYnZpb3VzIHRoaW5ncyBsaWtlIHBhY2tldCB0cmFmZmljKSBidXQgYWxzbyBlbmFi bGUgdGhlIHVzZSBvZiBzbWFsbGVyIG1vcmUgc3BlY2lmaWMgYnVja2V0cyB3aGVuIHRoZXkgYXJl IGFwcHJvcHJpYXRlIGFuZCBjb21tb25seSB1c2VkLg0KDQogDQoNCkRvZXMgdGhpcyBtYWtlIHNl bnNlPyANCg0KIA0KDQpzZWFuDQoNCiANCg0KRnJvbTogT21hciBTYW50b3MgKG9zYW50b3MpIFtt YWlsdG86b3NhbnRvc0BjaXNjby5jb21dIA0KU2VudDogTW9uZGF5LCBBcHJpbCAxNiwgMjAxMiA4 OjE3IFBNDQpUbzogTHVpcyBOdW5lejsgQmFybnVtLCBTZWFuIEQuDQpDYzogaWR4d2dAbmljd2cu b3JnOyBtaWxlQGlldGYub3JnOyBkYWxsZW5kb3VnQGdtYWlsLmNvbTsgc2FjbUBpZXRmLm9yZzsg bS10ZXJhZGFAaXBhLmdvLmpwDQpTdWJqZWN0OiBSRTogW3NhY21dIFttaWxlXSBDeWJPWCB2MS4w IChEcmFmdCkgaXMgbm93IHJlbGVhc2VkIGFuZCBsaXZlIG9udGhlIHdlYnNpdGUNCg0KIA0KDQpJ IGVjaG8gTHVpc+KAmSBjb21tZW50cy4gSXQgaXMgZ29vZCB0byBzZWUgdGhlIGluY2x1c2lvbiBv ZiBuZXR3b3JrIG9iamVjdHMuIFF1aWNrIHF1ZXN0aW9uIHRvIHRoZSB0ZWFtIHJlbGF0ZWQgdG8g eW91ciBuZXRmbG93IGNvbW1lbnQuDQoNCiANCg0KSSBhbSBsb29raW5nIGF0Og0KDQpodHRwOi8v Y3lib3gubWl0cmUub3JnL1hNTFNjaGVtYS9jeWJveF9jb3JlX3YxLjAlMjhkcmFmdCUyOS54c2QN Cg0KIA0KDQrigKYgYW5kIGl0IGxvb2tzIHRoYXQgd2UgcmVuYW1lZCBpdCB0byDigJxEYXRhIEZs b3figJ0/DQoNCiANCg0KPHhzOmVudW1lcmF0aW9uIHZhbHVlPSJEYXRhIEZsb3ciPg0KDQogICA8 eHM6YW5ub3RhdGlvbj4NCg0KICAgICAgICA8eHM6ZG9jdW1lbnRhdGlvbj5TcGVjaWZpZXMgdGhl IGNsYXNzIG9mIGV2ZW50cyBkZWFsaW5nIHdpdGggZGF0YSBmbG93LjwveHM6ZG9jdW1lbnRhdGlv bj4NCg0KICAgPC94czphbm5vdGF0aW9uPg0KDQo8L3hzOmVudW1lcmF0aW9uPg0KDQogDQoNCiAN Cg0KV2hhdCBpcyB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuIHRoYXQgYW5kIOKAnFBhY2tldCBUcmFm Zmlj4oCdPw0KDQogDQoNCjx4czplbnVtZXJhdGlvbiB2YWx1ZT0iUGFja2V0IFRyYWZmaWMiPg0K ICAgPHhzOmFubm90YXRpb24+DQogICAgIDx4czpkb2N1bWVudGF0aW9uPlNwZWNpZmllcyB0aGUg Y2xhc3Mgb2YgZXZlbnRzIGRlYWxpbmcgd2l0aCBwYWNrZXQgdHJhZmZpYy48L3hzOmRvY3VtZW50 YXRpb24+DQogICA8L3hzOmFubm90YXRpb24+DQo8L3hzOmVudW1lcmF0aW9uPg0KDQogDQoNCiAN Cg0KIA0KDQogDQoNClJlZ2FyZHMsDQoNCk9tYXIgU2FudG9zDQpJbmNpZGVudCBNYW5hZ2VyLCBQ U0lSVA0KU2VjdXJpdHkgUmVzZWFyY2ggYW5kIE9wZXJhdGlvbnMNCkNpc2NvIFN5c3RlbXMsIElu Yy4NCkVtYWlsOiBvc0BjaXNjby5jb20NClBob25lOiArMSA5MTkgMzkyIDg2MzUNClBHUCBLZXk6 IDB4M0FGMjdFREMNCg0KQ2lzY28uY29tIC0gaHR0cDovL3d3dy5jaXNjby5jb20NCkNpc2NvIFNl Y3VyaXR5IEFkdmlzb3JpZXMgYW5kIE5vdGljZXMgLSBodHRwOi8vd3d3LmNpc2NvLmNvbS9nby9w c2lydA0KDQpUaGlzIGVtYWlsIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBhbmQgcHJpdmlsZWdl ZCBtYXRlcmlhbCBmb3IgdGhlIHNvbGUNCnVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LiBB bnkgcmV2aWV3LCB1c2UsIGRpc3RyaWJ1dGlvbiBvcg0KZGlzY2xvc3VyZSBieSBvdGhlcnMgaXMg c3RyaWN0bHkgcHJvaGliaXRlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkDQpyZWNpcGll bnQgKG9yIGF1dGhvcml6ZWQgdG8gcmVjZWl2ZSBmb3IgdGhlIHJlY2lwaWVudCksIHBsZWFzZSBj b250YWN0DQp0aGUgc2VuZGVyIGJ5IHJlcGx5IGVtYWlsIGFuZCBkZWxldGUgYWxsIGNvcGllcyBv ZiB0aGlzIG1lc3NhZ2UuDQoNCkZvciBjb3Jwb3JhdGUgbGVnYWwgaW5mb3JtYXRpb24gZ28gdG86 DQpodHRwOi8vd3d3LmNpc2NvLmNvbS93ZWIvYWJvdXQvZG9pbmdfYnVzaW5lc3MvbGVnYWwvY3Jp L2luZGV4Lmh0bWwNCg0KIA0KDQpGcm9tOiBzYWNtLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpz YWNtLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBMdWlzIE51bmV6DQpTZW50OiBNb25k YXksIEFwcmlsIDE2LCAyMDEyIDY6NDQgUE0NClRvOiBCYXJudW0sIFNlYW4gRC4NCkNjOiBpZHh3 Z0BuaWN3Zy5vcmc7IG1pbGVAaWV0Zi5vcmc7IERvdWcgV2lsc29uIChkYWxsZW5kb3VnQGdtYWls LmNvbSk7IHNhY21AaWV0Zi5vcmc7IElQQS1NYXNhdG8gVGVyYWRhIChtLXRlcmFkYUBpcGEuZ28u anApDQpTdWJqZWN0OiBSZTogW3NhY21dIFttaWxlXSBDeWJPWCB2MS4wIChEcmFmdCkgaXMgbm93 IHJlbGVhc2VkIGFuZCBsaXZlIG9udGhlIHdlYnNpdGUNCg0KIA0KDQpJIGxpa2UgdGhlIGluY2x1 c2lvbiBvZiB0aGUgbmV0d29yay1jZW50cmljIG9iamVjdHMuICBJUEZJWCAobmV0ZmxvdykgIHdp bGwgYWRkIGFuIGFkZGl0aW9uYWwgcGVyc3BlY3RpdmUgZnJvbSBhbiBpbmNpZGVudCBpbmZvcm1h dGlvbiBzaGFyaW5nIHN0YW5kcG9pbnQuICANCg0KIA0KDQotbG4NCg0KIA0KDQpPbiBBcHIgMTYs IDIwMTIsIGF0IDQ6MDQgUE0sIEJhcm51bSwgU2VhbiBELiB3cm90ZToNCg0KIA0KDQpIZXkgZXZl cnlvbmUsDQoNCiANCg0KSSBqdXN0IHdhbnRlZCB0byBsZXQgeW91IGFsbCBrbm93IHRoYXQgQ3li T1ggdjEuMCAoRHJhZnQpIGNvbnRlbnQgaXMgbm93IGxpdmUgb24gdGhlIHdlYnNpdGUuIGh0dHA6 Ly9jeWJveC5taXRyZS5vcmcNCg0KVGhlIHJlbGVhc2Ugbm90ZXMgYXJlIHByb3ZpZGVkIGlubGlu ZSBiZWxvdy4NCg0KVGhlIGtleSBpdGVtcyBvZiBub3RlIGFyZToNCg0KwrcgICAgICAgIFRoZSBy ZWxlYXNlIG9mIHR3byBmb3JtYWwgc3BlY2lmaWNhdGlvbnMgZm9yIHRoZSBDeWJPWCBsYW5ndWFn ZSAob25lIGZvciB0aGUgY29yZSBsYW5ndWFnZSBhbmQgb25lIGZvciB0aGUgZGVmaW5lZCBvYmpl Y3RzKQ0KDQrCtyAgICAgICAgVGhlIFhNTCBTY2hlbWEgaGFzIGdvbmUgdGhyb3VnaCBleHRlbnNp dmUgaW1wcm92ZW1lbnRzIGZvciBleHByZXNzaXZlbmVzcywgY2xhcml0eSwgY29uc2lzdGVuY3ks IGVmZmljaWVuY3ksIGFsaWdubWVudCB0byBleGlzdGluZyBub3JtYXRpdmUgcmVmZXJlbmNlcyBh bmQgZG9jdW1lbnRhdGlvbi4NCg0KwrcgICAgICAgIFRoaXMgcmVsZWFzZSBpbmNsdWRlcyBhbiBp bml0aWFsIHNldCBvZiBsYW5ndWFnZSB1dGlsaXRpZXM6IGEgZHJhZnQgU25vcnQgLT4gQ3liT1gg dHJhbnNmb3JtLCBhIGRyYWZ0IE9wZW5JT0MgLT4gQ3liT1ggdHJhbnNmb3JtLCBhbmQgYSBzZXQg b2YgUHl0aG9uIGJpbmRpbmdzIGZvciB0aGUgQ3liT1ggbGFuZ3VhZ2UuDQoNCsK3ICAgICAgICBU aGUgd2Vic2l0ZSBub3cgaW5jbHVkZXMgYSBzbWFsbCBzZXQgb2YgY29udGVudCBleGFtcGxlcy4g VGhpcyBzZXQgd2lsbCBncm93IGdvaW5nIGZvcndhcmQuDQoNClRoaXMgcmVsZWFzZSBpbnZvbHZl ZCBhIGxvdCBvZiBoYXJkIHdvcmsgZnJvbSBhIGRpdmVyc2UgZ3JvdXAgb2YgcGVvcGxlLiBUaGFu ayB5b3UgYWxsIGZvciB5b3VyIGNvbnRyaWJ1dGlvbnMgYW5kIGVmZm9ydC4gV2UgY291bGQgbm90 IGhhdmUgZG9uZSBpdCB3aXRob3V0IHlvdS4NCg0KV2UgbG9vayBmb3J3YXJkIHRvIGV2ZXJ5b25l 4oCZcyBmZWVkYmFjayBhbmQgY29sbGFib3JhdGlvbiBhcyB3ZSBjb250aW51ZSB0byBpbXByb3Zl IGFuZCBtYXR1cmUgdGhlIEN5Yk9YIGxhbmd1YWdlLg0KDQogDQoNClNlYW4gQmFybnVtDQoNCiAN Cg0KIA0KDQogDQoNCkN5Yk9YIHYxLjAgKERyYWZ0KSBSZWxlYXNlIE5vdGVzDQoNClRoZSBWZXJz aW9uIDEuMCAoRHJhZnQpIHJlbGVhc2Ugb2YgQ3liZXIgT2JzZXJ2YWJsZSBlWHByZXNzaW9uIChD eWJPWOKEoikgaXMgaW50ZW5kZWQgYXMgYSBkcmFmdCByZWxlYXNlIG9mIGFuIGluaXRpYWwgbWFq b3IgdmVyc2lvbiBvZiB0aGUgQ3liT1ggTGFuZ3VhZ2UgdGhhdCBjb3VsZCBiZSB1dGlsaXplZCBm b3IgcHJhY3RpY2FsIG9wZXJhdGlvbmFsIHVzZSBhbmQgaW50ZWdyYXRpb24gaW50byBvdGhlciBz dGFuZGFyZHMgZWZmb3J0cy4gVGhpcyByZWxlYXNlIGNvbnNpc3RzIG9mIHRocmVlIHByaW1hcnkg Y29tcG9uZW50czogYSBwYWlyIG9mIGZvcm1hbCBsYW5ndWFnZSBzcGVjaWZpY2F0aW9ucyBmb3Ig dGhlIGNvcmUgbGFuZ3VhZ2UgY29udGVudCBhbmQgZGVmaW5lZCBvYmplY3RzIGNvbnRlbnQsIGEg c2V0IG9mIGxhbmd1YWdlIGltcGxlbWVudGF0aW9uIFhNTCBzY2hlbWFzIChjb3JlLCBjb21tb25f dHlwZXMsIGFuZCB+NzAgZGVmaW5lZCBvYmplY3Qgc2NoZW1hcyksIGFuZCBhIHNtYWxsIGluaXRp YWwgc2V0IG9mIGxhbmd1YWdlIHV0aWxpdGllcyBpbmNsdWRpbmcgYW4gaW5pdGlhbCBkcmFmdCBT bm9ydC0+Q3liT1ggdHJhbnNmb3JtLCBhbiBpbml0aWFsIGRyYWZ0IE9wZW5JT0MtPkN5Yk9YIHRy YW5zZm9ybSBhbmQgYSBzZXQgb2YgQ3liT1ggbGFuZ3VhZ2UgUHl0aG9uIGJpbmRpbmdzLiBSZWNv Z25pemluZyB0aGF0IHRoaXMgaXMgdGhlIGZpcnN0IHRpbWUgdGhhdCB0aGUgZm9ybWFsIGxhbmd1 YWdlIHNwZWNpZmljYXRpb25zIHdpbGwgYmUgYXZhaWxhYmxlIGZvciByZXZpZXcgYW5kIGFzIHN1 Y2ggd2lsbCBsaWtlbHkgZ2VuZXJhdGUgZmVlZGJhY2sgZnJvbSBuZXcgc3Rha2Vob2xkZXJzLCB0 aGlzIGluaXRpYWwgbWFqb3IgdmVyc2lvbiBpcyBiZWluZyByZWxlYXNlZCBhcyBhIOKAnGRyYWZ0 4oCdIHYxLjAgd2l0aCB0aGUgZXhwZWN0YXRpb24gb2YgY3ljbGVzIG9mIG5ldyBmZWVkYmFjayBh bmQgcmV2aXNpb24gYmVmb3JlIGEg4oCcZmluYWzigJ0gdjEuMCBpcyByZWxlYXNlZC4NCg0KVGhl IEN5Yk9YIHYxLjAgKERyYWZ0KSBYTUwgc2NoZW1hcyBpbmNsdWRlIGEgc2lnbmlmaWNhbnQgbnVt YmVyIG9mIGNoYW5nZXMgZnJvbSB2MC43IHRvIGltcHJvdmU6DQoNCsK3ICAgICAgIENsYXJpdHks IGRvY3VtZW50YXRpb24sIGFuZCBkZXNjcmlwdGl2ZSBmb3JtYWxpdHkgZm9yIHJlZmVyZW5jZSBh bmQgaW1wbGVtZW50YXRpb24gYnkgb3RoZXIgc3RhbmRhcmRzIGFuZCB1c2Vycy4NCg0KwrcgICAg ICAgQ29uc2lzdGVuY3ksIHNpbXBsaWNpdHksIGFuZCBlZmZpY2llbmN5Lg0KDQrCtyAgICAgICBB bGlnbm1lbnQgKGFzIGFwcHJvcHJpYXRlKSB0byBleGlzdGluZyBub3JtYXRpdmUgcmVmZXJlbmNl cy4NCg0KwrcgICAgICAgRXhwcmVzc2l2ZW5lc3Mgb2YgdGhlIHNjaGVtYSB0byBiZXR0ZXIgc3Vw cG9ydCB0aGUgYnJvYWQgc2V0IG9mIHVzZSBjYXNlcyBpdCB0YXJnZXRzIChtYWx3YXJlIGNoYXJh Y3Rlcml6YXRpb24sIGluZGljYXRvciBhbmQgaW5jaWRlbnQgZGF0YSBzaGFyaW5nLCBldmVudCBt YW5hZ2VtZW50LCBldGMuKSBpbmNsdWRpbmcgdGhlIGFkZGl0aW9uIG9mIGFuIGluaXRpYWwgc2V0 IG9mIG5ldHdvcmstcmVsYXRlZCBkZWZpbmVkIG9iamVjdHMuDQoNClN1bW1hcnkgb2YgY2hhbmdl cyBmcm9tIEN5Yk9YX3YwLjcgdG8gQ3liT1hfdjEuMF8oRHJhZnQpOg0KDQrCtyAgICAgICAgIFJl ZmluZW1lbnQgb2YgbmFtZXNwYWNlcyBhbmQgc2NoZW1hIGxvY2F0aW9ucyBmb3IgYmV0dGVyIGVm ZmVjdGl2ZW5lc3MgYW5kIGZsZXhpYmlsaXR5IGdvaW5nIGZvcndhcmQuDQoNCsK3ICAgICAgICAg Tm9ybWFsaXplZCBhbGwgY29udGVudCBhY2NvcmRpbmcgdG8gYW4gZXN0YWJsaXNoZWQgc2V0IG9m IG5hbWluZyBjb252ZW50aW9ucy4NCg0KwrcgICAgICAgICBGdWxseSBhbm5vdGF0ZWQgYWxsIGxh bmd1YWdlIGl0ZW1zICh0eXBlcywgYXR0cmlidXRlcywgZWxlbWVudHMsIGV0Yy4pLg0KDQrCtyAg ICAgICAgIE1vdmVkIHNldmVyYWwgY29tbW9ubHkgbGV2ZXJhZ2VkIHR5cGVzIG91dCBvZiB0aGUg Y29yZSBzY2hlbWEgYW5kIGludG8gY29tbW9uX3R5cGVzLg0KDQrCtyAgICAgICAgIEFjaGlldmVk IGZ1bGwgdHlwaW5nIG9mIGVudGlyZSBzY2hlbWEgc3RydWN0dXJlIHN1Y2ggdGhhdCBhbGwgYXR0 cmlidXRlcyBhbmQgZWxlbWVudHMgYXJlIGRlZmluaXRpdmVseSB0eXBlZC4NCg0KwrcgICAgICAg ICBDaGFuZ2VkIGFsbCBpZGVudGlmaWVycyBmcm9tIElEIGFuZCBJRFJFRiB0eXBlcyB0byBiZSBR TmFtZXMgZW5hYmxpbmcgZ2xvYmFsbHkgdW5pcXVlIGlkZW50aWZpZXJzIGFuZCBmbGV4aWJpbGl0 eSBmb3IgZG9tYWluLXNwZWNpZmljIHVzZXJzIG9mIEN5Yk9YIHRvIGRlZmluZSB0aGVpciBvd24g aWRlbnRpZmllciBzeW50YXggbG9jYWxseS4NCg0KwrcgICAgICAgICBSZW9yZGVyZWQgYXR0cmli dXRlcyBhbmQgZWxlbWVudHMgaW4gbnVtZXJvdXMgdHlwZXMgdG8gYmV0dGVyIHJlZmxlY3QgY29t bW9uIHVzYWdlIGFuZCBwcmlvcml0eS4NCg0KwrcgICAgICAgICBBZGRlZCBtYWpvcl92ZXJzaW9u IGFuZCBtaW5vcl92ZXJzaW9uIGF0dHJpYnV0ZXMgZm9yIGNvcmUgc2NoZW1hLg0KDQrCtyAgICAg ICAgIEFkZGVkIGNhcGFiaWxpdHkgdG8gY2hhcmFjdGVyaXplIHNvdXJjZSBvZiBvdmVyYWxsIG9i c2VydmFibGUgcGFja2FnZSBkYXRhIGFuZCBmb3IgaW5kaXZpZHVhbCBvYnNlcnZhYmxlcy4NCg0K wrcgICAgICAgICBNb2RpZmllZCB0aGUgbG9naWNhbCBjb21wb3NpdGlvbiBzdHJ1Y3R1cmUgc3Vj aCB0aGF0IGFueSBzdWNoIGNvbXBvc2l0aW9ucyBhcmUgbm93IGNvbnRhaW5lZCB3aXRoaW4gYSBP YnNlcnZhYmxlX0NvbXBvc2l0aW9uIGVsZW1lbnQgcHJvdmlkaW5nIGltcHJvdmVkIHNpbXBsaWNp dHkgYW5kIG1vZHVsYXJpdHkuDQoNCsK3ICAgICAgICAgUmVtb3ZlZCB0aGUgRGVsdGEgZWxlbWVu dCBmcm9tIE9ic2VydmFibGVUeXBlIGFuZCByZWxvY2F0ZWQgdGhlIGFwcHJvcHJpYXRlIHBvcnRp b25zIChDaGFuZ2UsIFRyZW5kLCBhbmQgRnJlcXVlbmN5KSB0byBhcHByb3ByaWF0ZSBsb2NhdGlv bnMgdW5kZXIgU3RhdGVmdWxfTWVhc3VyZSBhbmQgRXZlbnQuDQoNCsK3ICAgICAgICAgQWRkZWQg YSBEb21haW5fU3BlY2lmaWNfT2JqZWN0X0F0dHJpYnV0ZXMgZmllbGQgdG8gT2JqZWN0IHV0aWxp emluZyBhbiBhYnN0cmFjdCB0eXBlIHRoYXQgd2lsbCBhbGxvdyBkb21haW4tc3BlY2lmaWMgdXNl IGNhc2VzIHRvIGFkZCBpbiB0aGVpciBvd24gZG9tYWluLXNwZWNpZmljIGF0dHJpYnV0ZXMgZm9y IE9iamVjdHMuDQoNCsK3ICAgICAgICAgQWRkZWQgYSBUb29sLVNwZWNpZmljX0RhdGEgZmllbGQg dG8gVG9vbEluZm9ybWF0aW9uVHlwZSB1dGlsaXppbmcgYW4gYWJzdHJhY3QgdHlwZSB0aGF0IHdp bGwgYWxsb3cgYWRkaXRpb24gb2YgdG9vbC1zcGVjaWZpYyBkYXRhLg0KDQrCtyAgICAgICAgIEFk ZGVkIGFuIEluZGljYXRvcnMgZmllbGQgdG8gTWVhc3VyZVNvdXJjZVR5cGUgdXRpbGl6aW5nIGFu IGFic3RyYWN0IHR5cGUgdGhhdCB3aWxsIGFsbG93IGNoYXJhY3Rlcml6aW5nIGRpZmZlcmluZyBm b3JtYXRzIG9yIHN0YW5kYXJkcyBvZiBpbmRpY2F0b3JzIHRoYXQgbWF5IGhhdmUgbGVkIHRvIHRo ZSBpZGVudGlmaWNhdGlvbiBvZiB0aGUgb2JzZXJ2YWJsZSBkYXRhLg0KDQrCtyAgICAgICAgIEVu aGFuY2VkIHRoZSBIYXNoIHN0cnVjdHVyZSB0byBjYXB0dXJlIGZ1bGwgZnV6enkgaGFzaGVzIGlu IGFkZGl0aW9uIHRvIHNpbXBsZSBoYXNoZXMNCg0KwrcgICAgICAgICBBZGRlZCBhIG5ldyBFeHRy YWN0ZWRGZWF0dXJlc1R5cGUgdGhhdCBjYW4gYmUgdXNlZCB0byBhZG9ybiBkaWZmZXJpbmcgb2Jq ZWN0cyAoZS5nLiwgZmlsZXMsIG1lbW9yeSwgZXRjLikgdG8gY2FwdHVyZSBleHRyYWN0ZWQgc3Ry aW5ncywgaW1wb3J0cywgZnVuY3Rpb25zIGFuZCBjb2RlIHNuaXBwZXRzDQoNCsK3ICAgICAgICAg QWRkZWQgYSBCeXRlUnVuc1R5cGUgdG8gZW5hYmxlIGNhcHR1cmUgb2YgYnl0ZSBydW5zIHdpdGhp biB2YXJpb3VzIG9iamVjdHMuDQoNCsK3ICAgICAgICAgQWRkZWQgb2JqZWN0X3JlZmVyZW5jZSBh dHRyaWJ1dGUgdG8gRGVmaW5lZE9iamVjdFR5cGUgdG8gYmV0dGVyIHN1cHBvcnQgcmVmZXJlbmNp bmcgb2YgaW5kZXBlbmRlbnRseSBkZWZpbmVkIE9iamVjdHMgZnJvbSB3aXRoaW4gYW5vdGhlciBP YmplY3QgZGVmaW5pdGlvbi4NCg0KwrcgICAgICAgICBBZGRlZCBhIGdlbmVyaWMgRGF0YVNlZ21l bnRUeXBlIHRvIHByb3ZpZGUgYSByZWxhdGl2ZWx5IGFic3RyYWN0IHdheSBvZiBjaGFyYWN0ZXJp emluZyBkYXRhIHNlZ21lbnRzIHRoYXQgbWF5IGJlIHdyaXR0ZW4vcmVhZC90cmFuc21pdHRlZCBv ciBvdGhlcndpc2UgdXRpbGl6ZWQgaW4gYWN0aW9ucyBvciBkZWZpbmVkIGluIG9iamVjdHMuDQoN CsK3ICAgICAgICBBZGRlZCBzZXZlcmFsIG5ldyBkZWZpbmVkIG9iamVjdCBzY2hlbWFzIChBUEks IENvZGUsIERldmljZSwgRE5TX1JlY29yZCwgTmV0d29ya19GbG93LCBOZXR3b3JrX1BhY2tldCwg TmV0d29ya19Sb3V0ZV9FbnRyeSwgTmV0d29ya19TdWJuZXQsIFVuaXhfTmV0d29ya19Sb3V0ZV9F bnRyeSkgaW5jbHVkaW5nIGFuIGluaXRpYWwgc2V0IG9mIG5ldHdvcmstY2VudHJpYyBkZWZpbmVk IG9iamVjdHMuDQoNCsK3ICAgICAgICAgTW9kaWZpZWQgZXZlcnkgZGVmaW5lZCBvYmplY3Qgc2No ZW1hIHdpdGggYWRkZWQgYW5ub3RhdGlvbnMgYXMgd2VsbCBhcyBtaW5vciBhbmQgaW4gc29tZSBj YXNlcyBzdWJzdGFudGl2ZSBjaGFuZ2VzIHRvIGZpeCBlcnJvcnMsIGltcHJvdmUgY29uc2lzdGVu Y3kgYW5kIGFsaWdubWVudCB3aXRoIGV4aXN0aW5nIG5vcm1hdGl2ZSByZWZlcmVuY2VzLCBhbmQg dG8gaW1wcm92ZSBleHByZXNzaXZlbmVzcyBpbiBzdXBwb3J0IG9mIHRoZSB0YXJnZXRlZCB1c2Ug Y2FzZXMuDQoNCkRldGFpbGVkIGNoYW5nZXMgZnJvbSBDeWJPWF92MC43IHRvIEN5Yk9YX3YxLjBf KERyYWZ0KToNCg0KVGhlIGxldmVsIG9mIGNoYW5nZXMgd2l0aGluIHYxLjAgKERyYWZ0KSBpbiB0 aGUgY29yZSBzY2hlbWEsIGNvbW1vbl90eXBlcyBhbmQgdGhlIGRlZmluZWQgb2JqZWN0IHNjaGVt YXMgaXMgdG9vIGdyZWF0IHRvIGxpc3QgZXZlcnkgY2hhbmdlIGluIHRoZXNlIHJlbGVhc2Ugbm90 ZXMuIERldGFpbGVkIGRpZmZlcmVuY2UgcmVwb3J0cyBhcmUgYXZhaWxhYmxlIGZvciBlYWNoIGlu ZGl2aWR1YWwgc2NoZW1hIGF0Omh0dHA6Ly9jeWJveC5taXRyZS5vcmcvWE1MU2NoZW1hL3JlbGVh c2Vfbm90ZXMvY3lib3hfdjEuMChkcmFmdClfZGlmZl9yZXBvcnRzLnppcCA8aHR0cDovL2N5Ym94 Lm1pdHJlLm9yZy9YTUxTY2hlbWEvcmVsZWFzZV9ub3Rlcy9jeWJveF92MS4wKGRyYWZ0KV9kaWZm X3JlcG9ydHMuemlwPiANCg0KIA0KDQogDQoNCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09DQoNClNlYW4gQmFybnVtDQoNCkN5YmVyIFNlY3VyaXR5IFByaW5j aXBhbA0KDQpUaGUgTUlUUkUgQ29ycG9yYXRpb24NCg0KRW1haWw6IHNiYXJudW1AbWl0cmUub3Jn DQoNCiANCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cm1pbGUgbWFpbGluZyBsaXN0DQptaWxlQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL21pbGUNCg0KIA0KDQo= ------_=_NextPart_001_01CD1C4E.2F4B01A2 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PGJhc2UgaHJlZj0ieC1tc2c6 Ly8yMDEyLyI+PHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEg NiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FtYnJpYTsNCglw YW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KcC5N c29UaXRsZSwgbGkuTXNvVGl0bGUsIGRpdi5Nc29UaXRsZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6 MTA7DQoJbXNvLXN0eWxlLWxpbms6IlRpdGxlIENoYXIiOw0KCW1zby1tYXJnaW4tdG9wLWFsdDph dXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJ bWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVz IE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFBy ZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5Nc29B Y2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGlu Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1p bHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlz dFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0 Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4w cHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpzcGFuLkhUTUxQ cmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFy IjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9y bWF0dGVkIjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnNwYW4uVGl0bGVDaGFyDQoJ e21zby1zdHlsZS1uYW1lOiJUaXRsZSBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6MTA7DQoJ bXNvLXN0eWxlLWxpbms6VGl0bGU7DQoJZm9udC1mYW1pbHk6IkNhbWJyaWEiLCJzZXJpZiI7DQoJ Y29sb3I6IzE3MzY1RDsNCglsZXR0ZXItc3BhY2luZzouMjVwdDt9DQpzcGFuLmFwcGxlLXN0eWxl LXNwYW4NCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtc3R5bGUtc3Bhbjt9DQpzcGFuLmFwcGxlLWNv bnZlcnRlZC1zcGFjZQ0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1jb252ZXJ0ZWQtc3BhY2U7fQ0K c3Bhbi5FbWFpbFN0eWxlMjQNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxT dHlsZTI1DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyNg0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNv LXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIs InNhbnMtc2VyaWYiO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41 aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNl Y3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBs aXN0IGwwDQoJe21zby1saXN0LWlkOjExMjU2NTYwMjA7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRz Oi04MTgwMjAxOTY7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4w aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpA bGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9 DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1m b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDkN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDoxMzM1MjMxNTMx Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxMTczMTQ4NDMyO30NCkBsaXN0IGwxOmxldmVsMQ0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0K CW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9w OjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7 fQ0KQGxpc3QgbDE6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw0 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1i b2w7fQ0KQGxpc3QgbDE6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFu c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2 ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv grc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw4DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpT eW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNv LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0Kb2wNCgl7bWFy Z2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNw aWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBk YXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPjwvaGVhZD48Ym9k eSBsYW5nPUVOLVVTIGxpbms9Ymx1ZSB2bGluaz1wdXJwbGU+PGRpdiBjbGFzcz1Xb3JkU2VjdGlv bjE+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+SSBiZWxpZXZlIHRo YXQgd2hhdCBTZWFuIGlzIHNheWluZyBpcyB0aGF0IOKAnGRhdGEgZmxvd+KAnSBpcyBqdXN0IGEg dmFsdWUgdGhhdCBpcyBtZWFudCBmb3IgdXBwZXIgbGF5ZXIgcHJvdG9jb2xzLiBCdXQsIHlvdSBo YXZlIGEgZ29vZCBwb2ludC4gVHJhZGl0aW9uYWxseSwgYSDigJxmbG934oCdIGluIOKAnE5ldGZs b3figJ0gaXMgYmFzZWQgb24gYSBzZXQgb2YgNSBhbmQgdXAgdG8gNyBJUCBwYWNrZXQgYXR0cmli dXRlczo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29s b3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPi0gSVAgc291cmNlIGFkZHJlc3M8bzpwPjwvbzpwPjwv c3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+LSBJUCBk ZXN0aW5hdGlvbiBhZGRyZXNzPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPi0gU291cmNlIHBvcnQ8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+LSBEZXN0aW5hdGlv biBwb3J0PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2Nv bG9yOiMxRjQ5N0QnPi0gTGF5ZXIgMyBwcm90b2NvbCB0eXBlPG86cD48L286cD48L3NwYW4+PC9w PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPi0gQ2xhc3Mgb2YgU2Vy dmljZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xv cjojMUY0OTdEJz4tIFJvdXRlciBvciBzd2l0Y2ggaW50ZXJmYWNlPG86cD48L286cD48L3NwYW4+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdE Jz5BbHRob3VnaCwgdGhlcmUgaXMgYSBsb3QgbW9yZSBzdXBwb3J0IHdpdGggTmV0ZmxvdyB2ZXJz aW9uIDk6PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48YSBocmVmPSJo dHRwOi8vd3d3LmNpc2NvLmNvbS9lbi9VUy90ZWNobm9sb2dpZXMvdGs2NDgvdGszNjIvdGVjaG5v bG9naWVzX3doaXRlX3BhcGVyMDkxODZhMDA4MDBhM2RiOV9wczY2MDFfUHJvZHVjdHNfV2hpdGVf UGFwZXIuaHRtbCI+aHR0cDovL3d3dy5jaXNjby5jb20vZW4vVVMvdGVjaG5vbG9naWVzL3RrNjQ4 L3RrMzYyL3RlY2hub2xvZ2llc193aGl0ZV9wYXBlcjA5MTg2YTAwODAwYTNkYjlfcHM2NjAxX1By b2R1Y3RzX1doaXRlX1BhcGVyLmh0bWw8L2E+PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjojMUY0 OTdEJz5SZWdhcmRzLDxicj48YnI+T21hciA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPjxkaXY+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAj QjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4nPjxwIGNsYXNzPU1zb05vcm1h bD48Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwi c2Fucy1zZXJpZiInPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPiBNaWxsYXIsIFRob21hcyBbbWFp bHRvOlRob21hcy5NaWxsYXJAaHEuZGhzLmdvdl0gPGJyPjxiPlNlbnQ6PC9iPiBNb25kYXksIEFw cmlsIDE2LCAyMDEyIDExOjQ2IFBNPGJyPjxiPlRvOjwvYj4gc2Jhcm51bUBtaXRyZS5vcmc7IE9t YXIgU2FudG9zIChvc2FudG9zKTsgbG51bmV6QGMzaXNlY3VyaXR5LmNvbTxicj48Yj5DYzo8L2I+ IGlkeHdnQG5pY3dnLm9yZzsgbWlsZUBpZXRmLm9yZzsgZGFsbGVuZG91Z0BnbWFpbC5jb207IHNh Y21AaWV0Zi5vcmc7IG0tdGVyYWRhQGlwYS5nby5qcDxicj48Yj5TdWJqZWN0OjwvYj4gUmU6IFtz YWNtXSBbbWlsZV0gQ3liT1ggdjEuMCAoRHJhZnQpIGlzIG5vdyByZWxlYXNlZCBhbmQgbGl2ZSBv bnRoZSB3ZWJzaXRlPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjxwIGNsYXNzPU1z b05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtj b2xvcjojMUY0OTdEJz5JZiAmcXVvdDtkYXRhIGZsb3cmcXVvdDsgaXMgYSBldXBoZW1pc20gZm9y ICZxdW90O25ldGZsb3cmcXVvdDsgaXMgdGhlcmUgYW55IHJlYXNvbiBub3QgdG8gY2FsbCBpdCB0 aGF0Pzxicj48YnI+VG9tIE1pbGxhciA8YnI+PGEgaHJlZj0iaHR0cDovL3d3dy51cy1jZXJ0Lmdv di8iPmh0dHA6Ly93d3cudXMtY2VydC5nb3YvPC9hPiA8YnI+LS0tLS0tLS0tLS0tLS0tLS0tIDxi cj5NaXNzaXQgbWUgUnVidXMgZnJ1dGljb3N1czogPGJyPjIwMiA2MzEgMTkxNSA8YnI+PC9zcGFu Pjxicj4mbmJzcDs8bzpwPjwvbzpwPjwvcD48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbic+PHAgY2xh c3M9TXNvTm9ybWFsPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+RnJvbTwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz46IEJhcm51bSwg U2VhbiBELiA8YSBocmVmPSJtYWlsdG86W21haWx0bzpzYmFybnVtQG1pdHJlLm9yZ10iPlttYWls dG86c2Jhcm51bUBtaXRyZS5vcmddPC9hPiA8YnI+PGI+U2VudDwvYj46IE1vbmRheSwgQXByaWwg MTYsIDIwMTIgMTE6MjkgUE08YnI+PGI+VG88L2I+OiBPbWFyIFNhbnRvcyAob3NhbnRvcykgJmx0 OzxhIGhyZWY9Im1haWx0bzpvc2FudG9zQGNpc2NvLmNvbSI+b3NhbnRvc0BjaXNjby5jb208L2E+ Jmd0OzsgTHVpcyBOdW5leiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmxudW5lekBjM2lzZWN1cml0eS5j b20iPmxudW5lekBjM2lzZWN1cml0eS5jb208L2E+Jmd0OyA8YnI+PGI+Q2M8L2I+OiA8YSBocmVm PSJtYWlsdG86aWR4d2dAbmljd2cub3JnIj5pZHh3Z0BuaWN3Zy5vcmc8L2E+ICZsdDs8YSBocmVm PSJtYWlsdG86aWR4d2dAbmljd2cub3JnIj5pZHh3Z0BuaWN3Zy5vcmc8L2E+Jmd0OzsgPGEgaHJl Zj0ibWFpbHRvOm1pbGVAaWV0Zi5vcmciPm1pbGVAaWV0Zi5vcmc8L2E+ICZsdDs8YSBocmVmPSJt YWlsdG86bWlsZUBpZXRmLm9yZyI+bWlsZUBpZXRmLm9yZzwvYT4mZ3Q7OyA8YSBocmVmPSJtYWls dG86ZGFsbGVuZG91Z0BnbWFpbC5jb20iPmRhbGxlbmRvdWdAZ21haWwuY29tPC9hPiAmbHQ7PGEg aHJlZj0ibWFpbHRvOmRhbGxlbmRvdWdAZ21haWwuY29tIj5kYWxsZW5kb3VnQGdtYWlsLmNvbTwv YT4mZ3Q7OyA8YSBocmVmPSJtYWlsdG86c2FjbUBpZXRmLm9yZyI+c2FjbUBpZXRmLm9yZzwvYT4g Jmx0OzxhIGhyZWY9Im1haWx0bzpzYWNtQGlldGYub3JnIj5zYWNtQGlldGYub3JnPC9hPiZndDs7 IDxhIGhyZWY9Im1haWx0bzptLXRlcmFkYUBpcGEuZ28uanAiPm0tdGVyYWRhQGlwYS5nby5qcDwv YT4gJmx0OzxhIGhyZWY9Im1haWx0bzptLXRlcmFkYUBpcGEuZ28uanAiPm0tdGVyYWRhQGlwYS5n by5qcDwvYT4mZ3Q7IDxicj48Yj5TdWJqZWN0PC9iPjogUmU6IFtzYWNtXSBbbWlsZV0gQ3liT1gg djEuMCAoRHJhZnQpIGlzIG5vdyByZWxlYXNlZCBhbmQgbGl2ZSBvbnRoZSB3ZWJzaXRlIDxicj48 L3NwYW4+Jm5ic3A7PG86cD48L286cD48L3A+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7Y29sb3I6IzFGNDk3RCc+VGhhbmtzIE9tYXIuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5UbyBhbnN3 ZXIgeW91ciBxdWVzdGlvbiwgZmlyc3QgbGV0IG1lIHBvaW50IG91dCB0byBvdGhlciByZWFkZXJz IHRoYXQgdGhlIHR3byBlbnRyaWVzIHRoYXQgT21hciBpcyBxdW90aW5nIGhlcmUgZXhpc3QgYXMg dmFsdWVzIGluIGFuIGVudW1lcmF0aW9uIGNhbGxlZCBFdmVudFR5cGVFbnVtIHdoaWNoIGFzIGl0 cyBuYW1lIGltcGxpZXMgY29udGFpbnMgYSBsaXN0IG9mIGRpZmZlcmVudCBsYWJlbHMgZm9yIGdy b3VwaW5nIHR5cGVzIChvciBjbGFzc2VzKSBvZiBldmVudHMgdG8gYmUgdXNlZCBhcyBsb3ctZ3Jh bnVsYXJpdHkgYnVja2V0cyBmb3IgY2hhcmFjdGVyaXppbmcgYW5kIGNsYXNzaWZ5aW5nIGV2ZW50 cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6 IzFGNDk3RCc+T3RoZXIgZW50cmllcyBpbiB0aGlzIGVudW1lcmF0aW9uIGluY2x1ZGUgdGhpbmdz IGxpa2Ug4oCcRmlsZSBPcHMgKENSVUQp4oCdLCDigJxQcm9jZXNzIE1ndOKAnSwg4oCcQXV0aG9y aXphdGlvbiAoQUNMKeKAnSwgZXRjLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+VGhlIOKAnFBhY2tldCBU cmFmZmlj4oCdIHZhbHVlIGlzIGludGVuZGVkIHRvIGNoYXJhY3Rlcml6ZSBldmVudHMgZGVhbGlu ZyB3aXRoIG5ldHdvcmsgcGFja2V0IHRyYWZmaWMgYXMgaXRzIG5hbWUgaW1wbGllcy48bzpwPjwv bzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+ VGhlIOKAnERhdGEgRmxvd+KAnSB2YWx1ZSBpcyBpbnRlbmRlZCB0byBjaGFyYWN0ZXJpemUgZXZl bnRzIGRlYWxpbmcgd2l0aCBmb3JtcyBvZiBkYXRhIGZsb3cgYXQgYSBoaWdoZXIgbGV2ZWwgb2Yg YWJzdHJhY3Rpb24gdGhhbiBqdXN0IHBhY2tldCB0cmFmZmljLiBUaGUgcmVsYXRpb25zaGlwIGJl dHdlZW4gdGhlc2UgdHdvIHZhbHVlcyBjb3VsZCBiZSB2aWV3ZWQgYXMg4oCcUGFja2V0IFRyYWZm aWPigJ0gYmVpbmcgYSBtb3JlIGRldGFpbGVkIGZvcm0gb2Yg4oCcRGF0YSBGbG934oCdIGp1c3Qg YXMgdGhlIHZhbHVlcyDigJxBcHAgTGF5ZXIgVHJhZmZpY+KAnSBhbmQg4oCcSFRUUCBMYXllciBU cmFmZmlj4oCdLCBhbHNvIGluIHRoaXMgZW51bWVyYXRpb24sIGNvdWxkIGJlIG90aGVyIGxldmVs cyBpbiB0aGlzIHNhbWUgYWJzdHJhY3Rpb24gc3RhY2suPG86cD48L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlRoZSBpZGVhIGJlaGluZCB0 aGUgdmFyeWluZyBsZXZlbHMgb2YgYWJzdHJhY3Rpb24gaXMgdG8gbGVhdmUgJm5ic3A7YnVja2V0 cyBsYXJnZSBlbm91Z2ggdG8gY2FwdHVyZSBhIHdpZGUgdmFyaWV0eSBvZiBwb3RlbnRpYWwgZXZl bnQgdHlwZXMgKGUuZy4gZGF0YSBmbG93IGV2ZW50cyBvdGhlciB0aGFuIG9idmlvdXMgdGhpbmdz IGxpa2UgcGFja2V0IHRyYWZmaWMpIGJ1dCBhbHNvIGVuYWJsZSB0aGUgdXNlIG9mIHNtYWxsZXIg bW9yZSBzcGVjaWZpYyBidWNrZXRzIHdoZW4gdGhleSBhcmUgYXBwcm9wcmlhdGUgYW5kIGNvbW1v bmx5IHVzZWQuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi O2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5Eb2VzIHRoaXMgbWFrZSBzZW5zZT8gPG86cD48 L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0Qn PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtj b2xvcjojMUY0OTdEJz5zZWFuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48ZGl2 PjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtw YWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluJz48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdp bi1sZWZ0Oi41aW4nPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+IE9tYXIgU2Fu dG9zIChvc2FudG9zKSA8YSBocmVmPSJtYWlsdG86W21haWx0bzpvc2FudG9zQGNpc2NvLmNvbV0i PlttYWlsdG86b3NhbnRvc0BjaXNjby5jb21dPC9hPiA8YnI+PGI+U2VudDo8L2I+IE1vbmRheSwg QXByaWwgMTYsIDIwMTIgODoxNyBQTTxicj48Yj5Ubzo8L2I+IEx1aXMgTnVuZXo7IEJhcm51bSwg U2VhbiBELjxicj48Yj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0bzppZHh3Z0BuaWN3Zy5vcmciPmlk eHdnQG5pY3dnLm9yZzwvYT47IDxhIGhyZWY9Im1haWx0bzptaWxlQGlldGYub3JnIj5taWxlQGll dGYub3JnPC9hPjsgPGEgaHJlZj0ibWFpbHRvOmRhbGxlbmRvdWdAZ21haWwuY29tIj5kYWxsZW5k b3VnQGdtYWlsLmNvbTwvYT47IDxhIGhyZWY9Im1haWx0bzpzYWNtQGlldGYub3JnIj5zYWNtQGll dGYub3JnPC9hPjsgPGEgaHJlZj0ibWFpbHRvOm0tdGVyYWRhQGlwYS5nby5qcCI+bS10ZXJhZGFA aXBhLmdvLmpwPC9hPjxicj48Yj5TdWJqZWN0OjwvYj4gUkU6IFtzYWNtXSBbbWlsZV0gQ3liT1gg djEuMCAoRHJhZnQpIGlzIG5vdyByZWxlYXNlZCBhbmQgbGl2ZSBvbnRoZSB3ZWJzaXRlPG86cD48 L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFy Z2luLWxlZnQ6LjVpbic+PG86cD4mbmJzcDs8L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0 eWxlPSdtYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkkgZWNobyBMdWlz 4oCZIGNvbW1lbnRzLiBJdCBpcyBnb29kIHRvIHNlZSB0aGUgaW5jbHVzaW9uIG9mIG5ldHdvcmsg b2JqZWN0cy4gUXVpY2sgcXVlc3Rpb24gdG8gdGhlIHRlYW0gcmVsYXRlZCB0byB5b3VyIG5ldGZs b3cgY29tbWVudC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxl PSdtYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4n PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+SSBhbSBsb29raW5nIGF0OjxvOnA+PC9vOnA+PC9zcGFu PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 Y29sb3I6IzFGNDk3RCc+PGEgaHJlZj0iaHR0cDovL2N5Ym94Lm1pdHJlLm9yZy9YTUxTY2hlbWEv Y3lib3hfY29yZV92MS4wJTI4ZHJhZnQlMjkueHNkIj5odHRwOi8vY3lib3gubWl0cmUub3JnL1hN TFNjaGVtYS9jeWJveF9jb3JlX3YxLjAlMjhkcmFmdCUyOS54c2Q8L2E+PG86cD48L286cD48L3Nw YW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVpbic+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm Ijtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPuKA piBhbmQgaXQgbG9va3MgdGhhdCB3ZSByZW5hbWVkIGl0IHRvIOKAnERhdGEgRmxvd+KAnT88bzpw PjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDou NWluJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZsdDt4czplbnVtZXJh dGlvbiB2YWx1ZT0mcXVvdDtEYXRhIEZsb3cmcXVvdDsmZ3Q7PG86cD48L286cD48L3NwYW4+PC9w PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVpbic+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jm5ic3A7Jm5ic3A7 ICZsdDt4czphbm5vdGF0aW9uJmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29O b3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAmbHQ7eHM6ZG9jdW1lbnRhdGlvbiZndDtTcGVjaWZpZXMgdGhlIGNs YXNzIG9mIGV2ZW50cyBkZWFsaW5nIHdpdGggZGF0YSBmbG93LiZsdDsveHM6ZG9jdW1lbnRhdGlv biZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJn aW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToi Q291cmllciBOZXciJz4mbmJzcDsmbmJzcDsgJmx0Oy94czphbm5vdGF0aW9uJmd0OzxvOnA+PC9v OnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4n PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyIn PiZsdDsveHM6ZW51bWVyYXRpb24mZ3Q7PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z b05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVpbic+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVpbic+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6 LjVpbic+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5XaGF0IGlzIHRoZSBkaWZmZXJlbmNlIGJldHdl ZW4gdGhhdCBhbmQg4oCcUGFja2V0IFRyYWZmaWPigJ0/PG86cD48L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVpbic+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjoj MUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHByZSBzdHlsZT0nbWFyZ2luLWxl ZnQ6LjVpbic+Jmx0O3hzOmVudW1lcmF0aW9uIHZhbHVlPSZxdW90O1BhY2tldCBUcmFmZmljJnF1 b3Q7Jmd0OzxvOnA+PC9vOnA+PC9wcmU+PHByZSBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVpbic+Jm5i c3A7Jm5ic3A7ICZsdDt4czphbm5vdGF0aW9uJmd0OzxvOnA+PC9vOnA+PC9wcmU+PHByZSBzdHls ZT0nbWFyZ2luLWxlZnQ6LjVpbic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDt4czpkb2N1 bWVudGF0aW9uJmd0O1NwZWNpZmllcyB0aGUgY2xhc3Mgb2YgZXZlbnRzIGRlYWxpbmcgd2l0aCBw YWNrZXQgdHJhZmZpYy4mbHQ7L3hzOmRvY3VtZW50YXRpb24mZ3Q7PG86cD48L286cD48L3ByZT48 cHJlIHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz4mbmJzcDsmbmJzcDsgJmx0Oy94czphbm5vdGF0 aW9uJmd0OzxvOnA+PC9vOnA+PC9wcmU+PHByZSBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVpbic+Jmx0 Oy94czplbnVtZXJhdGlvbiZndDs8bzpwPjwvbzpwPjwvcHJlPjxwIGNsYXNzPU1zb05vcm1hbCBz dHlsZT0nbWFyZ2luLWxlZnQ6LjVpbic+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDou NWluJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6 IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBz dHlsZT0nbWFyZ2luLWxlZnQ6LjVpbic+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1s ZWZ0Oi41aW4nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyI7Y29sb3I6IzFGNDk3RCc+UmVnYXJkcyw8YnI+PGJyPk9tYXIgU2FudG9zPGJyPklu Y2lkZW50IE1hbmFnZXIsIFBTSVJUPGJyPlNlY3VyaXR5IFJlc2VhcmNoIGFuZCBPcGVyYXRpb25z PGJyPkNpc2NvIFN5c3RlbXMsIEluYy48YnI+RW1haWw6IDxhIGhyZWY9Im1haWx0bzpvc0BjaXNj by5jb20iPm9zQGNpc2NvLmNvbTwvYT48YnI+UGhvbmU6ICsxIDkxOSAzOTIgODYzNTxicj5QR1Ag S2V5OiAweDNBRjI3RURDPGJyPjxicj5DaXNjby5jb20gLSA8YSBocmVmPSJodHRwOi8vd3d3LmNp c2NvLmNvbSI+aHR0cDovL3d3dy5jaXNjby5jb208L2E+PGJyPkNpc2NvIFNlY3VyaXR5IEFkdmlz b3JpZXMgYW5kIE5vdGljZXMgLSA8YSBocmVmPSJodHRwOi8vd3d3LmNpc2NvLmNvbS9nby9wc2ly dCI+aHR0cDovL3d3dy5jaXNjby5jb20vZ28vcHNpcnQ8L2E+PGJyPjxicj5UaGlzIGVtYWlsIG1h eSBjb250YWluIGNvbmZpZGVudGlhbCBhbmQgcHJpdmlsZWdlZCBtYXRlcmlhbCBmb3IgdGhlIHNv bGU8YnI+dXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQuIEFueSByZXZpZXcsIHVzZSwgZGlz dHJpYnV0aW9uIG9yPGJyPmRpc2Nsb3N1cmUgYnkgb3RoZXJzIGlzIHN0cmljdGx5IHByb2hpYml0 ZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZDxicj5yZWNpcGllbnQgKG9yIGF1dGhvcml6 ZWQgdG8gcmVjZWl2ZSBmb3IgdGhlIHJlY2lwaWVudCksIHBsZWFzZSBjb250YWN0PGJyPnRoZSBz ZW5kZXIgYnkgcmVwbHkgZW1haWwgYW5kIGRlbGV0ZSBhbGwgY29waWVzIG9mIHRoaXMgbWVzc2Fn ZS48YnI+PGJyPkZvciBjb3Jwb3JhdGUgbGVnYWwgaW5mb3JtYXRpb24gZ28gdG86PGJyPjxhIGhy ZWY9Imh0dHA6Ly93d3cuY2lzY28uY29tL3dlYi9hYm91dC9kb2luZ19idXNpbmVzcy9sZWdhbC9j cmkvaW5kZXguaHRtbCI+aHR0cDovL3d3dy5jaXNjby5jb20vd2ViL2Fib3V0L2RvaW5nX2J1c2lu ZXNzL2xlZ2FsL2NyaS9pbmRleC5odG1sPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48 cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6 IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxkaXY+PGRpdiBzdHlsZT0nYm9y ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGlu IDBpbiAwaW4nPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVpbic+PGI+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiJz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz4gPGEgaHJlZj0ibWFpbHRvOnNhY20tYm91 bmNlc0BpZXRmLm9yZyI+c2FjbS1ib3VuY2VzQGlldGYub3JnPC9hPiA8YSBocmVmPSJtYWlsdG86 W21haWx0bzpzYWNtLWJvdW5jZXNAaWV0Zi5vcmddIj5bbWFpbHRvOnNhY20tYm91bmNlc0BpZXRm Lm9yZ108L2E+IDxiPk9uIEJlaGFsZiBPZiA8L2I+THVpcyBOdW5lejxicj48Yj5TZW50OjwvYj4g TW9uZGF5LCBBcHJpbCAxNiwgMjAxMiA2OjQ0IFBNPGJyPjxiPlRvOjwvYj4gQmFybnVtLCBTZWFu IEQuPGJyPjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRvOmlkeHdnQG5pY3dnLm9yZyI+aWR4d2dA bmljd2cub3JnPC9hPjsgPGEgaHJlZj0ibWFpbHRvOm1pbGVAaWV0Zi5vcmciPm1pbGVAaWV0Zi5v cmc8L2E+OyBEb3VnIFdpbHNvbiAoPGEgaHJlZj0ibWFpbHRvOmRhbGxlbmRvdWdAZ21haWwuY29t Ij5kYWxsZW5kb3VnQGdtYWlsLmNvbTwvYT4pOyA8YSBocmVmPSJtYWlsdG86c2FjbUBpZXRmLm9y ZyI+c2FjbUBpZXRmLm9yZzwvYT47IElQQS1NYXNhdG8gVGVyYWRhICg8YSBocmVmPSJtYWlsdG86 bS10ZXJhZGFAaXBhLmdvLmpwIj5tLXRlcmFkYUBpcGEuZ28uanA8L2E+KTxicj48Yj5TdWJqZWN0 OjwvYj4gUmU6IFtzYWNtXSBbbWlsZV0gQ3liT1ggdjEuMCAoRHJhZnQpIGlzIG5vdyByZWxlYXNl ZCBhbmQgbGl2ZSBvbnRoZSB3ZWJzaXRlPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2 PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVpbic+PG86cD4mbmJzcDs8 L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz5JIGxp a2UgdGhlIGluY2x1c2lvbiBvZiB0aGUgbmV0d29yay1jZW50cmljIG9iamVjdHMuICZuYnNwO0lQ RklYIChuZXRmbG93KSAmbmJzcDt3aWxsIGFkZCBhbiBhZGRpdGlvbmFsIHBlcnNwZWN0aXZlIGZy b20gYW4gaW5jaWRlbnQgaW5mb3JtYXRpb24gc2hhcmluZyBzdGFuZHBvaW50LiAmbmJzcDs8bzpw PjwvbzpwPjwvcD48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVp bic+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5 bGU9J21hcmdpbi1sZWZ0Oi41aW4nPi1sbjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz48bzpwPiZuYnNwOzwvbzpwPjwv cD48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz5P biBBcHIgMTYsIDIwMTIsIGF0IDQ6MDQgUE0sIEJhcm51bSwgU2VhbiBELiB3cm90ZTo8bzpwPjwv bzpwPjwvcD48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFs dDowaW47bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjEyLjBwdDttYXJnaW4tbGVmdDou NWluJz48bzpwPiZuYnNwOzwvbzpwPjwvcD48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0 eWxlPSdtYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz5IZXkgZXZlcnlvbmUsPG86cD48L286cD48 L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVm dDouNWluJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiJz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiInPkkganVz dCB3YW50ZWQgdG8gbGV0IHlvdSBhbGwga25vdyB0aGF0IEN5Yk9YIHYxLjAgKERyYWZ0KSBjb250 ZW50IGlzIG5vdyBsaXZlIG9uIHRoZSB3ZWJzaXRlLjxzcGFuIGNsYXNzPWFwcGxlLWNvbnZlcnRl ZC1zcGFjZT4mbmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0cDovL2N5Ym94Lm1pdHJlLm9yZyI+aHR0 cDovL2N5Ym94Lm1pdHJlLm9yZzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiInPlRoZSBy ZWxlYXNlIG5vdGVzIGFyZSBwcm92aWRlZCBpbmxpbmUgYmVsb3cuPG86cD48L286cD48L3NwYW4+ PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDouNWlu Jz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiJz5UaGUga2V5IGl0ZW1zIG9mIG5vdGUgYXJlOjxvOnA+PC9vOnA+PC9zcGFuPjwv cD48L2Rpdj48ZGl2IHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz48cCBjbGFzcz1Nc29Ob3JtYWwg c3R5bGU9J21hcmdpbi1sZWZ0Oi41aW47dGV4dC1pbmRlbnQ6LS4yNWluO2xpbmUtaGVpZ2h0OjEy Ljc1cHQnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbCc+ wrc8L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo3LjBwdCc+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9YXBwbGUtY29udmVydGVkLXNwYWNl PiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+VGhlIHJlbGVhc2Ugb2YgdHdvIGZvcm1hbCBz cGVjaWZpY2F0aW9ucyBmb3IgdGhlIEN5Yk9YIGxhbmd1YWdlIChvbmUgZm9yIHRoZSBjb3JlIGxh bmd1YWdlIGFuZCBvbmUgZm9yIHRoZSBkZWZpbmVkIG9iamVjdHMpPG86cD48L286cD48L3NwYW4+ PC9wPjwvZGl2PjxkaXYgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4nPjxwIGNsYXNzPU1zb05vcm1h bCBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVpbjt0ZXh0LWluZGVudDotLjI1aW47bGluZS1oZWlnaHQ6 MTIuNzVwdCc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9s Jz7Ctzwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjcuMHB0Jz4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz1hcHBsZS1jb252ZXJ0ZWQtc3Bh Y2U+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz5UaGUgWE1MIFNjaGVtYSBoYXMgZ29uZSB0 aHJvdWdoIGV4dGVuc2l2ZSBpbXByb3ZlbWVudHMgZm9yIGV4cHJlc3NpdmVuZXNzLCBjbGFyaXR5 LCBjb25zaXN0ZW5jeSwgZWZmaWNpZW5jeSwgYWxpZ25tZW50IHRvIGV4aXN0aW5nIG5vcm1hdGl2 ZSByZWZlcmVuY2VzIGFuZCBkb2N1bWVudGF0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rp dj48ZGl2IHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9 J21hcmdpbi1sZWZ0Oi41aW47dGV4dC1pbmRlbnQ6LS4yNWluO2xpbmUtaGVpZ2h0OjEyLjc1cHQn PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbCc+wrc8L3Nw YW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo3LjBwdCc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9YXBwbGUtY29udmVydGVkLXNwYWNlPiZuYnNw Ozwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+VGhpcyByZWxlYXNlIGluY2x1ZGVzIGFuIGluaXRpYWwg c2V0IG9mIGxhbmd1YWdlIHV0aWxpdGllczogYSBkcmFmdCBTbm9ydCAtJmd0OyBDeWJPWCB0cmFu c2Zvcm0sIGEgZHJhZnQgT3BlbklPQyAtJmd0OyBDeWJPWCB0cmFuc2Zvcm0sIGFuZCBhIHNldCBv ZiBQeXRob24gYmluZGluZ3MgZm9yIHRoZSBDeWJPWCBsYW5ndWFnZS48bzpwPjwvbzpwPjwvc3Bh bj48L3A+PC9kaXY+PHAgY2xhc3M9TXNvTGlzdFBhcmFncmFwaCBzdHlsZT0nbXNvLW1hcmdpbi10 b3AtYWx0OjBpbjttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206MTAuMHB0O21hcmdpbi1s ZWZ0OjEuMGluO3RleHQtaW5kZW50Oi0uMjVpbjtsaW5lLWhlaWdodDoxMi43NXB0Jz48c3BhbiBz dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpTeW1ib2wnPsK3PC9zcGFuPjxzcGFu IHN0eWxlPSdmb250LXNpemU6Ny4wcHQnPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOzxzcGFuIGNsYXNzPWFwcGxlLWNvbnZlcnRlZC1zcGFjZT4mbmJzcDs8L3NwYW4+ PC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiInPlRoZSB3ZWJzaXRlIG5vdyBpbmNsdWRlcyBhIHNtYWxsIHNldCBvZiBj b250ZW50IGV4YW1wbGVzLiBUaGlzIHNldCB3aWxsIGdyb3cgZ29pbmcgZm9yd2FyZC48bzpwPjwv bzpwPjwvc3Bhbj48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0 Oi41aW4nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiInPlRoaXMgcmVsZWFzZSBpbnZvbHZlZCBhIGxvdCBvZiBoYXJkIHdvcmsg ZnJvbSBhIGRpdmVyc2UgZ3JvdXAgb2YgcGVvcGxlLiBUaGFuayB5b3UgYWxsIGZvciB5b3VyIGNv bnRyaWJ1dGlvbnMgYW5kIGVmZm9ydC4gV2UgY291bGQgbm90IGhhdmUgZG9uZSBpdCB3aXRob3V0 IHlvdS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwg c3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiInPldlIGxvb2sgZm9yd2FyZCB0byBldmVy eW9uZeKAmXMgZmVlZGJhY2sgYW5kIGNvbGxhYm9yYXRpb24gYXMgd2UgY29udGludWUgdG8gaW1w cm92ZSBhbmQgbWF0dXJlIHRoZSBDeWJPWCBsYW5ndWFnZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4nPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiInPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVpbic+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+U2VhbiBCYXJudW08bzpw PjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21h cmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiInPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rp dj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVpbic+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm Iic+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsIHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz4mbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+PC9kaXY+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWJvdHRvbTpzb2xp ZCAjNEY4MUJEIDEuMHB0O3BhZGRpbmc6MGluIDBpbiA0LjBwdCAwaW47Ym9yZGVyLXdpZHRoOmlu aXRpYWw7Ym9yZGVyLWNvbG9yOmluaXRpYWwnPjxwIGNsYXNzPU1zb1RpdGxlIHN0eWxlPSdtc28t bWFyZ2luLXRvcC1hbHQ6MGluO21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbToxNS4wcHQ7 bWFyZ2luLWxlZnQ6LjVpbic+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToyNi4wcHQ7Zm9udC1mYW1p bHk6IkNhbWJyaWEiLCJzZXJpZiI7Y29sb3I6IzE3MzY1RDtsZXR0ZXItc3BhY2luZzouMjVwdCc+ Q3liT1ggdjEuMCAoRHJhZnQpIFJlbGVhc2UgTm90ZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9k aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4nPlRoZSBW ZXJzaW9uIDEuMCAoRHJhZnQpIHJlbGVhc2Ugb2YgQ3liZXIgT2JzZXJ2YWJsZSBlWHByZXNzaW9u IChDeWJPWOKEoik8c3BhbiBjbGFzcz1hcHBsZS1jb252ZXJ0ZWQtc3BhY2U+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+Jm5i c3A7PC9zcGFuPjwvc3Bhbj5pcyBpbnRlbmRlZCBhcyBhIGRyYWZ0IHJlbGVhc2Ugb2YgYW4gaW5p dGlhbCBtYWpvciB2ZXJzaW9uIG9mIHRoZSBDeWJPWCBMYW5ndWFnZSB0aGF0IGNvdWxkIGJlIHV0 aWxpemVkIGZvciBwcmFjdGljYWwgb3BlcmF0aW9uYWwgdXNlIGFuZCBpbnRlZ3JhdGlvbiBpbnRv IG90aGVyIHN0YW5kYXJkcyBlZmZvcnRzLiBUaGlzIHJlbGVhc2UgY29uc2lzdHMgb2YgdGhyZWUg cHJpbWFyeSBjb21wb25lbnRzOiBhIHBhaXIgb2YgZm9ybWFsIGxhbmd1YWdlIHNwZWNpZmljYXRp b25zIGZvciB0aGUgY29yZSBsYW5ndWFnZSBjb250ZW50IGFuZCBkZWZpbmVkIG9iamVjdHMgY29u dGVudCwgYSBzZXQgb2YgbGFuZ3VhZ2UgaW1wbGVtZW50YXRpb24gWE1MIHNjaGVtYXMgKGNvcmUs IGNvbW1vbl90eXBlcywgYW5kIH43MCBkZWZpbmVkIG9iamVjdCBzY2hlbWFzKSwgYW5kIGEgc21h bGwgaW5pdGlhbCBzZXQgb2YgbGFuZ3VhZ2UgdXRpbGl0aWVzIGluY2x1ZGluZyBhbiBpbml0aWFs IGRyYWZ0IFNub3J0LSZndDtDeWJPWCB0cmFuc2Zvcm0sIGFuIGluaXRpYWwgZHJhZnQgT3BlbklP Qy0mZ3Q7Q3liT1ggdHJhbnNmb3JtIGFuZCBhIHNldCBvZiBDeWJPWCBsYW5ndWFnZSBQeXRob24g YmluZGluZ3MuIFJlY29nbml6aW5nIHRoYXQgdGhpcyBpcyB0aGUgZmlyc3QgdGltZSB0aGF0IHRo ZSBmb3JtYWwgbGFuZ3VhZ2Ugc3BlY2lmaWNhdGlvbnMgd2lsbCBiZSBhdmFpbGFibGUgZm9yIHJl dmlldyBhbmQgYXMgc3VjaCB3aWxsIGxpa2VseSBnZW5lcmF0ZSBmZWVkYmFjayBmcm9tIG5ldyBz dGFrZWhvbGRlcnMsIHRoaXMgaW5pdGlhbCBtYWpvciB2ZXJzaW9uIGlzIGJlaW5nIHJlbGVhc2Vk IGFzIGEg4oCcZHJhZnTigJ0gdjEuMCB3aXRoIHRoZSBleHBlY3RhdGlvbiBvZiBjeWNsZXMgb2Yg bmV3IGZlZWRiYWNrIGFuZCByZXZpc2lvbiBiZWZvcmUgYSDigJxmaW5hbOKAnSB2MS4wIGlzIHJl bGVhc2VkLjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiInPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVpbic+VGhlIEN5Yk9YIHYxLjAgKERyYWZ0 KSBYTUwgc2NoZW1hcyBpbmNsdWRlIGEgc2lnbmlmaWNhbnQgbnVtYmVyIG9mIGNoYW5nZXMgZnJv bSB2MC43IHRvIGltcHJvdmU6PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2Pjxk aXYgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4nPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFy Z2luLWxlZnQ6LjVpbjt0ZXh0LWluZGVudDotLjI1aW4nPjxzcGFuIHN0eWxlPSdmb250LWZhbWls eTpTeW1ib2wnPsK3PC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6Ny4wcHQnPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPWFwcGxlLWNvbnZlcnRlZC1z cGFjZT4mbmJzcDs8L3NwYW4+PC9zcGFuPkNsYXJpdHksIGRvY3VtZW50YXRpb24sIGFuZCBkZXNj cmlwdGl2ZSBmb3JtYWxpdHkgZm9yIHJlZmVyZW5jZSBhbmQgaW1wbGVtZW50YXRpb24gYnkgb3Ro ZXIgc3RhbmRhcmRzIGFuZCB1c2Vycy48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9k aXY+PGRpdiBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVpbic+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxl PSdtYXJnaW4tbGVmdDouNWluO3RleHQtaW5kZW50Oi0uMjVpbic+PHNwYW4gc3R5bGU9J2ZvbnQt ZmFtaWx5OlN5bWJvbCc+wrc8L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo3LjBwdCc+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9YXBwbGUtY29udmVy dGVkLXNwYWNlPiZuYnNwOzwvc3Bhbj48L3NwYW4+Q29uc2lzdGVuY3ksIHNpbXBsaWNpdHksIGFu ZCBlZmZpY2llbmN5LjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiInPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2IHN0 eWxlPSdtYXJnaW4tbGVmdDouNWluJz48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1s ZWZ0Oi41aW47dGV4dC1pbmRlbnQ6LS4yNWluJz48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6U3lt Ym9sJz7Ctzwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjcuMHB0Jz4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz1hcHBsZS1jb252ZXJ0ZWQtc3BhY2U+ Jm5ic3A7PC9zcGFuPjwvc3Bhbj5BbGlnbm1lbnQgKGFzIGFwcHJvcHJpYXRlKSB0byBleGlzdGlu ZyBub3JtYXRpdmUgcmVmZXJlbmNlcy48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9k aXY+PHAgY2xhc3M9TXNvTGlzdFBhcmFncmFwaCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OjBp bjttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206MTAuMHB0O21hcmdpbi1sZWZ0OjEuMGlu O3RleHQtaW5kZW50Oi0uMjVpbic+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OlN5bWJvbCc+wrc8 L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo3LjBwdCc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9YXBwbGUtY29udmVydGVkLXNwYWNlPiZuYnNwOzwv c3Bhbj48L3NwYW4+RXhwcmVzc2l2ZW5lc3Mgb2YgdGhlIHNjaGVtYSB0byBiZXR0ZXIgc3VwcG9y dCB0aGUgYnJvYWQgc2V0IG9mIHVzZSBjYXNlcyBpdCB0YXJnZXRzIChtYWx3YXJlIGNoYXJhY3Rl cml6YXRpb24sIGluZGljYXRvciBhbmQgaW5jaWRlbnQgZGF0YSBzaGFyaW5nLCBldmVudCBtYW5h Z2VtZW50LCBldGMuKSBpbmNsdWRpbmcgdGhlIGFkZGl0aW9uIG9mIGFuIGluaXRpYWwgc2V0IG9m IG5ldHdvcmstcmVsYXRlZCBkZWZpbmVkIG9iamVjdHMuPHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+PG86cD48L286cD48L3Nw YW4+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz5T dW1tYXJ5IG9mIGNoYW5nZXMgZnJvbSBDeWJPWF92MC43IHRvIEN5Yk9YX3YxLjBfKERyYWZ0KTo8 c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0 eWxlPSdtYXJnaW4tbGVmdDoxLjBpbjt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDEgbGV2 ZWwxIGxmbzInPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OlN5bWJvbCc+PHNwYW4gc3R5bGU9J21zby1saXN0Oklnbm9yZSc+wrc8 c3BhbiBzdHlsZT0nZm9udDo3LjBwdCAiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48L3NwYW4+PC9zcGFuPjwh W2VuZGlmXT5SZWZpbmVtZW50IG9mIG5hbWVzcGFjZXMgYW5kIHNjaGVtYSBsb2NhdGlvbnMgZm9y IGJldHRlciBlZmZlY3RpdmVuZXNzIGFuZCBmbGV4aWJpbGl0eSBnb2luZyBmb3J3YXJkLjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiInPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdp bi1sZWZ0OjEuMGluO3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMSBsZXZlbDEgbGZvMic+ PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6U3ltYm9sJz48c3BhbiBzdHlsZT0nbXNvLWxpc3Q6SWdub3JlJz7CtzxzcGFuIHN0eWxl PSdmb250OjcuMHB0ICJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPk5v cm1hbGl6ZWQgYWxsIGNvbnRlbnQgYWNjb3JkaW5nIHRvIGFuIGVzdGFibGlzaGVkIHNldCBvZiBu YW1pbmcgY29udmVudGlvbnMuPHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNz PU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6MS4waW47dGV4dC1pbmRlbnQ6LS4yNWluO21z by1saXN0OmwxIGxldmVsMSBsZm8yJz48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTeW1ib2wnPjxzcGFuIHN0eWxlPSdtc28tbGlz dDpJZ25vcmUnPsK3PHNwYW4gc3R5bGU9J2ZvbnQ6Ny4wcHQgIlRpbWVzIE5ldyBSb21hbiInPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+PC9z cGFuPjwvc3Bhbj48IVtlbmRpZl0+RnVsbHkgYW5ub3RhdGVkIGFsbCBsYW5ndWFnZSBpdGVtcyAo dHlwZXMsIGF0dHJpYnV0ZXMsIGVsZW1lbnRzLCBldGMuKS48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz48bzpwPjwvbzpwPjwv c3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDoxLjBpbjt0ZXh0 LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzInPjwhW2lmICFzdXBwb3J0TGlz dHNdPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbCc+PHNw YW4gc3R5bGU9J21zby1saXN0Oklnbm9yZSc+wrc8c3BhbiBzdHlsZT0nZm9udDo3LjBwdCAiVGlt ZXMgTmV3IFJvbWFuIic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IDwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT5Nb3ZlZCBzZXZlcmFsIGNvbW1v bmx5IGxldmVyYWdlZCB0eXBlcyBvdXQgb2YgdGhlIGNvcmUgc2NoZW1hIGFuZCBpbnRvIGNvbW1v bl90eXBlcy48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFs IHN0eWxlPSdtYXJnaW4tbGVmdDoxLjBpbjt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDEg bGV2ZWwxIGxmbzInPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbCc+PHNwYW4gc3R5bGU9J21zby1saXN0Oklnbm9yZSc+ wrc8c3BhbiBzdHlsZT0nZm9udDo3LjBwdCAiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48L3NwYW4+PC9zcGFu PjwhW2VuZGlmXT5BY2hpZXZlZCBmdWxsIHR5cGluZyBvZiBlbnRpcmUgc2NoZW1hIHN0cnVjdHVy ZSBzdWNoIHRoYXQgYWxsIGF0dHJpYnV0ZXMgYW5kIGVsZW1lbnRzIGFyZSBkZWZpbml0aXZlbHkg dHlwZWQuPHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIic+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBz dHlsZT0nbWFyZ2luLWxlZnQ6MS4waW47dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwxIGxl dmVsMSBsZm8yJz48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTpTeW1ib2wnPjxzcGFuIHN0eWxlPSdtc28tbGlzdDpJZ25vcmUnPsK3 PHNwYW4gc3R5bGU9J2ZvbnQ6Ny4wcHQgIlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+PC9zcGFuPjwvc3Bhbj48 IVtlbmRpZl0+Q2hhbmdlZCBhbGwgaWRlbnRpZmllcnMgZnJvbSBJRCBhbmQgSURSRUYgdHlwZXMg dG8gYmUgUU5hbWVzIGVuYWJsaW5nIGdsb2JhbGx5IHVuaXF1ZSBpZGVudGlmaWVycyBhbmQgZmxl eGliaWxpdHkgZm9yIGRvbWFpbi1zcGVjaWZpYyB1c2VycyBvZiBDeWJPWCB0byBkZWZpbmUgdGhl aXIgb3duIGlkZW50aWZpZXIgc3ludGF4IGxvY2FsbHkuPHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+PG86cD48L286cD48L3Nw YW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6MS4waW47dGV4dC1p bmRlbnQ6LS4yNWluO21zby1saXN0OmwxIGxldmVsMSBsZm8yJz48IVtpZiAhc3VwcG9ydExpc3Rz XT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTeW1ib2wnPjxzcGFu IHN0eWxlPSdtc28tbGlzdDpJZ25vcmUnPsK3PHNwYW4gc3R5bGU9J2ZvbnQ6Ny4wcHQgIlRpbWVz IE5ldyBSb21hbiInPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyA8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+UmVvcmRlcmVkIGF0dHJpYnV0ZXMg YW5kIGVsZW1lbnRzIGluIG51bWVyb3VzIHR5cGVzIHRvIGJldHRlciByZWZsZWN0IGNvbW1vbiB1 c2FnZSBhbmQgcHJpb3JpdHkuPHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNz PU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6MS4waW47dGV4dC1pbmRlbnQ6LS4yNWluO21z by1saXN0OmwxIGxldmVsMSBsZm8yJz48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTeW1ib2wnPjxzcGFuIHN0eWxlPSdtc28tbGlz dDpJZ25vcmUnPsK3PHNwYW4gc3R5bGU9J2ZvbnQ6Ny4wcHQgIlRpbWVzIE5ldyBSb21hbiInPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+PC9z cGFuPjwvc3Bhbj48IVtlbmRpZl0+QWRkZWQgbWFqb3JfdmVyc2lvbiBhbmQgbWlub3JfdmVyc2lv biBhdHRyaWJ1dGVzIGZvciBjb3JlIHNjaGVtYS48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDoxLjBpbjt0ZXh0LWluZGVu dDotLjI1aW47bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzInPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbCc+PHNwYW4gc3R5 bGU9J21zby1saXN0Oklnbm9yZSc+wrc8c3BhbiBzdHlsZT0nZm9udDo3LjBwdCAiVGltZXMgTmV3 IFJvbWFuIic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IDwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT5BZGRlZCBjYXBhYmlsaXR5IHRvIGNoYXJh Y3Rlcml6ZSBzb3VyY2Ugb2Ygb3ZlcmFsbCBvYnNlcnZhYmxlIHBhY2thZ2UgZGF0YSBhbmQgZm9y IGluZGl2aWR1YWwgb2JzZXJ2YWJsZXMuPHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+PG86cD48L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6MS4waW47dGV4dC1pbmRlbnQ6LS4y NWluO21zby1saXN0OmwxIGxldmVsMSBsZm8yJz48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBz dHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTeW1ib2wnPjxzcGFuIHN0eWxlPSdt c28tbGlzdDpJZ25vcmUnPsK3PHNwYW4gc3R5bGU9J2ZvbnQ6Ny4wcHQgIlRpbWVzIE5ldyBSb21h biInPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3Nw YW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+TW9kaWZpZWQgdGhlIGxvZ2ljYWwgY29tcG9zaXRp b24gc3RydWN0dXJlIHN1Y2ggdGhhdCBhbnkgc3VjaCBjb21wb3NpdGlvbnMgYXJlIG5vdyBjb250 YWluZWQgd2l0aGluIGEgT2JzZXJ2YWJsZV9Db21wb3NpdGlvbiBlbGVtZW50IHByb3ZpZGluZyBp bXByb3ZlZCBzaW1wbGljaXR5IGFuZCBtb2R1bGFyaXR5LjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiInPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0OjEuMGluO3RleHQt aW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMSBsZXZlbDEgbGZvMic+PCFbaWYgIXN1cHBvcnRMaXN0 c10+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sJz48c3Bh biBzdHlsZT0nbXNvLWxpc3Q6SWdub3JlJz7CtzxzcGFuIHN0eWxlPSdmb250OjcuMHB0ICJUaW1l cyBOZXcgUm9tYW4iJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPlJlbW92ZWQgdGhlIERlbHRhIGVs ZW1lbnQgZnJvbSBPYnNlcnZhYmxlVHlwZSBhbmQgcmVsb2NhdGVkIHRoZSBhcHByb3ByaWF0ZSBw b3J0aW9ucyAoQ2hhbmdlLCBUcmVuZCwgYW5kIEZyZXF1ZW5jeSkgdG8gYXBwcm9wcmlhdGUgbG9j YXRpb25zIHVuZGVyIFN0YXRlZnVsX01lYXN1cmUgYW5kIEV2ZW50LjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiInPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0OjEuMGlu O3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMSBsZXZlbDEgbGZvMic+PCFbaWYgIXN1cHBv cnRMaXN0c10+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9s Jz48c3BhbiBzdHlsZT0nbXNvLWxpc3Q6SWdub3JlJz7CtzxzcGFuIHN0eWxlPSdmb250OjcuMHB0 ICJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPkFkZGVkIGEgRG9tYWlu X1NwZWNpZmljX09iamVjdF9BdHRyaWJ1dGVzIGZpZWxkIHRvIE9iamVjdCB1dGlsaXppbmcgYW4g YWJzdHJhY3QgdHlwZSB0aGF0IHdpbGwgYWxsb3cgZG9tYWluLXNwZWNpZmljIHVzZSBjYXNlcyB0 byBhZGQgaW4gdGhlaXIgb3duIGRvbWFpbi1zcGVjaWZpYyBhdHRyaWJ1dGVzIGZvciBPYmplY3Rz LjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiInPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9 J21hcmdpbi1sZWZ0OjEuMGluO3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMSBsZXZlbDEg bGZvMic+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6U3ltYm9sJz48c3BhbiBzdHlsZT0nbXNvLWxpc3Q6SWdub3JlJz7CtzxzcGFu IHN0eWxlPSdmb250OjcuMHB0ICJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5k aWZdPkFkZGVkIGEgVG9vbC1TcGVjaWZpY19EYXRhIGZpZWxkIHRvIFRvb2xJbmZvcm1hdGlvblR5 cGUgdXRpbGl6aW5nIGFuIGFic3RyYWN0IHR5cGUgdGhhdCB3aWxsIGFsbG93IGFkZGl0aW9uIG9m IHRvb2wtc3BlY2lmaWMgZGF0YS48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh c3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDoxLjBpbjt0ZXh0LWluZGVudDotLjI1aW47 bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzInPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbCc+PHNwYW4gc3R5bGU9J21zby1s aXN0Oklnbm9yZSc+wrc8c3BhbiBzdHlsZT0nZm9udDo3LjBwdCAiVGltZXMgTmV3IFJvbWFuIic+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48 L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT5BZGRlZCBhbiBJbmRpY2F0b3JzIGZpZWxkIHRvIE1lYXN1 cmVTb3VyY2VUeXBlIHV0aWxpemluZyBhbiBhYnN0cmFjdCB0eXBlIHRoYXQgd2lsbCBhbGxvdyBj aGFyYWN0ZXJpemluZyBkaWZmZXJpbmcgZm9ybWF0cyBvciBzdGFuZGFyZHMgb2YgaW5kaWNhdG9y cyB0aGF0IG1heSBoYXZlIGxlZCB0byB0aGUgaWRlbnRpZmljYXRpb24gb2YgdGhlIG9ic2VydmFi bGUgZGF0YS48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFs IHN0eWxlPSdtYXJnaW4tbGVmdDoxLjBpbjt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDEg bGV2ZWwxIGxmbzInPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbCc+PHNwYW4gc3R5bGU9J21zby1saXN0Oklnbm9yZSc+ wrc8c3BhbiBzdHlsZT0nZm9udDo3LjBwdCAiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48L3NwYW4+PC9zcGFu PjwhW2VuZGlmXT5FbmhhbmNlZCB0aGUgSGFzaCBzdHJ1Y3R1cmUgdG8gY2FwdHVyZSBmdWxsIGZ1 enp5IGhhc2hlcyBpbiBhZGRpdGlvbiB0byBzaW1wbGUgaGFzaGVzPHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+PG86cD48L286 cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6MS4waW47 dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwxIGxldmVsMSBsZm8yJz48IVtpZiAhc3VwcG9y dExpc3RzXT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTeW1ib2wn PjxzcGFuIHN0eWxlPSdtc28tbGlzdDpJZ25vcmUnPsK3PHNwYW4gc3R5bGU9J2ZvbnQ6Ny4wcHQg IlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyA8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+QWRkZWQgYSBuZXcgRXh0 cmFjdGVkRmVhdHVyZXNUeXBlIHRoYXQgY2FuIGJlIHVzZWQgdG8gYWRvcm4gZGlmZmVyaW5nIG9i amVjdHMgKGUuZy4sIGZpbGVzLCBtZW1vcnksIGV0Yy4pIHRvIGNhcHR1cmUgZXh0cmFjdGVkIHN0 cmluZ3MsIGltcG9ydHMsIGZ1bmN0aW9ucyBhbmQgY29kZSBzbmlwcGV0czxzcGFuIHN0eWxlPSdm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiInPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0OjEu MGluO3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMSBsZXZlbDEgbGZvMic+PCFbaWYgIXN1 cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U3lt Ym9sJz48c3BhbiBzdHlsZT0nbXNvLWxpc3Q6SWdub3JlJz7CtzxzcGFuIHN0eWxlPSdmb250Ojcu MHB0ICJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPkFkZGVkIGEgQnl0 ZVJ1bnNUeXBlIHRvIGVuYWJsZSBjYXB0dXJlIG9mIGJ5dGUgcnVucyB3aXRoaW4gdmFyaW91cyBv YmplY3RzLjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiInPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwg c3R5bGU9J21hcmdpbi1sZWZ0OjEuMGluO3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMSBs ZXZlbDEgbGZvMic+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sJz48c3BhbiBzdHlsZT0nbXNvLWxpc3Q6SWdub3JlJz7C tzxzcGFuIHN0eWxlPSdmb250OjcuMHB0ICJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjwvc3Bhbj48L3NwYW4+ PCFbZW5kaWZdPkFkZGVkIG9iamVjdF9yZWZlcmVuY2UgYXR0cmlidXRlIHRvIERlZmluZWRPYmpl Y3RUeXBlIHRvIGJldHRlciBzdXBwb3J0IHJlZmVyZW5jaW5nIG9mIGluZGVwZW5kZW50bHkgZGVm aW5lZCBPYmplY3RzIGZyb20gd2l0aGluIGFub3RoZXIgT2JqZWN0IGRlZmluaXRpb24uPHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm Iic+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2lu LWxlZnQ6MS4waW47dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwxIGxldmVsMSBsZm8yJz48 IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTpTeW1ib2wnPjxzcGFuIHN0eWxlPSdtc28tbGlzdDpJZ25vcmUnPsK3PHNwYW4gc3R5bGU9 J2ZvbnQ6Ny4wcHQgIlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+QWRk ZWQgYSBnZW5lcmljIERhdGFTZWdtZW50VHlwZSB0byBwcm92aWRlIGEgcmVsYXRpdmVseSBhYnN0 cmFjdCB3YXkgb2YgY2hhcmFjdGVyaXppbmcgZGF0YSBzZWdtZW50cyB0aGF0IG1heSBiZSB3cml0 dGVuL3JlYWQvdHJhbnNtaXR0ZWQgb3Igb3RoZXJ3aXNlIHV0aWxpemVkIGluIGFjdGlvbnMgb3Ig ZGVmaW5lZCBpbiBvYmplY3RzLjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiInPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48ZGl2IHN0 eWxlPSdtYXJnaW4tbGVmdDouNWluJz48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1s ZWZ0Oi41aW47dGV4dC1pbmRlbnQ6LS4yNWluJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTpTeW1ib2wnPsK3PC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6Ny4w cHQnPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNz PWFwcGxlLWNvbnZlcnRlZC1zcGFjZT4mbmJzcDs8L3NwYW4+PC9zcGFuPkFkZGVkIHNldmVyYWwg bmV3IGRlZmluZWQgb2JqZWN0IHNjaGVtYXMgKEFQSSwgQ29kZSwgRGV2aWNlLCBETlNfUmVjb3Jk LCBOZXR3b3JrX0Zsb3csIE5ldHdvcmtfUGFja2V0LCBOZXR3b3JrX1JvdXRlX0VudHJ5LCBOZXR3 b3JrX1N1Ym5ldCwgVW5peF9OZXR3b3JrX1JvdXRlX0VudHJ5KSBpbmNsdWRpbmcgYW4gaW5pdGlh bCBzZXQgb2YgbmV0d29yay1jZW50cmljIGRlZmluZWQgb2JqZWN0cy48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjExLjBwdCc+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxwIGNsYXNzPU1zb05v cm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6MS4waW47dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0 OmwwIGxldmVsMSBsZm80Jz48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0nZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTpTeW1ib2wnPjxzcGFuIHN0eWxlPSdtc28tbGlzdDpJZ25v cmUnPsK3PHNwYW4gc3R5bGU9J2ZvbnQ6Ny4wcHQgIlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+PC9zcGFuPjwv c3Bhbj48IVtlbmRpZl0+TW9kaWZpZWQgZXZlcnkgZGVmaW5lZCBvYmplY3Qgc2NoZW1hIHdpdGgg YWRkZWQgYW5ub3RhdGlvbnMgYXMgd2VsbCBhcyBtaW5vciBhbmQgaW4gc29tZSBjYXNlcyBzdWJz dGFudGl2ZSBjaGFuZ2VzIHRvIGZpeCBlcnJvcnMsIGltcHJvdmUgY29uc2lzdGVuY3kgYW5kIGFs aWdubWVudCB3aXRoIGV4aXN0aW5nIG5vcm1hdGl2ZSByZWZlcmVuY2VzLCBhbmQgdG8gaW1wcm92 ZSBleHByZXNzaXZlbmVzcyBpbiBzdXBwb3J0IG9mIHRoZSB0YXJnZXRlZCB1c2UgY2FzZXMuPHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIic+PG86cD48L286cD48L3NwYW4+PC9wPjxkaXYgc3R5bGU9J21hcmdpbi1sZWZ0Oi4yNWlu Jz48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4nPkRldGFpbGVkIGNo YW5nZXMgZnJvbSBDeWJPWF92MC43IHRvIEN5Yk9YX3YxLjBfKERyYWZ0KTo8c3BhbiBzdHlsZT0n Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz48bzpw PjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21h cmdpbi1sZWZ0Oi41aW4nPlRoZSBsZXZlbCBvZiBjaGFuZ2VzIHdpdGhpbiB2MS4wIChEcmFmdCkg aW4gdGhlIGNvcmUgc2NoZW1hLCBjb21tb25fdHlwZXMgYW5kIHRoZSBkZWZpbmVkIG9iamVjdCBz Y2hlbWFzIGlzIHRvbyBncmVhdCB0byBsaXN0IGV2ZXJ5IGNoYW5nZSBpbiB0aGVzZSByZWxlYXNl IG5vdGVzLiBEZXRhaWxlZCBkaWZmZXJlbmNlIHJlcG9ydHMgYXJlIGF2YWlsYWJsZSBmb3IgZWFj aCBpbmRpdmlkdWFsIHNjaGVtYSBhdDo8c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz48YSBocmVmPSJodHRwOi8vY3lib3gubWl0 cmUub3JnL1hNTFNjaGVtYS9yZWxlYXNlX25vdGVzL2N5Ym94X3YxLjAoZHJhZnQpX2RpZmZfcmVw b3J0cy56aXAiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iLCJzZXJpZiInPmh0dHA6Ly9jeWJveC5taXRyZS5vcmcvWE1MU2NoZW1hL3Jl bGVhc2Vfbm90ZXMvY3lib3hfdjEuMChkcmFmdClfZGlmZl9yZXBvcnRzLnppcDwvc3Bhbj48L2E+ PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxl PSdtYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4nPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiInPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2IHN0eWxlPSdtYXJn aW4tbGVmdDouNWluJz48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4n PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT08L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2 PjxkaXYgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4nPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0n bWFyZ2luLWxlZnQ6LjVpbic+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5TZWFuIEJhcm51bTwvc3Bh bj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdiBzdHlsZT0nbWFyZ2lu LWxlZnQ6LjVpbic+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkN5YmVyIFNlY3VyaXR5IFByaW5jaXBhbDwvc3Bhbj48c3Bh biBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdiBzdHlsZT0nbWFyZ2luLWxlZnQ6 LjVpbic+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz48c3BhbiBz dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi O2NvbG9yOiMxRjQ5N0QnPlRoZSBNSVRSRSBDb3Jwb3JhdGlvbjwvc3Bhbj48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz48bzpw PjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdiBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVpbic+PHAg Y2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMx RjQ5N0QnPkVtYWlsOjxzcGFuIGNsYXNzPWFwcGxlLWNvbnZlcnRlZC1zcGFjZT4mbmJzcDs8L3Nw YW4+PGEgaHJlZj0ibWFpbHRvOnNiYXJudW1AbWl0cmUub3JnIj5zYmFybnVtQG1pdHJlLm9yZzwv YT48L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIic+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0nZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz4mbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4t bGVmdDouNWluJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseToiSGVs dmV0aWNhIiwic2Fucy1zZXJpZiInPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPGJyPm1pbGUgbWFpbGluZyBsaXN0PGJyPjxhIGhyZWY9Im1haWx0bzptaWxl QGlldGYub3JnIj5taWxlQGlldGYub3JnPC9hPjxicj48YSBocmVmPSJodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL21pbGUiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbWlsZTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PHAgY2xh c3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz48bzpwPiZuYnNwOzwvbzpwPjwv cD48L2Rpdj48L2Rpdj48L2JvZHk+PC9odG1sPg== ------_=_NextPart_001_01CD1C4E.2F4B01A2-- From kathleen.moriarty@emc.com Tue Apr 17 00:48:15 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2E5221F849A; Tue, 17 Apr 2012 00:48:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.432 X-Spam-Level: X-Spam-Status: No, score=-10.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id awkiAScuy4v2; Tue, 17 Apr 2012 00:48:10 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 63B6D21F8498; Tue, 17 Apr 2012 00:48:09 -0700 (PDT) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q3H7m6mS018734 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Apr 2012 03:48:06 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.130]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Tue, 17 Apr 2012 03:47:51 -0400 Received: from mxhub14.corp.emc.com (mxhub14.corp.emc.com [128.222.70.235]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q3H7lo7u019192; Tue, 17 Apr 2012 03:47:50 -0400 Received: from mx06a.corp.emc.com ([169.254.1.106]) by mxhub14.corp.emc.com ([128.222.70.235]) with mapi; Tue, 17 Apr 2012 03:47:49 -0400 From: To: , Date: Tue, 17 Apr 2012 03:47:49 -0400 Thread-Topic: [mile] CybOX v1.0 (Draft) is now released and live on the website Thread-Index: Ac0cIooXr4s/7oQ8SPiJ2GBnx2iBMgAStEiR Message-ID: References: <7F48813B48558A4BB5CB7BB714E5B5A91706E3@IMCMBX03.MITRE.ORG>, <870A23D4-BA94-4431-B613-F3D7734B8DB5@c3isecurity.com> In-Reply-To: <870A23D4-BA94-4431-B613-F3D7734B8DB5@c3isecurity.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: mile@ietf.org, dallendoug@gmail.com, sacm@ietf.org, m-terada@ipa.go.jp Subject: Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live on the website X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 07:48:15 -0000 Thank you for sharing the publication of the CybOX specification to the MIT= RE site, Sean. =20 As an FYI to those who are not familiar with IODEF, I just want to clarify = that incident descriptions via IODEF already can include network-centric ob= jects (NetFlow data was specifically considered for this representation) in= the IODEF flow class. If there is something missing, please post to the M= ILE mailing list and we will track that for possible revision in IODEF to t= he guidance document. If CybOX gets submitted to the IETF or another standards body, then we will= be able to consider the intersection and how CybOX might be incorporated i= n IODEF.=20 Thank you, Kathleen ________________________________________ From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of Luis Nunez= [lnunez@c3isecurity.com] Sent: Monday, April 16, 2012 6:44 PM To: Barnum, Sean D. Cc: idxwg@nicwg.org; mile@ietf.org; Doug Wilson (dallendoug@gmail.com); sac= m@ietf.org; IPA-Masato Terada (m-terada@ipa.go.jp) Subject: Re: [mile] CybOX v1.0 (Draft) is now released and live on the web= site I like the inclusion of the network-centric objects. IPFIX (netflow) will= add an additional perspective from an incident information sharing standpo= int. -ln On Apr 16, 2012, at 4:04 PM, Barnum, Sean D. wrote: Hey everyone, I just wanted to let you all know that CybOX v1.0 (Draft) content is now li= ve on the website. http://cybox.mitre.org The release notes are provided inline below. The key items of note are: =95 The release of two formal specifications for the CybOX language = (one for the core language and one for the defined objects) =95 The XML Schema has gone through extensive improvements for expre= ssiveness, clarity, consistency, efficiency, alignment to existing normativ= e references and documentation. =95 This release includes an initial set of language utilities: a dr= aft Snort -> CybOX transform, a draft OpenIOC -> CybOX transform, and a set= of Python bindings for the CybOX language. =95 The website now includes a small set of content examples. This s= et will grow going forward. This release involved a lot of hard work from a diverse group of people. Th= ank you all for your contributions and effort. We could not have done it wi= thout you. We look forward to everyone=92s feedback and collaboration as we continue t= o improve and mature the CybOX language. Sean Barnum CybOX v1.0 (Draft) Release Notes The Version 1.0 (Draft) release of Cyber Observable eXpression (CybOX=99) i= s intended as a draft release of an initial major version of the CybOX Lang= uage that could be utilized for practical operational use and integration i= nto other standards efforts. This release consists of three primary compone= nts: a pair of formal language specifications for the core language content= and defined objects content, a set of language implementation XML schemas = (core, common_types, and ~70 defined object schemas), and a small initial s= et of language utilities including an initial draft Snort->CybOX transform,= an initial draft OpenIOC->CybOX transform and a set of CybOX language Pyth= on bindings. Recognizing that this is the first time that the formal langua= ge specifications will be available for review and as such will likely gene= rate feedback from new stakeholders, this initial major version is being re= leased as a =93draft=94 v1.0 with the expectation of cycles of new feedback= and revision before a =93final=94 v1.0 is released. The CybOX v1.0 (Draft) XML schemas include a significant number of changes = from v0.7 to improve: =95 Clarity, documentation, and descriptive formality for reference a= nd implementation by other standards and users. =95 Consistency, simplicity, and efficiency. =95 Alignment (as appropriate) to existing normative references. =95 Expressiveness of the schema to better support the broad set of u= se cases it targets (malware characterization, indicator and incident data = sharing, event management, etc.) including the addition of an initial set o= f network-related defined objects. Summary of changes from CybOX_v0.7 to CybOX_v1.0_(Draft): * Refinement of namespaces and schema locations for better effectiveness= and flexibility going forward. * Normalized all content according to an established set of naming conve= ntions. * Fully annotated all language items (types, attributes, elements, etc.)= . * Moved several commonly leveraged types out of the core schema and into= common_types. * Achieved full typing of entire schema structure such that all attribut= es and elements are definitively typed. * Changed all identifiers from ID and IDREF types to be QNames enabling = globally unique identifiers and flexibility for domain-specific users of Cy= bOX to define their own identifier syntax locally. * Reordered attributes and elements in numerous types to better reflect = common usage and priority. * Added major_version and minor_version attributes for core schema. * Added capability to characterize source of overall observable package = data and for individual observables. * Modified the logical composition structure such that any such composit= ions are now contained within a Observable_Composition element providing im= proved simplicity and modularity. * Removed the Delta element from ObservableType and relocated the approp= riate portions (Change, Trend, and Frequency) to appropriate locations unde= r Stateful_Measure and Event. * Added a Domain_Specific_Object_Attributes field to Object utilizing an= abstract type that will allow domain-specific use cases to add in their ow= n domain-specific attributes for Objects. * Added a Tool-Specific_Data field to ToolInformationType utilizing an a= bstract type that will allow addition of tool-specific data. * Added an Indicators field to MeasureSourceType utilizing an abstract t= ype that will allow characterizing differing formats or standards of indica= tors that may have led to the identification of the observable data. * Enhanced the Hash structure to capture full fuzzy hashes in addition t= o simple hashes * Added a new ExtractedFeaturesType that can be used to adorn differing = objects (e.g., files, memory, etc.) to capture extracted strings, imports, = functions and code snippets * Added a ByteRunsType to enable capture of byte runs within various obj= ects. * Added object_reference attribute to DefinedObjectType to better suppor= t referencing of independently defined Objects from within another Object d= efinition. * Added a generic DataSegmentType to provide a relatively abstract way o= f characterizing data segments that may be written/read/transmitted or othe= rwise utilized in actions or defined in objects. =95 Added several new defined object schemas (API, Code, Device, DNS= _Record, Network_Flow, Network_Packet, Network_Route_Entry, Network_Subnet,= Unix_Network_Route_Entry) including an initial set of network-centric defi= ned objects. * Modified every defined object schema with added annotations as well as= minor and in some cases substantive changes to fix errors, improve consist= ency and alignment with existing normative references, and to improve expre= ssiveness in support of the targeted use cases. Detailed changes from CybOX_v0.7 to CybOX_v1.0_(Draft): The level of changes within v1.0 (Draft) in the core schema, common_types a= nd the defined object schemas is too great to list every change in these re= lease notes. Detailed difference reports are available for each individual = schema at:http://cybox.mitre.org/XMLSchema/release_notes/cybox_v1.0(draft)_= diff_reports.zip =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Sean Barnum Cyber Security Principal The MITRE Corporation Email: sbarnum@mitre.org _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile From sbarnum@mitre.org Mon Apr 16 20:14:25 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47F0C11E808A; Mon, 16 Apr 2012 20:14:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gVtXyxs0Ry9g; Mon, 16 Apr 2012 20:14:20 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 2AD3711E8081; Mon, 16 Apr 2012 20:14:20 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 6BCA421B0E19; Mon, 16 Apr 2012 23:14:19 -0400 (EDT) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 4A9D921B0B58; Mon, 16 Apr 2012 23:14:19 -0400 (EDT) Received: from IMCMBX03.MITRE.ORG ([169.254.3.179]) by IMCCAS03.MITRE.ORG ([129.83.29.80]) with mapi id 14.02.0283.003; Mon, 16 Apr 2012 23:14:18 -0400 From: "Barnum, Sean D." To: Luis Nunez Thread-Topic: [mile] CybOX v1.0 (Draft) is now released and live on the website Thread-Index: Ac0cC5d+AmQj+T0kR7yrc02aMAE2BgAAA7pgAA4W5AAAAKzAMA== Date: Tue, 17 Apr 2012 03:14:18 +0000 Message-ID: <7F48813B48558A4BB5CB7BB714E5B5A9171AEB@IMCMBX03.MITRE.ORG> References: <7F48813B48558A4BB5CB7BB714E5B5A91706E3@IMCMBX03.MITRE.ORG> <870A23D4-BA94-4431-B613-F3D7734B8DB5@c3isecurity.com> In-Reply-To: <870A23D4-BA94-4431-B613-F3D7734B8DB5@c3isecurity.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [172.31.136.182] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_003A_01CD1C26.A2A48B80" MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 17 Apr 2012 05:31:10 -0700 Cc: "idxwg@nicwg.org" , "mile@ietf.org" , "Doug Wilson \(dallendoug@gmail.com\)" , "sacm@ietf.org" , "IPA-Masato Terada \(m-terada@ipa.go.jp\)" Subject: Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live on the website X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 03:14:25 -0000 ------=_NextPart_000_003A_01CD1C26.A2A48B80 Content-Type: multipart/alternative; boundary="----=_NextPart_001_003B_01CD1C26.A2A48B80" ------=_NextPart_001_003B_01CD1C26.A2A48B80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I am glad to hear that you find it useful Luis. We felt that a minimum initial set of network-related objects was an important part of any sort of 1.0 release. The initial set of network-related objects for CybOX v1.0 (Draft) includes: Address, Port, URI, Socket, DNS_Record, DNS_Cache, Network_Flow, Network_Packet, Network_Route_Entry, Unix_Network_Route_Entry, Win_Network_Route_Entry, Network_Route, Network_Subnet, and Win_Network_Share. From our discussions with various knowledgeable parties, this seemed like a good initial baseline. If any of you experts have suggestions on other objects that would be useful for current needs or suggestions on refinements to these existing objects, we humbly welcome your input. Thanks Luis, sean From: Luis Nunez [mailto:lnunez@c3isecurity.com] Sent: Monday, April 16, 2012 6:44 PM To: Barnum, Sean D. Cc: idxwg@nicwg.org; mile@ietf.org; Doug Wilson (dallendoug@gmail.com); IPA-Masato Terada (m-terada@ipa.go.jp); sacm@ietf.org Subject: Re: [mile] CybOX v1.0 (Draft) is now released and live on the website I like the inclusion of the network-centric objects. IPFIX (netflow) will add an additional perspective from an incident information sharing standpoint. -ln On Apr 16, 2012, at 4:04 PM, Barnum, Sean D. wrote: Hey everyone, I just wanted to let you all know that CybOX v1.0 (Draft) content is now live on the website. http://cybox.mitre.org The release notes are provided inline below. The key items of note are: . The release of two formal specifications for the CybOX language (one for the core language and one for the defined objects) . The XML Schema has gone through extensive improvements for expressiveness, clarity, consistency, efficiency, alignment to existing normative references and documentation. . This release includes an initial set of language utilities: a draft Snort -> CybOX transform, a draft OpenIOC -> CybOX transform, and a set of Python bindings for the CybOX language. . The website now includes a small set of content examples. This set will grow going forward. This release involved a lot of hard work from a diverse group of people. Thank you all for your contributions and effort. We could not have done it without you. We look forward to everyone's feedback and collaboration as we continue to improve and mature the CybOX language. Sean Barnum CybOX v1.0 (Draft) Release Notes The Version 1.0 (Draft) release of Cyber Observable eXpression (CybOXT) is intended as a draft release of an initial major version of the CybOX Language that could be utilized for practical operational use and integration into other standards efforts. This release consists of three primary components: a pair of formal language specifications for the core language content and defined objects content, a set of language implementation XML schemas (core, common_types, and ~70 defined object schemas), and a small initial set of language utilities including an initial draft Snort->CybOX transform, an initial draft OpenIOC->CybOX transform and a set of CybOX language Python bindings. Recognizing that this is the first time that the formal language specifications will be available for review and as such will likely generate feedback from new stakeholders, this initial major version is being released as a "draft" v1.0 with the expectation of cycles of new feedback and revision before a "final" v1.0 is released. The CybOX v1.0 (Draft) XML schemas include a significant number of changes from v0.7 to improve: . Clarity, documentation, and descriptive formality for reference and implementation by other standards and users. . Consistency, simplicity, and efficiency. . Alignment (as appropriate) to existing normative references. . Expressiveness of the schema to better support the broad set of use cases it targets (malware characterization, indicator and incident data sharing, event management, etc.) including the addition of an initial set of network-related defined objects. Summary of changes from CybOX_v0.7 to CybOX_v1.0_(Draft): . Refinement of namespaces and schema locations for better effectiveness and flexibility going forward. . Normalized all content according to an established set of naming conventions. . Fully annotated all language items (types, attributes, elements, etc.). . Moved several commonly leveraged types out of the core schema and into common_types. . Achieved full typing of entire schema structure such that all attributes and elements are definitively typed. . Changed all identifiers from ID and IDREF types to be QNames enabling globally unique identifiers and flexibility for domain-specific users of CybOX to define their own identifier syntax locally. . Reordered attributes and elements in numerous types to better reflect common usage and priority. . Added major_version and minor_version attributes for core schema. . Added capability to characterize source of overall observable package data and for individual observables. . Modified the logical composition structure such that any such compositions are now contained within a Observable_Composition element providing improved simplicity and modularity. . Removed the Delta element from ObservableType and relocated the appropriate portions (Change, Trend, and Frequency) to appropriate locations under Stateful_Measure and Event. . Added a Domain_Specific_Object_Attributes field to Object utilizing an abstract type that will allow domain-specific use cases to add in their own domain-specific attributes for Objects. . Added a Tool-Specific_Data field to ToolInformationType utilizing an abstract type that will allow addition of tool-specific data. . Added an Indicators field to MeasureSourceType utilizing an abstract type that will allow characterizing differing formats or standards of indicators that may have led to the identification of the observable data. . Enhanced the Hash structure to capture full fuzzy hashes in addition to simple hashes . Added a new ExtractedFeaturesType that can be used to adorn differing objects (e.g., files, memory, etc.) to capture extracted strings, imports, functions and code snippets . Added a ByteRunsType to enable capture of byte runs within various objects. . Added object_reference attribute to DefinedObjectType to better support referencing of independently defined Objects from within another Object definition. . Added a generic DataSegmentType to provide a relatively abstract way of characterizing data segments that may be written/read/transmitted or otherwise utilized in actions or defined in objects. . Added several new defined object schemas (API, Code, Device, DNS_Record, Network_Flow, Network_Packet, Network_Route_Entry, Network_Subnet, Unix_Network_Route_Entry) including an initial set of network-centric defined objects. . Modified every defined object schema with added annotations as well as minor and in some cases substantive changes to fix errors, improve consistency and alignment with existing normative references, and to improve expressiveness in support of the targeted use cases. Detailed changes from CybOX_v0.7 to CybOX_v1.0_(Draft): The level of changes within v1.0 (Draft) in the core schema, common_types and the defined object schemas is too great to list every change in these release notes. Detailed difference reports are available for each individual schema at: http://cybox.mitre.org/XMLSchema/release_notes/cybox_v1.0(draft)_diff_report s.zip =============================================== Sean Barnum Cyber Security Principal The MITRE Corporation Email: sbarnum@mitre.org _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile ------=_NextPart_001_003B_01CD1C26.A2A48B80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I am glad to hear that you find it useful = Luis.

We felt that a minimum initial set of network-related objects was an = important part of any sort of 1.0 release.

The initial set of network-related objects for CybOX v1.0 (Draft) = includes: Address, Port, URI, Socket, DNS_Record, DNS_Cache, = Network_Flow, Network_Packet, Network_Route_Entry, = Unix_Network_Route_Entry, Win_Network_Route_Entry, Network_Route, = Network_Subnet, and Win_Network_Share. From our discussions with various = knowledgeable parties, this seemed like a good initial = baseline.

 

If any of you experts have suggestions on other objects that would be = useful for current needs or suggestions on refinements to these existing = objects, we humbly welcome your input.

 

Thanks Luis,

 

sean

 

From:= = Luis Nunez [mailto:lnunez@c3isecurity.com]
Sent: Monday, = April 16, 2012 6:44 PM
To: Barnum, Sean D.
Cc: = idxwg@nicwg.org; mile@ietf.org; Doug Wilson (dallendoug@gmail.com); = IPA-Masato Terada (m-terada@ipa.go.jp); sacm@ietf.org
Subject: = Re: [mile] CybOX v1.0 (Draft) is now released and live on the = website

 

I like the inclusion of the network-centric = objects.  IPFIX (netflow)  will add an additional perspective = from an incident information sharing standpoint. =  

 

-ln

 

On Apr 16, 2012, at 4:04 = PM, Barnum, Sean D. wrote:



Hey = everyone,

 =

I just = wanted to let you all know that CybOX v1.0 (Draft) content is now live = on the website. http://cybox.mitre.org

The = release notes are provided inline = below.

The key = items of note are:

·        The = release of two formal specifications for the CybOX language (one for the = core language and one for the defined = objects)

·        The XML = Schema has gone through extensive improvements for expressiveness, = clarity, consistency, efficiency, alignment to existing normative = references and documentation.

·        This = release includes an initial set of language utilities: a draft Snort = -> CybOX transform, a draft OpenIOC -> CybOX transform, and a set = of Python bindings for the CybOX language.

·        The = website now includes a small set of content examples. This set will grow = going forward.

This = release involved a lot of hard work from a diverse group of people. = Thank you all for your contributions and effort. We could not have done = it without you.

We look = forward to everyone’s feedback and collaboration as we continue to = improve and mature the CybOX = language.

 =

Sean = Barnum

 =

 =

 =

CybOX v1.0 (Draft) Release = Notes

The Version 1.0 (Draft) release of Cyber = Observable eXpression (CybOX™) is intended as a draft release of an initial major version of = the CybOX Language that could be utilized for practical operational use = and integration into other standards efforts. This release consists of = three primary components: a pair of formal language specifications for = the core language content and defined objects content, a set of language = implementation XML schemas (core, common_types, and ~70 defined object = schemas), and a small initial set of language utilities including an = initial draft Snort->CybOX transform, an initial draft = OpenIOC->CybOX transform and a set of CybOX language Python bindings. = Recognizing that this is the first time that the formal language = specifications will be available for review and as such will likely = generate feedback from new stakeholders, this initial major version is = being released as a “draft” v1.0 with the expectation of = cycles of new feedback and revision before a “final” v1.0 is = released.=

The CybOX v1.0 (Draft) XML schemas include a = significant number of changes from v0.7 to improve:=

·       Clarity, = documentation, and descriptive formality for reference and = implementation by other standards and users.=

·       Consistency, = simplicity, and efficiency.=

·       Alignment (as = appropriate) to existing normative references.=

·       Expressiveness of the = schema to better support the broad set of use cases it targets (malware = characterization, indicator and incident data sharing, event management, = etc.) including the addition of an initial set of network-related = defined objects.=

Summary = of changes from CybOX_v0.7 to CybOX_v1.0_(Draft):=

·        = Refinement of namespaces and schema = locations for better effectiveness and flexibility going forward.=

·        = Normalized all content according to an = established set of naming conventions.=

·        = Fully annotated all language items = (types, attributes, elements, etc.).=

·        = Moved several commonly leveraged types = out of the core schema and into common_types.=

·        = Achieved full typing of entire schema = structure such that all attributes and elements are definitively = typed.=

·        = Changed all identifiers from ID and IDREF = types to be QNames enabling globally unique identifiers and flexibility = for domain-specific users of CybOX to define their own identifier syntax = locally.=

·        = Reordered attributes and elements in = numerous types to better reflect common usage and priority.=

·        = Added major_version and minor_version = attributes for core schema.=

·        = Added capability to characterize source = of overall observable package data and for individual observables.=

·        = Modified the logical composition = structure such that any such compositions are now contained within a = Observable_Composition element providing improved simplicity and = modularity.=

·        = Removed the Delta element from = ObservableType and relocated the appropriate portions (Change, Trend, = and Frequency) to appropriate locations under Stateful_Measure and = Event.=

·        = Added a Domain_Specific_Object_Attributes = field to Object utilizing an abstract type that will allow = domain-specific use cases to add in their own domain-specific attributes = for Objects.=

·        = Added a Tool-Specific_Data field to = ToolInformationType utilizing an abstract type that will allow addition = of tool-specific data.=

·        = Added an Indicators field to = MeasureSourceType utilizing an abstract type that will allow = characterizing differing formats or standards of indicators that may = have led to the identification of the observable data.=

·        = Enhanced the Hash structure to capture = full fuzzy hashes in addition to simple hashes=

·        = Added a new ExtractedFeaturesType that = can be used to adorn differing objects (e.g., files, memory, etc.) to = capture extracted strings, imports, functions and code snippets=

·        = Added a ByteRunsType to enable capture of = byte runs within various objects.=

·        = Added object_reference attribute to = DefinedObjectType to better support referencing of independently defined = Objects from within another Object definition.=

·        = Added a generic DataSegmentType to = provide a relatively abstract way of characterizing data segments that = may be written/read/transmitted or otherwise utilized in actions or = defined in objects.=

·        Added several new = defined object schemas (API, Code, Device, DNS_Record, Network_Flow, = Network_Packet, Network_Route_Entry, Network_Subnet, = Unix_Network_Route_Entry) including an initial set of network-centric = defined objects.

·        = Modified every defined object schema with = added annotations as well as minor and in some cases substantive changes = to fix errors, improve consistency and alignment with existing normative = references, and to improve expressiveness in support of the targeted use = cases.=

Detailed changes from CybOX_v0.7 to = CybOX_v1.0_(Draft):=

The level of changes within v1.0 (Draft) in = the core schema, common_types and the defined object schemas is too = great to list every change in these release notes. Detailed difference = reports are available for each individual schema at:http://cybox.mitre.org/XMLSchema/release_notes/cybox_v1.0= (draft)_diff_reports.zip

 =

 =

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

Sean Barnum=

Cyber Security Principal=

The MITRE Corporation=

 =

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

 

------=_NextPart_001_003B_01CD1C26.A2A48B80-- ------=_NextPart_000_003A_01CD1C26.A2A48B80 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIYNDCCBS0w ggMVoAMCAQICEEw6UhQhT9OgRBVHf7KQ+1AwDQYJKoZIhvcNAQELBQAwKTEnMCUGA1UEAxMeTUlU UkUgQ29ycG9yYXRpb24gUEUgUm9vdCBDQS0xMB4XDTExMDQyNjE5NDU0NVoXDTIxMDQyNjE5NDgy MlowKTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUEUgUm9vdCBDQS0xMIICIjANBgkqhkiG 9w0BAQEFAAOCAg8AMIICCgKCAgEAtp8hR0hRq3im+Alwfb5ZHGP5k2OSY2TlVHYHIMUDH3MfW7b6 8lB3j3MwAMsxGK1ke/t6O4K0t9wRH4QDgOQ1CthmOGZW7xiN81h0vP1Yf14SNugUa7ZvH9KP3iXs y8QnOHal1bKf0Pa9KXib58qUuwfaZSCTW5P2ekqd8z4TETvfBWvPgDxyxnVsiAO6yL9WaRpMiSVM hYLWy3KRuU/gue0bVEi+qdg+hENh1NSNXpoqseS262nq5cx5wybR/PF0YstQ9NNlYDM5cLECKYHH zD6cXKJozuFXriswlE8rdna7VaxyZrfgC0ueEIY/tsj/65IyUhyPBwO0ZpW+Ls9Cd4Y+ERSu5mR5 Fd8w42eVzuosmk3s3AxrKC+Z4tXYkjaiWUduIegAiST1vJBwkS53vR+zrBX3Ep56l7MFVvW/GcsZ 9wUT2HG65JOeiVc2YzCEqLgQ3ZCBHn09oBag2lnMac+E2sKm9aKL3xzHs6cyD8qCJK9O8QLCqo3C mzASlOwtTFiLYgpPW/MSmgYOt9JrwHAzk97DHFKTFttjrXGMmhMVzadt1EjMn1Wv8t5WLBI0qSoX /MYi2CaeiDsEiWRu9Nmpu3pmi8m7tIR9csdbAVPks2soNMWOopGEpFQSDvU1+m77v2jIKQKYxYmN 2zUOJ4TJFL1osnZ/71MmLCDVd+ECAwEAAaNRME8wCwYDVR0PBAQDAgGGMA8GA1UdEwEB/wQFMAMB Af8wHQYDVR0OBBYEFFuHfZ/+bL4C6fPgKTqKVCUsnzgvMBAGCSsGAQQBgjcVAQQDAgEAMA0GCSqG SIb3DQEBCwUAA4ICAQAy78sXsP/eqHH8/uOYyxQ6TBDhkCBxNoy8MF2c9UDns5ADL1qyxPAlpDBs L+2h1Zzt3FvPjg0SoRE/9juyG1qxMzhlv0jdQx12tESdo3uBb61b1uuc4H/VxCJWDI4KZL/B53EI 8HGPjUBdLADgOmG99uffm5uarSkjtIX//Bz3U6QfzTPlVWFi4SmzRI2mp16GQ8RPuJ/WMloaAn8X H6EjS2oLjGZC8Pw8/C46W48NvZ1JZTrZvYZr7GmuvmplYK68SZv/T5Su+FlLRTy9uNXQLHtm6jKv nDH2yB66zTwfaDpnjILnrC2O7ANRVZc0KywiKiW3nB7Joq74/XVuMI1PiSByt2Qu+RIS/WAI5wMi bTmwSiBxQZqvuth+dXoakJyOP2Wg5jvL55v9RLZhDqMtRI5ovnOFvTgNJQqNPSekGtA+m6Ctl/vh kSg65FFCMhaSkn7vY2Il+R8HouWJN8wTaudeexnyHcD+Mlt8QaB5CErpDjeeGZfQ0FcYm+6TtlMz Dw5eFhT/J6QrABCxfgLkVFHurMcQD4JkmXXkq5bP+GNkY0Uy2LMbw/UD94OEV1LpfAqUkT+mu5Yb vxg+elFtsad+Ix8owW372xynIADh9q1bHm+j1OHPJmGALWK9miRpC4t3isfu3ZB0QpI/e2Po6MED 393Jb0YbzrcElFv6ZDCCBhYwggP+oAMCAQICChrDbcgAAgAAN/wwDQYJKoZIhvcNAQEFBQAwUDET MBEGCgmSJomT8ixkARkWA09SRzEVMBMGCgmSJomT8ixkARkWBU1JVFJFMSIwIAYDVQQDExlNSVRS RSBDb3Jwb3JhdGlvbiBQRSBDQS0xMB4XDTEyMDMxMjE1MTgyN1oXDTE1MDMxMjE1MTgyN1owSjEL MAkGA1UEBhMCVVMxDjAMBgNVBAoTBU1JVFJFMQ8wDQYDVQQLEwZQZW9wbGUxGjAYBgNVBAMTEUJh cm51bS5TZWFuLjMxNTQzMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA9/I6RU7OcouL 6lcEJMAg8G3myNbQu84QnflS8p3PWOjgC6P50RDqGX5UxelDqMQPN5IsNYRXVY9/b7yN/RSH4goI JfYKMitndKuCKz1q38Nh0YycEm5x2t/IN/60b01T1uOmhZfptLDoDzj0UQZwMQ19mhM/ldsrC8bR GGuHXdQVaSyXygfhzNhqC06vZo5fvCBUJ6z7JtVrfRTHdudg19JYK+gds9p+Lvp/DOEXQmgpfpMl jfNKMnrG+kPMMngrIJUsF5lcbhHuc5mO+O8eR8FxM2KF7gfKVmUmZxs7Y6uLenVJVEmllP0XgUu1 sv3bClFgUo5x5Aq6rXshtHuVuQIDAQABo4IB9jCCAfIwKAYDVR0lBCEwHwYIKwYBBQUHAwQGCSsG AQQBcwIBBwYIKwYBBQUHAwIwHQYDVR0OBBYEFDvU1Ph/OVxGkxRmwvRx1TBf5PKqMA4GA1UdDwEB /wQEAwIGwDAcBgNVHREEFTATgRFzYmFybnVtQG1pdHJlLm9yZzAfBgNVHSMEGDAWgBRpZyAh1EjB 0BsGbvMIKOI6gn1BMTBJBgNVHR8EQjBAMD6gPKA6hjhodHRwOi8vcGtpLm1pdHJlLm9yZy9NSVRS RSUyMENvcnBvcmF0aW9uJTIwUEUlMjBDQS0xLmNybDB/BggrBgEFBQcBAQRzMHEwRwYIKwYBBQUH MAKGO2h0dHA6Ly9wa2kubWl0cmUub3JnL01JVFJFJTIwQ29ycG9yYXRpb24lMjBQRSUyMENBLTEo MikuY3J0MCYGCCsGAQUFBzABhhpodHRwOi8vb2NzcC5taXRyZS5vcmcvb2NzcDA+BgkrBgEEAYI3 FQcEMTAvBicrBgEEAYI3FQiDrqwjho6WV4GNiT2CpKsShb6uAYE2g9KXfYeg+0kCAWQCAQcwFgYD VR0gBA8wDTALBgkrBgEEAXMCAQgwNAYJKwYBBAGCNxUKBCcwJTAKBggrBgEFBQcDBDALBgkrBgEE AXMCAQcwCgYIKwYBBQUHAwIwDQYJKoZIhvcNAQEFBQADggIBAC2wqKo7QWQxIqnEKRznPrAQ5vQ9 X5JhB5keH8KMWu1W5n1RuSZH+3TYp4xccdYh+rV5b5+cJcWEYhtYpZriWm4kMHPaB6gKO9rbVfF9 R8Wp8sXvCKogbNhdkZwvXW4QymB1ASlMzDI1cCV8mzYgbIhWaCbV1zZBUVgOGa4LZIgdbdmgo5r/ O2gmnSftTYiE/tQ+DBs/25Bw/jC5HOiMXJqr+JctzJTqpEVLa7GKHnXWGuzGEPYkKBplxIyhz3Mv qc/yuKM7tZzAr8Qn5qf7VI9O2xp56QLjT2+mySOUR6Vml860FMpjjgZNMxAqOJt7OgY0PoUU9d18 yw1wiKSt0LUQoMcVvp7FifBjtBCG1sB/VOzxNvcNm6lO6EO23pvcjt6+WCG1X3pgnZ5UEohsM3c0 oLzYiuSYeVf85IO2yh9fWLWw2RGkf2szck1Xg0DsAQ54/YlZYyehELh43KbS3lpnTt8UlO7C0TMT 7JQwz4fTQg1a0e9rRPFnNDUG2fS2k3tz9IYILDB3F8uiZzzXptEzaYqzIqe5CK8ZGJQcw+w/CBen 6i+MV/y7yJmhio43Y1x9hIqoynqoSMV3CKYCoOwCvFUAGsNllDpExsQZoXrdd5gcuglqbh3t8wOM jtXDSQllQ/hXDZJf8rnH0wGx3K+WA+LKNvKqNCw9spEtsfG0MIIGYjCCBEqgAwIBAgIKFJcW0gAA AAAABDANBgkqhkiG9w0BAQsFADApMScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQRSBSb290 IENBLTEwHhcNMTEwNjE0MTc0NDQ0WhcNMTcwNjE0MTc1NDQ0WjBQMRMwEQYKCZImiZPyLGQBGRYD T1JHMRUwEwYKCZImiZPyLGQBGRYFTUlUUkUxIjAgBgNVBAMTGU1JVFJFIENvcnBvcmF0aW9uIFBF IENBLTEwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDSxK9RXieqdTz4JWRkRMs/EOuF 0P0S9SbspadLJkx/LDDnaAwmAnqfqm1n7/p82oVjy1yCye3SZu4Yp7fmDIAtWbkHvYOfxHkRv1ho /fhaNN0YRkd65oJJz2ngEbNZxdIiCoialQfX/iWU7ApQ+ovKbFV60v5E0p2mPncs20NYRfsaetdh nBZbFD9flDcXwJqSvGGGBfm7ifFCR1LrtEcNKjMwf7YEWZO0Vk3ZyhVq+k7JNLEbKv0OfBz8DU8G iGU+j88QlrgGW8PLkwNk7nsS/DJp8aLudTuVqIE2CA9mqn5QjU/EZYNHGzSfCr+/usUmbojyVSJu khhrAXspRAMz+Cia3yi3q3w8TnAljXWN1dhx1iuUv5GxyzMjfqK1tMuCUU2XzGNNqoVa1mqolBiy DTCOr9d/IC0YHYMBSpQ+xi0x9zjXKt4FmQmkEAZgF4hsZZqcJYL/iCQiwiz8fEyVPZuvoWvdEXOo zFYCpmkT0MZCJwyIux0Z6vJp6VLtN/6rZgc2y54HlTrp3ifazmpsfrk3NdHxlZTZug9kjEI+vEoy p/79nAPyTWQQ1MEP0ErCWav80/HOi0MLx/7lIUfvVOjkOFgFb+iDvR4T3RAQrnEpgTO+fc7Jyzh9 LpFDqm0slwDP4Hj9cC3IzdED5BU43PGAe+HoZ8OD/1ovVgwo/wIDAQABo4IBYzCCAV8wEAYJKwYB BAGCNxUBBAMCAQIwIwYJKwYBBAGCNxUCBBYEFFCiOtgZb+Zdflkw5sC2y01sUQaVMB0GA1UdDgQW BBRpZyAh1EjB0BsGbvMIKOI6gn1BMTAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTALBgNVHQ8E BAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAfBgNVHSMEGDAWgBRbh32f/my+Aunz4Ck6ilQlLJ84LzBQ BgNVHR8ESTBHMEWgQ6BBhj9odHRwOi8vcGtpLm1pdHJlLm9yZy9NSVRSRSUyMENvcnBvcmF0aW9u JTIwUEUlMjBSb290JTIwQ0EtMS5jcmwwWwYIKwYBBQUHAQEETzBNMEsGCCsGAQUFBzAChj9odHRw Oi8vcGtpLm1pdHJlLm9yZy9NSVRSRSUyMENvcnBvcmF0aW9uJTIwUEUlMjBSb290JTIwQ0EtMS5j cnQwDQYJKoZIhvcNAQELBQADggIBAHnDPfdYKxqNOtAYXMyyel83Vs8cCDAQZhSuIB0c6GkGoEdF rmWH9pwi42V96rCp7TvbNNKNJXbVHfJUAp+uqw663DL/sXXff9ZFxPxKOdPnpA8cKM7RBH9e437N w3d28A7PaGbP6tXmSqhXAhYZ4U12y1U5cOf2G/phUoAAMlnVJdfmXzMazvLo2SIeixAJyCze6rHQ TFQ/N+gAjbVuRJ+Hs8FEKVzMSwqlNoupe2ELqL4dMAKT6P08sAfxm2SrRlQvcWPYvqM/1C10bgc2 tdu+WGzRuP5Wx9Yr15KO9SW4z7fn2RVEXQgoDDno5vCIcfUPuKB5n+Kt9eBCitsgSD9yYsNUN9LE VIvjAb8MV2LWLfge1bumo6g7QMRa4Fgifw5siGwi7V2EaJQo6UAIVvxKKFC7W4p6CkrY2ga1d7GI Q0DPiWZOezOakJVAxL5gf+3WdNt0igKc/yLfbdHn6hCd1KPgDqkSKr8zWOZI/jiDBW957xAmaO6Q dGQDBZrQHWpIVwQGzF5bGrqms2kq49l3t7KmBu0C/9tExqKAmlf4Y5lfQGdCbKQpAq712DVQHYuD XmVQEAc2vlJ1C5hS3Iw9DwBWTfJ4vyB48buhBhbIhPiFta5OizXlKcsIi99ikA1yiZx/DBtjaw4J U6qJzWUFB2ecyGCNPtNbYjURA0A9MIIGfzCCBGegAwIBAgIKGsNq2wACAAA3+jANBgkqhkiG9w0B AQUFADBQMRMwEQYKCZImiZPyLGQBGRYDT1JHMRUwEwYKCZImiZPyLGQBGRYFTUlUUkUxIjAgBgNV BAMTGU1JVFJFIENvcnBvcmF0aW9uIFBFIENBLTEwHhcNMTIwMzEyMTUxODI3WhcNMTUwMzEyMTUx ODI3WjBKMQswCQYDVQQGEwJVUzEOMAwGA1UEChMFTUlUUkUxDzANBgNVBAsTBlBlb3BsZTEaMBgG A1UEAxMRQmFybnVtLlNlYW4uMzE1NDMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCW InZvCSslmSfSyhTVVSqnokCDajlsCNZHfUlkwkV1++2O71BYvMpjFHWR2XFIx963Hl63lFZzzVci OjIwLb1c/0YXhFfUdAvrbpjlu+ttlO05OEUW0h+5HO+qaebJPamxA00w0bokquRcPxUvwa3jiyL0 WfCwE3+/b5PCOW2xh7FXFKv262FnKIwxnQGXqkiXRP5D/SmdtcZSzxHkDThrhaiHPhJJhZ4XxwBk aGcAlMg8YH6uxshXm8e6c7XUu7gB5p+XThS0dqXujpQp/UQDp5t079+UrDcrpjfDBXIt9qCzLn26 uV5a4cD4xRKwA32f1cXFtiKXM0wYgUM3fEPDAgMBAAGjggJfMIICWzATBgNVHSUEDDAKBggrBgEF BQcDBDCBlAYJKoZIhvcNAQkPBIGGMIGDMA4GCCqGSIb3DQMCAgIAgDAOBggqhkiG9w0DBAICAIAw BwYFKw4DAgcwCgYIKoZIhvcNAwcwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBLTALBglghkgBZQME ARYwCwYJYIZIAWUDBAEZMAsGCWCGSAFlAwQBAjALBglghkgBZQMEAQUwHQYDVR0OBBYEFIrbKa+E Rxo2/Sth2C6jZqZqvRE7MA4GA1UdDwEB/wQEAwIFIDAcBgNVHREEFTATgRFzYmFybnVtQG1pdHJl Lm9yZzAfBgNVHSMEGDAWgBRpZyAh1EjB0BsGbvMIKOI6gn1BMTBJBgNVHR8EQjBAMD6gPKA6hjho dHRwOi8vcGtpLm1pdHJlLm9yZy9NSVRSRSUyMENvcnBvcmF0aW9uJTIwUEUlMjBDQS0xLmNybDB/ BggrBgEFBQcBAQRzMHEwRwYIKwYBBQUHMAKGO2h0dHA6Ly9wa2kubWl0cmUub3JnL01JVFJFJTIw Q29ycG9yYXRpb24lMjBQRSUyMENBLTEoMikuY3J0MCYGCCsGAQUFBzABhhpodHRwOi8vb2NzcC5t aXRyZS5vcmcvb2NzcDA+BgkrBgEEAYI3FQcEMTAvBicrBgEEAYI3FQiDrqwjho6WV4GNiT2CpKsS hb6uAYE2hquSaISo7EUCAWQCAQ8wFgYDVR0gBA8wDTALBgkrBgEEAXMCAQgwGwYJKwYBBAGCNxUK BA4wDDAKBggrBgEFBQcDBDANBgkqhkiG9w0BAQUFAAOCAgEAGmmL43yA+J5lEockM1cxSoyxfSES HUGLVJyrhObbdFD4yO3jf0R4lHLuJlhp1486d9LRZAyzAnl9q8Zf3Tx1rl1kEd3pw0wMuO+ATscc rArEW/rJxjz6zTrNO3PFkFuOEdmKpHaRiFpuSX602INiBEBPluei3uZlWxHW9VqC7hz2diQpOlzS jtPMbL3o7ACjWaq7sQ0xB4rZ6oWyqOZEfHWQA1b7nFgL4nEbmEHNdU4jAjcxkROku4O04205kb5n Loveoz3TSQNt8zalFayZAjt+JEcKuG1f5cyhYI6QwvkS/3M+CjJezuNaSmno29Lm+ToZnwUm4nIB YkBx4r9ZDU2W8029tr5og00A5MGo1LK+unWtHBa7zuPblfSiYgXIHWU+OKrSFaA935Yb4fLXFe9S BmApBr1gohHYos1hct5q90WPufSKIQ9WT+vJYXvW3FpseO4ZLKVnJsO7gVoQEEnWJUwyABBPQrii F0gh++ApKZJROTuR36PsEEx4duI6U4VXMCiIcnEjvNR8Mt5Q/Vp4W4Mp5fCv+QzYkqq9EWD7QuUW Yul6R8Hf7ZTxbUk0NfJgu8escLrgQSwMdP/kE/09vJAAslQBkNnIS7iIhWt4l5XQJBrJc+6popRE R8ykWf25e4CliaUgbAl1tBQKivQ3tlX99WykI2XK3sTk9nsxggMjMIIDHwIBATBeMFAxEzARBgoJ kiaJk/IsZAEZFgNPUkcxFTATBgoJkiaJk/IsZAEZFgVNSVRSRTEiMCAGA1UEAxMZTUlUUkUgQ29y cG9yYXRpb24gUEUgQ0EtMQIKGsNtyAACAAA3/DAJBgUrDgMCGgUAoIIBmjAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjA0MTcwMzE0MTJaMCMGCSqGSIb3DQEJBDEW BBS6PGbfJaQSbUFP5tSYZkxr8MMGXzBbBgkqhkiG9w0BCQ8xTjBMMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMC GjBtBgkrBgEEAYI3EAQxYDBeMFAxEzARBgoJkiaJk/IsZAEZFgNPUkcxFTATBgoJkiaJk/IsZAEZ FgVNSVRSRTEiMCAGA1UEAxMZTUlUUkUgQ29ycG9yYXRpb24gUEUgQ0EtMQIKGsNq2wACAAA3+jBv BgsqhkiG9w0BCRACCzFgoF4wUDETMBEGCgmSJomT8ixkARkWA09SRzEVMBMGCgmSJomT8ixkARkW BU1JVFJFMSIwIAYDVQQDExlNSVRSRSBDb3Jwb3JhdGlvbiBQRSBDQS0xAgoaw2rbAAIAADf6MA0G CSqGSIb3DQEBAQUABIIBABSeDhgYsEWq3Tg5fbNfccadfDni4D9kcCYYbTcyBJbAcIheiuNZQG8l kunqbsWuVd28aH1MymHziA2IDkBJtX8eGtwwN08jKaUsBuOAmi9V62trT8JhhsISzWPW4cmu+6Yz PRHTorB/Zr7TDaJCsC68UlJ01s9e/SZWHXaeAYWj3SWyNu+ksosNgBP3LeTOnvQMhnpIH+bQnAbV 5zNUcAsvEgPAlZWrjfSHeckNAnLxQkG77bdfSTdoWSslA/bcY5a8yhEGRCEscSEfI76D6XIWWy/N KyG8RbVH1r1Tz/8ZkJMUE7e6o0uoW6mRerfgnKe5pNyLPUwGlrONT5f+htkAAAAAAAA= ------=_NextPart_000_003A_01CD1C26.A2A48B80-- From sbarnum@mitre.org Mon Apr 16 20:29:16 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1160221F8581; Mon, 16 Apr 2012 20:29:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mIMSrriailwK; Mon, 16 Apr 2012 20:29:09 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 4129821F8585; Mon, 16 Apr 2012 20:29:09 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id C3E0521B0E26; Mon, 16 Apr 2012 23:29:08 -0400 (EDT) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id A008921B0E23; Mon, 16 Apr 2012 23:29:08 -0400 (EDT) Received: from IMCMBX03.MITRE.ORG ([169.254.3.179]) by IMCCAS03.MITRE.ORG ([129.83.29.80]) with mapi id 14.02.0283.003; Mon, 16 Apr 2012 23:29:08 -0400 From: "Barnum, Sean D." To: "Omar Santos (osantos)" , Luis Nunez Thread-Topic: [sacm] [mile] CybOX v1.0 (Draft) is now released and live onthe website Thread-Index: AQHNHC91EoahZz2AEEqd+yKyGmroMJaeWIaQ Date: Tue, 17 Apr 2012 03:29:07 +0000 Message-ID: <7F48813B48558A4BB5CB7BB714E5B5A9171B16@IMCMBX03.MITRE.ORG> References: <7F48813B48558A4BB5CB7BB714E5B5A91706E3@IMCMBX03.MITRE.ORG> <870A23D4-BA94-4431-B613-F3D7734B8DB5@c3isecurity.com> <953A2E460DBE7C43AC13E30B87C5B4FF080A1BAD@XMB-RCD-106.cisco.com> In-Reply-To: <953A2E460DBE7C43AC13E30B87C5B4FF080A1BAD@XMB-RCD-106.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [172.31.136.182] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0042_01CD1C28.B47EA280" MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 17 Apr 2012 05:31:10 -0700 Cc: "idxwg@nicwg.org" , "mile@ietf.org" , "dallendoug@gmail.com" , "sacm@ietf.org" , "m-terada@ipa.go.jp" Subject: Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live onthe website X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 03:29:16 -0000 ------=_NextPart_000_0042_01CD1C28.B47EA280 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0043_01CD1C28.B47EA280" ------=_NextPart_001_0043_01CD1C28.B47EA280 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thanks Omar. To answer your question, first let me point out to other readers that the two entries that Omar is quoting here exist as values in an enumeration called EventTypeEnum which as its name implies contains a list of different labels for grouping types (or classes) of events to be used as low-granularity buckets for characterizing and classifying events. Other entries in this enumeration include things like "File Ops (CRUD)", "Process Mgt", "Authorization (ACL)", etc. The "Packet Traffic" value is intended to characterize events dealing with network packet traffic as its name implies. The "Data Flow" value is intended to characterize events dealing with forms of data flow at a higher level of abstraction than just packet traffic. The relationship between these two values could be viewed as "Packet Traffic" being a more detailed form of "Data Flow" just as the values "App Layer Traffic" and "HTTP Layer Traffic", also in this enumeration, could be other levels in this same abstraction stack. The idea behind the varying levels of abstraction is to leave buckets large enough to capture a wide variety of potential event types (e.g. data flow events other than obvious things like packet traffic) but also enable the use of smaller more specific buckets when they are appropriate and commonly used. Does this make sense? sean From: Omar Santos (osantos) [mailto:osantos@cisco.com] Sent: Monday, April 16, 2012 8:17 PM To: Luis Nunez; Barnum, Sean D. Cc: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; m-terada@ipa.go.jp Subject: RE: [sacm] [mile] CybOX v1.0 (Draft) is now released and live onthe website I echo Luis' comments. It is good to see the inclusion of network objects. Quick question to the team related to your netflow comment. I am looking at: http://cybox.mitre.org/XMLSchema/cybox_core_v1.0%28draft%29.xsd . and it looks that we renamed it to "Data Flow"? Specifies the class of events dealing with data flow. What is the difference between that and "Packet Traffic"? Specifies the class of events dealing with packet traffic. Regards, Omar Santos Incident Manager, PSIRT Security Research and Operations Cisco Systems, Inc. Email: os@cisco.com Phone: +1 919 392 8635 PGP Key: 0x3AF27EDC Cisco.com - http://www.cisco.com Cisco Security Advisories and Notices - http://www.cisco.com/go/psirt This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message. For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Luis Nunez Sent: Monday, April 16, 2012 6:44 PM To: Barnum, Sean D. Cc: idxwg@nicwg.org; mile@ietf.org; Doug Wilson (dallendoug@gmail.com); sacm@ietf.org; IPA-Masato Terada (m-terada@ipa.go.jp) Subject: Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live onthe website I like the inclusion of the network-centric objects. IPFIX (netflow) will add an additional perspective from an incident information sharing standpoint. -ln On Apr 16, 2012, at 4:04 PM, Barnum, Sean D. wrote: Hey everyone, I just wanted to let you all know that CybOX v1.0 (Draft) content is now live on the website. http://cybox.mitre.org The release notes are provided inline below. The key items of note are: . The release of two formal specifications for the CybOX language (one for the core language and one for the defined objects) . The XML Schema has gone through extensive improvements for expressiveness, clarity, consistency, efficiency, alignment to existing normative references and documentation. . This release includes an initial set of language utilities: a draft Snort -> CybOX transform, a draft OpenIOC -> CybOX transform, and a set of Python bindings for the CybOX language. . The website now includes a small set of content examples. This set will grow going forward. This release involved a lot of hard work from a diverse group of people. Thank you all for your contributions and effort. We could not have done it without you. We look forward to everyone's feedback and collaboration as we continue to improve and mature the CybOX language. Sean Barnum CybOX v1.0 (Draft) Release Notes The Version 1.0 (Draft) release of Cyber Observable eXpression (CybOXT) is intended as a draft release of an initial major version of the CybOX Language that could be utilized for practical operational use and integration into other standards efforts. This release consists of three primary components: a pair of formal language specifications for the core language content and defined objects content, a set of language implementation XML schemas (core, common_types, and ~70 defined object schemas), and a small initial set of language utilities including an initial draft Snort->CybOX transform, an initial draft OpenIOC->CybOX transform and a set of CybOX language Python bindings. Recognizing that this is the first time that the formal language specifications will be available for review and as such will likely generate feedback from new stakeholders, this initial major version is being released as a "draft" v1.0 with the expectation of cycles of new feedback and revision before a "final" v1.0 is released. The CybOX v1.0 (Draft) XML schemas include a significant number of changes from v0.7 to improve: . Clarity, documentation, and descriptive formality for reference and implementation by other standards and users. . Consistency, simplicity, and efficiency. . Alignment (as appropriate) to existing normative references. . Expressiveness of the schema to better support the broad set of use cases it targets (malware characterization, indicator and incident data sharing, event management, etc.) including the addition of an initial set of network-related defined objects. Summary of changes from CybOX_v0.7 to CybOX_v1.0_(Draft): . Refinement of namespaces and schema locations for better effectiveness and flexibility going forward. . Normalized all content according to an established set of naming conventions. . Fully annotated all language items (types, attributes, elements, etc.). . Moved several commonly leveraged types out of the core schema and into common_types. . Achieved full typing of entire schema structure such that all attributes and elements are definitively typed. . Changed all identifiers from ID and IDREF types to be QNames enabling globally unique identifiers and flexibility for domain-specific users of CybOX to define their own identifier syntax locally. . Reordered attributes and elements in numerous types to better reflect common usage and priority. . Added major_version and minor_version attributes for core schema. . Added capability to characterize source of overall observable package data and for individual observables. . Modified the logical composition structure such that any such compositions are now contained within a Observable_Composition element providing improved simplicity and modularity. . Removed the Delta element from ObservableType and relocated the appropriate portions (Change, Trend, and Frequency) to appropriate locations under Stateful_Measure and Event. . Added a Domain_Specific_Object_Attributes field to Object utilizing an abstract type that will allow domain-specific use cases to add in their own domain-specific attributes for Objects. . Added a Tool-Specific_Data field to ToolInformationType utilizing an abstract type that will allow addition of tool-specific data. . Added an Indicators field to MeasureSourceType utilizing an abstract type that will allow characterizing differing formats or standards of indicators that may have led to the identification of the observable data. . Enhanced the Hash structure to capture full fuzzy hashes in addition to simple hashes . Added a new ExtractedFeaturesType that can be used to adorn differing objects (e.g., files, memory, etc.) to capture extracted strings, imports, functions and code snippets . Added a ByteRunsType to enable capture of byte runs within various objects. . Added object_reference attribute to DefinedObjectType to better support referencing of independently defined Objects from within another Object definition. . Added a generic DataSegmentType to provide a relatively abstract way of characterizing data segments that may be written/read/transmitted or otherwise utilized in actions or defined in objects. . Added several new defined object schemas (API, Code, Device, DNS_Record, Network_Flow, Network_Packet, Network_Route_Entry, Network_Subnet, Unix_Network_Route_Entry) including an initial set of network-centric defined objects. . Modified every defined object schema with added annotations as well as minor and in some cases substantive changes to fix errors, improve consistency and alignment with existing normative references, and to improve expressiveness in support of the targeted use cases. Detailed changes from CybOX_v0.7 to CybOX_v1.0_(Draft): The level of changes within v1.0 (Draft) in the core schema, common_types and the defined object schemas is too great to list every change in these release notes. Detailed difference reports are available for each individual schema at: http://cybox.mitre.org/XMLSchema/release_notes/cybox_v1.0(draft)_diff_report s.zip =============================================== Sean Barnum Cyber Security Principal The MITRE Corporation Email: sbarnum@mitre.org _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile ------=_NextPart_001_0043_01CD1C28.B47EA280 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks Omar.

 

To answer your question, first let me point out to other readers that = the two entries that Omar is quoting here exist as values in an = enumeration called EventTypeEnum which as its name implies contains a = list of different labels for grouping types (or classes) of events to be = used as low-granularity buckets for characterizing and classifying = events.

Other entries in this enumeration include things like “File Ops = (CRUD)”, “Process Mgt”, “Authorization = (ACL)”, etc.

 

The “Packet Traffic” value is intended to characterize = events dealing with network packet traffic as its name = implies.

The “Data Flow” value is intended to characterize events = dealing with forms of data flow at a higher level of abstraction than = just packet traffic. The relationship between these two values could be = viewed as “Packet Traffic” being a more detailed form of = “Data Flow” just as the values “App Layer = Traffic” and “HTTP Layer Traffic”, also in this = enumeration, could be other levels in this same abstraction = stack.

The idea behind the varying levels of abstraction is to leave =  buckets large enough to capture a wide variety of potential event = types (e.g. data flow events other than obvious things like packet = traffic) but also enable the use of smaller more specific buckets when = they are appropriate and commonly used.

 

Does this make sense?

 

sean

 

From:= = Omar Santos (osantos) [mailto:osantos@cisco.com]
Sent: = Monday, April 16, 2012 8:17 PM
To: Luis Nunez; Barnum, Sean = D.
Cc: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; = sacm@ietf.org; m-terada@ipa.go.jp
Subject: RE: [sacm] [mile] = CybOX v1.0 (Draft) is now released and live onthe = website

 

I echo Luis’ comments. It is good to see the inclusion of = network objects. Quick question to the team related to your netflow = comment.

 

I am looking at:

= http://cybox.mitre.org/XMLSchema/cybox_core_v1.0%28draft%29.xsd<= /o:p>

 

… and it looks that we renamed it to “Data = Flow”?

 

<xs:enumeration = value=3D"Data Flow">

   = <xs:annotation>

        = <xs:documentation>Specifies the class of events dealing with data = flow.</xs:documentation>

   = </xs:annotation>

</xs:enumeration>

 

 

What is the difference between that and “Packet = Traffic”?

 

<xs:enumeration value=3D"Packet =
Traffic">
   =
<xs:annotation>
     =
<xs:documentation>Specifies the class of events dealing with =
packet traffic.</xs:documentation>
   =
</xs:annotation>
</xs:enumeration>

 

 

 

 

Regards,

Omar Santos
Incident Manager, = PSIRT
Security Research and Operations
Cisco Systems, = Inc.
Email: os@cisco.com
Phone: +1 919 392 = 8635
PGP Key: 0x3AF27EDC

Cisco.com - http://www.cisco.com
Cisco Security = Advisories and Notices - http://www.cisco.com/go/psirt<= br>
This email may contain confidential and privileged material for = the sole
use of the intended recipient. Any review, use, distribution = or
disclosure by others is strictly prohibited. If you are not the = intended
recipient (or authorized to receive for the recipient), = please contact
the sender by reply email and delete all copies of = this message.

For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html=

 

From:= = sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.= org] On Behalf Of Luis Nunez
Sent: Monday, April = 16, 2012 6:44 PM
To: Barnum, Sean D.
Cc: idxwg@nicwg.org; mile@ietf.org; Doug Wilson (dallendoug@gmail.com); sacm@ietf.org; IPA-Masato Terada (m-terada@ipa.go.jp)
Subject:= Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live onthe = website

 

I like the inclusion of the network-centric = objects.  IPFIX (netflow)  will add an additional perspective = from an incident information sharing standpoint. =  

 

-ln

 

On Apr 16, 2012, at 4:04 = PM, Barnum, Sean D. wrote:

 

Hey = everyone,

 =

I just = wanted to let you all know that CybOX v1.0 (Draft) content is now live = on the website. http://cybox.mitre.org

The = release notes are provided inline = below.

The key = items of note are:

·        The = release of two formal specifications for the CybOX language (one for the = core language and one for the defined = objects)

·        The XML = Schema has gone through extensive improvements for expressiveness, = clarity, consistency, efficiency, alignment to existing normative = references and documentation.

·        This = release includes an initial set of language utilities: a draft Snort = -> CybOX transform, a draft OpenIOC -> CybOX transform, and a set = of Python bindings for the CybOX language.

·        The = website now includes a small set of content examples. This set will grow = going forward.

This = release involved a lot of hard work from a diverse group of people. = Thank you all for your contributions and effort. We could not have done = it without you.

We look = forward to everyone’s feedback and collaboration as we continue to = improve and mature the CybOX = language.

 =

Sean = Barnum

 =

 =

 =

CybOX v1.0 (Draft) Release = Notes

The Version 1.0 (Draft) release of Cyber = Observable eXpression (CybOX™) is intended as a draft release of an initial major version of = the CybOX Language that could be utilized for practical operational use = and integration into other standards efforts. This release consists of = three primary components: a pair of formal language specifications for = the core language content and defined objects content, a set of language = implementation XML schemas (core, common_types, and ~70 defined object = schemas), and a small initial set of language utilities including an = initial draft Snort->CybOX transform, an initial draft = OpenIOC->CybOX transform and a set of CybOX language Python bindings. = Recognizing that this is the first time that the formal language = specifications will be available for review and as such will likely = generate feedback from new stakeholders, this initial major version is = being released as a “draft” v1.0 with the expectation of = cycles of new feedback and revision before a “final” v1.0 is = released.=

The CybOX v1.0 (Draft) XML schemas include a = significant number of changes from v0.7 to improve:=

·       Clarity, = documentation, and descriptive formality for reference and = implementation by other standards and users.=

·       Consistency, = simplicity, and efficiency.=

·       Alignment (as = appropriate) to existing normative references.=

·       Expressiveness of the = schema to better support the broad set of use cases it targets (malware = characterization, indicator and incident data sharing, event management, = etc.) including the addition of an initial set of network-related = defined objects.=

Summary = of changes from CybOX_v0.7 to CybOX_v1.0_(Draft):=

·        = Refinement of namespaces and schema = locations for better effectiveness and flexibility going forward.=

·        = Normalized all content according to an = established set of naming conventions.=

·        = Fully annotated all language items = (types, attributes, elements, etc.).=

·        = Moved several commonly leveraged types = out of the core schema and into common_types.=

·        = Achieved full typing of entire schema = structure such that all attributes and elements are definitively = typed.=

·        = Changed all identifiers from ID and IDREF = types to be QNames enabling globally unique identifiers and flexibility = for domain-specific users of CybOX to define their own identifier syntax = locally.=

·        = Reordered attributes and elements in = numerous types to better reflect common usage and priority.=

·        = Added major_version and minor_version = attributes for core schema.=

·        = Added capability to characterize source = of overall observable package data and for individual observables.=

·        = Modified the logical composition = structure such that any such compositions are now contained within a = Observable_Composition element providing improved simplicity and = modularity.=

·        = Removed the Delta element from = ObservableType and relocated the appropriate portions (Change, Trend, = and Frequency) to appropriate locations under Stateful_Measure and = Event.=

·        = Added a Domain_Specific_Object_Attributes = field to Object utilizing an abstract type that will allow = domain-specific use cases to add in their own domain-specific attributes = for Objects.=

·        = Added a Tool-Specific_Data field to = ToolInformationType utilizing an abstract type that will allow addition = of tool-specific data.=

·        = Added an Indicators field to = MeasureSourceType utilizing an abstract type that will allow = characterizing differing formats or standards of indicators that may = have led to the identification of the observable data.=

·        = Enhanced the Hash structure to capture = full fuzzy hashes in addition to simple hashes=

·        = Added a new ExtractedFeaturesType that = can be used to adorn differing objects (e.g., files, memory, etc.) to = capture extracted strings, imports, functions and code snippets=

·        = Added a ByteRunsType to enable capture of = byte runs within various objects.=

·        = Added object_reference attribute to = DefinedObjectType to better support referencing of independently defined = Objects from within another Object definition.=

·        = Added a generic DataSegmentType to = provide a relatively abstract way of characterizing data segments that = may be written/read/transmitted or otherwise utilized in actions or = defined in objects.=

·        Added several new = defined object schemas (API, Code, Device, DNS_Record, Network_Flow, = Network_Packet, Network_Route_Entry, Network_Subnet, = Unix_Network_Route_Entry) including an initial set of network-centric = defined objects.

·        = Modified every defined object schema with = added annotations as well as minor and in some cases substantive changes = to fix errors, improve consistency and alignment with existing normative = references, and to improve expressiveness in support of the targeted use = cases.=

Detailed changes from CybOX_v0.7 to = CybOX_v1.0_(Draft):=

The level of changes within v1.0 (Draft) in = the core schema, common_types and the defined object schemas is too = great to list every change in these release notes. Detailed difference = reports are available for each individual schema at:http://cybox.mitre.org/XMLSchema/release_notes/cybox_v1.0= (draft)_diff_reports.zip

 =

 =

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

Sean Barnum=

Cyber Security Principal=

The MITRE Corporation=

 =

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

 

------=_NextPart_001_0043_01CD1C28.B47EA280-- ------=_NextPart_000_0042_01CD1C28.B47EA280 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIYNDCCBS0w ggMVoAMCAQICEEw6UhQhT9OgRBVHf7KQ+1AwDQYJKoZIhvcNAQELBQAwKTEnMCUGA1UEAxMeTUlU UkUgQ29ycG9yYXRpb24gUEUgUm9vdCBDQS0xMB4XDTExMDQyNjE5NDU0NVoXDTIxMDQyNjE5NDgy MlowKTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUEUgUm9vdCBDQS0xMIICIjANBgkqhkiG 9w0BAQEFAAOCAg8AMIICCgKCAgEAtp8hR0hRq3im+Alwfb5ZHGP5k2OSY2TlVHYHIMUDH3MfW7b6 8lB3j3MwAMsxGK1ke/t6O4K0t9wRH4QDgOQ1CthmOGZW7xiN81h0vP1Yf14SNugUa7ZvH9KP3iXs y8QnOHal1bKf0Pa9KXib58qUuwfaZSCTW5P2ekqd8z4TETvfBWvPgDxyxnVsiAO6yL9WaRpMiSVM hYLWy3KRuU/gue0bVEi+qdg+hENh1NSNXpoqseS262nq5cx5wybR/PF0YstQ9NNlYDM5cLECKYHH zD6cXKJozuFXriswlE8rdna7VaxyZrfgC0ueEIY/tsj/65IyUhyPBwO0ZpW+Ls9Cd4Y+ERSu5mR5 Fd8w42eVzuosmk3s3AxrKC+Z4tXYkjaiWUduIegAiST1vJBwkS53vR+zrBX3Ep56l7MFVvW/GcsZ 9wUT2HG65JOeiVc2YzCEqLgQ3ZCBHn09oBag2lnMac+E2sKm9aKL3xzHs6cyD8qCJK9O8QLCqo3C mzASlOwtTFiLYgpPW/MSmgYOt9JrwHAzk97DHFKTFttjrXGMmhMVzadt1EjMn1Wv8t5WLBI0qSoX /MYi2CaeiDsEiWRu9Nmpu3pmi8m7tIR9csdbAVPks2soNMWOopGEpFQSDvU1+m77v2jIKQKYxYmN 2zUOJ4TJFL1osnZ/71MmLCDVd+ECAwEAAaNRME8wCwYDVR0PBAQDAgGGMA8GA1UdEwEB/wQFMAMB Af8wHQYDVR0OBBYEFFuHfZ/+bL4C6fPgKTqKVCUsnzgvMBAGCSsGAQQBgjcVAQQDAgEAMA0GCSqG SIb3DQEBCwUAA4ICAQAy78sXsP/eqHH8/uOYyxQ6TBDhkCBxNoy8MF2c9UDns5ADL1qyxPAlpDBs L+2h1Zzt3FvPjg0SoRE/9juyG1qxMzhlv0jdQx12tESdo3uBb61b1uuc4H/VxCJWDI4KZL/B53EI 8HGPjUBdLADgOmG99uffm5uarSkjtIX//Bz3U6QfzTPlVWFi4SmzRI2mp16GQ8RPuJ/WMloaAn8X H6EjS2oLjGZC8Pw8/C46W48NvZ1JZTrZvYZr7GmuvmplYK68SZv/T5Su+FlLRTy9uNXQLHtm6jKv nDH2yB66zTwfaDpnjILnrC2O7ANRVZc0KywiKiW3nB7Joq74/XVuMI1PiSByt2Qu+RIS/WAI5wMi bTmwSiBxQZqvuth+dXoakJyOP2Wg5jvL55v9RLZhDqMtRI5ovnOFvTgNJQqNPSekGtA+m6Ctl/vh kSg65FFCMhaSkn7vY2Il+R8HouWJN8wTaudeexnyHcD+Mlt8QaB5CErpDjeeGZfQ0FcYm+6TtlMz Dw5eFhT/J6QrABCxfgLkVFHurMcQD4JkmXXkq5bP+GNkY0Uy2LMbw/UD94OEV1LpfAqUkT+mu5Yb vxg+elFtsad+Ix8owW372xynIADh9q1bHm+j1OHPJmGALWK9miRpC4t3isfu3ZB0QpI/e2Po6MED 393Jb0YbzrcElFv6ZDCCBhYwggP+oAMCAQICChrDbcgAAgAAN/wwDQYJKoZIhvcNAQEFBQAwUDET MBEGCgmSJomT8ixkARkWA09SRzEVMBMGCgmSJomT8ixkARkWBU1JVFJFMSIwIAYDVQQDExlNSVRS RSBDb3Jwb3JhdGlvbiBQRSBDQS0xMB4XDTEyMDMxMjE1MTgyN1oXDTE1MDMxMjE1MTgyN1owSjEL MAkGA1UEBhMCVVMxDjAMBgNVBAoTBU1JVFJFMQ8wDQYDVQQLEwZQZW9wbGUxGjAYBgNVBAMTEUJh cm51bS5TZWFuLjMxNTQzMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA9/I6RU7OcouL 6lcEJMAg8G3myNbQu84QnflS8p3PWOjgC6P50RDqGX5UxelDqMQPN5IsNYRXVY9/b7yN/RSH4goI JfYKMitndKuCKz1q38Nh0YycEm5x2t/IN/60b01T1uOmhZfptLDoDzj0UQZwMQ19mhM/ldsrC8bR GGuHXdQVaSyXygfhzNhqC06vZo5fvCBUJ6z7JtVrfRTHdudg19JYK+gds9p+Lvp/DOEXQmgpfpMl jfNKMnrG+kPMMngrIJUsF5lcbhHuc5mO+O8eR8FxM2KF7gfKVmUmZxs7Y6uLenVJVEmllP0XgUu1 sv3bClFgUo5x5Aq6rXshtHuVuQIDAQABo4IB9jCCAfIwKAYDVR0lBCEwHwYIKwYBBQUHAwQGCSsG AQQBcwIBBwYIKwYBBQUHAwIwHQYDVR0OBBYEFDvU1Ph/OVxGkxRmwvRx1TBf5PKqMA4GA1UdDwEB /wQEAwIGwDAcBgNVHREEFTATgRFzYmFybnVtQG1pdHJlLm9yZzAfBgNVHSMEGDAWgBRpZyAh1EjB 0BsGbvMIKOI6gn1BMTBJBgNVHR8EQjBAMD6gPKA6hjhodHRwOi8vcGtpLm1pdHJlLm9yZy9NSVRS RSUyMENvcnBvcmF0aW9uJTIwUEUlMjBDQS0xLmNybDB/BggrBgEFBQcBAQRzMHEwRwYIKwYBBQUH MAKGO2h0dHA6Ly9wa2kubWl0cmUub3JnL01JVFJFJTIwQ29ycG9yYXRpb24lMjBQRSUyMENBLTEo MikuY3J0MCYGCCsGAQUFBzABhhpodHRwOi8vb2NzcC5taXRyZS5vcmcvb2NzcDA+BgkrBgEEAYI3 FQcEMTAvBicrBgEEAYI3FQiDrqwjho6WV4GNiT2CpKsShb6uAYE2g9KXfYeg+0kCAWQCAQcwFgYD VR0gBA8wDTALBgkrBgEEAXMCAQgwNAYJKwYBBAGCNxUKBCcwJTAKBggrBgEFBQcDBDALBgkrBgEE AXMCAQcwCgYIKwYBBQUHAwIwDQYJKoZIhvcNAQEFBQADggIBAC2wqKo7QWQxIqnEKRznPrAQ5vQ9 X5JhB5keH8KMWu1W5n1RuSZH+3TYp4xccdYh+rV5b5+cJcWEYhtYpZriWm4kMHPaB6gKO9rbVfF9 R8Wp8sXvCKogbNhdkZwvXW4QymB1ASlMzDI1cCV8mzYgbIhWaCbV1zZBUVgOGa4LZIgdbdmgo5r/ O2gmnSftTYiE/tQ+DBs/25Bw/jC5HOiMXJqr+JctzJTqpEVLa7GKHnXWGuzGEPYkKBplxIyhz3Mv qc/yuKM7tZzAr8Qn5qf7VI9O2xp56QLjT2+mySOUR6Vml860FMpjjgZNMxAqOJt7OgY0PoUU9d18 yw1wiKSt0LUQoMcVvp7FifBjtBCG1sB/VOzxNvcNm6lO6EO23pvcjt6+WCG1X3pgnZ5UEohsM3c0 oLzYiuSYeVf85IO2yh9fWLWw2RGkf2szck1Xg0DsAQ54/YlZYyehELh43KbS3lpnTt8UlO7C0TMT 7JQwz4fTQg1a0e9rRPFnNDUG2fS2k3tz9IYILDB3F8uiZzzXptEzaYqzIqe5CK8ZGJQcw+w/CBen 6i+MV/y7yJmhio43Y1x9hIqoynqoSMV3CKYCoOwCvFUAGsNllDpExsQZoXrdd5gcuglqbh3t8wOM jtXDSQllQ/hXDZJf8rnH0wGx3K+WA+LKNvKqNCw9spEtsfG0MIIGYjCCBEqgAwIBAgIKFJcW0gAA AAAABDANBgkqhkiG9w0BAQsFADApMScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQRSBSb290 IENBLTEwHhcNMTEwNjE0MTc0NDQ0WhcNMTcwNjE0MTc1NDQ0WjBQMRMwEQYKCZImiZPyLGQBGRYD T1JHMRUwEwYKCZImiZPyLGQBGRYFTUlUUkUxIjAgBgNVBAMTGU1JVFJFIENvcnBvcmF0aW9uIFBF IENBLTEwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDSxK9RXieqdTz4JWRkRMs/EOuF 0P0S9SbspadLJkx/LDDnaAwmAnqfqm1n7/p82oVjy1yCye3SZu4Yp7fmDIAtWbkHvYOfxHkRv1ho /fhaNN0YRkd65oJJz2ngEbNZxdIiCoialQfX/iWU7ApQ+ovKbFV60v5E0p2mPncs20NYRfsaetdh nBZbFD9flDcXwJqSvGGGBfm7ifFCR1LrtEcNKjMwf7YEWZO0Vk3ZyhVq+k7JNLEbKv0OfBz8DU8G iGU+j88QlrgGW8PLkwNk7nsS/DJp8aLudTuVqIE2CA9mqn5QjU/EZYNHGzSfCr+/usUmbojyVSJu khhrAXspRAMz+Cia3yi3q3w8TnAljXWN1dhx1iuUv5GxyzMjfqK1tMuCUU2XzGNNqoVa1mqolBiy DTCOr9d/IC0YHYMBSpQ+xi0x9zjXKt4FmQmkEAZgF4hsZZqcJYL/iCQiwiz8fEyVPZuvoWvdEXOo zFYCpmkT0MZCJwyIux0Z6vJp6VLtN/6rZgc2y54HlTrp3ifazmpsfrk3NdHxlZTZug9kjEI+vEoy p/79nAPyTWQQ1MEP0ErCWav80/HOi0MLx/7lIUfvVOjkOFgFb+iDvR4T3RAQrnEpgTO+fc7Jyzh9 LpFDqm0slwDP4Hj9cC3IzdED5BU43PGAe+HoZ8OD/1ovVgwo/wIDAQABo4IBYzCCAV8wEAYJKwYB BAGCNxUBBAMCAQIwIwYJKwYBBAGCNxUCBBYEFFCiOtgZb+Zdflkw5sC2y01sUQaVMB0GA1UdDgQW BBRpZyAh1EjB0BsGbvMIKOI6gn1BMTAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTALBgNVHQ8E BAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAfBgNVHSMEGDAWgBRbh32f/my+Aunz4Ck6ilQlLJ84LzBQ BgNVHR8ESTBHMEWgQ6BBhj9odHRwOi8vcGtpLm1pdHJlLm9yZy9NSVRSRSUyMENvcnBvcmF0aW9u JTIwUEUlMjBSb290JTIwQ0EtMS5jcmwwWwYIKwYBBQUHAQEETzBNMEsGCCsGAQUFBzAChj9odHRw Oi8vcGtpLm1pdHJlLm9yZy9NSVRSRSUyMENvcnBvcmF0aW9uJTIwUEUlMjBSb290JTIwQ0EtMS5j cnQwDQYJKoZIhvcNAQELBQADggIBAHnDPfdYKxqNOtAYXMyyel83Vs8cCDAQZhSuIB0c6GkGoEdF rmWH9pwi42V96rCp7TvbNNKNJXbVHfJUAp+uqw663DL/sXXff9ZFxPxKOdPnpA8cKM7RBH9e437N w3d28A7PaGbP6tXmSqhXAhYZ4U12y1U5cOf2G/phUoAAMlnVJdfmXzMazvLo2SIeixAJyCze6rHQ TFQ/N+gAjbVuRJ+Hs8FEKVzMSwqlNoupe2ELqL4dMAKT6P08sAfxm2SrRlQvcWPYvqM/1C10bgc2 tdu+WGzRuP5Wx9Yr15KO9SW4z7fn2RVEXQgoDDno5vCIcfUPuKB5n+Kt9eBCitsgSD9yYsNUN9LE VIvjAb8MV2LWLfge1bumo6g7QMRa4Fgifw5siGwi7V2EaJQo6UAIVvxKKFC7W4p6CkrY2ga1d7GI Q0DPiWZOezOakJVAxL5gf+3WdNt0igKc/yLfbdHn6hCd1KPgDqkSKr8zWOZI/jiDBW957xAmaO6Q dGQDBZrQHWpIVwQGzF5bGrqms2kq49l3t7KmBu0C/9tExqKAmlf4Y5lfQGdCbKQpAq712DVQHYuD XmVQEAc2vlJ1C5hS3Iw9DwBWTfJ4vyB48buhBhbIhPiFta5OizXlKcsIi99ikA1yiZx/DBtjaw4J U6qJzWUFB2ecyGCNPtNbYjURA0A9MIIGfzCCBGegAwIBAgIKGsNq2wACAAA3+jANBgkqhkiG9w0B AQUFADBQMRMwEQYKCZImiZPyLGQBGRYDT1JHMRUwEwYKCZImiZPyLGQBGRYFTUlUUkUxIjAgBgNV BAMTGU1JVFJFIENvcnBvcmF0aW9uIFBFIENBLTEwHhcNMTIwMzEyMTUxODI3WhcNMTUwMzEyMTUx ODI3WjBKMQswCQYDVQQGEwJVUzEOMAwGA1UEChMFTUlUUkUxDzANBgNVBAsTBlBlb3BsZTEaMBgG A1UEAxMRQmFybnVtLlNlYW4uMzE1NDMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCW InZvCSslmSfSyhTVVSqnokCDajlsCNZHfUlkwkV1++2O71BYvMpjFHWR2XFIx963Hl63lFZzzVci OjIwLb1c/0YXhFfUdAvrbpjlu+ttlO05OEUW0h+5HO+qaebJPamxA00w0bokquRcPxUvwa3jiyL0 WfCwE3+/b5PCOW2xh7FXFKv262FnKIwxnQGXqkiXRP5D/SmdtcZSzxHkDThrhaiHPhJJhZ4XxwBk aGcAlMg8YH6uxshXm8e6c7XUu7gB5p+XThS0dqXujpQp/UQDp5t079+UrDcrpjfDBXIt9qCzLn26 uV5a4cD4xRKwA32f1cXFtiKXM0wYgUM3fEPDAgMBAAGjggJfMIICWzATBgNVHSUEDDAKBggrBgEF BQcDBDCBlAYJKoZIhvcNAQkPBIGGMIGDMA4GCCqGSIb3DQMCAgIAgDAOBggqhkiG9w0DBAICAIAw BwYFKw4DAgcwCgYIKoZIhvcNAwcwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBLTALBglghkgBZQME ARYwCwYJYIZIAWUDBAEZMAsGCWCGSAFlAwQBAjALBglghkgBZQMEAQUwHQYDVR0OBBYEFIrbKa+E Rxo2/Sth2C6jZqZqvRE7MA4GA1UdDwEB/wQEAwIFIDAcBgNVHREEFTATgRFzYmFybnVtQG1pdHJl Lm9yZzAfBgNVHSMEGDAWgBRpZyAh1EjB0BsGbvMIKOI6gn1BMTBJBgNVHR8EQjBAMD6gPKA6hjho dHRwOi8vcGtpLm1pdHJlLm9yZy9NSVRSRSUyMENvcnBvcmF0aW9uJTIwUEUlMjBDQS0xLmNybDB/ BggrBgEFBQcBAQRzMHEwRwYIKwYBBQUHMAKGO2h0dHA6Ly9wa2kubWl0cmUub3JnL01JVFJFJTIw Q29ycG9yYXRpb24lMjBQRSUyMENBLTEoMikuY3J0MCYGCCsGAQUFBzABhhpodHRwOi8vb2NzcC5t aXRyZS5vcmcvb2NzcDA+BgkrBgEEAYI3FQcEMTAvBicrBgEEAYI3FQiDrqwjho6WV4GNiT2CpKsS hb6uAYE2hquSaISo7EUCAWQCAQ8wFgYDVR0gBA8wDTALBgkrBgEEAXMCAQgwGwYJKwYBBAGCNxUK BA4wDDAKBggrBgEFBQcDBDANBgkqhkiG9w0BAQUFAAOCAgEAGmmL43yA+J5lEockM1cxSoyxfSES HUGLVJyrhObbdFD4yO3jf0R4lHLuJlhp1486d9LRZAyzAnl9q8Zf3Tx1rl1kEd3pw0wMuO+ATscc rArEW/rJxjz6zTrNO3PFkFuOEdmKpHaRiFpuSX602INiBEBPluei3uZlWxHW9VqC7hz2diQpOlzS jtPMbL3o7ACjWaq7sQ0xB4rZ6oWyqOZEfHWQA1b7nFgL4nEbmEHNdU4jAjcxkROku4O04205kb5n Loveoz3TSQNt8zalFayZAjt+JEcKuG1f5cyhYI6QwvkS/3M+CjJezuNaSmno29Lm+ToZnwUm4nIB YkBx4r9ZDU2W8029tr5og00A5MGo1LK+unWtHBa7zuPblfSiYgXIHWU+OKrSFaA935Yb4fLXFe9S BmApBr1gohHYos1hct5q90WPufSKIQ9WT+vJYXvW3FpseO4ZLKVnJsO7gVoQEEnWJUwyABBPQrii F0gh++ApKZJROTuR36PsEEx4duI6U4VXMCiIcnEjvNR8Mt5Q/Vp4W4Mp5fCv+QzYkqq9EWD7QuUW Yul6R8Hf7ZTxbUk0NfJgu8escLrgQSwMdP/kE/09vJAAslQBkNnIS7iIhWt4l5XQJBrJc+6popRE R8ykWf25e4CliaUgbAl1tBQKivQ3tlX99WykI2XK3sTk9nsxggMjMIIDHwIBATBeMFAxEzARBgoJ kiaJk/IsZAEZFgNPUkcxFTATBgoJkiaJk/IsZAEZFgVNSVRSRTEiMCAGA1UEAxMZTUlUUkUgQ29y cG9yYXRpb24gUEUgQ0EtMQIKGsNtyAACAAA3/DAJBgUrDgMCGgUAoIIBmjAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjA0MTcwMzI5MDFaMCMGCSqGSIb3DQEJBDEW BBRIEWxaq8SsiK51pgSGmMtoDmdlFDBbBgkqhkiG9w0BCQ8xTjBMMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMC GjBtBgkrBgEEAYI3EAQxYDBeMFAxEzARBgoJkiaJk/IsZAEZFgNPUkcxFTATBgoJkiaJk/IsZAEZ FgVNSVRSRTEiMCAGA1UEAxMZTUlUUkUgQ29ycG9yYXRpb24gUEUgQ0EtMQIKGsNq2wACAAA3+jBv BgsqhkiG9w0BCRACCzFgoF4wUDETMBEGCgmSJomT8ixkARkWA09SRzEVMBMGCgmSJomT8ixkARkW BU1JVFJFMSIwIAYDVQQDExlNSVRSRSBDb3Jwb3JhdGlvbiBQRSBDQS0xAgoaw2rbAAIAADf6MA0G CSqGSIb3DQEBAQUABIIBAM0n/4kGaa/qg7LhY4bjMLmA0s4gxQF622KO3ag4dA6D8NtdImIK+jz6 JqjS3rR+Uu6dO4ZxLhKYJEbHPDDQMAjDHb0ZxrmbDblDxNj7kVEhX9R9aHCFo60AiTiPSxRF0Qdk uBc/QAPZu42LJsay18/areDOCeVu56t+1unqgQqsyBQOTIy4JdqbkYnW8MtcDtDbAJEOb23tbJAb mkcT/+5R5M/I+9f6mhxglIZBnADkwhpl7TzAC8e6stfZoIhL9Q0gjmaW9fpzyxEXqs/dPDioiHG9 NfXOTif6p//AfIkCXZ+spc5AJK1DCU/8eiun2RWORuU3aJq8lDzkxeyLtcsAAAAAAAA= ------=_NextPart_000_0042_01CD1C28.B47EA280-- From Thomas.Millar@hq.dhs.gov Mon Apr 16 20:46:37 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBC1B11E808E; Mon, 16 Apr 2012 20:46:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.098 X-Spam-Level: X-Spam-Status: No, score=-6.098 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BAD_LINEBREAK=0.5, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5S06UEq75xbz; Mon, 16 Apr 2012 20:46:31 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe003.messaging.microsoft.com [65.55.88.13]) by ietfa.amsl.com (Postfix) with ESMTP id 220C611E8081; Mon, 16 Apr 2012 20:46:30 -0700 (PDT) Received: from mail132-tx2-R.bigfish.com (10.9.14.239) by TX2EHSOBE005.bigfish.com (10.9.40.25) with Microsoft SMTP Server id 14.1.225.23; Tue, 17 Apr 2012 03:46:30 +0000 Received: from mail132-tx2 (localhost [127.0.0.1]) by mail132-tx2-R.bigfish.com (Postfix) with ESMTP id 202974C0253; Tue, 17 Apr 2012 03:46:30 +0000 (UTC) X-SpamScore: -36 X-BigFish: VPS-36(zz9371Ic89bh1431Je2eM14ffIc857h98dK62a3Izz1202hzzd0f34h1033IL8275bhf14K8275dhz2dh2a8h668h839hd25h) X-Forefront-Antispam-Report: CIP:216.81.89.167; KIP:(null); UIP:(null); IPV:NLI; H:D1IBLPRHQ102.dhs.gov; RD:none; EFVD:NLI Received: from mail132-tx2 (localhost.localdomain [127.0.0.1]) by mail132-tx2 (MessageSwitch) id 1334634385982389_7472; Tue, 17 Apr 2012 03:46:25 +0000 (UTC) Received: from TX2EHSMHS043.bigfish.com (unknown [10.9.14.245]) by mail132-tx2.bigfish.com (Postfix) with ESMTP id E759230005F; Tue, 17 Apr 2012 03:46:25 +0000 (UTC) Received: from D1IBLPRHQ102.dhs.gov (216.81.89.167) by TX2EHSMHS043.bigfish.com (10.9.99.143) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 17 Apr 2012 03:46:25 +0000 Received: from D1IBLPRHQ107.dhs.gov (192.168.49.137) by D1IBLPRHQ102.dhs.gov (10.84.128.101) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 16 Apr 2012 23:48:07 -0400 Received: from D1ABLPRHQ101.DSA.DHS (10.16.146.31) by D1IBLPRHQ107.dhs.gov (10.84.132.102) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 16 Apr 2012 23:50:44 -0400 Received: from ZAS1UG-0360.DHSNET.DS1.DHS (10.79.65.245) by D1ABLPRHQ101.DSA.DHS (10.16.146.31) with Microsoft SMTP Server id 14.1.355.2; Mon, 16 Apr 2012 23:46:22 -0400 Received: from ZAU1UG-0308.DHSNET.DS1.DHS ([10.79.65.209]) by ZAS1UG-0360.DHSNET.DS1.DHS with Microsoft SMTPSVC(6.0.3790.4675); Mon, 16 Apr 2012 23:46:19 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD1C4C.A5E487EB" Date: Mon, 16 Apr 2012 23:46:18 -0400 Message-ID: <69CE2DCD9DAC3D48B830E0723141170B02A39BD2@ZAU1UG-0308.DHSNET.DS1.DHS> In-Reply-To: <7F48813B48558A4BB5CB7BB714E5B5A9171B16@IMCMBX03.MITRE.ORG> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sacm] [mile] CybOX v1.0 (Draft) is now released and live onthe website Thread-Index: AQHNHC91EoahZz2AEEqd+yKyGmroMJaeWIaQgAAIZb8= From: "Millar, Thomas" To: , , X-OriginalArrivalTime: 17 Apr 2012 03:46:19.0393 (UTC) FILETIME=[A621AF10:01CD1C4C] X-OriginatorOrg: hq.dhs.gov X-Mailman-Approved-At: Tue, 17 Apr 2012 05:31:10 -0700 Cc: idxwg@nicwg.org, mile@ietf.org, dallendoug@gmail.com, sacm@ietf.org, m-terada@ipa.go.jp Subject: Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live onthe website X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 03:53:23 -0000 ------_=_NextPart_001_01CD1C4C.A5E487EB Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SWYgImRhdGEgZmxvdyIgaXMgYSBldXBoZW1pc20gZm9yICJuZXRmbG93IiBpcyB0aGVyZSBhbnkg cmVhc29uIG5vdCB0byBjYWxsIGl0IHRoYXQ/DQoNClRvbSBNaWxsYXIgDQpodHRwOi8vd3d3LnVz LWNlcnQuZ292LyANCi0tLS0tLS0tLS0tLS0tLS0tLSANCk1pc3NpdCBtZSBSdWJ1cyBmcnV0aWNv c3VzOiANCjIwMiA2MzEgMTkxNSANCg0KIA0KDQpGcm9tOiBCYXJudW0sIFNlYW4gRC4gW21haWx0 bzpzYmFybnVtQG1pdHJlLm9yZ10gDQpTZW50OiBNb25kYXksIEFwcmlsIDE2LCAyMDEyIDExOjI5 IFBNDQpUbzogT21hciBTYW50b3MgKG9zYW50b3MpIDxvc2FudG9zQGNpc2NvLmNvbT47IEx1aXMg TnVuZXogPGxudW5lekBjM2lzZWN1cml0eS5jb20+IA0KQ2M6IGlkeHdnQG5pY3dnLm9yZyA8aWR4 d2dAbmljd2cub3JnPjsgbWlsZUBpZXRmLm9yZyA8bWlsZUBpZXRmLm9yZz47IGRhbGxlbmRvdWdA Z21haWwuY29tIDxkYWxsZW5kb3VnQGdtYWlsLmNvbT47IHNhY21AaWV0Zi5vcmcgPHNhY21AaWV0 Zi5vcmc+OyBtLXRlcmFkYUBpcGEuZ28uanAgPG0tdGVyYWRhQGlwYS5nby5qcD4gDQpTdWJqZWN0 OiBSZTogW3NhY21dIFttaWxlXSBDeWJPWCB2MS4wIChEcmFmdCkgaXMgbm93IHJlbGVhc2VkIGFu ZCBsaXZlIG9udGhlIHdlYnNpdGUgDQogDQoNCg0KVGhhbmtzIE9tYXIuDQoNCiANCg0KVG8gYW5z d2VyIHlvdXIgcXVlc3Rpb24sIGZpcnN0IGxldCBtZSBwb2ludCBvdXQgdG8gb3RoZXIgcmVhZGVy cyB0aGF0IHRoZSB0d28gZW50cmllcyB0aGF0IE9tYXIgaXMgcXVvdGluZyBoZXJlIGV4aXN0IGFz IHZhbHVlcyBpbiBhbiBlbnVtZXJhdGlvbiBjYWxsZWQgRXZlbnRUeXBlRW51bSB3aGljaCBhcyBp dHMgbmFtZSBpbXBsaWVzIGNvbnRhaW5zIGEgbGlzdCBvZiBkaWZmZXJlbnQgbGFiZWxzIGZvciBn cm91cGluZyB0eXBlcyAob3IgY2xhc3Nlcykgb2YgZXZlbnRzIHRvIGJlIHVzZWQgYXMgbG93LWdy YW51bGFyaXR5IGJ1Y2tldHMgZm9yIGNoYXJhY3Rlcml6aW5nIGFuZCBjbGFzc2lmeWluZyBldmVu dHMuDQoNCk90aGVyIGVudHJpZXMgaW4gdGhpcyBlbnVtZXJhdGlvbiBpbmNsdWRlIHRoaW5ncyBs aWtlIOKAnEZpbGUgT3BzIChDUlVEKeKAnSwg4oCcUHJvY2VzcyBNZ3TigJ0sIOKAnEF1dGhvcml6 YXRpb24gKEFDTCnigJ0sIGV0Yy4NCg0KIA0KDQpUaGUg4oCcUGFja2V0IFRyYWZmaWPigJ0gdmFs dWUgaXMgaW50ZW5kZWQgdG8gY2hhcmFjdGVyaXplIGV2ZW50cyBkZWFsaW5nIHdpdGggbmV0d29y ayBwYWNrZXQgdHJhZmZpYyBhcyBpdHMgbmFtZSBpbXBsaWVzLg0KDQpUaGUg4oCcRGF0YSBGbG93 4oCdIHZhbHVlIGlzIGludGVuZGVkIHRvIGNoYXJhY3Rlcml6ZSBldmVudHMgZGVhbGluZyB3aXRo IGZvcm1zIG9mIGRhdGEgZmxvdyBhdCBhIGhpZ2hlciBsZXZlbCBvZiBhYnN0cmFjdGlvbiB0aGFu IGp1c3QgcGFja2V0IHRyYWZmaWMuIFRoZSByZWxhdGlvbnNoaXAgYmV0d2VlbiB0aGVzZSB0d28g dmFsdWVzIGNvdWxkIGJlIHZpZXdlZCBhcyDigJxQYWNrZXQgVHJhZmZpY+KAnSBiZWluZyBhIG1v cmUgZGV0YWlsZWQgZm9ybSBvZiDigJxEYXRhIEZsb3figJ0ganVzdCBhcyB0aGUgdmFsdWVzIOKA nEFwcCBMYXllciBUcmFmZmlj4oCdIGFuZCDigJxIVFRQIExheWVyIFRyYWZmaWPigJ0sIGFsc28g aW4gdGhpcyBlbnVtZXJhdGlvbiwgY291bGQgYmUgb3RoZXIgbGV2ZWxzIGluIHRoaXMgc2FtZSBh YnN0cmFjdGlvbiBzdGFjay4NCg0KVGhlIGlkZWEgYmVoaW5kIHRoZSB2YXJ5aW5nIGxldmVscyBv ZiBhYnN0cmFjdGlvbiBpcyB0byBsZWF2ZSAgYnVja2V0cyBsYXJnZSBlbm91Z2ggdG8gY2FwdHVy ZSBhIHdpZGUgdmFyaWV0eSBvZiBwb3RlbnRpYWwgZXZlbnQgdHlwZXMgKGUuZy4gZGF0YSBmbG93 IGV2ZW50cyBvdGhlciB0aGFuIG9idmlvdXMgdGhpbmdzIGxpa2UgcGFja2V0IHRyYWZmaWMpIGJ1 dCBhbHNvIGVuYWJsZSB0aGUgdXNlIG9mIHNtYWxsZXIgbW9yZSBzcGVjaWZpYyBidWNrZXRzIHdo ZW4gdGhleSBhcmUgYXBwcm9wcmlhdGUgYW5kIGNvbW1vbmx5IHVzZWQuDQoNCiANCg0KRG9lcyB0 aGlzIG1ha2Ugc2Vuc2U/IA0KDQogDQoNCnNlYW4NCg0KIA0KDQpGcm9tOiBPbWFyIFNhbnRvcyAo b3NhbnRvcykgW21haWx0bzpvc2FudG9zQGNpc2NvLmNvbV0gDQpTZW50OiBNb25kYXksIEFwcmls IDE2LCAyMDEyIDg6MTcgUE0NClRvOiBMdWlzIE51bmV6OyBCYXJudW0sIFNlYW4gRC4NCkNjOiBp ZHh3Z0BuaWN3Zy5vcmc7IG1pbGVAaWV0Zi5vcmc7IGRhbGxlbmRvdWdAZ21haWwuY29tOyBzYWNt QGlldGYub3JnOyBtLXRlcmFkYUBpcGEuZ28uanANClN1YmplY3Q6IFJFOiBbc2FjbV0gW21pbGVd IEN5Yk9YIHYxLjAgKERyYWZ0KSBpcyBub3cgcmVsZWFzZWQgYW5kIGxpdmUgb250aGUgd2Vic2l0 ZQ0KDQogDQoNCkkgZWNobyBMdWlz4oCZIGNvbW1lbnRzLiBJdCBpcyBnb29kIHRvIHNlZSB0aGUg aW5jbHVzaW9uIG9mIG5ldHdvcmsgb2JqZWN0cy4gUXVpY2sgcXVlc3Rpb24gdG8gdGhlIHRlYW0g cmVsYXRlZCB0byB5b3VyIG5ldGZsb3cgY29tbWVudC4NCg0KIA0KDQpJIGFtIGxvb2tpbmcgYXQ6 DQoNCmh0dHA6Ly9jeWJveC5taXRyZS5vcmcvWE1MU2NoZW1hL2N5Ym94X2NvcmVfdjEuMCUyOGRy YWZ0JTI5LnhzZA0KDQogDQoNCuKApiBhbmQgaXQgbG9va3MgdGhhdCB3ZSByZW5hbWVkIGl0IHRv IOKAnERhdGEgRmxvd+KAnT8NCg0KIA0KDQo8eHM6ZW51bWVyYXRpb24gdmFsdWU9IkRhdGEgRmxv dyI+DQoNCiAgIDx4czphbm5vdGF0aW9uPg0KDQogICAgICAgIDx4czpkb2N1bWVudGF0aW9uPlNw ZWNpZmllcyB0aGUgY2xhc3Mgb2YgZXZlbnRzIGRlYWxpbmcgd2l0aCBkYXRhIGZsb3cuPC94czpk b2N1bWVudGF0aW9uPg0KDQogICA8L3hzOmFubm90YXRpb24+DQoNCjwveHM6ZW51bWVyYXRpb24+ DQoNCiANCg0KIA0KDQpXaGF0IGlzIHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gdGhhdCBhbmQg4oCc UGFja2V0IFRyYWZmaWPigJ0/DQoNCiANCg0KPHhzOmVudW1lcmF0aW9uIHZhbHVlPSJQYWNrZXQg VHJhZmZpYyI+DQogICA8eHM6YW5ub3RhdGlvbj4NCiAgICAgPHhzOmRvY3VtZW50YXRpb24+U3Bl Y2lmaWVzIHRoZSBjbGFzcyBvZiBldmVudHMgZGVhbGluZyB3aXRoIHBhY2tldCB0cmFmZmljLjwv eHM6ZG9jdW1lbnRhdGlvbj4NCiAgIDwveHM6YW5ub3RhdGlvbj4NCjwveHM6ZW51bWVyYXRpb24+ DQoNCiANCg0KIA0KDQogDQoNCiANCg0KUmVnYXJkcywNCg0KT21hciBTYW50b3MNCkluY2lkZW50 IE1hbmFnZXIsIFBTSVJUDQpTZWN1cml0eSBSZXNlYXJjaCBhbmQgT3BlcmF0aW9ucw0KQ2lzY28g U3lzdGVtcywgSW5jLg0KRW1haWw6IG9zQGNpc2NvLmNvbQ0KUGhvbmU6ICsxIDkxOSAzOTIgODYz NQ0KUEdQIEtleTogMHgzQUYyN0VEQw0KDQpDaXNjby5jb20gLSBodHRwOi8vd3d3LmNpc2NvLmNv bQ0KQ2lzY28gU2VjdXJpdHkgQWR2aXNvcmllcyBhbmQgTm90aWNlcyAtIGh0dHA6Ly93d3cuY2lz Y28uY29tL2dvL3BzaXJ0DQoNClRoaXMgZW1haWwgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFu ZCBwcml2aWxlZ2VkIG1hdGVyaWFsIGZvciB0aGUgc29sZQ0KdXNlIG9mIHRoZSBpbnRlbmRlZCBy ZWNpcGllbnQuIEFueSByZXZpZXcsIHVzZSwgZGlzdHJpYnV0aW9uIG9yDQpkaXNjbG9zdXJlIGJ5 IG90aGVycyBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5k ZWQNCnJlY2lwaWVudCAob3IgYXV0aG9yaXplZCB0byByZWNlaXZlIGZvciB0aGUgcmVjaXBpZW50 KSwgcGxlYXNlIGNvbnRhY3QNCnRoZSBzZW5kZXIgYnkgcmVwbHkgZW1haWwgYW5kIGRlbGV0ZSBh bGwgY29waWVzIG9mIHRoaXMgbWVzc2FnZS4NCg0KRm9yIGNvcnBvcmF0ZSBsZWdhbCBpbmZvcm1h dGlvbiBnbyB0bzoNCmh0dHA6Ly93d3cuY2lzY28uY29tL3dlYi9hYm91dC9kb2luZ19idXNpbmVz cy9sZWdhbC9jcmkvaW5kZXguaHRtbA0KDQogDQoNCkZyb206IHNhY20tYm91bmNlc0BpZXRmLm9y ZyBbbWFpbHRvOnNhY20tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEx1aXMgTnVuZXoN ClNlbnQ6IE1vbmRheSwgQXByaWwgMTYsIDIwMTIgNjo0NCBQTQ0KVG86IEJhcm51bSwgU2VhbiBE Lg0KQ2M6IGlkeHdnQG5pY3dnLm9yZzsgbWlsZUBpZXRmLm9yZzsgRG91ZyBXaWxzb24gKGRhbGxl bmRvdWdAZ21haWwuY29tKTsgc2FjbUBpZXRmLm9yZzsgSVBBLU1hc2F0byBUZXJhZGEgKG0tdGVy YWRhQGlwYS5nby5qcCkNClN1YmplY3Q6IFJlOiBbc2FjbV0gW21pbGVdIEN5Yk9YIHYxLjAgKERy YWZ0KSBpcyBub3cgcmVsZWFzZWQgYW5kIGxpdmUgb250aGUgd2Vic2l0ZQ0KDQogDQoNCkkgbGlr ZSB0aGUgaW5jbHVzaW9uIG9mIHRoZSBuZXR3b3JrLWNlbnRyaWMgb2JqZWN0cy4gIElQRklYIChu ZXRmbG93KSAgd2lsbCBhZGQgYW4gYWRkaXRpb25hbCBwZXJzcGVjdGl2ZSBmcm9tIGFuIGluY2lk ZW50IGluZm9ybWF0aW9uIHNoYXJpbmcgc3RhbmRwb2ludC4gIA0KDQogDQoNCi1sbg0KDQogDQoN Ck9uIEFwciAxNiwgMjAxMiwgYXQgNDowNCBQTSwgQmFybnVtLCBTZWFuIEQuIHdyb3RlOg0KDQog DQoNCkhleSBldmVyeW9uZSwNCg0KIA0KDQpJIGp1c3Qgd2FudGVkIHRvIGxldCB5b3UgYWxsIGtu b3cgdGhhdCBDeWJPWCB2MS4wIChEcmFmdCkgY29udGVudCBpcyBub3cgbGl2ZSBvbiB0aGUgd2Vi c2l0ZS4gaHR0cDovL2N5Ym94Lm1pdHJlLm9yZw0KDQpUaGUgcmVsZWFzZSBub3RlcyBhcmUgcHJv dmlkZWQgaW5saW5lIGJlbG93Lg0KDQpUaGUga2V5IGl0ZW1zIG9mIG5vdGUgYXJlOg0KDQrCtyAg ICAgICAgVGhlIHJlbGVhc2Ugb2YgdHdvIGZvcm1hbCBzcGVjaWZpY2F0aW9ucyBmb3IgdGhlIEN5 Yk9YIGxhbmd1YWdlIChvbmUgZm9yIHRoZSBjb3JlIGxhbmd1YWdlIGFuZCBvbmUgZm9yIHRoZSBk ZWZpbmVkIG9iamVjdHMpDQoNCsK3ICAgICAgICBUaGUgWE1MIFNjaGVtYSBoYXMgZ29uZSB0aHJv dWdoIGV4dGVuc2l2ZSBpbXByb3ZlbWVudHMgZm9yIGV4cHJlc3NpdmVuZXNzLCBjbGFyaXR5LCBj b25zaXN0ZW5jeSwgZWZmaWNpZW5jeSwgYWxpZ25tZW50IHRvIGV4aXN0aW5nIG5vcm1hdGl2ZSBy ZWZlcmVuY2VzIGFuZCBkb2N1bWVudGF0aW9uLg0KDQrCtyAgICAgICAgVGhpcyByZWxlYXNlIGlu Y2x1ZGVzIGFuIGluaXRpYWwgc2V0IG9mIGxhbmd1YWdlIHV0aWxpdGllczogYSBkcmFmdCBTbm9y dCAtPiBDeWJPWCB0cmFuc2Zvcm0sIGEgZHJhZnQgT3BlbklPQyAtPiBDeWJPWCB0cmFuc2Zvcm0s IGFuZCBhIHNldCBvZiBQeXRob24gYmluZGluZ3MgZm9yIHRoZSBDeWJPWCBsYW5ndWFnZS4NCg0K wrcgICAgICAgIFRoZSB3ZWJzaXRlIG5vdyBpbmNsdWRlcyBhIHNtYWxsIHNldCBvZiBjb250ZW50 IGV4YW1wbGVzLiBUaGlzIHNldCB3aWxsIGdyb3cgZ29pbmcgZm9yd2FyZC4NCg0KVGhpcyByZWxl YXNlIGludm9sdmVkIGEgbG90IG9mIGhhcmQgd29yayBmcm9tIGEgZGl2ZXJzZSBncm91cCBvZiBw ZW9wbGUuIFRoYW5rIHlvdSBhbGwgZm9yIHlvdXIgY29udHJpYnV0aW9ucyBhbmQgZWZmb3J0LiBX ZSBjb3VsZCBub3QgaGF2ZSBkb25lIGl0IHdpdGhvdXQgeW91Lg0KDQpXZSBsb29rIGZvcndhcmQg dG8gZXZlcnlvbmXigJlzIGZlZWRiYWNrIGFuZCBjb2xsYWJvcmF0aW9uIGFzIHdlIGNvbnRpbnVl IHRvIGltcHJvdmUgYW5kIG1hdHVyZSB0aGUgQ3liT1ggbGFuZ3VhZ2UuDQoNCiANCg0KU2VhbiBC YXJudW0NCg0KIA0KDQogDQoNCiANCg0KQ3liT1ggdjEuMCAoRHJhZnQpIFJlbGVhc2UgTm90ZXMN Cg0KVGhlIFZlcnNpb24gMS4wIChEcmFmdCkgcmVsZWFzZSBvZiBDeWJlciBPYnNlcnZhYmxlIGVY cHJlc3Npb24gKEN5Yk9Y4oSiKSBpcyBpbnRlbmRlZCBhcyBhIGRyYWZ0IHJlbGVhc2Ugb2YgYW4g aW5pdGlhbCBtYWpvciB2ZXJzaW9uIG9mIHRoZSBDeWJPWCBMYW5ndWFnZSB0aGF0IGNvdWxkIGJl IHV0aWxpemVkIGZvciBwcmFjdGljYWwgb3BlcmF0aW9uYWwgdXNlIGFuZCBpbnRlZ3JhdGlvbiBp bnRvIG90aGVyIHN0YW5kYXJkcyBlZmZvcnRzLiBUaGlzIHJlbGVhc2UgY29uc2lzdHMgb2YgdGhy ZWUgcHJpbWFyeSBjb21wb25lbnRzOiBhIHBhaXIgb2YgZm9ybWFsIGxhbmd1YWdlIHNwZWNpZmlj YXRpb25zIGZvciB0aGUgY29yZSBsYW5ndWFnZSBjb250ZW50IGFuZCBkZWZpbmVkIG9iamVjdHMg Y29udGVudCwgYSBzZXQgb2YgbGFuZ3VhZ2UgaW1wbGVtZW50YXRpb24gWE1MIHNjaGVtYXMgKGNv cmUsIGNvbW1vbl90eXBlcywgYW5kIH43MCBkZWZpbmVkIG9iamVjdCBzY2hlbWFzKSwgYW5kIGEg c21hbGwgaW5pdGlhbCBzZXQgb2YgbGFuZ3VhZ2UgdXRpbGl0aWVzIGluY2x1ZGluZyBhbiBpbml0 aWFsIGRyYWZ0IFNub3J0LT5DeWJPWCB0cmFuc2Zvcm0sIGFuIGluaXRpYWwgZHJhZnQgT3BlbklP Qy0+Q3liT1ggdHJhbnNmb3JtIGFuZCBhIHNldCBvZiBDeWJPWCBsYW5ndWFnZSBQeXRob24gYmlu ZGluZ3MuIFJlY29nbml6aW5nIHRoYXQgdGhpcyBpcyB0aGUgZmlyc3QgdGltZSB0aGF0IHRoZSBm b3JtYWwgbGFuZ3VhZ2Ugc3BlY2lmaWNhdGlvbnMgd2lsbCBiZSBhdmFpbGFibGUgZm9yIHJldmll dyBhbmQgYXMgc3VjaCB3aWxsIGxpa2VseSBnZW5lcmF0ZSBmZWVkYmFjayBmcm9tIG5ldyBzdGFr ZWhvbGRlcnMsIHRoaXMgaW5pdGlhbCBtYWpvciB2ZXJzaW9uIGlzIGJlaW5nIHJlbGVhc2VkIGFz IGEg4oCcZHJhZnTigJ0gdjEuMCB3aXRoIHRoZSBleHBlY3RhdGlvbiBvZiBjeWNsZXMgb2YgbmV3 IGZlZWRiYWNrIGFuZCByZXZpc2lvbiBiZWZvcmUgYSDigJxmaW5hbOKAnSB2MS4wIGlzIHJlbGVh c2VkLg0KDQpUaGUgQ3liT1ggdjEuMCAoRHJhZnQpIFhNTCBzY2hlbWFzIGluY2x1ZGUgYSBzaWdu aWZpY2FudCBudW1iZXIgb2YgY2hhbmdlcyBmcm9tIHYwLjcgdG8gaW1wcm92ZToNCg0KwrcgICAg ICAgQ2xhcml0eSwgZG9jdW1lbnRhdGlvbiwgYW5kIGRlc2NyaXB0aXZlIGZvcm1hbGl0eSBmb3Ig cmVmZXJlbmNlIGFuZCBpbXBsZW1lbnRhdGlvbiBieSBvdGhlciBzdGFuZGFyZHMgYW5kIHVzZXJz Lg0KDQrCtyAgICAgICBDb25zaXN0ZW5jeSwgc2ltcGxpY2l0eSwgYW5kIGVmZmljaWVuY3kuDQoN CsK3ICAgICAgIEFsaWdubWVudCAoYXMgYXBwcm9wcmlhdGUpIHRvIGV4aXN0aW5nIG5vcm1hdGl2 ZSByZWZlcmVuY2VzLg0KDQrCtyAgICAgICBFeHByZXNzaXZlbmVzcyBvZiB0aGUgc2NoZW1hIHRv IGJldHRlciBzdXBwb3J0IHRoZSBicm9hZCBzZXQgb2YgdXNlIGNhc2VzIGl0IHRhcmdldHMgKG1h bHdhcmUgY2hhcmFjdGVyaXphdGlvbiwgaW5kaWNhdG9yIGFuZCBpbmNpZGVudCBkYXRhIHNoYXJp bmcsIGV2ZW50IG1hbmFnZW1lbnQsIGV0Yy4pIGluY2x1ZGluZyB0aGUgYWRkaXRpb24gb2YgYW4g aW5pdGlhbCBzZXQgb2YgbmV0d29yay1yZWxhdGVkIGRlZmluZWQgb2JqZWN0cy4NCg0KU3VtbWFy eSBvZiBjaGFuZ2VzIGZyb20gQ3liT1hfdjAuNyB0byBDeWJPWF92MS4wXyhEcmFmdCk6DQoNCsK3 ICAgICAgICBSZWZpbmVtZW50IG9mIG5hbWVzcGFjZXMgYW5kIHNjaGVtYSBsb2NhdGlvbnMgZm9y IGJldHRlciBlZmZlY3RpdmVuZXNzIGFuZCBmbGV4aWJpbGl0eSBnb2luZyBmb3J3YXJkLg0KDQrC tyAgICAgICAgTm9ybWFsaXplZCBhbGwgY29udGVudCBhY2NvcmRpbmcgdG8gYW4gZXN0YWJsaXNo ZWQgc2V0IG9mIG5hbWluZyBjb252ZW50aW9ucy4NCg0KwrcgICAgICAgIEZ1bGx5IGFubm90YXRl ZCBhbGwgbGFuZ3VhZ2UgaXRlbXMgKHR5cGVzLCBhdHRyaWJ1dGVzLCBlbGVtZW50cywgZXRjLiku DQoNCsK3ICAgICAgICBNb3ZlZCBzZXZlcmFsIGNvbW1vbmx5IGxldmVyYWdlZCB0eXBlcyBvdXQg b2YgdGhlIGNvcmUgc2NoZW1hIGFuZCBpbnRvIGNvbW1vbl90eXBlcy4NCg0KwrcgICAgICAgIEFj aGlldmVkIGZ1bGwgdHlwaW5nIG9mIGVudGlyZSBzY2hlbWEgc3RydWN0dXJlIHN1Y2ggdGhhdCBh bGwgYXR0cmlidXRlcyBhbmQgZWxlbWVudHMgYXJlIGRlZmluaXRpdmVseSB0eXBlZC4NCg0Kwrcg ICAgICAgIENoYW5nZWQgYWxsIGlkZW50aWZpZXJzIGZyb20gSUQgYW5kIElEUkVGIHR5cGVzIHRv IGJlIFFOYW1lcyBlbmFibGluZyBnbG9iYWxseSB1bmlxdWUgaWRlbnRpZmllcnMgYW5kIGZsZXhp YmlsaXR5IGZvciBkb21haW4tc3BlY2lmaWMgdXNlcnMgb2YgQ3liT1ggdG8gZGVmaW5lIHRoZWly IG93biBpZGVudGlmaWVyIHN5bnRheCBsb2NhbGx5Lg0KDQrCtyAgICAgICAgUmVvcmRlcmVkIGF0 dHJpYnV0ZXMgYW5kIGVsZW1lbnRzIGluIG51bWVyb3VzIHR5cGVzIHRvIGJldHRlciByZWZsZWN0 IGNvbW1vbiB1c2FnZSBhbmQgcHJpb3JpdHkuDQoNCsK3ICAgICAgICBBZGRlZCBtYWpvcl92ZXJz aW9uIGFuZCBtaW5vcl92ZXJzaW9uIGF0dHJpYnV0ZXMgZm9yIGNvcmUgc2NoZW1hLg0KDQrCtyAg ICAgICAgQWRkZWQgY2FwYWJpbGl0eSB0byBjaGFyYWN0ZXJpemUgc291cmNlIG9mIG92ZXJhbGwg b2JzZXJ2YWJsZSBwYWNrYWdlIGRhdGEgYW5kIGZvciBpbmRpdmlkdWFsIG9ic2VydmFibGVzLg0K DQrCtyAgICAgICAgTW9kaWZpZWQgdGhlIGxvZ2ljYWwgY29tcG9zaXRpb24gc3RydWN0dXJlIHN1 Y2ggdGhhdCBhbnkgc3VjaCBjb21wb3NpdGlvbnMgYXJlIG5vdyBjb250YWluZWQgd2l0aGluIGEg T2JzZXJ2YWJsZV9Db21wb3NpdGlvbiBlbGVtZW50IHByb3ZpZGluZyBpbXByb3ZlZCBzaW1wbGlj aXR5IGFuZCBtb2R1bGFyaXR5Lg0KDQrCtyAgICAgICAgUmVtb3ZlZCB0aGUgRGVsdGEgZWxlbWVu dCBmcm9tIE9ic2VydmFibGVUeXBlIGFuZCByZWxvY2F0ZWQgdGhlIGFwcHJvcHJpYXRlIHBvcnRp b25zIChDaGFuZ2UsIFRyZW5kLCBhbmQgRnJlcXVlbmN5KSB0byBhcHByb3ByaWF0ZSBsb2NhdGlv bnMgdW5kZXIgU3RhdGVmdWxfTWVhc3VyZSBhbmQgRXZlbnQuDQoNCsK3ICAgICAgICBBZGRlZCBh IERvbWFpbl9TcGVjaWZpY19PYmplY3RfQXR0cmlidXRlcyBmaWVsZCB0byBPYmplY3QgdXRpbGl6 aW5nIGFuIGFic3RyYWN0IHR5cGUgdGhhdCB3aWxsIGFsbG93IGRvbWFpbi1zcGVjaWZpYyB1c2Ug Y2FzZXMgdG8gYWRkIGluIHRoZWlyIG93biBkb21haW4tc3BlY2lmaWMgYXR0cmlidXRlcyBmb3Ig T2JqZWN0cy4NCg0KwrcgICAgICAgIEFkZGVkIGEgVG9vbC1TcGVjaWZpY19EYXRhIGZpZWxkIHRv IFRvb2xJbmZvcm1hdGlvblR5cGUgdXRpbGl6aW5nIGFuIGFic3RyYWN0IHR5cGUgdGhhdCB3aWxs IGFsbG93IGFkZGl0aW9uIG9mIHRvb2wtc3BlY2lmaWMgZGF0YS4NCg0KwrcgICAgICAgIEFkZGVk IGFuIEluZGljYXRvcnMgZmllbGQgdG8gTWVhc3VyZVNvdXJjZVR5cGUgdXRpbGl6aW5nIGFuIGFi c3RyYWN0IHR5cGUgdGhhdCB3aWxsIGFsbG93IGNoYXJhY3Rlcml6aW5nIGRpZmZlcmluZyBmb3Jt YXRzIG9yIHN0YW5kYXJkcyBvZiBpbmRpY2F0b3JzIHRoYXQgbWF5IGhhdmUgbGVkIHRvIHRoZSBp ZGVudGlmaWNhdGlvbiBvZiB0aGUgb2JzZXJ2YWJsZSBkYXRhLg0KDQrCtyAgICAgICAgRW5oYW5j ZWQgdGhlIEhhc2ggc3RydWN0dXJlIHRvIGNhcHR1cmUgZnVsbCBmdXp6eSBoYXNoZXMgaW4gYWRk aXRpb24gdG8gc2ltcGxlIGhhc2hlcw0KDQrCtyAgICAgICAgQWRkZWQgYSBuZXcgRXh0cmFjdGVk RmVhdHVyZXNUeXBlIHRoYXQgY2FuIGJlIHVzZWQgdG8gYWRvcm4gZGlmZmVyaW5nIG9iamVjdHMg KGUuZy4sIGZpbGVzLCBtZW1vcnksIGV0Yy4pIHRvIGNhcHR1cmUgZXh0cmFjdGVkIHN0cmluZ3Ms IGltcG9ydHMsIGZ1bmN0aW9ucyBhbmQgY29kZSBzbmlwcGV0cw0KDQrCtyAgICAgICAgQWRkZWQg YSBCeXRlUnVuc1R5cGUgdG8gZW5hYmxlIGNhcHR1cmUgb2YgYnl0ZSBydW5zIHdpdGhpbiB2YXJp b3VzIG9iamVjdHMuDQoNCsK3ICAgICAgICBBZGRlZCBvYmplY3RfcmVmZXJlbmNlIGF0dHJpYnV0 ZSB0byBEZWZpbmVkT2JqZWN0VHlwZSB0byBiZXR0ZXIgc3VwcG9ydCByZWZlcmVuY2luZyBvZiBp bmRlcGVuZGVudGx5IGRlZmluZWQgT2JqZWN0cyBmcm9tIHdpdGhpbiBhbm90aGVyIE9iamVjdCBk ZWZpbml0aW9uLg0KDQrCtyAgICAgICAgQWRkZWQgYSBnZW5lcmljIERhdGFTZWdtZW50VHlwZSB0 byBwcm92aWRlIGEgcmVsYXRpdmVseSBhYnN0cmFjdCB3YXkgb2YgY2hhcmFjdGVyaXppbmcgZGF0 YSBzZWdtZW50cyB0aGF0IG1heSBiZSB3cml0dGVuL3JlYWQvdHJhbnNtaXR0ZWQgb3Igb3RoZXJ3 aXNlIHV0aWxpemVkIGluIGFjdGlvbnMgb3IgZGVmaW5lZCBpbiBvYmplY3RzLg0KDQrCtyAgICAg ICAgQWRkZWQgc2V2ZXJhbCBuZXcgZGVmaW5lZCBvYmplY3Qgc2NoZW1hcyAoQVBJLCBDb2RlLCBE ZXZpY2UsIEROU19SZWNvcmQsIE5ldHdvcmtfRmxvdywgTmV0d29ya19QYWNrZXQsIE5ldHdvcmtf Um91dGVfRW50cnksIE5ldHdvcmtfU3VibmV0LCBVbml4X05ldHdvcmtfUm91dGVfRW50cnkpIGlu Y2x1ZGluZyBhbiBpbml0aWFsIHNldCBvZiBuZXR3b3JrLWNlbnRyaWMgZGVmaW5lZCBvYmplY3Rz Lg0KDQrCtyAgICAgICAgTW9kaWZpZWQgZXZlcnkgZGVmaW5lZCBvYmplY3Qgc2NoZW1hIHdpdGgg YWRkZWQgYW5ub3RhdGlvbnMgYXMgd2VsbCBhcyBtaW5vciBhbmQgaW4gc29tZSBjYXNlcyBzdWJz dGFudGl2ZSBjaGFuZ2VzIHRvIGZpeCBlcnJvcnMsIGltcHJvdmUgY29uc2lzdGVuY3kgYW5kIGFs aWdubWVudCB3aXRoIGV4aXN0aW5nIG5vcm1hdGl2ZSByZWZlcmVuY2VzLCBhbmQgdG8gaW1wcm92 ZSBleHByZXNzaXZlbmVzcyBpbiBzdXBwb3J0IG9mIHRoZSB0YXJnZXRlZCB1c2UgY2FzZXMuDQoN CkRldGFpbGVkIGNoYW5nZXMgZnJvbSBDeWJPWF92MC43IHRvIEN5Yk9YX3YxLjBfKERyYWZ0KToN Cg0KVGhlIGxldmVsIG9mIGNoYW5nZXMgd2l0aGluIHYxLjAgKERyYWZ0KSBpbiB0aGUgY29yZSBz Y2hlbWEsIGNvbW1vbl90eXBlcyBhbmQgdGhlIGRlZmluZWQgb2JqZWN0IHNjaGVtYXMgaXMgdG9v IGdyZWF0IHRvIGxpc3QgZXZlcnkgY2hhbmdlIGluIHRoZXNlIHJlbGVhc2Ugbm90ZXMuIERldGFp bGVkIGRpZmZlcmVuY2UgcmVwb3J0cyBhcmUgYXZhaWxhYmxlIGZvciBlYWNoIGluZGl2aWR1YWwg c2NoZW1hIGF0Omh0dHA6Ly9jeWJveC5taXRyZS5vcmcvWE1MU2NoZW1hL3JlbGVhc2Vfbm90ZXMv Y3lib3hfdjEuMChkcmFmdClfZGlmZl9yZXBvcnRzLnppcCA8aHR0cDovL2N5Ym94Lm1pdHJlLm9y Zy9YTUxTY2hlbWEvcmVsZWFzZV9ub3Rlcy9jeWJveF92MS4wKGRyYWZ0KV9kaWZmX3JlcG9ydHMu emlwPiANCg0KIA0KDQogDQoNCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09DQoNClNlYW4gQmFybnVtDQoNCkN5YmVyIFNlY3VyaXR5IFByaW5jaXBhbA0KDQpU aGUgTUlUUkUgQ29ycG9yYXRpb24NCg0KRW1haWw6IHNiYXJudW1AbWl0cmUub3JnDQoNCiANCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1pbGUgbWFp bGluZyBsaXN0DQptaWxlQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL21pbGUNCg0KIA0KDQo= ------_=_NextPart_001_01CD1C4C.A5E487EB Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXVzLWFzY2lpIj48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250 ZW50PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PGJhc2UgaHJlZj0ieC1t c2c6Ly8yMDEyLyI+PHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZh Y2UNCgl7Zm9udC1mYW1pbHk6SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIg MTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FtYnJpYTsN CglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9 DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2 Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250 LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0K cC5Nc29UaXRsZSwgbGkuTXNvVGl0bGUsIGRpdi5Nc29UaXRsZQ0KCXttc28tc3R5bGUtcHJpb3Jp dHk6MTA7DQoJbXNvLXN0eWxlLWxpbms6IlRpdGxlIENoYXIiOw0KCW1zby1tYXJnaW4tdG9wLWFs dDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1M IFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFw dDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5N c29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFw aA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJ bWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4t bGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5h bWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyI7fQ0Kc3Bhbi5UaXRsZUNoYXINCgl7bXNvLXN0eWxlLW5hbWU6IlRpdGxlIENoYXIiOw0K CW1zby1zdHlsZS1wcmlvcml0eToxMDsNCgltc28tc3R5bGUtbGluazpUaXRsZTsNCglmb250LWZh bWlseToiQ2FtYnJpYSIsInNlcmlmIjsNCgljb2xvcjojMTczNjVEOw0KCWxldHRlci1zcGFjaW5n Oi4yNXB0O30NCnNwYW4uYXBwbGUtc3R5bGUtc3Bhbg0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1z dHlsZS1zcGFuO30NCnNwYW4uYXBwbGUtY29udmVydGVkLXNwYWNlDQoJe21zby1zdHlsZS1uYW1l OmFwcGxlLWNvbnZlcnRlZC1zcGFjZTt9DQpzcGFuLkVtYWlsU3R5bGUyNA0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNv bG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjUNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjoj MUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEu MGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24x DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGww DQoJe21zby1saXN0LWlkOjExMjU2NTYwMjA7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi04MTgw MjAxOTY7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDpcRjBCNzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGww OmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ6XEYwQjc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpcRjBCNzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0OlxGMEI3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoy LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30N CkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ6XEYwQjc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw2 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpcRjBC NzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0OlxGMEI3Ow0KCW1zby1sZXZlbC10 YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ6XEYwQjc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3Qg bDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDpcRjBCNzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1p ZDoxMzM1MjMxNTMxOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxMTczMTQ4NDMyO30NCkBsaXN0 IGwxOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ6XEYwQjc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0OlxGMEI3Ow0KCW1z by1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6XEYwQjc7DQoJbXNvLWxldmVsLXRhYi1zdG9w OjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7 fQ0KQGxpc3QgbDE6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDpcRjBCNzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZl bDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0OlxG MEI3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNg0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6XEYwQjc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDpcRjBCNzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsMTpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0OlxGMEI3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsOQ0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6XEYwQjc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDINCgl7bXNvLWxpc3QtaWQ6MTMzNTc2OTM5OTsN Cgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTIwMTEyNzI4OTI7fQ0KQGxpc3QgbDI6bGV2ZWwxDQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpcRjBCNzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6XEYwQjc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1i b2w7fQ0KQGxpc3QgbDI6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDpcRjBCNzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMjps ZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 OlxGMEI3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsNQ0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6XEYwQjc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpcRjBCNzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4w aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpA bGlzdCBsMjpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0OlxGMEI3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsOA0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6XEYwQjc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpcRjBCNzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5 bWJvbDt9DQpAbGlzdCBsMw0KCXttc28tbGlzdC1pZDoxNTAxNTAzMTc2Ow0KCW1zby1saXN0LXRl bXBsYXRlLWlkczoxMzQ1NjEwNDUyO30NCkBsaXN0IGwzOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6XEYwQjc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5 bWJvbDt9DQpAbGlzdCBsMzpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0OlxGMEI3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwz OmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ6XEYwQjc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWw0DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpcRjBCNzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMzpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0OlxGMEI3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoy LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30N CkBsaXN0IGwzOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ6XEYwQjc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWw3 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpcRjBC NzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMzpsZXZlbDgNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0OlxGMEI3Ow0KCW1zby1sZXZlbC10 YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGwzOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ6XEYwQjc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0Kb2wNCgl7 bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHls ZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0 IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPjwvaGVhZD48 Ym9keSBsYW5nPUVOLVVTIGxpbms9Ymx1ZSB2bGluaz1wdXJwbGU+PGZvbnQgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPg0KSWYgJnF1b3Q7ZGF0YSBmbG93JnF1b3Q7IGlzIGEg ZXVwaGVtaXNtIGZvciAmcXVvdDtuZXRmbG93JnF1b3Q7IGlzIHRoZXJlIGFueSByZWFzb24gbm90 IHRvIGNhbGwgaXQgdGhhdD88YnI+DTxicj5Ub20gTWlsbGFyDTxicj5odHRwOi8vd3d3LnVzLWNl cnQuZ292Lw08YnI+LS0tLS0tLS0tLS0tLS0tLS0tDTxicj5NaXNzaXQgbWUgUnVidXMgZnJ1dGlj b3N1czoNPGJyPjIwMiA2MzEgMTkxNQ08YnI+PC9mb250Pjxicj4mbmJzcDs8YnI+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzoz LjBwdCAwaW4gMGluIDBpbiI+DQo8Zm9udCBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+DQo8Yj5Gcm9t PC9iPjogQmFybnVtLCBTZWFuIEQuIFttYWlsdG86c2Jhcm51bUBtaXRyZS5vcmddDTxicj48Yj5T ZW50PC9iPjogTW9uZGF5LCBBcHJpbCAxNiwgMjAxMiAxMToyOSBQTTxicj48Yj5UbzwvYj46IE9t YXIgU2FudG9zIChvc2FudG9zKSAmbHQ7b3NhbnRvc0BjaXNjby5jb20mZ3Q7OyBMdWlzIE51bmV6 ICZsdDtsbnVuZXpAYzNpc2VjdXJpdHkuY29tJmd0Ow08YnI+PGI+Q2M8L2I+OiBpZHh3Z0BuaWN3 Zy5vcmcgJmx0O2lkeHdnQG5pY3dnLm9yZyZndDs7IG1pbGVAaWV0Zi5vcmcgJmx0O21pbGVAaWV0 Zi5vcmcmZ3Q7OyBkYWxsZW5kb3VnQGdtYWlsLmNvbSAmbHQ7ZGFsbGVuZG91Z0BnbWFpbC5jb20m Z3Q7OyBzYWNtQGlldGYub3JnICZsdDtzYWNtQGlldGYub3JnJmd0OzsgbS10ZXJhZGFAaXBhLmdv LmpwICZsdDttLXRlcmFkYUBpcGEuZ28uanAmZ3Q7DTxicj48Yj5TdWJqZWN0PC9iPjogUmU6IFtz YWNtXSBbbWlsZV0gQ3liT1ggdjEuMCAoRHJhZnQpIGlzIG5vdyByZWxlYXNlZCBhbmQgbGl2ZSBv bnRoZSB3ZWJzaXRlDTxicj48L2ZvbnQ+Jm5ic3A7PGJyPjwvZGl2Pg0KPGRpdiBjbGFzcz1Xb3Jk U2VjdGlvbjE+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+VGhhbmtz IE9tYXIuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2Nv bG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5UbyBhbnN3ZXIgeW91ciBxdWVzdGlvbiwgZmlyc3Qg bGV0IG1lIHBvaW50IG91dCB0byBvdGhlciByZWFkZXJzIHRoYXQgdGhlIHR3byBlbnRyaWVzIHRo YXQgT21hciBpcyBxdW90aW5nIGhlcmUgZXhpc3QgYXMgdmFsdWVzIGluIGFuIGVudW1lcmF0aW9u IGNhbGxlZCBFdmVudFR5cGVFbnVtIHdoaWNoIGFzIGl0cyBuYW1lIGltcGxpZXMgY29udGFpbnMg YSBsaXN0IG9mIGRpZmZlcmVudCBsYWJlbHMgZm9yIGdyb3VwaW5nIHR5cGVzIChvciBjbGFzc2Vz KSBvZiBldmVudHMgdG8gYmUgdXNlZCBhcyBsb3ctZ3JhbnVsYXJpdHkgYnVja2V0cyBmb3IgY2hh cmFjdGVyaXppbmcgYW5kIGNsYXNzaWZ5aW5nIGV2ZW50cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+T3RoZXIgZW50cmllcyBp biB0aGlzIGVudW1lcmF0aW9uIGluY2x1ZGUgdGhpbmdzIGxpa2UgJiM4MjIwO0ZpbGUgT3BzIChD UlVEKSYjODIyMTssICYjODIyMDtQcm9jZXNzIE1ndCYjODIyMTssICYjODIyMDtBdXRob3JpemF0 aW9uIChBQ0wpJiM4MjIxOywgZXRjLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+VGhlICYjODIyMDtQYWNr ZXQgVHJhZmZpYyYjODIyMTsgdmFsdWUgaXMgaW50ZW5kZWQgdG8gY2hhcmFjdGVyaXplIGV2ZW50 cyBkZWFsaW5nIHdpdGggbmV0d29yayBwYWNrZXQgdHJhZmZpYyBhcyBpdHMgbmFtZSBpbXBsaWVz LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjoj MUY0OTdEJz5UaGUgJiM4MjIwO0RhdGEgRmxvdyYjODIyMTsgdmFsdWUgaXMgaW50ZW5kZWQgdG8g Y2hhcmFjdGVyaXplIGV2ZW50cyBkZWFsaW5nIHdpdGggZm9ybXMgb2YgZGF0YSBmbG93IGF0IGEg aGlnaGVyIGxldmVsIG9mIGFic3RyYWN0aW9uIHRoYW4ganVzdCBwYWNrZXQgdHJhZmZpYy4gVGhl IHJlbGF0aW9uc2hpcCBiZXR3ZWVuIHRoZXNlIHR3byB2YWx1ZXMgY291bGQgYmUgdmlld2VkIGFz ICYjODIyMDtQYWNrZXQgVHJhZmZpYyYjODIyMTsgYmVpbmcgYSBtb3JlIGRldGFpbGVkIGZvcm0g b2YgJiM4MjIwO0RhdGEgRmxvdyYjODIyMTsganVzdCBhcyB0aGUgdmFsdWVzICYjODIyMDtBcHAg TGF5ZXIgVHJhZmZpYyYjODIyMTsgYW5kICYjODIyMDtIVFRQIExheWVyIFRyYWZmaWMmIzgyMjE7 LCBhbHNvIGluIHRoaXMgZW51bWVyYXRpb24sIGNvdWxkIGJlIG90aGVyIGxldmVscyBpbiB0aGlz IHNhbWUgYWJzdHJhY3Rpb24gc3RhY2suPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlRoZSBpZGVhIGJlaGluZCB0aGUgdmFyeWlu ZyBsZXZlbHMgb2YgYWJzdHJhY3Rpb24gaXMgdG8gbGVhdmUgJm5ic3A7YnVja2V0cyBsYXJnZSBl bm91Z2ggdG8gY2FwdHVyZSBhIHdpZGUgdmFyaWV0eSBvZiBwb3RlbnRpYWwgZXZlbnQgdHlwZXMg KGUuZy4gZGF0YSBmbG93IGV2ZW50cyBvdGhlciB0aGFuIG9idmlvdXMgdGhpbmdzIGxpa2UgcGFj a2V0IHRyYWZmaWMpIGJ1dCBhbHNvIGVuYWJsZSB0aGUgdXNlIG9mIHNtYWxsZXIgbW9yZSBzcGVj aWZpYyBidWNrZXRzIHdoZW4gdGhleSBhcmUgYXBwcm9wcmlhdGUgYW5kIGNvbW1vbmx5IHVzZWQu PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMx RjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjtjb2xvcjojMUY0OTdEJz5Eb2VzIHRoaXMgbWFrZSBzZW5zZT8gPG86cD48L286cD48L3Nw YW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0 OTdEJz5zZWFuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi O2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48ZGl2PjxkaXYgc3R5 bGU9J2JvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMu MHB0IDBpbiAwaW4gMGluJz48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41 aW4nPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEi LCJzYW5zLXNlcmlmIic+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+IE9tYXIgU2FudG9zIChvc2Fu dG9zKSBbbWFpbHRvOm9zYW50b3NAY2lzY28uY29tXSA8YnI+PGI+U2VudDo8L2I+IE1vbmRheSwg QXByaWwgMTYsIDIwMTIgODoxNyBQTTxicj48Yj5Ubzo8L2I+IEx1aXMgTnVuZXo7IEJhcm51bSwg U2VhbiBELjxicj48Yj5DYzo8L2I+IGlkeHdnQG5pY3dnLm9yZzsgbWlsZUBpZXRmLm9yZzsgZGFs bGVuZG91Z0BnbWFpbC5jb207IHNhY21AaWV0Zi5vcmc7IG0tdGVyYWRhQGlwYS5nby5qcDxicj48 Yj5TdWJqZWN0OjwvYj4gUkU6IFtzYWNtXSBbbWlsZV0gQ3liT1ggdjEuMCAoRHJhZnQpIGlzIG5v dyByZWxlYXNlZCBhbmQgbGl2ZSBvbnRoZSB3ZWJzaXRlPG86cD48L286cD48L3NwYW4+PC9wPjwv ZGl2PjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVpbic+PG86 cD4mbmJzcDs8L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDou NWluJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkkgZWNobyBMdWlzJiM4MjE3OyBjb21tZW50cy4g SXQgaXMgZ29vZCB0byBzZWUgdGhlIGluY2x1c2lvbiBvZiBuZXR3b3JrIG9iamVjdHMuIFF1aWNr IHF1ZXN0aW9uIHRvIHRoZSB0ZWFtIHJlbGF0ZWQgdG8geW91ciBuZXRmbG93IGNvbW1lbnQuPG86 cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6 LjVpbic+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9y OiMxRjQ5N0QnPkkgYW0gbG9va2luZyBhdDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9 TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0Qn PjxhIGhyZWY9Imh0dHA6Ly9jeWJveC5taXRyZS5vcmcvWE1MU2NoZW1hL2N5Ym94X2NvcmVfdjEu MCUyOGRyYWZ0JTI5LnhzZCI+aHR0cDovL2N5Ym94Lm1pdHJlLm9yZy9YTUxTY2hlbWEvY3lib3hf Y29yZV92MS4wJTI4ZHJhZnQlMjkueHNkPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFz cz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3 RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0n bWFyZ2luLWxlZnQ6LjVpbic+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz4mIzgyMzA7IGFuZCBpdCBs b29rcyB0aGF0IHdlIHJlbmFtZWQgaXQgdG8gJiM4MjIwO0RhdGEgRmxvdyYjODIyMTs/PG86cD48 L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVp bic+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz4mbHQ7eHM6ZW51bWVyYXRp b24gdmFsdWU9JnF1b3Q7RGF0YSBGbG93JnF1b3Q7Jmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZuYnNwOyZuYnNwOyAm bHQ7eHM6YW5ub3RhdGlvbiZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9y bWFsIHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseToiQ291cmllciBOZXciJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgJmx0O3hzOmRvY3VtZW50YXRpb24mZ3Q7U3BlY2lmaWVzIHRoZSBjbGFz cyBvZiBldmVudHMgZGVhbGluZyB3aXRoIGRhdGEgZmxvdy4mbHQ7L3hzOmRvY3VtZW50YXRpb24m Z3Q7PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2lu LWxlZnQ6LjVpbic+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNv dXJpZXIgTmV3Iic+Jm5ic3A7Jm5ic3A7ICZsdDsveHM6YW5ub3RhdGlvbiZndDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz4m bHQ7L3hzOmVudW1lcmF0aW9uJmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29O b3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41 aW4nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+V2hhdCBpcyB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVu IHRoYXQgYW5kICYjODIyMDtQYWNrZXQgVHJhZmZpYyYjODIyMTs/PG86cD48L286cD48L3NwYW4+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVpbic+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtj b2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHByZSBzdHlsZT0nbWFy Z2luLWxlZnQ6LjVpbic+Jmx0O3hzOmVudW1lcmF0aW9uIHZhbHVlPSZxdW90O1BhY2tldCBUcmFm ZmljJnF1b3Q7Jmd0OzxvOnA+PC9vOnA+PC9wcmU+PHByZSBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVp bic+Jm5ic3A7Jm5ic3A7ICZsdDt4czphbm5vdGF0aW9uJmd0OzxvOnA+PC9vOnA+PC9wcmU+PHBy ZSBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVpbic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDt4 czpkb2N1bWVudGF0aW9uJmd0O1NwZWNpZmllcyB0aGUgY2xhc3Mgb2YgZXZlbnRzIGRlYWxpbmcg d2l0aCBwYWNrZXQgdHJhZmZpYy4mbHQ7L3hzOmRvY3VtZW50YXRpb24mZ3Q7PG86cD48L286cD48 L3ByZT48cHJlIHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz4mbmJzcDsmbmJzcDsgJmx0Oy94czph bm5vdGF0aW9uJmd0OzxvOnA+PC9vOnA+PC9wcmU+PHByZSBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVp bic+Jmx0Oy94czplbnVtZXJhdGlvbiZndDs8bzpwPjwvbzpwPjwvcHJlPjxwIGNsYXNzPU1zb05v cm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVpbic+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4t bGVmdDouNWluJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05v cm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVpbic+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21h cmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiJDb3VyaWVyIE5ldyI7Y29sb3I6IzFGNDk3RCc+UmVnYXJkcyw8YnI+PGJyPk9tYXIgU2FudG9z PGJyPkluY2lkZW50IE1hbmFnZXIsIFBTSVJUPGJyPlNlY3VyaXR5IFJlc2VhcmNoIGFuZCBPcGVy YXRpb25zPGJyPkNpc2NvIFN5c3RlbXMsIEluYy48YnI+RW1haWw6IDxhIGhyZWY9Im1haWx0bzpv c0BjaXNjby5jb20iPm9zQGNpc2NvLmNvbTwvYT48YnI+UGhvbmU6ICsxIDkxOSAzOTIgODYzNTxi cj5QR1AgS2V5OiAweDNBRjI3RURDPGJyPjxicj5DaXNjby5jb20gLSA8YSBocmVmPSJodHRwOi8v d3d3LmNpc2NvLmNvbSI+aHR0cDovL3d3dy5jaXNjby5jb208L2E+PGJyPkNpc2NvIFNlY3VyaXR5 IEFkdmlzb3JpZXMgYW5kIE5vdGljZXMgLSA8YSBocmVmPSJodHRwOi8vd3d3LmNpc2NvLmNvbS9n by9wc2lydCI+aHR0cDovL3d3dy5jaXNjby5jb20vZ28vcHNpcnQ8L2E+PGJyPjxicj5UaGlzIGVt YWlsIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBhbmQgcHJpdmlsZWdlZCBtYXRlcmlhbCBmb3Ig dGhlIHNvbGU8YnI+dXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQuIEFueSByZXZpZXcsIHVz ZSwgZGlzdHJpYnV0aW9uIG9yPGJyPmRpc2Nsb3N1cmUgYnkgb3RoZXJzIGlzIHN0cmljdGx5IHBy b2hpYml0ZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZDxicj5yZWNpcGllbnQgKG9yIGF1 dGhvcml6ZWQgdG8gcmVjZWl2ZSBmb3IgdGhlIHJlY2lwaWVudCksIHBsZWFzZSBjb250YWN0PGJy PnRoZSBzZW5kZXIgYnkgcmVwbHkgZW1haWwgYW5kIGRlbGV0ZSBhbGwgY29waWVzIG9mIHRoaXMg bWVzc2FnZS48YnI+PGJyPkZvciBjb3Jwb3JhdGUgbGVnYWwgaW5mb3JtYXRpb24gZ28gdG86PGJy PjxhIGhyZWY9Imh0dHA6Ly93d3cuY2lzY28uY29tL3dlYi9hYm91dC9kb2luZ19idXNpbmVzcy9s ZWdhbC9jcmkvaW5kZXguaHRtbCI+aHR0cDovL3d3dy5jaXNjby5jb20vd2ViL2Fib3V0L2RvaW5n X2J1c2luZXNzL2xlZ2FsL2NyaS9pbmRleC5odG1sPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxkaXY+PGRpdiBzdHls ZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4w cHQgMGluIDBpbiAwaW4nPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVp bic+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIs InNhbnMtc2VyaWYiJz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz4gPGEgaHJlZj0ibWFpbHRvOnNh Y20tYm91bmNlc0BpZXRmLm9yZyI+c2FjbS1ib3VuY2VzQGlldGYub3JnPC9hPiA8YSBocmVmPSJt YWlsdG86W21haWx0bzpzYWNtLWJvdW5jZXNAaWV0Zi5vcmddIj5bbWFpbHRvOnNhY20tYm91bmNl c0BpZXRmLm9yZ108L2E+IDxiPk9uIEJlaGFsZiBPZiA8L2I+THVpcyBOdW5lejxicj48Yj5TZW50 OjwvYj4gTW9uZGF5LCBBcHJpbCAxNiwgMjAxMiA2OjQ0IFBNPGJyPjxiPlRvOjwvYj4gQmFybnVt LCBTZWFuIEQuPGJyPjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRvOmlkeHdnQG5pY3dnLm9yZyI+ aWR4d2dAbmljd2cub3JnPC9hPjsgPGEgaHJlZj0ibWFpbHRvOm1pbGVAaWV0Zi5vcmciPm1pbGVA aWV0Zi5vcmc8L2E+OyBEb3VnIFdpbHNvbiAoPGEgaHJlZj0ibWFpbHRvOmRhbGxlbmRvdWdAZ21h aWwuY29tIj5kYWxsZW5kb3VnQGdtYWlsLmNvbTwvYT4pOyA8YSBocmVmPSJtYWlsdG86c2FjbUBp ZXRmLm9yZyI+c2FjbUBpZXRmLm9yZzwvYT47IElQQS1NYXNhdG8gVGVyYWRhICg8YSBocmVmPSJt YWlsdG86bS10ZXJhZGFAaXBhLmdvLmpwIj5tLXRlcmFkYUBpcGEuZ28uanA8L2E+KTxicj48Yj5T dWJqZWN0OjwvYj4gUmU6IFtzYWNtXSBbbWlsZV0gQ3liT1ggdjEuMCAoRHJhZnQpIGlzIG5vdyBy ZWxlYXNlZCBhbmQgbGl2ZSBvbnRoZSB3ZWJzaXRlPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2 PjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVpbic+PG86cD4m bmJzcDs8L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDouNWlu Jz5JIGxpa2UgdGhlIGluY2x1c2lvbiBvZiB0aGUgbmV0d29yay1jZW50cmljIG9iamVjdHMuICZu YnNwO0lQRklYIChuZXRmbG93KSAmbmJzcDt3aWxsIGFkZCBhbiBhZGRpdGlvbmFsIHBlcnNwZWN0 aXZlIGZyb20gYW4gaW5jaWRlbnQgaW5mb3JtYXRpb24gc2hhcmluZyBzdGFuZHBvaW50LiAmbmJz cDs8bzpwPjwvbzpwPjwvcD48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxl ZnQ6LjVpbic+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3Jt YWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4nPi1sbjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz48bzpwPiZuYnNwOzwv bzpwPjwvcD48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDou NWluJz5PbiBBcHIgMTYsIDIwMTIsIGF0IDQ6MDQgUE0sIEJhcm51bSwgU2VhbiBELiB3cm90ZTo8 bzpwPjwvbzpwPjwvcD48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4t dG9wLWFsdDowaW47bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjEyLjBwdDttYXJnaW4t bGVmdDouNWluJz48bzpwPiZuYnNwOzwvbzpwPjwvcD48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsIHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz5IZXkgZXZlcnlvbmUsPG86cD48 L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJn aW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiJz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiIn PkkganVzdCB3YW50ZWQgdG8gbGV0IHlvdSBhbGwga25vdyB0aGF0IEN5Yk9YIHYxLjAgKERyYWZ0 KSBjb250ZW50IGlzIG5vdyBsaXZlIG9uIHRoZSB3ZWJzaXRlLjxzcGFuIGNsYXNzPWFwcGxlLWNv bnZlcnRlZC1zcGFjZT4mbmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0cDovL2N5Ym94Lm1pdHJlLm9y ZyI+aHR0cDovL2N5Ym94Lm1pdHJlLm9yZzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiIn PlRoZSByZWxlYXNlIG5vdGVzIGFyZSBwcm92aWRlZCBpbmxpbmUgYmVsb3cuPG86cD48L286cD48 L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVm dDouNWluJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiJz5UaGUga2V5IGl0ZW1zIG9mIG5vdGUgYXJlOjxvOnA+PC9vOnA+PC9z cGFuPjwvcD48L2Rpdj48ZGl2IHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz48cCBjbGFzcz1Nc29O b3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW47dGV4dC1pbmRlbnQ6LS4yNWluO2xpbmUtaGVp Z2h0OjEyLjc1cHQnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OlN5 bWJvbCc+Jm1pZGRvdDs8L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo3LjBwdCc+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9YXBwbGUtY29u dmVydGVkLXNwYWNlPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+VGhlIHJlbGVhc2Ugb2Yg dHdvIGZvcm1hbCBzcGVjaWZpY2F0aW9ucyBmb3IgdGhlIEN5Yk9YIGxhbmd1YWdlIChvbmUgZm9y IHRoZSBjb3JlIGxhbmd1YWdlIGFuZCBvbmUgZm9yIHRoZSBkZWZpbmVkIG9iamVjdHMpPG86cD48 L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXYgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4nPjxwIGNs YXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVpbjt0ZXh0LWluZGVudDotLjI1aW47 bGluZS1oZWlnaHQ6MTIuNzVwdCc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6U3ltYm9sJz4mbWlkZG90Ozwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjcuMHB0 Jz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz1h cHBsZS1jb252ZXJ0ZWQtc3BhY2U+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz5UaGUgWE1M IFNjaGVtYSBoYXMgZ29uZSB0aHJvdWdoIGV4dGVuc2l2ZSBpbXByb3ZlbWVudHMgZm9yIGV4cHJl c3NpdmVuZXNzLCBjbGFyaXR5LCBjb25zaXN0ZW5jeSwgZWZmaWNpZW5jeSwgYWxpZ25tZW50IHRv IGV4aXN0aW5nIG5vcm1hdGl2ZSByZWZlcmVuY2VzIGFuZCBkb2N1bWVudGF0aW9uLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2IHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz48cCBjbGFz cz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW47dGV4dC1pbmRlbnQ6LS4yNWluO2xp bmUtaGVpZ2h0OjEyLjc1cHQnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OlN5bWJvbCc+Jm1pZGRvdDs8L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo3LjBwdCc+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9YXBw bGUtY29udmVydGVkLXNwYWNlPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+VGhpcyByZWxl YXNlIGluY2x1ZGVzIGFuIGluaXRpYWwgc2V0IG9mIGxhbmd1YWdlIHV0aWxpdGllczogYSBkcmFm dCBTbm9ydCAtJmd0OyBDeWJPWCB0cmFuc2Zvcm0sIGEgZHJhZnQgT3BlbklPQyAtJmd0OyBDeWJP WCB0cmFuc2Zvcm0sIGFuZCBhIHNldCBvZiBQeXRob24gYmluZGluZ3MgZm9yIHRoZSBDeWJPWCBs YW5ndWFnZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PHAgY2xhc3M9TXNvTGlzdFBhcmFn cmFwaCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OjBpbjttYXJnaW4tcmlnaHQ6MGluO21hcmdp bi1ib3R0b206MTAuMHB0O21hcmdpbi1sZWZ0OjEuMGluO3RleHQtaW5kZW50Oi0uMjVpbjtsaW5l LWhlaWdodDoxMi43NXB0Jz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTpTeW1ib2wnPiZtaWRkb3Q7PC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6Ny4wcHQnPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPWFwcGxl LWNvbnZlcnRlZC1zcGFjZT4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiInPlRoZSB3ZWJzaXRl IG5vdyBpbmNsdWRlcyBhIHNtYWxsIHNldCBvZiBjb250ZW50IGV4YW1wbGVzLiBUaGlzIHNldCB3 aWxsIGdyb3cgZ29pbmcgZm9yd2FyZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PGRpdj48cCBjbGFz cz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiInPlRoaXMgcmVsZWFz ZSBpbnZvbHZlZCBhIGxvdCBvZiBoYXJkIHdvcmsgZnJvbSBhIGRpdmVyc2UgZ3JvdXAgb2YgcGVv cGxlLiBUaGFuayB5b3UgYWxsIGZvciB5b3VyIGNvbnRyaWJ1dGlvbnMgYW5kIGVmZm9ydC4gV2Ug Y291bGQgbm90IGhhdmUgZG9uZSBpdCB3aXRob3V0IHlvdS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4nPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiInPldlIGxvb2sgZm9yd2FyZCB0byBldmVyeW9uZSYjODIxNztzIGZlZWRiYWNrIGFuZCBj b2xsYWJvcmF0aW9uIGFzIHdlIGNvbnRpbnVlIHRvIGltcHJvdmUgYW5kIG1hdHVyZSB0aGUgQ3li T1ggbGFuZ3VhZ2UuPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNv Tm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz4mbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1s ZWZ0Oi41aW4nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiInPlNlYW4gQmFybnVtPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2 PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz48c3BhbiBz dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi Jz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3Jt YWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiInPiZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6 LjVpbic+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIic+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXYgc3R5 bGU9J2JvcmRlcjpub25lO2JvcmRlci1ib3R0b206c29saWQgIzRGODFCRCAxLjBwdDtwYWRkaW5n OjBpbiAwaW4gNC4wcHQgMGluO2JvcmRlci13aWR0aDppbml0aWFsO2JvcmRlci1jb2xvcjppbml0 aWFsJz48cCBjbGFzcz1Nc29UaXRsZSBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OjBpbjttYXJn aW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206MTUuMHB0O21hcmdpbi1sZWZ0Oi41aW4nPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MjYuMHB0O2ZvbnQtZmFtaWx5OiJDYW1icmlhIiwic2VyaWYiO2Nv bG9yOiMxNzM2NUQ7bGV0dGVyLXNwYWNpbmc6LjI1cHQnPkN5Yk9YIHYxLjAgKERyYWZ0KSBSZWxl YXNlIE5vdGVzPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsIHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz5UaGUgVmVyc2lvbiAxLjAgKERyYWZ0KSByZWxl YXNlIG9mIEN5YmVyIE9ic2VydmFibGUgZVhwcmVzc2lvbiAoQ3liT1gmIzg0ODI7KTxzcGFuIGNs YXNzPWFwcGxlLWNvbnZlcnRlZC1zcGFjZT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz4mbmJzcDs8L3NwYW4+PC9zcGFuPmlz IGludGVuZGVkIGFzIGEgZHJhZnQgcmVsZWFzZSBvZiBhbiBpbml0aWFsIG1ham9yIHZlcnNpb24g b2YgdGhlIEN5Yk9YIExhbmd1YWdlIHRoYXQgY291bGQgYmUgdXRpbGl6ZWQgZm9yIHByYWN0aWNh bCBvcGVyYXRpb25hbCB1c2UgYW5kIGludGVncmF0aW9uIGludG8gb3RoZXIgc3RhbmRhcmRzIGVm Zm9ydHMuIFRoaXMgcmVsZWFzZSBjb25zaXN0cyBvZiB0aHJlZSBwcmltYXJ5IGNvbXBvbmVudHM6 IGEgcGFpciBvZiBmb3JtYWwgbGFuZ3VhZ2Ugc3BlY2lmaWNhdGlvbnMgZm9yIHRoZSBjb3JlIGxh bmd1YWdlIGNvbnRlbnQgYW5kIGRlZmluZWQgb2JqZWN0cyBjb250ZW50LCBhIHNldCBvZiBsYW5n dWFnZSBpbXBsZW1lbnRhdGlvbiBYTUwgc2NoZW1hcyAoY29yZSwgY29tbW9uX3R5cGVzLCBhbmQg fjcwIGRlZmluZWQgb2JqZWN0IHNjaGVtYXMpLCBhbmQgYSBzbWFsbCBpbml0aWFsIHNldCBvZiBs YW5ndWFnZSB1dGlsaXRpZXMgaW5jbHVkaW5nIGFuIGluaXRpYWwgZHJhZnQgU25vcnQtJmd0O0N5 Yk9YIHRyYW5zZm9ybSwgYW4gaW5pdGlhbCBkcmFmdCBPcGVuSU9DLSZndDtDeWJPWCB0cmFuc2Zv cm0gYW5kIGEgc2V0IG9mIEN5Yk9YIGxhbmd1YWdlIFB5dGhvbiBiaW5kaW5ncy4gUmVjb2duaXpp bmcgdGhhdCB0aGlzIGlzIHRoZSBmaXJzdCB0aW1lIHRoYXQgdGhlIGZvcm1hbCBsYW5ndWFnZSBz cGVjaWZpY2F0aW9ucyB3aWxsIGJlIGF2YWlsYWJsZSBmb3IgcmV2aWV3IGFuZCBhcyBzdWNoIHdp bGwgbGlrZWx5IGdlbmVyYXRlIGZlZWRiYWNrIGZyb20gbmV3IHN0YWtlaG9sZGVycywgdGhpcyBp bml0aWFsIG1ham9yIHZlcnNpb24gaXMgYmVpbmcgcmVsZWFzZWQgYXMgYSAmIzgyMjA7ZHJhZnQm IzgyMjE7IHYxLjAgd2l0aCB0aGUgZXhwZWN0YXRpb24gb2YgY3ljbGVzIG9mIG5ldyBmZWVkYmFj ayBhbmQgcmV2aXNpb24gYmVmb3JlIGEgJiM4MjIwO2ZpbmFsJiM4MjIxOyB2MS4wIGlzIHJlbGVh c2VkLjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiInPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVpbic+VGhlIEN5Yk9YIHYxLjAgKERyYWZ0KSBY TUwgc2NoZW1hcyBpbmNsdWRlIGEgc2lnbmlmaWNhbnQgbnVtYmVyIG9mIGNoYW5nZXMgZnJvbSB2 MC43IHRvIGltcHJvdmU6PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXYg c3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4nPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2lu LWxlZnQ6LjVpbjt0ZXh0LWluZGVudDotLjI1aW4nPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseTpT eW1ib2wnPiZtaWRkb3Q7PC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6Ny4wcHQnPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPWFwcGxlLWNvbnZlcnRl ZC1zcGFjZT4mbmJzcDs8L3NwYW4+PC9zcGFuPkNsYXJpdHksIGRvY3VtZW50YXRpb24sIGFuZCBk ZXNjcmlwdGl2ZSBmb3JtYWxpdHkgZm9yIHJlZmVyZW5jZSBhbmQgaW1wbGVtZW50YXRpb24gYnkg b3RoZXIgc3RhbmRhcmRzIGFuZCB1c2Vycy48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PC9kaXY+PGRpdiBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVpbic+PHAgY2xhc3M9TXNvTm9ybWFsIHN0 eWxlPSdtYXJnaW4tbGVmdDouNWluO3RleHQtaW5kZW50Oi0uMjVpbic+PHNwYW4gc3R5bGU9J2Zv bnQtZmFtaWx5OlN5bWJvbCc+Jm1pZGRvdDs8L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo3 LjBwdCc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9YXBw bGUtY29udmVydGVkLXNwYWNlPiZuYnNwOzwvc3Bhbj48L3NwYW4+Q29uc2lzdGVuY3ksIHNpbXBs aWNpdHksIGFuZCBlZmZpY2llbmN5LjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiInPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rp dj48ZGl2IHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9 J21hcmdpbi1sZWZ0Oi41aW47dGV4dC1pbmRlbnQ6LS4yNWluJz48c3BhbiBzdHlsZT0nZm9udC1m YW1pbHk6U3ltYm9sJz4mbWlkZG90Ozwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjcuMHB0 Jz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz1hcHBsZS1j b252ZXJ0ZWQtc3BhY2U+Jm5ic3A7PC9zcGFuPjwvc3Bhbj5BbGlnbm1lbnQgKGFzIGFwcHJvcHJp YXRlKSB0byBleGlzdGluZyBub3JtYXRpdmUgcmVmZXJlbmNlcy48c3BhbiBzdHlsZT0nZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PC9kaXY+PHAgY2xhc3M9TXNvTGlzdFBhcmFncmFwaCBzdHlsZT0nbXNvLW1h cmdpbi10b3AtYWx0OjBpbjttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206MTAuMHB0O21h cmdpbi1sZWZ0OjEuMGluO3RleHQtaW5kZW50Oi0uMjVpbic+PHNwYW4gc3R5bGU9J2ZvbnQtZmFt aWx5OlN5bWJvbCc+Jm1pZGRvdDs8L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo3LjBwdCc+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9YXBwbGUtY29u dmVydGVkLXNwYWNlPiZuYnNwOzwvc3Bhbj48L3NwYW4+RXhwcmVzc2l2ZW5lc3Mgb2YgdGhlIHNj aGVtYSB0byBiZXR0ZXIgc3VwcG9ydCB0aGUgYnJvYWQgc2V0IG9mIHVzZSBjYXNlcyBpdCB0YXJn ZXRzIChtYWx3YXJlIGNoYXJhY3Rlcml6YXRpb24sIGluZGljYXRvciBhbmQgaW5jaWRlbnQgZGF0 YSBzaGFyaW5nLCBldmVudCBtYW5hZ2VtZW50LCBldGMuKSBpbmNsdWRpbmcgdGhlIGFkZGl0aW9u IG9mIGFuIGluaXRpYWwgc2V0IG9mIG5ldHdvcmstcmVsYXRlZCBkZWZpbmVkIG9iamVjdHMuPHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIic+PG86cD48L286cD48L3NwYW4+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxl PSdtYXJnaW4tbGVmdDouNWluJz5TdW1tYXJ5IG9mIGNoYW5nZXMgZnJvbSBDeWJPWF92MC43IHRv IEN5Yk9YX3YxLjBfKERyYWZ0KTo8c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+ PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDoxLjBpbjt0ZXh0LWluZGVudDot LjI1aW47bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzMnPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbCc+PHNwYW4gc3R5bGU9 J21zby1saXN0Oklnbm9yZSc+Jm1pZGRvdDs8c3BhbiBzdHlsZT0nZm9udDo3LjBwdCAiVGltZXMg TmV3IFJvbWFuIic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwv c3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT5SZWZpbmVtZW50IG9mIG5hbWVzcGFjZXMgYW5k IHNjaGVtYSBsb2NhdGlvbnMgZm9yIGJldHRlciBlZmZlY3RpdmVuZXNzIGFuZCBmbGV4aWJpbGl0 eSBnb2luZyBmb3J3YXJkLjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiInPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N c29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0OjEuMGluO3RleHQtaW5kZW50Oi0uMjVpbjttc28t bGlzdDpsMSBsZXZlbDEgbGZvMyc+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sJz48c3BhbiBzdHlsZT0nbXNvLWxpc3Q6 SWdub3JlJz4mbWlkZG90OzxzcGFuIHN0eWxlPSdmb250OjcuMHB0ICJUaW1lcyBOZXcgUm9tYW4i Jz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjwvc3Bh bj48L3NwYW4+PCFbZW5kaWZdPk5vcm1hbGl6ZWQgYWxsIGNvbnRlbnQgYWNjb3JkaW5nIHRvIGFu IGVzdGFibGlzaGVkIHNldCBvZiBuYW1pbmcgY29udmVudGlvbnMuPHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+PG86cD48L286 cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6MS4waW47 dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwxIGxldmVsMSBsZm8zJz48IVtpZiAhc3VwcG9y dExpc3RzXT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTeW1ib2wn PjxzcGFuIHN0eWxlPSdtc28tbGlzdDpJZ25vcmUnPiZtaWRkb3Q7PHNwYW4gc3R5bGU9J2ZvbnQ6 Ny4wcHQgIlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyA8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+RnVsbHkgYW5ub3RhdGVk IGFsbCBsYW5ndWFnZSBpdGVtcyAodHlwZXMsIGF0dHJpYnV0ZXMsIGVsZW1lbnRzLCBldGMuKS48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdt YXJnaW4tbGVmdDoxLjBpbjt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDEgbGV2ZWwxIGxm bzMnPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OlN5bWJvbCc+PHNwYW4gc3R5bGU9J21zby1saXN0Oklnbm9yZSc+Jm1pZGRvdDs8 c3BhbiBzdHlsZT0nZm9udDo3LjBwdCAiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlm XT5Nb3ZlZCBzZXZlcmFsIGNvbW1vbmx5IGxldmVyYWdlZCB0eXBlcyBvdXQgb2YgdGhlIGNvcmUg c2NoZW1hIGFuZCBpbnRvIGNvbW1vbl90eXBlcy48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDoxLjBpbjt0ZXh0LWluZGVu dDotLjI1aW47bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzMnPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbCc+PHNwYW4gc3R5 bGU9J21zby1saXN0Oklnbm9yZSc+Jm1pZGRvdDs8c3BhbiBzdHlsZT0nZm9udDo3LjBwdCAiVGlt ZXMgTmV3IFJvbWFuIic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IDwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT5BY2hpZXZlZCBmdWxsIHR5cGluZyBvZiBl bnRpcmUgc2NoZW1hIHN0cnVjdHVyZSBzdWNoIHRoYXQgYWxsIGF0dHJpYnV0ZXMgYW5kIGVsZW1l bnRzIGFyZSBkZWZpbml0aXZlbHkgdHlwZWQuPHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+PG86cD48L286cD48L3NwYW4+PC9w PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6MS4waW47dGV4dC1pbmRlbnQ6 LS4yNWluO21zby1saXN0OmwxIGxldmVsMSBsZm8zJz48IVtpZiAhc3VwcG9ydExpc3RzXT48c3Bh biBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTeW1ib2wnPjxzcGFuIHN0eWxl PSdtc28tbGlzdDpJZ25vcmUnPiZtaWRkb3Q7PHNwYW4gc3R5bGU9J2ZvbnQ6Ny4wcHQgIlRpbWVz IE5ldyBSb21hbiInPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8 L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+Q2hhbmdlZCBhbGwgaWRlbnRpZmllcnMgZnJv bSBJRCBhbmQgSURSRUYgdHlwZXMgdG8gYmUgUU5hbWVzIGVuYWJsaW5nIGdsb2JhbGx5IHVuaXF1 ZSBpZGVudGlmaWVycyBhbmQgZmxleGliaWxpdHkgZm9yIGRvbWFpbi1zcGVjaWZpYyB1c2VycyBv ZiBDeWJPWCB0byBkZWZpbmUgdGhlaXIgb3duIGlkZW50aWZpZXIgc3ludGF4IGxvY2FsbHkuPHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIic+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFy Z2luLWxlZnQ6MS4waW47dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwxIGxldmVsMSBsZm8z Jz48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTpTeW1ib2wnPjxzcGFuIHN0eWxlPSdtc28tbGlzdDpJZ25vcmUnPiZtaWRkb3Q7PHNw YW4gc3R5bGU9J2ZvbnQ6Ny4wcHQgIlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+ UmVvcmRlcmVkIGF0dHJpYnV0ZXMgYW5kIGVsZW1lbnRzIGluIG51bWVyb3VzIHR5cGVzIHRvIGJl dHRlciByZWZsZWN0IGNvbW1vbiB1c2FnZSBhbmQgcHJpb3JpdHkuPHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+PG86cD48L286 cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6MS4waW47 dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwxIGxldmVsMSBsZm8zJz48IVtpZiAhc3VwcG9y dExpc3RzXT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTeW1ib2wn PjxzcGFuIHN0eWxlPSdtc28tbGlzdDpJZ25vcmUnPiZtaWRkb3Q7PHNwYW4gc3R5bGU9J2ZvbnQ6 Ny4wcHQgIlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyA8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+QWRkZWQgbWFqb3JfdmVy c2lvbiBhbmQgbWlub3JfdmVyc2lvbiBhdHRyaWJ1dGVzIGZvciBjb3JlIHNjaGVtYS48c3BhbiBz dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi Jz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4t bGVmdDoxLjBpbjt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzMnPjwh W2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OlN5bWJvbCc+PHNwYW4gc3R5bGU9J21zby1saXN0Oklnbm9yZSc+Jm1pZGRvdDs8c3BhbiBz dHlsZT0nZm9udDo3LjBwdCAiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT5BZGRl ZCBjYXBhYmlsaXR5IHRvIGNoYXJhY3Rlcml6ZSBzb3VyY2Ugb2Ygb3ZlcmFsbCBvYnNlcnZhYmxl IHBhY2thZ2UgZGF0YSBhbmQgZm9yIGluZGl2aWR1YWwgb2JzZXJ2YWJsZXMuPHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+PG86 cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6 MS4waW47dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwxIGxldmVsMSBsZm8zJz48IVtpZiAh c3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpT eW1ib2wnPjxzcGFuIHN0eWxlPSdtc28tbGlzdDpJZ25vcmUnPiZtaWRkb3Q7PHNwYW4gc3R5bGU9 J2ZvbnQ6Ny4wcHQgIlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+TW9kaWZpZWQg dGhlIGxvZ2ljYWwgY29tcG9zaXRpb24gc3RydWN0dXJlIHN1Y2ggdGhhdCBhbnkgc3VjaCBjb21w b3NpdGlvbnMgYXJlIG5vdyBjb250YWluZWQgd2l0aGluIGEgT2JzZXJ2YWJsZV9Db21wb3NpdGlv biBlbGVtZW50IHByb3ZpZGluZyBpbXByb3ZlZCBzaW1wbGljaXR5IGFuZCBtb2R1bGFyaXR5Ljxz cGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiInPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21h cmdpbi1sZWZ0OjEuMGluO3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMSBsZXZlbDEgbGZv Myc+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6U3ltYm9sJz48c3BhbiBzdHlsZT0nbXNvLWxpc3Q6SWdub3JlJz4mbWlkZG90Ozxz cGFuIHN0eWxlPSdmb250OjcuMHB0ICJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZd PlJlbW92ZWQgdGhlIERlbHRhIGVsZW1lbnQgZnJvbSBPYnNlcnZhYmxlVHlwZSBhbmQgcmVsb2Nh dGVkIHRoZSBhcHByb3ByaWF0ZSBwb3J0aW9ucyAoQ2hhbmdlLCBUcmVuZCwgYW5kIEZyZXF1ZW5j eSkgdG8gYXBwcm9wcmlhdGUgbG9jYXRpb25zIHVuZGVyIFN0YXRlZnVsX01lYXN1cmUgYW5kIEV2 ZW50LjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiInPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5 bGU9J21hcmdpbi1sZWZ0OjEuMGluO3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMSBsZXZl bDEgbGZvMyc+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6U3ltYm9sJz48c3BhbiBzdHlsZT0nbXNvLWxpc3Q6SWdub3JlJz4mbWlk ZG90OzxzcGFuIHN0eWxlPSdmb250OjcuMHB0ICJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFb ZW5kaWZdPkFkZGVkIGEgRG9tYWluX1NwZWNpZmljX09iamVjdF9BdHRyaWJ1dGVzIGZpZWxkIHRv IE9iamVjdCB1dGlsaXppbmcgYW4gYWJzdHJhY3QgdHlwZSB0aGF0IHdpbGwgYWxsb3cgZG9tYWlu LXNwZWNpZmljIHVzZSBjYXNlcyB0byBhZGQgaW4gdGhlaXIgb3duIGRvbWFpbi1zcGVjaWZpYyBh dHRyaWJ1dGVzIGZvciBPYmplY3RzLjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiInPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBj bGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0OjEuMGluO3RleHQtaW5kZW50Oi0uMjVp bjttc28tbGlzdDpsMSBsZXZlbDEgbGZvMyc+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sJz48c3BhbiBzdHlsZT0nbXNv LWxpc3Q6SWdub3JlJz4mbWlkZG90OzxzcGFuIHN0eWxlPSdmb250OjcuMHB0ICJUaW1lcyBOZXcg Um9tYW4iJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFu Pjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPkFkZGVkIGEgVG9vbC1TcGVjaWZpY19EYXRhIGZpZWxk IHRvIFRvb2xJbmZvcm1hdGlvblR5cGUgdXRpbGl6aW5nIGFuIGFic3RyYWN0IHR5cGUgdGhhdCB3 aWxsIGFsbG93IGFkZGl0aW9uIG9mIHRvb2wtc3BlY2lmaWMgZGF0YS48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz48bzpwPjwv bzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDoxLjBp bjt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzMnPjwhW2lmICFzdXBw b3J0TGlzdHNdPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlN5bWJv bCc+PHNwYW4gc3R5bGU9J21zby1saXN0Oklnbm9yZSc+Jm1pZGRvdDs8c3BhbiBzdHlsZT0nZm9u dDo3LjBwdCAiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT5BZGRlZCBhbiBJbmRp Y2F0b3JzIGZpZWxkIHRvIE1lYXN1cmVTb3VyY2VUeXBlIHV0aWxpemluZyBhbiBhYnN0cmFjdCB0 eXBlIHRoYXQgd2lsbCBhbGxvdyBjaGFyYWN0ZXJpemluZyBkaWZmZXJpbmcgZm9ybWF0cyBvciBz dGFuZGFyZHMgb2YgaW5kaWNhdG9ycyB0aGF0IG1heSBoYXZlIGxlZCB0byB0aGUgaWRlbnRpZmlj YXRpb24gb2YgdGhlIG9ic2VydmFibGUgZGF0YS48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDoxLjBpbjt0ZXh0LWluZGVu dDotLjI1aW47bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzMnPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbCc+PHNwYW4gc3R5 bGU9J21zby1saXN0Oklnbm9yZSc+Jm1pZGRvdDs8c3BhbiBzdHlsZT0nZm9udDo3LjBwdCAiVGlt ZXMgTmV3IFJvbWFuIic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IDwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT5FbmhhbmNlZCB0aGUgSGFzaCBzdHJ1Y3R1 cmUgdG8gY2FwdHVyZSBmdWxsIGZ1enp5IGhhc2hlcyBpbiBhZGRpdGlvbiB0byBzaW1wbGUgaGFz aGVzPHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIic+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHls ZT0nbWFyZ2luLWxlZnQ6MS4waW47dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwxIGxldmVs MSBsZm8zJz48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTpTeW1ib2wnPjxzcGFuIHN0eWxlPSdtc28tbGlzdDpJZ25vcmUnPiZtaWRk b3Q7PHNwYW4gc3R5bGU9J2ZvbnQ6Ny4wcHQgIlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtl bmRpZl0+QWRkZWQgYSBuZXcgRXh0cmFjdGVkRmVhdHVyZXNUeXBlIHRoYXQgY2FuIGJlIHVzZWQg dG8gYWRvcm4gZGlmZmVyaW5nIG9iamVjdHMgKGUuZy4sIGZpbGVzLCBtZW1vcnksIGV0Yy4pIHRv IGNhcHR1cmUgZXh0cmFjdGVkIHN0cmluZ3MsIGltcG9ydHMsIGZ1bmN0aW9ucyBhbmQgY29kZSBz bmlwcGV0czxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiInPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwg c3R5bGU9J21hcmdpbi1sZWZ0OjEuMGluO3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMSBs ZXZlbDEgbGZvMyc+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sJz48c3BhbiBzdHlsZT0nbXNvLWxpc3Q6SWdub3JlJz4m bWlkZG90OzxzcGFuIHN0eWxlPSdmb250OjcuMHB0ICJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjwvc3Bhbj48L3NwYW4+ PCFbZW5kaWZdPkFkZGVkIGEgQnl0ZVJ1bnNUeXBlIHRvIGVuYWJsZSBjYXB0dXJlIG9mIGJ5dGUg cnVucyB3aXRoaW4gdmFyaW91cyBvYmplY3RzLjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiInPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0OjEuMGluO3RleHQtaW5kZW50 Oi0uMjVpbjttc28tbGlzdDpsMSBsZXZlbDEgbGZvMyc+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sJz48c3BhbiBzdHls ZT0nbXNvLWxpc3Q6SWdub3JlJz4mbWlkZG90OzxzcGFuIHN0eWxlPSdmb250OjcuMHB0ICJUaW1l cyBOZXcgUm9tYW4iJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg PC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPkFkZGVkIG9iamVjdF9yZWZlcmVuY2UgYXR0 cmlidXRlIHRvIERlZmluZWRPYmplY3RUeXBlIHRvIGJldHRlciBzdXBwb3J0IHJlZmVyZW5jaW5n IG9mIGluZGVwZW5kZW50bHkgZGVmaW5lZCBPYmplY3RzIGZyb20gd2l0aGluIGFub3RoZXIgT2Jq ZWN0IGRlZmluaXRpb24uPHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z b05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6MS4waW47dGV4dC1pbmRlbnQ6LS4yNWluO21zby1s aXN0OmwxIGxldmVsMSBsZm8zJz48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTeW1ib2wnPjxzcGFuIHN0eWxlPSdtc28tbGlzdDpJ Z25vcmUnPiZtaWRkb3Q7PHNwYW4gc3R5bGU9J2ZvbnQ6Ny4wcHQgIlRpbWVzIE5ldyBSb21hbiIn PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+PC9zcGFu Pjwvc3Bhbj48IVtlbmRpZl0+QWRkZWQgYSBnZW5lcmljIERhdGFTZWdtZW50VHlwZSB0byBwcm92 aWRlIGEgcmVsYXRpdmVseSBhYnN0cmFjdCB3YXkgb2YgY2hhcmFjdGVyaXppbmcgZGF0YSBzZWdt ZW50cyB0aGF0IG1heSBiZSB3cml0dGVuL3JlYWQvdHJhbnNtaXR0ZWQgb3Igb3RoZXJ3aXNlIHV0 aWxpemVkIGluIGFjdGlvbnMgb3IgZGVmaW5lZCBpbiBvYmplY3RzLjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiInPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD48ZGl2IHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz48cCBjbGFzcz1Nc29O b3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW47dGV4dC1pbmRlbnQ6LS4yNWluJz48c3BhbiBz dHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTeW1ib2wnPiZtaWRkb3Q7PC9zcGFu PjxzcGFuIHN0eWxlPSdmb250LXNpemU6Ny4wcHQnPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPWFwcGxlLWNvbnZlcnRlZC1zcGFjZT4mbmJzcDs8 L3NwYW4+PC9zcGFuPkFkZGVkIHNldmVyYWwgbmV3IGRlZmluZWQgb2JqZWN0IHNjaGVtYXMgKEFQ SSwgQ29kZSwgRGV2aWNlLCBETlNfUmVjb3JkLCBOZXR3b3JrX0Zsb3csIE5ldHdvcmtfUGFja2V0 LCBOZXR3b3JrX1JvdXRlX0VudHJ5LCBOZXR3b3JrX1N1Ym5ldCwgVW5peF9OZXR3b3JrX1JvdXRl X0VudHJ5KSBpbmNsdWRpbmcgYW4gaW5pdGlhbCBzZXQgb2YgbmV0d29yay1jZW50cmljIGRlZmlu ZWQgb2JqZWN0cy48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdCc+PG86cD48L286cD48L3Nw YW4+PC9wPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6MS4waW47 dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm82Jz48IVtpZiAhc3VwcG9y dExpc3RzXT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTeW1ib2wn PjxzcGFuIHN0eWxlPSdtc28tbGlzdDpJZ25vcmUnPiZtaWRkb3Q7PHNwYW4gc3R5bGU9J2ZvbnQ6 Ny4wcHQgIlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyA8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+TW9kaWZpZWQgZXZlcnkg ZGVmaW5lZCBvYmplY3Qgc2NoZW1hIHdpdGggYWRkZWQgYW5ub3RhdGlvbnMgYXMgd2VsbCBhcyBt aW5vciBhbmQgaW4gc29tZSBjYXNlcyBzdWJzdGFudGl2ZSBjaGFuZ2VzIHRvIGZpeCBlcnJvcnMs IGltcHJvdmUgY29uc2lzdGVuY3kgYW5kIGFsaWdubWVudCB3aXRoIGV4aXN0aW5nIG5vcm1hdGl2 ZSByZWZlcmVuY2VzLCBhbmQgdG8gaW1wcm92ZSBleHByZXNzaXZlbmVzcyBpbiBzdXBwb3J0IG9m IHRoZSB0YXJnZXRlZCB1c2UgY2FzZXMuPHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+PG86cD48L286cD48L3NwYW4+PC9wPjxk aXYgc3R5bGU9J21hcmdpbi1sZWZ0Oi4yNWluJz48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21h cmdpbi1sZWZ0Oi41aW4nPkRldGFpbGVkIGNoYW5nZXMgZnJvbSBDeWJPWF92MC43IHRvIEN5Yk9Y X3YxLjBfKERyYWZ0KTo8c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4nPlRoZSBsZXZlbCBvZiBj aGFuZ2VzIHdpdGhpbiB2MS4wIChEcmFmdCkgaW4gdGhlIGNvcmUgc2NoZW1hLCBjb21tb25fdHlw ZXMgYW5kIHRoZSBkZWZpbmVkIG9iamVjdCBzY2hlbWFzIGlzIHRvbyBncmVhdCB0byBsaXN0IGV2 ZXJ5IGNoYW5nZSBpbiB0aGVzZSByZWxlYXNlIG5vdGVzLiBEZXRhaWxlZCBkaWZmZXJlbmNlIHJl cG9ydHMgYXJlIGF2YWlsYWJsZSBmb3IgZWFjaCBpbmRpdmlkdWFsIHNjaGVtYSBhdDo8c3BhbiBz dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi Jz48YSBocmVmPSJodHRwOi8vY3lib3gubWl0cmUub3JnL1hNTFNjaGVtYS9yZWxlYXNlX25vdGVz L2N5Ym94X3YxLjAoZHJhZnQpX2RpZmZfcmVwb3J0cy56aXAiPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTIuMHB0O2ZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiInPmh0dHA6Ly9j eWJveC5taXRyZS5vcmcvWE1MU2NoZW1hL3JlbGVhc2Vfbm90ZXMvY3lib3hfdjEuMChkcmFmdClf ZGlmZl9yZXBvcnRzLnppcDwvc3Bhbj48L2E+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2Pjxk aXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHls ZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwg c3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiInPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD48L2Rpdj48ZGl2IHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz48cCBjbGFzcz1Nc29Ob3Jt YWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08L3NwYW4+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+ PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXYgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4n PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVpbic+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xv cjojMUY0OTdEJz5TZWFuIEJhcm51bTwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PC9kaXY+PGRpdiBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVpbic+PHAgY2xhc3M9TXNvTm9ybWFs IHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkN5YmVyIFNl Y3VyaXR5IFByaW5jaXBhbDwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9k aXY+PGRpdiBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVpbic+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxl PSdtYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlRoZSBNSVRSRSBDb3Jw b3JhdGlvbjwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdiBz dHlsZT0nbWFyZ2luLWxlZnQ6LjVpbic+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4t bGVmdDouNWluJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkVtYWlsOjxzcGFuIGNsYXNzPWFwcGxl LWNvbnZlcnRlZC1zcGFjZT4mbmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnNiYXJudW1AbWl0 cmUub3JnIj5zYmFybnVtQG1pdHJlLm9yZzwvYT48L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+PG86cD48L286cD48 L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVm dDouNWluJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiJz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PHAgY2xh c3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0nZm9udC1z aXplOjEzLjVwdDtmb250LWZhbWlseToiSGVsdmV0aWNhIiwic2Fucy1zZXJpZiInPl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPm1pbGUgbWFpbGluZyBs aXN0PGJyPjxhIGhyZWY9Im1haWx0bzptaWxlQGlldGYub3JnIj5taWxlQGlldGYub3JnPC9hPjxi cj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21pbGUiPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWlsZTwvYT48bzpwPjwvbzpwPjwv c3Bhbj48L3A+PC9kaXY+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVm dDouNWluJz48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48L2Rpdj48L2JvZHk+PC9odG1sPg== ------_=_NextPart_001_01CD1C4C.A5E487EB-- From sbarnum@mitre.org Mon Apr 16 21:52:36 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 613A621F8474; Mon, 16 Apr 2012 21:52:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NrbD2vEs1Vc4; Mon, 16 Apr 2012 21:52:31 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id E828121F84E4; Mon, 16 Apr 2012 21:52:29 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 5F05921B0E73; Tue, 17 Apr 2012 00:52:29 -0400 (EDT) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 43B2521B0E63; Tue, 17 Apr 2012 00:52:29 -0400 (EDT) Received: from IMCMBX03.MITRE.ORG ([169.254.3.179]) by IMCCAS02.MITRE.ORG ([129.83.29.79]) with mapi id 14.02.0283.003; Tue, 17 Apr 2012 00:52:28 -0400 From: "Barnum, Sean D." To: "Millar, Thomas" , "osantos@cisco.com" , "lnunez@c3isecurity.com" Thread-Topic: [sacm] [mile] CybOX v1.0 (Draft) is now released and live onthe website Thread-Index: AQHNHC91EoahZz2AEEqd+yKyGmroMJaeWIaQgAAIZb+AAA8foA== Date: Tue, 17 Apr 2012 04:52:27 +0000 Message-ID: <7F48813B48558A4BB5CB7BB714E5B5A9171B7C@IMCMBX03.MITRE.ORG> References: <7F48813B48558A4BB5CB7BB714E5B5A9171B16@IMCMBX03.MITRE.ORG> <69CE2DCD9DAC3D48B830E0723141170B02A39BD2@ZAU1UG-0308.DHSNET.DS1.DHS> In-Reply-To: <69CE2DCD9DAC3D48B830E0723141170B02A39BD2@ZAU1UG-0308.DHSNET.DS1.DHS> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [172.31.136.182] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_005F_01CD1C34.59077330" MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 17 Apr 2012 05:31:10 -0700 Cc: "idxwg@nicwg.org" , "mile@ietf.org" , "dallendoug@gmail.com" , "sacm@ietf.org" , "m-terada@ipa.go.jp" Subject: Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live onthe website X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 04:52:36 -0000 ------=_NextPart_000_005F_01CD1C34.59077330 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0060_01CD1C34.59077330" ------=_NextPart_001_0060_01CD1C34.59077330 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable It is not a euphemism for netflow. It is about all kinds of data flow not just network-related. It could be about ETL within a database or datawarehouse. It could be about data flow within an information system (perhaps = observable within an application log). It could be about data flow related to all sorts of forms of message = passing. It could be about data flow within data-driven reactive programming = software architectures. Etc., Etc. =E2=80=9CData Flow=E2=80=9D is a fairly abstract bucket acting as a = classifier for a broad range of potential event types.=20 Of course, we will seek to offer relevant lower abstraction buckets = within this broad bucket (e.g. =E2=80=9CPacket Traffic=E2=80=9D) to = offer more specific characterization where we have a clear understanding = of the sub-bucket but it is still useful to have the broader bucket = available to catch the things we do not have more specific sub-buckets = defined for yet. =20 Does that help clarify? =20 sean =20 From: Millar, Thomas [mailto:Thomas.Millar@hq.dhs.gov]=20 Sent: Monday, April 16, 2012 11:46 PM To: Barnum, Sean D.; osantos@cisco.com; lnunez@c3isecurity.com Cc: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; = m-terada@ipa.go.jp Subject: Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live = onthe website =20 If "data flow" is a euphemism for "netflow" is there any reason not to = call it that? Tom Millar=20 http://www.us-cert.gov/=20 ------------------=20 Missit me Rubus fruticosus:=20 202 631 1915=20 =20 From: Barnum, Sean D. [mailto:sbarnum@mitre.org]=20 Sent: Monday, April 16, 2012 11:29 PM To: Omar Santos (osantos) ; Luis Nunez = =20 Cc: idxwg@nicwg.org ; mile@ietf.org ; = dallendoug@gmail.com ; sacm@ietf.org = ; m-terada@ipa.go.jp =20 Subject: Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live = onthe website=20 =20 Thanks Omar. =20 To answer your question, first let me point out to other readers that = the two entries that Omar is quoting here exist as values in an = enumeration called EventTypeEnum which as its name implies contains a = list of different labels for grouping types (or classes) of events to be = used as low-granularity buckets for characterizing and classifying = events. Other entries in this enumeration include things like =E2=80=9CFile Ops = (CRUD)=E2=80=9D, =E2=80=9CProcess Mgt=E2=80=9D, =E2=80=9CAuthorization = (ACL)=E2=80=9D, etc. =20 The =E2=80=9CPacket Traffic=E2=80=9D value is intended to characterize = events dealing with network packet traffic as its name implies. The =E2=80=9CData Flow=E2=80=9D value is intended to characterize events = dealing with forms of data flow at a higher level of abstraction than = just packet traffic. The relationship between these two values could be = viewed as =E2=80=9CPacket Traffic=E2=80=9D being a more detailed form of = =E2=80=9CData Flow=E2=80=9D just as the values =E2=80=9CApp Layer = Traffic=E2=80=9D and =E2=80=9CHTTP Layer Traffic=E2=80=9D, also in this = enumeration, could be other levels in this same abstraction stack. The idea behind the varying levels of abstraction is to leave buckets = large enough to capture a wide variety of potential event types (e.g. = data flow events other than obvious things like packet traffic) but also = enable the use of smaller more specific buckets when they are = appropriate and commonly used. =20 Does this make sense?=20 =20 sean =20 From: Omar Santos (osantos) [mailto:osantos@cisco.com]=20 Sent: Monday, April 16, 2012 8:17 PM To: Luis Nunez; Barnum, Sean D. Cc: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; = m-terada@ipa.go.jp Subject: RE: [sacm] [mile] CybOX v1.0 (Draft) is now released and live = onthe website =20 I echo Luis=E2=80=99 comments. It is good to see the inclusion of = network objects. Quick question to the team related to your netflow = comment. =20 I am looking at: http://cybox.mitre.org/XMLSchema/cybox_core_v1.0%28draft%29.xsd =20 =E2=80=A6 and it looks that we renamed it to =E2=80=9CData = Flow=E2=80=9D? =20 Specifies the class of events dealing with = data flow. =20 =20 What is the difference between that and =E2=80=9CPacket = Traffic=E2=80=9D? =20 Specifies the class of events dealing with packet = traffic. =20 =20 =20 =20 Regards, Omar Santos Incident Manager, PSIRT Security Research and Operations Cisco Systems, Inc. Email: os@cisco.com Phone: +1 919 392 8635 PGP Key: 0x3AF27EDC Cisco.com - http://www.cisco.com Cisco Security Advisories and Notices - http://www.cisco.com/go/psirt This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message. For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html =20 From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of = Luis Nunez Sent: Monday, April 16, 2012 6:44 PM To: Barnum, Sean D. Cc: idxwg@nicwg.org; mile@ietf.org; Doug Wilson (dallendoug@gmail.com); = sacm@ietf.org; IPA-Masato Terada (m-terada@ipa.go.jp) Subject: Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live = onthe website =20 I like the inclusion of the network-centric objects. IPFIX (netflow) = will add an additional perspective from an incident information sharing = standpoint. =20 =20 -ln =20 On Apr 16, 2012, at 4:04 PM, Barnum, Sean D. wrote: =20 Hey everyone, =20 I just wanted to let you all know that CybOX v1.0 (Draft) content is now = live on the website. http://cybox.mitre.org The release notes are provided inline below. The key items of note are: =C2=B7 The release of two formal specifications for the CybOX = language (one for the core language and one for the defined objects) =C2=B7 The XML Schema has gone through extensive improvements for = expressiveness, clarity, consistency, efficiency, alignment to existing = normative references and documentation. =C2=B7 This release includes an initial set of language = utilities: a draft Snort -> CybOX transform, a draft OpenIOC -> CybOX = transform, and a set of Python bindings for the CybOX language. =C2=B7 The website now includes a small set of content examples. = This set will grow going forward. This release involved a lot of hard work from a diverse group of people. = Thank you all for your contributions and effort. We could not have done = it without you. We look forward to everyone=E2=80=99s feedback and collaboration as we = continue to improve and mature the CybOX language. =20 Sean Barnum =20 =20 =20 CybOX v1.0 (Draft) Release Notes The Version 1.0 (Draft) release of Cyber Observable eXpression = (CybOX=E2=84=A2) is intended as a draft release of an initial major = version of the CybOX Language that could be utilized for practical = operational use and integration into other standards efforts. This = release consists of three primary components: a pair of formal language = specifications for the core language content and defined objects = content, a set of language implementation XML schemas (core, = common_types, and ~70 defined object schemas), and a small initial set = of language utilities including an initial draft Snort->CybOX transform, = an initial draft OpenIOC->CybOX transform and a set of CybOX language = Python bindings. Recognizing that this is the first time that the formal = language specifications will be available for review and as such will = likely generate feedback from new stakeholders, this initial major = version is being released as a =E2=80=9Cdraft=E2=80=9D v1.0 with the = expectation of cycles of new feedback and revision before a = =E2=80=9Cfinal=E2=80=9D v1.0 is released. The CybOX v1.0 (Draft) XML schemas include a significant number of = changes from v0.7 to improve: =C2=B7 Clarity, documentation, and descriptive formality for = reference and implementation by other standards and users. =C2=B7 Consistency, simplicity, and efficiency. =C2=B7 Alignment (as appropriate) to existing normative = references. =C2=B7 Expressiveness of the schema to better support the broad = set of use cases it targets (malware characterization, indicator and = incident data sharing, event management, etc.) including the addition of = an initial set of network-related defined objects. Summary of changes from CybOX_v0.7 to CybOX_v1.0_(Draft): =C2=B7 Refinement of namespaces and schema locations for better = effectiveness and flexibility going forward. =C2=B7 Normalized all content according to an established set of = naming conventions. =C2=B7 Fully annotated all language items (types, attributes, = elements, etc.). =C2=B7 Moved several commonly leveraged types out of the core = schema and into common_types. =C2=B7 Achieved full typing of entire schema structure such that = all attributes and elements are definitively typed. =C2=B7 Changed all identifiers from ID and IDREF types to be = QNames enabling globally unique identifiers and flexibility for = domain-specific users of CybOX to define their own identifier syntax = locally. =C2=B7 Reordered attributes and elements in numerous types to = better reflect common usage and priority. =C2=B7 Added major_version and minor_version attributes for core = schema. =C2=B7 Added capability to characterize source of overall = observable package data and for individual observables. =C2=B7 Modified the logical composition structure such that any = such compositions are now contained within a Observable_Composition = element providing improved simplicity and modularity. =C2=B7 Removed the Delta element from ObservableType and = relocated the appropriate portions (Change, Trend, and Frequency) to = appropriate locations under Stateful_Measure and Event. =C2=B7 Added a Domain_Specific_Object_Attributes field to Object = utilizing an abstract type that will allow domain-specific use cases to = add in their own domain-specific attributes for Objects. =C2=B7 Added a Tool-Specific_Data field to ToolInformationType = utilizing an abstract type that will allow addition of tool-specific = data. =C2=B7 Added an Indicators field to MeasureSourceType utilizing = an abstract type that will allow characterizing differing formats or = standards of indicators that may have led to the identification of the = observable data. =C2=B7 Enhanced the Hash structure to capture full fuzzy hashes = in addition to simple hashes =C2=B7 Added a new ExtractedFeaturesType that can be used to = adorn differing objects (e.g., files, memory, etc.) to capture extracted = strings, imports, functions and code snippets =C2=B7 Added a ByteRunsType to enable capture of byte runs within = various objects. =C2=B7 Added object_reference attribute to DefinedObjectType to = better support referencing of independently defined Objects from within = another Object definition. =C2=B7 Added a generic DataSegmentType to provide a relatively = abstract way of characterizing data segments that may be = written/read/transmitted or otherwise utilized in actions or defined in = objects. =C2=B7 Added several new defined object schemas (API, Code, = Device, DNS_Record, Network_Flow, Network_Packet, Network_Route_Entry, = Network_Subnet, Unix_Network_Route_Entry) including an initial set of = network-centric defined objects. =C2=B7 Modified every defined object schema with added = annotations as well as minor and in some cases substantive changes to = fix errors, improve consistency and alignment with existing normative = references, and to improve expressiveness in support of the targeted use = cases. Detailed changes from CybOX_v0.7 to CybOX_v1.0_(Draft): The level of changes within v1.0 (Draft) in the core schema, = common_types and the defined object schemas is too great to list every = change in these release notes. Detailed difference reports are available = for each individual schema at: = = http://cybox.mitre.org/XMLSchema/release_notes/cybox_v1.0(draft)_diff_rep= orts.zip =20 =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Sean Barnum Cyber Security Principal The MITRE Corporation Email: sbarnum@mitre.org =20 _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile =20 ------=_NextPart_001_0060_01CD1C34.59077330 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

It is not a euphemism for netflow.

It is about all kinds of data flow not just = network-related.

It could be about ETL within a database or = datawarehouse.

It could be about data flow within an information system (perhaps = observable within an application log).

It could be about data flow related to all sorts of forms of message = passing.

It could be about data flow within data-driven reactive programming = software architectures.

Etc., Etc.

=E2=80=9CData Flow=E2=80=9D is a fairly abstract bucket acting as a = classifier for a broad range of potential event types. =

Of course, we will seek to offer relevant lower abstraction buckets = within this broad bucket (e.g. =E2=80=9CPacket Traffic=E2=80=9D) to = offer more specific characterization where we have a clear understanding = of the sub-bucket but it is still useful to have the broader bucket = available to catch the things we do not have more specific sub-buckets = defined for yet.

 

Does that help clarify?

 

sean

 

From:= = Millar, Thomas [mailto:Thomas.Millar@hq.dhs.gov]
Sent: = Monday, April 16, 2012 11:46 PM
To: Barnum, Sean D.; = osantos@cisco.com; lnunez@c3isecurity.com
Cc: idxwg@nicwg.org; = mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; = m-terada@ipa.go.jp
Subject: Re: [sacm] [mile] CybOX v1.0 = (Draft) is now released and live onthe = website

 

If "data flow" is a euphemism for "netflow" is = there any reason not to call it that?

Tom Millar
http://www.us-cert.gov/ =
------------------
Missit me Rubus fruticosus:
202 631 1915 =

 

From<= /b>: = Barnum, Sean D. [mailto:sbarnum@mitre.org]=
Sent: Monday, April 16, 2012 11:29 PM
To: Omar = Santos (osantos) <osantos@cisco.com>; Luis Nunez = <lnunez@c3isecurity.com> =
Cc: idxwg@nicwg.org = <idxwg@nicwg.org>; mile@ietf.org <mile@ietf.org>; dallendoug@gmail.com <dallendoug@gmail.com>; sacm@ietf.org <sacm@ietf.org>; m-terada@ipa.go.jp <m-terada@ipa.go.jp> =
Subject: Re: [sacm] [mile] CybOX v1.0 (Draft) is now released = and live onthe website
 

Thanks Omar.

 

To answer your question, first let me point out to other readers that = the two entries that Omar is quoting here exist as values in an = enumeration called EventTypeEnum which as its name implies contains a = list of different labels for grouping types (or classes) of events to be = used as low-granularity buckets for characterizing and classifying = events.

Other entries in this enumeration include things like =E2=80=9CFile = Ops (CRUD)=E2=80=9D, =E2=80=9CProcess Mgt=E2=80=9D, = =E2=80=9CAuthorization (ACL)=E2=80=9D, etc.

 

The =E2=80=9CPacket Traffic=E2=80=9D value is intended to = characterize events dealing with network packet traffic as its name = implies.

The =E2=80=9CData Flow=E2=80=9D value is intended to characterize = events dealing with forms of data flow at a higher level of abstraction = than just packet traffic. The relationship between these two values = could be viewed as =E2=80=9CPacket Traffic=E2=80=9D being a more = detailed form of =E2=80=9CData Flow=E2=80=9D just as the values = =E2=80=9CApp Layer Traffic=E2=80=9D and =E2=80=9CHTTP Layer = Traffic=E2=80=9D, also in this enumeration, could be other levels in = this same abstraction stack.

The idea behind the varying levels of abstraction is to leave =  buckets large enough to capture a wide variety of potential event = types (e.g. data flow events other than obvious things like packet = traffic) but also enable the use of smaller more specific buckets when = they are appropriate and commonly used.

 

Does this make sense?

 

sean

 

From:= = Omar Santos (osantos) [mailto:osantos@cisco.com]=
Sent: Monday, April 16, 2012 8:17 PM
To: Luis = Nunez; Barnum, Sean D.
Cc: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; m-terada@ipa.go.jp
Subject:<= /b> RE: [sacm] [mile] CybOX v1.0 (Draft) is now released and live onthe = website

 

I echo Luis=E2=80=99 comments. It is good to see the inclusion of = network objects. Quick question to the team related to your netflow = comment.

 

I am looking at:

= http://cybox.mitre.org/XMLSchema/cybox_core_v1.0%28draft%29.xsd<= /o:p>

 

=E2=80=A6 and it looks that we renamed it to =E2=80=9CData = Flow=E2=80=9D?

 

<xs:enumeration = value=3D"Data Flow">

   = <xs:annotation>

        = <xs:documentation>Specifies the class of events dealing with data = flow.</xs:documentation>

   = </xs:annotation>

</xs:enumeration>

 

 

What is the difference between that and =E2=80=9CPacket = Traffic=E2=80=9D?

 

<xs:enumeration value=3D"Packet =
Traffic">
   =
<xs:annotation>
     =
<xs:documentation>Specifies the class of events dealing with =
packet traffic.</xs:documentation>
   =
</xs:annotation>
</xs:enumeration>

 

 

 

 

Regards,

Omar Santos
Incident Manager, = PSIRT
Security Research and Operations
Cisco Systems, = Inc.
Email: os@cisco.com
Phone: +1 919 392 = 8635
PGP Key: 0x3AF27EDC

Cisco.com - http://www.cisco.com
Cisco Security = Advisories and Notices - http://www.cisco.com/go/psirt<= br>
This email may contain confidential and privileged material for = the sole
use of the intended recipient. Any review, use, distribution = or
disclosure by others is strictly prohibited. If you are not the = intended
recipient (or authorized to receive for the recipient), = please contact
the sender by reply email and delete all copies of = this message.

For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html=

 

From:= = sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.= org] On Behalf Of Luis Nunez
Sent: Monday, April = 16, 2012 6:44 PM
To: Barnum, Sean D.
Cc: idxwg@nicwg.org; mile@ietf.org; Doug Wilson (dallendoug@gmail.com); sacm@ietf.org; IPA-Masato Terada (m-terada@ipa.go.jp)
Subject:= Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live onthe = website

 

I like the inclusion of the network-centric = objects.  IPFIX (netflow)  will add an additional perspective = from an incident information sharing standpoint. =  

 

-ln

 

On Apr 16, 2012, at 4:04 = PM, Barnum, Sean D. wrote:

 

Hey = everyone,

 =

I just = wanted to let you all know that CybOX v1.0 (Draft) content is now live = on the website. http://cybox.mitre.org

The = release notes are provided inline = below.

The key = items of note are:

=C2=B7        The = release of two formal specifications for the CybOX language (one for the = core language and one for the defined = objects)

=C2=B7        The XML = Schema has gone through extensive improvements for expressiveness, = clarity, consistency, efficiency, alignment to existing normative = references and documentation.

=C2=B7        This = release includes an initial set of language utilities: a draft Snort = -> CybOX transform, a draft OpenIOC -> CybOX transform, and a set = of Python bindings for the CybOX language.

=C2=B7        The = website now includes a small set of content examples. This set will grow = going forward.

This = release involved a lot of hard work from a diverse group of people. = Thank you all for your contributions and effort. We could not have done = it without you.

We look = forward to everyone=E2=80=99s feedback and collaboration as we continue = to improve and mature the CybOX = language.

 =

Sean = Barnum

 =

 =

 =

CybOX v1.0 (Draft) Release = Notes

The Version 1.0 (Draft) release of Cyber = Observable eXpression (CybOX=E2=84=A2) is intended as a draft release of an initial major version of = the CybOX Language that could be utilized for practical operational use = and integration into other standards efforts. This release consists of = three primary components: a pair of formal language specifications for = the core language content and defined objects content, a set of language = implementation XML schemas (core, common_types, and ~70 defined object = schemas), and a small initial set of language utilities including an = initial draft Snort->CybOX transform, an initial draft = OpenIOC->CybOX transform and a set of CybOX language Python bindings. = Recognizing that this is the first time that the formal language = specifications will be available for review and as such will likely = generate feedback from new stakeholders, this initial major version is = being released as a =E2=80=9Cdraft=E2=80=9D v1.0 with the expectation of = cycles of new feedback and revision before a =E2=80=9Cfinal=E2=80=9D = v1.0 is released.=

The CybOX v1.0 (Draft) XML schemas include a = significant number of changes from v0.7 to improve:=

=C2=B7       Clarity, = documentation, and descriptive formality for reference and = implementation by other standards and users.=

=C2=B7       Consistency, = simplicity, and efficiency.=

=C2=B7       Alignment (as = appropriate) to existing normative references.=

=C2=B7       Expressiveness of the = schema to better support the broad set of use cases it targets (malware = characterization, indicator and incident data sharing, event management, = etc.) including the addition of an initial set of network-related = defined objects.=

Summary = of changes from CybOX_v0.7 to CybOX_v1.0_(Draft):=

=C2=B7        = Refinement of namespaces and schema = locations for better effectiveness and flexibility going forward.=

=C2=B7        = Normalized all content according to an = established set of naming conventions.=

=C2=B7        = Fully annotated all language items = (types, attributes, elements, etc.).=

=C2=B7        = Moved several commonly leveraged types = out of the core schema and into common_types.=

=C2=B7        = Achieved full typing of entire schema = structure such that all attributes and elements are definitively = typed.=

=C2=B7        = Changed all identifiers from ID and IDREF = types to be QNames enabling globally unique identifiers and flexibility = for domain-specific users of CybOX to define their own identifier syntax = locally.=

=C2=B7        = Reordered attributes and elements in = numerous types to better reflect common usage and priority.=

=C2=B7        = Added major_version and minor_version = attributes for core schema.=

=C2=B7        = Added capability to characterize source = of overall observable package data and for individual observables.=

=C2=B7        = Modified the logical composition = structure such that any such compositions are now contained within a = Observable_Composition element providing improved simplicity and = modularity.=

=C2=B7        = Removed the Delta element from = ObservableType and relocated the appropriate portions (Change, Trend, = and Frequency) to appropriate locations under Stateful_Measure and = Event.=

=C2=B7        = Added a Domain_Specific_Object_Attributes = field to Object utilizing an abstract type that will allow = domain-specific use cases to add in their own domain-specific attributes = for Objects.=

=C2=B7        = Added a Tool-Specific_Data field to = ToolInformationType utilizing an abstract type that will allow addition = of tool-specific data.=

=C2=B7        = Added an Indicators field to = MeasureSourceType utilizing an abstract type that will allow = characterizing differing formats or standards of indicators that may = have led to the identification of the observable data.=

=C2=B7        = Enhanced the Hash structure to capture = full fuzzy hashes in addition to simple hashes=

=C2=B7        = Added a new ExtractedFeaturesType that = can be used to adorn differing objects (e.g., files, memory, etc.) to = capture extracted strings, imports, functions and code snippets=

=C2=B7        = Added a ByteRunsType to enable capture of = byte runs within various objects.=

=C2=B7        = Added object_reference attribute to = DefinedObjectType to better support referencing of independently defined = Objects from within another Object definition.=

=C2=B7        = Added a generic DataSegmentType to = provide a relatively abstract way of characterizing data segments that = may be written/read/transmitted or otherwise utilized in actions or = defined in objects.=

=C2=B7        Added several new = defined object schemas (API, Code, Device, DNS_Record, Network_Flow, = Network_Packet, Network_Route_Entry, Network_Subnet, = Unix_Network_Route_Entry) including an initial set of network-centric = defined objects.

=C2=B7        = Modified every defined object schema with = added annotations as well as minor and in some cases substantive changes = to fix errors, improve consistency and alignment with existing normative = references, and to improve expressiveness in support of the targeted use = cases.=

Detailed changes from CybOX_v0.7 to = CybOX_v1.0_(Draft):=

The level of changes within v1.0 (Draft) in = the core schema, common_types and the defined object schemas is too = great to list every change in these release notes. Detailed difference = reports are available for each individual schema at:http://cybox.mitre.org/XMLSchema/release_notes/cybox_v1.0= (draft)_diff_reports.zip

 =

 =

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

Sean Barnum=

Cyber Security Principal=

The MITRE Corporation=

 =

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

 

------=_NextPart_001_0060_01CD1C34.59077330-- ------=_NextPart_000_005F_01CD1C34.59077330 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIYNDCCBS0w ggMVoAMCAQICEEw6UhQhT9OgRBVHf7KQ+1AwDQYJKoZIhvcNAQELBQAwKTEnMCUGA1UEAxMeTUlU UkUgQ29ycG9yYXRpb24gUEUgUm9vdCBDQS0xMB4XDTExMDQyNjE5NDU0NVoXDTIxMDQyNjE5NDgy MlowKTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUEUgUm9vdCBDQS0xMIICIjANBgkqhkiG 9w0BAQEFAAOCAg8AMIICCgKCAgEAtp8hR0hRq3im+Alwfb5ZHGP5k2OSY2TlVHYHIMUDH3MfW7b6 8lB3j3MwAMsxGK1ke/t6O4K0t9wRH4QDgOQ1CthmOGZW7xiN81h0vP1Yf14SNugUa7ZvH9KP3iXs y8QnOHal1bKf0Pa9KXib58qUuwfaZSCTW5P2ekqd8z4TETvfBWvPgDxyxnVsiAO6yL9WaRpMiSVM hYLWy3KRuU/gue0bVEi+qdg+hENh1NSNXpoqseS262nq5cx5wybR/PF0YstQ9NNlYDM5cLECKYHH zD6cXKJozuFXriswlE8rdna7VaxyZrfgC0ueEIY/tsj/65IyUhyPBwO0ZpW+Ls9Cd4Y+ERSu5mR5 Fd8w42eVzuosmk3s3AxrKC+Z4tXYkjaiWUduIegAiST1vJBwkS53vR+zrBX3Ep56l7MFVvW/GcsZ 9wUT2HG65JOeiVc2YzCEqLgQ3ZCBHn09oBag2lnMac+E2sKm9aKL3xzHs6cyD8qCJK9O8QLCqo3C mzASlOwtTFiLYgpPW/MSmgYOt9JrwHAzk97DHFKTFttjrXGMmhMVzadt1EjMn1Wv8t5WLBI0qSoX /MYi2CaeiDsEiWRu9Nmpu3pmi8m7tIR9csdbAVPks2soNMWOopGEpFQSDvU1+m77v2jIKQKYxYmN 2zUOJ4TJFL1osnZ/71MmLCDVd+ECAwEAAaNRME8wCwYDVR0PBAQDAgGGMA8GA1UdEwEB/wQFMAMB Af8wHQYDVR0OBBYEFFuHfZ/+bL4C6fPgKTqKVCUsnzgvMBAGCSsGAQQBgjcVAQQDAgEAMA0GCSqG SIb3DQEBCwUAA4ICAQAy78sXsP/eqHH8/uOYyxQ6TBDhkCBxNoy8MF2c9UDns5ADL1qyxPAlpDBs L+2h1Zzt3FvPjg0SoRE/9juyG1qxMzhlv0jdQx12tESdo3uBb61b1uuc4H/VxCJWDI4KZL/B53EI 8HGPjUBdLADgOmG99uffm5uarSkjtIX//Bz3U6QfzTPlVWFi4SmzRI2mp16GQ8RPuJ/WMloaAn8X H6EjS2oLjGZC8Pw8/C46W48NvZ1JZTrZvYZr7GmuvmplYK68SZv/T5Su+FlLRTy9uNXQLHtm6jKv nDH2yB66zTwfaDpnjILnrC2O7ANRVZc0KywiKiW3nB7Joq74/XVuMI1PiSByt2Qu+RIS/WAI5wMi bTmwSiBxQZqvuth+dXoakJyOP2Wg5jvL55v9RLZhDqMtRI5ovnOFvTgNJQqNPSekGtA+m6Ctl/vh kSg65FFCMhaSkn7vY2Il+R8HouWJN8wTaudeexnyHcD+Mlt8QaB5CErpDjeeGZfQ0FcYm+6TtlMz Dw5eFhT/J6QrABCxfgLkVFHurMcQD4JkmXXkq5bP+GNkY0Uy2LMbw/UD94OEV1LpfAqUkT+mu5Yb vxg+elFtsad+Ix8owW372xynIADh9q1bHm+j1OHPJmGALWK9miRpC4t3isfu3ZB0QpI/e2Po6MED 393Jb0YbzrcElFv6ZDCCBhYwggP+oAMCAQICChrDbcgAAgAAN/wwDQYJKoZIhvcNAQEFBQAwUDET MBEGCgmSJomT8ixkARkWA09SRzEVMBMGCgmSJomT8ixkARkWBU1JVFJFMSIwIAYDVQQDExlNSVRS RSBDb3Jwb3JhdGlvbiBQRSBDQS0xMB4XDTEyMDMxMjE1MTgyN1oXDTE1MDMxMjE1MTgyN1owSjEL MAkGA1UEBhMCVVMxDjAMBgNVBAoTBU1JVFJFMQ8wDQYDVQQLEwZQZW9wbGUxGjAYBgNVBAMTEUJh cm51bS5TZWFuLjMxNTQzMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA9/I6RU7OcouL 6lcEJMAg8G3myNbQu84QnflS8p3PWOjgC6P50RDqGX5UxelDqMQPN5IsNYRXVY9/b7yN/RSH4goI JfYKMitndKuCKz1q38Nh0YycEm5x2t/IN/60b01T1uOmhZfptLDoDzj0UQZwMQ19mhM/ldsrC8bR GGuHXdQVaSyXygfhzNhqC06vZo5fvCBUJ6z7JtVrfRTHdudg19JYK+gds9p+Lvp/DOEXQmgpfpMl jfNKMnrG+kPMMngrIJUsF5lcbhHuc5mO+O8eR8FxM2KF7gfKVmUmZxs7Y6uLenVJVEmllP0XgUu1 sv3bClFgUo5x5Aq6rXshtHuVuQIDAQABo4IB9jCCAfIwKAYDVR0lBCEwHwYIKwYBBQUHAwQGCSsG AQQBcwIBBwYIKwYBBQUHAwIwHQYDVR0OBBYEFDvU1Ph/OVxGkxRmwvRx1TBf5PKqMA4GA1UdDwEB /wQEAwIGwDAcBgNVHREEFTATgRFzYmFybnVtQG1pdHJlLm9yZzAfBgNVHSMEGDAWgBRpZyAh1EjB 0BsGbvMIKOI6gn1BMTBJBgNVHR8EQjBAMD6gPKA6hjhodHRwOi8vcGtpLm1pdHJlLm9yZy9NSVRS RSUyMENvcnBvcmF0aW9uJTIwUEUlMjBDQS0xLmNybDB/BggrBgEFBQcBAQRzMHEwRwYIKwYBBQUH MAKGO2h0dHA6Ly9wa2kubWl0cmUub3JnL01JVFJFJTIwQ29ycG9yYXRpb24lMjBQRSUyMENBLTEo MikuY3J0MCYGCCsGAQUFBzABhhpodHRwOi8vb2NzcC5taXRyZS5vcmcvb2NzcDA+BgkrBgEEAYI3 FQcEMTAvBicrBgEEAYI3FQiDrqwjho6WV4GNiT2CpKsShb6uAYE2g9KXfYeg+0kCAWQCAQcwFgYD VR0gBA8wDTALBgkrBgEEAXMCAQgwNAYJKwYBBAGCNxUKBCcwJTAKBggrBgEFBQcDBDALBgkrBgEE AXMCAQcwCgYIKwYBBQUHAwIwDQYJKoZIhvcNAQEFBQADggIBAC2wqKo7QWQxIqnEKRznPrAQ5vQ9 X5JhB5keH8KMWu1W5n1RuSZH+3TYp4xccdYh+rV5b5+cJcWEYhtYpZriWm4kMHPaB6gKO9rbVfF9 R8Wp8sXvCKogbNhdkZwvXW4QymB1ASlMzDI1cCV8mzYgbIhWaCbV1zZBUVgOGa4LZIgdbdmgo5r/ O2gmnSftTYiE/tQ+DBs/25Bw/jC5HOiMXJqr+JctzJTqpEVLa7GKHnXWGuzGEPYkKBplxIyhz3Mv qc/yuKM7tZzAr8Qn5qf7VI9O2xp56QLjT2+mySOUR6Vml860FMpjjgZNMxAqOJt7OgY0PoUU9d18 yw1wiKSt0LUQoMcVvp7FifBjtBCG1sB/VOzxNvcNm6lO6EO23pvcjt6+WCG1X3pgnZ5UEohsM3c0 oLzYiuSYeVf85IO2yh9fWLWw2RGkf2szck1Xg0DsAQ54/YlZYyehELh43KbS3lpnTt8UlO7C0TMT 7JQwz4fTQg1a0e9rRPFnNDUG2fS2k3tz9IYILDB3F8uiZzzXptEzaYqzIqe5CK8ZGJQcw+w/CBen 6i+MV/y7yJmhio43Y1x9hIqoynqoSMV3CKYCoOwCvFUAGsNllDpExsQZoXrdd5gcuglqbh3t8wOM jtXDSQllQ/hXDZJf8rnH0wGx3K+WA+LKNvKqNCw9spEtsfG0MIIGYjCCBEqgAwIBAgIKFJcW0gAA AAAABDANBgkqhkiG9w0BAQsFADApMScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQRSBSb290 IENBLTEwHhcNMTEwNjE0MTc0NDQ0WhcNMTcwNjE0MTc1NDQ0WjBQMRMwEQYKCZImiZPyLGQBGRYD T1JHMRUwEwYKCZImiZPyLGQBGRYFTUlUUkUxIjAgBgNVBAMTGU1JVFJFIENvcnBvcmF0aW9uIFBF IENBLTEwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDSxK9RXieqdTz4JWRkRMs/EOuF 0P0S9SbspadLJkx/LDDnaAwmAnqfqm1n7/p82oVjy1yCye3SZu4Yp7fmDIAtWbkHvYOfxHkRv1ho /fhaNN0YRkd65oJJz2ngEbNZxdIiCoialQfX/iWU7ApQ+ovKbFV60v5E0p2mPncs20NYRfsaetdh nBZbFD9flDcXwJqSvGGGBfm7ifFCR1LrtEcNKjMwf7YEWZO0Vk3ZyhVq+k7JNLEbKv0OfBz8DU8G iGU+j88QlrgGW8PLkwNk7nsS/DJp8aLudTuVqIE2CA9mqn5QjU/EZYNHGzSfCr+/usUmbojyVSJu khhrAXspRAMz+Cia3yi3q3w8TnAljXWN1dhx1iuUv5GxyzMjfqK1tMuCUU2XzGNNqoVa1mqolBiy DTCOr9d/IC0YHYMBSpQ+xi0x9zjXKt4FmQmkEAZgF4hsZZqcJYL/iCQiwiz8fEyVPZuvoWvdEXOo zFYCpmkT0MZCJwyIux0Z6vJp6VLtN/6rZgc2y54HlTrp3ifazmpsfrk3NdHxlZTZug9kjEI+vEoy p/79nAPyTWQQ1MEP0ErCWav80/HOi0MLx/7lIUfvVOjkOFgFb+iDvR4T3RAQrnEpgTO+fc7Jyzh9 LpFDqm0slwDP4Hj9cC3IzdED5BU43PGAe+HoZ8OD/1ovVgwo/wIDAQABo4IBYzCCAV8wEAYJKwYB BAGCNxUBBAMCAQIwIwYJKwYBBAGCNxUCBBYEFFCiOtgZb+Zdflkw5sC2y01sUQaVMB0GA1UdDgQW BBRpZyAh1EjB0BsGbvMIKOI6gn1BMTAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTALBgNVHQ8E BAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAfBgNVHSMEGDAWgBRbh32f/my+Aunz4Ck6ilQlLJ84LzBQ BgNVHR8ESTBHMEWgQ6BBhj9odHRwOi8vcGtpLm1pdHJlLm9yZy9NSVRSRSUyMENvcnBvcmF0aW9u JTIwUEUlMjBSb290JTIwQ0EtMS5jcmwwWwYIKwYBBQUHAQEETzBNMEsGCCsGAQUFBzAChj9odHRw Oi8vcGtpLm1pdHJlLm9yZy9NSVRSRSUyMENvcnBvcmF0aW9uJTIwUEUlMjBSb290JTIwQ0EtMS5j cnQwDQYJKoZIhvcNAQELBQADggIBAHnDPfdYKxqNOtAYXMyyel83Vs8cCDAQZhSuIB0c6GkGoEdF rmWH9pwi42V96rCp7TvbNNKNJXbVHfJUAp+uqw663DL/sXXff9ZFxPxKOdPnpA8cKM7RBH9e437N w3d28A7PaGbP6tXmSqhXAhYZ4U12y1U5cOf2G/phUoAAMlnVJdfmXzMazvLo2SIeixAJyCze6rHQ TFQ/N+gAjbVuRJ+Hs8FEKVzMSwqlNoupe2ELqL4dMAKT6P08sAfxm2SrRlQvcWPYvqM/1C10bgc2 tdu+WGzRuP5Wx9Yr15KO9SW4z7fn2RVEXQgoDDno5vCIcfUPuKB5n+Kt9eBCitsgSD9yYsNUN9LE VIvjAb8MV2LWLfge1bumo6g7QMRa4Fgifw5siGwi7V2EaJQo6UAIVvxKKFC7W4p6CkrY2ga1d7GI Q0DPiWZOezOakJVAxL5gf+3WdNt0igKc/yLfbdHn6hCd1KPgDqkSKr8zWOZI/jiDBW957xAmaO6Q dGQDBZrQHWpIVwQGzF5bGrqms2kq49l3t7KmBu0C/9tExqKAmlf4Y5lfQGdCbKQpAq712DVQHYuD XmVQEAc2vlJ1C5hS3Iw9DwBWTfJ4vyB48buhBhbIhPiFta5OizXlKcsIi99ikA1yiZx/DBtjaw4J U6qJzWUFB2ecyGCNPtNbYjURA0A9MIIGfzCCBGegAwIBAgIKGsNq2wACAAA3+jANBgkqhkiG9w0B AQUFADBQMRMwEQYKCZImiZPyLGQBGRYDT1JHMRUwEwYKCZImiZPyLGQBGRYFTUlUUkUxIjAgBgNV BAMTGU1JVFJFIENvcnBvcmF0aW9uIFBFIENBLTEwHhcNMTIwMzEyMTUxODI3WhcNMTUwMzEyMTUx ODI3WjBKMQswCQYDVQQGEwJVUzEOMAwGA1UEChMFTUlUUkUxDzANBgNVBAsTBlBlb3BsZTEaMBgG A1UEAxMRQmFybnVtLlNlYW4uMzE1NDMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCW InZvCSslmSfSyhTVVSqnokCDajlsCNZHfUlkwkV1++2O71BYvMpjFHWR2XFIx963Hl63lFZzzVci OjIwLb1c/0YXhFfUdAvrbpjlu+ttlO05OEUW0h+5HO+qaebJPamxA00w0bokquRcPxUvwa3jiyL0 WfCwE3+/b5PCOW2xh7FXFKv262FnKIwxnQGXqkiXRP5D/SmdtcZSzxHkDThrhaiHPhJJhZ4XxwBk aGcAlMg8YH6uxshXm8e6c7XUu7gB5p+XThS0dqXujpQp/UQDp5t079+UrDcrpjfDBXIt9qCzLn26 uV5a4cD4xRKwA32f1cXFtiKXM0wYgUM3fEPDAgMBAAGjggJfMIICWzATBgNVHSUEDDAKBggrBgEF BQcDBDCBlAYJKoZIhvcNAQkPBIGGMIGDMA4GCCqGSIb3DQMCAgIAgDAOBggqhkiG9w0DBAICAIAw BwYFKw4DAgcwCgYIKoZIhvcNAwcwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBLTALBglghkgBZQME ARYwCwYJYIZIAWUDBAEZMAsGCWCGSAFlAwQBAjALBglghkgBZQMEAQUwHQYDVR0OBBYEFIrbKa+E Rxo2/Sth2C6jZqZqvRE7MA4GA1UdDwEB/wQEAwIFIDAcBgNVHREEFTATgRFzYmFybnVtQG1pdHJl Lm9yZzAfBgNVHSMEGDAWgBRpZyAh1EjB0BsGbvMIKOI6gn1BMTBJBgNVHR8EQjBAMD6gPKA6hjho dHRwOi8vcGtpLm1pdHJlLm9yZy9NSVRSRSUyMENvcnBvcmF0aW9uJTIwUEUlMjBDQS0xLmNybDB/ BggrBgEFBQcBAQRzMHEwRwYIKwYBBQUHMAKGO2h0dHA6Ly9wa2kubWl0cmUub3JnL01JVFJFJTIw Q29ycG9yYXRpb24lMjBQRSUyMENBLTEoMikuY3J0MCYGCCsGAQUFBzABhhpodHRwOi8vb2NzcC5t aXRyZS5vcmcvb2NzcDA+BgkrBgEEAYI3FQcEMTAvBicrBgEEAYI3FQiDrqwjho6WV4GNiT2CpKsS hb6uAYE2hquSaISo7EUCAWQCAQ8wFgYDVR0gBA8wDTALBgkrBgEEAXMCAQgwGwYJKwYBBAGCNxUK BA4wDDAKBggrBgEFBQcDBDANBgkqhkiG9w0BAQUFAAOCAgEAGmmL43yA+J5lEockM1cxSoyxfSES HUGLVJyrhObbdFD4yO3jf0R4lHLuJlhp1486d9LRZAyzAnl9q8Zf3Tx1rl1kEd3pw0wMuO+ATscc rArEW/rJxjz6zTrNO3PFkFuOEdmKpHaRiFpuSX602INiBEBPluei3uZlWxHW9VqC7hz2diQpOlzS jtPMbL3o7ACjWaq7sQ0xB4rZ6oWyqOZEfHWQA1b7nFgL4nEbmEHNdU4jAjcxkROku4O04205kb5n Loveoz3TSQNt8zalFayZAjt+JEcKuG1f5cyhYI6QwvkS/3M+CjJezuNaSmno29Lm+ToZnwUm4nIB YkBx4r9ZDU2W8029tr5og00A5MGo1LK+unWtHBa7zuPblfSiYgXIHWU+OKrSFaA935Yb4fLXFe9S BmApBr1gohHYos1hct5q90WPufSKIQ9WT+vJYXvW3FpseO4ZLKVnJsO7gVoQEEnWJUwyABBPQrii F0gh++ApKZJROTuR36PsEEx4duI6U4VXMCiIcnEjvNR8Mt5Q/Vp4W4Mp5fCv+QzYkqq9EWD7QuUW Yul6R8Hf7ZTxbUk0NfJgu8escLrgQSwMdP/kE/09vJAAslQBkNnIS7iIhWt4l5XQJBrJc+6popRE R8ykWf25e4CliaUgbAl1tBQKivQ3tlX99WykI2XK3sTk9nsxggMjMIIDHwIBATBeMFAxEzARBgoJ kiaJk/IsZAEZFgNPUkcxFTATBgoJkiaJk/IsZAEZFgVNSVRSRTEiMCAGA1UEAxMZTUlUUkUgQ29y cG9yYXRpb24gUEUgQ0EtMQIKGsNtyAACAAA3/DAJBgUrDgMCGgUAoIIBmjAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjA0MTcwNDUyMjJaMCMGCSqGSIb3DQEJBDEW BBQ2/2p5eyn1OdOJf+igIyphE3O8wzBbBgkqhkiG9w0BCQ8xTjBMMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMC GjBtBgkrBgEEAYI3EAQxYDBeMFAxEzARBgoJkiaJk/IsZAEZFgNPUkcxFTATBgoJkiaJk/IsZAEZ FgVNSVRSRTEiMCAGA1UEAxMZTUlUUkUgQ29ycG9yYXRpb24gUEUgQ0EtMQIKGsNq2wACAAA3+jBv BgsqhkiG9w0BCRACCzFgoF4wUDETMBEGCgmSJomT8ixkARkWA09SRzEVMBMGCgmSJomT8ixkARkW BU1JVFJFMSIwIAYDVQQDExlNSVRSRSBDb3Jwb3JhdGlvbiBQRSBDQS0xAgoaw2rbAAIAADf6MA0G CSqGSIb3DQEBAQUABIIBAFuRmex2OLXGWaQKy8DpGgjhNbykeWhN8CUZYbL2wPL6w9j8nVmR8ftP guYaRc/cu3Kleh1HP9gDuKoQin2mksbV/cpXnjDnt3KXbaEHg/HaPjjFwH1NNwd930xuwfefDEbv XnYZg5pO6pUEXmaqSWsW+p60kCZl0rwnehAaz53emrDcDuIE971bQzAZPiUt/aBpimATcY/+sQmM SEJ7Onz19i0f97ZyOQ6aOH0pDpwRzFb2LCAZXS0V28WJdeOCFrnIEprA1ezUwuH30xtW6wj/UJnX Ti8GNA+YzOcH3PnyskowNQyjdgHC9dOs9SdsvfoyFykQQWhOLL/SSnLkHfgAAAAAAAA= ------=_NextPart_000_005F_01CD1C34.59077330-- From sbarnum@mitre.org Mon Apr 16 22:09:42 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B430121F8609; Mon, 16 Apr 2012 22:09:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QUmy0LAOHoPn; Mon, 16 Apr 2012 22:09:37 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 22ACF21F8608; Mon, 16 Apr 2012 22:09:37 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 85F9F21B0E86; Tue, 17 Apr 2012 01:09:36 -0400 (EDT) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 6112321B0E73; Tue, 17 Apr 2012 01:09:36 -0400 (EDT) Received: from IMCMBX03.MITRE.ORG ([169.254.3.179]) by IMCCAS01.MITRE.ORG ([129.83.29.78]) with mapi id 14.02.0283.003; Tue, 17 Apr 2012 01:09:35 -0400 From: "Barnum, Sean D." To: "Omar Santos (osantos)" , "Millar, Thomas" , "lnunez@c3isecurity.com" Thread-Topic: [sacm] [mile] CybOX v1.0 (Draft) is now released and live onthe website Thread-Index: AQHNHC91EoahZz2AEEqd+yKyGmroMJaeWIaQgAAIZb+AAAIPgIAAEJ3A Date: Tue, 17 Apr 2012 05:09:35 +0000 Message-ID: <7F48813B48558A4BB5CB7BB714E5B5A9171BA1@IMCMBX03.MITRE.ORG> References: <7F48813B48558A4BB5CB7BB714E5B5A9171B16@IMCMBX03.MITRE.ORG> <69CE2DCD9DAC3D48B830E0723141170B02A39BD2@ZAU1UG-0308.DHSNET.DS1.DHS> <953A2E460DBE7C43AC13E30B87C5B4FF080A1C09@XMB-RCD-106.cisco.com> In-Reply-To: <953A2E460DBE7C43AC13E30B87C5B4FF080A1C09@XMB-RCD-106.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [172.31.136.182] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0066_01CD1C36.BDA3E920" MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 17 Apr 2012 05:31:10 -0700 Cc: "idxwg@nicwg.org" , "mile@ietf.org" , "dallendoug@gmail.com" , "sacm@ietf.org" , "m-terada@ipa.go.jp" Subject: Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live onthe website X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 05:09:42 -0000 ------=_NextPart_000_0066_01CD1C36.BDA3E920 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0067_01CD1C36.BDA3E920" ------=_NextPart_001_0067_01CD1C36.BDA3E920 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable =E2=80=9Cupper layer=E2=80=9D? Yes, as in higher abstraction. Just =E2=80=9Cprotocols=E2=80=9D? No. =20 You guys have been looking at this through the lens of network flow = which if fine for thinking about that perspective but it is important to = also realize that the EventTypeEnum and its =E2=80=9CData Flow=E2=80=9D = value go far beyond network-related scope. It is about a lot of other types of potential data flows (as I just = outlined in a response to Tom) that have nothing to do with network = flow. =20 Thanks for your response though. This is the kind of discussions that we = hope to have a lot more of among the various supported communities. =20 =20 BTW, you may have noticed that the Network_Flow object within CybOX v1.0 = (Draft) supports expression of netflow within several of the most common = formats including Netflow9 (as well as IPFIX as Luis pointed out, = Netflow5 and SiLK as well as bi-directional flow in YAF). The common = 5-tuple or 7-tuple (you describe) (in our case it is an 8-tuple as we = broke the router interface out into both ingress and egress J) shared by = pretty much all of the netflow approaches has been broken out into a = shared Network_Flow_Label structure. The various context-dependent = portions of the independent approaches are then captured within optional = structures dedicated to each of them. We hope that eventually the = community can work to come together towards a single overall common = expressive structure for netflow that meets the needs of all. We hope = that CybOX and its use can even help that sort of maturation and = normalization. But since no such universal structure exists today, we = decided to enable optional expression of the most common individual = formats within a single netflow object to serve the large majority of = relevant users, maintain flexibility and enable discussions and analysis = of netflow within a common package. We look forward to continuing discussions with the community to validate = or invalidate this approach and to refine and mature going forward. =20 Sean=20 =20 From: Omar Santos (osantos) [mailto:osantos@cisco.com]=20 Sent: Monday, April 16, 2012 11:57 PM To: Millar, Thomas; Barnum, Sean D.; lnunez@c3isecurity.com Cc: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; = m-terada@ipa.go.jp Subject: RE: [sacm] [mile] CybOX v1.0 (Draft) is now released and live = onthe website =20 I believe that what Sean is saying is that =E2=80=9Cdata flow=E2=80=9D = is just a value that is meant for upper layer protocols. But, you have a = good point. Traditionally, a =E2=80=9Cflow=E2=80=9D in = =E2=80=9CNetflow=E2=80=9D is based on a set of 5 and up to 7 IP packet = attributes: =20 - IP source address - IP destination address - Source port - Destination port - Layer 3 protocol type - Class of Service - Router or switch interface =20 Although, there is a lot more support with Netflow version 9: http://www.cisco.com/en/US/technologies/tk648/tk362/technologies_white_pa= per09186a00800a3db9_ps6601_Products_White_Paper.html =20 =20 =20 Regards, Omar=20 =20 From: Millar, Thomas [mailto:Thomas.Millar@hq.dhs.gov]=20 Sent: Monday, April 16, 2012 11:46 PM To: sbarnum@mitre.org; Omar Santos (osantos); lnunez@c3isecurity.com Cc: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; = m-terada@ipa.go.jp Subject: Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live = onthe website =20 If "data flow" is a euphemism for "netflow" is there any reason not to = call it that? Tom Millar=20 http://www.us-cert.gov/=20 ------------------=20 Missit me Rubus fruticosus:=20 202 631 1915=20 =20 From: Barnum, Sean D. [mailto:sbarnum@mitre.org]=20 Sent: Monday, April 16, 2012 11:29 PM To: Omar Santos (osantos) ; Luis Nunez = =20 Cc: idxwg@nicwg.org ; mile@ietf.org ; = dallendoug@gmail.com ; sacm@ietf.org = ; m-terada@ipa.go.jp =20 Subject: Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live = onthe website=20 =20 Thanks Omar. =20 To answer your question, first let me point out to other readers that = the two entries that Omar is quoting here exist as values in an = enumeration called EventTypeEnum which as its name implies contains a = list of different labels for grouping types (or classes) of events to be = used as low-granularity buckets for characterizing and classifying = events. Other entries in this enumeration include things like =E2=80=9CFile Ops = (CRUD)=E2=80=9D, =E2=80=9CProcess Mgt=E2=80=9D, =E2=80=9CAuthorization = (ACL)=E2=80=9D, etc. =20 The =E2=80=9CPacket Traffic=E2=80=9D value is intended to characterize = events dealing with network packet traffic as its name implies. The =E2=80=9CData Flow=E2=80=9D value is intended to characterize events = dealing with forms of data flow at a higher level of abstraction than = just packet traffic. The relationship between these two values could be = viewed as =E2=80=9CPacket Traffic=E2=80=9D being a more detailed form of = =E2=80=9CData Flow=E2=80=9D just as the values =E2=80=9CApp Layer = Traffic=E2=80=9D and =E2=80=9CHTTP Layer Traffic=E2=80=9D, also in this = enumeration, could be other levels in this same abstraction stack. The idea behind the varying levels of abstraction is to leave buckets = large enough to capture a wide variety of potential event types (e.g. = data flow events other than obvious things like packet traffic) but also = enable the use of smaller more specific buckets when they are = appropriate and commonly used. =20 Does this make sense?=20 =20 sean =20 From: Omar Santos (osantos) [mailto:osantos@cisco.com]=20 Sent: Monday, April 16, 2012 8:17 PM To: Luis Nunez; Barnum, Sean D. Cc: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; = m-terada@ipa.go.jp Subject: RE: [sacm] [mile] CybOX v1.0 (Draft) is now released and live = onthe website =20 I echo Luis=E2=80=99 comments. It is good to see the inclusion of = network objects. Quick question to the team related to your netflow = comment. =20 I am looking at: http://cybox.mitre.org/XMLSchema/cybox_core_v1.0%28draft%29.xsd =20 =E2=80=A6 and it looks that we renamed it to =E2=80=9CData = Flow=E2=80=9D? =20 Specifies the class of events dealing with = data flow. =20 =20 What is the difference between that and =E2=80=9CPacket = Traffic=E2=80=9D? =20 Specifies the class of events dealing with packet = traffic. =20 =20 =20 =20 Regards, Omar Santos Incident Manager, PSIRT Security Research and Operations Cisco Systems, Inc. Email: os@cisco.com Phone: +1 919 392 8635 PGP Key: 0x3AF27EDC Cisco.com - http://www.cisco.com Cisco Security Advisories and Notices - http://www.cisco.com/go/psirt This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message. For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html =20 From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of = Luis Nunez Sent: Monday, April 16, 2012 6:44 PM To: Barnum, Sean D. Cc: idxwg@nicwg.org; mile@ietf.org; Doug Wilson (dallendoug@gmail.com); = sacm@ietf.org; IPA-Masato Terada (m-terada@ipa.go.jp) Subject: Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live = onthe website =20 I like the inclusion of the network-centric objects. IPFIX (netflow) = will add an additional perspective from an incident information sharing = standpoint. =20 =20 -ln =20 On Apr 16, 2012, at 4:04 PM, Barnum, Sean D. wrote: =20 Hey everyone, =20 I just wanted to let you all know that CybOX v1.0 (Draft) content is now = live on the website. http://cybox.mitre.org The release notes are provided inline below. The key items of note are: =C2=B7 The release of two formal specifications for the CybOX = language (one for the core language and one for the defined objects) =C2=B7 The XML Schema has gone through extensive improvements for = expressiveness, clarity, consistency, efficiency, alignment to existing = normative references and documentation. =C2=B7 This release includes an initial set of language = utilities: a draft Snort -> CybOX transform, a draft OpenIOC -> CybOX = transform, and a set of Python bindings for the CybOX language. =C2=B7 The website now includes a small set of content examples. = This set will grow going forward. This release involved a lot of hard work from a diverse group of people. = Thank you all for your contributions and effort. We could not have done = it without you. We look forward to everyone=E2=80=99s feedback and collaboration as we = continue to improve and mature the CybOX language. =20 Sean Barnum =20 =20 =20 CybOX v1.0 (Draft) Release Notes The Version 1.0 (Draft) release of Cyber Observable eXpression = (CybOX=E2=84=A2) is intended as a draft release of an initial major = version of the CybOX Language that could be utilized for practical = operational use and integration into other standards efforts. This = release consists of three primary components: a pair of formal language = specifications for the core language content and defined objects = content, a set of language implementation XML schemas (core, = common_types, and ~70 defined object schemas), and a small initial set = of language utilities including an initial draft Snort->CybOX transform, = an initial draft OpenIOC->CybOX transform and a set of CybOX language = Python bindings. Recognizing that this is the first time that the formal = language specifications will be available for review and as such will = likely generate feedback from new stakeholders, this initial major = version is being released as a =E2=80=9Cdraft=E2=80=9D v1.0 with the = expectation of cycles of new feedback and revision before a = =E2=80=9Cfinal=E2=80=9D v1.0 is released. The CybOX v1.0 (Draft) XML schemas include a significant number of = changes from v0.7 to improve: =C2=B7 Clarity, documentation, and descriptive formality for = reference and implementation by other standards and users. =C2=B7 Consistency, simplicity, and efficiency. =C2=B7 Alignment (as appropriate) to existing normative = references. =C2=B7 Expressiveness of the schema to better support the broad = set of use cases it targets (malware characterization, indicator and = incident data sharing, event management, etc.) including the addition of = an initial set of network-related defined objects. Summary of changes from CybOX_v0.7 to CybOX_v1.0_(Draft): =C2=B7 Refinement of namespaces and schema locations for better = effectiveness and flexibility going forward. =C2=B7 Normalized all content according to an established set of = naming conventions. =C2=B7 Fully annotated all language items (types, attributes, = elements, etc.). =C2=B7 Moved several commonly leveraged types out of the core = schema and into common_types. =C2=B7 Achieved full typing of entire schema structure such that = all attributes and elements are definitively typed. =C2=B7 Changed all identifiers from ID and IDREF types to be = QNames enabling globally unique identifiers and flexibility for = domain-specific users of CybOX to define their own identifier syntax = locally. =C2=B7 Reordered attributes and elements in numerous types to = better reflect common usage and priority. =C2=B7 Added major_version and minor_version attributes for core = schema. =C2=B7 Added capability to characterize source of overall = observable package data and for individual observables. =C2=B7 Modified the logical composition structure such that any = such compositions are now contained within a Observable_Composition = element providing improved simplicity and modularity. =C2=B7 Removed the Delta element from ObservableType and = relocated the appropriate portions (Change, Trend, and Frequency) to = appropriate locations under Stateful_Measure and Event. =C2=B7 Added a Domain_Specific_Object_Attributes field to Object = utilizing an abstract type that will allow domain-specific use cases to = add in their own domain-specific attributes for Objects. =C2=B7 Added a Tool-Specific_Data field to ToolInformationType = utilizing an abstract type that will allow addition of tool-specific = data. =C2=B7 Added an Indicators field to MeasureSourceType utilizing = an abstract type that will allow characterizing differing formats or = standards of indicators that may have led to the identification of the = observable data. =C2=B7 Enhanced the Hash structure to capture full fuzzy hashes = in addition to simple hashes =C2=B7 Added a new ExtractedFeaturesType that can be used to = adorn differing objects (e.g., files, memory, etc.) to capture extracted = strings, imports, functions and code snippets =C2=B7 Added a ByteRunsType to enable capture of byte runs within = various objects. =C2=B7 Added object_reference attribute to DefinedObjectType to = better support referencing of independently defined Objects from within = another Object definition. =C2=B7 Added a generic DataSegmentType to provide a relatively = abstract way of characterizing data segments that may be = written/read/transmitted or otherwise utilized in actions or defined in = objects. =C2=B7 Added several new defined object schemas (API, Code, = Device, DNS_Record, Network_Flow, Network_Packet, Network_Route_Entry, = Network_Subnet, Unix_Network_Route_Entry) including an initial set of = network-centric defined objects. =C2=B7 Modified every defined object schema with added = annotations as well as minor and in some cases substantive changes to = fix errors, improve consistency and alignment with existing normative = references, and to improve expressiveness in support of the targeted use = cases. Detailed changes from CybOX_v0.7 to CybOX_v1.0_(Draft): The level of changes within v1.0 (Draft) in the core schema, = common_types and the defined object schemas is too great to list every = change in these release notes. Detailed difference reports are available = for each individual schema at: = = http://cybox.mitre.org/XMLSchema/release_notes/cybox_v1.0(draft)_diff_rep= orts.zip =20 =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Sean Barnum Cyber Security Principal The MITRE Corporation Email: sbarnum@mitre.org =20 _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile =20 ------=_NextPart_001_0067_01CD1C36.BDA3E920 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

=E2=80=9Cupper layer=E2=80=9D? Yes, as in higher = abstraction.

Just =E2=80=9Cprotocols=E2=80=9D? No.

 

You guys have been looking at this through the lens of network flow = which if fine for thinking about that perspective but it is important to = also realize that the EventTypeEnum and its =E2=80=9CData Flow=E2=80=9D = value go far beyond network-related scope.

It is about a lot of other types of potential data flows (as I just = outlined in a response to Tom) that have nothing to do with network = flow.

 

Thanks for your response though. This is the kind of discussions that = we hope to have a lot more of among the various supported = communities.

 

 

BTW, you may have noticed that the Network_Flow object within CybOX = v1.0 (Draft) supports expression of netflow within several of the most = common formats including Netflow9 (as well as IPFIX as Luis pointed out, = Netflow5 and SiLK as well as bi-directional flow in YAF). The common = 5-tuple or 7-tuple (you describe) (in our case it is an 8-tuple as we = broke the router interface out into both ingress and egress J) shared by pretty much all of the netflow approaches has been broken = out into a shared Network_Flow_Label structure. The various = context-dependent portions of the independent approaches are then = captured within optional structures dedicated to each of them. We hope = that eventually the community can work to come together towards a single = overall common expressive structure for netflow that meets the needs of = all. We hope that CybOX and its use can even help that sort of = maturation and normalization. But since no such universal structure = exists today, we decided to enable optional expression of the most = common individual formats within a single netflow object to serve the = large majority of relevant users, maintain flexibility and enable = discussions and analysis of netflow within a common = package.

We look forward to continuing discussions with the community to = validate or invalidate this approach and to refine and mature going = forward.

 

Sean

 

From:= = Omar Santos (osantos) [mailto:osantos@cisco.com]
Sent: = Monday, April 16, 2012 11:57 PM
To: Millar, Thomas; Barnum, = Sean D.; lnunez@c3isecurity.com
Cc: idxwg@nicwg.org; = mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; = m-terada@ipa.go.jp
Subject: RE: [sacm] [mile] CybOX v1.0 = (Draft) is now released and live onthe = website

 

I believe that what Sean is saying is that =E2=80=9Cdata = flow=E2=80=9D is just a value that is meant for upper layer protocols. = But, you have a good point. Traditionally, a =E2=80=9Cflow=E2=80=9D in = =E2=80=9CNetflow=E2=80=9D is based on a set of 5 and up to 7 IP packet = attributes:

 

- IP source address

- IP destination address

- Source port

- Destination port

- Layer 3 protocol type

- Class of Service

- Router or switch interface

 

Although, there is a lot more support with Netflow version = 9:

http://www.= cisco.com/en/US/technologies/tk648/tk362/technologies_white_paper09186a00= 800a3db9_ps6601_Products_White_Paper.html

 

 

 

Regards,

Omar

 

From:= = Millar, Thomas [mailto:Thomas.Millar@h= q.dhs.gov]
Sent: Monday, April 16, 2012 11:46 = PM
To: sbarnum@mitre.org; Omar Santos = (osantos); lnunez@c3isecurity.com
C= c: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; m-terada@ipa.go.jp
Subject:<= /b> Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live onthe = website

 

If "data flow" is a euphemism for "netflow" is = there any reason not to call it that?

Tom Millar
http://www.us-cert.gov/ =
------------------
Missit me Rubus fruticosus:
202 631 1915 =

 

From<= /b>: = Barnum, Sean D. [mailto:sbarnum@mitre.org]=
Sent: Monday, April 16, 2012 11:29 PM
To: Omar = Santos (osantos) <osantos@cisco.com>; Luis Nunez = <lnunez@c3isecurity.com> =
Cc: idxwg@nicwg.org = <idxwg@nicwg.org>; mile@ietf.org <mile@ietf.org>; dallendoug@gmail.com <dallendoug@gmail.com>; sacm@ietf.org <sacm@ietf.org>; m-terada@ipa.go.jp <m-terada@ipa.go.jp> =
Subject: Re: [sacm] [mile] CybOX v1.0 (Draft) is now released = and live onthe website
 

Thanks Omar.

 

To answer your question, first let me point out to other readers that = the two entries that Omar is quoting here exist as values in an = enumeration called EventTypeEnum which as its name implies contains a = list of different labels for grouping types (or classes) of events to be = used as low-granularity buckets for characterizing and classifying = events.

Other entries in this enumeration include things like =E2=80=9CFile = Ops (CRUD)=E2=80=9D, =E2=80=9CProcess Mgt=E2=80=9D, = =E2=80=9CAuthorization (ACL)=E2=80=9D, etc.

 

The =E2=80=9CPacket Traffic=E2=80=9D value is intended to = characterize events dealing with network packet traffic as its name = implies.

The =E2=80=9CData Flow=E2=80=9D value is intended to characterize = events dealing with forms of data flow at a higher level of abstraction = than just packet traffic. The relationship between these two values = could be viewed as =E2=80=9CPacket Traffic=E2=80=9D being a more = detailed form of =E2=80=9CData Flow=E2=80=9D just as the values = =E2=80=9CApp Layer Traffic=E2=80=9D and =E2=80=9CHTTP Layer = Traffic=E2=80=9D, also in this enumeration, could be other levels in = this same abstraction stack.

The idea behind the varying levels of abstraction is to leave =  buckets large enough to capture a wide variety of potential event = types (e.g. data flow events other than obvious things like packet = traffic) but also enable the use of smaller more specific buckets when = they are appropriate and commonly used.

 

Does this make sense?

 

sean

 

From:= = Omar Santos (osantos) [mailto:osantos@cisco.com]=
Sent: Monday, April 16, 2012 8:17 PM
To: Luis = Nunez; Barnum, Sean D.
Cc: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; m-terada@ipa.go.jp
Subject:<= /b> RE: [sacm] [mile] CybOX v1.0 (Draft) is now released and live onthe = website

 

I echo Luis=E2=80=99 comments. It is good to see the inclusion of = network objects. Quick question to the team related to your netflow = comment.

 

I am looking at:

= http://cybox.mitre.org/XMLSchema/cybox_core_v1.0%28draft%29.xsd<= /o:p>

 

=E2=80=A6 and it looks that we renamed it to =E2=80=9CData = Flow=E2=80=9D?

 

<xs:enumeration = value=3D"Data Flow">

   = <xs:annotation>

        = <xs:documentation>Specifies the class of events dealing with data = flow.</xs:documentation>

   = </xs:annotation>

</xs:enumeration>

 

 

What is the difference between that and =E2=80=9CPacket = Traffic=E2=80=9D?

 

<xs:enumeration value=3D"Packet =
Traffic">
   =
<xs:annotation>
     =
<xs:documentation>Specifies the class of events dealing with =
packet traffic.</xs:documentation>
   =
</xs:annotation>
</xs:enumeration>

 

 

 

 

Regards,

Omar Santos
Incident Manager, = PSIRT
Security Research and Operations
Cisco Systems, = Inc.
Email: os@cisco.com
Phone: +1 919 392 = 8635
PGP Key: 0x3AF27EDC

Cisco.com - http://www.cisco.com
Cisco Security = Advisories and Notices - http://www.cisco.com/go/psirt<= br>
This email may contain confidential and privileged material for = the sole
use of the intended recipient. Any review, use, distribution = or
disclosure by others is strictly prohibited. If you are not the = intended
recipient (or authorized to receive for the recipient), = please contact
the sender by reply email and delete all copies of = this message.

For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html=

 

From:= = sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.= org] On Behalf Of Luis Nunez
Sent: Monday, April = 16, 2012 6:44 PM
To: Barnum, Sean D.
Cc: idxwg@nicwg.org; mile@ietf.org; Doug Wilson (dallendoug@gmail.com); sacm@ietf.org; IPA-Masato Terada (m-terada@ipa.go.jp)
Subject:= Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live onthe = website

 

I like the inclusion of the network-centric = objects.  IPFIX (netflow)  will add an additional perspective = from an incident information sharing standpoint. =  

 

-ln

 

On Apr 16, 2012, at 4:04 = PM, Barnum, Sean D. wrote:

 

Hey = everyone,

 =

I just = wanted to let you all know that CybOX v1.0 (Draft) content is now live = on the website. http://cybox.mitre.org

The = release notes are provided inline = below.

The key = items of note are:

=C2=B7        The = release of two formal specifications for the CybOX language (one for the = core language and one for the defined = objects)

=C2=B7        The XML = Schema has gone through extensive improvements for expressiveness, = clarity, consistency, efficiency, alignment to existing normative = references and documentation.

=C2=B7        This = release includes an initial set of language utilities: a draft Snort = -> CybOX transform, a draft OpenIOC -> CybOX transform, and a set = of Python bindings for the CybOX language.

=C2=B7        The = website now includes a small set of content examples. This set will grow = going forward.

This = release involved a lot of hard work from a diverse group of people. = Thank you all for your contributions and effort. We could not have done = it without you.

We look = forward to everyone=E2=80=99s feedback and collaboration as we continue = to improve and mature the CybOX = language.

 =

Sean = Barnum

 =

 =

 =

CybOX v1.0 (Draft) Release = Notes

The Version 1.0 (Draft) release of Cyber = Observable eXpression (CybOX=E2=84=A2) is intended as a draft release of an initial major version of = the CybOX Language that could be utilized for practical operational use = and integration into other standards efforts. This release consists of = three primary components: a pair of formal language specifications for = the core language content and defined objects content, a set of language = implementation XML schemas (core, common_types, and ~70 defined object = schemas), and a small initial set of language utilities including an = initial draft Snort->CybOX transform, an initial draft = OpenIOC->CybOX transform and a set of CybOX language Python bindings. = Recognizing that this is the first time that the formal language = specifications will be available for review and as such will likely = generate feedback from new stakeholders, this initial major version is = being released as a =E2=80=9Cdraft=E2=80=9D v1.0 with the expectation of = cycles of new feedback and revision before a =E2=80=9Cfinal=E2=80=9D = v1.0 is released.=

The CybOX v1.0 (Draft) XML schemas include a = significant number of changes from v0.7 to improve:=

=C2=B7       Clarity, = documentation, and descriptive formality for reference and = implementation by other standards and users.=

=C2=B7       Consistency, = simplicity, and efficiency.=

=C2=B7       Alignment (as = appropriate) to existing normative references.=

=C2=B7       Expressiveness of the = schema to better support the broad set of use cases it targets (malware = characterization, indicator and incident data sharing, event management, = etc.) including the addition of an initial set of network-related = defined objects.=

Summary = of changes from CybOX_v0.7 to CybOX_v1.0_(Draft):=

=C2=B7        = Refinement of namespaces and schema = locations for better effectiveness and flexibility going forward.=

=C2=B7        = Normalized all content according to an = established set of naming conventions.=

=C2=B7        = Fully annotated all language items = (types, attributes, elements, etc.).=

=C2=B7        = Moved several commonly leveraged types = out of the core schema and into common_types.=

=C2=B7        = Achieved full typing of entire schema = structure such that all attributes and elements are definitively = typed.=

=C2=B7        = Changed all identifiers from ID and IDREF = types to be QNames enabling globally unique identifiers and flexibility = for domain-specific users of CybOX to define their own identifier syntax = locally.=

=C2=B7        = Reordered attributes and elements in = numerous types to better reflect common usage and priority.=

=C2=B7        = Added major_version and minor_version = attributes for core schema.=

=C2=B7        = Added capability to characterize source = of overall observable package data and for individual observables.=

=C2=B7        = Modified the logical composition = structure such that any such compositions are now contained within a = Observable_Composition element providing improved simplicity and = modularity.=

=C2=B7        = Removed the Delta element from = ObservableType and relocated the appropriate portions (Change, Trend, = and Frequency) to appropriate locations under Stateful_Measure and = Event.=

=C2=B7        = Added a Domain_Specific_Object_Attributes = field to Object utilizing an abstract type that will allow = domain-specific use cases to add in their own domain-specific attributes = for Objects.=

=C2=B7        = Added a Tool-Specific_Data field to = ToolInformationType utilizing an abstract type that will allow addition = of tool-specific data.=

=C2=B7        = Added an Indicators field to = MeasureSourceType utilizing an abstract type that will allow = characterizing differing formats or standards of indicators that may = have led to the identification of the observable data.=

=C2=B7        = Enhanced the Hash structure to capture = full fuzzy hashes in addition to simple hashes=

=C2=B7        = Added a new ExtractedFeaturesType that = can be used to adorn differing objects (e.g., files, memory, etc.) to = capture extracted strings, imports, functions and code snippets=

=C2=B7        = Added a ByteRunsType to enable capture of = byte runs within various objects.=

=C2=B7        = Added object_reference attribute to = DefinedObjectType to better support referencing of independently defined = Objects from within another Object definition.=

=C2=B7        = Added a generic DataSegmentType to = provide a relatively abstract way of characterizing data segments that = may be written/read/transmitted or otherwise utilized in actions or = defined in objects.=

=C2=B7        Added several new = defined object schemas (API, Code, Device, DNS_Record, Network_Flow, = Network_Packet, Network_Route_Entry, Network_Subnet, = Unix_Network_Route_Entry) including an initial set of network-centric = defined objects.

=C2=B7        = Modified every defined object schema with = added annotations as well as minor and in some cases substantive changes = to fix errors, improve consistency and alignment with existing normative = references, and to improve expressiveness in support of the targeted use = cases.=

Detailed changes from CybOX_v0.7 to = CybOX_v1.0_(Draft):=

The level of changes within v1.0 (Draft) in = the core schema, common_types and the defined object schemas is too = great to list every change in these release notes. Detailed difference = reports are available for each individual schema at:http://cybox.mitre.org/XMLSchema/release_notes/cybox_v1.0= (draft)_diff_reports.zip

 =

 =

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

Sean Barnum=

Cyber Security Principal=

The MITRE Corporation=

 =

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

 

------=_NextPart_001_0067_01CD1C36.BDA3E920-- ------=_NextPart_000_0066_01CD1C36.BDA3E920 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIYNDCCBS0w ggMVoAMCAQICEEw6UhQhT9OgRBVHf7KQ+1AwDQYJKoZIhvcNAQELBQAwKTEnMCUGA1UEAxMeTUlU UkUgQ29ycG9yYXRpb24gUEUgUm9vdCBDQS0xMB4XDTExMDQyNjE5NDU0NVoXDTIxMDQyNjE5NDgy MlowKTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUEUgUm9vdCBDQS0xMIICIjANBgkqhkiG 9w0BAQEFAAOCAg8AMIICCgKCAgEAtp8hR0hRq3im+Alwfb5ZHGP5k2OSY2TlVHYHIMUDH3MfW7b6 8lB3j3MwAMsxGK1ke/t6O4K0t9wRH4QDgOQ1CthmOGZW7xiN81h0vP1Yf14SNugUa7ZvH9KP3iXs y8QnOHal1bKf0Pa9KXib58qUuwfaZSCTW5P2ekqd8z4TETvfBWvPgDxyxnVsiAO6yL9WaRpMiSVM hYLWy3KRuU/gue0bVEi+qdg+hENh1NSNXpoqseS262nq5cx5wybR/PF0YstQ9NNlYDM5cLECKYHH zD6cXKJozuFXriswlE8rdna7VaxyZrfgC0ueEIY/tsj/65IyUhyPBwO0ZpW+Ls9Cd4Y+ERSu5mR5 Fd8w42eVzuosmk3s3AxrKC+Z4tXYkjaiWUduIegAiST1vJBwkS53vR+zrBX3Ep56l7MFVvW/GcsZ 9wUT2HG65JOeiVc2YzCEqLgQ3ZCBHn09oBag2lnMac+E2sKm9aKL3xzHs6cyD8qCJK9O8QLCqo3C mzASlOwtTFiLYgpPW/MSmgYOt9JrwHAzk97DHFKTFttjrXGMmhMVzadt1EjMn1Wv8t5WLBI0qSoX /MYi2CaeiDsEiWRu9Nmpu3pmi8m7tIR9csdbAVPks2soNMWOopGEpFQSDvU1+m77v2jIKQKYxYmN 2zUOJ4TJFL1osnZ/71MmLCDVd+ECAwEAAaNRME8wCwYDVR0PBAQDAgGGMA8GA1UdEwEB/wQFMAMB Af8wHQYDVR0OBBYEFFuHfZ/+bL4C6fPgKTqKVCUsnzgvMBAGCSsGAQQBgjcVAQQDAgEAMA0GCSqG SIb3DQEBCwUAA4ICAQAy78sXsP/eqHH8/uOYyxQ6TBDhkCBxNoy8MF2c9UDns5ADL1qyxPAlpDBs L+2h1Zzt3FvPjg0SoRE/9juyG1qxMzhlv0jdQx12tESdo3uBb61b1uuc4H/VxCJWDI4KZL/B53EI 8HGPjUBdLADgOmG99uffm5uarSkjtIX//Bz3U6QfzTPlVWFi4SmzRI2mp16GQ8RPuJ/WMloaAn8X H6EjS2oLjGZC8Pw8/C46W48NvZ1JZTrZvYZr7GmuvmplYK68SZv/T5Su+FlLRTy9uNXQLHtm6jKv nDH2yB66zTwfaDpnjILnrC2O7ANRVZc0KywiKiW3nB7Joq74/XVuMI1PiSByt2Qu+RIS/WAI5wMi bTmwSiBxQZqvuth+dXoakJyOP2Wg5jvL55v9RLZhDqMtRI5ovnOFvTgNJQqNPSekGtA+m6Ctl/vh kSg65FFCMhaSkn7vY2Il+R8HouWJN8wTaudeexnyHcD+Mlt8QaB5CErpDjeeGZfQ0FcYm+6TtlMz Dw5eFhT/J6QrABCxfgLkVFHurMcQD4JkmXXkq5bP+GNkY0Uy2LMbw/UD94OEV1LpfAqUkT+mu5Yb vxg+elFtsad+Ix8owW372xynIADh9q1bHm+j1OHPJmGALWK9miRpC4t3isfu3ZB0QpI/e2Po6MED 393Jb0YbzrcElFv6ZDCCBhYwggP+oAMCAQICChrDbcgAAgAAN/wwDQYJKoZIhvcNAQEFBQAwUDET MBEGCgmSJomT8ixkARkWA09SRzEVMBMGCgmSJomT8ixkARkWBU1JVFJFMSIwIAYDVQQDExlNSVRS RSBDb3Jwb3JhdGlvbiBQRSBDQS0xMB4XDTEyMDMxMjE1MTgyN1oXDTE1MDMxMjE1MTgyN1owSjEL MAkGA1UEBhMCVVMxDjAMBgNVBAoTBU1JVFJFMQ8wDQYDVQQLEwZQZW9wbGUxGjAYBgNVBAMTEUJh cm51bS5TZWFuLjMxNTQzMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA9/I6RU7OcouL 6lcEJMAg8G3myNbQu84QnflS8p3PWOjgC6P50RDqGX5UxelDqMQPN5IsNYRXVY9/b7yN/RSH4goI JfYKMitndKuCKz1q38Nh0YycEm5x2t/IN/60b01T1uOmhZfptLDoDzj0UQZwMQ19mhM/ldsrC8bR GGuHXdQVaSyXygfhzNhqC06vZo5fvCBUJ6z7JtVrfRTHdudg19JYK+gds9p+Lvp/DOEXQmgpfpMl jfNKMnrG+kPMMngrIJUsF5lcbhHuc5mO+O8eR8FxM2KF7gfKVmUmZxs7Y6uLenVJVEmllP0XgUu1 sv3bClFgUo5x5Aq6rXshtHuVuQIDAQABo4IB9jCCAfIwKAYDVR0lBCEwHwYIKwYBBQUHAwQGCSsG AQQBcwIBBwYIKwYBBQUHAwIwHQYDVR0OBBYEFDvU1Ph/OVxGkxRmwvRx1TBf5PKqMA4GA1UdDwEB /wQEAwIGwDAcBgNVHREEFTATgRFzYmFybnVtQG1pdHJlLm9yZzAfBgNVHSMEGDAWgBRpZyAh1EjB 0BsGbvMIKOI6gn1BMTBJBgNVHR8EQjBAMD6gPKA6hjhodHRwOi8vcGtpLm1pdHJlLm9yZy9NSVRS RSUyMENvcnBvcmF0aW9uJTIwUEUlMjBDQS0xLmNybDB/BggrBgEFBQcBAQRzMHEwRwYIKwYBBQUH MAKGO2h0dHA6Ly9wa2kubWl0cmUub3JnL01JVFJFJTIwQ29ycG9yYXRpb24lMjBQRSUyMENBLTEo MikuY3J0MCYGCCsGAQUFBzABhhpodHRwOi8vb2NzcC5taXRyZS5vcmcvb2NzcDA+BgkrBgEEAYI3 FQcEMTAvBicrBgEEAYI3FQiDrqwjho6WV4GNiT2CpKsShb6uAYE2g9KXfYeg+0kCAWQCAQcwFgYD VR0gBA8wDTALBgkrBgEEAXMCAQgwNAYJKwYBBAGCNxUKBCcwJTAKBggrBgEFBQcDBDALBgkrBgEE AXMCAQcwCgYIKwYBBQUHAwIwDQYJKoZIhvcNAQEFBQADggIBAC2wqKo7QWQxIqnEKRznPrAQ5vQ9 X5JhB5keH8KMWu1W5n1RuSZH+3TYp4xccdYh+rV5b5+cJcWEYhtYpZriWm4kMHPaB6gKO9rbVfF9 R8Wp8sXvCKogbNhdkZwvXW4QymB1ASlMzDI1cCV8mzYgbIhWaCbV1zZBUVgOGa4LZIgdbdmgo5r/ O2gmnSftTYiE/tQ+DBs/25Bw/jC5HOiMXJqr+JctzJTqpEVLa7GKHnXWGuzGEPYkKBplxIyhz3Mv qc/yuKM7tZzAr8Qn5qf7VI9O2xp56QLjT2+mySOUR6Vml860FMpjjgZNMxAqOJt7OgY0PoUU9d18 yw1wiKSt0LUQoMcVvp7FifBjtBCG1sB/VOzxNvcNm6lO6EO23pvcjt6+WCG1X3pgnZ5UEohsM3c0 oLzYiuSYeVf85IO2yh9fWLWw2RGkf2szck1Xg0DsAQ54/YlZYyehELh43KbS3lpnTt8UlO7C0TMT 7JQwz4fTQg1a0e9rRPFnNDUG2fS2k3tz9IYILDB3F8uiZzzXptEzaYqzIqe5CK8ZGJQcw+w/CBen 6i+MV/y7yJmhio43Y1x9hIqoynqoSMV3CKYCoOwCvFUAGsNllDpExsQZoXrdd5gcuglqbh3t8wOM jtXDSQllQ/hXDZJf8rnH0wGx3K+WA+LKNvKqNCw9spEtsfG0MIIGYjCCBEqgAwIBAgIKFJcW0gAA AAAABDANBgkqhkiG9w0BAQsFADApMScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQRSBSb290 IENBLTEwHhcNMTEwNjE0MTc0NDQ0WhcNMTcwNjE0MTc1NDQ0WjBQMRMwEQYKCZImiZPyLGQBGRYD T1JHMRUwEwYKCZImiZPyLGQBGRYFTUlUUkUxIjAgBgNVBAMTGU1JVFJFIENvcnBvcmF0aW9uIFBF IENBLTEwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDSxK9RXieqdTz4JWRkRMs/EOuF 0P0S9SbspadLJkx/LDDnaAwmAnqfqm1n7/p82oVjy1yCye3SZu4Yp7fmDIAtWbkHvYOfxHkRv1ho /fhaNN0YRkd65oJJz2ngEbNZxdIiCoialQfX/iWU7ApQ+ovKbFV60v5E0p2mPncs20NYRfsaetdh nBZbFD9flDcXwJqSvGGGBfm7ifFCR1LrtEcNKjMwf7YEWZO0Vk3ZyhVq+k7JNLEbKv0OfBz8DU8G iGU+j88QlrgGW8PLkwNk7nsS/DJp8aLudTuVqIE2CA9mqn5QjU/EZYNHGzSfCr+/usUmbojyVSJu khhrAXspRAMz+Cia3yi3q3w8TnAljXWN1dhx1iuUv5GxyzMjfqK1tMuCUU2XzGNNqoVa1mqolBiy DTCOr9d/IC0YHYMBSpQ+xi0x9zjXKt4FmQmkEAZgF4hsZZqcJYL/iCQiwiz8fEyVPZuvoWvdEXOo zFYCpmkT0MZCJwyIux0Z6vJp6VLtN/6rZgc2y54HlTrp3ifazmpsfrk3NdHxlZTZug9kjEI+vEoy p/79nAPyTWQQ1MEP0ErCWav80/HOi0MLx/7lIUfvVOjkOFgFb+iDvR4T3RAQrnEpgTO+fc7Jyzh9 LpFDqm0slwDP4Hj9cC3IzdED5BU43PGAe+HoZ8OD/1ovVgwo/wIDAQABo4IBYzCCAV8wEAYJKwYB BAGCNxUBBAMCAQIwIwYJKwYBBAGCNxUCBBYEFFCiOtgZb+Zdflkw5sC2y01sUQaVMB0GA1UdDgQW BBRpZyAh1EjB0BsGbvMIKOI6gn1BMTAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTALBgNVHQ8E BAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAfBgNVHSMEGDAWgBRbh32f/my+Aunz4Ck6ilQlLJ84LzBQ BgNVHR8ESTBHMEWgQ6BBhj9odHRwOi8vcGtpLm1pdHJlLm9yZy9NSVRSRSUyMENvcnBvcmF0aW9u JTIwUEUlMjBSb290JTIwQ0EtMS5jcmwwWwYIKwYBBQUHAQEETzBNMEsGCCsGAQUFBzAChj9odHRw Oi8vcGtpLm1pdHJlLm9yZy9NSVRSRSUyMENvcnBvcmF0aW9uJTIwUEUlMjBSb290JTIwQ0EtMS5j cnQwDQYJKoZIhvcNAQELBQADggIBAHnDPfdYKxqNOtAYXMyyel83Vs8cCDAQZhSuIB0c6GkGoEdF rmWH9pwi42V96rCp7TvbNNKNJXbVHfJUAp+uqw663DL/sXXff9ZFxPxKOdPnpA8cKM7RBH9e437N w3d28A7PaGbP6tXmSqhXAhYZ4U12y1U5cOf2G/phUoAAMlnVJdfmXzMazvLo2SIeixAJyCze6rHQ TFQ/N+gAjbVuRJ+Hs8FEKVzMSwqlNoupe2ELqL4dMAKT6P08sAfxm2SrRlQvcWPYvqM/1C10bgc2 tdu+WGzRuP5Wx9Yr15KO9SW4z7fn2RVEXQgoDDno5vCIcfUPuKB5n+Kt9eBCitsgSD9yYsNUN9LE VIvjAb8MV2LWLfge1bumo6g7QMRa4Fgifw5siGwi7V2EaJQo6UAIVvxKKFC7W4p6CkrY2ga1d7GI Q0DPiWZOezOakJVAxL5gf+3WdNt0igKc/yLfbdHn6hCd1KPgDqkSKr8zWOZI/jiDBW957xAmaO6Q dGQDBZrQHWpIVwQGzF5bGrqms2kq49l3t7KmBu0C/9tExqKAmlf4Y5lfQGdCbKQpAq712DVQHYuD XmVQEAc2vlJ1C5hS3Iw9DwBWTfJ4vyB48buhBhbIhPiFta5OizXlKcsIi99ikA1yiZx/DBtjaw4J U6qJzWUFB2ecyGCNPtNbYjURA0A9MIIGfzCCBGegAwIBAgIKGsNq2wACAAA3+jANBgkqhkiG9w0B AQUFADBQMRMwEQYKCZImiZPyLGQBGRYDT1JHMRUwEwYKCZImiZPyLGQBGRYFTUlUUkUxIjAgBgNV BAMTGU1JVFJFIENvcnBvcmF0aW9uIFBFIENBLTEwHhcNMTIwMzEyMTUxODI3WhcNMTUwMzEyMTUx ODI3WjBKMQswCQYDVQQGEwJVUzEOMAwGA1UEChMFTUlUUkUxDzANBgNVBAsTBlBlb3BsZTEaMBgG A1UEAxMRQmFybnVtLlNlYW4uMzE1NDMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCW InZvCSslmSfSyhTVVSqnokCDajlsCNZHfUlkwkV1++2O71BYvMpjFHWR2XFIx963Hl63lFZzzVci OjIwLb1c/0YXhFfUdAvrbpjlu+ttlO05OEUW0h+5HO+qaebJPamxA00w0bokquRcPxUvwa3jiyL0 WfCwE3+/b5PCOW2xh7FXFKv262FnKIwxnQGXqkiXRP5D/SmdtcZSzxHkDThrhaiHPhJJhZ4XxwBk aGcAlMg8YH6uxshXm8e6c7XUu7gB5p+XThS0dqXujpQp/UQDp5t079+UrDcrpjfDBXIt9qCzLn26 uV5a4cD4xRKwA32f1cXFtiKXM0wYgUM3fEPDAgMBAAGjggJfMIICWzATBgNVHSUEDDAKBggrBgEF BQcDBDCBlAYJKoZIhvcNAQkPBIGGMIGDMA4GCCqGSIb3DQMCAgIAgDAOBggqhkiG9w0DBAICAIAw BwYFKw4DAgcwCgYIKoZIhvcNAwcwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBLTALBglghkgBZQME ARYwCwYJYIZIAWUDBAEZMAsGCWCGSAFlAwQBAjALBglghkgBZQMEAQUwHQYDVR0OBBYEFIrbKa+E Rxo2/Sth2C6jZqZqvRE7MA4GA1UdDwEB/wQEAwIFIDAcBgNVHREEFTATgRFzYmFybnVtQG1pdHJl Lm9yZzAfBgNVHSMEGDAWgBRpZyAh1EjB0BsGbvMIKOI6gn1BMTBJBgNVHR8EQjBAMD6gPKA6hjho dHRwOi8vcGtpLm1pdHJlLm9yZy9NSVRSRSUyMENvcnBvcmF0aW9uJTIwUEUlMjBDQS0xLmNybDB/ BggrBgEFBQcBAQRzMHEwRwYIKwYBBQUHMAKGO2h0dHA6Ly9wa2kubWl0cmUub3JnL01JVFJFJTIw Q29ycG9yYXRpb24lMjBQRSUyMENBLTEoMikuY3J0MCYGCCsGAQUFBzABhhpodHRwOi8vb2NzcC5t aXRyZS5vcmcvb2NzcDA+BgkrBgEEAYI3FQcEMTAvBicrBgEEAYI3FQiDrqwjho6WV4GNiT2CpKsS hb6uAYE2hquSaISo7EUCAWQCAQ8wFgYDVR0gBA8wDTALBgkrBgEEAXMCAQgwGwYJKwYBBAGCNxUK BA4wDDAKBggrBgEFBQcDBDANBgkqhkiG9w0BAQUFAAOCAgEAGmmL43yA+J5lEockM1cxSoyxfSES HUGLVJyrhObbdFD4yO3jf0R4lHLuJlhp1486d9LRZAyzAnl9q8Zf3Tx1rl1kEd3pw0wMuO+ATscc rArEW/rJxjz6zTrNO3PFkFuOEdmKpHaRiFpuSX602INiBEBPluei3uZlWxHW9VqC7hz2diQpOlzS jtPMbL3o7ACjWaq7sQ0xB4rZ6oWyqOZEfHWQA1b7nFgL4nEbmEHNdU4jAjcxkROku4O04205kb5n Loveoz3TSQNt8zalFayZAjt+JEcKuG1f5cyhYI6QwvkS/3M+CjJezuNaSmno29Lm+ToZnwUm4nIB YkBx4r9ZDU2W8029tr5og00A5MGo1LK+unWtHBa7zuPblfSiYgXIHWU+OKrSFaA935Yb4fLXFe9S BmApBr1gohHYos1hct5q90WPufSKIQ9WT+vJYXvW3FpseO4ZLKVnJsO7gVoQEEnWJUwyABBPQrii F0gh++ApKZJROTuR36PsEEx4duI6U4VXMCiIcnEjvNR8Mt5Q/Vp4W4Mp5fCv+QzYkqq9EWD7QuUW Yul6R8Hf7ZTxbUk0NfJgu8escLrgQSwMdP/kE/09vJAAslQBkNnIS7iIhWt4l5XQJBrJc+6popRE R8ykWf25e4CliaUgbAl1tBQKivQ3tlX99WykI2XK3sTk9nsxggMjMIIDHwIBATBeMFAxEzARBgoJ kiaJk/IsZAEZFgNPUkcxFTATBgoJkiaJk/IsZAEZFgVNSVRSRTEiMCAGA1UEAxMZTUlUUkUgQ29y cG9yYXRpb24gUEUgQ0EtMQIKGsNtyAACAAA3/DAJBgUrDgMCGgUAoIIBmjAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjA0MTcwNTA5MjlaMCMGCSqGSIb3DQEJBDEW BBREg80x8Kq4xX6tAXXPcXA3qysGCjBbBgkqhkiG9w0BCQ8xTjBMMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMC GjBtBgkrBgEEAYI3EAQxYDBeMFAxEzARBgoJkiaJk/IsZAEZFgNPUkcxFTATBgoJkiaJk/IsZAEZ FgVNSVRSRTEiMCAGA1UEAxMZTUlUUkUgQ29ycG9yYXRpb24gUEUgQ0EtMQIKGsNq2wACAAA3+jBv BgsqhkiG9w0BCRACCzFgoF4wUDETMBEGCgmSJomT8ixkARkWA09SRzEVMBMGCgmSJomT8ixkARkW BU1JVFJFMSIwIAYDVQQDExlNSVRSRSBDb3Jwb3JhdGlvbiBQRSBDQS0xAgoaw2rbAAIAADf6MA0G CSqGSIb3DQEBAQUABIIBANSPnLRCB76drdbzpsfRkzWha2MfStbrkWgCRFbDym4CjVePieriBPiG 1yUBPnwSLsJtViEcZJiUIk+uBGp82c9oJk7z2Jl9wfUhmKoeOIldSS2su5zUvxV+OwN7TFEwGlCd 5rE5gHad6SWC0Jglkrm2JggVVNcH/upYE/h4JTw/IqATqndCYPPgrr0d0eWphLH8ZeVOvc8tvLMr 09bNroKp5D5U11ZJPm0YqoYZaVWi0Be2LvAalb0z37rpC4KVFATKOS3YHXaYypKXbF/DrhWuLB6P G3P4pPGkL1stheCIdaUnly9Jg6uMK0GtJzk1PiRKk9VOPuuZBpkxehTQ5BAAAAAAAAA= ------=_NextPart_000_0066_01CD1C36.BDA3E920-- From michael.hammer@yaanatech.com Tue Apr 17 06:17:49 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1718821F857D; Tue, 17 Apr 2012 06:17:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VRWeXZnIpaJA; Tue, 17 Apr 2012 06:17:43 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id AF53221F841D; Tue, 17 Apr 2012 06:17:43 -0700 (PDT) Received: from EX2K10MB1.corp.yaanatech.com ([fe80::5568:c31d:f64a:f66a]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Tue, 17 Apr 2012 06:17:43 -0700 From: Michael Hammer To: "sbarnum@mitre.org" , "osantos@cisco.com" , "Thomas.Millar@hq.dhs.gov" , "lnunez@c3isecurity.com" Thread-Topic: [mile] [sacm] CybOX v1.0 (Draft) is now released and live onthe website Thread-Index: AQHNHFhQtpFrr+nGFkWqCWY68NIgupae/ygA Date: Tue, 17 Apr 2012 13:17:42 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB389FC37@EX2K10MB1.corp.yaanatech.com> References: <7F48813B48558A4BB5CB7BB714E5B5A9171B16@IMCMBX03.MITRE.ORG> <69CE2DCD9DAC3D48B830E0723141170B02A39BD2@ZAU1UG-0308.DHSNET.DS1.DHS> <953A2E460DBE7C43AC13E30B87C5B4FF080A1C09@XMB-RCD-106.cisco.com> <7F48813B48558A4BB5CB7BB714E5B5A9171BA1@IMCMBX03.MITRE.ORG> In-Reply-To: <7F48813B48558A4BB5CB7BB714E5B5A9171BA1@IMCMBX03.MITRE.ORG> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.88.19] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0008_01CD1C7A.EFE93B80" MIME-Version: 1.0 Cc: "idxwg@nicwg.org" , "mile@ietf.org" , "dallendoug@gmail.com" , "sacm@ietf.org" , "m-terada@ipa.go.jp" Subject: Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live onthe website X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 13:17:49 -0000 ------=_NextPart_000_0008_01CD1C7A.EFE93B80 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0009_01CD1C7A.EFE93B80" ------=_NextPart_001_0009_01CD1C7A.EFE93B80 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Sean, =20 Does the overlap between the various objects present a problem? =20 If there are one or more objects that could carry the same data, then = human nature means that probability-wise someone will choose data flow = instead of Netflow. That is the underlying principle in Murphy=E2=80=99s Law, where you try = to design it so that there is only one way to do it, and thus private = Murphy won=E2=80=99t do it the =E2=80=9Cwrong=E2=80=9D way. =20 Just wondering if these should be mutually exclusive sets. And designed = as such. Might improve interoperability. (And avoid discussions like this in = future.) J =20 Mike =20 =20 From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of = Barnum, Sean D. Sent: Tuesday, April 17, 2012 1:10 AM To: Omar Santos (osantos); Millar, Thomas; lnunez@c3isecurity.com Cc: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; = m-terada@ipa.go.jp Subject: Re: [mile] [sacm] CybOX v1.0 (Draft) is now released and live = onthe website =20 =E2=80=9Cupper layer=E2=80=9D? Yes, as in higher abstraction. Just =E2=80=9Cprotocols=E2=80=9D? No. =20 You guys have been looking at this through the lens of network flow = which if fine for thinking about that perspective but it is important to = also realize that the EventTypeEnum and its =E2=80=9CData Flow=E2=80=9D = value go far beyond network-related scope. It is about a lot of other types of potential data flows (as I just = outlined in a response to Tom) that have nothing to do with network = flow. =20 Thanks for your response though. This is the kind of discussions that we = hope to have a lot more of among the various supported communities. =20 =20 BTW, you may have noticed that the Network_Flow object within CybOX v1.0 = (Draft) supports expression of netflow within several of the most common = formats including Netflow9 (as well as IPFIX as Luis pointed out, = Netflow5 and SiLK as well as bi-directional flow in YAF). The common = 5-tuple or 7-tuple (you describe) (in our case it is an 8-tuple as we = broke the router interface out into both ingress and egress J) shared by = pretty much all of the netflow approaches has been broken out into a = shared Network_Flow_Label structure. The various context-dependent = portions of the independent approaches are then captured within optional = structures dedicated to each of them. We hope that eventually the = community can work to come together towards a single overall common = expressive structure for netflow that meets the needs of all. We hope = that CybOX and its use can even help that sort of maturation and = normalization. But since no such universal structure exists today, we = decided to enable optional expression of the most common individual = formats within a single netflow object to serve the large majority of = relevant users, maintain flexibility and enable discussions and analysis = of netflow within a common package. We look forward to continuing discussions with the community to validate = or invalidate this approach and to refine and mature going forward. =20 Sean=20 =20 From: Omar Santos (osantos) [mailto:osantos@cisco.com]=20 Sent: Monday, April 16, 2012 11:57 PM To: Millar, Thomas; Barnum, Sean D.; lnunez@c3isecurity.com Cc: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; = m-terada@ipa.go.jp Subject: RE: [sacm] [mile] CybOX v1.0 (Draft) is now released and live = onthe website =20 I believe that what Sean is saying is that =E2=80=9Cdata flow=E2=80=9D = is just a value that is meant for upper layer protocols. But, you have a = good point. Traditionally, a =E2=80=9Cflow=E2=80=9D in = =E2=80=9CNetflow=E2=80=9D is based on a set of 5 and up to 7 IP packet = attributes: =20 - IP source address - IP destination address - Source port - Destination port - Layer 3 protocol type - Class of Service - Router or switch interface =20 Although, there is a lot more support with Netflow version 9: http://www.cisco.com/en/US/technologies/tk648/tk362/technologies_white_pa= per09186a00800a3db9_ps6601_Products_White_Paper.html =20 =20 =20 Regards, Omar=20 =20 From: Millar, Thomas [mailto:Thomas.Millar@hq.dhs.gov]=20 Sent: Monday, April 16, 2012 11:46 PM To: sbarnum@mitre.org; Omar Santos (osantos); lnunez@c3isecurity.com Cc: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; = m-terada@ipa.go.jp Subject: Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live = onthe website =20 If "data flow" is a euphemism for "netflow" is there any reason not to = call it that? Tom Millar=20 http://www.us-cert.gov/=20 ------------------=20 Missit me Rubus fruticosus:=20 202 631 1915=20 =20 From: Barnum, Sean D. [mailto:sbarnum@mitre.org]=20 Sent: Monday, April 16, 2012 11:29 PM To: Omar Santos (osantos) ; Luis Nunez = =20 Cc: idxwg@nicwg.org ; mile@ietf.org ; = dallendoug@gmail.com ; sacm@ietf.org = ; m-terada@ipa.go.jp =20 Subject: Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live = onthe website=20 =20 Thanks Omar. =20 To answer your question, first let me point out to other readers that = the two entries that Omar is quoting here exist as values in an = enumeration called EventTypeEnum which as its name implies contains a = list of different labels for grouping types (or classes) of events to be = used as low-granularity buckets for characterizing and classifying = events. Other entries in this enumeration include things like =E2=80=9CFile Ops = (CRUD)=E2=80=9D, =E2=80=9CProcess Mgt=E2=80=9D, =E2=80=9CAuthorization = (ACL)=E2=80=9D, etc. =20 The =E2=80=9CPacket Traffic=E2=80=9D value is intended to characterize = events dealing with network packet traffic as its name implies. The =E2=80=9CData Flow=E2=80=9D value is intended to characterize events = dealing with forms of data flow at a higher level of abstraction than = just packet traffic. The relationship between these two values could be = viewed as =E2=80=9CPacket Traffic=E2=80=9D being a more detailed form of = =E2=80=9CData Flow=E2=80=9D just as the values =E2=80=9CApp Layer = Traffic=E2=80=9D and =E2=80=9CHTTP Layer Traffic=E2=80=9D, also in this = enumeration, could be other levels in this same abstraction stack. The idea behind the varying levels of abstraction is to leave buckets = large enough to capture a wide variety of potential event types (e.g. = data flow events other than obvious things like packet traffic) but also = enable the use of smaller more specific buckets when they are = appropriate and commonly used. =20 Does this make sense?=20 =20 sean =20 From: Omar Santos (osantos) [mailto:osantos@cisco.com]=20 Sent: Monday, April 16, 2012 8:17 PM To: Luis Nunez; Barnum, Sean D. Cc: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; = m-terada@ipa.go.jp Subject: RE: [sacm] [mile] CybOX v1.0 (Draft) is now released and live = onthe website =20 I echo Luis=E2=80=99 comments. It is good to see the inclusion of = network objects. Quick question to the team related to your netflow = comment. =20 I am looking at: http://cybox.mitre.org/XMLSchema/cybox_core_v1.0%28draft%29.xsd =20 =E2=80=A6 and it looks that we renamed it to =E2=80=9CData = Flow=E2=80=9D? =20 Specifies the class of events dealing with = data flow. =20 =20 What is the difference between that and =E2=80=9CPacket = Traffic=E2=80=9D? =20 Specifies the class of events dealing with packet = traffic. =20 =20 =20 =20 Regards, Omar Santos Incident Manager, PSIRT Security Research and Operations Cisco Systems, Inc. Email: os@cisco.com Phone: +1 919 392 8635 PGP Key: 0x3AF27EDC Cisco.com - http://www.cisco.com Cisco Security Advisories and Notices - http://www.cisco.com/go/psirt This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message. For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html =20 From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of = Luis Nunez Sent: Monday, April 16, 2012 6:44 PM To: Barnum, Sean D. Cc: idxwg@nicwg.org; mile@ietf.org; Doug Wilson (dallendoug@gmail.com); = sacm@ietf.org; IPA-Masato Terada (m-terada@ipa.go.jp) Subject: Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live = onthe website =20 I like the inclusion of the network-centric objects. IPFIX (netflow) = will add an additional perspective from an incident information sharing = standpoint. =20 =20 -ln =20 On Apr 16, 2012, at 4:04 PM, Barnum, Sean D. wrote: =20 Hey everyone, =20 I just wanted to let you all know that CybOX v1.0 (Draft) content is now = live on the website. http://cybox.mitre.org The release notes are provided inline below. The key items of note are: =C2=B7 The release of two formal specifications for the CybOX = language (one for the core language and one for the defined objects) =C2=B7 The XML Schema has gone through extensive improvements for = expressiveness, clarity, consistency, efficiency, alignment to existing = normative references and documentation. =C2=B7 This release includes an initial set of language = utilities: a draft Snort -> CybOX transform, a draft OpenIOC -> CybOX = transform, and a set of Python bindings for the CybOX language. =C2=B7 The website now includes a small set of content examples. = This set will grow going forward. This release involved a lot of hard work from a diverse group of people. = Thank you all for your contributions and effort. We could not have done = it without you. We look forward to everyone=E2=80=99s feedback and collaboration as we = continue to improve and mature the CybOX language. =20 Sean Barnum =20 =20 =20 CybOX v1.0 (Draft) Release Notes The Version 1.0 (Draft) release of Cyber Observable eXpression = (CybOX=E2=84=A2) is intended as a draft release of an initial major = version of the CybOX Language that could be utilized for practical = operational use and integration into other standards efforts. This = release consists of three primary components: a pair of formal language = specifications for the core language content and defined objects = content, a set of language implementation XML schemas (core, = common_types, and ~70 defined object schemas), and a small initial set = of language utilities including an initial draft Snort->CybOX transform, = an initial draft OpenIOC->CybOX transform and a set of CybOX language = Python bindings. Recognizing that this is the first time that the formal = language specifications will be available for review and as such will = likely generate feedback from new stakeholders, this initial major = version is being released as a =E2=80=9Cdraft=E2=80=9D v1.0 with the = expectation of cycles of new feedback and revision before a = =E2=80=9Cfinal=E2=80=9D v1.0 is released. The CybOX v1.0 (Draft) XML schemas include a significant number of = changes from v0.7 to improve: =C2=B7 Clarity, documentation, and descriptive formality for = reference and implementation by other standards and users. =C2=B7 Consistency, simplicity, and efficiency. =C2=B7 Alignment (as appropriate) to existing normative = references. =C2=B7 Expressiveness of the schema to better support the broad = set of use cases it targets (malware characterization, indicator and = incident data sharing, event management, etc.) including the addition of = an initial set of network-related defined objects. Summary of changes from CybOX_v0.7 to CybOX_v1.0_(Draft): =C2=B7 Refinement of namespaces and schema locations for better = effectiveness and flexibility going forward. =C2=B7 Normalized all content according to an established set of = naming conventions. =C2=B7 Fully annotated all language items (types, attributes, = elements, etc.). =C2=B7 Moved several commonly leveraged types out of the core = schema and into common_types. =C2=B7 Achieved full typing of entire schema structure such that = all attributes and elements are definitively typed. =C2=B7 Changed all identifiers from ID and IDREF types to be = QNames enabling globally unique identifiers and flexibility for = domain-specific users of CybOX to define their own identifier syntax = locally. =C2=B7 Reordered attributes and elements in numerous types to = better reflect common usage and priority. =C2=B7 Added major_version and minor_version attributes for core = schema. =C2=B7 Added capability to characterize source of overall = observable package data and for individual observables. =C2=B7 Modified the logical composition structure such that any = such compositions are now contained within a Observable_Composition = element providing improved simplicity and modularity. =C2=B7 Removed the Delta element from ObservableType and relocated = the appropriate portions (Change, Trend, and Frequency) to appropriate = locations under Stateful_Measure and Event. =C2=B7 Added a Domain_Specific_Object_Attributes field to Object = utilizing an abstract type that will allow domain-specific use cases to = add in their own domain-specific attributes for Objects. =C2=B7 Added a Tool-Specific_Data field to ToolInformationType = utilizing an abstract type that will allow addition of tool-specific = data. =C2=B7 Added an Indicators field to MeasureSourceType utilizing an = abstract type that will allow characterizing differing formats or = standards of indicators that may have led to the identification of the = observable data. =C2=B7 Enhanced the Hash structure to capture full fuzzy hashes in = addition to simple hashes =C2=B7 Added a new ExtractedFeaturesType that can be used to adorn = differing objects (e.g., files, memory, etc.) to capture extracted = strings, imports, functions and code snippets =C2=B7 Added a ByteRunsType to enable capture of byte runs within = various objects. =C2=B7 Added object_reference attribute to DefinedObjectType to = better support referencing of independently defined Objects from within = another Object definition. =C2=B7 Added a generic DataSegmentType to provide a relatively = abstract way of characterizing data segments that may be = written/read/transmitted or otherwise utilized in actions or defined in = objects. =C2=B7 Added several new defined object schemas (API, Code, = Device, DNS_Record, Network_Flow, Network_Packet, Network_Route_Entry, = Network_Subnet, Unix_Network_Route_Entry) including an initial set of = network-centric defined objects. =C2=B7 Modified every defined object schema with added annotations = as well as minor and in some cases substantive changes to fix errors, = improve consistency and alignment with existing normative references, = and to improve expressiveness in support of the targeted use cases. Detailed changes from CybOX_v0.7 to CybOX_v1.0_(Draft): The level of changes within v1.0 (Draft) in the core schema, = common_types and the defined object schemas is too great to list every = change in these release notes. Detailed difference reports are available = for each individual schema at: = = http://cybox.mitre.org/XMLSchema/release_notes/cybox_v1.0(draft)_diff_rep= orts.zip =20 =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Sean Barnum Cyber Security Principal The MITRE Corporation Email: sbarnum@mitre.org =20 _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile =20 ------=_NextPart_001_0009_01CD1C7A.EFE93B80 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Sean,

 

Does the overlap between the various objects present a = problem?

 

If there are one or more objects that could carry the same data, then = human nature means that probability-wise someone will choose data flow = instead of Netflow.

That is the underlying principle in Murphy=E2=80=99s Law, where you = try to design it so that there is only one way to do it, and thus = private Murphy won=E2=80=99t do it the =E2=80=9Cwrong=E2=80=9D = way.

 

Just wondering if these should be mutually exclusive sets.=C2=A0 And = designed as such.

Might improve interoperability.=C2=A0 (And avoid discussions like = this in future.)=C2=A0 J

 

Mike

 

 

From:= = mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of = Barnum, Sean D.
Sent: Tuesday, April 17, 2012 1:10 = AM
To: Omar Santos (osantos); Millar, Thomas; = lnunez@c3isecurity.com
Cc: idxwg@nicwg.org; mile@ietf.org; = dallendoug@gmail.com; sacm@ietf.org; = m-terada@ipa.go.jp
Subject: Re: [mile] [sacm] CybOX v1.0 = (Draft) is now released and live onthe = website

 

=E2=80=9Cupper layer=E2=80=9D? Yes, as in higher = abstraction.

Just =E2=80=9Cprotocols=E2=80=9D? No.

 

You guys have been looking at this through the lens of network flow = which if fine for thinking about that perspective but it is important to = also realize that the EventTypeEnum and its =E2=80=9CData Flow=E2=80=9D = value go far beyond network-related scope.

It is about a lot of other types of potential data flows (as I just = outlined in a response to Tom) that have nothing to do with network = flow.

 

Thanks for your response though. This is the kind of discussions that = we hope to have a lot more of among the various supported = communities.

 

 

BTW, you may have noticed that the Network_Flow object within CybOX = v1.0 (Draft) supports expression of netflow within several of the most = common formats including Netflow9 (as well as IPFIX as Luis pointed out, = Netflow5 and SiLK as well as bi-directional flow in YAF). The common = 5-tuple or 7-tuple (you describe) (in our case it is an 8-tuple as we = broke the router interface out into both ingress and egress J) shared by pretty much all of the netflow approaches has been broken = out into a shared Network_Flow_Label structure. The various = context-dependent portions of the independent approaches are then = captured within optional structures dedicated to each of them. We hope = that eventually the community can work to come together towards a single = overall common expressive structure for netflow that meets the needs of = all. We hope that CybOX and its use can even help that sort of = maturation and normalization. But since no such universal structure = exists today, we decided to enable optional expression of the most = common individual formats within a single netflow object to serve the = large majority of relevant users, maintain flexibility and enable = discussions and analysis of netflow within a common = package.

We look forward to continuing discussions with the community to = validate or invalidate this approach and to refine and mature going = forward.

 

Sean

 

From:= = Omar Santos (osantos) [mailto:osantos@cisco.com]=
Sent: Monday, April 16, 2012 11:57 PM
To: Millar, = Thomas; Barnum, Sean D.; lnunez@c3isecurity.com
C= c: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; m-terada@ipa.go.jp
Subject:<= /b> RE: [sacm] [mile] CybOX v1.0 (Draft) is now released and live onthe = website

 

I believe that what Sean is saying is that =E2=80=9Cdata = flow=E2=80=9D is just a value that is meant for upper layer protocols. = But, you have a good point. Traditionally, a =E2=80=9Cflow=E2=80=9D in = =E2=80=9CNetflow=E2=80=9D is based on a set of 5 and up to 7 IP packet = attributes:

 

- IP source address

- IP destination address

- Source port

- Destination port

- Layer 3 protocol type

- Class of Service

- Router or switch interface

 

Although, there is a lot more support with Netflow version = 9:

http://www.= cisco.com/en/US/technologies/tk648/tk362/technologies_white_paper09186a00= 800a3db9_ps6601_Products_White_Paper.html

 

 

 

Regards,

Omar

 

From:= = Millar, Thomas [mailto:Thomas.Millar@h= q.dhs.gov]
Sent: Monday, April 16, 2012 11:46 = PM
To: sbarnum@mitre.org; Omar Santos = (osantos); lnunez@c3isecurity.com
C= c: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; m-terada@ipa.go.jp
Subject:<= /b> Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live onthe = website

 

If "data flow" is a euphemism for "netflow" is = there any reason not to call it that?

Tom Millar
http://www.us-cert.gov/ =
------------------
Missit me Rubus fruticosus:
202 631 1915 =

 

From<= /b>: = Barnum, Sean D. [mailto:sbarnum@mitre.org]=
Sent: Monday, April 16, 2012 11:29 PM
To: Omar = Santos (osantos) <osantos@cisco.com>; Luis Nunez = <lnunez@c3isecurity.com> =
Cc: idxwg@nicwg.org = <idxwg@nicwg.org>; mile@ietf.org <mile@ietf.org>; dallendoug@gmail.com <dallendoug@gmail.com>; sacm@ietf.org <sacm@ietf.org>; m-terada@ipa.go.jp <m-terada@ipa.go.jp> =
Subject: Re: [sacm] [mile] CybOX v1.0 (Draft) is now released = and live onthe website
 

Thanks Omar.

 

To answer your question, first let me point out to other readers that = the two entries that Omar is quoting here exist as values in an = enumeration called EventTypeEnum which as its name implies contains a = list of different labels for grouping types (or classes) of events to be = used as low-granularity buckets for characterizing and classifying = events.

Other entries in this enumeration include things like =E2=80=9CFile = Ops (CRUD)=E2=80=9D, =E2=80=9CProcess Mgt=E2=80=9D, = =E2=80=9CAuthorization (ACL)=E2=80=9D, etc.

 

The =E2=80=9CPacket Traffic=E2=80=9D value is intended to = characterize events dealing with network packet traffic as its name = implies.

The =E2=80=9CData Flow=E2=80=9D value is intended to characterize = events dealing with forms of data flow at a higher level of abstraction = than just packet traffic. The relationship between these two values = could be viewed as =E2=80=9CPacket Traffic=E2=80=9D being a more = detailed form of =E2=80=9CData Flow=E2=80=9D just as the values = =E2=80=9CApp Layer Traffic=E2=80=9D and =E2=80=9CHTTP Layer = Traffic=E2=80=9D, also in this enumeration, could be other levels in = this same abstraction stack.

The idea behind the varying levels of abstraction is to leave =  buckets large enough to capture a wide variety of potential event = types (e.g. data flow events other than obvious things like packet = traffic) but also enable the use of smaller more specific buckets when = they are appropriate and commonly used.

 

Does this make sense?

 

sean

 

From:= = Omar Santos (osantos) [mailto:osantos@cisco.com]=
Sent: Monday, April 16, 2012 8:17 PM
To: Luis = Nunez; Barnum, Sean D.
Cc: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; m-terada@ipa.go.jp
Subject:<= /b> RE: [sacm] [mile] CybOX v1.0 (Draft) is now released and live onthe = website

 

I echo Luis=E2=80=99 comments. It is good to see the inclusion of = network objects. Quick question to the team related to your netflow = comment.

 

I am looking at:

= http://cybox.mitre.org/XMLSchema/cybox_core_v1.0%28draft%29.xsd<= /o:p>

 

=E2=80=A6 and it looks that we renamed it to =E2=80=9CData = Flow=E2=80=9D?

 

<xs:enumeration = value=3D"Data Flow">

   = <xs:annotation>

        = <xs:documentation>Specifies the class of events dealing with data = flow.</xs:documentation>

   = </xs:annotation>

</xs:enumeration>

 

 

What is the difference between that and =E2=80=9CPacket = Traffic=E2=80=9D?

 

<xs:enumeration value=3D"Packet =
Traffic">
   =
<xs:annotation>
     =
<xs:documentation>Specifies the class of events dealing with =
packet traffic.</xs:documentation>
   =
</xs:annotation>
</xs:enumeration>

 

 

 

 

Regards,

Omar Santos
Incident Manager, = PSIRT
Security Research and Operations
Cisco Systems, = Inc.
Email: os@cisco.com
Phone: +1 919 392 = 8635
PGP Key: 0x3AF27EDC

Cisco.com - http://www.cisco.com
Cisco Security = Advisories and Notices - http://www.cisco.com/go/psirt<= br>
This email may contain confidential and privileged material for = the sole
use of the intended recipient. Any review, use, distribution = or
disclosure by others is strictly prohibited. If you are not the = intended
recipient (or authorized to receive for the recipient), = please contact
the sender by reply email and delete all copies of = this message.

For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html=

 

From:= = sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.= org] On Behalf Of Luis Nunez
Sent: Monday, April = 16, 2012 6:44 PM
To: Barnum, Sean D.
Cc: idxwg@nicwg.org; mile@ietf.org; Doug Wilson (dallendoug@gmail.com); sacm@ietf.org; IPA-Masato Terada (m-terada@ipa.go.jp)
Subject:= Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live onthe = website

 

I like the inclusion of the network-centric = objects.  IPFIX (netflow)  will add an additional perspective = from an incident information sharing standpoint. =  

 

-ln

 

On Apr 16, 2012, at 4:04 = PM, Barnum, Sean D. wrote:

 

Hey = everyone,

 =

I just = wanted to let you all know that CybOX v1.0 (Draft) content is now live = on the website. http://cybox.mitre.org

The = release notes are provided inline = below.

The key = items of note are:

=C2=B7        The = release of two formal specifications for the CybOX language (one for the = core language and one for the defined = objects)

=C2=B7        The XML = Schema has gone through extensive improvements for expressiveness, = clarity, consistency, efficiency, alignment to existing normative = references and documentation.

=C2=B7        This = release includes an initial set of language utilities: a draft Snort = -> CybOX transform, a draft OpenIOC -> CybOX transform, and a set = of Python bindings for the CybOX language.

=C2=B7        The = website now includes a small set of content examples. This set will grow = going forward.

This = release involved a lot of hard work from a diverse group of people. = Thank you all for your contributions and effort. We could not have done = it without you.

We look = forward to everyone=E2=80=99s feedback and collaboration as we continue = to improve and mature the CybOX = language.

 =

Sean = Barnum

 =

 =

 =

CybOX v1.0 (Draft) Release = Notes

The Version 1.0 (Draft) release of Cyber = Observable eXpression (CybOX=E2=84=A2) is intended as a draft release of an initial major version of = the CybOX Language that could be utilized for practical operational use = and integration into other standards efforts. This release consists of = three primary components: a pair of formal language specifications for = the core language content and defined objects content, a set of language = implementation XML schemas (core, common_types, and ~70 defined object = schemas), and a small initial set of language utilities including an = initial draft Snort->CybOX transform, an initial draft = OpenIOC->CybOX transform and a set of CybOX language Python bindings. = Recognizing that this is the first time that the formal language = specifications will be available for review and as such will likely = generate feedback from new stakeholders, this initial major version is = being released as a =E2=80=9Cdraft=E2=80=9D v1.0 with the expectation of = cycles of new feedback and revision before a =E2=80=9Cfinal=E2=80=9D = v1.0 is released.=

The CybOX v1.0 (Draft) XML schemas include a = significant number of changes from v0.7 to improve:=

=C2=B7       Clarity, = documentation, and descriptive formality for reference and = implementation by other standards and users.=

=C2=B7       Consistency, = simplicity, and efficiency.=

=C2=B7       Alignment (as = appropriate) to existing normative references.=

=C2=B7       Expressiveness of the = schema to better support the broad set of use cases it targets (malware = characterization, indicator and incident data sharing, event management, = etc.) including the addition of an initial set of network-related = defined objects.=

Summary = of changes from CybOX_v0.7 to CybOX_v1.0_(Draft):=

=C2=B7       = Refinement of namespaces and schema = locations for better effectiveness and flexibility going forward.=

=C2=B7       = Normalized all content according to an = established set of naming conventions.=

=C2=B7       = Fully annotated all language items = (types, attributes, elements, etc.).=

=C2=B7       = Moved several commonly leveraged types = out of the core schema and into common_types.=

=C2=B7       = Achieved full typing of entire schema = structure such that all attributes and elements are definitively = typed.=

=C2=B7       = Changed all identifiers from ID and IDREF = types to be QNames enabling globally unique identifiers and flexibility = for domain-specific users of CybOX to define their own identifier syntax = locally.=

=C2=B7       = Reordered attributes and elements in = numerous types to better reflect common usage and priority.=

=C2=B7       = Added major_version and minor_version = attributes for core schema.=

=C2=B7       = Added capability to characterize source = of overall observable package data and for individual observables.=

=C2=B7       = Modified the logical composition = structure such that any such compositions are now contained within a = Observable_Composition element providing improved simplicity and = modularity.=

=C2=B7       = Removed the Delta element from = ObservableType and relocated the appropriate portions (Change, Trend, = and Frequency) to appropriate locations under Stateful_Measure and = Event.=

=C2=B7       = Added a Domain_Specific_Object_Attributes = field to Object utilizing an abstract type that will allow = domain-specific use cases to add in their own domain-specific attributes = for Objects.=

=C2=B7       = Added a Tool-Specific_Data field to = ToolInformationType utilizing an abstract type that will allow addition = of tool-specific data.=

=C2=B7       = Added an Indicators field to = MeasureSourceType utilizing an abstract type that will allow = characterizing differing formats or standards of indicators that may = have led to the identification of the observable data.=

=C2=B7       = Enhanced the Hash structure to capture = full fuzzy hashes in addition to simple hashes=

=C2=B7       = Added a new ExtractedFeaturesType that = can be used to adorn differing objects (e.g., files, memory, etc.) to = capture extracted strings, imports, functions and code snippets=

=C2=B7       = Added a ByteRunsType to enable capture of = byte runs within various objects.=

=C2=B7       = Added object_reference attribute to = DefinedObjectType to better support referencing of independently defined = Objects from within another Object definition.=

=C2=B7       = Added a generic DataSegmentType to = provide a relatively abstract way of characterizing data segments that = may be written/read/transmitted or otherwise utilized in actions or = defined in objects.=

=C2=B7        Added several new = defined object schemas (API, Code, Device, DNS_Record, Network_Flow, = Network_Packet, Network_Route_Entry, Network_Subnet, = Unix_Network_Route_Entry) including an initial set of network-centric = defined objects.

=C2=B7       = Modified every defined object schema with = added annotations as well as minor and in some cases substantive changes = to fix errors, improve consistency and alignment with existing normative = references, and to improve expressiveness in support of the targeted use = cases.=

Detailed changes from CybOX_v0.7 to = CybOX_v1.0_(Draft):=

The level of changes within v1.0 (Draft) in = the core schema, common_types and the defined object schemas is too = great to list every change in these release notes. Detailed difference = reports are available for each individual schema at:http://cybox.mitre.org/XMLSchema/release_notes/cybox_v1.0= (draft)_diff_reports.zip

 =

 =

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

Sean Barnum=

Cyber Security Principal=

The MITRE Corporation=

 =

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

 

------=_NextPart_001_0009_01CD1C7A.EFE93B80-- ------=_NextPart_000_0008_01CD1C7A.EFE93B80 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIP6zCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggTXMIIDv6ADAgECAhBcX1ns/Jl/DtI19/BXCcuBMA0G CSqGSIb3DQEBBQUAMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzMwHhcNMTIwNDAzMDAwMDAwWhcNMTMwNDAzMjM1OTU5WjCCAR4xFzAVBgNVBAoTDlZl cmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13 d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChj KTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNDAyBgNVBAsTK0RpZ2l0YWwgSUQg Q2xhc3MgMSAtIE1pY3Jvc29mdCBGdWxsIFNlcnZpY2UxFzAVBgNVBAMUDk1pY2hhZWwgSGFtbWVy MSswKQYJKoZIhvcNAQkBFhxtaWNoYWVsLmhhbW1lckB5YWFuYXRlY2guY29tMIGfMA0GCSqGSIb3 DQEBAQUAA4GNADCBiQKBgQDoKTk9rP/4lG6CLqIR4++IFTuOSLF6bmhDr6eiSahqU0VNP+H/LbiD MAZsK9GQoBYPKQdKzy/gM+fl3Gm6VOdjKl8M3GB6LGgAK8d3ETN5dyKe5CAG7EEbKg9wxHWcuXW7 KYd052ven5Ec+Xj++v3HsE423O5q2mNh1Q8FNsnlXQIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYD VR0gBD0wOzA5BgtghkgBhvhFAQcXATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2ln bi5jb20vcnBhMAsGA1UdDwQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYD VR0fBEkwRzBFoEOgQYY/aHR0cDovL2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20v SW5kQzFEaWdpdGFsSUQtRzMuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQA8rhDezFsw7OlR3+mZOZ39 SCKWNJ4gMlQEe31NNtvs6BUzE1uN+fJeZrJ5zjTdJWeG1NgVugcuzQfdv/m5BYbhgJvNfW6ElqZh cye6imOUx8diekkeHXKYSLnEvCdJItXsC1h/huIT9e83WksM92qI/TFyCq6u39cGf9PaBYbcKcZk jHjNi3SPnGifMC6opGiiyK/vB1lituoBRcJ13Y7XoXA8T0kSR8Dtmqvo1JudcFAbS1srytG1QX1H XTsPkTDKHlwv2ZfmCSKK3sWHDrZfpRglxvcX2OwibcKVkKBJRRw36UuJOIj/u0WYABcYtusAb2+0 nqoGmOEYARnrseTZMIIG7jCCBdagAwIBAgIQcRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUF ADCByjELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZv ciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQ cmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkw NDMwMjM1OTU5WjCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QSAtIEczMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP 6bGNQU4099oL42r6ZYggCxET6ZvgSU6Lb9UB0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYH r54UGAdPWr2f0jGyVBlzRmoZQhHsEnMhjfXcMM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50 ABMN0Ibak2f4MwOuGjxraXj2wCyO4YM/d/mZ//6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yx BF6+wbaULZeQLSfSux7pg2qE9sSyriMGZSalJ1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ 6/tu1ULEvkHH9QIDAQABo4ICuTCCArUwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRw Oi8vb2NzcC52ZXJpc2lnbi5jb20wEgYDVR0TAQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CG SAGG+EUBBxcBMFYwKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYI KwYBBQUHAgIwHhocaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6Al hiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYI KwYBBQUHAQwEYjBgoV6gXDBaMFgwVhYJaW1hZ2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQ UjibKaxLB4shBRgwJhYkaHR0cDovL2xvZ28udmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1Ud EQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRlTGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EI Qf04BKJL57XM9UP2SSsR+DCB8QYDVR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4 BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkx RTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZ gbWpBbVSOOk5hIls5DSoWufYbAlMJBq6WaSHO3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v 8dKBl8pUWkO/N4t6jhmND0OojPKvYLMVirOVnDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM6 1a4ScAjr+zvid+zoK2Q1ds262uDRyxTWcVibvtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/ XLJtSd5lUkL7DojS7Uodv0vj+Mxy+kgOZY5JyNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4 VRaMxmgD5yKocwuxvKDaUljdCg5/wYIxggS4MIIEtAIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTsw OQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykw OTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhBcX1ns/Jl/DtI19/BXCcuBMAkGBSsO AwIaBQCgggMbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQx NzEzMTc0MFowIwYJKoZIhvcNAQkEMRYEFBZsUOv3kF07vy/7lcmeU0rTodRRMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIIBAwYJKwYB BAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzMCEFxfWez8mX8O0jX38FcJy4EwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkG A1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz dCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24u Y29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5W ZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhBcX1ns/Jl/DtI1 9/BXCcuBMA0GCSqGSIb3DQEBAQUABIGACyUMz/RhCT/mblPhXxQNht28dXyXT/KeiY3RQVJoCCd0 7dFhulig1VpN2JoFxtyPUKeFxqcSBpJJrw6wHEyHyxIoxQBcso4H7oMbFOHNAVWutoReJsmZgUEp cFHqWfLt8L9Ca3EUV2Q5rk3Kx2j6g0dAj7od4Yq2aPrGJZx2mpoAAAAAAAA= ------=_NextPart_000_0008_01CD1C7A.EFE93B80-- From kathleen.moriarty@emc.com Tue Apr 17 07:09:09 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60D1311E8081; Tue, 17 Apr 2012 07:09:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.46 X-Spam-Level: X-Spam-Status: No, score=-10.46 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yljXePelEjBL; Tue, 17 Apr 2012 07:09:09 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id E7E1421F8621; Tue, 17 Apr 2012 07:09:08 -0700 (PDT) Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q3HE8vpC028336 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Apr 2012 10:09:02 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd03.lss.emc.com [10.254.221.145]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor); Tue, 17 Apr 2012 10:08:41 -0400 Received: from mxhub29.corp.emc.com (mxhub29.corp.emc.com [128.222.70.169]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q3HE8eJQ024240; Tue, 17 Apr 2012 10:08:41 -0400 Received: from mx06a.corp.emc.com ([169.254.1.106]) by mxhub29.corp.emc.com ([128.222.70.169]) with mapi; Tue, 17 Apr 2012 10:08:39 -0400 From: To: Date: Tue, 17 Apr 2012 10:07:52 -0400 Thread-Topic: [mile] [sacm] CybOX v1.0 (Draft) is now released and live onthe website Thread-Index: AQHNHFhQtpFrr+nGFkWqCWY68NIgupae/ygAgAAIhWOAAAaXXg== Message-ID: References: <7F48813B48558A4BB5CB7BB714E5B5A9171B16@IMCMBX03.MITRE.ORG> <69CE2DCD9DAC3D48B830E0723141170B02A39BD2@ZAU1UG-0308.DHSNET.DS1.DHS> <953A2E460DBE7C43AC13E30B87C5B4FF080A1C09@XMB-RCD-106.cisco.com> <7F48813B48558A4BB5CB7BB714E5B5A9171BA1@IMCMBX03.MITRE.ORG>, <00C069FD01E0324C9FFCADF539701DB389FC37@EX2K10MB1.corp.yaanatech.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: mile@ietf.org, sacm@ietf.org, m-terada@ipa.go.jp Subject: Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live onthe website X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 14:09:09 -0000 SGkgTWlrZSwNCg0KQXJlIHlvdSBzdWdnZXN0aW5nIHRvIGp1c3QgaW5jbHVkZSB0aGUgTmV0Q29u ZiBzY2hlbWEgYW5kIGFsbG93IHRoYXQgdG8gZXZvbHZlIGFuZCBwdWxsIGl0IGluIHdoZXJlIGFw cHJvcHJpYXRlPyAgVGhhdCBtYWtlcyBzZW5zZSB0byBtZS4uLiAgRm9yIElPREVGLCByaWdodCBu b3cgeW91IHdvdWxkIHVzZSB0aGUgRmxvdyBjbGFzcyBhbmQgY291bGQgb3B0aW9uYWxseSB1c2Ug TmV0Q29uZiB1c2luZyB0aGUgQWRkaXRpb25hbERhdGEgdG8gaW5jbHVkZSBhbm90aGVyIHNjaGVt YS4gIEFsdGhvdWdoIHdlIGRvbid0IGhhdmUgTmV0Q29uZiBpbiB0aGUgU0NJIGRyYWZ0LCB0aGF0 IHJhaXNlcyBhIGdvb2QgcG9pbnQgZm9yIE1JTEUgdG8gY29uc2lkZXIgKGlmIHRoZXJlIGlzIGEg Z2FwIGluIHNjaGVtYSBvciBndWlkYW5jZSkuICBPciB0byBpbmNsdWRlIHRoaXMgaW4gdGhlIElP REVGIGd1aWRhbmNlIGRvY3VtZW50IHNvIHdlIGhhdmUgYW4gYWdyZWVkIHdheSB0byBoYW5kbGUg dGhpcyB1c2UgY2FzZSBjb25zaXN0ZW50bHkgYmV0d2VlbiBpbXBsZW1lbnRhdGlvbnMuICBTQUNN IGlzIHRoaW5raW5nIGFib3V0IHRoZSByZWxhdGlvbnNoaXBzIGJldHdlZW4gbWFuYWdlbWVudCBw cm90b2NvbHMgYW5kIHNlY3VyaXR5IGF1dG9tYXRpb24gc3BlY2lmaWNhdGlvbnMgaW4gdGhlIGJh c2UgdXNlIGNhc2UsIHNvIHRoYXQgc2hvdWxkIGhlbHAgaW4gdGhhdCBzcGFjZS4NCg0KVW5kZXJz dGFuZGluZyB0aGUgdXNlIGNhc2VzIGZvciBDeWJPWCBhbmQgZmxvd3MgbWF5IGhlbHAgdG8gdW5k ZXJzdGFuZCB3aHkgd2UgbWF5IG5lZWQgdGhlIHJlcHJlc2VudGF0aW9uIGRpcmVjdGx5IGluIHRo ZSBzcGVjaWZpY2F0aW9uIGFzIG9wcG9zZWQgdG8gcmVmZXJlbmNpbmcgTmV0Q29uZi4gU2Vhbj8N Cg0KVGhhbmtzLA0KS2F0aGxlZW4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCkZyb206IG1pbGUtYm91bmNlc0BpZXRmLm9yZyBbbWlsZS1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgTWljaGFlbCBIYW1tZXIgW21pY2hhZWwuaGFtbWVyQHlhYW5hdGVjaC5j b21dDQpTZW50OiBUdWVzZGF5LCBBcHJpbCAxNywgMjAxMiA5OjE3IEFNDQpUbzogc2Jhcm51bUBt aXRyZS5vcmc7IG9zYW50b3NAY2lzY28uY29tOyBUaG9tYXMuTWlsbGFyQGhxLmRocy5nb3Y7IGxu dW5lekBjM2lzZWN1cml0eS5jb20NCkNjOiBpZHh3Z0BuaWN3Zy5vcmc7IG1pbGVAaWV0Zi5vcmc7 IGRhbGxlbmRvdWdAZ21haWwuY29tOyBzYWNtQGlldGYub3JnOyBtLXRlcmFkYUBpcGEuZ28uanAN ClN1YmplY3Q6IFJlOiBbbWlsZV0gW3NhY21dIEN5Yk9YIHYxLjAgKERyYWZ0KSBpcyBub3cgcmVs ZWFzZWQgYW5kIGxpdmUgb250aGUgd2Vic2l0ZQ0KDQpTZWFuLA0KDQpEb2VzIHRoZSBvdmVybGFw IGJldHdlZW4gdGhlIHZhcmlvdXMgb2JqZWN0cyBwcmVzZW50IGEgcHJvYmxlbT8NCg0KSWYgdGhl cmUgYXJlIG9uZSBvciBtb3JlIG9iamVjdHMgdGhhdCBjb3VsZCBjYXJyeSB0aGUgc2FtZSBkYXRh LCB0aGVuIGh1bWFuIG5hdHVyZSBtZWFucyB0aGF0IHByb2JhYmlsaXR5LXdpc2Ugc29tZW9uZSB3 aWxsIGNob29zZSBkYXRhIGZsb3cgaW5zdGVhZCBvZiBOZXRmbG93Lg0KVGhhdCBpcyB0aGUgdW5k ZXJseWluZyBwcmluY2lwbGUgaW4gTXVycGh54oCZcyBMYXcsIHdoZXJlIHlvdSB0cnkgdG8gZGVz aWduIGl0IHNvIHRoYXQgdGhlcmUgaXMgb25seSBvbmUgd2F5IHRvIGRvIGl0LCBhbmQgdGh1cyBw cml2YXRlIE11cnBoeSB3b27igJl0IGRvIGl0IHRoZSDigJx3cm9uZ+KAnSB3YXkuDQoNCkp1c3Qg d29uZGVyaW5nIGlmIHRoZXNlIHNob3VsZCBiZSBtdXR1YWxseSBleGNsdXNpdmUgc2V0cy4gIEFu ZCBkZXNpZ25lZCBhcyBzdWNoLg0KTWlnaHQgaW1wcm92ZSBpbnRlcm9wZXJhYmlsaXR5LiAgKEFu ZCBhdm9pZCBkaXNjdXNzaW9ucyBsaWtlIHRoaXMgaW4gZnV0dXJlLikgIOKYug0KDQpNaWtlDQoN Cg0KRnJvbTogbWlsZS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bWlsZS1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgQmFybnVtLCBTZWFuIEQuDQpTZW50OiBUdWVzZGF5LCBBcHJpbCAx NywgMjAxMiAxOjEwIEFNDQpUbzogT21hciBTYW50b3MgKG9zYW50b3MpOyBNaWxsYXIsIFRob21h czsgbG51bmV6QGMzaXNlY3VyaXR5LmNvbQ0KQ2M6IGlkeHdnQG5pY3dnLm9yZzsgbWlsZUBpZXRm Lm9yZzsgZGFsbGVuZG91Z0BnbWFpbC5jb207IHNhY21AaWV0Zi5vcmc7IG0tdGVyYWRhQGlwYS5n by5qcA0KU3ViamVjdDogUmU6IFttaWxlXSBbc2FjbV0gQ3liT1ggdjEuMCAoRHJhZnQpIGlzIG5v dyByZWxlYXNlZCBhbmQgbGl2ZSBvbnRoZSB3ZWJzaXRlDQoNCuKAnHVwcGVyIGxheWVy4oCdPyBZ ZXMsIGFzIGluIGhpZ2hlciBhYnN0cmFjdGlvbi4NCkp1c3Qg4oCccHJvdG9jb2xz4oCdPyBOby4N Cg0KWW91IGd1eXMgaGF2ZSBiZWVuIGxvb2tpbmcgYXQgdGhpcyB0aHJvdWdoIHRoZSBsZW5zIG9m IG5ldHdvcmsgZmxvdyB3aGljaCBpZiBmaW5lIGZvciB0aGlua2luZyBhYm91dCB0aGF0IHBlcnNw ZWN0aXZlIGJ1dCBpdCBpcyBpbXBvcnRhbnQgdG8gYWxzbyByZWFsaXplIHRoYXQgdGhlIEV2ZW50 VHlwZUVudW0gYW5kIGl0cyDigJxEYXRhIEZsb3figJ0gdmFsdWUgZ28gZmFyIGJleW9uZCBuZXR3 b3JrLXJlbGF0ZWQgc2NvcGUuDQpJdCBpcyBhYm91dCBhIGxvdCBvZiBvdGhlciB0eXBlcyBvZiBw b3RlbnRpYWwgZGF0YSBmbG93cyAoYXMgSSBqdXN0IG91dGxpbmVkIGluIGEgcmVzcG9uc2UgdG8g VG9tKSB0aGF0IGhhdmUgbm90aGluZyB0byBkbyB3aXRoIG5ldHdvcmsgZmxvdy4NCg0KVGhhbmtz IGZvciB5b3VyIHJlc3BvbnNlIHRob3VnaC4gVGhpcyBpcyB0aGUga2luZCBvZiBkaXNjdXNzaW9u cyB0aGF0IHdlIGhvcGUgdG8gaGF2ZSBhIGxvdCBtb3JlIG9mIGFtb25nIHRoZSB2YXJpb3VzIHN1 cHBvcnRlZCBjb21tdW5pdGllcy4NCg0KDQpCVFcsIHlvdSBtYXkgaGF2ZSBub3RpY2VkIHRoYXQg dGhlIE5ldHdvcmtfRmxvdyBvYmplY3Qgd2l0aGluIEN5Yk9YIHYxLjAgKERyYWZ0KSBzdXBwb3J0 cyBleHByZXNzaW9uIG9mIG5ldGZsb3cgd2l0aGluIHNldmVyYWwgb2YgdGhlIG1vc3QgY29tbW9u IGZvcm1hdHMgaW5jbHVkaW5nIE5ldGZsb3c5IChhcyB3ZWxsIGFzIElQRklYIGFzIEx1aXMgcG9p bnRlZCBvdXQsIE5ldGZsb3c1IGFuZCBTaUxLIGFzIHdlbGwgYXMgYmktZGlyZWN0aW9uYWwgZmxv dyBpbiBZQUYpLiBUaGUgY29tbW9uIDUtdHVwbGUgb3IgNy10dXBsZSAoeW91IGRlc2NyaWJlKSAo aW4gb3VyIGNhc2UgaXQgaXMgYW4gOC10dXBsZSBhcyB3ZSBicm9rZSB0aGUgcm91dGVyIGludGVy ZmFjZSBvdXQgaW50byBib3RoIGluZ3Jlc3MgYW5kIGVncmVzcyDimLopIHNoYXJlZCBieSBwcmV0 dHkgbXVjaCBhbGwgb2YgdGhlIG5ldGZsb3cgYXBwcm9hY2hlcyBoYXMgYmVlbiBicm9rZW4gb3V0 IGludG8gYSBzaGFyZWQgTmV0d29ya19GbG93X0xhYmVsIHN0cnVjdHVyZS4gVGhlIHZhcmlvdXMg Y29udGV4dC1kZXBlbmRlbnQgcG9ydGlvbnMgb2YgdGhlIGluZGVwZW5kZW50IGFwcHJvYWNoZXMg YXJlIHRoZW4gY2FwdHVyZWQgd2l0aGluIG9wdGlvbmFsIHN0cnVjdHVyZXMgZGVkaWNhdGVkIHRv IGVhY2ggb2YgdGhlbS4gV2UgaG9wZSB0aGF0IGV2ZW50dWFsbHkgdGhlIGNvbW11bml0eSBjYW4g d29yayB0byBjb21lIHRvZ2V0aGVyIHRvd2FyZHMgYSBzaW5nbGUgb3ZlcmFsbCBjb21tb24gZXhw cmVzc2l2ZSBzdHJ1Y3R1cmUgZm9yIG5ldGZsb3cgdGhhdCBtZWV0cyB0aGUgbmVlZHMgb2YgYWxs LiBXZSBob3BlIHRoYXQgQ3liT1ggYW5kIGl0cyB1c2UgY2FuIGV2ZW4gaGVscCB0aGF0IHNvcnQg b2YgbWF0dXJhdGlvbiBhbmQgbm9ybWFsaXphdGlvbi4gQnV0IHNpbmNlIG5vIHN1Y2ggdW5pdmVy c2FsIHN0cnVjdHVyZSBleGlzdHMgdG9kYXksIHdlIGRlY2lkZWQgdG8gZW5hYmxlIG9wdGlvbmFs IGV4cHJlc3Npb24gb2YgdGhlIG1vc3QgY29tbW9uIGluZGl2aWR1YWwgZm9ybWF0cyB3aXRoaW4g YSBzaW5nbGUgbmV0ZmxvdyBvYmplY3QgdG8gc2VydmUgdGhlIGxhcmdlIG1ham9yaXR5IG9mIHJl bGV2YW50IHVzZXJzLCBtYWludGFpbiBmbGV4aWJpbGl0eSBhbmQgZW5hYmxlIGRpc2N1c3Npb25z IGFuZCBhbmFseXNpcyBvZiBuZXRmbG93IHdpdGhpbiBhIGNvbW1vbiBwYWNrYWdlLg0KV2UgbG9v ayBmb3J3YXJkIHRvIGNvbnRpbnVpbmcgZGlzY3Vzc2lvbnMgd2l0aCB0aGUgY29tbXVuaXR5IHRv IHZhbGlkYXRlIG9yIGludmFsaWRhdGUgdGhpcyBhcHByb2FjaCBhbmQgdG8gcmVmaW5lIGFuZCBt YXR1cmUgZ29pbmcgZm9yd2FyZC4NCg0KU2Vhbg0KDQpGcm9tOiBPbWFyIFNhbnRvcyAob3NhbnRv cykgW21haWx0bzpvc2FudG9zQGNpc2NvLmNvbV08bWFpbHRvOlttYWlsdG86b3NhbnRvc0BjaXNj by5jb21dPg0KU2VudDogTW9uZGF5LCBBcHJpbCAxNiwgMjAxMiAxMTo1NyBQTQ0KVG86IE1pbGxh ciwgVGhvbWFzOyBCYXJudW0sIFNlYW4gRC47IGxudW5lekBjM2lzZWN1cml0eS5jb208bWFpbHRv OmxudW5lekBjM2lzZWN1cml0eS5jb20+DQpDYzogaWR4d2dAbmljd2cub3JnPG1haWx0bzppZHh3 Z0BuaWN3Zy5vcmc+OyBtaWxlQGlldGYub3JnPG1haWx0bzptaWxlQGlldGYub3JnPjsgZGFsbGVu ZG91Z0BnbWFpbC5jb208bWFpbHRvOmRhbGxlbmRvdWdAZ21haWwuY29tPjsgc2FjbUBpZXRmLm9y ZzxtYWlsdG86c2FjbUBpZXRmLm9yZz47IG0tdGVyYWRhQGlwYS5nby5qcDxtYWlsdG86bS10ZXJh ZGFAaXBhLmdvLmpwPg0KU3ViamVjdDogUkU6IFtzYWNtXSBbbWlsZV0gQ3liT1ggdjEuMCAoRHJh ZnQpIGlzIG5vdyByZWxlYXNlZCBhbmQgbGl2ZSBvbnRoZSB3ZWJzaXRlDQoNCkkgYmVsaWV2ZSB0 aGF0IHdoYXQgU2VhbiBpcyBzYXlpbmcgaXMgdGhhdCDigJxkYXRhIGZsb3figJ0gaXMganVzdCBh IHZhbHVlIHRoYXQgaXMgbWVhbnQgZm9yIHVwcGVyIGxheWVyIHByb3RvY29scy4gQnV0LCB5b3Ug aGF2ZSBhIGdvb2QgcG9pbnQuIFRyYWRpdGlvbmFsbHksIGEg4oCcZmxvd+KAnSBpbiDigJxOZXRm bG934oCdIGlzIGJhc2VkIG9uIGEgc2V0IG9mIDUgYW5kIHVwIHRvIDcgSVAgcGFja2V0IGF0dHJp YnV0ZXM6DQoNCi0gSVAgc291cmNlIGFkZHJlc3MNCi0gSVAgZGVzdGluYXRpb24gYWRkcmVzcw0K LSBTb3VyY2UgcG9ydA0KLSBEZXN0aW5hdGlvbiBwb3J0DQotIExheWVyIDMgcHJvdG9jb2wgdHlw ZQ0KLSBDbGFzcyBvZiBTZXJ2aWNlDQotIFJvdXRlciBvciBzd2l0Y2ggaW50ZXJmYWNlDQoNCkFs dGhvdWdoLCB0aGVyZSBpcyBhIGxvdCBtb3JlIHN1cHBvcnQgd2l0aCBOZXRmbG93IHZlcnNpb24g OToNCmh0dHA6Ly93d3cuY2lzY28uY29tL2VuL1VTL3RlY2hub2xvZ2llcy90azY0OC90azM2Mi90 ZWNobm9sb2dpZXNfd2hpdGVfcGFwZXIwOTE4NmEwMDgwMGEzZGI5X3BzNjYwMV9Qcm9kdWN0c19X aGl0ZV9QYXBlci5odG1sDQoNCg0KDQpSZWdhcmRzLA0KDQpPbWFyDQoNCkZyb206IE1pbGxhciwg VGhvbWFzIFttYWlsdG86VGhvbWFzLk1pbGxhckBocS5kaHMuZ292XTxtYWlsdG86W21haWx0bzpU aG9tYXMuTWlsbGFyQGhxLmRocy5nb3ZdPg0KU2VudDogTW9uZGF5LCBBcHJpbCAxNiwgMjAxMiAx MTo0NiBQTQ0KVG86IHNiYXJudW1AbWl0cmUub3JnPG1haWx0bzpzYmFybnVtQG1pdHJlLm9yZz47 IE9tYXIgU2FudG9zIChvc2FudG9zKTsgbG51bmV6QGMzaXNlY3VyaXR5LmNvbTxtYWlsdG86bG51 bmV6QGMzaXNlY3VyaXR5LmNvbT4NCkNjOiBpZHh3Z0BuaWN3Zy5vcmc8bWFpbHRvOmlkeHdnQG5p Y3dnLm9yZz47IG1pbGVAaWV0Zi5vcmc8bWFpbHRvOm1pbGVAaWV0Zi5vcmc+OyBkYWxsZW5kb3Vn QGdtYWlsLmNvbTxtYWlsdG86ZGFsbGVuZG91Z0BnbWFpbC5jb20+OyBzYWNtQGlldGYub3JnPG1h aWx0bzpzYWNtQGlldGYub3JnPjsgbS10ZXJhZGFAaXBhLmdvLmpwPG1haWx0bzptLXRlcmFkYUBp cGEuZ28uanA+DQpTdWJqZWN0OiBSZTogW3NhY21dIFttaWxlXSBDeWJPWCB2MS4wIChEcmFmdCkg aXMgbm93IHJlbGVhc2VkIGFuZCBsaXZlIG9udGhlIHdlYnNpdGUNCg0KSWYgImRhdGEgZmxvdyIg aXMgYSBldXBoZW1pc20gZm9yICJuZXRmbG93IiBpcyB0aGVyZSBhbnkgcmVhc29uIG5vdCB0byBj YWxsIGl0IHRoYXQ/DQoNClRvbSBNaWxsYXINCmh0dHA6Ly93d3cudXMtY2VydC5nb3YvDQotLS0t LS0tLS0tLS0tLS0tLS0NCk1pc3NpdCBtZSBSdWJ1cyBmcnV0aWNvc3VzOg0KMjAyIDYzMSAxOTE1 DQoNCg0KRnJvbTogQmFybnVtLCBTZWFuIEQuIFttYWlsdG86c2Jhcm51bUBtaXRyZS5vcmddPG1h aWx0bzpbbWFpbHRvOnNiYXJudW1AbWl0cmUub3JnXT4NClNlbnQ6IE1vbmRheSwgQXByaWwgMTYs IDIwMTIgMTE6MjkgUE0NClRvOiBPbWFyIFNhbnRvcyAob3NhbnRvcykgPG9zYW50b3NAY2lzY28u Y29tPG1haWx0bzpvc2FudG9zQGNpc2NvLmNvbT4+OyBMdWlzIE51bmV6IDxsbnVuZXpAYzNpc2Vj dXJpdHkuY29tPG1haWx0bzpsbnVuZXpAYzNpc2VjdXJpdHkuY29tPj4NCkNjOiBpZHh3Z0BuaWN3 Zy5vcmc8bWFpbHRvOmlkeHdnQG5pY3dnLm9yZz4gPGlkeHdnQG5pY3dnLm9yZzxtYWlsdG86aWR4 d2dAbmljd2cub3JnPj47IG1pbGVAaWV0Zi5vcmc8bWFpbHRvOm1pbGVAaWV0Zi5vcmc+IDxtaWxl QGlldGYub3JnPG1haWx0bzptaWxlQGlldGYub3JnPj47IGRhbGxlbmRvdWdAZ21haWwuY29tPG1h aWx0bzpkYWxsZW5kb3VnQGdtYWlsLmNvbT4gPGRhbGxlbmRvdWdAZ21haWwuY29tPG1haWx0bzpk YWxsZW5kb3VnQGdtYWlsLmNvbT4+OyBzYWNtQGlldGYub3JnPG1haWx0bzpzYWNtQGlldGYub3Jn PiA8c2FjbUBpZXRmLm9yZzxtYWlsdG86c2FjbUBpZXRmLm9yZz4+OyBtLXRlcmFkYUBpcGEuZ28u anA8bWFpbHRvOm0tdGVyYWRhQGlwYS5nby5qcD4gPG0tdGVyYWRhQGlwYS5nby5qcDxtYWlsdG86 bS10ZXJhZGFAaXBhLmdvLmpwPj4NClN1YmplY3Q6IFJlOiBbc2FjbV0gW21pbGVdIEN5Yk9YIHYx LjAgKERyYWZ0KSBpcyBub3cgcmVsZWFzZWQgYW5kIGxpdmUgb250aGUgd2Vic2l0ZQ0KDQpUaGFu a3MgT21hci4NCg0KVG8gYW5zd2VyIHlvdXIgcXVlc3Rpb24sIGZpcnN0IGxldCBtZSBwb2ludCBv dXQgdG8gb3RoZXIgcmVhZGVycyB0aGF0IHRoZSB0d28gZW50cmllcyB0aGF0IE9tYXIgaXMgcXVv dGluZyBoZXJlIGV4aXN0IGFzIHZhbHVlcyBpbiBhbiBlbnVtZXJhdGlvbiBjYWxsZWQgRXZlbnRU eXBlRW51bSB3aGljaCBhcyBpdHMgbmFtZSBpbXBsaWVzIGNvbnRhaW5zIGEgbGlzdCBvZiBkaWZm ZXJlbnQgbGFiZWxzIGZvciBncm91cGluZyB0eXBlcyAob3IgY2xhc3Nlcykgb2YgZXZlbnRzIHRv IGJlIHVzZWQgYXMgbG93LWdyYW51bGFyaXR5IGJ1Y2tldHMgZm9yIGNoYXJhY3Rlcml6aW5nIGFu ZCBjbGFzc2lmeWluZyBldmVudHMuDQpPdGhlciBlbnRyaWVzIGluIHRoaXMgZW51bWVyYXRpb24g aW5jbHVkZSB0aGluZ3MgbGlrZSDigJxGaWxlIE9wcyAoQ1JVRCnigJ0sIOKAnFByb2Nlc3MgTWd0 4oCdLCDigJxBdXRob3JpemF0aW9uIChBQ0wp4oCdLCBldGMuDQoNClRoZSDigJxQYWNrZXQgVHJh ZmZpY+KAnSB2YWx1ZSBpcyBpbnRlbmRlZCB0byBjaGFyYWN0ZXJpemUgZXZlbnRzIGRlYWxpbmcg d2l0aCBuZXR3b3JrIHBhY2tldCB0cmFmZmljIGFzIGl0cyBuYW1lIGltcGxpZXMuDQpUaGUg4oCc RGF0YSBGbG934oCdIHZhbHVlIGlzIGludGVuZGVkIHRvIGNoYXJhY3Rlcml6ZSBldmVudHMgZGVh bGluZyB3aXRoIGZvcm1zIG9mIGRhdGEgZmxvdyBhdCBhIGhpZ2hlciBsZXZlbCBvZiBhYnN0cmFj dGlvbiB0aGFuIGp1c3QgcGFja2V0IHRyYWZmaWMuIFRoZSByZWxhdGlvbnNoaXAgYmV0d2VlbiB0 aGVzZSB0d28gdmFsdWVzIGNvdWxkIGJlIHZpZXdlZCBhcyDigJxQYWNrZXQgVHJhZmZpY+KAnSBi ZWluZyBhIG1vcmUgZGV0YWlsZWQgZm9ybSBvZiDigJxEYXRhIEZsb3figJ0ganVzdCBhcyB0aGUg dmFsdWVzIOKAnEFwcCBMYXllciBUcmFmZmlj4oCdIGFuZCDigJxIVFRQIExheWVyIFRyYWZmaWPi gJ0sIGFsc28gaW4gdGhpcyBlbnVtZXJhdGlvbiwgY291bGQgYmUgb3RoZXIgbGV2ZWxzIGluIHRo aXMgc2FtZSBhYnN0cmFjdGlvbiBzdGFjay4NClRoZSBpZGVhIGJlaGluZCB0aGUgdmFyeWluZyBs ZXZlbHMgb2YgYWJzdHJhY3Rpb24gaXMgdG8gbGVhdmUgIGJ1Y2tldHMgbGFyZ2UgZW5vdWdoIHRv IGNhcHR1cmUgYSB3aWRlIHZhcmlldHkgb2YgcG90ZW50aWFsIGV2ZW50IHR5cGVzIChlLmcuIGRh dGEgZmxvdyBldmVudHMgb3RoZXIgdGhhbiBvYnZpb3VzIHRoaW5ncyBsaWtlIHBhY2tldCB0cmFm ZmljKSBidXQgYWxzbyBlbmFibGUgdGhlIHVzZSBvZiBzbWFsbGVyIG1vcmUgc3BlY2lmaWMgYnVj a2V0cyB3aGVuIHRoZXkgYXJlIGFwcHJvcHJpYXRlIGFuZCBjb21tb25seSB1c2VkLg0KDQpEb2Vz IHRoaXMgbWFrZSBzZW5zZT8NCg0Kc2Vhbg0KDQpGcm9tOiBPbWFyIFNhbnRvcyAob3NhbnRvcykg W21haWx0bzpvc2FudG9zQGNpc2NvLmNvbV08bWFpbHRvOlttYWlsdG86b3NhbnRvc0BjaXNjby5j b21dPg0KU2VudDogTW9uZGF5LCBBcHJpbCAxNiwgMjAxMiA4OjE3IFBNDQpUbzogTHVpcyBOdW5l ejsgQmFybnVtLCBTZWFuIEQuDQpDYzogaWR4d2dAbmljd2cub3JnPG1haWx0bzppZHh3Z0BuaWN3 Zy5vcmc+OyBtaWxlQGlldGYub3JnPG1haWx0bzptaWxlQGlldGYub3JnPjsgZGFsbGVuZG91Z0Bn bWFpbC5jb208bWFpbHRvOmRhbGxlbmRvdWdAZ21haWwuY29tPjsgc2FjbUBpZXRmLm9yZzxtYWls dG86c2FjbUBpZXRmLm9yZz47IG0tdGVyYWRhQGlwYS5nby5qcDxtYWlsdG86bS10ZXJhZGFAaXBh LmdvLmpwPg0KU3ViamVjdDogUkU6IFtzYWNtXSBbbWlsZV0gQ3liT1ggdjEuMCAoRHJhZnQpIGlz IG5vdyByZWxlYXNlZCBhbmQgbGl2ZSBvbnRoZSB3ZWJzaXRlDQoNCkkgZWNobyBMdWlz4oCZIGNv bW1lbnRzLiBJdCBpcyBnb29kIHRvIHNlZSB0aGUgaW5jbHVzaW9uIG9mIG5ldHdvcmsgb2JqZWN0 cy4gUXVpY2sgcXVlc3Rpb24gdG8gdGhlIHRlYW0gcmVsYXRlZCB0byB5b3VyIG5ldGZsb3cgY29t bWVudC4NCg0KSSBhbSBsb29raW5nIGF0Og0KaHR0cDovL2N5Ym94Lm1pdHJlLm9yZy9YTUxTY2hl bWEvY3lib3hfY29yZV92MS4wJTI4ZHJhZnQlMjkueHNkDQoNCuKApiBhbmQgaXQgbG9va3MgdGhh dCB3ZSByZW5hbWVkIGl0IHRvIOKAnERhdGEgRmxvd+KAnT8NCg0KPHhzOmVudW1lcmF0aW9uIHZh bHVlPSJEYXRhIEZsb3ciPg0KICAgPHhzOmFubm90YXRpb24+DQogICAgICAgIDx4czpkb2N1bWVu dGF0aW9uPlNwZWNpZmllcyB0aGUgY2xhc3Mgb2YgZXZlbnRzIGRlYWxpbmcgd2l0aCBkYXRhIGZs b3cuPC94czpkb2N1bWVudGF0aW9uPg0KICAgPC94czphbm5vdGF0aW9uPg0KPC94czplbnVtZXJh dGlvbj4NCg0KDQpXaGF0IGlzIHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gdGhhdCBhbmQg4oCcUGFj a2V0IFRyYWZmaWPigJ0/DQoNCg0KPHhzOmVudW1lcmF0aW9uIHZhbHVlPSJQYWNrZXQgVHJhZmZp YyI+DQoNCiAgIDx4czphbm5vdGF0aW9uPg0KDQogICAgIDx4czpkb2N1bWVudGF0aW9uPlNwZWNp ZmllcyB0aGUgY2xhc3Mgb2YgZXZlbnRzIGRlYWxpbmcgd2l0aCBwYWNrZXQgdHJhZmZpYy48L3hz OmRvY3VtZW50YXRpb24+DQoNCiAgIDwveHM6YW5ub3RhdGlvbj4NCg0KPC94czplbnVtZXJhdGlv bj4NCg0KDQoNCg0KUmVnYXJkcywNCg0KT21hciBTYW50b3MNCkluY2lkZW50IE1hbmFnZXIsIFBT SVJUDQpTZWN1cml0eSBSZXNlYXJjaCBhbmQgT3BlcmF0aW9ucw0KQ2lzY28gU3lzdGVtcywgSW5j Lg0KRW1haWw6IG9zQGNpc2NvLmNvbTxtYWlsdG86b3NAY2lzY28uY29tPg0KUGhvbmU6ICsxIDkx OSAzOTIgODYzNQ0KUEdQIEtleTogMHgzQUYyN0VEQw0KDQpDaXNjby5jb20gLSBodHRwOi8vd3d3 LmNpc2NvLmNvbQ0KQ2lzY28gU2VjdXJpdHkgQWR2aXNvcmllcyBhbmQgTm90aWNlcyAtIGh0dHA6 Ly93d3cuY2lzY28uY29tL2dvL3BzaXJ0DQoNClRoaXMgZW1haWwgbWF5IGNvbnRhaW4gY29uZmlk ZW50aWFsIGFuZCBwcml2aWxlZ2VkIG1hdGVyaWFsIGZvciB0aGUgc29sZQ0KdXNlIG9mIHRoZSBp bnRlbmRlZCByZWNpcGllbnQuIEFueSByZXZpZXcsIHVzZSwgZGlzdHJpYnV0aW9uIG9yDQpkaXNj bG9zdXJlIGJ5IG90aGVycyBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiBJZiB5b3UgYXJlIG5vdCB0 aGUgaW50ZW5kZWQNCnJlY2lwaWVudCAob3IgYXV0aG9yaXplZCB0byByZWNlaXZlIGZvciB0aGUg cmVjaXBpZW50KSwgcGxlYXNlIGNvbnRhY3QNCnRoZSBzZW5kZXIgYnkgcmVwbHkgZW1haWwgYW5k IGRlbGV0ZSBhbGwgY29waWVzIG9mIHRoaXMgbWVzc2FnZS4NCg0KRm9yIGNvcnBvcmF0ZSBsZWdh bCBpbmZvcm1hdGlvbiBnbyB0bzoNCmh0dHA6Ly93d3cuY2lzY28uY29tL3dlYi9hYm91dC9kb2lu Z19idXNpbmVzcy9sZWdhbC9jcmkvaW5kZXguaHRtbA0KDQpGcm9tOiBzYWNtLWJvdW5jZXNAaWV0 Zi5vcmc8bWFpbHRvOnNhY20tYm91bmNlc0BpZXRmLm9yZz4gW21haWx0bzpzYWNtLWJvdW5jZXNA aWV0Zi5vcmddPG1haWx0bzpbbWFpbHRvOnNhY20tYm91bmNlc0BpZXRmLm9yZ10+IE9uIEJlaGFs ZiBPZiBMdWlzIE51bmV6DQpTZW50OiBNb25kYXksIEFwcmlsIDE2LCAyMDEyIDY6NDQgUE0NClRv OiBCYXJudW0sIFNlYW4gRC4NCkNjOiBpZHh3Z0BuaWN3Zy5vcmc8bWFpbHRvOmlkeHdnQG5pY3dn Lm9yZz47IG1pbGVAaWV0Zi5vcmc8bWFpbHRvOm1pbGVAaWV0Zi5vcmc+OyBEb3VnIFdpbHNvbiAo ZGFsbGVuZG91Z0BnbWFpbC5jb208bWFpbHRvOmRhbGxlbmRvdWdAZ21haWwuY29tPik7IHNhY21A aWV0Zi5vcmc8bWFpbHRvOnNhY21AaWV0Zi5vcmc+OyBJUEEtTWFzYXRvIFRlcmFkYSAobS10ZXJh ZGFAaXBhLmdvLmpwPG1haWx0bzptLXRlcmFkYUBpcGEuZ28uanA+KQ0KU3ViamVjdDogUmU6IFtz YWNtXSBbbWlsZV0gQ3liT1ggdjEuMCAoRHJhZnQpIGlzIG5vdyByZWxlYXNlZCBhbmQgbGl2ZSBv bnRoZSB3ZWJzaXRlDQoNCkkgbGlrZSB0aGUgaW5jbHVzaW9uIG9mIHRoZSBuZXR3b3JrLWNlbnRy aWMgb2JqZWN0cy4gIElQRklYIChuZXRmbG93KSAgd2lsbCBhZGQgYW4gYWRkaXRpb25hbCBwZXJz cGVjdGl2ZSBmcm9tIGFuIGluY2lkZW50IGluZm9ybWF0aW9uIHNoYXJpbmcgc3RhbmRwb2ludC4N Cg0KLWxuDQoNCk9uIEFwciAxNiwgMjAxMiwgYXQgNDowNCBQTSwgQmFybnVtLCBTZWFuIEQuIHdy b3RlOg0KDQpIZXkgZXZlcnlvbmUsDQoNCkkganVzdCB3YW50ZWQgdG8gbGV0IHlvdSBhbGwga25v dyB0aGF0IEN5Yk9YIHYxLjAgKERyYWZ0KSBjb250ZW50IGlzIG5vdyBsaXZlIG9uIHRoZSB3ZWJz aXRlLiBodHRwOi8vY3lib3gubWl0cmUub3JnDQpUaGUgcmVsZWFzZSBub3RlcyBhcmUgcHJvdmlk ZWQgaW5saW5lIGJlbG93Lg0KVGhlIGtleSBpdGVtcyBvZiBub3RlIGFyZToNCuKAoiAgICAgICAg VGhlIHJlbGVhc2Ugb2YgdHdvIGZvcm1hbCBzcGVjaWZpY2F0aW9ucyBmb3IgdGhlIEN5Yk9YIGxh bmd1YWdlIChvbmUgZm9yIHRoZSBjb3JlIGxhbmd1YWdlIGFuZCBvbmUgZm9yIHRoZSBkZWZpbmVk IG9iamVjdHMpDQrigKIgICAgICAgIFRoZSBYTUwgU2NoZW1hIGhhcyBnb25lIHRocm91Z2ggZXh0 ZW5zaXZlIGltcHJvdmVtZW50cyBmb3IgZXhwcmVzc2l2ZW5lc3MsIGNsYXJpdHksIGNvbnNpc3Rl bmN5LCBlZmZpY2llbmN5LCBhbGlnbm1lbnQgdG8gZXhpc3Rpbmcgbm9ybWF0aXZlIHJlZmVyZW5j ZXMgYW5kIGRvY3VtZW50YXRpb24uDQrigKIgICAgICAgIFRoaXMgcmVsZWFzZSBpbmNsdWRlcyBh biBpbml0aWFsIHNldCBvZiBsYW5ndWFnZSB1dGlsaXRpZXM6IGEgZHJhZnQgU25vcnQgLT4gQ3li T1ggdHJhbnNmb3JtLCBhIGRyYWZ0IE9wZW5JT0MgLT4gQ3liT1ggdHJhbnNmb3JtLCBhbmQgYSBz ZXQgb2YgUHl0aG9uIGJpbmRpbmdzIGZvciB0aGUgQ3liT1ggbGFuZ3VhZ2UuDQoNCuKAoiAgICAg ICAgVGhlIHdlYnNpdGUgbm93IGluY2x1ZGVzIGEgc21hbGwgc2V0IG9mIGNvbnRlbnQgZXhhbXBs ZXMuIFRoaXMgc2V0IHdpbGwgZ3JvdyBnb2luZyBmb3J3YXJkLg0KVGhpcyByZWxlYXNlIGludm9s dmVkIGEgbG90IG9mIGhhcmQgd29yayBmcm9tIGEgZGl2ZXJzZSBncm91cCBvZiBwZW9wbGUuIFRo YW5rIHlvdSBhbGwgZm9yIHlvdXIgY29udHJpYnV0aW9ucyBhbmQgZWZmb3J0LiBXZSBjb3VsZCBu b3QgaGF2ZSBkb25lIGl0IHdpdGhvdXQgeW91Lg0KV2UgbG9vayBmb3J3YXJkIHRvIGV2ZXJ5b25l 4oCZcyBmZWVkYmFjayBhbmQgY29sbGFib3JhdGlvbiBhcyB3ZSBjb250aW51ZSB0byBpbXByb3Zl IGFuZCBtYXR1cmUgdGhlIEN5Yk9YIGxhbmd1YWdlLg0KDQpTZWFuIEJhcm51bQ0KDQoNCg0KDQpD eWJPWCB2MS4wIChEcmFmdCkgUmVsZWFzZSBOb3Rlcw0KVGhlIFZlcnNpb24gMS4wIChEcmFmdCkg cmVsZWFzZSBvZiBDeWJlciBPYnNlcnZhYmxlIGVYcHJlc3Npb24gKEN5Yk9Y4oSiKSBpcyBpbnRl bmRlZCBhcyBhIGRyYWZ0IHJlbGVhc2Ugb2YgYW4gaW5pdGlhbCBtYWpvciB2ZXJzaW9uIG9mIHRo ZSBDeWJPWCBMYW5ndWFnZSB0aGF0IGNvdWxkIGJlIHV0aWxpemVkIGZvciBwcmFjdGljYWwgb3Bl cmF0aW9uYWwgdXNlIGFuZCBpbnRlZ3JhdGlvbiBpbnRvIG90aGVyIHN0YW5kYXJkcyBlZmZvcnRz LiBUaGlzIHJlbGVhc2UgY29uc2lzdHMgb2YgdGhyZWUgcHJpbWFyeSBjb21wb25lbnRzOiBhIHBh aXIgb2YgZm9ybWFsIGxhbmd1YWdlIHNwZWNpZmljYXRpb25zIGZvciB0aGUgY29yZSBsYW5ndWFn ZSBjb250ZW50IGFuZCBkZWZpbmVkIG9iamVjdHMgY29udGVudCwgYSBzZXQgb2YgbGFuZ3VhZ2Ug aW1wbGVtZW50YXRpb24gWE1MIHNjaGVtYXMgKGNvcmUsIGNvbW1vbl90eXBlcywgYW5kIH43MCBk ZWZpbmVkIG9iamVjdCBzY2hlbWFzKSwgYW5kIGEgc21hbGwgaW5pdGlhbCBzZXQgb2YgbGFuZ3Vh Z2UgdXRpbGl0aWVzIGluY2x1ZGluZyBhbiBpbml0aWFsIGRyYWZ0IFNub3J0LT5DeWJPWCB0cmFu c2Zvcm0sIGFuIGluaXRpYWwgZHJhZnQgT3BlbklPQy0+Q3liT1ggdHJhbnNmb3JtIGFuZCBhIHNl dCBvZiBDeWJPWCBsYW5ndWFnZSBQeXRob24gYmluZGluZ3MuIFJlY29nbml6aW5nIHRoYXQgdGhp cyBpcyB0aGUgZmlyc3QgdGltZSB0aGF0IHRoZSBmb3JtYWwgbGFuZ3VhZ2Ugc3BlY2lmaWNhdGlv bnMgd2lsbCBiZSBhdmFpbGFibGUgZm9yIHJldmlldyBhbmQgYXMgc3VjaCB3aWxsIGxpa2VseSBn ZW5lcmF0ZSBmZWVkYmFjayBmcm9tIG5ldyBzdGFrZWhvbGRlcnMsIHRoaXMgaW5pdGlhbCBtYWpv ciB2ZXJzaW9uIGlzIGJlaW5nIHJlbGVhc2VkIGFzIGEg4oCcZHJhZnTigJ0gdjEuMCB3aXRoIHRo ZSBleHBlY3RhdGlvbiBvZiBjeWNsZXMgb2YgbmV3IGZlZWRiYWNrIGFuZCByZXZpc2lvbiBiZWZv cmUgYSDigJxmaW5hbOKAnSB2MS4wIGlzIHJlbGVhc2VkLg0KVGhlIEN5Yk9YIHYxLjAgKERyYWZ0 KSBYTUwgc2NoZW1hcyBpbmNsdWRlIGEgc2lnbmlmaWNhbnQgbnVtYmVyIG9mIGNoYW5nZXMgZnJv bSB2MC43IHRvIGltcHJvdmU6DQrigKIgICAgICAgQ2xhcml0eSwgZG9jdW1lbnRhdGlvbiwgYW5k IGRlc2NyaXB0aXZlIGZvcm1hbGl0eSBmb3IgcmVmZXJlbmNlIGFuZCBpbXBsZW1lbnRhdGlvbiBi eSBvdGhlciBzdGFuZGFyZHMgYW5kIHVzZXJzLg0K4oCiICAgICAgIENvbnNpc3RlbmN5LCBzaW1w bGljaXR5LCBhbmQgZWZmaWNpZW5jeS4NCuKAoiAgICAgICBBbGlnbm1lbnQgKGFzIGFwcHJvcHJp YXRlKSB0byBleGlzdGluZyBub3JtYXRpdmUgcmVmZXJlbmNlcy4NCg0K4oCiICAgICAgIEV4cHJl c3NpdmVuZXNzIG9mIHRoZSBzY2hlbWEgdG8gYmV0dGVyIHN1cHBvcnQgdGhlIGJyb2FkIHNldCBv ZiB1c2UgY2FzZXMgaXQgdGFyZ2V0cyAobWFsd2FyZSBjaGFyYWN0ZXJpemF0aW9uLCBpbmRpY2F0 b3IgYW5kIGluY2lkZW50IGRhdGEgc2hhcmluZywgZXZlbnQgbWFuYWdlbWVudCwgZXRjLikgaW5j bHVkaW5nIHRoZSBhZGRpdGlvbiBvZiBhbiBpbml0aWFsIHNldCBvZiBuZXR3b3JrLXJlbGF0ZWQg ZGVmaW5lZCBvYmplY3RzLg0KU3VtbWFyeSBvZiBjaGFuZ2VzIGZyb20gQ3liT1hfdjAuNyB0byBD eWJPWF92MS4wXyhEcmFmdCk6DQrCtyAgICAgICBSZWZpbmVtZW50IG9mIG5hbWVzcGFjZXMgYW5k IHNjaGVtYSBsb2NhdGlvbnMgZm9yIGJldHRlciBlZmZlY3RpdmVuZXNzIGFuZCBmbGV4aWJpbGl0 eSBnb2luZyBmb3J3YXJkLg0KwrcgICAgICAgTm9ybWFsaXplZCBhbGwgY29udGVudCBhY2NvcmRp bmcgdG8gYW4gZXN0YWJsaXNoZWQgc2V0IG9mIG5hbWluZyBjb252ZW50aW9ucy4NCsK3ICAgICAg IEZ1bGx5IGFubm90YXRlZCBhbGwgbGFuZ3VhZ2UgaXRlbXMgKHR5cGVzLCBhdHRyaWJ1dGVzLCBl bGVtZW50cywgZXRjLikuDQrCtyAgICAgICBNb3ZlZCBzZXZlcmFsIGNvbW1vbmx5IGxldmVyYWdl ZCB0eXBlcyBvdXQgb2YgdGhlIGNvcmUgc2NoZW1hIGFuZCBpbnRvIGNvbW1vbl90eXBlcy4NCsK3 ICAgICAgIEFjaGlldmVkIGZ1bGwgdHlwaW5nIG9mIGVudGlyZSBzY2hlbWEgc3RydWN0dXJlIHN1 Y2ggdGhhdCBhbGwgYXR0cmlidXRlcyBhbmQgZWxlbWVudHMgYXJlIGRlZmluaXRpdmVseSB0eXBl ZC4NCsK3ICAgICAgIENoYW5nZWQgYWxsIGlkZW50aWZpZXJzIGZyb20gSUQgYW5kIElEUkVGIHR5 cGVzIHRvIGJlIFFOYW1lcyBlbmFibGluZyBnbG9iYWxseSB1bmlxdWUgaWRlbnRpZmllcnMgYW5k IGZsZXhpYmlsaXR5IGZvciBkb21haW4tc3BlY2lmaWMgdXNlcnMgb2YgQ3liT1ggdG8gZGVmaW5l IHRoZWlyIG93biBpZGVudGlmaWVyIHN5bnRheCBsb2NhbGx5Lg0KwrcgICAgICAgUmVvcmRlcmVk IGF0dHJpYnV0ZXMgYW5kIGVsZW1lbnRzIGluIG51bWVyb3VzIHR5cGVzIHRvIGJldHRlciByZWZs ZWN0IGNvbW1vbiB1c2FnZSBhbmQgcHJpb3JpdHkuDQrCtyAgICAgICBBZGRlZCBtYWpvcl92ZXJz aW9uIGFuZCBtaW5vcl92ZXJzaW9uIGF0dHJpYnV0ZXMgZm9yIGNvcmUgc2NoZW1hLg0KwrcgICAg ICAgQWRkZWQgY2FwYWJpbGl0eSB0byBjaGFyYWN0ZXJpemUgc291cmNlIG9mIG92ZXJhbGwgb2Jz ZXJ2YWJsZSBwYWNrYWdlIGRhdGEgYW5kIGZvciBpbmRpdmlkdWFsIG9ic2VydmFibGVzLg0Kwrcg ICAgICAgTW9kaWZpZWQgdGhlIGxvZ2ljYWwgY29tcG9zaXRpb24gc3RydWN0dXJlIHN1Y2ggdGhh dCBhbnkgc3VjaCBjb21wb3NpdGlvbnMgYXJlIG5vdyBjb250YWluZWQgd2l0aGluIGEgT2JzZXJ2 YWJsZV9Db21wb3NpdGlvbiBlbGVtZW50IHByb3ZpZGluZyBpbXByb3ZlZCBzaW1wbGljaXR5IGFu ZCBtb2R1bGFyaXR5Lg0KwrcgICAgICAgUmVtb3ZlZCB0aGUgRGVsdGEgZWxlbWVudCBmcm9tIE9i c2VydmFibGVUeXBlIGFuZCByZWxvY2F0ZWQgdGhlIGFwcHJvcHJpYXRlIHBvcnRpb25zIChDaGFu Z2UsIFRyZW5kLCBhbmQgRnJlcXVlbmN5KSB0byBhcHByb3ByaWF0ZSBsb2NhdGlvbnMgdW5kZXIg U3RhdGVmdWxfTWVhc3VyZSBhbmQgRXZlbnQuDQrCtyAgICAgICBBZGRlZCBhIERvbWFpbl9TcGVj aWZpY19PYmplY3RfQXR0cmlidXRlcyBmaWVsZCB0byBPYmplY3QgdXRpbGl6aW5nIGFuIGFic3Ry YWN0IHR5cGUgdGhhdCB3aWxsIGFsbG93IGRvbWFpbi1zcGVjaWZpYyB1c2UgY2FzZXMgdG8gYWRk IGluIHRoZWlyIG93biBkb21haW4tc3BlY2lmaWMgYXR0cmlidXRlcyBmb3IgT2JqZWN0cy4NCsK3 ICAgICAgIEFkZGVkIGEgVG9vbC1TcGVjaWZpY19EYXRhIGZpZWxkIHRvIFRvb2xJbmZvcm1hdGlv blR5cGUgdXRpbGl6aW5nIGFuIGFic3RyYWN0IHR5cGUgdGhhdCB3aWxsIGFsbG93IGFkZGl0aW9u IG9mIHRvb2wtc3BlY2lmaWMgZGF0YS4NCsK3ICAgICAgIEFkZGVkIGFuIEluZGljYXRvcnMgZmll bGQgdG8gTWVhc3VyZVNvdXJjZVR5cGUgdXRpbGl6aW5nIGFuIGFic3RyYWN0IHR5cGUgdGhhdCB3 aWxsIGFsbG93IGNoYXJhY3Rlcml6aW5nIGRpZmZlcmluZyBmb3JtYXRzIG9yIHN0YW5kYXJkcyBv ZiBpbmRpY2F0b3JzIHRoYXQgbWF5IGhhdmUgbGVkIHRvIHRoZSBpZGVudGlmaWNhdGlvbiBvZiB0 aGUgb2JzZXJ2YWJsZSBkYXRhLg0KwrcgICAgICAgRW5oYW5jZWQgdGhlIEhhc2ggc3RydWN0dXJl IHRvIGNhcHR1cmUgZnVsbCBmdXp6eSBoYXNoZXMgaW4gYWRkaXRpb24gdG8gc2ltcGxlIGhhc2hl cw0KwrcgICAgICAgQWRkZWQgYSBuZXcgRXh0cmFjdGVkRmVhdHVyZXNUeXBlIHRoYXQgY2FuIGJl IHVzZWQgdG8gYWRvcm4gZGlmZmVyaW5nIG9iamVjdHMgKGUuZy4sIGZpbGVzLCBtZW1vcnksIGV0 Yy4pIHRvIGNhcHR1cmUgZXh0cmFjdGVkIHN0cmluZ3MsIGltcG9ydHMsIGZ1bmN0aW9ucyBhbmQg Y29kZSBzbmlwcGV0cw0KwrcgICAgICAgQWRkZWQgYSBCeXRlUnVuc1R5cGUgdG8gZW5hYmxlIGNh cHR1cmUgb2YgYnl0ZSBydW5zIHdpdGhpbiB2YXJpb3VzIG9iamVjdHMuDQrCtyAgICAgICBBZGRl ZCBvYmplY3RfcmVmZXJlbmNlIGF0dHJpYnV0ZSB0byBEZWZpbmVkT2JqZWN0VHlwZSB0byBiZXR0 ZXIgc3VwcG9ydCByZWZlcmVuY2luZyBvZiBpbmRlcGVuZGVudGx5IGRlZmluZWQgT2JqZWN0cyBm cm9tIHdpdGhpbiBhbm90aGVyIE9iamVjdCBkZWZpbml0aW9uLg0KwrcgICAgICAgQWRkZWQgYSBn ZW5lcmljIERhdGFTZWdtZW50VHlwZSB0byBwcm92aWRlIGEgcmVsYXRpdmVseSBhYnN0cmFjdCB3 YXkgb2YgY2hhcmFjdGVyaXppbmcgZGF0YSBzZWdtZW50cyB0aGF0IG1heSBiZSB3cml0dGVuL3Jl YWQvdHJhbnNtaXR0ZWQgb3Igb3RoZXJ3aXNlIHV0aWxpemVkIGluIGFjdGlvbnMgb3IgZGVmaW5l ZCBpbiBvYmplY3RzLg0K4oCiICAgICAgICBBZGRlZCBzZXZlcmFsIG5ldyBkZWZpbmVkIG9iamVj dCBzY2hlbWFzIChBUEksIENvZGUsIERldmljZSwgRE5TX1JlY29yZCwgTmV0d29ya19GbG93LCBO ZXR3b3JrX1BhY2tldCwgTmV0d29ya19Sb3V0ZV9FbnRyeSwgTmV0d29ya19TdWJuZXQsIFVuaXhf TmV0d29ya19Sb3V0ZV9FbnRyeSkgaW5jbHVkaW5nIGFuIGluaXRpYWwgc2V0IG9mIG5ldHdvcmst Y2VudHJpYyBkZWZpbmVkIG9iamVjdHMuDQrCtyAgICAgICBNb2RpZmllZCBldmVyeSBkZWZpbmVk IG9iamVjdCBzY2hlbWEgd2l0aCBhZGRlZCBhbm5vdGF0aW9ucyBhcyB3ZWxsIGFzIG1pbm9yIGFu ZCBpbiBzb21lIGNhc2VzIHN1YnN0YW50aXZlIGNoYW5nZXMgdG8gZml4IGVycm9ycywgaW1wcm92 ZSBjb25zaXN0ZW5jeSBhbmQgYWxpZ25tZW50IHdpdGggZXhpc3Rpbmcgbm9ybWF0aXZlIHJlZmVy ZW5jZXMsIGFuZCB0byBpbXByb3ZlIGV4cHJlc3NpdmVuZXNzIGluIHN1cHBvcnQgb2YgdGhlIHRh cmdldGVkIHVzZSBjYXNlcy4NCkRldGFpbGVkIGNoYW5nZXMgZnJvbSBDeWJPWF92MC43IHRvIEN5 Yk9YX3YxLjBfKERyYWZ0KToNClRoZSBsZXZlbCBvZiBjaGFuZ2VzIHdpdGhpbiB2MS4wIChEcmFm dCkgaW4gdGhlIGNvcmUgc2NoZW1hLCBjb21tb25fdHlwZXMgYW5kIHRoZSBkZWZpbmVkIG9iamVj dCBzY2hlbWFzIGlzIHRvbyBncmVhdCB0byBsaXN0IGV2ZXJ5IGNoYW5nZSBpbiB0aGVzZSByZWxl YXNlIG5vdGVzLiBEZXRhaWxlZCBkaWZmZXJlbmNlIHJlcG9ydHMgYXJlIGF2YWlsYWJsZSBmb3Ig ZWFjaCBpbmRpdmlkdWFsIHNjaGVtYSBhdDpodHRwOi8vY3lib3gubWl0cmUub3JnL1hNTFNjaGVt YS9yZWxlYXNlX25vdGVzL2N5Ym94X3YxLjAoZHJhZnQpX2RpZmZfcmVwb3J0cy56aXANCg0KDQo9 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KU2VhbiBCYXJu dW0NCkN5YmVyIFNlY3VyaXR5IFByaW5jaXBhbA0KVGhlIE1JVFJFIENvcnBvcmF0aW9uDQpFbWFp bDogc2Jhcm51bUBtaXRyZS5vcmc8bWFpbHRvOnNiYXJudW1AbWl0cmUub3JnPg0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbWlsZSBtYWlsaW5nIGxp c3QNCm1pbGVAaWV0Zi5vcmc8bWFpbHRvOm1pbGVAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL21pbGUNCg0K From michael.hammer@yaanatech.com Tue Apr 17 07:50:39 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A3DD11E80A3; Tue, 17 Apr 2012 07:50:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8bfb7T1r+CKd; Tue, 17 Apr 2012 07:50:33 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id C8D4311E80A2; Tue, 17 Apr 2012 07:50:33 -0700 (PDT) Received: from EX2K10MB1.corp.yaanatech.com ([fe80::5568:c31d:f64a:f66a]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Tue, 17 Apr 2012 07:50:33 -0700 From: Michael Hammer To: "kathleen.moriarty@emc.com" , "sbarnum@mitre.org" , "osantos@cisco.com" , "Thomas.Millar@hq.dhs.gov" , "lnunez@c3isecurity.com" Thread-Topic: [mile] [sacm] CybOX v1.0 (Draft) is now released and live onthe website Thread-Index: AQHNHFhQtpFrr+nGFkWqCWY68NIgupae/ygAgAAIhWOAAA7hYA== Date: Tue, 17 Apr 2012 14:50:32 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB389FDB7@EX2K10MB1.corp.yaanatech.com> References: <7F48813B48558A4BB5CB7BB714E5B5A9171B16@IMCMBX03.MITRE.ORG> <69CE2DCD9DAC3D48B830E0723141170B02A39BD2@ZAU1UG-0308.DHSNET.DS1.DHS> <953A2E460DBE7C43AC13E30B87C5B4FF080A1C09@XMB-RCD-106.cisco.com> <7F48813B48558A4BB5CB7BB714E5B5A9171BA1@IMCMBX03.MITRE.ORG>, <00C069FD01E0324C9FFCADF539701DB389FC37@EX2K10MB1.corp.yaanatech.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.88.19] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0029_01CD1C87.E844FB50" MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 17 Apr 2012 07:54:43 -0700 Cc: "idxwg@nicwg.org" , "mile@ietf.org" , "dallendoug@gmail.com" , "sacm@ietf.org" , "m-terada@ipa.go.jp" Subject: Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live onthe website X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 14:50:39 -0000 ------=_NextPart_000_0029_01CD1C87.E844FB50 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Kathleen, Not sure of the way forward, but comparing data sets could help produce = a more uniform, normalized one. I'm still trying to absorb this. Great work by the way. I did a scan of the words flow, network, and packet to see how often and = where they appeared. It seems that flow is the odd one, while network and packet seem scoped = to the whole protocol stack with parallel elements in different parts of = the core doc. So, I didn't see the low level (L1-L3) versus high level (L4-L7) = distinction there. The network protocol list seems to cover all layers. BTW, wondering if the non-exhaustive protocol list is intended to be = extended in the future to call out others at some point. Also, agree discussion is good one to have. Helps me to understand = better. Mike -----Original Message----- From: kathleen.moriarty@emc.com [mailto:kathleen.moriarty@emc.com]=20 Sent: Tuesday, April 17, 2012 10:01 AM To: Michael Hammer; sbarnum@mitre.org; osantos@cisco.com; = Thomas.Millar@hq.dhs.gov; lnunez@c3isecurity.com Cc: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; = m-terada@ipa.go.jp Subject: RE: [mile] [sacm] CybOX v1.0 (Draft) is now released and live = onthe website Hi Mike, Are you suggesting to just include the NetConf schema and allow that to = evolve and pull it in where appropriate? That makes sense to me... For = IODEF, right now you would use the Flow class and could optionally use = NetConf using the AdditionalData to include another schema. Although we = don't have NetConf in the SCI draft, that raises a good point for MILE = to consider (if there is a gap in schema or guidance). Or to include = this in the IODEF guidance document so we have an agreed way to handle = this use case consistently between implementations. SACM is thinking = about the relationships between management protocols and security = automation specifications in the base use case, so that should help in = that space. Understanding the use cases for CybOX and flows may help to understand = why we may need the representation directly in the specification as = opposed to referencing NetConf. Sean? Thanks, Kathleen ________________________________________ From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of Michael = Hammer [michael.hammer@yaanatech.com] Sent: Tuesday, April 17, 2012 9:17 AM To: sbarnum@mitre.org; osantos@cisco.com; Thomas.Millar@hq.dhs.gov; = lnunez@c3isecurity.com Cc: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; = m-terada@ipa.go.jp Subject: Re: [mile] [sacm] CybOX v1.0 (Draft) is now released and live = onthe website Sean, Does the overlap between the various objects present a problem? If there are one or more objects that could carry the same data, then = human nature means that probability-wise someone will choose data flow = instead of Netflow. That is the underlying principle in Murphy=E2=80=99s Law, where you try = to design it so that there is only one way to do it, and thus private = Murphy won=E2=80=99t do it the =E2=80=9Cwrong=E2=80=9D way. Just wondering if these should be mutually exclusive sets. And designed = as such. Might improve interoperability. (And avoid discussions like this in = future.) =E2=98=BA Mike From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of = Barnum, Sean D. Sent: Tuesday, April 17, 2012 1:10 AM To: Omar Santos (osantos); Millar, Thomas; lnunez@c3isecurity.com Cc: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; = m-terada@ipa.go.jp Subject: Re: [mile] [sacm] CybOX v1.0 (Draft) is now released and live = onthe website =E2=80=9Cupper layer=E2=80=9D? Yes, as in higher abstraction. Just =E2=80=9Cprotocols=E2=80=9D? No. You guys have been looking at this through the lens of network flow = which if fine for thinking about that perspective but it is important to = also realize that the EventTypeEnum and its =E2=80=9CData Flow=E2=80=9D = value go far beyond network-related scope. It is about a lot of other types of potential data flows (as I just = outlined in a response to Tom) that have nothing to do with network = flow. Thanks for your response though. This is the kind of discussions that we = hope to have a lot more of among the various supported communities. BTW, you may have noticed that the Network_Flow object within CybOX v1.0 = (Draft) supports expression of netflow within several of the most common = formats including Netflow9 (as well as IPFIX as Luis pointed out, = Netflow5 and SiLK as well as bi-directional flow in YAF). The common = 5-tuple or 7-tuple (you describe) (in our case it is an 8-tuple as we = broke the router interface out into both ingress and egress =E2=98=BA) = shared by pretty much all of the netflow approaches has been broken out = into a shared Network_Flow_Label structure. The various = context-dependent portions of the independent approaches are then = captured within optional structures dedicated to each of them. We hope = that eventually the community can work to come together towards a single = overall common expressive structure for netflow that meets the needs of = all. We hope that CybOX and its use can even help that sort of = maturation and normalization. But since no such universal structure = exists today, we decided to enable optional expression of the most = common individual formats within a single netflow object to serve the = large majority of relevant users, maintain flexibility and enable = discussions and analysis of netflow within a common package. We look forward to continuing discussions with the community to validate = or invalidate this approach and to refine and mature going forward. Sean From: Omar Santos (osantos) = [mailto:osantos@cisco.com] Sent: Monday, April 16, 2012 11:57 PM To: Millar, Thomas; Barnum, Sean D.; = lnunez@c3isecurity.com Cc: idxwg@nicwg.org; = mile@ietf.org; = dallendoug@gmail.com; = sacm@ietf.org; = m-terada@ipa.go.jp Subject: RE: [sacm] [mile] CybOX v1.0 (Draft) is now released and live = onthe website I believe that what Sean is saying is that =E2=80=9Cdata flow=E2=80=9D = is just a value that is meant for upper layer protocols. But, you have a = good point. Traditionally, a =E2=80=9Cflow=E2=80=9D in = =E2=80=9CNetflow=E2=80=9D is based on a set of 5 and up to 7 IP packet = attributes: - IP source address - IP destination address - Source port - Destination port - Layer 3 protocol type - Class of Service - Router or switch interface Although, there is a lot more support with Netflow version 9: http://www.cisco.com/en/US/technologies/tk648/tk362/technologies_white_pa= per09186a00800a3db9_ps6601_Products_White_Paper.html Regards, Omar From: Millar, Thomas = [mailto:Thomas.Millar@hq.dhs.gov] Sent: Monday, April 16, 2012 11:46 PM To: sbarnum@mitre.org; Omar Santos (osantos); = lnunez@c3isecurity.com Cc: idxwg@nicwg.org; = mile@ietf.org; = dallendoug@gmail.com; = sacm@ietf.org; = m-terada@ipa.go.jp Subject: Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live = onthe website If "data flow" is a euphemism for "netflow" is there any reason not to = call it that? Tom Millar http://www.us-cert.gov/ ------------------ Missit me Rubus fruticosus: 202 631 1915 From: Barnum, Sean D. = [mailto:sbarnum@mitre.org] Sent: Monday, April 16, 2012 11:29 PM To: Omar Santos (osantos) >; = Luis Nunez > Cc: idxwg@nicwg.org = >; = mile@ietf.org = >; = dallendoug@gmail.com = >; = sacm@ietf.org = >; = m-terada@ipa.go.jp = > Subject: Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live = onthe website Thanks Omar. To answer your question, first let me point out to other readers that = the two entries that Omar is quoting here exist as values in an = enumeration called EventTypeEnum which as its name implies contains a = list of different labels for grouping types (or classes) of events to be = used as low-granularity buckets for characterizing and classifying = events. Other entries in this enumeration include things like =E2=80=9CFile Ops = (CRUD)=E2=80=9D, =E2=80=9CProcess Mgt=E2=80=9D, =E2=80=9CAuthorization = (ACL)=E2=80=9D, etc. The =E2=80=9CPacket Traffic=E2=80=9D value is intended to characterize = events dealing with network packet traffic as its name implies. The =E2=80=9CData Flow=E2=80=9D value is intended to characterize events = dealing with forms of data flow at a higher level of abstraction than = just packet traffic. The relationship between these two values could be = viewed as =E2=80=9CPacket Traffic=E2=80=9D being a more detailed form of = =E2=80=9CData Flow=E2=80=9D just as the values =E2=80=9CApp Layer = Traffic=E2=80=9D and =E2=80=9CHTTP Layer Traffic=E2=80=9D, also in this = enumeration, could be other levels in this same abstraction stack. The idea behind the varying levels of abstraction is to leave buckets = large enough to capture a wide variety of potential event types (e.g. = data flow events other than obvious things like packet traffic) but also = enable the use of smaller more specific buckets when they are = appropriate and commonly used. Does this make sense? sean From: Omar Santos (osantos) = [mailto:osantos@cisco.com] Sent: Monday, April 16, 2012 8:17 PM To: Luis Nunez; Barnum, Sean D. Cc: idxwg@nicwg.org; = mile@ietf.org; = dallendoug@gmail.com; = sacm@ietf.org; = m-terada@ipa.go.jp Subject: RE: [sacm] [mile] CybOX v1.0 (Draft) is now released and live = onthe website I echo Luis=E2=80=99 comments. It is good to see the inclusion of = network objects. Quick question to the team related to your netflow = comment. I am looking at: http://cybox.mitre.org/XMLSchema/cybox_core_v1.0%28draft%29.xsd =E2=80=A6 and it looks that we renamed it to =E2=80=9CData = Flow=E2=80=9D? Specifies the class of events dealing with = data flow. What is the difference between that and =E2=80=9CPacket = Traffic=E2=80=9D? Specifies the class of events dealing with packet = traffic. Regards, Omar Santos Incident Manager, PSIRT Security Research and Operations Cisco Systems, Inc. Email: os@cisco.com Phone: +1 919 392 8635 PGP Key: 0x3AF27EDC Cisco.com - http://www.cisco.com Cisco Security Advisories and Notices - http://www.cisco.com/go/psirt This email may contain confidential and privileged material for the sole = use of the intended recipient. Any review, use, distribution or = disclosure by others is strictly prohibited. If you are not the intended = recipient (or authorized to receive for the recipient), please contact = the sender by reply email and delete all copies of this message. For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From: sacm-bounces@ietf.org = [mailto:sacm-bounces@ietf.org] On = Behalf Of Luis Nunez Sent: Monday, April 16, 2012 6:44 PM To: Barnum, Sean D. Cc: idxwg@nicwg.org; = mile@ietf.org; Doug Wilson = (dallendoug@gmail.com); = sacm@ietf.org; IPA-Masato Terada = (m-terada@ipa.go.jp) Subject: Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live = onthe website I like the inclusion of the network-centric objects. IPFIX (netflow) = will add an additional perspective from an incident information sharing = standpoint. -ln On Apr 16, 2012, at 4:04 PM, Barnum, Sean D. wrote: Hey everyone, I just wanted to let you all know that CybOX v1.0 (Draft) content is now = live on the website. http://cybox.mitre.org The release notes are = provided inline below. The key items of note are: =E2=80=A2 The release of two formal specifications for the CybOX = language (one for the core language and one for the defined objects) =E2=80=A2 The XML Schema has gone through extensive improvements = for expressiveness, clarity, consistency, efficiency, alignment to = existing normative references and documentation. =E2=80=A2 This release includes an initial set of language = utilities: a draft Snort -> CybOX transform, a draft OpenIOC -> CybOX = transform, and a set of Python bindings for the CybOX language. =E2=80=A2 The website now includes a small set of content = examples. This set will grow going forward. This release involved a lot of hard work from a diverse group of people. = Thank you all for your contributions and effort. We could not have done = it without you. We look forward to everyone=E2=80=99s feedback and collaboration as we = continue to improve and mature the CybOX language. Sean Barnum CybOX v1.0 (Draft) Release Notes The Version 1.0 (Draft) release of Cyber Observable eXpression = (CybOX=E2=84=A2) is intended as a draft release of an initial major = version of the CybOX Language that could be utilized for practical = operational use and integration into other standards efforts. This = release consists of three primary components: a pair of formal language = specifications for the core language content and defined objects = content, a set of language implementation XML schemas (core, = common_types, and ~70 defined object schemas), and a small initial set = of language utilities including an initial draft Snort->CybOX transform, = an initial draft OpenIOC->CybOX transform and a set of CybOX language = Python bindings. Recognizing that this is the first time that the formal = language specifications will be available for review and as such will = likely generate feedback from new stakeholders, this initial major = version is being released as a =E2=80=9Cdraft=E2=80=9D v1.0 with the = expectation of cycles of new feedback and revision before a = =E2=80=9Cfinal=E2=80=9D v1.0 is released. The CybOX v1.0 (Draft) XML schemas include a significant number of = changes from v0.7 to improve: =E2=80=A2 Clarity, documentation, and descriptive formality for = reference and implementation by other standards and users. =E2=80=A2 Consistency, simplicity, and efficiency. =E2=80=A2 Alignment (as appropriate) to existing normative = references. =E2=80=A2 Expressiveness of the schema to better support the broad = set of use cases it targets (malware characterization, indicator and = incident data sharing, event management, etc.) including the addition of = an initial set of network-related defined objects. Summary of changes from CybOX_v0.7 to CybOX_v1.0_(Draft): =C2=B7 Refinement of namespaces and schema locations for better = effectiveness and flexibility going forward. =C2=B7 Normalized all content according to an established set of = naming conventions. =C2=B7 Fully annotated all language items (types, attributes, = elements, etc.). =C2=B7 Moved several commonly leveraged types out of the core = schema and into common_types. =C2=B7 Achieved full typing of entire schema structure such that = all attributes and elements are definitively typed. =C2=B7 Changed all identifiers from ID and IDREF types to be = QNames enabling globally unique identifiers and flexibility for = domain-specific users of CybOX to define their own identifier syntax = locally. =C2=B7 Reordered attributes and elements in numerous types to = better reflect common usage and priority. =C2=B7 Added major_version and minor_version attributes for core = schema. =C2=B7 Added capability to characterize source of overall = observable package data and for individual observables. =C2=B7 Modified the logical composition structure such that any = such compositions are now contained within a Observable_Composition = element providing improved simplicity and modularity. =C2=B7 Removed the Delta element from ObservableType and relocated = the appropriate portions (Change, Trend, and Frequency) to appropriate = locations under Stateful_Measure and Event. =C2=B7 Added a Domain_Specific_Object_Attributes field to Object = utilizing an abstract type that will allow domain-specific use cases to = add in their own domain-specific attributes for Objects. =C2=B7 Added a Tool-Specific_Data field to ToolInformationType = utilizing an abstract type that will allow addition of tool-specific = data. =C2=B7 Added an Indicators field to MeasureSourceType utilizing an = abstract type that will allow characterizing differing formats or = standards of indicators that may have led to the identification of the = observable data. =C2=B7 Enhanced the Hash structure to capture full fuzzy hashes in = addition to simple hashes =C2=B7 Added a new ExtractedFeaturesType that can be used to adorn = differing objects (e.g., files, memory, etc.) to capture extracted = strings, imports, functions and code snippets =C2=B7 Added a ByteRunsType to enable capture of byte runs within = various objects. =C2=B7 Added object_reference attribute to DefinedObjectType to = better support referencing of independently defined Objects from within = another Object definition. =C2=B7 Added a generic DataSegmentType to provide a relatively = abstract way of characterizing data segments that may be = written/read/transmitted or otherwise utilized in actions or defined in = objects. =E2=80=A2 Added several new defined object schemas (API, Code, = Device, DNS_Record, Network_Flow, Network_Packet, Network_Route_Entry, = Network_Subnet, Unix_Network_Route_Entry) including an initial set of = network-centric defined objects. =C2=B7 Modified every defined object schema with added annotations = as well as minor and in some cases substantive changes to fix errors, = improve consistency and alignment with existing normative references, = and to improve expressiveness in support of the targeted use cases. Detailed changes from CybOX_v0.7 to CybOX_v1.0_(Draft): The level of changes within v1.0 (Draft) in the core schema, = common_types and the defined object schemas is too great to list every = change in these release notes. Detailed difference reports are available = for each individual schema = at:http://cybox.mitre.org/XMLSchema/release_notes/cybox_v1.0(draft)_diff_= reports.zip =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Sean Barnum Cyber Security Principal The MITRE Corporation Email: sbarnum@mitre.org _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile ------=_NextPart_000_0029_01CD1C87.E844FB50 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIP6zCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggTXMIIDv6ADAgECAhBcX1ns/Jl/DtI19/BXCcuBMA0G CSqGSIb3DQEBBQUAMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzMwHhcNMTIwNDAzMDAwMDAwWhcNMTMwNDAzMjM1OTU5WjCCAR4xFzAVBgNVBAoTDlZl cmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13 d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChj KTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNDAyBgNVBAsTK0RpZ2l0YWwgSUQg Q2xhc3MgMSAtIE1pY3Jvc29mdCBGdWxsIFNlcnZpY2UxFzAVBgNVBAMUDk1pY2hhZWwgSGFtbWVy MSswKQYJKoZIhvcNAQkBFhxtaWNoYWVsLmhhbW1lckB5YWFuYXRlY2guY29tMIGfMA0GCSqGSIb3 DQEBAQUAA4GNADCBiQKBgQDoKTk9rP/4lG6CLqIR4++IFTuOSLF6bmhDr6eiSahqU0VNP+H/LbiD MAZsK9GQoBYPKQdKzy/gM+fl3Gm6VOdjKl8M3GB6LGgAK8d3ETN5dyKe5CAG7EEbKg9wxHWcuXW7 KYd052ven5Ec+Xj++v3HsE423O5q2mNh1Q8FNsnlXQIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYD VR0gBD0wOzA5BgtghkgBhvhFAQcXATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2ln bi5jb20vcnBhMAsGA1UdDwQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYD VR0fBEkwRzBFoEOgQYY/aHR0cDovL2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20v SW5kQzFEaWdpdGFsSUQtRzMuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQA8rhDezFsw7OlR3+mZOZ39 SCKWNJ4gMlQEe31NNtvs6BUzE1uN+fJeZrJ5zjTdJWeG1NgVugcuzQfdv/m5BYbhgJvNfW6ElqZh cye6imOUx8diekkeHXKYSLnEvCdJItXsC1h/huIT9e83WksM92qI/TFyCq6u39cGf9PaBYbcKcZk jHjNi3SPnGifMC6opGiiyK/vB1lituoBRcJ13Y7XoXA8T0kSR8Dtmqvo1JudcFAbS1srytG1QX1H XTsPkTDKHlwv2ZfmCSKK3sWHDrZfpRglxvcX2OwibcKVkKBJRRw36UuJOIj/u0WYABcYtusAb2+0 nqoGmOEYARnrseTZMIIG7jCCBdagAwIBAgIQcRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUF ADCByjELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZv ciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQ cmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkw NDMwMjM1OTU5WjCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QSAtIEczMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP 6bGNQU4099oL42r6ZYggCxET6ZvgSU6Lb9UB0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYH r54UGAdPWr2f0jGyVBlzRmoZQhHsEnMhjfXcMM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50 ABMN0Ibak2f4MwOuGjxraXj2wCyO4YM/d/mZ//6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yx BF6+wbaULZeQLSfSux7pg2qE9sSyriMGZSalJ1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ 6/tu1ULEvkHH9QIDAQABo4ICuTCCArUwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRw Oi8vb2NzcC52ZXJpc2lnbi5jb20wEgYDVR0TAQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CG SAGG+EUBBxcBMFYwKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYI KwYBBQUHAgIwHhocaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6Al hiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYI KwYBBQUHAQwEYjBgoV6gXDBaMFgwVhYJaW1hZ2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQ UjibKaxLB4shBRgwJhYkaHR0cDovL2xvZ28udmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1Ud EQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRlTGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EI Qf04BKJL57XM9UP2SSsR+DCB8QYDVR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4 BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkx RTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZ gbWpBbVSOOk5hIls5DSoWufYbAlMJBq6WaSHO3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v 8dKBl8pUWkO/N4t6jhmND0OojPKvYLMVirOVnDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM6 1a4ScAjr+zvid+zoK2Q1ds262uDRyxTWcVibvtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/ XLJtSd5lUkL7DojS7Uodv0vj+Mxy+kgOZY5JyNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4 VRaMxmgD5yKocwuxvKDaUljdCg5/wYIxggS4MIIEtAIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTsw OQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykw OTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhBcX1ns/Jl/DtI19/BXCcuBMAkGBSsO AwIaBQCgggMbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQx NzE0NTAzMFowIwYJKoZIhvcNAQkEMRYEFIcWIjUG99t0AcZtLuUzvqfOue7EMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIIBAwYJKwYB BAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzMCEFxfWez8mX8O0jX38FcJy4EwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkG A1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz dCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24u Y29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5W ZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhBcX1ns/Jl/DtI1 9/BXCcuBMA0GCSqGSIb3DQEBAQUABIGAXmyAZl2LQ8G3vaY1OnQCALvIIPfAh5XiZ5q/YFRiOL3l QPddwTYg/DNMc35q/B1ZS/8tRpCmVHpR4fVvW6zQfuw9Rj1vuNJ0AcKtLiv56y46pGXg+Ow35AM7 n031+h4en0+txrWdq2zazySDwowEVQNxZEVGiY9Z6u5A0digmBMAAAAAAAA= ------=_NextPart_000_0029_01CD1C87.E844FB50-- From michael.hammer@yaanatech.com Tue Apr 17 12:28:18 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED4F511E80D5; Tue, 17 Apr 2012 12:28:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.665 X-Spam-Level: X-Spam-Status: No, score=-2.665 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F2IvgeJximOr; Tue, 17 Apr 2012 12:28:13 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id 87E4D11E80A0; Tue, 17 Apr 2012 12:28:13 -0700 (PDT) Received: from EX2K10MB1.corp.yaanatech.com ([fe80::5568:c31d:f64a:f66a]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Tue, 17 Apr 2012 12:28:13 -0700 From: Michael Hammer To: "Barnum, Sean D." , "osantos@cisco.com" , "Thomas.Millar@hq.dhs.gov" , "lnunez@c3isecurity.com" Thread-Topic: [mile] [sacm] CybOX v1.0 (Draft) is now released and live onthe website Thread-Index: AQHNHFhQtpFrr+nGFkWqCWY68NIgupae/ygAgADWyAD//48qoA== Date: Tue, 17 Apr 2012 19:28:12 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB38A0193@EX2K10MB1.corp.yaanatech.com> References: <7F48813B48558A4BB5CB7BB714E5B5A9171B16@IMCMBX03.MITRE.ORG> <69CE2DCD9DAC3D48B830E0723141170B02A39BD2@ZAU1UG-0308.DHSNET.DS1.DHS> <953A2E460DBE7C43AC13E30B87C5B4FF080A1C09@XMB-RCD-106.cisco.com> <7F48813B48558A4BB5CB7BB714E5B5A9171BA1@IMCMBX03.MITRE.ORG> <00C069FD01E0324C9FFCADF539701DB389FC37@EX2K10MB1.corp.yaanatech.com> <7F48813B48558A4BB5CB7BB714E5B5A9173046@IMCMBX03.MITRE.ORG> In-Reply-To: <7F48813B48558A4BB5CB7BB714E5B5A9173046@IMCMBX03.MITRE.ORG> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.88.19] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0156_01CD1CAE.B1C9C4D0" MIME-Version: 1.0 Cc: "idxwg@nicwg.org" , "mile@ietf.org" , "dallendoug@gmail.com" , "sacm@ietf.org" , "m-terada@ipa.go.jp" Subject: Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live onthe website X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 19:28:19 -0000 ------=_NextPart_000_0156_01CD1CAE.B1C9C4D0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0157_01CD1CAE.B1C9C4D0" ------=_NextPart_001_0157_01CD1CAE.B1C9C4D0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Sean, =20 What you say makes sense. But, if you will bear with me. (Still = learning this.) =20 If one used Packet Traffic event type always instead of Data Flow event = type, would some distinction be lost? Or, put another way, since the packet stuff seems to cover most = network-based events, does Data Flow involve something that is not on = the wire? (Such as an inter-process communication that doesn=E2=80=99t go through = a protocol stack.) =20 Mike =20 =20 From: Barnum, Sean D. [mailto:sbarnum@mitre.org]=20 Sent: Tuesday, April 17, 2012 3:03 PM To: Michael Hammer; osantos@cisco.com; Thomas.Millar@hq.dhs.gov; = lnunez@c3isecurity.com Cc: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; = m-terada@ipa.go.jp Subject: RE: [mile] [sacm] CybOX v1.0 (Draft) is now released and live = onthe website =20 Mike, =20 Just to clarify, all of our discussion so far about =E2=80=9CData = Flow=E2=80=9D and netflow were all in regards to an enumeration called = EventTypeEnum that simply lets you tag a cyber observable event with a = type label. It is metadata for an event description. The only object we have been talking about in any detail so far was the = Network_Flow object. These two topics are totally independent of each = other. There is no Data_Flow object. The abstraction overlap we have been discussing is only in the metadata = tag applied to an event to characterize what type/class of event it is. =20 The defined objects themselves (including Network_Flow) have been = designed to avoid, as much as possible, overlap of the type you = describe. The approach we have taken is that where there is common structure and = meaning relevant to multiple different types of objects, the structure = for that commonality is broken out into its own object (e.g. Address, = URI, Port, Account, Process, etc.). Content based on this common object structure can be embedded within a = leveraging object (via direct use of the object type) if the content is = directly relevant only within the context of that object or as an = independent object and associated to any number of other objects to = which it is relevant utilizing relationships. We make no guarantees that we have managed to implement this approach = flawlessly but we believe that it yields a good balance of consistency, = efficiency and flexibility. It also allows easy modular use of only what = is relevant within a given context and enables extension and evolution = to easily occur in a localized fashion rather than having to extend and = modify one monolithic structure standard. =20 Does that make sense? =20 sean =20 From: Michael Hammer [mailto:michael.hammer@yaanatech.com]=20 Sent: Tuesday, April 17, 2012 9:18 AM To: Barnum, Sean D.; osantos@cisco.com; Thomas.Millar@hq.dhs.gov; = lnunez@c3isecurity.com Cc: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; = m-terada@ipa.go.jp Subject: RE: [mile] [sacm] CybOX v1.0 (Draft) is now released and live = onthe website =20 Sean, =20 Does the overlap between the various objects present a problem? =20 If there are one or more objects that could carry the same data, then = human nature means that probability-wise someone will choose data flow = instead of Netflow. That is the underlying principle in Murphy=E2=80=99s Law, where you try = to design it so that there is only one way to do it, and thus private = Murphy won=E2=80=99t do it the =E2=80=9Cwrong=E2=80=9D way. =20 Just wondering if these should be mutually exclusive sets. And designed = as such. Might improve interoperability. (And avoid discussions like this in = future.) J =20 Mike =20 =20 From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of = Barnum, Sean D. Sent: Tuesday, April 17, 2012 1:10 AM To: Omar Santos (osantos); Millar, Thomas; lnunez@c3isecurity.com Cc: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; = m-terada@ipa.go.jp Subject: Re: [mile] [sacm] CybOX v1.0 (Draft) is now released and live = onthe website =20 =E2=80=9Cupper layer=E2=80=9D? Yes, as in higher abstraction. Just =E2=80=9Cprotocols=E2=80=9D? No. =20 You guys have been looking at this through the lens of network flow = which if fine for thinking about that perspective but it is important to = also realize that the EventTypeEnum and its =E2=80=9CData Flow=E2=80=9D = value go far beyond network-related scope. It is about a lot of other types of potential data flows (as I just = outlined in a response to Tom) that have nothing to do with network = flow. =20 Thanks for your response though. This is the kind of discussions that we = hope to have a lot more of among the various supported communities. =20 =20 BTW, you may have noticed that the Network_Flow object within CybOX v1.0 = (Draft) supports expression of netflow within several of the most common = formats including Netflow9 (as well as IPFIX as Luis pointed out, = Netflow5 and SiLK as well as bi-directional flow in YAF). The common = 5-tuple or 7-tuple (you describe) (in our case it is an 8-tuple as we = broke the router interface out into both ingress and egress J) shared by = pretty much all of the netflow approaches has been broken out into a = shared Network_Flow_Label structure. The various context-dependent = portions of the independent approaches are then captured within optional = structures dedicated to each of them. We hope that eventually the = community can work to come together towards a single overall common = expressive structure for netflow that meets the needs of all. We hope = that CybOX and its use can even help that sort of maturation and = normalization. But since no such universal structure exists today, we = decided to enable optional expression of the most common individual = formats within a single netflow object to serve the large majority of = relevant users, maintain flexibility and enable discussions and analysis = of netflow within a common package. We look forward to continuing discussions with the community to validate = or invalidate this approach and to refine and mature going forward. =20 Sean=20 =20 From: Omar Santos (osantos) [mailto:osantos@cisco.com]=20 Sent: Monday, April 16, 2012 11:57 PM To: Millar, Thomas; Barnum, Sean D.; lnunez@c3isecurity.com Cc: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; = m-terada@ipa.go.jp Subject: RE: [sacm] [mile] CybOX v1.0 (Draft) is now released and live = onthe website =20 I believe that what Sean is saying is that =E2=80=9Cdata flow=E2=80=9D = is just a value that is meant for upper layer protocols. But, you have a = good point. Traditionally, a =E2=80=9Cflow=E2=80=9D in = =E2=80=9CNetflow=E2=80=9D is based on a set of 5 and up to 7 IP packet = attributes: =20 - IP source address - IP destination address - Source port - Destination port - Layer 3 protocol type - Class of Service - Router or switch interface =20 Although, there is a lot more support with Netflow version 9: http://www.cisco.com/en/US/technologies/tk648/tk362/technologies_white_pa= per09186a00800a3db9_ps6601_Products_White_Paper.html =20 =20 =20 Regards, Omar=20 =20 From: Millar, Thomas [mailto:Thomas.Millar@hq.dhs.gov]=20 Sent: Monday, April 16, 2012 11:46 PM To: sbarnum@mitre.org; Omar Santos (osantos); lnunez@c3isecurity.com Cc: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; = m-terada@ipa.go.jp Subject: Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live = onthe website =20 If "data flow" is a euphemism for "netflow" is there any reason not to = call it that? Tom Millar=20 http://www.us-cert.gov/=20 ------------------=20 Missit me Rubus fruticosus:=20 202 631 1915=20 =20 From: Barnum, Sean D. [mailto:sbarnum@mitre.org]=20 Sent: Monday, April 16, 2012 11:29 PM To: Omar Santos (osantos) ; Luis Nunez = =20 Cc: idxwg@nicwg.org ; mile@ietf.org ; = dallendoug@gmail.com ; sacm@ietf.org = ; m-terada@ipa.go.jp =20 Subject: Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live = onthe website=20 =20 Thanks Omar. =20 To answer your question, first let me point out to other readers that = the two entries that Omar is quoting here exist as values in an = enumeration called EventTypeEnum which as its name implies contains a = list of different labels for grouping types (or classes) of events to be = used as low-granularity buckets for characterizing and classifying = events. Other entries in this enumeration include things like =E2=80=9CFile Ops = (CRUD)=E2=80=9D, =E2=80=9CProcess Mgt=E2=80=9D, =E2=80=9CAuthorization = (ACL)=E2=80=9D, etc. =20 The =E2=80=9CPacket Traffic=E2=80=9D value is intended to characterize = events dealing with network packet traffic as its name implies. The =E2=80=9CData Flow=E2=80=9D value is intended to characterize events = dealing with forms of data flow at a higher level of abstraction than = just packet traffic. The relationship between these two values could be = viewed as =E2=80=9CPacket Traffic=E2=80=9D being a more detailed form of = =E2=80=9CData Flow=E2=80=9D just as the values =E2=80=9CApp Layer = Traffic=E2=80=9D and =E2=80=9CHTTP Layer Traffic=E2=80=9D, also in this = enumeration, could be other levels in this same abstraction stack. The idea behind the varying levels of abstraction is to leave buckets = large enough to capture a wide variety of potential event types (e.g. = data flow events other than obvious things like packet traffic) but also = enable the use of smaller more specific buckets when they are = appropriate and commonly used. =20 Does this make sense?=20 =20 sean =20 From: Omar Santos (osantos) [mailto:osantos@cisco.com]=20 Sent: Monday, April 16, 2012 8:17 PM To: Luis Nunez; Barnum, Sean D. Cc: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; = m-terada@ipa.go.jp Subject: RE: [sacm] [mile] CybOX v1.0 (Draft) is now released and live = onthe website =20 I echo Luis=E2=80=99 comments. It is good to see the inclusion of = network objects. Quick question to the team related to your netflow = comment. =20 I am looking at: http://cybox.mitre.org/XMLSchema/cybox_core_v1.0%28draft%29.xsd =20 =E2=80=A6 and it looks that we renamed it to =E2=80=9CData = Flow=E2=80=9D? =20 Specifies the class of events dealing with = data flow. =20 =20 What is the difference between that and =E2=80=9CPacket = Traffic=E2=80=9D? =20 Specifies the class of events dealing with packet = traffic. =20 =20 =20 =20 Regards, Omar Santos Incident Manager, PSIRT Security Research and Operations Cisco Systems, Inc. Email: os@cisco.com Phone: +1 919 392 8635 PGP Key: 0x3AF27EDC Cisco.com - http://www.cisco.com Cisco Security Advisories and Notices - http://www.cisco.com/go/psirt This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message. For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html =20 From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of = Luis Nunez Sent: Monday, April 16, 2012 6:44 PM To: Barnum, Sean D. Cc: idxwg@nicwg.org; mile@ietf.org; Doug Wilson (dallendoug@gmail.com); = sacm@ietf.org; IPA-Masato Terada (m-terada@ipa.go.jp) Subject: Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live = onthe website =20 I like the inclusion of the network-centric objects. IPFIX (netflow) = will add an additional perspective from an incident information sharing = standpoint. =20 =20 -ln =20 On Apr 16, 2012, at 4:04 PM, Barnum, Sean D. wrote: =20 Hey everyone, =20 I just wanted to let you all know that CybOX v1.0 (Draft) content is now = live on the website. http://cybox.mitre.org The release notes are provided inline below. The key items of note are: =C2=B7 The release of two formal specifications for the CybOX = language (one for the core language and one for the defined objects) =C2=B7 The XML Schema has gone through extensive improvements for = expressiveness, clarity, consistency, efficiency, alignment to existing = normative references and documentation. =C2=B7 This release includes an initial set of language = utilities: a draft Snort -> CybOX transform, a draft OpenIOC -> CybOX = transform, and a set of Python bindings for the CybOX language. =C2=B7 The website now includes a small set of content examples. = This set will grow going forward. This release involved a lot of hard work from a diverse group of people. = Thank you all for your contributions and effort. We could not have done = it without you. We look forward to everyone=E2=80=99s feedback and collaboration as we = continue to improve and mature the CybOX language. =20 Sean Barnum =20 =20 =20 CybOX v1.0 (Draft) Release Notes The Version 1.0 (Draft) release of Cyber Observable eXpression = (CybOX=E2=84=A2) is intended as a draft release of an initial major = version of the CybOX Language that could be utilized for practical = operational use and integration into other standards efforts. This = release consists of three primary components: a pair of formal language = specifications for the core language content and defined objects = content, a set of language implementation XML schemas (core, = common_types, and ~70 defined object schemas), and a small initial set = of language utilities including an initial draft Snort->CybOX transform, = an initial draft OpenIOC->CybOX transform and a set of CybOX language = Python bindings. Recognizing that this is the first time that the formal = language specifications will be available for review and as such will = likely generate feedback from new stakeholders, this initial major = version is being released as a =E2=80=9Cdraft=E2=80=9D v1.0 with the = expectation of cycles of new feedback and revision before a = =E2=80=9Cfinal=E2=80=9D v1.0 is released. The CybOX v1.0 (Draft) XML schemas include a significant number of = changes from v0.7 to improve: =C2=B7 Clarity, documentation, and descriptive formality for = reference and implementation by other standards and users. =C2=B7 Consistency, simplicity, and efficiency. =C2=B7 Alignment (as appropriate) to existing normative = references. =C2=B7 Expressiveness of the schema to better support the broad = set of use cases it targets (malware characterization, indicator and = incident data sharing, event management, etc.) including the addition of = an initial set of network-related defined objects. Summary of changes from CybOX_v0.7 to CybOX_v1.0_(Draft): =C2=B7 Refinement of namespaces and schema locations for better = effectiveness and flexibility going forward. =C2=B7 Normalized all content according to an established set of = naming conventions. =C2=B7 Fully annotated all language items (types, attributes, = elements, etc.). =C2=B7 Moved several commonly leveraged types out of the core = schema and into common_types. =C2=B7 Achieved full typing of entire schema structure such that = all attributes and elements are definitively typed. =C2=B7 Changed all identifiers from ID and IDREF types to be = QNames enabling globally unique identifiers and flexibility for = domain-specific users of CybOX to define their own identifier syntax = locally. =C2=B7 Reordered attributes and elements in numerous types to = better reflect common usage and priority. =C2=B7 Added major_version and minor_version attributes for core = schema. =C2=B7 Added capability to characterize source of overall = observable package data and for individual observables. =C2=B7 Modified the logical composition structure such that any = such compositions are now contained within a Observable_Composition = element providing improved simplicity and modularity. =C2=B7 Removed the Delta element from ObservableType and relocated = the appropriate portions (Change, Trend, and Frequency) to appropriate = locations under Stateful_Measure and Event. =C2=B7 Added a Domain_Specific_Object_Attributes field to Object = utilizing an abstract type that will allow domain-specific use cases to = add in their own domain-specific attributes for Objects. =C2=B7 Added a Tool-Specific_Data field to ToolInformationType = utilizing an abstract type that will allow addition of tool-specific = data. =C2=B7 Added an Indicators field to MeasureSourceType utilizing an = abstract type that will allow characterizing differing formats or = standards of indicators that may have led to the identification of the = observable data. =C2=B7 Enhanced the Hash structure to capture full fuzzy hashes in = addition to simple hashes =C2=B7 Added a new ExtractedFeaturesType that can be used to adorn = differing objects (e.g., files, memory, etc.) to capture extracted = strings, imports, functions and code snippets =C2=B7 Added a ByteRunsType to enable capture of byte runs within = various objects. =C2=B7 Added object_reference attribute to DefinedObjectType to = better support referencing of independently defined Objects from within = another Object definition. =C2=B7 Added a generic DataSegmentType to provide a relatively = abstract way of characterizing data segments that may be = written/read/transmitted or otherwise utilized in actions or defined in = objects. =C2=B7 Added several new defined object schemas (API, Code, = Device, DNS_Record, Network_Flow, Network_Packet, Network_Route_Entry, = Network_Subnet, Unix_Network_Route_Entry) including an initial set of = network-centric defined objects. =C2=B7 Modified every defined object schema with added annotations = as well as minor and in some cases substantive changes to fix errors, = improve consistency and alignment with existing normative references, = and to improve expressiveness in support of the targeted use cases. Detailed changes from CybOX_v0.7 to CybOX_v1.0_(Draft): The level of changes within v1.0 (Draft) in the core schema, = common_types and the defined object schemas is too great to list every = change in these release notes. Detailed difference reports are available = for each individual schema at: = = http://cybox.mitre.org/XMLSchema/release_notes/cybox_v1.0(draft)_diff_rep= orts.zip =20 =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Sean Barnum Cyber Security Principal The MITRE Corporation Email: sbarnum@mitre.org =20 _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile =20 ------=_NextPart_001_0157_01CD1CAE.B1C9C4D0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Sean,

 

What you say makes sense.=C2=A0 But, if you will bear with me.=C2=A0 = (Still learning this.)

 

If one used Packet Traffic event type always instead of Data Flow = event type, would some distinction be lost?

Or, put another way, since the packet stuff seems to cover most = network-based events, does Data Flow involve something that is not on = the wire?

(Such as an inter-process communication that doesn=E2=80=99t go = through a protocol stack.)

 

Mike

 

 

From:= = Barnum, Sean D. [mailto:sbarnum@mitre.org]
Sent: Tuesday, = April 17, 2012 3:03 PM
To: Michael Hammer; osantos@cisco.com; = Thomas.Millar@hq.dhs.gov; lnunez@c3isecurity.com
Cc: = idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; = m-terada@ipa.go.jp
Subject: RE: [mile] [sacm] CybOX v1.0 = (Draft) is now released and live onthe = website

 

Mike,

 

Just to clarify, all of our discussion so far about =E2=80=9CData = Flow=E2=80=9D and netflow were all in regards to an enumeration called = EventTypeEnum that simply lets you tag a cyber observable event with a = type label. It is metadata for an event = description.

The only object we have been talking about in any detail so far was = the Network_Flow object. These two topics are totally independent of = each other. There is no Data_Flow object.

The abstraction overlap we have been discussing is only in the = metadata tag applied to an event to characterize what type/class of = event it is.

 

The defined objects themselves (including Network_Flow) have been = designed to avoid, as much as possible, overlap of the type you = describe.

The approach we have taken is that where there is common structure = and meaning relevant to multiple different types of objects, the = structure for that commonality is broken out into its own object (e.g. = Address, URI, Port, Account, Process, etc.).

Content based on this common object structure can be embedded within = a leveraging object (via direct use of the object type) if the content = is directly relevant only within the context of that object or as an = independent object and associated to any number of other objects to = which it is relevant utilizing relationships.

We make no guarantees that we have managed to implement this approach = flawlessly but we believe that it yields a good balance of consistency, = efficiency and flexibility. It also allows easy modular use of only what = is relevant within a given context and enables extension and evolution = to easily occur in a localized fashion rather than having to extend and = modify one monolithic structure standard.

 

Does that make sense?

 

sean

 

From:= = Michael Hammer [mailto:michael.ham= mer@yaanatech.com]
Sent: Tuesday, April 17, 2012 9:18 = AM
To: Barnum, Sean D.; osantos@cisco.com; Thomas.Millar@hq.dhs.gov; = lnunez@c3isecurity.com
C= c: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; m-terada@ipa.go.jp
Subject:<= /b> RE: [mile] [sacm] CybOX v1.0 (Draft) is now released and live onthe = website

 

Sean,

 

Does the overlap between the various objects present a = problem?

 

If there are one or more objects that could carry the same data, then = human nature means that probability-wise someone will choose data flow = instead of Netflow.

That is the underlying principle in Murphy=E2=80=99s Law, where you = try to design it so that there is only one way to do it, and thus = private Murphy won=E2=80=99t do it the =E2=80=9Cwrong=E2=80=9D = way.

 

Just wondering if these should be mutually exclusive sets.  And = designed as such.

Might improve interoperability.  (And avoid discussions like = this in future.)  J

 

Mike

 

 

From:= = mile-bounces@ietf.org [mailto:mile-bounces@ietf.= org] On Behalf Of Barnum, Sean D.
Sent: Tuesday, = April 17, 2012 1:10 AM
To: Omar Santos (osantos); Millar, = Thomas; lnunez@c3isecurity.com
C= c: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; m-terada@ipa.go.jp
Subject:<= /b> Re: [mile] [sacm] CybOX v1.0 (Draft) is now released and live onthe = website

 

=E2=80=9Cupper layer=E2=80=9D? Yes, as in higher = abstraction.

Just =E2=80=9Cprotocols=E2=80=9D? No.

 

You guys have been looking at this through the lens of network flow = which if fine for thinking about that perspective but it is important to = also realize that the EventTypeEnum and its =E2=80=9CData Flow=E2=80=9D = value go far beyond network-related scope.

It is about a lot of other types of potential data flows (as I just = outlined in a response to Tom) that have nothing to do with network = flow.

 

Thanks for your response though. This is the kind of discussions that = we hope to have a lot more of among the various supported = communities.

 

 

BTW, you may have noticed that the Network_Flow object within CybOX = v1.0 (Draft) supports expression of netflow within several of the most = common formats including Netflow9 (as well as IPFIX as Luis pointed out, = Netflow5 and SiLK as well as bi-directional flow in YAF). The common = 5-tuple or 7-tuple (you describe) (in our case it is an 8-tuple as we = broke the router interface out into both ingress and egress J) shared by pretty much all of the netflow approaches has been broken = out into a shared Network_Flow_Label structure. The various = context-dependent portions of the independent approaches are then = captured within optional structures dedicated to each of them. We hope = that eventually the community can work to come together towards a single = overall common expressive structure for netflow that meets the needs of = all. We hope that CybOX and its use can even help that sort of = maturation and normalization. But since no such universal structure = exists today, we decided to enable optional expression of the most = common individual formats within a single netflow object to serve the = large majority of relevant users, maintain flexibility and enable = discussions and analysis of netflow within a common = package.

We look forward to continuing discussions with the community to = validate or invalidate this approach and to refine and mature going = forward.

 

Sean

 

From:= = Omar Santos (osantos) [mailto:osantos@cisco.com]=
Sent: Monday, April 16, 2012 11:57 PM
To: Millar, = Thomas; Barnum, Sean D.; lnunez@c3isecurity.com
C= c: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; m-terada@ipa.go.jp
Subject:<= /b> RE: [sacm] [mile] CybOX v1.0 (Draft) is now released and live onthe = website

 

I believe that what Sean is saying is that =E2=80=9Cdata = flow=E2=80=9D is just a value that is meant for upper layer protocols. = But, you have a good point. Traditionally, a =E2=80=9Cflow=E2=80=9D in = =E2=80=9CNetflow=E2=80=9D is based on a set of 5 and up to 7 IP packet = attributes:

 

- IP source address

- IP destination address

- Source port

- Destination port

- Layer 3 protocol type

- Class of Service

- Router or switch interface

 

Although, there is a lot more support with Netflow version = 9:

http://www.= cisco.com/en/US/technologies/tk648/tk362/technologies_white_paper09186a00= 800a3db9_ps6601_Products_White_Paper.html

 

 

 

Regards,

Omar

 

From:= = Millar, Thomas [mailto:Thomas.Millar@h= q.dhs.gov]
Sent: Monday, April 16, 2012 11:46 = PM
To: sbarnum@mitre.org; Omar Santos = (osantos); lnunez@c3isecurity.com
C= c: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; m-terada@ipa.go.jp
Subject:<= /b> Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live onthe = website

 

If "data flow" is a euphemism for "netflow" is = there any reason not to call it that?

Tom Millar
http://www.us-cert.gov/ =
------------------
Missit me Rubus fruticosus:
202 631 1915 =

 

From<= /b>: = Barnum, Sean D. [mailto:sbarnum@mitre.org]=
Sent: Monday, April 16, 2012 11:29 PM
To: Omar = Santos (osantos) <osantos@cisco.com>; Luis Nunez = <lnunez@c3isecurity.com> =
Cc: idxwg@nicwg.org = <idxwg@nicwg.org>; mile@ietf.org <mile@ietf.org>; dallendoug@gmail.com <dallendoug@gmail.com>; sacm@ietf.org <sacm@ietf.org>; m-terada@ipa.go.jp <m-terada@ipa.go.jp> =
Subject: Re: [sacm] [mile] CybOX v1.0 (Draft) is now released = and live onthe website
 

Thanks Omar.

 

To answer your question, first let me point out to other readers that = the two entries that Omar is quoting here exist as values in an = enumeration called EventTypeEnum which as its name implies contains a = list of different labels for grouping types (or classes) of events to be = used as low-granularity buckets for characterizing and classifying = events.

Other entries in this enumeration include things like =E2=80=9CFile = Ops (CRUD)=E2=80=9D, =E2=80=9CProcess Mgt=E2=80=9D, = =E2=80=9CAuthorization (ACL)=E2=80=9D, etc.

 

The =E2=80=9CPacket Traffic=E2=80=9D value is intended to = characterize events dealing with network packet traffic as its name = implies.

The =E2=80=9CData Flow=E2=80=9D value is intended to characterize = events dealing with forms of data flow at a higher level of abstraction = than just packet traffic. The relationship between these two values = could be viewed as =E2=80=9CPacket Traffic=E2=80=9D being a more = detailed form of =E2=80=9CData Flow=E2=80=9D just as the values = =E2=80=9CApp Layer Traffic=E2=80=9D and =E2=80=9CHTTP Layer = Traffic=E2=80=9D, also in this enumeration, could be other levels in = this same abstraction stack.

The idea behind the varying levels of abstraction is to leave =  buckets large enough to capture a wide variety of potential event = types (e.g. data flow events other than obvious things like packet = traffic) but also enable the use of smaller more specific buckets when = they are appropriate and commonly used.

 

Does this make sense?

 

sean

 

From:= = Omar Santos (osantos) [mailto:osantos@cisco.com]=
Sent: Monday, April 16, 2012 8:17 PM
To: Luis = Nunez; Barnum, Sean D.
Cc: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; m-terada@ipa.go.jp
Subject:<= /b> RE: [sacm] [mile] CybOX v1.0 (Draft) is now released and live onthe = website

 

I echo Luis=E2=80=99 comments. It is good to see the inclusion of = network objects. Quick question to the team related to your netflow = comment.

 

I am looking at:

= http://cybox.mitre.org/XMLSchema/cybox_core_v1.0%28draft%29.xsd<= /o:p>

 

=E2=80=A6 and it looks that we renamed it to =E2=80=9CData = Flow=E2=80=9D?

 

<xs:enumeration = value=3D"Data Flow">

   = <xs:annotation>

        = <xs:documentation>Specifies the class of events dealing with data = flow.</xs:documentation>

   = </xs:annotation>

</xs:enumeration>

 

 

What is the difference between that and =E2=80=9CPacket = Traffic=E2=80=9D?

 

<xs:enumeration value=3D"Packet =
Traffic">
   =
<xs:annotation>
     =
<xs:documentation>Specifies the class of events dealing with =
packet traffic.</xs:documentation>
   =
</xs:annotation>
</xs:enumeration>

 

 

 

 

Regards,

Omar Santos
Incident Manager, = PSIRT
Security Research and Operations
Cisco Systems, = Inc.
Email: os@cisco.com
Phone: +1 919 392 = 8635
PGP Key: 0x3AF27EDC

Cisco.com - http://www.cisco.com
Cisco Security = Advisories and Notices - http://www.cisco.com/go/psirt<= br>
This email may contain confidential and privileged material for = the sole
use of the intended recipient. Any review, use, distribution = or
disclosure by others is strictly prohibited. If you are not the = intended
recipient (or authorized to receive for the recipient), = please contact
the sender by reply email and delete all copies of = this message.

For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html=

 

From:= = sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.= org] On Behalf Of Luis Nunez
Sent: Monday, April = 16, 2012 6:44 PM
To: Barnum, Sean D.
Cc: idxwg@nicwg.org; mile@ietf.org; Doug Wilson (dallendoug@gmail.com); sacm@ietf.org; IPA-Masato Terada (m-terada@ipa.go.jp)
Subject:= Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live onthe = website

 

I like the inclusion of the network-centric = objects.  IPFIX (netflow)  will add an additional perspective = from an incident information sharing standpoint. =  

 

-ln

 

On Apr 16, 2012, at 4:04 = PM, Barnum, Sean D. wrote:

 

Hey = everyone,

 =

I just = wanted to let you all know that CybOX v1.0 (Draft) content is now live = on the website. http://cybox.mitre.org

The = release notes are provided inline = below.

The key = items of note are:

=C2=B7        The = release of two formal specifications for the CybOX language (one for the = core language and one for the defined = objects)

=C2=B7        The XML = Schema has gone through extensive improvements for expressiveness, = clarity, consistency, efficiency, alignment to existing normative = references and documentation.

=C2=B7        This = release includes an initial set of language utilities: a draft Snort = -> CybOX transform, a draft OpenIOC -> CybOX transform, and a set = of Python bindings for the CybOX language.

=C2=B7        The = website now includes a small set of content examples. This set will grow = going forward.

This = release involved a lot of hard work from a diverse group of people. = Thank you all for your contributions and effort. We could not have done = it without you.

We look = forward to everyone=E2=80=99s feedback and collaboration as we continue = to improve and mature the CybOX = language.

 =

Sean = Barnum

 =

 =

 =

CybOX v1.0 (Draft) Release = Notes

The Version 1.0 (Draft) release of Cyber = Observable eXpression (CybOX=E2=84=A2) is intended as a draft release of an initial major version of = the CybOX Language that could be utilized for practical operational use = and integration into other standards efforts. This release consists of = three primary components: a pair of formal language specifications for = the core language content and defined objects content, a set of language = implementation XML schemas (core, common_types, and ~70 defined object = schemas), and a small initial set of language utilities including an = initial draft Snort->CybOX transform, an initial draft = OpenIOC->CybOX transform and a set of CybOX language Python bindings. = Recognizing that this is the first time that the formal language = specifications will be available for review and as such will likely = generate feedback from new stakeholders, this initial major version is = being released as a =E2=80=9Cdraft=E2=80=9D v1.0 with the expectation of = cycles of new feedback and revision before a =E2=80=9Cfinal=E2=80=9D = v1.0 is released.=

The CybOX v1.0 (Draft) XML schemas include a = significant number of changes from v0.7 to improve:=

=C2=B7       Clarity, = documentation, and descriptive formality for reference and = implementation by other standards and users.=

=C2=B7       Consistency, = simplicity, and efficiency.=

=C2=B7       Alignment (as = appropriate) to existing normative references.=

=C2=B7       Expressiveness of the = schema to better support the broad set of use cases it targets (malware = characterization, indicator and incident data sharing, event management, = etc.) including the addition of an initial set of network-related = defined objects.=

Summary = of changes from CybOX_v0.7 to CybOX_v1.0_(Draft):=

=C2=B7       = Refinement of namespaces and schema = locations for better effectiveness and flexibility going forward.=

=C2=B7       = Normalized all content according to an = established set of naming conventions.=

=C2=B7       = Fully annotated all language items = (types, attributes, elements, etc.).=

=C2=B7       = Moved several commonly leveraged types = out of the core schema and into common_types.=

=C2=B7       = Achieved full typing of entire schema = structure such that all attributes and elements are definitively = typed.=

=C2=B7       = Changed all identifiers from ID and IDREF = types to be QNames enabling globally unique identifiers and flexibility = for domain-specific users of CybOX to define their own identifier syntax = locally.=

=C2=B7       = Reordered attributes and elements in = numerous types to better reflect common usage and priority.=

=C2=B7       = Added major_version and minor_version = attributes for core schema.=

=C2=B7       = Added capability to characterize source = of overall observable package data and for individual observables.=

=C2=B7       = Modified the logical composition = structure such that any such compositions are now contained within a = Observable_Composition element providing improved simplicity and = modularity.=

=C2=B7       = Removed the Delta element from = ObservableType and relocated the appropriate portions (Change, Trend, = and Frequency) to appropriate locations under Stateful_Measure and = Event.=

=C2=B7       = Added a Domain_Specific_Object_Attributes = field to Object utilizing an abstract type that will allow = domain-specific use cases to add in their own domain-specific attributes = for Objects.=

=C2=B7       = Added a Tool-Specific_Data field to = ToolInformationType utilizing an abstract type that will allow addition = of tool-specific data.=

=C2=B7       = Added an Indicators field to = MeasureSourceType utilizing an abstract type that will allow = characterizing differing formats or standards of indicators that may = have led to the identification of the observable data.=

=C2=B7       = Enhanced the Hash structure to capture = full fuzzy hashes in addition to simple hashes=

=C2=B7       = Added a new ExtractedFeaturesType that = can be used to adorn differing objects (e.g., files, memory, etc.) to = capture extracted strings, imports, functions and code snippets=

=C2=B7       = Added a ByteRunsType to enable capture of = byte runs within various objects.=

=C2=B7       = Added object_reference attribute to = DefinedObjectType to better support referencing of independently defined = Objects from within another Object definition.=

=C2=B7       = Added a generic DataSegmentType to = provide a relatively abstract way of characterizing data segments that = may be written/read/transmitted or otherwise utilized in actions or = defined in objects.=

=C2=B7        Added several new = defined object schemas (API, Code, Device, DNS_Record, Network_Flow, = Network_Packet, Network_Route_Entry, Network_Subnet, = Unix_Network_Route_Entry) including an initial set of network-centric = defined objects.

=C2=B7       = Modified every defined object schema with = added annotations as well as minor and in some cases substantive changes = to fix errors, improve consistency and alignment with existing normative = references, and to improve expressiveness in support of the targeted use = cases.=

Detailed changes from CybOX_v0.7 to = CybOX_v1.0_(Draft):=

The level of changes within v1.0 (Draft) in = the core schema, common_types and the defined object schemas is too = great to list every change in these release notes. Detailed difference = reports are available for each individual schema at:http://cybox.mitre.org/XMLSchema/release_notes/cybox_v1.0= (draft)_diff_reports.zip

 =

 =

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

Sean Barnum=

Cyber Security Principal=

The MITRE Corporation=

 =

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

 

------=_NextPart_001_0157_01CD1CAE.B1C9C4D0-- ------=_NextPart_000_0156_01CD1CAE.B1C9C4D0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIP6zCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggTXMIIDv6ADAgECAhBcX1ns/Jl/DtI19/BXCcuBMA0G CSqGSIb3DQEBBQUAMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzMwHhcNMTIwNDAzMDAwMDAwWhcNMTMwNDAzMjM1OTU5WjCCAR4xFzAVBgNVBAoTDlZl cmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13 d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChj KTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNDAyBgNVBAsTK0RpZ2l0YWwgSUQg Q2xhc3MgMSAtIE1pY3Jvc29mdCBGdWxsIFNlcnZpY2UxFzAVBgNVBAMUDk1pY2hhZWwgSGFtbWVy MSswKQYJKoZIhvcNAQkBFhxtaWNoYWVsLmhhbW1lckB5YWFuYXRlY2guY29tMIGfMA0GCSqGSIb3 DQEBAQUAA4GNADCBiQKBgQDoKTk9rP/4lG6CLqIR4++IFTuOSLF6bmhDr6eiSahqU0VNP+H/LbiD MAZsK9GQoBYPKQdKzy/gM+fl3Gm6VOdjKl8M3GB6LGgAK8d3ETN5dyKe5CAG7EEbKg9wxHWcuXW7 KYd052ven5Ec+Xj++v3HsE423O5q2mNh1Q8FNsnlXQIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYD VR0gBD0wOzA5BgtghkgBhvhFAQcXATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2ln bi5jb20vcnBhMAsGA1UdDwQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYD VR0fBEkwRzBFoEOgQYY/aHR0cDovL2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20v SW5kQzFEaWdpdGFsSUQtRzMuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQA8rhDezFsw7OlR3+mZOZ39 SCKWNJ4gMlQEe31NNtvs6BUzE1uN+fJeZrJ5zjTdJWeG1NgVugcuzQfdv/m5BYbhgJvNfW6ElqZh cye6imOUx8diekkeHXKYSLnEvCdJItXsC1h/huIT9e83WksM92qI/TFyCq6u39cGf9PaBYbcKcZk jHjNi3SPnGifMC6opGiiyK/vB1lituoBRcJ13Y7XoXA8T0kSR8Dtmqvo1JudcFAbS1srytG1QX1H XTsPkTDKHlwv2ZfmCSKK3sWHDrZfpRglxvcX2OwibcKVkKBJRRw36UuJOIj/u0WYABcYtusAb2+0 nqoGmOEYARnrseTZMIIG7jCCBdagAwIBAgIQcRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUF ADCByjELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZv ciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQ cmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkw NDMwMjM1OTU5WjCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QSAtIEczMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP 6bGNQU4099oL42r6ZYggCxET6ZvgSU6Lb9UB0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYH r54UGAdPWr2f0jGyVBlzRmoZQhHsEnMhjfXcMM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50 ABMN0Ibak2f4MwOuGjxraXj2wCyO4YM/d/mZ//6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yx BF6+wbaULZeQLSfSux7pg2qE9sSyriMGZSalJ1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ 6/tu1ULEvkHH9QIDAQABo4ICuTCCArUwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRw Oi8vb2NzcC52ZXJpc2lnbi5jb20wEgYDVR0TAQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CG SAGG+EUBBxcBMFYwKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYI KwYBBQUHAgIwHhocaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6Al hiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYI KwYBBQUHAQwEYjBgoV6gXDBaMFgwVhYJaW1hZ2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQ UjibKaxLB4shBRgwJhYkaHR0cDovL2xvZ28udmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1Ud EQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRlTGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EI Qf04BKJL57XM9UP2SSsR+DCB8QYDVR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4 BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkx RTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZ gbWpBbVSOOk5hIls5DSoWufYbAlMJBq6WaSHO3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v 8dKBl8pUWkO/N4t6jhmND0OojPKvYLMVirOVnDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM6 1a4ScAjr+zvid+zoK2Q1ds262uDRyxTWcVibvtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/ XLJtSd5lUkL7DojS7Uodv0vj+Mxy+kgOZY5JyNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4 VRaMxmgD5yKocwuxvKDaUljdCg5/wYIxggS4MIIEtAIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTsw OQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykw OTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhBcX1ns/Jl/DtI19/BXCcuBMAkGBSsO AwIaBQCgggMbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQx NzE5MjgwOVowIwYJKoZIhvcNAQkEMRYEFFllKTDlV1vMktcdikuOwiuNNO2mMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIIBAwYJKwYB BAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzMCEFxfWez8mX8O0jX38FcJy4EwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkG A1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz dCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24u Y29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5W ZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhBcX1ns/Jl/DtI1 9/BXCcuBMA0GCSqGSIb3DQEBAQUABIGAorGa08RIhOHMMD15mYFNvzypXw/+FY9ysJzpzR97Pva3 b9b+gSWFRnwZYjPh8/ACjcHTly2X4+Vh/qF1YU/JDWobArBE6OLhRI2g2yW+niEX+eq60M6qKNvo +d7VhAGrg7Lc4YvCtdyz01Vi726Kjtjhg4LiRGKB/hsnsxJw+kYAAAAAAAA= ------=_NextPart_000_0156_01CD1CAE.B1C9C4D0-- From lnunez@c3isecurity.com Tue Apr 17 12:49:08 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95FF721F8458 for ; Tue, 17 Apr 2012 12:49:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pbFcH+4m3kCB for ; Tue, 17 Apr 2012 12:49:03 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id AEAE221F846E for ; Tue, 17 Apr 2012 12:49:02 -0700 (PDT) Received: by ghbg16 with SMTP id g16so3780386ghb.31 for ; Tue, 17 Apr 2012 12:49:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=SfzOkeZJDHfeK7hGyn7irZfHI/IFnfQqrQtTxpZXpbI=; b=S0yd1nvSnPnnj9u6VIlWbs0BVrWwwK9+iCCJn1uiX7t6KHEAhmSl7wyUsDeLZzRebc cMhXs50OfTzmto7FVD8xmFs6DD/Uvkpkscn6EMhUllDUhUgq5suxEy1Gn/M9AEwfKiZy LZ4qmQDtcdtc5e4xlwgGZHhnoGw4sU/Mx5bqEXbjQPjuBoRo1VBDmu5LTYg48BKLDu95 R+6VvsFtr9lJme2Tk9PSp0h8Jx/GHxpFY3tw+Wa7rjAqvKEViV9vr879B7FHwz/InLgI ODgsrBJxcQNTXz9LwBw/JrF0IJ2VG+0x0NJf+A3axm4hAx2pd3n9V7d8Pkq1LgkIEqmP KgpA== Received: by 10.236.125.135 with SMTP id z7mr16630602yhh.44.1334692142229; Tue, 17 Apr 2012 12:49:02 -0700 (PDT) Received: from [172.16.1.104] (cpe-066-057-025-190.nc.res.rr.com. [66.57.25.190]) by mx.google.com with ESMTPS id k35sm38719181ani.3.2012.04.17.12.48.59 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 17 Apr 2012 12:49:01 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_C592CC56-27E2-42C3-9DBB-7D60E3E22307" From: Luis Nunez In-Reply-To: <00C069FD01E0324C9FFCADF539701DB38A0193@EX2K10MB1.corp.yaanatech.com> Date: Tue, 17 Apr 2012 15:48:57 -0400 Message-Id: <7F708B86-FA77-441A-A1A0-BCC448708EC0@c3isecurity.com> References: <7F48813B48558A4BB5CB7BB714E5B5A9171B16@IMCMBX03.MITRE.ORG> <69CE2DCD9DAC3D48B830E0723141170B02A39BD2@ZAU1UG-0308.DHSNET.DS1.DHS> <953A2E460DBE7C43AC13E30B87C5B4FF080A1C09@XMB-RCD-106.cisco.com> <7F48813B48558A4BB5CB7BB714E5B5A9171BA1@IMCMBX03.MITRE.ORG> <00C069FD01E0324C9FFCADF539701DB389FC37@EX2K10MB1.corp.yaanatech.com> <7F48813B48558A4BB5CB7BB714E5B5A9173046@IMCMBX03.MITRE.ORG> <00C069FD01E0324C9FFCADF539701DB38A0193@EX2K10MB1.corp.yaanatech.com> To: Michael Hammer X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQnpF6M2TEp+RMSyAMQK1Opcc5VSUbm/OG1UrbS9G4ErVCt1h3PvjY4hSSFCSlwdkK1u+vUg Cc: "Barnum, Sean D." , "sacm@ietf.org" , "dallendoug@gmail.com" , "mile@ietf.org" , "idxwg@nicwg.org" , "Thomas.Millar@hq.dhs.gov" , "osantos@cisco.com" , "m-terada@ipa.go.jp" Subject: Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live onthe website X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 19:49:08 -0000 --Apple-Mail=_C592CC56-27E2-42C3-9DBB-7D60E3E22307 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 The salient point is IPFIX/Netflow is about accounting details of packet = traffic summaries (who,what, where, when and how many times). The following articles could provide the basis for a use case around = leveraging IPFIX to characterize an observable for information sharing. = http://blogs.cisco.com/security/correlating-netflow-data-for-proactive-sec= urity-network-notoriety/ = http://www.cisco.com/web/about/ciscoitatwork/network_systems/network_data_= monitoring_and_reporting_web.html -ln On Apr 17, 2012, at 3:28 PM, Michael Hammer wrote: > Sean, > =20 > What you say makes sense. But, if you will bear with me. (Still = learning this.) > =20 > If one used Packet Traffic event type always instead of Data Flow = event type, would some distinction be lost? > Or, put another way, since the packet stuff seems to cover most = network-based events, does Data Flow involve something that is not on = the wire? > (Such as an inter-process communication that doesn=92t go through a = protocol stack.) > =20 > Mike > =20 > =20 > From: Barnum, Sean D. [mailto:sbarnum@mitre.org]=20 > Sent: Tuesday, April 17, 2012 3:03 PM > To: Michael Hammer; osantos@cisco.com; Thomas.Millar@hq.dhs.gov; = lnunez@c3isecurity.com > Cc: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; = sacm@ietf.org; m-terada@ipa.go.jp > Subject: RE: [mile] [sacm] CybOX v1.0 (Draft) is now released and live = onthe website > =20 > Mike, > =20 > Just to clarify, all of our discussion so far about =93Data Flow=94 = and netflow were all in regards to an enumeration called EventTypeEnum = that simply lets you tag a cyber observable event with a type label. It = is metadata for an event description. > The only object we have been talking about in any detail so far was = the Network_Flow object. These two topics are totally independent of = each other. There is no Data_Flow object. > The abstraction overlap we have been discussing is only in the = metadata tag applied to an event to characterize what type/class of = event it is. > =20 > The defined objects themselves (including Network_Flow) have been = designed to avoid, as much as possible, overlap of the type you = describe. > The approach we have taken is that where there is common structure and = meaning relevant to multiple different types of objects, the structure = for that commonality is broken out into its own object (e.g. Address, = URI, Port, Account, Process, etc.). > Content based on this common object structure can be embedded within a = leveraging object (via direct use of the object type) if the content is = directly relevant only within the context of that object or as an = independent object and associated to any number of other objects to = which it is relevant utilizing relationships. > We make no guarantees that we have managed to implement this approach = flawlessly but we believe that it yields a good balance of consistency, = efficiency and flexibility. It also allows easy modular use of only what = is relevant within a given context and enables extension and evolution = to easily occur in a localized fashion rather than having to extend and = modify one monolithic structure standard. > =20 > Does that make sense? > =20 > sean > =20 > From: Michael Hammer [mailto:michael.hammer@yaanatech.com]=20 > Sent: Tuesday, April 17, 2012 9:18 AM > To: Barnum, Sean D.; osantos@cisco.com; Thomas.Millar@hq.dhs.gov; = lnunez@c3isecurity.com > Cc: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; = sacm@ietf.org; m-terada@ipa.go.jp > Subject: RE: [mile] [sacm] CybOX v1.0 (Draft) is now released and live = onthe website > =20 > Sean, > =20 > Does the overlap between the various objects present a problem? > =20 > If there are one or more objects that could carry the same data, then = human nature means that probability-wise someone will choose data flow = instead of Netflow. > That is the underlying principle in Murphy=92s Law, where you try to = design it so that there is only one way to do it, and thus private = Murphy won=92t do it the =93wrong=94 way. > =20 > Just wondering if these should be mutually exclusive sets. And = designed as such. > Might improve interoperability. (And avoid discussions like this in = future.) J > =20 > Mike > =20 > =20 > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf = Of Barnum, Sean D. > Sent: Tuesday, April 17, 2012 1:10 AM > To: Omar Santos (osantos); Millar, Thomas; lnunez@c3isecurity.com > Cc: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; = sacm@ietf.org; m-terada@ipa.go.jp > Subject: Re: [mile] [sacm] CybOX v1.0 (Draft) is now released and live = onthe website > =20 > =93upper layer=94? Yes, as in higher abstraction. > Just =93protocols=94? No. > =20 > You guys have been looking at this through the lens of network flow = which if fine for thinking about that perspective but it is important to = also realize that the EventTypeEnum and its =93Data Flow=94 value go far = beyond network-related scope. > It is about a lot of other types of potential data flows (as I just = outlined in a response to Tom) that have nothing to do with network = flow. > =20 > Thanks for your response though. This is the kind of discussions that = we hope to have a lot more of among the various supported communities. > =20 > =20 > BTW, you may have noticed that the Network_Flow object within CybOX = v1.0 (Draft) supports expression of netflow within several of the most = common formats including Netflow9 (as well as IPFIX as Luis pointed out, = Netflow5 and SiLK as well as bi-directional flow in YAF). The common = 5-tuple or 7-tuple (you describe) (in our case it is an 8-tuple as we = broke the router interface out into both ingress and egress J) shared by = pretty much all of the netflow approaches has been broken out into a = shared Network_Flow_Label structure. The various context-dependent = portions of the independent approaches are then captured within optional = structures dedicated to each of them. We hope that eventually the = community can work to come together towards a single overall common = expressive structure for netflow that meets the needs of all. We hope = that CybOX and its use can even help that sort of maturation and = normalization. But since no such universal structure exists today, we = decided to enable optional expression of the most common individual = formats within a single netflow object to serve the large majority of = relevant users, maintain flexibility and enable discussions and analysis = of netflow within a common package. > We look forward to continuing discussions with the community to = validate or invalidate this approach and to refine and mature going = forward. > =20 > Sean > =20 > From: Omar Santos (osantos) [mailto:osantos@cisco.com]=20 > Sent: Monday, April 16, 2012 11:57 PM > To: Millar, Thomas; Barnum, Sean D.; lnunez@c3isecurity.com > Cc: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; = sacm@ietf.org; m-terada@ipa.go.jp > Subject: RE: [sacm] [mile] CybOX v1.0 (Draft) is now released and live = onthe website > =20 > I believe that what Sean is saying is that =93data flow=94 is just a = value that is meant for upper layer protocols. But, you have a good = point. Traditionally, a =93flow=94 in =93Netflow=94 is based on a set of = 5 and up to 7 IP packet attributes: > =20 > - IP source address > - IP destination address > - Source port > - Destination port > - Layer 3 protocol type > - Class of Service > - Router or switch interface > =20 > Although, there is a lot more support with Netflow version 9: > = http://www.cisco.com/en/US/technologies/tk648/tk362/technologies_white_pap= er09186a00800a3db9_ps6601_Products_White_Paper.html > =20 > =20 > =20 > Regards, >=20 > Omar > =20 > From: Millar, Thomas [mailto:Thomas.Millar@hq.dhs.gov]=20 > Sent: Monday, April 16, 2012 11:46 PM > To: sbarnum@mitre.org; Omar Santos (osantos); lnunez@c3isecurity.com > Cc: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; = sacm@ietf.org; m-terada@ipa.go.jp > Subject: Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live = onthe website > =20 > If "data flow" is a euphemism for "netflow" is there any reason not to = call it that? >=20 > Tom Millar=20 > http://www.us-cert.gov/=20 > ------------------=20 > Missit me Rubus fruticosus:=20 > 202 631 1915=20 >=20 > =20 > From: Barnum, Sean D. [mailto:sbarnum@mitre.org]=20 > Sent: Monday, April 16, 2012 11:29 PM > To: Omar Santos (osantos) ; Luis Nunez = =20 > Cc: idxwg@nicwg.org ; mile@ietf.org ; = dallendoug@gmail.com; sacm@ietf.org = ; m-terada@ipa.go.jp =20 > Subject: Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live = onthe website=20 > =20 > Thanks Omar. > =20 > To answer your question, first let me point out to other readers that = the two entries that Omar is quoting here exist as values in an = enumeration called EventTypeEnum which as its name implies contains a = list of different labels for grouping types (or classes) of events to be = used as low-granularity buckets for characterizing and classifying = events. > Other entries in this enumeration include things like =93File Ops = (CRUD)=94, =93Process Mgt=94, =93Authorization (ACL)=94, etc. > =20 > The =93Packet Traffic=94 value is intended to characterize events = dealing with network packet traffic as its name implies. > The =93Data Flow=94 value is intended to characterize events dealing = with forms of data flow at a higher level of abstraction than just = packet traffic. The relationship between these two values could be = viewed as =93Packet Traffic=94 being a more detailed form of =93Data = Flow=94 just as the values =93App Layer Traffic=94 and =93HTTP Layer = Traffic=94, also in this enumeration, could be other levels in this same = abstraction stack. > The idea behind the varying levels of abstraction is to leave buckets = large enough to capture a wide variety of potential event types (e.g. = data flow events other than obvious things like packet traffic) but also = enable the use of smaller more specific buckets when they are = appropriate and commonly used. > =20 > Does this make sense? > =20 > sean > =20 > From: Omar Santos (osantos) [mailto:osantos@cisco.com]=20 > Sent: Monday, April 16, 2012 8:17 PM > To: Luis Nunez; Barnum, Sean D. > Cc: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; = sacm@ietf.org; m-terada@ipa.go.jp > Subject: RE: [sacm] [mile] CybOX v1.0 (Draft) is now released and live = onthe website > =20 > I echo Luis=92 comments. It is good to see the inclusion of network = objects. Quick question to the team related to your netflow comment. > =20 > I am looking at: > http://cybox.mitre.org/XMLSchema/cybox_core_v1.0%28draft%29.xsd > =20 > =85 and it looks that we renamed it to =93Data Flow=94? > =20 > > > Specifies the class of events dealing with = data flow. > > > =20 > =20 > What is the difference between that and =93Packet Traffic=94? > =20 > > > Specifies the class of events dealing with = packet traffic. > > > =20 > =20 > =20 > =20 > Regards, >=20 > Omar Santos > Incident Manager, PSIRT > Security Research and Operations > Cisco Systems, Inc. > Email: os@cisco.com > Phone: +1 919 392 8635 > PGP Key: 0x3AF27EDC >=20 > Cisco.com - http://www.cisco.com > Cisco Security Advisories and Notices - http://www.cisco.com/go/psirt >=20 > This email may contain confidential and privileged material for the = sole > use of the intended recipient. Any review, use, distribution or > disclosure by others is strictly prohibited. If you are not the = intended > recipient (or authorized to receive for the recipient), please contact > the sender by reply email and delete all copies of this message. >=20 > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > =20 > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf = Of Luis Nunez > Sent: Monday, April 16, 2012 6:44 PM > To: Barnum, Sean D. > Cc: idxwg@nicwg.org; mile@ietf.org; Doug Wilson = (dallendoug@gmail.com); sacm@ietf.org; IPA-Masato Terada = (m-terada@ipa.go.jp) > Subject: Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live = onthe website > =20 > I like the inclusion of the network-centric objects. IPFIX (netflow) = will add an additional perspective from an incident information sharing = standpoint. =20 > =20 > -ln > =20 > On Apr 16, 2012, at 4:04 PM, Barnum, Sean D. wrote: > =20 >=20 > Hey everyone, > =20 > I just wanted to let you all know that CybOX v1.0 (Draft) content is = now live on the website. http://cybox.mitre.org > The release notes are provided inline below. > The key items of note are: > =B7 The release of two formal specifications for the CybOX = language (one for the core language and one for the defined objects) > =B7 The XML Schema has gone through extensive improvements for = expressiveness, clarity, consistency, efficiency, alignment to existing = normative references and documentation. > =B7 This release includes an initial set of language utilities: = a draft Snort -> CybOX transform, a draft OpenIOC -> CybOX transform, = and a set of Python bindings for the CybOX language. > =B7 The website now includes a small set of content examples. = This set will grow going forward. >=20 > This release involved a lot of hard work from a diverse group of = people. Thank you all for your contributions and effort. We could not = have done it without you. > We look forward to everyone=92s feedback and collaboration as we = continue to improve and mature the CybOX language. > =20 > Sean Barnum > =20 > =20 > =20 > CybOX v1.0 (Draft) Release Notes >=20 > The Version 1.0 (Draft) release of Cyber Observable eXpression = (CybOX=99) is intended as a draft release of an initial major version of = the CybOX Language that could be utilized for practical operational use = and integration into other standards efforts. This release consists of = three primary components: a pair of formal language specifications for = the core language content and defined objects content, a set of language = implementation XML schemas (core, common_types, and ~70 defined object = schemas), and a small initial set of language utilities including an = initial draft Snort->CybOX transform, an initial draft OpenIOC->CybOX = transform and a set of CybOX language Python bindings. Recognizing that = this is the first time that the formal language specifications will be = available for review and as such will likely generate feedback from new = stakeholders, this initial major version is being released as a =93draft=94= v1.0 with the expectation of cycles of new feedback and revision before = a =93final=94 v1.0 is released. > The CybOX v1.0 (Draft) XML schemas include a significant number of = changes from v0.7 to improve: > =B7 Clarity, documentation, and descriptive formality for = reference and implementation by other standards and users. > =B7 Consistency, simplicity, and efficiency. > =B7 Alignment (as appropriate) to existing normative references. > =B7 Expressiveness of the schema to better support the broad set = of use cases it targets (malware characterization, indicator and = incident data sharing, event management, etc.) including the addition of = an initial set of network-related defined objects. >=20 > Summary of changes from CybOX_v0.7 to CybOX_v1.0_(Draft): > =B7 Refinement of namespaces and schema locations for better = effectiveness and flexibility going forward. > =B7 Normalized all content according to an established set of = naming conventions. > =B7 Fully annotated all language items (types, attributes, = elements, etc.). > =B7 Moved several commonly leveraged types out of the core = schema and into common_types. > =B7 Achieved full typing of entire schema structure such that = all attributes and elements are definitively typed. > =B7 Changed all identifiers from ID and IDREF types to be QNames = enabling globally unique identifiers and flexibility for domain-specific = users of CybOX to define their own identifier syntax locally. > =B7 Reordered attributes and elements in numerous types to = better reflect common usage and priority. > =B7 Added major_version and minor_version attributes for core = schema. > =B7 Added capability to characterize source of overall = observable package data and for individual observables. > =B7 Modified the logical composition structure such that any = such compositions are now contained within a Observable_Composition = element providing improved simplicity and modularity. > =B7 Removed the Delta element from ObservableType and relocated = the appropriate portions (Change, Trend, and Frequency) to appropriate = locations under Stateful_Measure and Event. > =B7 Added a Domain_Specific_Object_Attributes field to Object = utilizing an abstract type that will allow domain-specific use cases to = add in their own domain-specific attributes for Objects. > =B7 Added a Tool-Specific_Data field to ToolInformationType = utilizing an abstract type that will allow addition of tool-specific = data. > =B7 Added an Indicators field to MeasureSourceType utilizing an = abstract type that will allow characterizing differing formats or = standards of indicators that may have led to the identification of the = observable data. > =B7 Enhanced the Hash structure to capture full fuzzy hashes in = addition to simple hashes > =B7 Added a new ExtractedFeaturesType that can be used to adorn = differing objects (e.g., files, memory, etc.) to capture extracted = strings, imports, functions and code snippets > =B7 Added a ByteRunsType to enable capture of byte runs within = various objects. > =B7 Added object_reference attribute to DefinedObjectType to = better support referencing of independently defined Objects from within = another Object definition. > =B7 Added a generic DataSegmentType to provide a relatively = abstract way of characterizing data segments that may be = written/read/transmitted or otherwise utilized in actions or defined in = objects. > =B7 Added several new defined object schemas (API, Code, = Device, DNS_Record, Network_Flow, Network_Packet, Network_Route_Entry, = Network_Subnet, Unix_Network_Route_Entry) including an initial set of = network-centric defined objects. > =B7 Modified every defined object schema with added annotations = as well as minor and in some cases substantive changes to fix errors, = improve consistency and alignment with existing normative references, = and to improve expressiveness in support of the targeted use cases. > Detailed changes from CybOX_v0.7 to CybOX_v1.0_(Draft): > The level of changes within v1.0 (Draft) in the core schema, = common_types and the defined object schemas is too great to list every = change in these release notes. Detailed difference reports are available = for each individual schema = at:http://cybox.mitre.org/XMLSchema/release_notes/cybox_v1.0(draft)_diff_r= eports.zip > =20 > =20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Sean Barnum > Cyber Security Principal > The MITRE Corporation > Email: sbarnum@mitre.org > =20 > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile --Apple-Mail=_C592CC56-27E2-42C3-9DBB-7D60E3E22307 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 The salient point is IPFIX/Netflow is about = accounting details of packet traffic summaries (who,what, where, when = and how many times).


The following = articles could provide the basis for a use case around leveraging IPFIX = to characterize an observable for information = sharing.


-ln

On= Apr 17, 2012, at 3:28 PM, Michael Hammer wrote:

What = you say makes sense.  But, if you will bear with me.  (Still = learning this.)
If = one used Packet Traffic event type always instead of Data Flow event = type, would some distinction be lost?
Or, put another way, since the = packet stuff seems to cover most network-based events, does Data Flow = involve something that is not on the wire?
(Such as an inter-process = communication that doesn=92t go through a protocol = stack.)
From: Barnum, Sean D. = [mailto:sbarnum@mitre.org] 
Sent: Tuesday, April 17, 2012 = 3:03 PM
To: Michael Hammer; osantos@cisco.com; Thomas.Millar@hq.dhs.gov; = lnunez@c3isecurity.com
Cc= : idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; m-terada@ipa.go.jp
Subject: RE: [mile] [sacm] = CybOX v1.0 (Draft) is now released and live onthe = website
Just = to clarify, all of our discussion so far about =93Data Flow=94 and = netflow were all in regards to an enumeration called EventTypeEnum that = simply lets you tag a cyber observable event with a type label. It is = metadata for an event description.
The only object we have been = talking about in any detail so far was the Network_Flow object. These = two topics are totally independent of each other. There is no Data_Flow = object.
The = abstraction overlap we have been discussing is only in the metadata tag = applied to an event to characterize what type/class of event it = is.
The = defined objects themselves (including Network_Flow) have been designed = to avoid, as much as possible, overlap of the type you = describe.
The = approach we have taken is that where there is common structure and = meaning relevant to multiple different types of objects, the structure = for that commonality is broken out into its own object (e.g. Address, = URI, Port, Account, Process, etc.).
Content based on this common = object structure can be embedded within a leveraging object (via direct = use of the object type) if the content is directly relevant only within = the context of that object or as an independent object and associated to = any number of other objects to which it is relevant utilizing = relationships.
We = make no guarantees that we have managed to implement this approach = flawlessly but we believe that it yields a good balance of consistency, = efficiency and flexibility. It also allows easy modular use of only what = is relevant within a given context and enables extension and evolution = to easily occur in a localized fashion rather than having to extend and = modify one monolithic structure standard.
Does = that make sense?
BTW, you may have noticed that = the Network_Flow object within CybOX v1.0 (Draft) supports expression of = netflow within several of the most common formats including Netflow9 (as = well as IPFIX as Luis pointed out, Netflow5 and SiLK as well as = bi-directional flow in YAF). The common 5-tuple or 7-tuple (you = describe) (in our case it is an 8-tuple as we broke the router interface = out into both ingress and egress J) shared by pretty much all of = the netflow approaches has been broken out into a shared = Network_Flow_Label structure. The various context-dependent portions of = the independent approaches are then captured within optional structures = dedicated to each of them. We hope that eventually the community can = work to come together towards a single overall common expressive = structure for netflow that meets the needs of all. We hope that CybOX = and its use can even help that sort of maturation and normalization. But = since no such universal structure exists today, we decided to enable = optional expression of the most common individual formats within a = single netflow object to serve the large majority of relevant users, = maintain flexibility and enable discussions and analysis of netflow = within a common package.
: Barnum, Sean D. [mailto:sbarnum@mitre.org] 
Sent: Monday, = April 16, 2012 11:29 PM
To: Omar Santos (osantos) <osantos@cisco.com>; Luis Nunez <lnunez@c3isecurity.com> 
Cc: idxwg@nicwg.org <idxwg@nicwg.org>; mile@ietf.org <mile@ietf.org>; dallendoug@gmail.com<dallendoug@gmail.com>; sacm@ietf.org <sacm@ietf.org>; m-terada@ipa.go.jp <m-terada@ipa.go.jp> 
Subject: Re: = [sacm] [mile] CybOX v1.0 (Draft) is now released and live onthe = website 
 <= /div>
Thanks = Omar.
To = answer your question, first let me point out to other readers that the = two entries that Omar is quoting here exist as values in an enumeration = called EventTypeEnum which as its name implies contains a list of = different labels for grouping types (or classes) of events to be used as = low-granularity buckets for characterizing and classifying = events.
Other = entries in this enumeration include things like =93File Ops (CRUD)=94, = =93Process Mgt=94, =93Authorization (ACL)=94, = etc.
The = =93Packet Traffic=94 value is intended to characterize events dealing = with network packet traffic as its name = implies.
The = =93Data Flow=94 value is intended to characterize events dealing with = forms of data flow at a higher level of abstraction than just packet = traffic. The relationship between these two values could be viewed as = =93Packet Traffic=94 being a more detailed form of =93Data Flow=94 just = as the values =93App Layer Traffic=94 and =93HTTP Layer Traffic=94, also = in this enumeration, could be other levels in this same abstraction = stack.
The = idea behind the varying levels of abstraction is to leave  buckets = large enough to capture a wide variety of potential event types (e.g. = data flow events other than obvious things like packet traffic) but also = enable the use of smaller more specific buckets when they are = appropriate and commonly used.
Does = this make sense?
From: Omar Santos (osantos) [mailto:osantos@cisco.com] 
Sent: Monday, April 16, 2012 8:17 = PM
To: Luis = Nunez; Barnum, Sean D.
Cc: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org;  RE: [sacm] [mile] CybOX = v1.0 (Draft) is now released and live onthe = website
 
 
The release notes are provided inline =
below.
The key =
items of note are:
=B7 The =
release of two formal specifications for the CybOX language (one for the =
core language and one for the defined =
objects)
=B7 The XML =
Schema has gone through extensive improvements for expressiveness, =
clarity, consistency, efficiency, alignment to existing normative =
references and documentation.
=B7 This =
release includes an initial set of language utilities: a draft Snort =
-> CybOX transform, a draft OpenIOC -> CybOX transform, and a set =
of Python bindings for the CybOX =
language.
=B7 The =
website now includes a small set of content examples. This set will grow =
going forward.
This =
release involved a lot of hard work from a diverse group of people. =
Thank you all for your contributions and effort. We could not have done =
it without you.
We look forward to everyone=92s feedback and collaboration =
as we continue to improve and mature the CybOX =
language.
Sean =
Barnum
CybOX v1.0 (Draft) Release =
Notes
The Version =
1.0 (Draft) release of Cyber Observable eXpression (CybOX=99) is intended as a =
draft release of an initial major version of the CybOX Language that =
could be utilized for practical operational use and integration into =
other standards efforts. This release consists of three primary =
components: a pair of formal language specifications for the core =
language content and defined objects content, a set of language =
implementation XML schemas (core, common_types, and ~70 defined object =
schemas), and a small initial set of language utilities including an =
initial draft Snort->CybOX transform, an initial draft =
OpenIOC->CybOX transform and a set of CybOX language Python bindings. =
Recognizing that this is the first time that the formal language =
specifications will be available for review and as such will likely =
generate feedback from new stakeholders, this initial major version is =
being released as a =93draft=94 v1.0 with the expectation of cycles of =
new feedback and revision before a =93final=94 v1.0 is released.The CybOX v1.0 =
(Draft) XML schemas include a significant number of changes from v0.7 to =
improve:
=B7 Clarity, =
documentation, and descriptive formality for reference and =
implementation by other standards and users.
=B7 Consistency, =
simplicity, and efficiency.
=B7       Alignment (as =
appropriate) to existing normative references.=B7       Expressiveness of =
the schema to better support the broad set of use cases it targets =
(malware characterization, indicator and incident data sharing, event =
management, etc.) including the addition of an initial set of =
network-related defined objects.
Summary of changes from CybOX_v0.7 to =
CybOX_v1.0_(Draft):
       Refineme=
nt of namespaces and schema locations for better effectiveness and =
flexibility going forward.
       Normaliz=
ed all content according to an established set of naming =
conventions.
=B7 Fully =
annotated all language items (types, attributes, elements, etc.).=B7 Moved =
several commonly leveraged types out of the core schema and into =
common_types.
=B7 Achieved=
 full typing of entire schema structure such that all attributes and =
elements are definitively typed.
=B7 Changed =
all identifiers from ID and IDREF types to be QNames enabling globally =
unique identifiers and flexibility for domain-specific users of CybOX to =
define their own identifier syntax locally.
=B7 Reordere=
d attributes and elements in numerous types to better reflect common =
usage and priority.
=B7 Added =
major_version and minor_version attributes for core schema.=B7 Added =
capability to characterize source of overall observable package data and =
for individual observables.
       Modified=
 the logical composition structure such that any such compositions are =
now contained within a Observable_Composition element providing improved =
simplicity and modularity.
       Removed =
the Delta element from ObservableType and relocated the appropriate =
portions (Change, Trend, and Frequency) to appropriate locations under =
Stateful_Measure and Event.
       Added =
a Domain_Specific_Object_Attributes field to Object utilizing an =
abstract type that will allow domain-specific use cases to add in their =
own domain-specific attributes for Objects.
=B7 Added =
a Tool-Specific_Data field to ToolInformationType utilizing an abstract =
type that will allow addition of tool-specific data.=B7 Added =
an Indicators field to MeasureSourceType utilizing an abstract type that =
will allow characterizing differing formats or standards of indicators =
that may have led to the identification of the observable data.=B7 Enhanced=
 the Hash structure to capture full fuzzy hashes in addition to simple =
hashes=B7 Added =
a new ExtractedFeaturesType that can be used to adorn differing objects =
(e.g., files, memory, etc.) to capture extracted strings, imports, =
functions and code snippets
       Added =
a ByteRunsType to enable capture of byte runs within various =
objects.
=B7 Added =
object_reference attribute to DefinedObjectType to better support =
referencing of independently defined Objects from within another Object =
definition.
=B7 Added =
a generic DataSegmentType to provide a relatively abstract way of =
characterizing data segments that may be written/read/transmitted or =
otherwise utilized in actions or defined in objects.
=B7 Added several new =
defined object schemas (API, Code, Device, DNS_Record, Network_Flow, =
Network_Packet, Network_Route_Entry, Network_Subnet, =
Unix_Network_Route_Entry) including an initial set of network-centric =
defined objects.=B7 Modified=
 every defined object schema with added annotations as well as minor and =
in some cases substantive changes to fix errors, improve consistency and =
alignment with existing normative references, and to improve =
expressiveness in support of the targeted use cases.
Detailed changes from CybOX_v0.7 to =
CybOX_v1.0_(Draft):
The level of =
changes within v1.0 (Draft) in the core schema, common_types and the =
defined object schemas is too great to list every change in these =
release notes. Detailed difference reports are available for each =
individual schema at: 
Sean Barnum
Cyber Security =
Principal
The MITRE Corporation
Email: sbarnum@mitre.orgmile@ietf.org
, "osantos@cisco.com" , "Thomas.Millar@hq.dhs.gov" ,  "lnunez@c3isecurity.com" 
Thread-Topic: [mile] [sacm] CybOX v1.0 (Draft) is now released and live onthe website
Thread-Index: AQHNHFhQtpFrr+nGFkWqCWY68NIgupae/ygAgADWyAD//48qoIAAjiKA//+LrmA=
Date: Tue, 17 Apr 2012 20:51:22 +0000
Message-ID: <00C069FD01E0324C9FFCADF539701DB38A0218@EX2K10MB1.corp.yaanatech.com>
References: <7F48813B48558A4BB5CB7BB714E5B5A9171B16@IMCMBX03.MITRE.ORG> <69CE2DCD9DAC3D48B830E0723141170B02A39BD2@ZAU1UG-0308.DHSNET.DS1.DHS> <953A2E460DBE7C43AC13E30B87C5B4FF080A1C09@XMB-RCD-106.cisco.com> <7F48813B48558A4BB5CB7BB714E5B5A9171BA1@IMCMBX03.MITRE.ORG> <00C069FD01E0324C9FFCADF539701DB389FC37@EX2K10MB1.corp.yaanatech.com> <7F48813B48558A4BB5CB7BB714E5B5A9173046@IMCMBX03.MITRE.ORG> <00C069FD01E0324C9FFCADF539701DB38A0193@EX2K10MB1.corp.yaanatech.com> <7F48813B48558A4BB5CB7BB714E5B5A9173115@IMCMBX03.MITRE.ORG>
In-Reply-To: <7F48813B48558A4BB5CB7BB714E5B5A9173115@IMCMBX03.MITRE.ORG>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.17.88.19]
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0177_01CD1CBA.4FE9CE70"
MIME-Version: 1.0
Cc: "idxwg@nicwg.org" , "mile@ietf.org" , "dallendoug@gmail.com" , "sacm@ietf.org" , "m-terada@ipa.go.jp" 
Subject: Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live onthe website
X-BeenThere: sacm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Apr 2012 20:51:38 -0000

------=_NextPart_000_0177_01CD1CBA.4FE9CE70
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_0178_01CD1CBA.4FE9CE70"


------=_NextPart_001_0178_01CD1CBA.4FE9CE70
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Thanks.  Appreciated the detailed explanation.

=20

Mike

=20

=20

From: Barnum, Sean D. [mailto:sbarnum@mitre.org]=20
Sent: Tuesday, April 17, 2012 4:47 PM
To: Michael Hammer; osantos@cisco.com; Thomas.Millar@hq.dhs.gov; =
lnunez@c3isecurity.com
Cc: idxwg@nicwg.org; mile@ietf.org; sacm@ietf.org; m-terada@ipa.go.jp; =
dallendoug@gmail.com
Subject: RE: [mile] [sacm] CybOX v1.0 (Draft) is now released and live =
onthe website

=20

Mike,

=20

If you always utilized the most abstract label (Data Flow) to adorn =
events even when you knew the more specific type that they were and had =
a more specific label for them, then yes you would lose distinction.

Such misuse is always the potential downside of enabling flexibility =
through abstraction.

If you know that the event you are characterizing has to do with Packet =
Traffic and not just some form of more general data flow that does not =
have an appropriate associated event type label, then you should =
absolutely use Packet Traffic and not Data Flow. An event should only be =
tagged with an abstract label like Data Flow if there is not an =
appropriate more concrete label available.

=20

In answer to your second question, yes Data Flow definitely covers not =
only network-related events but also events that have nothing to do with =
the wire.

My response to Tom Millar that I sent at 12:52am this morning lists out =
several non-network related types of events that Data Flow could apply =
to.

=20

Please do not feel bad for asking these questions. They help you =
understand our approach, they help others understand our approach, they =
help us better understand the perspective of the communities we are =
targeting to support, they help us uncover issues with our approach or =
implementation, and they help us understand where we need to explain =
ourselves better.

=20

Thank you for the constructive discourse.

=20

sean

=20

From: Michael Hammer [mailto:michael.hammer@yaanatech.com]=20
Sent: Tuesday, April 17, 2012 3:28 PM
To: Barnum, Sean D.; osantos@cisco.com; Thomas.Millar@hq.dhs.gov; =
lnunez@c3isecurity.com
Cc: idxwg@nicwg.org; mile@ietf.org; sacm@ietf.org; m-terada@ipa.go.jp; =
dallendoug@gmail.com
Subject: RE: [mile] [sacm] CybOX v1.0 (Draft) is now released and live =
onthe website

=20

Sean,

=20

What you say makes sense.  But, if you will bear with me.  (Still =
learning this.)

=20

If one used Packet Traffic event type always instead of Data Flow event =
type, would some distinction be lost?

Or, put another way, since the packet stuff seems to cover most =
network-based events, does Data Flow involve something that is not on =
the wire?

(Such as an inter-process communication that doesn=E2=80=99t go through =
a protocol stack.)

=20

Mike

=20

=20

From: Barnum, Sean D. [mailto:sbarnum@mitre.org]=20
Sent: Tuesday, April 17, 2012 3:03 PM
To: Michael Hammer; osantos@cisco.com; Thomas.Millar@hq.dhs.gov; =
lnunez@c3isecurity.com
Cc: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; =
m-terada@ipa.go.jp
Subject: RE: [mile] [sacm] CybOX v1.0 (Draft) is now released and live =
onthe website

=20

Mike,

=20

Just to clarify, all of our discussion so far about =E2=80=9CData =
Flow=E2=80=9D and netflow were all in regards to an enumeration called =
EventTypeEnum that simply lets you tag a cyber observable event with a =
type label. It is metadata for an event description.

The only object we have been talking about in any detail so far was the =
Network_Flow object. These two topics are totally independent of each =
other. There is no Data_Flow object.

The abstraction overlap we have been discussing is only in the metadata =
tag applied to an event to characterize what type/class of event it is.

=20

The defined objects themselves (including Network_Flow) have been =
designed to avoid, as much as possible, overlap of the type you =
describe.

The approach we have taken is that where there is common structure and =
meaning relevant to multiple different types of objects, the structure =
for that commonality is broken out into its own object (e.g. Address, =
URI, Port, Account, Process, etc.).

Content based on this common object structure can be embedded within a =
leveraging object (via direct use of the object type) if the content is =
directly relevant only within the context of that object or as an =
independent object and associated to any number of other objects to =
which it is relevant utilizing relationships.

We make no guarantees that we have managed to implement this approach =
flawlessly but we believe that it yields a good balance of consistency, =
efficiency and flexibility. It also allows easy modular use of only what =
is relevant within a given context and enables extension and evolution =
to easily occur in a localized fashion rather than having to extend and =
modify one monolithic structure standard.

=20

Does that make sense?

=20

sean

=20

From: Michael Hammer [mailto:michael.hammer@yaanatech.com]=20
Sent: Tuesday, April 17, 2012 9:18 AM
To: Barnum, Sean D.; osantos@cisco.com; Thomas.Millar@hq.dhs.gov; =
lnunez@c3isecurity.com
Cc: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; =
m-terada@ipa.go.jp
Subject: RE: [mile] [sacm] CybOX v1.0 (Draft) is now released and live =
onthe website

=20

Sean,

=20

Does the overlap between the various objects present a problem?

=20

If there are one or more objects that could carry the same data, then =
human nature means that probability-wise someone will choose data flow =
instead of Netflow.

That is the underlying principle in Murphy=E2=80=99s Law, where you try =
to design it so that there is only one way to do it, and thus private =
Murphy won=E2=80=99t do it the =E2=80=9Cwrong=E2=80=9D way.

=20

Just wondering if these should be mutually exclusive sets.  And designed =
as such.

Might improve interoperability.  (And avoid discussions like this in =
future.)  J

=20

Mike

=20

=20

From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of =
Barnum, Sean D.
Sent: Tuesday, April 17, 2012 1:10 AM
To: Omar Santos (osantos); Millar, Thomas; lnunez@c3isecurity.com
Cc: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; =
m-terada@ipa.go.jp
Subject: Re: [mile] [sacm] CybOX v1.0 (Draft) is now released and live =
onthe website

=20

=E2=80=9Cupper layer=E2=80=9D? Yes, as in higher abstraction.

Just =E2=80=9Cprotocols=E2=80=9D? No.

=20

You guys have been looking at this through the lens of network flow =
which if fine for thinking about that perspective but it is important to =
also realize that the EventTypeEnum and its =E2=80=9CData Flow=E2=80=9D =
value go far beyond network-related scope.

It is about a lot of other types of potential data flows (as I just =
outlined in a response to Tom) that have nothing to do with network =
flow.

=20

Thanks for your response though. This is the kind of discussions that we =
hope to have a lot more of among the various supported communities.

=20

=20

BTW, you may have noticed that the Network_Flow object within CybOX v1.0 =
(Draft) supports expression of netflow within several of the most common =
formats including Netflow9 (as well as IPFIX as Luis pointed out, =
Netflow5 and SiLK as well as bi-directional flow in YAF). The common =
5-tuple or 7-tuple (you describe) (in our case it is an 8-tuple as we =
broke the router interface out into both ingress and egress J) shared by =
pretty much all of the netflow approaches has been broken out into a =
shared Network_Flow_Label structure. The various context-dependent =
portions of the independent approaches are then captured within optional =
structures dedicated to each of them. We hope that eventually the =
community can work to come together towards a single overall common =
expressive structure for netflow that meets the needs of all. We hope =
that CybOX and its use can even help that sort of maturation and =
normalization. But since no such universal structure exists today, we =
decided to enable optional expression of the most common individual =
formats within a single netflow object to serve the large majority of =
relevant users, maintain flexibility and enable discussions and analysis =
of netflow within a common package.

We look forward to continuing discussions with the community to validate =
or invalidate this approach and to refine and mature going forward.

=20

Sean=20

=20

From: Omar Santos (osantos) [mailto:osantos@cisco.com]=20
Sent: Monday, April 16, 2012 11:57 PM
To: Millar, Thomas; Barnum, Sean D.; lnunez@c3isecurity.com
Cc: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; =
m-terada@ipa.go.jp
Subject: RE: [sacm] [mile] CybOX v1.0 (Draft) is now released and live =
onthe website

=20

I believe that what Sean is saying is that =E2=80=9Cdata flow=E2=80=9D =
is just a value that is meant for upper layer protocols. But, you have a =
good point. Traditionally, a =E2=80=9Cflow=E2=80=9D in =
=E2=80=9CNetflow=E2=80=9D is based on a set of 5 and up to 7 IP packet =
attributes:

=20

- IP source address

- IP destination address

- Source port

- Destination port

- Layer 3 protocol type

- Class of Service

- Router or switch interface

=20

Although, there is a lot more support with Netflow version 9:

http://www.cisco.com/en/US/technologies/tk648/tk362/technologies_white_pa=
per09186a00800a3db9_ps6601_Products_White_Paper.html

=20

=20

=20

Regards,

Omar=20

=20

From: Millar, Thomas [mailto:Thomas.Millar@hq.dhs.gov]=20
Sent: Monday, April 16, 2012 11:46 PM
To: sbarnum@mitre.org; Omar Santos (osantos); lnunez@c3isecurity.com
Cc: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; =
m-terada@ipa.go.jp
Subject: Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live =
onthe website

=20

If "data flow" is a euphemism for "netflow" is there any reason not to =
call it that?

Tom Millar=20
http://www.us-cert.gov/=20
------------------=20
Missit me Rubus fruticosus:=20
202 631 1915=20

=20

From: Barnum, Sean D. [mailto:sbarnum@mitre.org]=20
Sent: Monday, April 16, 2012 11:29 PM
To: Omar Santos (osantos) ; Luis Nunez =
=20
Cc: idxwg@nicwg.org ; mile@ietf.org ; =
dallendoug@gmail.com ; sacm@ietf.org =
; m-terada@ipa.go.jp =20
Subject: Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live =
onthe website=20
=20

Thanks Omar.

=20

To answer your question, first let me point out to other readers that =
the two entries that Omar is quoting here exist as values in an =
enumeration called EventTypeEnum which as its name implies contains a =
list of different labels for grouping types (or classes) of events to be =
used as low-granularity buckets for characterizing and classifying =
events.

Other entries in this enumeration include things like =E2=80=9CFile Ops =
(CRUD)=E2=80=9D, =E2=80=9CProcess Mgt=E2=80=9D, =E2=80=9CAuthorization =
(ACL)=E2=80=9D, etc.

=20

The =E2=80=9CPacket Traffic=E2=80=9D value is intended to characterize =
events dealing with network packet traffic as its name implies.

The =E2=80=9CData Flow=E2=80=9D value is intended to characterize events =
dealing with forms of data flow at a higher level of abstraction than =
just packet traffic. The relationship between these two values could be =
viewed as =E2=80=9CPacket Traffic=E2=80=9D being a more detailed form of =
=E2=80=9CData Flow=E2=80=9D just as the values =E2=80=9CApp Layer =
Traffic=E2=80=9D and =E2=80=9CHTTP Layer Traffic=E2=80=9D, also in this =
enumeration, could be other levels in this same abstraction stack.

The idea behind the varying levels of abstraction is to leave  buckets =
large enough to capture a wide variety of potential event types (e.g. =
data flow events other than obvious things like packet traffic) but also =
enable the use of smaller more specific buckets when they are =
appropriate and commonly used.

=20

Does this make sense?=20

=20

sean

=20

From: Omar Santos (osantos) [mailto:osantos@cisco.com]=20
Sent: Monday, April 16, 2012 8:17 PM
To: Luis Nunez; Barnum, Sean D.
Cc: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; =
m-terada@ipa.go.jp
Subject: RE: [sacm] [mile] CybOX v1.0 (Draft) is now released and live =
onthe website

=20

I echo Luis=E2=80=99 comments. It is good to see the inclusion of =
network objects. Quick question to the team related to your netflow =
comment.

=20

I am looking at:

http://cybox.mitre.org/XMLSchema/cybox_core_v1.0%28draft%29.xsd

=20

=E2=80=A6 and it looks that we renamed it to =E2=80=9CData =
Flow=E2=80=9D?

=20



   

        Specifies the class of events dealing with =
data flow.

   



=20

=20

What is the difference between that and =E2=80=9CPacket =
Traffic=E2=80=9D?

=20


   
     Specifies the class of events dealing with packet =
traffic.
   


=20

=20

=20

=20

Regards,

Omar Santos
Incident Manager, PSIRT
Security Research and Operations
Cisco Systems, Inc.
Email: os@cisco.com
Phone: +1 919 392 8635
PGP Key: 0x3AF27EDC

Cisco.com - http://www.cisco.com
Cisco Security Advisories and Notices - http://www.cisco.com/go/psirt

This email may contain confidential and privileged material for the sole
use of the intended recipient. Any review, use, distribution or
disclosure by others is strictly prohibited. If you are not the intended
recipient (or authorized to receive for the recipient), please contact
the sender by reply email and delete all copies of this message.

For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

=20

From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of =
Luis Nunez
Sent: Monday, April 16, 2012 6:44 PM
To: Barnum, Sean D.
Cc: idxwg@nicwg.org; mile@ietf.org; Doug Wilson (dallendoug@gmail.com); =
sacm@ietf.org; IPA-Masato Terada (m-terada@ipa.go.jp)
Subject: Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live =
onthe website

=20

I like the inclusion of the network-centric objects.  IPFIX (netflow)  =
will add an additional perspective from an incident information sharing =
standpoint. =20

=20

-ln

=20

On Apr 16, 2012, at 4:04 PM, Barnum, Sean D. wrote:

=20

Hey everyone,

=20

I just wanted to let you all know that CybOX v1.0 (Draft) content is now =
live on the website. http://cybox.mitre.org

The release notes are provided inline below.

The key items of note are:

=C2=B7        The release of two formal specifications for the CybOX =
language (one for the core language and one for the defined objects)

=C2=B7        The XML Schema has gone through extensive improvements for =
expressiveness, clarity, consistency, efficiency, alignment to existing =
normative references and documentation.

=C2=B7        This release includes an initial set of language =
utilities: a draft Snort -> CybOX transform, a draft OpenIOC -> CybOX =
transform, and a set of Python bindings for the CybOX language.

=C2=B7        The website now includes a small set of content examples. =
This set will grow going forward.

This release involved a lot of hard work from a diverse group of people. =
Thank you all for your contributions and effort. We could not have done =
it without you.

We look forward to everyone=E2=80=99s feedback and collaboration as we =
continue to improve and mature the CybOX language.

=20

Sean Barnum

=20

=20

=20

CybOX v1.0 (Draft) Release Notes

The Version 1.0 (Draft) release of Cyber Observable eXpression =
(CybOX=E2=84=A2) is intended as a draft release of an initial major =
version of the CybOX Language that could be utilized for practical =
operational use and integration into other standards efforts. This =
release consists of three primary components: a pair of formal language =
specifications for the core language content and defined objects =
content, a set of language implementation XML schemas (core, =
common_types, and ~70 defined object schemas), and a small initial set =
of language utilities including an initial draft Snort->CybOX transform, =
an initial draft OpenIOC->CybOX transform and a set of CybOX language =
Python bindings. Recognizing that this is the first time that the formal =
language specifications will be available for review and as such will =
likely generate feedback from new stakeholders, this initial major =
version is being released as a =E2=80=9Cdraft=E2=80=9D v1.0 with the =
expectation of cycles of new feedback and revision before a =
=E2=80=9Cfinal=E2=80=9D v1.0 is released.

The CybOX v1.0 (Draft) XML schemas include a significant number of =
changes from v0.7 to improve:

=C2=B7       Clarity, documentation, and descriptive formality for =
reference and implementation by other standards and users.

=C2=B7       Consistency, simplicity, and efficiency.

=C2=B7       Alignment (as appropriate) to existing normative =
references.

=C2=B7       Expressiveness of the schema to better support the broad =
set of use cases it targets (malware characterization, indicator and =
incident data sharing, event management, etc.) including the addition of =
an initial set of network-related defined objects.

Summary of changes from CybOX_v0.7 to CybOX_v1.0_(Draft):

=C2=B7       Refinement of namespaces and schema locations for better =
effectiveness and flexibility going forward.

=C2=B7       Normalized all content according to an established set of =
naming conventions.

=C2=B7       Fully annotated all language items (types, attributes, =
elements, etc.).

=C2=B7       Moved several commonly leveraged types out of the core =
schema and into common_types.

=C2=B7       Achieved full typing of entire schema structure such that =
all attributes and elements are definitively typed.

=C2=B7       Changed all identifiers from ID and IDREF types to be =
QNames enabling globally unique identifiers and flexibility for =
domain-specific users of CybOX to define their own identifier syntax =
locally.

=C2=B7       Reordered attributes and elements in numerous types to =
better reflect common usage and priority.

=C2=B7       Added major_version and minor_version attributes for core =
schema.

=C2=B7       Added capability to characterize source of overall =
observable package data and for individual observables.

=C2=B7       Modified the logical composition structure such that any =
such compositions are now contained within a Observable_Composition =
element providing improved simplicity and modularity.

=C2=B7       Removed the Delta element from ObservableType and relocated =
the appropriate portions (Change, Trend, and Frequency) to appropriate =
locations under Stateful_Measure and Event.

=C2=B7       Added a Domain_Specific_Object_Attributes field to Object =
utilizing an abstract type that will allow domain-specific use cases to =
add in their own domain-specific attributes for Objects.

=C2=B7       Added a Tool-Specific_Data field to ToolInformationType =
utilizing an abstract type that will allow addition of tool-specific =
data.

=C2=B7       Added an Indicators field to MeasureSourceType utilizing an =
abstract type that will allow characterizing differing formats or =
standards of indicators that may have led to the identification of the =
observable data.

=C2=B7       Enhanced the Hash structure to capture full fuzzy hashes in =
addition to simple hashes

=C2=B7       Added a new ExtractedFeaturesType that can be used to adorn =
differing objects (e.g., files, memory, etc.) to capture extracted =
strings, imports, functions and code snippets

=C2=B7       Added a ByteRunsType to enable capture of byte runs within =
various objects.

=C2=B7       Added object_reference attribute to DefinedObjectType to =
better support referencing of independently defined Objects from within =
another Object definition.

=C2=B7       Added a generic DataSegmentType to provide a relatively =
abstract way of characterizing data segments that may be =
written/read/transmitted or otherwise utilized in actions or defined in =
objects.

=C2=B7        Added several new defined object schemas (API, Code, =
Device, DNS_Record, Network_Flow, Network_Packet, Network_Route_Entry, =
Network_Subnet, Unix_Network_Route_Entry) including an initial set of =
network-centric defined objects.

=C2=B7       Modified every defined object schema with added annotations =
as well as minor and in some cases substantive changes to fix errors, =
improve consistency and alignment with existing normative references, =
and to improve expressiveness in support of the targeted use cases.

Detailed changes from CybOX_v0.7 to CybOX_v1.0_(Draft):

The level of changes within v1.0 (Draft) in the core schema, =
common_types and the defined object schemas is too great to list every =
change in these release notes. Detailed difference reports are available =
for each individual schema at: =
 =
http://cybox.mitre.org/XMLSchema/release_notes/cybox_v1.0(draft)_diff_rep=
orts.zip

=20

=20

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

Sean Barnum

Cyber Security Principal

The MITRE Corporation

Email: sbarnum@mitre.org

=20

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

=20


------=_NextPart_001_0178_01CD1CBA.4FE9CE70
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable


Thanks.=C2=A0 Appreciated the detailed =
explanation.
 
Mike
 
 
From:=
 =
Barnum, Sean D. [mailto:sbarnum@mitre.org] 
Sent: Tuesday, =
April 17, 2012 4:47 PM
To: Michael Hammer; osantos@cisco.com; =
Thomas.Millar@hq.dhs.gov; lnunez@c3isecurity.com
Cc: =
idxwg@nicwg.org; mile@ietf.org; sacm@ietf.org; m-terada@ipa.go.jp; =
dallendoug@gmail.com
Subject: RE: [mile] [sacm] CybOX v1.0 =
(Draft) is now released and live onthe =
website
 
Mike,
 
If you always =
utilized the most abstract label (Data Flow) to adorn events even when =
you knew the more specific type that they were and had a more specific =
label for them, then yes you would lose =
distinction.
Such misuse =
is always the potential downside of enabling flexibility through =
abstraction.
If you know =
that the event you are characterizing has to do with Packet Traffic and =
not just some form of more general data flow that does not have an =
appropriate associated event type label, then you should absolutely use =
Packet Traffic and not Data Flow. An event should only be tagged with an =
abstract label like Data Flow if there is not an appropriate more =
concrete label available.
 
In answer to =
your second question, yes Data Flow definitely covers not only =
network-related events but also events that have nothing to do with the =
wire.
My response =
to Tom Millar that I sent at 12:52am this morning lists out several =
non-network related types of events that Data Flow could apply =
to.
 
Please do not =
feel bad for asking these questions. They help you understand our =
approach, they help others understand our approach, they help us better =
understand the perspective of the communities we are targeting to =
support, they help us uncover issues with our approach or =
implementation, and they help us understand where we need to explain =
ourselves better.
 
Thank you for =
the constructive discourse.
 
sean
 
From:=
 =
Michael Hammer [mailto:michael.ham=
mer@yaanatech.com] 
Sent: Tuesday, April 17, 2012 3:28 =
PM
To: Barnum, Sean D.; osantos@cisco.com; Thomas.Millar@hq.dhs.gov; =
lnunez@c3isecurity.com
C=
c: idxwg@nicwg.org; mile@ietf.org; sacm@ietf.org; m-terada@ipa.go.jp; dallendoug@gmail.com
Subje=
ct: RE: [mile] [sacm] CybOX v1.0 (Draft) is now released and live =
onthe website
 
Sean,
 
What you say makes sense.  But, if you will bear with me.  =
(Still learning this.)
 
If one used Packet Traffic event type always instead of Data Flow =
event type, would some distinction be lost?
Or, put another way, since the packet stuff seems to cover most =
network-based events, does Data Flow involve something that is not on =
the wire?
(Such as an inter-process communication that doesn=E2=80=99t go =
through a protocol stack.)
 
Mike
 
 
From:=
 =
Barnum, Sean D. [mailto:sbarnum@mitre.org]=
 
Sent: Tuesday, April 17, 2012 3:03 PM
To: Michael =
Hammer; osantos@cisco.com; Thomas.Millar@hq.dhs.gov; =
lnunez@c3isecurity.com
C=
c: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; m-terada@ipa.go.jp
Subject:<=
/b> RE: [mile] [sacm] CybOX v1.0 (Draft) is now released and live onthe =
website
 
Mike,
 
Just to clarify, all of our discussion so far about =E2=80=9CData =
Flow=E2=80=9D and netflow were all in regards to an enumeration called =
EventTypeEnum that simply lets you tag a cyber observable event with a =
type label. It is metadata for an event =
description.
The only object we have been talking about in any detail so far was =
the Network_Flow object. These two topics are totally independent of =
each other. There is no Data_Flow object.
The abstraction overlap we have been discussing is only in the =
metadata tag applied to an event to characterize what type/class of =
event it is.
 
The defined objects themselves (including Network_Flow) have been =
designed to avoid, as much as possible, overlap of the type you =
describe.
The approach we have taken is that where there is common structure =
and meaning relevant to multiple different types of objects, the =
structure for that commonality is broken out into its own object (e.g. =
Address, URI, Port, Account, Process, etc.).
Content based on this common object structure can be embedded within =
a leveraging object (via direct use of the object type) if the content =
is directly relevant only within the context of that object or as an =
independent object and associated to any number of other objects to =
which it is relevant utilizing relationships.
We make no guarantees that we have managed to implement this approach =
flawlessly but we believe that it yields a good balance of consistency, =
efficiency and flexibility. It also allows easy modular use of only what =
is relevant within a given context and enables extension and evolution =
to easily occur in a localized fashion rather than having to extend and =
modify one monolithic structure standard.
 
Does that make sense?
 
sean
 
From:=
 =
Michael Hammer [mailto:michael.ham=
mer@yaanatech.com] 
Sent: Tuesday, April 17, 2012 9:18 =
AM
To: Barnum, Sean D.; osantos@cisco.com; Thomas.Millar@hq.dhs.gov; =
lnunez@c3isecurity.com
C=
c: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; m-terada@ipa.go.jp
Subject:<=
/b> RE: [mile] [sacm] CybOX v1.0 (Draft) is now released and live onthe =
website
 
Sean,
 
Does the overlap between the various objects present a =
problem?
 
If there are one or more objects that could carry the same data, then =
human nature means that probability-wise someone will choose data flow =
instead of Netflow.
That is the underlying principle in Murphy=E2=80=99s Law, where you =
try to design it so that there is only one way to do it, and thus =
private Murphy won=E2=80=99t do it the =E2=80=9Cwrong=E2=80=9D =
way.
 
Just wondering if these should be mutually exclusive sets.  And =
designed as such.
Might improve interoperability.  (And avoid discussions like =
this in future.)  J
 
Mike
 
 
From:=
 =
mile-bounces@ietf.org [mailto:mile-bounces@ietf.=
org] On Behalf Of Barnum, Sean D.
Sent: Tuesday, =
April 17, 2012 1:10 AM
To: Omar Santos (osantos); Millar, =
Thomas; lnunez@c3isecurity.com
C=
c: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; m-terada@ipa.go.jp
Subject:<=
/b> Re: [mile] [sacm] CybOX v1.0 (Draft) is now released and live onthe =
website
 
=E2=80=9Cupper layer=E2=80=9D? Yes, as in higher =
abstraction.
Just =E2=80=9Cprotocols=E2=80=9D? No.
 
You guys have been looking at this through the lens of network flow =
which if fine for thinking about that perspective but it is important to =
also realize that the EventTypeEnum and its =E2=80=9CData Flow=E2=80=9D =
value go far beyond network-related scope.
It is about a lot of other types of potential data flows (as I just =
outlined in a response to Tom) that have nothing to do with network =
flow.
 
Thanks for your response though. This is the kind of discussions that =
we hope to have a lot more of among the various supported =
communities.
 
 
BTW, you may have noticed that the Network_Flow object within CybOX =
v1.0 (Draft) supports expression of netflow within several of the most =
common formats including Netflow9 (as well as IPFIX as Luis pointed out, =
Netflow5 and SiLK as well as bi-directional flow in YAF). The common =
5-tuple or 7-tuple (you describe) (in our case it is an 8-tuple as we =
broke the router interface out into both ingress and egress J) shared by pretty much all of the netflow approaches has been broken =
out into a shared Network_Flow_Label structure. The various =
context-dependent portions of the independent approaches are then =
captured within optional structures dedicated to each of them. We hope =
that eventually the community can work to come together towards a single =
overall common expressive structure for netflow that meets the needs of =
all. We hope that CybOX and its use can even help that sort of =
maturation and normalization. But since no such universal structure =
exists today, we decided to enable optional expression of the most =
common individual formats within a single netflow object to serve the =
large majority of relevant users, maintain flexibility and enable =
discussions and analysis of netflow within a common =
package.
We look forward to continuing discussions with the community to =
validate or invalidate this approach and to refine and mature going =
forward.
 
Sean 
 
From:=
 =
Omar Santos (osantos) [mailto:osantos@cisco.com]=
 
Sent: Monday, April 16, 2012 11:57 PM
To: Millar, =
Thomas; Barnum, Sean D.; lnunez@c3isecurity.com
C=
c: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; m-terada@ipa.go.jp
Subject:<=
/b> RE: [sacm] [mile] CybOX v1.0 (Draft) is now released and live onthe =
website
 
I believe that what Sean is saying is that =E2=80=9Cdata =
flow=E2=80=9D is just a value that is meant for upper layer protocols. =
But, you have a good point. Traditionally, a =E2=80=9Cflow=E2=80=9D in =
=E2=80=9CNetflow=E2=80=9D is based on a set of 5 and up to 7 IP packet =
attributes:
 
- IP source address
- IP destination address
- Source port
- Destination port
- Layer 3 protocol type
- Class of Service
- Router or switch interface
 
Although, there is a lot more support with Netflow version =
9:
http://www.=
cisco.com/en/US/technologies/tk648/tk362/technologies_white_paper09186a00=
800a3db9_ps6601_Products_White_Paper.html
 
 
 
Regards,

Omar 
 
From:=
 =
Millar, Thomas [mailto:Thomas.Millar@h=
q.dhs.gov] 
Sent: Monday, April 16, 2012 11:46 =
PM
To: sbarnum@mitre.org; Omar Santos =
(osantos); lnunez@c3isecurity.com
C=
c: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; m-terada@ipa.go.jp
Subject:<=
/b> Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live onthe =
website
 
If "data flow" is a euphemism for "netflow" is =
there any reason not to call it that?

Tom Millar 
http://www.us-cert.gov/ =

------------------ 
Missit me Rubus fruticosus: 
202 631 1915 =


 
From<=
/b>: =
Barnum, Sean D. [mailto:sbarnum@mitre.org]=
 
Sent: Monday, April 16, 2012 11:29 PM
To: Omar =
Santos (osantos) <osantos@cisco.com>; Luis Nunez =
<lnunez@c3isecurity.com> =

Cc: idxwg@nicwg.org =
<idxwg@nicwg.org>; mile@ietf.org <mile@ietf.org>; dallendoug@gmail.com <dallendoug@gmail.com>; sacm@ietf.org <sacm@ietf.org>; m-terada@ipa.go.jp <m-terada@ipa.go.jp> =

Subject: Re: [sacm] [mile] CybOX v1.0 (Draft) is now released =
and live onthe website 
 
Thanks Omar.
 
To answer your question, first let me point out to other readers that =
the two entries that Omar is quoting here exist as values in an =
enumeration called EventTypeEnum which as its name implies contains a =
list of different labels for grouping types (or classes) of events to be =
used as low-granularity buckets for characterizing and classifying =
events.
Other entries in this enumeration include things like =E2=80=9CFile =
Ops (CRUD)=E2=80=9D, =E2=80=9CProcess Mgt=E2=80=9D, =
=E2=80=9CAuthorization (ACL)=E2=80=9D, etc.
 
The =E2=80=9CPacket Traffic=E2=80=9D value is intended to =
characterize events dealing with network packet traffic as its name =
implies.
The =E2=80=9CData Flow=E2=80=9D value is intended to characterize =
events dealing with forms of data flow at a higher level of abstraction =
than just packet traffic. The relationship between these two values =
could be viewed as =E2=80=9CPacket Traffic=E2=80=9D being a more =
detailed form of =E2=80=9CData Flow=E2=80=9D just as the values =
=E2=80=9CApp Layer Traffic=E2=80=9D and =E2=80=9CHTTP Layer =
Traffic=E2=80=9D, also in this enumeration, could be other levels in =
this same abstraction stack.
The idea behind the varying levels of abstraction is to leave =
 buckets large enough to capture a wide variety of potential event =
types (e.g. data flow events other than obvious things like packet =
traffic) but also enable the use of smaller more specific buckets when =
they are appropriate and commonly used.
 
Does this make sense? 
 
sean
 
From:=
 =
Omar Santos (osantos) [mailto:osantos@cisco.com]=
 
Sent: Monday, April 16, 2012 8:17 PM
To: Luis =
Nunez; Barnum, Sean D.
Cc: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; m-terada@ipa.go.jp
Subject:<=
/b> RE: [sacm] [mile] CybOX v1.0 (Draft) is now released and live onthe =
website
 
I echo Luis=E2=80=99 comments. It is good to see the inclusion of =
network objects. Quick question to the team related to your netflow =
comment.
 
I am looking at:
=
http://cybox.mitre.org/XMLSchema/cybox_core_v1.0%28draft%29.xsd<=
/o:p>
 
=E2=80=A6 and it looks that we renamed it to =E2=80=9CData =
Flow=E2=80=9D?
 
<xs:enumeration =
value=3D"Data Flow">
   =
<xs:annotation>
        =
<xs:documentation>Specifies the class of events dealing with data =
flow.</xs:documentation>
   =
</xs:annotation>
</xs:enumeration>
 
 
What is the difference between that and =E2=80=9CPacket =
Traffic=E2=80=9D?
 
<xs:enumeration value=3D"Packet =
Traffic">
   =
<xs:annotation>
     =
<xs:documentation>Specifies the class of events dealing with =
packet traffic.</xs:documentation>
   =
</xs:annotation>
</xs:enumeration>
 
 
 
 
Regards,

Omar Santos
Incident Manager, =
PSIRT
Security Research and Operations
Cisco Systems, =
Inc.
Email: os@cisco.com
Phone: +1 919 392 =
8635
PGP Key: 0x3AF27EDC

Cisco.com - http://www.cisco.com
Cisco Security =
Advisories and Notices - http://www.cisco.com/go/psirt<=
br>
This email may contain confidential and privileged material for =
the sole
use of the intended recipient. Any review, use, distribution =
or
disclosure by others is strictly prohibited. If you are not the =
intended
recipient (or authorized to receive for the recipient), =
please contact
the sender by reply email and delete all copies of =
this message.

For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html=

 
From:=
 =
sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.=
org] On Behalf Of Luis Nunez
Sent: Monday, April =
16, 2012 6:44 PM
To: Barnum, Sean D.
Cc: idxwg@nicwg.org; mile@ietf.org; Doug Wilson (dallendoug@gmail.com); sacm@ietf.org; IPA-Masato Terada (m-terada@ipa.go.jp)
Subject:=
 Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live onthe =
website
 
I like the inclusion of the network-centric =
objects.  IPFIX (netflow)  will add an additional perspective =
from an incident information sharing standpoint. =
 
 
-ln
 
On Apr 16, 2012, at 4:04 =
PM, Barnum, Sean D. wrote:
 
Hey =
everyone,
 =

I just =
wanted to let you all know that CybOX v1.0 (Draft) content is now live =
on the website. http://cybox.mitre.org
The =
release notes are provided inline =
below.
The key =
items of note are:
=C2=B7        The =
release of two formal specifications for the CybOX language (one for the =
core language and one for the defined =
objects)
=C2=B7        The XML =
Schema has gone through extensive improvements for expressiveness, =
clarity, consistency, efficiency, alignment to existing normative =
references and documentation.
=C2=B7        This =
release includes an initial set of language utilities: a draft Snort =
-> CybOX transform, a draft OpenIOC -> CybOX transform, and a set =
of Python bindings for the CybOX language.
=C2=B7        The =
website now includes a small set of content examples. This set will grow =
going forward.
This =
release involved a lot of hard work from a diverse group of people. =
Thank you all for your contributions and effort. We could not have done =
it without you.
We look =
forward to everyone=E2=80=99s feedback and collaboration as we continue =
to improve and mature the CybOX =
language.
 =

Sean =
Barnum
 =

 =

 =

CybOX v1.0 (Draft) Release =
Notes
The Version 1.0 (Draft) release of Cyber =
Observable eXpression (CybOX=E2=84=A2) is intended as a draft release of an initial major version of =
the CybOX Language that could be utilized for practical operational use =
and integration into other standards efforts. This release consists of =
three primary components: a pair of formal language specifications for =
the core language content and defined objects content, a set of language =
implementation XML schemas (core, common_types, and ~70 defined object =
schemas), and a small initial set of language utilities including an =
initial draft Snort->CybOX transform, an initial draft =
OpenIOC->CybOX transform and a set of CybOX language Python bindings. =
Recognizing that this is the first time that the formal language =
specifications will be available for review and as such will likely =
generate feedback from new stakeholders, this initial major version is =
being released as a =E2=80=9Cdraft=E2=80=9D v1.0 with the expectation of =
cycles of new feedback and revision before a =E2=80=9Cfinal=E2=80=9D =
v1.0 is released.=

The CybOX v1.0 (Draft) XML schemas include a =
significant number of changes from v0.7 to improve:=

=C2=B7       Clarity, =
documentation, and descriptive formality for reference and =
implementation by other standards and users.=

=C2=B7       Consistency, =
simplicity, and efficiency.=

=C2=B7       Alignment (as =
appropriate) to existing normative references.=

=C2=B7       Expressiveness of the =
schema to better support the broad set of use cases it targets (malware =
characterization, indicator and incident data sharing, event management, =
etc.) including the addition of an initial set of network-related =
defined objects.=

Summary =
of changes from CybOX_v0.7 to CybOX_v1.0_(Draft):=

=C2=B7       =
Refinement of namespaces and schema =
locations for better effectiveness and flexibility going forward.=

=C2=B7       =
Normalized all content according to an =
established set of naming conventions.=

=C2=B7       =
Fully annotated all language items =
(types, attributes, elements, etc.).=

=C2=B7       =
Moved several commonly leveraged types =
out of the core schema and into common_types.=

=C2=B7       =
Achieved full typing of entire schema =
structure such that all attributes and elements are definitively =
typed.=

=C2=B7       =
Changed all identifiers from ID and IDREF =
types to be QNames enabling globally unique identifiers and flexibility =
for domain-specific users of CybOX to define their own identifier syntax =
locally.=

=C2=B7       =
Reordered attributes and elements in =
numerous types to better reflect common usage and priority.=

=C2=B7       =
Added major_version and minor_version =
attributes for core schema.=

=C2=B7       =
Added capability to characterize source =
of overall observable package data and for individual observables.=

=C2=B7       =
Modified the logical composition =
structure such that any such compositions are now contained within a =
Observable_Composition element providing improved simplicity and =
modularity.=

=C2=B7       =
Removed the Delta element from =
ObservableType and relocated the appropriate portions (Change, Trend, =
and Frequency) to appropriate locations under Stateful_Measure and =
Event.=

=C2=B7       =
Added a Domain_Specific_Object_Attributes =
field to Object utilizing an abstract type that will allow =
domain-specific use cases to add in their own domain-specific attributes =
for Objects.=

=C2=B7       =
Added a Tool-Specific_Data field to =
ToolInformationType utilizing an abstract type that will allow addition =
of tool-specific data.=

=C2=B7       =
Added an Indicators field to =
MeasureSourceType utilizing an abstract type that will allow =
characterizing differing formats or standards of indicators that may =
have led to the identification of the observable data.=

=C2=B7       =
Enhanced the Hash structure to capture =
full fuzzy hashes in addition to simple hashes=

=C2=B7       =
Added a new ExtractedFeaturesType that =
can be used to adorn differing objects (e.g., files, memory, etc.) to =
capture extracted strings, imports, functions and code snippets=

=C2=B7       =
Added a ByteRunsType to enable capture of =
byte runs within various objects.=

=C2=B7       =
Added object_reference attribute to =
DefinedObjectType to better support referencing of independently defined =
Objects from within another Object definition.=

=C2=B7       =
Added a generic DataSegmentType to =
provide a relatively abstract way of characterizing data segments that =
may be written/read/transmitted or otherwise utilized in actions or =
defined in objects.=

=C2=B7        Added several new =
defined object schemas (API, Code, Device, DNS_Record, Network_Flow, =
Network_Packet, Network_Route_Entry, Network_Subnet, =
Unix_Network_Route_Entry) including an initial set of network-centric =
defined objects.
=C2=B7       =
Modified every defined object schema with =
added annotations as well as minor and in some cases substantive changes =
to fix errors, improve consistency and alignment with existing normative =
references, and to improve expressiveness in support of the targeted use =
cases.=

Detailed changes from CybOX_v0.7 to =
CybOX_v1.0_(Draft):=

The level of changes within v1.0 (Draft) in =
the core schema, common_types and the defined object schemas is too =
great to list every change in these release notes. Detailed difference =
reports are available for each individual schema at:http://cybox.mitre.org/XMLSchema/release_notes/cybox_v1.0=
(draft)_diff_reports.zip
 =

 =

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

Sean Barnum=

Cyber Security Principal=

The MITRE Corporation=

 =

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

------=_NextPart_001_0178_01CD1CBA.4FE9CE70--

------=_NextPart_000_0177_01CD1CBA.4FE9CE70
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIP6zCCBBow
ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV
BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow
OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5
MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g
QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO
ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk
IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp
ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd
hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj
DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU
Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF
s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D
J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez
useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg
lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8
T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6
g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE
74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggTXMIIDv6ADAgECAhBcX1ns/Jl/DtI19/BXCcuBMA0G
CSqGSIb3DQEBBQUAMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd
BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo
dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW
YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy
IENBIC0gRzMwHhcNMTIwNDAzMDAwMDAwWhcNMTMwNDAzMjM1OTU5WjCCAR4xFzAVBgNVBAoTDlZl
cmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13
d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChj
KTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNDAyBgNVBAsTK0RpZ2l0YWwgSUQg
Q2xhc3MgMSAtIE1pY3Jvc29mdCBGdWxsIFNlcnZpY2UxFzAVBgNVBAMUDk1pY2hhZWwgSGFtbWVy
MSswKQYJKoZIhvcNAQkBFhxtaWNoYWVsLmhhbW1lckB5YWFuYXRlY2guY29tMIGfMA0GCSqGSIb3
DQEBAQUAA4GNADCBiQKBgQDoKTk9rP/4lG6CLqIR4++IFTuOSLF6bmhDr6eiSahqU0VNP+H/LbiD
MAZsK9GQoBYPKQdKzy/gM+fl3Gm6VOdjKl8M3GB6LGgAK8d3ETN5dyKe5CAG7EEbKg9wxHWcuXW7
KYd052ven5Ec+Xj++v3HsE423O5q2mNh1Q8FNsnlXQIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYD
VR0gBD0wOzA5BgtghkgBhvhFAQcXATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2ln
bi5jb20vcnBhMAsGA1UdDwQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYD
VR0fBEkwRzBFoEOgQYY/aHR0cDovL2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20v
SW5kQzFEaWdpdGFsSUQtRzMuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQA8rhDezFsw7OlR3+mZOZ39
SCKWNJ4gMlQEe31NNtvs6BUzE1uN+fJeZrJ5zjTdJWeG1NgVugcuzQfdv/m5BYbhgJvNfW6ElqZh
cye6imOUx8diekkeHXKYSLnEvCdJItXsC1h/huIT9e83WksM92qI/TFyCq6u39cGf9PaBYbcKcZk
jHjNi3SPnGifMC6opGiiyK/vB1lituoBRcJ13Y7XoXA8T0kSR8Dtmqvo1JudcFAbS1srytG1QX1H
XTsPkTDKHlwv2ZfmCSKK3sWHDrZfpRglxvcX2OwibcKVkKBJRRw36UuJOIj/u0WYABcYtusAb2+0
nqoGmOEYARnrseTZMIIG7jCCBdagAwIBAgIQcRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUF
ADCByjELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZv
ciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQ
cmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkw
NDMwMjM1OTU5WjCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD
VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0
cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs
aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD
QSAtIEczMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP
6bGNQU4099oL42r6ZYggCxET6ZvgSU6Lb9UB0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYH
r54UGAdPWr2f0jGyVBlzRmoZQhHsEnMhjfXcMM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50
ABMN0Ibak2f4MwOuGjxraXj2wCyO4YM/d/mZ//6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yx
BF6+wbaULZeQLSfSux7pg2qE9sSyriMGZSalJ1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ
6/tu1ULEvkHH9QIDAQABo4ICuTCCArUwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRw
Oi8vb2NzcC52ZXJpc2lnbi5jb20wEgYDVR0TAQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CG
SAGG+EUBBxcBMFYwKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYI
KwYBBQUHAgIwHhocaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6Al
hiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYI
KwYBBQUHAQwEYjBgoV6gXDBaMFgwVhYJaW1hZ2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQ
UjibKaxLB4shBRgwJhYkaHR0cDovL2xvZ28udmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1Ud
EQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRlTGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EI
Qf04BKJL57XM9UP2SSsR+DCB8QYDVR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUG
A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4
BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkx
RTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB
dXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZ
gbWpBbVSOOk5hIls5DSoWufYbAlMJBq6WaSHO3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v
8dKBl8pUWkO/N4t6jhmND0OojPKvYLMVirOVnDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM6
1a4ScAjr+zvid+zoK2Q1ds262uDRyxTWcVibvtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/
XLJtSd5lUkL7DojS7Uodv0vj+Mxy+kgOZY5JyNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4
VRaMxmgD5yKocwuxvKDaUljdCg5/wYIxggS4MIIEtAIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAV
BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTsw
OQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykw
OTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFz
cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhBcX1ns/Jl/DtI19/BXCcuBMAkGBSsO
AwIaBQCgggMbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQx
NzIwNTExOVowIwYJKoZIhvcNAQkEMRYEFPLFNoYIU9Dq6iW3BE58SAKSAGRuMIGrBgkqhkiG9w0B
CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME
AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo
MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIIBAwYJKwYB
BAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd
BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo
dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW
YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy
IENBIC0gRzMCEFxfWez8mX8O0jX38FcJy4EwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkG
A1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz
dCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24u
Y29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5W
ZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhBcX1ns/Jl/DtI1
9/BXCcuBMA0GCSqGSIb3DQEBAQUABIGAoQSRKKnuz647HvZtj0L2ZUKRq/20gwvnQdVhvF/1Srda
ZyuIPu4z/flG4rYKhgPmLLxIa+Hs5MBrZwOa7MuJtYKrDwwO8J06WFqYY51HINGxPvdMiJHLJuos
U5Is6f9b7PKappnSfH94aYvI07PLdB9d/sJ/LU1BrGeMi0c/Ne0AAAAAAAA=

------=_NextPart_000_0177_01CD1CBA.4FE9CE70--

From david.oliva@verizon.net  Wed Apr 18 06:23:20 2012
Return-Path: 
X-Original-To: sacm@ietfa.amsl.com
Delivered-To: sacm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1C8E21F8566; Wed, 18 Apr 2012 06:23:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.044
X-Spam-Level: 
X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, MIME_HTML_ONLY=1.457]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UirEMjFPDere; Wed, 18 Apr 2012 06:23:16 -0700 (PDT)
Received: from vms173015pub.verizon.net (vms173015pub.verizon.net [206.46.173.15]) by ietfa.amsl.com (Postfix) with ESMTP id 102DB21F8532; Wed, 18 Apr 2012 06:23:16 -0700 (PDT)
Received: from vznit170060pub.verizon.net ([unknown] [192.168.1.3]) by vms173015.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0M2O00LIPFU1FEB0@vms173015.mailsrvcs.net>; Wed, 18 Apr 2012 08:22:50 -0500 (CDT)
Received: from 96.255.129.191 ([96.255.129.191]) by vznit170060 (Verizon Webmail) with HTTP; Wed, 18 Apr 2012 08:22:49 -0500 (CDT)
Date: Wed, 18 Apr 2012 08:22:49 -0500 (CDT)
From: david.oliva@verizon.net
To: lnunez@c3isecurity.com, sbarnum@mitre.org
Message-id: <10587345.1828362.1334755369596.JavaMail.root@vznit170060>
MIME-version: 1.0
Content-type: text/html; charset=UTF-8
Content-transfer-encoding: quoted-printable
X-Mailer: Verizon Webmail
X-Originating-IP: [96.255.129.191]
Cc: idxwg@nicwg.org, mile@ietf.org, dallendoug@gmail.com, sacm@ietf.org, m-terada@ipa.go.jp
Subject: Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live on	the website
X-BeenThere: sacm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Apr 2012 13:23:20 -0000


OUT=
STANDING!
 
Does Cybox also talk to OCI=
L, CPE, AI, and ARF (from SCAP 1.2)?
 
David Oliva=

ISSEP, CISSP, CAP, CISM, Security+, Network+
 
 
On 04/16/12, Luis Nunez<lnunez@c3isecurity.com> wr=
ote:
 
I like the inclusion of the network-centric objects. &n=
bsp;IPFIX (netflow)  will add an additional perspective from an incide=
nt information sharing standpoint.  

-ln
=

On Apr 16, 2012, at 4:04 PM, Barnum, Sean D. wrote:

Hey everyone,
 
I just wanted to let you all know that CybOX =
v1.0 (Draft) content is now live on the website. http://cybox.mitre.org=

The release notes are provided inline below.
The key items of note are:
=C2=B7      &nbs=
p; The=
 release of two formal specifications for the CybOX language (one for the c=
ore language and one for the defined objects)
=C2=B7    =
    <=
/SPAN>The XML Schema has gone through extensive improvements for exp=
ressiveness, clarity, consistency, efficiency, alignment to existing normat=
ive references and documentation.
=C2=B7      =
  This release includes an initial set of language utilities: a draft Snort =
-> CybOX transform, a draft OpenIOC -> CybOX transform, and a set of =
Python bindings for the CybOX language.
=C2=B7This =
release involved a lot of hard work from a diverse group of people. Thank y=
ou all for your contributions and effort. We could not have done it without=
 you.
We look forward to everyone=E2=80=99s feedback and co=
llaboration as we continue to improve and mature the CybOX language.
<=
DIV style=3D"MARGIN: 0in 0in 0pt; FONT-FAMILY: Calibri, sans-serif; FONT-SI=
ZE: 11pt"> 
Sean Barnum
 
 
 
CybOX v1.0 (Draft) Release Notes
The=
 Version 1.0 (Draft) release of Cyber Observable eXpression (CybOX=E2=84=A2=
) is intended as a draft=
 release of an initial major version of the CybOX Language that could be ut=
ilized for practical operational use and integration into other standards e=
fforts. This release consists of three primary components: a pair of formal=
 language specifications for the core language content and defined objects =
content, a set of language implementation XML schemas (core, common_types, =
and ~70 defined object schemas), and a small initial set of language utilit=
ies including an initial draft Snort->CybOX transform, an initial draft =
OpenIOC->CybOX transform and a set of CybOX language Python bindings. Re=
cognizing that this is the first time that the formal language specificatio=
ns will be available for review and as such will likely generate feedback f=
rom new stakeholders, this initial major version is being released as a =E2=
=80=9Cdraft=E2=80=9D v1.0 with the expectation of cycles of new feedback an=
d revision before a =E2=80=9Cfinal=E2=80=9D v1.0 is released.
<=
DIV style=3D"MARGIN: 0in 0in 0pt; FONT-FAMILY: Calibri, sans-serif; FONT-SI=
ZE: 11pt">The CybOX v1.0 (Draft) XML schemas include a significant number of ch=
anges from v0.7 to improve:
=C2=B7  &nbs=
p;    Clarity, documentation, and descriptive formality for reference =
and implementation by other standards and users.
=C2=B7       Consistency, simplicity, and efficiency.
=C2=B7       Alignment (as appro=
priate) to existing normative references.
=C2=B7       Expressiveness of =
the schema to better support the broad set of use cases it targets (malware=
 characterization, indicator and incident data sharing, event management, e=
tc.) including the addition of an initial set of network-related defined ob=
jects.
Summary of changes from CybOX_v0.7 to CybOX_v1.0_(D=
raft):
  • Refinement of namespaces and schema locations for better eff=
ectiveness and flexibility going forward.
  • Fully annotated all language items =
(types, attributes, elements, etc.).
  • Mov=
ed several commonly leveraged types out of the core schema and into common_=
types.
  • Achieved full typing of entire sc=
hema structure such that all attributes and elements are definitively typed=
.
  • Changed all identifiers from ID and ID=
REF types to be QNames enabling globally unique identifiers and flexibility=
 for domain-specific users of CybOX to define their own identifier syntax l=
ocally.
  • Reordered attributes and element=
s in numerous types to better reflect common usage and priority.
  • Added major_version and minor_version attributes f=
or core schema.
  • Added capability to char=
acterize source of overall observable package data and for individual obser=
vables.
  • Modified the logical composition=
 structure such that any such compositions are now contained within a Obser=
vable_Composition element providing improved simplicity and modularity.
  • Removed the Delta element from ObservableTy=
pe and relocated the appropriate portions (Change, Trend, and Frequency) to=
 appropriate locations under Stateful_Measure and Event.
  • Added a Domain_Specific_Object_Attributes field to Object =
utilizing an abstract type that will allow domain-specific use cases to add=
 in their own domain-specific attributes for Objects.
  • Added a Tool-Specific_Data field to ToolInformationType util=
izing an abstract type that will allow addition of tool-specific data.
  • Added an Indicators field to MeasureSourceTy=
pe utilizing an abstract type that will allow characterizing differing form=
ats or standards of indicators that may have led to the identification of t=
he observable data.
  • Enhanced the Hash st=
ructure to capture full fuzzy hashes in addition to simple hashes
  • Added a new ExtractedFeaturesType that can be use=
d to adorn differing objects (e.g., files, memory, etc.) to capture extract=
ed strings, imports, functions and code snippets
  • Added a ByteRunsType to enable capture of byte runs within various=
 objects.
  • Added object_reference attribu=
te to DefinedObjectType to better support referencing of independently defi=
ned Objects from within another Object definition.
  • Added a generic DataSegmentType to provide a relatively abstract=
 way of characterizing data segments that may be written/read/transmitted o=
r otherwise utilized in actions or defined in objects.
=C2=B7&=
nbsp;       Added s=
everal new defined object schemas (API, Code, Device, DNS_Record, Network_F=
low, Network_Packet, Network_Route_Entry, Network_Subnet, Unix_Network_Rout=
e_Entry) including an initial set of network-centric defined objects.
  • Modified every defined object schema with added annotations as wel=
l as minor and in some cases substantive changes to fix errors, improve con=
sistency and alignment with existing normative references, and to improve e=
xpressiveness in support of the targeted use cases.
Detailed changes from CybOX_v0.7 to CybOX_v1.0_(Draft):
=

The level of changes within v1.0 (Draft) in the core schema, common_=
types and the defined object schemas is too great to list every change in t=
hese release notes. Detailed difference reports are available for each indi=
vidual schema at:http://cybox.mitre.org/XMLSchema/release_note=
s/cybox_v1.0(draft)_diff_reports.zip
 
 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Sean Barnu=
m
Cyber =
Security Principal
The MITRE Corporation
________________________________=
_______________
mile mailing list
mile@ietf.org
https://www.ietf.org/mailman/listinfo/mile



___________________________________=
____________
sacm mailing list
sacm@ietf.org
https://=
www.ietf.org/mailman/listinfo/sacm


From tkeanini@ncircle.com  Thu Apr 19 13:05:53 2012
Return-Path: 
X-Original-To: sacm@ietfa.amsl.com
Delivered-To: sacm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0A1221F843E for ; Thu, 19 Apr 2012 13:05:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.298
X-Spam-Level: 
X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_27=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GO4Z4BNxC57j for ; Thu, 19 Apr 2012 13:05:47 -0700 (PDT)
Received: from mail.ncircle.com (mail.ncircle.com [76.247.119.150]) by ietfa.amsl.com (Postfix) with ESMTP id A158D21F85AA for ; Thu, 19 Apr 2012 13:05:44 -0700 (PDT)
Received: from corp-mail-sf.ncircle.com (fw-hive-gate-dmz.ncircle.com [76.247.119.129] (may be forged)) by mail.ncircle.com (8.14.4/8.14.4) with ESMTP id q3JK5Z4J053557 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 19 Apr 2012 13:05:36 -0700 (PDT) (envelope-from tkeanini@ncircle.com)
X-DKIM: OpenDKIM Filter v2.5.1 mail.ncircle.com q3JK5Z4J053557
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ncircle.com; s=key1; t=1334865943; bh=9NT7c80K+/dFMxZ8739gSSoOTB2m3vWI0JhSF3IWBXs=; h=Subject:Date:In-Reply-To:References:From:To:CC; b=aDKF+btcdYGur2/fdH39RFkekNfnW5Vuy1V7vYZlbytC9j4nZ3ueLXtunl9cD8Zkd yIQTnl946w0QgVl+JK2JQ==
Received: from CORP-MAIL.ad.ncircle.com (192.168.75.90) by EXCH-SF-01.ad.ncircle.com (192.168.75.47) with Microsoft SMTP Server id 14.2.298.4; Thu, 19 Apr 2012 13:05:34 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD1E67.C822D043"
Date: Thu, 19 Apr 2012 13:05:34 -0700
Message-ID: 
In-Reply-To: <4F84649F.1070406@joval.org>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [sacm] Status Update Request
Thread-Index: Ac0XOfBy/1D0l6awSP2BorLBkQPsdAAAExlg
References:  <4F8364DF.5090809@joval.org>  <4F84649F.1070406@joval.org>
From: Tim Keanini 
To: David Solin 
X-Scanned-By: MIMEDefang 2.72 on 76.247.119.150
Cc: sacm@ietf.org
Subject: Re: [sacm] Status Update Request
X-BeenThere: sacm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Apr 2012 20:05:53 -0000

------_=_NextPart_001_01CD1E67.C822D043
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I would argue that it is not a problem of uniqueness but a machine
learning problem of computing inter-domain equivalence (which may or may
not be unique).  I say this only because in these case we are talking
about computing the syntactical equivalence but certainly in the future
we could also do this based on semantic equivalence. =20

=20

And you are so right in that CIM would require more schema to aid in the
task of synthesis with sacm/scap.  I'm completely in agreement at the
technical level.    In fact, most of the fields in AI can be computed
from the CIM model (being a subset). =20

=20

What I am sensitive to here is the administrative realms and political
realms of both standards.  If the solution couples the two standards
such that one is impaired by the others progress or dormancy, bad
design, no donut. =20

=20

--tk

=20

--

Tim "TK" Keanini, CTO    ...    nCircle Inc.   ...   mbl (415) 328-2722
...

=20

From: David Solin [mailto:solin@farnamhallventures.com] On Behalf Of
David Solin
Sent: Tuesday, April 10, 2012 11:50 AM
To: Tim Keanini
Cc: sacm@ietf.org
Subject: Re: [sacm] Status Update Request

=20

Hi Tim,

Addressing the problem of uniqueness certainly does not require an
entirely new data model.  Existing CMDBs have to solve the problem of
multiple discovery sources, as each product interacting with it is
potentially another discovery source.  BMC's Atrium CMDB, for instance,
extends the CIM schema with a reconciliation ID that is used for this
purpose, and I imagine that's probably not an uncommon solution.
There's no reason we can't have an Asset Identification specification
that consists purely of an extension of CIM -- where we can add, for
instance, a CPE property to existing classes (e.g., OperatingSystem,
DatabaseSystem ... or perhaps just to the System parent class?).
Indeed, perhaps that's what you're suggesting?

To my eye, the AI specification looks largely like a subset of CIM,
except with the addition of the specialized ai:website object (which
feels like it should be unnecessary).  Why do we want to reinvent the
wheel?

Regards,
--David

On 4/10/2012 10:36 AM, Tim Keanini wrote:=20

There are at least two considerations:=20

-          Inter-domain multi-sensor data fusion and synthesis

-          Limitations of discovery (instance data resolution)

=20

Inter-domain multi-sensor data fusion and synthesis

This is for all practical purposes the inverse-functional-property or
primary key syntax match problem.

The metadata in AI is designed with the other SCAP metadata in mind
whereas CIM was not and while they may share common keys like IP address
to perform a join, more and more this is not a stable characteristic of
the asset in either domain.  Another consideration here is that CIM
would not have in it something like a CPE identifier, very common key
for synthesis across domains within the SCAP family.  My suggestion here
is that we not look for a single domain to identify an asset but to
ensure that all the data domains (AI, CIM, etc) have in them enough
boundary objects to "join" or synthesize multiple domains.  We should
ensure that all information domains have in it a rich set of stable
characteristics that afford syntactical matching of the metadata for the
purposes of Inter-domain multi-sensor data fusion and synthesis

=20

=20

Limitations of discovery (instance data resolution): Authenticated and
Unauthenticated Discovery=20

Remote automated scanning comes in at least two flavors,
authenticated-scanning and unauthenticated-scanning.  We must keep this
in mind as we look to the design or borrow these metadata formats (AI,
CIM, etc).  Most if not all CMDB assumes the old network management
mindset of nodes-under-management and node-not-under-management.  The
former having an agent installed or some authentication/authorization
provided, the latter assumes an assessment of the target via its target
surface in an unauthenticated manner.  I raise this issue once again
because OVAL for example makes no provision for the assessment to take
place in an unauthenticated manner.   We need to keep this in mind as we
look to populate the metadata of AI as certain fields will only be valid
for authenticated scanning or an agent.  I'm a vendor that has both
types of scanners and I must say that for reasons I will not get into
here, customers deploy unauthenticated scanners across their entire
enterprise and authenticated scanners in targeted scopes.  I raise this
issue because time and time again, customers come back to us with the
unauthenticated scanners having much more identification of end-point
assets than any other authenticated scanner.  This is a sidebar but I
wanted to share this experience having been a supplier of this
technology for the past 12 years.   =20

=20

=20

--

Tim "TK" Keanini, CTO    ...    nCircle Inc.   ...   mbl (415) 328-2722
...

=20

From: sacm-bounces@ietf.org 
[mailto:sacm-bounces@ietf.org] 
On Behalf Of David Solin
Sent: Monday, April 09, 2012 5:38 PM
To: sacm@ietf.org =20
Subject: Re: [sacm] Status Update Request

=20

That is very neat, but I also have a question on the original topic...

Was there any discussion at the meeting in Paris on Asset Identification
vs. CIM, or has anyone identified a use-case for AI for which CIM is not
appropriate?  For the sake of making SACM easily adoptable by large
enterprises with existing CMDB implementations, I strongly advocate
abandoning AI in favor of CIM.  I'd be happy to discuss how BMC, IBM,
HP, CA, etc. have been making CIM the centerpiece of their systems
management offerings for most of the past decade.

Regards,
--David Solin




--=20

jOVAL.org: OVAL implemented in Java.
Scan any machine from any machine. For free!
Learn More   | Features
  | Download
 =20



On 4/9/2012 3:43 PM, Kent_Landfield@McAfee.com wrote:=20

What do you know....  SACM is already being valuable. ;-)

=20

Kent Landfield
Director Content Strategy, Architecture and Standards

McAfee | An Intel Company
5000 Headquarters Dr.
Plano, Texas 75024

Direct: +1.972.963.7096=20
Mobile: +1.817.637.8026
Web: www.mcafee.com =20

=20

From: "Polk, William T."  >
Date: Mon, 9 Apr 2012 15:22:25 -0500
To: Tim Keanini  >,
David Waltermire  >, Adam Montville
 >,
"sacm@ietf.org  "  >
Subject: Re: [sacm] Status Update Request

=20

	I wish someone would have told me this 14 RFCs ago....

	=20

	Tim

	________________________________________

	From: sacm-bounces@ietf.org [sacm-bounces@ietf.org] On Behalf Of
Tim Keanini [tkeanini@ncircle.com]

	Sent: Monday, April 09, 2012 4:14 PM

	To: Waltermire, David A.; Adam Montville; sacm@ietf.org

	Subject: Re: [sacm] Status Update Request

	=20

	We will certainly need a few ascii diagrams so let me share this
link:

	http://www.asciiflow.com/

	=20

	--tk

	=20

	--

	Tim "TK" Keanini, CTO    ...    nCircle Inc.

	=20

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

	From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On
Behalf Of

	Waltermire, David A.

	Sent: Monday, April 09, 2012 2:04 PM

	To: Adam Montville; 'sacm@ietf.org  '

	Subject: Re: [sacm] Status Update Request

	=20

	I can take a stab at that.  It will be useful at minimum to
start some

	discussion.

	Dave

	=20

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

		From: Adam Montville [mailto:amontville@tripwire.com]

		Sent: Monday, April 09, 2012 2:48 PM

		To: Waltermire, David A.; 'sacm@ietf.org
 '

		Subject: Re: Status Update Request

		=20

		Hi Dave,

		=20

		Thanks for sending this out.  I like the abstract and
the structure of

	=20

		the document so far, so no further comments from me on
the abstract.

		Are you planning to create a first pass at a complete
list of use

		cases for the document?

		=20

		Adam

		=20

		On 4/9/12 11:41 AM, "Waltermire, David A."


		wrote:

		=20

		>Please find a skeleton I-D of the use case document
attached with

		>updates to the abstract based on the feedback to date.
If there are

		no

		>other comments on the abstract I'll start work on the
introduction

		>and we can start breaking out use cases and authors for
each use

	case.

		>=20

		>Sincerely,

		>Dave

		>=20

		>=20

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

		>> From: sacm-bounces@ietf.org
[mailto:sacm-bounces@ietf.org] On

		>> Behalf Of Adam Montville

		>> Sent: Monday, April 09, 2012 2:33 PM

		>> To: 'sacm@ietf.org  '

		>> Subject: [sacm] Status Update Request

		>>=20

		>> All:

		>>=20

		>> The list seems to be rather quiet since the close of
IETF 83 more

		>> than a week ago.  Actions coming out of the side
meeting held on

		>> March 24

		>> included:

		>>=20

		>> 1. Use Case document first draft by middle of April
2. Use Case

		>> initial revision by end of April 3. Start of a
charter discussion

		>> around middle of April (after first draft Use Case
release)

		>>=20

		>> Dave Waltermire has offered to lead development of
the Use Case

		>> document and Kent Landfield has offered to lead the
subsequent

		>> charter discussion.

		>>=20

		>> Dave/Kent: Do either of you have an update you can
share?

		>>=20

		>> Adam

		>>=20

		>>=20

		>>=20

		>> _______________________________________________

		>> sacm mailing list

		>> sacm@ietf.org

		>> https://www.ietf.org/mailman/listinfo/sacm

		=20

	=20

	_______________________________________________

	sacm mailing list

	sacm@ietf.org

	https://www.ietf.org/mailman/listinfo/sacm

	_______________________________________________

	sacm mailing list

	sacm@ietf.org

	https://www.ietf.org/mailman/listinfo/sacm

	_______________________________________________

	sacm mailing list

	sacm@ietf.org

	https://www.ietf.org/mailman/listinfo/sacm

	=20







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

=20

=20

--=20

jOVAL.org: OVAL implemented in Java.
Scan any machine from any machine. For free!
Learn More   | Features
  | Download
 =20


------_=_NextPart_001_01CD1E67.C822D043
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


I would argue that it is not a problem of uniqueness but a machine =
learning problem of computing inter-domain equivalence (which may or may =
not be unique).  I say this only because in these case we are =
talking about computing the syntactical equivalence but certainly in the =
future we could also do this based on semantic equivalence.  =

 
And you are so right in that CIM would require more schema to aid in =
the task of synthesis with sacm/scap.  I’m completely in =
agreement at the technical level.    In fact, most of the =
fields in AI can be computed from the CIM model (being a subset).  =

 
What I am sensitive to here is the administrative realms and =
political realms of both standards.  If the solution couples the =
two standards such that one is impaired by the others progress or =
dormancy, bad design, no donut.  
 
--tk
 
--
Tim "TK" Keanini, CTO    =
…    nCircle Inc.   …   =
mbl (415) 328-2722  …
 
From: David Solin [mailto:solin@farna=
mhallventures.com] On Behalf Of David Solin
Sent: =
Tuesday, April 10, 2012 11:50 AM
To: Tim Keanini
Cc: =
sacm@ietf.org
Subject: =
Re: [sacm] Status Update Request
 
Hi =
Tim,

Addressing the problem of uniqueness certainly does not =
require an entirely new data model.  Existing CMDBs have to solve =
the problem of multiple discovery sources, as each product interacting =
with it is potentially another discovery source.  BMC's Atrium =
CMDB, for instance, extends the CIM schema with a reconciliation ID that =
is used for this purpose, and I imagine that's probably not an uncommon =
solution.  There's no reason we can't have an Asset Identification =
specification that consists purely of an extension of CIM -- where we =
can add, for instance, a CPE property to existing classes (e.g., =
OperatingSystem, DatabaseSystem ... or perhaps just to the System parent =
class?).  Indeed, perhaps that's what you're suggesting?

To =
my eye, the AI specification looks largely like a subset of CIM, except =
with the addition of the specialized ai:website object (which feels like =
it should be unnecessary).  Why do we want to reinvent the =
wheel?

Regards,
--David

On 4/10/2012 10:36 AM, Tim =
Keanini wrote: 
There are at least two considerations: 
-          =
Inter-domain multi-sensor data fusion and =
synthesis
-          =
Limitations of discovery (instance data =
resolution)
 
Inter-domain multi-sensor data fusion and =
synthesis
This is for all practical purposes the inverse-functional-property or =
primary key syntax match problem.
The metadata in AI is designed with the other SCAP metadata in mind =
whereas CIM was not and while they may share common keys like IP address =
to perform a join, more and more this is not a stable characteristic of =
the asset in either domain.  Another consideration here is that CIM =
would not have in it something like a CPE identifier, very common key =
for synthesis across domains within the SCAP family.  My suggestion =
here is that we not look for a single domain to identify an asset but to =
ensure that all the data domains (AI, CIM, etc) have in them enough =
boundary objects to “join” or synthesize multiple =
domains.  We should ensure that all information domains have in it =
a rich set of stable characteristics that afford syntactical matching of =
the metadata for the purposes of Inter-domain multi-sensor data fusion =
and synthesis
 
 
Limitations of discovery (instance data resolution): Authenticated =
and Unauthenticated Discovery 
Remote automated scanning comes in at least two flavors, =
authenticated-scanning and unauthenticated-scanning.  We must keep =
this in mind as we look to the design or borrow these metadata formats =
(AI, CIM, etc).  Most if not all CMDB assumes the old network =
management mindset of nodes-under-management and =
node-not-under-management.  The former having an agent installed or =
some authentication/authorization provided, the latter assumes an =
assessment of the target via its target surface in an unauthenticated =
manner.  I raise this issue once again because OVAL for example =
makes no provision for the assessment to take place in an =
unauthenticated manner.   We need to keep this in mind as we =
look to populate the metadata of AI as certain fields will only be valid =
for authenticated scanning or an agent.  I’m a vendor that =
has both types of scanners and I must say that for reasons I will not =
get into here, customers deploy unauthenticated scanners across their =
entire enterprise and authenticated scanners in targeted scopes.  I =
raise this issue because time and time again, customers come back to us =
with the unauthenticated scanners having much more identification of =
end-point assets than any other authenticated scanner.  This is a =
sidebar but I wanted to share this experience having been a supplier of =
this technology for the past 12 years.  =
  
 
 
--
Tim "TK" Keanini, CTO    =
…    nCircle Inc.   …   =
mbl (415) 328-2722  …
 
From: sacm-bounces=
@ietf.org [mailto:sacm=
-bounces@ietf.org] On Behalf Of David Solin
Sent: Monday, April 09, =
2012 5:38 PM
To: sacm@ietf.or=
g
Subject: Re: [sacm] Status Update =
Request
 
That is very neat, but I also have a =
question on the original topic...

Was there any discussion at the =
meeting in Paris on Asset Identification vs. CIM, or has anyone =
identified a use-case for AI for which CIM is not appropriate?  For =
the sake of making SACM easily adoptable by large enterprises with =
existing CMDB implementations, I strongly advocate abandoning AI in =
favor of CIM.  I'd be happy to discuss how BMC, IBM, HP, CA, etc. =
have been making CIM the centerpiece of their systems management =
offerings for most of the past decade.

Regards,
--David =
Solin


-- =

jOVAL.org: OVAL implemented in Java.=

=
Scan any machine from any machine. For free!=

=
Learn More=
 | =
Features=
 | =
Download=
 


On 4/9/2012 =
3:43 PM, Kent_Landfield@McAfee.com =
wrote: 
What do you =
know….  SACM is already being valuable. =
;-)
 
=
Kent Landfield=

Director Content Strategy, =
Architecture and Standards

McAfee | An Intel =
Company
5000 =
Headquarters Dr.
Plano, Texas =
75024

Direct: =
+1.972.963.7096 
Mobile: =
+1.817.637.8026
Web: www.mcafee.com=

 
From: =
"Polk,=
 William T." <william.pol=
k@nist.gov>
=
Date: Mon, 9 Apr 2012 15:22:25 -0500
To: Tim Keanini =
<tkeanini@nc=
ircle.com>, =
David Waltermire <david.walte=
rmire@nist.gov>, Adam =
Montville <amontville@=
tripwire.com>, =
"sacm@ietf.o=
rg" =
<sacm@ietf.o=
rg>
=
Subject: Re: [sacm] Status Update =
Request
 
I wish someone would have told me this 14 RFCs =
ago....
 
Tim
________________________________________
=

Sent: Monday, April 09, 2012 4:14 =
PM
To: Waltermire, David =
A.; Adam Montville; sacm@ietf.org
=

Subject: Re: [sacm] Status Update =
Request
 
We will certainly need a few ascii diagrams so let me =
share this link:
 
--tk
 
--
Tim =
"TK" Keanini, =
CTO    ...    nCircle =
Inc.
 
-----Original Message-----
Waltermire, =
David A.
Sent: Monday, =
April 09, 2012 2:04 PM
To: =
Adam Montville; 'sacm@ietf.org'
=

Subject: Re: [sacm] Status Update =
Request
 
I =
can take a stab at that.  It will be useful at minimum to =
start some
discussion.
Dave
 
-----Original Message-----
From: Adam Montville [mailto:amontville@tripwire.com]
=

Subject: Re: Status Update =
Request
 
Hi Dave,
 
Thanks for sending this out.  I like the =
abstract and the structure of
 
the document so far, so no further comments from me on =
the abstract.
Are you =
planning to create a first pass at a complete list of =
use
cases for the =
document?
 
Adam
 
On 4/9/12 11:41 AM, "Waltermire, David A." =
<david.waltermire@nist.gov&g=
t;
wrote:
 
>Please find a skeleton I-D of the use case =
document attached with
>updates to the abstract based on the feedback to =
date.  If there are
no
>other comments on the abstract I'll start work on =
the introduction
>and =
we can start breaking out use cases and authors for each =
use
case.
> 
>Sincerely,
>Dave
> 
> 
>> -----Original =
Message-----
>> Behalf Of Adam =
Montville
>> Sent: =
Monday, April 09, 2012 2:33 PM
=

>> Subject: [sacm] Status Update =
Request
>> 
>> All:
>> 
>> The list seems to be rather quiet since the =
close of IETF 83 more
>> than a week ago.  Actions coming =
out of the side meeting held on
>> March 24
>> included:
>> 
>> 1. Use Case document first draft by middle of =
April 2. Use Case
>> =
initial revision by end of April 3. Start of a charter =
discussion
>> around =
middle of April (after first draft Use Case =
release)
>> 
>> Dave Waltermire has offered to lead =
development of the Use Case
>> document and Kent Landfield has offered to =
lead the subsequent
>> charter =
discussion.
>> 
>> Dave/Kent: Do either of you have an update =
you can share?
>> 
>> Adam
>> 
>> 
>> 
>> =
_______________________________________________
=

>> sacm mailing =
list
 
 
_______________________________________________
sacm mailing =
list
_______________________________________________
sacm mailing =
list
_______________________________________________
sacm mailing =
list
 




___________________=
____________________________
sacm mailing =
list
sacm@ietf.org
https://www.ietf.org/=
mailman/listinfo/sacm
 
 
-- 
jOVAL.org: OVAL implemented in Java.=

=
Scan any machine from any machine. For free!=

=
Learn More=
 | =
Features=
 | =
Download=
 

------_=_NextPart_001_01CD1E67.C822D043--

From sbarnum@mitre.org  Tue Apr 17 12:02:40 2012
Return-Path: 
X-Original-To: sacm@ietfa.amsl.com
Delivered-To: sacm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 951B821F854B; Tue, 17 Apr 2012 12:02:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level: 
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MXW1fRzVR2re; Tue, 17 Apr 2012 12:02:35 -0700 (PDT)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id DA1E221F8548; Tue, 17 Apr 2012 12:02:34 -0700 (PDT)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 4322421B112F; Tue, 17 Apr 2012 15:02:34 -0400 (EDT)
Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 34C8521B112C; Tue, 17 Apr 2012 15:02:34 -0400 (EDT)
Received: from IMCMBX03.MITRE.ORG ([169.254.3.179]) by IMCCAS01.MITRE.ORG ([129.83.29.78]) with mapi id 14.02.0283.003; Tue, 17 Apr 2012 15:02:33 -0400
From: "Barnum, Sean D." 
To: Michael Hammer , "osantos@cisco.com" , "Thomas.Millar@hq.dhs.gov" ,  "lnunez@c3isecurity.com" 
Thread-Topic: [mile] [sacm] CybOX v1.0 (Draft) is now released and live onthe website
Thread-Index: AQHNHJx9CTO+wm8DM0KsuNMXzL3C5ZafV3hg
Date: Tue, 17 Apr 2012 19:02:32 +0000
Message-ID: <7F48813B48558A4BB5CB7BB714E5B5A9173046@IMCMBX03.MITRE.ORG>
References: <7F48813B48558A4BB5CB7BB714E5B5A9171B16@IMCMBX03.MITRE.ORG> <69CE2DCD9DAC3D48B830E0723141170B02A39BD2@ZAU1UG-0308.DHSNET.DS1.DHS> <953A2E460DBE7C43AC13E30B87C5B4FF080A1C09@XMB-RCD-106.cisco.com> <7F48813B48558A4BB5CB7BB714E5B5A9171BA1@IMCMBX03.MITRE.ORG> <00C069FD01E0324C9FFCADF539701DB389FC37@EX2K10MB1.corp.yaanatech.com>
In-Reply-To: <00C069FD01E0324C9FFCADF539701DB389FC37@EX2K10MB1.corp.yaanatech.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [172.31.135.134]
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_003E_01CD1CAB.18E81260"
MIME-Version: 1.0
X-Mailman-Approved-At: Fri, 20 Apr 2012 05:41:23 -0700
Cc: "idxwg@nicwg.org" , "mile@ietf.org" , "dallendoug@gmail.com" , "sacm@ietf.org" , "m-terada@ipa.go.jp" 
Subject: Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live onthe website
X-BeenThere: sacm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Apr 2012 19:02:40 -0000

------=_NextPart_000_003E_01CD1CAB.18E81260
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_003F_01CD1CAB.18E81260"


------=_NextPart_001_003F_01CD1CAB.18E81260
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Mike,

=20

Just to clarify, all of our discussion so far about =E2=80=9CData =
Flow=E2=80=9D and netflow were all in regards to an enumeration called =
EventTypeEnum that simply lets you tag a cyber observable event with a =
type label. It is metadata for an event description.

The only object we have been talking about in any detail so far was the =
Network_Flow object. These two topics are totally independent of each =
other. There is no Data_Flow object.

The abstraction overlap we have been discussing is only in the metadata =
tag applied to an event to characterize what type/class of event it is.

=20

The defined objects themselves (including Network_Flow) have been =
designed to avoid, as much as possible, overlap of the type you =
describe.

The approach we have taken is that where there is common structure and =
meaning relevant to multiple different types of objects, the structure =
for that commonality is broken out into its own object (e.g. Address, =
URI, Port, Account, Process, etc.).

Content based on this common object structure can be embedded within a =
leveraging object (via direct use of the object type) if the content is =
directly relevant only within the context of that object or as an =
independent object and associated to any number of other objects to =
which it is relevant utilizing relationships.

We make no guarantees that we have managed to implement this approach =
flawlessly but we believe that it yields a good balance of consistency, =
efficiency and flexibility. It also allows easy modular use of only what =
is relevant within a given context and enables extension and evolution =
to easily occur in a localized fashion rather than having to extend and =
modify one monolithic structure standard.

=20

Does that make sense?

=20

sean

=20

From: Michael Hammer [mailto:michael.hammer@yaanatech.com]=20
Sent: Tuesday, April 17, 2012 9:18 AM
To: Barnum, Sean D.; osantos@cisco.com; Thomas.Millar@hq.dhs.gov; =
lnunez@c3isecurity.com
Cc: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; =
m-terada@ipa.go.jp
Subject: RE: [mile] [sacm] CybOX v1.0 (Draft) is now released and live =
onthe website

=20

Sean,

=20

Does the overlap between the various objects present a problem?

=20

If there are one or more objects that could carry the same data, then =
human nature means that probability-wise someone will choose data flow =
instead of Netflow.

That is the underlying principle in Murphy=E2=80=99s Law, where you try =
to design it so that there is only one way to do it, and thus private =
Murphy won=E2=80=99t do it the =E2=80=9Cwrong=E2=80=9D way.

=20

Just wondering if these should be mutually exclusive sets.  And designed =
as such.

Might improve interoperability.  (And avoid discussions like this in =
future.)  J

=20

Mike

=20

=20

From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of =
Barnum, Sean D.
Sent: Tuesday, April 17, 2012 1:10 AM
To: Omar Santos (osantos); Millar, Thomas; lnunez@c3isecurity.com
Cc: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; =
m-terada@ipa.go.jp
Subject: Re: [mile] [sacm] CybOX v1.0 (Draft) is now released and live =
onthe website

=20

=E2=80=9Cupper layer=E2=80=9D? Yes, as in higher abstraction.

Just =E2=80=9Cprotocols=E2=80=9D? No.

=20

You guys have been looking at this through the lens of network flow =
which if fine for thinking about that perspective but it is important to =
also realize that the EventTypeEnum and its =E2=80=9CData Flow=E2=80=9D =
value go far beyond network-related scope.

It is about a lot of other types of potential data flows (as I just =
outlined in a response to Tom) that have nothing to do with network =
flow.

=20

Thanks for your response though. This is the kind of discussions that we =
hope to have a lot more of among the various supported communities.

=20

=20

BTW, you may have noticed that the Network_Flow object within CybOX v1.0 =
(Draft) supports expression of netflow within several of the most common =
formats including Netflow9 (as well as IPFIX as Luis pointed out, =
Netflow5 and SiLK as well as bi-directional flow in YAF). The common =
5-tuple or 7-tuple (you describe) (in our case it is an 8-tuple as we =
broke the router interface out into both ingress and egress J) shared by =
pretty much all of the netflow approaches has been broken out into a =
shared Network_Flow_Label structure. The various context-dependent =
portions of the independent approaches are then captured within optional =
structures dedicated to each of them. We hope that eventually the =
community can work to come together towards a single overall common =
expressive structure for netflow that meets the needs of all. We hope =
that CybOX and its use can even help that sort of maturation and =
normalization. But since no such universal structure exists today, we =
decided to enable optional expression of the most common individual =
formats within a single netflow object to serve the large majority of =
relevant users, maintain flexibility and enable discussions and analysis =
of netflow within a common package.

We look forward to continuing discussions with the community to validate =
or invalidate this approach and to refine and mature going forward.

=20

Sean=20

=20

From: Omar Santos (osantos) [mailto:osantos@cisco.com]=20
Sent: Monday, April 16, 2012 11:57 PM
To: Millar, Thomas; Barnum, Sean D.; lnunez@c3isecurity.com
Cc: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; =
m-terada@ipa.go.jp
Subject: RE: [sacm] [mile] CybOX v1.0 (Draft) is now released and live =
onthe website

=20

I believe that what Sean is saying is that =E2=80=9Cdata flow=E2=80=9D =
is just a value that is meant for upper layer protocols. But, you have a =
good point. Traditionally, a =E2=80=9Cflow=E2=80=9D in =
=E2=80=9CNetflow=E2=80=9D is based on a set of 5 and up to 7 IP packet =
attributes:

=20

- IP source address

- IP destination address

- Source port

- Destination port

- Layer 3 protocol type

- Class of Service

- Router or switch interface

=20

Although, there is a lot more support with Netflow version 9:

http://www.cisco.com/en/US/technologies/tk648/tk362/technologies_white_pa=
per09186a00800a3db9_ps6601_Products_White_Paper.html

=20

=20

=20

Regards,

Omar=20

=20

From: Millar, Thomas [mailto:Thomas.Millar@hq.dhs.gov]=20
Sent: Monday, April 16, 2012 11:46 PM
To: sbarnum@mitre.org; Omar Santos (osantos); lnunez@c3isecurity.com
Cc: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; =
m-terada@ipa.go.jp
Subject: Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live =
onthe website

=20

If "data flow" is a euphemism for "netflow" is there any reason not to =
call it that?

Tom Millar=20
http://www.us-cert.gov/=20
------------------=20
Missit me Rubus fruticosus:=20
202 631 1915=20

=20

From: Barnum, Sean D. [mailto:sbarnum@mitre.org]=20
Sent: Monday, April 16, 2012 11:29 PM
To: Omar Santos (osantos) ; Luis Nunez =
=20
Cc: idxwg@nicwg.org ; mile@ietf.org ; =
dallendoug@gmail.com ; sacm@ietf.org =
; m-terada@ipa.go.jp =20
Subject: Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live =
onthe website=20
=20

Thanks Omar.

=20

To answer your question, first let me point out to other readers that =
the two entries that Omar is quoting here exist as values in an =
enumeration called EventTypeEnum which as its name implies contains a =
list of different labels for grouping types (or classes) of events to be =
used as low-granularity buckets for characterizing and classifying =
events.

Other entries in this enumeration include things like =E2=80=9CFile Ops =
(CRUD)=E2=80=9D, =E2=80=9CProcess Mgt=E2=80=9D, =E2=80=9CAuthorization =
(ACL)=E2=80=9D, etc.

=20

The =E2=80=9CPacket Traffic=E2=80=9D value is intended to characterize =
events dealing with network packet traffic as its name implies.

The =E2=80=9CData Flow=E2=80=9D value is intended to characterize events =
dealing with forms of data flow at a higher level of abstraction than =
just packet traffic. The relationship between these two values could be =
viewed as =E2=80=9CPacket Traffic=E2=80=9D being a more detailed form of =
=E2=80=9CData Flow=E2=80=9D just as the values =E2=80=9CApp Layer =
Traffic=E2=80=9D and =E2=80=9CHTTP Layer Traffic=E2=80=9D, also in this =
enumeration, could be other levels in this same abstraction stack.

The idea behind the varying levels of abstraction is to leave  buckets =
large enough to capture a wide variety of potential event types (e.g. =
data flow events other than obvious things like packet traffic) but also =
enable the use of smaller more specific buckets when they are =
appropriate and commonly used.

=20

Does this make sense?=20

=20

sean

=20

From: Omar Santos (osantos) [mailto:osantos@cisco.com]=20
Sent: Monday, April 16, 2012 8:17 PM
To: Luis Nunez; Barnum, Sean D.
Cc: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; =
m-terada@ipa.go.jp
Subject: RE: [sacm] [mile] CybOX v1.0 (Draft) is now released and live =
onthe website

=20

I echo Luis=E2=80=99 comments. It is good to see the inclusion of =
network objects. Quick question to the team related to your netflow =
comment.

=20

I am looking at:

http://cybox.mitre.org/XMLSchema/cybox_core_v1.0%28draft%29.xsd

=20

=E2=80=A6 and it looks that we renamed it to =E2=80=9CData =
Flow=E2=80=9D?

=20



   

        Specifies the class of events dealing with =
data flow.

   



=20

=20

What is the difference between that and =E2=80=9CPacket =
Traffic=E2=80=9D?

=20


   
     Specifies the class of events dealing with packet =
traffic.
   


=20

=20

=20

=20

Regards,

Omar Santos
Incident Manager, PSIRT
Security Research and Operations
Cisco Systems, Inc.
Email: os@cisco.com
Phone: +1 919 392 8635
PGP Key: 0x3AF27EDC

Cisco.com - http://www.cisco.com
Cisco Security Advisories and Notices - http://www.cisco.com/go/psirt

This email may contain confidential and privileged material for the sole
use of the intended recipient. Any review, use, distribution or
disclosure by others is strictly prohibited. If you are not the intended
recipient (or authorized to receive for the recipient), please contact
the sender by reply email and delete all copies of this message.

For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

=20

From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of =
Luis Nunez
Sent: Monday, April 16, 2012 6:44 PM
To: Barnum, Sean D.
Cc: idxwg@nicwg.org; mile@ietf.org; Doug Wilson (dallendoug@gmail.com); =
sacm@ietf.org; IPA-Masato Terada (m-terada@ipa.go.jp)
Subject: Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live =
onthe website

=20

I like the inclusion of the network-centric objects.  IPFIX (netflow)  =
will add an additional perspective from an incident information sharing =
standpoint. =20

=20

-ln

=20

On Apr 16, 2012, at 4:04 PM, Barnum, Sean D. wrote:

=20

Hey everyone,

=20

I just wanted to let you all know that CybOX v1.0 (Draft) content is now =
live on the website. http://cybox.mitre.org

The release notes are provided inline below.

The key items of note are:

=C2=B7        The release of two formal specifications for the CybOX =
language (one for the core language and one for the defined objects)

=C2=B7        The XML Schema has gone through extensive improvements for =
expressiveness, clarity, consistency, efficiency, alignment to existing =
normative references and documentation.

=C2=B7        This release includes an initial set of language =
utilities: a draft Snort -> CybOX transform, a draft OpenIOC -> CybOX =
transform, and a set of Python bindings for the CybOX language.

=C2=B7        The website now includes a small set of content examples. =
This set will grow going forward.

This release involved a lot of hard work from a diverse group of people. =
Thank you all for your contributions and effort. We could not have done =
it without you.

We look forward to everyone=E2=80=99s feedback and collaboration as we =
continue to improve and mature the CybOX language.

=20

Sean Barnum

=20

=20

=20

CybOX v1.0 (Draft) Release Notes

The Version 1.0 (Draft) release of Cyber Observable eXpression =
(CybOX=E2=84=A2) is intended as a draft release of an initial major =
version of the CybOX Language that could be utilized for practical =
operational use and integration into other standards efforts. This =
release consists of three primary components: a pair of formal language =
specifications for the core language content and defined objects =
content, a set of language implementation XML schemas (core, =
common_types, and ~70 defined object schemas), and a small initial set =
of language utilities including an initial draft Snort->CybOX transform, =
an initial draft OpenIOC->CybOX transform and a set of CybOX language =
Python bindings. Recognizing that this is the first time that the formal =
language specifications will be available for review and as such will =
likely generate feedback from new stakeholders, this initial major =
version is being released as a =E2=80=9Cdraft=E2=80=9D v1.0 with the =
expectation of cycles of new feedback and revision before a =
=E2=80=9Cfinal=E2=80=9D v1.0 is released.

The CybOX v1.0 (Draft) XML schemas include a significant number of =
changes from v0.7 to improve:

=C2=B7       Clarity, documentation, and descriptive formality for =
reference and implementation by other standards and users.

=C2=B7       Consistency, simplicity, and efficiency.

=C2=B7       Alignment (as appropriate) to existing normative =
references.

=C2=B7       Expressiveness of the schema to better support the broad =
set of use cases it targets (malware characterization, indicator and =
incident data sharing, event management, etc.) including the addition of =
an initial set of network-related defined objects.

Summary of changes from CybOX_v0.7 to CybOX_v1.0_(Draft):

=C2=B7        Refinement of namespaces and schema locations for better =
effectiveness and flexibility going forward.

=C2=B7        Normalized all content according to an established set of =
naming conventions.

=C2=B7        Fully annotated all language items (types, attributes, =
elements, etc.).

=C2=B7        Moved several commonly leveraged types out of the core =
schema and into common_types.

=C2=B7        Achieved full typing of entire schema structure such that =
all attributes and elements are definitively typed.

=C2=B7        Changed all identifiers from ID and IDREF types to be =
QNames enabling globally unique identifiers and flexibility for =
domain-specific users of CybOX to define their own identifier syntax =
locally.

=C2=B7        Reordered attributes and elements in numerous types to =
better reflect common usage and priority.

=C2=B7        Added major_version and minor_version attributes for core =
schema.

=C2=B7        Added capability to characterize source of overall =
observable package data and for individual observables.

=C2=B7        Modified the logical composition structure such that any =
such compositions are now contained within a Observable_Composition =
element providing improved simplicity and modularity.

=C2=B7        Removed the Delta element from ObservableType and =
relocated the appropriate portions (Change, Trend, and Frequency) to =
appropriate locations under Stateful_Measure and Event.

=C2=B7        Added a Domain_Specific_Object_Attributes field to Object =
utilizing an abstract type that will allow domain-specific use cases to =
add in their own domain-specific attributes for Objects.

=C2=B7        Added a Tool-Specific_Data field to ToolInformationType =
utilizing an abstract type that will allow addition of tool-specific =
data.

=C2=B7        Added an Indicators field to MeasureSourceType utilizing =
an abstract type that will allow characterizing differing formats or =
standards of indicators that may have led to the identification of the =
observable data.

=C2=B7        Enhanced the Hash structure to capture full fuzzy hashes =
in addition to simple hashes

=C2=B7        Added a new ExtractedFeaturesType that can be used to =
adorn differing objects (e.g., files, memory, etc.) to capture extracted =
strings, imports, functions and code snippets

=C2=B7        Added a ByteRunsType to enable capture of byte runs within =
various objects.

=C2=B7        Added object_reference attribute to DefinedObjectType to =
better support referencing of independently defined Objects from within =
another Object definition.

=C2=B7        Added a generic DataSegmentType to provide a relatively =
abstract way of characterizing data segments that may be =
written/read/transmitted or otherwise utilized in actions or defined in =
objects.

=C2=B7        Added several new defined object schemas (API, Code, =
Device, DNS_Record, Network_Flow, Network_Packet, Network_Route_Entry, =
Network_Subnet, Unix_Network_Route_Entry) including an initial set of =
network-centric defined objects.

=C2=B7        Modified every defined object schema with added =
annotations as well as minor and in some cases substantive changes to =
fix errors, improve consistency and alignment with existing normative =
references, and to improve expressiveness in support of the targeted use =
cases.

Detailed changes from CybOX_v0.7 to CybOX_v1.0_(Draft):

The level of changes within v1.0 (Draft) in the core schema, =
common_types and the defined object schemas is too great to list every =
change in these release notes. Detailed difference reports are available =
for each individual schema at: =
 =
http://cybox.mitre.org/XMLSchema/release_notes/cybox_v1.0(draft)_diff_rep=
orts.zip

=20

=20

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

Sean Barnum

Cyber Security Principal

The MITRE Corporation

Email: sbarnum@mitre.org

=20

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

=20


------=_NextPart_001_003F_01CD1CAB.18E81260
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable


Mike,
 
Just to clarify, all of our discussion so far about =E2=80=9CData =
Flow=E2=80=9D and netflow were all in regards to an enumeration called =
EventTypeEnum that simply lets you tag a cyber observable event with a =
type label. It is metadata for an event =
description.
The only object we have been talking about in any detail so far was =
the Network_Flow object. These two topics are totally independent of =
each other. There is no Data_Flow object.
The abstraction overlap we have been discussing is only in the =
metadata tag applied to an event to characterize what type/class of =
event it is.
 
The defined objects themselves (including Network_Flow) have been =
designed to avoid, as much as possible, overlap of the type you =
describe.
The approach we have taken is that where there is common structure =
and meaning relevant to multiple different types of objects, the =
structure for that commonality is broken out into its own object (e.g. =
Address, URI, Port, Account, Process, etc.).
Content based on this common object structure can be embedded within =
a leveraging object (via direct use of the object type) if the content =
is directly relevant only within the context of that object or as an =
independent object and associated to any number of other objects to =
which it is relevant utilizing relationships.
We make no guarantees that we have managed to implement this approach =
flawlessly but we believe that it yields a good balance of consistency, =
efficiency and flexibility. It also allows easy modular use of only what =
is relevant within a given context and enables extension and evolution =
to easily occur in a localized fashion rather than having to extend and =
modify one monolithic structure standard.
 
Does that make sense?
 
sean
 
From:=
 =
Michael Hammer [mailto:michael.hammer@yaanatech.com] 
Sent: =
Tuesday, April 17, 2012 9:18 AM
To: Barnum, Sean D.; =
osantos@cisco.com; Thomas.Millar@hq.dhs.gov; =
lnunez@c3isecurity.com
Cc: idxwg@nicwg.org; mile@ietf.org; =
dallendoug@gmail.com; sacm@ietf.org; =
m-terada@ipa.go.jp
Subject: RE: [mile] [sacm] CybOX v1.0 =
(Draft) is now released and live onthe =
website
 
Sean,
 
Does the overlap between the various objects present a =
problem?
 
If there are one or more objects that could carry the same data, then =
human nature means that probability-wise someone will choose data flow =
instead of Netflow.
That is the underlying principle in Murphy=E2=80=99s Law, where you =
try to design it so that there is only one way to do it, and thus =
private Murphy won=E2=80=99t do it the =E2=80=9Cwrong=E2=80=9D =
way.
 
Just wondering if these should be mutually exclusive sets.  And =
designed as such.
Might improve interoperability.  (And avoid discussions like =
this in future.)  J
 
Mike
 
 
From:=
 =
mile-bounces@ietf.org [mailto:mile-bounces@ietf.=
org] On Behalf Of Barnum, Sean D.
Sent: Tuesday, =
April 17, 2012 1:10 AM
To: Omar Santos (osantos); Millar, =
Thomas; lnunez@c3isecurity.com
C=
c: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; m-terada@ipa.go.jp
Subject:<=
/b> Re: [mile] [sacm] CybOX v1.0 (Draft) is now released and live onthe =
website
 
=E2=80=9Cupper layer=E2=80=9D? Yes, as in higher =
abstraction.
Just =E2=80=9Cprotocols=E2=80=9D? No.
 
You guys have been looking at this through the lens of network flow =
which if fine for thinking about that perspective but it is important to =
also realize that the EventTypeEnum and its =E2=80=9CData Flow=E2=80=9D =
value go far beyond network-related scope.
It is about a lot of other types of potential data flows (as I just =
outlined in a response to Tom) that have nothing to do with network =
flow.
 
Thanks for your response though. This is the kind of discussions that =
we hope to have a lot more of among the various supported =
communities.
 
 
BTW, you may have noticed that the Network_Flow object within CybOX =
v1.0 (Draft) supports expression of netflow within several of the most =
common formats including Netflow9 (as well as IPFIX as Luis pointed out, =
Netflow5 and SiLK as well as bi-directional flow in YAF). The common =
5-tuple or 7-tuple (you describe) (in our case it is an 8-tuple as we =
broke the router interface out into both ingress and egress J) shared by pretty much all of the netflow approaches has been broken =
out into a shared Network_Flow_Label structure. The various =
context-dependent portions of the independent approaches are then =
captured within optional structures dedicated to each of them. We hope =
that eventually the community can work to come together towards a single =
overall common expressive structure for netflow that meets the needs of =
all. We hope that CybOX and its use can even help that sort of =
maturation and normalization. But since no such universal structure =
exists today, we decided to enable optional expression of the most =
common individual formats within a single netflow object to serve the =
large majority of relevant users, maintain flexibility and enable =
discussions and analysis of netflow within a common =
package.
We look forward to continuing discussions with the community to =
validate or invalidate this approach and to refine and mature going =
forward.
 
Sean 
 
From:=
 =
Omar Santos (osantos) [mailto:osantos@cisco.com]=
 
Sent: Monday, April 16, 2012 11:57 PM
To: Millar, =
Thomas; Barnum, Sean D.; lnunez@c3isecurity.com
C=
c: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; m-terada@ipa.go.jp
Subject:<=
/b> RE: [sacm] [mile] CybOX v1.0 (Draft) is now released and live onthe =
website
 
I believe that what Sean is saying is that =E2=80=9Cdata =
flow=E2=80=9D is just a value that is meant for upper layer protocols. =
But, you have a good point. Traditionally, a =E2=80=9Cflow=E2=80=9D in =
=E2=80=9CNetflow=E2=80=9D is based on a set of 5 and up to 7 IP packet =
attributes:
 
- IP source address
- IP destination address
- Source port
- Destination port
- Layer 3 protocol type
- Class of Service
- Router or switch interface
 
Although, there is a lot more support with Netflow version =
9:
http://www.=
cisco.com/en/US/technologies/tk648/tk362/technologies_white_paper09186a00=
800a3db9_ps6601_Products_White_Paper.html
 
 
 
Regards,

Omar 
 
From:=
 =
Millar, Thomas [mailto:Thomas.Millar@h=
q.dhs.gov] 
Sent: Monday, April 16, 2012 11:46 =
PM
To: sbarnum@mitre.org; Omar Santos =
(osantos); lnunez@c3isecurity.com
C=
c: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; m-terada@ipa.go.jp
Subject:<=
/b> Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live onthe =
website
 
If "data flow" is a euphemism for "netflow" is =
there any reason not to call it that?

Tom Millar 
http://www.us-cert.gov/ =

------------------ 
Missit me Rubus fruticosus: 
202 631 1915 =


 
From<=
/b>: =
Barnum, Sean D. [mailto:sbarnum@mitre.org]=
 
Sent: Monday, April 16, 2012 11:29 PM
To: Omar =
Santos (osantos) <osantos@cisco.com>; Luis Nunez =
<lnunez@c3isecurity.com> =

Cc: idxwg@nicwg.org =
<idxwg@nicwg.org>; mile@ietf.org <mile@ietf.org>; dallendoug@gmail.com <dallendoug@gmail.com>; sacm@ietf.org <sacm@ietf.org>; m-terada@ipa.go.jp <m-terada@ipa.go.jp> =

Subject: Re: [sacm] [mile] CybOX v1.0 (Draft) is now released =
and live onthe website 
 
Thanks Omar.
 
To answer your question, first let me point out to other readers that =
the two entries that Omar is quoting here exist as values in an =
enumeration called EventTypeEnum which as its name implies contains a =
list of different labels for grouping types (or classes) of events to be =
used as low-granularity buckets for characterizing and classifying =
events.
Other entries in this enumeration include things like =E2=80=9CFile =
Ops (CRUD)=E2=80=9D, =E2=80=9CProcess Mgt=E2=80=9D, =
=E2=80=9CAuthorization (ACL)=E2=80=9D, etc.
 
The =E2=80=9CPacket Traffic=E2=80=9D value is intended to =
characterize events dealing with network packet traffic as its name =
implies.
The =E2=80=9CData Flow=E2=80=9D value is intended to characterize =
events dealing with forms of data flow at a higher level of abstraction =
than just packet traffic. The relationship between these two values =
could be viewed as =E2=80=9CPacket Traffic=E2=80=9D being a more =
detailed form of =E2=80=9CData Flow=E2=80=9D just as the values =
=E2=80=9CApp Layer Traffic=E2=80=9D and =E2=80=9CHTTP Layer =
Traffic=E2=80=9D, also in this enumeration, could be other levels in =
this same abstraction stack.
The idea behind the varying levels of abstraction is to leave =
 buckets large enough to capture a wide variety of potential event =
types (e.g. data flow events other than obvious things like packet =
traffic) but also enable the use of smaller more specific buckets when =
they are appropriate and commonly used.
 
Does this make sense? 
 
sean
 
From:=
 =
Omar Santos (osantos) [mailto:osantos@cisco.com]=
 
Sent: Monday, April 16, 2012 8:17 PM
To: Luis =
Nunez; Barnum, Sean D.
Cc: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; m-terada@ipa.go.jp
Subject:<=
/b> RE: [sacm] [mile] CybOX v1.0 (Draft) is now released and live onthe =
website
 
I echo Luis=E2=80=99 comments. It is good to see the inclusion of =
network objects. Quick question to the team related to your netflow =
comment.
 
I am looking at:
=
http://cybox.mitre.org/XMLSchema/cybox_core_v1.0%28draft%29.xsd<=
/o:p>
 
=E2=80=A6 and it looks that we renamed it to =E2=80=9CData =
Flow=E2=80=9D?
 
<xs:enumeration =
value=3D"Data Flow">
   =
<xs:annotation>
        =
<xs:documentation>Specifies the class of events dealing with data =
flow.</xs:documentation>
   =
</xs:annotation>
</xs:enumeration>
 
 
What is the difference between that and =E2=80=9CPacket =
Traffic=E2=80=9D?
 
<xs:enumeration value=3D"Packet =
Traffic">
   =
<xs:annotation>
     =
<xs:documentation>Specifies the class of events dealing with =
packet traffic.</xs:documentation>
   =
</xs:annotation>
</xs:enumeration>
 
 
 
 
Regards,

Omar Santos
Incident Manager, =
PSIRT
Security Research and Operations
Cisco Systems, =
Inc.
Email: os@cisco.com
Phone: +1 919 392 =
8635
PGP Key: 0x3AF27EDC

Cisco.com - http://www.cisco.com
Cisco Security =
Advisories and Notices - http://www.cisco.com/go/psirt<=
br>
This email may contain confidential and privileged material for =
the sole
use of the intended recipient. Any review, use, distribution =
or
disclosure by others is strictly prohibited. If you are not the =
intended
recipient (or authorized to receive for the recipient), =
please contact
the sender by reply email and delete all copies of =
this message.

For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html=

 
From:=
 =
sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.=
org] On Behalf Of Luis Nunez
Sent: Monday, April =
16, 2012 6:44 PM
To: Barnum, Sean D.
Cc: idxwg@nicwg.org; mile@ietf.org; Doug Wilson (dallendoug@gmail.com); sacm@ietf.org; IPA-Masato Terada (m-terada@ipa.go.jp)
Subject:=
 Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live onthe =
website
 
I like the inclusion of the network-centric =
objects.  IPFIX (netflow)  will add an additional perspective =
from an incident information sharing standpoint. =
 
 
-ln
 
On Apr 16, 2012, at 4:04 =
PM, Barnum, Sean D. wrote:
 
Hey =
everyone,
 =

I just =
wanted to let you all know that CybOX v1.0 (Draft) content is now live =
on the website. http://cybox.mitre.org
The =
release notes are provided inline =
below.
The key =
items of note are:
=C2=B7        The =
release of two formal specifications for the CybOX language (one for the =
core language and one for the defined =
objects)
=C2=B7        The XML =
Schema has gone through extensive improvements for expressiveness, =
clarity, consistency, efficiency, alignment to existing normative =
references and documentation.
=C2=B7        This =
release includes an initial set of language utilities: a draft Snort =
-> CybOX transform, a draft OpenIOC -> CybOX transform, and a set =
of Python bindings for the CybOX language.
=C2=B7        The =
website now includes a small set of content examples. This set will grow =
going forward.
This =
release involved a lot of hard work from a diverse group of people. =
Thank you all for your contributions and effort. We could not have done =
it without you.
We look =
forward to everyone=E2=80=99s feedback and collaboration as we continue =
to improve and mature the CybOX =
language.
 =

Sean =
Barnum
 =

 =

 =

CybOX v1.0 (Draft) Release =
Notes
The Version 1.0 (Draft) release of Cyber =
Observable eXpression (CybOX=E2=84=A2) is intended as a draft release of an initial major version of =
the CybOX Language that could be utilized for practical operational use =
and integration into other standards efforts. This release consists of =
three primary components: a pair of formal language specifications for =
the core language content and defined objects content, a set of language =
implementation XML schemas (core, common_types, and ~70 defined object =
schemas), and a small initial set of language utilities including an =
initial draft Snort->CybOX transform, an initial draft =
OpenIOC->CybOX transform and a set of CybOX language Python bindings. =
Recognizing that this is the first time that the formal language =
specifications will be available for review and as such will likely =
generate feedback from new stakeholders, this initial major version is =
being released as a =E2=80=9Cdraft=E2=80=9D v1.0 with the expectation of =
cycles of new feedback and revision before a =E2=80=9Cfinal=E2=80=9D =
v1.0 is released.=

The CybOX v1.0 (Draft) XML schemas include a =
significant number of changes from v0.7 to improve:=

=C2=B7       Clarity, =
documentation, and descriptive formality for reference and =
implementation by other standards and users.=

=C2=B7       Consistency, =
simplicity, and efficiency.=

=C2=B7       Alignment (as =
appropriate) to existing normative references.=

=C2=B7       Expressiveness of the =
schema to better support the broad set of use cases it targets (malware =
characterization, indicator and incident data sharing, event management, =
etc.) including the addition of an initial set of network-related =
defined objects.=

Summary =
of changes from CybOX_v0.7 to CybOX_v1.0_(Draft):=

=C2=B7        =
Refinement of namespaces and schema =
locations for better effectiveness and flexibility going forward.=

=C2=B7        =
Normalized all content according to an =
established set of naming conventions.=

=C2=B7        =
Fully annotated all language items =
(types, attributes, elements, etc.).=

=C2=B7        =
Moved several commonly leveraged types =
out of the core schema and into common_types.=

=C2=B7        =
Achieved full typing of entire schema =
structure such that all attributes and elements are definitively =
typed.=

=C2=B7        =
Changed all identifiers from ID and IDREF =
types to be QNames enabling globally unique identifiers and flexibility =
for domain-specific users of CybOX to define their own identifier syntax =
locally.=

=C2=B7        =
Reordered attributes and elements in =
numerous types to better reflect common usage and priority.=

=C2=B7        =
Added major_version and minor_version =
attributes for core schema.=

=C2=B7        =
Added capability to characterize source =
of overall observable package data and for individual observables.=

=C2=B7        =
Modified the logical composition =
structure such that any such compositions are now contained within a =
Observable_Composition element providing improved simplicity and =
modularity.=

=C2=B7        =
Removed the Delta element from =
ObservableType and relocated the appropriate portions (Change, Trend, =
and Frequency) to appropriate locations under Stateful_Measure and =
Event.=

=C2=B7        =
Added a Domain_Specific_Object_Attributes =
field to Object utilizing an abstract type that will allow =
domain-specific use cases to add in their own domain-specific attributes =
for Objects.=

=C2=B7        =
Added a Tool-Specific_Data field to =
ToolInformationType utilizing an abstract type that will allow addition =
of tool-specific data.=

=C2=B7        =
Added an Indicators field to =
MeasureSourceType utilizing an abstract type that will allow =
characterizing differing formats or standards of indicators that may =
have led to the identification of the observable data.=

=C2=B7        =
Enhanced the Hash structure to capture =
full fuzzy hashes in addition to simple hashes=

=C2=B7        =
Added a new ExtractedFeaturesType that =
can be used to adorn differing objects (e.g., files, memory, etc.) to =
capture extracted strings, imports, functions and code snippets=

=C2=B7        =
Added a ByteRunsType to enable capture of =
byte runs within various objects.=

=C2=B7        =
Added object_reference attribute to =
DefinedObjectType to better support referencing of independently defined =
Objects from within another Object definition.=

=C2=B7        =
Added a generic DataSegmentType to =
provide a relatively abstract way of characterizing data segments that =
may be written/read/transmitted or otherwise utilized in actions or =
defined in objects.=

=C2=B7        Added several new =
defined object schemas (API, Code, Device, DNS_Record, Network_Flow, =
Network_Packet, Network_Route_Entry, Network_Subnet, =
Unix_Network_Route_Entry) including an initial set of network-centric =
defined objects.
=C2=B7        =
Modified every defined object schema with =
added annotations as well as minor and in some cases substantive changes =
to fix errors, improve consistency and alignment with existing normative =
references, and to improve expressiveness in support of the targeted use =
cases.=

Detailed changes from CybOX_v0.7 to =
CybOX_v1.0_(Draft):=

The level of changes within v1.0 (Draft) in =
the core schema, common_types and the defined object schemas is too =
great to list every change in these release notes. Detailed difference =
reports are available for each individual schema at:http://cybox.mitre.org/XMLSchema/release_notes/cybox_v1.0=
(draft)_diff_reports.zip
 =

 =

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

Sean Barnum=

Cyber Security Principal=

The MITRE Corporation=

 =

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

------=_NextPart_001_003F_01CD1CAB.18E81260--

------=_NextPart_000_003E_01CD1CAB.18E81260
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIYNDCCBS0w
ggMVoAMCAQICEEw6UhQhT9OgRBVHf7KQ+1AwDQYJKoZIhvcNAQELBQAwKTEnMCUGA1UEAxMeTUlU
UkUgQ29ycG9yYXRpb24gUEUgUm9vdCBDQS0xMB4XDTExMDQyNjE5NDU0NVoXDTIxMDQyNjE5NDgy
MlowKTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUEUgUm9vdCBDQS0xMIICIjANBgkqhkiG
9w0BAQEFAAOCAg8AMIICCgKCAgEAtp8hR0hRq3im+Alwfb5ZHGP5k2OSY2TlVHYHIMUDH3MfW7b6
8lB3j3MwAMsxGK1ke/t6O4K0t9wRH4QDgOQ1CthmOGZW7xiN81h0vP1Yf14SNugUa7ZvH9KP3iXs
y8QnOHal1bKf0Pa9KXib58qUuwfaZSCTW5P2ekqd8z4TETvfBWvPgDxyxnVsiAO6yL9WaRpMiSVM
hYLWy3KRuU/gue0bVEi+qdg+hENh1NSNXpoqseS262nq5cx5wybR/PF0YstQ9NNlYDM5cLECKYHH
zD6cXKJozuFXriswlE8rdna7VaxyZrfgC0ueEIY/tsj/65IyUhyPBwO0ZpW+Ls9Cd4Y+ERSu5mR5
Fd8w42eVzuosmk3s3AxrKC+Z4tXYkjaiWUduIegAiST1vJBwkS53vR+zrBX3Ep56l7MFVvW/GcsZ
9wUT2HG65JOeiVc2YzCEqLgQ3ZCBHn09oBag2lnMac+E2sKm9aKL3xzHs6cyD8qCJK9O8QLCqo3C
mzASlOwtTFiLYgpPW/MSmgYOt9JrwHAzk97DHFKTFttjrXGMmhMVzadt1EjMn1Wv8t5WLBI0qSoX
/MYi2CaeiDsEiWRu9Nmpu3pmi8m7tIR9csdbAVPks2soNMWOopGEpFQSDvU1+m77v2jIKQKYxYmN
2zUOJ4TJFL1osnZ/71MmLCDVd+ECAwEAAaNRME8wCwYDVR0PBAQDAgGGMA8GA1UdEwEB/wQFMAMB
Af8wHQYDVR0OBBYEFFuHfZ/+bL4C6fPgKTqKVCUsnzgvMBAGCSsGAQQBgjcVAQQDAgEAMA0GCSqG
SIb3DQEBCwUAA4ICAQAy78sXsP/eqHH8/uOYyxQ6TBDhkCBxNoy8MF2c9UDns5ADL1qyxPAlpDBs
L+2h1Zzt3FvPjg0SoRE/9juyG1qxMzhlv0jdQx12tESdo3uBb61b1uuc4H/VxCJWDI4KZL/B53EI
8HGPjUBdLADgOmG99uffm5uarSkjtIX//Bz3U6QfzTPlVWFi4SmzRI2mp16GQ8RPuJ/WMloaAn8X
H6EjS2oLjGZC8Pw8/C46W48NvZ1JZTrZvYZr7GmuvmplYK68SZv/T5Su+FlLRTy9uNXQLHtm6jKv
nDH2yB66zTwfaDpnjILnrC2O7ANRVZc0KywiKiW3nB7Joq74/XVuMI1PiSByt2Qu+RIS/WAI5wMi
bTmwSiBxQZqvuth+dXoakJyOP2Wg5jvL55v9RLZhDqMtRI5ovnOFvTgNJQqNPSekGtA+m6Ctl/vh
kSg65FFCMhaSkn7vY2Il+R8HouWJN8wTaudeexnyHcD+Mlt8QaB5CErpDjeeGZfQ0FcYm+6TtlMz
Dw5eFhT/J6QrABCxfgLkVFHurMcQD4JkmXXkq5bP+GNkY0Uy2LMbw/UD94OEV1LpfAqUkT+mu5Yb
vxg+elFtsad+Ix8owW372xynIADh9q1bHm+j1OHPJmGALWK9miRpC4t3isfu3ZB0QpI/e2Po6MED
393Jb0YbzrcElFv6ZDCCBhYwggP+oAMCAQICChrDbcgAAgAAN/wwDQYJKoZIhvcNAQEFBQAwUDET
MBEGCgmSJomT8ixkARkWA09SRzEVMBMGCgmSJomT8ixkARkWBU1JVFJFMSIwIAYDVQQDExlNSVRS
RSBDb3Jwb3JhdGlvbiBQRSBDQS0xMB4XDTEyMDMxMjE1MTgyN1oXDTE1MDMxMjE1MTgyN1owSjEL
MAkGA1UEBhMCVVMxDjAMBgNVBAoTBU1JVFJFMQ8wDQYDVQQLEwZQZW9wbGUxGjAYBgNVBAMTEUJh
cm51bS5TZWFuLjMxNTQzMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA9/I6RU7OcouL
6lcEJMAg8G3myNbQu84QnflS8p3PWOjgC6P50RDqGX5UxelDqMQPN5IsNYRXVY9/b7yN/RSH4goI
JfYKMitndKuCKz1q38Nh0YycEm5x2t/IN/60b01T1uOmhZfptLDoDzj0UQZwMQ19mhM/ldsrC8bR
GGuHXdQVaSyXygfhzNhqC06vZo5fvCBUJ6z7JtVrfRTHdudg19JYK+gds9p+Lvp/DOEXQmgpfpMl
jfNKMnrG+kPMMngrIJUsF5lcbhHuc5mO+O8eR8FxM2KF7gfKVmUmZxs7Y6uLenVJVEmllP0XgUu1
sv3bClFgUo5x5Aq6rXshtHuVuQIDAQABo4IB9jCCAfIwKAYDVR0lBCEwHwYIKwYBBQUHAwQGCSsG
AQQBcwIBBwYIKwYBBQUHAwIwHQYDVR0OBBYEFDvU1Ph/OVxGkxRmwvRx1TBf5PKqMA4GA1UdDwEB
/wQEAwIGwDAcBgNVHREEFTATgRFzYmFybnVtQG1pdHJlLm9yZzAfBgNVHSMEGDAWgBRpZyAh1EjB
0BsGbvMIKOI6gn1BMTBJBgNVHR8EQjBAMD6gPKA6hjhodHRwOi8vcGtpLm1pdHJlLm9yZy9NSVRS
RSUyMENvcnBvcmF0aW9uJTIwUEUlMjBDQS0xLmNybDB/BggrBgEFBQcBAQRzMHEwRwYIKwYBBQUH
MAKGO2h0dHA6Ly9wa2kubWl0cmUub3JnL01JVFJFJTIwQ29ycG9yYXRpb24lMjBQRSUyMENBLTEo
MikuY3J0MCYGCCsGAQUFBzABhhpodHRwOi8vb2NzcC5taXRyZS5vcmcvb2NzcDA+BgkrBgEEAYI3
FQcEMTAvBicrBgEEAYI3FQiDrqwjho6WV4GNiT2CpKsShb6uAYE2g9KXfYeg+0kCAWQCAQcwFgYD
VR0gBA8wDTALBgkrBgEEAXMCAQgwNAYJKwYBBAGCNxUKBCcwJTAKBggrBgEFBQcDBDALBgkrBgEE
AXMCAQcwCgYIKwYBBQUHAwIwDQYJKoZIhvcNAQEFBQADggIBAC2wqKo7QWQxIqnEKRznPrAQ5vQ9
X5JhB5keH8KMWu1W5n1RuSZH+3TYp4xccdYh+rV5b5+cJcWEYhtYpZriWm4kMHPaB6gKO9rbVfF9
R8Wp8sXvCKogbNhdkZwvXW4QymB1ASlMzDI1cCV8mzYgbIhWaCbV1zZBUVgOGa4LZIgdbdmgo5r/
O2gmnSftTYiE/tQ+DBs/25Bw/jC5HOiMXJqr+JctzJTqpEVLa7GKHnXWGuzGEPYkKBplxIyhz3Mv
qc/yuKM7tZzAr8Qn5qf7VI9O2xp56QLjT2+mySOUR6Vml860FMpjjgZNMxAqOJt7OgY0PoUU9d18
yw1wiKSt0LUQoMcVvp7FifBjtBCG1sB/VOzxNvcNm6lO6EO23pvcjt6+WCG1X3pgnZ5UEohsM3c0
oLzYiuSYeVf85IO2yh9fWLWw2RGkf2szck1Xg0DsAQ54/YlZYyehELh43KbS3lpnTt8UlO7C0TMT
7JQwz4fTQg1a0e9rRPFnNDUG2fS2k3tz9IYILDB3F8uiZzzXptEzaYqzIqe5CK8ZGJQcw+w/CBen
6i+MV/y7yJmhio43Y1x9hIqoynqoSMV3CKYCoOwCvFUAGsNllDpExsQZoXrdd5gcuglqbh3t8wOM
jtXDSQllQ/hXDZJf8rnH0wGx3K+WA+LKNvKqNCw9spEtsfG0MIIGYjCCBEqgAwIBAgIKFJcW0gAA
AAAABDANBgkqhkiG9w0BAQsFADApMScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQRSBSb290
IENBLTEwHhcNMTEwNjE0MTc0NDQ0WhcNMTcwNjE0MTc1NDQ0WjBQMRMwEQYKCZImiZPyLGQBGRYD
T1JHMRUwEwYKCZImiZPyLGQBGRYFTUlUUkUxIjAgBgNVBAMTGU1JVFJFIENvcnBvcmF0aW9uIFBF
IENBLTEwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDSxK9RXieqdTz4JWRkRMs/EOuF
0P0S9SbspadLJkx/LDDnaAwmAnqfqm1n7/p82oVjy1yCye3SZu4Yp7fmDIAtWbkHvYOfxHkRv1ho
/fhaNN0YRkd65oJJz2ngEbNZxdIiCoialQfX/iWU7ApQ+ovKbFV60v5E0p2mPncs20NYRfsaetdh
nBZbFD9flDcXwJqSvGGGBfm7ifFCR1LrtEcNKjMwf7YEWZO0Vk3ZyhVq+k7JNLEbKv0OfBz8DU8G
iGU+j88QlrgGW8PLkwNk7nsS/DJp8aLudTuVqIE2CA9mqn5QjU/EZYNHGzSfCr+/usUmbojyVSJu
khhrAXspRAMz+Cia3yi3q3w8TnAljXWN1dhx1iuUv5GxyzMjfqK1tMuCUU2XzGNNqoVa1mqolBiy
DTCOr9d/IC0YHYMBSpQ+xi0x9zjXKt4FmQmkEAZgF4hsZZqcJYL/iCQiwiz8fEyVPZuvoWvdEXOo
zFYCpmkT0MZCJwyIux0Z6vJp6VLtN/6rZgc2y54HlTrp3ifazmpsfrk3NdHxlZTZug9kjEI+vEoy
p/79nAPyTWQQ1MEP0ErCWav80/HOi0MLx/7lIUfvVOjkOFgFb+iDvR4T3RAQrnEpgTO+fc7Jyzh9
LpFDqm0slwDP4Hj9cC3IzdED5BU43PGAe+HoZ8OD/1ovVgwo/wIDAQABo4IBYzCCAV8wEAYJKwYB
BAGCNxUBBAMCAQIwIwYJKwYBBAGCNxUCBBYEFFCiOtgZb+Zdflkw5sC2y01sUQaVMB0GA1UdDgQW
BBRpZyAh1EjB0BsGbvMIKOI6gn1BMTAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTALBgNVHQ8E
BAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAfBgNVHSMEGDAWgBRbh32f/my+Aunz4Ck6ilQlLJ84LzBQ
BgNVHR8ESTBHMEWgQ6BBhj9odHRwOi8vcGtpLm1pdHJlLm9yZy9NSVRSRSUyMENvcnBvcmF0aW9u
JTIwUEUlMjBSb290JTIwQ0EtMS5jcmwwWwYIKwYBBQUHAQEETzBNMEsGCCsGAQUFBzAChj9odHRw
Oi8vcGtpLm1pdHJlLm9yZy9NSVRSRSUyMENvcnBvcmF0aW9uJTIwUEUlMjBSb290JTIwQ0EtMS5j
cnQwDQYJKoZIhvcNAQELBQADggIBAHnDPfdYKxqNOtAYXMyyel83Vs8cCDAQZhSuIB0c6GkGoEdF
rmWH9pwi42V96rCp7TvbNNKNJXbVHfJUAp+uqw663DL/sXXff9ZFxPxKOdPnpA8cKM7RBH9e437N
w3d28A7PaGbP6tXmSqhXAhYZ4U12y1U5cOf2G/phUoAAMlnVJdfmXzMazvLo2SIeixAJyCze6rHQ
TFQ/N+gAjbVuRJ+Hs8FEKVzMSwqlNoupe2ELqL4dMAKT6P08sAfxm2SrRlQvcWPYvqM/1C10bgc2
tdu+WGzRuP5Wx9Yr15KO9SW4z7fn2RVEXQgoDDno5vCIcfUPuKB5n+Kt9eBCitsgSD9yYsNUN9LE
VIvjAb8MV2LWLfge1bumo6g7QMRa4Fgifw5siGwi7V2EaJQo6UAIVvxKKFC7W4p6CkrY2ga1d7GI
Q0DPiWZOezOakJVAxL5gf+3WdNt0igKc/yLfbdHn6hCd1KPgDqkSKr8zWOZI/jiDBW957xAmaO6Q
dGQDBZrQHWpIVwQGzF5bGrqms2kq49l3t7KmBu0C/9tExqKAmlf4Y5lfQGdCbKQpAq712DVQHYuD
XmVQEAc2vlJ1C5hS3Iw9DwBWTfJ4vyB48buhBhbIhPiFta5OizXlKcsIi99ikA1yiZx/DBtjaw4J
U6qJzWUFB2ecyGCNPtNbYjURA0A9MIIGfzCCBGegAwIBAgIKGsNq2wACAAA3+jANBgkqhkiG9w0B
AQUFADBQMRMwEQYKCZImiZPyLGQBGRYDT1JHMRUwEwYKCZImiZPyLGQBGRYFTUlUUkUxIjAgBgNV
BAMTGU1JVFJFIENvcnBvcmF0aW9uIFBFIENBLTEwHhcNMTIwMzEyMTUxODI3WhcNMTUwMzEyMTUx
ODI3WjBKMQswCQYDVQQGEwJVUzEOMAwGA1UEChMFTUlUUkUxDzANBgNVBAsTBlBlb3BsZTEaMBgG
A1UEAxMRQmFybnVtLlNlYW4uMzE1NDMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCW
InZvCSslmSfSyhTVVSqnokCDajlsCNZHfUlkwkV1++2O71BYvMpjFHWR2XFIx963Hl63lFZzzVci
OjIwLb1c/0YXhFfUdAvrbpjlu+ttlO05OEUW0h+5HO+qaebJPamxA00w0bokquRcPxUvwa3jiyL0
WfCwE3+/b5PCOW2xh7FXFKv262FnKIwxnQGXqkiXRP5D/SmdtcZSzxHkDThrhaiHPhJJhZ4XxwBk
aGcAlMg8YH6uxshXm8e6c7XUu7gB5p+XThS0dqXujpQp/UQDp5t079+UrDcrpjfDBXIt9qCzLn26
uV5a4cD4xRKwA32f1cXFtiKXM0wYgUM3fEPDAgMBAAGjggJfMIICWzATBgNVHSUEDDAKBggrBgEF
BQcDBDCBlAYJKoZIhvcNAQkPBIGGMIGDMA4GCCqGSIb3DQMCAgIAgDAOBggqhkiG9w0DBAICAIAw
BwYFKw4DAgcwCgYIKoZIhvcNAwcwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBLTALBglghkgBZQME
ARYwCwYJYIZIAWUDBAEZMAsGCWCGSAFlAwQBAjALBglghkgBZQMEAQUwHQYDVR0OBBYEFIrbKa+E
Rxo2/Sth2C6jZqZqvRE7MA4GA1UdDwEB/wQEAwIFIDAcBgNVHREEFTATgRFzYmFybnVtQG1pdHJl
Lm9yZzAfBgNVHSMEGDAWgBRpZyAh1EjB0BsGbvMIKOI6gn1BMTBJBgNVHR8EQjBAMD6gPKA6hjho
dHRwOi8vcGtpLm1pdHJlLm9yZy9NSVRSRSUyMENvcnBvcmF0aW9uJTIwUEUlMjBDQS0xLmNybDB/
BggrBgEFBQcBAQRzMHEwRwYIKwYBBQUHMAKGO2h0dHA6Ly9wa2kubWl0cmUub3JnL01JVFJFJTIw
Q29ycG9yYXRpb24lMjBQRSUyMENBLTEoMikuY3J0MCYGCCsGAQUFBzABhhpodHRwOi8vb2NzcC5t
aXRyZS5vcmcvb2NzcDA+BgkrBgEEAYI3FQcEMTAvBicrBgEEAYI3FQiDrqwjho6WV4GNiT2CpKsS
hb6uAYE2hquSaISo7EUCAWQCAQ8wFgYDVR0gBA8wDTALBgkrBgEEAXMCAQgwGwYJKwYBBAGCNxUK
BA4wDDAKBggrBgEFBQcDBDANBgkqhkiG9w0BAQUFAAOCAgEAGmmL43yA+J5lEockM1cxSoyxfSES
HUGLVJyrhObbdFD4yO3jf0R4lHLuJlhp1486d9LRZAyzAnl9q8Zf3Tx1rl1kEd3pw0wMuO+ATscc
rArEW/rJxjz6zTrNO3PFkFuOEdmKpHaRiFpuSX602INiBEBPluei3uZlWxHW9VqC7hz2diQpOlzS
jtPMbL3o7ACjWaq7sQ0xB4rZ6oWyqOZEfHWQA1b7nFgL4nEbmEHNdU4jAjcxkROku4O04205kb5n
Loveoz3TSQNt8zalFayZAjt+JEcKuG1f5cyhYI6QwvkS/3M+CjJezuNaSmno29Lm+ToZnwUm4nIB
YkBx4r9ZDU2W8029tr5og00A5MGo1LK+unWtHBa7zuPblfSiYgXIHWU+OKrSFaA935Yb4fLXFe9S
BmApBr1gohHYos1hct5q90WPufSKIQ9WT+vJYXvW3FpseO4ZLKVnJsO7gVoQEEnWJUwyABBPQrii
F0gh++ApKZJROTuR36PsEEx4duI6U4VXMCiIcnEjvNR8Mt5Q/Vp4W4Mp5fCv+QzYkqq9EWD7QuUW
Yul6R8Hf7ZTxbUk0NfJgu8escLrgQSwMdP/kE/09vJAAslQBkNnIS7iIhWt4l5XQJBrJc+6popRE
R8ykWf25e4CliaUgbAl1tBQKivQ3tlX99WykI2XK3sTk9nsxggMjMIIDHwIBATBeMFAxEzARBgoJ
kiaJk/IsZAEZFgNPUkcxFTATBgoJkiaJk/IsZAEZFgVNSVRSRTEiMCAGA1UEAxMZTUlUUkUgQ29y
cG9yYXRpb24gUEUgQ0EtMQIKGsNtyAACAAA3/DAJBgUrDgMCGgUAoIIBmjAYBgkqhkiG9w0BCQMx
CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjA0MTcxOTAyMjRaMCMGCSqGSIb3DQEJBDEW
BBSETqhvdjq0Lmg5AqxlbOVlHGuAQDBbBgkqhkiG9w0BCQ8xTjBMMAoGCCqGSIb3DQMHMA4GCCqG
SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMC
GjBtBgkrBgEEAYI3EAQxYDBeMFAxEzARBgoJkiaJk/IsZAEZFgNPUkcxFTATBgoJkiaJk/IsZAEZ
FgVNSVRSRTEiMCAGA1UEAxMZTUlUUkUgQ29ycG9yYXRpb24gUEUgQ0EtMQIKGsNq2wACAAA3+jBv
BgsqhkiG9w0BCRACCzFgoF4wUDETMBEGCgmSJomT8ixkARkWA09SRzEVMBMGCgmSJomT8ixkARkW
BU1JVFJFMSIwIAYDVQQDExlNSVRSRSBDb3Jwb3JhdGlvbiBQRSBDQS0xAgoaw2rbAAIAADf6MA0G
CSqGSIb3DQEBAQUABIIBAHTascEWL/C70gb9NVZtM5TeerT9f/HSMKuHM2b7AeWbS0t58u6VSG4z
8tIf+O7P1rXGWgPKAemrgSUy4Ulg9pIr+L8qwKSC46n7fk8ZR0MCC3iHfZpnP9q5Shvx2eyH1mMb
7XjMG4FcYVYcYaQsN8EU5uRvV8/xLTsr1NgvUSAoy2k6rEFuPtJOzjsavxj8g9qMYQMvcBGypaYf
Boww+EOxlnxp5HidNd/zlDL7WlzphVFY2GU8ruu81zeRu5G4SfHA/lG6feB36VKXmlsZsS6Yyw+P
gudvT4iCQWFpwhRCgW8oPAPD0Svu/5dTzhlFfAtKANIHtq5eArXQ8mEnkoMAAAAAAAA=

------=_NextPart_000_003E_01CD1CAB.18E81260--

From sbarnum@mitre.org  Tue Apr 17 13:47:32 2012
Return-Path: 
X-Original-To: sacm@ietfa.amsl.com
Delivered-To: sacm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0105321F849D; Tue, 17 Apr 2012 13:47:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level: 
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id llsKQb+kWYMC; Tue, 17 Apr 2012 13:47:26 -0700 (PDT)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 32D5121F8493; Tue, 17 Apr 2012 13:47:26 -0700 (PDT)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 9E82621B111E; Tue, 17 Apr 2012 16:47:25 -0400 (EDT)
Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 8DFE621B0DE3; Tue, 17 Apr 2012 16:47:25 -0400 (EDT)
Received: from IMCMBX03.MITRE.ORG ([169.254.3.179]) by IMCCAS04.MITRE.ORG ([129.83.29.81]) with mapi id 14.02.0283.003; Tue, 17 Apr 2012 16:47:24 -0400
From: "Barnum, Sean D." 
To: Michael Hammer , "osantos@cisco.com" , "Thomas.Millar@hq.dhs.gov" ,  "lnunez@c3isecurity.com" 
Thread-Topic: [mile] [sacm] CybOX v1.0 (Draft) is now released and live onthe website
Thread-Index: AQHNHJx9CTO+wm8DM0KsuNMXzL3C5ZafV3hggABS0QD//8vnoA==
Date: Tue, 17 Apr 2012 20:47:23 +0000
Message-ID: <7F48813B48558A4BB5CB7BB714E5B5A9173115@IMCMBX03.MITRE.ORG>
References: <7F48813B48558A4BB5CB7BB714E5B5A9171B16@IMCMBX03.MITRE.ORG> <69CE2DCD9DAC3D48B830E0723141170B02A39BD2@ZAU1UG-0308.DHSNET.DS1.DHS> <953A2E460DBE7C43AC13E30B87C5B4FF080A1C09@XMB-RCD-106.cisco.com> <7F48813B48558A4BB5CB7BB714E5B5A9171BA1@IMCMBX03.MITRE.ORG> <00C069FD01E0324C9FFCADF539701DB389FC37@EX2K10MB1.corp.yaanatech.com> <7F48813B48558A4BB5CB7BB714E5B5A9173046@IMCMBX03.MITRE.ORG> <00C069FD01E0324C9FFCADF539701DB38A0193@EX2K10MB1.corp.yaanatech.com>
In-Reply-To: <00C069FD01E0324C9FFCADF539701DB38A0193@EX2K10MB1.corp.yaanatech.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [172.31.135.134]
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00B5_01CD1CB9.BDEF3370"
MIME-Version: 1.0
X-Mailman-Approved-At: Fri, 20 Apr 2012 05:41:23 -0700
Cc: "idxwg@nicwg.org" , "mile@ietf.org" , "dallendoug@gmail.com" , "sacm@ietf.org" , "m-terada@ipa.go.jp" 
Subject: Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live onthe website
X-BeenThere: sacm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Apr 2012 20:47:32 -0000

------=_NextPart_000_00B5_01CD1CB9.BDEF3370
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_00B6_01CD1CB9.BDEF3370"


------=_NextPart_001_00B6_01CD1CB9.BDEF3370
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Mike,

=20

If you always utilized the most abstract label (Data Flow) to adorn =
events even when you knew the more specific type that they were and had =
a more specific label for them, then yes you would lose distinction.

Such misuse is always the potential downside of enabling flexibility =
through abstraction.

If you know that the event you are characterizing has to do with Packet =
Traffic and not just some form of more general data flow that does not =
have an appropriate associated event type label, then you should =
absolutely use Packet Traffic and not Data Flow. An event should only be =
tagged with an abstract label like Data Flow if there is not an =
appropriate more concrete label available.

=20

In answer to your second question, yes Data Flow definitely covers not =
only network-related events but also events that have nothing to do with =
the wire.

My response to Tom Millar that I sent at 12:52am this morning lists out =
several non-network related types of events that Data Flow could apply =
to.

=20

Please do not feel bad for asking these questions. They help you =
understand our approach, they help others understand our approach, they =
help us better understand the perspective of the communities we are =
targeting to support, they help us uncover issues with our approach or =
implementation, and they help us understand where we need to explain =
ourselves better.

=20

Thank you for the constructive discourse.

=20

sean

=20

From: Michael Hammer [mailto:michael.hammer@yaanatech.com]=20
Sent: Tuesday, April 17, 2012 3:28 PM
To: Barnum, Sean D.; osantos@cisco.com; Thomas.Millar@hq.dhs.gov; =
lnunez@c3isecurity.com
Cc: idxwg@nicwg.org; mile@ietf.org; sacm@ietf.org; m-terada@ipa.go.jp; =
dallendoug@gmail.com
Subject: RE: [mile] [sacm] CybOX v1.0 (Draft) is now released and live =
onthe website

=20

Sean,

=20

What you say makes sense.  But, if you will bear with me.  (Still =
learning this.)

=20

If one used Packet Traffic event type always instead of Data Flow event =
type, would some distinction be lost?

Or, put another way, since the packet stuff seems to cover most =
network-based events, does Data Flow involve something that is not on =
the wire?

(Such as an inter-process communication that doesn=E2=80=99t go through =
a protocol stack.)

=20

Mike

=20

=20

From: Barnum, Sean D. [mailto:sbarnum@mitre.org]=20
Sent: Tuesday, April 17, 2012 3:03 PM
To: Michael Hammer; osantos@cisco.com; Thomas.Millar@hq.dhs.gov; =
lnunez@c3isecurity.com
Cc: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; =
m-terada@ipa.go.jp
Subject: RE: [mile] [sacm] CybOX v1.0 (Draft) is now released and live =
onthe website

=20

Mike,

=20

Just to clarify, all of our discussion so far about =E2=80=9CData =
Flow=E2=80=9D and netflow were all in regards to an enumeration called =
EventTypeEnum that simply lets you tag a cyber observable event with a =
type label. It is metadata for an event description.

The only object we have been talking about in any detail so far was the =
Network_Flow object. These two topics are totally independent of each =
other. There is no Data_Flow object.

The abstraction overlap we have been discussing is only in the metadata =
tag applied to an event to characterize what type/class of event it is.

=20

The defined objects themselves (including Network_Flow) have been =
designed to avoid, as much as possible, overlap of the type you =
describe.

The approach we have taken is that where there is common structure and =
meaning relevant to multiple different types of objects, the structure =
for that commonality is broken out into its own object (e.g. Address, =
URI, Port, Account, Process, etc.).

Content based on this common object structure can be embedded within a =
leveraging object (via direct use of the object type) if the content is =
directly relevant only within the context of that object or as an =
independent object and associated to any number of other objects to =
which it is relevant utilizing relationships.

We make no guarantees that we have managed to implement this approach =
flawlessly but we believe that it yields a good balance of consistency, =
efficiency and flexibility. It also allows easy modular use of only what =
is relevant within a given context and enables extension and evolution =
to easily occur in a localized fashion rather than having to extend and =
modify one monolithic structure standard.

=20

Does that make sense?

=20

sean

=20

From: Michael Hammer [mailto:michael.hammer@yaanatech.com]=20
Sent: Tuesday, April 17, 2012 9:18 AM
To: Barnum, Sean D.; osantos@cisco.com; Thomas.Millar@hq.dhs.gov; =
lnunez@c3isecurity.com
Cc: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; =
m-terada@ipa.go.jp
Subject: RE: [mile] [sacm] CybOX v1.0 (Draft) is now released and live =
onthe website

=20

Sean,

=20

Does the overlap between the various objects present a problem?

=20

If there are one or more objects that could carry the same data, then =
human nature means that probability-wise someone will choose data flow =
instead of Netflow.

That is the underlying principle in Murphy=E2=80=99s Law, where you try =
to design it so that there is only one way to do it, and thus private =
Murphy won=E2=80=99t do it the =E2=80=9Cwrong=E2=80=9D way.

=20

Just wondering if these should be mutually exclusive sets.  And designed =
as such.

Might improve interoperability.  (And avoid discussions like this in =
future.)  J

=20

Mike

=20

=20

From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of =
Barnum, Sean D.
Sent: Tuesday, April 17, 2012 1:10 AM
To: Omar Santos (osantos); Millar, Thomas; lnunez@c3isecurity.com
Cc: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; =
m-terada@ipa.go.jp
Subject: Re: [mile] [sacm] CybOX v1.0 (Draft) is now released and live =
onthe website

=20

=E2=80=9Cupper layer=E2=80=9D? Yes, as in higher abstraction.

Just =E2=80=9Cprotocols=E2=80=9D? No.

=20

You guys have been looking at this through the lens of network flow =
which if fine for thinking about that perspective but it is important to =
also realize that the EventTypeEnum and its =E2=80=9CData Flow=E2=80=9D =
value go far beyond network-related scope.

It is about a lot of other types of potential data flows (as I just =
outlined in a response to Tom) that have nothing to do with network =
flow.

=20

Thanks for your response though. This is the kind of discussions that we =
hope to have a lot more of among the various supported communities.

=20

=20

BTW, you may have noticed that the Network_Flow object within CybOX v1.0 =
(Draft) supports expression of netflow within several of the most common =
formats including Netflow9 (as well as IPFIX as Luis pointed out, =
Netflow5 and SiLK as well as bi-directional flow in YAF). The common =
5-tuple or 7-tuple (you describe) (in our case it is an 8-tuple as we =
broke the router interface out into both ingress and egress J) shared by =
pretty much all of the netflow approaches has been broken out into a =
shared Network_Flow_Label structure. The various context-dependent =
portions of the independent approaches are then captured within optional =
structures dedicated to each of them. We hope that eventually the =
community can work to come together towards a single overall common =
expressive structure for netflow that meets the needs of all. We hope =
that CybOX and its use can even help that sort of maturation and =
normalization. But since no such universal structure exists today, we =
decided to enable optional expression of the most common individual =
formats within a single netflow object to serve the large majority of =
relevant users, maintain flexibility and enable discussions and analysis =
of netflow within a common package.

We look forward to continuing discussions with the community to validate =
or invalidate this approach and to refine and mature going forward.

=20

Sean=20

=20

From: Omar Santos (osantos) [mailto:osantos@cisco.com]=20
Sent: Monday, April 16, 2012 11:57 PM
To: Millar, Thomas; Barnum, Sean D.; lnunez@c3isecurity.com
Cc: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; =
m-terada@ipa.go.jp
Subject: RE: [sacm] [mile] CybOX v1.0 (Draft) is now released and live =
onthe website

=20

I believe that what Sean is saying is that =E2=80=9Cdata flow=E2=80=9D =
is just a value that is meant for upper layer protocols. But, you have a =
good point. Traditionally, a =E2=80=9Cflow=E2=80=9D in =
=E2=80=9CNetflow=E2=80=9D is based on a set of 5 and up to 7 IP packet =
attributes:

=20

- IP source address

- IP destination address

- Source port

- Destination port

- Layer 3 protocol type

- Class of Service

- Router or switch interface

=20

Although, there is a lot more support with Netflow version 9:

http://www.cisco.com/en/US/technologies/tk648/tk362/technologies_white_pa=
per09186a00800a3db9_ps6601_Products_White_Paper.html

=20

=20

=20

Regards,

Omar=20

=20

From: Millar, Thomas [mailto:Thomas.Millar@hq.dhs.gov]=20
Sent: Monday, April 16, 2012 11:46 PM
To: sbarnum@mitre.org; Omar Santos (osantos); lnunez@c3isecurity.com
Cc: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; =
m-terada@ipa.go.jp
Subject: Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live =
onthe website

=20

If "data flow" is a euphemism for "netflow" is there any reason not to =
call it that?

Tom Millar=20
http://www.us-cert.gov/=20
------------------=20
Missit me Rubus fruticosus:=20
202 631 1915=20

=20

From: Barnum, Sean D. [mailto:sbarnum@mitre.org]=20
Sent: Monday, April 16, 2012 11:29 PM
To: Omar Santos (osantos) ; Luis Nunez =
=20
Cc: idxwg@nicwg.org ; mile@ietf.org ; =
dallendoug@gmail.com ; sacm@ietf.org =
; m-terada@ipa.go.jp =20
Subject: Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live =
onthe website=20
=20

Thanks Omar.

=20

To answer your question, first let me point out to other readers that =
the two entries that Omar is quoting here exist as values in an =
enumeration called EventTypeEnum which as its name implies contains a =
list of different labels for grouping types (or classes) of events to be =
used as low-granularity buckets for characterizing and classifying =
events.

Other entries in this enumeration include things like =E2=80=9CFile Ops =
(CRUD)=E2=80=9D, =E2=80=9CProcess Mgt=E2=80=9D, =E2=80=9CAuthorization =
(ACL)=E2=80=9D, etc.

=20

The =E2=80=9CPacket Traffic=E2=80=9D value is intended to characterize =
events dealing with network packet traffic as its name implies.

The =E2=80=9CData Flow=E2=80=9D value is intended to characterize events =
dealing with forms of data flow at a higher level of abstraction than =
just packet traffic. The relationship between these two values could be =
viewed as =E2=80=9CPacket Traffic=E2=80=9D being a more detailed form of =
=E2=80=9CData Flow=E2=80=9D just as the values =E2=80=9CApp Layer =
Traffic=E2=80=9D and =E2=80=9CHTTP Layer Traffic=E2=80=9D, also in this =
enumeration, could be other levels in this same abstraction stack.

The idea behind the varying levels of abstraction is to leave  buckets =
large enough to capture a wide variety of potential event types (e.g. =
data flow events other than obvious things like packet traffic) but also =
enable the use of smaller more specific buckets when they are =
appropriate and commonly used.

=20

Does this make sense?=20

=20

sean

=20

From: Omar Santos (osantos) [mailto:osantos@cisco.com]=20
Sent: Monday, April 16, 2012 8:17 PM
To: Luis Nunez; Barnum, Sean D.
Cc: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; =
m-terada@ipa.go.jp
Subject: RE: [sacm] [mile] CybOX v1.0 (Draft) is now released and live =
onthe website

=20

I echo Luis=E2=80=99 comments. It is good to see the inclusion of =
network objects. Quick question to the team related to your netflow =
comment.

=20

I am looking at:

http://cybox.mitre.org/XMLSchema/cybox_core_v1.0%28draft%29.xsd

=20

=E2=80=A6 and it looks that we renamed it to =E2=80=9CData =
Flow=E2=80=9D?

=20



   

        Specifies the class of events dealing with =
data flow.

   



=20

=20

What is the difference between that and =E2=80=9CPacket =
Traffic=E2=80=9D?

=20


   
     Specifies the class of events dealing with packet =
traffic.
   


=20

=20

=20

=20

Regards,

Omar Santos
Incident Manager, PSIRT
Security Research and Operations
Cisco Systems, Inc.
Email: os@cisco.com
Phone: +1 919 392 8635
PGP Key: 0x3AF27EDC

Cisco.com - http://www.cisco.com
Cisco Security Advisories and Notices - http://www.cisco.com/go/psirt

This email may contain confidential and privileged material for the sole
use of the intended recipient. Any review, use, distribution or
disclosure by others is strictly prohibited. If you are not the intended
recipient (or authorized to receive for the recipient), please contact
the sender by reply email and delete all copies of this message.

For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

=20

From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of =
Luis Nunez
Sent: Monday, April 16, 2012 6:44 PM
To: Barnum, Sean D.
Cc: idxwg@nicwg.org; mile@ietf.org; Doug Wilson (dallendoug@gmail.com); =
sacm@ietf.org; IPA-Masato Terada (m-terada@ipa.go.jp)
Subject: Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live =
onthe website

=20

I like the inclusion of the network-centric objects.  IPFIX (netflow)  =
will add an additional perspective from an incident information sharing =
standpoint. =20

=20

-ln

=20

On Apr 16, 2012, at 4:04 PM, Barnum, Sean D. wrote:

=20

Hey everyone,

=20

I just wanted to let you all know that CybOX v1.0 (Draft) content is now =
live on the website. http://cybox.mitre.org

The release notes are provided inline below.

The key items of note are:

=C2=B7        The release of two formal specifications for the CybOX =
language (one for the core language and one for the defined objects)

=C2=B7        The XML Schema has gone through extensive improvements for =
expressiveness, clarity, consistency, efficiency, alignment to existing =
normative references and documentation.

=C2=B7        This release includes an initial set of language =
utilities: a draft Snort -> CybOX transform, a draft OpenIOC -> CybOX =
transform, and a set of Python bindings for the CybOX language.

=C2=B7        The website now includes a small set of content examples. =
This set will grow going forward.

This release involved a lot of hard work from a diverse group of people. =
Thank you all for your contributions and effort. We could not have done =
it without you.

We look forward to everyone=E2=80=99s feedback and collaboration as we =
continue to improve and mature the CybOX language.

=20

Sean Barnum

=20

=20

=20

CybOX v1.0 (Draft) Release Notes

The Version 1.0 (Draft) release of Cyber Observable eXpression =
(CybOX=E2=84=A2) is intended as a draft release of an initial major =
version of the CybOX Language that could be utilized for practical =
operational use and integration into other standards efforts. This =
release consists of three primary components: a pair of formal language =
specifications for the core language content and defined objects =
content, a set of language implementation XML schemas (core, =
common_types, and ~70 defined object schemas), and a small initial set =
of language utilities including an initial draft Snort->CybOX transform, =
an initial draft OpenIOC->CybOX transform and a set of CybOX language =
Python bindings. Recognizing that this is the first time that the formal =
language specifications will be available for review and as such will =
likely generate feedback from new stakeholders, this initial major =
version is being released as a =E2=80=9Cdraft=E2=80=9D v1.0 with the =
expectation of cycles of new feedback and revision before a =
=E2=80=9Cfinal=E2=80=9D v1.0 is released.

The CybOX v1.0 (Draft) XML schemas include a significant number of =
changes from v0.7 to improve:

=C2=B7       Clarity, documentation, and descriptive formality for =
reference and implementation by other standards and users.

=C2=B7       Consistency, simplicity, and efficiency.

=C2=B7       Alignment (as appropriate) to existing normative =
references.

=C2=B7       Expressiveness of the schema to better support the broad =
set of use cases it targets (malware characterization, indicator and =
incident data sharing, event management, etc.) including the addition of =
an initial set of network-related defined objects.

Summary of changes from CybOX_v0.7 to CybOX_v1.0_(Draft):

=C2=B7        Refinement of namespaces and schema locations for better =
effectiveness and flexibility going forward.

=C2=B7        Normalized all content according to an established set of =
naming conventions.

=C2=B7        Fully annotated all language items (types, attributes, =
elements, etc.).

=C2=B7        Moved several commonly leveraged types out of the core =
schema and into common_types.

=C2=B7        Achieved full typing of entire schema structure such that =
all attributes and elements are definitively typed.

=C2=B7        Changed all identifiers from ID and IDREF types to be =
QNames enabling globally unique identifiers and flexibility for =
domain-specific users of CybOX to define their own identifier syntax =
locally.

=C2=B7        Reordered attributes and elements in numerous types to =
better reflect common usage and priority.

=C2=B7        Added major_version and minor_version attributes for core =
schema.

=C2=B7        Added capability to characterize source of overall =
observable package data and for individual observables.

=C2=B7        Modified the logical composition structure such that any =
such compositions are now contained within a Observable_Composition =
element providing improved simplicity and modularity.

=C2=B7        Removed the Delta element from ObservableType and =
relocated the appropriate portions (Change, Trend, and Frequency) to =
appropriate locations under Stateful_Measure and Event.

=C2=B7        Added a Domain_Specific_Object_Attributes field to Object =
utilizing an abstract type that will allow domain-specific use cases to =
add in their own domain-specific attributes for Objects.

=C2=B7        Added a Tool-Specific_Data field to ToolInformationType =
utilizing an abstract type that will allow addition of tool-specific =
data.

=C2=B7        Added an Indicators field to MeasureSourceType utilizing =
an abstract type that will allow characterizing differing formats or =
standards of indicators that may have led to the identification of the =
observable data.

=C2=B7        Enhanced the Hash structure to capture full fuzzy hashes =
in addition to simple hashes

=C2=B7        Added a new ExtractedFeaturesType that can be used to =
adorn differing objects (e.g., files, memory, etc.) to capture extracted =
strings, imports, functions and code snippets

=C2=B7        Added a ByteRunsType to enable capture of byte runs within =
various objects.

=C2=B7        Added object_reference attribute to DefinedObjectType to =
better support referencing of independently defined Objects from within =
another Object definition.

=C2=B7        Added a generic DataSegmentType to provide a relatively =
abstract way of characterizing data segments that may be =
written/read/transmitted or otherwise utilized in actions or defined in =
objects.

=C2=B7        Added several new defined object schemas (API, Code, =
Device, DNS_Record, Network_Flow, Network_Packet, Network_Route_Entry, =
Network_Subnet, Unix_Network_Route_Entry) including an initial set of =
network-centric defined objects.

=C2=B7        Modified every defined object schema with added =
annotations as well as minor and in some cases substantive changes to =
fix errors, improve consistency and alignment with existing normative =
references, and to improve expressiveness in support of the targeted use =
cases.

Detailed changes from CybOX_v0.7 to CybOX_v1.0_(Draft):

The level of changes within v1.0 (Draft) in the core schema, =
common_types and the defined object schemas is too great to list every =
change in these release notes. Detailed difference reports are available =
for each individual schema at: =
 =
http://cybox.mitre.org/XMLSchema/release_notes/cybox_v1.0(draft)_diff_rep=
orts.zip

=20

=20

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

Sean Barnum

Cyber Security Principal

The MITRE Corporation

Email: sbarnum@mitre.org

=20

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

=20


------=_NextPart_001_00B6_01CD1CB9.BDEF3370
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable


Mike,
 
If you always =
utilized the most abstract label (Data Flow) to adorn events even when =
you knew the more specific type that they were and had a more specific =
label for them, then yes you would lose =
distinction.
Such misuse =
is always the potential downside of enabling flexibility through =
abstraction.
If you know =
that the event you are characterizing has to do with Packet Traffic and =
not just some form of more general data flow that does not have an =
appropriate associated event type label, then you should absolutely use =
Packet Traffic and not Data Flow. An event should only be tagged with an =
abstract label like Data Flow if there is not an appropriate more =
concrete label available.
 
In answer to =
your second question, yes Data Flow definitely covers not only =
network-related events but also events that have nothing to do with the =
wire.
My response =
to Tom Millar that I sent at 12:52am this morning lists out several =
non-network related types of events that Data Flow could apply =
to.
 
Please do not =
feel bad for asking these questions. They help you understand our =
approach, they help others understand our approach, they help us better =
understand the perspective of the communities we are targeting to =
support, they help us uncover issues with our approach or =
implementation, and they help us understand where we need to explain =
ourselves better.
 
Thank you for =
the constructive discourse.
 
sean
 
From:=
 =
Michael Hammer [mailto:michael.hammer@yaanatech.com] 
Sent: =
Tuesday, April 17, 2012 3:28 PM
To: Barnum, Sean D.; =
osantos@cisco.com; Thomas.Millar@hq.dhs.gov; =
lnunez@c3isecurity.com
Cc: idxwg@nicwg.org; mile@ietf.org; =
sacm@ietf.org; m-terada@ipa.go.jp; =
dallendoug@gmail.com
Subject: RE: [mile] [sacm] CybOX v1.0 =
(Draft) is now released and live onthe =
website
 
Sean,
 
What you say makes sense.  But, if you will bear with me.  =
(Still learning this.)
 
If one used Packet Traffic event type always instead of Data Flow =
event type, would some distinction be lost?
Or, put another way, since the packet stuff seems to cover most =
network-based events, does Data Flow involve something that is not on =
the wire?
(Such as an inter-process communication that doesn=E2=80=99t go =
through a protocol stack.)
 
Mike
 
 
From:=
 =
Barnum, Sean D. [mailto:sbarnum@mitre.org]=
 
Sent: Tuesday, April 17, 2012 3:03 PM
To: Michael =
Hammer; osantos@cisco.com; Thomas.Millar@hq.dhs.gov; =
lnunez@c3isecurity.com
C=
c: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; m-terada@ipa.go.jp
Subject:<=
/b> RE: [mile] [sacm] CybOX v1.0 (Draft) is now released and live onthe =
website
 
Mike,
 
Just to clarify, all of our discussion so far about =E2=80=9CData =
Flow=E2=80=9D and netflow were all in regards to an enumeration called =
EventTypeEnum that simply lets you tag a cyber observable event with a =
type label. It is metadata for an event =
description.
The only object we have been talking about in any detail so far was =
the Network_Flow object. These two topics are totally independent of =
each other. There is no Data_Flow object.
The abstraction overlap we have been discussing is only in the =
metadata tag applied to an event to characterize what type/class of =
event it is.
 
The defined objects themselves (including Network_Flow) have been =
designed to avoid, as much as possible, overlap of the type you =
describe.
The approach we have taken is that where there is common structure =
and meaning relevant to multiple different types of objects, the =
structure for that commonality is broken out into its own object (e.g. =
Address, URI, Port, Account, Process, etc.).
Content based on this common object structure can be embedded within =
a leveraging object (via direct use of the object type) if the content =
is directly relevant only within the context of that object or as an =
independent object and associated to any number of other objects to =
which it is relevant utilizing relationships.
We make no guarantees that we have managed to implement this approach =
flawlessly but we believe that it yields a good balance of consistency, =
efficiency and flexibility. It also allows easy modular use of only what =
is relevant within a given context and enables extension and evolution =
to easily occur in a localized fashion rather than having to extend and =
modify one monolithic structure standard.
 
Does that make sense?
 
sean
 
From:=
 =
Michael Hammer [mailto:michael.ham=
mer@yaanatech.com] 
Sent: Tuesday, April 17, 2012 9:18 =
AM
To: Barnum, Sean D.; osantos@cisco.com; Thomas.Millar@hq.dhs.gov; =
lnunez@c3isecurity.com
C=
c: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; m-terada@ipa.go.jp
Subject:<=
/b> RE: [mile] [sacm] CybOX v1.0 (Draft) is now released and live onthe =
website
 
Sean,
 
Does the overlap between the various objects present a =
problem?
 
If there are one or more objects that could carry the same data, then =
human nature means that probability-wise someone will choose data flow =
instead of Netflow.
That is the underlying principle in Murphy=E2=80=99s Law, where you =
try to design it so that there is only one way to do it, and thus =
private Murphy won=E2=80=99t do it the =E2=80=9Cwrong=E2=80=9D =
way.
 
Just wondering if these should be mutually exclusive sets.  And =
designed as such.
Might improve interoperability.  (And avoid discussions like =
this in future.)  J
 
Mike
 
 
From:=
 =
mile-bounces@ietf.org [mailto:mile-bounces@ietf.=
org] On Behalf Of Barnum, Sean D.
Sent: Tuesday, =
April 17, 2012 1:10 AM
To: Omar Santos (osantos); Millar, =
Thomas; lnunez@c3isecurity.com
C=
c: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; m-terada@ipa.go.jp
Subject:<=
/b> Re: [mile] [sacm] CybOX v1.0 (Draft) is now released and live onthe =
website
 
=E2=80=9Cupper layer=E2=80=9D? Yes, as in higher =
abstraction.
Just =E2=80=9Cprotocols=E2=80=9D? No.
 
You guys have been looking at this through the lens of network flow =
which if fine for thinking about that perspective but it is important to =
also realize that the EventTypeEnum and its =E2=80=9CData Flow=E2=80=9D =
value go far beyond network-related scope.
It is about a lot of other types of potential data flows (as I just =
outlined in a response to Tom) that have nothing to do with network =
flow.
 
Thanks for your response though. This is the kind of discussions that =
we hope to have a lot more of among the various supported =
communities.
 
 
BTW, you may have noticed that the Network_Flow object within CybOX =
v1.0 (Draft) supports expression of netflow within several of the most =
common formats including Netflow9 (as well as IPFIX as Luis pointed out, =
Netflow5 and SiLK as well as bi-directional flow in YAF). The common =
5-tuple or 7-tuple (you describe) (in our case it is an 8-tuple as we =
broke the router interface out into both ingress and egress J) shared by pretty much all of the netflow approaches has been broken =
out into a shared Network_Flow_Label structure. The various =
context-dependent portions of the independent approaches are then =
captured within optional structures dedicated to each of them. We hope =
that eventually the community can work to come together towards a single =
overall common expressive structure for netflow that meets the needs of =
all. We hope that CybOX and its use can even help that sort of =
maturation and normalization. But since no such universal structure =
exists today, we decided to enable optional expression of the most =
common individual formats within a single netflow object to serve the =
large majority of relevant users, maintain flexibility and enable =
discussions and analysis of netflow within a common =
package.
We look forward to continuing discussions with the community to =
validate or invalidate this approach and to refine and mature going =
forward.
 
Sean 
 
From:=
 =
Omar Santos (osantos) [mailto:osantos@cisco.com]=
 
Sent: Monday, April 16, 2012 11:57 PM
To: Millar, =
Thomas; Barnum, Sean D.; lnunez@c3isecurity.com
C=
c: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; m-terada@ipa.go.jp
Subject:<=
/b> RE: [sacm] [mile] CybOX v1.0 (Draft) is now released and live onthe =
website
 
I believe that what Sean is saying is that =E2=80=9Cdata =
flow=E2=80=9D is just a value that is meant for upper layer protocols. =
But, you have a good point. Traditionally, a =E2=80=9Cflow=E2=80=9D in =
=E2=80=9CNetflow=E2=80=9D is based on a set of 5 and up to 7 IP packet =
attributes:
 
- IP source address
- IP destination address
- Source port
- Destination port
- Layer 3 protocol type
- Class of Service
- Router or switch interface
 
Although, there is a lot more support with Netflow version =
9:
http://www.=
cisco.com/en/US/technologies/tk648/tk362/technologies_white_paper09186a00=
800a3db9_ps6601_Products_White_Paper.html
 
 
 
Regards,

Omar 
 
From:=
 =
Millar, Thomas [mailto:Thomas.Millar@h=
q.dhs.gov] 
Sent: Monday, April 16, 2012 11:46 =
PM
To: sbarnum@mitre.org; Omar Santos =
(osantos); lnunez@c3isecurity.com
C=
c: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; m-terada@ipa.go.jp
Subject:<=
/b> Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live onthe =
website
 
If "data flow" is a euphemism for "netflow" is =
there any reason not to call it that?

Tom Millar 
http://www.us-cert.gov/ =

------------------ 
Missit me Rubus fruticosus: 
202 631 1915 =


 
From<=
/b>: =
Barnum, Sean D. [mailto:sbarnum@mitre.org]=
 
Sent: Monday, April 16, 2012 11:29 PM
To: Omar =
Santos (osantos) <osantos@cisco.com>; Luis Nunez =
<lnunez@c3isecurity.com> =

Cc: idxwg@nicwg.org =
<idxwg@nicwg.org>; mile@ietf.org <mile@ietf.org>; dallendoug@gmail.com <dallendoug@gmail.com>; sacm@ietf.org <sacm@ietf.org>; m-terada@ipa.go.jp <m-terada@ipa.go.jp> =

Subject: Re: [sacm] [mile] CybOX v1.0 (Draft) is now released =
and live onthe website 
 
Thanks Omar.
 
To answer your question, first let me point out to other readers that =
the two entries that Omar is quoting here exist as values in an =
enumeration called EventTypeEnum which as its name implies contains a =
list of different labels for grouping types (or classes) of events to be =
used as low-granularity buckets for characterizing and classifying =
events.
Other entries in this enumeration include things like =E2=80=9CFile =
Ops (CRUD)=E2=80=9D, =E2=80=9CProcess Mgt=E2=80=9D, =
=E2=80=9CAuthorization (ACL)=E2=80=9D, etc.
 
The =E2=80=9CPacket Traffic=E2=80=9D value is intended to =
characterize events dealing with network packet traffic as its name =
implies.
The =E2=80=9CData Flow=E2=80=9D value is intended to characterize =
events dealing with forms of data flow at a higher level of abstraction =
than just packet traffic. The relationship between these two values =
could be viewed as =E2=80=9CPacket Traffic=E2=80=9D being a more =
detailed form of =E2=80=9CData Flow=E2=80=9D just as the values =
=E2=80=9CApp Layer Traffic=E2=80=9D and =E2=80=9CHTTP Layer =
Traffic=E2=80=9D, also in this enumeration, could be other levels in =
this same abstraction stack.
The idea behind the varying levels of abstraction is to leave =
 buckets large enough to capture a wide variety of potential event =
types (e.g. data flow events other than obvious things like packet =
traffic) but also enable the use of smaller more specific buckets when =
they are appropriate and commonly used.
 
Does this make sense? 
 
sean
 
From:=
 =
Omar Santos (osantos) [mailto:osantos@cisco.com]=
 
Sent: Monday, April 16, 2012 8:17 PM
To: Luis =
Nunez; Barnum, Sean D.
Cc: idxwg@nicwg.org; mile@ietf.org; dallendoug@gmail.com; sacm@ietf.org; m-terada@ipa.go.jp
Subject:<=
/b> RE: [sacm] [mile] CybOX v1.0 (Draft) is now released and live onthe =
website
 
I echo Luis=E2=80=99 comments. It is good to see the inclusion of =
network objects. Quick question to the team related to your netflow =
comment.
 
I am looking at:
=
http://cybox.mitre.org/XMLSchema/cybox_core_v1.0%28draft%29.xsd<=
/o:p>
 
=E2=80=A6 and it looks that we renamed it to =E2=80=9CData =
Flow=E2=80=9D?
 
<xs:enumeration =
value=3D"Data Flow">
   =
<xs:annotation>
        =
<xs:documentation>Specifies the class of events dealing with data =
flow.</xs:documentation>
   =
</xs:annotation>
</xs:enumeration>
 
 
What is the difference between that and =E2=80=9CPacket =
Traffic=E2=80=9D?
 
<xs:enumeration value=3D"Packet =
Traffic">
   =
<xs:annotation>
     =
<xs:documentation>Specifies the class of events dealing with =
packet traffic.</xs:documentation>
   =
</xs:annotation>
</xs:enumeration>
 
 
 
 
Regards,

Omar Santos
Incident Manager, =
PSIRT
Security Research and Operations
Cisco Systems, =
Inc.
Email: os@cisco.com
Phone: +1 919 392 =
8635
PGP Key: 0x3AF27EDC

Cisco.com - http://www.cisco.com
Cisco Security =
Advisories and Notices - http://www.cisco.com/go/psirt<=
br>
This email may contain confidential and privileged material for =
the sole
use of the intended recipient. Any review, use, distribution =
or
disclosure by others is strictly prohibited. If you are not the =
intended
recipient (or authorized to receive for the recipient), =
please contact
the sender by reply email and delete all copies of =
this message.

For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html=

 
From:=
 =
sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.=
org] On Behalf Of Luis Nunez
Sent: Monday, April =
16, 2012 6:44 PM
To: Barnum, Sean D.
Cc: idxwg@nicwg.org; mile@ietf.org; Doug Wilson (dallendoug@gmail.com); sacm@ietf.org; IPA-Masato Terada (m-terada@ipa.go.jp)
Subject:=
 Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live onthe =
website
 
I like the inclusion of the network-centric =
objects.  IPFIX (netflow)  will add an additional perspective =
from an incident information sharing standpoint. =
 
 
-ln
 
On Apr 16, 2012, at 4:04 =
PM, Barnum, Sean D. wrote:
 
Hey =
everyone,
 =

I just =
wanted to let you all know that CybOX v1.0 (Draft) content is now live =
on the website. http://cybox.mitre.org
The =
release notes are provided inline =
below.
The key =
items of note are:
=C2=B7        The =
release of two formal specifications for the CybOX language (one for the =
core language and one for the defined =
objects)
=C2=B7        The XML =
Schema has gone through extensive improvements for expressiveness, =
clarity, consistency, efficiency, alignment to existing normative =
references and documentation.
=C2=B7        This =
release includes an initial set of language utilities: a draft Snort =
-> CybOX transform, a draft OpenIOC -> CybOX transform, and a set =
of Python bindings for the CybOX language.
=C2=B7        The =
website now includes a small set of content examples. This set will grow =
going forward.
This =
release involved a lot of hard work from a diverse group of people. =
Thank you all for your contributions and effort. We could not have done =
it without you.
We look =
forward to everyone=E2=80=99s feedback and collaboration as we continue =
to improve and mature the CybOX =
language.
 =

Sean =
Barnum
 =

 =

 =

CybOX v1.0 (Draft) Release =
Notes
The Version 1.0 (Draft) release of Cyber =
Observable eXpression (CybOX=E2=84=A2) is intended as a draft release of an initial major version of =
the CybOX Language that could be utilized for practical operational use =
and integration into other standards efforts. This release consists of =
three primary components: a pair of formal language specifications for =
the core language content and defined objects content, a set of language =
implementation XML schemas (core, common_types, and ~70 defined object =
schemas), and a small initial set of language utilities including an =
initial draft Snort->CybOX transform, an initial draft =
OpenIOC->CybOX transform and a set of CybOX language Python bindings. =
Recognizing that this is the first time that the formal language =
specifications will be available for review and as such will likely =
generate feedback from new stakeholders, this initial major version is =
being released as a =E2=80=9Cdraft=E2=80=9D v1.0 with the expectation of =
cycles of new feedback and revision before a =E2=80=9Cfinal=E2=80=9D =
v1.0 is released.=

The CybOX v1.0 (Draft) XML schemas include a =
significant number of changes from v0.7 to improve:=

=C2=B7       Clarity, =
documentation, and descriptive formality for reference and =
implementation by other standards and users.=

=C2=B7       Consistency, =
simplicity, and efficiency.=

=C2=B7       Alignment (as =
appropriate) to existing normative references.=

=C2=B7       Expressiveness of the =
schema to better support the broad set of use cases it targets (malware =
characterization, indicator and incident data sharing, event management, =
etc.) including the addition of an initial set of network-related =
defined objects.=

Summary =
of changes from CybOX_v0.7 to CybOX_v1.0_(Draft):=

=C2=B7        =
Refinement of namespaces and schema =
locations for better effectiveness and flexibility going forward.=

=C2=B7        =
Normalized all content according to an =
established set of naming conventions.=

=C2=B7        =
Fully annotated all language items =
(types, attributes, elements, etc.).=

=C2=B7        =
Moved several commonly leveraged types =
out of the core schema and into common_types.=

=C2=B7        =
Achieved full typing of entire schema =
structure such that all attributes and elements are definitively =
typed.=

=C2=B7        =
Changed all identifiers from ID and IDREF =
types to be QNames enabling globally unique identifiers and flexibility =
for domain-specific users of CybOX to define their own identifier syntax =
locally.=

=C2=B7        =
Reordered attributes and elements in =
numerous types to better reflect common usage and priority.=

=C2=B7        =
Added major_version and minor_version =
attributes for core schema.=

=C2=B7        =
Added capability to characterize source =
of overall observable package data and for individual observables.=

=C2=B7        =
Modified the logical composition =
structure such that any such compositions are now contained within a =
Observable_Composition element providing improved simplicity and =
modularity.=

=C2=B7        =
Removed the Delta element from =
ObservableType and relocated the appropriate portions (Change, Trend, =
and Frequency) to appropriate locations under Stateful_Measure and =
Event.=

=C2=B7        =
Added a Domain_Specific_Object_Attributes =
field to Object utilizing an abstract type that will allow =
domain-specific use cases to add in their own domain-specific attributes =
for Objects.=

=C2=B7        =
Added a Tool-Specific_Data field to =
ToolInformationType utilizing an abstract type that will allow addition =
of tool-specific data.=

=C2=B7        =
Added an Indicators field to =
MeasureSourceType utilizing an abstract type that will allow =
characterizing differing formats or standards of indicators that may =
have led to the identification of the observable data.=

=C2=B7        =
Enhanced the Hash structure to capture =
full fuzzy hashes in addition to simple hashes=

=C2=B7        =
Added a new ExtractedFeaturesType that =
can be used to adorn differing objects (e.g., files, memory, etc.) to =
capture extracted strings, imports, functions and code snippets=

=C2=B7        =
Added a ByteRunsType to enable capture of =
byte runs within various objects.=

=C2=B7        =
Added object_reference attribute to =
DefinedObjectType to better support referencing of independently defined =
Objects from within another Object definition.=

=C2=B7        =
Added a generic DataSegmentType to =
provide a relatively abstract way of characterizing data segments that =
may be written/read/transmitted or otherwise utilized in actions or =
defined in objects.=

=C2=B7        Added several new =
defined object schemas (API, Code, Device, DNS_Record, Network_Flow, =
Network_Packet, Network_Route_Entry, Network_Subnet, =
Unix_Network_Route_Entry) including an initial set of network-centric =
defined objects.
=C2=B7        =
Modified every defined object schema with =
added annotations as well as minor and in some cases substantive changes =
to fix errors, improve consistency and alignment with existing normative =
references, and to improve expressiveness in support of the targeted use =
cases.=

Detailed changes from CybOX_v0.7 to =
CybOX_v1.0_(Draft):=

The level of changes within v1.0 (Draft) in =
the core schema, common_types and the defined object schemas is too =
great to list every change in these release notes. Detailed difference =
reports are available for each individual schema at:http://cybox.mitre.org/XMLSchema/release_notes/cybox_v1.0=
(draft)_diff_reports.zip
 =

 =

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

Sean Barnum=

Cyber Security Principal=

The MITRE Corporation=

 =

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

------=_NextPart_001_00B6_01CD1CB9.BDEF3370--

------=_NextPart_000_00B5_01CD1CB9.BDEF3370
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIYNDCCBS0w
ggMVoAMCAQICEEw6UhQhT9OgRBVHf7KQ+1AwDQYJKoZIhvcNAQELBQAwKTEnMCUGA1UEAxMeTUlU
UkUgQ29ycG9yYXRpb24gUEUgUm9vdCBDQS0xMB4XDTExMDQyNjE5NDU0NVoXDTIxMDQyNjE5NDgy
MlowKTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUEUgUm9vdCBDQS0xMIICIjANBgkqhkiG
9w0BAQEFAAOCAg8AMIICCgKCAgEAtp8hR0hRq3im+Alwfb5ZHGP5k2OSY2TlVHYHIMUDH3MfW7b6
8lB3j3MwAMsxGK1ke/t6O4K0t9wRH4QDgOQ1CthmOGZW7xiN81h0vP1Yf14SNugUa7ZvH9KP3iXs
y8QnOHal1bKf0Pa9KXib58qUuwfaZSCTW5P2ekqd8z4TETvfBWvPgDxyxnVsiAO6yL9WaRpMiSVM
hYLWy3KRuU/gue0bVEi+qdg+hENh1NSNXpoqseS262nq5cx5wybR/PF0YstQ9NNlYDM5cLECKYHH
zD6cXKJozuFXriswlE8rdna7VaxyZrfgC0ueEIY/tsj/65IyUhyPBwO0ZpW+Ls9Cd4Y+ERSu5mR5
Fd8w42eVzuosmk3s3AxrKC+Z4tXYkjaiWUduIegAiST1vJBwkS53vR+zrBX3Ep56l7MFVvW/GcsZ
9wUT2HG65JOeiVc2YzCEqLgQ3ZCBHn09oBag2lnMac+E2sKm9aKL3xzHs6cyD8qCJK9O8QLCqo3C
mzASlOwtTFiLYgpPW/MSmgYOt9JrwHAzk97DHFKTFttjrXGMmhMVzadt1EjMn1Wv8t5WLBI0qSoX
/MYi2CaeiDsEiWRu9Nmpu3pmi8m7tIR9csdbAVPks2soNMWOopGEpFQSDvU1+m77v2jIKQKYxYmN
2zUOJ4TJFL1osnZ/71MmLCDVd+ECAwEAAaNRME8wCwYDVR0PBAQDAgGGMA8GA1UdEwEB/wQFMAMB
Af8wHQYDVR0OBBYEFFuHfZ/+bL4C6fPgKTqKVCUsnzgvMBAGCSsGAQQBgjcVAQQDAgEAMA0GCSqG
SIb3DQEBCwUAA4ICAQAy78sXsP/eqHH8/uOYyxQ6TBDhkCBxNoy8MF2c9UDns5ADL1qyxPAlpDBs
L+2h1Zzt3FvPjg0SoRE/9juyG1qxMzhlv0jdQx12tESdo3uBb61b1uuc4H/VxCJWDI4KZL/B53EI
8HGPjUBdLADgOmG99uffm5uarSkjtIX//Bz3U6QfzTPlVWFi4SmzRI2mp16GQ8RPuJ/WMloaAn8X
H6EjS2oLjGZC8Pw8/C46W48NvZ1JZTrZvYZr7GmuvmplYK68SZv/T5Su+FlLRTy9uNXQLHtm6jKv
nDH2yB66zTwfaDpnjILnrC2O7ANRVZc0KywiKiW3nB7Joq74/XVuMI1PiSByt2Qu+RIS/WAI5wMi
bTmwSiBxQZqvuth+dXoakJyOP2Wg5jvL55v9RLZhDqMtRI5ovnOFvTgNJQqNPSekGtA+m6Ctl/vh
kSg65FFCMhaSkn7vY2Il+R8HouWJN8wTaudeexnyHcD+Mlt8QaB5CErpDjeeGZfQ0FcYm+6TtlMz
Dw5eFhT/J6QrABCxfgLkVFHurMcQD4JkmXXkq5bP+GNkY0Uy2LMbw/UD94OEV1LpfAqUkT+mu5Yb
vxg+elFtsad+Ix8owW372xynIADh9q1bHm+j1OHPJmGALWK9miRpC4t3isfu3ZB0QpI/e2Po6MED
393Jb0YbzrcElFv6ZDCCBhYwggP+oAMCAQICChrDbcgAAgAAN/wwDQYJKoZIhvcNAQEFBQAwUDET
MBEGCgmSJomT8ixkARkWA09SRzEVMBMGCgmSJomT8ixkARkWBU1JVFJFMSIwIAYDVQQDExlNSVRS
RSBDb3Jwb3JhdGlvbiBQRSBDQS0xMB4XDTEyMDMxMjE1MTgyN1oXDTE1MDMxMjE1MTgyN1owSjEL
MAkGA1UEBhMCVVMxDjAMBgNVBAoTBU1JVFJFMQ8wDQYDVQQLEwZQZW9wbGUxGjAYBgNVBAMTEUJh
cm51bS5TZWFuLjMxNTQzMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA9/I6RU7OcouL
6lcEJMAg8G3myNbQu84QnflS8p3PWOjgC6P50RDqGX5UxelDqMQPN5IsNYRXVY9/b7yN/RSH4goI
JfYKMitndKuCKz1q38Nh0YycEm5x2t/IN/60b01T1uOmhZfptLDoDzj0UQZwMQ19mhM/ldsrC8bR
GGuHXdQVaSyXygfhzNhqC06vZo5fvCBUJ6z7JtVrfRTHdudg19JYK+gds9p+Lvp/DOEXQmgpfpMl
jfNKMnrG+kPMMngrIJUsF5lcbhHuc5mO+O8eR8FxM2KF7gfKVmUmZxs7Y6uLenVJVEmllP0XgUu1
sv3bClFgUo5x5Aq6rXshtHuVuQIDAQABo4IB9jCCAfIwKAYDVR0lBCEwHwYIKwYBBQUHAwQGCSsG
AQQBcwIBBwYIKwYBBQUHAwIwHQYDVR0OBBYEFDvU1Ph/OVxGkxRmwvRx1TBf5PKqMA4GA1UdDwEB
/wQEAwIGwDAcBgNVHREEFTATgRFzYmFybnVtQG1pdHJlLm9yZzAfBgNVHSMEGDAWgBRpZyAh1EjB
0BsGbvMIKOI6gn1BMTBJBgNVHR8EQjBAMD6gPKA6hjhodHRwOi8vcGtpLm1pdHJlLm9yZy9NSVRS
RSUyMENvcnBvcmF0aW9uJTIwUEUlMjBDQS0xLmNybDB/BggrBgEFBQcBAQRzMHEwRwYIKwYBBQUH
MAKGO2h0dHA6Ly9wa2kubWl0cmUub3JnL01JVFJFJTIwQ29ycG9yYXRpb24lMjBQRSUyMENBLTEo
MikuY3J0MCYGCCsGAQUFBzABhhpodHRwOi8vb2NzcC5taXRyZS5vcmcvb2NzcDA+BgkrBgEEAYI3
FQcEMTAvBicrBgEEAYI3FQiDrqwjho6WV4GNiT2CpKsShb6uAYE2g9KXfYeg+0kCAWQCAQcwFgYD
VR0gBA8wDTALBgkrBgEEAXMCAQgwNAYJKwYBBAGCNxUKBCcwJTAKBggrBgEFBQcDBDALBgkrBgEE
AXMCAQcwCgYIKwYBBQUHAwIwDQYJKoZIhvcNAQEFBQADggIBAC2wqKo7QWQxIqnEKRznPrAQ5vQ9
X5JhB5keH8KMWu1W5n1RuSZH+3TYp4xccdYh+rV5b5+cJcWEYhtYpZriWm4kMHPaB6gKO9rbVfF9
R8Wp8sXvCKogbNhdkZwvXW4QymB1ASlMzDI1cCV8mzYgbIhWaCbV1zZBUVgOGa4LZIgdbdmgo5r/
O2gmnSftTYiE/tQ+DBs/25Bw/jC5HOiMXJqr+JctzJTqpEVLa7GKHnXWGuzGEPYkKBplxIyhz3Mv
qc/yuKM7tZzAr8Qn5qf7VI9O2xp56QLjT2+mySOUR6Vml860FMpjjgZNMxAqOJt7OgY0PoUU9d18
yw1wiKSt0LUQoMcVvp7FifBjtBCG1sB/VOzxNvcNm6lO6EO23pvcjt6+WCG1X3pgnZ5UEohsM3c0
oLzYiuSYeVf85IO2yh9fWLWw2RGkf2szck1Xg0DsAQ54/YlZYyehELh43KbS3lpnTt8UlO7C0TMT
7JQwz4fTQg1a0e9rRPFnNDUG2fS2k3tz9IYILDB3F8uiZzzXptEzaYqzIqe5CK8ZGJQcw+w/CBen
6i+MV/y7yJmhio43Y1x9hIqoynqoSMV3CKYCoOwCvFUAGsNllDpExsQZoXrdd5gcuglqbh3t8wOM
jtXDSQllQ/hXDZJf8rnH0wGx3K+WA+LKNvKqNCw9spEtsfG0MIIGYjCCBEqgAwIBAgIKFJcW0gAA
AAAABDANBgkqhkiG9w0BAQsFADApMScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQRSBSb290
IENBLTEwHhcNMTEwNjE0MTc0NDQ0WhcNMTcwNjE0MTc1NDQ0WjBQMRMwEQYKCZImiZPyLGQBGRYD
T1JHMRUwEwYKCZImiZPyLGQBGRYFTUlUUkUxIjAgBgNVBAMTGU1JVFJFIENvcnBvcmF0aW9uIFBF
IENBLTEwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDSxK9RXieqdTz4JWRkRMs/EOuF
0P0S9SbspadLJkx/LDDnaAwmAnqfqm1n7/p82oVjy1yCye3SZu4Yp7fmDIAtWbkHvYOfxHkRv1ho
/fhaNN0YRkd65oJJz2ngEbNZxdIiCoialQfX/iWU7ApQ+ovKbFV60v5E0p2mPncs20NYRfsaetdh
nBZbFD9flDcXwJqSvGGGBfm7ifFCR1LrtEcNKjMwf7YEWZO0Vk3ZyhVq+k7JNLEbKv0OfBz8DU8G
iGU+j88QlrgGW8PLkwNk7nsS/DJp8aLudTuVqIE2CA9mqn5QjU/EZYNHGzSfCr+/usUmbojyVSJu
khhrAXspRAMz+Cia3yi3q3w8TnAljXWN1dhx1iuUv5GxyzMjfqK1tMuCUU2XzGNNqoVa1mqolBiy
DTCOr9d/IC0YHYMBSpQ+xi0x9zjXKt4FmQmkEAZgF4hsZZqcJYL/iCQiwiz8fEyVPZuvoWvdEXOo
zFYCpmkT0MZCJwyIux0Z6vJp6VLtN/6rZgc2y54HlTrp3ifazmpsfrk3NdHxlZTZug9kjEI+vEoy
p/79nAPyTWQQ1MEP0ErCWav80/HOi0MLx/7lIUfvVOjkOFgFb+iDvR4T3RAQrnEpgTO+fc7Jyzh9
LpFDqm0slwDP4Hj9cC3IzdED5BU43PGAe+HoZ8OD/1ovVgwo/wIDAQABo4IBYzCCAV8wEAYJKwYB
BAGCNxUBBAMCAQIwIwYJKwYBBAGCNxUCBBYEFFCiOtgZb+Zdflkw5sC2y01sUQaVMB0GA1UdDgQW
BBRpZyAh1EjB0BsGbvMIKOI6gn1BMTAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTALBgNVHQ8E
BAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAfBgNVHSMEGDAWgBRbh32f/my+Aunz4Ck6ilQlLJ84LzBQ
BgNVHR8ESTBHMEWgQ6BBhj9odHRwOi8vcGtpLm1pdHJlLm9yZy9NSVRSRSUyMENvcnBvcmF0aW9u
JTIwUEUlMjBSb290JTIwQ0EtMS5jcmwwWwYIKwYBBQUHAQEETzBNMEsGCCsGAQUFBzAChj9odHRw
Oi8vcGtpLm1pdHJlLm9yZy9NSVRSRSUyMENvcnBvcmF0aW9uJTIwUEUlMjBSb290JTIwQ0EtMS5j
cnQwDQYJKoZIhvcNAQELBQADggIBAHnDPfdYKxqNOtAYXMyyel83Vs8cCDAQZhSuIB0c6GkGoEdF
rmWH9pwi42V96rCp7TvbNNKNJXbVHfJUAp+uqw663DL/sXXff9ZFxPxKOdPnpA8cKM7RBH9e437N
w3d28A7PaGbP6tXmSqhXAhYZ4U12y1U5cOf2G/phUoAAMlnVJdfmXzMazvLo2SIeixAJyCze6rHQ
TFQ/N+gAjbVuRJ+Hs8FEKVzMSwqlNoupe2ELqL4dMAKT6P08sAfxm2SrRlQvcWPYvqM/1C10bgc2
tdu+WGzRuP5Wx9Yr15KO9SW4z7fn2RVEXQgoDDno5vCIcfUPuKB5n+Kt9eBCitsgSD9yYsNUN9LE
VIvjAb8MV2LWLfge1bumo6g7QMRa4Fgifw5siGwi7V2EaJQo6UAIVvxKKFC7W4p6CkrY2ga1d7GI
Q0DPiWZOezOakJVAxL5gf+3WdNt0igKc/yLfbdHn6hCd1KPgDqkSKr8zWOZI/jiDBW957xAmaO6Q
dGQDBZrQHWpIVwQGzF5bGrqms2kq49l3t7KmBu0C/9tExqKAmlf4Y5lfQGdCbKQpAq712DVQHYuD
XmVQEAc2vlJ1C5hS3Iw9DwBWTfJ4vyB48buhBhbIhPiFta5OizXlKcsIi99ikA1yiZx/DBtjaw4J
U6qJzWUFB2ecyGCNPtNbYjURA0A9MIIGfzCCBGegAwIBAgIKGsNq2wACAAA3+jANBgkqhkiG9w0B
AQUFADBQMRMwEQYKCZImiZPyLGQBGRYDT1JHMRUwEwYKCZImiZPyLGQBGRYFTUlUUkUxIjAgBgNV
BAMTGU1JVFJFIENvcnBvcmF0aW9uIFBFIENBLTEwHhcNMTIwMzEyMTUxODI3WhcNMTUwMzEyMTUx
ODI3WjBKMQswCQYDVQQGEwJVUzEOMAwGA1UEChMFTUlUUkUxDzANBgNVBAsTBlBlb3BsZTEaMBgG
A1UEAxMRQmFybnVtLlNlYW4uMzE1NDMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCW
InZvCSslmSfSyhTVVSqnokCDajlsCNZHfUlkwkV1++2O71BYvMpjFHWR2XFIx963Hl63lFZzzVci
OjIwLb1c/0YXhFfUdAvrbpjlu+ttlO05OEUW0h+5HO+qaebJPamxA00w0bokquRcPxUvwa3jiyL0
WfCwE3+/b5PCOW2xh7FXFKv262FnKIwxnQGXqkiXRP5D/SmdtcZSzxHkDThrhaiHPhJJhZ4XxwBk
aGcAlMg8YH6uxshXm8e6c7XUu7gB5p+XThS0dqXujpQp/UQDp5t079+UrDcrpjfDBXIt9qCzLn26
uV5a4cD4xRKwA32f1cXFtiKXM0wYgUM3fEPDAgMBAAGjggJfMIICWzATBgNVHSUEDDAKBggrBgEF
BQcDBDCBlAYJKoZIhvcNAQkPBIGGMIGDMA4GCCqGSIb3DQMCAgIAgDAOBggqhkiG9w0DBAICAIAw
BwYFKw4DAgcwCgYIKoZIhvcNAwcwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBLTALBglghkgBZQME
ARYwCwYJYIZIAWUDBAEZMAsGCWCGSAFlAwQBAjALBglghkgBZQMEAQUwHQYDVR0OBBYEFIrbKa+E
Rxo2/Sth2C6jZqZqvRE7MA4GA1UdDwEB/wQEAwIFIDAcBgNVHREEFTATgRFzYmFybnVtQG1pdHJl
Lm9yZzAfBgNVHSMEGDAWgBRpZyAh1EjB0BsGbvMIKOI6gn1BMTBJBgNVHR8EQjBAMD6gPKA6hjho
dHRwOi8vcGtpLm1pdHJlLm9yZy9NSVRSRSUyMENvcnBvcmF0aW9uJTIwUEUlMjBDQS0xLmNybDB/
BggrBgEFBQcBAQRzMHEwRwYIKwYBBQUHMAKGO2h0dHA6Ly9wa2kubWl0cmUub3JnL01JVFJFJTIw
Q29ycG9yYXRpb24lMjBQRSUyMENBLTEoMikuY3J0MCYGCCsGAQUFBzABhhpodHRwOi8vb2NzcC5t
aXRyZS5vcmcvb2NzcDA+BgkrBgEEAYI3FQcEMTAvBicrBgEEAYI3FQiDrqwjho6WV4GNiT2CpKsS
hb6uAYE2hquSaISo7EUCAWQCAQ8wFgYDVR0gBA8wDTALBgkrBgEEAXMCAQgwGwYJKwYBBAGCNxUK
BA4wDDAKBggrBgEFBQcDBDANBgkqhkiG9w0BAQUFAAOCAgEAGmmL43yA+J5lEockM1cxSoyxfSES
HUGLVJyrhObbdFD4yO3jf0R4lHLuJlhp1486d9LRZAyzAnl9q8Zf3Tx1rl1kEd3pw0wMuO+ATscc
rArEW/rJxjz6zTrNO3PFkFuOEdmKpHaRiFpuSX602INiBEBPluei3uZlWxHW9VqC7hz2diQpOlzS
jtPMbL3o7ACjWaq7sQ0xB4rZ6oWyqOZEfHWQA1b7nFgL4nEbmEHNdU4jAjcxkROku4O04205kb5n
Loveoz3TSQNt8zalFayZAjt+JEcKuG1f5cyhYI6QwvkS/3M+CjJezuNaSmno29Lm+ToZnwUm4nIB
YkBx4r9ZDU2W8029tr5og00A5MGo1LK+unWtHBa7zuPblfSiYgXIHWU+OKrSFaA935Yb4fLXFe9S
BmApBr1gohHYos1hct5q90WPufSKIQ9WT+vJYXvW3FpseO4ZLKVnJsO7gVoQEEnWJUwyABBPQrii
F0gh++ApKZJROTuR36PsEEx4duI6U4VXMCiIcnEjvNR8Mt5Q/Vp4W4Mp5fCv+QzYkqq9EWD7QuUW
Yul6R8Hf7ZTxbUk0NfJgu8escLrgQSwMdP/kE/09vJAAslQBkNnIS7iIhWt4l5XQJBrJc+6popRE
R8ykWf25e4CliaUgbAl1tBQKivQ3tlX99WykI2XK3sTk9nsxggMjMIIDHwIBATBeMFAxEzARBgoJ
kiaJk/IsZAEZFgNPUkcxFTATBgoJkiaJk/IsZAEZFgVNSVRSRTEiMCAGA1UEAxMZTUlUUkUgQ29y
cG9yYXRpb24gUEUgQ0EtMQIKGsNtyAACAAA3/DAJBgUrDgMCGgUAoIIBmjAYBgkqhkiG9w0BCQMx
CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjA0MTcyMDQ3MTRaMCMGCSqGSIb3DQEJBDEW
BBTizelClN67bW00c6VOdlzZSytMWjBbBgkqhkiG9w0BCQ8xTjBMMAoGCCqGSIb3DQMHMA4GCCqG
SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMC
GjBtBgkrBgEEAYI3EAQxYDBeMFAxEzARBgoJkiaJk/IsZAEZFgNPUkcxFTATBgoJkiaJk/IsZAEZ
FgVNSVRSRTEiMCAGA1UEAxMZTUlUUkUgQ29ycG9yYXRpb24gUEUgQ0EtMQIKGsNq2wACAAA3+jBv
BgsqhkiG9w0BCRACCzFgoF4wUDETMBEGCgmSJomT8ixkARkWA09SRzEVMBMGCgmSJomT8ixkARkW
BU1JVFJFMSIwIAYDVQQDExlNSVRSRSBDb3Jwb3JhdGlvbiBQRSBDQS0xAgoaw2rbAAIAADf6MA0G
CSqGSIb3DQEBAQUABIIBAKFZgGrEcoG7ZPIGeD7eXPE2p+Mjy3jlRzl5p5ejz/AkR26jwn/+HZHN
uIaV8kU3c878UZP9AznBIUh7sdV8K/+kmB2KZxE41WBrjHpx8lZcbZOLJI0q6EX9NQpSbSrtFmV/
R7gsmiPbwIEnW9LaJyXF3PC1TgpSSmxhnP9drGtQE2ZiTRgA+6bYHoy9uXiagXrR5HMjBtVcDDzP
F1CPQyyFeC7mAkuIRRwmC1lugEFaVSxKd3fwGN8gFagl2KhiY8SlvVQV+qEE6xsT9uEM5A9WEgfS
KvfgRVWE8wuW1vX6qZnBFtP1GGpEz8nhQ9FXgE3iZk7nkGETT9XY9QCOL9MAAAAAAAA=

------=_NextPart_000_00B5_01CD1CB9.BDEF3370--

From amontville@tripwire.com  Tue Apr 24 13:31:23 2012
Return-Path: 
X-Original-To: sacm@ietfa.amsl.com
Delivered-To: sacm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9D6B21F85BD for ; Tue, 24 Apr 2012 13:31:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.766
X-Spam-Level: 
X-Spam-Status: No, score=-3.766 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WaANaF5FsP18 for ; Tue, 24 Apr 2012 13:31:22 -0700 (PDT)
Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe003.messaging.microsoft.com [213.199.154.141]) by ietfa.amsl.com (Postfix) with ESMTP id 6419521F85B4 for ; Tue, 24 Apr 2012 13:31:22 -0700 (PDT)
Received: from mail86-db3-R.bigfish.com (10.3.81.239) by DB3EHSOBE005.bigfish.com (10.3.84.25) with Microsoft SMTP Server id 14.1.225.23; Tue, 24 Apr 2012 20:31:21 +0000
Received: from mail86-db3 (localhost [127.0.0.1])	by mail86-db3-R.bigfish.com (Postfix) with ESMTP id 5E52E603D9	for ; Tue, 24 Apr 2012 20:31:21 +0000 (UTC)
X-SpamScore: -40
X-BigFish: VPS-40(zzbb2dI9371I542M1432N98dK148cMzz1202hz31iz1033IL8275bh8275dhz2dh2a8h668h839h944he5bh)
X-Forefront-Antispam-Report: CIP:174.47.84.216; KIP:(null); UIP:(null); IPV:NLI; H:PDXHB01.tripwire.com; RD:174-47-84-216.static.twtelecom.net; EFVD:NLI
Received: from mail86-db3 (localhost.localdomain [127.0.0.1]) by mail86-db3 (MessageSwitch) id 1335299479136491_22369; Tue, 24 Apr 2012 20:31:19 +0000 (UTC)
Received: from DB3EHSMHS019.bigfish.com (unknown [10.3.81.246])	by mail86-db3.bigfish.com (Postfix) with ESMTP id 13224240112	for ; Tue, 24 Apr 2012 20:31:19 +0000 (UTC)
Received: from PDXHB01.tripwire.com (174.47.84.216) by DB3EHSMHS019.bigfish.com (10.3.87.119) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 24 Apr 2012 20:31:17 +0000
Received: from PDXHB01.tripwire.com (172.30.0.53) by PDXED01.tripwire.com (192.168.192.5) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 24 Apr 2012 13:41:32 -0700
Received: from PDXMB02.tripwire.com ([fe80::f997:7b65:8e64:438e]) by PDXHB01.tripwire.com ([fe80::d495:98d2:7df4:2154%11]) with mapi id 14.01.0355.002; Tue, 24 Apr 2012 13:31:14 -0700
From: Adam Montville 
To: "'sacm@ietf.org'" 
Thread-Topic: [sacm] Status Update Request
Thread-Index: AQHNFoE4f7sr7kkdS02JMJ0z7pzzGZaqhWAA
Date: Tue, 24 Apr 2012 20:31:13 +0000
Message-ID: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.14.0.111121
x-originating-ip: [172.16.97.107]
x-exclaimer-md-config: 79afcaa7-fdf4-4fa6-abe0-afeaa4640a4f
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: tripwire.com
Subject: Re: [sacm] Status Update Request
X-BeenThere: sacm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Apr 2012 20:31:23 -0000

All:

A bit of time has passed since David sent out the most recent introductory
document, and there does not seem to be much activity with respect to the
structure of this document.  Should we assume that silence is, in effect,
agreement to the abstract and skeleton format?

I would also like to see some discussion about the charter happen on this
list.  It seems reasonable to start thinking about how we move the charter
forward even though we may not have the complete use case document yet.

Regards,

Adam

On 4/9/12 11:47 AM, "Adam Montville"  wrote:

>Hi Dave,
>
>Thanks for sending this out.  I like the abstract and the structure of the
>document so far, so no further comments from me on the abstract.  Are you
>planning to create a first pass at a complete list of use cases for the
>document?
>
>Adam
>
>On 4/9/12 11:41 AM, "Waltermire, David A." 
>wrote:
>
>>Please find a skeleton I-D of the use case document attached with updates
>>to the abstract based on the feedback to date.  If there are no other
>>comments on the abstract I'll start work on the introduction and we can
>>start breaking out use cases and authors for each use case.
>>
>>Sincerely,
>>Dave
>>
>>
>>> -----Original Message-----
>>> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of
>>> Adam Montville
>>> Sent: Monday, April 09, 2012 2:33 PM
>>> To: 'sacm@ietf.org'
>>> Subject: [sacm] Status Update Request
>>>=20
>>> All:
>>>=20
>>> The list seems to be rather quiet since the close of IETF 83 more than
>>> a week ago.  Actions coming out of the side meeting held on March 24
>>> included:
>>>=20
>>> 1. Use Case document first draft by middle of April 2. Use Case initial
>>> revision by end of April 3. Start of a charter discussion around middle
>>> of April (after first draft Use Case release)
>>>=20
>>> Dave Waltermire has offered to lead development of the Use Case
>>> document and Kent Landfield has offered to lead the subsequent charter
>>> discussion.
>>>=20
>>> Dave/Kent: Do either of you have an update you can share?
>>>=20
>>> Adam
>>>=20
>>>=20
>>>=20
>>> _______________________________________________
>>> sacm mailing list
>>> sacm@ietf.org
>>> https://www.ietf.org/mailman/listinfo/sacm
>
>
>_______________________________________________
>sacm mailing list
>sacm@ietf.org
>https://www.ietf.org/mailman/listinfo/sacm
>



From solin@farnamhallventures.com  Tue Apr 24 14:51:44 2012
Return-Path: 
X-Original-To: sacm@ietfa.amsl.com
Delivered-To: sacm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13C8F11E8087 for ; Tue, 24 Apr 2012 14:51:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.198
X-Spam-Level: 
X-Spam-Status: No, score=-3.198 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_27=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D5dB2mcKu72C for ; Tue, 24 Apr 2012 14:51:39 -0700 (PDT)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9EEDB11E8085 for ; Tue, 24 Apr 2012 14:51:38 -0700 (PDT)
Received: by yhkk25 with SMTP id k25so930814yhk.31 for ; Tue, 24 Apr 2012 14:51:38 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:message-id:date:from:organization:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type:x-gm-message-state; bh=9G4Okyaff2zXwXSvu93wN6kS+nq79JA0JKzsJMJWjnc=; b=Ssz2ZVaYghNf/bpU+iLRKH79Ii6yJp7rCVXr1ZbQoisN0Y4W04scNE9YE7LWo5r7JM nUZiWB89dixCNVfwMFYi8liPPtP/gLG/W7R8FwLjcthXrBGMpbJBHcukTQZ1ARUSF6vE X4wGwdth812Z+gqeZH2U3V+HUWs5b1NYRNaQJceh6bkaKhI9xLSdJ0gMdRN/cnWse4ML 3L71nXiakEQn7XdAwuGHiw2P/XY6fdB9L/jXjwcjO27QIjw8GfoFD+ukC7msY4FceTIF bIgb9KgANcY7IjP9rhRo4craNbmavp7JyVZdeV+k0nIpV1G50sZFT5dJser2deNdCuHs Onxg==
Received: by 10.60.4.134 with SMTP id k6mr248942oek.19.1335304297775; Tue, 24 Apr 2012 14:51:37 -0700 (PDT)
Received: from [192.168.0.113] (cpe-70-123-137-202.austin.res.rr.com. [70.123.137.202]) by mx.google.com with ESMTPS id bd10sm19281629obb.15.2012.04.24.14.51.35 (version=SSLv3 cipher=OTHER); Tue, 24 Apr 2012 14:51:36 -0700 (PDT)
Sender: David Solin 
Message-ID: <4F972066.9090901@joval.org>
Date: Tue, 24 Apr 2012 16:51:34 -0500
From: David Solin 
Organization: jOVAL
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: Tim Keanini 
References:  <4F8364DF.5090809@joval.org>  <4F84649F.1070406@joval.org> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------040906010109050001090307"
X-Gm-Message-State: ALoCoQmm8hT+eIJlg9RD2t51NXjPG6+QnU4eyav1UdKd5IZPpJvlO+CZU1uWtrySYMfNUp1W7We1
Cc: sacm@ietf.org
Subject: Re: [sacm] Status Update Request
X-BeenThere: sacm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Apr 2012 21:51:44 -0000

This is a multi-part message in MIME format.
--------------040906010109050001090307
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

All I'm saying is that CIM is already widely used for exactly the 
purposes and use-cases specified by AI.  From what I can determine, AI 
is not inherently capable of dealing with issues like reconciliation, 
but there are existing well-known practices around CIM.  If CIM's 
attributes are insufficient for our needs, it is extensible by design.  
But I think the CIM class model is more than sufficient for anything we 
can dream up.

If every potential user designs a new standard, then there are, in 
effect, no standards.  My opinion is that since we can choose between an 
immature proposal (AI), and a mature widely-adopted standard (CIM), the 
choice should be obvious.

Anyway, are Tim and I the only people with thoughts on the matter?  I 
was hoping that perhaps David Waltermire might be able to explain the 
rationale behind proposing a new standard.

Regards,
--David Solin

On 4/19/2012 3:05 PM, Tim Keanini wrote:
>
> I would argue that it is not a problem of uniqueness but a machine 
> learning problem of computing inter-domain equivalence (which may or 
> may not be unique).  I say this only because in these case we are 
> talking about computing the syntactical equivalence but certainly in 
> the future we could also do this based on semantic equivalence.
>
> And you are so right in that CIM would require more schema to aid in 
> the task of synthesis with sacm/scap.  I'm completely in agreement at 
> the technical level.    In fact, most of the fields in AI can be 
> computed from the CIM model (being a subset).
>
> What I am sensitive to here is the administrative realms and political 
> realms of both standards.  If the solution couples the two standards 
> such that one is impaired by the others progress or dormancy, bad 
> design, no donut.
>
> --tk
>
> --
>
> Tim "TK" Keanini, CTO    ...    nCircle Inc.   ...   mbl (415) 
> 328-2722  ...
>
> *From:*David Solin [mailto:solin@farnamhallventures.com] 
>  *On Behalf Of *David Solin
> *Sent:* Tuesday, April 10, 2012 11:50 AM
> *To:* Tim Keanini
> *Cc:* sacm@ietf.org 
> *Subject:* Re: [sacm] Status Update Request
>
> Hi Tim,
>
> Addressing the problem of uniqueness certainly does not require an 
> entirely new data model.  Existing CMDBs have to solve the problem of 
> multiple discovery sources, as each product interacting with it is 
> potentially another discovery source.  BMC's Atrium CMDB, for 
> instance, extends the CIM schema with a reconciliation ID that is used 
> for this purpose, and I imagine that's probably not an uncommon 
> solution.  There's no reason we can't have an Asset Identification 
> specification that consists purely of an extension of CIM -- where we 
> can add, for instance, a CPE property to existing classes (e.g., 
> OperatingSystem, DatabaseSystem ... or perhaps just to the System 
> parent class?).  Indeed, perhaps that's what you're suggesting?
>
> To my eye, the AI specification looks largely like a subset of CIM, 
> except with the addition of the specialized ai:website object (which 
> feels like it should be unnecessary).  Why do we want to reinvent the 
> wheel?
>
> Regards,
> --David
>
> On 4/10/2012 10:36 AM, Tim Keanini wrote:
>
> There are at least two considerations:
>
> -Inter-domain multi-sensor data fusion and synthesis
>
> -Limitations of discovery (instance data resolution)
>
> *Inter-domain multi-sensor data fusion and synthesis*
>
> This is for all practical purposes the inverse-functional-property or 
> primary key syntax match problem.
>
> The metadata in AI is designed with the other SCAP metadata in mind 
> whereas CIM was not and while they may share common keys like IP 
> address to perform a join, more and more this is not a stable 
> characteristic of the asset in either domain.  Another consideration 
> here is that CIM would not have in it something like a CPE identifier, 
> very common key for synthesis across domains within the SCAP family.  
> My suggestion here is that we not look for a single domain to identify 
> an asset but to ensure that all the data domains (AI, CIM, etc) have 
> in them enough boundary objects to "join" or synthesize multiple 
> domains.  We should ensure that all information domains have in it a 
> rich set of stable characteristics that afford syntactical matching of 
> the metadata for the purposes of Inter-domain multi-sensor data fusion 
> and synthesis
>
> *Limitations of discovery (instance data resolution): Authenticated 
> and Unauthenticated Discovery *
>
> Remote automated scanning comes in at least two flavors, 
> authenticated-scanning and unauthenticated-scanning.  We must keep 
> this in mind as we look to the design or borrow these metadata formats 
> (AI, CIM, etc).  Most if not all CMDB assumes the old network 
> management mindset of nodes-under-management and 
> node-not-under-management.  The former having an agent installed or 
> some authentication/authorization provided, the latter assumes an 
> assessment of the target via its target surface in an unauthenticated 
> manner.  I raise this issue once again because OVAL for example makes 
> no provision for the assessment to take place in an unauthenticated 
> manner.   We need to keep this in mind as we look to populate the 
> metadata of AI as certain fields will only be valid for authenticated 
> scanning or an agent.  I'm a vendor that has both types of scanners 
> and I must say that for reasons I will not get into here, customers 
> deploy unauthenticated scanners across their entire enterprise and 
> authenticated scanners in targeted scopes.  I raise this issue because 
> time and time again, customers come back to us with the 
> unauthenticated scanners having much more identification of end-point 
> assets than any other authenticated scanner.  This is a sidebar but I 
> wanted to share this experience having been a supplier of this 
> technology for the past 12 years.
>
> --
>
> Tim "TK" Keanini, CTO    ...    nCircle Inc.   ...   mbl (415) 
> 328-2722  ...
>
> *From:*sacm-bounces@ietf.org 
> [mailto:sacm-bounces@ietf.org] 
> *On Behalf Of *David Solin
> *Sent:* Monday, April 09, 2012 5:38 PM
> *To:* sacm@ietf.org 
> *Subject:* Re: [sacm] Status Update Request
>
> That is very neat, but I also have a question on the original topic...
>
> Was there any discussion at the meeting in Paris on Asset 
> Identification vs. CIM, or has anyone identified a use-case for AI for 
> which CIM is not appropriate?  For the sake of making SACM easily 
> adoptable by large enterprises with existing CMDB implementations, I 
> strongly advocate abandoning AI in favor of CIM.  I'd be happy to 
> discuss how BMC, IBM, HP, CA, etc. have been making CIM the 
> centerpiece of their systems management offerings for most of the past 
> decade.
>
> Regards,
> --David Solin
>
>
> -- 
>
> jOVAL.org: OVAL implemented in Java.
> /Scan any machine from any machine. For free!/
> Learn More | Features 
> | Download 
> 
>
>
>
> On 4/9/2012 3:43 PM, Kent_Landfield@McAfee.com 
>  wrote:
>
> What do you know....  SACM is already being valuable. ;-)
>
> *Kent Landfield*
> Director Content Strategy, Architecture and Standards
>
> *McAfee | An Intel Company*
> 5000 Headquarters Dr.
> Plano, Texas 75024
>
> Direct: +1.972.963.7096
> Mobile: +1.817.637.8026
> *Web: *www.mcafee.com 
>
> *From: *"Polk, William T."  >
> *Date: *Mon, 9 Apr 2012 15:22:25 -0500
> *To: *Tim Keanini  >, David Waltermire 
> >, Adam 
> Montville >, 
> "sacm@ietf.org "  >
> *Subject: *Re: [sacm] Status Update Request
>
>     I wish someone would have told me this 14 RFCs ago....
>
>     Tim
>
>     ________________________________________
>
>     From: sacm-bounces@ietf.org 
>     [sacm-bounces@ietf.org ] On Behalf
>     Of Tim Keanini [tkeanini@ncircle.com ]
>
>     Sent: Monday, April 09, 2012 4:14 PM
>
>     To: Waltermire, David A.; Adam Montville; sacm@ietf.org
>     
>
>     Subject: Re: [sacm] Status Update Request
>
>     We will certainly need a few ascii diagrams so let me share this link:
>
>     http://www.asciiflow.com/
>
>     --tk
>
>     --
>
>     Tim "TK" Keanini, CTO    ...    nCircle Inc.
>
>     -----Original Message-----
>
>     From: sacm-bounces@ietf.org 
>     [mailto:sacm-bounces@ietf.org] On Behalf Of
>
>     Waltermire, David A.
>
>     Sent: Monday, April 09, 2012 2:04 PM
>
>     To: Adam Montville; 'sacm@ietf.org '
>
>     Subject: Re: [sacm] Status Update Request
>
>     I can take a stab at that.  It will be useful at minimum to start some
>
>     discussion.
>
>     Dave
>
>         -----Original Message-----
>
>         From: Adam Montville [mailto:amontville@tripwire.com]
>
>         Sent: Monday, April 09, 2012 2:48 PM
>
>         To: Waltermire, David A.; 'sacm@ietf.org
>         '
>
>         Subject: Re: Status Update Request
>
>         Hi Dave,
>
>         Thanks for sending this out.  I like the abstract and the
>         structure of
>
>         the document so far, so no further comments from me on the
>         abstract.
>
>         Are you planning to create a first pass at a complete list of use
>
>         cases for the document?
>
>         Adam
>
>         On 4/9/12 11:41 AM, "Waltermire, David A."
>         >
>
>         wrote:
>
>         >Please find a skeleton I-D of the use case document attached with
>
>         >updates to the abstract based on the feedback to date.  If
>         there are
>
>         no
>
>         >other comments on the abstract I'll start work on the
>         introduction
>
>         >and we can start breaking out use cases and authors for each use
>
>     case.
>
>         >
>
>         >Sincerely,
>
>         >Dave
>
>         >
>
>         >
>
>         >> -----Original Message-----
>
>         >> From: sacm-bounces@ietf.org 
>         [mailto:sacm-bounces@ietf.org] On
>
>         >> Behalf Of Adam Montville
>
>         >> Sent: Monday, April 09, 2012 2:33 PM
>
>         >> To: 'sacm@ietf.org '
>
>         >> Subject: [sacm] Status Update Request
>
>         >>
>
>         >> All:
>
>         >>
>
>         >> The list seems to be rather quiet since the close of IETF
>         83 more
>
>         >> than a week ago.  Actions coming out of the side meeting
>         held on
>
>         >> March 24
>
>         >> included:
>
>         >>
>
>         >> 1. Use Case document first draft by middle of April 2. Use Case
>
>         >> initial revision by end of April 3. Start of a charter
>         discussion
>
>         >> around middle of April (after first draft Use Case release)
>
>         >>
>
>         >> Dave Waltermire has offered to lead development of the Use Case
>
>         >> document and Kent Landfield has offered to lead the subsequent
>
>         >> charter discussion.
>
>         >>
>
>         >> Dave/Kent: Do either of you have an update you can share?
>
>         >>
>
>         >> Adam
>
>         >>
>
>         >>
>
>         >>
>
>         >> _______________________________________________
>
>         >> sacm mailing list
>
>         >> sacm@ietf.org 
>
>         >> https://www.ietf.org/mailman/listinfo/sacm
>
>     _______________________________________________
>
>     sacm mailing list
>
>     sacm@ietf.org 
>
>     https://www.ietf.org/mailman/listinfo/sacm
>
>     _______________________________________________
>
>     sacm mailing list
>
>     sacm@ietf.org 
>
>     https://www.ietf.org/mailman/listinfo/sacm
>
>     _______________________________________________
>
>     sacm mailing list
>
>     sacm@ietf.org 
>
>     https://www.ietf.org/mailman/listinfo/sacm
>
>
>
>
>
> _______________________________________________
> sacm mailing list
> sacm@ietf.org  
> https://www.ietf.org/mailman/listinfo/sacm
>
> -- 
>
> jOVAL.org: OVAL implemented in Java.
> /Scan any machine from any machine. For free!/
> Learn More | Features 
> | Download 
> 
>


-- 

jOVAL.org: OVAL implemented in Java.
/Scan any machine from any machine. For free!/
Learn More  | Features 
 | Download 



--------------040906010109050001090307
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    All I'm saying is that CIM is already widely used for exactly the
    purposes and use-cases specified by AI.  From what I can determine,
    AI is not inherently capable of dealing with issues like
    reconciliation, but there are existing well-known practices around
    CIM.  If CIM's attributes are insufficient for our needs, it is
    extensible by design.  But I think the CIM class model is more than
    sufficient for anything we can dream up.

    

    If every potential user designs a new standard, then there are, in
    effect, no standards.  My opinion is that since we can choose
    between an immature proposal (AI), and a mature widely-adopted
    standard (CIM), the choice should be obvious.

    

    Anyway, are Tim and I the only people with thoughts on the matter? 
    I was hoping that perhaps David Waltermire might be able to explain
    the rationale behind proposing a new standard.

    

    Regards,

    --David Solin

    

    On 4/19/2012 3:05 PM, Tim Keanini wrote:
    

      
      
      
      

        
I
            would argue that it is not a problem of uniqueness but a
            machine learning problem of computing inter-domain
            equivalence (which may or may not be unique).  I say this
            only because in these case we are talking about computing
            the syntactical equivalence but certainly in the future we
            could also do this based on semantic equivalence.  

        
 

        
And
            you are so right in that CIM would require more schema to
            aid in the task of synthesis with sacm/scap.  I’m completely
            in agreement at the technical level.    In fact, most of the
            fields in AI can be computed from the CIM model (being a
            subset).  

        
 

        
What
            I am sensitive to here is the administrative realms and
            political realms of both standards.  If the solution couples
            the two standards such that one is impaired by the others
            progress or dormancy, bad design, no donut.  

        
 

        
--tk

        
 

        

          
--

          
Tim
              "TK" Keanini, CTO    …    nCircle Inc.   …   mbl (415)
              328-2722  …

        

        
 

        

          

            
From:
                David Solin [mailto:solin@farnamhallventures.com]
                On Behalf Of David Solin

                Sent: Tuesday, April 10, 2012 11:50 AM

                To: Tim Keanini

                Cc: sacm@ietf.org

                Subject: Re: [sacm] Status Update Request

          

        

        
 

        
Hi Tim,

          

          Addressing the problem of uniqueness certainly does not
          require an entirely new data model.  Existing CMDBs have to
          solve the problem of multiple discovery sources, as each
          product interacting with it is potentially another discovery
          source.  BMC's Atrium CMDB, for instance, extends the CIM
          schema with a reconciliation ID that is used for this purpose,
          and I imagine that's probably not an uncommon solution. 
          There's no reason we can't have an Asset Identification
          specification that consists purely of an extension of CIM --
          where we can add, for instance, a CPE property to existing
          classes (e.g., OperatingSystem, DatabaseSystem ... or perhaps
          just to the System parent class?).  Indeed, perhaps that's
          what you're suggesting?

          

          To my eye, the AI specification looks largely like a subset of
          CIM, except with the addition of the specialized ai:website
          object (which feels like it should be unnecessary).  Why do we
          want to reinvent the wheel?

          

          Regards,

          --David

          

          On 4/10/2012 10:36 AM, Tim Keanini wrote: 

        
There
            are at least two considerations: 

        
-          Inter-domain
            multi-sensor data fusion and synthesis

        
-          Limitations
            of discovery (instance data resolution)

        
 

        
Inter-domain
              multi-sensor data fusion and synthesis

        
This
            is for all practical purposes the
            inverse-functional-property or primary key syntax match
            problem.

        
The
            metadata in AI is designed with the other SCAP metadata in
            mind whereas CIM was not and while they may share common
            keys like IP address to perform a join, more and more this
            is not a stable characteristic of the asset in either
            domain.  Another consideration here is that CIM would not
            have in it something like a CPE identifier, very common key
            for synthesis across domains within the SCAP family.  My
            suggestion here is that we not look for a single domain to
            identify an asset but to ensure that all the data domains
            (AI, CIM, etc) have in them enough boundary objects to
            “join” or synthesize multiple domains.  We should ensure
            that all information domains have in it a rich set of stable
            characteristics that afford syntactical matching of the
            metadata for the purposes of Inter-domain multi-sensor data
            fusion and synthesis

        
 

        
 

        
Limitations
              of discovery (instance data resolution): Authenticated and
              Unauthenticated Discovery 

        
Remote
            automated scanning comes in at least two flavors,
            authenticated-scanning and unauthenticated-scanning.  We
            must keep this in mind as we look to the design or borrow
            these metadata formats (AI, CIM, etc).  Most if not all CMDB
            assumes the old network management mindset of
            nodes-under-management and node-not-under-management.  The
            former having an agent installed or some
            authentication/authorization provided, the latter assumes an
            assessment of the target via its target surface in an
            unauthenticated manner.  I raise this issue once again
            because OVAL for example makes no provision for the
            assessment to take place in an unauthenticated manner.   We
            need to keep this in mind as we look to populate the
            metadata of AI as certain fields will only be valid for
            authenticated scanning or an agent.  I’m a vendor that has
            both types of scanners and I must say that for reasons I
            will not get into here, customers deploy unauthenticated
            scanners across their entire enterprise and authenticated
            scanners in targeted scopes.  I raise this issue because
            time and time again, customers come back to us with the
            unauthenticated scanners having much more identification of
            end-point assets than any other authenticated scanner.  This
            is a sidebar but I wanted to share this experience having
            been a supplier of this technology for the past 12 years. 
              

        
 

        
 

        

          
--

          
Tim
              "TK" Keanini, CTO    …    nCircle Inc.   …   mbl (415)
              328-2722  …

        

        
 

        

          

            
From:
              sacm-bounces@ietf.org
              [mailto:sacm-bounces@ietf.org]
                On Behalf Of David Solin

                Sent: Monday, April 09, 2012 5:38 PM

                To: sacm@ietf.org

                Subject: Re: [sacm] Status Update Request

          

        

        
 

        
That is very
          neat, but I also have a question on the original topic...

          

          Was there any discussion at the meeting in Paris on Asset
          Identification vs. CIM, or has anyone identified a use-case
          for AI for which CIM is not appropriate?  For the sake of
          making SACM easily adoptable by large enterprises with
          existing CMDB implementations, I strongly advocate abandoning
          AI in favor of CIM.  I'd be happy to discuss how BMC, IBM, HP,
          CA, etc. have been making CIM the centerpiece of their systems
          management offerings for most of the past decade.

          

          Regards,

          --David Solin

          

          

          

        

          
-- 

          
jOVAL.org:
              OVAL implemented in Java.

            Scan
                any machine from any machine. For free!

            Learn
                More
              | Features
              | Download
            

        

        


          

          On 4/9/2012 3:43 PM, Kent_Landfield@McAfee.com
          wrote: 

        

          

            

              
What do you know….  SACM is already
                being valuable. ;-)

            

            

              
 

            

            

              

                
Kent
                      Landfield

                    Director Content
                      Strategy, Architecture and Standards

                    

                    McAfee
                        | An Intel Company

                    5000 Headquarters Dr.

                    Plano, Texas 75024

                    

                    Direct:
                      +1.972.963.7096 

                    Mobile:
                      +1.817.637.8026

                    Web: www.mcafee.com

              

            

          

        

        

          
 

        

        

          
From:
              "Polk,
              William T." <william.polk@nist.gov>

              Date: Mon, 9 Apr 2012 15:22:25 -0500

              To: Tim Keanini <tkeanini@ncircle.com>,
              David Waltermire <david.waltermire@nist.gov>,
              Adam Montville <amontville@tripwire.com>,
              "sacm@ietf.org"
              <sacm@ietf.org>

              Subject: Re: [sacm] Status Update Request

        

        

          
 

        

        

          

            

              

                
I wish someone would have told me
                  this 14 RFCs ago....

              

              

                
 

              

              

                
Tim

              

              

                
________________________________________

              

              
              

                
Sent: Monday, April 09, 2012 4:14
                  PM

              

              

                
To: Waltermire, David A.; Adam
                  Montville; sacm@ietf.org

              

              

                
Subject: Re: [sacm] Status Update
                  Request

              

              

                
 

              

              

                
We will certainly need a few ascii
                  diagrams so let me share this link:

              

              
              

                
 

              

              

                
--tk

              

              

                
 

              

              

                
--

              

              

                
Tim "TK" Keanini,
                  CTO    ...    nCircle Inc.

              

              

                
 

              

              

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

              

              
              

                
Waltermire, David A.

              

              

                
Sent: Monday, April 09, 2012 2:04
                  PM

              

              

                
To: Adam Montville; 'sacm@ietf.org'

              

              

                
Subject: Re: [sacm] Status Update
                  Request

              

              

                
 

              

              

                
I can take a stab at that.  It will
                  be useful at minimum to start some

              

              

                
discussion.

              

              

                
Dave

              

              

                
 

              

              

                

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

                

                

                  
From: Adam Montville [mailto:amontville@tripwire.com]

                

                

                  
Sent: Monday, April 09, 2012 2:48
                    PM

                

                

                  
To: Waltermire, David A.; 'sacm@ietf.org'

                

                

                  
Subject: Re: Status Update
                    Request

                

                

                  
 

                

                

                  
Hi Dave,

                

                

                  
 

                

                

                  
Thanks for sending this out.  I
                    like the abstract and the structure of

                

              

              

                
 

              

              

                

                  
the document so far, so no
                    further comments from me on the abstract.

                

                

                  
Are you planning to create a
                    first pass at a complete list of use

                

                

                  
cases for the document?

                

                

                  
 

                

                

                  
Adam

                

                

                  
 

                

                

                  
On 4/9/12 11:41 AM, "Waltermire,
                    David A." <david.waltermire@nist.gov>

                

                

                  
wrote:

                

                

                  
 

                

                

                  
>Please find a skeleton I-D of
                    the use case document attached with

                

                

                  
>updates to the abstract based
                    on the feedback to date.  If there are

                

                

                  
no

                

                

                  
>other comments on the
                    abstract I'll start work on the introduction

                

                

                  
>and we can start breaking out
                    use cases and authors for each use

                

              

              

                
case.

              

              

                

                  
> 

                

                

                  
>Sincerely,

                

                

                  
>Dave

                

                

                  
> 

                

                

                  
> 

                

                

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

                

                
                

                  
>> Behalf Of Adam Montville

                

                

                  
>> Sent: Monday, April 09,
                    2012 2:33 PM

                

                

                  
>> To: 'sacm@ietf.org'

                

                

                  
>> Subject: [sacm] Status
                    Update Request

                

                

                  
>> 

                

                

                  
>> All:

                

                

                  
>> 

                

                

                  
>> The list seems to be
                    rather quiet since the close of IETF 83 more

                

                

                  
>> than a week
                    ago.  Actions coming out of the side meeting held on

                

                

                  
>> March 24

                

                

                  
>> included:

                

                

                  
>> 

                

                

                  
>> 1. Use Case document
                    first draft by middle of April 2. Use Case

                

                

                  
>> initial revision by end
                    of April 3. Start of a charter discussion

                

                

                  
>> around middle of April
                    (after first draft Use Case release)

                

                

                  
>> 

                

                

                  
>> Dave Waltermire has
                    offered to lead development of the Use Case

                

                

                  
>> document and Kent
                    Landfield has offered to lead the subsequent

                

                

                  
>> charter discussion.

                

                

                  
>> 

                

                

                  
>> Dave/Kent: Do either of
                    you have an update you can share?

                

                

                  
>> 

                

                

                  
>> Adam

                

                

                  
>> 

                

                

                  
>> 

                

                

                  
>> 

                

                

                  
>>
                    _______________________________________________

                

                

                  
>> sacm mailing list

                

                
                
                

                  
 

                

              

              

                
 

              

              

                
_______________________________________________

              

              

                
sacm mailing list

              

              
              
              

                
_______________________________________________

              

              

                
sacm mailing list

              

              
              
              

                
_______________________________________________

              

              

                
sacm mailing list

              

              
              
              

                
 

              

            

          

        

        


          

          

          

          

        
_______________________________________________

        
sacm mailing list

        
sacm@ietf.org

        
https://www.ietf.org/mailman/listinfo/sacm

        
 

        
 

        

          
-- 

          
jOVAL.org:
              OVAL implemented in Java.

            Scan
                any machine from any machine. For free!

            Learn
                More
              | Features
              | Download
              

        

      

    

    

    

    
-- 

      
 jOVAL.org:
          OVAL implemented in Java.

        Scan any machine from any machine. For
          free!

        Learn More
        | Features
        | Download
      

    

  


--------------040906010109050001090307--

From david.waltermire@nist.gov  Tue Apr 24 21:13:27 2012
Return-Path: 
X-Original-To: sacm@ietfa.amsl.com
Delivered-To: sacm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 897A411E8074 for ; Tue, 24 Apr 2012 21:13:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.82
X-Spam-Level: 
X-Spam-Status: No, score=-4.82 tagged_above=-999 required=5 tests=[AWL=-0.575,  BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_27=0.6, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lwR0j4pZmqFG for ; Tue, 24 Apr 2012 21:13:20 -0700 (PDT)
Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id A4CFD11E808E for ; Tue, 24 Apr 2012 21:13:18 -0700 (PDT)
Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 25 Apr 2012 00:13:10 -0400
Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Wed, 25 Apr 2012 00:13:16 -0400
From: "Waltermire, David A." 
To: David Solin , Tim Keanini 
Date: Wed, 25 Apr 2012 00:13:15 -0400
Thread-Topic: [sacm] Status Update Request
Thread-Index: Ac0iZD3Hd6ffa5CsRtGE+bi+6Y3G5gAMn1Xg
Message-ID: 
References:  <4F8364DF.5090809@joval.org>  <4F84649F.1070406@joval.org>  <4F972066.9090901@joval.org>
In-Reply-To: <4F972066.9090901@joval.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_D7A0423E5E193F40BE6E94126930C4930B98C82362MBCLUSTERxcha_"
MIME-Version: 1.0
Cc: "sacm@ietf.org" 
Subject: Re: [sacm] Status Update Request
X-BeenThere: sacm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 25 Apr 2012 04:13:27 -0000

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

Ok.  I'll bite. ;-)  First off, I am not interested in creating a new stand=
ard that competes with CIM or any of the other data models capturing asset =
information.  If fact, if there is a better solution I'd like to explore it=
.  This thread has been useful in exploring some possibilities.

Speaking to Asset Identification, one of the major reasons we created the s=
pecification was to provide a mapping mechanism that can synthesize data ac=
ross any underlying systems management protocol (e.g. WEBM, SNMP, NetConf, =
etc) and data format (e.g. CIM, MIB, Yang, SCAP, etc.)  We wanted something=
 that would be information domain neutral.  In my mind the controlled vocab=
ulary approach used in Asset Identification provides part of a semantic abs=
traction over all of these things.  It enables data synthesis within a hete=
rogeneous environment of tools implementing a variety of standards-based ap=
proaches.

I hope this provides more context.

Sincerely,
Dave

From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Dav=
id Solin
Sent: Tuesday, April 24, 2012 5:52 PM
To: Tim Keanini
Cc: sacm@ietf.org
Subject: Re: [sacm] Status Update Request

All I'm saying is that CIM is already widely used for exactly the purposes =
and use-cases specified by AI.  From what I can determine, AI is not inhere=
ntly capable of dealing with issues like reconciliation, but there are exis=
ting well-known practices around CIM.  If CIM's attributes are insufficient=
 for our needs, it is extensible by design.  But I think the CIM class mode=
l is more than sufficient for anything we can dream up.

If every potential user designs a new standard, then there are, in effect, =
no standards.  My opinion is that since we can choose between an immature p=
roposal (AI), and a mature widely-adopted standard (CIM), the choice should=
 be obvious.

Anyway, are Tim and I the only people with thoughts on the matter?  I was h=
oping that perhaps David Waltermire might be able to explain the rationale =
behind proposing a new standard.

Regards,
--David Solin

On 4/19/2012 3:05 PM, Tim Keanini wrote:
I would argue that it is not a problem of uniqueness but a machine learning=
 problem of computing inter-domain equivalence (which may or may not be uni=
que).  I say this only because in these case we are talking about computing=
 the syntactical equivalence but certainly in the future we could also do t=
his based on semantic equivalence.

And you are so right in that CIM would require more schema to aid in the ta=
sk of synthesis with sacm/scap.  I'm completely in agreement at the technic=
al level.    In fact, most of the fields in AI can be computed from the CIM=
 model (being a subset).

What I am sensitive to here is the administrative realms and political real=
ms of both standards.  If the solution couples the two standards such that =
one is impaired by the others progress or dormancy, bad design, no donut.

--tk

--
Tim "TK" Keanini, CTO    ...    nCircle Inc.   ...   mbl (415) 328-2722  ..=
.

From: David Solin [mailto:solin@farnamhallventures.com] On Behalf Of David Solin
Sent: Tuesday, April 10, 2012 11:50 AM
To: Tim Keanini
Cc: sacm@ietf.org
Subject: Re: [sacm] Status Update Request

Hi Tim,

Addressing the problem of uniqueness certainly does not require an entirely=
 new data model.  Existing CMDBs have to solve the problem of multiple disc=
overy sources, as each product interacting with it is potentially another d=
iscovery source.  BMC's Atrium CMDB, for instance, extends the CIM schema w=
ith a reconciliation ID that is used for this purpose, and I imagine that's=
 probably not an uncommon solution.  There's no reason we can't have an Ass=
et Identification specification that consists purely of an extension of CIM=
 -- where we can add, for instance, a CPE property to existing classes (e.g=
., OperatingSystem, DatabaseSystem ... or perhaps just to the System parent=
 class?).  Indeed, perhaps that's what you're suggesting?

To my eye, the AI specification looks largely like a subset of CIM, except =
with the addition of the specialized ai:website object (which feels like it=
 should be unnecessary).  Why do we want to reinvent the wheel?

Regards,
--David

On 4/10/2012 10:36 AM, Tim Keanini wrote:
There are at least two considerations:

-        Inter-domain multi-sensor data fusion and synthesis

-        Limitations of discovery (instance data resolution)

Inter-domain multi-sensor data fusion and synthesis
This is for all practical purposes the inverse-functional-property or prima=
ry key syntax match problem.
The metadata in AI is designed with the other SCAP metadata in mind whereas=
 CIM was not and while they may share common keys like IP address to perfor=
m a join, more and more this is not a stable characteristic of the asset in=
 either domain.  Another consideration here is that CIM would not have in i=
t something like a CPE identifier, very common key for synthesis across dom=
ains within the SCAP family.  My suggestion here is that we not look for a =
single domain to identify an asset but to ensure that all the data domains =
(AI, CIM, etc) have in them enough boundary objects to "join" or synthesize=
 multiple domains.  We should ensure that all information domains have in i=
t a rich set of stable characteristics that afford syntactical matching of =
the metadata for the purposes of Inter-domain multi-sensor data fusion and =
synthesis


Limitations of discovery (instance data resolution): Authenticated and Unau=
thenticated Discovery
Remote automated scanning comes in at least two flavors, authenticated-scan=
ning and unauthenticated-scanning.  We must keep this in mind as we look to=
 the design or borrow these metadata formats (AI, CIM, etc).  Most if not a=
ll CMDB assumes the old network management mindset of nodes-under-managemen=
t and node-not-under-management.  The former having an agent installed or s=
ome authentication/authorization provided, the latter assumes an assessment=
 of the target via its target surface in an unauthenticated manner.  I rais=
e this issue once again because OVAL for example makes no provision for the=
 assessment to take place in an unauthenticated manner.   We need to keep t=
his in mind as we look to populate the metadata of AI as certain fields wil=
l only be valid for authenticated scanning or an agent.  I'm a vendor that =
has both types of scanners and I must say that for reasons I will not get i=
nto here, customers deploy unauthenticated scanners across their entire ent=
erprise and authenticated scanners in targeted scopes.  I raise this issue =
because time and time again, customers come back to us with the unauthentic=
ated scanners having much more identification of end-point assets than any =
other authenticated scanner.  This is a sidebar but I wanted to share this =
experience having been a supplier of this technology for the past 12 years.


--
Tim "TK" Keanini, CTO    ...    nCircle Inc.   ...   mbl (415) 328-2722  ..=
.

From: sacm-bounces@ietf.org [mailto:sacm-boun=
ces@ietf.org] On Behalf Of David Sol=
in
Sent: Monday, April 09, 2012 5:38 PM
To: sacm@ietf.org
Subject: Re: [sacm] Status Update Request

That is very neat, but I also have a question on the original topic...

Was there any discussion at the meeting in Paris on Asset Identification vs=
. CIM, or has anyone identified a use-case for AI for which CIM is not appr=
opriate?  For the sake of making SACM easily adoptable by large enterprises=
 with existing CMDB implementations, I strongly advocate abandoning AI in f=
avor of CIM.  I'd be happy to discuss how BMC, IBM, HP, CA, etc. have been =
making CIM the centerpiece of their systems management offerings for most o=
f the past decade.

Regards,
--David Solin



--

jOVAL.org: OVAL implemented in Java.
Scan any machine from any machine. For free!
Learn More | Features=
 | Download


On 4/9/2012 3:43 PM, Kent_Landfield@McAfee.com wrote:
What do you know....  SACM is already being valuable. ;-)

Kent Landfield
Director Content Strategy, Architecture and Standards

McAfee | An Intel Company
5000 Headquarters Dr.
Plano, Texas 75024

Direct: +1.972.963.7096
Mobile: +1.817.637.8026
Web: www.mcafee.com

From: "Polk, William T." >
Date: Mon, 9 Apr 2012 15:22:25 -0500
To: Tim Keanini >, David =
Waltermire >, A=
dam Montville >, "s=
acm@ietf.org" >
Subject: Re: [sacm] Status Update Request

I wish someone would have told me this 14 RFCs ago....

Tim
________________________________________
From: sacm-bounces@ietf.org [sacm-bounces@iet=
f.org] On Behalf Of Tim Keanini [tkeanini@nci=
rcle.com]
Sent: Monday, April 09, 2012 4:14 PM
To: Waltermire, David A.; Adam Montville; sacm@ietf.org
Subject: Re: [sacm] Status Update Request

We will certainly need a few ascii diagrams so let me share this link:
http://www.asciiflow.com/

--tk

--
Tim "TK" Keanini, CTO    ...    nCircle Inc.

-----Original Message-----
From: sacm-bounces@ietf.org [mailto:sacm-boun=
ces@ietf.org] On Behalf Of
Waltermire, David A.
Sent: Monday, April 09, 2012 2:04 PM
To: Adam Montville; 'sacm@ietf.org'
Subject: Re: [sacm] Status Update Request

I can take a stab at that.  It will be useful at minimum to start some
discussion.
Dave

-----Original Message-----
From: Adam Montville [mailto:amontville@tripwire.com]
Sent: Monday, April 09, 2012 2:48 PM
To: Waltermire, David A.; 'sacm@ietf.org'
Subject: Re: Status Update Request

Hi Dave,

Thanks for sending this out.  I like the abstract and the structure of

the document so far, so no further comments from me on the abstract.
Are you planning to create a first pass at a complete list of use
cases for the document?

Adam

On 4/9/12 11:41 AM, "Waltermire, David A." >
wrote:

>Please find a skeleton I-D of the use case document attached with
>updates to the abstract based on the feedback to date.  If there are
no
>other comments on the abstract I'll start work on the introduction
>and we can start breaking out use cases and authors for each use
case.
>
>Sincerely,
>Dave
>
>
>> -----Original Message-----
>> From: sacm-bounces@ietf.org [mailto:sacm-b=
ounces@ietf.org] On
>> Behalf Of Adam Montville
>> Sent: Monday, April 09, 2012 2:33 PM
>> To: 'sacm@ietf.org'
>> Subject: [sacm] Status Update Request
>>
>> All:
>>
>> The list seems to be rather quiet since the close of IETF 83 more
>> than a week ago.  Actions coming out of the side meeting held on
>> March 24
>> included:
>>
>> 1. Use Case document first draft by middle of April 2. Use Case
>> initial revision by end of April 3. Start of a charter discussion
>> around middle of April (after first draft Use Case release)
>>
>> Dave Waltermire has offered to lead development of the Use Case
>> document and Kent Landfield has offered to lead the subsequent
>> charter discussion.
>>
>> Dave/Kent: Do either of you have an update you can share?
>>
>> Adam
>>
>>
>>
>> _______________________________________________
>> sacm mailing list
>> sacm@ietf.org
>> https://www.ietf.org/mailman/listinfo/sacm


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







_______________________________________________

sacm mailing list

sacm@ietf.org

https://www.ietf.org/mailman/listinfo/sacm


--

jOVAL.org: OVAL implemented in Java.
Scan any machine from any machine. For free!
Learn More | Features=
 | Download

--

jOVAL.org: OVAL implemented in Java.
Scan any machine from any machine. For free!
Learn More | Features=
 | Download

--_000_D7A0423E5E193F40BE6E94126930C4930B98C82362MBCLUSTERxcha_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu
dD0idGV4dC9odG1sOyBjaGFyc2V0PXVzLWFzY2lpIj48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250
ZW50PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8q
IEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2Rpbmdz
Ow0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh
bWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2
IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglw
YW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K
cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0K
CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5
OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0KYTpsaW5rLCBzcGFu
Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0
ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtG
b2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQt
ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv
LW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJv
dHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglm
b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCnBy
ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9y
bWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZv
bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgljb2xvcjpibGFj
azt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1z
dHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0K
CW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsN
Cglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0KcC5N
c29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFw
aA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJp
Z2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDouNWluOw0KCW1hcmdp
bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1l
cyBOZXcgUm9tYW4iLCJzZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0
dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNv
LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7
DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5CYWxsb29uVGV4
dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUt
cHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1p
bHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uYXBwbGUtc3R5
bGUtc3Bhbg0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1zdHlsZS1zcGFuO30NCnNwYW4uRW1haWxT
dHlsZTI0DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp
Iiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyNQ0KCXtt
c28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy
aWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjcNCgl7bXNvLXN0eWxlLXR5
cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsN
Cgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9y
dC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6
OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29y
ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8N
CkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjMzMDcxNjIwMTsNCgltc28tbGlzdC10eXBlOmh5YnJp
ZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTQ2NzM5ODMwMiAtMTUwNTA5OTQ5MCA2NzY5ODY5
MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2
NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjA7DQoJbXNv
LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Oi07DQoJbXNvLWxl
dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl
eHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0K
CW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21z
by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1s
ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0
ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBs
MDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10
ZXh0OlxGMEE3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt
cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2Rp
bmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7
DQoJbXNvLWxldmVsLXRleHQ6XEYwQjc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv
LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250
LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9y
bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l
Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47
DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxl
dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0OlxGMEE3Ow0KCW1zby1s
ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0
ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxl
dmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6
XEYwQjc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np
dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K
QGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t
bGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i
ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNv
dXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6
YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0OlxGMEE3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25l
Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47
DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVs
DQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4
bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94
bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2
OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFw
ZWxheW91dD48L3htbD48IVtlbmRpZl0tLT48L2hlYWQ+PGJvZHkgYmdjb2xvcj13aGl0ZSBsYW5n
PUVOLVVTIGxpbms9Ymx1ZSB2bGluaz1wdXJwbGU+PGRpdiBjbGFzcz1Xb3JkU2VjdGlvbjE+PHAg
Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+T2suJm5ic3A7IEkmIzgyMTc7
bGwgYml0ZS4gOy0pJm5ic3A7IEZpcnN0IG9mZiwgSSBhbSBub3QgaW50ZXJlc3RlZCBpbiBjcmVh
dGluZyBhIG5ldyBzdGFuZGFyZCB0aGF0IGNvbXBldGVzIHdpdGggQ0lNIG9yIGFueSBvZiB0aGUg
b3RoZXIgZGF0YSBtb2RlbHMgY2FwdHVyaW5nIGFzc2V0IGluZm9ybWF0aW9uLiZuYnNwOyBJZiBm
YWN0LCBpZiB0aGVyZSBpcyBhIGJldHRlciBzb2x1dGlvbiBJJiM4MjE3O2QgbGlrZSB0byBleHBs
b3JlIGl0LiZuYnNwOyBUaGlzIHRocmVhZCBoYXMgYmVlbiB1c2VmdWwgaW4gZXhwbG9yaW5nIHNv
bWUgcG9zc2liaWxpdGllcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFs
PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu
cy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNs
YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToi
Q2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlNwZWFraW5nIHRvIEFzc2V0IElk
ZW50aWZpY2F0aW9uLCBvbmUgb2YgdGhlIG1ham9yIHJlYXNvbnMgd2UgY3JlYXRlZCB0aGUgc3Bl
Y2lmaWNhdGlvbiB3YXMgdG8gcHJvdmlkZSBhIG1hcHBpbmcgbWVjaGFuaXNtIHRoYXQgY2FuIHN5
bnRoZXNpemUgZGF0YSBhY3Jvc3MgYW55IHVuZGVybHlpbmcgc3lzdGVtcyBtYW5hZ2VtZW50IHBy
b3RvY29sIChlLmcuIFdFQk0sIFNOTVAsIE5ldENvbmYsIGV0YykgYW5kIGRhdGEgZm9ybWF0IChl
LmcuIENJTSwgTUlCLCBZYW5nLCBTQ0FQLCBldGMuKSZuYnNwOyBXZSB3YW50ZWQgc29tZXRoaW5n
IHRoYXQgd291bGQgYmUgaW5mb3JtYXRpb24gZG9tYWluIG5ldXRyYWwuJm5ic3A7IEluIG15IG1p
bmQgdGhlIGNvbnRyb2xsZWQgdm9jYWJ1bGFyeSBhcHByb2FjaCB1c2VkIGluIEFzc2V0IElkZW50
aWZpY2F0aW9uIHByb3ZpZGVzIHBhcnQgb2YgYSBzZW1hbnRpYyBhYnN0cmFjdGlvbiBvdmVyIGFs
bCBvZiB0aGVzZSB0aGluZ3MuJm5ic3A7IEl0IGVuYWJsZXMgZGF0YSBzeW50aGVzaXMgd2l0aGlu
IGEgaGV0ZXJvZ2VuZW91cyBlbnZpcm9ubWVudCBvZiB0b29scyBpbXBsZW1lbnRpbmcgYSB2YXJp
ZXR5IG9mIHN0YW5kYXJkcy1iYXNlZCBhcHByb2FjaGVzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48
cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpw
Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+SSBo
b3BlIHRoaXMgcHJvdmlkZXMgbW9yZSBjb250ZXh0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBj
bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwv
c3Bhbj48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5T
aW5jZXJlbHksPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz
dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi
O2NvbG9yOiMxRjQ5N0QnPkRhdmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PHAgY2xhc3M9
TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxp
YnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+
PC9wPjxkaXY+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERG
IDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4nPjxwIGNsYXNzPU1zb05vcm1hbD48Yj48
c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1z
ZXJpZiI7Y29sb3I6d2luZG93dGV4dCc+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSdmb250
LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjtjb2xvcjp3aW5k
b3d0ZXh0Jz4gc2FjbS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86c2FjbS1ib3VuY2VzQGlldGYu
b3JnXSA8Yj5PbiBCZWhhbGYgT2YgPC9iPkRhdmlkIFNvbGluPGJyPjxiPlNlbnQ6PC9iPiBUdWVz
ZGF5LCBBcHJpbCAyNCwgMjAxMiA1OjUyIFBNPGJyPjxiPlRvOjwvYj4gVGltIEtlYW5pbmk8YnI+
PGI+Q2M6PC9iPiBzYWNtQGlldGYub3JnPGJyPjxiPlN1YmplY3Q6PC9iPiBSZTogW3NhY21dIFN0
YXR1cyBVcGRhdGUgUmVxdWVzdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48cCBj
bGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPkFs
bCBJJ20gc2F5aW5nIGlzIHRoYXQgQ0lNIGlzIGFscmVhZHkgd2lkZWx5IHVzZWQgZm9yIGV4YWN0
bHkgdGhlIHB1cnBvc2VzIGFuZCB1c2UtY2FzZXMgc3BlY2lmaWVkIGJ5IEFJLiZuYnNwOyBGcm9t
IHdoYXQgSSBjYW4gZGV0ZXJtaW5lLCBBSSBpcyBub3QgaW5oZXJlbnRseSBjYXBhYmxlIG9mIGRl
YWxpbmcgd2l0aCBpc3N1ZXMgbGlrZSByZWNvbmNpbGlhdGlvbiwgYnV0IHRoZXJlIGFyZSBleGlz
dGluZyB3ZWxsLWtub3duIHByYWN0aWNlcyBhcm91bmQgQ0lNLiZuYnNwOyBJZiBDSU0ncyBhdHRy
aWJ1dGVzIGFyZSBpbnN1ZmZpY2llbnQgZm9yIG91ciBuZWVkcywgaXQgaXMgZXh0ZW5zaWJsZSBi
eSBkZXNpZ24uJm5ic3A7IEJ1dCBJIHRoaW5rIHRoZSBDSU0gY2xhc3MgbW9kZWwgaXMgbW9yZSB0
aGFuIHN1ZmZpY2llbnQgZm9yIGFueXRoaW5nIHdlIGNhbiBkcmVhbSB1cC48YnI+PGJyPklmIGV2
ZXJ5IHBvdGVudGlhbCB1c2VyIGRlc2lnbnMgYSBuZXcgc3RhbmRhcmQsIHRoZW4gdGhlcmUgYXJl
LCBpbiBlZmZlY3QsIG5vIHN0YW5kYXJkcy4mbmJzcDsgTXkgb3BpbmlvbiBpcyB0aGF0IHNpbmNl
IHdlIGNhbiBjaG9vc2UgYmV0d2VlbiBhbiBpbW1hdHVyZSBwcm9wb3NhbCAoQUkpLCBhbmQgYSBt
YXR1cmUgd2lkZWx5LWFkb3B0ZWQgc3RhbmRhcmQgKENJTSksIHRoZSBjaG9pY2Ugc2hvdWxkIGJl
IG9idmlvdXMuPGJyPjxicj5Bbnl3YXksIGFyZSBUaW0gYW5kIEkgdGhlIG9ubHkgcGVvcGxlIHdp
dGggdGhvdWdodHMgb24gdGhlIG1hdHRlcj8mbmJzcDsgSSB3YXMgaG9waW5nIHRoYXQgcGVyaGFw
cyBEYXZpZCBXYWx0ZXJtaXJlIG1pZ2h0IGJlIGFibGUgdG8gZXhwbGFpbiB0aGUgcmF0aW9uYWxl
IGJlaGluZCBwcm9wb3NpbmcgYSBuZXcgc3RhbmRhcmQuPGJyPjxicj5SZWdhcmRzLDxicj4tLURh
dmlkIFNvbGluPGJyPjxicj5PbiA0LzE5LzIwMTIgMzowNSBQTSwgVGltIEtlYW5pbmkgd3JvdGU6
IDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0Qn
Pkkgd291bGQgYXJndWUgdGhhdCBpdCBpcyBub3QgYSBwcm9ibGVtIG9mIHVuaXF1ZW5lc3MgYnV0
IGEgbWFjaGluZSBsZWFybmluZyBwcm9ibGVtIG9mIGNvbXB1dGluZyBpbnRlci1kb21haW4gZXF1
aXZhbGVuY2UgKHdoaWNoIG1heSBvciBtYXkgbm90IGJlIHVuaXF1ZSkuJm5ic3A7IEkgc2F5IHRo
aXMgb25seSBiZWNhdXNlIGluIHRoZXNlIGNhc2Ugd2UgYXJlIHRhbGtpbmcgYWJvdXQgY29tcHV0
aW5nIHRoZSBzeW50YWN0aWNhbCBlcXVpdmFsZW5jZSBidXQgY2VydGFpbmx5IGluIHRoZSBmdXR1
cmUgd2UgY291bGQgYWxzbyBkbyB0aGlzIGJhc2VkIG9uIHNlbWFudGljIGVxdWl2YWxlbmNlLiZu
YnNwOyA8L3NwYW4+PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl
PSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29s
b3I6IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1h
bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh
bnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkFuZCB5b3UgYXJlIHNvIHJpZ2h0IGluIHRoYXQgQ0lN
IHdvdWxkIHJlcXVpcmUgbW9yZSBzY2hlbWEgdG8gYWlkIGluIHRoZSB0YXNrIG9mIHN5bnRoZXNp
cyB3aXRoIHNhY20vc2NhcC4mbmJzcDsgSSYjODIxNzttIGNvbXBsZXRlbHkgaW4gYWdyZWVtZW50
IGF0IHRoZSB0ZWNobmljYWwgbGV2ZWwuJm5ic3A7Jm5ic3A7Jm5ic3A7IEluIGZhY3QsIG1vc3Qg
b2YgdGhlIGZpZWxkcyBpbiBBSSBjYW4gYmUgY29tcHV0ZWQgZnJvbSB0aGUgQ0lNIG1vZGVsIChi
ZWluZyBhIHN1YnNldCkuJm5ic3A7IDwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29O
b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki
LCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+
PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+V2hhdCBJIGFtIHNlbnNp
dGl2ZSB0byBoZXJlIGlzIHRoZSBhZG1pbmlzdHJhdGl2ZSByZWFsbXMgYW5kIHBvbGl0aWNhbCBy
ZWFsbXMgb2YgYm90aCBzdGFuZGFyZHMuJm5ic3A7IElmIHRoZSBzb2x1dGlvbiBjb3VwbGVzIHRo
ZSB0d28gc3RhbmRhcmRzIHN1Y2ggdGhhdCBvbmUgaXMgaW1wYWlyZWQgYnkgdGhlIG90aGVycyBw
cm9ncmVzcyBvciBkb3JtYW5jeSwgYmFkIGRlc2lnbiwgbm8gZG9udXQuJm5ic3A7IDwvc3Bhbj48
bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz4m
bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl
PSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29s
b3I6IzFGNDk3RCc+LS10azwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+
PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z
LXNlcmlmIjtjb2xvcjojMUY0OTdEJz4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+PGRpdj48
cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p
bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz4tLTwvc3Bhbj48bzpwPjwv
bzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7
Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5UaW0gJnF1
b3Q7VEsmcXVvdDsgS2VhbmluaSwgQ1RPJm5ic3A7Jm5ic3A7Jm5ic3A7ICYjODIzMDsmbmJzcDsm
bmJzcDsmbmJzcDsgbkNpcmNsZSBJbmMuJm5ic3A7Jm5ic3A7ICYjODIzMDsmbmJzcDsmbmJzcDsg
bWJsICg0MTUpIDMyOC0yNzIyJm5ic3A7ICYjODIzMDs8L3NwYW4+PG86cD48L286cD48L3A+PC9k
aXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+Jm5ic3A7PC9zcGFu
PjxvOnA+PC9vOnA+PC9wPjxkaXY+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz
b2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4nPjxwIGNsYXNzPU1z
b05vcm1hbD48Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFo
b21hIiwic2Fucy1zZXJpZiI7Y29sb3I6d2luZG93dGV4dCc+RnJvbTo8L3NwYW4+PC9iPjxzcGFu
IHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlm
Ijtjb2xvcjp3aW5kb3d0ZXh0Jz4gRGF2aWQgU29saW4gPGEgaHJlZj0ibWFpbHRvOlttYWlsdG86
c29saW5AZmFybmFtaGFsbHZlbnR1cmVzLmNvbV0iPlttYWlsdG86c29saW5AZmFybmFtaGFsbHZl
bnR1cmVzLmNvbV08L2E+IDxiPk9uIEJlaGFsZiBPZiA8L2I+RGF2aWQgU29saW48YnI+PGI+U2Vu
dDo8L2I+IFR1ZXNkYXksIEFwcmlsIDEwLCAyMDEyIDExOjUwIEFNPGJyPjxiPlRvOjwvYj4gVGlt
IEtlYW5pbmk8YnI+PGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86c2FjbUBpZXRmLm9yZyI+c2Fj
bUBpZXRmLm9yZzwvYT48YnI+PGI+U3ViamVjdDo8L2I+IFJlOiBbc2FjbV0gU3RhdHVzIFVwZGF0
ZSBSZXF1ZXN0PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjxwIGNsYXNzPU1zb05v
cm1hbD4mbmJzcDs8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+SGkgVGltLDxicj48
YnI+QWRkcmVzc2luZyB0aGUgcHJvYmxlbSBvZiB1bmlxdWVuZXNzIGNlcnRhaW5seSBkb2VzIG5v
dCByZXF1aXJlIGFuIGVudGlyZWx5IG5ldyBkYXRhIG1vZGVsLiZuYnNwOyBFeGlzdGluZyBDTURC
cyBoYXZlIHRvIHNvbHZlIHRoZSBwcm9ibGVtIG9mIG11bHRpcGxlIGRpc2NvdmVyeSBzb3VyY2Vz
LCBhcyBlYWNoIHByb2R1Y3QgaW50ZXJhY3Rpbmcgd2l0aCBpdCBpcyBwb3RlbnRpYWxseSBhbm90
aGVyIGRpc2NvdmVyeSBzb3VyY2UuJm5ic3A7IEJNQydzIEF0cml1bSBDTURCLCBmb3IgaW5zdGFu
Y2UsIGV4dGVuZHMgdGhlIENJTSBzY2hlbWEgd2l0aCBhIHJlY29uY2lsaWF0aW9uIElEIHRoYXQg
aXMgdXNlZCBmb3IgdGhpcyBwdXJwb3NlLCBhbmQgSSBpbWFnaW5lIHRoYXQncyBwcm9iYWJseSBu
b3QgYW4gdW5jb21tb24gc29sdXRpb24uJm5ic3A7IFRoZXJlJ3Mgbm8gcmVhc29uIHdlIGNhbid0
IGhhdmUgYW4gQXNzZXQgSWRlbnRpZmljYXRpb24gc3BlY2lmaWNhdGlvbiB0aGF0IGNvbnNpc3Rz
IHB1cmVseSBvZiBhbiBleHRlbnNpb24gb2YgQ0lNIC0tIHdoZXJlIHdlIGNhbiBhZGQsIGZvciBp
bnN0YW5jZSwgYSBDUEUgcHJvcGVydHkgdG8gZXhpc3RpbmcgY2xhc3NlcyAoZS5nLiwgT3BlcmF0
aW5nU3lzdGVtLCBEYXRhYmFzZVN5c3RlbSAuLi4gb3IgcGVyaGFwcyBqdXN0IHRvIHRoZSBTeXN0
ZW0gcGFyZW50IGNsYXNzPykuJm5ic3A7IEluZGVlZCwgcGVyaGFwcyB0aGF0J3Mgd2hhdCB5b3Un
cmUgc3VnZ2VzdGluZz88YnI+PGJyPlRvIG15IGV5ZSwgdGhlIEFJIHNwZWNpZmljYXRpb24gbG9v
a3MgbGFyZ2VseSBsaWtlIGEgc3Vic2V0IG9mIENJTSwgZXhjZXB0IHdpdGggdGhlIGFkZGl0aW9u
IG9mIHRoZSBzcGVjaWFsaXplZCBhaTp3ZWJzaXRlIG9iamVjdCAod2hpY2ggZmVlbHMgbGlrZSBp
dCBzaG91bGQgYmUgdW5uZWNlc3NhcnkpLiZuYnNwOyBXaHkgZG8gd2Ugd2FudCB0byByZWludmVu
dCB0aGUgd2hlZWw/PGJyPjxicj5SZWdhcmRzLDxicj4tLURhdmlkPGJyPjxicj5PbiA0LzEwLzIw
MTIgMTA6MzYgQU0sIFRpbSBLZWFuaW5pIHdyb3RlOiA8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1N
c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGli
cmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5UaGVyZSBhcmUgYXQgbGVhc3QgdHdvIGNv
bnNpZGVyYXRpb25zOiA8L3NwYW4+PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTGlzdFBhcmFn
cmFwaCBzdHlsZT0ndGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8yJz48
IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkNhbGlicmkiLCJz
YW5zLXNlcmlmIic+PHNwYW4gc3R5bGU9J21zby1saXN0Oklnbm9yZSc+LTxzcGFuIHN0eWxlPSdm
b250OjcuMHB0ICJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsgPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxl
PSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29s
b3I6IzFGNDk3RCc+SW50ZXItZG9tYWluIG11bHRpLXNlbnNvciBkYXRhIGZ1c2lvbiBhbmQgc3lu
dGhlc2lzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGggc3R5
bGU9J3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMic+PCFbaWYgIXN1
cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp
ZiInPjxzcGFuIHN0eWxlPSdtc28tbGlzdDpJZ25vcmUnPi08c3BhbiBzdHlsZT0nZm9udDo3LjBw
dCAiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7IDwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0nZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5
N0QnPkxpbWl0YXRpb25zIG9mIGRpc2NvdmVyeSAoaW5zdGFuY2UgZGF0YSByZXNvbHV0aW9uKTwv
c3Bhbj48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0
OTdEJz4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxz
cGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z
ZXJpZiI7Y29sb3I6IzFGNDk3RCc+SW50ZXItZG9tYWluIG11bHRpLXNlbnNvciBkYXRhIGZ1c2lv
biBhbmQgc3ludGhlc2lzPC9zcGFuPjwvYj48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3Jt
YWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJz
YW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5UaGlzIGlzIGZvciBhbGwgcHJhY3RpY2FsIHB1cnBv
c2VzIHRoZSBpbnZlcnNlLWZ1bmN0aW9uYWwtcHJvcGVydHkgb3IgcHJpbWFyeSBrZXkgc3ludGF4
IG1hdGNoIHByb2JsZW0uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48
c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt
c2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlRoZSBtZXRhZGF0YSBpbiBBSSBpcyBkZXNpZ25lZCB3aXRo
IHRoZSBvdGhlciBTQ0FQIG1ldGFkYXRhIGluIG1pbmQgd2hlcmVhcyBDSU0gd2FzIG5vdCBhbmQg
d2hpbGUgdGhleSBtYXkgc2hhcmUgY29tbW9uIGtleXMgbGlrZSBJUCBhZGRyZXNzIHRvIHBlcmZv
cm0gYSBqb2luLCBtb3JlIGFuZCBtb3JlIHRoaXMgaXMgbm90IGEgc3RhYmxlIGNoYXJhY3Rlcmlz
dGljIG9mIHRoZSBhc3NldCBpbiBlaXRoZXIgZG9tYWluLiZuYnNwOyBBbm90aGVyIGNvbnNpZGVy
YXRpb24gaGVyZSBpcyB0aGF0IENJTSB3b3VsZCBub3QgaGF2ZSBpbiBpdCBzb21ldGhpbmcgbGlr
ZSBhIENQRSBpZGVudGlmaWVyLCB2ZXJ5IGNvbW1vbiBrZXkgZm9yIHN5bnRoZXNpcyBhY3Jvc3Mg
ZG9tYWlucyB3aXRoaW4gdGhlIFNDQVAgZmFtaWx5LiZuYnNwOyBNeSBzdWdnZXN0aW9uIGhlcmUg
aXMgdGhhdCB3ZSBub3QgbG9vayBmb3IgYSBzaW5nbGUgZG9tYWluIHRvIGlkZW50aWZ5IGFuIGFz
c2V0IGJ1dCB0byBlbnN1cmUgdGhhdCBhbGwgdGhlIGRhdGEgZG9tYWlucyAoQUksIENJTSwgZXRj
KSBoYXZlIGluIHRoZW0gZW5vdWdoIGJvdW5kYXJ5IG9iamVjdHMgdG8gJiM4MjIwO2pvaW4mIzgy
MjE7IG9yIHN5bnRoZXNpemUgbXVsdGlwbGUgZG9tYWlucy4mbmJzcDsgV2Ugc2hvdWxkIGVuc3Vy
ZSB0aGF0IGFsbCBpbmZvcm1hdGlvbiBkb21haW5zIGhhdmUgaW4gaXQgYSByaWNoIHNldCBvZiBz
dGFibGUgY2hhcmFjdGVyaXN0aWNzIHRoYXQgYWZmb3JkIHN5bnRhY3RpY2FsIG1hdGNoaW5nIG9m
IHRoZSBtZXRhZGF0YSBmb3IgdGhlIHB1cnBvc2VzIG9mIEludGVyLWRvbWFpbiBtdWx0aS1zZW5z
b3IgZGF0YSBmdXNpb24gYW5kIHN5bnRoZXNpczwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cCBjbGFz
cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNh
bGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz4mbmJzcDs8L3NwYW4+PG86cD48L286
cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+Jm5ic3A7PC9z
cGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48Yj48c3BhbiBzdHlsZT0nZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMx
RjQ5N0QnPkxpbWl0YXRpb25zIG9mIGRpc2NvdmVyeSAoaW5zdGFuY2UgZGF0YSByZXNvbHV0aW9u
KTogQXV0aGVudGljYXRlZCBhbmQgVW5hdXRoZW50aWNhdGVkIERpc2NvdmVyeSA8L3NwYW4+PC9i
PjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0Qn
PlJlbW90ZSBhdXRvbWF0ZWQgc2Nhbm5pbmcgY29tZXMgaW4gYXQgbGVhc3QgdHdvIGZsYXZvcnMs
IGF1dGhlbnRpY2F0ZWQtc2Nhbm5pbmcgYW5kIHVuYXV0aGVudGljYXRlZC1zY2FubmluZy4mbmJz
cDsgV2UgbXVzdCBrZWVwIHRoaXMgaW4gbWluZCBhcyB3ZSBsb29rIHRvIHRoZSBkZXNpZ24gb3Ig
Ym9ycm93IHRoZXNlIG1ldGFkYXRhIGZvcm1hdHMgKEFJLCBDSU0sIGV0YykuJm5ic3A7IE1vc3Qg
aWYgbm90IGFsbCBDTURCIGFzc3VtZXMgdGhlIG9sZCBuZXR3b3JrIG1hbmFnZW1lbnQgbWluZHNl
dCBvZiBub2Rlcy11bmRlci1tYW5hZ2VtZW50IGFuZCBub2RlLW5vdC11bmRlci1tYW5hZ2VtZW50
LiZuYnNwOyBUaGUgZm9ybWVyIGhhdmluZyBhbiBhZ2VudCBpbnN0YWxsZWQgb3Igc29tZSBhdXRo
ZW50aWNhdGlvbi9hdXRob3JpemF0aW9uIHByb3ZpZGVkLCB0aGUgbGF0dGVyIGFzc3VtZXMgYW4g
YXNzZXNzbWVudCBvZiB0aGUgdGFyZ2V0IHZpYSBpdHMgdGFyZ2V0IHN1cmZhY2UgaW4gYW4gdW5h
dXRoZW50aWNhdGVkIG1hbm5lci4mbmJzcDsgSSByYWlzZSB0aGlzIGlzc3VlIG9uY2UgYWdhaW4g
YmVjYXVzZSBPVkFMIGZvciBleGFtcGxlIG1ha2VzIG5vIHByb3Zpc2lvbiBmb3IgdGhlIGFzc2Vz
c21lbnQgdG8gdGFrZSBwbGFjZSBpbiBhbiB1bmF1dGhlbnRpY2F0ZWQgbWFubmVyLiZuYnNwOyZu
YnNwOyBXZSBuZWVkIHRvIGtlZXAgdGhpcyBpbiBtaW5kIGFzIHdlIGxvb2sgdG8gcG9wdWxhdGUg
dGhlIG1ldGFkYXRhIG9mIEFJIGFzIGNlcnRhaW4gZmllbGRzIHdpbGwgb25seSBiZSB2YWxpZCBm
b3IgYXV0aGVudGljYXRlZCBzY2FubmluZyBvciBhbiBhZ2VudC4mbmJzcDsgSSYjODIxNzttIGEg
dmVuZG9yIHRoYXQgaGFzIGJvdGggdHlwZXMgb2Ygc2Nhbm5lcnMgYW5kIEkgbXVzdCBzYXkgdGhh
dCBmb3IgcmVhc29ucyBJIHdpbGwgbm90IGdldCBpbnRvIGhlcmUsIGN1c3RvbWVycyBkZXBsb3kg
dW5hdXRoZW50aWNhdGVkIHNjYW5uZXJzIGFjcm9zcyB0aGVpciBlbnRpcmUgZW50ZXJwcmlzZSBh
bmQgYXV0aGVudGljYXRlZCBzY2FubmVycyBpbiB0YXJnZXRlZCBzY29wZXMuJm5ic3A7IEkgcmFp
c2UgdGhpcyBpc3N1ZSBiZWNhdXNlIHRpbWUgYW5kIHRpbWUgYWdhaW4sIGN1c3RvbWVycyBjb21l
IGJhY2sgdG8gdXMgd2l0aCB0aGUgdW5hdXRoZW50aWNhdGVkIHNjYW5uZXJzIGhhdmluZyBtdWNo
IG1vcmUgaWRlbnRpZmljYXRpb24gb2YgZW5kLXBvaW50IGFzc2V0cyB0aGFuIGFueSBvdGhlciBh
dXRoZW50aWNhdGVkIHNjYW5uZXIuJm5ic3A7IFRoaXMgaXMgYSBzaWRlYmFyIGJ1dCBJIHdhbnRl
ZCB0byBzaGFyZSB0aGlzIGV4cGVyaWVuY2UgaGF2aW5nIGJlZW4gYSBzdXBwbGllciBvZiB0aGlz
IHRlY2hub2xvZ3kgZm9yIHRoZSBwYXN0IDEyIHllYXJzLiZuYnNwOyAmbmJzcDsmbmJzcDs8L3Nw
YW4+PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3
RCc+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz
dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi
O2NvbG9yOiMxRjQ5N0QnPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD48ZGl2PjxwIGNsYXNz
PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ2Fs
aWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPi0tPC9zcGFuPjxvOnA+PC9vOnA+PC9w
PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlRpbSAmcXVvdDtUSyZx
dW90OyBLZWFuaW5pLCBDVE8mbmJzcDsmbmJzcDsmbmJzcDsgJiM4MjMwOyZuYnNwOyZuYnNwOyZu
YnNwOyBuQ2lyY2xlIEluYy4mbmJzcDsmbmJzcDsgJiM4MjMwOyZuYnNwOyZuYnNwOyBtYmwgKDQx
NSkgMzI4LTI3MjImbmJzcDsgJiM4MjMwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48cCBj
bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz4mbmJzcDs8L3NwYW4+PG86cD48
L286cD48L3A+PGRpdj48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNC
NUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbic+PHAgY2xhc3M9TXNvTm9ybWFs
PjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJz
YW5zLXNlcmlmIjtjb2xvcjp3aW5kb3d0ZXh0Jz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9
J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO2NvbG9y
OndpbmRvd3RleHQnPiA8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnNhY20tYm91bmNlc0BpZXRmLm9y
ZyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNh
bnMtc2VyaWYiJz5zYWNtLWJvdW5jZXNAaWV0Zi5vcmc8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSdm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjtjb2xvcjp3
aW5kb3d0ZXh0Jz4gPC9zcGFuPjxhIGhyZWY9Im1haWx0bzpbbWFpbHRvOnNhY20tYm91bmNlc0Bp
ZXRmLm9yZ10iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhv
bWEiLCJzYW5zLXNlcmlmIic+W21haWx0bzpzYWNtLWJvdW5jZXNAaWV0Zi5vcmddPC9zcGFuPjwv
YT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fu
cy1zZXJpZiI7Y29sb3I6d2luZG93dGV4dCc+IDxiPk9uIEJlaGFsZiBPZiA8L2I+RGF2aWQgU29s
aW48YnI+PGI+U2VudDo8L2I+IE1vbmRheSwgQXByaWwgMDksIDIwMTIgNTozOCBQTTxicj48Yj5U
bzo8L2I+IDwvc3Bhbj48YSBocmVmPSJtYWlsdG86c2FjbUBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9
J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5zYWNt
QGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7Y29sb3I6d2luZG93dGV4dCc+PGJyPjxiPlN1Ympl
Y3Q6PC9iPiBSZTogW3NhY21dIFN0YXR1cyBVcGRhdGUgUmVxdWVzdDwvc3Bhbj48bzpwPjwvbzpw
PjwvcD48L2Rpdj48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+Jm5ic3A7PG86cD48L286cD48L3A+
PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+VGhhdCBpcyB2
ZXJ5IG5lYXQsIGJ1dCBJIGFsc28gaGF2ZSBhIHF1ZXN0aW9uIG9uIHRoZSBvcmlnaW5hbCB0b3Bp
Yy4uLjxicj48YnI+V2FzIHRoZXJlIGFueSBkaXNjdXNzaW9uIGF0IHRoZSBtZWV0aW5nIGluIFBh
cmlzIG9uIEFzc2V0IElkZW50aWZpY2F0aW9uIHZzLiBDSU0sIG9yIGhhcyBhbnlvbmUgaWRlbnRp
ZmllZCBhIHVzZS1jYXNlIGZvciBBSSBmb3Igd2hpY2ggQ0lNIGlzIG5vdCBhcHByb3ByaWF0ZT8m
bmJzcDsgRm9yIHRoZSBzYWtlIG9mIG1ha2luZyBTQUNNIGVhc2lseSBhZG9wdGFibGUgYnkgbGFy
Z2UgZW50ZXJwcmlzZXMgd2l0aCBleGlzdGluZyBDTURCIGltcGxlbWVudGF0aW9ucywgSSBzdHJv
bmdseSBhZHZvY2F0ZSBhYmFuZG9uaW5nIEFJIGluIGZhdm9yIG9mIENJTS4mbmJzcDsgSSdkIGJl
IGhhcHB5IHRvIGRpc2N1c3MgaG93IEJNQywgSUJNLCBIUCwgQ0EsIGV0Yy4gaGF2ZSBiZWVuIG1h
a2luZyBDSU0gdGhlIGNlbnRlcnBpZWNlIG9mIHRoZWlyIHN5c3RlbXMgbWFuYWdlbWVudCBvZmZl
cmluZ3MgZm9yIG1vc3Qgb2YgdGhlIHBhc3QgZGVjYWRlLjxicj48YnI+UmVnYXJkcyw8YnI+LS1E
YXZpZCBTb2xpbjxicj48YnI+PGJyPjxicj48bzpwPjwvbzpwPjwvcD48ZGl2PjxwIGNsYXNzPU1z
b05vcm1hbD4tLSA8bzpwPjwvbzpwPjwvcD48cCBzdHlsZT0nbGluZS1oZWlnaHQ6MTIuMHB0Jz48
c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNl
cmlmIjtjb2xvcjojMzMzMzMzJz5qT1ZBTC5vcmc6IE9WQUwgaW1wbGVtZW50ZWQgaW4gSmF2YS48
L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo4LjVwdDtmb250LWZhbWlseToiQXJpYWwiLCJz
YW5zLXNlcmlmIjtjb2xvcjojMzMzMzMzJz48YnI+PC9zcGFuPjxpPjxzcGFuIHN0eWxlPSdmb250
LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6IzMzMzMz
Myc+U2NhbiBhbnkgbWFjaGluZSBmcm9tIGFueSBtYWNoaW5lLiBGb3IgZnJlZSE8L3NwYW4+PC9p
PjxzcGFuIHN0eWxlPSdmb250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1z
ZXJpZiI7Y29sb3I6IzMzMzMzMyc+PGJyPjwvc3Bhbj48YSBocmVmPSJodHRwOi8vd3d3LmpvdmFs
Lm9yZyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo4LjVwdDtmb250LWZhbWlseToiQXJpYWwiLCJz
YW5zLXNlcmlmIjtjb2xvcjojMzM2NjAwJz5MZWFybiBNb3JlPC9zcGFuPjwvYT48c3BhbiBzdHls
ZT0nZm9udC1zaXplOjguNXB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9y
OiMzMzMzMzMnPiB8IDwvc3Bhbj48YSBocmVmPSJodHRwOi8vd3d3LmpvdmFsLm9yZy9mZWF0dXJl
cy8iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fu
cy1zZXJpZiI7Y29sb3I6IzMzNjYwMCc+RmVhdHVyZXM8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSdm
b250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6IzMz
MzMzMyc+IHwgPC9zcGFuPjxhIGhyZWY9Imh0dHA6Ly93d3cuam92YWwub3JnL2Rvd25sb2FkLyI+
PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo4LjVwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNl
cmlmIjtjb2xvcjojMzM2NjAwJz5Eb3dubG9hZDwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9J2ZvbnQt
c2l6ZTo4LjVwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojMzMzMzMz
Jz4gPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48YnI+PGJy
Pk9uIDQvOS8yMDEyIDM6NDMgUE0sIDxhIGhyZWY9Im1haWx0bzpLZW50X0xhbmRmaWVsZEBNY0Fm
ZWUuY29tIj5LZW50X0xhbmRmaWVsZEBNY0FmZWUuY29tPC9hPiB3cm90ZTogPG86cD48L286cD48
L3A+PGRpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPldoYXQgZG8geW91IGtub3cmIzgy
MzA7LiAmbmJzcDtTQUNNIGlzIGFscmVhZHkgYmVpbmcgdmFsdWFibGUuIDstKTxvOnA+PC9vOnA+
PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPiZuYnNwOzxvOnA+PC9vOnA+PC9wPjwv
ZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHN0cm9uZz48c3BhbiBzdHlsZT0nZm9u
dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiM2MDZB
NzEnPktlbnQgTGFuZGZpZWxkPC9zcGFuPjwvc3Ryb25nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6
OS4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6IzYwNkE3MSc+PGJy
PjxzcGFuIGNsYXNzPWFwcGxlLXN0eWxlLXNwYW4+RGlyZWN0b3IgQ29udGVudCBTdHJhdGVneSwg
QXJjaGl0ZWN0dXJlIGFuZCBTdGFuZGFyZHM8L3NwYW4+PGJyPjxicj48c3Ryb25nPjxzcGFuIHN0
eWxlPSdmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+TWNBZmVlIHwgQW4gSW50ZWwg
Q29tcGFueTwvc3Bhbj48L3N0cm9uZz48YnI+PHNwYW4gY2xhc3M9YXBwbGUtc3R5bGUtc3Bhbj41
MDAwIEhlYWRxdWFydGVycyBEci48L3NwYW4+PGJyPjxzcGFuIGNsYXNzPWFwcGxlLXN0eWxlLXNw
YW4+UGxhbm8sIFRleGFzIDc1MDI0PC9zcGFuPjxicj48YnI+PHNwYW4gY2xhc3M9YXBwbGUtc3R5
bGUtc3Bhbj5EaXJlY3Q6ICsxLjk3Mi45NjMuNzA5NiZuYnNwOzwvc3Bhbj48YnI+PHNwYW4gY2xh
c3M9YXBwbGUtc3R5bGUtc3Bhbj5Nb2JpbGU6ICsxLjgxNy42MzcuODAyNjwvc3Bhbj48YnI+PHN0
cm9uZz48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPldlYjom
bmJzcDs8L3NwYW4+PC9zdHJvbmc+PC9zcGFuPjxhIGhyZWY9Imh0dHA6Ly93d3cubWNhZmVlLmNv
bS8iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fu
cy1zZXJpZiInPnd3dy5tY2FmZWUuY29tPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD48L2Rpdj48
L2Rpdj48L2Rpdj48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4mbmJzcDs8bzpwPjwvbzpw
PjwvcD48L2Rpdj48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0
REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbic+PHAgY2xhc3M9TXNvTm9ybWFsPjxi
PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu
cy1zZXJpZiInPkZyb206IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+JnF1b3Q7UG9saywgV2lsbGlhbSBU
LiZxdW90OyAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzp3aWxsaWFtLnBvbGtAbmlzdC5nb3Yi
PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu
cy1zZXJpZiInPndpbGxpYW0ucG9sa0BuaXN0Lmdvdjwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9J2Zv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+Jmd0Ozxi
cj48Yj5EYXRlOiA8L2I+TW9uLCA5IEFwciAyMDEyIDE1OjIyOjI1IC0wNTAwPGJyPjxiPlRvOiA8
L2I+VGltIEtlYW5pbmkgJmx0Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86dGtlYW5pbmlAbmNpcmNs
ZS5jb20iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJp
Iiwic2Fucy1zZXJpZiInPnRrZWFuaW5pQG5jaXJjbGUuY29tPC9zcGFuPjwvYT48c3BhbiBzdHls
ZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz4m
Z3Q7LCBEYXZpZCBXYWx0ZXJtaXJlICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmRhdmlkLndh
bHRlcm1pcmVAbmlzdC5nb3YiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiInPmRhdmlkLndhbHRlcm1pcmVAbmlzdC5nb3Y8L3Nw
YW4+PC9hPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJp
Iiwic2Fucy1zZXJpZiInPiZndDssIEFkYW0gTW9udHZpbGxlICZsdDs8L3NwYW4+PGEgaHJlZj0i
bWFpbHRvOmFtb250dmlsbGVAdHJpcHdpcmUuY29tIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz5hbW9udHZpbGxlQHRyaXB3
aXJlLmNvbTwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+Jmd0OywgJnF1b3Q7PC9zcGFuPjxhIGhyZWY9Im1h
aWx0bzpzYWNtQGlldGYub3JnIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz5zYWNtQGlldGYub3JnPC9zcGFuPjwvYT48c3Bh
biBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy
aWYiJz4mcXVvdDsgJmx0Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86c2FjbUBpZXRmLm9yZyI+PHNw
YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl
cmlmIic+c2FjbUBpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+Jmd0Ozxicj48Yj5TdWJqZWN0
OiA8L2I+UmU6IFtzYWNtXSBTdGF0dXMgVXBkYXRlIFJlcXVlc3Q8L3NwYW4+PG86cD48L286cD48
L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+Jm5ic3A7PG86cD48L286cD48L3A+PC9k
aXY+PGJsb2NrcXVvdGUgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNCNUM0
REYgNC41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdDttYXJnaW4tbGVmdDozLjc1cHQ7bWFy
Z2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQnIGlkPSJN
QUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIj48ZGl2PjxkaXY+PGRpdj48cCBjbGFz
cz1Nc29Ob3JtYWw+SSB3aXNoIHNvbWVvbmUgd291bGQgaGF2ZSB0b2xkIG1lIHRoaXMgMTQgUkZD
cyBhZ28uLi4uPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+Jm5i
c3A7PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+VGltPG86cD48
L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+X19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9
TXNvTm9ybWFsPkZyb206IDxhIGhyZWY9Im1haWx0bzpzYWNtLWJvdW5jZXNAaWV0Zi5vcmciPnNh
Y20tYm91bmNlc0BpZXRmLm9yZzwvYT4gWzxhIGhyZWY9Im1haWx0bzpzYWNtLWJvdW5jZXNAaWV0
Zi5vcmciPnNhY20tYm91bmNlc0BpZXRmLm9yZzwvYT5dIE9uIEJlaGFsZiBPZiBUaW0gS2Vhbmlu
aSBbPGEgaHJlZj0ibWFpbHRvOnRrZWFuaW5pQG5jaXJjbGUuY29tIj50a2VhbmluaUBuY2lyY2xl
LmNvbTwvYT5dPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+U2Vu
dDogTW9uZGF5LCBBcHJpbCAwOSwgMjAxMiA0OjE0IFBNPG86cD48L286cD48L3A+PC9kaXY+PGRp
dj48cCBjbGFzcz1Nc29Ob3JtYWw+VG86IFdhbHRlcm1pcmUsIERhdmlkIEEuOyBBZGFtIE1vbnR2
aWxsZTsgPGEgaHJlZj0ibWFpbHRvOnNhY21AaWV0Zi5vcmciPnNhY21AaWV0Zi5vcmc8L2E+PG86
cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+U3ViamVjdDogUmU6IFtz
YWNtXSBTdGF0dXMgVXBkYXRlIFJlcXVlc3Q8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNs
YXNzPU1zb05vcm1hbD4mbmJzcDs8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1z
b05vcm1hbD5XZSB3aWxsIGNlcnRhaW5seSBuZWVkIGEgZmV3IGFzY2lpIGRpYWdyYW1zIHNvIGxl
dCBtZSBzaGFyZSB0aGlzIGxpbms6PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1N
c29Ob3JtYWw+PGEgaHJlZj0iaHR0cDovL3d3dy5hc2NpaWZsb3cuY29tLyI+aHR0cDovL3d3dy5h
c2NpaWZsb3cuY29tLzwvYT48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05v
cm1hbD4mbmJzcDs8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4t
LXRrPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+Jm5ic3A7PG86
cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+LS08bzpwPjwvbzpwPjwv
cD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5UaW0gJnF1b3Q7VEsmcXVvdDsgS2Vhbmlu
aSwgQ1RPJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Li4uJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
bkNpcmNsZSBJbmMuPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+
Jm5ic3A7PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+LS0tLS1P
cmlnaW5hbCBNZXNzYWdlLS0tLS08bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1z
b05vcm1hbD5Gcm9tOiA8YSBocmVmPSJtYWlsdG86c2FjbS1ib3VuY2VzQGlldGYub3JnIj5zYWNt
LWJvdW5jZXNAaWV0Zi5vcmc8L2E+IFs8YSBocmVmPSJtYWlsdG86c2FjbS1ib3VuY2VzQGlldGYu
b3JnIj5tYWlsdG86c2FjbS1ib3VuY2VzQGlldGYub3JnPC9hPl0gT24gQmVoYWxmIE9mPG86cD48
L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+V2FsdGVybWlyZSwgRGF2aWQg
QS48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5TZW50OiBNb25k
YXksIEFwcmlsIDA5LCAyMDEyIDI6MDQgUE08bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNs
YXNzPU1zb05vcm1hbD5UbzogQWRhbSBNb250dmlsbGU7IDxhIGhyZWY9Im1haWx0bzolMjdzYWNt
QGlldGYub3JnIj4nc2FjbUBpZXRmLm9yZzwvYT4nPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48
cCBjbGFzcz1Nc29Ob3JtYWw+U3ViamVjdDogUmU6IFtzYWNtXSBTdGF0dXMgVXBkYXRlIFJlcXVl
c3Q8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4mbmJzcDs8bzpw
PjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5JIGNhbiB0YWtlIGEgc3Rh
YiBhdCB0aGF0LiZuYnNwOyZuYnNwO0l0IHdpbGwgYmUgdXNlZnVsIGF0IG1pbmltdW0gdG8gc3Rh
cnQgc29tZTxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPmRpc2N1
c3Npb24uPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+RGF2ZTxv
OnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPiZuYnNwOzxvOnA+PC9v
OnA+PC9wPjwvZGl2PjxibG9ja3F1b3RlIHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz
b2xpZCAjQjVDNERGIDQuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQ7bWFyZ2luLWxlZnQ6
My43NXB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUu
MHB0JyBpZD0iTUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSI+PGRpdj48cCBjbGFz
cz1Nc29Ob3JtYWw+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08bzpwPjwvbzpwPjwvcD48L2Rp
dj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5Gcm9tOiBBZGFtIE1vbnR2aWxsZSBbPGEgaHJlZj0i
bWFpbHRvOmFtb250dmlsbGVAdHJpcHdpcmUuY29tIj5tYWlsdG86YW1vbnR2aWxsZUB0cmlwd2ly
ZS5jb208L2E+XTxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPlNl
bnQ6IE1vbmRheSwgQXByaWwgMDksIDIwMTIgMjo0OCBQTTxvOnA+PC9vOnA+PC9wPjwvZGl2Pjxk
aXY+PHAgY2xhc3M9TXNvTm9ybWFsPlRvOiBXYWx0ZXJtaXJlLCBEYXZpZCBBLjsgPGEgaHJlZj0i
bWFpbHRvOiUyN3NhY21AaWV0Zi5vcmciPidzYWNtQGlldGYub3JnPC9hPic8bzpwPjwvbzpwPjwv
cD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5TdWJqZWN0OiBSZTogU3RhdHVzIFVwZGF0
ZSBSZXF1ZXN0PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+Jm5i
c3A7PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+SGkgRGF2ZSw8
bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4mbmJzcDs8bzpwPjwv
bzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5UaGFua3MgZm9yIHNlbmRpbmcg
dGhpcyBvdXQuJm5ic3A7Jm5ic3A7SSBsaWtlIHRoZSBhYnN0cmFjdCBhbmQgdGhlIHN0cnVjdHVy
ZSBvZjxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvYmxvY2txdW90ZT48ZGl2PjxwIGNsYXNzPU1zb05v
cm1hbD4mbmJzcDs8bzpwPjwvbzpwPjwvcD48L2Rpdj48YmxvY2txdW90ZSBzdHlsZT0nYm9yZGVy
Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0I1QzRERiA0LjVwdDtwYWRkaW5nOjBpbiAwaW4gMGlu
IDQuMHB0O21hcmdpbi1sZWZ0OjMuNzVwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDow
aW47bWFyZ2luLWJvdHRvbTo1LjBwdCcgaWQ9Ik1BQ19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NL
UVVPVEUiPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPnRoZSBkb2N1bWVudCBzbyBmYXIsIHNvIG5v
IGZ1cnRoZXIgY29tbWVudHMgZnJvbSBtZSBvbiB0aGUgYWJzdHJhY3QuPG86cD48L286cD48L3A+
PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+QXJlIHlvdSBwbGFubmluZyB0byBjcmVhdGUg
YSBmaXJzdCBwYXNzIGF0IGEgY29tcGxldGUgbGlzdCBvZiB1c2U8bzpwPjwvbzpwPjwvcD48L2Rp
dj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5jYXNlcyBmb3IgdGhlIGRvY3VtZW50PzxvOnA+PC9v
OnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPiZuYnNwOzxvOnA+PC9vOnA+PC9w
PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPkFkYW08bzpwPjwvbzpwPjwvcD48L2Rpdj48
ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4mbmJzcDs8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2Pjxw
IGNsYXNzPU1zb05vcm1hbD5PbiA0LzkvMTIgMTE6NDEgQU0sICZxdW90O1dhbHRlcm1pcmUsIERh
dmlkIEEuJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86ZGF2aWQud2FsdGVybWlyZUBuaXN0Lmdv
diI+ZGF2aWQud2FsdGVybWlyZUBuaXN0LmdvdjwvYT4mZ3Q7PG86cD48L286cD48L3A+PC9kaXY+
PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+d3JvdGU6PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48
cCBjbGFzcz1Nc29Ob3JtYWw+Jm5ic3A7PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFz
cz1Nc29Ob3JtYWw+Jmd0O1BsZWFzZSBmaW5kIGEgc2tlbGV0b24gSS1EIG9mIHRoZSB1c2UgY2Fz
ZSBkb2N1bWVudCBhdHRhY2hlZCB3aXRoPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFz
cz1Nc29Ob3JtYWw+Jmd0O3VwZGF0ZXMgdG8gdGhlIGFic3RyYWN0IGJhc2VkIG9uIHRoZSBmZWVk
YmFjayB0byBkYXRlLiZuYnNwOyZuYnNwO0lmIHRoZXJlIGFyZTxvOnA+PC9vOnA+PC9wPjwvZGl2
PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPm5vPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBj
bGFzcz1Nc29Ob3JtYWw+Jmd0O290aGVyIGNvbW1lbnRzIG9uIHRoZSBhYnN0cmFjdCBJJ2xsIHN0
YXJ0IHdvcmsgb24gdGhlIGludHJvZHVjdGlvbjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAg
Y2xhc3M9TXNvTm9ybWFsPiZndDthbmQgd2UgY2FuIHN0YXJ0IGJyZWFraW5nIG91dCB1c2UgY2Fz
ZXMgYW5kIGF1dGhvcnMgZm9yIGVhY2ggdXNlPG86cD48L286cD48L3A+PC9kaXY+PC9ibG9ja3F1
b3RlPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPmNhc2UuPG86cD48L286cD48L3A+PC9kaXY+PGJs
b2NrcXVvdGUgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNCNUM0REYgNC41
cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdDttYXJnaW4tbGVmdDozLjc1cHQ7bWFyZ2luLXRv
cDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQnIGlkPSJNQUNfT1VU
TE9PS19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4mZ3Q7
Jm5ic3A7PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+Jmd0O1Np
bmNlcmVseSw8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4mZ3Q7
RGF2ZTxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPiZndDsmbmJz
cDs8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4mZ3Q7Jm5ic3A7
PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+Jmd0OyZndDsgLS0t
LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNz
PU1zb05vcm1hbD4mZ3Q7Jmd0OyBGcm9tOiA8YSBocmVmPSJtYWlsdG86c2FjbS1ib3VuY2VzQGll
dGYub3JnIj5zYWNtLWJvdW5jZXNAaWV0Zi5vcmc8L2E+IFs8YSBocmVmPSJtYWlsdG86c2FjbS1i
b3VuY2VzQGlldGYub3JnIj5tYWlsdG86c2FjbS1ib3VuY2VzQGlldGYub3JnPC9hPl0gT248bzpw
PjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4mZ3Q7Jmd0OyBCZWhhbGYg
T2YgQWRhbSBNb250dmlsbGU8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05v
cm1hbD4mZ3Q7Jmd0OyBTZW50OiBNb25kYXksIEFwcmlsIDA5LCAyMDEyIDI6MzMgUE08bzpwPjwv
bzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4mZ3Q7Jmd0OyBUbzogPGEgaHJl
Zj0ibWFpbHRvOiUyN3NhY21AaWV0Zi5vcmciPidzYWNtQGlldGYub3JnPC9hPic8bzpwPjwvbzpw
PjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4mZ3Q7Jmd0OyBTdWJqZWN0OiBbc2Fj
bV0gU3RhdHVzIFVwZGF0ZSBSZXF1ZXN0PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFz
cz1Nc29Ob3JtYWw+Jmd0OyZndDsmbmJzcDs8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNs
YXNzPU1zb05vcm1hbD4mZ3Q7Jmd0OyBBbGw6PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBj
bGFzcz1Nc29Ob3JtYWw+Jmd0OyZndDsmbmJzcDs8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2Pjxw
IGNsYXNzPU1zb05vcm1hbD4mZ3Q7Jmd0OyBUaGUgbGlzdCBzZWVtcyB0byBiZSByYXRoZXIgcXVp
ZXQgc2luY2UgdGhlIGNsb3NlIG9mIElFVEYgODMgbW9yZTxvOnA+PC9vOnA+PC9wPjwvZGl2Pjxk
aXY+PHAgY2xhc3M9TXNvTm9ybWFsPiZndDsmZ3Q7IHRoYW4gYSB3ZWVrIGFnby4mbmJzcDsmbmJz
cDtBY3Rpb25zIGNvbWluZyBvdXQgb2YgdGhlIHNpZGUgbWVldGluZyBoZWxkIG9uPG86cD48L286
cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+Jmd0OyZndDsgTWFyY2ggMjQ8bzpw
PjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4mZ3Q7Jmd0OyBpbmNsdWRl
ZDo8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4mZ3Q7Jmd0OyZu
YnNwOzxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPiZndDsmZ3Q7
IDEuIFVzZSBDYXNlIGRvY3VtZW50IGZpcnN0IGRyYWZ0IGJ5IG1pZGRsZSBvZiBBcHJpbCAyLiBV
c2UgQ2FzZTxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPiZndDsm
Z3Q7IGluaXRpYWwgcmV2aXNpb24gYnkgZW5kIG9mIEFwcmlsIDMuIFN0YXJ0IG9mIGEgY2hhcnRl
ciBkaXNjdXNzaW9uPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+
Jmd0OyZndDsgYXJvdW5kIG1pZGRsZSBvZiBBcHJpbCAoYWZ0ZXIgZmlyc3QgZHJhZnQgVXNlIENh
c2UgcmVsZWFzZSk8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4m
Z3Q7Jmd0OyZuYnNwOzxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFs
PiZndDsmZ3Q7IERhdmUgV2FsdGVybWlyZSBoYXMgb2ZmZXJlZCB0byBsZWFkIGRldmVsb3BtZW50
IG9mIHRoZSBVc2UgQ2FzZTxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y
bWFsPiZndDsmZ3Q7IGRvY3VtZW50IGFuZCBLZW50IExhbmRmaWVsZCBoYXMgb2ZmZXJlZCB0byBs
ZWFkIHRoZSBzdWJzZXF1ZW50PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29O
b3JtYWw+Jmd0OyZndDsgY2hhcnRlciBkaXNjdXNzaW9uLjxvOnA+PC9vOnA+PC9wPjwvZGl2Pjxk
aXY+PHAgY2xhc3M9TXNvTm9ybWFsPiZndDsmZ3Q7Jm5ic3A7PG86cD48L286cD48L3A+PC9kaXY+
PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+Jmd0OyZndDsgRGF2ZS9LZW50OiBEbyBlaXRoZXIgb2Yg
eW91IGhhdmUgYW4gdXBkYXRlIHlvdSBjYW4gc2hhcmU/PG86cD48L286cD48L3A+PC9kaXY+PGRp
dj48cCBjbGFzcz1Nc29Ob3JtYWw+Jmd0OyZndDsmbmJzcDs8bzpwPjwvbzpwPjwvcD48L2Rpdj48
ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4mZ3Q7Jmd0OyBBZGFtPG86cD48L286cD48L3A+PC9kaXY+
PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+Jmd0OyZndDsmbmJzcDs8bzpwPjwvbzpwPjwvcD48L2Rp
dj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4mZ3Q7Jmd0OyZuYnNwOzxvOnA+PC9vOnA+PC9wPjwv
ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPiZndDsmZ3Q7Jm5ic3A7PG86cD48L286cD48L3A+
PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+Jmd0OyZndDsgX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2Pjxw
IGNsYXNzPU1zb05vcm1hbD4mZ3Q7Jmd0OyBzYWNtIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9w
PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPiZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzpz
YWNtQGlldGYub3JnIj5zYWNtQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+
PHAgY2xhc3M9TXNvTm9ybWFsPiZndDsmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn
L21haWxtYW4vbGlzdGluZm8vc2FjbSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0
aW5mby9zYWNtPC9hPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFs
PiZuYnNwOzxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvYmxvY2txdW90ZT48ZGl2PjxwIGNsYXNzPU1z
b05vcm1hbD4mbmJzcDs8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1h
bD5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9v
OnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPnNhY20gbWFpbGluZyBsaXN0PG86
cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PGEgaHJlZj0ibWFpbHRv
OnNhY21AaWV0Zi5vcmciPnNhY21AaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3A+PC9kaXY+PGRp
dj48cCBjbGFzcz1Nc29Ob3JtYWw+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h
bi9saXN0aW5mby9zYWNtIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Nh
Y208L2E+PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+X19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvcD48
L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5zYWNtIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+
PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxhIGhyZWY9Im1haWx0bzpzYWNtQGll
dGYub3JnIj5zYWNtQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xh
c3M9TXNvTm9ybWFsPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu
Zm8vc2FjbSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zYWNtPC9hPjxv
OnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPl9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3A+PC9kaXY+PGRp
dj48cCBjbGFzcz1Nc29Ob3JtYWw+c2FjbSBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvcD48L2Rp
dj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48YSBocmVmPSJtYWlsdG86c2FjbUBpZXRmLm9yZyI+
c2FjbUBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05v
cm1hbD48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NhY20i
Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2FjbTwvYT48bzpwPjwvbzpw
PjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4mbmJzcDs8bzpwPjwvbzpwPjwvcD48
L2Rpdj48L2Rpdj48L2Rpdj48L2Jsb2NrcXVvdGU+PHAgY2xhc3M9TXNvTm9ybWFsPjxicj48YnI+
PGJyPjxicj48YnI+PG86cD48L286cD48L3A+PHByZT5fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9wcmU+PHByZT5zYWNtIG1haWxpbmcg
bGlzdDxvOnA+PC9vOnA+PC9wcmU+PHByZT48YSBocmVmPSJtYWlsdG86c2FjbUBpZXRmLm9yZyI+
c2FjbUBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvcHJlPjxwcmU+PGEgaHJlZj0iaHR0cHM6Ly93
d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zYWNtIj5odHRwczovL3d3dy5pZXRmLm9yZy9t
YWlsbWFuL2xpc3RpbmZvL3NhY208L2E+PG86cD48L286cD48L3ByZT48cCBjbGFzcz1Nc29Ob3Jt
YWwgc3R5bGU9J21hcmdpbi1ib3R0b206MTIuMHB0Jz4mbmJzcDs8bzpwPjwvbzpwPjwvcD48cCBj
bGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206MTIuMHB0Jz4mbmJzcDs8bzpwPjwv
bzpwPjwvcD48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4tLSA8bzpwPjwvbzpwPjwvcD48cCBzdHls
ZT0nbGluZS1oZWlnaHQ6MTIuMHB0Jz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjVwdDtmb250
LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojMzMzMzMzJz5qT1ZBTC5vcmc6IE9W
QUwgaW1wbGVtZW50ZWQgaW4gSmF2YS48L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo4LjVw
dDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojMzMzMzMzJz48YnI+PC9z
cGFuPjxpPjxzcGFuIHN0eWxlPSdmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwi
c2Fucy1zZXJpZiI7Y29sb3I6IzMzMzMzMyc+U2NhbiBhbnkgbWFjaGluZSBmcm9tIGFueSBtYWNo
aW5lLiBGb3IgZnJlZSE8L3NwYW4+PC9pPjxzcGFuIHN0eWxlPSdmb250LXNpemU6OC41cHQ7Zm9u
dC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6IzMzMzMzMyc+PGJyPjwvc3Bhbj48
YSBocmVmPSJodHRwOi8vd3d3LmpvdmFsLm9yZyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo4LjVw
dDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojMzM2NjAwJz5MZWFybiBN
b3JlPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjguNXB0O2ZvbnQtZmFtaWx5OiJB
cmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiMzMzMzMzMnPiB8IDwvc3Bhbj48YSBocmVmPSJodHRw
Oi8vd3d3LmpvdmFsLm9yZy9mZWF0dXJlcy8iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6OC41cHQ7
Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6IzMzNjYwMCc+RmVhdHVyZXM8
L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSdmb250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6IkFyaWFs
Iiwic2Fucy1zZXJpZiI7Y29sb3I6IzMzMzMzMyc+IHwgPC9zcGFuPjxhIGhyZWY9Imh0dHA6Ly93
d3cuam92YWwub3JnL2Rvd25sb2FkLyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo4LjVwdDtmb250
LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojMzM2NjAwJz5Eb3dubG9hZDwvc3Bh
bj48L2E+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo4LjVwdDtmb250LWZhbWlseToiQXJpYWwiLCJz
YW5zLXNlcmlmIjtjb2xvcjojMzMzMzMzJz4gPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2Pjxw
IGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbToxMi4wcHQnPjxvOnA+Jm5ic3A7
PC9vOnA+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPi0tIDxvOnA+PC9vOnA+PC9wPjxwIHN0
eWxlPSdsaW5lLWhlaWdodDoxMi4wcHQnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuNXB0O2Zv
bnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiMzMzMzMzMnPmpPVkFMLm9yZzog
T1ZBTCBpbXBsZW1lbnRlZCBpbiBKYXZhLjwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjgu
NXB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiMzMzMzMzMnPjxicj48
L3NwYW4+PGk+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseToiQXJpYWwi
LCJzYW5zLXNlcmlmIjtjb2xvcjojMzMzMzMzJz5TY2FuIGFueSBtYWNoaW5lIGZyb20gYW55IG1h
Y2hpbmUuIEZvciBmcmVlITwvc3Bhbj48L2k+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo4LjVwdDtm
b250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojMzMzMzMzJz48YnI+PGEgaHJl
Zj0iaHR0cDovL3d3dy5qb3ZhbC5vcmciPjxzcGFuIHN0eWxlPSdjb2xvcjojMzM2NjAwJz5MZWFy
biBNb3JlPC9zcGFuPjwvYT4gfCA8YSBocmVmPSJodHRwOi8vd3d3LmpvdmFsLm9yZy9mZWF0dXJl
cy8iPjxzcGFuIHN0eWxlPSdjb2xvcjojMzM2NjAwJz5GZWF0dXJlczwvc3Bhbj48L2E+IHwgPGEg
aHJlZj0iaHR0cDovL3d3dy5qb3ZhbC5vcmcvZG93bmxvYWQvIj48c3BhbiBzdHlsZT0nY29sb3I6
IzMzNjYwMCc+RG93bmxvYWQ8L3NwYW4+PC9hPiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+
PC9kaXY+PC9ib2R5PjwvaHRtbD4=

--_000_D7A0423E5E193F40BE6E94126930C4930B98C82362MBCLUSTERxcha_--

From jerome@netpeas.com  Mon Apr 30 10:32:56 2012
Return-Path: 
X-Original-To: sacm@ietfa.amsl.com
Delivered-To: sacm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98BE721E802C for ; Mon, 30 Apr 2012 10:32:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level: 
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wYMy+dI16Koe for ; Mon, 30 Apr 2012 10:32:56 -0700 (PDT)
Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [217.70.183.196]) by ietfa.amsl.com (Postfix) with ESMTP id 9A8DD21F8855 for ; Mon, 30 Apr 2012 10:32:55 -0700 (PDT)
X-Originating-IP: 217.70.178.142
Received: from mfilter14-d.gandi.net (mfilter14-d.gandi.net [217.70.178.142]) by relay4-d.mail.gandi.net (Postfix) with ESMTP id 39BA31720A9; Mon, 30 Apr 2012 19:32:44 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at mfilter14-d.gandi.net
Received: from relay4-d.mail.gandi.net ([217.70.183.196]) by mfilter14-d.gandi.net (mfilter14-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id VchRtrRrQInD; Mon, 30 Apr 2012 19:32:42 +0200 (CEST)
X-Originating-IP: 196.217.192.200
Received: from [192.168.1.9] (adsl196-200-192-217-196.adsl196-15.iam.net.ma [196.217.192.200]) (Authenticated sender: jerome@netpeas.com) by relay4-d.mail.gandi.net (Postfix) with ESMTPA id 210B617207C; Mon, 30 Apr 2012 19:32:42 +0200 (CEST)
Message-ID: <4F9ECCB8.8020003@netpeas.com>
Date: Mon, 30 Apr 2012 17:32:40 +0000
From: Jerome Athias 
Organization: NETpeas
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: sacm@ietf.org, Multiple recipients of list 
References: <4F9ECC63.8080501@netpeas.com>
In-Reply-To: <4F9ECC63.8080501@netpeas.com>
X-Enigmail-Version: 1.4.1
X-Forwarded-Message-Id: <4F9ECC63.8080501@netpeas.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090603040708090401020708"
Subject: [sacm] Fwd: CWEs translation
X-BeenThere: sacm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 30 Apr 2012 17:32:56 -0000

Ceci est un message signé cryptographiquement au format MIME.

--------------ms090603040708090401020708
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


Hi list,

I finished the translation into french of all available CWEs (Titles +
Descriptions).
We use it for our CERT.
I should soon share this work with french CERTs, but I would like to
know if others could provide a translation in other languages?
(I know some spain guys are working on it)

Thanks
My 5 euro cents

--=20
Jerome Athias - NETpeas
VP, Director of Software Engineer
Palo Alto - Paris - Casablanca
www.netpeas.com
---------------------------------------------

"The computer security is an art form. It's the ultimate martial art."



--------------ms090603040708090401020708
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: Signature cryptographique S/MIME

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIO1jCC
BIowggNyoAMCAQICECf06hH0eobEbp27bqkXBwcwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UE
BhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h
bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0w
NTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMC
VVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5l
dHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO
LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG
9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVN
NRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQy
lbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXq
vgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6
hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu
9mIwFIws6wIDAQABo4HhMIHeMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0G
A1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/
BAUwAwEB/zB7BgNVHR8EdDByMDigNqA0hjJodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9BZGRU
cnVzdEV4dGVybmFsQ0FSb290LmNybDA2oDSgMoYwaHR0cDovL2NybC5jb21vZG8ubmV0L0Fk
ZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQAZ2IkRbyispgCi
54fBm5AD236hEv0e8+LwAamUVEJrmgnEoG3XkJIEA2Z5Q3H8+G+v23ZF4jcaPd3kWQR4rBz0
g0bzes9bhHIt5UbBuhgRKfPLSXmHPLptBZ2kbWhPrXIUNqi5sf2/z3/wpGqUNVCPz4FtVbHd
WTBK322gnGQfSXzvNrv042n0+DmPWq1LhTq3Du3Tzw1EovsEv+QvcI4l+1pUBrPQxLxtjftz
Mizpm4QkLdZ/kXpoAlAfDj9N6cz1u2fo3BwuO/xOzf4CjuOoEwqlJkRl6RDyTVKnrtw+ymsy
XEFs/vVdoOr/0fqbhlhtPZZH5f4ulQTCAMyOofK7MIIFGjCCBAKgAwIBAgIQbRnqpxlPajMi
5iIyeqpx3jANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcw
FQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3Jr
MSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VS
Rmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0xMTA0MjgwMDAwMDBa
Fw0yMDA1MzAxMDQ4MzhaMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5j
aGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5
MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls
IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoSEW0tXmNReL4uk4UDIo1NY
X2Zl8TJO958yfVXQeExVt0KU4PkncQfFxmmkuTLE8UAakMwnVmJ/F7Vxaa7lIBvky2NeYMqi
QfZq4aP/uN8fSG1lQ4wqLitjOHffsReswtqCAtbUMmrUZ28gE49cNfrlVICv2HEKHTcKAlBT
bJUdqRAUtJmVWRIx/wmi0kzcUtve4kABW0ho3cVKtODtJB86r3FfB+OsvxQ7sCVxaD30D9YX
WEYVgTxoi4uDD216IVfmNLDbMn7jSuGlUnJkJpFOpZIP/+CxYP0ab2hRmWONGoulzEKbm30i
Y9OpoPzOnpDfRBn0XFs1uhbzp5v/wQIDAQABo4IBSzCCAUcwHwYDVR0jBBgwFoAUiYJnfcSd
JnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MA4GA1UdDwEB
/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEAMBEGA1UdIAQKMAgwBgYEVR0gADBYBgNVHR8E
UTBPME2gS6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVROLVVTRVJGaXJzdC1DbGll
bnRBdXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDB0BggrBgEFBQcBAQRoMGYwPQYIKwYBBQUH
MAKGMWh0dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BZGRUcnVzdENsaWVudF9DQS5jcnQw
JQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQEFBQAD
ggEBAIXWvnhXVW0zf0RS/kLVBqgBA4CK+w2y/Uq/9q9BSfUbWsXSrRtzbj7pJnzmTJjBMCjf
y/tCPKElPgp11tA9OYZm0aGbtU2bb68obB2v5ep0WqjascDxdXovnrqTecr+4pEeVnSy+I3T
4ENyG+2P/WA5IEf7i686ZUg8mD2lJb+972DgSeUWyOs/Q4Pw4O4NwdPNM1+b0L1garM7/vrU
yTo8H+2b/5tJM75CKTmD7jNpLoKdRU2oadqAGx490hpdfEeZpZsIbRKZhtZdVwcbpzC+S0lE
uJB+ytF5OOu0M/qgOl0mWJ5hVRi0IdWZ1eBDQEIwvuql55TSsP7zdfl/bucwggUmMIIEDqAD
AgECAhEA5lTT8LELIS0mX9H+gyGlPjANBgkqhkiG9w0BAQUFADCBkzELMAkGA1UEBhMCR0Ix
GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE
ChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGlj
YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xMTEyMTIwMDAwMDBaFw0xMjEyMTEyMzU5
NTlaMCMxITAfBgkqhkiG9w0BCQEWEmplcm9tZUBuZXRwZWFzLmNvbTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBALJedpRkN6A8OYLCZg6uoO+XLaTLW82TpVwNgxlEZ8J0JG6D
PwXSCBkfpDPyf6DdDNz+ebCociHK5c2iluLcn5OGO+krH2+Dh5j2JrzU0Tl6jdJBeW3SycVM
yaiAvqNuZlGTp8VRm+X3XAepBOAk3ySjt4pD+g8bcGppv7yyBdk96nQaQX0oU0WXuw4a0Psd
9a89rmr9JXxgxdyDE4ZF0f1C8CNV+2Gle0v4l504WUBo8yLIlqtUuof3P7gSyQUJfV83usqu
f82LvAXSZo1dab3nyT8otkO7zIi6m1CiLZy7K1PipVwyEVR83tPvAQcytApUb4cPgL1K+4rC
DY4qdmsCAwEAAaOCAeIwggHeMB8GA1UdIwQYMBaAFHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MB0G
A1UdDgQWBBQ0/atJh7Q439DmP6hqHGk0+wNEJzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/
BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQD
AgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8v
c2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBKoEiGRmh0dHA6Ly9jcmwuY29t
b2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5j
cmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2NydC5jb21vZG9jYS5j
b20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggr
BgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMB0GA1UdEQQWMBSBEmplcm9tZUBu
ZXRwZWFzLmNvbTANBgkqhkiG9w0BAQUFAAOCAQEAHkzuV1Jj4D4FpqTFXlfIw8Mme0DjT1NR
7Cq/vpOpp5JWrnvsb/f5pR51MloHayVXBrpoKdrLfPl6z7dalB9oPDfyT5DONipXUShvftZC
DXAHW2kGbBSKRmoe9i0WOWz9KfG5qtxXIDiJXp/fLO2dGvyohYoRBODledjTrsoTP4VhvFCK
R6UCqMFcX9i+5I7Qp+DFpQUEWE49c3nYaFOmQS5qYb0BJkk9qq4OqR4DgBT7TIhMKSjLAOlB
c49AyivZoaFmoyLmu6wdf/m5lrqzGjdKSZCxOZ0OdupA+qEpaniJBj/nCK5XlvC3efDP8x70
p1w3/jCRBlHHYtpqUEnJ5zGCBA8wggQLAgEBMIGpMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UE
CBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01P
RE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBh
bmQgU2VjdXJlIEVtYWlsIENBAhEA5lTT8LELIS0mX9H+gyGlPjAJBgUrDgMCGgUAoIICOjAY
BgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjA0MzAxNzMyNDBa
MCMGCSqGSIb3DQEJBDEWBBRzrLXUE3fpjk5N5u62pI0J2nmCXTBfBgkqhkiG9w0BCQ8xUjBQ
MAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwIC
AUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgboGCSsGAQQBgjcQBDGBrDCBqTCBkzELMAkG
A1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y
ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQg
QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAOZU0/CxCyEtJl/R/oMhpT4w
gbwGCyqGSIb3DQEJEAILMYGsoIGpMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRl
ciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGlt
aXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJl
IEVtYWlsIENBAhEA5lTT8LELIS0mX9H+gyGlPjANBgkqhkiG9w0BAQEFAASCAQAMO3B2L8DU
+ZlpbPP2c+HF9OhtozMb9lE5ivvV5flbm+Z4HvskaW1DW/CNFb/eqzJ1m5m7WVznyWpm47eq
2TzTN9Qj+Y5vS/zEUGvBZebH3pG8D3h/WJpWEHsiHdwunPCM+l3bWONJsxxz2nFhoLzuMuCl
o1vh0K14Hxpuvt5QojzfWmWkDbcVoKlvDeYOKFkmd40cmQrNQ+EhynWHxdzIl7WZMVydgks/
pZIAlv4Bp3I2GAaSuCdB4VMROUtYUEgChtoq85F3AfQI5lzWrNY/pkd1BDTdLx6ZIMRolXiS
WXQCvetHHLjMejR3jwYsb8AdE1TAGObc287VD7jg0/xxAAAAAAAA
--------------ms090603040708090401020708--