From johnp.field@emc.com Wed Oct 3 12:33:20 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38C2721F84FC for ; Wed, 3 Oct 2012 12:33:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.399 X-Spam-Level: X-Spam-Status: No, score=-0.399 tagged_above=-999 required=5 tests=[AWL=-1.600, BAYES_50=0.001, J_CHICKENPOX_33=0.6, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o77G88xbomTH for ; Wed, 3 Oct 2012 12:33:19 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 270E021F84EA for ; Wed, 3 Oct 2012 12:33:18 -0700 (PDT) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q93JXDdX031753 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Oct 2012 15:33:14 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.226]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Wed, 3 Oct 2012 15:33:03 -0400 Received: from mxhub31.corp.emc.com (mxhub31.corp.emc.com [128.222.70.171]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q93JX2bl016617; Wed, 3 Oct 2012 15:33:02 -0400 Received: from mx14a.corp.emc.com ([169.254.1.172]) by mxhub31.corp.emc.com ([128.222.70.171]) with mapi; Wed, 3 Oct 2012 15:33:02 -0400 From: "Field, John" To: Francis Brosnan Blazquez , "stpeter@jabber.org" Date: Wed, 3 Oct 2012 15:33:00 -0400 Thread-Topic: [mile] Transport discussion was: New draft notification ... Thread-Index: Ac2do9gYVcl4eOnmTCeWmO4W+ozyNQD+OGuQ Message-ID: References: <5065D9ED.9020801@stpeter.im> <1348854344.3622.177.camel@vulcan.aspl.local> 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" Subject: Re: [mile] Transport discussion was: New draft notification ... X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 19:33:20 -0000 VGhhbmtzIGV2ZXJ5b25lIGZvciB0aGVzZSBjb21tZW50cy4gICANCg0KUGV0ZXIsICANCkkgYWdy ZWUgdGhhdCBYTVBQIGlzIGEgZ29vZCBzdWdnZXN0aW9uIGZvciBhbnkgZXZlbnQgZHJpdmVuIHVz ZSBjYXNlcy4gIFNpbmNlIGl0IGlzIGJhc2VkIG9uIEhUVFAsIHRoZSBST0xJRSBSRVNUIG1vZGVs IGlzIGEgInB1bGwiIG1vZGVsLiAgSG93ZXZlciwgaWYgeW91IG5lZWQgdG8gcmVjZWl2ZSBhc3lu Y2hyb25vdXMgbm90aWZpY2F0aW9uIG9mIHNvbWUgZXZlbnQsIHNheSwgYW4gYWxhcm0gZnJvbSBh biBpbnRydXNpb24gZGV0ZWN0aW9uIHN5c3RlbSwgZXRjLiwgdGhlbiBYTVBQIG1heSBiZSBhIHZl cnkgZ29vZCBjaG9pY2UgZm9yIHRoYXQuICBJIHRoaW5rIHRoaXMgYXBwcm9hY2ggd291bGQgYmUg Y29tcGxlbWVudGFyeSB0byB0aGUgY3VycmVudCBST0xJRSBkcmFmdCwgYW5kIFhNUFAgY291bGQg Y28tZXhpc3QgbmljZWx5ICh0byBzdXBwb3J0IHRob3NlIGRpZmZlcmVudCB0eXBlcyBvZiB1c2Ug Y2FzZXMgYW5kIGNvbnN1bWVycykuICBJIGRvbid0IGhhdmUgYSBuZWVkIHRvIHB1cnN1ZSB0aGUg ZXZlbnQtZHJpdmVuIHVzZSBjYXNlIGluIG15IGN1cnJlbnQgd29yaywgYnV0IEkgd291bGQgYmUg c3VwcG9ydGl2ZSBpZiBzb21lb25lIHdhbnRlZCB0byBwdXJzdWUgdGhhdCBhbmQgd3JpdGUgc29t ZXRoaW5nIHVwLg0KDQpGcmFuY2lzLA0KSSBhbSBub3QgYW4gZXhwZXJ0IG9uIEJFRVAgc28gSSBj YW4ndCBjb21tZW50IHRvbyBtdWNoIG9uIHRoZSBwcm9zIGFuZCBjb25zIG9mIHVzaW5nIGl0LiAg SW4gcHJpbmNpcGFsLCBpdCBzZWVtcyB0byBtZSB0aGF0IEJFRVAgY291bGQgYmUgYSBnb29kIGNo b2ljZSBmb3IgYSB0cmFkaXRpb25hbCBSSUQgZXhjaGFuZ2UgaW4gYSAqbWVzc2FnZS1iYXNlZCBh cmNoaXRlY3R1cmUqLiAgSW50ZXJlc3RpbmcgdG8ga25vdyAodmlhIEthdGhsZWVuJ3MgcHJpb3Ig cG9zdCksIHRoYXQgaW4gZmFjdCBCRUVQICsgUklEIGhhcyBhbHJlYWR5IGJlZW4gZXhwbG9yZWQs IGJ1dCB0aGUgY29tbXVuaXR5IGNob3NlIHRvIHN3aXRjaCBvdmVyIHRvIEhUVFAgZm9yIHJlYXNv bnMgb2YgbG93IGRlcGxveW1lbnQgb2YgQkVFUC4gIFNvIHRoaXMgbWF5IGJlIG1vb3QsIHVubGVz cyB0aGVyZSBpcyBub3cgZ3JlYXRlciBhZG9wdGlvbiBvZiBCRUVQLCBpbiB3aGljaCBjYXNlIHRo ZSBncm91cCBtaWdodCB3YW50IHRvIHJldmlzaXQgdGhhdC4NCg0KDQpNeSByZWFzb24gZm9yIHdy aXRpbmcgdGhlIFJPTElFIGRyYWZ0IHdhcyBub3QganVzdCBhIG1hdHRlciBvZiBkZWZpbmluZyBh IGRpZmZlcmVudCB0cmFuc3BvcnQgcHJvdG9jb2wuICBJbmRlZWQgUkZDIDY1NDYgYWxyZWFkeSBz cGVjaWZpZXMgYSBzaW1wbGUgSFRUUCBiaW5kaW5nIGZvciBSSUQuICBUaGUgZ29hbCBmb3IgUk9M SUUgd2FzIHRvIGVuYWJsZSBhbiBlbnRpcmVseSBkaWZmZXJlbnQgaW50ZXJhY3Rpb24gbW9kZWws IG9uZSB0aGF0IGZvbGxvd3MgdGhlIFJFU1RmdWwgYXJjaGl0ZWN0dXJhbCBzdHlsZSwgcmF0aGVy IHRoYW4gYSBtZXNzYWdlIGV4Y2hhbmdlIG1vZGVsLiAgSW4gc2hvcnQsIHRoaXMgbWVhbnMgdGhh dDoNCg0KLSBldmVyeXRoaW5nIGlzIGEgcmVzb3VyY2UNCi0gYWxsIHJlc291cmNlcyBhcmUgYWRk cmVzc2FibGUgdmlhIGEgVVJMDQotIHN1cHBvcnQgZm9yIGEgVW5pZm9ybSBpbnRlcmZhY2UgKGlu IHRoZSBjYXNlIG9mIEhUVFA6IEdFVCwgUFVULCBQT1NULCBERUxFVEUsIEhFQUQgKChQQVRDSCkp Lg0KLSB1c2UgTWVkaWEgdHlwZXMgdG8gbmVnb3RpYXRlIHRoZSByZXByZXNlbnRhdGlvbiBzZW50 IHRvIHRoZSBjbGllbnQgKGkuZS4gSFRNTCwgQXBwbGljYXRpb24vQXRvbStYTUwsIFhNTCtSSUQs IFhNTCtJT0RFRiwgSlNPTiwgUERGLCBvdGhlci4uLikNCi0gdXNlIEh5cGVydGV4dCBhcyB0aGUg RW1ib2RpbWVudCBvZiBBcHBsaWNhdGlvbiBTdGF0ZSAoSEFURU9BUykNCg0KU28gdGhlIGludGVu dCBpcyB0byBwcm92aWRlIGEgbmV3L2JldHRlciBhbHRlcm5hdGl2ZSB0aGF0IHdpbGwgaW1wcm92 ZSBjeWJlciBzZWN1cml0eSBpbmZvcm1hdGlvbiBzaGFyaW5nLCBieSBtb3ZpbmcgZnJvbSBhIG1l c3NhZ2UtYmFzZWQgbW9kZWwgdG8gYSBtb3JlIGxvb3NlbHktY291cGxlZCByZXNvdXJjZS1iYXNl ZCBhcHByb2FjaC4gIEluIHRoZW9yeSwgb25lIGNhbiBldmVuIGRvIHRoZSBSRVNUIHN0eWxlIHdp dGhvdXQgbmVjZXNzYXJpbHkgdXNpbmcgSFRUUCwgYWx0aG91Z2ggYXMgYSBwcmFjdGljYWwgbWF0 dGVyLCByZWFsIHN5c3RlbXMgYWx3YXlzIHVzZSBIVFRQIGJlY2F1c2UgaXQgaXMgdWJpcXVpdG91 cy4NCg0KTG90cyBoYXMgYWxyZWFkeSBiZWVuIHdyaXR0ZW4gb24gdGhlIHByb3MgYW5kIGNvbnMg b2YgbWVzc2FnZS1vcmllbnRlZCB2ZXJzdXMgcmVzb3VyY2Utb3JpZW50ZWQgYXJjaGl0ZWN0dXJl cyAoaS5lLiAiU09BUCB2ZXJzdXMgUkVTVCIpIHNvIEkgd29uJ3QgcmVoYXNoIGFsbCB0aG9zZSBk aXNjdXNzaW9ucyBoZXJlICh1bmxlc3Mgd2UgcmVhbGx5IHdhbnQgdG8pLiAgDQoNCkkgcHJlZmVy IHRoZSBSRVNUIG1vZGVsIGR1ZSB0byBpdHMgc2ltcGxpY2l0eSBhbmQgZmxleGliaWxpdHksIGFu ZCBJIHRob3VnaHQgaXQgY291bGQgYmUgaGVscGZ1bCB0byBzcGVjaWZpY2FsbHkgZGVzY3JpYmUg aG93IHRoZSBSRVNUIGFwcHJvYWNoIGNvdWxkIGJlIGFwcGxpZWQgdG8gc29tZSBvZiB0aGUgdXNl IGNhc2VzIG9mIGludGVyZXN0IHRvIHRoZSBNSUxFIGNvbW11bml0eS4gIElmIHdlIGNhbiBtYWtl IHRoZSBleGNoYW5nZSBvZiBjeWJlciBzZWN1cml0eSBpbmZvcm1hdGlvbiBzaW1wbGVyIGFuZCBl YXNpZXIsIHRoZW4gdGhhdCBtaWdodCBoZWxwIHRvIG1ha2UgdXMgYWxsIHNhZmVyLg0KDQpUaGFu a3MgYWdhaW4sIEkgYXBwcmVjaWF0ZSBwZW9wbGUgdGFraW5nIHRoZSB0aW1lIHRvIGNvbW1lbnQu ICBMb29raW5nIGZvcndhcmQgdG8gbW9yZSBnb29kIGRpc2N1c3Npb24uLi4NCg0KUmVnYXJkcywN CkpvaG4NCg0KLy8gSm9obiBQLiBGaWVsZCANCi8vIFNlY3VyaXR5IEFyY2hpdGVjdCANCi8vIEVN QyBPZmZpY2Ugb2YgdGhlIENUTyANCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpG cm9tOiBNb3JpYXJ0eSwgS2F0aGxlZW4gW21haWx0bzprYXRobGVlbi5tb3JpYXJ0eUBlbWMuY29t XSANClNlbnQ6IEZyaWRheSwgU2VwdGVtYmVyIDI4LCAyMDEyIDI6MDUgUE0NClRvOiBGcmFuY2lz IEJyb3NuYW4gQmxhenF1ZXoNCkNjOiBtaWxlQGlldGYub3JnDQpTdWJqZWN0OiBbbWlsZV0gVHJh bnNwb3J0IGRpc2N1c3Npb24gd2FzOiBOZXcgZHJhZnQgbm90aWZpY2F0aW9uIC4uLg0KDQpJbnRl cmVzdGluZy4uLiAgUklEIHVzZWQgQkVFUCBpbiBhbiBlYXJsaWVyIHZlcnNpb24gYmVjYXVzZSBv ZiB0aGUgc3VpdGFiaWxpdHkgdG8gdGhlIHByb3RvY29sIG5lZWRzLCBidXQgYmVjYXVzZSBvZiBs b3cgZGVwbG95bWVudCBvZiBCRUVQLCB3ZSBzd2l0Y2hlZCB0byBIVFRQUy4NCg0KSSBhbSBjdXJp b3VzIHRvIHNlZSBpZiBkaWZmZXJlbnQgZXhjaGFuZ2UgdHlwZXMgbWF5IHVzZSBkaWZmZXJlbnQg YmluZGluZ3MuICBUaGUgUkVTVGZ1bCBiaW5kaW5nIGluIHRoZSBST0xJRSBkcmFmdCBtYXkgYmUg d2VsbCBzdWl0ZWQgZm9yIHJlcG9zaXRvcnkgYWNjZXNzIGFuZCBJT0RFRiArIFJJRCArIHRyYW5z cG9ydCB3aGVyZSBvYmplY3Qgc2VjdXJpdHkgaXMgbmVlZGVkLiAgV2hhdCBhcmUgdGhlIHVzZSBj YXNlcyBmb3IgZWFjaCBpZiB0aGV5IGRpZmZlciBhbmQgd2hhdCBkbyBmb2xrcyBwcmVmZXIgYW5k IHRoaW5rIHdpbGwgaGVscCBhZG9wdGlvbi4NCg0KQXMgQnJpYW4gc2FpZCwgb3RoZXIgZm9ybWF0 cyBhcmUgcG9zc2libGUuICBJT0RFRiBoYXMgYmVlbiBpbXBsZW1lbnRlZCBpbiBKU09OIGZyb20g dGhlIGRhdGEgbW9kZWwgZGVzY3JpcHRpb24gYWxyZWFkeS4NCg0KSSB3b3VsZCBsb3ZlIHRvIHNl ZSBtb3JlIHZpZXdzIG9uIHRoaXMgZGlzY3Vzc2lvbiENCg0KVGhhbmtzLA0KS2F0aGxlZW4NCg0K DQpTZW50IGZyb20gbXkgaVBob25lDQoNCk9uIFNlcCAyOCwgMjAxMiwgYXQgMTo0NiBQTSwgIkZy YW5jaXMgQnJvc25hbiBCbGF6cXVleiIgPGZyYW5jaXNAYXNwbC5lcz4gd3JvdGU6DQoNCj4gSGks DQo+IA0KPiBUaGUgd29ya2luZyBncm91cCBjb3VsZCBhbHNvIGNvbnNpZGVyIEJFRVAuIEl0IGlz IGxpZ2h0d2VpZ2h0LA0KPiBleHRlbnNpYmxlIGFuZCBpdCBhbGxvd3MgYW55IGZvcm1hdCBmb3Ig eW91ciBtZXNzYWdlIChzaW5jZSBpdCBzZWVzIHRoZQ0KPiBwYXlsb2FkIGFzIGEgYnVuY2ggb2Yg b2N0ZXRzKS4gDQo+IA0KPiBTcGVjaWZpY2FsbHksIHdlIGFyZSB1c2luZyBpdCBpbiBhIHJlYWwt dGltZSBtb25pdG9yaW5nIHNvbHV0aW9uIHdoZXJlDQo+IGh1bmRyZWQgb2Ygbm9kZXMgYXJlIHdh dGNoZWQgYW5kIHF1ZXJpZWQsIHdpdGhvdXQgaGF2aW5nIHRvIHVzZSBhDQo+IHBvbGxpbmcgc29s dXRpb25zIHRvIGdldCB0aG9zZSBldmVudHMuLi4NCj4gDQo+IEJlc3QgUmVnYXJkcywNCj4gDQo+ PiAtLS0tLUJFR0lOIFBHUCBTSUdORUQgTUVTU0FHRS0tLS0tDQo+PiBIYXNoOiBTSEExDQo+PiAN Cj4+IE9uIDkvMjgvMTIgMTE6MDAgQU0sIEpvaG4gSG93aWUgd3JvdGU6DQo+PiANCj4+PiBJIHdv dWxkIHJlYWxseSBsaWtlIHRvIHNlZSBpbmZvcm1hdGlvbiBleGNoYW5nZSBiZSBzZWN1cmUsIGZh c3QNCj4+PiBhbmQgbGlnaHR3ZWlnaHQsIGFuZCBhIG5ldyBwcm90b2NvbCBjb3VsZCB3ZWxsIGJl IHByZWZlcmFibGUgaGVyZS4NCj4+IA0KPj4gSWYgeW91IGRpZG4ndCBoYXZlIGEgYmlhcyBhZ2Fp bnN0IFhNTCwgWE1QUCB3b3VsZCBiZSBhIGdvb2Qgc29sdXRpb24NCj4+IHRvIHRoZSByZXF1aXJl bWVudHMgeW91J3ZlIG91dGxpbmVkLg0KPj4gDQo+PiAoV2l0aCByZWdhcmQgdG8gdGhlICJibG9h dCIgb2YgWE1MLCBub3RlIHRoYXQgWE1QUCB1c2VzIGxvbmctbGl2ZWQgWE1MDQo+PiBzdHJlYW1z IHNvIHRoZSBjb21wcmVzc2lvbiByYXRpb3MgYXJlIHNpZ25pZmljYW50LikNCj4+IA0KPj4gUGV0 ZXINCj4+IA0KPj4gLSAtLSANCj4+IFBldGVyIFNhaW50LUFuZHJlDQo+PiBodHRwczovL3N0cGV0 ZXIuaW0vDQo+PiANCj4+IA0KPj4gLS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0NCj4+IFZl cnNpb246IEdudVBHL01hY0dQRzIgdjIuMC4xOCAoRGFyd2luKQ0KPj4gQ29tbWVudDogVXNpbmcg R251UEcgd2l0aCBNb3ppbGxhIC0gaHR0cDovL3d3dy5lbmlnbWFpbC5uZXQvDQo+PiANCj4+IGlF WUVBUkVDQUFZRkFsQmwyZTBBQ2drUU5MOGs1QTJ3L3Z3US9BQ2ZRL0pvTGYwOGplNldvQmtrOUEr T3BxVG8NCj4+IDA5d0FvT29DUllwMUltU0FKTUtNV0NsREtMMjZxbEo0DQo+PiA9REp6TQ0KPj4g LS0tLS1FTkQgUEdQIFNJR05BVFVSRS0tLS0tDQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPj4gbWlsZSBtYWlsaW5nIGxpc3QNCj4+IG1pbGVAaWV0 Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWlsZQ0KPiAN Cj4gLS0gDQo+IEZyYW5jaXMgQnJvc25hbiBCbMOhenF1ZXogPGZyYW5jaXMuYnJvc25hbkBhc3Bs LmVzPg0KPiBBU1BMDQo+IDkxIDEzNCAxNCAyMiAtIDkxIDEzNCAxNCA0NSAtIDkxIDExNiAwNyA1 Nw0KPiANCj4gQVZJU08gTEVHQUwNCj4gDQo+IEVzdGUgbWVuc2FqZSBzZSBkaXJpZ2UgZXhjbHVz aXZhbWVudGUgYSBzdSBkZXN0aW5hdGFyaW8uIExvcyBkYXRvcw0KPiBpbmNsdWlkb3MgZW4gZWwg cHJlc2VudGUgY29ycmVvIHNvbiBjb25maWRlbmNpYWxlcyB5IHNvbWV0aWRvcyBhIHNlY3JldG8N Cj4gcHJvZmVzaW9uYWwsIHNlIHByb2jDrWJlIGRpdnVsZ2FybG9zLCBlbiB2aXJ0dWQgZGUgbGFz IGxleWVzIHZpZ2VudGVzLiBTaQ0KPiB1c3RlZCBubyBsbyBlcyB5IGxvIGhhIHJlY2liaWRvIHBv ciBlcnJvciBvIHRpZW5lIGNvbm9jaW1pZW50byBkZWwgbWlzbW8NCj4gcG9yIGN1YWxxdWllciBt b3Rpdm8sIGxlIHJvZ2Ftb3MgcXVlIG5vcyBsbyBjb211bmlxdWUgcG9yIGVzdGUgbWVkaW8geQ0K PiBwcm9jZWRhIGEgZGVzdHJ1aXJsbyBvIGJvcnJhcmxvLg0KPiANCj4gRW4gdmlydHVkIGRlIGxv IGRpc3B1ZXN0byBlbiBsYSBMZXkgT3Jnw6FuaWNhIDE1LzE5OTksIGRlIDEzIGRlDQo+IGRpY2ll bWJyZSwgZGUgUHJvdGVjY2nDs24gZGUgRGF0b3MgZGUgQ2Fyw6FjdGVyIFBlcnNvbmFsLCBsZSBp bmZvcm1hbW9zIGRlDQo+IHF1ZSBzdXMgZGF0b3MgZGUgY2Fyw6FjdGVyIHBlcnNvbmFsLCByZWNv Z2lkb3MgZGUgZnVlbnRlcyBhY2Nlc2libGVzIGFsDQo+IHDDumJsaWNvIG8gZGF0b3MgcXVlIHVz dGVkIG5vcyBoYSBmYWNpbGl0YWRvIHByZXZpYW1lbnRlLCBwcm9jZWRlbiBkZQ0KPiBiYXNlcyBk ZSBkYXRvcyBwcm9waWVkYWQgZGUgQWR2YW5jZWQgU29mdHdhcmUgUHJvZHVjdGlvbiBMaW5lLCBT LkwuDQo+IChBU1BMKS4gTm8gb2JzdGFudGUsIHVzdGVkIHB1ZWRlIGVqZXJjaXRhciBzdXMgZGVy ZWNob3MgZGUgYWNjZXNvLA0KPiByZWN0aWZpY2FjacOzbiwgY2FuY2VsYWNpw7NuIHkgb3Bvc2lj acOzbiBkaXNwdWVzdG9zIGVuIGxhIG1lbmNpb25hZGEgTGV5DQo+IE9yZ8OhbmljYSwgbm90aWZp Y8OhbmRvbG8gcG9yIGVzY3JpdG8gYToNCj4gQVNQTCAtIFByb3RlY2Npw7NuIERhdG9zLCBDL0Fu dG9uaW8gU3XDoXJleiAxMCBBLTEwMiwgMjg4MDIsIEFsY2Fsw6EgZGUNCj4gSGVuYXJlcyAoTWFk cmlkKS4NCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+IG1pbGUgbWFpbGluZyBsaXN0DQo+IG1pbGVAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9taWxlDQo+IA0K From johnp.field@emc.com Wed Oct 3 12:58:32 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B86BE11E80BF; Wed, 3 Oct 2012 12:58:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ytfNG3VRw3SP; Wed, 3 Oct 2012 12:58:31 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id AA79611E80AE; Wed, 3 Oct 2012 12:58:31 -0700 (PDT) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q93JwO0b026743 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Oct 2012 15:58:28 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd04.lss.emc.com [10.254.222.226]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Wed, 3 Oct 2012 15:58:17 -0400 Received: from mxhub20.corp.emc.com (mxhub20.corp.emc.com [10.254.93.49]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q93JwBDV001943; Wed, 3 Oct 2012 15:58:11 -0400 Received: from mx14a.corp.emc.com ([169.254.1.172]) by mxhub20.corp.emc.com ([10.254.93.49]) with mapi; Wed, 3 Oct 2012 15:58:10 -0400 From: "Field, John" To: Luis Nunez Date: Wed, 3 Oct 2012 15:58:09 -0400 Thread-Topic: [sacm] New draft for review and comment: draft-field-mile-rolie-00.txt Thread-Index: Ac2MRtb5CUom2+9vTeiOHaLaHD6oZAVV2OZw 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" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: "mile@ietf.org" , "sacm@ietf.org" Subject: Re: [mile] [sacm] New draft for review and comment: draft-field-mile-rolie-00.txt X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 19:58:32 -0000 Luis, Sorry for the delay in responding, I have been quite busy with a few projec= ts and also traveling. Thanks for the feedback; scaprepo does look interes= ting... =20 I can easily imagine an integration where the representation of an "inciden= t" or "indicator" resource could also include a link to a corresponding SCA= P repository resource, say an OVAL benchmark or an OVAL def, etc. that is r= elated to the requested resource...a quick hack of an example might look so= mething like... HTTP/1.1 200 OK Date: Wed, 03 Oct 2012 17:30:11 GMT Content-Length: nnn Content-Type: application/atom+xml;type=3Dentry;charset=3D"utf-8" =20 http://www.example.org/csirt/private/incidents/123456 Sample Incident 2012-08-04T18:13:51.0Z 2012-08-05T18:13:51.0Z =20 =20 ... =20 =20 The possibility of such an integration is exactly what motivated the draft.= The issues that would need to be resolved include making the authenticatio= n to the scaprepo seamless (possible, at least in principal, using existing= Web Single Sign On protocols) and dealing with differences in interaction = style...for example, I notice that scaprepo seems to prefer the use of POST= for all operations (including a read operation). As a general rule, it is= best to support GET for read operations, and reserve POST for write operat= ions. But, this is a relatively minor issue at this point. The more impor= tant point is that by using a REST approach such an integration would becom= e possible, and that would be of benefit to users dealing with indicators, = incident response, and assessment and compliance, etc....we could tie it al= l together quite nicely. Thanks for commenting. I'll take a deeper look at scaprepo when I get some= more time. Regards, John -----Original Message----- From: Luis Nunez [mailto:lnunez@c3isecurity.com]=20 Sent: Thursday, September 06, 2012 11:36 AM To: Field, John Cc: sacm@ietf.org; mile@ietf.org Subject: Re: [sacm] New draft for review and comment: draft-field-mile-roli= e-00.txt John, this definitely is of interest and could be related to past discussions aro= und content repositories. =20 I know of two publicly accessible (REST) repositories that could potential = host this type of content. http://scaprepo.com/SCAPRepoWebService http://scapsync.com/api/ NIST is also working on a repository with webservices. It would be interesting to prototype a sample document and flesh out issues= . -ln On Sep 6, 2012, at 11:10 AM, Field, John wrote: > All, >=20 > Cross posting this announcement from MILE to SACM, as I think this may be= of interest within the SCAP community as well. =20 >=20 > The new draft referenced below describes a RESTful HTTP binding for shari= ng incident, indicator, and other cyber security-related information. In p= articular, the draft includes a suggested approach to retrieving a related = benchmark resource. =20 >=20 > I hope you'll find this draft to be of interest. =20 >=20 > Please post any questions or comments to the MILE list. >=20 > Regards, > John >=20 > // John P. Field=20 > // Security Architect=20 > // EMC Office of the CTO=20 >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: Field, John=20 > Sent: Thursday, September 06, 2012 10:53 AM > To: > Subject: New draft for review and comment: draft-field-mile-rolie-00.txt >=20 > All, >=20 > Please note that I have just posted a new draft for review and comment. = As stated in the abstract, the draft describes a RESTful HTTP binding for s= haring incident, indicator, and other cyber security-related information. = I hope you'll find this document to be of interest, and I look forward to d= iscussing any questions and/or comments that the group may have. >=20 > Regards, > John >=20 > // John P. Field=20 > // Security Architect=20 > // EMC Office of the CTO=20 >=20 >=20 > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 > Sent: Wednesday, September 05, 2012 9:59 PM > To: Field, John > Subject: New Version Notification for draft-field-mile-rolie-00.txt >=20 >=20 > A new version of I-D, draft-field-mile-rolie-00.txt > has been successfully submitted by John P. Field and posted to the > IETF repository. >=20 > Filename: draft-field-mile-rolie > Revision: 00 > Title: Resource-Oriented Lightweight Indicator Exchange > Creation date: 2012-09-05 > WG ID: Individual Submission > Number of pages: 41 > URL: http://www.ietf.org/internet-drafts/draft-field-mile-rol= ie-00.txt > Status: http://datatracker.ietf.org/doc/draft-field-mile-rolie > Htmlized: http://tools.ietf.org/html/draft-field-mile-rolie-00 >=20 >=20 > Abstract: > This document defines a resource-oriented approach to cyber security > information sharing. Using this approach, a CSIRT or other > stakeholder may share and exchange representations of cyber security > incidents, indicators, and other related information as Web- > addressable resources. The transport protocol binding is specified > as HTTP(S) with a MIME media type of Atom+XML. An appropriate set of > link relation types specific to cyber security information sharing is > defined. The resource representations leverage the existing IODEF > [RFC5070] and RID [RFC6545] specifications as appropriate. > Coexistence with deployments that conform to existing specifications > including RID [RFC6545] and Transport of Real-time Inter-network > Defense (RID) Messages over HTTP/TLS [RFC6546] is supported via > appropriate use of HTTP status codes. >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 >=20 > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm From michael.hammer@yaanatech.com Wed Oct 3 13:51:53 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFCC611E8097 for ; Wed, 3 Oct 2012 13:51:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.854 X-Spam-Level: X-Spam-Status: No, score=-0.854 tagged_above=-999 required=5 tests=[AWL=-0.944, BAYES_05=-1.11, J_CHICKENPOX_33=0.6, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id myqMHG58XbeA for ; Wed, 3 Oct 2012 13:51:53 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id 2087F11E80A6 for ; Wed, 3 Oct 2012 13:51:53 -0700 (PDT) Received: from EX2K10MB2.corp.yaanatech.com ([fe80::5d11:66a1:e508:6871]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Wed, 3 Oct 2012 13:51:52 -0700 From: Michael Hammer To: "'johnp.field@emc.com'" , "'francis@aspl.es'" , "'stpeter@jabber.org'" Thread-Topic: [mile] Transport discussion was: New draft notification ... Thread-Index: AQHNnaPIlTQG1/AjuEidX2FT6tFQwZeoddwA//+e3BA= Date: Wed, 3 Oct 2012 20:51:52 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3238A1758@ex2k10mb2.corp.yaanatech.com> References: <5065D9ED.9020801@stpeter.im> <1348854344.3622.177.camel@vulcan.aspl.local> 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.4] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0019_01CDA187.631B8FE0" MIME-Version: 1.0 Cc: "'mile@ietf.org'" Subject: Re: [mile] Transport discussion was: New draft notification ... X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 20:51:54 -0000 ------=_NextPart_000_0019_01CDA187.631B8FE0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable So, what I get from this is that HTTP/REST is a pull model when you know = you want to go get a resource. While XMPP is a presence-based messaging system for notifying others of = the presence of events, e.g. a change in the resource state. So, does this imply a 3-phase exchange: XMPP subscribe to resource XMPP notify of resource change HTTP fetch of resource status? Not an either/or choice. Mike -----Original Message----- From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of = Field, John Sent: Wednesday, October 03, 2012 3:33 PM To: Francis Brosnan Blazquez; stpeter@jabber.org Cc: mile@ietf.org Subject: Re: [mile] Transport discussion was: New draft notification ... Thanks everyone for these comments. =20 Peter, I agree that XMPP is a good suggestion for any event driven use cases. = Since it is based on HTTP, the ROLIE REST model is a "pull" model. = However, if you need to receive asynchronous notification of some event, = say, an alarm from an intrusion detection system, etc., then XMPP may be = a very good choice for that. I think this approach would be = complementary to the current ROLIE draft, and XMPP could co-exist nicely = (to support those different types of use cases and consumers). I don't = have a need to pursue the event-driven use case in my current work, but = I would be supportive if someone wanted to pursue that and write = something up. Francis, I am not an expert on BEEP so I can't comment too much on the pros and = cons of using it. In principal, it seems to me that BEEP could be a = good choice for a traditional RID exchange in a *message-based = architecture*. Interesting to know (via Kathleen's prior post), that in = fact BEEP + RID has already been explored, but the community chose to = switch over to HTTP for reasons of low deployment of BEEP. So this may = be moot, unless there is now greater adoption of BEEP, in which case the = group might want to revisit that. My reason for writing the ROLIE draft was not just a matter of defining = a different transport protocol. Indeed RFC 6546 already specifies a = simple HTTP binding for RID. The goal for ROLIE was to enable an = entirely different interaction model, one that follows the RESTful = architectural style, rather than a message exchange model. In short, = this means that: - everything is a resource - all resources are addressable via a URL - support for a Uniform interface (in the case of HTTP: GET, PUT, POST, = DELETE, HEAD ((PATCH)). - use Media types to negotiate the representation sent to the client = (i.e. HTML, Application/Atom+XML, XML+RID, XML+IODEF, JSON, PDF, = other...) - use Hypertext as the Embodiment of Application State (HATEOAS) So the intent is to provide a new/better alternative that will improve = cyber security information sharing, by moving from a message-based model = to a more loosely-coupled resource-based approach. In theory, one can = even do the REST style without necessarily using HTTP, although as a = practical matter, real systems always use HTTP because it is ubiquitous. Lots has already been written on the pros and cons of message-oriented = versus resource-oriented architectures (i.e. "SOAP versus REST") so I = won't rehash all those discussions here (unless we really want to). =20 I prefer the REST model due to its simplicity and flexibility, and I = thought it could be helpful to specifically describe how the REST = approach could be applied to some of the use cases of interest to the = MILE community. If we can make the exchange of cyber security = information simpler and easier, then that might help to make us all = safer. Thanks again, I appreciate people taking the time to comment. Looking = forward to more good discussion... Regards, John // John P. Field // Security Architect // EMC Office of the CTO=20 -----Original Message----- From: Moriarty, Kathleen [mailto:kathleen.moriarty@emc.com] Sent: Friday, September 28, 2012 2:05 PM To: Francis Brosnan Blazquez Cc: mile@ietf.org Subject: [mile] Transport discussion was: New draft notification ... Interesting... RID used BEEP in an earlier version because of the = suitability to the protocol needs, but because of low deployment of = BEEP, we switched to HTTPS. I am curious to see if different exchange types may use different = bindings. The RESTful binding in the ROLIE draft may be well suited for = repository access and IODEF + RID + transport where object security is = needed. What are the use cases for each if they differ and what do = folks prefer and think will help adoption. As Brian said, other formats are possible. IODEF has been implemented = in JSON from the data model description already. I would love to see more views on this discussion! Thanks, Kathleen Sent from my iPhone On Sep 28, 2012, at 1:46 PM, "Francis Brosnan Blazquez" = wrote: > Hi, >=20 > The working group could also consider BEEP. It is lightweight,=20 > extensible and it allows any format for your message (since it sees=20 > the payload as a bunch of octets). >=20 > Specifically, we are using it in a real-time monitoring solution where = > hundred of nodes are watched and queried, without having to use a=20 > polling solutions to get those events... >=20 > Best Regards, >=20 >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >>=20 >> On 9/28/12 11:00 AM, John Howie wrote: >>=20 >>> I would really like to see information exchange be secure, fast and=20 >>> lightweight, and a new protocol could well be preferable here. >>=20 >> If you didn't have a bias against XML, XMPP would be a good solution=20 >> to the requirements you've outlined. >>=20 >> (With regard to the "bloat" of XML, note that XMPP uses long-lived=20 >> XML streams so the compression ratios are significant.) >>=20 >> Peter >>=20 >> - -- >> Peter Saint-Andre >> https://stpeter.im/ >>=20 >>=20 >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG/MacGPG2 v2.0.18 (Darwin) >> Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ >>=20 >> iEYEARECAAYFAlBl2e0ACgkQNL8k5A2w/vwQ/ACfQ/JoLf08je6WoBkk9A+OpqTo >> 09wAoOoCRYp1ImSAJMKMWClDKL26qlJ4 >> =3DDJzM >> -----END PGP SIGNATURE----- >> _______________________________________________ >> mile mailing list >> mile@ietf.org >> https://www.ietf.org/mailman/listinfo/mile >=20 > -- > Francis Brosnan Bl=C3=A1zquez ASPL > 91 134 14 22 - 91 134 14 45 - 91 116 07 57 >=20 > AVISO LEGAL >=20 > Este mensaje se dirige exclusivamente a su destinatario. Los datos=20 > incluidos en el presente correo son confidenciales y sometidos a=20 > secreto profesional, se proh=C3=ADbe divulgarlos, en virtud de las = leyes=20 > vigentes. Si usted no lo es y lo ha recibido por error o tiene=20 > conocimiento del mismo por cualquier motivo, le rogamos que nos lo=20 > comunique por este medio y proceda a destruirlo o borrarlo. >=20 > En virtud de lo dispuesto en la Ley Org=C3=A1nica 15/1999, de 13 de=20 > diciembre, de Protecci=C3=B3n de Datos de Car=C3=A1cter Personal, le = informamos=20 > de que sus datos de car=C3=A1cter personal, recogidos de fuentes = accesibles=20 > al p=C3=BAblico o datos que usted nos ha facilitado previamente, = proceden=20 > de bases de datos propiedad de Advanced Software Production Line, S.L. > (ASPL). No obstante, usted puede ejercitar sus derechos de acceso,=20 > rectificaci=C3=B3n, cancelaci=C3=B3n y oposici=C3=B3n dispuestos en la = mencionada Ley=20 > Org=C3=A1nica, notific=C3=A1ndolo por escrito a: > ASPL - Protecci=C3=B3n Datos, C/Antonio Su=C3=A1rez 10 A-102, 28802, = Alcal=C3=A1 de=20 > Henares (Madrid). >=20 > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile >=20 _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile ------=_NextPart_000_0019_01CDA187.631B8FE0 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 AwIaBQCgggMbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMTAw MzIwNTE1MVowIwYJKoZIhvcNAQkEMRYEFKo1xt2KrD694nth2QuXzERCPjEtMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIIBAwYJKwYB BAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzMCEFxfWez8mX8O0jX38FcJy4EwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkG A1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz dCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24u Y29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5W ZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhBcX1ns/Jl/DtI1 9/BXCcuBMA0GCSqGSIb3DQEBAQUABIGANJHrzNuyfTiF2nl4Rk6SzQlHSIiyMjc4fzKvvpIjWA7f 2feGN4DCWfombz7B4kAwD1ZGk2qYXFu6H6g6strmM7YSSXLAsR24F07vbtG2p0j0xMPLLXfIwp0r QhHhHoqyvb2BKBAT8JlovLX6KVSiVoH5H1+/L5/KOwaH3c0G1BIAAAAAAAA= ------=_NextPart_000_0019_01CDA187.631B8FE0-- From lnunez@c3isecurity.com Thu Oct 4 04:06:50 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0368221F864A for ; Thu, 4 Oct 2012 04:06:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YyObOlemEUEC for ; Thu, 4 Oct 2012 04:06:49 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id D22C421F8648 for ; Thu, 4 Oct 2012 04:06:48 -0700 (PDT) Received: by mail-qa0-f44.google.com with SMTP id 25so2781067qao.10 for ; Thu, 04 Oct 2012 04:06:48 -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 :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=x4+S97Evw9DeEKAuerbuR0r63Cl1kCBXHdfe/4Cta9w=; b=QaVTCpyb0Vm6SvLvpyL9Qlc+pMoM66JPZYlYOY7JtlAoVBedJl7XA/XhJ4Mrsf8qtb Z0dbAEshJJ9nYoP7y1CiFzOrUNyMYUvv732f3y5JAIw3JyWwQm8ns0OYCnY1ycDqyopA QqTvZvS67vMD66Ttwzi2GjAp9BX0Lp4Atc1RAvFD0RGqXYDWEi9+vgytTwSD+pM+RF7N nFtcrBjBJ9SckaQWE3gOryJIJ+u8KYugsXSiuazZ3WCMNCzn4HdLoZdvNFX/PwUqEzRo lCAgJ6Jp8nBOxvbaG21qVgtYE+tBbqmcNjAlN4B0PZy8H8YYvg26DeTX+3q5OpmdX685 UAOw== Received: by 10.49.72.199 with SMTP id f7mr18079162qev.43.1349348807853; Thu, 04 Oct 2012 04:06:47 -0700 (PDT) Received: from [10.71.77.129] ([74.10.226.222]) by mx.google.com with ESMTPS id ep8sm6917750qab.22.2012.10.04.04.06.44 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 04 Oct 2012 04:06:45 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Luis Nunez In-Reply-To: Date: Thu, 4 Oct 2012 07:06:52 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Field, John" X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQlJ7Vr8a4tJ3vJU5nNS/17u9hNgFsjdDasjUml5zsZIWws/NLzNkYuqqFcIIqt+fyxcj5Am Cc: "mile@ietf.org" , "sacm@ietf.org" Subject: Re: [mile] [sacm] New draft for review and comment: draft-field-mile-rolie-00.txt X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 11:06:50 -0000 I agree with your motivation. This great timing to publish such draft. = I am at the ITSAC this week talking to folks about possibility = prototyping this specification into repositories such as scaprepo.com = and also scapsync.com. =20 I think once we have a live prototype we can also address authentication = and entitlement capabilities. Entitlements to public and private = content I think will help in opening up further access into content = repositories.=20 thanks. -ln On Oct 3, 2012, at 3:58 PM, Field, John wrote: > Luis, >=20 > Sorry for the delay in responding, I have been quite busy with a few = projects and also traveling. Thanks for the feedback; scaprepo does = look interesting... =20 >=20 > I can easily imagine an integration where the representation of an = "incident" or "indicator" resource could also include a link to a = corresponding SCAP repository resource, say an OVAL benchmark or an OVAL = def, etc. that is related to the requested resource...a quick hack of an = example might look something like... >=20 > HTTP/1.1 200 OK > Date: Wed, 03 Oct 2012 17:30:11 GMT > Content-Length: nnn > Content-Type: application/atom+xml;type=3Dentry;charset=3D"utf-8" >=20 > =20 > > http://www.example.org/csirt/private/incidents/123456 > Sample Incident > > > 2012-08-04T18:13:51.0Z > 2012-08-05T18:13:51.0Z >=20 > > > >=20 > > >=20 > > > > ... =20 > > > >=20 >=20 > The possibility of such an integration is exactly what motivated the = draft. The issues that would need to be resolved include making the = authentication to the scaprepo seamless (possible, at least in = principal, using existing Web Single Sign On protocols) and dealing with = differences in interaction style...for example, I notice that scaprepo = seems to prefer the use of POST for all operations (including a read = operation). As a general rule, it is best to support GET for read = operations, and reserve POST for write operations. But, this is a = relatively minor issue at this point. The more important point is that = by using a REST approach such an integration would become possible, and = that would be of benefit to users dealing with indicators, incident = response, and assessment and compliance, etc....we could tie it all = together quite nicely. >=20 > Thanks for commenting. I'll take a deeper look at scaprepo when I get = some more time. >=20 > Regards, > John >=20 >=20 > -----Original Message----- > From: Luis Nunez [mailto:lnunez@c3isecurity.com]=20 > Sent: Thursday, September 06, 2012 11:36 AM > To: Field, John > Cc: sacm@ietf.org; mile@ietf.org > Subject: Re: [sacm] New draft for review and comment: = draft-field-mile-rolie-00.txt >=20 > John, > this definitely is of interest and could be related to past = discussions around content repositories. =20 >=20 > I know of two publicly accessible (REST) repositories that could = potential host this type of content. >=20 > http://scaprepo.com/SCAPRepoWebService > http://scapsync.com/api/ >=20 > NIST is also working on a repository with webservices. >=20 > It would be interesting to prototype a sample document and flesh out = issues. >=20 >=20 > -ln >=20 > On Sep 6, 2012, at 11:10 AM, Field, John wrote: >=20 >> All, >>=20 >> Cross posting this announcement from MILE to SACM, as I think this = may be of interest within the SCAP community as well. =20 >>=20 >> The new draft referenced below describes a RESTful HTTP binding for = sharing incident, indicator, and other cyber security-related = information. In particular, the draft includes a suggested approach to = retrieving a related benchmark resource. =20 >>=20 >> I hope you'll find this draft to be of interest. =20 >>=20 >> Please post any questions or comments to the MILE list. >>=20 >> Regards, >> John >>=20 >> // John P. Field=20 >> // Security Architect=20 >> // EMC Office of the CTO=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> -----Original Message----- >> From: Field, John=20 >> Sent: Thursday, September 06, 2012 10:53 AM >> To: >> Subject: New draft for review and comment: = draft-field-mile-rolie-00.txt >>=20 >> All, >>=20 >> Please note that I have just posted a new draft for review and = comment. As stated in the abstract, the draft describes a RESTful HTTP = binding for sharing incident, indicator, and other cyber = security-related information. I hope you'll find this document to be of = interest, and I look forward to discussing any questions and/or comments = that the group may have. >>=20 >> Regards, >> John >>=20 >> // John P. Field=20 >> // Security Architect=20 >> // EMC Office of the CTO=20 >>=20 >>=20 >> -----Original Message----- >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 >> Sent: Wednesday, September 05, 2012 9:59 PM >> To: Field, John >> Subject: New Version Notification for draft-field-mile-rolie-00.txt >>=20 >>=20 >> A new version of I-D, draft-field-mile-rolie-00.txt >> has been successfully submitted by John P. Field and posted to the >> IETF repository. >>=20 >> Filename: draft-field-mile-rolie >> Revision: 00 >> Title: Resource-Oriented Lightweight Indicator = Exchange >> Creation date: 2012-09-05 >> WG ID: Individual Submission >> Number of pages: 41 >> URL: = http://www.ietf.org/internet-drafts/draft-field-mile-rolie-00.txt >> Status: = http://datatracker.ietf.org/doc/draft-field-mile-rolie >> Htmlized: http://tools.ietf.org/html/draft-field-mile-rolie-00 >>=20 >>=20 >> Abstract: >> This document defines a resource-oriented approach to cyber security >> information sharing. Using this approach, a CSIRT or other >> stakeholder may share and exchange representations of cyber security >> incidents, indicators, and other related information as Web- >> addressable resources. The transport protocol binding is specified >> as HTTP(S) with a MIME media type of Atom+XML. An appropriate set = of >> link relation types specific to cyber security information sharing = is >> defined. The resource representations leverage the existing IODEF >> [RFC5070] and RID [RFC6545] specifications as appropriate. >> Coexistence with deployments that conform to existing specifications >> including RID [RFC6545] and Transport of Real-time Inter-network >> Defense (RID) Messages over HTTP/TLS [RFC6546] is supported via >> appropriate use of HTTP status codes. >>=20 >>=20 >>=20 >>=20 >> The IETF Secretariat >>=20 >>=20 >> _______________________________________________ >> sacm mailing list >> sacm@ietf.org >> https://www.ietf.org/mailman/listinfo/sacm >=20 >=20 From bchandra@secpod.com Thu Oct 4 06:33:47 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8275B21F8648; Thu, 4 Oct 2012 06:33:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.816 X-Spam-Level: X-Spam-Status: No, score=-1.816 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_43=0.6, SARE_OBFU_SPLIT_HR2=0.183] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rasjn+zynzSo; Thu, 4 Oct 2012 06:33:46 -0700 (PDT) Received: from cpanel23.interactivedns.com (cpanel23.interactivedns.com [184.173.122.2]) by ietfa.amsl.com (Postfix) with ESMTP id 8598D21F8647; Thu, 4 Oct 2012 06:33:46 -0700 (PDT) Received: from [182.72.99.242] (port=2564 helo=hpPC) by cpanel23.interactivedns.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1TJlYe-0002l4-Qo; Thu, 04 Oct 2012 19:03:45 +0530 From: "Chandrashekhar B" To: "'Field, John'" , "'Luis Nunez'" References: In-Reply-To: Date: Thu, 4 Oct 2012 19:03:38 +0530 Organization: SecPod Technologies Message-ID: <013e01cda234$def74ac0$9ce5e040$@secpod.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIDkLRwduFPN/39ahIvZ01+DQBPpAF1d2SmAqBmgbiXHJXcYA== Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cpanel23.interactivedns.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - secpod.com X-Source: X-Source-Args: X-Source-Dir: X-Mailman-Approved-At: Thu, 04 Oct 2012 06:35:47 -0700 Cc: mile@ietf.org, sacm@ietf.org Subject: Re: [mile] [sacm] New draft for review and comment: draft-field-mile-rolie-00.txt X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: bchandra@secpod.com List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 13:33:47 -0000 Thanks John. Authentication was the primary reason for a POST request, we'll look into your suggestion. The example helped quickly grasp the idea. We'll look into the draft in detail and come back with any comments. There are three specs now which are somewhat related although each for different purposes, 1. SCAP Messages for IF-M draft - http://www.trustedcomputinggroup.org/resources/tnc_scap_messages_for_ifm 2. Resource-Oriented Lightweight Indicator Exchange - http://www.ietf.org/id/draft-field-mile-rolie-00.txt 3. Content Repository interface - http://tools.ietf.org/html/draft-waltermire-content-repository-00 I think all should align on a similar content exchange mechanism. Just a thought, am not sure if it really make sense, haven't gone through each of them in detail. Thanks, Chandra. -----Original Message----- From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Field, John Sent: Thursday, October 04, 2012 1:28 AM To: Luis Nunez Cc: mile@ietf.org; sacm@ietf.org Subject: Re: [sacm] New draft for review and comment: draft-field-mile-rolie-00.txt Luis, Sorry for the delay in responding, I have been quite busy with a few projects and also traveling. Thanks for the feedback; scaprepo does look interesting... I can easily imagine an integration where the representation of an "incident" or "indicator" resource could also include a link to a corresponding SCAP repository resource, say an OVAL benchmark or an OVAL def, etc. that is related to the requested resource...a quick hack of an example might look something like... HTTP/1.1 200 OK Date: Wed, 03 Oct 2012 17:30:11 GMT Content-Length: nnn Content-Type: application/atom+xml;type=entry;charset="utf-8" http://www.example.org/csirt/private/incidents/123456 Sample Incident 2012-08-04T18:13:51.0Z 2012-08-05T18:13:51.0Z ... The possibility of such an integration is exactly what motivated the draft. The issues that would need to be resolved include making the authentication to the scaprepo seamless (possible, at least in principal, using existing Web Single Sign On protocols) and dealing with differences in interaction style...for example, I notice that scaprepo seems to prefer the use of POST for all operations (including a read operation). As a general rule, it is best to support GET for read operations, and reserve POST for write operations. But, this is a relatively minor issue at this point. The more important point is that by using a REST approach such an integration would become possible, and that would be of benefit to users dealing with indicators, incident response, and assessment and compliance, etc....we could tie it all together quite nicely. Thanks for commenting. I'll take a deeper look at scaprepo when I get some more time. Regards, John -----Original Message----- From: Luis Nunez [mailto:lnunez@c3isecurity.com] Sent: Thursday, September 06, 2012 11:36 AM To: Field, John Cc: sacm@ietf.org; mile@ietf.org Subject: Re: [sacm] New draft for review and comment: draft-field-mile-rolie-00.txt John, this definitely is of interest and could be related to past discussions around content repositories. I know of two publicly accessible (REST) repositories that could potential host this type of content. http://scaprepo.com/SCAPRepoWebService http://scapsync.com/api/ NIST is also working on a repository with webservices. It would be interesting to prototype a sample document and flesh out issues. -ln On Sep 6, 2012, at 11:10 AM, Field, John wrote: > All, > > Cross posting this announcement from MILE to SACM, as I think this may be of interest within the SCAP community as well. > > The new draft referenced below describes a RESTful HTTP binding for sharing incident, indicator, and other cyber security-related information. In particular, the draft includes a suggested approach to retrieving a related benchmark resource. > > I hope you'll find this draft to be of interest. > > Please post any questions or comments to the MILE list. > > Regards, > John > > // John P. Field > // Security Architect > // EMC Office of the CTO > > > > > > -----Original Message----- > From: Field, John > Sent: Thursday, September 06, 2012 10:53 AM > To: > Subject: New draft for review and comment: draft-field-mile-rolie-00.txt > > All, > > Please note that I have just posted a new draft for review and comment. As stated in the abstract, the draft describes a RESTful HTTP binding for sharing incident, indicator, and other cyber security-related information. I hope you'll find this document to be of interest, and I look forward to discussing any questions and/or comments that the group may have. > > Regards, > John > > // John P. Field > // Security Architect > // EMC Office of the CTO > > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Wednesday, September 05, 2012 9:59 PM > To: Field, John > Subject: New Version Notification for draft-field-mile-rolie-00.txt > > > A new version of I-D, draft-field-mile-rolie-00.txt > has been successfully submitted by John P. Field and posted to the > IETF repository. > > Filename: draft-field-mile-rolie > Revision: 00 > Title: Resource-Oriented Lightweight Indicator Exchange > Creation date: 2012-09-05 > WG ID: Individual Submission > Number of pages: 41 > URL: http://www.ietf.org/internet-drafts/draft-field-mile-rolie-00.txt > Status: http://datatracker.ietf.org/doc/draft-field-mile-rolie > Htmlized: http://tools.ietf.org/html/draft-field-mile-rolie-00 > > > Abstract: > This document defines a resource-oriented approach to cyber security > information sharing. Using this approach, a CSIRT or other > stakeholder may share and exchange representations of cyber security > incidents, indicators, and other related information as Web- > addressable resources. The transport protocol binding is specified > as HTTP(S) with a MIME media type of Atom+XML. An appropriate set of > link relation types specific to cyber security information sharing is > defined. The resource representations leverage the existing IODEF > [RFC5070] and RID [RFC6545] specifications as appropriate. > Coexistence with deployments that conform to existing specifications > including RID [RFC6545] and Transport of Real-time Inter-network > Defense (RID) Messages over HTTP/TLS [RFC6546] is supported via > appropriate use of HTTP status codes. > > > > > The IETF Secretariat > > > _______________________________________________ > 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 francis@aspl.es Fri Oct 5 00:52:34 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3801321F8545 for ; Fri, 5 Oct 2012 00:52:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.884 X-Spam-Level: **** X-Spam-Status: No, score=4.884 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_HOST_ALMOST_IP=1.889, HOST_EQ_STATIC=1.172, HOST_EQ_STATICIP=1.511, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YLmvgfy33Ber for ; Fri, 5 Oct 2012 00:52:33 -0700 (PDT) Received: from mail.aspl.es (196.Red-212-170-101.staticIP.rima-tde.net [212.170.101.196]) by ietfa.amsl.com (Postfix) with ESMTP id 19BA721F858E for ; Fri, 5 Oct 2012 00:52:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.aspl.es (Postfix) with ESMTP id 4AF11312003; Fri, 5 Oct 2012 09:52:20 +0200 (CEST) X-Virus-Scanned: amavisd-new at aspl.es Received: from mail.aspl.es ([127.0.0.1]) by localhost (dolphin.aspl.es [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 95Me264GbPbf; Fri, 5 Oct 2012 09:52:15 +0200 (CEST) Received: from [192.168.0.132] (unknown [192.168.0.132]) by mail.aspl.es (Postfix) with ESMTP id 6E047312001; Fri, 5 Oct 2012 09:52:15 +0200 (CEST) From: Francis Brosnan Blazquez To: "Field, John" In-Reply-To: References: <5065D9ED.9020801@stpeter.im> <1348854344.3622.177.camel@vulcan.aspl.local> Content-Type: text/plain; charset="ISO-8859-15" Organization: ASPL Date: Fri, 05 Oct 2012 09:52:15 +0200 Message-ID: <1349423535.28780.19.camel@vulcan.aspl.local> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 8bit Cc: "mile@ietf.org" , "stpeter@jabber.org" Subject: Re: [mile] Transport discussion was: New draft notification ... X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 07:52:34 -0000 Hi John, > Francis, > I am not an expert on BEEP so I can't comment too much on the pros and > cons of using it. In principal, it seems to me that BEEP could be a > good choice for a traditional RID exchange in a *message-based > architecture*. Interesting to know (via Kathleen's prior post), that > in fact BEEP + RID has already been explored, but the community chose > to switch over to HTTP for reasons of low deployment of BEEP. So this > may be moot, unless there is now greater adoption of BEEP, in which > case the group might want to revisit that. This would be something to consider, especially because until recently (in terms of protocol definition) there weren't any comercial grade/production ready BEEP stacks so without them, it is not possible to do anything with BEEP. I just wanted to draw attention to that fact, that is, now it is possible to use BEEP without investing time in writing a proven stack. > My reason for writing the ROLIE draft was not just a matter of > defining a different transport protocol. Indeed RFC 6546 already > specifies a simple HTTP binding for RID. The goal for ROLIE was to > enable an entirely different interaction model, one that follows the > RESTful architectural style, rather than a message exchange model. I think your effort is good especially because it comes to add possibilities which is always a good thing. Best Regards, -- Francis Brosnan Blázquez ASPL 91 134 14 22 - 91 134 14 45 - 91 116 07 57 AVISO LEGAL Este mensaje se dirige exclusivamente a su destinatario. Los datos incluidos en el presente correo son confidenciales y sometidos a secreto profesional, se prohíbe divulgarlos, en virtud de las leyes vigentes. Si usted no lo es y lo ha recibido por error o tiene conocimiento del mismo por cualquier motivo, le rogamos que nos lo comunique por este medio y proceda a destruirlo o borrarlo. En virtud de lo dispuesto en la Ley Orgánica 15/1999, de 13 de diciembre, de Protección de Datos de Carácter Personal, le informamos de que sus datos de carácter personal, recogidos de fuentes accesibles al público o datos que usted nos ha facilitado previamente, proceden de bases de datos propiedad de Advanced Software Production Line, S.L. (ASPL). No obstante, usted puede ejercitar sus derechos de acceso, rectificación, cancelación y oposición dispuestos en la mencionada Ley Orgánica, notificándolo por escrito a: ASPL - Protección Datos, C/Antonio Suárez 10 A-102, 28802, Alcalá de Henares (Madrid). From trammell@tik.ee.ethz.ch Fri Oct 5 06:46:47 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4993B21F8779 for ; Fri, 5 Oct 2012 06:46: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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f9wqHFAdmFR2 for ; Fri, 5 Oct 2012 06:46:47 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 7225321F8767 for ; Fri, 5 Oct 2012 06:46:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 6190DD9493 for ; Fri, 5 Oct 2012 15:46:31 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id rsSYPtemFss0 for ; Fri, 5 Oct 2012 15:46:30 +0200 (MEST) Received: from [10.0.27.100] (cust-integra-121-161.antanet.ch [80.75.121.161]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 88A76D93A2 for ; Fri, 5 Oct 2012 15:46:30 +0200 (MEST) From: Brian Trammell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 5 Oct 2012 15:46:29 +0200 Message-Id: <408A7A94-AEE4-47B6-8BC6-32D190916761@tik.ee.ethz.ch> To: mile@ietf.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Subject: [mile] Draft agenda for Atlanta posted X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 13:46:47 -0000 Greetings, all, A draft agenda for Atlanta has been posted = (http://www.ietf.org/proceedings/85/agenda/agenda-85-mile) with one slot = for each active WG document and published individual draft as of today; = if you'd like some time on the agenda to discuss other MILE work, please = let us know at mile-chairs@tools.ietf.org. Best regards, Brian= From stpeter@gmail.com Tue Oct 9 08:26:46 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 404DC21F853C for ; Tue, 9 Oct 2012 08:26:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IMGmz2ycDDlP for ; Tue, 9 Oct 2012 08:26:45 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id BFC1C21F8495 for ; Tue, 9 Oct 2012 08:26:45 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id ro8so5420572pbb.31 for ; Tue, 09 Oct 2012 08:26:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=agVHDuz63s+Wuq7/N8BlaOKqq8EeG26HZkNnIMeXhnA=; b=vnn3hH4ARizvarLtax9KhNEYBL+dc6j0Gf5ah73H9pG4+H3MrXhlcnfBm8eVDlwZnv Z1NP+Ce40X0FSDR/FuVGHPVOyuwlXDrxPS98WlwKAFV2MIXvGngV1RXZW5Pu8f9eO+xL U+2NbokAqvT6FQcZOiRRtEYztSFF7y9eHI/2V0AS840sG0p88dwv1r1XBe0if3ce0EIE j0jYhM2VTztbqqwjQCN+r7WQsp+MaV5fM0P1nRLetVYCPn5S6NgqQWlhx7lZ+VDGGPtQ 0c1lOdso/QGDBL5BtULFO/aUXocE/YX+4GjXEdcWcMdv55sIKT9ip4nw0pxxWH/z7ik9 pmjA== MIME-Version: 1.0 Received: by 10.68.132.40 with SMTP id or8mr49170767pbb.63.1349796405539; Tue, 09 Oct 2012 08:26:45 -0700 (PDT) Sender: stpeter@gmail.com Received: by 10.68.15.137 with HTTP; Tue, 9 Oct 2012 08:26:45 -0700 (PDT) In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3238A1758@ex2k10mb2.corp.yaanatech.com> References: <5065D9ED.9020801@stpeter.im> <1348854344.3622.177.camel@vulcan.aspl.local> <00C069FD01E0324C9FFCADF539701DB3238A1758@ex2k10mb2.corp.yaanatech.com> Date: Tue, 9 Oct 2012 09:26:45 -0600 X-Google-Sender-Auth: JlFk2C2rjr-hzH-V3ePa_azHpEE Message-ID: From: Peter Saint-Andre To: Michael Hammer Content-Type: multipart/alternative; boundary=047d7b10cde34571a604cba1f758 Cc: "mile@ietf.org" Subject: Re: [mile] Transport discussion was: New draft notification ... X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 15:35:26 -0000 --047d7b10cde34571a604cba1f758 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Oct 3, 2012 at 2:51 PM, Michael Hammer wrote: > So, what I get from this is that HTTP/REST is a pull model when you know > you want to go get a resource. > While XMPP is a presence-based messaging system for notifying others of > the presence of events, e.g. a change in the resource state. > > So, does this imply a 3-phase exchange: > XMPP subscribe to resource > XMPP notify of resource change > HTTP fetch of resource status? > That is one possibility, yes, although one could also fetch the status over XMPP. Peter --047d7b10cde34571a604cba1f758 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Oct 3, 2012 at 2:51 PM, Michael Hammer <michael.hammer@= yaanatech.com> wrote:
So, what I get from this is that HTTP/REST is a pull model when you know yo= u want to go get a resource.
While XMPP is a presence-based messaging system for notifying others of the= presence of events, e.g. a change in the resource state.

So, does this imply a 3-phase exchange:
XMPP subscribe to resource
XMPP notify of resource change
HTTP fetch of resource status?

That is = one possibility, yes, although one could also fetch the status over XMPP.

Peter
=A0
--047d7b10cde34571a604cba1f758-- From takeshi_takahashi@nict.go.jp Tue Oct 9 22:59:36 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C61C21F8709 for ; Tue, 9 Oct 2012 22:59:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.355 X-Spam-Level: X-Spam-Status: No, score=-1.355 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x2If5H3FWZ7h for ; Tue, 9 Oct 2012 22:59:35 -0700 (PDT) Received: from ns2.nict.go.jp (ns2.nict.go.jp [IPv6:2001:df0:232:300::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2A18521F84F0 for ; Tue, 9 Oct 2012 22:59:34 -0700 (PDT) Received: from gw2.nict.go.jp (gw2 [133.243.18.251]) by ns2.nict.go.jp with ESMTP id q9A5xTli007736; Wed, 10 Oct 2012 14:59:29 +0900 (JST) Received: from gw2.nict.go.jp (localhost [127.0.0.1]) by gw2.nict.go.jp with ESMTP id q9A5xTkH022889; Wed, 10 Oct 2012 14:59:29 +0900 (JST) Received: from takeVAIO2 (ssh.nict.go.jp [133.243.3.49]) by gw2.nict.go.jp with ESMTP id q9A5xLUS022869; Wed, 10 Oct 2012 14:59:23 +0900 (JST) From: "Takeshi Takahashi" To: "'Adam Montville'" , "'Moriarty, Kathleen'" , References: In-Reply-To: Date: Wed, 10 Oct 2012 14:59:18 +0900 Message-ID: <000001cda6ac$6621f6a0$3265e3e0$@nict.go.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJuqzcBZENMJ7FGywqpFy1R6yEw7pZv/64Q Content-Language: ja Subject: Re: [mile] FW: New Version Notification for draft-montville-mile-enum-reference-format-00.txt X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 05:59:36 -0000 Hi Adam, Thank you for posting the draft. I like the IANA table that the draft will create, and the SCI draft should be able to use the table as well. Regarding the IANA table, you have "Version" in addition to "Name." For this point. Let me ask you a clarification question. If we have a specification of two different versions (for instance, SampleSpec 1.0 and SampleSpec 2.0), does the IANA table prepare only one identifier ("Name") for both of them? (case A) Or, does the draft prepare two different identifiers (for SampleSpec 1.0 and SampleSpec 2.0 respectively)? (case B) If it is the latter case (case B), I wonder whether we need "Version" entry since the version information is included inside the identifier ("Name") Just a clarification question, and I would be happy to hear your opinion on this. Thank you. Take > -----Original Message----- > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of > Adam Montville > Sent: Friday, September 28, 2012 10:31 PM > To: Moriarty, Kathleen; mile@ietf.org > Subject: Re: [mile] FW: New Version Notification for > draft-montville-mile-enum-reference-format-00.txt > > On 9/28/12 6:19 AM, "Moriarty, Kathleen" > wrote: > > >Hi Adam, > > > >I am sorry for the confusion! I was referring to the full value > >contained in the "ReferenceName". > > That makes more sense to me, sorry. This is a great point, Kathleen. > > >The example shows: > > > > > > CXI:CXI-1234-XYZ > > http://cxi.example.com > > Foo > > > > > > Information in the IANA table (see Section 4) would include: > > > > Name: Concept X Identifier > > Version: x.y > > Specification URI: http://cxi.example.com/spec_url > > Reference: Foo. > > > > > >How would you get from the IANA table entry to what is included in the > >example? The name gets abbreviated. Is the version part of the name > >and a new version would be a new name? How is the structure after the > >colon formed? What characters are permitted. > > > I think I was taking the "Name" in the IANA table to be the identifier, > rather than the full name (so, for example, "CPE" rather than "Common > Platform Enumeration"). So, we could simply add an abbreviation to the > IANA table, where the abbreviation would consist of lowercase > alphabetical characters for the type identifier ("CXI" in the example > above). > > > The character limitations should be none, such that this method would > not encumber any enumeration specification. That said, I think it would > be reasonable to make it alphanumeric with some punctuation (but I'd like > to hear from the list as to what they think) - so essentially a string > with some character restrictions. > > As I mention above, I'd really like to hear from others on the list as > to what they feel is best. > > Thanks again for pointing this out. > > > > > > > >Thank you, > >Kathleen > > > >________________________________________ > >From: Adam Montville [amontville@tripwire.com] > >Sent: Thursday, September 27, 2012 6:28 PM > >To: Moriarty, Kathleen; mile@ietf.org > >Subject: Re: [mile] FW: New Version Notification for > >draft-montville-mile-enum-reference-format-00.txt > > > >On 9/27/12 6:17 AM, "Moriarty, Kathleen" > >wrote: > > > >>Adam & MILE members, > >> > >>I read through the draft and think it looks great! I did notice that > >>the identifier format after the id: is not specified. An example is > >>provided, but am wondering if it would be helpful to provide an > >>explicit format to help developers when formatting and parsing the > content. > >> > >>Any thoughts - Adam or others on the MILE list? > > > > > >Kathleen, thanks for reviewing the specification. I think there's a > >misunderstanding. I'm looking at the id_type:id item described in 2.1. > >The id in that item *is* the identifier, and it's format should be > >explicitly defined by a document or available specification that would > >be attainable from the registry (Specification URI). > > > >Does that help or are we talking about two different things? > > > >Adam > > > > > >> > >>Thank you! > >>Kathleen > >>________________________________________ > >>From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of > >>Moriarty, Kathleen [kathleen.moriarty@emc.com] > >>Sent: Wednesday, September 05, 2012 10:35 AM > >>To: Adam Montville; mile@ietf.org > >>Subject: Re: [mile] FW: New Version Notification for > >>draft-montville-mile-enum-reference-format-00.txt > >> > >>Adam, > >> > >>Thank you very much for your work on this draft! > >> > >>MILE members: Please review and comment on the draft. > >> > >>Thank you! > >>Kathleen > >>________________________________________ > >>From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of Adam > >>Montville [amontville@tripwire.com] > >>Sent: Saturday, September 01, 2012 9:54 AM > >>To: mile@ietf.org > >>Subject: [mile] FW: New Version Notification for > >>draft-montville-mile-enum-reference-format-00.txt > >> > >>On 9/1/12 6:46 AM, "internet-drafts@ietf.org" > >> > >>wrote: > >> > >>> > >>>A new version of I-D, > >>>draft-montville-mile-enum-reference-format-00.txt > >>>has been successfully submitted by Adam W. Montville and posted to > >>>the IETF repository. > >>> > >>>Filename: draft-montville-mile-enum-reference-format > >>>Revision: 00 > >>>Title: IODEF Enumeration Reference Format > >>>Creation date: 2012-09-01 > >>>WG ID: Individual Submission > >>>Number of pages: 6 > >>>URL: > >>>http://www.ietf.org/internet-drafts/draft-montville-mile-enum-ref > eren > >>>ce- > >>>f > >>>o > >>>rmat-00.txt > >>>Status: > >>>http://datatracker.ietf.org/doc/draft-montville-mile-enum-referen > ce-f > >>>orm > >>>a > >>>t > >>>Htmlized: > >>>http://tools.ietf.org/html/draft-montville-mile-enum-reference-fo > rmat > >>>-00 > >>> > >>> > >>>Abstract: > >>> Some standards, such as the Incident Object Description Exchange > >>> Format [IODEF], provide classes used to reference external entities > >>> (such as enumeration identifiers). At the time of > standardization, > >>> however, needed references may not be known, and the method of > >>> external entity identification is often left unstructured. This > >>> document describes, using [IODEF] as an example, a method to provide > >>> structure after the fact. > >>> > >>> > >>> > >>> > >>> > >>> > >>>The IETF Secretariat > >>> > >>> > >>> > >> > >> > >> > >> > >>_______________________________________________ > >>mile mailing list > >>mile@ietf.org > >>https://www.ietf.org/mailman/listinfo/mile > >> > >>_______________________________________________ > >>mile mailing list > >>mile@ietf.org > >>https://www.ietf.org/mailman/listinfo/mile > >> > >> > >> > > > > > > > > > > > > > > > > > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile From takeshi_takahashi@nict.go.jp Sun Oct 14 19:38:28 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA29C21F8438 for ; Sun, 14 Oct 2012 19:38:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.355 X-Spam-Level: X-Spam-Status: No, score=-1.355 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OgF0UGHyUr3L for ; Sun, 14 Oct 2012 19:38:27 -0700 (PDT) Received: from ns1.nict.go.jp (ns1.nict.go.jp [IPv6:2001:df0:232:300::1]) by ietfa.amsl.com (Postfix) with ESMTP id 231B021F8433 for ; Sun, 14 Oct 2012 19:38:26 -0700 (PDT) Received: from gw1.nict.go.jp (gw1 [133.243.18.250]) by ns1.nict.go.jp with ESMTP id q9F2cJN0004725; Mon, 15 Oct 2012 11:38:19 +0900 (JST) Received: from gw1.nict.go.jp (localhost [127.0.0.1]) by gw1.nict.go.jp with ESMTP id q9F2cIKq005265; Mon, 15 Oct 2012 11:38:18 +0900 (JST) Received: from mail2.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw1.nict.go.jp with ESMTP id q9F2cIox005262; Mon, 15 Oct 2012 11:38:18 +0900 (JST) Received: from mail2.nict.go.jp (localhost [127.0.0.1]) by mail2.nict.go.jp (NICT Mail) with ESMTP id 9CD55162F1; Mon, 15 Oct 2012 11:38:18 +0900 (JST) Received: from takeVAIO2 (unknown [133.243.119.6]) by mail2.nict.go.jp (NICT Mail) with ESMTP id 97048162B2; Mon, 15 Oct 2012 11:38:18 +0900 (JST) From: "Takeshi Takahashi" To: "'Panos Kampanakis \(pkampana\)'" , "'Moriarty, Kathleen'" , References: <1C9F17D1873AFA47A969C4DD98F98A75057C6A@xmb-rcd-x10.cisco.com> In-Reply-To: <1C9F17D1873AFA47A969C4DD98F98A75057C6A@xmb-rcd-x10.cisco.com> Date: Mon, 15 Oct 2012 11:38:17 +0900 Message-ID: <005d01cdaa7e$2233be30$669b3a90$@nict.go.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFaPwSgKugNkFHKHWsUkQETMhTq/gI75+lumI6etaA= Content-Language: ja Subject: Re: [mile] SCI document and WG decision X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 02:38:28 -0000 +1 Thank you very much for your kind assistance, and I am sorry for very = late response. Take From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Panos Kampanakis (pkampana) Sent: Tuesday, August 21, 2012 2:24 AM To: Moriarty, Kathleen; mile@ietf.org Subject: Re: [mile] SCI document and WG decision +1 Panos From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Moriarty, Kathleen Sent: Monday, August 20, 2012 9:40 AM To: mile@ietf.org Subject: [mile] SCI document and WG decision Hello, =A0 At the IETF meeting in Vancouver, the WG consensus was to remove the referenced specifications from the SCI draft so that the document could progress without IP issues.=A0 In this model, the draft would have empty tables and the WG would then decide which specifications or standards references would get added into the document.=A0 The thought was that = the WG could think more carefully about what specifications were important to reference to meet relevant use cases for the community.=A0 The process = would include a review of the specification to ensure we could reference it, including that the specification or standard is a document that the IETF = can normatively reference. =A0 Does the WG agree on this approach?=A0 (consensus needs to be shown on = the list in one direction or another to formalize and move forward). =A0 We will give this a two week period for responses, finishing the morning = of September 3rd. =A0 Thank you in advance!=A0=20 Kathleen =A0 =A0 From takeshi_takahashi@nict.go.jp Sun Oct 14 22:36:33 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B765921F855E for ; Sun, 14 Oct 2012 22:36:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.355 X-Spam-Level: X-Spam-Status: No, score=-1.355 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PgszYDoMfzzg for ; Sun, 14 Oct 2012 22:36:33 -0700 (PDT) Received: from ns1.nict.go.jp (ns1.nict.go.jp [IPv6:2001:df0:232:300::1]) by ietfa.amsl.com (Postfix) with ESMTP id E27E721F854F for ; Sun, 14 Oct 2012 22:36:32 -0700 (PDT) Received: from gw1.nict.go.jp (gw1 [133.243.18.250]) by ns1.nict.go.jp with ESMTP id q9F5aRfG015848; Mon, 15 Oct 2012 14:36:27 +0900 (JST) Received: from gw1.nict.go.jp (localhost [127.0.0.1]) by gw1.nict.go.jp with ESMTP id q9F5aRvM008310; Mon, 15 Oct 2012 14:36:27 +0900 (JST) Received: from mail3.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw1.nict.go.jp with ESMTP id q9F5aRVM008307; Mon, 15 Oct 2012 14:36:27 +0900 (JST) Received: from mail3.nict.go.jp (localhost [127.0.0.1]) by mail3.nict.go.jp (NICT Mail) with ESMTP id 16016166BE; Mon, 15 Oct 2012 14:36:27 +0900 (JST) Received: from takeVAIO2 (unknown [133.243.119.6]) by mail3.nict.go.jp (NICT Mail) with ESMTP id 0FEBB16312; Mon, 15 Oct 2012 14:36:27 +0900 (JST) From: "Takeshi Takahashi" To: "'Moriarty, Kathleen'" , References: <1C9F17D1873AFA47A969C4DD98F98A75057C6A@xmb-rcd-x10.cisco.com> In-Reply-To: Date: Mon, 15 Oct 2012 14:36:26 +0900 Message-ID: <000e01cdaa97$04e6ca70$0eb45f50$@nict.go.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFaPwSgKugNkFHKHWsUkQETMhTq/gI75+luAaP7eICYgatFUA== Content-Language: ja Subject: Re: [mile] SCI document and WG decision X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 05:36:33 -0000 Hello all, I was late for the discussion, but let me join in. One simple example scenario is as below. It is a scenario where an organization is reporting possible incident to = its internal administrator, who analyzes and minimizes the damages caused by that. The organization realizes some anomaly and judges it as a potential incident. Multiple "sensors" inside the organization then send related log information. (It could be IODEF with CEE/Cybox embedded) In case if the sensors (or any other computer administered by operators) = can identify which vulnerability was exploited, they may also send the identifier . (IODEF with CVE identifier) The administrator then notify the organization's internal resources that = may have the same vulnerability. To do so, it is assumed that the administrator collects system = information and security status (Asset Identification, ARF, CPE, etc.) periodically = or following certain rules. Does it make sense? CEE/Cybox, CVE identifier, AI, ARF, CPE can be seen in the above = scenario. Take From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Moriarty, Kathleen Sent: Tuesday, September 11, 2012 11:23 PM To: mile@ietf.org Subject: Re: [mile] SCI document and WG decision Hello, The list is in agreement with the decision from the IETF meeting in Vancouver and this message ends the call for opinions.=A0=20 This means that we as a group have some work to do.=A0 We will start = with the SCI draft not having any included schemas, then decide what are the = needed schemas to incorporate in the draft prior to WGLC and publication.=A0 = The SCI draft does create IANA tables where additional schemas can be added to = the SCI method of extending IODEF. The SCI draft will incorporate developed schemas (not extensions = specific to IODEF as those can be drafts on their own) that add value by enabling = the IODEF schema to be extended and creating relationships to these schema standards.=A0 The format Take chose in the SCI draft categorizes schemas = to create those relationships and creates patterns for the schemas to be = added. I think the most useful approach here would be to have use case driven discussions.=A0=20 We need at least ONE schema to be agreed upon for the entire draft to = meet the IETF definition and purpose for having a Mandatory To Implement = (MTI) schema for the SCI draft.=A0 One MTI is beneficial for vendors to be = able to claim interoperability, but not necessarily to require full support for = all the schemas in the eventual tables as the vendors may be supporting different use cases and we do not want to make it too hard to implement = as that could delay implementations or stop them altogether. Let=92s not get into the MTI discussion yet, but discuss schemas that = are needed to compliment IODEF is a standard way to enable business use = cases to be met. I=92ll start a new thread asking for use case driven examples and the = schemas that best fit those use cases. Thank you, Kathleen From: Panos Kampanakis (pkampana) [mailto:pkampana@cisco.com]=20 Sent: Monday, August 20, 2012 1:24 PM To: Moriarty, Kathleen; mile@ietf.org Subject: RE: SCI document and WG decision +1 Panos From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Moriarty, Kathleen Sent: Monday, August 20, 2012 9:40 AM To: mile@ietf.org Subject: [mile] SCI document and WG decision Hello, =A0 At the IETF meeting in Vancouver, the WG consensus was to remove the referenced specifications from the SCI draft so that the document could progress without IP issues.=A0 In this model, the draft would have empty tables and the WG would then decide which specifications or standards references would get added into the document.=A0 The thought was that = the WG could think more carefully about what specifications were important to reference to meet relevant use cases for the community.=A0 The process = would include a review of the specification to ensure we could reference it, including that the specification or standard is a document that the IETF = can normatively reference. =A0 Does the WG agree on this approach?=A0 (consensus needs to be shown on = the list in one direction or another to formalize and move forward). =A0 We will give this a two week period for responses, finishing the morning = of September 3rd. =A0 Thank you in advance!=A0=20 Kathleen =A0 =A0 From internet-drafts@ietf.org Mon Oct 15 22:55:48 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13C5A21F88FE; Mon, 15 Oct 2012 22:55:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W1sqTbAoCa9c; Mon, 15 Oct 2012 22:55:47 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DE0F21F88F6; Mon, 15 Oct 2012 22:55:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121016055547.19061.51504.idtracker@ietfa.amsl.com> Date: Mon, 15 Oct 2012 22:55:47 -0700 Cc: mile@ietf.org Subject: [mile] I-D Action: draft-ietf-mile-sci-05.txt X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 05:55:48 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Managed Incident Lightweight Exchange Wor= king Group of the IETF. Title : IODEF-extension to support structured cybersecurity info= rmation Author(s) : Takeshi Takahashi Kent Landfield Thomas Millar Youki Kadobayashi Filename : draft-ietf-mile-sci-05.txt Pages : 33 Date : 2012-10-15 Abstract: This document extends the Incident Object Description Exchange Format (IODEF) defined in RFC 5070 [RFC5070] to exchange enriched cybersecurity information among cybersecurity entities and facilitate their operations. It provides the capability of embedding structured information, such as identifier- and XML-based information. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mile-sci There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mile-sci-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mile-sci-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From takeshi_takahashi@nict.go.jp Mon Oct 15 22:57:44 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67BD421F891F for ; Mon, 15 Oct 2012 22:57:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.355 X-Spam-Level: X-Spam-Status: No, score=-1.355 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_JP=1.244] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cNuF0m5vWogN for ; Mon, 15 Oct 2012 22:57:43 -0700 (PDT) Received: from ns2.nict.go.jp (ns2.nict.go.jp [IPv6:2001:df0:232:300::2]) by ietfa.amsl.com (Postfix) with ESMTP id 97F6421F8909 for ; Mon, 15 Oct 2012 22:57:43 -0700 (PDT) Received: from gw2.nict.go.jp (gw2 [133.243.18.251]) by ns2.nict.go.jp with ESMTP id q9G5vftE021128 for ; Tue, 16 Oct 2012 14:57:41 +0900 (JST) Received: from gw2.nict.go.jp (localhost [127.0.0.1]) by gw2.nict.go.jp with ESMTP id q9G5vfDp006950 for ; Tue, 16 Oct 2012 14:57:41 +0900 (JST) Received: from mail3.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw2.nict.go.jp with ESMTP id q9G5vfMn006944 for ; Tue, 16 Oct 2012 14:57:41 +0900 (JST) Received: from mail3.nict.go.jp (localhost [127.0.0.1]) by mail3.nict.go.jp (NICT Mail) with ESMTP id 57F89162F5 for ; Tue, 16 Oct 2012 14:57:41 +0900 (JST) Received: from takeVAIO2 (unknown [133.243.119.6]) by mail3.nict.go.jp (NICT Mail) with ESMTP id 5259B162E9 for ; Tue, 16 Oct 2012 14:57:41 +0900 (JST) From: "Takeshi Takahashi" To: References: <20121016055547.19061.51504.idtracker@ietfa.amsl.com> In-Reply-To: <20121016055547.19061.51504.idtracker@ietfa.amsl.com> Date: Tue, 16 Oct 2012 14:57:39 +0900 Message-ID: <001001cdab63$2674e740$735eb5c0$@nict.go.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQMbDucZ2cUo/KrM9CNQitWlAYlQp5UgqBaw Content-Language: ja Subject: Re: [mile] I-D Action: draft-ietf-mile-sci-05.txt X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 05:57:44 -0000 Hello all, Based on the discussion at the meeting in Vancouver, I've updated the SCI draft. The main content of the draft is not changed at all, and how to handle referenced specifications are the focal point of the changes. Let me summarize how I did as below. 1. Specification names are removed from the normative reference All the xml format specifications are removed from the normative reference. The text in the main body (until section 9) does not have any name of the specifications. They appear only in the appendix II and appendix III and informative references. For the purpose of providing example XML, it was needed to have these specifications in the appendices. 2. Trademark remarks are added at the beginning of Appendix II, where these trademarked specifications firstly appear. Trademark-related information are marked for all the specifications except CCSS, CVRF, CVSS, and XCCDF. 3. Mandatory to implement section was changed. There was a discussion of EICAR before. Thus the latest version of the draft uses the examples in the draft is used for that. The example contains the CEE in XML and CVE identifiers. I would appreciate any comments on the draft. Thank you. Take > -----Original Message----- > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: Tuesday, October 16, 2012 2:56 PM > To: i-d-announce@ietf.org > Cc: mile@ietf.org > Subject: [mile] I-D Action: draft-ietf-mile-sci-05.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Managed Incident Lightweight Exchange > Working Group of the IETF. > > Title : IODEF-extension to support structured > cybersecurity information > Author(s) : Takeshi Takahashi > Kent Landfield > Thomas Millar > Youki Kadobayashi > Filename : draft-ietf-mile-sci-05.txt > Pages : 33 > Date : 2012-10-15 > > Abstract: > This document extends the Incident Object Description Exchange Format > (IODEF) defined in RFC 5070 [RFC5070] to exchange enriched > cybersecurity information among cybersecurity entities and > facilitate > their operations. It provides the capability of embedding structured > information, such as identifier- and XML-based information. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-mile-sci > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-mile-sci-05 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-mile-sci-05 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile --- Takeshi Takahashi, Ph.D., Senior Researcher at National Institute of Information and Communications Technology, Tokyo, Japan. takeshi_takahashi@nict.go.jp From trammell@tik.ee.ethz.ch Tue Oct 30 02:43:43 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22A5A21F84D9 for ; Tue, 30 Oct 2012 02:43:43 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aEW1wCAUcIhu for ; Tue, 30 Oct 2012 02:43:42 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 8EA9421F84B9 for ; Tue, 30 Oct 2012 02:43:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 93669D930A for ; Tue, 30 Oct 2012 10:43:41 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 7A06LiM9fMgm for ; Tue, 30 Oct 2012 10:43:41 +0100 (MET) Received: from [10.0.27.100] (cust-integra-121-161.antanet.ch [80.75.121.161]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 52687D9307 for ; Tue, 30 Oct 2012 10:43:41 +0100 (MET) From: Brian Trammell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 30 Oct 2012 10:43:40 +0100 Message-Id: To: mile@ietf.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Subject: [mile] MILE agenda posted X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 09:43:43 -0000 Greetings, all, The MILE WG agenda for IETF 85 has been posted = tohttp://datatracker.ietf.org/meeting/85/agenda/mile/ Presenters: please send your slides to mile-chairs@tools.ietf.org by = next Tuesday morning, so that we can make sure they're available for = remote participants via MeetEcho. Best regards, Brian=