From kathleen.moriarty@emc.com Thu Nov 1 02:06:24 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 78FC421F853B for ; Thu, 1 Nov 2012 02:06:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 vImyUBUQkaFE for ; Thu, 1 Nov 2012 02:06:23 -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 C232F21F853D for ; Thu, 1 Nov 2012 02:06:23 -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 qA196JHB021303 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 1 Nov 2012 05:06:19 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd04.lss.emc.com [10.254.222.226]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor) for ; Thu, 1 Nov 2012 05:06:05 -0400 Received: from mxhub10.corp.emc.com (mxhub10.corp.emc.com [10.254.92.105]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id qA1964Wi008781 for ; Thu, 1 Nov 2012 05:06:05 -0400 Received: from mx15a.corp.emc.com ([169.254.1.83]) by mxhub10.corp.emc.com ([10.254.92.105]) with mapi; Thu, 1 Nov 2012 05:06:04 -0400 From: "Moriarty, Kathleen" To: "mile@ietf.org" Date: Thu, 1 Nov 2012 05:05:57 -0400 Thread-Topic: [sacm] FW: [85all] NomCom: Office Hours in Atlanta Thread-Index: Ac24EB5LdtDLSOmiSI61DVdT6jfy7w== Message-ID: <5612A748-82A5-475B-857C-869B445E1ACE@emc.com> References: 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 Subject: [mile] Fwd: [sacm] FW: [85all] NomCom: Office Hours in Atlanta 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, 01 Nov 2012 09:06:24 -0000 Please help NomCom with you comments on specific individuals as well as gen= eral feedback related to position being considered. Thank you, Kathleen=20 Sent from my iPhone >=20 > -----Original Message----- > From: 85all-bounces@ietf.org [mailto:85all-bounces@ietf.org] On Behalf > Of Matthew Lepinski > Sent: Thursday, November 01, 2012 5:09 AM > To: 85all@ietf.org > Subject: [85all] NomCom: Office Hours in Atlanta >=20 > The IETF Nominations Committee (NomCom) continues to seek input from the > IETF Community. >=20 > The final list of candidates (as per RFC 5680) that the NomCom is > considering for open positions can be found at: > https://www.ietf.org/group/nomcom/2012/input/ >=20 > The NomCom will be holding office hours during IETF 85, Monday- Thursday > from 1:00pm to 3:00pm in Room 305. The NomCom welcomes comments on > specific individuals, as well as general feedback related to any of the > positions that NomCom is considering. >=20 > Note: A list of leadership positions that the NomCom is considering can > be found at: https://www.ietf.org/group/nomcom/2012/ >=20 > If the NomCom office hours are inconvenient for you or if you cannot > attend IETF 85, the NomCom is happy to take community input via email to > nomcom12@ietf.org. Additionally, the NomCom is happy to arrange a > meeting outside of office hours, just send us email and we can set > something up. >=20 > Comments on specific candidates can also be provided to the NomCom via > the web feedback tool: > https://www.ietf.org/group/nomcom/2012/input/ >=20 > In order to ensure that your input is received in time to be useful, > please provide your input on or before Sunday, November 4. >=20 > Thank you for your help, > - Matt Lepinski > nomcom-chair@ietf.org > _______________________________________________ > 85all mailing list > 85all@ietf.org > https://www.ietf.org/mailman/listinfo/85all > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm >=20 From kathleen.moriarty@emc.com Thu Nov 1 07:14:15 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 E573C21F8CDF for ; Thu, 1 Nov 2012 07:14:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LpRpRdwgT0jS for ; Thu, 1 Nov 2012 07:14:15 -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 306B821F8ABB for ; Thu, 1 Nov 2012 07:14:14 -0700 (PDT) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id qA1EED8A007413 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 1 Nov 2012 10:14:14 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.226]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor) for ; Thu, 1 Nov 2012 10:14:01 -0400 Received: from mxhub15.corp.emc.com (mxhub15.corp.emc.com [128.222.70.236]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id qA1EE0gb008806 for ; Thu, 1 Nov 2012 10:14:01 -0400 Received: from mxhub38.corp.emc.com (128.222.70.105) by mxhub15.corp.emc.com (128.222.70.236) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 1 Nov 2012 10:14:00 -0400 Received: from mx15a.corp.emc.com ([169.254.1.83]) by mxhub38.corp.emc.com ([128.222.70.105]) with mapi; Thu, 1 Nov 2012 10:14:01 -0400 From: "Moriarty, Kathleen" To: "mile@ietf.org" Date: Thu, 1 Nov 2012 10:13:56 -0400 Thread-Topic: [85all] NomCom: Office Hours in Atlanta Thread-Index: Ac24OyLEGzUMChrTR2KwCAykoBTjcA== Message-ID: <713AD05B-CEB0-45CC-ABDC-83238267AD1E@emc.com> References: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_713AD05BCEB045CCABDC83238267AD1Eemccom_" MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: [mile] Fwd: [85all] NomCom: Office Hours in Atlanta 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, 01 Nov 2012 14:14:16 -0000 --_000_713AD05BCEB045CCABDC83238267AD1Eemccom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNClNlbnQgZnJvbSBteSBpUGhvbmUNCg0KQmVnaW4gZm9yd2FyZGVkIG1lc3NhZ2U6DQoNCkZy b206IE1hdHRoZXcgTGVwaW5za2kgPG1sZXBpbnNraS5pZXRmQGdtYWlsLmNvbTxtYWlsdG86bWxl cGluc2tpLmlldGZAZ21haWwuY29tPj4NCkRhdGU6IE5vdmVtYmVyIDEsIDIwMTIgMTI6MjI6NDgg UE0gR01UDQpUbzogIjg1YWxsQGlldGYub3JnPG1haWx0bzo4NWFsbEBpZXRmLm9yZz4iIDw4NWFs bEBpZXRmLm9yZzxtYWlsdG86ODVhbGxAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFs4NWFsbF0g Tm9tQ29tOiBPZmZpY2UgSG91cnMgaW4gQXRsYW50YQ0KDQpJIGFwb2xvZ2l6ZSBmb3IgYSBtaW5v ciBlcnJvciBpbiB0aGUgbWVzc2FnZSBiZWxvdy4NCg0KSW4gb3JkZXIgdG8gZW5zdXJlIHRoYXQg eW91ciBpbnB1dCBpcyB1c2VmdWwgdG8gdGhlIE5vbUNvbSwgcGxlYXNlDQpzZW5kIHVzIHlvdXIg ZmVlZGJhY2sgb24gb3IgYmVmb3JlIFN1bmRheSwgTm92ZW1iZXIgMTEuDQooaS5lLiwgTk9UIE5v dmVtYmVyIDQgYXMgaW5jb3JyZWN0bHkgaW5kaWNhdGVkIGluIHRoZSBlbWFpbCBiZWxvdykNCg0K LSBNYXR0IExlcGluc2tpDQogPG1haWx0bzpub21jb20tY2hhaXJAaWV0Zi5vcmc+IG5vbWNvbS1j aGFpckBpZXRmLm9yZzxtYWlsdG86bm9tY29tLWNoYWlyQGlldGYub3JnPg0KDQpPbiBXZWQsIE9j dCAzMSwgMjAxMiBhdCAxMTowOSBQTSwgTWF0dGhldyBMZXBpbnNraQ0KPG1sZXBpbnNraS5pZXRm QGdtYWlsLmNvbTxtYWlsdG86bWxlcGluc2tpLmlldGZAZ21haWwuY29tPj4gd3JvdGU6DQpUaGUg SUVURiBOb21pbmF0aW9ucyBDb21taXR0ZWUgKE5vbUNvbSkgY29udGludWVzIHRvIHNlZWsgaW5w dXQgZnJvbQ0KdGhlIElFVEYgQ29tbXVuaXR5Lg0KDQpUaGUgZmluYWwgbGlzdCBvZiBjYW5kaWRh dGVzIChhcyBwZXIgUkZDIDU2ODApIHRoYXQgdGhlIE5vbUNvbSBpcw0KY29uc2lkZXJpbmcgZm9y IG9wZW4gcG9zaXRpb25zIGNhbiBiZSBmb3VuZCBhdDoNCmh0dHBzOi8vd3d3LmlldGYub3JnL2dy b3VwL25vbWNvbS8yMDEyL2lucHV0Lw0KDQpUaGUgTm9tQ29tIHdpbGwgYmUgaG9sZGluZyBvZmZp Y2UgaG91cnMgZHVyaW5nIElFVEYgODUsIE1vbmRheS0NClRodXJzZGF5IGZyb20gMTowMHBtIHRv IDM6MDBwbSBpbiBSb29tIDMwNS4gVGhlIE5vbUNvbSB3ZWxjb21lcw0KY29tbWVudHMgb24gc3Bl Y2lmaWMgaW5kaXZpZHVhbHMsIGFzIHdlbGwgYXMgZ2VuZXJhbCBmZWVkYmFjayByZWxhdGVkIHRv DQphbnkgb2YgdGhlIHBvc2l0aW9ucyB0aGF0IE5vbUNvbSBpcyBjb25zaWRlcmluZy4NCg0KTm90 ZTogQSBsaXN0IG9mIGxlYWRlcnNoaXAgcG9zaXRpb25zIHRoYXQgdGhlIE5vbUNvbSBpcyBjb25z aWRlcmluZyBjYW4gYmUNCmZvdW5kIGF0OiA8aHR0cHM6Ly93d3cuaWV0Zi5vcmcvZ3JvdXAvbm9t Y29tLzIwMTIvPiBodHRwczovL3d3dy5pZXRmLm9yZy9ncm91cC9ub21jb20vMjAxMi8NCg0KSWYg dGhlIE5vbUNvbSBvZmZpY2UgaG91cnMgYXJlIGluY29udmVuaWVudCBmb3IgeW91IG9yIGlmIHlv dSBjYW5ub3QNCmF0dGVuZCBJRVRGIDg1LCB0aGUgTm9tQ29tIGlzIGhhcHB5IHRvIHRha2UgY29t bXVuaXR5IGlucHV0IHZpYSBlbWFpbA0KdG8gbm9tY29tMTJAaWV0Zi5vcmc8bWFpbHRvOm5vbWNv bTEyQGlldGYub3JnPi4gQWRkaXRpb25hbGx5LCB0aGUgTm9tQ29tIGlzIGhhcHB5IHRvIGFycmFu Z2UgYQ0KbWVldGluZyBvdXRzaWRlIG9mIG9mZmljZSBob3VycywganVzdCBzZW5kIHVzIGVtYWls IGFuZCB3ZSBjYW4gc2V0DQpzb21ldGhpbmcgdXAuDQoNCkNvbW1lbnRzIG9uIHNwZWNpZmljIGNh bmRpZGF0ZXMgY2FuIGFsc28gYmUgcHJvdmlkZWQgdG8gdGhlIE5vbUNvbQ0KdmlhIHRoZSB3ZWIg ZmVlZGJhY2sgdG9vbDoNCmh0dHBzOi8vd3d3LmlldGYub3JnL2dyb3VwL25vbWNvbS8yMDEyL2lu cHV0Lw0KDQpJbiBvcmRlciB0byBlbnN1cmUgdGhhdCB5b3VyIGlucHV0IGlzIHJlY2VpdmVkIGlu IHRpbWUgdG8gYmUgdXNlZnVsLCBwbGVhc2UNCnByb3ZpZGUgeW91ciBpbnB1dCBvbiBvciBiZWZv cmUgU3VuZGF5LCBOb3ZlbWJlciA0Lg0KDQpUaGFuayB5b3UgZm9yIHlvdXIgaGVscCwNCi0gTWF0 dCBMZXBpbnNraQ0KIDxtYWlsdG86bm9tY29tLWNoYWlyQGlldGYub3JnPiBub21jb20tY2hhaXJA aWV0Zi5vcmc8bWFpbHRvOm5vbWNvbS1jaGFpckBpZXRmLm9yZz4NCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo4NWFsbCBtYWlsaW5nIGxpc3QNCjg1YWxs QGlldGYub3JnPG1haWx0bzo4NWFsbEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vODVhbGwNCg0K --_000_713AD05BCEB045CCABDC83238267AD1Eemccom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+PGJvZHkgYmdjb2xvcj0iI0ZGRkZGRiI+PGRpdj48YnI+PGJyPlNlbnQgZnJvbSBteSBp UGhvbmU8L2Rpdj48ZGl2Pjxicj5CZWdpbiBmb3J3YXJkZWQgbWVzc2FnZTo8YnI+PGJyPjwvZGl2 PjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxkaXY+PGI+RnJvbTo8L2I+IE1hdHRoZXcgTGVwaW5z a2kgJmx0OzxhIGhyZWY9Im1haWx0bzptbGVwaW5za2kuaWV0ZkBnbWFpbC5jb20iPm1sZXBpbnNr aS5pZXRmQGdtYWlsLmNvbTwvYT4mZ3Q7PGJyPjxiPkRhdGU6PC9iPiBOb3ZlbWJlciAxLCAyMDEy IDEyOjIyOjQ4IFBNIEdNVDxicj48Yj5Ubzo8L2I+ICI8YSBocmVmPSJtYWlsdG86ODVhbGxAaWV0 Zi5vcmciPjg1YWxsQGlldGYub3JnPC9hPiIgJmx0OzxhIGhyZWY9Im1haWx0bzo4NWFsbEBpZXRm Lm9yZyI+ODVhbGxAaWV0Zi5vcmc8L2E+Jmd0Ozxicj48Yj5TdWJqZWN0OjwvYj4gPGI+UmU6IFs4 NWFsbF0gTm9tQ29tOiBPZmZpY2UgSG91cnMgaW4gQXRsYW50YTwvYj48YnI+PGJyPjwvZGl2Pjwv YmxvY2txdW90ZT48ZGl2PjwvZGl2PjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxkaXY+PHNwYW4+ SSBhcG9sb2dpemUgZm9yIGEgbWlub3IgZXJyb3IgaW4gdGhlIG1lc3NhZ2UgYmVsb3cuPC9zcGFu Pjxicj48c3Bhbj48L3NwYW4+PGJyPjxzcGFuPkluIG9yZGVyIHRvIGVuc3VyZSB0aGF0IHlvdXIg aW5wdXQgaXMgdXNlZnVsIHRvIHRoZSBOb21Db20sIHBsZWFzZTwvc3Bhbj48YnI+PHNwYW4+c2Vu ZCB1cyB5b3VyIGZlZWRiYWNrIG9uIG9yIGJlZm9yZSBTdW5kYXksIE5vdmVtYmVyIDExLjwvc3Bh bj48YnI+PHNwYW4+KGkuZS4sIE5PVCBOb3ZlbWJlciA0IGFzIGluY29ycmVjdGx5IGluZGljYXRl ZCBpbiB0aGUgZW1haWwgYmVsb3cpPC9zcGFuPjxicj48c3Bhbj48L3NwYW4+PGJyPjxzcGFuPi0g TWF0dCBMZXBpbnNraTwvc3Bhbj48YnI+PHNwYW4+ICZuYnNwOzxhIGhyZWY9Im1haWx0bzpub21j b20tY2hhaXJAaWV0Zi5vcmciPjxhIGhyZWY9Im1haWx0bzpub21jb20tY2hhaXJAaWV0Zi5vcmci Pm5vbWNvbS1jaGFpckBpZXRmLm9yZzwvYT48L2E+PC9zcGFuPjxicj48c3Bhbj48L3NwYW4+PGJy PjxzcGFuPk9uIFdlZCwgT2N0IDMxLCAyMDEyIGF0IDExOjA5IFBNLCBNYXR0aGV3IExlcGluc2tp PC9zcGFuPjxicj48c3Bhbj4mbHQ7PGEgaHJlZj0ibWFpbHRvOm1sZXBpbnNraS5pZXRmQGdtYWls LmNvbSI+bWxlcGluc2tpLmlldGZAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PC9zcGFuPjxicj48 YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj5UaGUgSUVURiBOb21pbmF0aW9ucyBDb21taXR0 ZWUgKE5vbUNvbSkgY29udGludWVzIHRvIHNlZWsgaW5wdXQgZnJvbTwvc3Bhbj48YnI+PC9ibG9j a3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPnRoZSBJRVRGIENvbW11bml0eS48 L3NwYW4+PGJyPjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj48L3Nw YW4+PGJyPjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj5UaGUgZmlu YWwgbGlzdCBvZiBjYW5kaWRhdGVzIChhcyBwZXIgUkZDIDU2ODApIHRoYXQgdGhlIE5vbUNvbSBp czwvc3Bhbj48YnI+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPmNv bnNpZGVyaW5nIGZvciBvcGVuIHBvc2l0aW9ucyBjYW4gYmUgZm91bmQgYXQ6PC9zcGFuPjxicj48 L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+PGEgaHJlZj0iaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvZ3JvdXAvbm9tY29tLzIwMTIvaW5wdXQvIj5odHRwczovL3d3dy5pZXRm Lm9yZy9ncm91cC9ub21jb20vMjAxMi9pbnB1dC88L2E+PC9zcGFuPjxicj48L2Jsb2NrcXVvdGU+ PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+PC9zcGFuPjxicj48L2Jsb2NrcXVvdGU+PGJs b2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+VGhlIE5vbUNvbSB3aWxsIGJlIGhvbGRpbmcgb2Zm aWNlIGhvdXJzIGR1cmluZyBJRVRGIDg1LCBNb25kYXktPC9zcGFuPjxicj48L2Jsb2NrcXVvdGU+ PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+VGh1cnNkYXkgZnJvbSAxOjAwcG0gdG8gMzow MHBtIGluIFJvb20gMzA1LiBUaGUgTm9tQ29tIHdlbGNvbWVzPC9zcGFuPjxicj48L2Jsb2NrcXVv dGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+Y29tbWVudHMgb24gc3BlY2lmaWMgaW5k aXZpZHVhbHMsIGFzIHdlbGwgYXMgZ2VuZXJhbCBmZWVkYmFjayByZWxhdGVkIHRvPC9zcGFuPjxi cj48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+YW55IG9mIHRoZSBw b3NpdGlvbnMgdGhhdCBOb21Db20gaXMgY29uc2lkZXJpbmcuPC9zcGFuPjxicj48L2Jsb2NrcXVv dGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+PC9zcGFuPjxicj48L2Jsb2NrcXVvdGU+ PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+Tm90ZTogQSBsaXN0IG9mIGxlYWRlcnNoaXAg cG9zaXRpb25zIHRoYXQgdGhlIE5vbUNvbSBpcyBjb25zaWRlcmluZyBjYW4gYmU8L3NwYW4+PGJy PjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj5mb3VuZCBhdDogPGEg aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvZ3JvdXAvbm9tY29tLzIwMTIvIj48YSBocmVmPSJo dHRwczovL3d3dy5pZXRmLm9yZy9ncm91cC9ub21jb20vMjAxMi8iPmh0dHBzOi8vd3d3LmlldGYu b3JnL2dyb3VwL25vbWNvbS8yMDEyLzwvYT48L2E+PC9zcGFuPjxicj48L2Jsb2NrcXVvdGU+PGJs b2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+PC9zcGFuPjxicj48L2Jsb2NrcXVvdGU+PGJsb2Nr cXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+SWYgdGhlIE5vbUNvbSBvZmZpY2UgaG91cnMgYXJlIGlu Y29udmVuaWVudCBmb3IgeW91IG9yIGlmIHlvdSBjYW5ub3Q8L3NwYW4+PGJyPjwvYmxvY2txdW90 ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj5hdHRlbmQgSUVURiA4NSwgdGhlIE5vbUNv bSBpcyBoYXBweSB0byB0YWtlIGNvbW11bml0eSBpbnB1dCB2aWEgZW1haWw8L3NwYW4+PGJyPjwv YmxvY2txdW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj50byA8YSBocmVmPSJtYWls dG86bm9tY29tMTJAaWV0Zi5vcmciPm5vbWNvbTEyQGlldGYub3JnPC9hPi4gQWRkaXRpb25hbGx5 LCB0aGUgTm9tQ29tIGlzIGhhcHB5IHRvIGFycmFuZ2UgYTwvc3Bhbj48YnI+PC9ibG9ja3F1b3Rl PjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPm1lZXRpbmcgb3V0c2lkZSBvZiBvZmZpY2Ug aG91cnMsIGp1c3Qgc2VuZCB1cyBlbWFpbCBhbmQgd2UgY2FuIHNldDwvc3Bhbj48YnI+PC9ibG9j a3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPnNvbWV0aGluZyB1cC48L3NwYW4+ PGJyPjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj48L3NwYW4+PGJy PjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj5Db21tZW50cyBvbiBz cGVjaWZpYyBjYW5kaWRhdGVzIGNhbiBhbHNvIGJlIHByb3ZpZGVkIHRvIHRoZSBOb21Db208L3Nw YW4+PGJyPjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj52aWEgdGhl IHdlYiBmZWVkYmFjayB0b29sOjwvc3Bhbj48YnI+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5 cGU9ImNpdGUiPjxzcGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL2dyb3VwL25vbWNv bS8yMDEyL2lucHV0LyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvZ3JvdXAvbm9tY29tLzIwMTIvaW5w dXQvPC9hPjwvc3Bhbj48YnI+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxz cGFuPjwvc3Bhbj48YnI+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFu PkluIG9yZGVyIHRvIGVuc3VyZSB0aGF0IHlvdXIgaW5wdXQgaXMgcmVjZWl2ZWQgaW4gdGltZSB0 byBiZSB1c2VmdWwsIHBsZWFzZTwvc3Bhbj48YnI+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5 cGU9ImNpdGUiPjxzcGFuPnByb3ZpZGUgeW91ciBpbnB1dCBvbiBvciBiZWZvcmUgU3VuZGF5LCBO b3ZlbWJlciA0Ljwvc3Bhbj48YnI+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUi PjxzcGFuPjwvc3Bhbj48YnI+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxz cGFuPlRoYW5rIHlvdSBmb3IgeW91ciBoZWxwLDwvc3Bhbj48YnI+PC9ibG9ja3F1b3RlPjxibG9j a3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPi0gTWF0dCBMZXBpbnNraTwvc3Bhbj48YnI+PC9ibG9j a3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPiAmbmJzcDs8YSBocmVmPSJtYWls dG86bm9tY29tLWNoYWlyQGlldGYub3JnIj48YSBocmVmPSJtYWlsdG86bm9tY29tLWNoYWlyQGll dGYub3JnIj5ub21jb20tY2hhaXJAaWV0Zi5vcmc8L2E+PC9hPjwvc3Bhbj48YnI+PC9ibG9ja3F1 b3RlPjxzcGFuPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f PC9zcGFuPjxicj48c3Bhbj44NWFsbCBtYWlsaW5nIGxpc3Q8L3NwYW4+PGJyPjxzcGFuPjxhIGhy ZWY9Im1haWx0bzo4NWFsbEBpZXRmLm9yZyI+ODVhbGxAaWV0Zi5vcmc8L2E+PC9zcGFuPjxicj48 c3Bhbj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvLzg1YWxs Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvLzg1YWxsPC9hPjwvc3Bhbj48 YnI+PHNwYW4+PC9zcGFuPjxicj48L2Rpdj48L2Jsb2NrcXVvdGU+PC9ib2R5PjwvaHRtbD4= --_000_713AD05BCEB045CCABDC83238267AD1Eemccom_-- From amontville@tripwire.com Sun Nov 4 14:05:24 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 09FD021F84A8 for ; Sun, 4 Nov 2012 14:05:24 -0800 (PST) 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 wNMIw8mywTio for ; Sun, 4 Nov 2012 14:05:23 -0800 (PST) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe006.messaging.microsoft.com [216.32.180.16]) by ietfa.amsl.com (Postfix) with ESMTP id BF43E21F84AF for ; Sun, 4 Nov 2012 14:05:22 -0800 (PST) Received: from mail208-va3-R.bigfish.com (10.7.14.246) by VA3EHSOBE005.bigfish.com (10.7.40.25) with Microsoft SMTP Server id 14.1.225.23; Sun, 4 Nov 2012 22:05:22 +0000 Received: from mail208-va3 (localhost [127.0.0.1]) by mail208-va3-R.bigfish.com (Postfix) with ESMTP id D8C66720118 for ; Sun, 4 Nov 2012 22:05:21 +0000 (UTC) X-Forefront-Antispam-Report: CIP:174.47.84.215; KIP:(null); UIP:(null); IPV:NLI; H:zgw01.tripwire.com; RD:174-47-84-215.static.twtelecom.net; EFVD:NLI X-SpamScore: -38 X-BigFish: VPS-38(zzbb2dI98dI9371I936eI148cI542M1432I11f6N111aIzz1de0h1202h1d1ah1d2ahzz1033IL17326ah8275bh8275dhz2dh2a8h668h839h944hd25he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h14ddh1504h1537h153bh1155h) Received: from mail208-va3 (localhost.localdomain [127.0.0.1]) by mail208-va3 (MessageSwitch) id 1352066720284361_6914; Sun, 4 Nov 2012 22:05:20 +0000 (UTC) Received: from VA3EHSMHS003.bigfish.com (unknown [10.7.14.236]) by mail208-va3.bigfish.com (Postfix) with ESMTP id 39090D4008A for ; Sun, 4 Nov 2012 22:05:20 +0000 (UTC) Received: from zgw01.tripwire.com (174.47.84.215) by VA3EHSMHS003.bigfish.com (10.7.99.13) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sun, 4 Nov 2012 22:05:17 +0000 Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.tripwire.com (Proprietary) with SMTP id 7A0792321213 for ; Sun, 4 Nov 2012 13:56:51 -0800 (PST) Received: from PDXED01.tripwire.com (unknown [192.168.192.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by zgw01.tripwire.com (Proprietary) with ESMTPS id CD61C232120B; Sun, 4 Nov 2012 13:56:50 -0800 (PST) Received: from PDXHB01.tripwire.com (172.30.0.53) by PDXED01.tripwire.com (192.168.192.5) with Microsoft SMTP Server (TLS) id 14.1.379.0; Sun, 4 Nov 2012 14:09:33 -0800 Received: from PDXMB02.tripwire.com ([fe80::f997:7b65:8e64:438e]) by PDXHB01.tripwire.com ([fe80::d495:98d2:7df4:2154%11]) with mapi id 14.01.0379.000; Sun, 4 Nov 2012 14:05:15 -0800 From: Adam Montville To: Takeshi Takahashi Thread-Topic: [mile] New Version Notification for draft-montville-mile-enum-reference-format-00.txt Thread-Index: AQHNuth3NIENhykBH0ijZtq2yS6GJw== Date: Sun, 4 Nov 2012 22:05:14 +0000 Message-ID: <16219828-D8E4-42F1-A18F-C2B5B7DC1F10@tripwire.com> References: <000001cda6ac$6621f6a0$3265e3e0$@nict.go.jp> In-Reply-To: <000001cda6ac$6621f6a0$3265e3e0$@nict.go.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.0.234] x-exclaimer-md-config: 79afcaa7-fdf4-4fa6-abe0-afeaa4640a4f Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-VPM-MSG-ID: c0fe2d2e-7fa9-410e-b3ff-366d2f687400 X-VPM-HOST: zgw01.tripwire.com X-VPM-ENC-REGIME: Plaintext X-VPM-CERT-FLAG: 0 X-VPM-IS-HYBRID: 0 X-OriginatorOrg: tripwire.com Cc: "" Subject: Re: [mile] 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: Sun, 04 Nov 2012 22:05:24 -0000 Hi Take, Many apologies for taking so long to respond to this. I was anticipating t= hat the name would be kept distinct from the version, much like the Common = Platform Enumeration specification segregates version from platform name. Adam On Oct 10, 2012, at 1:59 AM, Takeshi Takahashi wrote: > Hi Adam, >=20 > Thank you for posting the draft. > I like the IANA table that the draft will create, and the SCI draft shoul= d > be able to use the table as well. >=20 > Regarding the IANA table, you have "Version" in addition to "Name." > For this point. Let me ask you a clarification question. >=20 > 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) >=20 > If it is the latter case (case B), I wonder whether we need "Version" ent= ry > since the version information is included inside the identifier ("Name") >=20 > Just a clarification question, and I would be happy to hear your opinion = on > this. >=20 > Thank you. > Take >=20 >=20 >=20 >=20 >> -----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 >>=20 >> On 9/28/12 6:19 AM, "Moriarty, Kathleen" >> wrote: >>=20 >>> Hi Adam, >>>=20 >>> I am sorry for the confusion! I was referring to the full value >>> contained in the "ReferenceName". >>=20 >> That makes more sense to me, sorry. This is a great point, Kathleen. >>=20 >>> The example shows: >>>=20 >>> >>> CXI:CXI-1234-XYZ >>> http://cxi.example.com >>> Foo >>> >>>=20 >>> Information in the IANA table (see Section 4) would include: >>>=20 >>> Name: Concept X Identifier >>> Version: x.y >>> Specification URI: http://cxi.example.com/spec_url >>> Reference: Foo. >>>=20 >>>=20 >>> 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. >>=20 >>=20 >> 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). >>=20 >>=20 >> 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 lik= e >> to hear from the list as to what they think) - so essentially a string >> with some character restrictions. >>=20 >> As I mention above, I'd really like to hear from others on the list as >> to what they feel is best. >>=20 >> Thanks again for pointing this out. >>=20 >>=20 >>>=20 >>>=20 >>> Thank you, >>> Kathleen >>>=20 >>> ________________________________________ >>> 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 >>>=20 >>> On 9/27/12 6:17 AM, "Moriarty, Kathleen" >>> wrote: >>>=20 >>>> Adam & MILE members, >>>>=20 >>>> 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. >>>>=20 >>>> Any thoughts - Adam or others on the MILE list? >>>=20 >>>=20 >>> 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). >>>=20 >>> Does that help or are we talking about two different things? >>>=20 >>> Adam >>>=20 >>>=20 >>>>=20 >>>> 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 >>>>=20 >>>> Adam, >>>>=20 >>>> Thank you very much for your work on this draft! >>>>=20 >>>> MILE members: Please review and comment on the draft. >>>>=20 >>>> 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 >>>>=20 >>>> On 9/1/12 6:46 AM, "internet-drafts@ietf.org" >>>> >>>> wrote: >>>>=20 >>>>>=20 >>>>> 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. >>>>>=20 >>>>> 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 >>>>>=20 >>>>>=20 >>>>> 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. >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> The IETF Secretariat >>>>>=20 >>>>>=20 >>>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=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 >>>>=20 >>>>=20 >>>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> mile mailing list >> mile@ietf.org >> https://www.ietf.org/mailman/listinfo/mile >=20 >=20 From takeshi_takahashi@nict.go.jp Sun Nov 4 15:39: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 C6C3621F87FA for ; Sun, 4 Nov 2012 15:39:33 -0800 (PST) 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 dbUsX0MzveEr for ; Sun, 4 Nov 2012 15:39:33 -0800 (PST) Received: from ns2.nict.go.jp (ns2.nict.go.jp [IPv6:2001:df0:232:300::2]) by ietfa.amsl.com (Postfix) with ESMTP id BC37621F87F7 for ; Sun, 4 Nov 2012 15:39:32 -0800 (PST) Received: from gw2.nict.go.jp (gw2 [133.243.18.251]) by ns2.nict.go.jp with ESMTP id qA4NdVXZ016165; Mon, 5 Nov 2012 08:39:31 +0900 (JST) Received: from gw2.nict.go.jp (localhost [127.0.0.1]) by gw2.nict.go.jp with ESMTP id qA4NdVkX013400; Mon, 5 Nov 2012 08:39:31 +0900 (JST) Received: from takeVAIO2 (ssh.nict.go.jp [133.243.3.49]) by gw2.nict.go.jp with ESMTP id qA4NdQ3Q013362; Mon, 5 Nov 2012 08:39:28 +0900 (JST) From: "Takeshi Takahashi" To: "'Adam Montville'" References: <000001cda6ac$6621f6a0$3265e3e0$@nict.go.jp> <16219828-D8E4-42F1-A18F-C2B5B7DC1F10@tripwire.com> In-Reply-To: <16219828-D8E4-42F1-A18F-C2B5B7DC1F10@tripwire.com> Date: Sun, 4 Nov 2012 17:39:26 -0600 Message-ID: <009401cdbae5$a2574d80$e705e880$@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: AQHXmF/S9wtSBIyNY8u7NigMhkqZcAJuqzcBATiJPxMBeAxXu5ednuRA Content-Language: ja Cc: mile@ietf.org Subject: Re: [mile] 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: Sun, 04 Nov 2012 23:39:33 -0000 Hi Adam, Thank you for your clarification. Things are clear to me. I am just sticking to a very minor issue, so let me talk to you in Atlanta. Sincerely, Take > -----Original Message----- > From: Adam Montville [mailto:amontville@tripwire.com] > Sent: Sunday, November 04, 2012 4:05 PM > To: Takeshi Takahashi > Cc: Moriarty, Kathleen; > Subject: Re: [mile] New Version Notification for > draft-montville-mile-enum-reference-format-00.txt > > Hi Take, > > Many apologies for taking so long to respond to this. I was anticipating > that the name would be kept distinct from the version, much like the Common > Platform Enumeration specification segregates version from platform > name. > > Adam > > On Oct 10, 2012, at 1:59 AM, Takeshi Takahashi > wrote: > > > 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 trammell@tik.ee.ethz.ch Mon Nov 5 07:47:17 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 6FE7521F87AA for ; Mon, 5 Nov 2012 07:47:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8HPgyfdE5bAQ for ; Mon, 5 Nov 2012 07:47:16 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 433F121F867D for ; Mon, 5 Nov 2012 07:47:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 9D097D930A for ; Mon, 5 Nov 2012 16:47:14 +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 7FwmxwLpadkt for ; Mon, 5 Nov 2012 16:47:14 +0100 (MET) Received: from dhcp-549e.meeting.ietf.org (dhcp-549e.meeting.ietf.org [130.129.84.158]) (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 05495D9305 for ; Mon, 5 Nov 2012 16:47:13 +0100 (MET) From: Brian Trammell Content-Type: multipart/alternative; boundary="Apple-Mail=_C7BA1D12-4873-4632-A7E1-EECEF5F6ECE2" Message-Id: <24A28E9E-B605-4B32-B182-0E1C577A9D5C@tik.ee.ethz.ch> Date: Mon, 5 Nov 2012 10:47:12 -0500 To: mile@ietf.org Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [mile] MILE Agenda, Tuesday 6 November 2012 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, 05 Nov 2012 15:47:17 -0000 --Apple-Mail=_C7BA1D12-4873-4632-A7E1-EECEF5F6ECE2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Managed Incident Lightweight Exchange (mile) Working = Group =20 Agenda for IETF 85, Atlanta =20 Tuesday 6 November 2012, 15:20 - 16:50 = Salon E = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 Chairs: Kathleen Moriarty Brian Trammell =20 AGENDA: =20 1. Agenda-bashing and WG status =3D = 30 min =20 Call for Participation: IODEF-bis / IODEF Guidance Survey =20 Charter and Milestone Review =20 2. Active WG documents =3D = 20 min =20 IODEF-extension to support structured cybersecurity = information draft-ietf-mile-sci (T. = Takahashi) =20 3. Individual Drafts =3D = 40 min =20 IODEF Enumeration Reference Format draft-montville-mile-enum-reference-format (A. = Montville) =20 Resource-Oriented Lightweight Indicator Exchange draft-field-mile-rolie = (J. Field) =20 Remote participation is available via Meetecho http://ietf85.conf.meetecho.com/ =20 Remote participants, please note that the meeting takes place = in UTC-6, i.e. from 21:20 to 22:50 UTC. =20 Presentation slides will be available at = https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=3D85= (search for MILE in the Security Area) =20 --Apple-Mail=_C7BA1D12-4873-4632-A7E1-EECEF5F6ECE2 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii 
         =======================================================================
                Managed Incident Lightweight Exchange (mile) Working Group
          
                            Agenda for IETF 85, Atlanta
          
          Tuesday 6 November 2012, 15:20 - 16:50                          Salon E
          =======================================================================
          
          Chairs:
          Kathleen Moriarty <kathleen.moriarty@emc.com>
          Brian Trammell <trammell@tik.ee.ethz.ch>
          
          AGENDA:
          
          1. Agenda-bashing and WG status                            = 30 min
          
             Call for Participation: IODEF-bis / IODEF Guidance Survey
          
             Charter and Milestone Review
          
          2. Active WG documents                                     = 20 min
          
             IODEF-extension to support structured cybersecurity information
             draft-ietf-mile-sci                                   (T. Takahashi)
          
          3. Individual Drafts                                       = 40 min
          
             IODEF Enumeration Reference Format
             draft-montville-mile-enum-reference-format            (A. Montville)
          
             Resource-Oriented Lightweight Indicator Exchange
             draft-field-mile-rolie                                    (J. Field)
          
          Remote participation is available via Meetecho
            http://ietf85.conf.meetecho.com/
          
          Remote participants, please note that the meeting takes place in UTC-6,
          i.e. from 21:20 to 22:50 UTC.
          
          Presentation slides will be available at
          https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=85
          (search for MILE in the Security Area)

--Apple-Mail=_C7BA1D12-4873-4632-A7E1-EECEF5F6ECE2-- From david.black@emc.com Mon Nov 5 13:38:26 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 2DB5B21F84DD for ; Mon, 5 Nov 2012 13:38:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, 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 Mt95rCNUkZne for ; Mon, 5 Nov 2012 13:38:25 -0800 (PST) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 8723D21F84BC for ; Mon, 5 Nov 2012 13:38:25 -0800 (PST) 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 qA5LcMkS027146 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 5 Nov 2012 16:38:23 -0500 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.129]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor) for ; Mon, 5 Nov 2012 16:38:12 -0500 Received: from mxhub18.corp.emc.com (mxhub18.corp.emc.com [10.254.93.47]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id qA5LcCNH019402 for ; Mon, 5 Nov 2012 16:38:12 -0500 Received: from mx15a.corp.emc.com ([169.254.1.83]) by mxhub18.corp.emc.com ([10.254.93.47]) with mapi; Mon, 5 Nov 2012 16:38:11 -0500 From: "Black, David" To: "mile@ietf.org" Date: Mon, 5 Nov 2012 16:38:10 -0500 Thread-Topic: draft-montville-mile-enum-reference-format-00.txt - formats Thread-Index: Ac27ndnqVTomr8c4SDKU7QQeVW39rw== Message-ID: <8D3D17ACE214DC429325B2B98F3AE7120E11489D@MX15A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: [mile] draft-montville-mile-enum-reference-format-00.txt - formats 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, 05 Nov 2012 21:38:26 -0000 Hi Adam, This draft is a good start - it effectively describes the approach to this area and should make an important contribution to clarity. I apologize for not being able to take a look at it until just before the meeting tomorrow (and also that I will not be in Atlanta until Wednesday of this week). As has also been pointed out in some other comments, the draft doesn't say much about the format of id_type and id. This email is about formats - I'll send another email about versions, and I have some editorial comments that I'll send to you directly. All the id_type examples in the draft are three letter acronyms, but there's nothing there to stop someone from trying to use a 100-character id_type (yes, 100 characters would be ridiculous, but that's precisely the concern - the draft should provide guidance about what's reasonable, and requirements as appropriate). Kathleen's earlier concern about allowed characters in id applies to id_type - for example, the character ':' has to be prohibited in id_type because that character is used as a separator between id_type and id, and XML escapes have to be used if their equivalents are allowed (e.g. "<" instead of '<'). I also share Kathleen's concern that the format of the id needs precise specification for each id_type, but I have a different approach to suggest. For the example in the draft, "CXI:CXI-1234-XYZ", "CXI-1234-XYZ" is the id. I'd suggest that the format of that id be the format of CXI enumeration strings as specified in the CXI specification in the IANA registry entry for the "CXI" id_type. Leaving those enumeration formats to the referenced specifications should result in more flexibility and reuse of formats, although we probably should guide the Designated Expert to check that each specification does effectively specify its enumeration format. Would it help to have the registry record where each enumeration format is specified in the referenced specification (e.g., by section number)? What do other people think, especially about where to specify enumeration string formats? Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-778= 6 david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 ---------------------------------------------------- From david.black@emc.com Mon Nov 5 13:44:55 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 7A4EF21F875C for ; Mon, 5 Nov 2012 13:44:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.099 X-Spam-Level: X-Spam-Status: No, score=-103.099 tagged_above=-999 required=5 tests=[AWL=-0.500, 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 cOqblSDo-yDZ for ; Mon, 5 Nov 2012 13:44:55 -0800 (PST) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id C0E0C21F86E4 for ; Mon, 5 Nov 2012 13:44:53 -0800 (PST) Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id qA5Limor031600 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 5 Nov 2012 16:44:51 -0500 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.129]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor) for ; Mon, 5 Nov 2012 16:44:37 -0500 Received: from mxhub01.corp.emc.com (mxhub01.corp.emc.com [10.254.141.103]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id qA5Liam5026044 for ; Mon, 5 Nov 2012 16:44:36 -0500 Received: from mx15a.corp.emc.com ([169.254.1.83]) by mxhub01.corp.emc.com ([10.254.141.103]) with mapi; Mon, 5 Nov 2012 16:44:35 -0500 From: "Black, David" To: "mile@ietf.org" Date: Mon, 5 Nov 2012 16:44:34 -0500 Thread-Topic: draft-montville-mile-enum-reference-format-00.txt - spec versions Thread-Index: Ac27nr6U5EWTA6R3TsGU9XzPNMrTaw== Message-ID: <8D3D17ACE214DC429325B2B98F3AE7120E1148A4@MX15A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: [mile] draft-montville-mile-enum-reference-format-00.txt - spec versions 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, 05 Nov 2012 21:44:55 -0000 Hi Adam, I concur with Take's concern that different versions of the same specification may or may not be able to share an enumeration format, and hence may or may not be able to share a registered id_type. We could leave this decision about id_type sharing among spec version to the Designated Expert with suitable guidance about compatibility among versions that share an id_type. One baseline rule to start with is that any change to the id format that could cause a parser for the old format to not correctly parse an id in the new format MUST use a different id_type string (for example, suppose that CXI versions 1.0, 1.1, 1.2 and 1.2.1 use the same id format, but a completely new and incompatible id format was introduced in CXI version 2.0 - we might have registry entries for CXI and CXI2). For each id_type, the registry could list the spec versions that use that id_type. This could get verbose if every version includes a name, link and citable reference in the registry, so perhaps the registry could contain full details for only the latest version (including its version number), plus a list of other versions that use the same format. Does that sound reasonable? Are the specifications for these enumerations revised often enough that a list of spec versions for each id_type helps? In addition, I suspect (unfortunately) that something will need to be said about Unicode characters in id (and id_type). I'll defer to others (e.g., Take) as to whether we can get away with an ASCII-only restriction, although I'm skeptical that ASCII will suffice. OTOH, Kathleen's already pointed out that the Unicode considerations in RFC 5070 (IODEF) need work, so perhaps some of what's needed for Unicode considerations can be left to the effort to revise RFC 5070. Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-778= 6 david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 ---------------------------------------------------- From trammell@tik.ee.ethz.ch Tue Nov 6 03:43: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 B442421F8846 for ; Tue, 6 Nov 2012 03:43:53 -0800 (PST) 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=[AWL=0.000, 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 v6dA8GS4Fagm for ; Tue, 6 Nov 2012 03:43:53 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id E051521F8842 for ; Tue, 6 Nov 2012 03:43:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 876FBD9315 for ; Tue, 6 Nov 2012 12:43:51 +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 WBfs4wXKeg5f for ; Tue, 6 Nov 2012 12:43:51 +0100 (MET) Received: from dhcp-447b.meeting.ietf.org (dhcp-447b.meeting.ietf.org [130.129.68.123]) (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 131D2D9310 for ; Tue, 6 Nov 2012 12:43:50 +0100 (MET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Brian Trammell In-Reply-To: <24A28E9E-B605-4B32-B182-0E1C577A9D5C@tik.ee.ethz.ch> Date: Tue, 6 Nov 2012 06:43:50 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <3670C9C5-47E4-4476-9413-4669D955754B@tik.ee.ethz.ch> References: <24A28E9E-B605-4B32-B182-0E1C577A9D5C@tik.ee.ethz.ch> To: mile@ietf.org X-Mailer: Apple Mail (2.1499) Subject: Re: [mile] MILE Agenda, Tuesday 6 November 2012 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, 06 Nov 2012 11:43:54 -0000 Greetings, all, Due to what I can only assume is an insufficient understanding of = geography on my part, I somehow accidentally placed Atlanta in the US = Central Standard Time Zone in the note for remote participants in the = previous revision of the agenda. The correct time (UTC) for today's = meeting is 20:20 - 21:50. Apologies for any confusion or inconvenience = or error this may cause. (Thanks to David Black for pointing this out!) The updated agenda is posted below. Best regards, Brian =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Managed Incident Lightweight Exchange (mile) Working Group Agenda for IETF 85, Atlanta Tuesday 6 November 2012, 15:20 - 16:50 Salon E =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Chairs: Kathleen Moriarty Brian Trammell AGENDA: 1. Agenda-bashing and WG status =3D 30 min Call for Participation: IODEF-bis / IODEF Guidance Survey Charter and Milestone Review 2. Active WG documents =3D 20 min IODEF-extension to support structured cybersecurity information draft-ietf-mile-sci (T. Takahashi) 3. Individual Drafts =3D 40 min IODEF Enumeration Reference Format draft-montville-mile-enum-reference-format (A. Montville) Resource-Oriented Lightweight Indicator Exchange draft-field-mile-rolie (J. Field) Remote participation is available via Meetecho=20 http://ietf85.conf.meetecho.com/ Remote participants, please note that the meeting takes place in UTC-5, i.e. from 20:20 to 21:50 UTC. Presentation slides will be available at https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=3D85= (search for MILE in the Security Area) From internet-drafts@ietf.org Tue Nov 6 11:19:19 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 6753721F89B5; Tue, 6 Nov 2012 11:19:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tpf9zKOkqajA; Tue, 6 Nov 2012 11:19:18 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0E7321F8772; Tue, 6 Nov 2012 11:19:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.35 Message-ID: <20121106191918.30554.52991.idtracker@ietfa.amsl.com> Date: Tue, 06 Nov 2012 11:19:18 -0800 Cc: mile@ietf.org Subject: [mile] I-D Action: draft-ietf-mile-grc-exchange-01.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, 06 Nov 2012 19:19:19 -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 : GRC Report Exchange Author(s) : Kathleen M. Moriarty Said Tabet David Waltermire Filename : draft-ietf-mile-grc-exchange-01.txt Pages : 68 Date : 2012-11-06 Abstract: Governance, risk, and compliance (GRC) programs provide oversight (governance) of risks and compliance initiatives within an organization. GRC reports are increasingly provided in an XML format. This specification defines a common method to securely transport GRC and other XML reports. The defined messaging capability provides policy options and markings in an XML schema, options for confidentiality at the document/report level, and security for the end-to-end communication. XML reports may be shared between service providers and clients, enterprises, or within enterprises. Reports may also be exchanged for official purposes such as business report filings, compliance report filings, and the handling of legal incidents (eWarrant, eDiscovery, etc.) This work is a generalized format derived from the secure exchange of incident information defined by RFC6545, Real-time Inter-network Defense (RID). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mile-grc-exchange There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mile-grc-exchange-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mile-grc-exchange-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From trammell@tik.ee.ethz.ch Tue Nov 6 11:27:05 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 27B8B21F85C0 for ; Tue, 6 Nov 2012 11:27:05 -0800 (PST) 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=[AWL=0.000, 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 MBYpzvaVlytx for ; Tue, 6 Nov 2012 11:27:04 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 4E9B321F851C for ; Tue, 6 Nov 2012 11:27:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 654B6D9314 for ; Tue, 6 Nov 2012 20:27:03 +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 0HBd3j2zXs9J for ; Tue, 6 Nov 2012 20:27:03 +0100 (MET) Received: from dhcp-549e.meeting.ietf.org (dhcp-549e.meeting.ietf.org [130.129.84.158]) (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 EC4F6D9312 for ; Tue, 6 Nov 2012 20:27:02 +0100 (MET) From: Brian Trammell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <168C00E5-932E-4C52-8C85-222B2F4BAFC2@tik.ee.ethz.ch> Date: Tue, 6 Nov 2012 14:27:02 -0500 To: "mile@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [mile] Call for note-takers 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, 06 Nov 2012 19:27:05 -0000 Greetings, all, Is there anyone here in Atlanta who would volunteer to take notes at the = MILE WG meeting, or to make their notes available for the chairs for the = minutes? Please let us know at mile-chairs@tools.ietf.org. Many thanks in advance, Brian= From amontville@tripwire.com Wed Nov 7 09:32:41 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 5C56821F8C80 for ; Wed, 7 Nov 2012 09:32:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[AWL=-1.501, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 IvDktINL7woA for ; Wed, 7 Nov 2012 09:32:40 -0800 (PST) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe004.messaging.microsoft.com [213.199.154.142]) by ietfa.amsl.com (Postfix) with ESMTP id 18FDC21F8C3D for ; Wed, 7 Nov 2012 09:32:40 -0800 (PST) Received: from mail13-db3-R.bigfish.com (10.3.81.252) by DB3EHSOBE002.bigfish.com (10.3.84.22) with Microsoft SMTP Server id 14.1.225.23; Wed, 7 Nov 2012 17:32:38 +0000 Received: from mail13-db3 (localhost [127.0.0.1]) by mail13-db3-R.bigfish.com (Postfix) with ESMTP id A2FF8300321 for ; Wed, 7 Nov 2012 17:32:38 +0000 (UTC) X-Forefront-Antispam-Report: CIP:174.47.84.215; KIP:(null); UIP:(null); IPV:NLI; H:zgw01.tripwire.com; RD:174-47-84-215.static.twtelecom.net; EFVD:NLI X-SpamScore: -27 X-BigFish: VPS-27(zz9f17Rc85fh1415Izz1de0h1202h1d1ah1d2ahz31iz1033IL17326ah8275bh8275dhz2dh2a8h668h839hd25he5bhf0ah1288h12a5h12bdh137ah1441h14ddh1504h1537h153bhbe3k1155h) Received: from mail13-db3 (localhost.localdomain [127.0.0.1]) by mail13-db3 (MessageSwitch) id 1352309555963033_9180; Wed, 7 Nov 2012 17:32:35 +0000 (UTC) Received: from DB3EHSMHS002.bigfish.com (unknown [10.3.81.248]) by mail13-db3.bigfish.com (Postfix) with ESMTP id E96A926004A for ; Wed, 7 Nov 2012 17:32:35 +0000 (UTC) Received: from zgw01.tripwire.com (174.47.84.215) by DB3EHSMHS002.bigfish.com (10.3.87.102) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 7 Nov 2012 17:32:32 +0000 Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.tripwire.com (Proprietary) with SMTP id 514A02321219 for ; Wed, 7 Nov 2012 09:23:51 -0800 (PST) Received: from PDXED01.tripwire.com (unknown [192.168.192.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by zgw01.tripwire.com (Proprietary) with ESMTPS id B2C2423211D5 for ; Wed, 7 Nov 2012 09:23:50 -0800 (PST) Received: from PDXHB01.tripwire.com (172.30.0.53) by PDXED01.tripwire.com (192.168.192.5) with Microsoft SMTP Server (TLS) id 14.1.379.0; Wed, 7 Nov 2012 09:36:43 -0800 Received: from PDXMB02.tripwire.com ([fe80::f997:7b65:8e64:438e]) by PDXHB01.tripwire.com ([fe80::d495:98d2:7df4:2154%11]) with mapi id 14.01.0379.000; Wed, 7 Nov 2012 09:32:29 -0800 From: Adam Montville To: "" Thread-Topic: Updated IODEF Enumeration Reference Format Draft Thread-Index: AQHNvQ3c5igWirSip0ScCVgUmvLL1A== Date: Wed, 7 Nov 2012 17:32:28 +0000 Message-ID: <18EDCB49-399F-44DC-BF11-9A77F3E459FC@tripwire.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.16.97.75] x-exclaimer-md-config: 79afcaa7-fdf4-4fa6-abe0-afeaa4640a4f Content-Type: multipart/alternative; boundary="_000_18EDCB49399F44DCBF119A77F3E459FCtripwirecom_" MIME-Version: 1.0 X-VPM-MSG-ID: d6759f93-b289-49b6-be42-84c9c255fd74 X-VPM-HOST: zgw01.tripwire.com X-VPM-ENC-REGIME: Plaintext X-VPM-CERT-FLAG: 0 X-VPM-IS-HYBRID: 0 X-OriginatorOrg: tripwire.com Subject: [mile] Updated IODEF Enumeration Reference Format Draft 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, 07 Nov 2012 17:32:41 -0000 --_000_18EDCB49399F44DCBF119A77F3E459FCtripwirecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All: I'm pleased to submit draft-montville-mile-enum-reference-format-01 availab= le at http://www.ietf.org/id/draft-montville-mile-enum-reference-format-01.txt Changes: * IANA Table Request Changes * Removed "Name" * Added "Full Name * Added "Abbreviation" * Specified id_type to be _ * Reviewed text for scope statements and limited scope to IODEF, while = alluding to the method's potential usefulness elsewhere. * Ensured that the Reference class diagram is explicitly referenced as = [IODEF]. * Updated IANA Considerations to request creation of the table * Updated IANA table format fields with simple descriptions I look forward to your comments. Regards, Adam W. Montville | Security and Compliance Architect CISA, CISSP Direct: 503 276-7661 Mobile: 360 471-7815 TRIPWIRE | Take CONTROL http://www.tripwire.com --_000_18EDCB49399F44DCBF119A77F3E459FCtripwirecom_ Content-Type: text/html; charset="us-ascii" Content-ID: <1FCA987A09A7454CA8035A3D7CD1E554@tripwire.com> Content-Transfer-Encoding: quoted-printable All:

I'm pleased to submit draft-montville-mile-enum-reference-format-01 av= ailable at


Changes:

  • IANA Table Request Changes
    • Removed "Name"
    • Added "Full Name
    • Added &q= uot;Abbreviation"
  • Specified id_type to be <Abbreviation>_<Version>
    • <= li>Reviewed text for scope statements and limited scope to IODEF, while all= uding to the method's potential usefulness elsewhere.
  • Ensured that = the Reference class diagram is explicitly referenced as [IODEF].
  • Up= dated IANA Considerations to request creation of the table
  • Updated = IANA table format fields with simple descriptions


I look forward to your comments.

Regards,

Adam W. Montville | Security and Compliance Architect
CISA, CISSP

Direct: 503 276-7661
Mobile: 360 471-7815

TRIPWIRE | Take CONTROL






--_000_18EDCB49399F44DCBF119A77F3E459FCtripwirecom_-- From amontville@tripwire.com Wed Nov 7 10:08:24 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 DAFB021F8A7F for ; Wed, 7 Nov 2012 10:08:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.348 X-Spam-Level: X-Spam-Status: No, score=-4.348 tagged_above=-999 required=5 tests=[AWL=-0.750, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 IfdWDHSF+shL for ; Wed, 7 Nov 2012 10:08:24 -0800 (PST) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe002.messaging.microsoft.com [216.32.180.185]) by ietfa.amsl.com (Postfix) with ESMTP id 2490221F887F for ; Wed, 7 Nov 2012 10:08:23 -0800 (PST) Received: from mail194-co1-R.bigfish.com (10.243.78.251) by CO1EHSOBE011.bigfish.com (10.243.66.74) with Microsoft SMTP Server id 14.1.225.23; Wed, 7 Nov 2012 18:08:16 +0000 Received: from mail194-co1 (localhost [127.0.0.1]) by mail194-co1-R.bigfish.com (Postfix) with ESMTP id 47E93480129 for ; Wed, 7 Nov 2012 18:08:16 +0000 (UTC) X-Forefront-Antispam-Report: CIP:174.47.84.215; KIP:(null); UIP:(null); IPV:NLI; H:zgw01.tripwire.com; RD:174-47-84-215.static.twtelecom.net; EFVD:NLI X-SpamScore: -19 X-BigFish: VPS-19(zf7Iz9371I936eIc85fhzz1de0h1202h1d1ah1d2ahz31iz1033IL17326ah8275bh8275dhz2dh2a8h668h839hd25he5bhf0ah1288h12a5h12bdh137ah1441h14ddh1504h1537h153bhbe3k1155h) Received: from mail194-co1 (localhost.localdomain [127.0.0.1]) by mail194-co1 (MessageSwitch) id 1352311694476502_21286; Wed, 7 Nov 2012 18:08:14 +0000 (UTC) Received: from CO1EHSMHS031.bigfish.com (unknown [10.243.78.236]) by mail194-co1.bigfish.com (Postfix) with ESMTP id 681BAB00047 for ; Wed, 7 Nov 2012 18:08:14 +0000 (UTC) Received: from zgw01.tripwire.com (174.47.84.215) by CO1EHSMHS031.bigfish.com (10.243.66.41) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 7 Nov 2012 18:08:03 +0000 Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.tripwire.com (Proprietary) with SMTP id 09992232124A for ; Wed, 7 Nov 2012 09:59:23 -0800 (PST) Received: from PDXED01.tripwire.com (unknown [192.168.192.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by zgw01.tripwire.com (Proprietary) with ESMTPS id 6CA0A2321219 for ; Wed, 7 Nov 2012 09:59:22 -0800 (PST) Received: from PDXHB01.tripwire.com (172.30.0.53) by PDXED01.tripwire.com (192.168.192.5) with Microsoft SMTP Server (TLS) id 14.1.379.0; Wed, 7 Nov 2012 10:12:15 -0800 Received: from PDXMB02.tripwire.com ([fe80::f997:7b65:8e64:438e]) by PDXHB01.tripwire.com ([fe80::d495:98d2:7df4:2154%11]) with mapi id 14.01.0379.000; Wed, 7 Nov 2012 10:08:01 -0800 From: Adam Montville To: "" Thread-Topic: New Version Notification for draft-montville-mile-enum-reference-format-01.txt Thread-Index: AQHNvQ0+mKpsZ5KQU0+6EXxVAfQOlg== Date: Wed, 7 Nov 2012 18:08:00 +0000 Message-ID: <3D3E6E17-E033-4728-B48F-8F7C34B3F996@tripwire.com> References: <20121107172759.9166.52712.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.16.97.57] x-exclaimer-md-config: 79afcaa7-fdf4-4fa6-abe0-afeaa4640a4f Content-Type: multipart/alternative; boundary="_000_3D3E6E17E0334728B48F8F7C34B3F996tripwirecom_" MIME-Version: 1.0 X-VPM-MSG-ID: 8972607a-cd4c-471b-95b8-fc43a29a9ec7 X-VPM-HOST: zgw01.tripwire.com X-VPM-ENC-REGIME: Plaintext X-VPM-CERT-FLAG: 0 X-VPM-IS-HYBRID: 0 X-OriginatorOrg: tripwire.com Subject: [mile] Fwd: New Version Notification for draft-montville-mile-enum-reference-format-01.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, 07 Nov 2012 18:08:25 -0000 --_000_3D3E6E17E0334728B48F8F7C34B3F996tripwirecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Here is the full response to posting the 01 draft for IODEF Enum Ref Format= . Begin forwarded message: From: > Subject: New Version Notification for draft-montville-mile-enum-reference-f= ormat-01.txt Date: November 7, 2012 12:27:59 PM EST To: > A new version of I-D, draft-montville-mile-enum-reference-format-01.txt has been successfully submitted by Adam W. Montville and posted to the IETF repository. Filename: draft-montville-mile-enum-reference-format Revision: 01 Title: IODEF Enumeration Reference Format Creation date: 2012-11-06 WG ID: Individual Submission Number of pages: 6 URL: http://www.ietf.org/internet-drafts/draft-montville-mile-e= num-reference-format-01.txt Status: http://datatracker.ietf.org/doc/draft-montville-mile-enum-= reference-format Htmlized: http://tools.ietf.org/html/draft-montville-mile-enum-refer= ence-format-01 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-montville-mile-en= um-reference-format-01 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 a method to provide structure after the fact for [IODEF]. The IETF Secretariat --_000_3D3E6E17E0334728B48F8F7C34B3F996tripwirecom_ Content-Type: text/html; charset="us-ascii" Content-ID: <8E6E302AE2493749879822BAE142576B@tripwire.com> Content-Transfer-Encoding: quoted-printable
Here is the full response to posting the 01 draft for IODEF Enum Ref F= ormat.


Begin forwarded message:

From: <<= a href=3D"mailto:internet-drafts@ietf.org">internet-drafts@ietf.org>=
Subject: Ne= w Version Notification for draft-montville-mile-enum-reference-format-01.tx= t
Date: Novem= ber 7, 2012 12:27:59 PM EST
To: <<= a href=3D"mailto:amontville@tripwire.com">amontville@tripwire.com>


A new version of I-D, draft-montville-mile-enum-reference-format-01.txt
has been successfully submitted by Adam W. Montville and posted to the
IETF repository.

Filename: d= raft-montville-mile-enum-reference-format
Revision: 0= 1
Title: IODEF Enumerati= on Reference Format
Creation date: 2012-11-06
WG ID: Individual Subm= ission
Number of pages: 6
URL:            &nbs= p;http://www.ietf.org/internet-drafts/draft-montvill= e-mile-enum-reference-format-01.txt
Status:          h= ttp://datatracker.ietf.org/doc/draft-montville-mile-enum-reference-format
Htmlized:        http://tools.= ietf.org/html/draft-montville-mile-enum-reference-format-01
Diff:            http://www.ietf.org/rfcdiff?url2=3Ddraft-montville-mile-enum= -reference-format-01

Abstract:
  Some standards, such as the Incident Object Description Exchang= e
  Format [IODEF], provide classes used to reference external enti= ties
  (such as enumeration identifiers).  At the time of standar= dization,
  however, needed references may not be known, and the method of<= br>   external entity identification is often left unstructured. &nbs= p;This
  document describes a method to provide structure after the fact= for
  [IODEF].





The IETF Secretariat



--_000_3D3E6E17E0334728B48F8F7C34B3F996tripwirecom_-- From trammell@tik.ee.ethz.ch Fri Nov 9 06:01: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 1440921F853B for ; Fri, 9 Nov 2012 06:01:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.577 X-Spam-Level: X-Spam-Status: No, score=-6.577 tagged_above=-999 required=5 tests=[AWL=0.022, 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 X9AMcLsHvJte for ; Fri, 9 Nov 2012 06:01:47 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 148FD21F853A for ; Fri, 9 Nov 2012 06:01:47 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 3203CD9308 for ; Fri, 9 Nov 2012 15:01:46 +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 FUT0kjwUVlG9 for ; Fri, 9 Nov 2012 15:01:45 +0100 (MET) Received: from dhcp-549e.meeting.ietf.org (dhcp-549e.meeting.ietf.org [130.129.84.158]) (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 AE800D9305 for ; Fri, 9 Nov 2012 15:01:45 +0100 (MET) From: Brian Trammell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <3830EDC8-5A05-4646-B073-AE5367003B22@tik.ee.ethz.ch> Date: Fri, 9 Nov 2012 09:01:44 -0500 To: "mile@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [mile] Minutes 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, 09 Nov 2012 14:01:48 -0000 Greetings, all, Draft minutes from our meeting on Tuesday are available at = http://www.ietf.org/proceedings/85/minutes/minutes-85-mile; please let = us know if there are any omissions or errors. Best regards, Brian= From ietf@meetecho.com Fri Nov 9 09:07:08 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 E21EE21F8780 for ; Fri, 9 Nov 2012 09:07:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 TmH46dQcQnZJ for ; Fri, 9 Nov 2012 09:07:08 -0800 (PST) Received: from smtpdg7.aruba.it (smtpdg7.aruba.it [62.149.158.237]) by ietfa.amsl.com (Postfix) with ESMTP id 5F0FB21F8789 for ; Fri, 9 Nov 2012 09:07:08 -0800 (PST) Received: from [130.129.19.11] ([130.129.19.11]) by smtpcmd03.ad.aruba.it with bizsmtp id MV761k00J0ELJoa01V769e; Fri, 09 Nov 2012 18:07:07 +0100 Message-ID: <509D3838.5030808@meetecho.com> Date: Fri, 09 Nov 2012 18:07:04 +0100 From: Meetecho IETF support User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: "" Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: [mile] Meetecho session recording 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, 09 Nov 2012 17:07:09 -0000 Dear all, the full recording (synchronized video, audio, slides and jabber room) of this WG session at IETF-85 is available. You can watch it by accessing the following URL: http://www.meetecho.com/ietf85/recordings For the chair(s): please feel free to put the link to the recording in the minutes, if you think this might be useful. In case of problems with the playout, just drop an e-mail to ietf-team@meetecho.com. Cheers, the Meetecho team -- Meetecho s.r.l. Web Conferencing and Collaboration Tools www.meetecho.com From chatlga2000@yahoo.com Wed Nov 14 17:17: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 D29E221F8609 for ; Wed, 14 Nov 2012 17:17:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] 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 whhq5+wKhvgg for ; Wed, 14 Nov 2012 17:17:28 -0800 (PST) Received: from nm17-vm2.bullet.mail.ne1.yahoo.com (nm17-vm2.bullet.mail.ne1.yahoo.com [98.138.91.93]) by ietfa.amsl.com (Postfix) with ESMTP id 28BC221F8542 for ; Wed, 14 Nov 2012 17:17:28 -0800 (PST) Received: from [98.138.90.50] by nm17.bullet.mail.ne1.yahoo.com with NNFMP; 15 Nov 2012 01:17:25 -0000 Received: from [98.138.89.167] by tm3.bullet.mail.ne1.yahoo.com with NNFMP; 15 Nov 2012 01:17:25 -0000 Received: from [127.0.0.1] by omp1023.mail.ne1.yahoo.com with NNFMP; 15 Nov 2012 01:17:25 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 49777.95782.bm@omp1023.mail.ne1.yahoo.com Received: (qmail 32622 invoked by uid 60001); 15 Nov 2012 01:17:25 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1352942244; bh=W7SvpUhUbNqCzg3SnV/ZVqdaxhvMphEp+cXJLJbJz9k=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=uhowrx+1/SFBFEwORY2jFUcKS60HNB4L/w0oQ8reNr3MQB/siIrW7N/GGlFX6l0JZacqdKNP1yGWckZnqNmqhqDKRsMnUCcbuvGbPA8WzIx6NyLLOj4qMjN0PsxLkIMy3QmRlMHAT9yjefPOMG5SEpeVxBuVpSN8peq+WzgC6Fo= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=h3FwXmFB3K1MgzEw8kSDFvNY6HlekB1qZfr4vPvk+8TfpQpgXXijkdOwf5GEeqpUEkRAJJJCNmjrt50T2q59nWZ9NnEd+VoDWPW5LKeWJ7aGxH2c8JFo8fb3fMi43INgVP1AkBG1w5/E802G4mO3Vs96lrDOCqglRVrKpfcqT0E=; X-YMail-OSG: i674n5IVM1kDPUuVhUWUt6GVeW9BvNBrQnkNBb.U1P.tV1T 5g0gWVyGweeZeRpFGrxX4pkofGeEThHyTUkRAPKMn91koWFHndb1pNLByVUq WdMVAnxmEZo1JGHUqNm67l89SSOipzRPhiWniZhgCVgjp7eFkJXZeMf85FQ8 6yKwwNhijdfdfMM4OrRzhAi9qxMO7b5w.UUSUdvAfEyCxfo.WnXC7rHrVLtt J1c49Ohdwtdddefb6JY_FueHlrLdOwhn9scHfrrk9WGL9CdbXI1aIdh9BWk0 ePmcdnCblbFqx08qS54LCPY8tZkK_CZX7UdZQK_jveZDwc2MoUcWHrEIF_BU gVpRfknNaVjh89NDKQF5B_C3OueZbLViKGr.5cmLs29VrC4pwkHO2R91yGxe mklmuEykUdtCILFhVrvnWMw4QOzgUY5Qdgh6_6wIjwGxeqnSSUQVwwDvJeyv 1UhzguQ1puZnBwjlAxyKMQfuhulR96ow0vLHAUg3UorfZhIWqkvrb8Q-- Received: from [166.204.192.120] by web121603.mail.ne1.yahoo.com via HTTP; Wed, 14 Nov 2012 17:17:24 PST X-Rocket-MIMEInfo: 001.001, UmV2aWV3aW5nIHRoZSBHUkMgRXhjaGFuZ2UgRG9jdW1lbnQsIEkgaWRlbnRpZmllZCB3aXRoIHdoYXQgYXBwZWFycyB0byBiZSBhIGRlc2NyaXB0aW9uIG9mIFhNTCBzdHJpbmdzIGluIFNlY3Rpb24gMy7CoMKgIFNob3VsZCB0aGUgdGVybSAiU3RyaW5nIG9yIFN0cmluZ3MiIGZvbGxvdyB0aGUgd29yZHMgaW4gc3Vic2VjdGlvbnMgMy40LjcgwqAgRXhhbXBsZSAoMy40LjcuICBQb3N0YWwgQWRkcmVzcyBTdHJpbmcpICwgMy40LjggRXhhbXBsZSAoMy40LjguICBUZWxlcGhvbmUgYW5kIEZheCBOdW1iZXJzIFMBMAEBAQE- X-Mailer: YahooMailClassic/15.0.8 YahooMailWebService/0.8.123.460 Message-ID: <1352942244.31359.YahooMailClassic@web121603.mail.ne1.yahoo.com> Date: Wed, 14 Nov 2012 17:17:24 -0800 (PST) From: "C. Henry Adams & BIE" To: mile@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1682663710-185222297-1352942244=:31359" Cc: "C. Henry Adams" Subject: [mile] GRC Report Exchange draft-ietf-mile-grc-exchange-01.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, 15 Nov 2012 01:17:29 -0000 ---1682663710-185222297-1352942244=:31359 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Reviewing the GRC Exchange Document, I identified with what appears to be a= description of XML strings in Section 3.=A0=A0 Should the term "String or = Strings" follow the words in subsections 3.4.7 =A0 Example (3.4.7. Postal = Address String) , 3.4.8 Example (3.4.8. Telephone and Fax Numbers String) = (OR)=A0 should defining specific "strings" be a subsection in itself of=A0 = the Language Type "Strings" which represent a sequence of elements utilized= by XML? =A0 C. Henry Adams =0Achatlga2000@yahoo.com (Direct Email) =0A =0A =0A ---1682663710-185222297-1352942244=:31359 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Reviewing the GRC Exchange Document, I identi= fied with what appears to be a description of XML strings in Section 3.&nbs= p;  Should the term "String or Strings" follow the words in subsection= s 3.4.7   Example (3.4.7. Postal Address String) , 3.4.8 Example (3.4.8. Telephone and Fax Numbe= rs String) (OR)  should defining specific "strings" be a subsec= tion in itself of  the Language Type "Strings" which represent a seque= nce of elements utilized by XML?
 
C. Henry Adams
=0Achatlga2= 000@yahoo.com (Direct Email)
=0A
=0A
=0A
---1682663710-185222297-1352942244=:31359-- From chatlga2000@yahoo.com Wed Nov 14 17:41:13 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 0274C21F8565 for ; Wed, 14 Nov 2012 17:41:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_50=0.001, GB_I_LETTER=-2, HTML_MESSAGE=0.001] 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 hpmH3W-6tXUF for ; Wed, 14 Nov 2012 17:41:12 -0800 (PST) Received: from nm25-vm0.bullet.mail.ne1.yahoo.com (nm25-vm0.bullet.mail.ne1.yahoo.com [98.138.91.73]) by ietfa.amsl.com (Postfix) with ESMTP id 2EA0121F8564 for ; Wed, 14 Nov 2012 17:41:12 -0800 (PST) Received: from [98.138.226.178] by nm25.bullet.mail.ne1.yahoo.com with NNFMP; 15 Nov 2012 01:39:01 -0000 Received: from [98.138.89.254] by tm13.bullet.mail.ne1.yahoo.com with NNFMP; 15 Nov 2012 01:39:00 -0000 Received: from [127.0.0.1] by omp1046.mail.ne1.yahoo.com with NNFMP; 15 Nov 2012 01:39:00 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 902235.7221.bm@omp1046.mail.ne1.yahoo.com Received: (qmail 56000 invoked by uid 60001); 15 Nov 2012 01:39:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1352943540; bh=MzNw20sRs2o3Qn8Nq6J9tDWJ/RYjAEbB2ORdXuV4maE=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=QSYc9uX3SJ44xEIVemgKkVhYtA+Bv7tcpSxCszeFA5PWSH3HooHlctUw4ul0YOX9GfMLSWIeMU6pU8Rihn37atnwdCTTVFyQVgozT1ulKBZwPAO0nS7wlknBVLYiz+qfO7bfSRe3k9A4g7u4s84KleoGtUtphp2uMXf7DNAMmWg= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=1j8Ii2+R+aW9qEnsN+7gMByzGYBJzd3hpz/Gt/Omy0prKApm+v6eN01Ey5gA6FKP1eBpl4IX/w7k6ChZVzqk5HZLxhc4F8Hk8OwguR7ch+5IgoGxwGac6mNdaB4FeSehQtBkXBab4cDoWqgEDLevYcfNTlS8Vq7L22MMEg/DIv4=; X-YMail-OSG: zfPUNjUVM1mQ9ftaOSEyPpHLRYse_sH29vyCXOdn8H.0pJX _p1C0UlI1bC8spVIRg1mUEYHC3UcY7PC1xfp3F4H7G_.Ik5SCHtUBOFCFg8u DbAKW7VmjpiCC5LMbvPgepNHxH0GT091.6y.9Nn0gXBnPi4zDOIqmFCpLiY6 V0W5JVtLMqGm2KYuqk82DQdNg7NKMsUYa9fgC28DI3oJlljMAWRHXk6lLIQt wyQS_YJM8VHTk0rFZh_29PgE.Jx_hsGxgXoOFWaxQKfn6GELzQ_OE_5vlzyf CytkjmdCZWTescq3cNkdTCKa4D9ll0SLDF_LuknFCful7ig5An0ZcrgjKZ_y 1cVahYs18BJIrE2XF2I1xQNO.aXd5qxkMoXOvkNECYAAK7kzTlavwlUYvR2x oTlD3IudLK_CNV05bpgFziDFEhUTBU9por7BmG5yUcbrfr2IqIHmRvVhewmC M_8ckKxg0xiEfjzm.8N2m82CLXIERRN08PfMEg.qnagaR9ObjL_41XrDlM9s SETZAx_3jWL2Eue6f Received: from [166.204.192.120] by web121603.mail.ne1.yahoo.com via HTTP; Wed, 14 Nov 2012 17:39:00 PST X-Rocket-MIMEInfo: 001.001, SXQgaXMgc3RhdGVkLCAiVGhlIEdSQ1BvbGljeSBjbGFzcyBoYXMgc2l4IGF0dHJpYnV0ZXM6IiBsb2NhdGVkIGluIHNlY3Rpb27CoDQuMS4gIEdSQ1BvbGljeSBDbGFzcyBDb3VsZCB0aGUgZm9sbG93aW5nIGF0dHJpYnV0ZXMgYmUgaWRlbnRpZmllZCBieSBhIGxldHRlciBvciBudW1iZXI_DQoNCjEuIHJlc3RyaWN0aW9uDQoyLiBleHQtcmVzdHJpY3Rpb24NCjMuIE1zZ1R5cGUNCjQuIGV4dC1Nc2dUeXBlDQo1LiBNc2dEZXN0aW5hdGlvbg0KNi4gZXh0LU1zZ0Rlc3RpbmF0aW9uDQoNCsKgIA0KQy4gSGVucnkBMAEBAQE- X-Mailer: YahooMailClassic/15.0.8 YahooMailWebService/0.8.123.460 Message-ID: <1352943540.53229.YahooMailClassic@web121603.mail.ne1.yahoo.com> Date: Wed, 14 Nov 2012 17:39:00 -0800 (PST) From: "C. Henry Adams & BIE" To: mile@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1682663710-1699046188-1352943540=:53229" Cc: "C. Henry Adams" Subject: [mile] Fw: GRC Report Exchange draft-ietf-mile-grc-exchange-01.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, 15 Nov 2012 01:41:13 -0000 ---1682663710-1699046188-1352943540=:53229 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable It is stated, "The GRCPolicy class has six attributes:" located in section= =A04.1. GRCPolicy Class Could the following attributes be identified by a = letter or number? 1. restriction 2. ext-restriction 3. MsgType 4. ext-MsgType 5. MsgDestination 6. ext-MsgDestination =A0=20 C. Henry Adams =0Achatlga2000@yahoo.com (Direct Email) =0A --- On Wed, 11/14/12, C. Henry Adams & BIE wrote: From: C. Henry Adams & BIE Subject: GRC Report Exchange draft-ietf-mile-grc-exchange-01.txt To: mile@ietf.org Cc: "C. Henry Adams" Date: Wednesday, November 14, 2012, 8:17 PM Reviewing the GRC Exchange Document, I identified with what appears to be a= description of XML strings in Section 3.=A0=A0 Should the term "String or = Strings" follow the words in subsections 3.4.7 =A0 Example (3.4.7. Postal = Address String) , 3.4.8 Example (3.4.8. Telephone and Fax Numbers String) = (OR)=A0 should defining specific "strings" be a subsection in itself of=A0 = the Language Type "Strings" which represent a sequence of elements utilized= by XML? =A0 C. Henry Adams =0Achatlga2000@yahoo.com (Direct Email) =0A =0A =0A ---1682663710-1699046188-1352943540=:53229 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
It is stated, "The GRCPolicy class has six at= tributes:" located in section 
4.1.  GRCPolicy=
 Class
Could the following attributes be identified by a lette= r or number?

1. restriction
2. ext-restriction
3. MsgType
4= . ext-MsgType
5. MsgDestination
6. ext-MsgDestination

  <= br>C. Henry Adams
=0Achatlga2000@yahoo.com (Direct Email)
=0A

= --- On Wed, 11/14/12, C. Henry Adams & BIE <chatlga2000@yahoo.= com> wrote:

From: C. Henry Adams= & BIE <chatlga2000@yahoo.com>
Subject: GRC Report Exchange d= raft-ietf-mile-grc-exchange-01.txt
To: mile@ietf.org
Cc: "C. Henry Ad= ams" <chatlga2000@yahoo.com>
Date: Wednesday, November 14, 2012, 8= :17 PM

= Reviewing the GRC Exchange Document, I identified with what appears to be a= description of XML strings in Section 3.   Should the term "Stri= ng or Strings" follow the words in subsections 3.4.7   Example (3.4.7. Postal Address String) , 3.4.8 Ex= ample (3.4.8. Telephone and Fax Numbers String) (OR)  should defining specific "strings" be a subsecti= on in itself of  the Language Type "Strings" which represent a sequenc= e of elements utilized by XML?
 
C. Henry Adams
=0Achatlga200= 0@yahoo.com (Direct Email)
=0A
=0A
=0A
---1682663710-1699046188-1352943540=:53229-- From chatlga2000@yahoo.com Wed Nov 14 18:01:11 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 D9E5121F858E for ; Wed, 14 Nov 2012 18:01:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_50=0.001, GB_I_LETTER=-2, HTML_MESSAGE=0.001] 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 vbscvB0dJp2f for ; Wed, 14 Nov 2012 18:01:10 -0800 (PST) Received: from nm33-vm5.bullet.mail.ne1.yahoo.com (nm33-vm5.bullet.mail.ne1.yahoo.com [98.138.229.69]) by ietfa.amsl.com (Postfix) with ESMTP id 8740721E8034 for ; Wed, 14 Nov 2012 18:01:09 -0800 (PST) Received: from [98.138.90.55] by nm33.bullet.mail.ne1.yahoo.com with NNFMP; 15 Nov 2012 02:00:57 -0000 Received: from [98.138.89.168] by tm8.bullet.mail.ne1.yahoo.com with NNFMP; 15 Nov 2012 02:00:57 -0000 Received: from [127.0.0.1] by omp1024.mail.ne1.yahoo.com with NNFMP; 15 Nov 2012 02:00:57 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 491643.28188.bm@omp1024.mail.ne1.yahoo.com Received: (qmail 95741 invoked by uid 60001); 15 Nov 2012 02:00:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1352944857; bh=NQEFJ/8bYC4IiT5jrLZBWFa5SIzobC6ScQs+ZtbX0ME=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=4Xmw+MSwmD8LeXzxCnz5JbTW6RHdfDx9Woms4r16OKwIRM7/6sKpjmJs6lH268ruW2ccyaQ/oOEpucbSE41ZUI6V4PK/vX6VddJHTi6KeH/28eVtK5/jcyaOQ/jt1i/lvD1Uu7sptW0NHD1mPF6KOoSiavmvX/jDlxSKPj8ehek= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=yZe5lp4D2t9XusuaAWhwh15yPXtJh4j/bPaC2P434nPEy9q4X3DqdcK99g+iAHYM+807C4isvMvb92f2XyfCR0fPpO0p09WsqE3M0K3D67W9s2vaS+edZPZpCvJAAMkMyMV7Ejf4vwt1PzmhK0swzu5y+vpj0D0PikQtcBUpc7c=; X-YMail-OSG: 3NoVen4VM1mmV47nK83h4hIkN6rGSJ9w14i9odQMQVwk4qd kkpS5At2bU74lDN0zDe.iWewvWac0UiCqkh63DWNKLMWOHMez1LF08Rt.Pk1 C.IXBiqvRFNVWtQdqhpjFBFwD.3RFYJAptVJjZ3k4b1VTtEHtjBjHPSXotKE WK3XSbQO1hpUJ1y4HUyiKPyuQPIiJSwYrZyqRzGn6fhzQmRK80f5ebYL4v1e WJ9i8sJHDVv1GH15UYPq9RT1D95rVc4ES14O4ek_zRKpFLi2BnfVImrXzc66 O49jyNlRPOUz5vavi.YA4Pvs5qb7bLrAra0CXTi9p9PjkGx2cNxSUcrNwP.Q NFbESM48sOxuJ_niLyPcjX_cSZjY685arecWp1SYQeVrq_ezLrRRcucVE.re QttNol.WKzZ.IKhTMvfA9a_2CxyU58MrrELpgtSa6OWbEoRcpA_yZq6NZ8a0 KApu7SnCKy5JLtdwTSlwYj22thSWAijmsQj4baLQxLOa2oCDP71ZHaGeBUbW pcMb9N7ixOtTgArV8 Received: from [166.204.192.120] by web121605.mail.ne1.yahoo.com via HTTP; Wed, 14 Nov 2012 18:00:56 PST X-Rocket-MIMEInfo: 001.001, UmV2aWV3aW5nIFJGQzQxMTkswqAgd291bGQgYSBHZW9ncmFwaGljYWwgU3RyaW5nIGFkZGVkIG9yIGluc2VydGVkLCBhcyB3ZWxsIGFzLCBjbGFzcyB3aXRoaW4gdGhpcyBkcmFmdCBwb3NzaWJseSBjb25zdGl0dXRlIGEgcG90ZW50aWFsIHNlY3VyaXR5IGNvbmNlcm4gYmV0d2VlbiB0byBHUkMtUkVzIHBlZXJpbmcgdG9nZXRoZXI_DQoNCkkgd291bGQgdGVuZCB0byB0aGluayBpZiBJIHdhbnRlZCB0byBnZXQgcmVwb3J0cyBmcm9tIGRpZmZlcmVudCBvZmZpY2VzIGFyb3VuZCB0aGUgY2l0eSwgc3RhdGUsIGMBMAEBAQE- X-Mailer: YahooMailClassic/15.0.8 YahooMailWebService/0.8.123.460 Message-ID: <1352944856.95690.YahooMailClassic@web121605.mail.ne1.yahoo.com> Date: Wed, 14 Nov 2012 18:00:56 -0800 (PST) From: "C. Henry Adams & BIE" To: MILE IETF MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="2053635335-550172056-1352944856=:95690" Cc: "C. Henry Adams" Subject: [mile] Fw: GRC Report Exchange draft-ietf-mile-grc-exchange-01.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, 15 Nov 2012 02:01:11 -0000 --2053635335-550172056-1352944856=:95690 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Reviewing RFC4119,=A0 would a Geographical String added or inserted, as wel= l as, class within this draft possibly constitute a potential security conc= ern between to GRC-REs peering together? I would tend to think if I wanted to get reports from different offices aro= und the city, state, country or even the global... I would likely want to i= dentify whom is sending or requesting the information. I notice that no Geographical String or Class was added, thus why I ask the= question regarding the security concern. C. Henry Adams =0Achatlga2000@yahoo.com (Direct Email) =0A --- On Wed, 11/14/12, C. Henry Adams & BIE wrote: From: C. Henry Adams & BIE Subject: Fw: GRC Report Exchange draft-ietf-mile-grc-exchange-01.txt To: mile@ietf.org Cc: "C. Henry Adams" Date: Wednesday, November 14, 2012, 8:39 PM It is stated, "The GRCPolicy class has six attributes:" located in section= =A04.1. GRCPolicy Class Could the following attributes be identified by a = letter or number? 1. restriction 2. ext-restriction 3. MsgType 4. ext-MsgType 5. MsgDestination 6. ext-MsgDestination =A0=20 C. Henry Adams =0Achatlga2000@yahoo.com (Direct Email) =0A --- On Wed, 11/14/12, C. Henry Adams & BIE wrote: From: C. Henry Adams & BIE Subject: GRC Report Exchange draft-ietf-mile-grc-exchange-01.txt To: mile@ietf.org Cc: "C. Henry Adams" Date: Wednesday, November 14, 2012, 8:17 PM Reviewing the GRC Exchange Document, I identified with what appears to be a= description of XML strings in Section 3.=A0=A0 Should the term "String or = Strings" follow the words in subsections 3.4.7 =A0 Example (3.4.7. Postal = Address String) , 3.4.8 Example (3.4.8. Telephone and Fax Numbers=0A Strin= g) (OR)=A0 should defining specific "strings" be a subsection in itself of= =A0 the Language Type "Strings" which represent a sequence of elements util= ized by XML? =A0 C. Henry Adams =0Achatlga2000@yahoo.com (Direct Email) =0A =0A =0A --2053635335-550172056-1352944856=:95690 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Reviewing RFC4119,  would a Geographical= String added or inserted, as well as, class within this draft possibly con= stitute a potential security concern between to GRC-REs peering together?
I would tend to think if I wanted to get reports from different offic= es around the city, state, country or even the global... I would likely wan= t to identify whom is sending or requesting the information.

I notic= e that no Geographical String or Class was added, thus why I ask the questi= on regarding the security concern.

C. Henry Adams
=0Achatlga2000@= yahoo.com (Direct Email)
=0A

--- On Wed, 11/14/12, C. Henry Ad= ams & BIE <chatlga2000@yahoo.com> wrote:

From: C. Henry Adams & BIE <chatlga2000@yahoo.com= >
Subject: Fw: GRC Report Exchange draft-ietf-mile-grc-exchange-01.t= xt
To: mile@ietf.org
Cc: "C. Henry Adams" <chatlga2000@yahoo.com&g= t;
Date: Wednesday, November 14, 2012, 8:39 PM

=
It is stated, "The GRCPolicy cla= ss has six attributes:" located in section 
4.1.  GRCPolicy Class
Could the following attribute= s be identified by a letter or number?

1. restriction
2. ext-rest= riction
3. MsgType
4. ext-MsgType
5. MsgDestination
6. ext-MsgD= estination

 
C. Henry Adams
=0Achatlga2000@yahoo.com (Direct Email)
=0A

--- On W= ed, 11/14/12, C. Henry Adams & BIE <chatlga2000@yahoo.com>= wrote:

From: C. Henry Adams & BIE <c= hatlga2000@yahoo.com>
Subject: GRC Report Exchange draft-ietf-mile-g= rc-exchange-01.txt
To: mile@ietf.org
Cc: "C. Henry Adams" <chatlga= 2000@yahoo.com>
Date: Wednesday, November 14, 2012, 8:17 PM

Reviewing the = GRC Exchange Document, I identified with what appears to be a description o= f XML strings in Section 3.   Should the term "String or Strings"= follow the words in subsections 3.4.7   Example (3.4.7. Postal Address String) , 3.4.8 Example (3.4.8. Telephone and Fax Numbers=0A String) (OR)  should defining specific "strings" be a subsection in itself = of  the Language Type "Strings" which represent a sequence of elements= utilized by XML?
 
C. Henry Adams
=0Achatlga2000@yahoo.com (= Direct Email)
=0A
=0A
=0A
--2053635335-550172056-1352944856=:95690-- From wwwrun@rfc-editor.org Thu Nov 15 06:07:04 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 07E3C21F84E0 for ; Thu, 15 Nov 2012 06:07:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.093 X-Spam-Level: X-Spam-Status: No, score=-102.093 tagged_above=-999 required=5 tests=[AWL=0.507, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 DxngSOLLT0ps for ; Thu, 15 Nov 2012 06:07:03 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 4B2D221F84DB for ; Thu, 15 Nov 2012 06:07:03 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id B28EDB1E004; Thu, 15 Nov 2012 05:59:59 -0800 (PST) To: Kathleen.Moriarty@emc.com, stephen.farrell@cs.tcd.ie, turners@ieca.com, Kathleen.Moriarty@emc.com, trammell@tik.ee.ethz.ch From: RFC Errata System Message-Id: <20121115140000.B28EDB1E004@rfc-editor.org> Date: Thu, 15 Nov 2012 05:59:59 -0800 (PST) Cc: mile@ietf.org, rfc-editor@rfc-editor.org Subject: [mile] [Editorial Errata Reported] RFC6545 (3410) 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, 15 Nov 2012 14:07:04 -0000 The following errata report has been submitted for RFC6545, "Real-time Inter-network Defense (RID)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6545&eid=3410 -------------------------------------- Type: Editorial Reported by: Text update for AuthorizationStatus value defintions Section: 5.2 Original Text ------------- AuthorizationStatus One. REQUIRED. ENUM. The listed values are used to provide a response to the requesting CSIRT of the status of a Request, Report, or Query. 1. Approved. The trace was approved and will begin in the current SP. 2. Denied. The trace was denied in the current SP. The next closest SP can use this message to filter traffic from the upstream SP using the example packet to help mitigate the effects of the attack as close to the source as possible. The Acknowledgement message must be passed back to the originator and a Result message must be used from the closest SP to the source in order to indicate actions taken in the IODEF History class. Corrected Text -------------- AuthorizationStatus One. REQUIRED. ENUM. The listed values are used to provide a response to the requesting CSIRT of the status of a Request, Report, or Query. 1. Approved. The request was approved and will be processed and acted upon by the receiving SP or the report was approved for processing. 2. Denied. The message was denied for processing by the recipient for the reasons provided in the Justification. If the RID message was a Trace, the next closest SP can use this message to filter traffic from the upstream SP using the example packet to help mitigate the effects of the attack as close to the source as possible. The Acknowledgement message must be passed back to the originator and a Result message must be used from the closest SP to the source in order to indicate actions taken in the IODEF History class. Notes ----- The definition for Approved and Denied was confusing to an implementer. Although the AuthorizationStatus was broadly defined and the message flows in 7 show the Acknowledgement applies to all messages, the Approved and Denied were being read as specific to Trace Requests. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6545 (draft-ietf-mile-rfc6045-bis-11) -------------------------------------- Title : Real-time Inter-network Defense (RID) Publication Date : April 2012 Author(s) : K. Moriarty Category : PROPOSED STANDARD Source : Managed Incident Lightweight Exchange Area : Security Stream : IETF Verifying Party : IESG From kathleen.moriarty@emc.com Thu Nov 15 12:44:06 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 EE5CD21F856B for ; Thu, 15 Nov 2012 12:44:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.798 X-Spam-Level: X-Spam-Status: No, score=-2.798 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 bVcEuLFYSlTM for ; Thu, 15 Nov 2012 12:44:05 -0800 (PST) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 0F97021F8522 for ; Thu, 15 Nov 2012 12:44:04 -0800 (PST) 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 qAFKhxFK011154 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Nov 2012 15:44:00 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd03.lss.emc.com [10.254.221.145]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Thu, 15 Nov 2012 15:43:32 -0500 Received: from mxhub14.corp.emc.com (mxhub14.corp.emc.com [128.222.70.235]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id qAFKhWRd031703; Thu, 15 Nov 2012 15:43:32 -0500 Received: from mx15a.corp.emc.com ([169.254.1.120]) by mxhub14.corp.emc.com ([128.222.70.235]) with mapi; Thu, 15 Nov 2012 15:43:32 -0500 From: "Moriarty, Kathleen" To: "mile@ietf.org" Date: Thu, 15 Nov 2012 15:43:30 -0500 Thread-Topic: Incident/Indicators Thread-Index: Ac3Dcd8ut3RC6jf7SPu5avp2hqIIjw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_F5063677821E3B4F81ACFB7905573F24CAF57083MX15Acorpemccom_" MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: "Roman D. Danyliw" , "Stoecker, Paul" Subject: [mile] Incident/Indicators 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, 15 Nov 2012 20:44:07 -0000 --_000_F5063677821E3B4F81ACFB7905573F24CAF57083MX15Acorpemccom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, I'd like to hear some opinions on the way that INCH and MILE have used and = defined the term incident and if we should change or update the definition = for the update of RFC5070. I have been asked a few times if IODEF covers i= ndicators. From INCH, the understanding was that we broadly referred to a= n incident and it could use IODEF to exchange selected parts of an incident= and not just the full incident information. The IODEF format could be use= d to encompass a full incident report or just a few helpful parts of that i= ncident, today called indicators. As we start an RFC5070-bis, do we update the definition of an incident to i= nclude this newer term or use the word indicator in the document more? Her= e is the current intended use of the term from RFC5070: 1.3. About the IODEF Data Model The IODEF data model is a data representation that provides a framework for sharing information commonly exchanged by CSIRTs about computer security incidents. A number of considerations were made in the design of the data model. o The data model serves as a transport format. Therefore, its specific representation is not the optimal representation for on- disk storage, long-term archiving, or in-memory processing. o As there is no precise widely agreed upon definition for an incident, the data model does not attempt to dictate one through its implementation. Rather, a broad understanding is assumed in the IODEF that is flexible enough to encompass most operators. o Describing an incident for all definitions would require an extremely complex data model. Therefore, the IODEF only intends to be a framework to convey commonly exchanged incident information. It ensures that there are ample mechanisms for extensibility to support organization-specific information, and techniques to reference information kept outside of the explicit data model. o The domain of security analysis is not fully standardized and must rely on free-form textual descriptions. The IODEF attempts to strike a balance between supporting this free-form content, while still allowing automated processing of incident information. o The IODEF is only one of several security relevant data representations being standardized. Attempts were made to ensure they were complimentary. The data model of the Intrusion Detection Message Exchange Format [17] influenced the design of the IODEF. Further discussion of the desirable properties for the IODEF can be found in the Requirements for the Format for Incident Information Exchange (FINE) [16]. Thank you, Kathleen --_000_F5063677821E3B4F81ACFB7905573F24CAF57083MX15Acorpemccom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hello,
 
I’d like to hear some opinions on the way that INCH and MILE hav= e used and defined the term incident and if we should change or update the = definition for the update of RFC5070.  I have been asked a few times i= f IODEF covers indicators.   From INCH, the understanding was that we broadly referred to an incident and it could use = IODEF to exchange selected parts of an incident and not just the full incid= ent information.  The IODEF format could be used to encompass a full i= ncident report or just a few helpful parts of that incident, today called indicators.
 
As we start an RFC5070-bis, do we update the definition of an incident= to include this newer term or use the word indicator in the document more?=   Here is the current intended use of the term from RFC5070:
 
 
1.3.  About the = IODEF Data Model
 
   The IODE= F data model is a data representation that provides a
   framewor= k for sharing information commonly exchanged by CSIRTs about
   computer= security incidents.  A number of considerations were made in
   the desi= gn of the data model.
 
   o  = The data model serves as a transport format.  Therefore, its
   &nb= sp;  specific representation is not the optimal representation for on-=
   &nb= sp;  disk storage, long-term archiving, or in-memory processing.
 
   o  = As there is no precise widely agreed upon definition for an
   &nb= sp;  incident, the data model does not attempt to dictate one through<= /font>
   &nb= sp;  its implementation.  Rather, a broad understanding is assume= d in
   &nb= sp;  the IODEF that is flexible enough to encompass most operators.
 
   o  = Describing an incident for all definitions would require an
   &nb= sp;  extremely complex data model.  Therefore, the IODEF only int= ends
   &nb= sp;  to be a framework to convey commonly exchanged incident
   &nb= sp;  information.  It ensures that there are ample mechanisms for=
   &nb= sp;  extensibility to support organization-specific information, and
   &nb= sp;  techniques to reference information kept outside of the explicit<= /font>
   &nb= sp;  data model.
 
   o  = The domain of security analysis is not fully standardized and must
   &nb= sp;  rely on free-form textual descriptions.  The IODEF attempts = to
   &nb= sp;  strike a balance between supporting this free-form content, while=
   &nb= sp;  still allowing automated processing of incident information.
 
   o  = The IODEF is only one of several security relevant data
   &nb= sp;  representations being standardized.  Attempts were made to e= nsure
   &nb= sp;  they were complimentary.  The data model of the Intrusion
   &nb= sp;  Detection Message Exchange Format [17] influenced the design of
   &nb= sp;  the IODEF.
 
   Further = discussion of the desirable properties for the IODEF can be
   found in= the Requirements for the Format for Incident Information
   Exchange= (FINE) [16].
 
 
Thank you,
Kathleen
 
 --_000_F5063677821E3B4F81ACFB7905573F24CAF57083MX15Acorpemccom_-- From kathleen.moriarty@emc.com Thu Nov 15 13:26:14 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 8161021F89AA for ; Thu, 15 Nov 2012 13:26:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.765 X-Spam-Level: X-Spam-Status: No, score=-3.765 tagged_above=-999 required=5 tests=[AWL=0.833, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001] 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 RW3R0YtFKqgd for ; Thu, 15 Nov 2012 13:26:13 -0800 (PST) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id B1B7821F871F for ; Thu, 15 Nov 2012 13:26:13 -0800 (PST) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id qAFLQ6eU005376 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Nov 2012 16:26:11 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd03.lss.emc.com [10.254.221.145]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Thu, 15 Nov 2012 16:25:54 -0500 Received: from mxhub32.corp.emc.com (mxhub32.corp.emc.com [128.222.70.172]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id qAFLPsjl001844; Thu, 15 Nov 2012 16:25:54 -0500 Received: from mxhub37.corp.emc.com (128.222.70.104) by mxhub32.corp.emc.com (128.222.70.172) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 15 Nov 2012 16:25:53 -0500 Received: from mx15a.corp.emc.com ([169.254.1.120]) by mxhub37.corp.emc.com ([128.222.70.104]) with mapi; Thu, 15 Nov 2012 16:25:53 -0500 From: "Moriarty, Kathleen" To: "C. Henry Adams & BIE" , "mile@ietf.org" Date: Thu, 15 Nov 2012 16:25:53 -0500 Thread-Topic: [mile] Fw: GRC Report Exchange draft-ietf-mile-grc-exchange-01.txt Thread-Index: Ac3C0pz2W6kFr3jeTNa3ZvTmgEikDgApMXxQ Message-ID: References: <1352943540.53229.YahooMailClassic@web121603.mail.ne1.yahoo.com> In-Reply-To: <1352943540.53229.YahooMailClassic@web121603.mail.ne1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_F5063677821E3B4F81ACFB7905573F24CAF57094MX15Acorpemccom_" MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [mile] Fw: GRC Report Exchange draft-ietf-mile-grc-exchange-01.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, 15 Nov 2012 21:26:14 -0000 --_000_F5063677821E3B4F81ACFB7905573F24CAF57094MX15Acorpemccom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello C. Henry, Each of the referenced attributes contains a selection of values that are v= alid for that attribute. While a number could be used for a machine readab= le implementation, it is common to use the full name from the data model in= an XML schema. The thinking is that XML is already a bit bloated, so you = can read and understand the XML formatted document. In the case of this li= st of attributes, it is possible, but then you would have to go back and lo= ok at the data model to figure out what the attribute is about when you loo= k at the value. Thanks, Kathleen From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of C. = Henry Adams & BIE Sent: Wednesday, November 14, 2012 8:39 PM To: mile@ietf.org Cc: C. Henry Adams Subject: [mile] Fw: GRC Report Exchange draft-ietf-mile-grc-exchange-01.txt It is stated, "The GRCPolicy class has six attributes:" located in section 4.1. GRCPolicy Class Could the following attributes be identified by a letter or number? 1. restriction 2. ext-restriction 3. MsgType 4. ext-MsgType 5. MsgDestination 6. ext-MsgDestination C. Henry Adams chatlga2000@yahoo.com (Direct Email) --- On Wed, 11/14/12, C. Henry Adams & BIE > wrote: From: C. Henry Adams & BIE > Subject: GRC Report Exchange draft-ietf-mile-grc-exchange-01.txt To: mile@ietf.org Cc: "C. Henry Adams" > Date: Wednesday, November 14, 2012, 8:17 PM Reviewing the GRC Exchange Document, I identified with what appears to be a= description of XML strings in Section 3. Should the term "String or Stri= ngs" follow the words in subsections 3.4.7 Example (3.4.7. Postal Address= String) , 3.4.8 Example (3.4.8. Telephone and Fax Numbers String) (OR) sh= ould defining specific "strings" be a subsection in itself of the Language= Type "Strings" which represent a sequence of elements utilized by XML? C. Henry Adams chatlga2000@yahoo.com (Direct Email) --_000_F5063677821E3B4F81ACFB7905573F24CAF57094MX15Acorpemccom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello C. = Henry,

 

Each of the referenced attributes cont= ains a selection of values that are valid for that attribute.  While a= number could be used for a machine readable implementation, it is common t= o use the full name from the data model in an XML schema.  The thinkin= g is that XML is already a bit bloated, so you can read and understand the = XML formatted document.  In the case of this list of attributes, it is= possible, but then you would have to go back and look at the data model to= figure out what the attribute is about when you look at the value.

 

Thanks,

Kathleen

 <= /o:p>

From: mile-bounces@ietf.org [ma= ilto:mile-bounces@ietf.org] On Behalf Of C. Henry Adams & BIESent: Wednesday, November 14, 2012 8:39 PM
To: mile@ietf.= org
Cc: C. Henry Adams
Subject: [mile] Fw: GRC Report E= xchange draft-ietf-mile-grc-exchange-01.txt

 

Reviewing the GRC Exchange Document, I identified= with what appears to be a description of XML strings in Section 3. &n= bsp; Should the term "String or Strings" follow the words in subs= ections 3.4.7   Example (3.4.7. Postal A= ddress String) , 3.4.8 Example (3.4.8.= Telephone and Fax Numbers String) (OR)  should defining specif= ic "strings" be a subsection in itself of  the Language Type= "Strings" which represent a sequence of elements utilized by XML= ?
 
C. Henry Adams
c= hatlga2000@yahoo.com (Direct Email)


It is stated, "The GRCPolicy cla= ss has six attributes:" located in section 

4.1.  GRCPolicy Class

Could the following attributes be identified by a letter or nu= mber?

1. restriction
2. ext-restriction
3. MsgType
4. ext-M= sgType
5. MsgDestination
6. ext-MsgDestination

 
C. H= enry Adams
chatlga2000@yahoo.co= m (Direct Email)


--- On Wed, 11/14/12, C. Henry Adams &am= p; BIE <chatlga2000@yahoo.co= m> wrote:


From: C. Henry Adams & BIE <chatlga2000@yahoo.com>
Subject: GRC Report E= xchange draft-ietf-mile-grc-exchange-01.txt
To: mile@ietf.org
Cc: "C. Henry Adams" <chatlga2000@yahoo.com>
Date: Wedne= sday, November 14, 2012, 8:17 PM

 

= = --_000_F5063677821E3B4F81ACFB7905573F24CAF57094MX15Acorpemccom_-- From chatlga2000@yahoo.com Thu Nov 15 16:46: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 BCA101F0C49 for ; Thu, 15 Nov 2012 16:46:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.598 X-Spam-Level: X-Spam-Status: No, score=-4.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001] 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 yAymz87+FK0b for ; Thu, 15 Nov 2012 16:46:31 -0800 (PST) Received: from nm10-vm3.bullet.mail.ne1.yahoo.com (nm10-vm3.bullet.mail.ne1.yahoo.com [98.138.91.140]) by ietfa.amsl.com (Postfix) with ESMTP id 7F5DA1F041A for ; Thu, 15 Nov 2012 16:46:31 -0800 (PST) Received: from [98.138.90.55] by nm10.bullet.mail.ne1.yahoo.com with NNFMP; 16 Nov 2012 00:46:26 -0000 Received: from [98.138.89.250] by tm8.bullet.mail.ne1.yahoo.com with NNFMP; 16 Nov 2012 00:46:26 -0000 Received: from [127.0.0.1] by omp1042.mail.ne1.yahoo.com with NNFMP; 16 Nov 2012 00:46:26 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 106340.8787.bm@omp1042.mail.ne1.yahoo.com Received: (qmail 63547 invoked by uid 60001); 16 Nov 2012 00:46:25 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1353026785; bh=z1PpVEjYBteWddVz7zJXkEt/a/VZ/2J5POahuA9sBlo=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=4LjGCU11cG5kd/n5RLL/Vc3T9NHWMXt+EOd0rpXAFDC/nspQ6FqXL6bcE8/fpSxmI3WZ/W7KtHM1uhg4hju6nD9QNuNjb/x7KnFtgYmmbLEuTuGjSiiG1YFlfGevh9o4fbk1GZZpw4gqzI8W1VIn4x3l1xdRkhgGK7KSeiW82RE= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=D5O8+xfZzJCqL7t+xmBjy0MmDvFCnZSaQ5aHF6M+qXpWKxLhR2YAH2s8Evo0p7tKqwUKfEn4qsDdUyIKwgP1agWVb92Hi0mGl64oMsJ5HtimAYhRWFG34usMYymlNaZpZ4Zhv+Kghz+m2ekp3nRrs44ikHbSUrXa89CUyDlpRlk=; X-YMail-OSG: j0vm0vcVM1k31JUbSGntenwYYoesqA8bQ17uWw8MW3YAyFP 8c9ORwtTtKpoiRvrHyd2qyrKpsSSyMd1yQNwWVHO3EMDO1W1jlg16nfX9h24 af.vFK8jInJ_Q1trpIvXtawoRodirz_bxQ342C5VYwc6hTd_lCEbmX4xWp3f iCSrEl1cfhsn9vxjKu2uEsU1e7IctX6RazKXEE02nELt.pe0hOZd9oMBl97R nd5zDLryS7T9GJXYiU4UgxV4Yo1d3zcog9DYho.axQo8KimcDKns5Xh9OjE_ r2O7X_oSX9uYwHfCafDsVIyO0pmNf..eQqVzHg6gN.Aqc0jNluoLiMr6vvyB l050wwf_nKnNkaFUtAM6u7a.pQmXCr6G8Pj8wNqBFsybmE.On66vyzmrxsdN zpLrnTGHAAx1oK_4KApF5_Hm_v6hfkzsBhqadaByoAdxjdZdrmprd4qAZeWq cYhzQyTGpF.5Kvjr33Zi2Z8ZAP0ezSiJPmKHDykWwgQgP6kLZpf_tExuxMIw oP.zgQMGWcW4znz9.MtSn5O2c Received: from [32.179.118.24] by web121606.mail.ne1.yahoo.com via HTTP; Thu, 15 Nov 2012 16:46:25 PST X-Rocket-MIMEInfo: 001.001, TXkgYXBvbG9naWVzOyBmb3IgY2xhcmlmaWNhdGlvbiBwdXJwb3Nlcywgd2hlbiByZWFkaW5nIHRoZSBkb2N1bWVudCAtIEkgYXR0ZW1wdCB0byBpZGVudGlmeSB3aXRoIGEgbGF5cGVyc29uIHJldmlld2luZyBzdGF0ZW1lbnRzIHdoaWxlIHRyeWluZyB0byByZWFkIGFuZCBjb21wcmVoZW5kIHRoZSB3b3JkcyBvciAiQXR0cmlidXRlcyIgd3JpdHRlbiBvbiBhIHNpbmdsZSBzZXBhcmF0ZSBsaW5lIG9mIGEgRHJhZnQgRG9jdW1lbnQuIFBlcmhhcHMsIGl0IGNvdWxkIGJlIHVuY2xlYXIgdG8gZGlzdGluZ3Vpc2gBMAEBAQE- X-Mailer: YahooMailClassic/15.0.8 YahooMailWebService/0.8.123.460 Message-ID: <1353026785.57315.YahooMailClassic@web121606.mail.ne1.yahoo.com> Date: Thu, 15 Nov 2012 16:46:25 -0800 (PST) From: "C. Henry Adams & BIE" To: KathleenMoriarty , MILE IETF In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1458340343-845433672-1353026785=:57315" Cc: "C. Henry Adams" Subject: Re: [mile] Fw: GRC Report Exchange draft-ietf-mile-grc-exchange-01.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: Fri, 16 Nov 2012 00:46:32 -0000 --1458340343-845433672-1353026785=:57315 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable My apologies; for clarification purposes, when reading the document - I att= empt to identify with a layperson reviewing statements while trying to read= and comprehend the words or "Attributes" written on a single separate line= of a Draft Document. Perhaps, it could be unclear to distinguish their sig= nificance. It was not my intent to associate an alphanumerical value to an Attribute.= =A0 I was trying to view the document from a written standpoint and not fro= m a programming standpoint. By doing so, I gather a better understanding of how to take an analytical v= ision and place it in the realm of a visual one. Furthermore, I agree with your explanation regarding not complicating XML S= chema any more than it already is at this point.=A0=20 C. Henry Adams =0Achatlga2000@yahoo.com (Direct Email) =0A --- On Thu, 11/15/12, Moriarty, Kathleen wrote: From: Moriarty, Kathleen Subject: RE: [mile] Fw: GRC Report Exchange draft-ietf-mile-grc-exchange-01= .txt To: "C. Henry Adams & BIE" , "mile@ietf.org" Date: Thursday, November 15, 2012, 4:25 PM Hello C. Henry, =A0Each of the referenced attributes contains a selection o= f values that are valid for that attribute.=A0 While a number could be used= for a machine readable implementation, it is common to use the full name f= rom the data model in an XML schema.=A0 The thinking is that XML is already= a bit bloated, so you can read and understand the XML formatted document.= =A0 In the case of this list of attributes, it is possible, but then you wo= uld have to go back and look at the data model to figure out what the attri= bute is about when you look at the value. =A0Thanks,Kathleen =A0From: mile-= bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of C. Henry Adams= & BIE Sent: Wednesday, November 14, 2012 8:39 PM To: mile@ietf.org Cc: C. Henry Adams Subject: [mile] Fw: GRC Report Exchange draft-ietf-mile-grc-exchange-01.txt= =A0It is stated, "The GRCPolicy class has six attributes:" located in sect= ion=A04.1.=A0 GRCPolicy ClassCould the following attributes be identified b= y a letter or number? 1. restriction 2. ext-restriction 3. MsgType 4. ext-MsgType 5. MsgDestination 6. ext-MsgDestination =A0=20 C. Henry Adams chatlga2000@yahoo.com (Direct Email) --- On Wed, 11/14/12, C. Henry Adams & BIE wrote: From: C. Henry Adams & BIE Subject: GRC Report Exchange draft-ietf-mile-grc-exchange-01.txt To: mile@ietf.org Cc: "C. Henry Adams" Date: Wednesday, November 14, 2012, 8:17 PMReviewing the GRC Exchange Docum= ent, I identified with what appears to be a description of XML strings in S= ection 3.=A0=A0 Should the term "String or Strings" follow the words in sub= sections 3.4.7 =A0 Example (3.4.7. Postal Address String) , 3.4.8 Example (= 3.4.8. Telephone and Fax Numbers String) (OR)=A0 should defining specific "= strings" be a subsection in itself of=A0 the Language Type "Strings" which = represent a sequence of elements utilized by XML? =A0 C. Henry Adams chatlga2000@yahoo.com (Direct Email) =A0 --1458340343-845433672-1353026785=:57315 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
My apologies; for clarification purposes, whe= n reading the document - I attempt to identify with a layperson reviewing s= tatements while trying to read and comprehend the words or "Attributes" wri= tten on a single separate line of a Draft Document. Perhaps, it could be un= clear to distinguish their significance.

It was not my intent to ass= ociate an alphanumerical value to an Attribute.  I was trying to view = the document from a written standpoint and not from a programming standpoin= t.

By doing so, I gather a better understanding of how to take an an= alytical vision and place it in the realm of a visual one.

Furthermo= re, I agree with your explanation regarding not complicating XML Schema any= more than it already is at this point. 



C. Henry Adam= s
=0Achatlga2000@yahoo.com (Direct Email)
=0A

--- On Thu, 1= 1/15/12, Moriarty, Kathleen <kathleen.moriarty@emc.com> wr= ote:

From: Moriarty, Kathleen <kathleen.= moriarty@emc.com>
Subject: RE: [mile] Fw: GRC Report Exchange draft-i= etf-mile-grc-exchange-01.txt
To: "C. Henry Adams & BIE" <chatlga2= 000@yahoo.com>, "mile@ietf.org" <mile@ietf.org>
Date: Thursday,= November 15, 2012, 4:25 PM

Hello C. Henry,

<= p class=3D"yiv334617860MsoNormal">  

Each = of the referenced attributes contains a selection of values that are valid = for that attribute.  While a number could be used for a machine readab= le implementation, it is common to use the full name from the data model in= an XML schema.  The thinking is that XML is already a bit bloated, so= you can read and understand the XML formatted document.  In the case = of this list of attributes, it is possible, but then you would have to go b= ack and look at the data model to figure out what the attribute is about when you = look at the value.

 

Thanks,

Kathleen

 

From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf= Of C. Henry Adams & BIE
Sent: Wednesday, November 14, 20= 12 8:39 PM
To: mile@ietf.org
Cc: C. Henry Adams
S= ubject: [mile] Fw: GRC Report Exchange draft-ietf-mile-grc-exchange-01.= txt

 

<= p class=3D"yiv334617860MsoNormal">It is stated, "The GRCPolicy class has si= x attributes:" located in section 

4.1.  GRCPolicy Class

Could the following attributes be identified by a letter or number?
<= br>1. restriction
2. ext-restriction
3. MsgType
4. ext-MsgType
= 5. MsgDestination
6. ext-MsgDestination

 
C. Henry Adamschatlga2000@yahoo.com= (Direct Email)


--- On Wed, 11/14/12, C. Henry Adams &= ; BIE <chatlga200= 0@yahoo.com> wrote:


From: C. Henry Adams & BIE <chatlga2000@yahoo.com>=
Subject: GRC Report Exchange draft-ietf-mile-grc-exchange-01.txt
To:= mile@ietf.org
Cc: "C. Henry Ada= ms" <chatlga2000@yahoo.com>
Date: Wed= nesday, November 14, 2012, 8:17 PM

=

Reviewing t= he GRC Exchange Document, I identified with what appears to be a descriptio= n of XML strings in Section 3.   Should the term "String or Strin= gs" follow the words in subsections 3.4.7   Example (3.4.7. Postal Address String) , 3.4.8 Example (3.4.8. Telephone and Fax Numbers String) (OR= )  should defining specific "strings" be a subsection in itself of&nbs= p; the Language Type "Strings" which represent a sequence of elements utili= zed by XML?
 
C. Henry Adams
chatlga2000@yahoo.com (Direct Email)


 

--1458340343-845433672-1353026785=:57315-- From david.black@emc.com Sat Nov 17 07:13:55 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 384E721F873B for ; Sat, 17 Nov 2012 07:13:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.61 X-Spam-Level: X-Spam-Status: No, score=-98.61 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_STOCK2=3.988, HTML_MESSAGE=0.001, 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 UQrQ-juxDU3Z for ; Sat, 17 Nov 2012 07:13:52 -0800 (PST) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 686B921F847F for ; Sat, 17 Nov 2012 07:13:51 -0800 (PST) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id qAHFDjnQ027036 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 17 Nov 2012 10:13:45 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd04.lss.emc.com [10.254.222.226]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Sat, 17 Nov 2012 10:13:41 -0500 Received: from mxhub16.corp.emc.com (mxhub16.corp.emc.com [128.222.70.237]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id qAHFDeT8022833; Sat, 17 Nov 2012 10:13:40 -0500 Received: from mx15a.corp.emc.com ([169.254.1.120]) by mxhub16.corp.emc.com ([128.222.70.237]) with mapi; Sat, 17 Nov 2012 10:13:40 -0500 From: "Black, David" To: "Moriarty, Kathleen" , "mile@ietf.org" Date: Sat, 17 Nov 2012 10:13:38 -0500 Thread-Topic: Incident/Indicators Thread-Index: Ac3Dcd8ut3RC6jf7SPu5avp2hqIIjwBY+CWQ Message-ID: <8D3D17ACE214DC429325B2B98F3AE71284B5A563@MX15A.corp.emc.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_8D3D17ACE214DC429325B2B98F3AE71284B5A563MX15Acorpemccom_" MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: "Roman D. Danyliw" , "Stoecker, Paul" Subject: Re: [mile] Incident/Indicators 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: Sat, 17 Nov 2012 15:13:55 -0000 --_000_8D3D17ACE214DC429325B2B98F3AE71284B5A563MX15Acorpemccom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Kathleen, Here's my 0.02 ... > The IODEF format could be used to encompass a full incident report or > just a few helpful parts of that incident, today called indicators. > > As we start an RFC5070-bis, do we update the definition of an incident to > include this newer term or use the word indicator in the document more? IMHO - yes, both sound like good ideas :-). An update to use current terminology certainly sounds like a good thing to do. In addition to using "indicator" in the definition of "incident", I'd suggest adding a definition of "indicator" as a part or an aspect of an incident and using that term as appropriate in the body of the draft, as that should help readers who are more familiar with current terminology. It might also be useful to discuss use of an IODEF Incident instance as a lightweight container for selected indicators - the incident ID would serve only as part of wrapping the indicators in a collection, and in the simple case where there's only one indicator, that incident ID effectively provides an identifier for the indicator. Anyone else care to comment? Thanks, --David From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Mor= iarty, Kathleen Sent: Thursday, November 15, 2012 3:44 PM To: mile@ietf.org Cc: Roman D. Danyliw; Stoecker, Paul Subject: [mile] Incident/Indicators Hello, I'd like to hear some opinions on the way that INCH and MILE have used and = defined the term incident and if we should change or update the definition = for the update of RFC5070. I have been asked a few times if IODEF covers i= ndicators. From INCH, the understanding was that we broadly referred to a= n incident and it could use IODEF to exchange selected parts of an incident= and not just the full incident information. The IODEF format could be use= d to encompass a full incident report or just a few helpful parts of that i= ncident, today called indicators. As we start an RFC5070-bis, do we update the definition of an incident to i= nclude this newer term or use the word indicator in the document more? Her= e is the current intended use of the term from RFC5070: 1.3. About the IODEF Data Model The IODEF data model is a data representation that provides a framework for sharing information commonly exchanged by CSIRTs about computer security incidents. A number of considerations were made in the design of the data model. o The data model serves as a transport format. Therefore, its specific representation is not the optimal representation for on- disk storage, long-term archiving, or in-memory processing. o As there is no precise widely agreed upon definition for an incident, the data model does not attempt to dictate one through its implementation. Rather, a broad understanding is assumed in the IODEF that is flexible enough to encompass most operators. o Describing an incident for all definitions would require an extremely complex data model. Therefore, the IODEF only intends to be a framework to convey commonly exchanged incident information. It ensures that there are ample mechanisms for extensibility to support organization-specific information, and techniques to reference information kept outside of the explicit data model. o The domain of security analysis is not fully standardized and must rely on free-form textual descriptions. The IODEF attempts to strike a balance between supporting this free-form content, while still allowing automated processing of incident information. o The IODEF is only one of several security relevant data representations being standardized. Attempts were made to ensure they were complimentary. The data model of the Intrusion Detection Message Exchange Format [17] influenced the design of the IODEF. Further discussion of the desirable properties for the IODEF can be found in the Requirements for the Format for Incident Information Exchange (FINE) [16]. Thank you, Kathleen --_000_8D3D17ACE214DC429325B2B98F3AE71284B5A563MX15Acorpemccom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Kathleen,<= o:p>

 

Here's my 0.02 ...

 = ;

> The IODEF format could be used to e= ncompass a full incident report or

&g= t; just a few helpful parts of that incident, today called indicators.=

> 

> As we start an RFC5070-bis, do we update the definition of an= incident to

> include this newer = term or use the word indicator in the document more?

 

IMHO - yes, bo= th sound like good ideas :-).

&n= bsp;

An update to use current terminology = certainly sounds like a good thing

to= do.  In addition to using "indicator" in the definition of = "incident",

I'd suggest add= ing a definition of "indicator" as a part or an aspect of

an incident and using that term as appropria= te in the body of the draft,

as that = should help readers who are more familiar with current terminology.

 

It might also be useful to discuss use of an IODEF Incident instance<= /o:p>

as a lightweight container for selected in= dicators - the incident ID

would serv= e only as part of wrapping the indicators in a collection,

and in the simple case where there’s only one i= ndicator, that incident

ID effectivel= y provides an identifier for the indicator.

 

Anyone else care to com= ment?

 

=

Thanks,
--David

 

From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Beh= alf Of Moriarty, Kathleen
Sent: Thursday, November 15, 2012 3= :44 PM
To: mile@ietf.org
Cc: Roman D. Danyliw; Stoecker= , Paul
Subject: [mile] Incident/Indicators

<= /div>

 

Hel= lo,

 <= /p>

I’d like to hear some opinions on the way= that INCH and MILE have used and defined the term incident and if we shoul= d change or update the definition for the update of RFC5070.  I have b= een asked a few times if IODEF covers indicators.   From INCH, th= e understanding was that we broadly referred to an incident and it could us= e IODEF to exchange selected parts of an incident and not just the full inc= ident information.  The IODEF format could be used to encompass a full= incident report or just a few helpful parts of that incident, today called= indicators.

 

As we start an RFC5070-bis, do we upda= te the definition of an incident to include this newer term or use the word= indicator in the document more?  Here is the current intended use of = the term from RFC5070:

 =

 

=

1.3.  About the IODEF Data Model

=

 

   Th= e IODEF data model is a data representation that provides a

   framework for sharing information common= ly exchanged by CSIRTs about

 &nb= sp; computer security incidents.  A number of considerations were made= in

   the design of the dat= a model.

 

   o  The data model serves as a transport = format.  Therefore, its

 &nb= sp;    specific representation is not the optimal representa= tion for on-

    &= nbsp; disk storage, long-term archiving, or in-memory processing.

 

&nb= sp;  o  As there is no precise widely agreed upon definition for = an

      inci= dent, the data model does not attempt to dictate one through

      its implementation.&n= bsp; Rather, a broad understanding is assumed in

      the IODEF that is flexible enough= to encompass most operators.

 

   o  Describing an inci= dent for all definitions would require an

<= p class=3DMsoNormal>      extremely complex data model.  Ther= efore, the IODEF only intends

 &n= bsp;    to be a framework to convey commonly exchanged incid= ent

      inf= ormation.  It ensures that there are ample mechanisms for

      extensibility to su= pport organization-specific information, and

      techniques to reference information k= ept outside of the explicit

 &nbs= p;    data model.

&nb= sp;

   o  The domain of= security analysis is not fully standardized and must

=

      rely on free-form textual de= scriptions.  The IODEF attempts to

  &n= bsp;   still allowing automated processing of incident informatio= n.

 

<= div>

   o  The IODEF is only one of several security rel= evant data

    &nb= sp; representations being standardized.  Attempts were made to ensure<= /span><= o:p>

      they we= re complimentary.  The data model of the Intrusion=

      Detection Message Exchan= ge Format [17] influenced the design of

 

   Further disc= ussion of the desirable properties for the IODEF can be=

   found in the Requirements for the Format f= or Incident Information

   E= xchange (FINE) [16].

<= span style=3D'font-size:10.0pt;font-family:"Calibri","sans-serif"'> 

 

Thank you,

Kathleen

 

= --_000_8D3D17ACE214DC429325B2B98F3AE71284B5A563MX15Acorpemccom_-- From david.black@emc.com Sat Nov 17 07:43:08 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 EFECE21F84DF for ; Sat, 17 Nov 2012 07:43:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.604 X-Spam-Level: X-Spam-Status: No, score=-100.604 tagged_above=-999 required=5 tests=[AWL=1.994, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 vlqu8UXlK662 for ; Sat, 17 Nov 2012 07:43:06 -0800 (PST) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id AF17521F84DD for ; Sat, 17 Nov 2012 07:43:03 -0800 (PST) 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 qAHFh37w002571 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 17 Nov 2012 10:43:03 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd01.lss.emc.com [10.254.221.251]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Sat, 17 Nov 2012 10:42:48 -0500 Received: from mxhub21.corp.emc.com (mxhub21.corp.emc.com [128.222.70.133]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id qAHFglSD009525; Sat, 17 Nov 2012 10:42:47 -0500 Received: from mx15a.corp.emc.com ([169.254.1.120]) by mxhub21.corp.emc.com ([128.222.70.133]) with mapi; Sat, 17 Nov 2012 10:42:46 -0500 From: "Black, David" To: Adam Montville , "" Date: Sat, 17 Nov 2012 10:42:45 -0500 Thread-Topic: Updated IODEF Enumeration Reference Format Draft Thread-Index: AQHNvQ3c5igWirSip0ScCVgUmvLL1JfuMxLg Message-ID: <8D3D17ACE214DC429325B2B98F3AE71284B5A565@MX15A.corp.emc.com> References: <18EDCB49-399F-44DC-BF11-9A77F3E459FC@tripwire.com> In-Reply-To: <18EDCB49-399F-44DC-BF11-9A77F3E459FC@tripwire.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_8D3D17ACE214DC429325B2B98F3AE71284B5A565MX15Acorpemccom_" MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [mile] Updated IODEF Enumeration Reference Format Draft 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: Sat, 17 Nov 2012 15:43:09 -0000 --_000_8D3D17ACE214DC429325B2B98F3AE71284B5A565MX15Acorpemccom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Adam, Thanks for working on this draft. I see that the version is included in the id_type string prefix. I'm assuming that this version is the version number of the registered specification. That makes sense if the version doesn't change often and especially if a version change results in a change to the identifier format. How often does the version change for the specs that are the sources of the enumerations of interest? If the spec version changes often, and especially if enumeration identifiers from previous versions usually remain valid in new versions, an alternative approach would be to tie the version to the identifier format rather than the spec version - this could avoid having several dozen id_type strings for versions of a single spec. Please also take a look at these two emails that I sent to the list earlier= : identifier formats: http://www.ietf.org/mail-archive/web/mile/current/msg00= 853.html more on versions: http://www.ietf.org/mail-archive/web/mile/current/msg0085= 4.html I have some additional editorial concerns that I'll send to you directly. Thanks, --David From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Ada= m Montville Sent: Wednesday, November 07, 2012 12:32 PM To: Subject: [mile] Updated IODEF Enumeration Reference Format Draft All: I'm pleased to submit draft-montville-mile-enum-reference-format-01 availab= le at http://www.ietf.org/id/draft-montville-mile-enum-reference-format-01.txt Changes: * IANA Table Request Changes * Removed "Name" * Added "Full Name * Added "Abbreviation" * Specified id_type to be _ * Reviewed text for scope statements and limited scope to IODEF, while a= lluding to the method's potential usefulness elsewhere. * Ensured that the Reference class diagram is explicitly referenced as [= IODEF]. * Updated IANA Considerations to request creation of the table * Updated IANA table format fields with simple descriptions I look forward to your comments. Regards, Adam W. Montville | Security and Compliance Architect CISA, CISSP Direct: 503 276-7661 Mobile: 360 471-7815 TRIPWIRE | Take CONTROL http://www.tripwire.com --_000_8D3D17ACE214DC429325B2B98F3AE71284B5A565MX15Acorpemccom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Adam,

 

Thanks for working on this draft.

 

I see that the vers= ion is included in the id_type string prefix.

I’m assuming that this version is the version number of the = registered

specification.  That = makes sense if the version doesn’t change often

=

and especially if a version change results in a change to = the identifier

format. 

 

How often does the version change for the specs that are the sources of

the enumerations of interest?

 

I= f the spec version changes often, and especially if enumeration<= /span>

identifiers from previous versions usually remai= n valid in new versions,

an alternati= ve approach would be to tie the version to the identifier=

format rather than the spec version - this could avoid= having several

dozen id_type strings= for versions of a single spec.

<= span style=3D'font-size:10.0pt;font-family:"Courier New";color:black'>=  

Please also take a look at these tw= o emails that I sent to the list earlier:

 

identifier formats: http= ://www.ietf.org/mail-archive/web/mile/current/msg00853.html<= /span>

more on versions: http://www.ietf.org/mail-arch= ive/web/mile/current/msg00854.html

I have some additional edito= rial concerns that I’ll send to you directly.

Thank= s,
--David

&nb= sp;

From: mile-boun= ces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Adam Montvi= lle
Sent: Wednesday, November 07, 2012 12:32 PM
To: <= ;mile@ietf.org>
Subject: [mile] Updated IODEF Enumeration Refe= rence Format Draft

 

All:

 

I'm pleas= ed to submit draft-montville-mile-enum-reference-format-01 available at

 

 

Changes:

 

  • IANA Table Request Changes <= /o:p>
    • Removed "Name"
    • Added "Full Name
    • A= dded "Abbreviation"
  • Specified id_type to be <Abbreviation>_&l= t;Version>
  • Reviewed text = for scope statements and limited scope to IODEF, while alluding to the meth= od's potential usefulness elsewhere.
  • Ensured that the Reference class diagram is explicitly referenced = as [IODEF].
  • Updated IANA Con= siderations to request creation of the table
  • Updated IANA table format fields with simple descriptions<= o:p>

 

 

I look forward to your comments.

 

Re= gards,

 

Adam W. Montville = | Security and Complianc= e Architect

CISA, = CISSP

 

Direct: 503 276-7661

Mobile: 360 471-7815=

 =

TRIPWIRE | Take CONTROL<= span style=3D'font-size:10.5pt;font-family:"Calibri","sans-serif";color:bla= ck'>

<= /div>

 

 

 

 

 

= --_000_8D3D17ACE214DC429325B2B98F3AE71284B5A565MX15Acorpemccom_-- From david.waltermire@nist.gov Tue Nov 20 11:22:55 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 BF81521F84F1 for ; Tue, 20 Nov 2012 11:22:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.509 X-Spam-Level: X-Spam-Status: No, score=-3.509 tagged_above=-999 required=5 tests=[AWL=-2.652, BAYES_00=-2.599, FRT_STOCK2=3.988, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, 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 IlPE9luBVzur for ; Tue, 20 Nov 2012 11:22:50 -0800 (PST) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 35D1621F881B for ; Tue, 20 Nov 2012 11:22:48 -0800 (PST) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.2.318.4; Tue, 20 Nov 2012 14:22:43 -0500 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Tue, 20 Nov 2012 14:22:47 -0500 From: "Waltermire, David A." To: "Black, David" , "Moriarty, Kathleen" , "mile@ietf.org" Date: Tue, 20 Nov 2012 14:22:45 -0500 Thread-Topic: Incident/Indicators Thread-Index: Ac3Dcd8ut3RC6jf7SPu5avp2hqIIjwBY+CWQAJ+P0aA= Message-ID: References: <8D3D17ACE214DC429325B2B98F3AE71284B5A563@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE71284B5A563@MX15A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_D7A0423E5E193F40BE6E94126930C4930BAC6DC578MBCLUSTERxcha_" MIME-Version: 1.0 Cc: "Roman D. Danyliw" , "Stoecker, Paul" Subject: Re: [mile] Incident/Indicators 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, 20 Nov 2012 19:22:55 -0000 --_000_D7A0423E5E193F40BE6E94126930C4930BAC6DC578MBCLUSTERxcha_ Content-Type: text/plain; charset="us-ascii" David, +1. What you are suggesting sounds like a reasonable approach. Sincerely, Dave From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Black, David Sent: Saturday, November 17, 2012 10:14 AM To: Moriarty, Kathleen; mile@ietf.org Cc: Roman D. Danyliw; Stoecker, Paul Subject: Re: [mile] Incident/Indicators Hi Kathleen, Here's my 0.02 ... > The IODEF format could be used to encompass a full incident report or > just a few helpful parts of that incident, today called indicators. > > As we start an RFC5070-bis, do we update the definition of an incident to > include this newer term or use the word indicator in the document more? IMHO - yes, both sound like good ideas :-). An update to use current terminology certainly sounds like a good thing to do. In addition to using "indicator" in the definition of "incident", I'd suggest adding a definition of "indicator" as a part or an aspect of an incident and using that term as appropriate in the body of the draft, as that should help readers who are more familiar with current terminology. It might also be useful to discuss use of an IODEF Incident instance as a lightweight container for selected indicators - the incident ID would serve only as part of wrapping the indicators in a collection, and in the simple case where there's only one indicator, that incident ID effectively provides an identifier for the indicator. Anyone else care to comment? Thanks, --David From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Moriarty, Kathleen Sent: Thursday, November 15, 2012 3:44 PM To: mile@ietf.org Cc: Roman D. Danyliw; Stoecker, Paul Subject: [mile] Incident/Indicators Hello, I'd like to hear some opinions on the way that INCH and MILE have used and defined the term incident and if we should change or update the definition for the update of RFC5070. I have been asked a few times if IODEF covers indicators. From INCH, the understanding was that we broadly referred to an incident and it could use IODEF to exchange selected parts of an incident and not just the full incident information. The IODEF format could be used to encompass a full incident report or just a few helpful parts of that incident, today called indicators. As we start an RFC5070-bis, do we update the definition of an incident to include this newer term or use the word indicator in the document more? Here is the current intended use of the term from RFC5070: 1.3. About the IODEF Data Model The IODEF data model is a data representation that provides a framework for sharing information commonly exchanged by CSIRTs about computer security incidents. A number of considerations were made in the design of the data model. o The data model serves as a transport format. Therefore, its specific representation is not the optimal representation for on- disk storage, long-term archiving, or in-memory processing. o As there is no precise widely agreed upon definition for an incident, the data model does not attempt to dictate one through its implementation. Rather, a broad understanding is assumed in the IODEF that is flexible enough to encompass most operators. o Describing an incident for all definitions would require an extremely complex data model. Therefore, the IODEF only intends to be a framework to convey commonly exchanged incident information. It ensures that there are ample mechanisms for extensibility to support organization-specific information, and techniques to reference information kept outside of the explicit data model. o The domain of security analysis is not fully standardized and must rely on free-form textual descriptions. The IODEF attempts to strike a balance between supporting this free-form content, while still allowing automated processing of incident information. o The IODEF is only one of several security relevant data representations being standardized. Attempts were made to ensure they were complimentary. The data model of the Intrusion Detection Message Exchange Format [17] influenced the design of the IODEF. Further discussion of the desirable properties for the IODEF can be found in the Requirements for the Format for Incident Information Exchange (FINE) [16]. Thank you, Kathleen --_000_D7A0423E5E193F40BE6E94126930C4930BAC6DC578MBCLUSTERxcha_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05U RU5UPSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXMtYXNjaWkiPjxtZXRhIG5hbWU9R2VuZXJhdG9yIGNv bnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDE0IChmaWx0ZXJlZCBtZWRpdW0pIj48c3R5bGU+PCEtLQ0K LyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCi8qIFN0eWxl IERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFs DQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4w cHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNw YW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlu a0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0 LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUt bGluazoiUGxhaW4gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAw MDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0K cC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJn aW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9u dC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uUGxhaW5UZXh0Q2hhcg0KCXtt c28tc3R5bGUtbmFtZToiUGxhaW4gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyI7fQ0KcC5lbWFpbHF1b3RlLCBsaS5lbWFpbHF1b3RlLCBkaXYuZW1haWxxdW90ZQ0KCXttc28t c3R5bGUtbmFtZTplbWFpbHF1b3RlOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdp bi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6 MS4wcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu Iiwic2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6YmxhY2s7DQoJZm9udC13ZWln aHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFsOw0KCXRleHQtZGVjb3JhdGlvbjpub25lIG5v bmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30N CnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hh ciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRl eHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBw YWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4w aW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9 DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2 OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAg djpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZd LS0+PC9oZWFkPjxib2R5IGxhbmc9RU4tVVMgbGluaz1ibHVlIHZsaW5rPXB1cnBsZT48ZGl2IGNs YXNzPVdvcmRTZWN0aW9uMT48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdE Jz5EYXZpZCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPisxLiZuYnNwOyBXaGF0IHlvdSBhcmUgc3VnZ2Vz dGluZyBzb3VuZHMgbGlrZSBhIHJlYXNvbmFibGUgYXBwcm9hY2guPG86cD48L286cD48L3NwYW4+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMx RjQ5N0QnPlNpbmNlcmVseSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+RGF2ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+PGRpdj48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk ICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbic+PHAgY2xhc3M9TXNvTm9y bWFsPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEi LCJzYW5zLXNlcmlmIic+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+IG1pbGUtYm91bmNlc0BpZXRm Lm9yZyBbbWFpbHRvOm1pbGUtYm91bmNlc0BpZXRmLm9yZ10gPGI+T24gQmVoYWxmIE9mIDwvYj5C bGFjaywgRGF2aWQ8YnI+PGI+U2VudDo8L2I+IFNhdHVyZGF5LCBOb3ZlbWJlciAxNywgMjAxMiAx MDoxNCBBTTxicj48Yj5Ubzo8L2I+IE1vcmlhcnR5LCBLYXRobGVlbjsgbWlsZUBpZXRmLm9yZzxi cj48Yj5DYzo8L2I+IFJvbWFuIEQuIERhbnlsaXc7IFN0b2Vja2VyLCBQYXVsPGJyPjxiPlN1Ympl Y3Q6PC9iPiBSZTogW21pbGVdIEluY2lkZW50L0luZGljYXRvcnM8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PC9kaXY+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxw IGNsYXNzPU1zb1BsYWluVGV4dD5IaSBLYXRobGVlbiw8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1N c29QbGFpblRleHQ+PG86cD4mbmJzcDs8L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0Pkhl cmUncyBteSAwLjAyIC4uLjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD48bzpw PiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyBUaGUgSU9ERUYgZm9y bWF0IGNvdWxkIGJlIHVzZWQgdG8gZW5jb21wYXNzIGEgZnVsbCBpbmNpZGVudCByZXBvcnQgb3I8 bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyBqdXN0IGEgZmV3IGhlbHBm dWwgcGFydHMgb2YgdGhhdCBpbmNpZGVudCwgdG9kYXkgY2FsbGVkIGluZGljYXRvcnMuPG86cD48 L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsmbmJzcDsgPG86cD48L286cD48L3A+ PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsgQXMgd2Ugc3RhcnQgYW4gUkZDNTA3MC1iaXMsIGRv IHdlIHVwZGF0ZSB0aGUgZGVmaW5pdGlvbiBvZiBhbiBpbmNpZGVudCB0bzxvOnA+PC9vOnA+PC9w PjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7IGluY2x1ZGUgdGhpcyBuZXdlciB0ZXJtIG9yIHVz ZSB0aGUgd29yZCBpbmRpY2F0b3IgaW4gdGhlIGRvY3VtZW50IG1vcmU/PG86cD48L286cD48L3A+ PHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1Bs YWluVGV4dD5JTUhPIC0geWVzLCBib3RoIHNvdW5kIGxpa2UgZ29vZCBpZGVhcyA6LSkuPG86cD48 L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNs YXNzPU1zb1BsYWluVGV4dD5BbiB1cGRhdGUgdG8gdXNlIGN1cnJlbnQgdGVybWlub2xvZ3kgY2Vy dGFpbmx5IHNvdW5kcyBsaWtlIGEgZ29vZCB0aGluZzxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1z b1BsYWluVGV4dD50byBkby4mbmJzcDsgSW4gYWRkaXRpb24gdG8gdXNpbmcgJnF1b3Q7aW5kaWNh dG9yJnF1b3Q7IGluIHRoZSBkZWZpbml0aW9uIG9mICZxdW90O2luY2lkZW50JnF1b3Q7LDxvOnA+ PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD5JJ2Qgc3VnZ2VzdCBhZGRpbmcgYSBkZWZp bml0aW9uIG9mICZxdW90O2luZGljYXRvciZxdW90OyBhcyBhIHBhcnQgb3IgYW4gYXNwZWN0IG9m PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PmFuIGluY2lkZW50IGFuZCB1c2lu ZyB0aGF0IHRlcm0gYXMgYXBwcm9wcmlhdGUgaW4gdGhlIGJvZHkgb2YgdGhlIGRyYWZ0LDxvOnA+ PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD5hcyB0aGF0IHNob3VsZCBoZWxwIHJlYWRl cnMgd2hvIGFyZSBtb3JlIGZhbWlsaWFyIHdpdGggY3VycmVudCB0ZXJtaW5vbG9neS48bzpwPjwv bzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+PG86cD4mbmJzcDs8L286cD48L3A+PHAgY2xh c3M9TXNvUGxhaW5UZXh0Pkl0IG1pZ2h0IGFsc28gYmUgdXNlZnVsIHRvIGRpc2N1c3MgdXNlIG9m IGFuIElPREVGIEluY2lkZW50IGluc3RhbmNlPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxh aW5UZXh0PmFzIGEgbGlnaHR3ZWlnaHQgY29udGFpbmVyIGZvciBzZWxlY3RlZCBpbmRpY2F0b3Jz IC0gdGhlIGluY2lkZW50IElEPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0Pndv dWxkIHNlcnZlIG9ubHkgYXMgcGFydCBvZiB3cmFwcGluZyB0aGUgaW5kaWNhdG9ycyBpbiBhIGNv bGxlY3Rpb24sPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PmFuZCBpbiB0aGUg c2ltcGxlIGNhc2Ugd2hlcmUgdGhlcmUmIzgyMTc7cyBvbmx5IG9uZSBpbmRpY2F0b3IsIHRoYXQg aW5jaWRlbnQ8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+SUQgZWZmZWN0aXZl bHkgcHJvdmlkZXMgYW4gaWRlbnRpZmllciBmb3IgdGhlIGluZGljYXRvci48bzpwPjwvbzpwPjwv cD48cCBjbGFzcz1Nc29QbGFpblRleHQ+PG86cD4mbmJzcDs8L286cD48L3A+PHAgY2xhc3M9TXNv UGxhaW5UZXh0PkFueW9uZSBlbHNlIGNhcmUgdG8gY29tbWVudD88bzpwPjwvbzpwPjwvcD48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3Ijtjb2xvcjpibGFjayc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxk aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjpibGFjayc+VGhhbmtzLDxicj4tLURhdmlk PC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyI7Y29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3Ijtjb2xvcjpibGFjayc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxk aXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGlu ZzowaW4gMGluIDBpbiA0LjBwdCc+PGRpdj48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbic+PHAgY2xh c3M9TXNvTm9ybWFsPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+IDxhIGhyZWY9 Im1haWx0bzptaWxlLWJvdW5jZXNAaWV0Zi5vcmciPm1pbGUtYm91bmNlc0BpZXRmLm9yZzwvYT4g WzxhIGhyZWY9Im1haWx0bzptaWxlLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzptaWxlLWJvdW5j ZXNAaWV0Zi5vcmc8L2E+XSA8Yj5PbiBCZWhhbGYgT2YgPC9iPk1vcmlhcnR5LCBLYXRobGVlbjxi cj48Yj5TZW50OjwvYj4gVGh1cnNkYXksIE5vdmVtYmVyIDE1LCAyMDEyIDM6NDQgUE08YnI+PGI+ VG86PC9iPiA8YSBocmVmPSJtYWlsdG86bWlsZUBpZXRmLm9yZyI+bWlsZUBpZXRmLm9yZzwvYT48 YnI+PGI+Q2M6PC9iPiBSb21hbiBELiBEYW55bGl3OyBTdG9lY2tlciwgUGF1bDxicj48Yj5TdWJq ZWN0OjwvYj4gW21pbGVdIEluY2lkZW50L0luZGljYXRvcnM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PC9kaXY+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiInPkhlbGxvLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz4mbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+SSYjODIxNztk IGxpa2UgdG8gaGVhciBzb21lIG9waW5pb25zIG9uIHRoZSB3YXkgdGhhdCBJTkNIIGFuZCBNSUxF IGhhdmUgdXNlZCBhbmQgZGVmaW5lZCB0aGUgdGVybSBpbmNpZGVudCBhbmQgaWYgd2Ugc2hvdWxk IGNoYW5nZSBvciB1cGRhdGUgdGhlIGRlZmluaXRpb24gZm9yIHRoZSB1cGRhdGUgb2YgUkZDNTA3 MC4mbmJzcDsgSSBoYXZlIGJlZW4gYXNrZWQgYSBmZXcgdGltZXMgaWYgSU9ERUYgY292ZXJzIGlu ZGljYXRvcnMuJm5ic3A7Jm5ic3A7IEZyb20gSU5DSCwgdGhlIHVuZGVyc3RhbmRpbmcgd2FzIHRo YXQgd2UgYnJvYWRseSByZWZlcnJlZCB0byBhbiBpbmNpZGVudCBhbmQgaXQgY291bGQgdXNlIElP REVGIHRvIGV4Y2hhbmdlIHNlbGVjdGVkIHBhcnRzIG9mIGFuIGluY2lkZW50IGFuZCBub3QganVz dCB0aGUgZnVsbCBpbmNpZGVudCBpbmZvcm1hdGlvbi4mbmJzcDsgVGhlIElPREVGIGZvcm1hdCBj b3VsZCBiZSB1c2VkIHRvIGVuY29tcGFzcyBhIGZ1bGwgaW5jaWRlbnQgcmVwb3J0IG9yIGp1c3Qg YSBmZXcgaGVscGZ1bCBwYXJ0cyBvZiB0aGF0IGluY2lkZW50LCB0b2RheSBjYWxsZWQgaW5kaWNh dG9ycy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIic+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiInPkFzIHdlIHN0YXJ0IGFuIFJGQzUwNzAtYmlzLCBkbyB3ZSB1cGRh dGUgdGhlIGRlZmluaXRpb24gb2YgYW4gaW5jaWRlbnQgdG8gaW5jbHVkZSB0aGlzIG5ld2VyIHRl cm0gb3IgdXNlIHRoZSB3b3JkIGluZGljYXRvciBpbiB0aGUgZG9jdW1lbnQgbW9yZT8mbmJzcDsg SGVyZSBpcyB0aGUgY3VycmVudCBpbnRlbmRlZCB1c2Ugb2YgdGhlIHRlcm0gZnJvbSBSRkM1MDcw OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiJz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIic+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiJDb3VyaWVyIE5ldyInPjEuMy4mbmJzcDsgQWJvdXQgdGhlIElPREVGIERhdGEgTW9kZWw8L3Nw YW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIic+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyInPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jm5ic3A7Jm5ic3A7IFRoZSBJT0RFRiBkYXRhIG1vZGVs IGlzIGEgZGF0YSByZXByZXNlbnRhdGlvbiB0aGF0IHByb3ZpZGVzIGE8L3NwYW4+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+ PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZuYnNw OyZuYnNwOyBmcmFtZXdvcmsgZm9yIHNoYXJpbmcgaW5mb3JtYXRpb24gY29tbW9ubHkgZXhjaGFu Z2VkIGJ5IENTSVJUcyBhYm91dDwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jm5ic3A7Jm5ic3A7IGNvbXB1dGVyIHNlY3Vy aXR5IGluY2lkZW50cy4mbmJzcDsgQSBudW1iZXIgb2YgY29uc2lkZXJhdGlvbnMgd2VyZSBtYWRl IGluPC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiInPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToi Q291cmllciBOZXciJz4mbmJzcDsmbmJzcDsgdGhlIGRlc2lnbiBvZiB0aGUgZGF0YSBtb2RlbC48 L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIic+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyInPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9k aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jm5ic3A7Jm5ic3A7IG8mbmJzcDsgVGhlIGRhdGEg bW9kZWwgc2VydmVzIGFzIGEgdHJhbnNwb3J0IGZvcm1hdC4mbmJzcDsgVGhlcmVmb3JlLCBpdHM8 L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIic+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyInPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBzcGVjaWZpYyByZXByZXNl bnRhdGlvbiBpcyBub3QgdGhlIG9wdGltYWwgcmVwcmVzZW50YXRpb24gZm9yIG9uLTwvc3Bhbj48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3 Iic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRpc2sgc3RvcmFnZSwgbG9uZy10ZXJt IGFyY2hpdmluZywgb3IgaW4tbWVtb3J5IHByb2Nlc3NpbmcuPC9zcGFuPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiInPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz4mbmJzcDs8L3Nw YW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIic+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyInPiZuYnNwOyZuYnNwOyBvJm5ic3A7IEFzIHRoZXJlIGlzIG5vIHByZWNpc2Ugd2lkZWx5 IGFncmVlZCB1cG9uIGRlZmluaXRpb24gZm9yIGFuPC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiInPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgaW5jaWRlbnQsIHRoZSBkYXRhIG1vZGVsIGRvZXMgbm90IGF0dGVtcHQg dG8gZGljdGF0ZSBvbmUgdGhyb3VnaDwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IGl0cyBpbXBsZW1lbnRhdGlvbi4mbmJzcDsgUmF0aGVyLCBhIGJyb2FkIHVuZGVyc3Rh bmRpbmcgaXMgYXNzdW1lZCBpbjwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IHRoZSBJT0RFRiB0aGF0IGlzIGZsZXhpYmxlIGVub3VnaCB0byBlbmNvbXBhc3MgbW9zdCBv cGVyYXRvcnMuPC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiInPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseToiQ291cmllciBOZXciJz4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+PG86cD48L286cD48L3Nw YW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZuYnNwOyZuYnNwOyBvJm5ic3A7 IERlc2NyaWJpbmcgYW4gaW5jaWRlbnQgZm9yIGFsbCBkZWZpbml0aW9ucyB3b3VsZCByZXF1aXJl IGFuPC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiInPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToi Q291cmllciBOZXciJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZXh0cmVtZWx5IGNv bXBsZXggZGF0YSBtb2RlbC4mbmJzcDsgVGhlcmVmb3JlLCB0aGUgSU9ERUYgb25seSBpbnRlbmRz PC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiInPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291 cmllciBOZXciJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdG8gYmUgYSBmcmFtZXdv cmsgdG8gY29udmV5IGNvbW1vbmx5IGV4Y2hhbmdlZCBpbmNpZGVudDwvc3Bhbj48c3BhbiBzdHls ZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGluZm9ybWF0aW9uLiZuYnNwOyBJdCBlbnN1cmVzIHRo YXQgdGhlcmUgYXJlIGFtcGxlIG1lY2hhbmlzbXMgZm9yPC9zcGFuPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiInPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgZXh0ZW5zaWJpbGl0eSB0byBzdXBwb3J0IG9yZ2FuaXphdGlvbi1z cGVjaWZpYyBpbmZvcm1hdGlvbiwgYW5kPC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiInPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgdGVjaG5pcXVlcyB0byByZWZlcmVuY2UgaW5mb3JtYXRpb24ga2VwdCBvdXRzaWRl IG9mIHRoZSBleHBsaWNpdDwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9k aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IGRhdGEgbW9kZWwuPC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiInPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseToiQ291cmllciBOZXciJz4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+PG86cD48L286cD48 L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZuYnNwOyZuYnNwOyBvJm5i c3A7IFRoZSBkb21haW4gb2Ygc2VjdXJpdHkgYW5hbHlzaXMgaXMgbm90IGZ1bGx5IHN0YW5kYXJk aXplZCBhbmQgbXVzdDwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHJl bHkgb24gZnJlZS1mb3JtIHRleHR1YWwgZGVzY3JpcHRpb25zLiZuYnNwOyBUaGUgSU9ERUYgYXR0 ZW1wdHMgdG88L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyInPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBzdHJpa2Ug YSBiYWxhbmNlIGJldHdlZW4gc3VwcG9ydGluZyB0aGlzIGZyZWUtZm9ybSBjb250ZW50LCB3aGls ZTwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNv dXJpZXIgTmV3Iic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHN0aWxsIGFsbG93aW5n IGF1dG9tYXRlZCBwcm9jZXNzaW5nIG9mIGluY2lkZW50IGluZm9ybWF0aW9uLjwvc3Bhbj48c3Bh biBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+ Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiInPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eToiQ291cmllciBOZXciJz4mbmJzcDsmbmJzcDsgbyZuYnNwOyBUaGUgSU9ERUYgaXMgb25seSBv bmUgb2Ygc2V2ZXJhbCBzZWN1cml0eSByZWxldmFudCBkYXRhPC9zcGFuPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiInPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgcmVwcmVzZW50YXRpb25zIGJlaW5nIHN0YW5kYXJkaXplZC4m bmJzcDsgQXR0ZW1wdHMgd2VyZSBtYWRlIHRvIGVuc3VyZTwvc3Bhbj48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz48bzpwPjwv bzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRoZXkgd2VyZSBjb21wbGltZW50YXJ5LiZuYnNwOyBUaGUgZGF0 YSBtb2RlbCBvZiB0aGUgSW50cnVzaW9uPC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiInPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgRGV0ZWN0aW9uIE1lc3NhZ2UgRXhjaGFuZ2UgRm9ybWF0IFsxN10gaW5mbHVlbmNl ZCB0aGUgZGVzaWduIG9mPC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiInPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rp dj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseToiQ291cmllciBOZXciJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg dGhlIElPREVGLjwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6IkNvdXJpZXIgTmV3Iic+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiInPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz4mbmJzcDsmbmJzcDsgRnVydGhl ciBkaXNjdXNzaW9uIG9mIHRoZSBkZXNpcmFibGUgcHJvcGVydGllcyBmb3IgdGhlIElPREVGIGNh biBiZTwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3Iic+Jm5ic3A7Jm5ic3A7IGZvdW5kIGluIHRoZSBSZXF1aXJlbWVudHMgZm9y IHRoZSBGb3JtYXQgZm9yIEluY2lkZW50IEluZm9ybWF0aW9uPC9zcGFuPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiInPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz4mbmJzcDsmbmJz cDsgRXhjaGFuZ2UgKEZJTkUpIFsxNl0uPC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiInPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+Jm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiInPlRoYW5rIHlvdSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIic+S2F0aGxlZW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+Jm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPjwvZGl2PjwvZGl2PjwvZGl2PjwvYm9keT48L2h0bWw+ --_000_D7A0423E5E193F40BE6E94126930C4930BAC6DC578MBCLUSTERxcha_-- From pkampana@cisco.com Tue Nov 20 13:24:40 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 E181921F873F for ; Tue, 20 Nov 2012 13:24:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.61 X-Spam-Level: X-Spam-Status: No, score=-6.61 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_STOCK2=3.988, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 RFDjRodAxFei for ; Tue, 20 Nov 2012 13:24:38 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 7F8F221F873D for ; Tue, 20 Nov 2012 13:24:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21213; q=dns/txt; s=iport; t=1353446678; x=1354656278; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=W7+ri/JgohSrgt9VznRzv6PRHYsNenJrd5hFaXKCKG4=; b=UutBs8m0UckQYDYZqxnca6pqFKmfGxzgM6O55ixWR93GwT53RxHW2s1J /rc9qlZkRpWTdwMr1FQhj8earTtEQUNnflyp5UmNNorn2OBOtMpolCfyO TOw2N/xxV3lGvFGNnY2uJ7u3/6zwYjHi/83f8nh3PEmQqmEzVNxB0H2ut s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAJP0q1CtJV2d/2dsb2JhbABEgknAEhZzgh4BAQEEDh84JAIBCBEEAQELFgcHMhQJCAEBBAESCIgFrxCQQYw1IIN0YQOmP4JvgVwfHg X-IronPort-AV: E=McAfee;i="5400,1158,6902"; a="144538193" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-2.cisco.com with ESMTP; 20 Nov 2012 21:24:33 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id qAKLOXUa007244 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 20 Nov 2012 21:24:33 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.192]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.02.0318.001; Tue, 20 Nov 2012 15:24:33 -0600 From: "Panos Kampanakis (pkampana)" To: "Moriarty, Kathleen" , "mile@ietf.org" Thread-Topic: Incident/Indicators Thread-Index: Ac3Dcd8ut3RC6jf7SPu5avp2hqIIjwD8zBOg Date: Tue, 20 Nov 2012 21:24:32 +0000 Message-ID: <1C9F17D1873AFA47A969C4DD98F98A750F7283@xmb-rcd-x10.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.89.106] Content-Type: multipart/alternative; boundary="_000_1C9F17D1873AFA47A969C4DD98F98A750F7283xmbrcdx10ciscocom_" MIME-Version: 1.0 Subject: Re: [mile] Incident/Indicators 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, 20 Nov 2012 21:24:41 -0000 --_000_1C9F17D1873AFA47A969C4DD98F98A750F7283xmbrcdx10ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1. I also think Indicators sound more suitable. Panos From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Mor= iarty, Kathleen Sent: Thursday, November 15, 2012 3:44 PM To: mile@ietf.org Cc: Roman D. Danyliw; Stoecker, Paul Subject: [mile] Incident/Indicators Hello, I'd like to hear some opinions on the way that INCH and MILE have used and = defined the term incident and if we should change or update the definition = for the update of RFC5070. I have been asked a few times if IODEF covers i= ndicators. From INCH, the understanding was that we broadly referred to a= n incident and it could use IODEF to exchange selected parts of an incident= and not just the full incident information. The IODEF format could be use= d to encompass a full incident report or just a few helpful parts of that i= ncident, today called indicators. As we start an RFC5070-bis, do we update the definition of an incident to i= nclude this newer term or use the word indicator in the document more? Her= e is the current intended use of the term from RFC5070: 1.3. About the IODEF Data Model The IODEF data model is a data representation that provides a framework for sharing information commonly exchanged by CSIRTs about computer security incidents. A number of considerations were made in the design of the data model. o The data model serves as a transport format. Therefore, its specific representation is not the optimal representation for on- disk storage, long-term archiving, or in-memory processing. o As there is no precise widely agreed upon definition for an incident, the data model does not attempt to dictate one through its implementation. Rather, a broad understanding is assumed in the IODEF that is flexible enough to encompass most operators. o Describing an incident for all definitions would require an extremely complex data model. Therefore, the IODEF only intends to be a framework to convey commonly exchanged incident information. It ensures that there are ample mechanisms for extensibility to support organization-specific information, and techniques to reference information kept outside of the explicit data model. o The domain of security analysis is not fully standardized and must rely on free-form textual descriptions. The IODEF attempts to strike a balance between supporting this free-form content, while still allowing automated processing of incident information. o The IODEF is only one of several security relevant data representations being standardized. Attempts were made to ensure they were complimentary. The data model of the Intrusion Detection Message Exchange Format [17] influenced the design of the IODEF. Further discussion of the desirable properties for the IODEF can be found in the Requirements for the Format for Incident Information Exchange (FINE) [16]. Thank you, Kathleen --_000_1C9F17D1873AFA47A969C4DD98F98A750F7283xmbrcdx10ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1.

I also think Indicators s= ound more suitable.

Panos

 <= /p>

 <= /p>

From: mile-bou= nces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Moriarty, Kathleen
Sent: Thursday, November 15, 2012 3:44 PM
To: mile@ietf.org
Cc: Roman D. Danyliw; Stoecker, Paul
Subject: [mile] Incident/Indicators

 

Hello,

 

I’d like to hear some opinions on= the way that INCH and MILE have used and defined the term incident and if = we should change or update the definition for the update of RFC5070.  I have been asked a few times if IODEF covers indicators.   From= INCH, the understanding was that we broadly referred to an incident and it= could use IODEF to exchange selected parts of an incident and not just the= full incident information.  The IODEF format could be used to encompass a full incident report or just a few helpful pa= rts of that incident, today called indicators.

 

As we start an RFC5070-bis, do we updat= e the definition of an incident to include this newer term or use the word = indicator in the document more?  Here is the current intended use of the term from RFC5070:

 

 

1.3.  About the IODEF Data Model<= o:p>

 

   The IODEF data model is a data representation= that provides a

   framework for sharing information commonly ex= changed by CSIRTs about

   computer security incidents.  A number o= f considerations were made in

   the design of the data model.

 

   o  The data model serves as a transport = format.  Therefore, its

      specific representation is = not the optimal representation for on-

      disk storage, long-term arc= hiving, or in-memory processing.

 

   o  As there is no precise widely agreed = upon definition for an

      incident, the data model do= es not attempt to dictate one through=

      its implementation.  R= ather, a broad understanding is assumed in

      the IODEF that is flexible = enough to encompass most operators.

 

   o  Describing an incident for all defini= tions would require an

      extremely complex data mode= l.  Therefore, the IODEF only intends

      to be a framework to convey= commonly exchanged incident

      information.  It ensur= es that there are ample mechanisms for

      extensibility to support or= ganization-specific information, and<= /p>

      techniques to reference inf= ormation kept outside of the explicit=

      data model.

 

   o  The domain of security analysis is no= t fully standardized and must

      rely on free-form textual d= escriptions.  The IODEF attempts to

      strike a balance between su= pporting this free-form content, while

      still allowing automated pr= ocessing of incident information.

 

   o  The IODEF is only one of several secu= rity relevant data

      representations being stand= ardized.  Attempts were made to ensure<= /span>

      they were complimentary.&nb= sp; The data model of the Intrusion

      Detection Message Exchange = Format [17] influenced the design of<= /p>

      the IODEF.

 

   Further discussion of the desirable propertie= s for the IODEF can be

   found in the Requirements for the Format for = Incident Information

   Exchange (FINE) [16].

 

 

Thank you,

Kathleen

 

--_000_1C9F17D1873AFA47A969C4DD98F98A750F7283xmbrcdx10ciscocom_-- From kathleen.moriarty@emc.com Tue Nov 20 15:32:11 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 650FD21F8825 for ; Tue, 20 Nov 2012 15:32:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.511 X-Spam-Level: X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599] 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 xkQzv2G+wWGL for ; Tue, 20 Nov 2012 15:32:10 -0800 (PST) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id B1CDF21F8808 for ; Tue, 20 Nov 2012 15:32:10 -0800 (PST) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id qAKNW8Nk002807 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Nov 2012 18:32:08 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd06.lss.emc.com [10.254.222.130]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Tue, 20 Nov 2012 18:31:51 -0500 Received: from mxhub01.corp.emc.com (mxhub01.corp.emc.com [10.254.141.103]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id qAKNVpna005467; Tue, 20 Nov 2012 18:31:51 -0500 Received: from mx15a.corp.emc.com ([169.254.1.120]) by mxhub01.corp.emc.com ([10.254.141.103]) with mapi; Tue, 20 Nov 2012 18:31:50 -0500 From: "Moriarty, Kathleen" To: Brian Trammell , "mile@ietf.org" Date: Tue, 20 Nov 2012 18:31:50 -0500 Thread-Topic: RFC6546 possible editorial errata Thread-Index: AQHNx3c3xJ1YhZ8C70+YoGKYshcu/Q== Message-ID: 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 Subject: [mile] RFC6546 possible editorial errata 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, 20 Nov 2012 23:32:11 -0000 Hi Brian & all, There has been some confusion by a developer on when to use a HTTP 4xx resp= onse versus the use of an HTTP 200 response with an acknowledgement. I thi= nk to get to the intent of RFC6545 and RFC6546 a proposed text fix could ad= dress this confusion and just get filed as an editorial errata: Section 3, paragraph 12: Change from: If a RID system receives an improper RID message in an HTTP Request, it MUST return an appropriate 4xx Client Error result code to the requesting RID system.=20 To: If a RID system receives an improper HTTP Request, it MUST return an appropriate 4xx Client Error result code to the requesting RID system.=20 Thoughts? Do others on the list agree with the text change? Brian, do you= agree this change more clearly states the intent? Thanks, Kathleen= From sm@resistor.net Wed Nov 21 08:07:22 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 9111C21F8675 for ; Wed, 21 Nov 2012 08:07:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.512 X-Spam-Level: X-Spam-Status: No, score=-102.512 tagged_above=-999 required=5 tests=[AWL=0.087, 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 9jT5a+r7ODpt for ; Wed, 21 Nov 2012 08:07:21 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id C14DA21F8665 for ; Wed, 21 Nov 2012 08:07:21 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id qALG7Ens001378; Wed, 21 Nov 2012 08:07:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1353514039; bh=i/LMFvWgYrcPZA88XqagC9UhDPhTCBKrC1XeIQy50Mg=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=cEyCc7LcQhKHn+Ayz7WFDqKLGTOfiB5rwAm7oO1ItVRvaGtJuDvnDZwyywp3UXM3F Iyy6SaIpycIafCoTk6uI9t7cbeSeEdGS1cv8b2WITv4X+K/3p49aTcXPI+gKiqxq+F 1wxCJdh+P4e7l/S2by55BagdQHr3AFXNrjkqU6ys= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1353514039; i=@resistor.net; bh=i/LMFvWgYrcPZA88XqagC9UhDPhTCBKrC1XeIQy50Mg=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=r2dFhnjr9d2/gfcmwIGR8jjLAJGIQTTktXsOWnKo34d/XwhCp7N2YHMOSM8JS8S7Y 1V0T24+Y0fHcAuTIdXCUfEslIRiHkVvY4LtGUA9GwQJcVIbccriHDHmaxFZEheIEvU obLN1MTBEB4I4fHBRuoCTns+ol092DFemYriuVJg= Message-Id: <6.2.5.6.2.20121121074441.09c00288@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 21 Nov 2012 08:00:28 -0800 To: "Moriarty, Kathleen" From: SM In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: mile@ietf.org Subject: Re: [mile] RFC6546 possible editorial errata 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, 21 Nov 2012 16:07:22 -0000 Hi Kathleen, At 15:31 20-11-2012, Moriarty, Kathleen wrote: >There has been some confusion by a developer on when to use a HTTP >4xx response versus the use of an HTTP 200 response with an >acknowledgement. I think to get to the intent of RFC6545 and >RFC6546 a proposed text fix could address this confusion and just >get filed as an editorial errata: > >Section 3, paragraph 12: >Change from: >If a RID system receives an improper RID message in an HTTP Request, > it MUST return an appropriate 4xx Client Error result code to the > requesting RID system. > >To: >If a RID system receives an improper HTTP Request, > it MUST return an appropriate 4xx Client Error result code to the > requesting RID system. The above suggested text changes the RFC 2119 requirement. I wouldn't consider it as editorial as the intent is debatable if there wasn't any (prior) discussion to support it. BTW, the requirement is similar to the one in the sentence that follows the one quoted above. Regards, -sm From kathleen.moriarty@emc.com Wed Nov 21 08:25: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 41E1921F8721 for ; Wed, 21 Nov 2012 08:25:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.521 X-Spam-Level: X-Spam-Status: No, score=-2.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599] 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 VsDBOZLWfXFn for ; Wed, 21 Nov 2012 08:25:49 -0800 (PST) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 7733721F8717 for ; Wed, 21 Nov 2012 08:25:49 -0800 (PST) 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 qALGPlsg000397 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Nov 2012 11:25:48 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd02.lss.emc.com [10.254.221.253]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Wed, 21 Nov 2012 11:25:40 -0500 Received: from mxhub19.corp.emc.com (mxhub19.corp.emc.com [10.254.93.48]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id qALGPd4W001745; Wed, 21 Nov 2012 11:25:40 -0500 Received: from mx15a.corp.emc.com ([169.254.1.120]) by mxhub19.corp.emc.com ([10.254.93.48]) with mapi; Wed, 21 Nov 2012 11:25:39 -0500 From: "Moriarty, Kathleen" To: SM Date: Wed, 21 Nov 2012 11:21:17 -0500 Thread-Topic: [mile] RFC6546 possible editorial errata Thread-Index: Ac3IAmdSUK+z8hqsRIC2MQroHYdyHQAAdTg8 Message-ID: References: , <6.2.5.6.2.20121121074441.09c00288@resistor.net> In-Reply-To: <6.2.5.6.2.20121121074441.09c00288@resistor.net> 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" Subject: Re: [mile] RFC6546 possible editorial errata 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, 21 Nov 2012 16:25:50 -0000 SM, Thanks for the review! Here is the text that SM is referring to: "If a RID system receives an improper RID message in an HTTP Request, it MUST return an appropriate 4xx Client Error result code to the requesting RID system. If a RID system cannot process a RID message received in an HTTP Request due to an error on its own side, it MUST return an appropriate 5xx Server Error result code to the requesting RID system." I agree that the text is confusing as one developer interpreted it to apply= to the RID messages and another interpreted it as applying to HTTP since t= he codes are specific to HTTP and not the application layer. I believe the= intent was that it applied to the HTTP error level as this document was fo= cused on transport. I see your point that this may be a technical change. = The following sentence has the same problem, do you agree with the assessm= ent and what do others think? Thanks, Kathleen ________________________________________ From: SM [sm@resistor.net] Sent: Wednesday, November 21, 2012 11:00 AM To: Moriarty, Kathleen Cc: mile@ietf.org Subject: Re: [mile] RFC6546 possible editorial errata Hi Kathleen, At 15:31 20-11-2012, Moriarty, Kathleen wrote: >There has been some confusion by a developer on when to use a HTTP >4xx response versus the use of an HTTP 200 response with an >acknowledgement. I think to get to the intent of RFC6545 and >RFC6546 a proposed text fix could address this confusion and just >get filed as an editorial errata: > >Section 3, paragraph 12: >Change from: >If a RID system receives an improper RID message in an HTTP Request, > it MUST return an appropriate 4xx Client Error result code to the > requesting RID system. > >To: >If a RID system receives an improper HTTP Request, > it MUST return an appropriate 4xx Client Error result code to the > requesting RID system. The above suggested text changes the RFC 2119 requirement. I wouldn't consider it as editorial as the intent is debatable if there wasn't any (prior) discussion to support it. BTW, the requirement is similar to the one in the sentence that follows the one quoted above. Regards, -sm From sm@resistor.net Wed Nov 21 09:46:55 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 17B3521F84D4 for ; Wed, 21 Nov 2012 09:46:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.894 X-Spam-Level: X-Spam-Status: No, score=-101.894 tagged_above=-999 required=5 tests=[AWL=-0.535, BAYES_00=-2.599, SARE_LWSHORTT=1.24, 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 XYWg7lEEH4AJ for ; Wed, 21 Nov 2012 09:46:54 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8619B21F84CF for ; Wed, 21 Nov 2012 09:46:54 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id qALHklEo026260; Wed, 21 Nov 2012 09:46:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1353520012; bh=HuBYo3Hksm9LVHvz4eQVd0VkzpdrMwKwyX+CS7yQKLQ=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=rusjbyI1lmcDbymx2wr/b5HrAmiYtltb/J+hYCTq4/Bl5x26EKs5QMbYtS0tyPii9 BH4QgqVhfFHEAiX6DwK2pin9K/DDsV2Kb3FvjbH7BhNwrycmG6Fwi/NhdQXP3hh+rs +0+h2PctUXlRapgF2o3RX0aSeAUVxSPID2OSfuM4= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1353520012; i=@resistor.net; bh=HuBYo3Hksm9LVHvz4eQVd0VkzpdrMwKwyX+CS7yQKLQ=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=v0WnsUIS9zpfCTPYCjzYRruvmmrkjXYcG93twmma7aweFpWI01ngm54NbBkR1hOhr /GmLVeMMgMZ6llee2AjlxfkfQRSxY6hi1aRYa9Jis5jtqFcmGdd/3AONUAhMU32/L6 iwy/6INFY98Zs+IDpxi110c5CfyEmGY4fGGVtGbQ= Message-Id: <6.2.5.6.2.20121121083351.0b0aac58@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 21 Nov 2012 09:40:19 -0800 To: "Moriarty, Kathleen" From: SM In-Reply-To: References: <6.2.5.6.2.20121121074441.09c00288@resistor.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: mile@ietf.org Subject: Re: [mile] RFC6546 possible editorial errata 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, 21 Nov 2012 17:46:55 -0000 Hi Kathleen, At 08:21 21-11-2012, Moriarty, Kathleen wrote: >Thanks for the review! Here is the text that SM is referring to: > >"If a RID system receives an improper RID message in an HTTP Request, > it MUST return an appropriate 4xx Client Error result code to the > requesting RID system. If a RID system cannot process a RID message > received in an HTTP Request due to an error on its own side, it MUST > return an appropriate 5xx Server Error result code to the requesting > RID system." > >I agree that the text is confusing as one developer interpreted it >to apply to the RID messages and another interpreted it as applying >to HTTP since the codes are specific to HTTP and not the application >layer. I believe the intent was that it applied to the HTTP error >level as this document was focused on transport. I see your point >that this may be a technical change. The following sentence has the >same problem, do you agree with the assessment and what do others think? I read Brian Trammell's response to a review of the draft [1]. I vaguely recall a discussion about not redefining HTTP status codes (see RFC 3205). I could explain the text which you quoted above as follows: If a RID system receives an improper RID message it MUST return an appropriate 4xx Client Error result code The confusion might be from the following text in RFC 6546: "Note that HTTP provides no mechanism for signaling to a server that a response body is not a valid RID message. If a RID system receives an improper RID message in an HTTP Response, or cannot process a RID message received in an HTTP Response due to an error on its own side, it MUST log the error and present it to the RID system administrator for handling; the error logging format is an implementation detail and is considered out of scope for this specification." My explanation may be wrong as it depends on how I read the first sentence quoted above. This is not the first time there was confusion about the HTTP codes [2]. I suggest removing the two RFC 2119 requirements and adding a pointer to the relevant section of RFC 2616. In the short term an erratum could be filed with the argument you made about transport. I suggest having an informal discussion with the Responsible AD first as he can provide better advice about this issue. Regards, -sm 1. http://www.ietf.org/mail-archive/web/apps-discuss/current/msg03942.html 2. http://www.ietf.org/mail-archive/web/mile/current/msg00716.html From david.waltermire@nist.gov Wed Nov 21 15:46:04 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 49D1421E8041 for ; Wed, 21 Nov 2012 15:46:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.974 X-Spam-Level: X-Spam-Status: No, score=-5.974 tagged_above=-999 required=5 tests=[AWL=0.625, 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 ddBfTl4xV9VL for ; Wed, 21 Nov 2012 15:46:03 -0800 (PST) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 6300221F8455 for ; Wed, 21 Nov 2012 15:46:02 -0800 (PST) Received: from WSXGHUB2.xchange.nist.gov (129.6.18.19) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.2.318.4; Wed, 21 Nov 2012 18:45:55 -0500 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Wed, 21 Nov 2012 18:44:11 -0500 From: "Waltermire, David A." To: "Moriarty, Kathleen" , SM Date: Wed, 21 Nov 2012 18:46:00 -0500 Thread-Topic: [mile] RFC6546 possible editorial errata Thread-Index: Ac3IAmdSUK+z8hqsRIC2MQroHYdyHQAAdTg8AA7cWyA= Message-ID: References: , <6.2.5.6.2.20121121074441.09c00288@resistor.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Cc: "mile@ietf.org" Subject: Re: [mile] RFC6546 possible editorial errata 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, 21 Nov 2012 23:46:04 -0000 The document is focused on applying the HTTP transport to define an application-layer protocol for RID (at least according to the abstract), so to some extent it has its feet on both sides of the fence. ;-) If the text is changed it might clarify what to do in the case of an invalid HTTP request at the transport layer. In doing so, wouldn't we then be introducing the same ambiguity at the application layer for an invalid RID message? In this case it would be undefined as to what to do if you have a valid HTTP request from a transport perspective with an invalid RID message from an application perspective. It might make sense instead to change it to: "If a RID system receives an improper HTTP Request or an improper RID message in a valid HTTP Request, it MUST return an appropriate 4xx Client Error result code to the requesting RID system." Something like this would cover both cases making it clear to both developers. Happy Thanksgiving to those celebrating! Sincerely, Dave -----Original Message----- From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Moriarty, Kathleen Sent: Wednesday, November 21, 2012 11:21 AM To: SM Cc: mile@ietf.org Subject: Re: [mile] RFC6546 possible editorial errata SM, Thanks for the review! Here is the text that SM is referring to: "If a RID system receives an improper RID message in an HTTP Request, it MUST return an appropriate 4xx Client Error result code to the requesting RID system. If a RID system cannot process a RID message received in an HTTP Request due to an error on its own side, it MUST return an appropriate 5xx Server Error result code to the requesting RID system." I agree that the text is confusing as one developer interpreted it to apply to the RID messages and another interpreted it as applying to HTTP since the codes are specific to HTTP and not the application layer. I believe the intent was that it applied to the HTTP error level as this document was focused on transport. I see your point that this may be a technical change. The following sentence has the same problem, do you agree with the assessment and what do others think? Thanks, Kathleen ________________________________________ From: SM [sm@resistor.net] Sent: Wednesday, November 21, 2012 11:00 AM To: Moriarty, Kathleen Cc: mile@ietf.org Subject: Re: [mile] RFC6546 possible editorial errata Hi Kathleen, At 15:31 20-11-2012, Moriarty, Kathleen wrote: >There has been some confusion by a developer on when to use a HTTP 4xx >response versus the use of an HTTP 200 response with an >acknowledgement. I think to get to the intent of RFC6545 and >RFC6546 a proposed text fix could address this confusion and just get >filed as an editorial errata: > >Section 3, paragraph 12: >Change from: >If a RID system receives an improper RID message in an HTTP Request, > it MUST return an appropriate 4xx Client Error result code to the > requesting RID system. > >To: >If a RID system receives an improper HTTP Request, > it MUST return an appropriate 4xx Client Error result code to the > requesting RID system. The above suggested text changes the RFC 2119 requirement. I wouldn't consider it as editorial as the intent is debatable if there wasn't any (prior) discussion to support it. BTW, the requirement is similar to the one in the sentence that follows the one quoted above. Regards, -sm _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile From kathleen.moriarty@emc.com Wed Nov 21 18:22:16 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 F1B5A21E8053 for ; Wed, 21 Nov 2012 18:22:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599] 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 gETfiWfDXI8F for ; Wed, 21 Nov 2012 18:22:16 -0800 (PST) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 36D0221E8051 for ; Wed, 21 Nov 2012 18:22:15 -0800 (PST) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id qAM2MDrC004439 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Nov 2012 21:22:13 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd04.lss.emc.com [10.254.222.226]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Wed, 21 Nov 2012 21:21:50 -0500 Received: from mxhub35.corp.emc.com (mxhub35.corp.emc.com [10.254.93.83]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id qAM2Lnxe023253; Wed, 21 Nov 2012 21:21:49 -0500 Received: from mx15a.corp.emc.com ([169.254.1.120]) by mxhub35.corp.emc.com ([::1]) with mapi; Wed, 21 Nov 2012 21:21:49 -0500 From: "Moriarty, Kathleen" To: "Waltermire, David A." , SM Date: Wed, 21 Nov 2012 21:21:48 -0500 Thread-Topic: [mile] RFC6546 possible editorial errata Thread-Index: Ac3IAmdSUK+z8hqsRIC2MQroHYdyHQAAdTg8AA7cWyAABcppsA== Message-ID: References: , <6.2.5.6.2.20121121074441.09c00288@resistor.net> , 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" Subject: Re: [mile] RFC6546 possible editorial errata 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, 22 Nov 2012 02:22:17 -0000 Hi Dave, Thanks for taking a look at this as well! At the application layer, you have the ability to figure out what is wrong = with the RID/IODEF document and provide a response with details via the Ack= nowledgement message. This would be in a 200 HTTP code according to the ta= ble and then the 'Justification' can be set appropriately (xml encryption e= rror, xml schema error, etc.). As a result, the language in the sentences = provided is causing some confusion. I should have provided that context in= the initial message. Does the additional context change your view? I thi= nk it would be easier for developers (and meet the intended objective with = the language change, but it may be technical and not editorial). Does that= change your view? =20 Anyone other thoughts from the list? Thanks, Kathleen ________________________________________ From: Waltermire, David A. [david.waltermire@nist.gov] Sent: Wednesday, November 21, 2012 6:46 PM To: Moriarty, Kathleen; SM Cc: mile@ietf.org Subject: RE: [mile] RFC6546 possible editorial errata The document is focused on applying the HTTP transport to define an applica= tion-layer protocol for RID (at least according to the abstract), so to som= e extent it has its feet on both sides of the fence. ;-) If the text is changed it might clarify what to do in the case of an invali= d HTTP request at the transport layer. In doing so, wouldn't we then be in= troducing the same ambiguity at the application layer for an invalid RID me= ssage? In this case it would be undefined as to what to do if you have a v= alid HTTP request from a transport perspective with an invalid RID message = from an application perspective. It might make sense instead to change it = to: "If a RID system receives an improper HTTP Request or an improper RID messa= ge in a valid HTTP Request, it MUST return an appropriate 4xx Client Error= result code to the requesting RID system." Something like this would cover both cases making it clear to both develope= rs. Happy Thanksgiving to those celebrating! Sincerely, Dave -----Original Message----- From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Mor= iarty, Kathleen Sent: Wednesday, November 21, 2012 11:21 AM To: SM Cc: mile@ietf.org Subject: Re: [mile] RFC6546 possible editorial errata SM, Thanks for the review! Here is the text that SM is referring to: "If a RID system receives an improper RID message in an HTTP Request, it MUST return an appropriate 4xx Client Error result code to the requesting RID system. If a RID system cannot process a RID message received in an HTTP Request due to an error on its own side, it MUST return an appropriate 5xx Server Error result code to the requesting RID system." I agree that the text is confusing as one developer interpreted it to apply= to the RID messages and another interpreted it as applying to HTTP since t= he codes are specific to HTTP and not the application layer. I believe the= intent was that it applied to the HTTP error level as this document was fo= cused on transport. I see your point that this may be a technical change. = The following sentence has the same problem, do you agree with the assessm= ent and what do others think? Thanks, Kathleen ________________________________________ From: SM [sm@resistor.net] Sent: Wednesday, November 21, 2012 11:00 AM To: Moriarty, Kathleen Cc: mile@ietf.org Subject: Re: [mile] RFC6546 possible editorial errata Hi Kathleen, At 15:31 20-11-2012, Moriarty, Kathleen wrote: >There has been some confusion by a developer on when to use a HTTP 4xx >response versus the use of an HTTP 200 response with an >acknowledgement. I think to get to the intent of RFC6545 and >RFC6546 a proposed text fix could address this confusion and just get >filed as an editorial errata: > >Section 3, paragraph 12: >Change from: >If a RID system receives an improper RID message in an HTTP Request, > it MUST return an appropriate 4xx Client Error result code to the > requesting RID system. > >To: >If a RID system receives an improper HTTP Request, > it MUST return an appropriate 4xx Client Error result code to the > requesting RID system. The above suggested text changes the RFC 2119 requirement. I wouldn't cons= ider it as editorial as the intent is debatable if there wasn't any (prior)= discussion to support it. BTW, the requirement is similar to the one in the sentence that follows the= one quoted above. Regards, -sm _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile From chatlga2000@yahoo.com Wed Nov 21 19:08:14 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 3A33121E8053 for ; Wed, 21 Nov 2012 19:08:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.12 X-Spam-Level: * X-Spam-Status: No, score=1.12 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_60=1, HTML_MESSAGE=0.001, RCVD_IN_SORBS_WEB=0.619] 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 t+43UaxbJzuT for ; Wed, 21 Nov 2012 19:08:13 -0800 (PST) Received: from nm7.bullet.mail.ne1.yahoo.com (nm7.bullet.mail.ne1.yahoo.com [98.138.90.70]) by ietfa.amsl.com (Postfix) with ESMTP id A2D9721E8048 for ; Wed, 21 Nov 2012 19:08:13 -0800 (PST) Received: from [98.138.90.52] by nm7.bullet.mail.ne1.yahoo.com with NNFMP; 22 Nov 2012 03:08:07 -0000 Received: from [98.138.226.166] by tm5.bullet.mail.ne1.yahoo.com with NNFMP; 22 Nov 2012 03:08:07 -0000 Received: from [127.0.0.1] by omp1067.mail.ne1.yahoo.com with NNFMP; 22 Nov 2012 03:08:07 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 93138.31877.bm@omp1067.mail.ne1.yahoo.com Received: (qmail 56529 invoked by uid 60001); 22 Nov 2012 03:08:07 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1353553687; bh=7oIapLFsgCifCV8yaUtJGp3k+BMlDPajX88SPyuU8ZA=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=SYE1VwctnNzJDq4vfM24YjjNMmHxMMTsX1XkAUmUmqN5ELOxgW84I/pKKLbFrWnQh27igokEGPRonFjdCMZ2Vwky4UwM6VVPqtTU2R/v9wE+TfMWCrzE1beCBwnqHHh5ajLD/OPYNEGrlz3Q6OCM9Z6HZl7npqjgjkpTyV1gj+I= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=FypB1wnUjgTCZZ44p/3eQhGT4Af+WJKDGN5HV2mMNSl9F/xEKfXqcpjRbR0GivCzSp1v1lIgnWx/8Jq2J63dW8SswFFPilAROxsZdzZ1BL181iV2+1E8joz995sim5PQXX8YEVNgTTVQYwLzLi/juPrFHpurNW8lDYXM/kakjx0=; X-YMail-OSG: PVaUQAYVM1kb4xje9dqcOkfSUqQTbXdfArXt8ZsQwhYwBW9 Nd_dy7ICLhyPFBPbwP5LTIx7dV0lHJ80fkdWb0JDrbI2.czujxQ..4mqjz0q ha04dIY_bwFLWDYIovzi1FVvfsNgbuBcDV_Zt_UFCwgOQq3PO7PPvs5fNFjZ 0L40LwmVXcvfRX_n3_0Nk0a18XUoJLTwtX2vtDGZFsiO4qt02aIp8YG1oKvX C4n5XdVaRs.FrqI43hNCE5CcHmX1iuqHHh3z3LXkb_oTdEQtaMzgj5d0X2uo i7O1njwNZJiiSUIiZpjAxllHDyJFNsGfsqx2aCoCMcv6kltckYOhfTLMsc35 d7hN4NYDl4iH5MjaX5xCCVlRHoYi0ZZSfonGlgi04tV8lcMtgqF.qtwdsbYW 9wyFy9mGZfUgNROdvfIqlDfZ2zzGwa8PCIVfty_jQWeeJ_hvIyCN1z2t0mve mNskmUvuDgTJauR2Fe7g_tglBMDA_ifrqqWE_ibqz.a6E.VH6BY1c2Q-- Received: from [166.216.160.112] by web121604.mail.ne1.yahoo.com via HTTP; Wed, 21 Nov 2012 19:08:06 PST X-Rocket-MIMEInfo: 001.001, SSB3b3VsZCB0ZW5kIHRvIHRoaW5rIGl0IHdvdWxkIGJlIHZlcnkgaGVscGZ1bCB0byBvdXRsaW5lIHRoZSAibmV3IiBkZWZpbml0aW9uIG9mIHRoZSB0ZXJtImluZGljYXRvciIgYW5kIHV0aWxpemUgdGhlIHdvcmQgdGhyb3VnaG91dCB0aGUgZG9jdW1lbnQgYXMgaXQgcGVydGFpbi4gRnVydGhlcm1vcmUsIGlmIHNvbWUgZXhhbXBsZSBvciBzY2VuYXJpbyBvZiBpdHMgdXNhZ2UgY291bGQgYWxzbyBiZSBhcHBsaWVkIHRoYXQgbWlnaHQgYmUgdXNlZnVsIGFzIHdlbGwuDQoNCg0KDQoNCkMuIEhlbnJ5IEFkYW0BMAEBAQE- X-Mailer: YahooMailClassic/15.0.8 YahooMailWebService/0.8.123.460 Message-ID: <1353553686.55749.YahooMailClassic@web121604.mail.ne1.yahoo.com> Date: Wed, 21 Nov 2012 19:08:06 -0800 (PST) From: "C. Henry Adams & BIE" To: MILE IETF MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-36511695-299609161-1353553686=:55749" Cc: "C. Henry Adams" Subject: [mile] Incident/Indicators Comment 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, 22 Nov 2012 03:08:14 -0000 ---36511695-299609161-1353553686=:55749 Content-Type: text/plain; charset=us-ascii I would tend to think it would be very helpful to outline the "new" definition of the term"indicator" and utilize the word throughout the document as it pertain. Furthermore, if some example or scenario of its usage could also be applied that might be useful as well. C. Henry Adams chatlga2000@yahoo.com (Direct Email) chenryadams@biemediagroup.com ---36511695-299609161-1353553686=:55749 Content-Type: text/html; charset=us-ascii
I would tend to think it would be very helpful to outline the "new" definition of the term"indicator" and utilize the word throughout the document as it pertain. Furthermore, if some example or scenario of its usage could also be applied that might be useful as well.




C. Henry Adams
chatlga2000@yahoo.com (Direct Email)
chenryadams@biemediagroup.com

---36511695-299609161-1353553686=:55749-- From chatlga2000@yahoo.com Fri Nov 23 07:37:22 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 4E4B321F8576 for ; Fri, 23 Nov 2012 07:37:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.001 X-Spam-Level: ** X-Spam-Status: No, score=2.001 tagged_above=-999 required=5 tests=[BAYES_80=2, HTML_MESSAGE=0.001] 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 kEm7kEUWuDrX for ; Fri, 23 Nov 2012 07:37:21 -0800 (PST) Received: from nm25-vm4.bullet.mail.ne1.yahoo.com (nm25-vm4.bullet.mail.ne1.yahoo.com [98.138.91.185]) by ietfa.amsl.com (Postfix) with ESMTP id B81C621F856C for ; Fri, 23 Nov 2012 07:37:21 -0800 (PST) Received: from [98.138.226.177] by nm25.bullet.mail.ne1.yahoo.com with NNFMP; 23 Nov 2012 15:37:18 -0000 Received: from [98.138.87.12] by tm12.bullet.mail.ne1.yahoo.com with NNFMP; 23 Nov 2012 15:37:18 -0000 Received: from [127.0.0.1] by omp1012.mail.ne1.yahoo.com with NNFMP; 23 Nov 2012 15:37:18 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 786550.83470.bm@omp1012.mail.ne1.yahoo.com Received: (qmail 25765 invoked by uid 60001); 23 Nov 2012 15:37:18 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1353685038; bh=4BOfkgrLnJhEqjlyAhi3b8Tez19ufqbjZ5lB+ppXHdk=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=J6esAHbZ8eyw8Jm+rBra0oUDhWCyB7s4E7j+FH/K1gvT8zkLN6jRj7DiBIPZRytsPhkPLrM3k27s4vXHGjY1XPihZczXAACsxAHWx8avX7PTNRQkVg1mT+VCh5SBXLh4xDvhMEhzumkWnhkPicH70LpOgB0ra+dDltuW4jXZPec= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=K2x/jpzmFvmyi2lRpgTy1yba31gGrC3GsbRUDbIe+LBB6zgxoCk6df9v2Fh31cG62vlDoOstCY6tYPP8Fv+s8ky7+LKIs90u3VRSsC2gIWMaVryZnrN+u0vutMDuLndPcYMLhT7NZJ0OSAn7S4jj5SesTNheN00XbpgPQFKKC+c=; X-YMail-OSG: sA3_jUsVM1lLRfllisQIDQcJXRIAHOPU0sdCJgwnnldaiUR feTCtRE4keI86Ge324vuxorJ089gylvw2yAyVcYj6RZ4H1r0HxT9NThG3Y1m hQNJvKze39naEEYfg3e32Odq4iQ.dVWH9pUyy._DcCZMHRgAIhTpyQTg7Fho ErVb74PhUANmNZuqSBcCYTd_s.M8ROlPjmqfupvYsRob9mwqFnkE80MhPcxV bDH8od7FOpD2fcSVTVf.hymPhxPZKqJjQkheT4p2kkXGcLwJkcDUIcTwSoLt uKDdfIx8Bb4g7fGAMnUMel5Z37jrTiPIxG8Z_c01IZ1w6_BmgB9MmiHZkq9r fWEQZGBOWg7nVw0wu0YQi2fJ5WC4oM3u0zzSnOasXlAlpfJDqnAG6hGkj7l6 y29MfVyfdfYAXMEAe7cuychJ27yzj9gLaYa2MIIJJaaQV3oukBDYAbv5iPeI l5y35HuIh4YfeOdl02MvAhbLmsZexhblwdGann5Hdh5lb9eSzbwg- Received: from [209.183.34.49] by web121603.mail.ne1.yahoo.com via HTTP; Fri, 23 Nov 2012 07:37:18 PST X-Rocket-MIMEInfo: 001.001, QWZ0ZXIgZnVydGhlciByZXZpZXcsIEkgYWdyZWUgdGhhdCB0aGUgc3RhdGVtZW50IGFwcGVhcnMgdG8gYmUgaW4gCmVycm9yLsKgwqAgVGhlcmUgYXJlIGEgbnVtYmVyIG9mIHZhcmlhYmxlcyAoVHlwZXMgb2YgRXJyb3JzKSB0aGF0IGNvdWxkIGJlCiBhcHBsaWVkIHdoZW4gaXQgY29tZXMgdG8gSFRUUCBFcnJvciBDb2Rlcy4gVGh1cywgdGhlIHJlc3VsdHMgb2Ygc2VuZGluZwogYSByZXF1ZXN0IHRvIGEgUklEIFN5c3RlbSBmcm9tIGEgY2xpZW50IHNob3VsZCBub3QgcmVsYXRlIHRvIHRoZSAKZmFpbHVyZSABMAEBAQE- X-Mailer: YahooMailClassic/15.0.8 YahooMailWebService/0.8.123.460 Message-ID: <1353685038.16524.YahooMailClassic@web121603.mail.ne1.yahoo.com> Date: Fri, 23 Nov 2012 07:37:18 -0800 (PST) From: "C. Henry Adams & BIE" To: MILE IETF MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1682663710-1337657993-1353685038=:16524" Cc: "C. Henry Adams" Subject: Re: [mile] RFC6546 possible editorial errata 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, 23 Nov 2012 15:37:22 -0000 ---1682663710-1337657993-1353685038=:16524 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable After further review, I agree that the statement appears to be in =0Aerror.= =A0=A0 There are a number of variables (Types of Errors) that could be=0A a= pplied when it comes to HTTP Error Codes. Thus, the results of sending=0A a= request to a RID System from a client should not relate to the =0Afailure = or malfunction of the RID System itself. The statement =0Ashould not relate HTTP Error Codes to a failing RID System= with internal=0A issues. Perhaps the statement should identify External an= d Internal =0AErrors related a RID System to some capacity. C. Henry Adams =0Achatlga2000@yahoo.com (Direct Email) =0Achenryadams@biemediagroup.com ---1682663710-1337657993-1353685038=:16524 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
After further review, I agree that the statem= ent appears to be in =0Aerror.   There are a number of variables = (Types of Errors) that could be=0A applied when it comes to HTTP Error Code= s. Thus, the results of sending=0A a request to a RID System from a client = should not relate to the =0Afailure or malfunction of the RID System itself= .

The statement =0Ashould not relate HTTP Error Codes to a failing R= ID System with internal=0A issues. Perhaps the statement should identify Ex= ternal and Internal =0AErrors related a RID System to some capacity.



C. Henry Adams
=0Achatlga2000@yahoo.com (Direct Email)
= =0Achenryadams@biemediagroup.com
---1682663710-1337657993-1353685038=:16524-- From chatlga2000@yahoo.com Fri Nov 23 08:04:41 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 4925F21F8539 for ; Fri, 23 Nov 2012 08:04:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.501 X-Spam-Level: ** X-Spam-Status: No, score=2.501 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_95=3, HTML_MESSAGE=0.001] 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 aQy2efUUBOGc for ; Fri, 23 Nov 2012 08:04:40 -0800 (PST) Received: from nm4.bullet.mail.ne1.yahoo.com (nm4.bullet.mail.ne1.yahoo.com [98.138.90.67]) by ietfa.amsl.com (Postfix) with ESMTP id 9E8A421F8533 for ; Fri, 23 Nov 2012 08:04:40 -0800 (PST) Received: from [98.138.90.55] by nm4.bullet.mail.ne1.yahoo.com with NNFMP; 23 Nov 2012 16:04:35 -0000 Received: from [98.138.89.168] by tm8.bullet.mail.ne1.yahoo.com with NNFMP; 23 Nov 2012 16:04:35 -0000 Received: from [127.0.0.1] by omp1024.mail.ne1.yahoo.com with NNFMP; 23 Nov 2012 16:04:35 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 400347.1919.bm@omp1024.mail.ne1.yahoo.com Received: (qmail 61722 invoked by uid 60001); 23 Nov 2012 16:04:35 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1353686675; bh=bRAOCgtmgCVC0ZLlE3FO4/+LKYQG8R8yLBuQu0LnU9A=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=GzoSOyXGMvqzudVlzM0uhWluAz+zl1hr5PIXN0obuD7o011EN07MNuyqjvBb6BkB3C0DJE0yYH7qYFK4Y2GzvE94OK1PX/Pm60k55noaTYyEZtJdxq2z8O0NuYbTHfsv29cbHi7WbT2QsRkgqJxlXG64MSYspdAmPIcVgSydmNk= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=VKEmNLEYApgKR9rOgaEft2oIMCtxPuAj1rJJXW6AU/I0FXL14GRkgjh34u4RUqIOvBswFrXLHPpmQ5Yr27ANzuF2Wl4EVN7kLY8HYr7XYlf4sCAgoaLwxdAiwNeUATghPoPAKJc++mkl9YirZHPmA47DRFaZ+FiAyyxPnsluuwQ=; X-YMail-OSG: QlQVvZ4VM1nUumToB6azP1XCP5T8j5Q70W6rjWEpgsgBjPa LJs21kkr4aGJ.9x.Q5AGLVJsITpu9wuPaM2K00owC__e3MA5RCuIadNHxFio UtH3iq5t.C4wER7d9auZqxXlJcWYBGahNq582Oes3u3Hd1oYgAEHFT0gX.tP NB_oo_6E2.SjhfUeA2nXwT1li_pD4v8y0hlMVc93gIm9xhKy6ddNjaQj3TaH 6jz8FfZtWJWauT59.rVpSFqGieShMIjpoaO1uNqhrkJTNsAV8h0hbeiJ3mZe Z3OyeA62UcBjxTEkEiH2i53QwVEiZnSkc3hzm0TPMlnqEn_IIYZtWbKaoWmq YyN1LhB5z1nH1mBh888gFkGHy6W0bHr4dq1EFMTwS8LR7GF6H4ANUDIRbkZE p3FVgWd0g0tOVkfig.CU37rI5E_pE5qgui18h7qgSlsHI8E1p1Rq2lDdd.BC 74oaGtN4y1_BO4P2yh4oZ1QPS273a_zPvoD26S6fxSPSqwc5D1.0- Received: from [209.183.34.49] by web121603.mail.ne1.yahoo.com via HTTP; Fri, 23 Nov 2012 08:04:34 PST X-Rocket-MIMEInfo: 001.001, V2FpdC1hLW1pbnV0ZS7CoMKgIFRoZSBvbmx5IHRpbWUgb25lIG9ic2VydmVzIEhUVFAgNDAwLTQwNCBFcnJvciBDb2RlcyBpcyB3aGVuIHRoZSBDbGllbnQgaXMgc2VuZGluZyBhIHJlcXVlc3QgdG8gc2F5IGEgIiB3ZWIgc2l0ZSAiLsKgwqAgU28sIHJlcGxhY2luZyB0aGUgIndlYiBzaXRlIiB3aXRoIFJJRCBTeXN0ZW0sIHRoZSBlcnJvciB3aWxsIGxpa2VseSBiZSBvYnNlcnZlZCBmcm9tIHRoZSBDbGllbnQncyBTaWRlIG5vdCB0aGUgU2VydmVyJ3MgU2lkZS4NCg0KRnVydGhlcm1vcmUsIHRoaXMgd291bGQBMAEBAQE- X-Mailer: YahooMailClassic/15.0.8 YahooMailWebService/0.8.123.460 Message-ID: <1353686674.58199.YahooMailClassic@web121603.mail.ne1.yahoo.com> Date: Fri, 23 Nov 2012 08:04:34 -0800 (PST) From: "C. Henry Adams & BIE" To: MILE IETF MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1682663710-1015273370-1353686674=:58199" Cc: "C. Henry Adams" Subject: Re: [mile] RFC6546 possible editorial errata 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, 23 Nov 2012 16:04:41 -0000 ---1682663710-1015273370-1353686674=:58199 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Wait-a-minute.=A0=A0 The only time one observes HTTP 400-404 Error Codes is= when the Client is sending a request to say a " web site ".=A0=A0 So, repl= acing the "web site" with RID System, the error will likely be observed fro= m the Client's Side not the Server's Side. Furthermore, this would likely apply to HTTP 500-510 Error Codes as well. The RID System will not see the HTTP Error Codes period.=A0 The Client will= see and experience them. C. Henry Adams =0Achatlga2000@yahoo.com (Direct Email) =0Achenryadams@biemediagroup.com =0A ---1682663710-1015273370-1353686674=:58199 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Wait-a-minute.   The only time one = observes HTTP 400-404 Error Codes is when the Client is sending a request t= o say a " web site ".   So, replacing the "web site" with RID Sys= tem, the error will likely be observed from the Client's Side not the Serve= r's Side.

Furthermore, this would likely apply to HTTP 500-510 Error= Codes as well.

The RID System will not see the HTTP Error Codes per= iod.  The Client will see and experience them.


C. Henry Ada= ms
=0Achatlga2000@yahoo.com (Direct Email)
=0Achenryadams@biemediagro= up.com
=0A
---1682663710-1015273370-1353686674=:58199-- From chatlga2000@yahoo.com Fri Nov 23 08:39: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 CE66021F84E1 for ; Fri, 23 Nov 2012 08:39:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.871 X-Spam-Level: X-Spam-Status: No, score=0.871 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_SORBS_WEB=0.619] 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 FWU9i8FsotcH for ; Fri, 23 Nov 2012 08:39:43 -0800 (PST) Received: from nm1-vm1.bullet.mail.ne1.yahoo.com (nm1-vm1.bullet.mail.ne1.yahoo.com [98.138.91.36]) by ietfa.amsl.com (Postfix) with ESMTP id 11A0B21F84DE for ; Fri, 23 Nov 2012 08:39:43 -0800 (PST) Received: from [98.138.90.50] by nm1.bullet.mail.ne1.yahoo.com with NNFMP; 23 Nov 2012 16:39:40 -0000 Received: from [98.138.226.169] by tm3.bullet.mail.ne1.yahoo.com with NNFMP; 23 Nov 2012 16:39:40 -0000 Received: from [127.0.0.1] by omp1070.mail.ne1.yahoo.com with NNFMP; 23 Nov 2012 16:39:40 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 77877.34608.bm@omp1070.mail.ne1.yahoo.com Received: (qmail 96419 invoked by uid 60001); 23 Nov 2012 16:39:40 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1353688780; bh=EMnPEQs8hAaMRLphsL2grcdo3YOKv6yx9YM05csV15Y=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=52rrTy6rnREZeu5MmWBnTKZAL8Dlcq6e9C6+SdvThS4N20BEx0r7TQRHprWNFrtzXf6rC6rz1arrbtUmUb76ueYznLv6xw+PWoukDN+K2ii24Gy2pOM0E571OYlslppouOk6fv461RIZOk9OA0+lcre/W0BPiytI4mUvtQj/HSk= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=5Nz78m1peBrxUeDVioak1lZUeqGFefDEpdTf6tTvBlDYe1iYGAUTsTYZ9Lh/RL1kV++BLxMM2my6eW6gbpW37vOK0TwKPRHlfWQgecasCeywUSztVVFy1SgJDRLu7oEKPGduf59umhPIkA6XqF9vqz7C64GwRwJ6NKL4+KBUV/I=; X-YMail-OSG: wR2fHyQVM1lr5hOHdeAUqzqnOUq8bUE1CfBYTKHOCIAR4Mk OypvEGhO_RbFDF8A3vKAfOVnV3upvUcC_WjcltPFF2qqckzFp5XqbPuaoKZz 3sdgth2s41Bv4AtMzlHtl59JxtsLp3VZAXWsgJNWYzw42HgbUWyJ3uNX6ZUC WPD7Zur85wMPtmxz8KqSh37SY08uQh9eTNZfBzi9IcFyz6qkdBbEaW8tDKC1 Hv64ion4QM6oS_MLTKbYDWUWhNFVNCBAnG2_cxGgCRdzGe722tmkaeb3DSPX E3ObNiVgHnoGaDxIdkk9X1hGMzYn5n8JlwtdhzVsj3P1GYrPUcaVu7l9igFU WdrxXudZWa1FYfOh8xTNA__j0bczffTZqOkhaiwXYvf1yrAxuq6lWrFk8F8f Of9uzt1EW7_A57lEVQpwr2epZXKk4RbGlyP6vB0Ii5SvH_Nr2tbPxNLzPSaX 6nMmr_pStzZdU6u_pOsWbFgu.SdtpMqAqOha1wGe6ae0lu9Lyy4yi Received: from [166.216.160.76] by web121604.mail.ne1.yahoo.com via HTTP; Fri, 23 Nov 2012 08:39:39 PST X-Rocket-MIMEInfo: 001.001, DQpDbGFyaWZpY2F0aW9uOg0KDQpIZXJlJ3MgdGhlIHdheSBJIHdvdWxkIHdyaXRlIHRoZSBzdGF0ZW1lbnQgYmVsb3c6DQoNCg0KT24gdGhlIGNvbmRpdGlvbiB0aGF0IGEgQ2xpZW50IG9mIGEgUklEIFN5c3RlbSBzZW5kcyBhIEhUVFAgUmVxdWVzdCB0byBhIFNlcnZlciBSSUQgU3lzdGVtIGFuZCBleHBlcmllbmNlIGEgSFRUUCA0MDAtNDA0IEVycm9yLCB0aGF0IENsaWVudCBpcyBsaWtlbHkgaW4gZXJyb3IuDQoNCk9uIHRoZSBjb25kaXRpb24gdGhhdCBhIENsaWVudCBvZiBhIFJJRCBTeXN0ZW0gc2VuZHMBMAEBAQE- X-Mailer: YahooMailClassic/15.0.8 YahooMailWebService/0.8.123.460 Message-ID: <1353688779.79015.YahooMailClassic@web121604.mail.ne1.yahoo.com> Date: Fri, 23 Nov 2012 08:39:39 -0800 (PST) From: "C. Henry Adams & BIE" To: MILE IETF MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-36511695-199934147-1353688779=:79015" Cc: "C. Henry Adams" Subject: Re: [mile] RFC6546 possible editorial errata 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, 23 Nov 2012 16:39:43 -0000 ---36511695-199934147-1353688779=:79015 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Clarification: Here's the way I would write the statement below: On the condition that a Client of a RID System sends a HTTP Request to a Se= rver RID System and experience a HTTP 400-404 Error, that Client is likely = in error. On the condition that a Client of a RID System sends a HTTP Request to a Se= rver RID System and experience a HTTP 500-510 Error, the receiving Server i= s likely in error. ---------------------------------------------------------------------------= -------------------------------------------------------- "If a RID system receives an improper RID message in an HTTP Request, =A0=A0 it MUST return an appropriate 4xx Client Error result code to the =A0=A0 requesting RID system.=A0 If a RID system cannot process a RID messa= ge =A0=A0 received in an HTTP Request due to an error on its own side, it MUST =A0=A0 return an appropriate 5xx Server Error result code to the requesting =A0=A0 RID system." C. Henry Adams chatlga2000@yahoo.com (Direct Email) chenryadams@biemediagroup.com ---36511695-199934147-1353688779=:79015 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable

Clarification:

Here's the way I wo= uld write the statement below:


On the condition that a Client of= a RID System sends a HTTP Request to a Server RID System and experience a = HTTP 400-404 Error, that Client is likely in error.

On the condition= that a Client of a RID System sends a HTTP Request to a Server RID System = and experience a HTTP 500-510 Error, the receiving Server is likely in erro= r.

-----------------------------------------------------------------= ------------------------------------------------------------------

"= If a RID system receives an improper RID message in an HTTP Request,
&nb= sp;  it MUST return an appropriate 4xx Client Error result code to the=
   requesting RID system.  If a RID system cannot proces= s a RID message
   received in an HTTP Request due to an error= on its own side, it MUST
   return an appropriate 5xx Server Err= or result code to the requesting
   RID system."


C. Henry Adams
chatlga2000@yahoo.com (Direct Email)
chenryadams@bie= mediagroup.com

---36511695-199934147-1353688779=:79015-- From david.waltermire@nist.gov Tue Nov 27 07:57:55 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 2E43621F84D1 for ; Tue, 27 Nov 2012 07:57:55 -0800 (PST) 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 HOzYOHVb8Q-K for ; Tue, 27 Nov 2012 07:57:54 -0800 (PST) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 25C6C21F8432 for ; Tue, 27 Nov 2012 07:57:54 -0800 (PST) Received: from WSXGHUB2.xchange.nist.gov (129.6.18.19) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.2.318.4; Tue, 27 Nov 2012 10:57:16 -0500 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Tue, 27 Nov 2012 10:55:17 -0500 From: "Waltermire, David A." To: "Moriarty, Kathleen" , SM Date: Tue, 27 Nov 2012 10:57:27 -0500 Thread-Topic: [mile] RFC6546 possible editorial errata Thread-Index: Ac3IAmdSUK+z8hqsRIC2MQroHYdyHQAAdTg8AA7cWyAABcppsAEX6brg Message-ID: References: , <6.2.5.6.2.20121121074441.09c00288@resistor.net> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Cc: "mile@ietf.org" Subject: Re: [mile] RFC6546 possible editorial errata 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, 27 Nov 2012 15:57:55 -0000 I think it makes sense to classify any change to the original wording in question as technical, since it changes the technical meaning of the text. I am good with using the application layer Acknowledgement message to report a malformed RID request message. This looks like it is aligned well with the text in rfc6545 section 6.2. My only concern is introducing ambiguity from the other direction with the change. Relative to the transport, is the use of the acknowledgement approach clear? Have the developers you mentioned weighed in on the change from their perspectives? Any other thoughts? Thanks, Dave -----Original Message----- From: Moriarty, Kathleen [mailto:kathleen.moriarty@emc.com] Sent: Wednesday, November 21, 2012 9:22 PM To: Waltermire, David A.; SM Cc: mile@ietf.org Subject: RE: [mile] RFC6546 possible editorial errata Hi Dave, Thanks for taking a look at this as well! At the application layer, you have the ability to figure out what is wrong with the RID/IODEF document and provide a response with details via the Acknowledgement message. This would be in a 200 HTTP code according to the table and then the 'Justification' can be set appropriately (xml encryption error, xml schema error, etc.). As a result, the language in the sentences provided is causing some confusion. I should have provided that context in the initial message. Does the additional context change your view? I think it would be easier for developers (and meet the intended objective with the language change, but it may be technical and not editorial). Does that change your view? Anyone other thoughts from the list? Thanks, Kathleen ________________________________________ From: Waltermire, David A. [david.waltermire@nist.gov] Sent: Wednesday, November 21, 2012 6:46 PM To: Moriarty, Kathleen; SM Cc: mile@ietf.org Subject: RE: [mile] RFC6546 possible editorial errata The document is focused on applying the HTTP transport to define an application-layer protocol for RID (at least according to the abstract), so to some extent it has its feet on both sides of the fence. ;-) If the text is changed it might clarify what to do in the case of an invalid HTTP request at the transport layer. In doing so, wouldn't we then be introducing the same ambiguity at the application layer for an invalid RID message? In this case it would be undefined as to what to do if you have a valid HTTP request from a transport perspective with an invalid RID message from an application perspective. It might make sense instead to change it to: "If a RID system receives an improper HTTP Request or an improper RID message in a valid HTTP Request, it MUST return an appropriate 4xx Client Error result code to the requesting RID system." Something like this would cover both cases making it clear to both developers. Happy Thanksgiving to those celebrating! Sincerely, Dave -----Original Message----- From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Moriarty, Kathleen Sent: Wednesday, November 21, 2012 11:21 AM To: SM Cc: mile@ietf.org Subject: Re: [mile] RFC6546 possible editorial errata SM, Thanks for the review! Here is the text that SM is referring to: "If a RID system receives an improper RID message in an HTTP Request, it MUST return an appropriate 4xx Client Error result code to the requesting RID system. If a RID system cannot process a RID message received in an HTTP Request due to an error on its own side, it MUST return an appropriate 5xx Server Error result code to the requesting RID system." I agree that the text is confusing as one developer interpreted it to apply to the RID messages and another interpreted it as applying to HTTP since the codes are specific to HTTP and not the application layer. I believe the intent was that it applied to the HTTP error level as this document was focused on transport. I see your point that this may be a technical change. The following sentence has the same problem, do you agree with the assessment and what do others think? Thanks, Kathleen ________________________________________ From: SM [sm@resistor.net] Sent: Wednesday, November 21, 2012 11:00 AM To: Moriarty, Kathleen Cc: mile@ietf.org Subject: Re: [mile] RFC6546 possible editorial errata Hi Kathleen, At 15:31 20-11-2012, Moriarty, Kathleen wrote: >There has been some confusion by a developer on when to use a HTTP 4xx >response versus the use of an HTTP 200 response with an >acknowledgement. I think to get to the intent of RFC6545 and >RFC6546 a proposed text fix could address this confusion and just get >filed as an editorial errata: > >Section 3, paragraph 12: >Change from: >If a RID system receives an improper RID message in an HTTP Request, > it MUST return an appropriate 4xx Client Error result code to the > requesting RID system. > >To: >If a RID system receives an improper HTTP Request, > it MUST return an appropriate 4xx Client Error result code to the > requesting RID system. The above suggested text changes the RFC 2119 requirement. I wouldn't consider it as editorial as the intent is debatable if there wasn't any (prior) discussion to support it. BTW, the requirement is similar to the one in the sentence that follows the one quoted above. Regards, -sm _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile From david.black@emc.com Tue Nov 27 12:48:25 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 1607F21F8785 for ; Tue, 27 Nov 2012 12:48:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id llIXQhoKFMXE for ; Tue, 27 Nov 2012 12:48:24 -0800 (PST) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id ADCFC21F8789 for ; Tue, 27 Nov 2012 12:48:23 -0800 (PST) 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 qARKmL2u007601 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Nov 2012 15:48:22 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd04.lss.emc.com [10.254.222.226]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Tue, 27 Nov 2012 15:48:01 -0500 Received: from mxhub06.corp.emc.com (mxhub06.corp.emc.com [128.222.70.203]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id qARKlqrL030487; Tue, 27 Nov 2012 15:47:57 -0500 Received: from mx15a.corp.emc.com ([169.254.1.120]) by mxhub06.corp.emc.com ([128.222.70.203]) with mapi; Tue, 27 Nov 2012 15:47:53 -0500 From: "Black, David" To: "Waltermire, David A." Date: Tue, 27 Nov 2012 15:47:51 -0500 Thread-Topic: [mile] RFC6546 possible editorial errata Thread-Index: Ac3IAmdSUK+z8hqsRIC2MQroHYdyHQAAdTg8AA7cWyAABcppsAEX6brgAACMP1A= Message-ID: <8D3D17ACE214DC429325B2B98F3AE71284D40403@MX15A.corp.emc.com> References: , <6.2.5.6.2.20121121074441.09c00288@resistor.net> , 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" Subject: Re: [mile] RFC6546 possible editorial errata 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, 27 Nov 2012 20:48:25 -0000 Hi Dave, I like the approach of reporting errors at the layer at which they occur, but I do agree that this would be a technical change. For the RID Acknowledgement message, what should be in the RequestStatus instance to indicate that the RID message that is being acknowledged was malformed (and hence has been discarded)? Would UnrecognizedFormat cover this case? Thanks, --David > -----Original Message----- > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of > Waltermire, David A. > Sent: Tuesday, November 27, 2012 10:57 AM > To: Moriarty, Kathleen; SM > Cc: mile@ietf.org > Subject: Re: [mile] RFC6546 possible editorial errata >=20 > I think it makes sense to classify any change to the original wording in > question as technical, since it changes the technical meaning of the text= . >=20 > I am good with using the application layer Acknowledgement message to rep= ort a > malformed RID request message. This looks like it is aligned well with t= he > text in rfc6545 section 6.2. >=20 > My only concern is introducing ambiguity from the other direction with th= e > change. Relative to the transport, is the use of the acknowledgement app= roach > clear? Have the developers you mentioned weighed in on the change from t= heir > perspectives? >=20 > Any other thoughts? >=20 > Thanks, > Dave >=20 > -----Original Message----- > From: Moriarty, Kathleen [mailto:kathleen.moriarty@emc.com] > Sent: Wednesday, November 21, 2012 9:22 PM > To: Waltermire, David A.; SM > Cc: mile@ietf.org > Subject: RE: [mile] RFC6546 possible editorial errata >=20 > Hi Dave, >=20 > Thanks for taking a look at this as well! >=20 > At the application layer, you have the ability to figure out what is wron= g > with the RID/IODEF document and provide a response with details via the > Acknowledgement message. This would be in a 200 HTTP code according to t= he > table and then the 'Justification' can be set appropriately (xml encrypti= on > error, xml schema error, etc.). As a result, the language in the sentenc= es > provided is causing some confusion. I should have provided that context = in > the initial message. Does the additional context change your view? I th= ink > it would be easier for developers (and meet the intended objective with t= he > language change, but it may be technical and not editorial). Does that c= hange > your view? >=20 > Anyone other thoughts from the list? >=20 > Thanks, > Kathleen > ________________________________________ > From: Waltermire, David A. [david.waltermire@nist.gov] > Sent: Wednesday, November 21, 2012 6:46 PM > To: Moriarty, Kathleen; SM > Cc: mile@ietf.org > Subject: RE: [mile] RFC6546 possible editorial errata >=20 > The document is focused on applying the HTTP transport to define an > application-layer protocol for RID (at least according to the abstract), = so to > some extent it has its feet on both sides of the fence. ;-) >=20 > If the text is changed it might clarify what to do in the case of an inva= lid > HTTP request at the transport layer. In doing so, wouldn't we then be > introducing the same ambiguity at the application layer for an invalid RI= D > message? In this case it would be undefined as to what to do if you have= a > valid HTTP request from a transport perspective with an invalid RID messa= ge > from an application perspective. It might make sense instead to change i= t to: >=20 > "If a RID system receives an improper HTTP Request or an improper RID mes= sage > in a valid HTTP Request, it MUST return an appropriate 4xx Client Error > result code to the requesting RID system." >=20 > Something like this would cover both cases making it clear to both develo= pers. >=20 > Happy Thanksgiving to those celebrating! >=20 > Sincerely, > Dave >=20 > -----Original Message----- > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of > Moriarty, Kathleen > Sent: Wednesday, November 21, 2012 11:21 AM > To: SM > Cc: mile@ietf.org > Subject: Re: [mile] RFC6546 possible editorial errata >=20 > SM, >=20 > Thanks for the review! Here is the text that SM is referring to: >=20 > "If a RID system receives an improper RID message in an HTTP Request, > it MUST return an appropriate 4xx Client Error result code to the > requesting RID system. If a RID system cannot process a RID message > received in an HTTP Request due to an error on its own side, it MUST > return an appropriate 5xx Server Error result code to the requesting > RID system." >=20 > I agree that the text is confusing as one developer interpreted it to app= ly to > the RID messages and another interpreted it as applying to HTTP since the > codes are specific to HTTP and not the application layer. I believe the > intent was that it applied to the HTTP error level as this document was > focused on transport. I see your point that this may be a technical chan= ge. > The following sentence has the same problem, do you agree with the assess= ment > and what do others think? >=20 > Thanks, > Kathleen > ________________________________________ > From: SM [sm@resistor.net] > Sent: Wednesday, November 21, 2012 11:00 AM > To: Moriarty, Kathleen > Cc: mile@ietf.org > Subject: Re: [mile] RFC6546 possible editorial errata >=20 > Hi Kathleen, > At 15:31 20-11-2012, Moriarty, Kathleen wrote: > >There has been some confusion by a developer on when to use a HTTP 4xx > >response versus the use of an HTTP 200 response with an > >acknowledgement. I think to get to the intent of RFC6545 and > >RFC6546 a proposed text fix could address this confusion and just get > >filed as an editorial errata: > > > >Section 3, paragraph 12: > >Change from: > >If a RID system receives an improper RID message in an HTTP Request, > > it MUST return an appropriate 4xx Client Error result code to the > > requesting RID system. > > > >To: > >If a RID system receives an improper HTTP Request, > > it MUST return an appropriate 4xx Client Error result code to the > > requesting RID system. >=20 > The above suggested text changes the RFC 2119 requirement. I wouldn't > consider it as editorial as the intent is debatable if there wasn't any > (prior) discussion to support it. >=20 > BTW, the requirement is similar to the one in the sentence that follows t= he > one quoted above. >=20 > Regards, > -sm >=20 >=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 From kathleen.moriarty@emc.com Tue Nov 27 13:11:38 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 F13E821F8751 for ; Tue, 27 Nov 2012 13:11:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 bjIpFP4E8HcF for ; Tue, 27 Nov 2012 13:11:34 -0800 (PST) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 0126621F8745 for ; Tue, 27 Nov 2012 13:11:33 -0800 (PST) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id qARLBV2A031529 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Nov 2012 16:11:32 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd05.lss.emc.com [10.254.222.129]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Tue, 27 Nov 2012 16:11:22 -0500 Received: from mxhub08.corp.emc.com (mxhub08.corp.emc.com [128.222.70.205]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id qARLBLP2032024; Tue, 27 Nov 2012 16:11:22 -0500 Received: from mx15a.corp.emc.com ([169.254.1.120]) by mxhub08.corp.emc.com ([128.222.70.205]) with mapi; Tue, 27 Nov 2012 16:11:21 -0500 From: "Moriarty, Kathleen" To: "Black, David" , "Waltermire, David A." Date: Tue, 27 Nov 2012 16:11:20 -0500 Thread-Topic: [mile] RFC6546 possible editorial errata Thread-Index: Ac3IAmdSUK+z8hqsRIC2MQroHYdyHQAAdTg8AA7cWyAABcppsAEX6brgAACMP1AACrjHEA== Message-ID: References: , <6.2.5.6.2.20121121074441.09c00288@resistor.net> , <8D3D17ACE214DC429325B2B98F3AE71284D40403@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE71284D40403@MX15A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: "mile@ietf.org" Subject: Re: [mile] RFC6546 possible editorial errata 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, 27 Nov 2012 21:11:39 -0000 Thanks, David. Yes, UnrecognizedFormat for the Justification attribute would be the correc= t response at the RID layer. We have some consensus it seems. Brian and Sean may want to weigh in as we= ll (or anyone else). Best regards, Kathleen -----Original Message----- From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Bla= ck, David Sent: Tuesday, November 27, 2012 3:48 PM To: Waltermire, David A. Cc: mile@ietf.org Subject: Re: [mile] RFC6546 possible editorial errata Hi Dave, I like the approach of reporting errors at the layer at which they occur, but I do agree that this would be a technical change. For the RID Acknowledgement message, what should be in the RequestStatus instance to indicate that the RID message that is being acknowledged was malformed (and hence has been discarded)? Would UnrecognizedFormat cover this case? Thanks, --David > -----Original Message----- > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of > Waltermire, David A. > Sent: Tuesday, November 27, 2012 10:57 AM > To: Moriarty, Kathleen; SM > Cc: mile@ietf.org > Subject: Re: [mile] RFC6546 possible editorial errata >=20 > I think it makes sense to classify any change to the original wording in > question as technical, since it changes the technical meaning of the text= . >=20 > I am good with using the application layer Acknowledgement message to rep= ort a > malformed RID request message. This looks like it is aligned well with t= he > text in rfc6545 section 6.2. >=20 > My only concern is introducing ambiguity from the other direction with th= e > change. Relative to the transport, is the use of the acknowledgement app= roach > clear? Have the developers you mentioned weighed in on the change from t= heir > perspectives? >=20 > Any other thoughts? >=20 > Thanks, > Dave >=20 > -----Original Message----- > From: Moriarty, Kathleen [mailto:kathleen.moriarty@emc.com] > Sent: Wednesday, November 21, 2012 9:22 PM > To: Waltermire, David A.; SM > Cc: mile@ietf.org > Subject: RE: [mile] RFC6546 possible editorial errata >=20 > Hi Dave, >=20 > Thanks for taking a look at this as well! >=20 > At the application layer, you have the ability to figure out what is wron= g > with the RID/IODEF document and provide a response with details via the > Acknowledgement message. This would be in a 200 HTTP code according to t= he > table and then the 'Justification' can be set appropriately (xml encrypti= on > error, xml schema error, etc.). As a result, the language in the sentenc= es > provided is causing some confusion. I should have provided that context = in > the initial message. Does the additional context change your view? I th= ink > it would be easier for developers (and meet the intended objective with t= he > language change, but it may be technical and not editorial). Does that c= hange > your view? >=20 > Anyone other thoughts from the list? >=20 > Thanks, > Kathleen > ________________________________________ > From: Waltermire, David A. [david.waltermire@nist.gov] > Sent: Wednesday, November 21, 2012 6:46 PM > To: Moriarty, Kathleen; SM > Cc: mile@ietf.org > Subject: RE: [mile] RFC6546 possible editorial errata >=20 > The document is focused on applying the HTTP transport to define an > application-layer protocol for RID (at least according to the abstract), = so to > some extent it has its feet on both sides of the fence. ;-) >=20 > If the text is changed it might clarify what to do in the case of an inva= lid > HTTP request at the transport layer. In doing so, wouldn't we then be > introducing the same ambiguity at the application layer for an invalid RI= D > message? In this case it would be undefined as to what to do if you have= a > valid HTTP request from a transport perspective with an invalid RID messa= ge > from an application perspective. It might make sense instead to change i= t to: >=20 > "If a RID system receives an improper HTTP Request or an improper RID mes= sage > in a valid HTTP Request, it MUST return an appropriate 4xx Client Error > result code to the requesting RID system." >=20 > Something like this would cover both cases making it clear to both develo= pers. >=20 > Happy Thanksgiving to those celebrating! >=20 > Sincerely, > Dave >=20 > -----Original Message----- > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of > Moriarty, Kathleen > Sent: Wednesday, November 21, 2012 11:21 AM > To: SM > Cc: mile@ietf.org > Subject: Re: [mile] RFC6546 possible editorial errata >=20 > SM, >=20 > Thanks for the review! Here is the text that SM is referring to: >=20 > "If a RID system receives an improper RID message in an HTTP Request, > it MUST return an appropriate 4xx Client Error result code to the > requesting RID system. If a RID system cannot process a RID message > received in an HTTP Request due to an error on its own side, it MUST > return an appropriate 5xx Server Error result code to the requesting > RID system." >=20 > I agree that the text is confusing as one developer interpreted it to app= ly to > the RID messages and another interpreted it as applying to HTTP since the > codes are specific to HTTP and not the application layer. I believe the > intent was that it applied to the HTTP error level as this document was > focused on transport. I see your point that this may be a technical chan= ge. > The following sentence has the same problem, do you agree with the assess= ment > and what do others think? >=20 > Thanks, > Kathleen > ________________________________________ > From: SM [sm@resistor.net] > Sent: Wednesday, November 21, 2012 11:00 AM > To: Moriarty, Kathleen > Cc: mile@ietf.org > Subject: Re: [mile] RFC6546 possible editorial errata >=20 > Hi Kathleen, > At 15:31 20-11-2012, Moriarty, Kathleen wrote: > >There has been some confusion by a developer on when to use a HTTP 4xx > >response versus the use of an HTTP 200 response with an > >acknowledgement. I think to get to the intent of RFC6545 and > >RFC6546 a proposed text fix could address this confusion and just get > >filed as an editorial errata: > > > >Section 3, paragraph 12: > >Change from: > >If a RID system receives an improper RID message in an HTTP Request, > > it MUST return an appropriate 4xx Client Error result code to the > > requesting RID system. > > > >To: > >If a RID system receives an improper HTTP Request, > > it MUST return an appropriate 4xx Client Error result code to the > > requesting RID system. >=20 > The above suggested text changes the RFC 2119 requirement. I wouldn't > consider it as editorial as the intent is debatable if there wasn't any > (prior) discussion to support it. >=20 > BTW, the requirement is similar to the one in the sentence that follows t= he > one quoted above. >=20 > Regards, > -sm >=20 >=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 _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile From trammell@tik.ee.ethz.ch Tue Nov 27 15:49:54 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 49B7621E803A for ; Tue, 27 Nov 2012 15:49:54 -0800 (PST) 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 51+TIlOSm06d for ; Tue, 27 Nov 2012 15:49:53 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id EF1FB21E8030 for ; Tue, 27 Nov 2012 15:49:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id CA365D9304; Wed, 28 Nov 2012 00:49:49 +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 VIVpbEtxzage; Wed, 28 Nov 2012 00:49:49 +0100 (MET) Received: from [10.0.27.100] (cust-integra-122-165.antanet.ch [80.75.122.165]) (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 73013D9307; Wed, 28 Nov 2012 00:49:49 +0100 (MET) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Brian Trammell In-Reply-To: Date: Wed, 28 Nov 2012 00:49:48 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4FB1BD7D-F1B1-4A2C-B795-6DAB2B1163D8@tik.ee.ethz.ch> References: , <6.2.5.6.2.20121121074441.09c00288@resistor.net> , <8D3D17ACE214DC429325B2B98F3AE71284D40403@MX15A.corp.emc.com> To: "Moriarty, Kathleen" X-Mailer: Apple Mail (2.1283) Cc: "mile@ietf.org" Subject: Re: [mile] RFC6546 possible editorial errata 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, 27 Nov 2012 23:49:54 -0000 Hi, Kathleen, all, (chair hat off) (6546 author hat on) I'm a little confused on terminology here; "malformed" with respect to a = RID message meaning "not well-formed XML", or "XML not corresponding to = the RID schema"? In any case, since there's an application-layer mechanism for reporting = such errors it makes sense to use it, of course. However, I'd find = something deeply odd about returning a 200 OK which inside it contained = an Acknowledgment signaling UnrecognizedFormat -- the response status = and response body would mismatch then. I'd suggest instead 400 Bad Request, with Acknowledgment as response = body. Which leaves us with NEW (a little stilted, can probably stand some = editorial improvement...) If a RID system receives an improper HTTP Request, it MUST return an appropriate 4xx Client Error result code to the requesting RID system. If a RID system receives a malformed RID = message,=20 it MUST return an Acknowledgment RID message, with 'Denied' as the AuthorizationStatus attribute of RequestStatus and = 'UnrecognizedFormat'=20 as the Justification attribute of RequestStatus, in a response with=20 result code 400 Bad Request. If a RID system cannot process a RID = message received in an HTTP Request due to an error on its own side, it MUST return an appropriate 5xx Server Error result code to the requesting RID system. Best regards, Brian On Nov 27, 2012, at 10:11 PM, Moriarty, Kathleen wrote: > Thanks, David. >=20 > Yes, UnrecognizedFormat for the Justification attribute would be the = correct response at the RID layer. >=20 > We have some consensus it seems. Brian and Sean may want to weigh in = as well (or anyone else). >=20 > Best regards, > Kathleen >=20 > -----Original Message----- > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf = Of Black, David > Sent: Tuesday, November 27, 2012 3:48 PM > To: Waltermire, David A. > Cc: mile@ietf.org > Subject: Re: [mile] RFC6546 possible editorial errata >=20 > Hi Dave, >=20 > I like the approach of reporting errors at the layer at which they > occur, but I do agree that this would be a technical change. >=20 > For the RID Acknowledgement message, what should be in the > RequestStatus instance to indicate that the RID message that is > being acknowledged was malformed (and hence has been discarded)? > Would UnrecognizedFormat cover this case? >=20 > Thanks, > --David >=20 >> -----Original Message----- >> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf = Of >> Waltermire, David A. >> Sent: Tuesday, November 27, 2012 10:57 AM >> To: Moriarty, Kathleen; SM >> Cc: mile@ietf.org >> Subject: Re: [mile] RFC6546 possible editorial errata >>=20 >> I think it makes sense to classify any change to the original wording = in >> question as technical, since it changes the technical meaning of the = text. >>=20 >> I am good with using the application layer Acknowledgement message to = report a >> malformed RID request message. This looks like it is aligned well = with the >> text in rfc6545 section 6.2. >>=20 >> My only concern is introducing ambiguity from the other direction = with the >> change. Relative to the transport, is the use of the acknowledgement = approach >> clear? Have the developers you mentioned weighed in on the change = from their >> perspectives? >>=20 >> Any other thoughts? >>=20 >> Thanks, >> Dave >>=20 >> -----Original Message----- >> From: Moriarty, Kathleen [mailto:kathleen.moriarty@emc.com] >> Sent: Wednesday, November 21, 2012 9:22 PM >> To: Waltermire, David A.; SM >> Cc: mile@ietf.org >> Subject: RE: [mile] RFC6546 possible editorial errata >>=20 >> Hi Dave, >>=20 >> Thanks for taking a look at this as well! >>=20 >> At the application layer, you have the ability to figure out what is = wrong >> with the RID/IODEF document and provide a response with details via = the >> Acknowledgement message. This would be in a 200 HTTP code according = to the >> table and then the 'Justification' can be set appropriately (xml = encryption >> error, xml schema error, etc.). As a result, the language in the = sentences >> provided is causing some confusion. I should have provided that = context in >> the initial message. Does the additional context change your view? = I think >> it would be easier for developers (and meet the intended objective = with the >> language change, but it may be technical and not editorial). Does = that change >> your view? >>=20 >> Anyone other thoughts from the list? >>=20 >> Thanks, >> Kathleen >> ________________________________________ >> From: Waltermire, David A. [david.waltermire@nist.gov] >> Sent: Wednesday, November 21, 2012 6:46 PM >> To: Moriarty, Kathleen; SM >> Cc: mile@ietf.org >> Subject: RE: [mile] RFC6546 possible editorial errata >>=20 >> The document is focused on applying the HTTP transport to define an >> application-layer protocol for RID (at least according to the = abstract), so to >> some extent it has its feet on both sides of the fence. ;-) >>=20 >> If the text is changed it might clarify what to do in the case of an = invalid >> HTTP request at the transport layer. In doing so, wouldn't we then = be >> introducing the same ambiguity at the application layer for an = invalid RID >> message? In this case it would be undefined as to what to do if you = have a >> valid HTTP request from a transport perspective with an invalid RID = message >> from an application perspective. It might make sense instead to = change it to: >>=20 >> "If a RID system receives an improper HTTP Request or an improper RID = message >> in a valid HTTP Request, it MUST return an appropriate 4xx Client = Error >> result code to the requesting RID system." >>=20 >> Something like this would cover both cases making it clear to both = developers. >>=20 >> Happy Thanksgiving to those celebrating! >>=20 >> Sincerely, >> Dave >>=20 >> -----Original Message----- >> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf = Of >> Moriarty, Kathleen >> Sent: Wednesday, November 21, 2012 11:21 AM >> To: SM >> Cc: mile@ietf.org >> Subject: Re: [mile] RFC6546 possible editorial errata >>=20 >> SM, >>=20 >> Thanks for the review! Here is the text that SM is referring to: >>=20 >> "If a RID system receives an improper RID message in an HTTP Request, >> it MUST return an appropriate 4xx Client Error result code to the >> requesting RID system. If a RID system cannot process a RID = message >> received in an HTTP Request due to an error on its own side, it = MUST >> return an appropriate 5xx Server Error result code to the = requesting >> RID system." >>=20 >> I agree that the text is confusing as one developer interpreted it to = apply to >> the RID messages and another interpreted it as applying to HTTP since = the >> codes are specific to HTTP and not the application layer. I believe = the >> intent was that it applied to the HTTP error level as this document = was >> focused on transport. I see your point that this may be a technical = change. >> The following sentence has the same problem, do you agree with the = assessment >> and what do others think? >>=20 >> Thanks, >> Kathleen >> ________________________________________ >> From: SM [sm@resistor.net] >> Sent: Wednesday, November 21, 2012 11:00 AM >> To: Moriarty, Kathleen >> Cc: mile@ietf.org >> Subject: Re: [mile] RFC6546 possible editorial errata >>=20 >> Hi Kathleen, >> At 15:31 20-11-2012, Moriarty, Kathleen wrote: >>> There has been some confusion by a developer on when to use a HTTP = 4xx >>> response versus the use of an HTTP 200 response with an >>> acknowledgement. I think to get to the intent of RFC6545 and >>> RFC6546 a proposed text fix could address this confusion and just = get >>> filed as an editorial errata: >>>=20 >>> Section 3, paragraph 12: >>> Change from: >>> If a RID system receives an improper RID message in an HTTP Request, >>> it MUST return an appropriate 4xx Client Error result code to the >>> requesting RID system. >>>=20 >>> To: >>> If a RID system receives an improper HTTP Request, >>> it MUST return an appropriate 4xx Client Error result code to the >>> requesting RID system. >>=20 >> The above suggested text changes the RFC 2119 requirement. I = wouldn't >> consider it as editorial as the intent is debatable if there wasn't = any >> (prior) discussion to support it. >>=20 >> BTW, the requirement is similar to the one in the sentence that = follows the >> one quoted above. >>=20 >> Regards, >> -sm >>=20 >>=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 >=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 From kathleen.moriarty@emc.com Tue Nov 27 16:30:35 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 3FBDE1F0C49 for ; Tue, 27 Nov 2012 16:30:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 I2S6Zb9FUhRX for ; Tue, 27 Nov 2012 16:30:34 -0800 (PST) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 0EA7321F86A4 for ; Tue, 27 Nov 2012 16:30:33 -0800 (PST) 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 qAS0UUdO010797 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Nov 2012 19:30:32 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd04.lss.emc.com [10.254.222.226]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Tue, 27 Nov 2012 19:30:09 -0500 Received: from mxhub05.corp.emc.com (mxhub05.corp.emc.com [128.222.70.202]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id qAS0U8gK023054; Tue, 27 Nov 2012 19:30:08 -0500 Received: from mxhub38.corp.emc.com (128.222.70.105) by mxhub05.corp.emc.com (128.222.70.202) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 27 Nov 2012 19:30:08 -0500 Received: from mx15a.corp.emc.com ([169.254.1.120]) by mxhub38.corp.emc.com ([128.222.70.105]) with mapi; Tue, 27 Nov 2012 19:30:08 -0500 From: "Moriarty, Kathleen" To: Brian Trammell Date: Tue, 27 Nov 2012 19:30:06 -0500 Thread-Topic: [mile] RFC6546 possible editorial errata Thread-Index: Ac3M+fND3rhxWyCrRMy8mf/jQPhcIAABEqDw Message-ID: References: , <6.2.5.6.2.20121121074441.09c00288@resistor.net> , <8D3D17ACE214DC429325B2B98F3AE71284D40403@MX15A.corp.emc.com> <4FB1BD7D-F1B1-4A2C-B795-6DAB2B1163D8@tik.ee.ethz.ch> In-Reply-To: <4FB1BD7D-F1B1-4A2C-B795-6DAB2B1163D8@tik.ee.ethz.ch> 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" Subject: Re: [mile] RFC6546 possible editorial errata 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, 28 Nov 2012 00:30:35 -0000 Hi Brian, Malformed is the wrong word, we are really talking about the IODEF schema o= r some embedded schema via the SCI draft not being conformant. Or you coul= d have some other schema sent in RID that is not recognized by the receivin= g system (something other than IODEF). As such, handling that error at the= RID application layer is easier than at the HTTP layer from a development = perspective. There are a range of possible things that could occur and mal= formed is not really the right word to describe UnrecognizedFormat. By cha= nging the response to a 400 with an Acknowledgement now, that is pretty sig= nificant as the flows and tables change to allow an Ack to come back in eit= her a 200 or a 400 depending on the Justification value selected. I think = for developers, handling HTTP at the HTTP layer is easier and then applicat= ion errors at the RID layer. I think it is a smaller change and may be bet= ter for adoption by developers rather than having them do both before sendi= ng an HTTP 400 message. Does that help clear up your confusion? Any thoughts? Thanks, Kathleen -----Original Message----- From: Brian Trammell [mailto:trammell@tik.ee.ethz.ch]=20 Sent: Tuesday, November 27, 2012 6:50 PM To: Moriarty, Kathleen Cc: Black, David; Waltermire, David A.; mile@ietf.org Subject: Re: [mile] RFC6546 possible editorial errata Hi, Kathleen, all, (chair hat off) (6546 author hat on) I'm a little confused on terminology here; "malformed" with respect to a RI= D message meaning "not well-formed XML", or "XML not corresponding to the R= ID schema"? In any case, since there's an application-layer mechanism for reporting suc= h errors it makes sense to use it, of course. However, I'd find something d= eeply odd about returning a 200 OK which inside it contained an Acknowledgm= ent signaling UnrecognizedFormat -- the response status and response body w= ould mismatch then. I'd suggest instead 400 Bad Request, with Acknowledgment as response body. Which leaves us with NEW (a little stilted, can probably stand some editori= al improvement...) If a RID system receives an improper HTTP Request, it MUST return an appropriate 4xx Client Error result code to the requesting RID system. If a RID system receives a malformed RID message,= =20 it MUST return an Acknowledgment RID message, with 'Denied' as the AuthorizationStatus attribute of RequestStatus and 'UnrecognizedFormat'=20 as the Justification attribute of RequestStatus, in a response with=20 result code 400 Bad Request. If a RID system cannot process a RID message received in an HTTP Request due to an error on its own side, it MUST return an appropriate 5xx Server Error result code to the requesting RID system. Best regards, Brian On Nov 27, 2012, at 10:11 PM, Moriarty, Kathleen wrote: > Thanks, David. >=20 > Yes, UnrecognizedFormat for the Justification attribute would be the corr= ect response at the RID layer. >=20 > We have some consensus it seems. Brian and Sean may want to weigh in as = well (or anyone else). >=20 > Best regards, > Kathleen >=20 > -----Original Message----- > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of B= lack, David > Sent: Tuesday, November 27, 2012 3:48 PM > To: Waltermire, David A. > Cc: mile@ietf.org > Subject: Re: [mile] RFC6546 possible editorial errata >=20 > Hi Dave, >=20 > I like the approach of reporting errors at the layer at which they > occur, but I do agree that this would be a technical change. >=20 > For the RID Acknowledgement message, what should be in the > RequestStatus instance to indicate that the RID message that is > being acknowledged was malformed (and hence has been discarded)? > Would UnrecognizedFormat cover this case? >=20 > Thanks, > --David >=20 >> -----Original Message----- >> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of >> Waltermire, David A. >> Sent: Tuesday, November 27, 2012 10:57 AM >> To: Moriarty, Kathleen; SM >> Cc: mile@ietf.org >> Subject: Re: [mile] RFC6546 possible editorial errata >>=20 >> I think it makes sense to classify any change to the original wording in >> question as technical, since it changes the technical meaning of the tex= t. >>=20 >> I am good with using the application layer Acknowledgement message to re= port a >> malformed RID request message. This looks like it is aligned well with = the >> text in rfc6545 section 6.2. >>=20 >> My only concern is introducing ambiguity from the other direction with t= he >> change. Relative to the transport, is the use of the acknowledgement ap= proach >> clear? Have the developers you mentioned weighed in on the change from = their >> perspectives? >>=20 >> Any other thoughts? >>=20 >> Thanks, >> Dave >>=20 >> -----Original Message----- >> From: Moriarty, Kathleen [mailto:kathleen.moriarty@emc.com] >> Sent: Wednesday, November 21, 2012 9:22 PM >> To: Waltermire, David A.; SM >> Cc: mile@ietf.org >> Subject: RE: [mile] RFC6546 possible editorial errata >>=20 >> Hi Dave, >>=20 >> Thanks for taking a look at this as well! >>=20 >> At the application layer, you have the ability to figure out what is wro= ng >> with the RID/IODEF document and provide a response with details via the >> Acknowledgement message. This would be in a 200 HTTP code according to = the >> table and then the 'Justification' can be set appropriately (xml encrypt= ion >> error, xml schema error, etc.). As a result, the language in the senten= ces >> provided is causing some confusion. I should have provided that context= in >> the initial message. Does the additional context change your view? I t= hink >> it would be easier for developers (and meet the intended objective with = the >> language change, but it may be technical and not editorial). Does that = change >> your view? >>=20 >> Anyone other thoughts from the list? >>=20 >> Thanks, >> Kathleen >> ________________________________________ >> From: Waltermire, David A. [david.waltermire@nist.gov] >> Sent: Wednesday, November 21, 2012 6:46 PM >> To: Moriarty, Kathleen; SM >> Cc: mile@ietf.org >> Subject: RE: [mile] RFC6546 possible editorial errata >>=20 >> The document is focused on applying the HTTP transport to define an >> application-layer protocol for RID (at least according to the abstract),= so to >> some extent it has its feet on both sides of the fence. ;-) >>=20 >> If the text is changed it might clarify what to do in the case of an inv= alid >> HTTP request at the transport layer. In doing so, wouldn't we then be >> introducing the same ambiguity at the application layer for an invalid R= ID >> message? In this case it would be undefined as to what to do if you hav= e a >> valid HTTP request from a transport perspective with an invalid RID mess= age >> from an application perspective. It might make sense instead to change = it to: >>=20 >> "If a RID system receives an improper HTTP Request or an improper RID me= ssage >> in a valid HTTP Request, it MUST return an appropriate 4xx Client Error >> result code to the requesting RID system." >>=20 >> Something like this would cover both cases making it clear to both devel= opers. >>=20 >> Happy Thanksgiving to those celebrating! >>=20 >> Sincerely, >> Dave >>=20 >> -----Original Message----- >> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of >> Moriarty, Kathleen >> Sent: Wednesday, November 21, 2012 11:21 AM >> To: SM >> Cc: mile@ietf.org >> Subject: Re: [mile] RFC6546 possible editorial errata >>=20 >> SM, >>=20 >> Thanks for the review! Here is the text that SM is referring to: >>=20 >> "If a RID system receives an improper RID message in an HTTP Request, >> it MUST return an appropriate 4xx Client Error result code to the >> requesting RID system. If a RID system cannot process a RID message >> received in an HTTP Request due to an error on its own side, it MUST >> return an appropriate 5xx Server Error result code to the requesting >> RID system." >>=20 >> I agree that the text is confusing as one developer interpreted it to ap= ply to >> the RID messages and another interpreted it as applying to HTTP since th= e >> codes are specific to HTTP and not the application layer. I believe the >> intent was that it applied to the HTTP error level as this document was >> focused on transport. I see your point that this may be a technical cha= nge. >> The following sentence has the same problem, do you agree with the asses= sment >> and what do others think? >>=20 >> Thanks, >> Kathleen >> ________________________________________ >> From: SM [sm@resistor.net] >> Sent: Wednesday, November 21, 2012 11:00 AM >> To: Moriarty, Kathleen >> Cc: mile@ietf.org >> Subject: Re: [mile] RFC6546 possible editorial errata >>=20 >> Hi Kathleen, >> At 15:31 20-11-2012, Moriarty, Kathleen wrote: >>> There has been some confusion by a developer on when to use a HTTP 4xx >>> response versus the use of an HTTP 200 response with an >>> acknowledgement. I think to get to the intent of RFC6545 and >>> RFC6546 a proposed text fix could address this confusion and just get >>> filed as an editorial errata: >>>=20 >>> Section 3, paragraph 12: >>> Change from: >>> If a RID system receives an improper RID message in an HTTP Request, >>> it MUST return an appropriate 4xx Client Error result code to the >>> requesting RID system. >>>=20 >>> To: >>> If a RID system receives an improper HTTP Request, >>> it MUST return an appropriate 4xx Client Error result code to the >>> requesting RID system. >>=20 >> The above suggested text changes the RFC 2119 requirement. I wouldn't >> consider it as editorial as the intent is debatable if there wasn't any >> (prior) discussion to support it. >>=20 >> BTW, the requirement is similar to the one in the sentence that follows = the >> one quoted above. >>=20 >> Regards, >> -sm >>=20 >>=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 >=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 From trammell@tik.ee.ethz.ch Wed Nov 28 12:49:55 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 31CD121F84D2 for ; Wed, 28 Nov 2012 12:49:55 -0800 (PST) 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 uusd+t2DDHih for ; Wed, 28 Nov 2012 12:49:54 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id B774021F88C2 for ; Wed, 28 Nov 2012 12:49:53 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id E83BBD9307; Wed, 28 Nov 2012 21:49:52 +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 3Vd53-enLHXK; Wed, 28 Nov 2012 21:49:52 +0100 (MET) Received: from [10.0.27.113] (cust-integra-122-165.antanet.ch [80.75.122.165]) (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 6AAFCD9305; Wed, 28 Nov 2012 21:49:52 +0100 (MET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Brian Trammell In-Reply-To: Date: Wed, 28 Nov 2012 21:49:50 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0064D4AE-6339-4A97-97F7-3543B91595B1@tik.ee.ethz.ch> References: , <6.2.5.6.2.20121121074441.09c00288@resistor.net> , <8D3D17ACE214DC429325B2B98F3AE71284D40403@MX15A.corp.emc.com> <4FB1BD7D-F1B1-4A2C-B795-6DAB2B1163D8@tik.ee.ethz.ch> To: "Moriarty, Kathleen" X-Mailer: Apple Mail (2.1499) Cc: "mile@ietf.org" Subject: Re: [mile] RFC6546 possible editorial errata 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, 28 Nov 2012 20:49:55 -0000 Hi, Kathleen, all, I suppose if we view 6546 as a completely separate layer for RID, it = makes sense for 200 OK to mean "I accepted your RID message", or "here = is a response" even if that response indicates error. In that case, the original fix (remove "improper RID message") would be = the correct one; I (as a contributor) would be okay with that. But yes, = it's clearly a technical ambiguity (in any case, the new text changes = how I'd implement it) and therefore a technical erratum. Best regards, Brian On 28 Nov 2012, at 1:30, "Moriarty, Kathleen" = wrote: > Hi Brian, >=20 > Malformed is the wrong word, we are really talking about the IODEF = schema or some embedded schema via the SCI draft not being conformant. = Or you could have some other schema sent in RID that is not recognized = by the receiving system (something other than IODEF). As such, handling = that error at the RID application layer is easier than at the HTTP layer = from a development perspective. There are a range of possible things = that could occur and malformed is not really the right word to describe = UnrecognizedFormat. By changing the response to a 400 with an = Acknowledgement now, that is pretty significant as the flows and tables = change to allow an Ack to come back in either a 200 or a 400 depending = on the Justification value selected. I think for developers, handling = HTTP at the HTTP layer is easier and then application errors at the RID = layer. I think it is a smaller change and may be better for adoption by = developers rather than having them do both before sending an HTTP 400 = message. >=20 > Does that help clear up your confusion? Any thoughts? >=20 > Thanks, > Kathleen >=20 > -----Original Message----- > From: Brian Trammell [mailto:trammell@tik.ee.ethz.ch]=20 > Sent: Tuesday, November 27, 2012 6:50 PM > To: Moriarty, Kathleen > Cc: Black, David; Waltermire, David A.; mile@ietf.org > Subject: Re: [mile] RFC6546 possible editorial errata >=20 > Hi, Kathleen, all, >=20 > (chair hat off) (6546 author hat on) >=20 > I'm a little confused on terminology here; "malformed" with respect to = a RID message meaning "not well-formed XML", or "XML not corresponding = to the RID schema"? >=20 > In any case, since there's an application-layer mechanism for = reporting such errors it makes sense to use it, of course. However, I'd = find something deeply odd about returning a 200 OK which inside it = contained an Acknowledgment signaling UnrecognizedFormat -- the response = status and response body would mismatch then. >=20 > I'd suggest instead 400 Bad Request, with Acknowledgment as response = body. >=20 > Which leaves us with NEW (a little stilted, can probably stand some = editorial improvement...) >=20 > If a RID system receives an improper HTTP Request, > it MUST return an appropriate 4xx Client Error result code to the > requesting RID system. If a RID system receives a malformed RID = message,=20 > it MUST return an Acknowledgment RID message, with 'Denied' as the > AuthorizationStatus attribute of RequestStatus and = 'UnrecognizedFormat'=20 > as the Justification attribute of RequestStatus, in a response with=20= > result code 400 Bad Request. If a RID system cannot process a RID = message > received in an HTTP Request due to an error on its own side, it MUST > return an appropriate 5xx Server Error result code to the requesting > RID system. >=20 > Best regards, > Brian >=20 > On Nov 27, 2012, at 10:11 PM, Moriarty, Kathleen wrote: >=20 >> Thanks, David. >>=20 >> Yes, UnrecognizedFormat for the Justification attribute would be the = correct response at the RID layer. >>=20 >> We have some consensus it seems. Brian and Sean may want to weigh in = as well (or anyone else). >>=20 >> Best regards, >> Kathleen >>=20 >> -----Original Message----- >> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf = Of Black, David >> Sent: Tuesday, November 27, 2012 3:48 PM >> To: Waltermire, David A. >> Cc: mile@ietf.org >> Subject: Re: [mile] RFC6546 possible editorial errata >>=20 >> Hi Dave, >>=20 >> I like the approach of reporting errors at the layer at which they >> occur, but I do agree that this would be a technical change. >>=20 >> For the RID Acknowledgement message, what should be in the >> RequestStatus instance to indicate that the RID message that is >> being acknowledged was malformed (and hence has been discarded)? >> Would UnrecognizedFormat cover this case? >>=20 >> Thanks, >> --David >>=20 >>> -----Original Message----- >>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf = Of >>> Waltermire, David A. >>> Sent: Tuesday, November 27, 2012 10:57 AM >>> To: Moriarty, Kathleen; SM >>> Cc: mile@ietf.org >>> Subject: Re: [mile] RFC6546 possible editorial errata >>>=20 >>> I think it makes sense to classify any change to the original = wording in >>> question as technical, since it changes the technical meaning of the = text. >>>=20 >>> I am good with using the application layer Acknowledgement message = to report a >>> malformed RID request message. This looks like it is aligned well = with the >>> text in rfc6545 section 6.2. >>>=20 >>> My only concern is introducing ambiguity from the other direction = with the >>> change. Relative to the transport, is the use of the = acknowledgement approach >>> clear? Have the developers you mentioned weighed in on the change = from their >>> perspectives? >>>=20 >>> Any other thoughts? >>>=20 >>> Thanks, >>> Dave >>>=20 >>> -----Original Message----- >>> From: Moriarty, Kathleen [mailto:kathleen.moriarty@emc.com] >>> Sent: Wednesday, November 21, 2012 9:22 PM >>> To: Waltermire, David A.; SM >>> Cc: mile@ietf.org >>> Subject: RE: [mile] RFC6546 possible editorial errata >>>=20 >>> Hi Dave, >>>=20 >>> Thanks for taking a look at this as well! >>>=20 >>> At the application layer, you have the ability to figure out what is = wrong >>> with the RID/IODEF document and provide a response with details via = the >>> Acknowledgement message. This would be in a 200 HTTP code according = to the >>> table and then the 'Justification' can be set appropriately (xml = encryption >>> error, xml schema error, etc.). As a result, the language in the = sentences >>> provided is causing some confusion. I should have provided that = context in >>> the initial message. Does the additional context change your view? = I think >>> it would be easier for developers (and meet the intended objective = with the >>> language change, but it may be technical and not editorial). Does = that change >>> your view? >>>=20 >>> Anyone other thoughts from the list? >>>=20 >>> Thanks, >>> Kathleen >>> ________________________________________ >>> From: Waltermire, David A. [david.waltermire@nist.gov] >>> Sent: Wednesday, November 21, 2012 6:46 PM >>> To: Moriarty, Kathleen; SM >>> Cc: mile@ietf.org >>> Subject: RE: [mile] RFC6546 possible editorial errata >>>=20 >>> The document is focused on applying the HTTP transport to define an >>> application-layer protocol for RID (at least according to the = abstract), so to >>> some extent it has its feet on both sides of the fence. ;-) >>>=20 >>> If the text is changed it might clarify what to do in the case of an = invalid >>> HTTP request at the transport layer. In doing so, wouldn't we then = be >>> introducing the same ambiguity at the application layer for an = invalid RID >>> message? In this case it would be undefined as to what to do if you = have a >>> valid HTTP request from a transport perspective with an invalid RID = message >>> from an application perspective. It might make sense instead to = change it to: >>>=20 >>> "If a RID system receives an improper HTTP Request or an improper = RID message >>> in a valid HTTP Request, it MUST return an appropriate 4xx Client = Error >>> result code to the requesting RID system." >>>=20 >>> Something like this would cover both cases making it clear to both = developers. >>>=20 >>> Happy Thanksgiving to those celebrating! >>>=20 >>> Sincerely, >>> Dave >>>=20 >>> -----Original Message----- >>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf = Of >>> Moriarty, Kathleen >>> Sent: Wednesday, November 21, 2012 11:21 AM >>> To: SM >>> Cc: mile@ietf.org >>> Subject: Re: [mile] RFC6546 possible editorial errata >>>=20 >>> SM, >>>=20 >>> Thanks for the review! Here is the text that SM is referring to: >>>=20 >>> "If a RID system receives an improper RID message in an HTTP = Request, >>> it MUST return an appropriate 4xx Client Error result code to the >>> requesting RID system. If a RID system cannot process a RID = message >>> received in an HTTP Request due to an error on its own side, it = MUST >>> return an appropriate 5xx Server Error result code to the = requesting >>> RID system." >>>=20 >>> I agree that the text is confusing as one developer interpreted it = to apply to >>> the RID messages and another interpreted it as applying to HTTP = since the >>> codes are specific to HTTP and not the application layer. I believe = the >>> intent was that it applied to the HTTP error level as this document = was >>> focused on transport. I see your point that this may be a technical = change. >>> The following sentence has the same problem, do you agree with the = assessment >>> and what do others think? >>>=20 >>> Thanks, >>> Kathleen >>> ________________________________________ >>> From: SM [sm@resistor.net] >>> Sent: Wednesday, November 21, 2012 11:00 AM >>> To: Moriarty, Kathleen >>> Cc: mile@ietf.org >>> Subject: Re: [mile] RFC6546 possible editorial errata >>>=20 >>> Hi Kathleen, >>> At 15:31 20-11-2012, Moriarty, Kathleen wrote: >>>> There has been some confusion by a developer on when to use a HTTP = 4xx >>>> response versus the use of an HTTP 200 response with an >>>> acknowledgement. I think to get to the intent of RFC6545 and >>>> RFC6546 a proposed text fix could address this confusion and just = get >>>> filed as an editorial errata: >>>>=20 >>>> Section 3, paragraph 12: >>>> Change from: >>>> If a RID system receives an improper RID message in an HTTP = Request, >>>> it MUST return an appropriate 4xx Client Error result code to the >>>> requesting RID system. >>>>=20 >>>> To: >>>> If a RID system receives an improper HTTP Request, >>>> it MUST return an appropriate 4xx Client Error result code to the >>>> requesting RID system. >>>=20 >>> The above suggested text changes the RFC 2119 requirement. I = wouldn't >>> consider it as editorial as the intent is debatable if there wasn't = any >>> (prior) discussion to support it. >>>=20 >>> BTW, the requirement is similar to the one in the sentence that = follows the >>> one quoted above. >>>=20 >>> Regards, >>> -sm >>>=20 >>>=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 >>=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 >=20 From turners@ieca.com Thu Nov 29 08:36:52 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 617A721F89E4 for ; Thu, 29 Nov 2012 08:36:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.254 X-Spam-Level: X-Spam-Status: No, score=-102.254 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 hbLVpJGKMITr for ; Thu, 29 Nov 2012 08:36:51 -0800 (PST) Received: from gateway04.websitewelcome.com (gateway04.websitewelcome.com [67.18.59.10]) by ietfa.amsl.com (Postfix) with ESMTP id 45A9421F8AF8 for ; Thu, 29 Nov 2012 08:36:51 -0800 (PST) Received: by gateway04.websitewelcome.com (Postfix, from userid 5007) id A36D690B31E41; Thu, 29 Nov 2012 10:36:49 -0600 (CST) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway04.websitewelcome.com (Postfix) with ESMTP id 9595390B31DF7 for ; Thu, 29 Nov 2012 10:36:49 -0600 (CST) Received: from [108.45.19.185] (port=49719 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1Te76X-0006qs-Vu for mile@ietf.org; Thu, 29 Nov 2012 10:36:50 -0600 Message-ID: <50B78F21.9050001@ieca.com> Date: Thu, 29 Nov 2012 11:36:49 -0500 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: "mile@ietf.org" References: , <6.2.5.6.2.20121121074441.09c00288@resistor.net> , <8D3D17ACE214DC429325B2B98F3AE71284D40403@MX15A.corp.emc.com> <4FB1BD7D-F1B1-4A2C-B795-6DAB2B1163D8@tik.ee.ethz.ch> <0064D4AE-6339-4A97-97F7-3543B91595B1@tik.ee.ethz.ch> In-Reply-To: <0064D4AE-6339-4A97-97F7-3543B91595B1@tik.ee.ethz.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [108.45.19.185]:49719 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 7 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: Re: [mile] RFC6546 possible editorial errata 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, 29 Nov 2012 16:36:52 -0000 wfm spt On 11/28/12 3:49 PM, Brian Trammell wrote: > Hi, Kathleen, all, > > I suppose if we view 6546 as a completely separate layer for RID, it makes sense for 200 OK to mean "I accepted your RID message", or "here is a response" even if that response indicates error. > > In that case, the original fix (remove "improper RID message") would be the correct one; I (as a contributor) would be okay with that. But yes, it's clearly a technical ambiguity (in any case, the new text changes how I'd implement it) and therefore a technical erratum. > > Best regards, > > Brian > > On 28 Nov 2012, at 1:30, "Moriarty, Kathleen" wrote: > >> Hi Brian, >> >> Malformed is the wrong word, we are really talking about the IODEF schema or some embedded schema via the SCI draft not being conformant. Or you could have some other schema sent in RID that is not recognized by the receiving system (something other than IODEF). As such, handling that error at the RID application layer is easier than at the HTTP layer from a development perspective. There are a range of possible things that could occur and malformed is not really the right word to describe UnrecognizedFormat. By changing the response to a 400 with an Acknowledgement now, that is pretty significant as the flows and tables change to allow an Ack to come back in either a 200 or a 400 depending on the Justification value selected. I think for developers, handling HTTP at the HTTP layer is easier and then application errors at the RID layer. I think it is a smaller change and may be better for adoption by developers rather than having them do both before sending an HTTP 4 0 > 0 message. >> >> Does that help clear up your confusion? Any thoughts? >> >> Thanks, >> Kathleen >> >> -----Original Message----- >> From: Brian Trammell [mailto:trammell@tik.ee.ethz.ch] >> Sent: Tuesday, November 27, 2012 6:50 PM >> To: Moriarty, Kathleen >> Cc: Black, David; Waltermire, David A.; mile@ietf.org >> Subject: Re: [mile] RFC6546 possible editorial errata >> >> Hi, Kathleen, all, >> >> (chair hat off) (6546 author hat on) >> >> I'm a little confused on terminology here; "malformed" with respect to a RID message meaning "not well-formed XML", or "XML not corresponding to the RID schema"? >> >> In any case, since there's an application-layer mechanism for reporting such errors it makes sense to use it, of course. However, I'd find something deeply odd about returning a 200 OK which inside it contained an Acknowledgment signaling UnrecognizedFormat -- the response status and response body would mismatch then. >> >> I'd suggest instead 400 Bad Request, with Acknowledgment as response body. >> >> Which leaves us with NEW (a little stilted, can probably stand some editorial improvement...) >> >> If a RID system receives an improper HTTP Request, >> it MUST return an appropriate 4xx Client Error result code to the >> requesting RID system. If a RID system receives a malformed RID message, >> it MUST return an Acknowledgment RID message, with 'Denied' as the >> AuthorizationStatus attribute of RequestStatus and 'UnrecognizedFormat' >> as the Justification attribute of RequestStatus, in a response with >> result code 400 Bad Request. If a RID system cannot process a RID message >> received in an HTTP Request due to an error on its own side, it MUST >> return an appropriate 5xx Server Error result code to the requesting >> RID system. >> >> Best regards, >> Brian >> >> On Nov 27, 2012, at 10:11 PM, Moriarty, Kathleen wrote: >> >>> Thanks, David. >>> >>> Yes, UnrecognizedFormat for the Justification attribute would be the correct response at the RID layer. >>> >>> We have some consensus it seems. Brian and Sean may want to weigh in as well (or anyone else). >>> >>> Best regards, >>> Kathleen >>> >>> -----Original Message----- >>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Black, David >>> Sent: Tuesday, November 27, 2012 3:48 PM >>> To: Waltermire, David A. >>> Cc: mile@ietf.org >>> Subject: Re: [mile] RFC6546 possible editorial errata >>> >>> Hi Dave, >>> >>> I like the approach of reporting errors at the layer at which they >>> occur, but I do agree that this would be a technical change. >>> >>> For the RID Acknowledgement message, what should be in the >>> RequestStatus instance to indicate that the RID message that is >>> being acknowledged was malformed (and hence has been discarded)? >>> Would UnrecognizedFormat cover this case? >>> >>> Thanks, >>> --David >>> >>>> -----Original Message----- >>>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of >>>> Waltermire, David A. >>>> Sent: Tuesday, November 27, 2012 10:57 AM >>>> To: Moriarty, Kathleen; SM >>>> Cc: mile@ietf.org >>>> Subject: Re: [mile] RFC6546 possible editorial errata >>>> >>>> I think it makes sense to classify any change to the original wording in >>>> question as technical, since it changes the technical meaning of the text. >>>> >>>> I am good with using the application layer Acknowledgement message to report a >>>> malformed RID request message. This looks like it is aligned well with the >>>> text in rfc6545 section 6.2. >>>> >>>> My only concern is introducing ambiguity from the other direction with the >>>> change. Relative to the transport, is the use of the acknowledgement approach >>>> clear? Have the developers you mentioned weighed in on the change from their >>>> perspectives? >>>> >>>> Any other thoughts? >>>> >>>> Thanks, >>>> Dave >>>> >>>> -----Original Message----- >>>> From: Moriarty, Kathleen [mailto:kathleen.moriarty@emc.com] >>>> Sent: Wednesday, November 21, 2012 9:22 PM >>>> To: Waltermire, David A.; SM >>>> Cc: mile@ietf.org >>>> Subject: RE: [mile] RFC6546 possible editorial errata >>>> >>>> Hi Dave, >>>> >>>> Thanks for taking a look at this as well! >>>> >>>> At the application layer, you have the ability to figure out what is wrong >>>> with the RID/IODEF document and provide a response with details via the >>>> Acknowledgement message. This would be in a 200 HTTP code according to the >>>> table and then the 'Justification' can be set appropriately (xml encryption >>>> error, xml schema error, etc.). As a result, the language in the sentences >>>> provided is causing some confusion. I should have provided that context in >>>> the initial message. Does the additional context change your view? I think >>>> it would be easier for developers (and meet the intended objective with the >>>> language change, but it may be technical and not editorial). Does that change >>>> your view? >>>> >>>> Anyone other thoughts from the list? >>>> >>>> Thanks, >>>> Kathleen >>>> ________________________________________ >>>> From: Waltermire, David A. [david.waltermire@nist.gov] >>>> Sent: Wednesday, November 21, 2012 6:46 PM >>>> To: Moriarty, Kathleen; SM >>>> Cc: mile@ietf.org >>>> Subject: RE: [mile] RFC6546 possible editorial errata >>>> >>>> The document is focused on applying the HTTP transport to define an >>>> application-layer protocol for RID (at least according to the abstract), so to >>>> some extent it has its feet on both sides of the fence. ;-) >>>> >>>> If the text is changed it might clarify what to do in the case of an invalid >>>> HTTP request at the transport layer. In doing so, wouldn't we then be >>>> introducing the same ambiguity at the application layer for an invalid RID >>>> message? In this case it would be undefined as to what to do if you have a >>>> valid HTTP request from a transport perspective with an invalid RID message >>>> from an application perspective. It might make sense instead to change it to: >>>> >>>> "If a RID system receives an improper HTTP Request or an improper RID message >>>> in a valid HTTP Request, it MUST return an appropriate 4xx Client Error >>>> result code to the requesting RID system." >>>> >>>> Something like this would cover both cases making it clear to both developers. >>>> >>>> Happy Thanksgiving to those celebrating! >>>> >>>> Sincerely, >>>> Dave >>>> >>>> -----Original Message----- >>>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of >>>> Moriarty, Kathleen >>>> Sent: Wednesday, November 21, 2012 11:21 AM >>>> To: SM >>>> Cc: mile@ietf.org >>>> Subject: Re: [mile] RFC6546 possible editorial errata >>>> >>>> SM, >>>> >>>> Thanks for the review! Here is the text that SM is referring to: >>>> >>>> "If a RID system receives an improper RID message in an HTTP Request, >>>> it MUST return an appropriate 4xx Client Error result code to the >>>> requesting RID system. If a RID system cannot process a RID message >>>> received in an HTTP Request due to an error on its own side, it MUST >>>> return an appropriate 5xx Server Error result code to the requesting >>>> RID system." >>>> >>>> I agree that the text is confusing as one developer interpreted it to apply to >>>> the RID messages and another interpreted it as applying to HTTP since the >>>> codes are specific to HTTP and not the application layer. I believe the >>>> intent was that it applied to the HTTP error level as this document was >>>> focused on transport. I see your point that this may be a technical change. >>>> The following sentence has the same problem, do you agree with the assessment >>>> and what do others think? >>>> >>>> Thanks, >>>> Kathleen >>>> ________________________________________ >>>> From: SM [sm@resistor.net] >>>> Sent: Wednesday, November 21, 2012 11:00 AM >>>> To: Moriarty, Kathleen >>>> Cc: mile@ietf.org >>>> Subject: Re: [mile] RFC6546 possible editorial errata >>>> >>>> Hi Kathleen, >>>> At 15:31 20-11-2012, Moriarty, Kathleen wrote: >>>>> There has been some confusion by a developer on when to use a HTTP 4xx >>>>> response versus the use of an HTTP 200 response with an >>>>> acknowledgement. I think to get to the intent of RFC6545 and >>>>> RFC6546 a proposed text fix could address this confusion and just get >>>>> filed as an editorial errata: >>>>> >>>>> Section 3, paragraph 12: >>>>> Change from: >>>>> If a RID system receives an improper RID message in an HTTP Request, >>>>> it MUST return an appropriate 4xx Client Error result code to the >>>>> requesting RID system. >>>>> >>>>> To: >>>>> If a RID system receives an improper HTTP Request, >>>>> it MUST return an appropriate 4xx Client Error result code to the >>>>> requesting RID system. >>>> >>>> The above suggested text changes the RFC 2119 requirement. I wouldn't >>>> consider it as editorial as the intent is debatable if there wasn't any >>>> (prior) discussion to support it. >>>> >>>> BTW, the requirement is similar to the one in the sentence that follows the >>>> one quoted above. >>>> >>>> Regards, >>>> -sm >>>> >>>> >>>> _______________________________________________ >>>> 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 >>> >>> _______________________________________________ >>> 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 amontville@tripwire.com Thu Nov 29 12:29: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 EEF6121F8C11 for ; Thu, 29 Nov 2012 12:29:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V6JGMayY4d+q for ; Thu, 29 Nov 2012 12:29:31 -0800 (PST) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe003.messaging.microsoft.com [216.32.180.13]) by ietfa.amsl.com (Postfix) with ESMTP id 7C69521F8C35 for ; Thu, 29 Nov 2012 12:29:31 -0800 (PST) Received: from mail190-va3-R.bigfish.com (10.7.14.239) by VA3EHSOBE007.bigfish.com (10.7.40.11) with Microsoft SMTP Server id 14.1.225.23; Thu, 29 Nov 2012 20:29:30 +0000 Received: from mail190-va3 (localhost [127.0.0.1]) by mail190-va3-R.bigfish.com (Postfix) with ESMTP id 357E81806B7 for ; Thu, 29 Nov 2012 20:29:30 +0000 (UTC) X-Forefront-Antispam-Report: CIP:174.47.84.215; KIP:(null); UIP:(null); IPV:NLI; H:zgw01.tripwire.com; RD:174-47-84-215.static.twtelecom.net; EFVD:NLI X-SpamScore: -32 X-BigFish: VPS-32(zz98dI9371I9f17Rc85eh148cI4015I1415Izz1de0h1202h1d1ah1d2ahzz1033IL17326ah8275bh8275dh18c673hz2dh2a8h668h839hd25he5bhf0ah1288h12a5h12bdh137ah1441h14ddh1504h1537h153bh162dh1631hbe3k1155h) Received: from mail190-va3 (localhost.localdomain [127.0.0.1]) by mail190-va3 (MessageSwitch) id 1354220967991253_10658; Thu, 29 Nov 2012 20:29:27 +0000 (UTC) Received: from VA3EHSMHS020.bigfish.com (unknown [10.7.14.237]) by mail190-va3.bigfish.com (Postfix) with ESMTP id ED873601C9 for ; Thu, 29 Nov 2012 20:29:27 +0000 (UTC) Received: from zgw01.tripwire.com (174.47.84.215) by VA3EHSMHS020.bigfish.com (10.7.99.30) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 29 Nov 2012 20:29:27 +0000 Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.tripwire.com (Proprietary) with SMTP id 4BB192321217 for ; Thu, 29 Nov 2012 12:18:55 -0800 (PST) Received: from PDXED01.tripwire.com (unknown [192.168.192.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by zgw01.tripwire.com (Proprietary) with ESMTPS id A157023211FF; Thu, 29 Nov 2012 12:18:54 -0800 (PST) Received: from PDXHB01.tripwire.com (172.30.0.53) by PDXED01.tripwire.com (192.168.192.5) with Microsoft SMTP Server (TLS) id 14.1.379.0; Thu, 29 Nov 2012 12:34:09 -0800 Received: from PDXMB02.tripwire.com ([fe80::f997:7b65:8e64:438e]) by PDXHB01.tripwire.com ([fe80::d495:98d2:7df4:2154%11]) with mapi id 14.01.0421.002; Thu, 29 Nov 2012 12:29:25 -0800 From: Adam Montville To: "Black, David" Thread-Topic: Updated IODEF Enumeration Reference Format Draft Thread-Index: AQHNvQ3c5igWirSip0ScCVgUmvLL1JfuMxLggBO5WgA= Date: Thu, 29 Nov 2012 20:29:24 +0000 Message-ID: <74613456-C11E-434C-91FF-23F2AAF7B87D@tripwire.com> References: <18EDCB49-399F-44DC-BF11-9A77F3E459FC@tripwire.com> <8D3D17ACE214DC429325B2B98F3AE71284B5A565@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE71284B5A565@MX15A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.16.97.59] x-exclaimer-md-config: 79afcaa7-fdf4-4fa6-abe0-afeaa4640a4f Content-Type: multipart/alternative; boundary="_000_74613456C11E434C91FF23F2AAF7B87Dtripwirecom_" MIME-Version: 1.0 X-VPM-MSG-ID: 24cf920a-3f9c-4401-8d18-a7dcc3598641 X-VPM-HOST: zgw01.tripwire.com X-VPM-ENC-REGIME: Plaintext X-VPM-CERT-FLAG: 0 X-VPM-IS-HYBRID: 0 X-OriginatorOrg: tripwire.com Cc: "" Subject: Re: [mile] Updated IODEF Enumeration Reference Format Draft 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, 29 Nov 2012 20:29:33 -0000 --_000_74613456C11E434C91FF23F2AAF7B87Dtripwirecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi David, Thank you for your diligence! I do appreciate it. Please see comments inline. Regards, Adam On Nov 17, 2012, at 7:42 AM, "Black, David" > wrote: Adam, Thanks for working on this draft. I see that the version is included in the id_type string prefix. I=92m assuming that this version is the version number of the registered specification. That makes sense if the version doesn=92t change often and especially if a version change results in a change to the identifier format. How often does the version change for the specs that are the sources of the enumerations of interest? >From what I've seen, rarely. However, emerging enumerations could be used = and they might change more frequently. If the spec version changes often, and especially if enumeration identifiers from previous versions usually remain valid in new versions, an alternative approach would be to tie the version to the identifier format rather than the spec version - this could avoid having several dozen id_type strings for versions of a single spec. So, what you're proposing is that the versioning information be attached to= id rather than id_type. That seems reasonable to me. Please also take a look at these two emails that I sent to the list earlier= : identifier formats: http://www.ietf.org/mail-archive/web/mile/current/msg00= 853.html With respect to this message, which is about id and id_type formatting, I'm= happy to make adjustments to the draft where necessary. In that message y= ou mention guidance being provided to the Designated Expert. Where would t= hat guidance be provided in the draft (or is it provided elsewhere)? Additionally, I'm interested to know what others think about these approach= es. Again, I'm here to create a draft based on what the community wants to= see implemented, so chime in if you have an opinion in these matters. more on versions: http://www.ietf.org/mail-archive/web/mile/current/msg0085= 4.html Take and I had an opportunity to speak in Atlanta, and I understand the con= cern represented in the message above. This will be addressed in a forthco= ming revision. I have some additional editorial concerns that I=92ll send to you directly. Thanks, --David From: mile-bounces@ietf.org [mailto:mile-boun= ces@ietf.org] On Behalf Of Adam Montville Sent: Wednesday, November 07, 2012 12:32 PM To: > Subject: [mile] Updated IODEF Enumeration Reference Format Draft All: I'm pleased to submit draft-montville-mile-enum-reference-format-01 availab= le at http://www.ietf.org/id/draft-montville-mile-enum-reference-format-01.txt Changes: * IANA Table Request Changes * Removed "Name" * Added "Full Name * Added "Abbreviation" * Specified id_type to be _ * Reviewed text for scope statements and limited scope to IODEF, while = alluding to the method's potential usefulness elsewhere. * Ensured that the Reference class diagram is explicitly referenced as = [IODEF]. * Updated IANA Considerations to request creation of the table * Updated IANA table format fields with simple descriptions I look forward to your comments. Regards, Adam W. Montville | Security and Compliance Architect CISA, CISSP Direct: 503 276-7661 Mobile: 360 471-7815 TRIPWIRE | Take CONTROL http://www.tripwire.com --_000_74613456C11E434C91FF23F2AAF7B87Dtripwirecom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <72F4CCC29A2C0647BA6DD9C88B966915@tripwire.com> Content-Transfer-Encoding: quoted-printable Hi David,

Thank you for your diligence!  I do appreciate it.

Please see comments inline.

Regards,

Adam

On Nov 17, 2012, at 7:42 AM, "Black, David" <david.black@emc.com> wrote:

Adam,
 =
Thanks for wo= rking on this draft.
 =
I see that th= e version is included in the id_type string prefix.
I=92m assumin= g that this version is the version number of the registered
specification= .  That makes sense if the version doesn=92t change often
and especiall= y if a version change results in a change to the identifier
format. =
 =
How often doe= s the version change for the specs that are the sources of
the enumerati= ons of interest?

From what I've seen, rarely.  However, emerging enumerations coul= d be used and they might change more frequently.

 =
If the spec v= ersion changes often, and especially if enumeration
identifiers f= rom previous versions usually remain valid in new versions,
an alternativ= e approach would be to tie the version to the identifier<= /div>
format rather= than the spec version - this could avoid having several<= /div>
dozen id_type= strings for versions of a single spec.

So, what you're proposing is that the versioning information be attach= ed to id rather than id_type.  That seems reasonable to me.


 =
Please also t= ake a look at these two emails that I sent to the list earlier:<= /span>
 =

With respect to this message, which is about id and id_type formatting= , I'm happy to make adjustments to the draft where necessary.  In that= message you mention guidance being provided to the Designated Expert. &nbs= p;Where would that guidance be provided in the draft (or is it provided elsewhere)?  

Additionally, I'm interested to know what others think about these app= roaches.  Again, I'm here to create a draft based on what the communit= y wants to see implemented, so chime in if you have an opinion in these mat= ters.


Take and I had an opportunity to speak in Atlanta, and I understand th= e concern represented in the message above.  This will be addressed in= a forthcoming revision.

 =
I have some a= dditional editorial concerns that I=92ll send to you directly.
 =
Thanks,
--David
 =
From:=  m= ile-bounces@ietf.org = [mailto:mile-bounces@ietf.org] On Behalf Of Adam Montv= ille
Sent: Wednesday, N= ovember 07, 2012 12:32 PM
To: < [mile] Up= dated IODEF Enumeration Reference Format Draft
 
All:
 
I'm pleased to submit draft-montville-mile-enum-reference-format-01 availab= le at
 
 
Changes:
 
  • IANA Table Request Changes
    • Removed "Name"
    • Added "Full Name
    • Added "Abbreviation"
  • Specified id_type to be <Abbreviation>_<Version>
  • Reviewed text for scope statements and limited scope to IODEF, while alludi= ng to the method's potential usefulness elsewhere.
  • Ensured that the Reference class diagram is explicitly referenced as [IODEF= ].
  • Updated IANA Considerations to request creation of the table
  • Updated IANA table format fields with simple descriptions
    •  
 
I look forward to your comments.
 
Regards,
 = ;
Adam W. Montville | Security and Compliance Archite= ct
CISA, CISSP=
 = ;
Direct: 503 276-7661
Mobile: 360 471-7815
 = ;
TRIPWIRE | Take CONTR= OL
&nb= sp;
&nb= sp;
 = ;

 

 

--_000_74613456C11E434C91FF23F2AAF7B87Dtripwirecom_-- From amontville@tripwire.com Fri Nov 30 06:53:57 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 46A5021F8AFB for ; Fri, 30 Nov 2012 06:53:57 -0800 (PST) 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=[AWL=0.001, 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 uSE0+aHviu3Q for ; Fri, 30 Nov 2012 06:53:56 -0800 (PST) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe003.messaging.microsoft.com [216.32.180.186]) by ietfa.amsl.com (Postfix) with ESMTP id B8C2B21F8ADD for ; Fri, 30 Nov 2012 06:53:56 -0800 (PST) Received: from mail13-co1-R.bigfish.com (10.243.78.250) by CO1EHSOBE009.bigfish.com (10.243.66.72) with Microsoft SMTP Server id 14.1.225.23; Fri, 30 Nov 2012 14:53:56 +0000 Received: from mail13-co1 (localhost [127.0.0.1]) by mail13-co1-R.bigfish.com (Postfix) with ESMTP id 29C399002D3 for ; Fri, 30 Nov 2012 14:53:56 +0000 (UTC) X-Forefront-Antispam-Report: CIP:174.47.84.215; KIP:(null); UIP:(null); IPV:NLI; H:zgw01.tripwire.com; RD:174-47-84-215.static.twtelecom.net; EFVD:NLI X-SpamScore: 0 X-BigFish: VPS0(zz1452Izz1de0h1202h1d1ah1d2ahz31izz2dh2a8h668h839h944hd25he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h14ddh1504h1537h153bh162dh1631h1155h) Received: from mail13-co1 (localhost.localdomain [127.0.0.1]) by mail13-co1 (MessageSwitch) id 1354287234909685_18656; Fri, 30 Nov 2012 14:53:54 +0000 (UTC) Received: from CO1EHSMHS003.bigfish.com (unknown [10.243.78.231]) by mail13-co1.bigfish.com (Postfix) with ESMTP id D4B5BD800D6 for ; Fri, 30 Nov 2012 14:53:54 +0000 (UTC) Received: from zgw01.tripwire.com (174.47.84.215) by CO1EHSMHS003.bigfish.com (10.243.66.13) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 30 Nov 2012 14:52:30 +0000 Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.tripwire.com (Proprietary) with SMTP id 643B9232124A for ; Fri, 30 Nov 2012 06:41:55 -0800 (PST) Received: from PDXED01.tripwire.com (unknown [192.168.192.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by zgw01.tripwire.com (Proprietary) with ESMTPS id C82372321205 for ; Fri, 30 Nov 2012 06:41:54 -0800 (PST) Received: from PDXHB01.tripwire.com (172.30.0.53) by PDXED01.tripwire.com (192.168.192.5) with Microsoft SMTP Server (TLS) id 14.1.379.0; Fri, 30 Nov 2012 06:57:12 -0800 Received: from PDXMB02.tripwire.com ([fe80::f997:7b65:8e64:438e]) by PDXHB01.tripwire.com ([fe80::d495:98d2:7df4:2154%11]) with mapi id 14.01.0421.002; Fri, 30 Nov 2012 06:52:29 -0800 From: Adam Montville To: "" Thread-Topic: Working on IODEF Enum Reference Format Thread-Index: AQHNzwpRUNHbSaH+bU2zRtF3rlP8/A== Date: Fri, 30 Nov 2012 14:52:28 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.0.234] x-exclaimer-md-config: 79afcaa7-fdf4-4fa6-abe0-afeaa4640a4f Content-Type: text/plain; charset="us-ascii" Content-ID: <0F643DB9138687408DC7FE19ED7A8831@tripwire.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-VPM-MSG-ID: 467ea58e-8d97-47d4-8d61-1408704e59e1 X-VPM-HOST: zgw01.tripwire.com X-VPM-ENC-REGIME: Plaintext X-VPM-CERT-FLAG: 0 X-VPM-IS-HYBRID: 0 X-OriginatorOrg: tripwire.com Subject: [mile] Working on IODEF Enum Reference Format 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, 30 Nov 2012 14:53:57 -0000 All: I'm working on the IODEF Enumeration Reference Format draft. Several sugge= stions have been made since 02 publication during the week in Atlanta. Her= e's what's happening now: * Abstract is being narrowed to the scope of IODEF exclusively * The term "enumeration identifiers" is used consistently * Additional guidance for and is provided * Format of ReferenceName string is id_type:version:id Open Questions: * Should this draft support Unicode characters? IODEF presently does not s= upport the Unicode character set, but I presume this will be one of the add= ressed concerns when work on 5070-bis begins. Still, at issue is whether U= nicode support should simply be called out now rather than rely on 5070 rew= ork. Thoughts? Adam=