From Adam.Montville@cisecurity.org Mon Dec 2 07:37:19 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CC2B1AE493 for ; Mon, 2 Dec 2013 07:37:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AUpy9Z7oQSiM for ; Mon, 2 Dec 2013 07:37:17 -0800 (PST) Received: from mail1.bemta8.messagelabs.com (mail1.bemta8.messagelabs.com [216.82.243.198]) by ietfa.amsl.com (Postfix) with ESMTP id 6BA9B1A1DFA for ; Mon, 2 Dec 2013 07:37:17 -0800 (PST) Received: from [216.82.241.211:54625] by server-6.bemta-8.messagelabs.com id E1/69-13366-929AC925; Mon, 02 Dec 2013 15:37:13 +0000 X-Env-Sender: Adam.Montville@cisecurity.org X-Msg-Ref: server-11.tower-85.messagelabs.com!1385998633!38751112!2 X-Originating-IP: [69.195.43.86] X-StarScan-Received: X-StarScan-Version: 6.9.13; banners=cisecurity.org,-,- X-VirusChecked: Checked Received: (qmail 28712 invoked from network); 2 Dec 2013 15:37:13 -0000 Received: from mail.msisac.org (HELO mail.msisac.org) (69.195.43.86) by server-11.tower-85.messagelabs.com with AES128-SHA encrypted SMTP; 2 Dec 2013 15:37:13 -0000 Received: from CISEXCHANGE1.msisac.org.local ([fe80::4f0:b68d:e779:38c3]) by CISEXCHANGE2.msisac.org.local ([::1]) with mapi id 14.02.0347.000; Mon, 2 Dec 2013 10:35:14 -0500 From: Adam Montville To: "Romascanu, Dan (Dan)" , "sacm@ietf.org" Thread-Topic: preliminary minutes of the SACM WG meeting at IETF-88 Thread-Index: Ac7quSgoP9PIVFgzSrCcju20y330fwEuyUiw Date: Mon, 2 Dec 2013 15:35:22 +0000 Message-ID: <05BCCEB107AF88469B9F99783D47C1D6065D462B@CISEXCHANGE1.msisac.org.local> References: <9904FB1B0159DA42B0B887B7FA8119CA1294A42A@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA1294A42A@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.252.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sacm] preliminary minutes of the SACM WG meeting at IETF-88 X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 15:37:19 -0000 Thank you, Dan, for uploading these, and thank you to Aaron and Kent... T= hese minutes appear accurate and comprehensive to me. Regards, Adam > -----Original Message----- > From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Romascanu, Dan > (Dan) > Sent: Tuesday, November 26, 2013 9:06 AM > To: sacm@ietf.org > Subject: [sacm] preliminary minutes of the SACM WG meeting at IETF-88 >=20 > Hi, >=20 > I uploaded the preliminary minutes from the IETF 88 SACM WG meeting - > http://www.ietf.org/proceedings/88/minutes/minutes-88-sacm. Thanks to > Aaron Woland and Kent Landfield for the excellent notes the minutes are > based upon. Please read, correct the mistakes and fill in the missing. >=20 > Thanks and Regards, >=20 > Dan >=20 >=20 >=20 >=20 > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm >=20 > ... . . . From kathleen.moriarty@emc.com Wed Dec 4 11:46:34 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10D4B1AE0D6 for ; Wed, 4 Dec 2013 11:46:34 -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_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ve74vuQSyDGt for ; Wed, 4 Dec 2013 11:46:31 -0800 (PST) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) by ietfa.amsl.com (Postfix) with ESMTP id 59F581AD957 for ; Wed, 4 Dec 2013 11:46:26 -0800 (PST) Received: from maildlpprd56.lss.emc.com (maildlpprd56.lss.emc.com [10.106.48.160]) by mailuogwprd51.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id rB4JkCQO005821 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Dec 2013 14:46:13 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com rB4JkCQO005821 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1386186373; bh=LkW2F4MImB78mGKr9PxQW5JKHIU=; h=From:To:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=fp9jWyYMeVy9MnJTvmdKpqmg5h3YES9IJ1zoANGKwe9O6qmi5F+wbNk5oNpWb2af+ QeS2X9Mz10x4j0L5jWd+aDj5qKdFuW09/jTm6UXsDKESU1ubAP7Lq8Y7kVwWO4FbWk XBxmYWO/0qW2h73OcDVz3zCe829aYE6eCOe1qT6U= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com rB4JkCQO005821 Received: from mailusrhubprd02.lss.emc.com (mailusrhubprd02.lss.emc.com [10.253.24.20]) by maildlpprd56.lss.emc.com (RSA Interceptor); Wed, 4 Dec 2013 14:46:00 -0500 Received: from mxhub06.corp.emc.com (mxhub06.corp.emc.com [128.222.70.203]) by mailusrhubprd02.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id rB4Jk0Mc003978 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 4 Dec 2013 14:46:00 -0500 Received: from mx15a.corp.emc.com ([169.254.1.239]) by mxhub06.corp.emc.com ([128.222.70.203]) with mapi; Wed, 4 Dec 2013 14:46:00 -0500 From: "Moriarty, Kathleen" To: Hosnieh , "sacm@ietf.org" Date: Wed, 4 Dec 2013 14:45:58 -0500 Thread-Topic: [sacm] Is latency is important for you? Thread-Index: Ac7myGHX2LFFx8cUTlCfT9uv4Fmk1QKYDilA Message-ID: References: <492903078.119554.1385045144290.open-xchange@email.1and1.com> In-Reply-To: <492903078.119554.1385045144290.open-xchange@email.1and1.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_F5063677821E3B4F81ACFB7905573F240654095B2AMX15Acorpemcc_" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd02.lss.emc.com X-RSA-Classifications: public Subject: Re: [sacm] Is latency is important for you? X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 19:46:34 -0000 --_000_F5063677821E3B4F81ACFB7905573F240654095B2AMX15Acorpemcc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gSG9zbmllaCwNCg0KQ291bGQgeW91IHByb3ZpZGUgYSBsaXR0bGUgbW9yZSBiYWNrZ3Jv dW5kIGFuZCByZWxldmFuY2UgdG8gdGhlIGxpc3QgbWVtYmVycyBmb3IgeW91ciByZXF1ZXN0Pw0K DQpJIGhhdmUgaGFkIHRoZSBwbGVhc3VyZSBvZiBtZWV0aW5nIEhvc25pZWggYXQgc2V2ZXJhbCBJ RVRGIHJlbGF0ZWQgZXZlbnRzIGFuZCBzaGUgaGFzIHNvbWUgYWN0aXZlIGRyYWZ0cyByZWxhdGVk IHRvIHNlY3VyZSB0cmFuc3BvcnQuICBTaGUgaXMgaW4gdGhlIHByb2Nlc3Mgb2Ygc3RhcnRpbmcg dXAgYSBtYWlsaW5nIGxpc3QgZm9yIGRpc2N1c3Npb24gb24gdGhhdCB0b3BpYyBhbmQgSSBhbSBn dWVzc2luZyB0aGlzIHJlcXVlc3QgaXMgcmVsYXRlZCB0byB0aGF0IG5ldyBtYWlsaW5nIGxpc3Qu DQoNClRoZSBxdWVzdGlvbiBhcyB3b3JkZWQgYmVsb3cgbWF5IGJlIHRvdWdoIGZvciB0aGlzIGdy b3VwIGFzIHRoZWlyIGZvY3VzIGlzIG9uIHNlY3VyaXR5IGF1dG9tYXRpb24uICBUaGlzIHdvcmsg d2lsbCByZXF1aXJlIHRoZSBleGNoYW5nZSBvZiBpbmZvcm1hdGlvbiBvdmVyIHNlY3VyZSBwcm90 b2NvbHMsIGJ1dCB0aGUgZ3JvdXAgaXMgd29ya2luZyB0aHJvdWdoIHVzZSBjYXNlcyBhbmQgcmVx dWlyZW1lbnRzIGF0IHRoaXMgc3RhZ2UuDQoNCk1heWJlIGEgcXVpY2svYnJpZWYgZXhwbGFuYXRp b24gd291bGQgYmUgaGVscGZ1bCBhbmQgdGhlbiB5b3UgY291bGQgaGF2ZSBwZW9wbGUgY29udGFj dCB5b3UgZGlyZWN0bHkgb3Igb24gdGhlIG5ldyBtYWlsaW5nIGxpc3Qgb25jZSBpdCBpcyBlc3Rh Ymxpc2hlZC4gIFdlIHNob3VsZG7igJl0IGNsdXR0ZXIgb3RoZXIgbWFpbGluZyBsaXN0cy4gIFlv dSBjb3VsZCBzZW5kIHRoYXQgcmVxdWVzdCB3aXRoIGFuIGFubm91bmNlbWVudCBtZXNzYWdlIHRv IFNBQUcgbGlzdCBvbmNlIHRoZSBsaXN0IGhhcyBiZWVuIGNyZWF0ZWQuDQoNClRoYW5rIHlvdSwN CkthdGhsZWVuDQoNCkZyb206IHNhY20gW21haWx0bzpzYWNtLWJvdW5jZXNAaWV0Zi5vcmddIE9u IEJlaGFsZiBPZiBIb3NuaWVoDQpTZW50OiBUaHVyc2RheSwgTm92ZW1iZXIgMjEsIDIwMTMgOTo0 NiBBTQ0KVG86IEFwcHMgRGlzY3VzcywgSUVURjsgc2FjbUBpZXRmLm9yZw0KQ2M6IE5vcmRtYXJr LCBFcmlrDQpTdWJqZWN0OiBbc2FjbV0gSXMgbGF0ZW5jeSBpcyBpbXBvcnRhbnQgZm9yIHlvdT8N Cg0KSGVsbG8sDQoNCkkgZG8gbm90IGtub3cgaW4gd2hpY2ggV0cgSSBzYXcgYSBtZXNzYWdlIGFu ZCBhIGRpc2N1c3Npb24gb2YgSUlEIGdlbmVyYXRpb24gYW5kIGxhdGVuY3kgcHJvYmxlbXMuIElm IGl0IHdhcyBub3QgaW4gdGhpcyBtYWlsaW5nbGlzdCBidXQgSSBndWVzcyBpdCBpcyBhIGdvb2Qg cGxhY2UgdG8gc3RhcnQgc2luY2UgaXQgcmVhbGx5IHJlbGF0ZXMgdG8gdGhpcyBXRy4NCkkgaGF2 ZSBhIHZlcnkgaW1wb3J0YW50IHF1ZXN0aW9uLiBQbGVhc2UgcmF0ZSAgeW91ciBleHBlcmllbmNl IGFib3V0IHRoZSBsYXRlbmN5IHlvdSBlbmNvdW50ZXJlZCBpbiBhbnkgbmV0d29yayB0aGF0IHdh cyBiZWNhdXNlIG9mIElQIGNvbmZpZ3VyYXRpb24gb2YgeW91ciBub2RlLg0KDQoNClRoYW5rcywN Cg0KDQotLS0NClNtaWxlLA0KSG9zbmllaA0KU29ycnkgZm9yIHRweW9zIGZyb20gbXkgY2h1YmJ5 IGZpbmdlcnMgdHlwaW5nIG9uIG15IHBob25lDQo= --_000_F5063677821E3B4F81ACFB7905573F240654095B2AMX15Acorpemcc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCglj b2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41 aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNl Y3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAv Pg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxh eW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwv bzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT48L2hlYWQ+PGJvZHkgbGFuZz1FTi1VUyBs aW5rPWJsdWUgdmxpbms9cHVycGxlPjxkaXYgY2xhc3M9V29yZFNlY3Rpb24xPjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkhlbGxvIEhvc25pZWgsPG86cD48L286cD48 L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjoj MUY0OTdEJz5Db3VsZCB5b3UgcHJvdmlkZSBhIGxpdHRsZSBtb3JlIGJhY2tncm91bmQgYW5kIHJl bGV2YW5jZSB0byB0aGUgbGlzdCBtZW1iZXJzIGZvciB5b3VyIHJlcXVlc3Q/wqAgPG86cD48L286 cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xv cjojMUY0OTdEJz5JIGhhdmUgaGFkIHRoZSBwbGVhc3VyZSBvZiBtZWV0aW5nIEhvc25pZWggYXQg c2V2ZXJhbCBJRVRGIHJlbGF0ZWQgZXZlbnRzIGFuZCBzaGUgaGFzIHNvbWUgYWN0aXZlIGRyYWZ0 cyByZWxhdGVkIHRvIHNlY3VyZSB0cmFuc3BvcnQuwqAgU2hlIGlzIGluIHRoZSBwcm9jZXNzIG9m IHN0YXJ0aW5nIHVwIGEgbWFpbGluZyBsaXN0IGZvciBkaXNjdXNzaW9uIG9uIHRoYXQgdG9waWMg YW5kIEkgYW0gZ3Vlc3NpbmcgdGhpcyByZXF1ZXN0IGlzIHJlbGF0ZWQgdG8gdGhhdCBuZXcgbWFp bGluZyBsaXN0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm Ijtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+VGhlIHF1ZXN0aW9uIGFzIHdvcmRlZCBiZWxv dyBtYXkgYmUgdG91Z2ggZm9yIHRoaXMgZ3JvdXAgYXMgdGhlaXIgZm9jdXMgaXMgb24gc2VjdXJp dHkgYXV0b21hdGlvbi7CoCBUaGlzIHdvcmsgd2lsbCByZXF1aXJlIHRoZSBleGNoYW5nZSBvZiBp bmZvcm1hdGlvbiBvdmVyIHNlY3VyZSBwcm90b2NvbHMsIGJ1dCB0aGUgZ3JvdXAgaXMgd29ya2lu ZyB0aHJvdWdoIHVzZSBjYXNlcyBhbmQgcmVxdWlyZW1lbnRzIGF0IHRoaXMgc3RhZ2UuPG86cD48 L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0Qn PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtj b2xvcjojMUY0OTdEJz5NYXliZSBhIHF1aWNrL2JyaWVmIGV4cGxhbmF0aW9uIHdvdWxkIGJlIGhl bHBmdWwgYW5kIHRoZW4geW91IGNvdWxkIGhhdmUgcGVvcGxlIGNvbnRhY3QgeW91IGRpcmVjdGx5 IG9yIG9uIHRoZSBuZXcgbWFpbGluZyBsaXN0IG9uY2UgaXQgaXMgZXN0YWJsaXNoZWQuwqAgV2Ug c2hvdWxkbuKAmXQgY2x1dHRlciBvdGhlciBtYWlsaW5nIGxpc3RzLsKgIFlvdSBjb3VsZCBzZW5k IHRoYXQgcmVxdWVzdCB3aXRoIGFuIGFubm91bmNlbWVudCBtZXNzYWdlIHRvIFNBQUcgbGlzdCBv bmNlIHRoZSBsaXN0IGhhcyBiZWVuIGNyZWF0ZWQuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5UaGFuayB5 b3UsPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9y OiMxRjQ5N0QnPkthdGhsZWVuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48ZGl2 PjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtw YWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluJz48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5G cm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 IlRhaG9tYSIsInNhbnMtc2VyaWYiJz4gc2FjbSBbbWFpbHRvOnNhY20tYm91bmNlc0BpZXRmLm9y Z10gPGI+T24gQmVoYWxmIE9mIDwvYj5Ib3NuaWVoPGJyPjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwg Tm92ZW1iZXIgMjEsIDIwMTMgOTo0NiBBTTxicj48Yj5Ubzo8L2I+IEFwcHMgRGlzY3VzcywgSUVU Rjsgc2FjbUBpZXRmLm9yZzxicj48Yj5DYzo8L2I+IE5vcmRtYXJrLCBFcmlrPGJyPjxiPlN1Ympl Y3Q6PC9iPiBbc2FjbV0gSXMgbGF0ZW5jeSBpcyBpbXBvcnRhbnQgZm9yIHlvdT88bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPkhlbGxvLCA8bzpwPjwvbzpwPjwvcD48L2Rp dj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4mbmJzcDsgPG86cD48L286cD48L3A+PC9kaXY+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWw+SSBkbyBub3Qga25vdyBpbiB3aGljaCBXRyBJIHNhdyBhIG1l c3NhZ2UgYW5kIGEgZGlzY3Vzc2lvbiBvZiBJSUQgZ2VuZXJhdGlvbiBhbmQgbGF0ZW5jeSBwcm9i bGVtcy4gSWYgaXQgd2FzIG5vdCBpbiB0aGlzIG1haWxpbmdsaXN0IGJ1dCBJIGd1ZXNzIGl0IGlz IGEgZ29vZCBwbGFjZSB0byBzdGFydCBzaW5jZSBpdCByZWFsbHkgcmVsYXRlcyB0byB0aGlzIFdH LiA8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5JIGhhdmUgYSB2 ZXJ5IGltcG9ydGFudCBxdWVzdGlvbi4gUGxlYXNlIHJhdGUmbmJzcDsgeW91ciBleHBlcmllbmNl IGFib3V0IHRoZSBsYXRlbmN5IHlvdSBlbmNvdW50ZXJlZCBpbiBhbnkgbmV0d29yayB0aGF0IHdh cyBiZWNhdXNlIG9mIElQIGNvbmZpZ3VyYXRpb24gb2YgeW91ciBub2RlLiA8bzpwPjwvbzpwPjwv cD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4mbmJzcDsgPG86cD48L286cD48L3A+PC9k aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+Jm5ic3A7IDxvOnA+PC9vOnA+PC9wPjwvZGl2Pjxk aXY+PHAgY2xhc3M9TXNvTm9ybWFsPlRoYW5rcywgPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+Jm5ic3A7IDxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsPiZuYnNwOyA8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2IGlkPW94LXNpZ25h dHVyZT48cCBjbGFzcz1Nc29Ob3JtYWw+LS0tIDxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAg Y2xhc3M9TXNvTm9ybWFsPlNtaWxlLCA8YnI+SG9zbmllaCA8YnI+U29ycnkgZm9yIHRweW9zIGZy b20gbXkgY2h1YmJ5IGZpbmdlcnMgdHlwaW5nIG9uIG15IHBob25lIDxvOnA+PC9vOnA+PC9wPjwv ZGl2PjwvZGl2PjwvYm9keT48L2h0bWw+ --_000_F5063677821E3B4F81ACFB7905573F240654095B2AMX15Acorpemcc_-- From Adam.Montville@cisecurity.org Wed Dec 4 17:40:55 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AEFB1ADFDC for ; Wed, 4 Dec 2013 17:40:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wXxJMqejeT45 for ; Wed, 4 Dec 2013 17:40:52 -0800 (PST) Received: from mail1.bemta7.messagelabs.com (mail1.bemta7.messagelabs.com [216.82.254.108]) by ietfa.amsl.com (Postfix) with ESMTP id 6E7C91ADFD1 for ; Wed, 4 Dec 2013 17:40:52 -0800 (PST) Received: from [216.82.253.227:63310] by server-12.bemta-7.messagelabs.com id 77/B3-05174-0A9DF925; Thu, 05 Dec 2013 01:40:48 +0000 X-Env-Sender: Adam.Montville@cisecurity.org X-Msg-Ref: server-8.tower-170.messagelabs.com!1386207586!172557!2 X-Originating-IP: [69.195.43.86] X-StarScan-Received: X-StarScan-Version: 6.9.16; banners=cisecurity.org,-,- X-VirusChecked: Checked Received: (qmail 25818 invoked from network); 5 Dec 2013 01:39:50 -0000 Received: from mail.msisac.org (HELO mail.msisac.org) (69.195.43.86) by server-8.tower-170.messagelabs.com with AES128-SHA encrypted SMTP; 5 Dec 2013 01:39:50 -0000 Received: from CISEXCHANGE1.msisac.org.local ([fe80::4f0:b68d:e779:38c3]) by CISEXCHANGE2.msisac.org.local ([::1]) with mapi id 14.02.0347.000; Wed, 4 Dec 2013 20:37:44 -0500 From: Adam Montville To: Henk Birkholz , "sacm@ietf.org" Thread-Topic: [sacm] FW: New Version Notification for draft-ietf-sacm-use-cases-05.txt Thread-Index: AQHO5kP2nRZCN5aiKEKjYSnlqGZSP5ouu8iggAKWAACAE5WvoQ== Date: Thu, 5 Dec 2013 01:37:52 +0000 Message-ID: <05BCCEB107AF88469B9F99783D47C1D6065E4769@CISEXCHANGE1.msisac.org.local> References: <20131120225753.9031.68753.idtracker@ietfa.amsl.com> , <528F23D0.3080504@sit.fraunhofer.de> In-Reply-To: <528F23D0.3080504@sit.fraunhofer.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.252.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sacm] FW: New Version Notification for draft-ietf-sacm-use-cases-05.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 01:40:55 -0000 Something I've found helpful in the past is to abstract a bit further from= "user", "operator", "application" and simply reference all of them at onc= e with the term "actor". I also believe that listing *potential* acquisition methods is useful in a= t least the following way: Including a multitude of acquisition methods cl= early signals our intent of finding information where it already exists, w= hile not necessarily precluding our ability to *get* information when info= rmation does not exist. Finally, I, too, like the notion of a work-flow scenario. I don't want to= be the one drawing a process diagram in an RFC, though. ;-) awm ________________________________________ From: sacm [sacm-bounces@ietf.org] on behalf of Henk Birkholz [henk.birkho= lz@sit.fraunhofer.de] Sent: Friday, November 22, 2013 3:27 AM To: sacm@ietf.org Subject: Re: [sacm] FW: New Version Notification for draft-ietf-sacm-us= e-cases-05.txt Regarding the first two question in section 2: 1.) Security automation today often supports the user/operator, I think. There are cases a security-process can be fully automated, of course, and in order to manage the sheer amount of security related system events automation is essential, but it seems to me that the complexity and heterogeneity of root-causes (that might trigger the work-flow) make the inclusion of a user/operator necessary. 2.) To include acquisition methods can provide an intuitive insight about the scope and intend of the endpoint posture assessment domain, I think. On one hand, that might bloat the use-case document a bit (and maybe renders the title "sacm use cases" too specific?). On the other hand, I like the inclusion of a work-flow scenario and I think it is a good place to highlight acquisition methods. - Henk On 11/21/2013 12:27 AM, Waltermire, David A. wrote: > I just posted an updated use case draft based on the editorial sessions = during the IETF 88 meeting in Vancouver, BC, Canada. My thanks to all that= provided input. > > I used the word version that we edited as a starting=20point. Here is wh= at I did: > > - I worked through the use cases we planned to remove and made sure to m= erge in any concepts that would be lost. If you submitted a previous use c= ase that was removed, please double check that I didn't miss anything. > - I broke up "Endpoint Identification and Assessment" into 3 distinct an= d somewhat separable use cases: "Endpoint Identification and Assessment Pl= anning", "Endpoint Posture Attribute Value Collection", "Posture Evaluatio= n". Please let me know what you think about this change. > - Addressed some aspects of the discussion thread based on the working s= ession changes. Please provide any suggested edits for aspects that I migh= t have missed or got wrong. > > The rest of the changes can be found in the draft's change log. > > If possible, I'd like to get to a fairly stable place with this draft in= the next revision or two to allow for progress to be made on the requirem= ents. In addition to the embedded questions in the document, I'd like to f= ocus on the following questions: > > Is the draft approachable for a newcomer to the effort? Do you see the u= pdated use case structure as an improvement? > Does this draft paint a complete enough picture? Are we missing any impo= rtant concepts? > Is there anything you can't live with? > > I hope to release at least one or two more updates to this draft within = the next few weeks before the holidays catch up on us. I know everyone is= busy; timely comments are appreciated to allow for a quick turnaround on = the next revision. > > Thanks, > Dave > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Wednesday, November 20, 2013 5:58 PM > To: Waltermire, David A.; David Harrington > Subject: New Version Notification for draft-ietf-sacm-use-cases-05.txt > > > A new version of I-D, draft-ietf-sacm-use-cases-05.txt has been successf= ully submitted by David Waltermire and posted to the IETF repository. > > Filename: draft-ietf-sacm-use-cases > Revision: 05 > Title: Endpoint Security Posture Assessment - Enterprise= Use Cases > Creation date: 2013-11-20 > Group: sacm > Number of pages: 24 > URL: http://www.ietf.org/internet-drafts/draft-ietf-sacm-use= -cases-05.txt > Status: http://datatracker.ietf.org/doc/draft-ietf-sacm-use-cas= es > Htmlized: http://tools.ietf.org/html/draft-ietf-sacm-use-cases-05= > Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sacm-use-= cases-05 > > Abstract: > This memo documents a sampling of use cases for securely aggregating= > configuration and operational data and evaluating that data to > determine an organization's security posture. From these operationa= l > use cases, we can derive common functional capabilities and > requirements to guide development of vendor-neutral, interoperable > standards for aggregating and evaluating data relevant to security > posture. > > > > > Please note that it may take a couple of minutes from the time of submis= sion until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > ... . . . From david.waltermire@nist.gov Wed Dec 4 17:53:50 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA2F41AE2FA for ; Wed, 4 Dec 2013 17:53:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gO66hAQs4JzH for ; Wed, 4 Dec 2013 17:53:48 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0182.outbound.protection.outlook.com [207.46.163.182]) by ietfa.amsl.com (Postfix) with ESMTP id C871F1ADFA5 for ; Wed, 4 Dec 2013 17:53:47 -0800 (PST) Received: from BLUPR09MB038.namprd09.prod.outlook.com (10.255.211.144) by BLUPR09MB038.namprd09.prod.outlook.com (10.255.211.144) with Microsoft SMTP Server (TLS) id 15.0.825.14; Thu, 5 Dec 2013 01:53:37 +0000 Received: from BLUPR09MB038.namprd09.prod.outlook.com ([169.254.11.38]) by BLUPR09MB038.namprd09.prod.outlook.com ([169.254.11.38]) with mapi id 15.00.0825.006; Thu, 5 Dec 2013 01:53:37 +0000 From: "Waltermire, David A." To: Adam Montville , Henk Birkholz , "sacm@ietf.org" Thread-Topic: [sacm] FW: New Version Notification for draft-ietf-sacm-use-cases-05.txt Thread-Index: AQHO8VsMHrVvvEnjLUymUnYYetgHJ5pE1ewg Date: Thu, 5 Dec 2013 01:53:37 +0000 Message-ID: References: <20131120225753.9031.68753.idtracker@ietfa.amsl.com> , <528F23D0.3080504@sit.fraunhofer.de> <05BCCEB107AF88469B9F99783D47C1D6065E4769@CISEXCHANGE1.msisac.org.local> In-Reply-To: <05BCCEB107AF88469B9F99783D47C1D6065E4769@CISEXCHANGE1.msisac.org.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.6.227.119] x-forefront-prvs: 00514A2FE6 x-forefront-antispam-report: SFV:NSPM; SFS:(24454002)(76104003)(164054003)(479174003)(377454003)(54164003)(51704005)(377424004)(13464003)(54534003)(189002)(199002)(69226001)(15202345003)(87266001)(2656002)(54316002)(224303002)(47446002)(80022001)(79102001)(74502001)(54356001)(63696002)(66066001)(76576001)(56776001)(53806001)(19580395003)(76482001)(19580405001)(33646001)(46102001)(74316001)(81342001)(15975445006)(47976001)(81686001)(80976001)(59766001)(77096001)(74876001)(74662001)(74366001)(83072001)(50986001)(87936001)(74706001)(49866001)(76786001)(65816001)(77982001)(31966008)(81816001)(4396001)(83322001)(47736001)(85306002)(224313003)(81542001)(56816005)(51856001)(76796001)(85852002)(90146001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR09MB038; H:BLUPR09MB038.namprd09.prod.outlook.com; CLIP:129.6.227.119; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov Subject: Re: [sacm] FW: New Version Notification for draft-ietf-sacm-use-cases-05.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 01:53:50 -0000 Comments inline. > -----Original Message----- > From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Adam Montville > Sent: Wednesday, December 04, 2013 8:38 PM > To: Henk Birkholz; sacm@ietf.org > Subject: Re: [sacm] FW: New Version Notification for draft-ietf-sacm-use- > cases-05.txt >=20 > Something I've found helpful in the past is to abstract a bit further fro= m > "user", "operator", "application" and simply reference all of them at onc= e > with the term "actor". Are we ok with the change to using actor? The current usage of "user", "ope= rator", "application" (specifically the last two) was suggested a while bac= k to align with IETF terminology. Does use of "actor" to reference all thre= e concepts raise any concerns? > I also believe that listing *potential* acquisition methods is useful in = at least > the following way: Including a multitude of acquisition methods clearly s= ignals > our intent of finding information where it already exists, while not > necessarily precluding our ability to *get* information when information > does not exist. Adam, would you or Henk provide some example acquisition methods for discus= sion? > Finally, I, too, like the notion of a work-flow scenario. I don't want t= o be the > one drawing a process diagram in an RFC, though. ;-) How would this differ from the workflow scenario text in section 2? Are you suggesting representing this text in a visual form? If so, would an= yone like to make a contribution of some ascii art? > awm > ________________________________________ > From: sacm [sacm-bounces@ietf.org] on behalf of Henk Birkholz > [henk.birkholz@sit.fraunhofer.de] > Sent: Friday, November 22, 2013 3:27 AM > To: sacm@ietf.org > Subject: Re: [sacm] FW: New Version Notification for draft-ietf-sacm-u= se- > cases-05.txt >=20 > Regarding the first two question in section 2: >=20 > 1.) Security automation today often supports the user/operator, I think. > There are cases a security-process can be fully automated, of course, and= in > order to manage the sheer amount of security related system events > automation is essential, but it seems to me that the complexity and > heterogeneity of root-causes (that might trigger the work-flow) make the > inclusion of a user/operator necessary. >=20 > 2.) To include acquisition methods can provide an intuitive insight about= the > scope and intend of the endpoint posture assessment domain, I think. On > one hand, that might bloat the use-case document a bit (and maybe renders > the title "sacm use cases" too specific?). On the other hand, I like the > inclusion of a work-flow scenario and I think it is a good place to highl= ight > acquisition methods. >=20 > - Henk >=20 > On 11/21/2013 12:27 AM, Waltermire, David A. wrote: > > I just posted an updated use case draft based on the editorial sessions > during the IETF 88 meeting in Vancouver, BC, Canada. My thanks to all tha= t > provided input. > > > > I used the word version that we edited as a starting point. Here is wha= t I > did: > > > > - I worked through the use cases we planned to remove and made sure to > merge in any concepts that would be lost. If you submitted a previous use > case that was removed, please double check that I didn't miss anything. > > - I broke up "Endpoint Identification and Assessment" into 3 distinct a= nd > somewhat separable use cases: "Endpoint Identification and Assessment > Planning", "Endpoint Posture Attribute Value Collection", "Posture > Evaluation". Please let me know what you think about this change. > > - Addressed some aspects of the discussion thread based on the working > session changes. Please provide any suggested edits for aspects that I mi= ght > have missed or got wrong. > > > > The rest of the changes can be found in the draft's change log. > > > > If possible, I'd like to get to a fairly stable place with this draft i= n the next > revision or two to allow for progress to be made on the requirements. In > addition to the embedded questions in the document, I'd like to focus on = the > following questions: > > > > Is the draft approachable for a newcomer to the effort? Do you see the > updated use case structure as an improvement? > > Does this draft paint a complete enough picture? Are we missing any > important concepts? > > Is there anything you can't live with? > > > > I hope to release at least one or two more updates to this draft within= the > next few weeks before the holidays catch up on us. I know everyone is > busy; timely comments are appreciated to allow for a quick turnaround on > the next revision. > > > > Thanks, > > Dave > > > > -----Original Message----- > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > Sent: Wednesday, November 20, 2013 5:58 PM > > To: Waltermire, David A.; David Harrington > > Subject: New Version Notification for draft-ietf-sacm-use-cases-05.txt > > > > > > A new version of I-D, draft-ietf-sacm-use-cases-05.txt has been > successfully submitted by David Waltermire and posted to the IETF > repository. > > > > Filename: draft-ietf-sacm-use-cases > > Revision: 05 > > Title: Endpoint Security Posture Assessment - Enterpris= e Use Cases > > Creation date: 2013-11-20 > > Group: sacm > > Number of pages: 24 > > URL: http://www.ietf.org/internet-drafts/draft-ietf-sacm-us= e-cases- > 05.txt > > Status: http://datatracker.ietf.org/doc/draft-ietf-sacm-use-ca= ses > > Htmlized: http://tools.ietf.org/html/draft-ietf-sacm-use-cases-0= 5 > > Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sacm-use= -cases-05 > > > > Abstract: > > This memo documents a sampling of use cases for securely aggregatin= g > > configuration and operational data and evaluating that data to > > determine an organization's security posture. From these operation= al > > use cases, we can derive common functional capabilities and > > requirements to guide development of vendor-neutral, interoperable > > standards for aggregating and evaluating data relevant to security > > posture. > > > > > > > > > > Please note that it may take a couple of minutes from the time of > submission until the htmlized version and diff are available at tools.iet= f.org. > > > > The IETF Secretariat > > > > _______________________________________________ > > sacm mailing list > > sacm@ietf.org > > https://www.ietf.org/mailman/listinfo/sacm > > >=20 >=20 >=20 > ... >=20 > . . . > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm From david.waltermire@nist.gov Wed Dec 4 18:03:32 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 761861AE005 for ; Wed, 4 Dec 2013 18:03:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nJh-kE4P7TK2 for ; Wed, 4 Dec 2013 18:03:30 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0210.outbound.protection.outlook.com [207.46.163.210]) by ietfa.amsl.com (Postfix) with ESMTP id EBA391ADFD2 for ; Wed, 4 Dec 2013 18:03:29 -0800 (PST) Received: from BLUPR09MB038.namprd09.prod.outlook.com (10.255.211.144) by BLUPR09MB040.namprd09.prod.outlook.com (10.255.211.154) with Microsoft SMTP Server (TLS) id 15.0.825.14; Thu, 5 Dec 2013 02:03:24 +0000 Received: from BLUPR09MB038.namprd09.prod.outlook.com ([169.254.11.38]) by BLUPR09MB038.namprd09.prod.outlook.com ([169.254.11.38]) with mapi id 15.00.0825.006; Thu, 5 Dec 2013 02:03:23 +0000 From: "Waltermire, David A." To: "sacm@ietf.org" Thread-Topic: Use case draft comments for 12/17 meeting Thread-Index: Ac7xXb0puYBuLOHnSeybFmIWMPR4FQ== Date: Thu, 5 Dec 2013 02:03:23 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.6.227.119] x-forefront-prvs: 00514A2FE6 x-forefront-antispam-report: SFV:NSPM; SFS:(51704005)(164054003)(54164003)(377454003)(13464003)(199002)(189002)(56776001)(76576001)(47446002)(76786001)(74502001)(2656002)(69226001)(54316002)(31966008)(76176001)(66066001)(85852002)(15202345003)(87266001)(65816001)(63696002)(54356001)(53806001)(76482001)(83322001)(74316001)(15975445006)(19580405001)(19580395003)(33646001)(74706001)(83072001)(74876001)(77982001)(85306002)(87936001)(59766001)(47736001)(74366001)(4396001)(74662001)(77096001)(80976001)(81686001)(50986001)(76796001)(80022001)(81542001)(46102001)(47976001)(49866001)(51856001)(81342001)(79102001)(90146001)(56816005)(81816001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR09MB040; H:BLUPR09MB038.namprd09.prod.outlook.com; CLIP:129.6.227.119; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov Subject: [sacm] Use case draft comments for 12/17 meeting X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 02:03:32 -0000 I'd like to post another draft of the use cases document before our virtual= interim meeting on 12/17. To do this I will need comments on draft-ietf-sa= cm-use-cases-05 by 12/11 to have time to make any edits. Additional comments are welcome and appreciated. You can find the current draft here: http://datatracker.ietf.org/doc/draft-ietf-sacm-use-cases/ Thanks, Dave > -----Original Message----- > From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Romascanu, Dan > (Dan) > Sent: Thursday, November 21, 2013 6:45 AM > To: Waltermire, David A.; sacm@ietf.org > Subject: Re: [sacm] FW: New Version Notification for draft-ietf-sacm-use- > cases-05.txt >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Waltermire, > > David A. > > Sent: Thursday, November 21, 2013 1:27 AM > > To: sacm@ietf.org > > Subject: [sacm] FW: New Version Notification for draft-ietf-sacm-use- > > cases-05.txt > > > > I just posted an updated use case draft based on the editorial > > sessions during the IETF 88 meeting in Vancouver, BC, Canada. My > > thanks to all that provided input. > > > [[DR]] Thanks, David and all contributors! > ... > > > > I hope to release at least one or two more updates to this draft > > within the next few weeks before the holidays catch up on us. I know > > everyone is busy; timely comments are appreciated to allow for a quick > > turnaround on the next revision. >=20 > [[DR]] Please do not forget about the virtual interim scheduled for 12/17= . > Hopefully one more version could be released before this date addressing > the comments against the current version >=20 > Regards, >=20 > Dan >=20 >=20 > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm From shanna@juniper.net Wed Dec 4 18:33:08 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7382B1AE314 for ; Wed, 4 Dec 2013 18:33:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sYOAEVjbh3hF for ; Wed, 4 Dec 2013 18:33:06 -0800 (PST) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe004.messaging.microsoft.com [216.32.180.187]) by ietfa.amsl.com (Postfix) with ESMTP id 5A5891AE008 for ; Wed, 4 Dec 2013 18:33:06 -0800 (PST) Received: from mail133-co1-R.bigfish.com (10.243.78.246) by CO1EHSOBE004.bigfish.com (10.243.66.67) with Microsoft SMTP Server id 14.1.225.22; Thu, 5 Dec 2013 02:33:02 +0000 Received: from mail133-co1 (localhost [127.0.0.1]) by mail133-co1-R.bigfish.com (Postfix) with ESMTP id BD1604C0222; Thu, 5 Dec 2013 02:33:02 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT004.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -1 X-BigFish: VPS-1(z579eh579fhz98dI1432I4015Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah1fc6hzzz2fh109h2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h2216h22d0h2336h9a9j1155h) Received-SPF: pass (mail133-co1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=shanna@juniper.net; helo=BL2PRD0510HT004.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(51704005)(164054003)(24454002)(189002)(199002)(4396001)(69226001)(49866001)(47736001)(81816001)(224303002)(83072001)(50986001)(2656002)(47976001)(87266001)(79102001)(59766001)(77982001)(80976001)(224313003)(74502001)(74662001)(74316001)(47446002)(85306002)(74366001)(31966008)(74706001)(87936001)(76786001)(76796001)(81542001)(81342001)(74876001)(77096001)(56776001)(66066001)(76576001)(33646001)(83322001)(81686001)(56816005)(63696002)(80022001)(51856001)(53806001)(54356001)(76482001)(90146001)(54316002)(65816001)(85852002)(46102001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR05MB324; H:BLUPR05MB323.namprd05.prod.outlook.com; CLIP:66.129.241.15; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail133-co1 (localhost.localdomain [127.0.0.1]) by mail133-co1 (MessageSwitch) id 1386210781899350_5678; Thu, 5 Dec 2013 02:33:01 +0000 (UTC) Received: from CO1EHSMHS010.bigfish.com (unknown [10.243.78.225]) by mail133-co1.bigfish.com (Postfix) with ESMTP id CD787B4006D; Thu, 5 Dec 2013 02:33:01 +0000 (UTC) Received: from BL2PRD0510HT004.namprd05.prod.outlook.com (157.56.240.101) by CO1EHSMHS010.bigfish.com (10.243.66.20) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 5 Dec 2013 02:33:01 +0000 Received: from BLUPR05MB324.namprd05.prod.outlook.com (10.141.24.27) by BL2PRD0510HT004.namprd05.prod.outlook.com (10.255.100.39) with Microsoft SMTP Server (TLS) id 14.16.383.1; Thu, 5 Dec 2013 02:32:51 +0000 Received: from BLUPR05MB323.namprd05.prod.outlook.com (10.141.24.26) by BLUPR05MB324.namprd05.prod.outlook.com (10.141.24.27) with Microsoft SMTP Server (TLS) id 15.0.810.5; Thu, 5 Dec 2013 02:32:50 +0000 Received: from BLUPR05MB323.namprd05.prod.outlook.com ([169.254.6.241]) by BLUPR05MB323.namprd05.prod.outlook.com ([169.254.6.185]) with mapi id 15.00.0810.005; Thu, 5 Dec 2013 02:32:50 +0000 From: Stephen Hanna To: "Waltermire, David A." , Adam Montville , Henk Birkholz , "sacm@ietf.org" Thread-Topic: [sacm] FW: New Version Notification for draft-ietf-sacm-use-cases-05.txt Thread-Index: AQHO8VzkS5dXQuJrY0u6cFK6+iROgppE3tdw Date: Thu, 5 Dec 2013 02:32:49 +0000 Message-ID: References: <20131120225753.9031.68753.idtracker@ietfa.amsl.com> , <528F23D0.3080504@sit.fraunhofer.de> <05BCCEB107AF88469B9F99783D47C1D6065E4769@CISEXCHANGE1.msisac.org.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.15] x-forefront-prvs: 00514A2FE6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [sacm] FW: New Version Notification for draft-ietf-sacm-use-cases-05.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 02:33:08 -0000 Dave Waltermire wrote: > Adam Montville wrote: > > Something I've found helpful in the past is to abstract a bit further > > from "user", "operator", "application" and simply reference all of > > them at once with the term "actor". >=20 > Are we ok with the change to using actor? The current usage of "user", > "operator", "application" (specifically the last two) was suggested a > while back to align with IETF terminology. Does use of "actor" to > reference all three concepts raise any concerns? I'm not OK with this change. Not all users and applications are the same. To be specific, the word "administrator" is only used in section 2.2.4, which describes a security administrator querying posture databases to look for installed software that's correlated with a particular data exfiltration pattern. Changing "administrator" to "actor" in this section would take the heart out of the scenario. I realize that we say "operator or application" in several places. This may seem like duplicative text. However, I believe that it's useful to point out explicitly that these actions can be performed by either humans or processes. Thanks, Steve From blueroofmusic@gmail.com Wed Dec 4 19:24:42 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B4CE1AE342 for ; Wed, 4 Dec 2013 19:24:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eaB33eoMBvuA for ; Wed, 4 Dec 2013 19:24:40 -0800 (PST) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 2913F1AE340 for ; Wed, 4 Dec 2013 19:24:40 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id qd12so28995703ieb.3 for ; Wed, 04 Dec 2013 19:24:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=z45m8eGQqXCMxxhP/1dx9EKlPUF0g59cGeD2pcVo8So=; b=ksrYt2eb1SNoQToiqbpZtS+vMT63sthj518azXjy7UJ/3MydYrEzhdT8v5ErEZJ4RC /atbzuZL9h4dG/0OtnLceOahhowY852bCwvw5fsk+w3WV2HIq5GQ+qLRjl3aZES2f1V/ /h7q4GrNHXI8i7ZcFgS7YwUyJ0JlwOWgqvPxUkjknFmKqzHbM6bG2R0zishAvnobdPuS CxVSVv2gPJYnHn8X6dz7sTw3tS/5LoIAS350CCQmNA8FJt1pq52halVt8SIwkGNMadjK /eBc5PuAhpEse4U5y1V3m1tr/A3IjiueriwdJJ4y7rnW7i2P3YZq6jEyyMnyJvRXIxcS DPHQ== X-Received: by 10.42.227.195 with SMTP id jb3mr49862911icb.27.1386213876745; Wed, 04 Dec 2013 19:24:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.203.38 with HTTP; Wed, 4 Dec 2013 19:24:16 -0800 (PST) From: Ira McDonald Date: Wed, 4 Dec 2013 22:24:16 -0500 Message-ID: To: Adam Montville , Ira McDonald Content-Type: multipart/alternative; boundary=001a1133df8eb4cd7a04ecc111b8 Cc: Henk Birkholz , "sacm@ietf.org" Subject: Re: [sacm] FW: New Version Notification for draft-ietf-sacm-use-cases-05.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 03:24:42 -0000 --001a1133df8eb4cd7a04ecc111b8 Content-Type: text/plain; charset=ISO-8859-1 Hi Adam, Your remark about RFC diagrams piqued my curiosity - so I went looking... http://www.asciiflow.com/#Draw And had fun playing with this online ASCII art drawing tool. Also, this online image-to-ASCII tool http://www.ascii-art.org/ Having done a lot of ASCII art the hard way for RFCs in the past, you brought a smile to my day - thanks. Cheers, - Ira Ira McDonald (Musician / Software Architect) Co-Chair - TCG Trusted Mobility Solutions WG Chair - Linux Foundation Open Printing WG Secretary - IEEE-ISTO Printer Working Group Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG IETF Designated Expert - IPP & Printer MIB Blue Roof Music / High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto: blueroofmusic@gmail.com Winter 579 Park Place Saline, MI 48176 734-944-0094 Summer PO Box 221 Grand Marais, MI 49839 906-494-2434 On Wed, Dec 4, 2013 at 8:37 PM, Adam Montville < Adam.Montville@cisecurity.org> wrote: > Something I've found helpful in the past is to abstract a bit further from > "user", "operator", "application" and simply reference all of them at once > with the term "actor". > > I also believe that listing *potential* acquisition methods is useful in > at least the following way: Including a multitude of acquisition methods > clearly signals our intent of finding information where it already exists, > while not necessarily precluding our ability to *get* information when > information does not exist. > > Finally, I, too, like the notion of a work-flow scenario. I don't want to > be the one drawing a process diagram in an RFC, though. ;-) > > awm > > --001a1133df8eb4cd7a04ecc111b8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Adam,

Your remark= about RFC diagrams piqued my curiosity - so I went looking...

=A0 <= a href=3D"http://www.asciiflow.com/#Draw">http://www.asciiflow.com/#Draw

And had fun playing with this online ASCII art drawing tool.
<= /div>
Also, this online image-to-ASCII tool

=A0 http://www.ascii-art.org/

Having done a lot of ASCII art the hard way for RFCs in the past, you = brought
a smile to my day - thanks.
=A0
Cheers,
- Ira


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



On Wed, Dec 4, 2013 at 8:37 PM, Adam Mon= tville <Adam.Montville@cisecurity.org> wrote:
Something I've found helpful in the past is to abstract a bit further f= rom "user", "operator", "application" and sim= ply reference all of them at once with the term "actor".

I also believe that listing *potential* acquisition methods is useful in at= least the following way: Including a multitude of acquisition methods clea= rly signals our intent of finding information where it already exists, whil= e not necessarily precluding our ability to *get* information when informat= ion does not exist.

Finally, I, too, like the notion of a work-flow scenario. =A0I don't wa= nt to be the one drawing a process diagram in an RFC, though. ;-)

awm


--001a1133df8eb4cd7a04ecc111b8-- From adam@stoicsecurity.com Wed Dec 4 21:00:38 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C62071AE02F for ; Wed, 4 Dec 2013 21:00:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TPXNVr0YKJaf for ; Wed, 4 Dec 2013 21:00:36 -0800 (PST) Received: from p3plsmtpa11-07.prod.phx3.secureserver.net (p3plsmtpa11-07.prod.phx3.secureserver.net [68.178.252.108]) by ietfa.amsl.com (Postfix) with ESMTP id C74EB1ADFA7 for ; Wed, 4 Dec 2013 21:00:36 -0800 (PST) Received: from [192.168.1.69] ([99.64.100.240]) by p3plsmtpa11-07.prod.phx3.secureserver.net with id xh0U1m00F5BBm5P01h0V0y; Wed, 04 Dec 2013 22:00:33 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: "Adam W. Montville" In-Reply-To: Date: Wed, 4 Dec 2013 23:00:27 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20131120225753.9031.68753.idtracker@ietfa.amsl.com> , <528F23D0.3080504@sit.fraunhofer.de> <05BCCEB107AF88469B9F99783D47C1D6065E4769@CISEXCHANGE1.msisac.org.local> To: Stephen Hanna X-Mailer: Apple Mail (2.1822) Cc: Adam Montville , Dave Waltermier , "sacm@ietf.org" , Henk Birkholz Subject: Re: [sacm] FW: New Version Notification for draft-ietf-sacm-use-cases-05.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 05:00:39 -0000 On Dec 4, 2013, at 8:32 PM, Stephen Hanna wrote: > Dave Waltermire wrote: >> Adam Montville wrote: >>> Something I've found helpful in the past is to abstract a bit = further >>> from "user", "operator", "application" and simply reference all of >>> them at once with the term "actor". >>=20 >> Are we ok with the change to using actor? The current usage of = "user", >> "operator", "application" (specifically the last two) was suggested a >> while back to align with IETF terminology. Does use of "actor" to >> reference all three concepts raise any concerns? >=20 > I'm not OK with this change. Not all users and applications are the = same. > To be specific, the word "administrator" is only used in section = 2.2.4, > which describes a security administrator querying posture databases to > look for installed software that's correlated with a particular data > exfiltration pattern. Changing "administrator" to "actor" in this = section > would take the heart out of the scenario. >=20 > I realize that we say "operator or application" in several places. = This > may seem like duplicative text. However, I believe that it's useful to > point out explicitly that these actions can be performed by either = humans > or processes. A fair point. I'm fine either way, but do give preference to the term = actor at higher levels of abstraction to get the overall point across = without muddying the details too much with the (ultimately important) = differences at the level of technical detail. >=20 > Thanks, >=20 > Steve >=20 >=20 > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm From dbharrington@comcast.net Wed Dec 4 21:11:07 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A488B1AE028 for ; Wed, 4 Dec 2013 21:11:07 -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_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4J6HKqPvcDiw for ; Wed, 4 Dec 2013 21:11:04 -0800 (PST) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id 841821AE344 for ; Wed, 4 Dec 2013 21:11:03 -0800 (PST) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta02.westchester.pa.mail.comcast.net with comcast id xh8G1m0011c6gX851hAz26; Thu, 05 Dec 2013 05:10:59 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta23.westchester.pa.mail.comcast.net with comcast id xhAy1m00i2yZEBF3jhAyzW; Thu, 05 Dec 2013 05:10:59 +0000 From: "David Harrington" To: "'Waltermire, David A.'" , "'Adam Montville'" , "'Henk Birkholz'" , References: <20131120225753.9031.68753.idtracker@ietfa.amsl.com> , <528F23D0.3080504@sit.fraunhofer.de> <05BCCEB107AF88469B9F99783D47C1D6065E4769@CISEXCHANGE1.msisac.org.local> In-Reply-To: Date: Thu, 5 Dec 2013 00:11:00 -0500 Message-ID: <025d01cef178$63f56840$2be038c0$@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQDqYHUjRqa6AdCybnAKjK8iZl6ZEgHRoRLuAd5OVZsCKr/+CgJ7lTzzm8t7ZpA= Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1386220259; bh=nm8IhW9A17SkUUta1ajtT0CvHKlRetmulDY9lm6gRnQ=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=j9KSOFWMlcw1Bw8/V9cLjf5Z1gb6d6MzYTOC8hOxiA7/Z/fj5TPixbJjoiGz94LK8 /HEsBDa3RIwLqGYFaMieL9qlX2yiXfaZvITXfQ4TXknMXReem0BKaQCFlaSLa5agLD xpRJGqj7wCf7Br55q2ZH+xeuTqEAnUdqepZwQ9Q0lsbF3gF3n7Dv8pmqXJpRmz6a2U +cTPZc6aph7d9z6LlgrV8fpnBNkf14olcO4eZSJr6niCp/CWfdbnnQiUtTR7T52OhX PBdMrbXPZ+5X4A+WwOfjMZ0s/s5BRk0yaKiLVQNahTfDtqqchTHGFr/B1AdwaEvdmK 5fSRs7v5ijE9w== Subject: Re: [sacm] FW: New Version Notification for draft-ietf-sacm-use-cases-05.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 05:11:07 -0000 Hi, Using actor concerns me. I find it important to understand whether some content needs to be parsed by a human (with our wonderful ability to parse), or a computer application (which is bound by a set of rules, and has great difficulty when the content is not consistent with the rules). Around 2003, the operators made it clear that CLIs were difficult to work with, because queries would return information in variable formats. While humans might be able to parse the output that might change from vendor to vendor, model to model, and release to release, tools had significant difficulty due to the lack of standardization. Operators could try to deal with the lack of standardization by writing expect scripts, but they would need to be updated constantly because what worked for one release of a product might not be the same in the next release. Humans can parse variable syntax, such as the natural language content of syslog, but applications can have a hard time. I think is very important to know whether we are designing something for human consumption or for computer consumption. "Actor" doesn't provide enough differentiation to know how to design our solutions. David Harrington dbharrington@comcast.net +1-603-828-1401 > -----Original Message----- > From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Waltermire, David > A. > Sent: Wednesday, December 04, 2013 8:54 PM > To: Adam Montville; Henk Birkholz; sacm@ietf.org > Subject: Re: [sacm] FW: New Version Notification for draft-ietf-sacm-use- > cases-05.txt > > Comments inline. > > > -----Original Message----- > > From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Adam Montville > > Sent: Wednesday, December 04, 2013 8:38 PM > > To: Henk Birkholz; sacm@ietf.org > > Subject: Re: [sacm] FW: New Version Notification for draft-ietf-sacm-use- > > cases-05.txt > > > > Something I've found helpful in the past is to abstract a bit further from > > "user", "operator", "application" and simply reference all of them at once > > with the term "actor". > > Are we ok with the change to using actor? The current usage of "user", > "operator", "application" (specifically the last two) was suggested a while > back to align with IETF terminology. Does use of "actor" to reference all three > concepts raise any concerns? > > > I also believe that listing *potential* acquisition methods is useful in at least > > the following way: Including a multitude of acquisition methods clearly > signals > > our intent of finding information where it already exists, while not > > necessarily precluding our ability to *get* information when information > > does not exist. > > Adam, would you or Henk provide some example acquisition methods for > discussion? > > > Finally, I, too, like the notion of a work-flow scenario. I don't want to be > the > > one drawing a process diagram in an RFC, though. ;-) > > How would this differ from the workflow scenario text in section 2? > > Are you suggesting representing this text in a visual form? If so, would > anyone like to make a contribution of some ascii art? > > > awm > > ________________________________________ > > From: sacm [sacm-bounces@ietf.org] on behalf of Henk Birkholz > > [henk.birkholz@sit.fraunhofer.de] > > Sent: Friday, November 22, 2013 3:27 AM > > To: sacm@ietf.org > > Subject: Re: [sacm] FW: New Version Notification for draft-ietf-sacm-use- > > cases-05.txt > > > > Regarding the first two question in section 2: > > > > 1.) Security automation today often supports the user/operator, I think. > > There are cases a security-process can be fully automated, of course, and in > > order to manage the sheer amount of security related system events > > automation is essential, but it seems to me that the complexity and > > heterogeneity of root-causes (that might trigger the work-flow) make the > > inclusion of a user/operator necessary. > > > > 2.) To include acquisition methods can provide an intuitive insight about the > > scope and intend of the endpoint posture assessment domain, I think. On > > one hand, that might bloat the use-case document a bit (and maybe > renders > > the title "sacm use cases" too specific?). On the other hand, I like the > > inclusion of a work-flow scenario and I think it is a good place to highlight > > acquisition methods. > > > > - Henk > > > > On 11/21/2013 12:27 AM, Waltermire, David A. wrote: > > > I just posted an updated use case draft based on the editorial sessions > > during the IETF 88 meeting in Vancouver, BC, Canada. My thanks to all that > > provided input. > > > > > > I used the word version that we edited as a starting point. Here is what I > > did: > > > > > > - I worked through the use cases we planned to remove and made sure > to > > merge in any concepts that would be lost. If you submitted a previous use > > case that was removed, please double check that I didn't miss anything. > > > - I broke up "Endpoint Identification and Assessment" into 3 distinct and > > somewhat separable use cases: "Endpoint Identification and Assessment > > Planning", "Endpoint Posture Attribute Value Collection", "Posture > > Evaluation". Please let me know what you think about this change. > > > - Addressed some aspects of the discussion thread based on the working > > session changes. Please provide any suggested edits for aspects that I > might > > have missed or got wrong. > > > > > > The rest of the changes can be found in the draft's change log. > > > > > > If possible, I'd like to get to a fairly stable place with this draft in the next > > revision or two to allow for progress to be made on the requirements. In > > addition to the embedded questions in the document, I'd like to focus on > the > > following questions: > > > > > > Is the draft approachable for a newcomer to the effort? Do you see the > > updated use case structure as an improvement? > > > Does this draft paint a complete enough picture? Are we missing any > > important concepts? > > > Is there anything you can't live with? > > > > > > I hope to release at least one or two more updates to this draft within the > > next few weeks before the holidays catch up on us. I know everyone is > > busy; timely comments are appreciated to allow for a quick turnaround on > > the next revision. > > > > > > Thanks, > > > Dave > > > > > > -----Original Message----- > > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > > Sent: Wednesday, November 20, 2013 5:58 PM > > > To: Waltermire, David A.; David Harrington > > > Subject: New Version Notification for draft-ietf-sacm-use-cases-05.txt > > > > > > > > > A new version of I-D, draft-ietf-sacm-use-cases-05.txt has been > > successfully submitted by David Waltermire and posted to the IETF > > repository. > > > > > > Filename: draft-ietf-sacm-use-cases > > > Revision: 05 > > > Title: Endpoint Security Posture Assessment - Enterprise Use > Cases > > > Creation date: 2013-11-20 > > > Group: sacm > > > Number of pages: 24 > > > URL: http://www.ietf.org/internet-drafts/draft-ietf-sacm-use- > cases- > > 05.txt > > > Status: http://datatracker.ietf.org/doc/draft-ietf-sacm-use-cases > > > Htmlized: http://tools.ietf.org/html/draft-ietf-sacm-use-cases-05 > > > Diff: http://www.ietf.org/rfcdiff?url2=draft-ietf-sacm-use-cases-05 > > > > > > Abstract: > > > This memo documents a sampling of use cases for securely aggregating > > > configuration and operational data and evaluating that data to > > > determine an organization's security posture. From these operational > > > use cases, we can derive common functional capabilities and > > > requirements to guide development of vendor-neutral, interoperable > > > standards for aggregating and evaluating data relevant to security > > > posture. > > > > > > > > > > > > > > > Please note that it may take a couple of minutes from the time of > > submission until the htmlized version and diff are available at tools.ietf.org. > > > > > > The IETF Secretariat > > > > > > _______________________________________________ > > > sacm mailing list > > > sacm@ietf.org > > > https://www.ietf.org/mailman/listinfo/sacm > > > > > > > > > > > ... > > > > . . . > > _______________________________________________ > > sacm mailing list > > sacm@ietf.org > > https://www.ietf.org/mailman/listinfo/sacm > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm From dromasca@avaya.com Thu Dec 5 01:52:38 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 583901ADD02 for ; Thu, 5 Dec 2013 01:52:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id no--AgXx8pve for ; Thu, 5 Dec 2013 01:52:35 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id A819A1ADBD4 for ; Thu, 5 Dec 2013 01:52:35 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlQHAMpLoFKHCzI1/2dsb2JhbABWA4JmIThNBqNxi0eJNIEYFnSCJQEBAQEDAQEBDygsCAkOBAIBCA0BAwQBAQEKFAkHJwsUCAEIAgQBEggBEgeHTgMPAQcFpjyTMgiHIBeOHTIhFwYLgw+BEwOUMYUThTyLJ4Mpgio X-IronPort-AV: E=Sophos;i="4.93,832,1378872000"; d="scan'208";a="39708737" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 05 Dec 2013 04:52:31 -0500 Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES128-SHA; 05 Dec 2013 04:41:33 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC01.global.avaya.com ([135.64.58.11]) with mapi id 14.03.0146.000; Thu, 5 Dec 2013 10:52:29 +0100 From: "Romascanu, Dan (Dan)" To: David Harrington , "'Waltermire, David A.'" , 'Adam Montville' , 'Henk Birkholz' , "sacm@ietf.org" Thread-Topic: [sacm] FW: New Version Notification for draft-ietf-sacm-use-cases-05.txt Thread-Index: AQHO8XhpGD+JoxePMEWSbDEgFCM8bZpFWjdg Date: Thu, 5 Dec 2013 09:52:29 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA12952A08@AZ-FFEXMB04.global.avaya.com> References: <20131120225753.9031.68753.idtracker@ietfa.amsl.com> , <528F23D0.3080504@sit.fraunhofer.de> <05BCCEB107AF88469B9F99783D47C1D6065E4769@CISEXCHANGE1.msisac.org.local> <025d01cef178$63f56840$2be038c0$@comcast.net> In-Reply-To: <025d01cef178$63f56840$2be038c0$@comcast.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sacm] FW: New Version Notification for draft-ietf-sacm-use-cases-05.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 09:52:38 -0000 I share DBH's concern. There may be significant differences in workflows an= d interface requirements between systems (networks, devices) and humans vs.= systems (networks, devices) and applications. There may be significant dif= ferences if the humans are operators or end-users. Using one term (say 'act= or') for all may create ambiguities. I am not sure that I understand the ad= vantages of the proposed abstraction. Dan=20 (speaking as contributor) > -----Original Message----- > From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of David Harrington > Sent: Thursday, December 05, 2013 7:11 AM > To: 'Waltermire, David A.'; 'Adam Montville'; 'Henk Birkholz'; > sacm@ietf.org > Subject: Re: [sacm] FW: New Version Notification for draft-ietf-sacm- > use-cases-05.txt >=20 > Hi, >=20 > Using actor concerns me. > I find it important to understand whether some content needs to be > parsed by a human (with our wonderful ability to parse), or a computer > application (which is bound by a set of rules, and has great difficulty > when the content is not consistent with the rules). >=20 > Around 2003, the operators made it clear that CLIs were difficult to > work with, because queries would return information in variable formats. > While humans might be able to parse the output that might change from > vendor to vendor, model to model, and release to release, tools had > significant difficulty due to the lack of standardization. Operators > could try to deal with the lack of standardization by writing expect > scripts, but they would need to be updated constantly because what > worked for one release of a product might not be the same in the next > release. > Humans can parse variable syntax, such as the natural language content > of syslog, but applications can have a hard time. >=20 > I think is very important to know whether we are designing something for > human consumption or for computer consumption. > "Actor" doesn't provide enough differentiation to know how to design our > solutions. >=20 > David Harrington > dbharrington@comcast.net > +1-603-828-1401 >=20 > > -----Original Message----- > > From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Waltermire, > > David A. > > Sent: Wednesday, December 04, 2013 8:54 PM > > To: Adam Montville; Henk Birkholz; sacm@ietf.org > > Subject: Re: [sacm] FW: New Version Notification for > > draft-ietf-sacm-use- cases-05.txt > > > > Comments inline. > > > > > -----Original Message----- > > > From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Adam > > > Montville > > > Sent: Wednesday, December 04, 2013 8:38 PM > > > To: Henk Birkholz; sacm@ietf.org > > > Subject: Re: [sacm] FW: New Version Notification for > draft-ietf-sacm-use- > > > cases-05.txt > > > > > > Something I've found helpful in the past is to abstract a bit > > > further > from > > > "user", "operator", "application" and simply reference all of them > > > at > once > > > with the term "actor". > > > > Are we ok with the change to using actor? The current usage of "user", > > "operator", "application" (specifically the last two) was suggested a > while > > back to align with IETF terminology. Does use of "actor" to reference > > all > three > > concepts raise any concerns? > > > > > I also believe that listing *potential* acquisition methods is > > > useful in > at least > > > the following way: Including a multitude of acquisition methods > > > clearly > > signals > > > our intent of finding information where it already exists, while not > > > necessarily precluding our ability to *get* information when > > > information does not exist. > > > > Adam, would you or Henk provide some example acquisition methods for > > discussion? > > > > > Finally, I, too, like the notion of a work-flow scenario. I don't > > > want > to be > > the > > > one drawing a process diagram in an RFC, though. ;-) > > > > How would this differ from the workflow scenario text in section 2? > > > > Are you suggesting representing this text in a visual form? If so, > > would anyone like to make a contribution of some ascii art? > > > > > awm > > > ________________________________________ > > > From: sacm [sacm-bounces@ietf.org] on behalf of Henk Birkholz > > > [henk.birkholz@sit.fraunhofer.de] > > > Sent: Friday, November 22, 2013 3:27 AM > > > To: sacm@ietf.org > > > Subject: Re: [sacm] FW: New Version Notification for > draft-ietf-sacm-use- > > > cases-05.txt > > > > > > Regarding the first two question in section 2: > > > > > > 1.) Security automation today often supports the user/operator, I > think. > > > There are cases a security-process can be fully automated, of > > > course, > and in > > > order to manage the sheer amount of security related system events > > > automation is essential, but it seems to me that the complexity and > > > heterogeneity of root-causes (that might trigger the work-flow) make > > > the inclusion of a user/operator necessary. > > > > > > 2.) To include acquisition methods can provide an intuitive insight > about the > > > scope and intend of the endpoint posture assessment domain, I think. > > > On one hand, that might bloat the use-case document a bit (and maybe > > renders > > > the title "sacm use cases" too specific?). On the other hand, I like > > > the inclusion of a work-flow scenario and I think it is a good place > > > to > highlight > > > acquisition methods. > > > > > > - Henk > > > > > > On 11/21/2013 12:27 AM, Waltermire, David A. wrote: > > > > I just posted an updated use case draft based on the editorial > sessions > > > during the IETF 88 meeting in Vancouver, BC, Canada. My thanks to > > > all > that > > > provided input. > > > > > > > > I used the word version that we edited as a starting point. Here > > > > is > what I > > > did: > > > > > > > > - I worked through the use cases we planned to remove and made > > > > sure > > to > > > merge in any concepts that would be lost. If you submitted a > > > previous > use > > > case that was removed, please double check that I didn't miss > anything. > > > > - I broke up "Endpoint Identification and Assessment" into 3 > > > > distinct > and > > > somewhat separable use cases: "Endpoint Identification and > > > Assessment Planning", "Endpoint Posture Attribute Value Collection", > > > "Posture Evaluation". Please let me know what you think about this > change. > > > > - Addressed some aspects of the discussion thread based on the > > > > working > > > session changes. Please provide any suggested edits for aspects that > > > I > > might > > > have missed or got wrong. > > > > > > > > The rest of the changes can be found in the draft's change log. > > > > > > > > If possible, I'd like to get to a fairly stable place with this > > > > draft > in the next > > > revision or two to allow for progress to be made on the > > > requirements. In addition to the embedded questions in the document, > > > I'd like to focus on > > the > > > following questions: > > > > > > > > Is the draft approachable for a newcomer to the effort? Do you see > > > > the > > > updated use case structure as an improvement? > > > > Does this draft paint a complete enough picture? Are we missing > > > > any > > > important concepts? > > > > Is there anything you can't live with? > > > > > > > > I hope to release at least one or two more updates to this draft > within the > > > next few weeks before the holidays catch up on us. I know everyone > > > is busy; timely comments are appreciated to allow for a quick > > > turnaround on the next revision. > > > > > > > > Thanks, > > > > Dave > > > > > > > > -----Original Message----- > > > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > > > Sent: Wednesday, November 20, 2013 5:58 PM > > > > To: Waltermire, David A.; David Harrington > > > > Subject: New Version Notification for > > > > draft-ietf-sacm-use-cases-05.txt > > > > > > > > > > > > A new version of I-D, draft-ietf-sacm-use-cases-05.txt has been > > > successfully submitted by David Waltermire and posted to the IETF > > > repository. > > > > > > > > Filename: draft-ietf-sacm-use-cases > > > > Revision: 05 > > > > Title: Endpoint Security Posture Assessment - > Enterprise Use > > Cases > > > > Creation date: 2013-11-20 > > > > Group: sacm > > > > Number of pages: 24 > > > > URL: > http://www.ietf.org/internet-drafts/draft-ietf-sacm-use- > > cases- > > > 05.txt > > > > Status: > http://datatracker.ietf.org/doc/draft-ietf-sacm-use-cases > > > > Htmlized: > http://tools.ietf.org/html/draft-ietf-sacm-use-cases-05 > > > > Diff: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sacm-use-cases-05 > > > > > > > > Abstract: > > > > This memo documents a sampling of use cases for securely > aggregating > > > > configuration and operational data and evaluating that data to > > > > determine an organization's security posture. From these > operational > > > > use cases, we can derive common functional capabilities and > > > > requirements to guide development of vendor-neutral, > interoperable > > > > standards for aggregating and evaluating data relevant to > security > > > > posture. > > > > > > > > > > > > > > > > > > > > Please note that it may take a couple of minutes from the time of > > > submission until the htmlized version and diff are available at > tools.ietf.org. > > > > > > > > The IETF Secretariat > > > > > > > > _______________________________________________ > > > > sacm mailing list > > > > sacm@ietf.org > > > > https://www.ietf.org/mailman/listinfo/sacm > > > > > > > > > > > > > > > > ... > > > > > > . . . > > > _______________________________________________ > > > sacm mailing list > > > sacm@ietf.org > > > https://www.ietf.org/mailman/listinfo/sacm > > _______________________________________________ > > sacm mailing list > > sacm@ietf.org > > https://www.ietf.org/mailman/listinfo/sacm >=20 > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm From michael.hammer@yaanatech.com Thu Dec 5 06:12:57 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0FC31ADFD0 for ; Thu, 5 Dec 2013 06:12:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uV0vajlx3tcV for ; Thu, 5 Dec 2013 06:12:54 -0800 (PST) Received: from email1.corp.yaanatech.com (webmail10.yaanatech.com [63.128.177.10]) by ietfa.amsl.com (Postfix) with ESMTP id 086F91ADFBC for ; Thu, 5 Dec 2013 06:12:38 -0800 (PST) Received: from SC9-EX2K10MB1.corp.yaanatech.com ([fe80::149d:c2e1:8065:2a47]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Thu, 5 Dec 2013 06:12:34 -0800 From: Michael Hammer To: "dromasca@avaya.com" , "dbharrington@comcast.net" , "david.waltermire@nist.gov" , "Adam.Montville@cisecurity.org" , "henk.birkholz@sit.fraunhofer.de" , "sacm@ietf.org" Thread-Topic: [sacm] FW: New Version Notification for draft-ietf-sacm-use-cases-05.txt Thread-Index: AQHO8Z+8PPDG2hvlOUaGfqmV1VtLbJpFpFag Date: Thu, 5 Dec 2013 14:12:33 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBF01B8D@sc9-ex2k10mb1.corp.yaanatech.com> References: <20131120225753.9031.68753.idtracker@ietfa.amsl.com> , <528F23D0.3080504@sit.fraunhofer.de> <05BCCEB107AF88469B9F99783D47C1D6065E4769@CISEXCHANGE1.msisac.org.local> <025d01cef178$63f56840$2be038c0$@comcast.net> <9904FB1B0159DA42B0B887B7FA8119CA12952A08@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA12952A08@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.52] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0008_01CEF19A.1ED5F8C0" MIME-Version: 1.0 Subject: Re: [sacm] FW: New Version Notification for draft-ietf-sacm-use-cases-05.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 14:12:58 -0000 ------=_NextPart_000_0008_01CEF19A.1ED5F8C0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Actor connotes human to me. What would be wrong with using client or server if asymmetric, or user agent if peering? With adjectives to differentiate types. Mike -----Original Message----- From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Thursday, December 05, 2013 4:52 AM To: David Harrington; 'Waltermire, David A.'; 'Adam Montville'; 'Henk Birkholz'; sacm@ietf.org Subject: Re: [sacm] FW: New Version Notification for draft-ietf-sacm-use-cases-05.txt I share DBH's concern. There may be significant differences in workflows and interface requirements between systems (networks, devices) and humans vs. systems (networks, devices) and applications. There may be significant differences if the humans are operators or end-users. Using one term (say 'actor') for all may create ambiguities. I am not sure that I understand the advantages of the proposed abstraction. Dan (speaking as contributor) > -----Original Message----- > From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of David Harrington > Sent: Thursday, December 05, 2013 7:11 AM > To: 'Waltermire, David A.'; 'Adam Montville'; 'Henk Birkholz'; > sacm@ietf.org > Subject: Re: [sacm] FW: New Version Notification for draft-ietf-sacm- > use-cases-05.txt > > Hi, > > Using actor concerns me. > I find it important to understand whether some content needs to be > parsed by a human (with our wonderful ability to parse), or a computer > application (which is bound by a set of rules, and has great difficulty > when the content is not consistent with the rules). > > Around 2003, the operators made it clear that CLIs were difficult to > work with, because queries would return information in variable formats. > While humans might be able to parse the output that might change from > vendor to vendor, model to model, and release to release, tools had > significant difficulty due to the lack of standardization. Operators > could try to deal with the lack of standardization by writing expect > scripts, but they would need to be updated constantly because what > worked for one release of a product might not be the same in the next > release. > Humans can parse variable syntax, such as the natural language content > of syslog, but applications can have a hard time. > > I think is very important to know whether we are designing something for > human consumption or for computer consumption. > "Actor" doesn't provide enough differentiation to know how to design our > solutions. > > David Harrington > dbharrington@comcast.net > +1-603-828-1401 > > > -----Original Message----- > > From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Waltermire, > > David A. > > Sent: Wednesday, December 04, 2013 8:54 PM > > To: Adam Montville; Henk Birkholz; sacm@ietf.org > > Subject: Re: [sacm] FW: New Version Notification for > > draft-ietf-sacm-use- cases-05.txt > > > > Comments inline. > > > > > -----Original Message----- > > > From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Adam > > > Montville > > > Sent: Wednesday, December 04, 2013 8:38 PM > > > To: Henk Birkholz; sacm@ietf.org > > > Subject: Re: [sacm] FW: New Version Notification for > draft-ietf-sacm-use- > > > cases-05.txt > > > > > > Something I've found helpful in the past is to abstract a bit > > > further > from > > > "user", "operator", "application" and simply reference all of them > > > at > once > > > with the term "actor". > > > > Are we ok with the change to using actor? The current usage of "user", > > "operator", "application" (specifically the last two) was suggested a > while > > back to align with IETF terminology. Does use of "actor" to reference > > all > three > > concepts raise any concerns? > > > > > I also believe that listing *potential* acquisition methods is > > > useful in > at least > > > the following way: Including a multitude of acquisition methods > > > clearly > > signals > > > our intent of finding information where it already exists, while not > > > necessarily precluding our ability to *get* information when > > > information does not exist. > > > > Adam, would you or Henk provide some example acquisition methods for > > discussion? > > > > > Finally, I, too, like the notion of a work-flow scenario. I don't > > > want > to be > > the > > > one drawing a process diagram in an RFC, though. ;-) > > > > How would this differ from the workflow scenario text in section 2? > > > > Are you suggesting representing this text in a visual form? If so, > > would anyone like to make a contribution of some ascii art? > > > > > awm > > > ________________________________________ > > > From: sacm [sacm-bounces@ietf.org] on behalf of Henk Birkholz > > > [henk.birkholz@sit.fraunhofer.de] > > > Sent: Friday, November 22, 2013 3:27 AM > > > To: sacm@ietf.org > > > Subject: Re: [sacm] FW: New Version Notification for > draft-ietf-sacm-use- > > > cases-05.txt > > > > > > Regarding the first two question in section 2: > > > > > > 1.) Security automation today often supports the user/operator, I > think. > > > There are cases a security-process can be fully automated, of > > > course, > and in > > > order to manage the sheer amount of security related system events > > > automation is essential, but it seems to me that the complexity and > > > heterogeneity of root-causes (that might trigger the work-flow) make > > > the inclusion of a user/operator necessary. > > > > > > 2.) To include acquisition methods can provide an intuitive insight > about the > > > scope and intend of the endpoint posture assessment domain, I think. > > > On one hand, that might bloat the use-case document a bit (and maybe > > renders > > > the title "sacm use cases" too specific?). On the other hand, I like > > > the inclusion of a work-flow scenario and I think it is a good place > > > to > highlight > > > acquisition methods. > > > > > > - Henk > > > > > > On 11/21/2013 12:27 AM, Waltermire, David A. wrote: > > > > I just posted an updated use case draft based on the editorial > sessions > > > during the IETF 88 meeting in Vancouver, BC, Canada. My thanks to > > > all > that > > > provided input. > > > > > > > > I used the word version that we edited as a starting point. Here > > > > is > what I > > > did: > > > > > > > > - I worked through the use cases we planned to remove and made > > > > sure > > to > > > merge in any concepts that would be lost. If you submitted a > > > previous > use > > > case that was removed, please double check that I didn't miss > anything. > > > > - I broke up "Endpoint Identification and Assessment" into 3 > > > > distinct > and > > > somewhat separable use cases: "Endpoint Identification and > > > Assessment Planning", "Endpoint Posture Attribute Value Collection", > > > "Posture Evaluation". Please let me know what you think about this > change. > > > > - Addressed some aspects of the discussion thread based on the > > > > working > > > session changes. Please provide any suggested edits for aspects that > > > I > > might > > > have missed or got wrong. > > > > > > > > The rest of the changes can be found in the draft's change log. > > > > > > > > If possible, I'd like to get to a fairly stable place with this > > > > draft > in the next > > > revision or two to allow for progress to be made on the > > > requirements. In addition to the embedded questions in the document, > > > I'd like to focus on > > the > > > following questions: > > > > > > > > Is the draft approachable for a newcomer to the effort? Do you see > > > > the > > > updated use case structure as an improvement? > > > > Does this draft paint a complete enough picture? Are we missing > > > > any > > > important concepts? > > > > Is there anything you can't live with? > > > > > > > > I hope to release at least one or two more updates to this draft > within the > > > next few weeks before the holidays catch up on us. I know everyone > > > is busy; timely comments are appreciated to allow for a quick > > > turnaround on the next revision. > > > > > > > > Thanks, > > > > Dave > > > > > > > > -----Original Message----- > > > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > > > Sent: Wednesday, November 20, 2013 5:58 PM > > > > To: Waltermire, David A.; David Harrington > > > > Subject: New Version Notification for > > > > draft-ietf-sacm-use-cases-05.txt > > > > > > > > > > > > A new version of I-D, draft-ietf-sacm-use-cases-05.txt has been > > > successfully submitted by David Waltermire and posted to the IETF > > > repository. > > > > > > > > Filename: draft-ietf-sacm-use-cases > > > > Revision: 05 > > > > Title: Endpoint Security Posture Assessment - > Enterprise Use > > Cases > > > > Creation date: 2013-11-20 > > > > Group: sacm > > > > Number of pages: 24 > > > > URL: > http://www.ietf.org/internet-drafts/draft-ietf-sacm-use- > > cases- > > > 05.txt > > > > Status: > http://datatracker.ietf.org/doc/draft-ietf-sacm-use-cases > > > > Htmlized: > http://tools.ietf.org/html/draft-ietf-sacm-use-cases-05 > > > > Diff: > http://www.ietf.org/rfcdiff?url2=draft-ietf-sacm-use-cases-05 > > > > > > > > Abstract: > > > > This memo documents a sampling of use cases for securely > aggregating > > > > configuration and operational data and evaluating that data to > > > > determine an organization's security posture. From these > operational > > > > use cases, we can derive common functional capabilities and > > > > requirements to guide development of vendor-neutral, > interoperable > > > > standards for aggregating and evaluating data relevant to > security > > > > posture. > > > > > > > > > > > > > > > > > > > > Please note that it may take a couple of minutes from the time of > > > submission until the htmlized version and diff are available at > tools.ietf.org. > > > > > > > > The IETF Secretariat > > > > > > > > _______________________________________________ > > > > sacm mailing list > > > > sacm@ietf.org > > > > https://www.ietf.org/mailman/listinfo/sacm > > > > > > > > > > > > > > > > ... > > > > > > . . . > > > _______________________________________________ > > > sacm mailing list > > > sacm@ietf.org > > > https://www.ietf.org/mailman/listinfo/sacm > > _______________________________________________ > > sacm mailing list > > sacm@ietf.org > > https://www.ietf.org/mailman/listinfo/sacm > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm ------=_NextPart_000_0008_01CEF19A.1ED5F8C0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRPzCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggZCMIIFKqADAgECAhA4qwAv/66Wt1b/OVr7XecbMA0G CSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWdu LCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNz IDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw0xMTA5MDEw MDAwMDBaFw0yMTA4MzEyMzU5NTlaMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMg Q29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBl cnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHNDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMbsJ/0d Y/Q7HYrB0xzIyIKGtrhKhpKqgVxyyjANL55BIlcwISWQmqP0rCrGiBeGYXITdi7sA8snm48ggDfg 5IraVaZQD/y5XCNpiUKhuh+v7w75pMkK8fg3ssbZkkqufd+4RB+buj+MBv7YI09IUSNqYISo7icv YN+W8hoqjDyPAMxPy/ogjrw19uHwmrYF8/wdP8YUew7a8gXk04MCpsVpcLSp5Fbp2x1c9KY24mu1 Hiot3L677joEsDAIrV9obMa9BpaIhOfmqWQtvDgwu4gmw2dmZrS0d/nAoccOcu9m4uW5yuDzhXc1 mN7UHLD+ZnHiOMtufE9AVeuX2agYHu0CAwEAAaOCAkQwggJAMDgGCCsGAQUFBwEBBCwwKjAoBggr BgEFBQcwAYYcaHR0cDovL3BraS1vY3NwLnZlcmlzaWduLmNvbTASBgNVHRMBAf8ECDAGAQH/AgEA MGwGA1UdIARlMGMwYQYLYIZIAYb4RQEHFwEwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1h dXRoLmNvbS9jcHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwNAYD VR0fBC0wKzApoCegJYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0P AQH/BAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFWZXJpU2lnbk1QS0ktMi05NzAdBgNV HQ4EFgQUrfnDk3IttbkoYeSk12DVxApeGgEwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUA A4IBAQDWj8Ham4jys2xNH1gvugFRXXTBRujDuHuf1kDx7/8yuolrwA40Q5+kmeak8F1IM2KFhWH+ I4gijGCbK5xlSZTEojgkSKVcpVBLaOliIqeT6Jkibj1buxBCDh9MdUc0VgmP+L2MPPNcu9KWcFRw Yk3v0RC+nUgsXuyGaweC8D3hJScoLOAWdh6z/eViltKKPV8rrvtcwhO3ZWPLNHZDn9aHmaturZXB AD9GJ4H/Nd4jDkPcFF8y+cop78JSMPWZ3bmB+DolII2CaPK5IYV0ZgThhjkWMvIt1iqoyd7ZAAJP 4xggxaWBVraV3tOCrfh7Jb5kfC6gunAs+Pl14nRNB22EMIIG1zCCBb+gAwIBAgIQEB3dROkPDT0Q 6QYEc74tcjANBgkqhkiG9w0BAQUFADCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVj IENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQ ZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVh bCBTdWJzY3JpYmVyIENBIC0gRzQwHhcNMTMwNDAxMDAwMDAwWhcNMTQwNDAyMjM1OTU5WjCBzjEu MCwGA1UEAwwlUGVyc29uYSBOb3QgVmFsaWRhdGVkIC0gMTM2NDg0MjY5NDQ0MzErMCkGCSqGSIb3 DQEJARYcbWljaGFlbC5oYW1tZXJAeWFhbmF0ZWNoLmNvbTEPMA0GA1UECwwGUy9NSU1FMR4wHAYD VQQLDBVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxHzAdBgNVBAsMFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHTAbBgNVBAoMFFN5bWFudGVjIENvcnBvcmF0aW9uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAh2AtKQNowI8ILmNvdcY16moA8CH7hjSvGDNofwWsh4quEfZ6VQGtDhhOjUmW6JVq 719MH8FNJcVr8oAiVaK3nNeJTL2wO68LpgX6tcZ/z22pJoz98wHzgfWf3pfEUYrCqYg2V3m6oe0t kd+OaeY8DmPVSpG7as0rkoEzeNwCtmpYjkm96mBO6/AQwsowSLbSuqkEGykp1k47KiPBtxhbp2um IReh94vPrr1O9zXau9oGMvABJjigYQ2e5AhhhDdK8qOkhgkMAJN2nvLqY+VFrnFIsb5noQ/tP2M/ ct9qwRZ5kUaumRqE/XzV3rH8PoacZW/YvcwAp8Gr1ZaHCMRl+wIDAQABo4IC1TCCAtEwDAYDVR0T AQH/BAIwADAOBgNVHQ8BAf8EBAMCBaAwIAYDVR0lAQH/BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBTlvYUx4PMlUy6uvceJkDMK4jBDZjAnBgNVHREEIDAegRxtaWNoYWVsLmhhbW1l ckB5YWFuYXRlY2guY29tMB8GA1UdIwQYMBaAFK35w5NyLbW5KGHkpNdg1cQKXhoBMIIBKwYIKwYB BQUHAQEEggEdMIIBGTCCARUGCCsGAQUFBzAChoIBB2xkYXA6Ly9kaXJlY3RvcnkudmVyaXNpZ24u Y29tL0NOJTIwJTNEJTIwU3ltYW50ZWMlMjBDbGFzcyUyMDElMjBJbmRpdmlkdWFsJTIwU3Vic2Ny aWJlciUyMENBJTIwLSUyMEc0JTJDJTIwT1UlMjAlM0QlMjBQZXJzb25hJTIwTm90JTIwVmFsaWRh dGVkJTJDJTIwT1UlMjAlM0QlMjBTeW1hbnRlYyUyMFRydXN0JTIwTmV0d29yayUyQyUyME8lMjAl M0QlMjBTeW1hbnRlYyUyMENvcnBvcmF0aW9uJTJDJTIwQyUyMCUzRCUyMFVTP2NBQ2VydGlmaWNh dGU7YmluYXJ5MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1dGguY29tL2Nh XzU2MWMxMDM2OTBjOTdhNjkyNDdhMGVmMDcxYWM4MWFmL0xhdGVzdENSTC5jcmwwbAYDVR0gBGUw YzBhBgtghkgBhvhFAQcXATBSMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2Nw czAoBggrBgEFBQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTAqBgpghkgBhvhFARAD BBwwGgYRYIZIAYb4RQEQAQICBAGGsxcWBTEwOTIyMA0GCSqGSIb3DQEBBQUAA4IBAQAae/er4pfB TpqK6c/uJ9D8dVJzzNX26akkB8z/29totzbkpFAIlXRh02iNVK+GnsgS1gwu3FOvjgT5M4i+cNxD vTJVcnZNXns75JUGX3UsWQbtSySrVzQx8lMtwW6nXHM5GlEaY8/jKVpambG2q9OHjmwMTz7I4A+y KiiGCGdhE23dFOvku6t/oiwqFnXJmb4o75kbVevKEOd34MIj0P7Q8+1mZcNYEUTYKadoPXFyTWnO 2HTMvFcGgdLFKcqb13clWeW3/B5WjdBimpMjbvwi8ZbrhFdp7Y3NLKFSRH8W29rt0LW7zULxii0z 34NGsBkW9w95PLzTsqmKD4Yv5AkIMYIEkjCCBI4CAQEwgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYD VQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29y azEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMAkGBSsO AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMTIw NTE0MTIyOFowIwYJKoZIhvcNAQkEMRYEFHpf8T7enEu1JrgqjIJQWxq3BwFmMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAMG1berjFir+0fov0rTJgXki3Vux0hPH2Yth7dVXB WcN9sFV73rz086WJaThsFcQRMYTWz4LnCb8fvSxs+BKmf9uIwvPCR92qr3TYvgQmrho3RidZVljN BqJSo1L/59ojM1iOgDx2INt9EDIdGeJXL133WCvLAtAKTqf2iBPI2cjUlQ+pq3nZ7xCLXs0EMYrg eFuwHFrYWbxu8NIuivJ/ZXW9OFv/zXIvsXwjhQP8Qq37MRzxMcRYtFubcTsf+3YIH7WIAWuI8II2 cwC0y8YOPEX9I1bbwsoY/a5X0SEfDfiYNZBuVub91krTcRnRfBLNClWbcPwb5zHed366djQOXQAA AAAAAA== ------=_NextPart_000_0008_01CEF19A.1ED5F8C0-- From blueroofmusic@gmail.com Thu Dec 5 06:50:01 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C8DF1AE052 for ; Thu, 5 Dec 2013 06:50:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iUNb9iS6FkYi for ; Thu, 5 Dec 2013 06:49:56 -0800 (PST) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 964531AE05C for ; Thu, 5 Dec 2013 06:49:56 -0800 (PST) Received: by mail-ie0-f174.google.com with SMTP id at1so29013603iec.5 for ; Thu, 05 Dec 2013 06:49:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=tO6o5jnpNFErXS3CNq7ZkrJLIX1VnWL9ocCqcRdI3+k=; b=0KBnxChk+TvlQN9yzEIyeq8zka1emOmG3MBnwH3Rb6FiptG/sgmDkEqSRu3s3LqOGJ CehxTXwJxYUeTDlow4oyzbDqmG8zOAWKmW3vBac65e+tDXnXxWkRd+pRg7pgSsf1hG0j 0/+CrCdc1u6nL3RpFrjPoGoMKhoXVMI6aJ2F2ER6Kc4QgEwM9OfdNjZn+/rGoXrvM1Vt 0K6jVoHkK5Kq5553ljR67G7V8DWcKZB8FgsxlYo0MfKa32sDEusbAxdeTDK0Dp1QJ6y/ O9lZl44fsVpWmOwZAC5o412AAABkgnM11pEyfpUDM54H39VgF8zO38gNwM9vYUBm0A4j gfuA== X-Received: by 10.50.39.45 with SMTP id m13mr6598023igk.14.1386254993110; Thu, 05 Dec 2013 06:49:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.203.38 with HTTP; Thu, 5 Dec 2013 06:49:33 -0800 (PST) In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBF01B8D@sc9-ex2k10mb1.corp.yaanatech.com> References: <20131120225753.9031.68753.idtracker@ietfa.amsl.com> <528F23D0.3080504@sit.fraunhofer.de> <05BCCEB107AF88469B9F99783D47C1D6065E4769@CISEXCHANGE1.msisac.org.local> <025d01cef178$63f56840$2be038c0$@comcast.net> <9904FB1B0159DA42B0B887B7FA8119CA12952A08@AZ-FFEXMB04.global.avaya.com> <00C069FD01E0324C9FFCADF539701DB3BBF01B8D@sc9-ex2k10mb1.corp.yaanatech.com> From: Ira McDonald Date: Thu, 5 Dec 2013 09:49:33 -0500 Message-ID: To: Michael Hammer Content-Type: multipart/alternative; boundary=047d7bdc131e6ebfbd04eccaa4cd Cc: "dbharrington@comcast.net" , "henk.birkholz@sit.fraunhofer.de" , "dromasca@avaya.com" , "david.waltermire@nist.gov" , "Adam.Montville@cisecurity.org" , "sacm@ietf.org" Subject: Re: [sacm] FW: New Version Notification for draft-ietf-sacm-use-cases-05.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 14:50:01 -0000 --047d7bdc131e6ebfbd04eccaa4cd Content-Type: text/plain; charset=ISO-8859-1 Hi, My two cents - End User, Operator, and Administrator are quite distinct roles of actors in standards from many SDOs - they have inherently distinct default privileges - using these common role terms consistently would make SACM use cases more accessible to non-participants in the SACM WG. BTW - there are a few other roles of actors that should probably be used in SACM use cases, e.g., Application - although tthat's a slippery slope, because normal applications (browsers, email readers, etc.) have very different privileges and responsibilities from security-specific applications (MDM agents, anti-virus scanners, etc.). Cheers, - Ira Ira McDonald (Musician / Software Architect) Co-Chair - TCG Trusted Mobility Solutions WG Chair - Linux Foundation Open Printing WG Secretary - IEEE-ISTO Printer Working Group Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG IETF Designated Expert - IPP & Printer MIB Blue Roof Music / High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto: blueroofmusic@gmail.com Winter 579 Park Place Saline, MI 48176 734-944-0094 Summer PO Box 221 Grand Marais, MI 49839 906-494-2434 On Thu, Dec 5, 2013 at 9:12 AM, Michael Hammer wrote: > Actor connotes human to me. > > What would be wrong with using client or server if asymmetric, or user > agent > if peering? > With adjectives to differentiate types. > > Mike > > > -----Original Message----- > From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Romascanu, Dan > (Dan) > Sent: Thursday, December 05, 2013 4:52 AM > To: David Harrington; 'Waltermire, David A.'; 'Adam Montville'; 'Henk > Birkholz'; sacm@ietf.org > Subject: Re: [sacm] FW: New Version Notification for > draft-ietf-sacm-use-cases-05.txt > > I share DBH's concern. There may be significant differences in workflows > and > interface requirements between systems (networks, devices) and humans vs. > systems (networks, devices) and applications. There may be significant > differences if the humans are operators or end-users. Using one term (say > 'actor') for all may create ambiguities. I am not sure that I understand > the > advantages of the proposed abstraction. > > Dan > (speaking as contributor) > > > > -----Original Message----- > > From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of David Harrington > > Sent: Thursday, December 05, 2013 7:11 AM > > To: 'Waltermire, David A.'; 'Adam Montville'; 'Henk Birkholz'; > > sacm@ietf.org > > Subject: Re: [sacm] FW: New Version Notification for draft-ietf-sacm- > > use-cases-05.txt > > > > Hi, > > > > Using actor concerns me. > > I find it important to understand whether some content needs to be > > parsed by a human (with our wonderful ability to parse), or a computer > > application (which is bound by a set of rules, and has great difficulty > > when the content is not consistent with the rules). > > > > Around 2003, the operators made it clear that CLIs were difficult to > > work with, because queries would return information in variable formats. > > While humans might be able to parse the output that might change from > > vendor to vendor, model to model, and release to release, tools had > > significant difficulty due to the lack of standardization. Operators > > could try to deal with the lack of standardization by writing expect > > scripts, but they would need to be updated constantly because what > > worked for one release of a product might not be the same in the next > > release. > > Humans can parse variable syntax, such as the natural language content > > of syslog, but applications can have a hard time. > > > > I think is very important to know whether we are designing something for > > human consumption or for computer consumption. > > "Actor" doesn't provide enough differentiation to know how to design our > > solutions. > > > > David Harrington > > dbharrington@comcast.net > > +1-603-828-1401 > > > > > -----Original Message----- > > > From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Waltermire, > > > David A. > > > Sent: Wednesday, December 04, 2013 8:54 PM > > > To: Adam Montville; Henk Birkholz; sacm@ietf.org > > > Subject: Re: [sacm] FW: New Version Notification for > > > draft-ietf-sacm-use- cases-05.txt > > > > > > Comments inline. > > > > > > > -----Original Message----- > > > > From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Adam > > > > Montville > > > > Sent: Wednesday, December 04, 2013 8:38 PM > > > > To: Henk Birkholz; sacm@ietf.org > > > > Subject: Re: [sacm] FW: New Version Notification for > > draft-ietf-sacm-use- > > > > cases-05.txt > > > > > > > > Something I've found helpful in the past is to abstract a bit > > > > further > > from > > > > "user", "operator", "application" and simply reference all of them > > > > at > > once > > > > with the term "actor". > > > > > > Are we ok with the change to using actor? The current usage of "user", > > > "operator", "application" (specifically the last two) was suggested a > > while > > > back to align with IETF terminology. Does use of "actor" to reference > > > all > > three > > > concepts raise any concerns? > > > > > > > I also believe that listing *potential* acquisition methods is > > > > useful in > > at least > > > > the following way: Including a multitude of acquisition methods > > > > clearly > > > signals > > > > our intent of finding information where it already exists, while not > > > > necessarily precluding our ability to *get* information when > > > > information does not exist. > > > > > > Adam, would you or Henk provide some example acquisition methods for > > > discussion? > > > > > > > Finally, I, too, like the notion of a work-flow scenario. I don't > > > > want > > to be > > > the > > > > one drawing a process diagram in an RFC, though. ;-) > > > > > > How would this differ from the workflow scenario text in section 2? > > > > > > Are you suggesting representing this text in a visual form? If so, > > > would anyone like to make a contribution of some ascii art? > > > > > > > awm > > > > ________________________________________ > > > > From: sacm [sacm-bounces@ietf.org] on behalf of Henk Birkholz > > > > [henk.birkholz@sit.fraunhofer.de] > > > > Sent: Friday, November 22, 2013 3:27 AM > > > > To: sacm@ietf.org > > > > Subject: Re: [sacm] FW: New Version Notification for > > draft-ietf-sacm-use- > > > > cases-05.txt > > > > > > > > Regarding the first two question in section 2: > > > > > > > > 1.) Security automation today often supports the user/operator, I > > think. > > > > There are cases a security-process can be fully automated, of > > > > course, > > and in > > > > order to manage the sheer amount of security related system events > > > > automation is essential, but it seems to me that the complexity and > > > > heterogeneity of root-causes (that might trigger the work-flow) make > > > > the inclusion of a user/operator necessary. > > > > > > > > 2.) To include acquisition methods can provide an intuitive insight > > about the > > > > scope and intend of the endpoint posture assessment domain, I think. > > > > On one hand, that might bloat the use-case document a bit (and maybe > > > renders > > > > the title "sacm use cases" too specific?). On the other hand, I like > > > > the inclusion of a work-flow scenario and I think it is a good place > > > > to > > highlight > > > > acquisition methods. > > > > > > > > - Henk > > > > > > > > On 11/21/2013 12:27 AM, Waltermire, David A. wrote: > > > > > I just posted an updated use case draft based on the editorial > > sessions > > > > during the IETF 88 meeting in Vancouver, BC, Canada. My thanks to > > > > all > > that > > > > provided input. > > > > > > > > > > I used the word version that we edited as a starting point. Here > > > > > is > > what I > > > > did: > > > > > > > > > > - I worked through the use cases we planned to remove and made > > > > > sure > > > to > > > > merge in any concepts that would be lost. If you submitted a > > > > previous > > use > > > > case that was removed, please double check that I didn't miss > > anything. > > > > > - I broke up "Endpoint Identification and Assessment" into 3 > > > > > distinct > > and > > > > somewhat separable use cases: "Endpoint Identification and > > > > Assessment Planning", "Endpoint Posture Attribute Value Collection", > > > > "Posture Evaluation". Please let me know what you think about this > > change. > > > > > - Addressed some aspects of the discussion thread based on the > > > > > working > > > > session changes. Please provide any suggested edits for aspects that > > > > I > > > might > > > > have missed or got wrong. > > > > > > > > > > The rest of the changes can be found in the draft's change log. > > > > > > > > > > If possible, I'd like to get to a fairly stable place with this > > > > > draft > > in the next > > > > revision or two to allow for progress to be made on the > > > > requirements. In addition to the embedded questions in the document, > > > > I'd like to focus on > > > the > > > > following questions: > > > > > > > > > > Is the draft approachable for a newcomer to the effort? Do you see > > > > > the > > > > updated use case structure as an improvement? > > > > > Does this draft paint a complete enough picture? Are we missing > > > > > any > > > > important concepts? > > > > > Is there anything you can't live with? > > > > > > > > > > I hope to release at least one or two more updates to this draft > > within the > > > > next few weeks before the holidays catch up on us. I know everyone > > > > is busy; timely comments are appreciated to allow for a quick > > > > turnaround on the next revision. > > > > > > > > > > Thanks, > > > > > Dave > > > > > > > > > > -----Original Message----- > > > > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > > > > Sent: Wednesday, November 20, 2013 5:58 PM > > > > > To: Waltermire, David A.; David Harrington > > > > > Subject: New Version Notification for > > > > > draft-ietf-sacm-use-cases-05.txt > > > > > > > > > > > > > > > A new version of I-D, draft-ietf-sacm-use-cases-05.txt has been > > > > successfully submitted by David Waltermire and posted to the IETF > > > > repository. > > > > > > > > > > Filename: draft-ietf-sacm-use-cases > > > > > Revision: 05 > > > > > Title: Endpoint Security Posture Assessment - > > Enterprise Use > > > Cases > > > > > Creation date: 2013-11-20 > > > > > Group: sacm > > > > > Number of pages: 24 > > > > > URL: > > http://www.ietf.org/internet-drafts/draft-ietf-sacm-use- > > > cases- > > > > 05.txt > > > > > Status: > > http://datatracker.ietf.org/doc/draft-ietf-sacm-use-cases > > > > > Htmlized: > > http://tools.ietf.org/html/draft-ietf-sacm-use-cases-05 > > > > > Diff: > > http://www.ietf.org/rfcdiff?url2=draft-ietf-sacm-use-cases-05 > > > > > > > > > > Abstract: > > > > > This memo documents a sampling of use cases for securely > > aggregating > > > > > configuration and operational data and evaluating that data to > > > > > determine an organization's security posture. From these > > operational > > > > > use cases, we can derive common functional capabilities and > > > > > requirements to guide development of vendor-neutral, > > interoperable > > > > > standards for aggregating and evaluating data relevant to > > security > > > > > posture. > > > > > > > > > > > > > > > > > > > > > > > > > Please note that it may take a couple of minutes from the time of > > > > submission until the htmlized version and diff are available at > > tools.ietf.org. > > > > > > > > > > The IETF Secretariat > > > > > > > > > > _______________________________________________ > > > > > sacm mailing list > > > > > sacm@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/sacm > > > > > > > > > > > > > > > > > > > > > ... > > > > > > > > . . . > > > > _______________________________________________ > > > > sacm mailing list > > > > sacm@ietf.org > > > > https://www.ietf.org/mailman/listinfo/sacm > > > _______________________________________________ > > > sacm mailing list > > > sacm@ietf.org > > > https://www.ietf.org/mailman/listinfo/sacm > > > > _______________________________________________ > > sacm mailing list > > sacm@ietf.org > > https://www.ietf.org/mailman/listinfo/sacm > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > > --047d7bdc131e6ebfbd04eccaa4cd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

My two cents - End Us= er, Operator, and Administrator are quite distinct
roles of actors= in standards from many SDOs - they have inherently
distinct defau= lt privileges - using these common role terms consistently
would make SACM use cases more accessible to non-participants in=
the SACM WG.

BTW - there are a few other roles of act= ors that should probably be
used in SACM use cases, e.g., App= lication - although tthat's a slippery
slope, because normal applications (browsers, email readers, etc= .)
have very different privileges and responsibilities from s= ecurity-specific
applications (MDM agents, anti-virus scanner= s, etc.).

Cheers,
- Ira


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



On Thu, Dec 5, 2013 at 9:12 AM, Michael = Hammer <michael.hammer@yaanatech.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"> Actor connotes human to me.

What would be wrong with using client or server if asymmetric, or user agen= t
if peering?
With adjectives to differentiate types.

Mike


-----Original Message-----
From: sacm [mailto:sacm-bounces@ie= tf.org] On Behalf Of Romascanu, Dan (Dan)
Sent: Thursday, December 05, 2013 4:52 AM
To: David Harrington; 'Waltermire, David A.'; 'Adam Montville&#= 39;; 'Henk
Birkholz'; sacm@ietf.org
Subject: Re: [sacm] FW: New Version Notification for
draft-ietf-sacm-use-cases-05.txt

I share DBH's concern. There may be significant differences in workflow= s and
interface requirements between systems (networks, devices) and humans vs. systems (networks, devices) and applications. There may be significant
differences if the humans are operators or end-users. Using one term (say 'actor') for all may create ambiguities. I am not sure that I under= stand the
advantages of the proposed abstraction.

Dan
(speaking as contributor)


> -----Original Message-----
> From: sacm [mailto:sacm-bounc= es@ietf.org] On Behalf Of David Harrington
> Sent: Thursday, December 05, 2013 7:11 AM
> To: 'Waltermire, David A.'; 'Adam Montville'; 'Hen= k Birkholz';
> sacm@ietf.org
> Subject: Re: [sacm] FW: New Version Notification for draft-ietf-sacm-<= br> > use-cases-05.txt
>
> Hi,
>
> Using actor concerns me.
> I find it important to understand whether some content needs to be
> parsed by a human (with our wonderful ability to parse), or a computer=
> application (which is bound by a set of rules, and has great difficult= y
> when the content is not consistent with the rules).
>
> Around 2003, the operators made it clear that CLIs were difficult to > work with, because queries would return information in variable format= s.
> While humans might be able to parse the output that might change from<= br> > vendor to vendor, model to model, and release to release, tools had > significant difficulty due to the lack of standardization. Operators > could try to deal with the lack of standardization by writing expect > scripts, but they would need to be updated constantly because what
> worked for one release of a product might not be the same in the next<= br> > release.
> Humans can parse variable syntax, such as the natural language content=
> of syslog, but applications can have a hard time.
>
> I think is very important to know whether we are designing something f= or
> human consumption or for computer consumption.
> "Actor" doesn't provide enough differentiation to know h= ow to design our
> solutions.
>
> David Harrington
> dbharrington@comcast.net
> +1-603-828-14= 01
>
> > -----Original Message-----
> > From: sacm [mailto:sacm-= bounces@ietf.org] On Behalf Of Waltermire,
> > David A.
> > Sent: Wednesday, December 04, 2013 8:54 PM
> > To: Adam Montville; Henk Birkholz; sacm@ietf.org
> > Subject: Re: [sacm] FW: New Version Notification for
> > draft-ietf-sacm-use- cases-05.txt
> >
> > Comments inline.
> >
> > > -----Original Message-----
> > > From: sacm [mailto:= sacm-bounces@ietf.org] On Behalf Of Adam
> > > Montville
> > > Sent: Wednesday, December 04, 2013 8:38 PM
> > > To: Henk Birkholz; sacm@iet= f.org
> > > Subject: Re: [sacm] FW: New Version Notification for
> draft-ietf-sacm-use-
> > > cases-05.txt
> > >
> > > Something I've found helpful in the past is to abstract = a bit
> > > further
> from
> > > "user", "operator", "application&qu= ot; and simply reference all of them
> > > at
> once
> > > with the term "actor".
> >
> > Are we ok with the change to using actor? The current usage of &q= uot;user",
> > "operator", "application" (specifically the l= ast two) was suggested a
> while
> > back to align with IETF terminology. Does use of "actor"= ; to reference
> > all
> three
> > concepts raise any concerns?
> >
> > > I also believe that listing *potential* acquisition methods = is
> > > useful in
> at least
> > > the following way: Including a multitude of acquisition meth= ods
> > > clearly
> > signals
> > > our intent of finding information where it already exists, w= hile not
> > > necessarily precluding our ability to *get* information when=
> > > information does not exist.
> >
> > Adam, would you or Henk provide some example acquisition methods = for
> > discussion?
> >
> > > Finally, I, too, like the notion of a work-flow scenario. = =A0I don't
> > > want
> to be
> > the
> > > one drawing a process diagram in an RFC, though. ;-)
> >
> > How would this differ from the workflow scenario text in section = 2?
> >
> > Are you suggesting representing this text in a visual form? If so= ,
> > would anyone like to make a contribution of some ascii art?
> >
> > > awm
> > > ________________________________________
> > > From: sacm [sacm-bo= unces@ietf.org] on behalf of Henk Birkholz
> > > [henk.bir= kholz@sit.fraunhofer.de]
> > > Sent: Friday, November 22, 2013 3:27 AM
> > > To: sacm@ietf.org
> > > Subject: Re: [sacm] FW: New Version Notification for
> draft-ietf-sacm-use-
> > > cases-05.txt
> > >
> > > Regarding the first two question in section 2:
> > >
> > > 1.) Security automation today often supports the user/operat= or, I
> think.
> > > There are cases a security-process can be fully automated, o= f
> > > course,
> and in
> > > order to manage the sheer amount of security related system = events
> > > automation is essential, but it seems to me that the complex= ity and
> > > heterogeneity of root-causes (that might trigger the work-fl= ow) make
> > > the inclusion of a user/operator necessary.
> > >
> > > 2.) To include acquisition methods can provide an intuitive = insight
> about the
> > > scope and intend of the endpoint posture assessment domain, = I think.
> > > On one hand, that might bloat the use-case document a bit (a= nd maybe
> > renders
> > > the title "sacm use cases" too specific?). On the = other hand, I like
> > > the inclusion of a work-flow scenario and I think it is a go= od place
> > > to
> highlight
> > > acquisition methods.
> > >
> > > - Henk
> > >
> > > On 11/21/2013 12:27 AM, Waltermire, David A. wrote:
> > > > I just posted an updated use case draft based on the ed= itorial
> sessions
> > > during the IETF 88 meeting in Vancouver, BC, Canada. My than= ks to
> > > all
> that
> > > provided input.
> > > >
> > > > I used the word version that we edited as a starting po= int. Here
> > > > is
> what I
> > > did:
> > > >
> > > > - I worked through the use cases we planned to remove a= nd made
> > > > sure
> > to
> > > merge in any concepts that would be lost. If you submitted a=
> > > previous
> use
> > > case that was removed, please double check that I didn't= miss
> anything.
> > > > - I broke up "Endpoint Identification and Assessme= nt" into 3
> > > > distinct
> and
> > > somewhat separable use cases: "Endpoint Identification = and
> > > Assessment Planning", "Endpoint Posture Attribute = Value Collection",
> > > "Posture Evaluation". Please let me know what you = think about this
> change.
> > > > - Addressed some aspects of the discussion thread based= on the
> > > > working
> > > session changes. Please provide any suggested edits for aspe= cts that
> > > I
> > might
> > > have missed or got wrong.
> > > >
> > > > The rest of the changes can be found in the draft's= change log.
> > > >
> > > > If possible, I'd like to get to a fairly stable pla= ce with this
> > > > draft
> in the next
> > > revision or two to allow for progress to be made on the
> > > requirements. In addition to the embedded questions in the d= ocument,
> > > I'd like to focus on
> > the
> > > following questions:
> > > >
> > > > Is the draft approachable for a newcomer to the effort?= Do you see
> > > > the
> > > updated use case structure as an improvement?
> > > > Does this draft paint a complete enough picture? Are we= missing
> > > > any
> > > important concepts?
> > > > Is there anything you can't live with?
> > > >
> > > > I hope to release at least one or two more updates to t= his draft
> within the
> > > next few weeks before the holidays catch up on us. =A0I know= everyone
> > > is busy; timely comments are appreciated to allow for a quic= k
> > > turnaround on the next revision.
> > > >
> > > > Thanks,
> > > > Dave
> > > >
> > > > -----Original Message-----
> > > > From: inter= net-drafts@ietf.org [mailto:internet-drafts@ietf.org]
> > > > Sent: Wednesday, November 20, 2013 5:58 PM
> > > > To: Waltermire, David A.; David Harrington
> > > > Subject: New Version Notification for
> > > > draft-ietf-sacm-use-cases-05.txt
> > > >
> > > >
> > > > A new version of I-D, draft-ietf-sacm-use-cases-05.txt = has been
> > > successfully submitted by David Waltermire and posted to the= IETF
> > > repository.
> > > >
> > > > Filename: =A0 =A0 =A0draft-ietf-sacm-use-cases
> > > > Revision: =A0 =A0 =A005
> > > > Title: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Endpoint Securit= y Posture Assessment -
> Enterprise Use
> > Cases
> > > > Creation date: =A0 =A0 =A0 =A0 2013-11-20
> > > > Group: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 sacm
> > > > Number of pages: 24
> > > > URL:
> http://www.ietf.org/internet-drafts/draft-ietf-sacm-use-
> > cases-
> > > 05.txt
> > > > Status:
> http://datatracker.ietf.org/doc/draft-ietf-sacm-use-cases=
> > > > Htmlized:
> http://tools.ietf.org/html/draft-ietf-sacm-use-cases-05=
> > > > Diff:
> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sacm-= use-cases-05
> > > >
> > > > Abstract:
> > > > =A0 =A0 This memo documents a sampling of use cases for= securely
> aggregating
> > > > =A0 =A0 configuration and operational data and evaluati= ng that data to
> > > > =A0 =A0 determine an organization's security postur= e. =A0From these
> operational
> > > > =A0 =A0 use cases, we can derive common functional capa= bilities and
> > > > =A0 =A0 requirements to guide development of vendor-neu= tral,
> interoperable
> > > > =A0 =A0 standards for aggregating and evaluating data r= elevant to
> security
> > > > =A0 =A0 posture.
> > > >
> > > >
> > > >
> > > >
> > > > Please note that it may take a couple of minutes from t= he time of
> > > submission until the htmlized version and diff are available= at
> tools.ietf.org= .
> > > >
> > > > The IETF Secretariat
> > > >
> > > > _______________________________________________
> > > > sacm mailing list
> > > > sacm@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/sacm
> > > >
> > >
> > >
> > >
> > > ...
> > >
> > > . . .
> > > _______________________________________________
> > > sacm mailing list
> > > sacm@ietf.org
> > > https://www.ietf.org/mailman/listinfo/sacm
> > _______________________________________________
> > sacm mailing list
> > sacm@ietf.org
> > https://www.ietf.org/mailman/listinfo/sacm
>
> _______________________________________________
> sacm mailing list
> sacm@ietf.org
> https://www.ietf.org/mailman/listinfo/sacm
_______________________________________________
sacm mailing list
sacm@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/sacm

_______________________________________________
sacm mailing list
sacm@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/sacm


--047d7bdc131e6ebfbd04eccaa4cd-- From Adam.Montville@cisecurity.org Thu Dec 5 17:10:58 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FAEF1AE243 for ; Thu, 5 Dec 2013 17:10:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KtU7w-1jEmim for ; Thu, 5 Dec 2013 17:10:54 -0800 (PST) Received: from mail1.bemta8.messagelabs.com (mail1.bemta8.messagelabs.com [216.82.243.201]) by ietfa.amsl.com (Postfix) with ESMTP id 9034D1ADFCB for ; Thu, 5 Dec 2013 17:10:54 -0800 (PST) Received: from [216.82.242.179:47777] by server-9.bemta-8.messagelabs.com id FC/65-27569-A1421A25; Fri, 06 Dec 2013 01:10:50 +0000 X-Env-Sender: Adam.Montville@cisecurity.org X-Msg-Ref: server-7.tower-86.messagelabs.com!1386292249!33489085!2 X-Originating-IP: [69.195.43.86] X-StarScan-Received: X-StarScan-Version: 6.9.16; banners=cisecurity.org,-,- X-VirusChecked: Checked Received: (qmail 1335 invoked from network); 6 Dec 2013 01:10:50 -0000 Received: from mail.msisac.org (HELO mail.msisac.org) (69.195.43.86) by server-7.tower-86.messagelabs.com with AES128-SHA encrypted SMTP; 6 Dec 2013 01:10:50 -0000 Received: from CISEXCHANGE1.msisac.org.local ([fe80::4f0:b68d:e779:38c3]) by CISEXCHANGE2.msisac.org.local ([::1]) with mapi id 14.02.0347.000; Thu, 5 Dec 2013 20:08:44 -0500 From: Adam Montville To: "Romascanu, Dan (Dan)" , David Harrington , "'Waltermire, David A.'" , 'Henk Birkholz' , "sacm@ietf.org" Thread-Topic: [sacm] FW: New Version Notification for draft-ietf-sacm-use-cases-05.txt Thread-Index: AQHO8Z9zdyc3zy8QB0Sf9kxt6avTbppGW043 Date: Fri, 6 Dec 2013 01:08:53 +0000 Message-ID: <05BCCEB107AF88469B9F99783D47C1D6065EFE34@CISEXCHANGE1.msisac.org.local> References: <20131120225753.9031.68753.idtracker@ietfa.amsl.com> , <528F23D0.3080504@sit.fraunhofer.de> <05BCCEB107AF88469B9F99783D47C1D6065E4769@CISEXCHANGE1.msisac.org.local> <025d01cef178$63f56840$2be038c0$@comcast.net>, <9904FB1B0159DA42B0B887B7FA8119CA12952A08@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA12952A08@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.252.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sacm] FW: New Version Notification for draft-ietf-sacm-use-cases-05.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 01:10:58 -0000 I am in agreement with all of the comments made to the suggestion of using= "actor" thus far. The only advantage to using that term is the abstracti= on it provides, which usually lends itself to communicating the generaliti= es of the system for comprehension before getting into the important seman= tic differences between various actor subtypes. If we see no reason for the abstraction, we don't need to use it. And, it= seems that many don't like the idea :-) Adam ________________________________________ From: Romascanu, Dan (Dan) [dromasca@avaya.com] Sent: Thursday, December 05, 2013 3:50 AM To: David Harrington; 'Waltermire, David A.'; Adam Montville; 'Henk Birkho= lz'; sacm@ietf.org Subject: RE: [sacm] FW: New Version Notification for draft-ietf= -sacm-use-cases-05.txt I share DBH's concern. There may be significant differences in workflows a= nd interface requirements between systems (networks, devices) and humans v= s. systems (networks, devices) and applications. There may be significant = differences=20if the humans are operators or end-users. Using one term (sa= y 'actor') for all may create ambiguities. I am not sure that I understand= the advantages of the proposed abstraction. Dan (speaking as contributor) > -----Original Message----- > From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of David Harrington > Sent: Thursday, December 05, 2013 7:11 AM > To: 'Waltermire, David A.'; 'Adam Montville'; 'Henk Birkholz'; > sacm@ietf.org > Subject: Re: [sacm] FW: New Version Notification for draft-ietf-sacm- > use-cases-05.txt > > Hi, > > Using actor concerns me. > I find it important to understand whether some content needs to be > parsed by a human (with our wonderful ability to parse), or a computer > application (which is bound by a set of rules, and has great difficulty > when the content is not consistent with the rules). > > Around 2003, the operators made it clear that CLIs were difficult to > work with, because queries would return information in variable formats.= > While humans might be able to parse the output that might change from > vendor to vendor, model to model, and release to release, tools had > significant difficulty due to the lack of standardization. Operators > could try to deal with the lack of standardization by writing expect > scripts, but they would need to be updated constantly because what > worked for one release of a product might not be the same in the next > release. > Humans can parse variable syntax, such as the natural language content > of syslog, but applications can have a hard time. > > I think is very important to know whether we are designing something for= > human consumption or for computer consumption. > "Actor" doesn't provide enough differentiation to know how to design our= > solutions. > > David Harrington > dbharrington@comcast.net > +1-603-828-1401 > > > -----Original Message----- > > From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Waltermire, > > David A. > > Sent: Wednesday, December 04, 2013 8:54 PM > > To: Adam Montville; Henk Birkholz; sacm@ietf.org >=20> Subject: Re: [sacm] FW: New Version Notification for > > draft-ietf-sacm-use- cases-05.txt > > > > Comments inline. > > > > > -----Original Message----- > > > From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Adam > > > Montville > > > Sent: Wednesday, December 04, 2013 8:38 PM > > > To: Henk Birkholz; sacm@ietf.org > > > Subject: Re: [sacm] FW: New Version Notification for > draft-ietf-sacm-use- > > > cases-05.txt > > > > > > Something I've found helpful in the past is to abstract a bit > > > further > from > > > "user", "operator", "application" and simply reference all of them > > > at > once > > > with the term "actor". > > > > Are we ok with the change to using actor? The current usage of "user",= > > "operator", "application" (specifically the last two) was suggested a > while > > back to align with IETF terminology. Does use of "actor" to reference > > all > three > > concepts raise any concerns? > > > > > I also believe that listing *potential* acquisition methods is > > > useful in > at least > > > the following way: Including a multitude of acquisition methods > > > clearly > > signals > > > our intent of finding information where it already exists, while not= > > > necessarily precluding our ability to *get* information when > > > information does not exist. > > > > Adam, would you or Henk provide some example acquisition methods for > > discussion? > > > > > Finally, I, too, like the notion of a work-flow scenario. I don't > > > want > to be > > the > > > one drawing a process diagram in an RFC, though. ;-) > > > > How would this differ from the workflow scenario text in section 2? > > > > Are you suggesting representing this text in a visual form? If so, > > would anyone like to make a contribution of some ascii art? > > > > > awm > > > ________________________________________ > > > From: sacm [sacm-bounces@ietf.org] on behalf of Henk Birkholz > > > [henk.birkholz@sit.fraunhofer.de] > > > Sent: Friday, November 22, 2013 3:27 AM > > > To: sacm@ietf.org > > > Subject: Re: [sacm] FW: New Version Notification for > draft-ietf-sacm-use- > > > cases-05.txt > > > > > > Regarding the first two question in section 2: > > > > > > 1.) Security automation today often supports the user/operator, I > think. > > > There are cases a security-process can be fully automated, of > > > course, > and in > > > order to manage the sheer amount of security related system events > > > automation is essential, but it seems to me that the complexity and > > > heterogeneity of root-causes (that might trigger the work-flow) make= > > > the inclusion of a user/operator necessary. > > > > > > 2.) To include acquisition methods can provide an intuitive insight > about the > > > scope and intend of the endpoint posture assessment domain, I think.= > > > On one hand, that might bloat the use-case document a bit (and maybe= > > renders > > > the title "sacm use cases" too specific?). On the other hand, I like= > > > the inclusion of a work-flow scenario and I think it is a good place= > > > to > highlight > > > acquisition methods. >=20> > > > > - Henk > > > > > > On 11/21/2013 12:27 AM, Waltermire, David A. wrote: > > > > I just posted an updated use case draft based on the editorial > sessions > > > during the IETF 88 meeting in Vancouver, BC, Canada. My thanks to > > > all > that > > > provided input. > > > > > > > > I used the word version that we edited as a starting point. Here > > > > is > what I > > > did: > > > > > > > > - I worked through the use cases we planned to remove and made > > > > sure > > to > > > merge in any concepts that would be lost. If you submitted a > > > previous > use > > > case that was removed, please double check that I didn't miss > anything. > > > > - I broke up "Endpoint Identification and Assessment" into 3 > > > > distinct > and > > > somewhat separable use cases: "Endpoint Identification and > > > Assessment Planning", "Endpoint Posture Attribute Value Collection",= > > > "Posture Evaluation". Please let me know what you think about this > change. > > > > - Addressed some aspects of the discussion thread based on the > > > > working > > > session changes. Please provide any suggested edits for aspects that= > > > I > > might > > > have missed or got wrong. > > > > > > > > The rest of the changes can be found in the draft's change log. > > > > > > > > If possible, I'd like to get to a fairly stable place with this > > > > draft > in the next > > > revision or two to allow for progress to be made on the > > > requirements. In addition to the embedded questions in the document,= > > > I'd like to focus on > > the > > > following questions: > > > > > > > > Is the draft approachable for a newcomer to the effort? Do you see= > > > > the > > > updated use case structure as an improvement? > > > > Does this draft paint a complete enough picture? Are we missing > > > > any > > > important concepts? > > > > Is there anything you can't live with? > > > > > > > > I hope to release at least one or two more updates to this draft > within the > > > next few weeks before the holidays catch up on us. I know everyone > > > is busy; timely comments are appreciated to allow for a quick > > > turnaround on the next revision. > > > > > > > > Thanks, > > > > Dave > > > > > > > > -----Original Message----- > > > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > > > Sent: Wednesday, November 20, 2013 5:58 PM > > > > To: Waltermire, David A.; David Harrington > > > > Subject: New Version Notification for > > > > draft-ietf-sacm-use-cases-05.txt > > > > > > > > > > > > A new version of I-D, draft-ietf-sacm-use-cases-05.txt has been > > > successfully submitted by David Waltermire and posted to the IETF > > > repository. > > > > > > > > Filename: draft-ietf-sacm-use-cases > > > > Revision: 05 > > > > Title: Endpoint Security Posture Assessment - > Enterprise Use > > Cases > > > > Creation date: 2013-11-20 > > > > Group: sacm > > > > Number of pages: 24 > > > > URL: > http://www.ietf.org/internet-drafts/draft-ietf-sacm-use- > > cases- > > > 05.txt > > > > Status: > http://datatracker.ietf.org/doc/draft-ietf-sacm-use-cases > > > > Htmlized: > http://tools.ietf.org/html/draft-ietf-sacm-use-cases-05 > > > > Diff: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sacm-use-cases-05 > > > > > > > > Abstract: > > > > This memo documents a sampling of use cases for securely > aggregating > > > > configuration and operational data and evaluating that data to= > > > > determine an organization's security posture. From these > operational > > > > use cases, we can derive common functional capabilities and > > > > requirements to guide development of vendor-neutral, > interoperable > > > > standards for aggregating and evaluating data relevant to > security > > > > posture. > > > > > > > > > > > > > > > > > > > > Please note that it may take a couple of minutes from the time of > > > submission until the htmlized version and diff are available at > tools.ietf.org. > > > > > > > > The IETF Secretariat > > > > > > > > _______________________________________________ > > > > sacm mailing list > > > > sacm@ietf.org > > > > https://www.ietf.org/mailman/listinfo/sacm > > > > > > > > > > > > > > > > ... > > > > > > . . . > > > _______________________________________________ > > > sacm mailing list > > > sacm@ietf.org > > > https://www.ietf.org/mailman/listinfo/sacm > > _______________________________________________ > > sacm mailing list > > sacm@ietf.org > > https://www.ietf.org/mailman/listinfo/sacm > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm ... . . . From Adam.Montville@cisecurity.org Thu Dec 5 17:13:40 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85C741AE1DA for ; Thu, 5 Dec 2013 17:13:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0vhkv2n9BpjZ for ; Thu, 5 Dec 2013 17:13:35 -0800 (PST) Received: from mail1.bemta8.messagelabs.com (mail1.bemta8.messagelabs.com [216.82.243.196]) by ietfa.amsl.com (Postfix) with ESMTP id B80A91AE1D5 for ; Thu, 5 Dec 2013 17:13:34 -0800 (PST) Received: from [216.82.241.211:44113] by server-4.bemta-8.messagelabs.com id 76/5D-21664-BB421A25; Fri, 06 Dec 2013 01:13:31 +0000 X-Env-Sender: Adam.Montville@cisecurity.org X-Msg-Ref: server-16.tower-85.messagelabs.com!1386292409!25082332!2 X-Originating-IP: [69.195.43.86] X-StarScan-Received: X-StarScan-Version: 6.9.16; banners=cisecurity.org,-,- X-VirusChecked: Checked Received: (qmail 5704 invoked from network); 6 Dec 2013 01:13:30 -0000 Received: from mail.msisac.org (HELO mail.msisac.org) (69.195.43.86) by server-16.tower-85.messagelabs.com with AES128-SHA encrypted SMTP; 6 Dec 2013 01:13:30 -0000 Received: from CISEXCHANGE1.msisac.org.local ([fe80::4f0:b68d:e779:38c3]) by CISEXCHANGE2.msisac.org.local ([::1]) with mapi id 14.02.0347.000; Thu, 5 Dec 2013 20:11:25 -0500 From: Adam Montville To: Ira McDonald , Michael Hammer Thread-Topic: [sacm] FW: New Version Notification for draft-ietf-sacm-use-cases-05.txt Thread-Index: AQHO8ckAYv7q29frk02Os/NZSI49BppGW+RI Date: Fri, 6 Dec 2013 01:11:33 +0000 Message-ID: <05BCCEB107AF88469B9F99783D47C1D6065EFE47@CISEXCHANGE1.msisac.org.local> References: <20131120225753.9031.68753.idtracker@ietfa.amsl.com> <528F23D0.3080504@sit.fraunhofer.de> <05BCCEB107AF88469B9F99783D47C1D6065E4769@CISEXCHANGE1.msisac.org.local> <025d01cef178$63f56840$2be038c0$@comcast.net> <9904FB1B0159DA42B0B887B7FA8119CA12952A08@AZ-FFEXMB04.global.avaya.com> <00C069FD01E0324C9FFCADF539701DB3BBF01B8D@sc9-ex2k10mb1.corp.yaanatech.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.252.38] Content-Type: multipart/alternative; boundary="_000_05BCCEB107AF88469B9F99783D47C1D6065EFE47CISEXCHANGE1msi_" MIME-Version: 1.0 Cc: "dromasca@avaya.com" , "henk.birkholz@sit.fraunhofer.de" , "david.waltermire@nist.gov" , "sacm@ietf.org" , "dbharrington@comcast.net" Subject: Re: [sacm] FW: New Version Notification for draft-ietf-sacm-use-cases-05.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 01:13:40 -0000 --_000_05BCCEB107AF88469B9F99783D47C1D6065EFE47CISEXCHANGE1msi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I like this set of terminology. End User, Operator, Administrator, and Ap= plication. Then, Application can potentially have further specification a= s we move forward. For example, Analysis Application, Acquisition Applica= tion, and so on. Whatever we choose, I would prefer to choose terms that we can easily use = consistently. Adam (I'm assuming, but perhaps shouldn't, that when I comment like this it's a= s a contributor) ________________________________ From: Ira McDonald [blueroofmusic@gmail.com] Sent: Thursday, December 05, 2013 8:48 AM To: Michael Hammer Cc: dromasca@avaya.com; dbharrington@comcast.net; david.waltermire@nist.go= v; Adam Montville; henk.birkholz@sit.fraunhofer.de; sacm@ietf.org Subject: Re: [sacm] FW: New Version Notification for draft-ietf-sacm-use-c= ases-05.txt Hi, My two cents - End User, Operator, and Administrator are quite distinct roles of actors in standards from many SDOs - they have inherently distinct default privileges - using these common role terms consistently would make SACM use cases more accessible to non-participants in the SACM WG. BTW - there are a few other roles of actors that should probably be used in SACM use cases, e.g., Application - although tthat's a slippery slope, because normal applications (browsers, email readers, etc.) have very different privileges and responsibilities from security-specific= applications (MDM agents, anti-virus scanners, etc.). Cheers, - Ira Ira McDonald (Musician / Software Architect) Co-Chair - TCG Trusted Mobility Solutions WG Chair - Linux Foundation Open Printing WG Secretary - IEEE-ISTO Printer Working Group Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG IETF Designated Expert - IPP & Printer MIB Blue Roof Music / High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto: blueroofmusic@gmail.com Winter 579 Park Place Saline, MI 48176 734-944-0094 Summer PO Box 221 Grand Marais, MI 49839 906-494-2434 On Thu, Dec 5, 2013 at 9:12 AM,=20Michael Hammer > wrote: Actor connotes human to me. What would be wrong with using client or server if asymmetric, or user age= nt if peering? With adjectives to differentiate types. Mike -----Original Message----- From: sacm [mailto:sacm-bounces@ietf.org] On= Behalf Of Romascanu, Dan (Dan) Sent: Thursday, December 05, 2013 4:52 AM To: David Harrington; 'Waltermire, David A.'; 'Adam Montville'; 'Henk Birkholz'; sacm@ietf.org Subject: Re: [sacm] FW: New Version Notification for draft-ietf-sacm-use-cases-05.txt I share DBH's concern. There may be significant differences in workflows a= nd interface requirements between systems (networks, devices) and humans vs. systems (networks, devices) and applications. There may be significant differences if the humans are operators or end-users. Using one term (say 'actor') for all may create ambiguities. I am not sure that I understand t= he advantages of the proposed abstraction. Dan (speaking as contributor) > -----Original Message----- > From: sacm [mailto:sacm-bounces@ietf.org] = On Behalf Of David Harrington > Sent: Thursday, December 05, 2013 7:11 AM > To: 'Waltermire, David A.'; 'Adam Montville'; 'Henk Birkholz'; > sacm@ietf.org > Subject: Re: [sacm] FW: New Version Notification for draft-ietf-sacm- > use-cases-05.txt > > Hi, > > Using actor concerns me. > I find it important to understand whether some content needs to be > parsed by a human (with our wonderful ability to parse), or a computer > application (which is bound by a set of rules, and has great difficulty > when the content is not consistent with the rules). > > Around 2003, the operators made it clear that CLIs were difficult to > work with, because queries would return information in variable formats.= > While humans might be able to parse the output that might change from > vendor to vendor, model to model, and release to release, tools had > significant difficulty due to the lack of standardization. Operators > could try to deal with the lack of standardization by writing expect > scripts, but they would need to be updated constantly because what > worked for one release of a product might not be the same in the next > release. > Humans can parse variable syntax, such as the natural language content > of syslog, but applications can have a hard time. > > I think is very important to know whether we are designing something for= > human consumption or for computer consumption. > "Actor" doesn't provide enough differentiation to know how to design our= > solutions. > > David Harrington > dbharrington@comcast.net > +1-603-828-1401 > > > -----Original Message----- > > From: sacm [mailto:sacm-bounces@ietf.org= ] On Behalf Of Waltermire, > > David A. > > Sent: Wednesday, December 04, 2013 8:54 PM > > To: Adam Montville; Henk Birkholz; sacm@ietf.org= > > Subject: Re: [sacm] FW: New Version Notification for > > draft-ietf-sacm-use- cases-05.txt > > > > Comments inline. > > > > > -----Original Message----- > > > From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Adam > > > Montville > > > Sent: Wednesday, December 04, 2013 8:38 PM > > > To: Henk Birkholz; sacm@ietf.org > > > Subject: Re: [sacm] FW: New Version Notification for > draft-ietf-sacm-use- > > > cases-05.txt > > > > > > Something I've found helpful in the past is to abstract a bit > > > further > from > > > "user", "operator", "application" and simply reference all of them > > > at > once > > > with the term "actor". > > > > Are we ok with the change to using actor? The current usage of "user",= > > "operator", "application" (specifically the last two) was suggested a > while > > back to align with IETF terminology. Does use of "actor" to reference > > all > three > > concepts raise any concerns? > > > > > I also believe that listing *potential* acquisition methods is > > > useful in > at least > > > the following way: Including a multitude of acquisition methods > > > clearly > > signals > > > our intent of finding information where it already exists, while not= > > > necessarily precluding our ability to *get* information when > > > information does not exist. > > > > Adam, would you or Henk provide some example acquisition methods for > > discussion? > > > > > Finally, I, too, like the notion of a work-flow scenario. I don't > > > want > to be > > the > > > one drawing a process diagram in an RFC, though. ;-) > > > > How would this differ from the workflow scenario text in section 2? > > > > Are you suggesting representing this text in a visual form? If so, > > would anyone like to make a contribution of some ascii art? > > > > > awm > > > ________________________________________ > > > From: sacm [sacm-bounces@ietf.org] on = behalf of Henk Birkholz > > > [henk.birkholz@sit.fraunhofer.de] > > > Sent: Friday, November 22, 2013 3:27 AM > > > To: sacm@ietf.org > > > Subject: Re: [sacm] FW: New Version Notification for > draft-ietf-sacm-use- > > > cases-05.txt > > > > > > Regarding the first two question in section 2: > > > > > > 1.) Security automation today often supports the user/operator, I > think. > > > There are cases a security-process can be fully automated, of > > > course, > and in > > > order to manage the sheer amount of security related system events > > > automation is essential, but it seems to me that the complexity and > > > heterogeneity of root-causes (that might trigger the work-flow) make= > > > the inclusion of a user/operator necessary. > > > > > > 2.) To include acquisition methods can provide an intuitive insight > about the > > > scope and intend of the endpoint posture assessment domain, I think.= > > > On one hand, that might bloat the use-case document a bit (and maybe= > > renders > > > the title "sacm use cases" too specific?). On the other hand, I like= > > > the inclusion of a work-flow scenario and I think it is a good place= > > > to > highlight > > > acquisition methods. > > > > > > - Henk > > > > > > On 11/21/2013 12:27 AM, Waltermire, David A. wrote: > > > > I just posted an updated use case draft based on the editorial > sessions > > > during the IETF 88 meeting in Vancouver, BC, Canada. My thanks to > > > all > that > > > provided input. > > > > > > > > I used the word version that we edited as a starting point. Here > > > > is > what I > > > did: > > > > > > > > - I worked through the use cases we planned to remove and made > > > > sure > > to > > > merge in any concepts that would be lost. If you submitted a > > > previous > use > > > case that was removed, please double check that I didn't miss > anything. > > > > - I broke up "Endpoint Identification and Assessment" into 3 > > > > distinct > and > > > somewhat separable use cases: "Endpoint Identification and > > > Assessment Planning", "Endpoint Posture Attribute Value Collection",= > > > "Posture Evaluation". Please let me know what you think about this > change. > > > > - Addressed some aspects of the discussion thread based on the > > > > working > > > session changes. Please provide any suggested edits for aspects that= > > > I > > might > > > have missed or got wrong. > > > > > > > > The rest of the changes can be found in the draft's change log. > > > > > > > > If possible, I'd like to get to a fairly stable place with this > > > > draft > in the next > > > revision or two to allow for progress to be made on the > > > requirements. In addition to the embedded questions in the document,= > > > I'd like to focus on > > the > > > following questions: > > > > > > > > Is the draft approachable for a newcomer to the effort? Do you see= > > > > the > > > updated use case structure as an improvement? > > > > Does this draft paint a complete enough picture? Are we missing > > > > any > > > important concepts? > > > > Is there anything you can't live with? > > > > > > > > I hope to release at least one or two more updates to this draft > within the > > > next few weeks before the holidays catch up on us. I know everyone > > > is busy; timely comments are appreciated to allow for a quick > > > turnaround on the next revision. > > > > > > > > Thanks, > > > > Dave > > > > > > > > -----Original Message----- > > > > From: internet-drafts@ietf.org [m= ailto:internet-drafts@ietf.org] > > > > Sent: Wednesday, November 20, 2013 5:58 PM > > > > To: Waltermire, David A.; David Harrington > > > > Subject: New Version Notification for > > > > draft-ietf-sacm-use-cases-05.txt > > > > > > > > > > > > A new version of I-D, draft-ietf-sacm-use-cases-05.txt has been > > > successfully submitted by David Waltermire and posted to the IETF > > > repository. > > > > > > > > Filename: draft-ietf-sacm-use-cases > > > > Revision: 05 > > > > Title: Endpoint Security Posture Assessment - > Enterprise Use > > Cases > > > > Creation date: 2013-11-20 > > > > Group: sacm > > > > Number of pages: 24 > > > > URL: > http://www.ietf.org/internet-drafts/draft-ietf-sacm-use- > > cases- > > > 05.txt > > > > Status: > http://datatracker.ietf.org/doc/draft-ietf-sacm-use-cases > > > > Htmlized: > http://tools.ietf.org/html/draft-ietf-sacm-use-cases-05 > > > > Diff: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sacm-use-cases-05 > > > > > > > > Abstract: > > > > This memo documents a sampling of use cases for securely > aggregating > > > > configuration and operational data and evaluating that data to= > > > > determine an organization's security posture. From these > operational > > > > use cases, we can derive common functional capabilities and > > > > requirements to guide development of vendor-neutral, > interoperable > > > > standards for aggregating and evaluating data relevant to > security > > > > posture. > > > > > > > > > > > > > > > > > > > > Please note that it may take a couple of minutes from the time of > > > submission until the htmlized version and diff are available at > tools.ietf.org. > > > > > > > > The IETF Secretariat > > > > > > > > _______________________________________________ > > > > sacm mailing list > > > > sacm@ietf.org > > > > https://www.ietf.org/mailman/listinfo/sacm > > > > > > > > > > > > > > > > ... > > > > > > . . . > > > _______________________________________________ > > > sacm mailing list > > > sacm@ietf.org > > > https://www.ietf.org/mailman/listinfo/sacm > > _______________________________________________ > > sacm mailing list > > sacm@ietf.org > > https://www.ietf.org/mailman/listinfo/sacm > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm ... . . . --_000_05BCCEB107AF88469B9F99783D47C1D6065EFE47CISEXCHANGE1msi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I like this set of terminology.  End User, Operator, Administ= rator, and Application.  Then, Application can potentially have furth= er specification as we move forward.  For example, Analysis Application, Acquisition Application, and so on.  

Whatever we choose, I would prefer to choose terms that we can easily= use consistently. 

Adam

(I'm assuming, but perhaps shouldn't, that when I comment like this i= t's as a contributor)

From: Ira McDonald=20[blueroofmusic@gma= il.com]
Sent: Thursday, December 05, 2013 8:48 AM
To: Michael Hammer
Cc: dromasca@avaya.com; dbharrington@comcast.net; david.waltermire@= nist.gov; Adam Montville; henk.birkholz@sit.fraunhofer.de; sacm@ietf.org Subject: Re: [sacm] FW: New Version Notification for draft-ietf-sac= m-use-cases-05.txt

Hi,

My two cents - End User, Operator, and Administrator are quite distinct
roles of actors in standards from many SDOs - they have inherently
distinct default privileges - using these common role terms consistently
would make SACM use cases more accessible to non-participants in
the SACM WG.

BTW - there are a few other roles of actors that should probably be
used in SACM use cases, e.g., Application - although tthat's a slippe= ry
slope, because normal applications (browsers, email readers, etc.)
have very different privileges and responsibilities from security-spe= cific
applications (MDM agents, anti-virus scanners, etc.).

Cheers,
- Ira


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


On Thu, Dec 5, 2013 at 9:12 AM, Michael Hammer = <mich= ael.hammer@yaanatech.com> wrote:
Actor connotes human to me.

What would be wrong with using client or server if asymmetric, or user age= nt
if peering?
With adjectives to differentiate types.

Mike


-----Original Message-----
From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan)
Sent: Thursday, December 05, 2013 4:52 AM
To: David Harrington; 'Waltermire, David A.'; 'Adam Montville'; 'Henk
Birkholz'; sacm@ietf.or= g
Subject: Re: [sacm] FW: New Version Notification for
draft-ietf-sacm-use-cases-05.txt

I share DBH's concern. There may be significant differences in workflows a= nd
interface requirements between systems (networks, devices) and humans vs.<= br> systems (networks, devices) and applications. There may be significant
= differences if the humans are operators or end-users. Using one term (say<= br> 'actor') for all may create ambiguities. I am not sure that I understand t= he
advantages of the proposed abstraction.

Dan
(speaking as contributor)


> -----Original Message-----
> From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of David Harrington
> Sent: Thursday, December 05, 2013 7:11 AM
> To: 'Waltermire, David A.'; 'Adam Montville'; 'Henk Birkholz';
> sacm@ietf.org<= br> > Subject: Re: [sacm] FW: New Version Notification for draft-ietf-sacm-=
> use-cases-05.txt
>
> Hi,
>
> Using actor concerns me.
> I find it important to understand whether some content needs to be > parsed by a human (with our wonderful ability to parse), or a compute= r
> application (which is bound by a set of rules, and has great difficul= ty
> when the content is not consistent with the rules).
>
> Around 2003, the operators made it clear that CLIs were difficult to<= br> > work with, because queries would return information in variable forma= ts.
> While humans might be able to parse the output that might change from=
> vendor to vendor, model to model, and release to release, tools had > significant difficulty due to the lack of standardization. Operators<= br> > could try to deal with the lack of standardization by writing expect<= br> > scripts, but they would need to be updated constantly because what > worked for one release of a product might not be the same in the next=
> release.
> Humans can parse variable syntax, such as the natural language conten= t
> of syslog, but applications can have a hard time.
>
> I think is very important to know whether we are designing something = for
> human consumption or for computer consumption.
> "Actor" doesn't provide enough differentiation to know how = to design our
> solutions.
>
> David Harrington
> dbharri= ngton@comcast.net
> +1-603-828-1401
>
> > -----Original Message-----
> > From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Waltermire,
> > David A.
> > Sent: Wednesday, December 04, 2013 8:54 PM
> > To: Adam Montville; Henk Birkholz; sacm@ietf.org
> > Subject: Re: [sacm] FW: New Version Notification for
> > draft-ietf-sacm-use- cases-05.txt
> >
> > Comments inline.
> >
> > > -----Original Message-----
> > > From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Adam
> > > Montville
> > > Sent: Wednesday, December 04, 2013 8:38 PM
> > > To: Henk Birkholz; sacm@ietf.org
> > > Subject: Re: [sacm] FW: New Version Notification for
> draft-ietf-sacm-use-
> > > cases-05.txt
> > >
> > > Something I've found helpful in the past is to abstract a b= it
> > > further
> from
> > > "user", "operator", "application&q= uot; and simply reference all of them
> > > at
> once
> > > with the term "actor".
> >
> > Are we ok with the change to using actor? The current usage of &= quot;user",
> > "operator", "application" (specifically the = last two) was suggested a
> while
> > back to align with IETF terminology. Does use of "actor&quo= t; to reference
> > all
> three
> > concepts raise any concerns?
> >
> > > I also believe that listing *potential* acquisition methods= is
> > > useful in
> at least
> > > the following way: Including a multitude of acquisition met= hods
> > > clearly
> > signals
> > > our intent of finding information where it already exists, = while not
> > > necessarily precluding our ability to *get* information whe= n
> > > information does not exist.
> >
> > Adam, would you or Henk provide some example acquisition methods= for
> > discussion?
> >
> > > Finally, I, too, like the notion of a work-flow scenario. &= nbsp;I don't
> > > want
> to be
> > the
> > > one drawing a process diagram in an RFC, though. ;-)
> >
> > How would this differ from the workflow scenario text in section= 2?
> >
> > Are you suggesting representing this text in a visual form? If s= o,
> > would anyone like to make a contribution of some ascii art?
> >
> > > awm
> > > ________________________________________
> > > From: sacm [sacm-bounces@ietf.org] on behalf of Henk Birkholz
> > > [henk.birkholz@sit.fraunhofer.de]
> > > Sent: Friday, November 22, 2013 3:27 AM
> > > To: sacm= @ietf.org
> > > Subject: Re: [sacm] FW: New Version Notification for
> draft-ietf-sacm-use-
> > > cases-05.txt
> > >
> > > Regarding the first two question in section 2:
> > >
> > > 1.) Security automation today often supports the user/opera= tor, I
> think.
> > > There are cases a security-process can be fully automated, = of
> > > course,
> and in
> > > order to manage the sheer amount of security related system= events
> > > automation is essential, but it seems to me that the comple= xity and
> > > heterogeneity of root-causes (that might trigger the work-f= low) make
> > > the inclusion of a user/operator necessary.
> > >
> > > 2.) To include acquisition methods can provide an intuitive= insight
> about the
> > > scope and intend of the endpoint posture assessment domain,= I think.
> > > On one hand, that might bloat the use-case document a bit (= and maybe
> > renders
> > > the title "sacm use cases" too specific?). On the= other hand, I like
> > > the inclusion of a work-flow scenario and I think it is a g= ood place
> > > to
> highlight
> > > acquisition methods.
> > >
> > > - Henk
> > >
> > > On 11/21/2013 12:27 AM, Waltermire, David A. wrote:
> > > > I just posted an updated use case draft based on the e= ditorial
> sessions
> > > during the IETF 88 meeting in Vancouver, BC, Canada. My tha= nks to
> > > all
> that
> > > provided input.
> > > >
> > > > I used the word version that we edited as a starting p= oint. Here
> > > > is
> what I
> > > did:
> > > >
> > > > - I worked through the use cases we planned to remove = and made
> > > > sure
> > to
> > > merge in any concepts that would be lost. If you submitted = a
> > > previous
> use
> > > case that was removed, please double check that I didn't mi= ss
> anything.
> > > > - I broke up "Endpoint Identification and Assessm= ent" into 3
> > > > distinct
> and
> > > somewhat separable use cases: "Endpoint Identification= and
> > > Assessment Planning", "Endpoint Posture Attribute= Value Collection",
> > > "Posture Evaluation". Please let me know what you= think about this
> change.
> > > > - Addressed some aspects of the discussion thread base= d on the
> > > > working
> > > session changes. Please provide any suggested edits for asp= ects that
> > > I
> > might
> > > have missed or got wrong.
> > > >
> > > > The rest of the changes can be found in the draft's ch= ange log.
> > > >
> > > > If possible, I'd like to get to a fairly stable place = with this
> > > > draft
> in the next
> > > revision or two to allow for progress to be made on the
= > > > requirements. In addition to the embedded questions in the = document,
> > > I'd like to focus on
> > the
> > > following questions:
> > > >
> > > > Is the draft approachable for a newcomer to the effort= ? Do you see
> > > > the
> > > updated use case structure as an improvement?
> > > > Does this draft paint a complete enough picture? Are w= e missing
> > > > any
> > > important concepts?
> > > > Is there anything you can't live with?
> > > >
> > > > I hope to release at least one or two more updates to = this draft
> within the
> > > next few weeks before the holidays catch up on us.  I = know everyone
> > > is busy; timely comments are appreciated to allow for a qui= ck
> > > turnaround on the next revision.
> > > >
> > > > Thanks,
> > > > Dave
> > > >
> > > > -----Original Message-----
> > > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
> > > > Sent: Wednesday, November 20, 2013 5:58 PM
>=20> > > To: Waltermire, David A.; David Harrington
> > > > Subject: New Version Notification for
> > > > draft-ietf-sacm-use-cases-05.txt
> > > >
> > > >
> > > > A new version of I-D, draft-ietf-sacm-use-cases-05.txt= has been
> > > successfully submitted by David Waltermire and posted to th= e IETF
> > > repository.
> > > >
> > > > Filename:      draft-ietf-sacm-use-case= s
> > > > Revision:      05
> > > > Title:              = ;   Endpoint Security Posture Assessment -
> Enterprise Use
> > Cases
> > > > Creation date:         2013-11-20<= br> > > > > Group:              = ;   sacm
> > > > Number of pages: 24
> > > > URL:
> http://www.ietf.org/internet-drafts/draft-ietf-sacm-use-
> > cases-
> > > 05.txt
> > > > Status:
> http://datatracker.ietf.org/doc/draft-ietf-sacm-use-cases
> > > > Htmlized:
> http://tools.ietf.org/html/draft-ietf-sacm-use-cases-05
> > > > Diff:
> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sacm-use-cases-05
> > > >
> > > > Abstract:
> > > >     This memo documents a sampling of use ca= ses for securely
> aggregating
> > > >     configuration and operational data and e= valuating that data to
> > > >     determine an organization's security pos= ture.  From these
> operational
> > > >     use cases, we can derive common function= al capabilities and
> > > >     requirements to guide development of ven= dor-neutral,
> interoperable
> > > >     standards for aggregating and evaluating= data relevant to
> security
> > > >     posture.
> > > >
> > > >
> > > >
> > > >
> > > > Please note that it may take a couple of minutes from = the time of
> > > submission until the htmlized version and diff are availabl= e at
> tools.ietf.org.
> > > >
> > > > The IETF Secretariat
> > > >
> > > > _______________________________________________
> > > > sacm mailing list
> > > > sac= m@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/sacm
> > > >
> > >
> > >
> > >
> > > ...
> > >
> > > . . .
> > > _______________________________________________
> > > sacm mailing list
> > > sacm@iet= f.org
> > > https://www.ietf.org/mailman/listinfo/sacm
> > _______________________________________________
> > sacm mailing list
> > sacm@ietf.org=
> > https://www.ietf.org/mailman/listinfo/sacm
>
> _______________________________________________
> sacm mailing list
> sacm@ietf.org<= br> > https://www.ietf.org/mailman/listinfo/sacm
_______________________________________________
sacm mailing list
sacm@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/sacm

_______________________________________________
sacm mailing list
sacm@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/sacm



...

. . .
--_000_05BCCEB107AF88469B9F99783D47C1D6065EFE47CISEXCHANGE1msi_-- From ncamwing@cisco.com Thu Dec 5 22:10:15 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF3451AE2D5 for ; Thu, 5 Dec 2013 22:10:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.502 X-Spam-Level: X-Spam-Status: No, score=-9.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SN_XkLavNwNE for ; Thu, 5 Dec 2013 22:10:12 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) by ietfa.amsl.com (Postfix) with ESMTP id 414071AE2E1 for ; Thu, 5 Dec 2013 22:10:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11065; q=dns/txt; s=iport; t=1386310207; x=1387519807; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=m+IPZ9fu3YMiHqUA9Jk1+d4aYCZwUvME79PTj+/7xQs=; b=fohDE4TKoyRf2Y3PdToL42GBcm6/SKnDKgBfAbYVtlpsM5jvWU/BgoWk 2aVoBi1slOol2lzZjIVueodxpY+URpPWxHdKM/6q4y45ADhP2exAukes7 ++Ti0tdvYXHgg2iPUw0Q+NI2H/ca5hl6mV04GDPJv+kfGzG8pLEq0iBbv I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8FAAhqoVKtJV2Z/2dsb2JhbABVA4MHOE0Gr0GJNIEkFnSCJQEBAQQBAQE3LAgJDgYBCBEEAQEBHgkuCxQIAQgCBAESCRKHVQMPCAW5WgiHHxeOHVMXBguEIgOUMYNjgTCQY4Mpgio X-IronPort-AV: E=Sophos;i="4.93,839,1378857600"; d="scan'208";a="4759974" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-4.cisco.com with ESMTP; 06 Dec 2013 06:09:50 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id rB669o0F006313 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 6 Dec 2013 06:09:50 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.231]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0123.003; Fri, 6 Dec 2013 00:09:49 -0600 From: "Nancy Cam-Winget (ncamwing)" To: "Romascanu, Dan (Dan)" , David Harrington , "'Waltermire, David A.'" , "'Adam Montville'" , "'Henk Birkholz'" , "sacm@ietf.org" Thread-Topic: [sacm] FW: New Version Notification for draft-ietf-sacm-use-cases-05.txt Thread-Index: AQHO8knEYv7q29frk02Os/NZSI49Bg== Date: Fri, 6 Dec 2013 06:09:49 +0000 Message-ID: In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA12952A08@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.21.81.35] Content-Type: text/plain; charset="us-ascii" Content-ID: <3FC6559A91A999488B0380401677D3BA@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sacm] FW: New Version Notification for draft-ietf-sacm-use-cases-05.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 06:10:16 -0000 I will also echo these concerns; to Dan's points the workflow, interface as well as timing requirements will be influenced by the differentiation of human vs. systems vs. applications (as well as the distinctive roles they play). Thanks Nancy. On 12/5/13 1:52 AM, "Romascanu, Dan (Dan)" wrote: >I share DBH's concern. There may be significant differences in workflows >and interface requirements between systems (networks, devices) and humans >vs. systems (networks, devices) and applications. There may be >significant differences if the humans are operators or end-users. Using >one term (say 'actor') for all may create ambiguities. I am not sure that >I understand the advantages of the proposed abstraction. > >Dan=20 >(speaking as contributor) > > >> -----Original Message----- >> From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of David Harrington >> Sent: Thursday, December 05, 2013 7:11 AM >> To: 'Waltermire, David A.'; 'Adam Montville'; 'Henk Birkholz'; >> sacm@ietf.org >> Subject: Re: [sacm] FW: New Version Notification for draft-ietf-sacm- >> use-cases-05.txt >>=20 >> Hi, >>=20 >> Using actor concerns me. >> I find it important to understand whether some content needs to be >> parsed by a human (with our wonderful ability to parse), or a computer >> application (which is bound by a set of rules, and has great difficulty >> when the content is not consistent with the rules). >>=20 >> Around 2003, the operators made it clear that CLIs were difficult to >> work with, because queries would return information in variable formats. >> While humans might be able to parse the output that might change from >> vendor to vendor, model to model, and release to release, tools had >> significant difficulty due to the lack of standardization. Operators >> could try to deal with the lack of standardization by writing expect >> scripts, but they would need to be updated constantly because what >> worked for one release of a product might not be the same in the next >> release. >> Humans can parse variable syntax, such as the natural language content >> of syslog, but applications can have a hard time. >>=20 >> I think is very important to know whether we are designing something for >> human consumption or for computer consumption. >> "Actor" doesn't provide enough differentiation to know how to design our >> solutions. >>=20 >> David Harrington >> dbharrington@comcast.net >> +1-603-828-1401 >>=20 >> > -----Original Message----- >> > From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Waltermire, >> > David A. >> > Sent: Wednesday, December 04, 2013 8:54 PM >> > To: Adam Montville; Henk Birkholz; sacm@ietf.org >> > Subject: Re: [sacm] FW: New Version Notification for >> > draft-ietf-sacm-use- cases-05.txt >> > >> > Comments inline. >> > >> > > -----Original Message----- >> > > From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Adam >> > > Montville >> > > Sent: Wednesday, December 04, 2013 8:38 PM >> > > To: Henk Birkholz; sacm@ietf.org >> > > Subject: Re: [sacm] FW: New Version Notification for >> draft-ietf-sacm-use- >> > > cases-05.txt >> > > >> > > Something I've found helpful in the past is to abstract a bit >> > > further >> from >> > > "user", "operator", "application" and simply reference all of them >> > > at >> once >> > > with the term "actor". >> > >> > Are we ok with the change to using actor? The current usage of "user", >> > "operator", "application" (specifically the last two) was suggested a >> while >> > back to align with IETF terminology. Does use of "actor" to reference >> > all >> three >> > concepts raise any concerns? >> > >> > > I also believe that listing *potential* acquisition methods is >> > > useful in >> at least >> > > the following way: Including a multitude of acquisition methods >> > > clearly >> > signals >> > > our intent of finding information where it already exists, while not >> > > necessarily precluding our ability to *get* information when >> > > information does not exist. >> > >> > Adam, would you or Henk provide some example acquisition methods for >> > discussion? >> > >> > > Finally, I, too, like the notion of a work-flow scenario. I don't >> > > want >> to be >> > the >> > > one drawing a process diagram in an RFC, though. ;-) >> > >> > How would this differ from the workflow scenario text in section 2? >> > >> > Are you suggesting representing this text in a visual form? If so, >> > would anyone like to make a contribution of some ascii art? >> > >> > > awm >> > > ________________________________________ >> > > From: sacm [sacm-bounces@ietf.org] on behalf of Henk Birkholz >> > > [henk.birkholz@sit.fraunhofer.de] >> > > Sent: Friday, November 22, 2013 3:27 AM >> > > To: sacm@ietf.org >> > > Subject: Re: [sacm] FW: New Version Notification for >> draft-ietf-sacm-use- >> > > cases-05.txt >> > > >> > > Regarding the first two question in section 2: >> > > >> > > 1.) Security automation today often supports the user/operator, I >> think. >> > > There are cases a security-process can be fully automated, of >> > > course, >> and in >> > > order to manage the sheer amount of security related system events >> > > automation is essential, but it seems to me that the complexity and >> > > heterogeneity of root-causes (that might trigger the work-flow) make >> > > the inclusion of a user/operator necessary. >> > > >> > > 2.) To include acquisition methods can provide an intuitive insight >> about the >> > > scope and intend of the endpoint posture assessment domain, I think. >> > > On one hand, that might bloat the use-case document a bit (and maybe >> > renders >> > > the title "sacm use cases" too specific?). On the other hand, I like >> > > the inclusion of a work-flow scenario and I think it is a good place >> > > to >> highlight >> > > acquisition methods. >> > > >> > > - Henk >> > > >> > > On 11/21/2013 12:27 AM, Waltermire, David A. wrote: >> > > > I just posted an updated use case draft based on the editorial >> sessions >> > > during the IETF 88 meeting in Vancouver, BC, Canada. My thanks to >> > > all >> that >> > > provided input. >> > > > >> > > > I used the word version that we edited as a starting point. Here >> > > > is >> what I >> > > did: >> > > > >> > > > - I worked through the use cases we planned to remove and made >> > > > sure >> > to >> > > merge in any concepts that would be lost. If you submitted a >> > > previous >> use >> > > case that was removed, please double check that I didn't miss >> anything. >> > > > - I broke up "Endpoint Identification and Assessment" into 3 >> > > > distinct >> and >> > > somewhat separable use cases: "Endpoint Identification and >> > > Assessment Planning", "Endpoint Posture Attribute Value Collection", >> > > "Posture Evaluation". Please let me know what you think about this >> change. >> > > > - Addressed some aspects of the discussion thread based on the >> > > > working >> > > session changes. Please provide any suggested edits for aspects that >> > > I >> > might >> > > have missed or got wrong. >> > > > >> > > > The rest of the changes can be found in the draft's change log. >> > > > >> > > > If possible, I'd like to get to a fairly stable place with this >> > > > draft >> in the next >> > > revision or two to allow for progress to be made on the >> > > requirements. In addition to the embedded questions in the document, >> > > I'd like to focus on >> > the >> > > following questions: >> > > > >> > > > Is the draft approachable for a newcomer to the effort? Do you see >> > > > the >> > > updated use case structure as an improvement? >> > > > Does this draft paint a complete enough picture? Are we missing >> > > > any >> > > important concepts? >> > > > Is there anything you can't live with? >> > > > >> > > > I hope to release at least one or two more updates to this draft >> within the >> > > next few weeks before the holidays catch up on us. I know everyone >> > > is busy; timely comments are appreciated to allow for a quick >> > > turnaround on the next revision. >> > > > >> > > > Thanks, >> > > > Dave >> > > > >> > > > -----Original Message----- >> > > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> > > > Sent: Wednesday, November 20, 2013 5:58 PM >> > > > To: Waltermire, David A.; David Harrington >> > > > Subject: New Version Notification for >> > > > draft-ietf-sacm-use-cases-05.txt >> > > > >> > > > >> > > > A new version of I-D, draft-ietf-sacm-use-cases-05.txt has been >> > > successfully submitted by David Waltermire and posted to the IETF >> > > repository. >> > > > >> > > > Filename: draft-ietf-sacm-use-cases >> > > > Revision: 05 >> > > > Title: Endpoint Security Posture Assessment - >> Enterprise Use >> > Cases >> > > > Creation date: 2013-11-20 >> > > > Group: sacm >> > > > Number of pages: 24 >> > > > URL: >> http://www.ietf.org/internet-drafts/draft-ietf-sacm-use- >> > cases- >> > > 05.txt >> > > > Status: >> http://datatracker.ietf.org/doc/draft-ietf-sacm-use-cases >> > > > Htmlized: >> http://tools.ietf.org/html/draft-ietf-sacm-use-cases-05 >> > > > Diff: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sacm-use-cases-05 >> > > > >> > > > Abstract: >> > > > This memo documents a sampling of use cases for securely >> aggregating >> > > > configuration and operational data and evaluating that data to >> > > > determine an organization's security posture. From these >> operational >> > > > use cases, we can derive common functional capabilities and >> > > > requirements to guide development of vendor-neutral, >> interoperable >> > > > standards for aggregating and evaluating data relevant to >> security >> > > > posture. >> > > > >> > > > >> > > > >> > > > >> > > > Please note that it may take a couple of minutes from the time of >> > > submission until the htmlized version and diff are available at >> tools.ietf.org. >> > > > >> > > > The IETF Secretariat >> > > > >> > > > _______________________________________________ >> > > > sacm mailing list >> > > > sacm@ietf.org >> > > > https://www.ietf.org/mailman/listinfo/sacm >> > > > >> > > >> > > >> > > >> > > ... >> > > >> > > . . . >> > > _______________________________________________ >> > > sacm mailing list >> > > sacm@ietf.org >> > > https://www.ietf.org/mailman/listinfo/sacm >> > _______________________________________________ >> > sacm mailing list >> > sacm@ietf.org >> > https://www.ietf.org/mailman/listinfo/sacm >>=20 >> _______________________________________________ >> sacm mailing list >> sacm@ietf.org >> https://www.ietf.org/mailman/listinfo/sacm >_______________________________________________ >sacm mailing list >sacm@ietf.org >https://www.ietf.org/mailman/listinfo/sacm From dromasca@avaya.com Sun Dec 8 05:44:21 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CEFD1ADF90 for ; Sun, 8 Dec 2013 05:44:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E1wMys1Gx-8j for ; Sun, 8 Dec 2013 05:44:16 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id AAC821ADF4F for ; Sun, 8 Dec 2013 05:44:14 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: At0JADF3pFLGmAcV/2dsb2JhbABWA4JDIyE4TQakFII7iQ1jiFGBFxZ0giUBAQEBAgEBAQEPCBM5BQMJAgwEAgEIDQQEAQEBChYBBgchBgsUCAEIAgQBDQUIARIHh04DCQYBBwWmbJJGCAWGZxeMfYEwAREBHw8QAgYFAQQGAQYDCIMPgRMDlDGBdwGDG4U8hW6FOYMpgXE5 X-IronPort-AV: E=Sophos;i="4.93,851,1378872000"; d="scan'208,217";a="34651926" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by de307622-de-outbound.net.avaya.com with ESMTP; 08 Dec 2013 08:43:41 -0500 Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 08 Dec 2013 08:36:13 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC02.global.avaya.com ([135.64.58.12]) with mapi id 14.03.0146.000; Sun, 8 Dec 2013 14:43:39 +0100 From: "Romascanu, Dan (Dan)" To: Adam Montville , Ira McDonald , Michael Hammer Thread-Topic: [sacm] FW: New Version Notification for draft-ietf-sacm-use-cases-05.txt Thread-Index: AQHO8clHKhAEAY0Gtk696TobEwT6x5pGS92AgAQHQQA= Date: Sun, 8 Dec 2013 13:43:38 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA129DBB1D@AZ-FFEXMB04.global.avaya.com> References: <20131120225753.9031.68753.idtracker@ietfa.amsl.com> <528F23D0.3080504@sit.fraunhofer.de> <05BCCEB107AF88469B9F99783D47C1D6065E4769@CISEXCHANGE1.msisac.org.local> <025d01cef178$63f56840$2be038c0$@comcast.net> <9904FB1B0159DA42B0B887B7FA8119CA12952A08@AZ-FFEXMB04.global.avaya.com> <00C069FD01E0324C9FFCADF539701DB3BBF01B8D@sc9-ex2k10mb1.corp.yaanatech.com>, <05BCCEB107AF88469B9F99783D47C1D6065EFE47@CISEXCHANGE1.msisac.org.local> In-Reply-To: <05BCCEB107AF88469B9F99783D47C1D6065EFE47@CISEXCHANGE1.msisac.org.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA129DBB1DAZFFEXMB04globa_" MIME-Version: 1.0 Cc: "dbharrington@comcast.net" , "david.waltermire@nist.gov" , "sacm@ietf.org" , "henk.birkholz@sit.fraunhofer.de" Subject: Re: [sacm] FW: New Version Notification for draft-ietf-sacm-use-cases-05.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Dec 2013 13:44:21 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA129DBB1DAZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 Dan Speaking as contributor - better to say it clearly if there are reasons to = wonder From: Adam Montville [mailto:Adam.Montville@cisecurity.org] Sent: Friday, December 06, 2013 3:12 AM To: Ira McDonald; Michael Hammer Cc: Romascanu, Dan (Dan); dbharrington@comcast.net; david.waltermire@nist.g= ov; henk.birkholz@sit.fraunhofer.de; sacm@ietf.org Subject: RE: [sacm] FW: New Version Notification for draft-ietf-sacm-use-ca= ses-05.txt I like this set of terminology. End User, Operator, Administrator, and App= lication. Then, Application can potentially have further specification as = we move forward. For example, Analysis Application, Acquisition Applicatio= n, and so on. Whatever we choose, I would prefer to choose terms that we can easily use c= onsistently. Adam (I'm assuming, but perhaps shouldn't, that when I comment like this it's as= a contributor) ________________________________ From: Ira McDonald [blueroofmusic@gmail.com] Sent: Thursday, December 05, 2013 8:48 AM To: Michael Hammer Cc: dromasca@avaya.com; dbharrington@comcast.net= ; david.waltermire@nist.gov; Adam Montville; henk.birkholz@sit.fraunhofer.de; sacm@ietf.org Subject: Re: [sacm] FW: New Version Notification for draft-ietf-sacm-use-ca= ses-05.txt Hi, My two cents - End User, Operator, and Administrator are quite distinct roles of actors in standards from many SDOs - they have inherently distinct default privileges - using these common role terms consistently would make SACM use cases more accessible to non-participants in the SACM WG. BTW - there are a few other roles of actors that should probably be used in SACM use cases, e.g., Application - although tthat's a slippery slope, because normal applications (browsers, email readers, etc.) have very different privileges and responsibilities from security-specific applications (MDM agents, anti-virus scanners, etc.). Cheers, - Ira Ira McDonald (Musician / Software Architect) Co-Chair - TCG Trusted Mobility Solutions WG Chair - Linux Foundation Open Printing WG Secretary - IEEE-ISTO Printer Working Group Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG IETF Designated Expert - IPP & Printer MIB Blue Roof Music / High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto: blueroofmusic@gmail.com Winter 579 Park Place Saline, MI 48176 734-944-0094 Summer PO Box 221 Grand Marais, MI 49839 906-494-2434 On Thu, Dec 5, 2013 at 9:12 AM, Michael Hammer > wrote: Actor connotes human to me. What would be wrong with using client or server if asymmetric, or user agen= t if peering? With adjectives to differentiate types. Mike -----Original Message----- From: sacm [mailto:sacm-bounces@ietf.org] On = Behalf Of Romascanu, Dan (Dan) Sent: Thursday, December 05, 2013 4:52 AM To: David Harrington; 'Waltermire, David A.'; 'Adam Montville'; 'Henk Birkholz'; sacm@ietf.org Subject: Re: [sacm] FW: New Version Notification for draft-ietf-sacm-use-cases-05.txt I share DBH's concern. There may be significant differences in workflows an= d interface requirements between systems (networks, devices) and humans vs. systems (networks, devices) and applications. There may be significant differences if the humans are operators or end-users. Using one term (say 'actor') for all may create ambiguities. I am not sure that I understand th= e advantages of the proposed abstraction. Dan (speaking as contributor) > -----Original Message----- > From: sacm [mailto:sacm-bounces@ietf.org] O= n Behalf Of David Harrington > Sent: Thursday, December 05, 2013 7:11 AM > To: 'Waltermire, David A.'; 'Adam Montville'; 'Henk Birkholz'; > sacm@ietf.org > Subject: Re: [sacm] FW: New Version Notification for draft-ietf-sacm- > use-cases-05.txt > > Hi, > > Using actor concerns me. > I find it important to understand whether some content needs to be > parsed by a human (with our wonderful ability to parse), or a computer > application (which is bound by a set of rules, and has great difficulty > when the content is not consistent with the rules). > > Around 2003, the operators made it clear that CLIs were difficult to > work with, because queries would return information in variable formats. > While humans might be able to parse the output that might change from > vendor to vendor, model to model, and release to release, tools had > significant difficulty due to the lack of standardization. Operators > could try to deal with the lack of standardization by writing expect > scripts, but they would need to be updated constantly because what > worked for one release of a product might not be the same in the next > release. > Humans can parse variable syntax, such as the natural language content > of syslog, but applications can have a hard time. > > I think is very important to know whether we are designing something for > human consumption or for computer consumption. > "Actor" doesn't provide enough differentiation to know how to design our > solutions. > > David Harrington > dbharrington@comcast.net > +1-603-828-1401 > > > -----Original Message----- > > From: sacm [mailto:sacm-bounces@ietf.org]= On Behalf Of Waltermire, > > David A. > > Sent: Wednesday, December 04, 2013 8:54 PM > > To: Adam Montville; Henk Birkholz; sacm@ietf.org > > Subject: Re: [sacm] FW: New Version Notification for > > draft-ietf-sacm-use- cases-05.txt > > > > Comments inline. > > > > > -----Original Message----- > > > From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Adam > > > Montville > > > Sent: Wednesday, December 04, 2013 8:38 PM > > > To: Henk Birkholz; sacm@ietf.org > > > Subject: Re: [sacm] FW: New Version Notification for > draft-ietf-sacm-use- > > > cases-05.txt > > > > > > Something I've found helpful in the past is to abstract a bit > > > further > from > > > "user", "operator", "application" and simply reference all of them > > > at > once > > > with the term "actor". > > > > Are we ok with the change to using actor? The current usage of "user", > > "operator", "application" (specifically the last two) was suggested a > while > > back to align with IETF terminology. Does use of "actor" to reference > > all > three > > concepts raise any concerns? > > > > > I also believe that listing *potential* acquisition methods is > > > useful in > at least > > > the following way: Including a multitude of acquisition methods > > > clearly > > signals > > > our intent of finding information where it already exists, while not > > > necessarily precluding our ability to *get* information when > > > information does not exist. > > > > Adam, would you or Henk provide some example acquisition methods for > > discussion? > > > > > Finally, I, too, like the notion of a work-flow scenario. I don't > > > want > to be > > the > > > one drawing a process diagram in an RFC, though. ;-) > > > > How would this differ from the workflow scenario text in section 2? > > > > Are you suggesting representing this text in a visual form? If so, > > would anyone like to make a contribution of some ascii art? > > > > > awm > > > ________________________________________ > > > From: sacm [sacm-bounces@ietf.org] on b= ehalf of Henk Birkholz > > > [henk.birkholz@sit.fraunhofer.de] > > > Sent: Friday, November 22, 2013 3:27 AM > > > To: sacm@ietf.org > > > Subject: Re: [sacm] FW: New Version Notification for > draft-ietf-sacm-use- > > > cases-05.txt > > > > > > Regarding the first two question in section 2: > > > > > > 1.) Security automation today often supports the user/operator, I > think. > > > There are cases a security-process can be fully automated, of > > > course, > and in > > > order to manage the sheer amount of security related system events > > > automation is essential, but it seems to me that the complexity and > > > heterogeneity of root-causes (that might trigger the work-flow) make > > > the inclusion of a user/operator necessary. > > > > > > 2.) To include acquisition methods can provide an intuitive insight > about the > > > scope and intend of the endpoint posture assessment domain, I think. > > > On one hand, that might bloat the use-case document a bit (and maybe > > renders > > > the title "sacm use cases" too specific?). On the other hand, I like > > > the inclusion of a work-flow scenario and I think it is a good place > > > to > highlight > > > acquisition methods. > > > > > > - Henk > > > > > > On 11/21/2013 12:27 AM, Waltermire, David A. wrote: > > > > I just posted an updated use case draft based on the editorial > sessions > > > during the IETF 88 meeting in Vancouver, BC, Canada. My thanks to > > > all > that > > > provided input. > > > > > > > > I used the word version that we edited as a starting point. Here > > > > is > what I > > > did: > > > > > > > > - I worked through the use cases we planned to remove and made > > > > sure > > to > > > merge in any concepts that would be lost. If you submitted a > > > previous > use > > > case that was removed, please double check that I didn't miss > anything. > > > > - I broke up "Endpoint Identification and Assessment" into 3 > > > > distinct > and > > > somewhat separable use cases: "Endpoint Identification and > > > Assessment Planning", "Endpoint Posture Attribute Value Collection", > > > "Posture Evaluation". Please let me know what you think about this > change. > > > > - Addressed some aspects of the discussion thread based on the > > > > working > > > session changes. Please provide any suggested edits for aspects that > > > I > > might > > > have missed or got wrong. > > > > > > > > The rest of the changes can be found in the draft's change log. > > > > > > > > If possible, I'd like to get to a fairly stable place with this > > > > draft > in the next > > > revision or two to allow for progress to be made on the > > > requirements. In addition to the embedded questions in the document, > > > I'd like to focus on > > the > > > following questions: > > > > > > > > Is the draft approachable for a newcomer to the effort? Do you see > > > > the > > > updated use case structure as an improvement? > > > > Does this draft paint a complete enough picture? Are we missing > > > > any > > > important concepts? > > > > Is there anything you can't live with? > > > > > > > > I hope to release at least one or two more updates to this draft > within the > > > next few weeks before the holidays catch up on us. I know everyone > > > is busy; timely comments are appreciated to allow for a quick > > > turnaround on the next revision. > > > > > > > > Thanks, > > > > Dave > > > > > > > > -----Original Message----- > > > > From: internet-drafts@ietf.org [ma= ilto:internet-drafts@ietf.org] > > > > Sent: Wednesday, November 20, 2013 5:58 PM > > > > To: Waltermire, David A.; David Harrington > > > > Subject: New Version Notification for > > > > draft-ietf-sacm-use-cases-05.txt > > > > > > > > > > > > A new version of I-D, draft-ietf-sacm-use-cases-05.txt has been > > > successfully submitted by David Waltermire and posted to the IETF > > > repository. > > > > > > > > Filename: draft-ietf-sacm-use-cases > > > > Revision: 05 > > > > Title: Endpoint Security Posture Assessment - > Enterprise Use > > Cases > > > > Creation date: 2013-11-20 > > > > Group: sacm > > > > Number of pages: 24 > > > > URL: > http://www.ietf.org/internet-drafts/draft-ietf-sacm-use- > > cases- > > > 05.txt > > > > Status: > http://datatracker.ietf.org/doc/draft-ietf-sacm-use-cases > > > > Htmlized: > http://tools.ietf.org/html/draft-ietf-sacm-use-cases-05 > > > > Diff: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sacm-use-cases-05 > > > > > > > > Abstract: > > > > This memo documents a sampling of use cases for securely > aggregating > > > > configuration and operational data and evaluating that data to > > > > determine an organization's security posture. From these > operational > > > > use cases, we can derive common functional capabilities and > > > > requirements to guide development of vendor-neutral, > interoperable > > > > standards for aggregating and evaluating data relevant to > security > > > > posture. > > > > > > > > > > > > > > > > > > > > Please note that it may take a couple of minutes from the time of > > > submission until the htmlized version and diff are available at > tools.ietf.org. > > > > > > > > The IETF Secretariat > > > > > > > > _______________________________________________ > > > > sacm mailing list > > > > sacm@ietf.org > > > > https://www.ietf.org/mailman/listinfo/sacm > > > > > > > > > > > > > > > > ... > > > > > > . . . > > > _______________________________________________ > > > sacm mailing list > > > sacm@ietf.org > > > https://www.ietf.org/mailman/listinfo/sacm > > _______________________________________________ > > sacm mailing list > > sacm@ietf.org > > https://www.ietf.org/mailman/listinfo/sacm > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm ... This message and attachments may contain confidential information. If it ap= pears that this message was sent to you by mistake, any retention, dissemin= ation, distribution or copying of this message and attachments is strictly = prohibited. Please notify the sender immediately and permanently delete the= message and any attachments. . . . --_000_9904FB1B0159DA42B0B887B7FA8119CA129DBB1DAZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1<= /p>

 <= /p>

Dan

 <= /p>

Speaking as contributor &= #8211; better to say it clearly if there are reasons to wonder

 <= /p>

 <= /p>

From: Adam Mon= tville [mailto:Adam.Montville@cisecurity.org]
Sent: Friday, December 06, 2013 3:12 AM
To: Ira McDonald; Michael Hammer
Cc: Romascanu, Dan (Dan); dbharrington@comcast.net; david.waltermire= @nist.gov; henk.birkholz@sit.fraunhofer.de; sacm@ietf.org
Subject: RE: [sacm] FW: New Version Notification for draft-ietf-sacm= -use-cases-05.txt

 

I like this set of terminolo= gy.  End User, Operator, Administrator, and Application.  Then, A= pplication can potentially have further specification as we move forward.  For example, Analysis Application, Acquisition Application, and so o= n.  

 

Whatever we choose, I would = prefer to choose terms that we can easily use consistently. 

 

Adam

 

(I'm assuming, but perhaps s= houldn't, that when I comment like this it's as a contributor)

 

From: Ira McDonald [blueroofmusic@= gmail.com]
Sent: Thursday, December 05, 2013 8:48 AM
To: Michael Hammer
Cc: dromasca@avaya.com; dbharrington@comcast.net; = david.waltermire@nist.gov; Adam Montville; henk.birkholz@sit.fraunh= ofer.de; sacm@ietf.org
Subject: Re: [sacm] FW: New Version Notification for draft-ietf-sacm= -use-cases-05.txt

Hi,

My two cents - End User,= Operator, and Administrator are quite distinct

roles of actors in stand= ards from many SDOs - they have inherently

distinct default privile= ges - using these common role terms consistently

would make SACM use cases more accessible to non-participants in
the SACM WG.

BTW - there are a few ot= her roles of actors that should probably be

used in SACM use cases, = e.g., Application - although tthat's a slippery

slope, because normal ap= plications (browsers, email readers, etc.)

have very different priv= ileges and responsibilities from security-specific

applications (MDM agents, anti-virus scanners, etc.).

Cheers,

- Ira


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

 

On Thu, Dec 5, 2013 at 9= :12 AM, Michael Hammer <michael.hammer@yaanatech.com> wrote:

Actor connotes human to = me.

What would be wrong with using client or server if asymmetric, or user agen= t
if peering?
With adjectives to differentiate types.

Mike



-----Original Message-----
From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan)
Sent: Thursday, December 05, 2013 4:52 AM
To: David Harrington; 'Waltermire, David A.'; 'Adam Montville'; 'Henk
Birkholz'; sacm@ietf.org=
Subject: Re: [sacm] FW: New Version Notification for
draft-ietf-sacm-use-cases-05.txt

I share DBH's concern. There may be significant differences in workflows an= d
interface requirements between systems (networks, devices) and humans vs. systems (networks, devices) and applications. There may be significant
differences if the humans are operators or end-users. Using one term (say 'actor') for all may create ambiguities. I am not sure that I understand th= e
advantages of the proposed abstraction.

Dan
(speaking as contributor)


> -----Original Message-----
> From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of David Harrington
> Sent: Thursday, December 05, 2013 7:11 AM
> To: 'Waltermire, David A.'; 'Adam Montville'; 'Henk Birkholz';
> sacm@ietf.org > Subject: Re: [sacm] FW: New Version Notification for draft-ietf-sacm-<= br> > use-cases-05.txt
>
> Hi,
>
> Using actor concerns me.
> I find it important to understand whether some content needs to be
> parsed by a human (with our wonderful ability to parse), or a computer=
> application (which is bound by a set of rules, and has great difficult= y
> when the content is not consistent with the rules).
>
> Around 2003, the operators made it clear that CLIs were difficult to > work with, because queries would return information in variable format= s.
> While humans might be able to parse the output that might change from<= br> > vendor to vendor, model to model, and release to release, tools had > significant difficulty due to the lack of standardization. Operators > could try to deal with the lack of standardization by writing expect > scripts, but they would need to be updated constantly because what
> worked for one release of a product might not be the same in the next<= br> > release.
> Humans can parse variable syntax, such as the natural language content=
> of syslog, but applications can have a hard time.
>
> I think is very important to know whether we are designing something f= or
> human consumption or for computer consumption.
> "Actor" doesn't provide enough differentiation to know how t= o design our
> solutions.
>
> David Harrington
> dbharrin= gton@comcast.net
> +1-603-828-140= 1
>
> > -----Original Message-----
> > From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Waltermire,
> > David A.
> > Sent: Wednesday, December 04, 2013 8:54 PM
> > To: Adam Montville; Henk Birkholz; sacm@ietf.org
> > Subject: Re: [sacm] FW: New Version Notification for
> > draft-ietf-sacm-use- cases-05.txt
> >
> > Comments inline.
> >
> > > -----Original Message-----
> > > From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Adam
> > > Montville
> > > Sent: Wednesday, December 04, 2013 8:38 PM
> > > To: Henk Birkholz; sacm@ietf.org
> > > Subject: Re: [sacm] FW: New Version Notification for
> draft-ietf-sacm-use-
> > > cases-05.txt
> > >
> > > Something I've found helpful in the past is to abstract a bi= t
> > > further
> from
> > > "user", "operator", "application&qu= ot; and simply reference all of them
> > > at
> once
> > > with the term "actor".
> >
> > Are we ok with the change to using actor? The current usage of &q= uot;user",
> > "operator", "application" (specifically the l= ast two) was suggested a
> while
> > back to align with IETF terminology. Does use of "actor"= ; to reference
> > all
> three
> > concepts raise any concerns?
> >
> > > I also believe that listing *potential* acquisition methods = is
> > > useful in
> at least
> > > the following way: Including a multitude of acquisition meth= ods
> > > clearly
> > signals
> > > our intent of finding information where it already exists, w= hile not
> > > necessarily precluding our ability to *get* information when=
> > > information does not exist.
> >
> > Adam, would you or Henk provide some example acquisition methods = for
> > discussion?
> >
> > > Finally, I, too, like the notion of a work-flow scenario. &n= bsp;I don't
> > > want
> to be
> > the
> > > one drawing a process diagram in an RFC, though. ;-)
> >
> > How would this differ from the workflow scenario text in section = 2?
> >
> > Are you suggesting representing this text in a visual form? If so= ,
> > would anyone like to make a contribution of some ascii art?
> >
> > > awm
> > > ________________________________________
> > > From: sacm [sacm-bounces@ietf.org] on behalf of Henk Birkholz
> > > [henk.birkholz@sit.fraunhofer.de]
> > > Sent: Friday, November 22, 2013 3:27 AM
> > > To: sacm@= ietf.org
> > > Subject: Re: [sacm] FW: New Version Notification for
> draft-ietf-sacm-use-
> > > cases-05.txt
> > >
> > > Regarding the first two question in section 2:
> > >
> > > 1.) Security automation today often supports the user/operat= or, I
> think.
> > > There are cases a security-process can be fully automated, o= f
> > > course,
> and in
> > > order to manage the sheer amount of security related system = events
> > > automation is essential, but it seems to me that the complex= ity and
> > > heterogeneity of root-causes (that might trigger the work-fl= ow) make
> > > the inclusion of a user/operator necessary.
> > >
> > > 2.) To include acquisition methods can provide an intuitive = insight
> about the
> > > scope and intend of the endpoint posture assessment domain, = I think.
> > > On one hand, that might bloat the use-case document a bit (a= nd maybe
> > renders
> > > the title "sacm use cases" too specific?). On the = other hand, I like
> > > the inclusion of a work-flow scenario and I think it is a go= od place
> > > to
> highlight
> > > acquisition methods.
> > >
> > > - Henk
> > >
> > > On 11/21/2013 12:27 AM, Waltermire, David A. wrote:
> > > > I just posted an updated use case draft based on the ed= itorial
> sessions
> > > during the IETF 88 meeting in Vancouver, BC, Canada. My than= ks to
> > > all
> that
> > > provided input.
> > > >
> > > > I used the word version that we edited as a starting po= int. Here
> > > > is
> what I
> > > did:
> > > >
> > > > - I worked through the use cases we planned to remove a= nd made
> > > > sure
> > to
> > > merge in any concepts that would be lost. If you submitted a=
> > > previous
> use
> > > case that was removed, please double check that I didn't mis= s
> anything.
> > > > - I broke up "Endpoint Identification and Assessme= nt" into 3
> > > > distinct
> and
> > > somewhat separable use cases: "Endpoint Identification = and
> > > Assessment Planning", "Endpoint Posture Attribute = Value Collection",
> > > "Posture Evaluation". Please let me know what you = think about this
> change.
> > > > - Addressed some aspects of the discussion thread based= on the
> > > > working
> > > session changes. Please provide any suggested edits for aspe= cts that
> > > I
> > might
> > > have missed or got wrong.
> > > >
> > > > The rest of the changes can be found in the draft's cha= nge log.
> > > >
> > > > If possible, I'd like to get to a fairly stable place w= ith this
> > > > draft
> in the next
> > > revision or two to allow for progress to be made on the
> > > requirements. In addition to the embedded questions in the d= ocument,
> > > I'd like to focus on
> > the
> > > following questions:
> > > >
> > > > Is the draft approachable for a newcomer to the effort?= Do you see
> > > > the
> > > updated use case structure as an improvement?
> > > > Does this draft paint a complete enough picture? Are we= missing
> > > > any
> > > important concepts?
> > > > Is there anything you can't live with?
> > > >
> > > > I hope to release at least one or two more updates to t= his draft
> within the
> > > next few weeks before the holidays catch up on us.  I k= now everyone
> > > is busy; timely comments are appreciated to allow for a quic= k
> > > turnaround on the next revision.
> > > >
> > > > Thanks,
> > > > Dave
> > > >
> > > > -----Original Message-----
> > > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
> > > > Sent: Wednesday, November 20, 2013 5:58 PM
> > > > To: Waltermire, David A.; David Harrington
> > > > Subject: New Version Notification for
> > > > draft-ietf-sacm-use-cases-05.txt
> > > >
> > > >
> > > > A new version of I-D, draft-ietf-sacm-use-cases-05.txt = has been
> > > successfully submitted by David Waltermire and posted to the= IETF
> > > repository.
> > > >
> > > > Filename:      draft-ietf-sacm-use-cases=
> > > > Revision:      05
> > > > Title:              =   Endpoint Security Posture Assessment -
> Enterprise Use
> > Cases
> > > > Creation date:         2013-11-20 > > > > Group:              =   sacm
> > > > Number of pages: 24
> > > > URL:
> http://www.ietf.org/internet-drafts/draft-ietf-sacm-use-
> > cases-
> > > 05.txt
> > > > Status:
> http://datatracker.ietf.org/doc/draft-ietf-sacm-use-cases
> > > > Htmlized:
> http://tools.ietf.org/html/draft-ietf-sacm-use-cases-05
> > > > Diff:
> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sacm-use-cases-05
> > > >
> > > > Abstract:
> > > >     This memo documents a sampling of use cas= es for securely
> aggregating
> > > >     configuration and operational data and ev= aluating that data to
> > > >     determine an organization's security post= ure.  From these
> operational
> > > >     use cases, we can derive common functiona= l capabilities and
> > > >     requirements to guide development of vend= or-neutral,
> interoperable
> > > >     standards for aggregating and evaluating = data relevant to
> security
> > > >     posture.
> > > >
> > > >
> > > >
> > > >
> > > > Please note that it may take a couple of minutes from t= he time of
> > > submission until the htmlized version and diff are available= at
> tools.ietf.org= .
> > > >
> > > > The IETF Secretariat
> > > >
> > > > _______________________________________________
> > > > sacm mailing list
> > > > sacm= @ietf.org
> > > > https://www.ietf.org/mailman/listinfo/sacm
> > > >
> > >
> > >
> > >
> > > ...
> > >
> > > . . .
> > > _______________________________________________
> > > sacm mailing list
> > > sacm@ietf= .org
> > > https://www.ietf.org/mailman/listinfo/sacm
> > _______________________________________________
> > sacm mailing list
> > sacm@ietf.org<= /a>
> > https://www.ietf.org/mailman/listinfo/sacm
>
> _______________________________________________
> sacm mailing list
> sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm
_______________________________________________
sacm mailing list
sacm@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/sacm


_______________________________________________
sacm mailing list
sacm@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/sacm

 =


...

This message and attachments may contain confidentia= l information. If it appears that this message was sent to you by mistake, = any retention, dissemination, distribution or copying of this message and a= ttachments is strictly prohibited. Please notify the sender immediately and permanently delete the message an= d any attachments.
. . .

--_000_9904FB1B0159DA42B0B887B7FA8119CA129DBB1DAZFFEXMB04globa_-- From Kent_Landfield@mcafee.com Sun Dec 8 09:19:49 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FC1D1AE011 for ; Sun, 8 Dec 2013 09:19:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U9aahoYse7iX for ; Sun, 8 Dec 2013 09:19:45 -0800 (PST) Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) by ietfa.amsl.com (Postfix) with ESMTP id 977461AE018 for ; Sun, 8 Dec 2013 09:19:44 -0800 (PST) Received: from MIVEXAMER1N1.corp.nai.org (unknown [10.48.48.11]) by MIVWSMAILOUT1.mcafee.com with smtp id 18e7_6c19_214aae26_d62c_4731_b853_4dad2ca795e5; Sun, 08 Dec 2013 11:19:38 -0600 Received: from MIVEXEMEA1N1.corp.nai.org (10.48.48.31) by MIVEXAMER1N1.corp.nai.org (10.48.48.11) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sun, 8 Dec 2013 12:19:39 -0500 Received: from MIVEXAMER1N1.corp.nai.org ([169.254.2.68]) by MIVEXEMEA1N1.corp.nai.org ([169.254.3.231]) with mapi id 14.03.0158.001; Sun, 8 Dec 2013 12:19:39 -0500 From: To: Thread-Topic: [sacm] FW: New Version Notification for draft-ietf-sacm-use-cases-05.txt Thread-Index: AQHO9DmsFv4QotP87kSfkHf2QAYjjQ== Date: Sun, 8 Dec 2013 17:19:38 +0000 Message-ID: References: <20131120225753.9031.68753.idtracker@ietfa.amsl.com> <528F23D0.3080504@sit.fraunhofer.de> <05BCCEB107AF88469B9F99783D47C1D6065E4769@CISEXCHANGE1.msisac.org.local> <025d01cef178$63f56840$2be038c0$@comcast.net> <9904FB1B0159DA42B0B887B7FA8119CA12952A08@AZ-FFEXMB04.global.avaya.com> <00C069FD01E0324C9FFCADF539701DB3BBF01B8D@sc9-ex2k10mb1.corp.yaanatech.com> <05BCCEB107AF88469B9F99783D47C1D6065EFE47@CISEXCHANGE1.msisac.org.local> <9904FB1B0159DA42B0B887B7FA8119CA129DBB1D@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA129DBB1D@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.48.48.242] Content-Type: multipart/alternative; boundary="_000_CECA05EE5A742kentlandfieldmcafeecom_" MIME-Version: 1.0 Subject: Re: [sacm] FW: New Version Notification for draft-ietf-sacm-use-cases-05.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Dec 2013 17:19:49 -0000 --_000_CECA05EE5A742kentlandfieldmcafeecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable +1 I like the terminology Ira and Adam have suggested. Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: , "Dan (Dan)" > Date: Sunday, December 8, 2013 7:43 AM To: Adam Montville >, Ira McDonald >, Michael Hammer > Cc: "dbharrington@comcast.net" >, David Waltermire >, "sacm@ietf.org" >, "henk.birkholz@sit= .fraunhofer.de" > Subject: Re: [sacm] FW: New Version Notification for draft-ietf-sacm-use-ca= ses-05.txt +1 Dan Speaking as contributor =96 better to say it clearly if there are reasons t= o wonder From: Adam Montville [mailto:Adam.Montville@cisecurity.org] Sent: Friday, December 06, 2013 3:12 AM To: Ira McDonald; Michael Hammer Cc: Romascanu, Dan (Dan); dbharrington@comcast.net; david.waltermire@nist.gov; henk= .birkholz@sit.fraunhofer.de; sacm@i= etf.org Subject: RE: [sacm] FW: New Version Notification for draft-ietf-sacm-use-ca= ses-05.txt I like this set of terminology. End User, Operator, Administrator, and App= lication. Then, Application can potentially have further specification as = we move forward. For example, Analysis Application, Acquisition Applicatio= n, and so on. Whatever we choose, I would prefer to choose terms that we can easily use c= onsistently. Adam (I'm assuming, but perhaps shouldn't, that when I comment like this it's as= a contributor) ________________________________ From: Ira McDonald [blueroofmusic@gmail.com= ] Sent: Thursday, December 05, 2013 8:48 AM To: Michael Hammer Cc: dromasca@avaya.com; dbharrington@comcast.net= ; david.waltermire@nist.gov; Adam Montville; henk.birkholz@sit.fraunhofer.de; sacm@ietf.org Subject: Re: [sacm] FW: New Version Notification for draft-ietf-sacm-use-ca= ses-05.txt Hi, My two cents - End User, Operator, and Administrator are quite distinct roles of actors in standards from many SDOs - they have inherently distinct default privileges - using these common role terms consistently would make SACM use cases more accessible to non-participants in the SACM WG. BTW - there are a few other roles of actors that should probably be used in SACM use cases, e.g., Application - although tthat's a slippery slope, because normal applications (browsers, email readers, etc.) have very different privileges and responsibilities from security-specific applications (MDM agents, anti-virus scanners, etc.). Cheers, - Ira Ira McDonald (Musician / Software Architect) Co-Chair - TCG Trusted Mobility Solutions WG Chair - Linux Foundation Open Printing WG Secretary - IEEE-ISTO Printer Working Group Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG IETF Designated Expert - IPP & Printer MIB Blue Roof Music / High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto: blueroofmusic@gmail.com Winter 579 Park Place Saline, MI 48176 734-944-0094 Summer PO Box 221 Grand Marais, MI 49839 906-494-2434 On Thu, Dec 5, 2013 at 9:12 AM, Michael Hammer > wrote: Actor connotes human to me. What would be wrong with using client or server if asymmetric, or user agen= t if peering? With adjectives to differentiate types. Mike -----Original Message----- From: sacm [mailto:sacm-bounces@ietf.org] On = Behalf Of Romascanu, Dan (Dan) Sent: Thursday, December 05, 2013 4:52 AM To: David Harrington; 'Waltermire, David A.'; 'Adam Montville'; 'Henk Birkholz'; sacm@ietf.org Subject: Re: [sacm] FW: New Version Notification for draft-ietf-sacm-use-cases-05.txt I share DBH's concern. There may be significant differences in workflows an= d interface requirements between systems (networks, devices) and humans vs. systems (networks, devices) and applications. There may be significant differences if the humans are operators or end-users. Using one term (say 'actor') for all may create ambiguities. I am not sure that I understand th= e advantages of the proposed abstraction. Dan (speaking as contributor) > -----Original Message----- > From: sacm [mailto:sacm-bounces@ietf.org] O= n Behalf Of David Harrington > Sent: Thursday, December 05, 2013 7:11 AM > To: 'Waltermire, David A.'; 'Adam Montville'; 'Henk Birkholz'; > sacm@ietf.org > Subject: Re: [sacm] FW: New Version Notification for draft-ietf-sacm- > use-cases-05.txt > > Hi, > > Using actor concerns me. > I find it important to understand whether some content needs to be > parsed by a human (with our wonderful ability to parse), or a computer > application (which is bound by a set of rules, and has great difficulty > when the content is not consistent with the rules). > > Around 2003, the operators made it clear that CLIs were difficult to > work with, because queries would return information in variable formats. > While humans might be able to parse the output that might change from > vendor to vendor, model to model, and release to release, tools had > significant difficulty due to the lack of standardization. Operators > could try to deal with the lack of standardization by writing expect > scripts, but they would need to be updated constantly because what > worked for one release of a product might not be the same in the next > release. > Humans can parse variable syntax, such as the natural language content > of syslog, but applications can have a hard time. > > I think is very important to know whether we are designing something for > human consumption or for computer consumption. > "Actor" doesn't provide enough differentiation to know how to design our > solutions. > > David Harrington > dbharrington@comcast.net > +1-603-828-1401 > > > -----Original Message----- > > From: sacm [mailto:sacm-bounces@ietf.org]= On Behalf Of Waltermire, > > David A. > > Sent: Wednesday, December 04, 2013 8:54 PM > > To: Adam Montville; Henk Birkholz; sacm@ietf.org > > Subject: Re: [sacm] FW: New Version Notification for > > draft-ietf-sacm-use- cases-05.txt > > > > Comments inline. > > > > > -----Original Message----- > > > From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Adam > > > Montville > > > Sent: Wednesday, December 04, 2013 8:38 PM > > > To: Henk Birkholz; sacm@ietf.org > > > Subject: Re: [sacm] FW: New Version Notification for > draft-ietf-sacm-use- > > > cases-05.txt > > > > > > Something I've found helpful in the past is to abstract a bit > > > further > from > > > "user", "operator", "application" and simply reference all of them > > > at > once > > > with the term "actor". > > > > Are we ok with the change to using actor? The current usage of "user", > > "operator", "application" (specifically the last two) was suggested a > while > > back to align with IETF terminology. Does use of "actor" to reference > > all > three > > concepts raise any concerns? > > > > > I also believe that listing *potential* acquisition methods is > > > useful in > at least > > > the following way: Including a multitude of acquisition methods > > > clearly > > signals > > > our intent of finding information where it already exists, while not > > > necessarily precluding our ability to *get* information when > > > information does not exist. > > > > Adam, would you or Henk provide some example acquisition methods for > > discussion? > > > > > Finally, I, too, like the notion of a work-flow scenario. I don't > > > want > to be > > the > > > one drawing a process diagram in an RFC, though. ;-) > > > > How would this differ from the workflow scenario text in section 2? > > > > Are you suggesting representing this text in a visual form? If so, > > would anyone like to make a contribution of some ascii art? > > > > > awm > > > ________________________________________ > > > From: sacm [sacm-bounces@ietf.org] on b= ehalf of Henk Birkholz > > > [henk.birkholz@sit.fraunhofer.de] > > > Sent: Friday, November 22, 2013 3:27 AM > > > To: sacm@ietf.org > > > Subject: Re: [sacm] FW: New Version Notification for > draft-ietf-sacm-use- > > > cases-05.txt > > > > > > Regarding the first two question in section 2: > > > > > > 1.) Security automation today often supports the user/operator, I > think. > > > There are cases a security-process can be fully automated, of > > > course, > and in > > > order to manage the sheer amount of security related system events > > > automation is essential, but it seems to me that the complexity and > > > heterogeneity of root-causes (that might trigger the work-flow) make > > > the inclusion of a user/operator necessary. > > > > > > 2.) To include acquisition methods can provide an intuitive insight > about the > > > scope and intend of the endpoint posture assessment domain, I think. > > > On one hand, that might bloat the use-case document a bit (and maybe > > renders > > > the title "sacm use cases" too specific?). On the other hand, I like > > > the inclusion of a work-flow scenario and I think it is a good place > > > to > highlight > > > acquisition methods. > > > > > > - Henk > > > > > > On 11/21/2013 12:27 AM, Waltermire, David A. wrote: > > > > I just posted an updated use case draft based on the editorial > sessions > > > during the IETF 88 meeting in Vancouver, BC, Canada. My thanks to > > > all > that > > > provided input. > > > > > > > > I used the word version that we edited as a starting point. Here > > > > is > what I > > > did: > > > > > > > > - I worked through the use cases we planned to remove and made > > > > sure > > to > > > merge in any concepts that would be lost. If you submitted a > > > previous > use > > > case that was removed, please double check that I didn't miss > anything. > > > > - I broke up "Endpoint Identification and Assessment" into 3 > > > > distinct > and > > > somewhat separable use cases: "Endpoint Identification and > > > Assessment Planning", "Endpoint Posture Attribute Value Collection", > > > "Posture Evaluation". Please let me know what you think about this > change. > > > > - Addressed some aspects of the discussion thread based on the > > > > working > > > session changes. Please provide any suggested edits for aspects that > > > I > > might > > > have missed or got wrong. > > > > > > > > The rest of the changes can be found in the draft's change log. > > > > > > > > If possible, I'd like to get to a fairly stable place with this > > > > draft > in the next > > > revision or two to allow for progress to be made on the > > > requirements. In addition to the embedded questions in the document, > > > I'd like to focus on > > the > > > following questions: > > > > > > > > Is the draft approachable for a newcomer to the effort? Do you see > > > > the > > > updated use case structure as an improvement? > > > > Does this draft paint a complete enough picture? Are we missing > > > > any > > > important concepts? > > > > Is there anything you can't live with? > > > > > > > > I hope to release at least one or two more updates to this draft > within the > > > next few weeks before the holidays catch up on us. I know everyone > > > is busy; timely comments are appreciated to allow for a quick > > > turnaround on the next revision. > > > > > > > > Thanks, > > > > Dave > > > > > > > > -----Original Message----- > > > > From: internet-drafts@ietf.org [ma= ilto:internet-drafts@ietf.org] > > > > Sent: Wednesday, November 20, 2013 5:58 PM > > > > To: Waltermire, David A.; David Harrington > > > > Subject: New Version Notification for > > > > draft-ietf-sacm-use-cases-05.txt > > > > > > > > > > > > A new version of I-D, draft-ietf-sacm-use-cases-05.txt has been > > > successfully submitted by David Waltermire and posted to the IETF > > > repository. > > > > > > > > Filename: draft-ietf-sacm-use-cases > > > > Revision: 05 > > > > Title: Endpoint Security Posture Assessment - > Enterprise Use > > Cases > > > > Creation date: 2013-11-20 > > > > Group: sacm > > > > Number of pages: 24 > > > > URL: > http://www.ietf.org/internet-drafts/draft-ietf-sacm-use- > > cases- > > > 05.txt > > > > Status: > http://datatracker.ietf.org/doc/draft-ietf-sacm-use-cases > > > > Htmlized: > http://tools.ietf.org/html/draft-ietf-sacm-use-cases-05 > > > > Diff: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sacm-use-cases-05 > > > > > > > > Abstract: > > > > This memo documents a sampling of use cases for securely > aggregating > > > > configuration and operational data and evaluating that data to > > > > determine an organization's security posture. From these > operational > > > > use cases, we can derive common functional capabilities and > > > > requirements to guide development of vendor-neutral, > interoperable > > > > standards for aggregating and evaluating data relevant to > security > > > > posture. > > > > > > > > > > > > > > > > > > > > Please note that it may take a couple of minutes from the time of > > > submission until the htmlized version and diff are available at > tools.ietf.org. > > > > > > > > The IETF Secretariat > > > > > > > > _______________________________________________ > > > > sacm mailing list > > > > sacm@ietf.org > > > > https://www.ietf.org/mailman/listinfo/sacm > > > > > > > > > > > > > > > > ... > > > > > > . . . > > > _______________________________________________ > > > sacm mailing list > > > sacm@ietf.org > > > https://www.ietf.org/mailman/listinfo/sacm > > _______________________________________________ > > sacm mailing list > > sacm@ietf.org > > https://www.ietf.org/mailman/listinfo/sacm > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm ... This message and attachments may contain confidential information. If it ap= pears that this message was sent to you by mistake, any retention, dissemin= ation, distribution or copying of this message and attachments is strictly = prohibited. Please notify the sender immediately and permanently delete the= message and any attachments. . . . --_000_CECA05EE5A742kentlandfieldmcafeecom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
+1

I like the terminology Ira and Adam have suggested.

Kent Landfield

McAfee | An Intel Company
Direct: +1.972.963.7096 
Mobile: +1.817.637.8026
Web: www.mcafee.com


+1

 

Dan

 

Speaking as contributor =96 better= to say it clearly if there are reasons to wonder

 

 

From: Adam Montville [mailto:Adam.Montville@cisecurity.org]
Sent: Friday, December 06, 2013 3:12 AM
To: Ira McDonald; Michael Hammer
Cc: Romascanu, Dan (Dan); dbharrington@comcast.net; david.waltermire@nist.gov;= henk.birkholz@sit.fraunhofer.de; sacm@= ietf.org
Subject: RE: [sacm] FW: New Version Notification for draft-ietf-sacm= -use-cases-05.txt

 

I like this set of terminology.  End User= , Operator, Administrator, and Application.  Then, Application can pot= entially have further specification as we move forward.  For example, Analysis Application, Acquisition Application,= and so on.  

 

Whatever we choose, I would prefer to choose t= erms that we can easily use consistently. 

 

Adam

 

(I'm assuming, but perhaps shouldn't, that whe= n I comment like this it's as a contributor)

 

From:= Ira McDonald [blueroo= fmusic@gmail.com]
Sent: Thursday, December 05, 2013 8:48 AM
To: Michael Hammer
Cc: dromasca@avaya.com; dbharrington@comcast.net; = david.waltermire@nist.gov; Adam Montville; henk.birkholz@sit.fraunh= ofer.de; sacm@ietf.org
Subject: Re: [sacm] FW: New Version Notification for draft-ietf-sacm= -use-cases-05.txt

Hi,

My two cents - End User,= Operator, and Administrator are quite distinct

roles of actors in stand= ards from many SDOs - they have inherently

distinct default privile= ges - using these common role terms consistently

would make SACM use cases more accessible to non-participants in
the SACM WG.

BTW - there are a few ot= her roles of actors that should probably be

used in SACM use cases, = e.g., Application - although tthat's a slippery

slope, because normal ap= plications (browsers, email readers, etc.)

have very different priv= ileges and responsibilities from security-specific

applications (MDM agents, anti-virus scanners, etc.).

Cheers,

- Ira


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

 

On Thu, Dec 5, 2013 at 9= :12 AM, Michael Hammer <michael.hammer@yaanatech.com> wrote:

Actor connotes human to = me.

What would be wrong with using client or server if asymmetric, or user agen= t
if peering?
With adjectives to differentiate types.

Mike



-----Original Message-----
From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan)
Sent: Thursday, December 05, 2013 4:52 AM
To: David Harrington; 'Waltermire, David A.'; 'Adam Montville'; 'Henk
Birkholz'; sacm@ietf.org=
Subject: Re: [sacm] FW: New Version Notification for
draft-ietf-sacm-use-cases-05.txt

I share DBH's concern. There may be significant differences in workflows an= d
interface requirements between systems (networks, devices) and humans vs. systems (networks, devices) and applications. There may be significant
differences if the humans are operators or end-users. Using one term (say 'actor') for all may create ambiguities. I am not sure that I understand th= e
advantages of the proposed abstraction.

Dan
(speaking as contributor)


> -----Original Message-----
> From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of David Harrington
> Sent: Thursday, December 05, 2013 7:11 AM
> To: 'Waltermire, David A.'; 'Adam Montville'; 'Henk Birkholz';
> sacm@ietf.org > Subject: Re: [sacm] FW: New Version Notification for draft-ietf-sacm-<= br> > use-cases-05.txt
>
> Hi,
>
> Using actor concerns me.
> I find it important to understand whether some content needs to be
> parsed by a human (with our wonderful ability to parse), or a computer=
> application (which is bound by a set of rules, and has great difficult= y
> when the content is not consistent with the rules).
>
> Around 2003, the operators made it clear that CLIs were difficult to > work with, because queries would return information in variable format= s.
> While humans might be able to parse the output that might change from<= br> > vendor to vendor, model to model, and release to release, tools had > significant difficulty due to the lack of standardization. Operators > could try to deal with the lack of standardization by writing expect > scripts, but they would need to be updated constantly because what
> worked for one release of a product might not be the same in the next<= br> > release.
> Humans can parse variable syntax, such as the natural language content=
> of syslog, but applications can have a hard time.
>
> I think is very important to know whether we are designing something f= or
> human consumption or for computer consumption.
> "Actor" doesn't provide enough differentiation to know how t= o design our
> solutions.
>
> David Harrington
> dbharrin= gton@comcast.net
> +1-603-828-140= 1
>
> > -----Original Message-----
> > From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Waltermire,
> > David A.
> > Sent: Wednesday, December 04, 2013 8:54 PM
> > To: Adam Montville; Henk Birkholz; sacm@ietf.org
> > Subject: Re: [sacm] FW: New Version Notification for
> > draft-ietf-sacm-use- cases-05.txt
> >
> > Comments inline.
> >
> > > -----Original Message-----
> > > From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Adam
> > > Montville
> > > Sent: Wednesday, December 04, 2013 8:38 PM
> > > To: Henk Birkholz; sacm@ietf.org
> > > Subject: Re: [sacm] FW: New Version Notification for
> draft-ietf-sacm-use-
> > > cases-05.txt
> > >
> > > Something I've found helpful in the past is to abstract a bi= t
> > > further
> from
> > > "user", "operator", "application&qu= ot; and simply reference all of them
> > > at
> once
> > > with the term "actor".
> >
> > Are we ok with the change to using actor? The current usage of &q= uot;user",
> > "operator", "application" (specifically the l= ast two) was suggested a
> while
> > back to align with IETF terminology. Does use of "actor"= ; to reference
> > all
> three
> > concepts raise any concerns?
> >
> > > I also believe that listing *potential* acquisition methods = is
> > > useful in
> at least
> > > the following way: Including a multitude of acquisition meth= ods
> > > clearly
> > signals
> > > our intent of finding information where it already exists, w= hile not
> > > necessarily precluding our ability to *get* information when=
> > > information does not exist.
> >
> > Adam, would you or Henk provide some example acquisition methods = for
> > discussion?
> >
> > > Finally, I, too, like the notion of a work-flow scenario. &n= bsp;I don't
> > > want
> to be
> > the
> > > one drawing a process diagram in an RFC, though. ;-)
> >
> > How would this differ from the workflow scenario text in section = 2?
> >
> > Are you suggesting representing this text in a visual form? If so= ,
> > would anyone like to make a contribution of some ascii art?
> >
> > > awm
> > > ________________________________________
> > > From: sacm [sacm-bounces@ietf.org] on behalf of Henk Birkholz
> > > [henk.birkholz@sit.fraunhofer.de]
> > > Sent: Friday, November 22, 2013 3:27 AM
> > > To: sacm@= ietf.org
> > > Subject: Re: [sacm] FW: New Version Notification for
> draft-ietf-sacm-use-
> > > cases-05.txt
> > >
> > > Regarding the first two question in section 2:
> > >
> > > 1.) Security automation today often supports the user/operat= or, I
> think.
> > > There are cases a security-process can be fully automated, o= f
> > > course,
> and in
> > > order to manage the sheer amount of security related system = events
> > > automation is essential, but it seems to me that the complex= ity and
> > > heterogeneity of root-causes (that might trigger the work-fl= ow) make
> > > the inclusion of a user/operator necessary.
> > >
> > > 2.) To include acquisition methods can provide an intuitive = insight
> about the
> > > scope and intend of the endpoint posture assessment domain, = I think.
> > > On one hand, that might bloat the use-case document a bit (a= nd maybe
> > renders
> > > the title "sacm use cases" too specific?). On the = other hand, I like
> > > the inclusion of a work-flow scenario and I think it is a go= od place
> > > to
> highlight
> > > acquisition methods.
> > >
> > > - Henk
> > >
> > > On 11/21/2013 12:27 AM, Waltermire, David A. wrote:
> > > > I just posted an updated use case draft based on the ed= itorial
> sessions
> > > during the IETF 88 meeting in Vancouver, BC, Canada. My than= ks to
> > > all
> that
> > > provided input.
> > > >
> > > > I used the word version that we edited as a starting po= int. Here
> > > > is
> what I
> > > did:
> > > >
> > > > - I worked through the use cases we planned to remove a= nd made
> > > > sure
> > to
> > > merge in any concepts that would be lost. If you submitted a=
> > > previous
> use
> > > case that was removed, please double check that I didn't mis= s
> anything.
> > > > - I broke up "Endpoint Identification and Assessme= nt" into 3
> > > > distinct
> and
> > > somewhat separable use cases: "Endpoint Identification = and
> > > Assessment Planning", "Endpoint Posture Attribute = Value Collection",
> > > "Posture Evaluation". Please let me know what you = think about this
> change.
> > > > - Addressed some aspects of the discussion thread based= on the
> > > > working
> > > session changes. Please provide any suggested edits for aspe= cts that
> > > I
> > might
> > > have missed or got wrong.
> > > >
> > > > The rest of the changes can be found in the draft's cha= nge log.
> > > >
> > > > If possible, I'd like to get to a fairly stable place w= ith this
> > > > draft
> in the next
> > > revision or two to allow for progress to be made on the
> > > requirements. In addition to the embedded questions in the d= ocument,
> > > I'd like to focus on
> > the
> > > following questions:
> > > >
> > > > Is the draft approachable for a newcomer to the effort?= Do you see
> > > > the
> > > updated use case structure as an improvement?
> > > > Does this draft paint a complete enough picture? Are we= missing
> > > > any
> > > important concepts?
> > > > Is there anything you can't live with?
> > > >
> > > > I hope to release at least one or two more updates to t= his draft
> within the
> > > next few weeks before the holidays catch up on us.  I k= now everyone
> > > is busy; timely comments are appreciated to allow for a quic= k
> > > turnaround on the next revision.
> > > >
> > > > Thanks,
> > > > Dave
> > > >
> > > > -----Original Message-----
> > > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
> > > > Sent: Wednesday, November 20, 2013 5:58 PM
> > > > To: Waltermire, David A.; David Harrington
> > > > Subject: New Version Notification for
> > > > draft-ietf-sacm-use-cases-05.txt
> > > >
> > > >
> > > > A new version of I-D, draft-ietf-sacm-use-cases-05.txt = has been
> > > successfully submitted by David Waltermire and posted to the= IETF
> > > repository.
> > > >
> > > > Filename:      draft-ietf-sacm-use-cases=
> > > > Revision:      05
> > > > Title:              =   Endpoint Security Posture Assessment -
> Enterprise Use
> > Cases
> > > > Creation date:         2013-11-20 > > > > Group:              =   sacm
> > > > Number of pages: 24
> > > > URL:
> http://www.ietf.org/internet-drafts/draft-ietf-sacm-use-
> > cases-
> > > 05.txt
> > > > Status:
> http://datatracker.ietf.org/doc/draft-ietf-sacm-use-cases
> > > > Htmlized:
> http://tools.ietf.org/html/draft-ietf-sacm-use-cases-05
> > > > Diff:
> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sacm-use-cases-05
> > > >
> > > > Abstract:
> > > >     This memo documents a sampling of use cas= es for securely
> aggregating
> > > >     configuration and operational data and ev= aluating that data to
> > > >     determine an organization's security post= ure.  From these
> operational
> > > >     use cases, we can derive common functiona= l capabilities and
> > > >     requirements to guide development of vend= or-neutral,
> interoperable
> > > >     standards for aggregating and evaluating = data relevant to
> security
> > > >     posture.
> > > >
> > > >
> > > >
> > > >
> > > > Please note that it may take a couple of minutes from t= he time of
> > > submission until the htmlized version and diff are available= at
> tools.ietf.org= .
> > > >
> > > > The IETF Secretariat
> > > >
> > > > _______________________________________________
> > > > sacm mailing list
> > > > sacm= @ietf.org
> > > > https://www.ietf.org/mailman/listinfo/sacm
> > > >
> > >
> > >
> > >
> > > ...
> > >
> > > . . .
> > > _______________________________________________
> > > sacm mailing list
> > > sacm@ietf= .org
> > > https://www.ietf.org/mailman/listinfo/sacm
> > _______________________________________________
> > sacm mailing list
> > sacm@ietf.org<= /a>
> > https://www.ietf.org/mailman/listinfo/sacm
>
> _______________________________________________
> sacm mailing list
> sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm
_______________________________________________
sacm mailing list
sacm@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/sacm


_______________________________________________
sacm mailing list
sacm@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/sacm

 =


...

This message and attachments may contain confidentia= l information. If it appears that this message was sent to you by mistake, = any retention, dissemination, distribution or copying of this message and a= ttachments is strictly prohibited. Please notify the sender immediately and permanently delete the message an= d any attachments.
. . .

 --_000_CECA05EE5A742kentlandfieldmcafeecom_-- From ietf@rozanak.com Sun Dec 8 12:06:38 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50D741AE034 for ; Sun, 8 Dec 2013 12:06:38 -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_40=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Urth_NEB65WJ for ; Sun, 8 Dec 2013 12:06:36 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 983041AE0D0 for ; Sun, 8 Dec 2013 12:06:26 -0800 (PST) Received: from kopoli (g231251244.adsl.alicedsl.de [92.231.251.244]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0Lhgpl-1VCJ7T1B6P-00msTG; Sun, 08 Dec 2013 15:06:21 -0500 From: "Hosnieh Rafiee" To: "'Moriarty, Kathleen'" , References: <492903078.119554.1385045144290.open-xchange@email.1and1.com> In-Reply-To: Date: Sun, 8 Dec 2013 21:06:14 +0100 Message-ID: <005a01cef450$f601d7c0$e2058740$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQDQm8ptDpq2oiesvF47REoB5KdYBAF3tI/anDulxmA= Content-Language: en-us X-Provags-ID: V02:K0:YOmFUIIb2KlJemzEiIYk7ZjlxOiT7RYbfkJqei2Tp1o p3qDeNHci7Q8IQk5qADMgOowRArzx85ykZfLlid+kNCInCOm8w 8CaPeE6gXj8jtjiVKDHeQY4fyBePB9CH6SS2CU6yulQAX0klL/ fIlv2MoTBItuixETJvxRVHnQWO5DMoMvxlGygETx6nb/9ZRSeL JNBZ74yUITQXInRlx+roNBotSyiFfWOin9LOl0noEwHdAwY75M pp8wRgN+9sddJG/8U+fvL+4HTzbJCxFFRylWSoO94ioDSuVXkS LWACGy7rDHvtyiirFwB+V/IayLNnLJpN3woFEupsmPVQoL/TAX MuNxoeZAqR1lwmvY+y/8= Subject: Re: [sacm] Is latency is important for you? X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Dec 2013 20:06:38 -0000 Hi Kathleen, I guess my question was so ambiguous.=20 >Could you provide a little more background and relevance to the list = members for your request? =20 My question here was about the delay that might cause by network layer. = It might be any reason such as IP address generation, authentication, = etc (any security approach that used in network layer that caused this = delay). This delay can vary from a few seconds to minutes.=20 Since my experience in application layer is as a developer or end user, = I would like to hear the opinion of people who have more experience in = operational level, security, realtime applications, etc in application = area (and welcome them to join to the new mailing list). Are all = services in application layer can be/might be delay tolerance? If so how = many seconds/minutes ?=20 Is it better to avoid delay in network layer (any security approach that = caused this delay, just stop it or if it is because of packet size, = decrease the packet size, etc)? Is it better to consider this in application layer? How? What about realtime applications? What is the best solution to avoid = delay? What are their delay threshold? (if we need to apply security) >I have had the pleasure of meeting Hosnieh at several IETF related = events and she has some active drafts related to secure transport. She = is in the process of starting up a mailing list for discussion on that = topic and I am guessing this request is related to that new mailing = list. >The question as worded below may be tough for this group as their focus = is on security automation. This work will require the exchange of = information over secure protocols, but the group is working through use = cases and requirements at this stage. As you already explained briefly here, the focus of mailing list is = around the topic of security automation. How network layer can be = helpful to provide a means for the application layer with a good = security level. How this can be automated. We might also discuss about = the privacy topic during this automation. How we should also consider = the privacy issue. How we can improve performance in this approach? One = example would be SIP protocol and proxy servers.=20 Is it good to have an authentication library (an interface library) = between application layer and network layer so that the application uses = network layer security as a means of authentication or (also) use this = means of authentication to have a good level of security assurance and = many other topics that might come to our mind during the discussion or = focusing on these areas. Thanks, Smile, Hosnieh From pkampana@cisco.com Sun Dec 8 15:04:21 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E22A31AE0EA for ; Sun, 8 Dec 2013 15:04:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.502 X-Spam-Level: X-Spam-Status: No, score=-9.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QClQwNxx566z for ; Sun, 8 Dec 2013 15:04:20 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id 5A3EA1AE15E for ; Sun, 8 Dec 2013 15:04:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3532; q=dns/txt; s=iport; t=1386543856; x=1387753456; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=Bi1DUrv6jB1Y3Z+nmbxVU209RZMoJEf07i3E6vqhDBk=; b=DSCNMg688MqnN7CUR+d1ZSGo+qKTUgOT7lFDMiiIOIqku3M9ScoJ6Lmd Hcr6e6CbcCLqN6wMslVPSPX6TbcYz1e+l+HpG0OTAmVVCMe9a03CACrOC JmmsAUaEWRFDg3Rbml8Rs3NvjHVQlM+Qn70pa9XEpnPBGtdWCCtdNC2Wd s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFAMT5pFKtJV2a/2dsb2JhbABZgwc4U7kQgRgWdIIlAQEBBAEBATc0BhEEAgEIDgMEAQELFAkHJwsUCQgCBAESCBOHZw3AXxMEjl84BoMagRMDqieDKYIq X-IronPort-AV: E=Sophos;i="4.93,853,1378857600"; d="scan'208";a="5253920" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-8.cisco.com with ESMTP; 08 Dec 2013 23:04:15 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id rB8N4FPV028232 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 8 Dec 2013 23:04:15 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.250]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0123.003; Sun, 8 Dec 2013 17:04:15 -0600 From: "Panos Kampanakis (pkampana)" To: Hosnieh Rafiee , "'Moriarty, Kathleen'" , "sacm@ietf.org" Thread-Topic: [sacm] Is latency is important for you? Thread-Index: AQDQm8ptDpq2oiesvF47REoB5KdYBAF3tI/anDulxmCAADROEA== Date: Sun, 8 Dec 2013 23:04:14 +0000 Message-ID: <1C9F17D1873AFA47A969C4DD98F98A750FA93FA5@xmb-rcd-x10.cisco.com> References: <492903078.119554.1385045144290.open-xchange@email.1and1.com> <005a01cef450$f601d7c0$e2058740$@rozanak.com> In-Reply-To: <005a01cef450$f601d7c0$e2058740$@rozanak.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.214.30] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sacm] Is latency is important for you? X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Dec 2013 23:04:22 -0000 I think delay is a valid concern to think about but it highly depends on t= he usecase.=20 As for "an authentication library (an interface library) between applicatio= n layer and network layer so that the application uses network layer securi= ty as a means of authentication", I am not sure how that would work, as aut= hentication at Layer X is traditionally decoupled from Layer Y security acc= ording to the OSI or TCP/IP models. Rgs, Panos -----Original Message----- From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Hosnieh Rafiee Sent: Sunday, December 08, 2013 3:06 PM To: 'Moriarty, Kathleen'; sacm@ietf.org Subject: Re: [sacm] Is latency is important for you? Hi Kathleen, I guess my question was so ambiguous.=20 >Could you provide a little more background and relevance to the list membe= rs for your request? =20 My question here was about the delay that might cause by network layer. It = might be any reason such as IP address generation, authentication, etc (any= security approach that used in network layer that caused this delay). This= delay can vary from a few seconds to minutes.=20 Since my experience in application layer is as a developer or end user, I w= ould like to hear the opinion of people who have more experience in operati= onal level, security, realtime applications, etc in application area (and w= elcome them to join to the new mailing list). Are all services in applicati= on layer can be/might be delay tolerance? If so how many seconds/minutes ?= =20 Is it better to avoid delay in network layer (any security approach that ca= used this delay, just stop it or if it is because of packet size, decrease = the packet size, etc)? Is it better to consider this in application layer? How? What about realtime applications? What is the best solution to avoid delay?= What are their delay threshold? (if we need to apply security) >I have had the pleasure of meeting Hosnieh at several IETF related events = and she has some active drafts related to secure transport. She is in the = process of starting up a mailing list for discussion on that topic and I am= guessing this request is related to that new mailing list. >The question as worded below may be tough for this group as their focus is= on security automation. This work will require the exchange of informatio= n over secure protocols, but the group is working through use cases and req= uirements at this stage. As you already explained briefly here, the focus of mailing list is around = the topic of security automation. How network layer can be helpful to provi= de a means for the application layer with a good security level. How this c= an be automated. We might also discuss about the privacy topic during this = automation. How we should also consider the privacy issue. How we can impro= ve performance in this approach? One example would be SIP protocol and prox= y servers.=20 Is it good to have an authentication library (an interface library) betwee= n application layer and network layer so that the application uses network = layer security as a means of authentication or (also) use this means of aut= hentication to have a good level of security assurance and many other topic= s that might come to our mind during the discussion or focusing on these ar= eas. Thanks, Smile, Hosnieh _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm From ietf@rozanak.com Sun Dec 8 15:09:51 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75E7E1AE168 for ; Sun, 8 Dec 2013 15:09:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4xj7JqPG4yRx for ; Sun, 8 Dec 2013 15:09:50 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 104D61AE0EA for ; Sun, 8 Dec 2013 15:09:50 -0800 (PST) Received: from kopoli (g231251244.adsl.alicedsl.de [92.231.251.244]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0MF4yZ-1VoMhC1DfX-00FhuQ; Sun, 08 Dec 2013 18:09:45 -0500 From: "Hosnieh Rafiee" To: "'Panos Kampanakis \(pkampana\)'" , "'Moriarty, Kathleen'" , References: <492903078.119554.1385045144290.open-xchange@email.1and1.com> <005a01cef450$f601d7c0$e2058740$@rozanak.com> <1C9F17D1873AFA47A969C4DD98F98A750FA93FA5@xmb-rcd-x10.cisco.com> In-Reply-To: <1C9F17D1873AFA47A969C4DD98F98A750FA93FA5@xmb-rcd-x10.cisco.com> Date: Mon, 9 Dec 2013 00:09:37 +0100 Message-ID: <008701cef46a$950f1f30$bf2d5d90$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQDQm8ptDpq2oiesvF47REoB5KdYBAF3tI/aAi1N1+0B1TnujpwbyzPA Content-Language: en-us X-Provags-ID: V02:K0:aQRiUFj4CIyBcLhcfViidKAMe4DsdXnIx2JaiWpyyU8 zxE01O6FfMPk1wRSwwH7KqDNZd5ww/fiqMzGqGWya7qvZygUCI 0IriZj4DsmdyQT7lAog2CUOn4MOmezsAUI/b2Qly7MyAvRN27W 7J7cHyfmtbd6e5pTJnHh13mdb9HX8rdzDA81mv/W6nKM7wwy8c 0UykPF5fi9jXd0MgnANufMYqaTFtbFy+ebfLODDInCpc9+kFyJ yhVSXwT5mxsJJF087uJZzOJdL8Iiac9f6CVewAsiEF/OIuNxXI XMqg56Cqdf+4X33x0Q5lzgmljEryaXw1vXUXlW0DheYm8upB20 NvOXDlNtbU+CSXwNhdgs= Subject: Re: [sacm] Is latency is important for you? X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Dec 2013 23:09:51 -0000 Hi Panos, > > I think delay is a valid concern to think about but it highly depends on the > usecase. > > As for "an authentication library (an interface library) between application > layer and network layer so that the application uses network layer security as > a means of authentication", I am not sure how that would work, as > authentication at Layer X is traditionally decoupled from Layer Y security > according to the OSI or TCP/IP models. > This is what we actually want to discuss and find out. Of course it is not only the discussion in that mailing list. But this is one of the topic of discussion to find the best solution to avoid delay and provide an automated security in a better way. Thanks, Smile, Hosnieh From david.waltermire@nist.gov Mon Dec 9 12:13:17 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 543951AE0BD for ; Mon, 9 Dec 2013 12:13:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H2MPZfYjiqzc for ; Mon, 9 Dec 2013 12:13:07 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0154.outbound.protection.outlook.com [207.46.163.154]) by ietfa.amsl.com (Postfix) with ESMTP id A1C451AE51B for ; Mon, 9 Dec 2013 12:13:06 -0800 (PST) Received: from BLUPR09MB038.namprd09.prod.outlook.com (10.255.211.144) by BLUPR09MB040.namprd09.prod.outlook.com (10.255.211.154) with Microsoft SMTP Server (TLS) id 15.0.837.10; Mon, 9 Dec 2013 20:12:59 +0000 Received: from BLUPR09MB038.namprd09.prod.outlook.com ([169.254.11.67]) by BLUPR09MB038.namprd09.prod.outlook.com ([169.254.11.67]) with mapi id 15.00.0837.004; Mon, 9 Dec 2013 20:12:59 +0000 From: "Waltermire, David A." To: "sacm@ietf.org" Thread-Topic: [sacm] FW: New Version Notification for draft-ietf-sacm-use-cases-05.txt Thread-Index: AQHO8clDUyfS/hxF3k6G2AaSKzcJd5pGXKGAgAP2ywCAADxZAIABv9Zw Date: Mon, 9 Dec 2013 20:12:58 +0000 Message-ID: <4b451425cbec406d94fa1a82b32fa1ab@BLUPR09MB038.namprd09.prod.outlook.com> References: <20131120225753.9031.68753.idtracker@ietfa.amsl.com> <528F23D0.3080504@sit.fraunhofer.de> <05BCCEB107AF88469B9F99783D47C1D6065E4769@CISEXCHANGE1.msisac.org.local> <025d01cef178$63f56840$2be038c0$@comcast.net> <9904FB1B0159DA42B0B887B7FA8119CA12952A08@AZ-FFEXMB04.global.avaya.com> <00C069FD01E0324C9FFCADF539701DB3BBF01B8D@sc9-ex2k10mb1.corp.yaanatech.com> <05BCCEB107AF88469B9F99783D47C1D6065EFE47@CISEXCHANGE1.msisac.org.local> <9904FB1B0159DA42B0B887B7FA8119CA129DBB1D@AZ-FFEXMB04.global.avaya.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.6.227.119] x-forefront-prvs: 00550ABE1F x-forefront-antispam-report: SFV:NSPM; SFS:(189002)(199002)(76104003)(24454002)(13464003)(54534003)(377424004)(407274004)(164054003)(51704005)(479174003)(377454003)(81686001)(16236675002)(90146001)(56816005)(2656002)(87936001)(76482001)(80976001)(74366001)(85306002)(87266001)(74316001)(14971765001)(19580395003)(19580405001)(81342001)(49866001)(83072002)(85852003)(74876001)(83322001)(81816001)(74662001)(54356001)(59766001)(51856001)(15202345003)(66066001)(4396001)(81542001)(77982001)(80022001)(46102001)(65816001)(79102001)(76576001)(47446002)(19609705001)(15975445006)(54316002)(56776001)(19300405004)(47976001)(50986001)(47736001)(74706001)(19273905006)(16601075003)(53806001)(74502001)(77096001)(33646001)(63696002)(76796001)(69226001)(31966008)(76786001)(24736002)(16351025005)(563064011); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR09MB040; H:BLUPR09MB038.namprd09.prod.outlook.com; CLIP:129.6.227.119; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_4b451425cbec406d94fa1a82b32fa1abBLUPR09MB038namprd09pro_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov Subject: Re: [sacm] FW: New Version Notification for draft-ietf-sacm-use-cases-05.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 20:13:17 -0000 --_000_4b451425cbec406d94fa1a82b32fa1abBLUPR09MB038namprd09pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1. I too like this approach. This has been a good discussion. To direct this dialog towards actionable changes to the use cases draft, is= there specific draft text that should be updated to make the roles and the= ir relevance to a use case or usage scenario more clear? Thanks, Dave From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Kent_Landfield@McAfe= e.com Sent: Sunday, December 08, 2013 12:20 PM To: sacm@ietf.org Subject: Re: [sacm] FW: New Version Notification for draft-ietf-sacm-use-ca= ses-05.txt +1 I like the terminology Ira and Adam have suggested. Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: , "Dan (Dan)" > Date: Sunday, December 8, 2013 7:43 AM To: Adam Montville >, Ira McDonald >, Michael Hammer > Cc: "dbharrington@comcast.net" >, David Waltermire >, "sacm@ietf.org" >, "henk.birkholz@sit= .fraunhofer.de" > Subject: Re: [sacm] FW: New Version Notification for draft-ietf-sacm-use-ca= ses-05.txt +1 Dan Speaking as contributor - better to say it clearly if there are reasons to = wonder From: Adam Montville [mailto:Adam.Montville@cisecurity.org] Sent: Friday, December 06, 2013 3:12 AM To: Ira McDonald; Michael Hammer Cc: Romascanu, Dan (Dan); dbharrington@comcast.net; david.waltermire@nist.gov; henk= .birkholz@sit.fraunhofer.de; sacm@i= etf.org Subject: RE: [sacm] FW: New Version Notification for draft-ietf-sacm-use-ca= ses-05.txt I like this set of terminology. End User, Operator, Administrator, and App= lication. Then, Application can potentially have further specification as = we move forward. For example, Analysis Application, Acquisition Applicatio= n, and so on. Whatever we choose, I would prefer to choose terms that we can easily use c= onsistently. Adam (I'm assuming, but perhaps shouldn't, that when I comment like this it's as= a contributor) ________________________________ From: Ira McDonald [blueroofmusic@gmail.com= ] Sent: Thursday, December 05, 2013 8:48 AM To: Michael Hammer Cc: dromasca@avaya.com; dbharrington@comcast.net= ; david.waltermire@nist.gov; Adam Montville; henk.birkholz@sit.fraunhofer.de; sacm@ietf.org Subject: Re: [sacm] FW: New Version Notification for draft-ietf-sacm-use-ca= ses-05.txt Hi, My two cents - End User, Operator, and Administrator are quite distinct roles of actors in standards from many SDOs - they have inherently distinct default privileges - using these common role terms consistently would make SACM use cases more accessible to non-participants in the SACM WG. BTW - there are a few other roles of actors that should probably be used in SACM use cases, e.g., Application - although tthat's a slippery slope, because normal applications (browsers, email readers, etc.) have very different privileges and responsibilities from security-specific applications (MDM agents, anti-virus scanners, etc.). Cheers, - Ira Ira McDonald (Musician / Software Architect) Co-Chair - TCG Trusted Mobility Solutions WG Chair - Linux Foundation Open Printing WG Secretary - IEEE-ISTO Printer Working Group Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG IETF Designated Expert - IPP & Printer MIB Blue Roof Music / High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto: blueroofmusic@gmail.com Winter 579 Park Place Saline, MI 48176 734-944-0094 Summer PO Box 221 Grand Marais, MI 49839 906-494-2434 On Thu, Dec 5, 2013 at 9:12 AM, Michael Hammer > wrote: Actor connotes human to me. What would be wrong with using client or server if asymmetric, or user agen= t if peering? With adjectives to differentiate types. Mike -----Original Message----- From: sacm [mailto:sacm-bounces@ietf.org] On = Behalf Of Romascanu, Dan (Dan) Sent: Thursday, December 05, 2013 4:52 AM To: David Harrington; 'Waltermire, David A.'; 'Adam Montville'; 'Henk Birkholz'; sacm@ietf.org Subject: Re: [sacm] FW: New Version Notification for draft-ietf-sacm-use-cases-05.txt I share DBH's concern. There may be significant differences in workflows an= d interface requirements between systems (networks, devices) and humans vs. systems (networks, devices) and applications. There may be significant differences if the humans are operators or end-users. Using one term (say 'actor') for all may create ambiguities. I am not sure that I understand th= e advantages of the proposed abstraction. Dan (speaking as contributor) > -----Original Message----- > From: sacm [mailto:sacm-bounces@ietf.org] O= n Behalf Of David Harrington > Sent: Thursday, December 05, 2013 7:11 AM > To: 'Waltermire, David A.'; 'Adam Montville'; 'Henk Birkholz'; > sacm@ietf.org > Subject: Re: [sacm] FW: New Version Notification for draft-ietf-sacm- > use-cases-05.txt > > Hi, > > Using actor concerns me. > I find it important to understand whether some content needs to be > parsed by a human (with our wonderful ability to parse), or a computer > application (which is bound by a set of rules, and has great difficulty > when the content is not consistent with the rules). > > Around 2003, the operators made it clear that CLIs were difficult to > work with, because queries would return information in variable formats. > While humans might be able to parse the output that might change from > vendor to vendor, model to model, and release to release, tools had > significant difficulty due to the lack of standardization. Operators > could try to deal with the lack of standardization by writing expect > scripts, but they would need to be updated constantly because what > worked for one release of a product might not be the same in the next > release. > Humans can parse variable syntax, such as the natural language content > of syslog, but applications can have a hard time. > > I think is very important to know whether we are designing something for > human consumption or for computer consumption. > "Actor" doesn't provide enough differentiation to know how to design our > solutions. > > David Harrington > dbharrington@comcast.net > +1-603-828-1401 > > > -----Original Message----- > > From: sacm [mailto:sacm-bounces@ietf.org]= On Behalf Of Waltermire, > > David A. > > Sent: Wednesday, December 04, 2013 8:54 PM > > To: Adam Montville; Henk Birkholz; sacm@ietf.org > > Subject: Re: [sacm] FW: New Version Notification for > > draft-ietf-sacm-use- cases-05.txt > > > > Comments inline. > > > > > -----Original Message----- > > > From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Adam > > > Montville > > > Sent: Wednesday, December 04, 2013 8:38 PM > > > To: Henk Birkholz; sacm@ietf.org > > > Subject: Re: [sacm] FW: New Version Notification for > draft-ietf-sacm-use- > > > cases-05.txt > > > > > > Something I've found helpful in the past is to abstract a bit > > > further > from > > > "user", "operator", "application" and simply reference all of them > > > at > once > > > with the term "actor". > > > > Are we ok with the change to using actor? The current usage of "user", > > "operator", "application" (specifically the last two) was suggested a > while > > back to align with IETF terminology. Does use of "actor" to reference > > all > three > > concepts raise any concerns? > > > > > I also believe that listing *potential* acquisition methods is > > > useful in > at least > > > the following way: Including a multitude of acquisition methods > > > clearly > > signals > > > our intent of finding information where it already exists, while not > > > necessarily precluding our ability to *get* information when > > > information does not exist. > > > > Adam, would you or Henk provide some example acquisition methods for > > discussion? > > > > > Finally, I, too, like the notion of a work-flow scenario. I don't > > > want > to be > > the > > > one drawing a process diagram in an RFC, though. ;-) > > > > How would this differ from the workflow scenario text in section 2? > > > > Are you suggesting representing this text in a visual form? If so, > > would anyone like to make a contribution of some ascii art? > > > > > awm > > > ________________________________________ > > > From: sacm [sacm-bounces@ietf.org] on b= ehalf of Henk Birkholz > > > [henk.birkholz@sit.fraunhofer.de] > > > Sent: Friday, November 22, 2013 3:27 AM > > > To: sacm@ietf.org > > > Subject: Re: [sacm] FW: New Version Notification for > draft-ietf-sacm-use- > > > cases-05.txt > > > > > > Regarding the first two question in section 2: > > > > > > 1.) Security automation today often supports the user/operator, I > think. > > > There are cases a security-process can be fully automated, of > > > course, > and in > > > order to manage the sheer amount of security related system events > > > automation is essential, but it seems to me that the complexity and > > > heterogeneity of root-causes (that might trigger the work-flow) make > > > the inclusion of a user/operator necessary. > > > > > > 2.) To include acquisition methods can provide an intuitive insight > about the > > > scope and intend of the endpoint posture assessment domain, I think. > > > On one hand, that might bloat the use-case document a bit (and maybe > > renders > > > the title "sacm use cases" too specific?). On the other hand, I like > > > the inclusion of a work-flow scenario and I think it is a good place > > > to > highlight > > > acquisition methods. > > > > > > - Henk > > > > > > On 11/21/2013 12:27 AM, Waltermire, David A. wrote: > > > > I just posted an updated use case draft based on the editorial > sessions > > > during the IETF 88 meeting in Vancouver, BC, Canada. My thanks to > > > all > that > > > provided input. > > > > > > > > I used the word version that we edited as a starting point. Here > > > > is > what I > > > did: > > > > > > > > - I worked through the use cases we planned to remove and made > > > > sure > > to > > > merge in any concepts that would be lost. If you submitted a > > > previous > use > > > case that was removed, please double check that I didn't miss > anything. > > > > - I broke up "Endpoint Identification and Assessment" into 3 > > > > distinct > and > > > somewhat separable use cases: "Endpoint Identification and > > > Assessment Planning", "Endpoint Posture Attribute Value Collection", > > > "Posture Evaluation". Please let me know what you think about this > change. > > > > - Addressed some aspects of the discussion thread based on the > > > > working > > > session changes. Please provide any suggested edits for aspects that > > > I > > might > > > have missed or got wrong. > > > > > > > > The rest of the changes can be found in the draft's change log. > > > > > > > > If possible, I'd like to get to a fairly stable place with this > > > > draft > in the next > > > revision or two to allow for progress to be made on the > > > requirements. In addition to the embedded questions in the document, > > > I'd like to focus on > > the > > > following questions: > > > > > > > > Is the draft approachable for a newcomer to the effort? Do you see > > > > the > > > updated use case structure as an improvement? > > > > Does this draft paint a complete enough picture? Are we missing > > > > any > > > important concepts? > > > > Is there anything you can't live with? > > > > > > > > I hope to release at least one or two more updates to this draft > within the > > > next few weeks before the holidays catch up on us. I know everyone > > > is busy; timely comments are appreciated to allow for a quick > > > turnaround on the next revision. > > > > > > > > Thanks, > > > > Dave > > > > > > > > -----Original Message----- > > > > From: internet-drafts@ietf.org [ma= ilto:internet-drafts@ietf.org] > > > > Sent: Wednesday, November 20, 2013 5:58 PM > > > > To: Waltermire, David A.; David Harrington > > > > Subject: New Version Notification for > > > > draft-ietf-sacm-use-cases-05.txt > > > > > > > > > > > > A new version of I-D, draft-ietf-sacm-use-cases-05.txt has been > > > successfully submitted by David Waltermire and posted to the IETF > > > repository. > > > > > > > > Filename: draft-ietf-sacm-use-cases > > > > Revision: 05 > > > > Title: Endpoint Security Posture Assessment - > Enterprise Use > > Cases > > > > Creation date: 2013-11-20 > > > > Group: sacm > > > > Number of pages: 24 > > > > URL: > http://www.ietf.org/internet-drafts/draft-ietf-sacm-use- > > cases- > > > 05.txt > > > > Status: > http://datatracker.ietf.org/doc/draft-ietf-sacm-use-cases > > > > Htmlized: > http://tools.ietf.org/html/draft-ietf-sacm-use-cases-05 > > > > Diff: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sacm-use-cases-05 > > > > > > > > Abstract: > > > > This memo documents a sampling of use cases for securely > aggregating > > > > configuration and operational data and evaluating that data to > > > > determine an organization's security posture. From these > operational > > > > use cases, we can derive common functional capabilities and > > > > requirements to guide development of vendor-neutral, > interoperable > > > > standards for aggregating and evaluating data relevant to > security > > > > posture. > > > > > > > > > > > > > > > > > > > > Please note that it may take a couple of minutes from the time of > > > submission until the htmlized version and diff are available at > tools.ietf.org. > > > > > > > > The IETF Secretariat > > > > > > > > _______________________________________________ > > > > sacm mailing list > > > > sacm@ietf.org > > > > https://www.ietf.org/mailman/listinfo/sacm > > > > > > > > > > > > > > > > ... > > > > > > . . . > > > _______________________________________________ > > > sacm mailing list > > > sacm@ietf.org > > > https://www.ietf.org/mailman/listinfo/sacm > > _______________________________________________ > > sacm mailing list > > sacm@ietf.org > > https://www.ietf.org/mailman/listinfo/sacm > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm ... This message and attachments may contain confidential information. If it ap= pears that this message was sent to you by mistake, any retention, dissemin= ation, distribution or copying of this message and attachments is strictly = prohibited. Please notify the sender immediately and permanently delete the= message and any attachments. . . . --_000_4b451425cbec406d94fa1a82b32fa1abBLUPR09MB038namprd09pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1. I too like this a= pproach. This has been a good discussion.

 <= /p>

To direct this dialog tow= ards actionable changes to the use cases draft, is there specific draft tex= t that should be updated to make the roles and their relevance to a use case or usage scenario more clear?

 <= /p>

Thanks,=

Dave

 <= /p>

From: sacm [ma= ilto:sacm-bounces@ietf.org] On Behalf Of Kent_Landfield@McAfee.com
Sent: Sunday, December 08, 2013 12:20 PM
To: sacm@ietf.org
Subject: Re: [sacm] FW: New Version Notification for draft-ietf-sacm= -use-cases-05.txt

 

+1=

 =

I like the terminology I= ra and Adam have suggested.

 =

Kent Landfield

McAfee | An Intel Company
Direct: +1.972.963.7096  Mobile: +1.817.637.8026
Web: www.mcafee.com

 =

From: <Romascanu>, "Dan (Dan)"= ; <dromasca@avaya.com>
Date: Sunday, December 8, 2013 7:43 AM
To: Adam Montville <Adam.Montville@cisecurity.org>, Ira McDonald <blueroofmusic@gmail.com>, Michael Hammer= <michael.hammer@yaanate= ch.com>
Cc: "dbharrington@c= omcast.net" <dbharr= ington@comcast.net>, David Waltermire <david.waltermire@nist.gov>, "sacm@ietf.org" <sacm@ietf.org>, "henk.birkholz@sit.fraunhofer.de= " <henk.birk= holz@sit.fraunhofer.de>
Subject: Re: [sacm] FW: New Version Notification for draft-ietf-sacm= -use-cases-05.txt

 =

+1

 

Dan

 

Speaking as contributor &= #8211; better to say it clearly if there are reasons to wonder

 

 

From: Adam Montville [mailto:Adam.Montville@cisecurity.org]
Sent: Friday, December 06, 2013 3:12 AM
To: Ira McDonald; Michael Hammer
Cc: Romascanu, Dan (Dan); dbharrington@comcast.net; david.waltermire@nist.gov;= henk.birkholz@sit.fraunhofer.de; sacm@= ietf.org
Subject: RE: [sacm] FW: New Version Notification for draft-ietf-sacm= -use-cases-05.txt

 =

I like this set of terminolo= gy.  End User, Operator, Administrator, and Application.  Then, A= pplication can potentially have further specification as we move forward.  For example, Analysis Application, Acquisition Application, and so o= n.  

 

Whatever we choose, I would = prefer to choose terms that we can easily use consistently. 

 

Adam

 

(I'm assuming, but perhaps s= houldn't, that when I comment like this it's as a contributor)

 

From: Ira McDonald [blueroofmusic@gmail.com]
Sent: Thursday, December 05, 2013 8:48 AM
To: Michael Hammer
Cc: dromasca@avaya.com; dbharrington@comcast.net; = david.waltermire@nist.gov; Adam Montville; henk.birkholz@sit.fraunh= ofer.de; sacm@ietf.org
Subject: Re: [sacm] FW: New Version Notification for draft-ietf-sacm= -use-cases-05.txt

Hi,

My two cents - End User,= Operator, and Administrator are quite distinct

roles of actors in stand= ards from many SDOs - they have inherently

distinct default privile= ges - using these common role terms consistently

would make SACM use cases more accessible to non-participants in
the SACM WG.

BTW - there are a few ot= her roles of actors that should probably be

used in SACM use cases, = e.g., Application - although tthat's a slippery

slope, because normal ap= plications (browsers, email readers, etc.)

have very different priv= ileges and responsibilities from security-specific

applications (MDM agents, anti-virus scanners, etc.).

Cheers,

- Ira


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

 

On Thu, Dec 5, 2013 at 9= :12 AM, Michael Hammer <michael.hammer@yaanatech.com> wrote:

Actor connotes human to = me.

What would be wrong with using client or server if asymmetric, or user agen= t
if peering?
With adjectives to differentiate types.

Mike



-----Original Message-----
From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan)
Sent: Thursday, December 05, 2013 4:52 AM
To: David Harrington; 'Waltermire, David A.'; 'Adam Montville'; 'Henk
Birkholz'; sacm@ietf.org=
Subject: Re: [sacm] FW: New Version Notification for
draft-ietf-sacm-use-cases-05.txt

I share DBH's concern. There may be significant differences in workflows an= d
interface requirements between systems (networks, devices) and humans vs. systems (networks, devices) and applications. There may be significant
differences if the humans are operators or end-users. Using one term (say 'actor') for all may create ambiguities. I am not sure that I understand th= e
advantages of the proposed abstraction.

Dan
(speaking as contributor)


> -----Original Message-----
> From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of David Harrington
> Sent: Thursday, December 05, 2013 7:11 AM
> To: 'Waltermire, David A.'; 'Adam Montville'; 'Henk Birkholz';
> sacm@ietf.org > Subject: Re: [sacm] FW: New Version Notification for draft-ietf-sacm-<= br> > use-cases-05.txt
>
> Hi,
>
> Using actor concerns me.
> I find it important to understand whether some content needs to be
> parsed by a human (with our wonderful ability to parse), or a computer=
> application (which is bound by a set of rules, and has great difficult= y
> when the content is not consistent with the rules).
>
> Around 2003, the operators made it clear that CLIs were difficult to > work with, because queries would return information in variable format= s.
> While humans might be able to parse the output that might change from<= br> > vendor to vendor, model to model, and release to release, tools had > significant difficulty due to the lack of standardization. Operators > could try to deal with the lack of standardization by writing expect > scripts, but they would need to be updated constantly because what
> worked for one release of a product might not be the same in the next<= br> > release.
> Humans can parse variable syntax, such as the natural language content=
> of syslog, but applications can have a hard time.
>
> I think is very important to know whether we are designing something f= or
> human consumption or for computer consumption.
> "Actor" doesn't provide enough differentiation to know how t= o design our
> solutions.
>
> David Harrington
> dbharrin= gton@comcast.net
> +1-603-828-140= 1
>
> > -----Original Message-----
> > From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Waltermire,
> > David A.
> > Sent: Wednesday, December 04, 2013 8:54 PM
> > To: Adam Montville; Henk Birkholz; sacm@ietf.org
> > Subject: Re: [sacm] FW: New Version Notification for
> > draft-ietf-sacm-use- cases-05.txt
> >
> > Comments inline.
> >
> > > -----Original Message-----
> > > From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Adam
> > > Montville
> > > Sent: Wednesday, December 04, 2013 8:38 PM
> > > To: Henk Birkholz; sacm@ietf.org
> > > Subject: Re: [sacm] FW: New Version Notification for
> draft-ietf-sacm-use-
> > > cases-05.txt
> > >
> > > Something I've found helpful in the past is to abstract a bi= t
> > > further
> from
> > > "user", "operator", "application&qu= ot; and simply reference all of them
> > > at
> once
> > > with the term "actor".
> >
> > Are we ok with the change to using actor? The current usage of &q= uot;user",
> > "operator", "application" (specifically the l= ast two) was suggested a
> while
> > back to align with IETF terminology. Does use of "actor"= ; to reference
> > all
> three
> > concepts raise any concerns?
> >
> > > I also believe that listing *potential* acquisition methods = is
> > > useful in
> at least
> > > the following way: Including a multitude of acquisition meth= ods
> > > clearly
> > signals
> > > our intent of finding information where it already exists, w= hile not
> > > necessarily precluding our ability to *get* information when=
> > > information does not exist.
> >
> > Adam, would you or Henk provide some example acquisition methods = for
> > discussion?
> >
> > > Finally, I, too, like the notion of a work-flow scenario. &n= bsp;I don't
> > > want
> to be
> > the
> > > one drawing a process diagram in an RFC, though. ;-)
> >
> > How would this differ from the workflow scenario text in section = 2?
> >
> > Are you suggesting representing this text in a visual form? If so= ,
> > would anyone like to make a contribution of some ascii art?
> >
> > > awm
> > > ________________________________________
> > > From: sacm [sacm-bounces@ietf.org] on behalf of Henk Birkholz
> > > [henk.birkholz@sit.fraunhofer.de]
> > > Sent: Friday, November 22, 2013 3:27 AM
> > > To: sacm@= ietf.org
> > > Subject: Re: [sacm] FW: New Version Notification for
> draft-ietf-sacm-use-
> > > cases-05.txt
> > >
> > > Regarding the first two question in section 2:
> > >
> > > 1.) Security automation today often supports the user/operat= or, I
> think.
> > > There are cases a security-process can be fully automated, o= f
> > > course,
> and in
> > > order to manage the sheer amount of security related system = events
> > > automation is essential, but it seems to me that the complex= ity and
> > > heterogeneity of root-causes (that might trigger the work-fl= ow) make
> > > the inclusion of a user/operator necessary.
> > >
> > > 2.) To include acquisition methods can provide an intuitive = insight
> about the
> > > scope and intend of the endpoint posture assessment domain, = I think.
> > > On one hand, that might bloat the use-case document a bit (a= nd maybe
> > renders
> > > the title "sacm use cases" too specific?). On the = other hand, I like
> > > the inclusion of a work-flow scenario and I think it is a go= od place
> > > to
> highlight
> > > acquisition methods.
> > >
> > > - Henk
> > >
> > > On 11/21/2013 12:27 AM, Waltermire, David A. wrote:
> > > > I just posted an updated use case draft based on the ed= itorial
> sessions
> > > during the IETF 88 meeting in Vancouver, BC, Canada. My than= ks to
> > > all
> that
> > > provided input.
> > > >
> > > > I used the word version that we edited as a starting po= int. Here
> > > > is
> what I
> > > did:
> > > >
> > > > - I worked through the use cases we planned to remove a= nd made
> > > > sure
> > to
> > > merge in any concepts that would be lost. If you submitted a=
> > > previous
> use
> > > case that was removed, please double check that I didn't mis= s
> anything.
> > > > - I broke up "Endpoint Identification and Assessme= nt" into 3
> > > > distinct
> and
> > > somewhat separable use cases: "Endpoint Identification = and
> > > Assessment Planning", "Endpoint Posture Attribute = Value Collection",
> > > "Posture Evaluation". Please let me know what you = think about this
> change.
> > > > - Addressed some aspects of the discussion thread based= on the
> > > > working
> > > session changes. Please provide any suggested edits for aspe= cts that
> > > I
> > might
> > > have missed or got wrong.
> > > >
> > > > The rest of the changes can be found in the draft's cha= nge log.
> > > >
> > > > If possible, I'd like to get to a fairly stable place w= ith this
> > > > draft
> in the next
> > > revision or two to allow for progress to be made on the
> > > requirements. In addition to the embedded questions in the d= ocument,
> > > I'd like to focus on
> > the
> > > following questions:
> > > >
> > > > Is the draft approachable for a newcomer to the effort?= Do you see
> > > > the
> > > updated use case structure as an improvement?
> > > > Does this draft paint a complete enough picture? Are we= missing
> > > > any
> > > important concepts?
> > > > Is there anything you can't live with?
> > > >
> > > > I hope to release at least one or two more updates to t= his draft
> within the
> > > next few weeks before the holidays catch up on us.  I k= now everyone
> > > is busy; timely comments are appreciated to allow for a quic= k
> > > turnaround on the next revision.
> > > >
> > > > Thanks,
> > > > Dave
> > > >
> > > > -----Original Message-----
> > > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
> > > > Sent: Wednesday, November 20, 2013 5:58 PM
> > > > To: Waltermire, David A.; David Harrington
> > > > Subject: New Version Notification for
> > > > draft-ietf-sacm-use-cases-05.txt
> > > >
> > > >
> > > > A new version of I-D, draft-ietf-sacm-use-cases-05.txt = has been
> > > successfully submitted by David Waltermire and posted to the= IETF
> > > repository.
> > > >
> > > > Filename:      draft-ietf-sacm-use-cases=
> > > > Revision:      05
> > > > Title:              =   Endpoint Security Posture Assessment -
> Enterprise Use
> > Cases
> > > > Creation date:         2013-11-20 > > > > Group:              =   sacm
> > > > Number of pages: 24
> > > > URL:
> http://www.ietf.org/internet-drafts/draft-ietf-sacm-use-
> > cases-
> > > 05.txt
> > > > Status:
> http://datatracker.ietf.org/doc/draft-ietf-sacm-use-cases
> > > > Htmlized:
> http://tools.ietf.org/html/draft-ietf-sacm-use-cases-05
> > > > Diff:
> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sacm-use-cases-05
> > > >
> > > > Abstract:
> > > >     This memo documents a sampling of use cas= es for securely
> aggregating
> > > >     configuration and operational data and ev= aluating that data to
> > > >     determine an organization's security post= ure.  From these
> operational
> > > >     use cases, we can derive common functiona= l capabilities and
> > > >     requirements to guide development of vend= or-neutral,
> interoperable
> > > >     standards for aggregating and evaluating = data relevant to
> security
> > > >     posture.
> > > >
> > > >
> > > >
> > > >
> > > > Please note that it may take a couple of minutes from t= he time of
> > > submission until the htmlized version and diff are available= at
> tools.ietf.org= .
> > > >
> > > > The IETF Secretariat
> > > >
> > > > _______________________________________________
> > > > sacm mailing list
> > > > sacm= @ietf.org
> > > > https://www.ietf.org/mailman/listinfo/sacm
> > > >
> > >
> > >
> > >
> > > ...
> > >
> > > . . .
> > > _______________________________________________
> > > sacm mailing list
> > > sacm@ietf= .org
> > > https://www.ietf.org/mailman/listinfo/sacm
> > _______________________________________________
> > sacm mailing list
> > sacm@ietf.org<= /a>
> > https://www.ietf.org/mailman/listinfo/sacm
>
> _______________________________________________
> sacm mailing list
> sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm
_______________________________________________
sacm mailing list
sacm@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/sacm


_______________________________________________
sacm mailing list
sacm@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/sacm

 =


...

This message and attachm= ents may contain confidential information. If it appears that this message = was sent to you by mistake, any retention, dissemination, distribution or c= opying of this message and attachments is strictly prohibited. Please notify the sender immediately and permanent= ly delete the message and any attachments.
. . .

--_000_4b451425cbec406d94fa1a82b32fa1abBLUPR09MB038namprd09pro_-- From blueroofmusic@gmail.com Mon Dec 9 12:35:09 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 651771AE548 for ; Mon, 9 Dec 2013 12:35:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, GB_I_LETTER=-2, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4a9hnWtGFXgl for ; Mon, 9 Dec 2013 12:35:03 -0800 (PST) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id E34071AE52D for ; Mon, 9 Dec 2013 12:35:02 -0800 (PST) Received: by mail-ie0-f182.google.com with SMTP id as1so7057042iec.41 for ; Mon, 09 Dec 2013 12:34:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=tgziqhND0lSRAceor3UMIP+u5p4GogAq1fhhSjS5E8w=; b=tQNy2mDNdGYjRJ8pNrlO2Zk71/Q3vmY3fzYIyZ3P/8vMaG3D2CXxtIWkFovSy2wCmw hblTk/E7ZX9l8vdwnH6NQicTmzbuy4KKFQzO5Po84akfJz2GGzxuA2FoUdyfp2304wwE 1GoFSjBIt54J6f1I6fKinssCfXDCuKUF2BuMtRmtvihHNRNY9G6l9YPD8X7a4Rs8+in0 n8MwWYwAyUq5S2usXHe4woam5wPN6/6+Wp6vL8bXMET/g4mKFTDhSTPAf845lGD7FUjO DQaXFt8NWVdXCmi9wwZn7HmRNA5Z+DcmnZuul2U7i7gR9iEsUYWJc1JG9na1ZcJqOsbt pyaA== X-Received: by 10.50.110.74 with SMTP id hy10mr17236956igb.0.1386621297810; Mon, 09 Dec 2013 12:34:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.203.38 with HTTP; Mon, 9 Dec 2013 12:34:37 -0800 (PST) In-Reply-To: <4b451425cbec406d94fa1a82b32fa1ab@BLUPR09MB038.namprd09.prod.outlook.com> References: <20131120225753.9031.68753.idtracker@ietfa.amsl.com> <528F23D0.3080504@sit.fraunhofer.de> <05BCCEB107AF88469B9F99783D47C1D6065E4769@CISEXCHANGE1.msisac.org.local> <025d01cef178$63f56840$2be038c0$@comcast.net> <9904FB1B0159DA42B0B887B7FA8119CA12952A08@AZ-FFEXMB04.global.avaya.com> <00C069FD01E0324C9FFCADF539701DB3BBF01B8D@sc9-ex2k10mb1.corp.yaanatech.com> <05BCCEB107AF88469B9F99783D47C1D6065EFE47@CISEXCHANGE1.msisac.org.local> <9904FB1B0159DA42B0B887B7FA8119CA129DBB1D@AZ-FFEXMB04.global.avaya.com> <4b451425cbec406d94fa1a82b32fa1ab@BLUPR09MB038.namprd09.prod.outlook.com> From: Ira McDonald Date: Mon, 9 Dec 2013 15:34:37 -0500 Message-ID: To: "Waltermire, David A." , Ira McDonald Content-Type: multipart/alternative; boundary=047d7bf182d2e4e62904ed1fed43 Cc: "sacm@ietf.org" Subject: Re: [sacm] FW: New Version Notification for draft-ietf-sacm-use-cases-05.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 20:35:09 -0000 --047d7bf182d2e4e62904ed1fed43 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Dave, I'm not sure if there's consensus about this, but I suggest that the curren= t lowercase "operator", "administrator", etc. (e.g., in 2.1.1) should be titlecase (first letter capitalized). Also that a new section 1.1 Actors be added that defines these actor terms (one to three sentences each about what are typical actions or responsibilities for each actor). >From the original Design Goals for IPP (RFC 2567) here are some admittedly printing-specific definitions, but they give the right flavor: "3.1. END-USER An end-user of a printer accepting jobs through the Internet is one of the roles in which humans act. The end-user is the person that will submit a job to be printed on the printer. The wants and needs of the end-user are broken down into six categories: finding/locating a printer, creating a local instance of a printer, viewing printer status, viewing printer capabilities, submitting a print job, viewing print job status, altering the attributes of a print job. 3.2. OPERATOR An operator of a printer accepting jobs through the Internet is one of the roles in which humans act. The operator has the responsibility of monitoring the status of the printer as well as managing and controlling the jobs at the device. These responsibilities include but are not limited to the replenishing of supplies (ink, toner, paper, etc.), the clearing of minor errors (paper jams, etc.) and the re-prioritization of end-user jobs. Operator wants and needs will not be addressed by V1.0 of the protocol. The wants and needs of the operator include all those of the end-user but may include additional privileges. For example, an operator may be able to view all print jobs on a printer while the end-user might only be able to see his own jobs. 3.3. ADMINISTRATOR An administrator of a printer accepting jobs through the Internet is one of the roles in which humans act. The administrator has the responsibility of creating the printer instances and controlling the authorization of other end-users and operators. Administrator wants and needs will not be addressed by V1.0 of the protocol. The wants and needs of the administrator include all those of the end-user and, in some environments, some or all of those of the operator. Minimally, the administrator must also have the tools, programs, utilities and supporting protocols available to be able to: - create an instance of a printer - create, edit and maintain the list of authorized end-users - create, edit and maintain the list of authorized operators - create, edit and maintain the list of authorized administrators - create, customize, change or otherwise alter the manner in which the status capabilities and other information about printers and jobs are presented - create, customize, or change other printer or job features - administrate billing or other charge-back mechanisms - create sets of defaults - create sets of capabilities The administrator must have the capability to perform all the above tasks locally or remotely to the printer." >From later IPP Get-Notifications (RFC 3997), here are much shorter definitions: "2.1. Job-Submitting End User A human end user who submits a print job to an IPP Printer. This person may or may not be within the same security domain as the Printer. This person may or may not be geographically near the printer. 2.2. Administrator A human user who established policy for and configures the print system. 2.3. Operator A human user who carries out the policy established by the Administrator and controls the day-to-day running of the print system." As Nancy said, we need also: Application, System. Cheers, - Ira Ira McDonald (Musician / Software Architect) Co-Chair - TCG Trusted Mobility Solutions WG Chair - Linux Foundation Open Printing WG Secretary - IEEE-ISTO Printer Working Group Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG IETF Designated Expert - IPP & Printer MIB Blue Roof Music / High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto: blueroofmusic@gmail.com Winter 579 Park Place Saline, MI 48176 734-944-0094 Summer PO Box 221 Grand Marais, MI 49839 906-494-2434 On Mon, Dec 9, 2013 at 3:12 PM, Waltermire, David A. < david.waltermire@nist.gov> wrote: > +1. I too like this approach. This has been a good discussion. > > > > To direct this dialog towards actionable changes to the use cases draft, > is there specific draft text that should be updated to make the roles and > their relevance to a use case or usage scenario more clear? > > > > Thanks, > > Dave > > > > *From:* sacm [mailto:sacm-bounces@ietf.org] *On Behalf Of * > Kent_Landfield@McAfee.com > *Sent:* Sunday, December 08, 2013 12:20 PM > > *To:* sacm@ietf.org > *Subject:* Re: [sacm] FW: New Version Notification for > draft-ietf-sacm-use-cases-05.txt > > > > +1 > > > > I like the terminology Ira and Adam have suggested. > > > > *Kent Landfield* > > *McAfee | An Intel Company* > Direct: +1.972.963.7096 > Mobile: +1.817.637.8026 > *Web: *www.mcafee.com > > > > *From: *, "Dan (Dan)" > *Date: *Sunday, December 8, 2013 7:43 AM > *To: *Adam Montville , Ira McDonald < > blueroofmusic@gmail.com>, Michael Hammer > *Cc: *"dbharrington@comcast.net" , David > Waltermire , "sacm@ietf.org" , = " > henk.birkholz@sit.fraunhofer.de" > *Subject: *Re: [sacm] FW: New Version Notification for > draft-ietf-sacm-use-cases-05.txt > > > > +1 > > > > Dan > > > > Speaking as contributor =96 better to say it clearly if there are reasons= to > wonder > > > > > > *From:* Adam Montville [mailto:Adam.Montville@cisecurity.org] > > *Sent:* Friday, December 06, 2013 3:12 AM > *To:* Ira McDonald; Michael Hammer > *Cc:* Romascanu, Dan (Dan); dbharrington@comcast.net; > david.waltermire@nist.gov; henk.birkholz@sit.fraunhofer.de; sacm@ietf.org > *Subject:* RE: [sacm] FW: New Version Notification for > draft-ietf-sacm-use-cases-05.txt > > > > I like this set of terminology. End User, Operator, Administrator, and > Application. Then, Application can potentially have further specificatio= n > as we move forward. For example, Analysis Application, Acquisition > Application, and so on. > > > > Whatever we choose, I would prefer to choose terms that we can easily use > consistently. > > > > Adam > > > > (I'm assuming, but perhaps shouldn't, that when I comment like this it's > as a contributor) > > > ------------------------------ > > *From:* Ira McDonald [blueroofmusic@gmail.com] > *Sent:* Thursday, December 05, 2013 8:48 AM > *To:* Michael Hammer > *Cc:* dromasca@avaya.com; dbharrington@comcast.net; > david.waltermire@nist.gov; Adam Montville; henk.birkholz@sit.fraunhofer.d= e; > sacm@ietf.org > *Subject:* Re: [sacm] FW: New Version Notification for > draft-ietf-sacm-use-cases-05.txt > > Hi, > > My two cents - End User, Operator, and Administrator are quite distinct > > roles of actors in standards from many SDOs - they have inherently > > distinct default privileges - using these common role terms consistently > > would make SACM use cases more accessible to non-participants in > the SACM WG. > > BTW - there are a few other roles of actors that should probably be > > used in SACM use cases, e.g., Application - although tthat's a slippery > > slope, because normal applications (browsers, email readers, etc.) > > have very different privileges and responsibilities from security-specifi= c > > applications (MDM agents, anti-virus scanners, etc.). > > Cheers, > > - Ira > > > Ira McDonald (Musician / Software Architect) > Co-Chair - TCG Trusted Mobility Solutions WG > Chair - Linux Foundation Open Printing WG > Secretary - IEEE-ISTO Printer Working Group > Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG > IETF Designated Expert - IPP & Printer MIB > Blue Roof Music / High North Inc > http://sites.google.com/site/blueroofmusic > http://sites.google.com/site/highnorthinc > mailto: blueroofmusic@gmail.com > Winter 579 Park Place Saline, MI 48176 734-944-0094 > Summer PO Box 221 Grand Marais, MI 49839 906-494-2434 > > > > On Thu, Dec 5, 2013 at 9:12 AM, Michael Hammer < > michael.hammer@yaanatech.com> wrote: > > Actor connotes human to me. > > What would be wrong with using client or server if asymmetric, or user > agent > if peering? > With adjectives to differentiate types. > > Mike > > > > -----Original Message----- > From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Romascanu, Dan > (Dan) > Sent: Thursday, December 05, 2013 4:52 AM > To: David Harrington; 'Waltermire, David A.'; 'Adam Montville'; 'Henk > Birkholz'; sacm@ietf.org > Subject: Re: [sacm] FW: New Version Notification for > draft-ietf-sacm-use-cases-05.txt > > I share DBH's concern. There may be significant differences in workflows > and > interface requirements between systems (networks, devices) and humans vs. > systems (networks, devices) and applications. There may be significant > differences if the humans are operators or end-users. Using one term (say > 'actor') for all may create ambiguities. I am not sure that I understand > the > advantages of the proposed abstraction. > > Dan > (speaking as contributor) > > > > -----Original Message----- > > From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of David Harrington > > Sent: Thursday, December 05, 2013 7:11 AM > > To: 'Waltermire, David A.'; 'Adam Montville'; 'Henk Birkholz'; > > sacm@ietf.org > > Subject: Re: [sacm] FW: New Version Notification for draft-ietf-sacm- > > use-cases-05.txt > > > > Hi, > > > > Using actor concerns me. > > I find it important to understand whether some content needs to be > > parsed by a human (with our wonderful ability to parse), or a computer > > application (which is bound by a set of rules, and has great difficulty > > when the content is not consistent with the rules). > > > > Around 2003, the operators made it clear that CLIs were difficult to > > work with, because queries would return information in variable formats= . > > While humans might be able to parse the output that might change from > > vendor to vendor, model to model, and release to release, tools had > > significant difficulty due to the lack of standardization. Operators > > could try to deal with the lack of standardization by writing expect > > scripts, but they would need to be updated constantly because what > > worked for one release of a product might not be the same in the next > > release. > > Humans can parse variable syntax, such as the natural language content > > of syslog, but applications can have a hard time. > > > > I think is very important to know whether we are designing something fo= r > > human consumption or for computer consumption. > > "Actor" doesn't provide enough differentiation to know how to design ou= r > > solutions. > > > > David Harrington > > dbharrington@comcast.net > > +1-603-828-1401 > > > > > -----Original Message----- > > > From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Waltermire, > > > David A. > > > Sent: Wednesday, December 04, 2013 8:54 PM > > > To: Adam Montville; Henk Birkholz; sacm@ietf.org > > > Subject: Re: [sacm] FW: New Version Notification for > > > draft-ietf-sacm-use- cases-05.txt > > > > > > Comments inline. > > > > > > > -----Original Message----- > > > > From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Adam > > > > Montville > > > > Sent: Wednesday, December 04, 2013 8:38 PM > > > > To: Henk Birkholz; sacm@ietf.org > > > > Subject: Re: [sacm] FW: New Version Notification for > > draft-ietf-sacm-use- > > > > cases-05.txt > > > > > > > > Something I've found helpful in the past is to abstract a bit > > > > further > > from > > > > "user", "operator", "application" and simply reference all of them > > > > at > > once > > > > with the term "actor". > > > > > > Are we ok with the change to using actor? The current usage of "user"= , > > > "operator", "application" (specifically the last two) was suggested a > > while > > > back to align with IETF terminology. Does use of "actor" to reference > > > all > > three > > > concepts raise any concerns? > > > > > > > I also believe that listing *potential* acquisition methods is > > > > useful in > > at least > > > > the following way: Including a multitude of acquisition methods > > > > clearly > > > signals > > > > our intent of finding information where it already exists, while no= t > > > > necessarily precluding our ability to *get* information when > > > > information does not exist. > > > > > > Adam, would you or Henk provide some example acquisition methods for > > > discussion? > > > > > > > Finally, I, too, like the notion of a work-flow scenario. I don't > > > > want > > to be > > > the > > > > one drawing a process diagram in an RFC, though. ;-) > > > > > > How would this differ from the workflow scenario text in section 2? > > > > > > Are you suggesting representing this text in a visual form? If so, > > > would anyone like to make a contribution of some ascii art? > > > > > > > awm > > > > ________________________________________ > > > > From: sacm [sacm-bounces@ietf.org] on behalf of Henk Birkholz > > > > [henk.birkholz@sit.fraunhofer.de] > > > > Sent: Friday, November 22, 2013 3:27 AM > > > > To: sacm@ietf.org > > > > Subject: Re: [sacm] FW: New Version Notification for > > draft-ietf-sacm-use- > > > > cases-05.txt > > > > > > > > Regarding the first two question in section 2: > > > > > > > > 1.) Security automation today often supports the user/operator, I > > think. > > > > There are cases a security-process can be fully automated, of > > > > course, > > and in > > > > order to manage the sheer amount of security related system events > > > > automation is essential, but it seems to me that the complexity and > > > > heterogeneity of root-causes (that might trigger the work-flow) mak= e > > > > the inclusion of a user/operator necessary. > > > > > > > > 2.) To include acquisition methods can provide an intuitive insight > > about the > > > > scope and intend of the endpoint posture assessment domain, I think= . > > > > On one hand, that might bloat the use-case document a bit (and mayb= e > > > renders > > > > the title "sacm use cases" too specific?). On the other hand, I lik= e > > > > the inclusion of a work-flow scenario and I think it is a good plac= e > > > > to > > highlight > > > > acquisition methods. > > > > > > > > - Henk > > > > > > > > On 11/21/2013 12:27 AM, Waltermire, David A. wrote: > > > > > I just posted an updated use case draft based on the editorial > > sessions > > > > during the IETF 88 meeting in Vancouver, BC, Canada. My thanks to > > > > all > > that > > > > provided input. > > > > > > > > > > I used the word version that we edited as a starting point. Here > > > > > is > > what I > > > > did: > > > > > > > > > > - I worked through the use cases we planned to remove and made > > > > > sure > > > to > > > > merge in any concepts that would be lost. If you submitted a > > > > previous > > use > > > > case that was removed, please double check that I didn't miss > > anything. > > > > > - I broke up "Endpoint Identification and Assessment" into 3 > > > > > distinct > > and > > > > somewhat separable use cases: "Endpoint Identification and > > > > Assessment Planning", "Endpoint Posture Attribute Value Collection"= , > > > > "Posture Evaluation". Please let me know what you think about this > > change. > > > > > - Addressed some aspects of the discussion thread based on the > > > > > working > > > > session changes. Please provide any suggested edits for aspects tha= t > > > > I > > > might > > > > have missed or got wrong. > > > > > > > > > > The rest of the changes can be found in the draft's change log. > > > > > > > > > > If possible, I'd like to get to a fairly stable place with this > > > > > draft > > in the next > > > > revision or two to allow for progress to be made on the > > > > requirements. In addition to the embedded questions in the document= , > > > > I'd like to focus on > > > the > > > > following questions: > > > > > > > > > > Is the draft approachable for a newcomer to the effort? Do you se= e > > > > > the > > > > updated use case structure as an improvement? > > > > > Does this draft paint a complete enough picture? Are we missing > > > > > any > > > > important concepts? > > > > > Is there anything you can't live with? > > > > > > > > > > I hope to release at least one or two more updates to this draft > > within the > > > > next few weeks before the holidays catch up on us. I know everyone > > > > is busy; timely comments are appreciated to allow for a quick > > > > turnaround on the next revision. > > > > > > > > > > Thanks, > > > > > Dave > > > > > > > > > > -----Original Message----- > > > > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > > > > Sent: Wednesday, November 20, 2013 5:58 PM > > > > > To: Waltermire, David A.; David Harrington > > > > > Subject: New Version Notification for > > > > > draft-ietf-sacm-use-cases-05.txt > > > > > > > > > > > > > > > A new version of I-D, draft-ietf-sacm-use-cases-05.txt has been > > > > successfully submitted by David Waltermire and posted to the IETF > > > > repository. > > > > > > > > > > Filename: draft-ietf-sacm-use-cases > > > > > Revision: 05 > > > > > Title: Endpoint Security Posture Assessment - > > Enterprise Use > > > Cases > > > > > Creation date: 2013-11-20 > > > > > Group: sacm > > > > > Number of pages: 24 > > > > > URL: > > http://www.ietf.org/internet-drafts/draft-ietf-sacm-use- > > > cases- > > > > 05.txt > > > > > Status: > > http://datatracker.ietf.org/doc/draft-ietf-sacm-use-cases > > > > > Htmlized: > > http://tools.ietf.org/html/draft-ietf-sacm-use-cases-05 > > > > > Diff: > > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sacm-use-cases-05 > > > > > > > > > > Abstract: > > > > > This memo documents a sampling of use cases for securely > > aggregating > > > > > configuration and operational data and evaluating that data t= o > > > > > determine an organization's security posture. From these > > operational > > > > > use cases, we can derive common functional capabilities and > > > > > requirements to guide development of vendor-neutral, > > interoperable > > > > > standards for aggregating and evaluating data relevant to > > security > > > > > posture. > > > > > > > > > > > > > > > > > > > > > > > > > Please note that it may take a couple of minutes from the time of > > > > submission until the htmlized version and diff are available at > > tools.ietf.org. > > > > > > > > > > The IETF Secretariat > > > > > > > > > > _______________________________________________ > > > > > sacm mailing list > > > > > sacm@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/sacm > > > > > > > > > > > > > > > > > > > > > ... > > > > > > > > . . . > > > > _______________________________________________ > > > > sacm mailing list > > > > sacm@ietf.org > > > > https://www.ietf.org/mailman/listinfo/sacm > > > _______________________________________________ > > > sacm mailing list > > > sacm@ietf.org > > > https://www.ietf.org/mailman/listinfo/sacm > > > > _______________________________________________ > > sacm mailing list > > sacm@ietf.org > > https://www.ietf.org/mailman/listinfo/sacm > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > > > > > ... > > This message and attachments may contain confidential information. If it > appears that this message was sent to you by mistake, any retention, > dissemination, distribution or copying of this message and attachments is > strictly prohibited. Please notify the sender immediately and permanently > delete the message and any attachments. > . . . > > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > > --047d7bf182d2e4e62904ed1fed43 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi Dave,

I'= m not sure if there's consensus about this, but I suggest that the curr= ent
lowercase "operator", "administrator", etc= . (e.g., in 2.1.1) should be
titlecase (first letter capitalized).

Also that a new se= ction 1.1 Actors be added that defines these actor
terms (one to three s= entences each about what are typical actions or
responsibilities for eac= h actor).

From the original Design Goals for IPP (RFC 2567) here are s= ome
admittedly printing-specific definitions, but they give the right fl= avor:

"3.1. END-USER

=A0=A0 An end-user of a printer acc= epting jobs through the Internet is one
=A0=A0 of the roles in which humans act.=A0 The end-user is the person that=
=A0=A0 will submit a job to be printed on the printer.

=A0=A0 Th= e wants and needs of the end-user are broken down into six
=A0=A0 catego= ries: finding/locating a printer, creating a local instance of
=A0=A0 a printer, viewing printer status, viewing printer capabilities,
= =A0=A0 submitting a print job, viewing print job status, altering the
= =A0=A0 attributes of a print job.

3.2. OPERATOR

=A0=A0 An ope= rator of a printer accepting jobs through the Internet is one
=A0=A0 of the roles in which humans act.=A0 The operator has the
=A0=A0 = responsibility of monitoring the status of the printer as well as
=A0=A0= managing and controlling the jobs at the device.=A0 These
=A0=A0 respon= sibilities include but are not limited to the replenishing of
=A0=A0 supplies (ink, toner, paper, etc.), the clearing of minor errors
= =A0=A0 (paper jams, etc.) and the re-prioritization of end-user jobs.
= =A0=A0 Operator wants and needs will not be addressed by V1.0 of the
=A0= =A0 protocol.

=A0=A0 The wants and needs of the operator include all those of the end= -user
=A0=A0 but may include additional privileges.=A0 For example, an o= perator may
=A0=A0 be able to view all print jobs on a printer while the= end-user might
=A0=A0 only be able to see his own jobs.

3.3. ADMINISTRATOR

= =A0=A0 An administrator of a printer accepting jobs through the Internet is=
=A0=A0 one of the roles in which humans act.=A0 The administrator has t= he
=A0=A0 responsibility of creating the printer instances and controlli= ng the
=A0=A0 authorization of other end-users and operators.=A0 Administrator wan= ts
=A0=A0 and needs will not be addressed by V1.0 of the protocol.
=A0=A0 The wants and needs of the administrator include all those of the<= br>=A0=A0 end-user and, in some environments, some or all of those of the =A0=A0 operator.=A0 Minimally, the administrator must also have the tools,<= br>=A0=A0 programs, utilities and supporting protocols available to be able= to:

=A0=A0 - create an instance of a printer
=A0=A0 - create, ed= it and maintain the list of authorized end-users
=A0=A0 - create, edit and maintain the list of authorized operators
=A0= =A0 - create, edit and maintain the list of authorized
=A0=A0=A0=A0 admi= nistrators
=A0=A0 - create, customize, change or otherwise alter the man= ner in
=A0=A0=A0=A0 which the status capabilities and other information = about printers
=A0=A0=A0=A0 and jobs are presented
=A0=A0 - create, customize, or chang= e other printer or job features
=A0=A0 - administrate billing or other c= harge-back mechanisms
=A0=A0 - create sets of defaults
=A0=A0 - creat= e sets of capabilities

=A0=A0 The administrator must have the capability to perform all the ab= ove
=A0=A0 tasks locally or remotely to the printer."

=
From later IPP Get-Notifications (RFC 3997), here are much shorter
=
definitions:

"2.1.=A0 Job-Submitting End User

=A0= =A0 A human end user who submits a print job to an IPP Printer.=A0 This
= =A0=A0 person may or may not be within the same security domain as the
= =A0=A0 Printer.=A0 This person may or may not be geographically near the =A0=A0 printer.

2.2.=A0 Administrator

=A0=A0 A human user who= established policy for and configures the print
=A0=A0 system.

2= .3.=A0 Operator

=A0=A0 A human user who carries out the policy estab= lished by the
=A0=A0 Administrator and controls the day-to-day running of the print
= =A0=A0 system."

As Nancy said, we need also:=A0 Appl= ication, System.

Cheers,
- Ira


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



On Mon, Dec 9, 2013 at 3:12 PM, Waltermi= re, David A. <david.waltermire@nist.gov> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">

+1. I too like this appro= ach. This has been a good discussion.

=A0<= /p>

To direct this dialog tow= ards actionable changes to the use cases draft, is there specific draft tex= t that should be updated to make the roles and their relevance to a use case or usage scenario more clear?

=A0<= /p>

Thanks,

Dave=

=A0<= /p>

From: sacm [ma= ilto:sacm-bounce= s@ietf.org] On Behalf Of Kent_Landfield@McAfee.com
Sent: Sunday, December 08, 2013 12:20 PM


To: sacm@ietf.org=
Subject: Re: [sacm] FW: New Version Notification for draft-ietf-sacm= -use-cases-05.txt

=A0

+1

=A0

I like the terminology Ira and Adam have= suggested.

=A0

Kent Landfield

McAfee | An Intel Company
Direct: +1.972.963.7096=A0
Mobile: +1.817.637.8026
Web:=A0www.mcafee.com<= /p>

=A0

From: <Romascanu>, "Dan (Dan)" <dromasca@avaya.com>= ;
Date: Sunday, December 8, 2013 7:43 AM
To: Adam Montville <Adam.Montville@cisecurity.org>, Ira McDonald &= lt;blueroofmus= ic@gmail.com>, Michael Hammer <michael.hammer@yaanatech.com>
Cc: "dbharrington@comcast.net" <dbharrington@comcast.net>, David Walte= rmire <da= vid.waltermire@nist.gov>, "sacm@ietf.org" <sacm@ietf.org&g= t;, "henk.birkholz@sit.fraunhofer.de" <henk.birkholz@sit.fraunhofer.de= >
Subject: Re: [sacm] FW: New Version Notification for draft-ietf-sacm= -use-cases-05.txt

=A0

+1<= /u>

=A0=

Dan=

=A0=

Speaking as contributor = =96 better to say it clearly if there are reasons to wonder

=A0=

=A0=

From: Adam Mon= tville [= mailto:Adam.Montville@cisecurity.org]
Sent: Friday, December 06, 2013 3:12 AM
To: Ira McDonald; Michael Hammer
Cc: Romascanu, Dan (Dan); dbharrington@comcast.net; david.walter= mire@nist.gov; henk.birkholz@sit.fraunhofer.de; sacm@ietf.org
Subject: RE: [sacm] FW: New Version Notification for draft-ietf-sacm= -use-cases-05.txt

=A0

I like this set of terminology. =A0End U= ser, Operator, Administrator, and Application. =A0Then, Application can pot= entially have further specification as we move forward. =A0For example, Analysis Application, Acquisition Application, and so on. = =A0

=A0

Whatever we choose, I would prefer to ch= oose terms that we can easily use consistently.=A0

=A0

Adam

=A0

(I'm assuming, but perhaps shouldn&#= 39;t, that when I comment like this it's as a contributor)

=A0

From:<= /span> Ira McDonald [blueroofmusic@gmail.com]
Sent: Thursday, December 05, 2013 8:48 AM
To: Michael Hammer
Cc: dromasca= @avaya.com; dbharrington@comcast.net; david.waltermire@nist.gov; Adam Montville; henk.b= irkholz@sit.fraunhofer.de; sacm@ietf.org
Subject: Re: [sacm] FW: New Version Notification for draft-ietf-sacm= -use-cases-05.txt

Hi,

My two cents - End User, Operator, and A= dministrator are quite distinct

roles of actors in standards from many S= DOs - they have inherently

distinct default privileges - using thes= e common role terms consistently

would mak= e SACM use cases more accessible to non-participants in
the SACM WG.

BTW - there are a few other roles of act= ors that should probably be

used in SACM use cases, e.g., Applicatio= n - although tthat's a slippery

slope, because normal applications (brow= sers, email readers, etc.)

have very different privileges and respo= nsibilities from security-specific

applicati= ons (MDM agents, anti-virus scanners, etc.).

Cheers,

- Ira<= /u>


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

=A0

On Thu, Dec 5, 2013 at 9:12 AM, Michael = Hammer <michael.hammer@yaanatech.com> wrote:

Actor connotes human to me.

What would be wrong with using client or server if asymmetric, or user agen= t
if peering?
With adjectives to differentiate types.

Mike



-----Original Message-----
From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan)
Sent: Thursday, December 05, 2013 4:52 AM
To: David Harrington; 'Waltermire, David A.'; 'Adam Montville&#= 39;; 'Henk
Birkholz'; sacm@ietf= .org
Subject: Re: [sacm] FW: New Version Notification for
draft-ietf-sacm-use-cases-05.txt

I share DBH's concern. There may be significant differences in workflow= s and
interface requirements between systems (networks, devices) and humans vs. systems (networks, devices) and applications. There may be significant
differences if the humans are operators or end-users. Using one term (say 'actor') for all may create ambiguities. I am not sure that I under= stand the
advantages of the proposed abstraction.

Dan
(speaking as contributor)


> -----Original Message-----
> From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of David Harrington
> Sent: Thursday, December 05, 2013 7:11 AM
> To: 'Waltermire, David A.'; 'Adam Montville'; 'Hen= k Birkholz';
> sacm@ietf.org > Subject: Re: [sacm] FW: New Version Notification for draft-ietf-sacm-<= br> > use-cases-05.txt
>
> Hi,
>
> Using actor concerns me.
> I find it important to understand whether some content needs to be
> parsed by a human (with our wonderful ability to parse), or a computer=
> application (which is bound by a set of rules, and has great difficult= y
> when the content is not consistent with the rules).
>
> Around 2003, the operators made it clear that CLIs were difficult to > work with, because queries would return information in variable format= s.
> While humans might be able to parse the output that might change from<= br> > vendor to vendor, model to model, and release to release, tools had > significant difficulty due to the lack of standardization. Operators > could try to deal with the lack of standardization by writing expect > scripts, but they would need to be updated constantly because what
> worked for one release of a product might not be the same in the next<= br> > release.
> Humans can parse variable syntax, such as the natural language content=
> of syslog, but applications can have a hard time.
>
> I think is very important to know whether we are designing something f= or
> human consumption or for computer consumption.
> "Actor" doesn't provide enough differentiation to know h= ow to design our
> solutions.
>
> David Harrington
> dbharrin= gton@comcast.net
> +1-603-828-1401
>
> > -----Original Message-----
> > From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Waltermire,
> > David A.
> > Sent: Wednesday, December 04, 2013 8:54 PM
> > To: Adam Montville; Henk Birkholz; sacm@ietf.org
> > Subject: Re: [sacm] FW: New Version Notification for
> > draft-ietf-sacm-use- cases-05.txt
> >
> > Comments inline.
> >
> > > -----Original Message-----
> > > From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Adam
> > > Montville
> > > Sent: Wednesday, December 04, 2013 8:38 PM
> > > To: Henk Birkholz; sacm@ietf.org
> > > Subject: Re: [sacm] FW: New Version Notification for
> draft-ietf-sacm-use-
> > > cases-05.txt
> > >
> > > Something I've found helpful in the past is to abstract = a bit
> > > further
> from
> > > "user", "operator", "application&qu= ot; and simply reference all of them
> > > at
> once
> > > with the term "actor".
> >
> > Are we ok with the change to using actor? The current usage of &q= uot;user",
> > "operator", "application" (specifically the l= ast two) was suggested a
> while
> > back to align with IETF terminology. Does use of "actor"= ; to reference
> > all
> three
> > concepts raise any concerns?
> >
> > > I also believe that listing *potential* acquisition methods = is
> > > useful in
> at least
> > > the following way: Including a multitude of acquisition meth= ods
> > > clearly
> > signals
> > > our intent of finding information where it already exists, w= hile not
> > > necessarily precluding our ability to *get* information when=
> > > information does not exist.
> >
> > Adam, would you or Henk provide some example acquisition methods = for
> > discussion?
> >
> > > Finally, I, too, like the notion of a work-flow scenario. = =A0I don't
> > > want
> to be
> > the
> > > one drawing a process diagram in an RFC, though. ;-)
> >
> > How would this differ from the workflow scenario text in section = 2?
> >
> > Are you suggesting representing this text in a visual form? If so= ,
> > would anyone like to make a contribution of some ascii art?
> >
> > > awm
> > > ________________________________________
> > > From: sacm [sacm-bounces@ietf.org] on behalf of Henk Birkholz
> > > [henk.birkholz@sit.fraunhofer.de]
> > > Sent: Friday, November 22, 2013 3:27 AM
> > > To: sacm@= ietf.org
> > > Subject: Re: [sacm] FW: New Version Notification for
> draft-ietf-sacm-use-
> > > cases-05.txt
> > >
> > > Regarding the first two question in section 2:
> > >
> > > 1.) Security automation today often supports the user/operat= or, I
> think.
> > > There are cases a security-process can be fully automated, o= f
> > > course,
> and in
> > > order to manage the sheer amount of security related system = events
> > > automation is essential, but it seems to me that the complex= ity and
> > > heterogeneity of root-causes (that might trigger the work-fl= ow) make
> > > the inclusion of a user/operator necessary.
> > >
> > > 2.) To include acquisition methods can provide an intuitive = insight
> about the
> > > scope and intend of the endpoint posture assessment domain, = I think.
> > > On one hand, that might bloat the use-case document a bit (a= nd maybe
> > renders
> > > the title "sacm use cases" too specific?). On the = other hand, I like
> > > the inclusion of a work-flow scenario and I think it is a go= od place
> > > to
> highlight
> > > acquisition methods.
> > >
> > > - Henk
> > >
> > > On 11/21/2013 12:27 AM, Waltermire, David A. wrote:
> > > > I just posted an updated use case draft based on the ed= itorial
> sessions
> > > during the IETF 88 meeting in Vancouver, BC, Canada. My than= ks to
> > > all
> that
> > > provided input.
> > > >
> > > > I used the word version that we edited as a starting po= int. Here
> > > > is
> what I
> > > did:
> > > >
> > > > - I worked through the use cases we planned to remove a= nd made
> > > > sure
> > to
> > > merge in any concepts that would be lost. If you submitted a=
> > > previous
> use
> > > case that was removed, please double check that I didn't= miss
> anything.
> > > > - I broke up "Endpoint Identification and Assessme= nt" into 3
> > > > distinct
> and
> > > somewhat separable use cases: "Endpoint Identification = and
> > > Assessment Planning", "Endpoint Posture Attribute = Value Collection",
> > > "Posture Evaluation". Please let me know what you = think about this
> change.
> > > > - Addressed some aspects of the discussion thread based= on the
> > > > working
> > > session changes. Please provide any suggested edits for aspe= cts that
> > > I
> > might
> > > have missed or got wrong.
> > > >
> > > > The rest of the changes can be found in the draft's= change log.
> > > >
> > > > If possible, I'd like to get to a fairly stable pla= ce with this
> > > > draft
> in the next
> > > revision or two to allow for progress to be made on the
> > > requirements. In addition to the embedded questions in the d= ocument,
> > > I'd like to focus on
> > the
> > > following questions:
> > > >
> > > > Is the draft approachable for a newcomer to the effort?= Do you see
> > > > the
> > > updated use case structure as an improvement?
> > > > Does this draft paint a complete enough picture? Are we= missing
> > > > any
> > > important concepts?
> > > > Is there anything you can't live with?
> > > >
> > > > I hope to release at least one or two more updates to t= his draft
> within the
> > > next few weeks before the holidays catch up on us. =A0I know= everyone
> > > is busy; timely comments are appreciated to allow for a quic= k
> > > turnaround on the next revision.
> > > >
> > > > Thanks,
> > > > Dave
> > > >
> > > > -----Original Message-----
> > > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
> > > > Sent: Wednesday, November 20, 2013 5:58 PM
> > > > To: Waltermire, David A.; David Harrington
> > > > Subject: New Version Notification for
> > > > draft-ietf-sacm-use-cases-05.txt
> > > >
> > > >
> > > > A new version of I-D, draft-ietf-sacm-use-cases-05.txt = has been
> > > successfully submitted by David Waltermire and posted to the= IETF
> > > repository.
> > > >
> > > > Filename: =A0 =A0 =A0draft-ietf-sacm-use-cases
> > > > Revision: =A0 =A0 =A005
> > > > Title: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Endpoint Securit= y Posture Assessment -
> Enterprise Use
> > Cases
> > > > Creation date: =A0 =A0 =A0 =A0 2013-11-20
> > > > Group: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 sacm
> > > > Number of pages: 24
> > > > URL:
> http://www.ietf.org/internet-drafts/draft-ietf-sacm-use-
> > cases-
> > > 05.txt
> > > > Status:
> http://datatracker.ietf.org/doc/draft-ietf-sacm-use-cases
> > > > Htmlized:
> http://tools.ietf.org/html/draft-ietf-sacm-use-cases-05
> > > > Diff:
> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sacm-use-cases-05
> > > >
> > > > Abstract:
> > > > =A0 =A0 This memo documents a sampling of use cases for= securely
> aggregating
> > > > =A0 =A0 configuration and operational data and evaluati= ng that data to
> > > > =A0 =A0 determine an organization's security postur= e. =A0From these
> operational
> > > > =A0 =A0 use cases, we can derive common functional capa= bilities and
> > > > =A0 =A0 requirements to guide development of vendor-neu= tral,
> interoperable
> > > > =A0 =A0 standards for aggregating and evaluating data r= elevant to
> security
> > > > =A0 =A0 posture.
> > > >
> > > >
> > > >
> > > >
> > > > Please note that it may take a couple of minutes from t= he time of
> > > submission until the htmlized version and diff are available= at
> tools.ietf.org= .
> > > >
> > > > The IETF Secretariat
> > > >
> > > > _______________________________________________
> > > > sacm mailing list
> > > > sacm= @ietf.org
> > > > https://www.ietf.org/mailman/listinfo/sacm
> > > >
> > >
> > >
> > >
> > > ...
> > >
> > > . . .
> > > _______________________________________________
> > > sacm mailing list
> > > sacm@ietf= .org
> > > https://www.ietf.org/mailman/listinfo/sacm
> > _______________________________________________
> > sacm mailing list
> > sacm@ietf.org<= /a>
> > https://www.ietf.org/mailman/listinfo/sacm
>
> _______________________________________________
> sacm mailing list
> sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm
_______________________________________________
sacm mailing list
sacm@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/sacm


_______________________________________________
sacm mailing list
sacm@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/sacm

=A0


...

This message and attachments may contain= confidential information. If it appears that this message was sent to you = by mistake, any retention, dissemination, distribution or copying of this m= essage and attachments is strictly prohibited. Please notify the sender immediately and permanent= ly delete the message and any attachments.
. . .


_______________________________________________
sacm mailing list
sacm@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/sacm


--047d7bf182d2e4e62904ed1fed43-- From ietfdbh@comcast.net Mon Dec 9 17:10:46 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1486D1AE046 for ; Mon, 9 Dec 2013 17:10:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4 X-Spam-Level: X-Spam-Status: No, score=-4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AtYzL2ObQWN8 for ; Mon, 9 Dec 2013 17:10:35 -0800 (PST) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:64]) by ietfa.amsl.com (Postfix) with ESMTP id 23F3D1AE0AA for ; Mon, 9 Dec 2013 17:10:35 -0800 (PST) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta07.westchester.pa.mail.comcast.net with comcast id zajc1m0061ei1Bg57dAVdc; Tue, 10 Dec 2013 01:10:29 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta24.westchester.pa.mail.comcast.net with comcast id zdAT1m00d2yZEBF3kdAUj0; Tue, 10 Dec 2013 01:10:29 +0000 From: "ietfdbh" To: "'Ira McDonald'" , "'Waltermire, David A.'" References: <20131120225753.9031.68753.idtracker@ietfa.amsl.com> <528F23D0.3080504@sit.fraunhofer.de> <05BCCEB107AF88469B9F99783D47C1D6065E4769@CISEXCHANGE1.msisac.org.local> <025d01cef178$63f56840$2be038c0$@comcast.net> <9904FB1B0159DA42B0B887B7FA8119CA12952A08@AZ-FFEXMB04.global.avaya.com> <00C069FD01E0324C9FFCADF539701DB3BBF01B8D@sc9-ex2k10mb1.corp.yaanatech.com> <05BCCEB107AF88469B9F99783D47C1D6065EFE47@CISEXCHANGE1.msisac.org.local> <9904FB1B0159DA42B0B887B7FA8119CA129DBB1D@AZ-FFEXMB04.global.avaya.com> <4b451425cbec406d94fa1a82b32fa1ab@BLUPR09MB038.namprd09.prod.outlook.com> In-Reply-To: Date: Mon, 9 Dec 2013 20:10:26 -0500 Message-ID: <018701cef544$9d2ce730$d786b590$@comcast.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0188_01CEF51A.B45D47D0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQDqYHUjRqa6AdCybnAKjK8iZl6ZEgHRoRLuAd5OVZsCKr/+CgJ7lTzzAQ4/IcwBus0sYgFPhFmkAlHlbqECl4tgtQH1NBIcATnrWRYCSft4xQGV9CYpm1KNO3A= Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1386637829; bh=fsyH1InmQi07YH9uEDKzhlPFRBjedHNzcux8jNW2VsM=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=HR32X6f/g27YQTuj1gW3ty4IpFQADsQ6PwkKQlB4WgBeItgt6NitaRYENyyVUBt5t SNMn24UtU8BlRlkuNvKJgrKSAvQO8Vx8UvDXzzla2O2C6RQ20aBK5+2wFOLjkwZnLx Nol4SJ+7rXlZisz/YclYV/B2gWP9sndSR5oZhmQTMSQtcaq2bcvif+8G7WORuYPmAJ Dc6VwoBi7ejnzys9rEJg8tnQtnfTbBZHw+Dl+8vdQynr4XNp22tSHQ4JdEaT184AgV 9oRRJHlsW4YODWPxQPLmm8/+l10CNuOru+8xtCuwYZLHFTxbDdoOjY/Y4Rjws05PZe Xx5QZenjGsjoQ== Cc: sacm@ietf.org Subject: Re: [sacm] FW: New Version Notification for draft-ietf-sacm-use-cases-05.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 01:10:46 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0188_01CEF51A.B45D47D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I'd have to go look up a reference, but I believe the rfc editor considers it bad form to capitalize things that don't need to be capitalized. David Harrington ietfdbh@comcast.net +1-603-828-1401 From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Ira McDonald Sent: Monday, December 09, 2013 3:35 PM To: Waltermire, David A.; Ira McDonald Cc: sacm@ietf.org Subject: Re: [sacm] FW: New Version Notification for draft-ietf-sacm-use-cases-05.txt Hi Dave, I'm not sure if there's consensus about this, but I suggest that the current lowercase "operator", "administrator", etc. (e.g., in 2.1.1) should be titlecase (first letter capitalized). Also that a new section 1.1 Actors be added that defines these actor terms (one to three sentences each about what are typical actions or responsibilities for each actor). >From the original Design Goals for IPP (RFC 2567) here are some admittedly printing-specific definitions, but they give the right flavor: "3.1. END-USER An end-user of a printer accepting jobs through the Internet is one of the roles in which humans act. The end-user is the person that will submit a job to be printed on the printer. The wants and needs of the end-user are broken down into six categories: finding/locating a printer, creating a local instance of a printer, viewing printer status, viewing printer capabilities, submitting a print job, viewing print job status, altering the attributes of a print job. 3.2. OPERATOR An operator of a printer accepting jobs through the Internet is one of the roles in which humans act. The operator has the responsibility of monitoring the status of the printer as well as managing and controlling the jobs at the device. These responsibilities include but are not limited to the replenishing of supplies (ink, toner, paper, etc.), the clearing of minor errors (paper jams, etc.) and the re-prioritization of end-user jobs. Operator wants and needs will not be addressed by V1.0 of the protocol. The wants and needs of the operator include all those of the end-user but may include additional privileges. For example, an operator may be able to view all print jobs on a printer while the end-user might only be able to see his own jobs. 3.3. ADMINISTRATOR An administrator of a printer accepting jobs through the Internet is one of the roles in which humans act. The administrator has the responsibility of creating the printer instances and controlling the authorization of other end-users and operators. Administrator wants and needs will not be addressed by V1.0 of the protocol. The wants and needs of the administrator include all those of the end-user and, in some environments, some or all of those of the operator. Minimally, the administrator must also have the tools, programs, utilities and supporting protocols available to be able to: - create an instance of a printer - create, edit and maintain the list of authorized end-users - create, edit and maintain the list of authorized operators - create, edit and maintain the list of authorized administrators - create, customize, change or otherwise alter the manner in which the status capabilities and other information about printers and jobs are presented - create, customize, or change other printer or job features - administrate billing or other charge-back mechanisms - create sets of defaults - create sets of capabilities The administrator must have the capability to perform all the above tasks locally or remotely to the printer." >From later IPP Get-Notifications (RFC 3997), here are much shorter definitions: "2.1. Job-Submitting End User A human end user who submits a print job to an IPP Printer. This person may or may not be within the same security domain as the Printer. This person may or may not be geographically near the printer. 2.2. Administrator A human user who established policy for and configures the print system. 2.3. Operator A human user who carries out the policy established by the Administrator and controls the day-to-day running of the print system." As Nancy said, we need also: Application, System. Cheers, - Ira Ira McDonald (Musician / Software Architect) Co-Chair - TCG Trusted Mobility Solutions WG Chair - Linux Foundation Open Printing WG Secretary - IEEE-ISTO Printer Working Group Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG IETF Designated Expert - IPP & Printer MIB Blue Roof Music / High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto: blueroofmusic@gmail.com Winter 579 Park Place Saline, MI 48176 734-944-0094 Summer PO Box 221 Grand Marais, MI 49839 906-494-2434 On Mon, Dec 9, 2013 at 3:12 PM, Waltermire, David A. wrote: +1. I too like this approach. This has been a good discussion. To direct this dialog towards actionable changes to the use cases draft, is there specific draft text that should be updated to make the roles and their relevance to a use case or usage scenario more clear? Thanks, Dave From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Kent_Landfield@McAfee.com Sent: Sunday, December 08, 2013 12:20 PM To: sacm@ietf.org Subject: Re: [sacm] FW: New Version Notification for draft-ietf-sacm-use-cases-05.txt +1 I like the terminology Ira and Adam have suggested. Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: , "Dan (Dan)" Date: Sunday, December 8, 2013 7:43 AM To: Adam Montville , Ira McDonald , Michael Hammer Cc: "dbharrington@comcast.net" , David Waltermire , "sacm@ietf.org" , "henk.birkholz@sit.fraunhofer.de" Subject: Re: [sacm] FW: New Version Notification for draft-ietf-sacm-use-cases-05.txt +1 Dan Speaking as contributor - better to say it clearly if there are reasons to wonder From: Adam Montville [mailto:Adam.Montville@cisecurity.org] Sent: Friday, December 06, 2013 3:12 AM To: Ira McDonald; Michael Hammer Cc: Romascanu, Dan (Dan); dbharrington@comcast.net; david.waltermire@nist.gov; henk.birkholz@sit.fraunhofer.de; sacm@ietf.org Subject: RE: [sacm] FW: New Version Notification for draft-ietf-sacm-use-cases-05.txt I like this set of terminology. End User, Operator, Administrator, and Application. Then, Application can potentially have further specification as we move forward. For example, Analysis Application, Acquisition Application, and so on. Whatever we choose, I would prefer to choose terms that we can easily use consistently. Adam (I'm assuming, but perhaps shouldn't, that when I comment like this it's as a contributor) _____ From: Ira McDonald [blueroofmusic@gmail.com] Sent: Thursday, December 05, 2013 8:48 AM To: Michael Hammer Cc: dromasca@avaya.com; dbharrington@comcast.net; david.waltermire@nist.gov; Adam Montville; henk.birkholz@sit.fraunhofer.de; sacm@ietf.org Subject: Re: [sacm] FW: New Version Notification for draft-ietf-sacm-use-cases-05.txt Hi, My two cents - End User, Operator, and Administrator are quite distinct roles of actors in standards from many SDOs - they have inherently distinct default privileges - using these common role terms consistently would make SACM use cases more accessible to non-participants in the SACM WG. BTW - there are a few other roles of actors that should probably be used in SACM use cases, e.g., Application - although tthat's a slippery slope, because normal applications (browsers, email readers, etc.) have very different privileges and responsibilities from security-specific applications (MDM agents, anti-virus scanners, etc.). Cheers, - Ira Ira McDonald (Musician / Software Architect) Co-Chair - TCG Trusted Mobility Solutions WG Chair - Linux Foundation Open Printing WG Secretary - IEEE-ISTO Printer Working Group Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG IETF Designated Expert - IPP & Printer MIB Blue Roof Music / High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto: blueroofmusic@gmail.com Winter 579 Park Place Saline, MI 48176 734-944-0094 Summer PO Box 221 Grand Marais, MI 49839 906-494-2434 On Thu, Dec 5, 2013 at 9:12 AM, Michael Hammer wrote: Actor connotes human to me. What would be wrong with using client or server if asymmetric, or user agent if peering? With adjectives to differentiate types. Mike -----Original Message----- From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Thursday, December 05, 2013 4:52 AM To: David Harrington; 'Waltermire, David A.'; 'Adam Montville'; 'Henk Birkholz'; sacm@ietf.org Subject: Re: [sacm] FW: New Version Notification for draft-ietf-sacm-use-cases-05.txt I share DBH's concern. There may be significant differences in workflows and interface requirements between systems (networks, devices) and humans vs. systems (networks, devices) and applications. There may be significant differences if the humans are operators or end-users. Using one term (say 'actor') for all may create ambiguities. I am not sure that I understand the advantages of the proposed abstraction. Dan (speaking as contributor) > -----Original Message----- > From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of David Harrington > Sent: Thursday, December 05, 2013 7:11 AM > To: 'Waltermire, David A.'; 'Adam Montville'; 'Henk Birkholz'; > sacm@ietf.org > Subject: Re: [sacm] FW: New Version Notification for draft-ietf-sacm- > use-cases-05.txt > > Hi, > > Using actor concerns me. > I find it important to understand whether some content needs to be > parsed by a human (with our wonderful ability to parse), or a computer > application (which is bound by a set of rules, and has great difficulty > when the content is not consistent with the rules). > > Around 2003, the operators made it clear that CLIs were difficult to > work with, because queries would return information in variable formats. > While humans might be able to parse the output that might change from > vendor to vendor, model to model, and release to release, tools had > significant difficulty due to the lack of standardization. Operators > could try to deal with the lack of standardization by writing expect > scripts, but they would need to be updated constantly because what > worked for one release of a product might not be the same in the next > release. > Humans can parse variable syntax, such as the natural language content > of syslog, but applications can have a hard time. > > I think is very important to know whether we are designing something for > human consumption or for computer consumption. > "Actor" doesn't provide enough differentiation to know how to design our > solutions. > > David Harrington > dbharrington@comcast.net > +1-603-828-1401 > > > -----Original Message----- > > From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Waltermire, > > David A. > > Sent: Wednesday, December 04, 2013 8:54 PM > > To: Adam Montville; Henk Birkholz; sacm@ietf.org > > Subject: Re: [sacm] FW: New Version Notification for > > draft-ietf-sacm-use- cases-05.txt > > > > Comments inline. > > > > > -----Original Message----- > > > From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Adam > > > Montville > > > Sent: Wednesday, December 04, 2013 8:38 PM > > > To: Henk Birkholz; sacm@ietf.org > > > Subject: Re: [sacm] FW: New Version Notification for > draft-ietf-sacm-use- > > > cases-05.txt > > > > > > Something I've found helpful in the past is to abstract a bit > > > further > from > > > "user", "operator", "application" and simply reference all of them > > > at > once > > > with the term "actor". > > > > Are we ok with the change to using actor? The current usage of "user", > > "operator", "application" (specifically the last two) was suggested a > while > > back to align with IETF terminology. Does use of "actor" to reference > > all > three > > concepts raise any concerns? > > > > > I also believe that listing *potential* acquisition methods is > > > useful in > at least > > > the following way: Including a multitude of acquisition methods > > > clearly > > signals > > > our intent of finding information where it already exists, while not > > > necessarily precluding our ability to *get* information when > > > information does not exist. > > > > Adam, would you or Henk provide some example acquisition methods for > > discussion? > > > > > Finally, I, too, like the notion of a work-flow scenario. I don't > > > want > to be > > the > > > one drawing a process diagram in an RFC, though. ;-) > > > > How would this differ from the workflow scenario text in section 2? > > > > Are you suggesting representing this text in a visual form? If so, > > would anyone like to make a contribution of some ascii art? > > > > > awm > > > ________________________________________ > > > From: sacm [sacm-bounces@ietf.org] on behalf of Henk Birkholz > > > [henk.birkholz@sit.fraunhofer.de] > > > Sent: Friday, November 22, 2013 3:27 AM > > > To: sacm@ietf.org > > > Subject: Re: [sacm] FW: New Version Notification for > draft-ietf-sacm-use- > > > cases-05.txt > > > > > > Regarding the first two question in section 2: > > > > > > 1.) Security automation today often supports the user/operator, I > think. > > > There are cases a security-process can be fully automated, of > > > course, > and in > > > order to manage the sheer amount of security related system events > > > automation is essential, but it seems to me that the complexity and > > > heterogeneity of root-causes (that might trigger the work-flow) make > > > the inclusion of a user/operator necessary. > > > > > > 2.) To include acquisition methods can provide an intuitive insight > about the > > > scope and intend of the endpoint posture assessment domain, I think. > > > On one hand, that might bloat the use-case document a bit (and maybe > > renders > > > the title "sacm use cases" too specific?). On the other hand, I like > > > the inclusion of a work-flow scenario and I think it is a good place > > > to > highlight > > > acquisition methods. > > > > > > - Henk > > > > > > On 11/21/2013 12:27 AM, Waltermire, David A. wrote: > > > > I just posted an updated use case draft based on the editorial > sessions > > > during the IETF 88 meeting in Vancouver, BC, Canada. My thanks to > > > all > that > > > provided input. > > > > > > > > I used the word version that we edited as a starting point. Here > > > > is > what I > > > did: > > > > > > > > - I worked through the use cases we planned to remove and made > > > > sure > > to > > > merge in any concepts that would be lost. If you submitted a > > > previous > use > > > case that was removed, please double check that I didn't miss > anything. > > > > - I broke up "Endpoint Identification and Assessment" into 3 > > > > distinct > and > > > somewhat separable use cases: "Endpoint Identification and > > > Assessment Planning", "Endpoint Posture Attribute Value Collection", > > > "Posture Evaluation". Please let me know what you think about this > change. > > > > - Addressed some aspects of the discussion thread based on the > > > > working > > > session changes. Please provide any suggested edits for aspects that > > > I > > might > > > have missed or got wrong. > > > > > > > > The rest of the changes can be found in the draft's change log. > > > > > > > > If possible, I'd like to get to a fairly stable place with this > > > > draft > in the next > > > revision or two to allow for progress to be made on the > > > requirements. In addition to the embedded questions in the document, > > > I'd like to focus on > > the > > > following questions: > > > > > > > > Is the draft approachable for a newcomer to the effort? Do you see > > > > the > > > updated use case structure as an improvement? > > > > Does this draft paint a complete enough picture? Are we missing > > > > any > > > important concepts? > > > > Is there anything you can't live with? > > > > > > > > I hope to release at least one or two more updates to this draft > within the > > > next few weeks before the holidays catch up on us. I know everyone > > > is busy; timely comments are appreciated to allow for a quick > > > turnaround on the next revision. > > > > > > > > Thanks, > > > > Dave > > > > > > > > -----Original Message----- > > > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > > > Sent: Wednesday, November 20, 2013 5:58 PM > > > > To: Waltermire, David A.; David Harrington > > > > Subject: New Version Notification for > > > > draft-ietf-sacm-use-cases-05.txt > > > > > > > > > > > > A new version of I-D, draft-ietf-sacm-use-cases-05.txt has been > > > successfully submitted by David Waltermire and posted to the IETF > > > repository. > > > > > > > > Filename: draft-ietf-sacm-use-cases > > > > Revision: 05 > > > > Title: Endpoint Security Posture Assessment - > Enterprise Use > > Cases > > > > Creation date: 2013-11-20 > > > > Group: sacm > > > > Number of pages: 24 > > > > URL: > http://www.ietf.org/internet-drafts/draft-ietf-sacm-use- > > cases- > > > 05.txt > > > > Status: > http://datatracker.ietf.org/doc/draft-ietf-sacm-use-cases > > > > Htmlized: > http://tools.ietf.org/html/draft-ietf-sacm-use-cases-05 > > > > Diff: > http://www.ietf.org/rfcdiff?url2=draft-ietf-sacm-use-cases-05 > > > > > > > > Abstract: > > > > This memo documents a sampling of use cases for securely > aggregating > > > > configuration and operational data and evaluating that data to > > > > determine an organization's security posture. From these > operational > > > > use cases, we can derive common functional capabilities and > > > > requirements to guide development of vendor-neutral, > interoperable > > > > standards for aggregating and evaluating data relevant to > security > > > > posture. > > > > > > > > > > > > > > > > > > > > Please note that it may take a couple of minutes from the time of > > > submission until the htmlized version and diff are available at > tools.ietf.org. > > > > > > > > The IETF Secretariat > > > > > > > > _______________________________________________ > > > > sacm mailing list > > > > sacm@ietf.org > > > > https://www.ietf.org/mailman/listinfo/sacm > > > > > > > > > > > > > > > > ... > > > > > > . . . > > > _______________________________________________ > > > sacm mailing list > > > sacm@ietf.org > > > https://www.ietf.org/mailman/listinfo/sacm > > _______________________________________________ > > sacm mailing list > > sacm@ietf.org > > https://www.ietf.org/mailman/listinfo/sacm > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm ... This message and attachments may contain confidential information. If it appears that this message was sent to you by mistake, any retention, dissemination, distribution or copying of this message and attachments is strictly prohibited. Please notify the sender immediately and permanently delete the message and any attachments. . . . _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm ------=_NextPart_000_0188_01CEF51A.B45D47D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I’d have to go look up a reference, but I believe the rfc = editor considers it bad form to capitalize things that don’t need = to be capitalized.

 

 

David Harrington

ietfdbh@comca= st.net

+1-603-828-1401

From:= = sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Ira = McDonald
Sent: Monday, December 09, 2013 3:35 PM
To: = Waltermire, David A.; Ira McDonald
Cc: = sacm@ietf.org
Subject: Re: [sacm] FW: New Version Notification = for draft-ietf-sacm-use-cases-05.txt

 

Hi = Dave,

I'm not sure if there's = consensus about this, but I suggest that the = current

lowercase = "operator", "administrator", etc. (e.g., in 2.1.1) = should be

titlecase (first letter = capitalized).

Also that a new section 1.1 Actors be = added that defines these actor
terms (one to three sentences each = about what are typical actions or
responsibilities for each = actor).

From the original Design Goals for IPP = (RFC 2567) here are some
admittedly printing-specific definitions, = but they give the right flavor:

"3.1. = END-USER

   An end-user of a printer accepting jobs = through the Internet is one
   of the roles in which humans = act.  The end-user is the person that
   will submit a = job to be printed on the printer.

   The wants and = needs of the end-user are broken down into six
   = categories: finding/locating a printer, creating a local instance = of
   a printer, viewing printer status, viewing printer = capabilities,
   submitting a print job, viewing print job = status, altering the
   attributes of a print = job.

3.2. OPERATOR

   An operator of a printer = accepting jobs through the Internet is one
   of the roles = in which humans act.  The operator has the
   = responsibility of monitoring the status of the printer as well = as
   managing and controlling the jobs at the = device.  These
   responsibilities include but are not = limited to the replenishing of
   supplies (ink, toner, = paper, etc.), the clearing of minor errors
   (paper jams, = etc.) and the re-prioritization of end-user jobs.
   = Operator wants and needs will not be addressed by V1.0 of = the
   protocol.

   The wants and needs of = the operator include all those of the end-user
   but may = include additional privileges.  For example, an operator = may
   be able to view all print jobs on a printer while = the end-user might
   only be able to see his own = jobs.

3.3. ADMINISTRATOR

   An administrator of = a printer accepting jobs through the Internet is
   one of = the roles in which humans act.  The administrator has = the
   responsibility of creating the printer instances and = controlling the
   authorization of other end-users and = operators.  Administrator wants
   and needs will not = be addressed by V1.0 of the protocol.

   The wants and = needs of the administrator include all those of the
   = end-user and, in some environments, some or all of those of = the
   operator.  Minimally, the administrator must = also have the tools,
   programs, utilities and supporting = protocols available to be able to:

   - create an = instance of a printer
   - create, edit and maintain the = list of authorized end-users
   - create, edit and maintain = the list of authorized operators
   - create, edit and = maintain the list of authorized
     = administrators
   - create, customize, change or otherwise = alter the manner in
     which the status = capabilities and other information about = printers
     and jobs are = presented
   - create, customize, or change other printer = or job features
   - administrate billing or other = charge-back mechanisms
   - create sets of = defaults
   - create sets of = capabilities

   The administrator must have the = capability to perform all the above
   tasks locally or = remotely to the printer."

From later IPP Get-Notifications (RFC 3997), here are = much shorter

definitions:

"2.1.  = Job-Submitting End User

   A human end user who submits = a print job to an IPP Printer.  This
   person may or = may not be within the same security domain as the
   = Printer.  This person may or may not be geographically near = the
   printer.

2.2.  = Administrator

   A human user who established policy = for and configures the print
   system.

2.3.  = Operator

   A human user who carries out the policy = established by the
   Administrator and controls the = day-to-day running of the print
   = system."

As Nancy said, we need also:  = Application, System.

Cheers,

- Ira


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

 

On Mon, Dec 9, 2013 at 3:12 PM, Waltermire, David A. = <david.waltermire@nist.gov> = wrote:

+1. I too like this approach. This has been a good = discussion.

 

To direct this dialog towards actionable changes to the use cases = draft, is there specific draft text that should be updated to make the = roles and their relevance to a use case or usage scenario more = clear?

 

Thanks,

Dave

 

From:= = sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Kent_Landfield@McAfee.comSent: Sunday, December 08, 2013 12:20 = PM


To: sacm@ietf.org
Subject: Re: [sacm] FW: = New Version Notification for = draft-ietf-sacm-use-cases-05.txt

 <= /o:p>

+1

 <= /o:p>

I like the = terminology Ira and Adam have suggested.

 <= /o:p>

= Kent Landfield=

McAfee = | An Intel Company
Direct: +1.972.963.7096 
Mobile: +1.817.637.8026
Web: www.mcafee.com

 <= /o:p>

From: = <Romasca= nu>, "Dan (Dan)" <dromasca@avaya.com>
Date: Sunday, = December 8, 2013 7:43 AM
To: Adam Montville <Adam.Montville@cisecurity.org>, Ira McDonald = <blueroofmusic@gmail.com>, Michael Hammer <michael.hammer@yaanatech.com>
Cc: = "dbharrington@comcast.net" <dbharrington@comcast.net>, David Waltermire = <david.waltermire@nist.gov>, "sacm@ietf.org" = <sacm@ietf.org>, "henk.birkholz@sit.fraunhofer.de" <henk.birkholz@sit.fraunhofer.de>
Subject: = Re: [sacm] FW: New Version Notification for = draft-ietf-sacm-use-cases-05.txt

 <= /o:p>

+1

 

Dan

 

Speaking as contributor – better to say it clearly if there are = reasons to wonder

 

 

From:= = Adam Montville [mailto:Adam.Montville@cisecurity.org] =
Sent: Friday, December 06, 2013 3:12 AM
To: Ira = McDonald; Michael Hammer
Cc: Romascanu, Dan (Dan); dbharrington@comcast.net; david.waltermire@nist.gov; henk.birkholz@sit.fraunhofer.de; sacm@ietf.org
Subject: RE: [sacm] FW: = New Version Notification for = draft-ietf-sacm-use-cases-05.txt

 <= /o:p>

I like this = set of terminology.  End User, Operator, Administrator, and = Application.  Then, Application can potentially have further = specification as we move forward.  For example, Analysis = Application, Acquisition Application, and so on.   =

 

Whatever we = choose, I would prefer to choose terms that we can easily use = consistently. 

 

Adam<= o:p>

 

(I'm = assuming, but perhaps shouldn't, that when I comment like this it's as a = contributor)

 

From:= = Ira McDonald [blueroofmusic@gmail.com]
Sent: Thursday, = December 05, 2013 8:48 AM
To: Michael Hammer
Cc: dromasca@avaya.com; dbharrington@comcast.net; david.waltermire@nist.gov; Adam Montville; henk.birkholz@sit.fraunhofer.de; sacm@ietf.org
Subject: Re: [sacm] FW: = New Version Notification for = draft-ietf-sacm-use-cases-05.txt

Hi,

=

My two = cents - End User, Operator, and Administrator are quite = distinct

roles of = actors in standards from many SDOs - they have = inherently

distinct = default privileges - using these common role terms = consistently

would make SACM = use cases more accessible to non-participants in
the SACM = WG.

BTW - there = are a few other roles of actors that should probably = be

used in = SACM use cases, e.g., Application - although tthat's a = slippery

slope, = because normal applications (browsers, email readers, = etc.)

have very = different privileges and responsibilities from = security-specific

applications (MDM = agents, anti-virus scanners, etc.).

Cheers,=

- = Ira


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

 <= /p>

On Thu, Dec = 5, 2013 at 9:12 AM, Michael Hammer <michael.hammer@yaanatech.com> = wrote:

Actor = connotes human to me.

What would be wrong with using client or = server if asymmetric, or user agent
if peering?
With adjectives to = differentiate types.

Mike



----= -Original Message-----
From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Romascanu, Dan = (Dan)
Sent: Thursday, December 05, 2013 4:52 AM
To: David = Harrington; 'Waltermire, David A.'; 'Adam Montville'; = 'Henk
Birkholz'; sacm@ietf.org
Subject: Re: [sacm] FW: New = Version Notification for
draft-ietf-sacm-use-cases-05.txt

I = share DBH's concern. There may be significant differences in workflows = and
interface requirements between systems (networks, devices) and = humans vs.
systems (networks, devices) and applications. There may be = significant
differences if the humans are operators or end-users. = Using one term (say
'actor') for all may create ambiguities. I am not = sure that I understand the
advantages of the proposed = abstraction.

Dan
(speaking as contributor)


> = -----Original Message-----
> From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of David = Harrington
> Sent: Thursday, December 05, 2013 7:11 AM
> To: = 'Waltermire, David A.'; 'Adam Montville'; 'Henk Birkholz';
> sacm@ietf.org
> Subject: Re: [sacm] FW: New = Version Notification for draft-ietf-sacm-
> = use-cases-05.txt
>
> Hi,
>
> Using actor = concerns me.
> I find it important to understand whether some = content needs to be
> parsed by a human (with our wonderful = ability to parse), or a computer
> application (which is bound by = a set of rules, and has great difficulty
> when the content is not = consistent with the rules).
>
> Around 2003, the operators = made it clear that CLIs were difficult to
> work with, because = queries would return information in variable formats.
> While = humans might be able to parse the output that might change from
> = vendor to vendor, model to model, and release to release, tools = had
> significant difficulty due to the lack of standardization. = Operators
> could try to deal with the lack of standardization by = writing expect
> scripts, but they would need to be updated = constantly because what
> worked for one release of a product = might not be the same in the next
> release.
> Humans can = parse variable syntax, such as the natural language content
> of = syslog, but applications can have a hard time.
>
> I think = is very important to know whether we are designing something for
> = human consumption or for computer consumption.
> "Actor" = doesn't provide enough differentiation to know how to design our
> = solutions.
>
> David Harrington
> dbharrington@comcast.net
> +1-603-828-1401
>
> > -----Original = Message-----
> > From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of = Waltermire,
> > David A.
> > Sent: Wednesday, December = 04, 2013 8:54 PM
> > To: Adam Montville; Henk Birkholz; sacm@ietf.org
> > Subject: Re: [sacm] FW: = New Version Notification for
> > draft-ietf-sacm-use- = cases-05.txt
> >
> > Comments inline.
> = >
> > > -----Original Message-----
> > > = From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Adam
> = > > Montville
> > > Sent: Wednesday, December 04, 2013 = 8:38 PM
> > > To: Henk Birkholz; sacm@ietf.org
> > > Subject: Re: = [sacm] FW: New Version Notification for
> = draft-ietf-sacm-use-
> > > cases-05.txt
> > = >
> > > Something I've found helpful in the past is to = abstract a bit
> > > further
> from
> > > = "user", "operator", "application" and = simply reference all of them
> > > at
> once
> = > > with the term "actor".
> >
> > Are = we ok with the change to using actor? The current usage of = "user",
> > "operator", = "application" (specifically the last two) was suggested = a
> while
> > back to align with IETF terminology. Does = use of "actor" to reference
> > all
> = three
> > concepts raise any concerns?
> >
> = > > I also believe that listing *potential* acquisition methods = is
> > > useful in
> at least
> > > the = following way: Including a multitude of acquisition methods
> > = > clearly
> > signals
> > > our intent of = finding information where it already exists, while not
> > > = necessarily precluding our ability to *get* information when
> = > > information does not exist.
> >
> > Adam, = would you or Henk provide some example acquisition methods for
> = > discussion?
> >
> > > Finally, I, too, like = the notion of a work-flow scenario.  I don't
> > > = want
> to be
> > the
> > > one drawing a = process diagram in an RFC, though. ;-)
> >
> > How = would this differ from the workflow scenario text in section 2?
> = >
> > Are you suggesting representing this text in a visual = form? If so,
> > would anyone like to make a contribution of = some ascii art?
> >
> > > awm
> > > = ________________________________________
> > > From: sacm = [sacm-bounces@ietf.org] on behalf of Henk = Birkholz
> > > [henk.birkholz@sit.fraunhofer.de]
> > > = Sent: Friday, November 22, 2013 3:27 AM
> > > To: sacm@ietf.org
> > > Subject: Re: = [sacm] FW: New Version Notification for
> = draft-ietf-sacm-use-
> > > cases-05.txt
> > = >
> > > Regarding the first two question in section = 2:
> > >
> > > 1.) Security automation today = often supports the user/operator, I
> think.
> > > = There are cases a security-process can be fully automated, of
> = > > course,
> and in
> > > order to manage the = sheer amount of security related system events
> > > = automation is essential, but it seems to me that the complexity = and
> > > heterogeneity of root-causes (that might trigger = the work-flow) make
> > > the inclusion of a user/operator = necessary.
> > >
> > > 2.) To include = acquisition methods can provide an intuitive insight
> about = the
> > > scope and intend of the endpoint posture = assessment domain, I think.
> > > On one hand, that might = bloat the use-case document a bit (and maybe
> > = renders
> > > the title "sacm use cases" too = specific?). On the other hand, I like
> > > the inclusion of = a work-flow scenario and I think it is a good place
> > > = to
> highlight
> > > acquisition methods.
> > = >
> > > - Henk
> > >
> > > On = 11/21/2013 12:27 AM, Waltermire, David A. wrote:
> > > > = I just posted an updated use case draft based on the editorial
> = sessions
> > > during the IETF 88 meeting in Vancouver, BC, = Canada. My thanks to
> > > all
> that
> > = > provided input.
> > > >
> > > > I = used the word version that we edited as a starting point. Here
> = > > > is
> what I
> > > did:
> > = > >
> > > > - I worked through the use cases we = planned to remove and made
> > > > sure
> > = to
> > > merge in any concepts that would be lost. If you = submitted a
> > > previous
> use
> > > = case that was removed, please double check that I didn't miss
> = anything.
> > > > - I broke up "Endpoint = Identification and Assessment" into 3
> > > > = distinct
> and
> > > somewhat separable use cases: = "Endpoint Identification and
> > > Assessment = Planning", "Endpoint Posture Attribute Value = Collection",
> > > "Posture Evaluation". = Please let me know what you think about this
> change.
> = > > > - Addressed some aspects of the discussion thread based = on the
> > > > working
> > > session changes. = Please provide any suggested edits for aspects that
> > > = I
> > might
> > > have missed or got wrong.
> = > > >
> > > > The rest of the changes can be = found in the draft's change log.
> > > >
> > = > > If possible, I'd like to get to a fairly stable place with = this
> > > > draft
> in the next
> > > = revision or two to allow for progress to be made on the
> > = > requirements. In addition to the embedded questions in the = document,
> > > I'd like to focus on
> > = the
> > > following questions:
> > > = >
> > > > Is the draft approachable for a newcomer to = the effort? Do you see
> > > > the
> > > = updated use case structure as an improvement?
> > > > = Does this draft paint a complete enough picture? Are we missing
> = > > > any
> > > important concepts?
> > = > > Is there anything you can't live with?
> > > = >
> > > > I hope to release at least one or two more = updates to this draft
> within the
> > > next few = weeks before the holidays catch up on us.  I know everyone
> = > > is busy; timely comments are appreciated to allow for a = quick
> > > turnaround on the next revision.
> > = > >
> > > > Thanks,
> > > > = Dave
> > > >
> > > > -----Original = Message-----
> > > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
> > > > = Sent: Wednesday, November 20, 2013 5:58 PM
> > > > To: = Waltermire, David A.; David Harrington
> > > > Subject: = New Version Notification for
> > > > = draft-ietf-sacm-use-cases-05.txt
> > > >
> > = > >
> > > > A new version of I-D, = draft-ietf-sacm-use-cases-05.txt has been
> > > successfully = submitted by David Waltermire and posted to the IETF
> > > = repository.
> > > >
> > > > Filename: =      draft-ietf-sacm-use-cases
> > > > = Revision:      05
> > > > Title:   =               Endpoint Security = Posture Assessment -
> Enterprise Use
> > Cases
> = > > > Creation date:         = 2013-11-20
> > > > Group:         =         sacm
> > > > Number of pages: = 24
> > > > URL:
> http://www.ietf.org/internet-drafts/draft-ietf-sacm-use= -
> > cases-
> > > 05.txt
> > > = > Status:
> http://datatracker.ietf.org/doc/draft-ietf-sacm-use-cas= es
> > > > Htmlized:
> http://tools.ietf.org/html/draft-ietf-sacm-use-cases-05=
> > > > Diff:
> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sacm-use-= cases-05
> > > >
> > > > = Abstract:
> > > >     This memo documents a = sampling of use cases for securely
> aggregating
> > > = >     configuration and operational data and evaluating = that data to
> > > >     determine an = organization's security posture.  From these
> = operational
> > > >     use cases, we can = derive common functional capabilities and
> > > >   =   requirements to guide development of vendor-neutral,
> = interoperable
> > > >     standards for = aggregating and evaluating data relevant to
> security
> = > > >     posture.
> > > >
> = > > >
> > > >
> > > >
> = > > > Please note that it may take a couple of minutes from the = time of
> > > submission until the htmlized version and diff = are available at
> tools.ietf.org.
> > > >
> = > > > The IETF Secretariat
> > > >
> > = > > _______________________________________________
> > = > > sacm mailing list
> > > > sacm@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/sacm
> = > > >
> > >
> > >
> > = >
> > > ...
> > >
> > > . . = .
> > > = _______________________________________________
> > > sacm = mailing list
> > > sacm@ietf.org
> > > https://www.ietf.org/mailman/listinfo/sacm
> = > _______________________________________________
> > sacm = mailing list
> > sacm@ietf.org
> > https://www.ietf.org/mailman/listinfo/sacm
><= br>> _______________________________________________
> sacm = mailing list
> sacm@ietf.org
> https://www.ietf.org/mailman/listinfo/sacm
_____= __________________________________________
sacm mailing list
sacm@ietf.org
https://www.ietf.org/mailman/listinfo/sacm


______________= _________________________________
sacm mailing list
sacm@ietf.org
https://www.ietf.org/mailman/listinfo/sacm

 <= /o:p>


...=

This = message and attachments may contain confidential information. If it = appears that this message was sent to you by mistake, any retention, = dissemination, distribution or copying of this message and attachments = is strictly prohibited. Please notify the sender immediately and = permanently delete the message and any attachments.
. . = .


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

 

------=_NextPart_000_0188_01CEF51A.B45D47D0-- From Adam.Montville@cisecurity.org Tue Dec 10 04:27:27 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF9541AE002 for ; Tue, 10 Dec 2013 04:27:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.898 X-Spam-Level: X-Spam-Status: No, score=-3.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PsrjHWsTlM_h for ; Tue, 10 Dec 2013 04:27:20 -0800 (PST) Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.251.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8DE821ADFA2 for ; Tue, 10 Dec 2013 04:27:19 -0800 (PST) Received: from [216.82.250.179:63158] by server-17.bemta-12.messagelabs.com id 9B/A6-18777-2A807A25; Tue, 10 Dec 2013 12:27:14 +0000 X-Env-Sender: Adam.Montville@cisecurity.org X-Msg-Ref: server-2.tower-210.messagelabs.com!1386678431!9842339!2 X-Originating-IP: [69.195.43.86] X-StarScan-Received: X-StarScan-Version: 6.9.16; banners=cisecurity.org,-,- X-VirusChecked: Checked Received: (qmail 20665 invoked from network); 10 Dec 2013 12:27:13 -0000 Received: from mail.msisac.org (HELO mail.msisac.org) (69.195.43.86) by server-2.tower-210.messagelabs.com with AES128-SHA encrypted SMTP; 10 Dec 2013 12:27:13 -0000 Received: from CISEXCHANGE1.msisac.org.local ([fe80::4f0:b68d:e779:38c3]) by CISEXCHANGE2.msisac.org.local ([::1]) with mapi id 14.02.0347.000; Tue, 10 Dec 2013 07:24:56 -0500 From: Adam Montville To: ietfdbh , 'Ira McDonald' , "'Waltermire, David A.'" Thread-Topic: [sacm] FW: New Version Notification for draft-ietf-sacm-use-cases-05.txt Thread-Index: AQHO9URh7wOa9sCMakiZ578Al+iLoppNWjoq Date: Tue, 10 Dec 2013 12:25:05 +0000 Message-ID: <05BCCEB107AF88469B9F99783D47C1D6065F5476@CISEXCHANGE1.msisac.org.local> References: <20131120225753.9031.68753.idtracker@ietfa.amsl.com> <528F23D0.3080504@sit.fraunhofer.de> <05BCCEB107AF88469B9F99783D47C1D6065E4769@CISEXCHANGE1.msisac.org.local> <025d01cef178$63f56840$2be038c0$@comcast.net> <9904FB1B0159DA42B0B887B7FA8119CA12952A08@AZ-FFEXMB04.global.avaya.com> <00C069FD01E0324C9FFCADF539701DB3BBF01B8D@sc9-ex2k10mb1.corp.yaanatech.com> <05BCCEB107AF88469B9F99783D47C1D6065EFE47@CISEXCHANGE1.msisac.org.local> <9904FB1B0159DA42B0B887B7FA8119CA129DBB1D@AZ-FFEXMB04.global.avaya.com> <4b451425cbec406d94fa1a82b32fa1ab@BLUPR09MB038.namprd09.prod.outlook.com> , <018701cef544$9d2ce730$d786b590$@comcast.net> In-Reply-To: <018701cef544$9d2ce730$d786b590$@comcast.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.252.39] Content-Type: multipart/alternative; boundary="_000_05BCCEB107AF88469B9F99783D47C1D6065F5476CISEXCHANGE1msi_" MIME-Version: 1.0 Cc: "sacm@ietf.org" Subject: Re: [sacm] FW: New Version Notification for draft-ietf-sacm-use-cases-05.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 12:27:27 -0000 --_000_05BCCEB107AF88469B9F99783D47C1D6065F5476CISEXCHANGE1msi_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thanks for pointing that out, David. This might be stylistic in some ways= , but these aren't titles they are roles. From that perspective we could = treat them as proper nouns, which would technically warrant capitalization= . But, better to stick with what the Editor would prefer, I think. Adam ________________________________ From: sacm [sacm-bounces@ietf.org] on behalf of ietfdbh [ietfdbh@comcast.n= et] Sent: Monday, December 09, 2013 7:08 PM To: 'Ira McDonald'; 'Waltermire, David A.' Cc: sacm@ietf.org Subject: Re: [sacm] FW: New Version Notification for draft-ietf-sacm-use-c= ases-05.txt Hi, I=92d have to go look up a reference, but I believe the rfc editor conside= rs it bad form to capitalize things that don=92t need to be capitalized. David Harrington ietfdbh@comcast.net +1-603-828-1401 From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Ira McDonald Sent: Monday, December 09, 2013 3:35 PM To: Waltermire, David A.; Ira McDonald Cc: sacm@ietf.org Subject: Re: [sacm] FW: New Version Notification for draft-ietf-sacm-use-c= ases-05.txt Hi Dave, I'm not sure if there's consensus about this, but I suggest that the curre= nt lowercase "operator", "administrator", etc. (e.g., in 2.1.1) should be titlecase (first letter capitalized). Also that a new section 1.1 Actors be added that defines these actor terms (one to three sentences each about what are typical actions or responsibilities for each actor). >From the original Design Goals for IPP (RFC 2567) here are some admittedly printing-specific definitions, but they give the right flavor: "3.1. END-USER An end-user of a printer accepting jobs through the Internet is one of the roles in which humans act. The end-user is the person that will submit a job to be printed on the printer. The wants and needs of the end-user are broken down into six categories: finding/locating a printer, creating a local instance of a printer, viewing printer status, viewing printer capabilities, submitting a print job, viewing print job status, altering the attributes of a print job. 3.2. OPERATOR An operator of a printer accepting jobs through the Internet is one of the roles in which humans act. The operator has the responsibility of monitoring the status of the printer as well as managing and controlling the jobs at the device. These responsibilities include but are not limited to the replenishing of supplies (ink, toner, paper, etc.), the clearing of minor errors (paper jams, etc.) and the re-prioritization of end-user jobs. Operator wants and needs will not be addressed by V1.0 of the protocol. The wants and needs of the operator include all those of the end-user but may include additional privileges. For example, an operator may be able to view all print jobs on a printer while the end-user might only be able to see his own jobs. 3.3. ADMINISTRATOR An administrator of a printer accepting jobs through the Internet is one of the roles in which humans act. The administrator has the =20 responsibility of creating the printer instances and controlling the authorization of other end-users and operators. Administrator wants and needs will not be addressed by V1.0 of the protocol. The wants and needs of the administrator include all those of the end-user and, in some environments, some or all of those of the operator. Minimally, the administrator must also have the tools, programs, utilities and supporting protocols available to be able to: - create an instance of a printer - create, edit and maintain the list of authorized end-users - create, edit and maintain the list of authorized operators - create, edit and maintain the list of authorized administrators - create, customize, change or otherwise alter the manner in which the status capabilities and other information about printers and jobs are presented - create, customize, or change other printer or job features - administrate billing or other charge-back mechanisms - create sets of defaults - create sets of capabilities The administrator must have the capability to perform all the above tasks locally or remotely to the printer." >From later IPP Get-Notifications (RFC 3997), here are much shorter definitions: "2.1. Job-Submitting End User A human end user who submits a print job to an IPP Printer. This person may or may not be within the same security domain as the Printer. This person may or may not be geographically near the printer. 2.2. Administrator A human user who established policy for and configures the print system. 2.3. Operator A human user who carries out the policy established by the Administrator and controls the day-to-day running of the print system." As Nancy said, we need also: Application, System. Cheers, - Ira Ira McDonald (Musician / Software Architect) Co-Chair - TCG Trusted Mobility Solutions WG Chair - Linux Foundation Open Printing WG Secretary - IEEE-ISTO Printer Working Group Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG IETF Designated Expert - IPP & Printer MIB Blue Roof Music / High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto: blueroofmusic@gmail.com Winter 579 Park Place Saline, MI 48176 734-944-0094 Summer PO Box 221 Grand Marais, MI 49839 906-494-2434 On Mon, Dec 9, 2013 at 3:12 PM, Waltermire, David A. > wrote: +1. I too like this approach. This has been a good discussion. To direct this dialog towards actionable changes to the use cases draft, i= s there specific draft text that should be updated to make the roles and t= heir relevance to a use case or usage scenario more clear? Thanks, Dave From: sacm [mailto:sacm-bounces@ietf.org] On= Behalf Of Kent_Landfield@McAfee.com Sent: Sunday, December 08, 2013 12:20 PM To: sacm@ietf.org Subject: Re: [sacm] FW: New Version Notification for draft-ietf-sacm-use-c= ases-05.txt +1 I like the terminology Ira and Adam have suggested. Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: , "Dan (Dan)" > Date: Sunday, December 8, 2013 7:43 AM To: Adam Montville >, Ira McDonald >, Michael Hammer > Cc: "dbharrington@comcast.net" >, David Waltermire >, "sacm@ietf.org" >, "henk.birkholz= @sit.fraunhofer.de" > Subject: Re: [sacm] FW: New Version Notification for draft-ietf-sacm-use-c= ases-05.txt +1 Dan Speaking as contributor =96 better to say it clearly if there are reasons = to wonder From: Adam Montville [mailto:Adam.Montville@cisecurity.org] Sent: Friday, December 06, 2013 3:12 AM To: Ira McDonald; Michael Hammer Cc: Romascanu, Dan (Dan); dbharrington@comcast.net; david.waltermire@nist.gov; he= nk.birkholz@sit.fraunhofer.de; sac= m@ietf.org Subject: RE: [sacm] FW: New Version Notification for draft-ietf-sacm-use-c= ases-05.txt I like this set of terminology. End User, Operator, Administrator, and Ap= plication. Then, Application can potentially have further specification a= s we move forward. For example, Analysis Application, Acquisition Applica= tion, and so on. Whatever we choose, I would prefer to choose terms that we can easily use = consistently. Adam (I'm assuming, but perhaps shouldn't, that when I comment like this it's a= s a contributor) ________________________________ From: Ira McDonald [blueroofmusic@gmail.com] Sent: Thursday, December 05, 2013 8:48 AM To: Michael Hammer Cc: dromasca@avaya.com; dbharrington@comcast.ne= t; david.waltermire@nist.gov; Adam Montville; henk.birkholz@sit.fraunhofer.de; sacm@ietf.org Subject: Re: [sacm] FW: New Version Notification for draft-ietf-sacm-use-c= ases-05.txt Hi, My two cents - End User, Operator, and Administrator are quite distinct roles of actors in standards from many SDOs - they have inherently distinct default privileges - using these common role terms consistently would make SACM use cases more accessible to non-participants in the SACM WG. BTW - there are a few other roles of actors that should probably be used in SACM use cases, e.g., Application - although tthat's a slippery slope, because normal applications (browsers, email readers, etc.) have very different privileges and responsibilities from security-specific= applications (MDM agents, anti-virus scanners, etc.). Cheers, - Ira Ira McDonald (Musician / Software Architect) Co-Chair - TCG Trusted Mobility Solutions WG Chair - Linux Foundation Open Printing WG Secretary - IEEE-ISTO Printer Working Group Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG IETF Designated Expert - IPP & Printer MIB Blue Roof Music / High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto: blueroofmusic@gmail.com Winter 579 Park Place Saline, MI 48176 734-944-0094 Summer PO Box 221 Grand Marais, MI 49839 906-494-2434= On Thu, Dec 5, 2013 at 9:12 AM, Michael Hammer > wrote: Actor connotes human to me. What would be wrong with using client or server if asymmetric, or user age= nt if peering? With adjectives to differentiate types. Mike -----Original Message----- From: sacm [mailto:sacm-bounces@ietf.org] On= Behalf Of Romascanu, Dan (Dan) Sent: Thursday, December 05, 2013 4:52 AM To: David Harrington; 'Waltermire, David A.'; 'Adam Montville'; 'Henk Birkholz'; sacm@ietf.org Subject: Re: [sacm] FW: New Version Notification for draft-ietf-sacm-use-cases-05.txt I share DBH's concern. There may be significant differences in workflows a= nd interface requirements between systems (networks, devices) and humans vs. systems (networks, devices) and applications. There may be significant differences if the humans are operators or end-users. Using one term (say 'actor') for all may create ambiguities. I am not sure that I understand t= he advantages of the proposed abstraction. Dan (speaking as contributor) > -----Original Message----- > From: sacm [mailto:sacm-bounces@ietf.org] = On Behalf Of David Harrington > Sent: Thursday, December 05, 2013 7:11 AM > To: 'Waltermire, David A.'; 'Adam Montville'; 'Henk Birkholz'; > sacm@ietf.org > Subject: Re: [sacm] FW: New Version Notification for draft-ietf-sacm- > use-cases-05.txt > > Hi, > > Using actor concerns me. > I find it important to understand whether some content needs to be > parsed by a human (with our wonderful ability to parse), or a computer > application (which is bound by a set of rules, and has great difficulty > when the content is not consistent with the rules). > > Around 2003, the operators made it clear that CLIs were difficult to > work with, because queries would return information in variable formats.= > While humans might be able to parse the output that might change from > vendor to vendor, model to model, and release to release, tools had > significant difficulty due to the lack of standardization. Operators > could try to deal with the lack of standardization by writing expect > scripts, but they would need to be updated constantly because what > worked for one release of a product might not be the same in the next > release. > Humans can parse variable syntax, such as the natural language content > of syslog, but applications can have a hard time. > > I think is very important to know whether we are designing something for= > human consumption or for computer consumption. > "Actor" doesn't provide enough differentiation to know how to design our= > solutions. > > David Harrington > dbharrington@comcast.net > +1-603-828-1401 > > > -----Original Message----- > > From: sacm [mailto:sacm-bounces@ietf.org= ] On Behalf Of Waltermire, > > David A. > > Sent: Wednesday, December 04, 2013 8:54 PM > > To: Adam Montville; Henk Birkholz; sacm@ietf.org= > > Subject: Re: [sacm] FW: New Version Notification for > > draft-ietf-sacm-use- cases-05.txt > > > > Comments inline. > > > > > -----Original Message----- > > > From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Adam > > > Montville > > > Sent: Wednesday, December 04, 2013 8:38 PM > > > To: Henk Birkholz; sacm@ietf.org > > > Subject: Re: [sacm] FW: New Version Notification for > draft-ietf-sacm-use- > > > cases-05.txt > > > > > > Something I've found helpful in the past is to abstract a bit > > > further > from > > > "user", "operator", "application" and simply reference all of them > > > at > once > > > with the term "actor". > > > > Are we ok with the change to using actor? The current usage of "user",= > > "operator", "application" (specifically the last two) was suggested a > while > > back to align with IETF terminology. Does use of "actor" to reference > > all > three > > concepts raise any concerns? > > > > > I also believe that listing *potential* acquisition methods is > > > useful in > at least > > > the following way: Including a multitude of acquisition methods > > > clearly > > signals > > > our intent of finding information where it already exists, while not= > > > necessarily precluding our ability to *get* information when > > > information does not exist. > > > > Adam, would you or Henk provide some example acquisition methods for > > discussion? > > > > > Finally, I, too, like the notion of a work-flow scenario. I don't > > > want > to be > > the > > > one drawing a process diagram in an RFC, though. ;-) > > > > How would this differ from the workflow scenario text in section 2? > > > > Are you suggesting representing this text in a visual form? If so, > > would anyone like to make a contribution of some ascii art? > > > > > awm > > > ________________________________________ > > > From: sacm [sacm-bounces@ietf.org] on = behalf of Henk Birkholz > > > [henk.birkholz@sit.fraunhofer.de] > > > Sent: Friday, November 22, 2013 3:27 AM > > > To: sacm@ietf.org > > > Subject: Re: [sacm] FW: New Version Notification for > draft-ietf-sacm-use- > > > cases-05.txt > > > > > > Regarding the first two question in section 2: > > > > > > 1.) Security automation today often supports the user/operator, I > think. > > > There are cases a security-process can be fully automated, of > > > course, > and in > > > order to manage the sheer amount of security related system events > > > automation is essential, but it seems to me that the complexity and > > > heterogeneity of root-causes (that might trigger the work-flow) make= > > > the inclusion of a user/operator necessary. > > > > > > 2.) To include acquisition methods can provide an intuitive insight > about the > > > scope and intend of the endpoint posture assessment domain, I think.= > > > On one hand, that might bloat the use-case document a bit (and maybe= > > renders > > > the title "sacm use cases" too specific?). On the other hand, I like= > > > the inclusion of a work-flow scenario and I think=20it is a good pla= ce > > > to > highlight > > > acquisition methods. > > > > > > - Henk > > > > > > On 11/21/2013 12:27 AM, Waltermire, David A. wrote: > > > > I just posted an updated use case draft based on the editorial > sessions > > > during the IETF 88 meeting in Vancouver, BC, Canada. My thanks to > > > all > that > > > provided input. > > > > > > > > I used the word version that we edited as a starting point. Here > > > > is > what I > > > did: > > > > > > > > - I worked through the use cases we planned to remove and made > > > > sure > > to > > > merge in any concepts that would be lost. If you submitted a > > > previous > use > > > case that was removed, please double check that I didn't miss > anything. > > > > - I broke up "Endpoint Identification and Assessment" into 3 > > > > distinct > and > > > somewhat separable use cases: "Endpoint Identification and > > > Assessment Planning", "Endpoint Posture Attribute Value Collection",= > > > "Posture Evaluation". Please let me know what you think about this > change. > > > > - Addressed some aspects of the discussion thread based on the > > > > working > > > session changes. Please provide any suggested edits for aspects that= > > > I > > might > > > have missed or got wrong. > > > > > > > > The rest of the changes can be found in the draft's change log. > > > > > > > > If possible, I'd like to get to a fairly stable place with this > > > > draft > in the next > > > revision or two to allow for progress to be made on the > > > requirements. In addition to the embedded questions in the document,= > > > I'd like to focus on > > the > > > following questions: > > > > > > > > Is the draft approachable for a newcomer to the effort? Do you see= > > > > the > > > updated use case structure as an improvement? > > > > Does this draft paint a complete enough picture? Are we missing > > > > any > > > important concepts? > > > > Is there anything you can't live with? > > > > > > > > I hope to release at least one or two more updates to this draft > within the > > > next few weeks before the holidays catch up on us. I know everyone > > > is busy; timely comments are appreciated to allow for a quick > > > turnaround on the next revision. > > > > > > > > Thanks, > > > > Dave > > > > > > > > -----Original Message----- > > > > From: internet-drafts@ietf.org [m= ailto:internet-drafts@ietf.org] > > > > Sent: Wednesday, November 20, 2013 5:58 PM > > > > To: Waltermire, David A.; David Harrington > > > > Subject: New Version Notification for > > > > draft-ietf-sacm-use-cases-05.txt > > > > > > > > > > > > A new version of I-D, draft-ietf-sacm-use-cases-05.txt has been > > > successfully submitted by David Waltermire and posted to the IETF > > > repository. > > > > > > > > Filename: draft-ietf-sacm-use-cases > > > > Revision: 05 > > > > Title: Endpoint Security Posture Assessment - > Enterprise Use > > Cases > > > > Creation date: 2013-11-20 > > > > Group: sacm > > > > Number of pages: 24 > > > > URL: > http://www.ietf.org/internet-drafts/draft-ietf-sacm-use- > > cases- > > > 05.txt > > > > Status: > http://datatracker.ietf.org/doc/draft-ietf-sacm-use-cases > > > > Htmlized: > http://tools.ietf.org/html/draft-ietf-sacm-use-cases-05 > > > > Diff: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sacm-use-cases-05 > > > > > > > > Abstract: > > > > This memo documents a sampling of use cases for securely > aggregating > > > > configuration and operational data and evaluating that data to= > > > > determine an organization's security posture. From these > operational > > > > use cases, we can derive common functional capabilities and > > > > requirements to guide development of vendor-neutral, > interoperable > > > > standards for aggregating and evaluating data relevant to > security > > > > posture. > > > > > > > > > > > > > > > > > > > > Please note that it may take a couple of minutes from the time of > > > submission until the htmlized version and diff are available at > tools.ietf.org. > > > > > > > > The IETF Secretariat > > > > > > > > _______________________________________________ > > > > sacm mailing list > > > > sacm@ietf.org > > > > https://www.ietf.org/mailman/listinfo/sacm > > > > > > > > > > > > > > > > ... > > > > > > . . . > > > _______________________________________________ > > > sacm mailing list > > > sacm@ietf.org > > > https://www.ietf.org/mailman/listinfo/sacm > > _______________________________________________ > > sacm mailing list > > sacm@ietf.org > > https://www.ietf.org/mailman/listinfo/sacm > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm ... This message and attachments may contain confidential information. If it a= ppears that this message was sent to you by mistake, any retention, dissem= ination, distribution or copying of this message and attachments is strict= ly prohibited. Please notify the sender immediately and permanently delete= the message and any attachments. . . . _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm ... . . . --_000_05BCCEB107AF88469B9F99783D47C1D6065F5476CISEXCHANGE1msi_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Thanks for pointing that out, David.  This might be stylistic= in some ways, but these aren't titles they are roles.  From that per= spective we could treat them as proper nouns, which would technically warrant capitalization.  But, better to stick with= what the Editor would prefer, I think.

Adam

From: sacm [sacm-bounces@ietf.org] on b= ehalf of ietfdbh [ietfdbh@comcast.net]
Sent: Monday, December 09, 2013 7:08 PM
To: 'Ira McDonald'; 'Waltermire, David A.'
Cc: sacm@ietf.org
Subject: Re: [sacm] FW: New Version Notification for draft-ietf-sac= m-use-cases-05.txt

Hi,

 

I=92d have to go look= up a reference, but I believe the rfc editor considers it bad form to cap= italize things that don=92t need to be capitalized.

 

 

David Harrington=

ietfdbh@comcast.net

+1-603-828-1401

From: sac= m [mailto:sacm-bounces@ietf.org] On Behalf Of Ira McDonald
Sent: Monday, December 09, 2013 3:35 PM
To: Waltermire, David A.; Ira McDonald
Cc: sacm@ietf.org
Subject: Re: [sacm] FW: New Version Notification for draft-ietf-sac= m-use-cases-05.txt

 

Hi Dave,

I'm not sure if there's consensus about this, but I= suggest that the current

lowercase "operator", "administrator= ", etc. (e.g., in 2.1.1) should be

titlecase (first let= ter capitalized).

Also that a new sect= ion 1.1 Actors be added that defines these actor
terms (one to three sentences each about what are typical actions or
responsibilities for each actor).

From the original De= sign Goals for IPP (RFC 2567) here are some
admittedly printing-specific definitions, but they give the right flavor:<= br>
"3.1. END-USER

   An end-user of a printer accepting jobs through the Internet = is one
   of the roles in which humans act.  The end-user is the p= erson that
   will submit a job to be printed on the printer.

   The wants and needs of the end-user are broken down into six<= br>    categories: finding/locating a printer, creating a local inst= ance of
   a printer, viewing printer status, viewing printer capabiliti= es,
   submitting a print job, viewing print job status, altering th= e
   attributes of a print job.

3.2. OPERATOR

   An operator of a printer accepting jobs through the Internet = is one
   of the roles in which humans act.  The operator has the<= br>    responsibility of monitoring the status of the printer as wel= l as
   managing and controlling the jobs at the device.  These<= br>    responsibilities include but are not limited to the replenish= ing of
   supplies (ink, toner, paper, etc.), the clearing of minor err= ors
   (paper jams, etc.) and the re-prioritization of end-user jobs= .
   Operator wants and needs will not be addressed by V1.0 of the=
   protocol.

   The wants and needs of the operator include all those of the = end-user
   but may include additional privileges.  For example, an = operator may
   be able to view all print jobs on a printer while the end-use= r might
   only be able to see his own jobs.

3.3. ADMINISTRATOR

   An administrator of a printer accepting jobs through the Inte= rnet is
   one of the roles in which humans act.  The administrator= has the
   responsibility of creating the printer instances and controll= ing the
   authorization of other end-users and operators.  Adminis= trator wants
   and needs will not be addressed by V1.0 of the protocol.

   The wants and needs of the administrator include all those of= the
   end-user and, in some environments, some or all of those of t= he
   operator.  Minimally, the administrator must also have t= he tools,
   programs, utilities and supporting protocols available to be = able to:

   - create an instance of a printer
   - create, edit and maintain the list of authorized end-users<= br>    - create, edit and maintain the list of authorized operators<= br>    - create, edit and maintain the list of authorized
     administrators
   - create, customize, change or otherwise alter the manner in<= br>      which the status capabilities and other informati= on about printers
     and jobs are presented
   - create, customize, or change other printer or job features<= br>    - administrate billing or other charge-back mechanisms
   - create sets of defaults
   - create sets of capabilities

   The administrator must have the capability to perform all the= above
   tasks locally or remotely to the printer."

From later IPP Get-Notifications (RFC 3997), here a= re much shorter

definitions:

"2.1.  Job-Submitting End User

   A human end user who submits a print job to an IPP Printer.&n= bsp; This
   person may or may not be within the same security domain as t= he
   Printer.  This person may or may not be geographically n= ear the
   printer.

2.2.  Administrator

   A human user who established policy for and configures the pr= int
   system.

2.3.  Operator

   A human user who carries out the policy established by the    Administrator and controls the day-to-day running of the prin= t
   system."

As Nancy said, we ne= ed also:  Application, System.

Cheers,

- Ira


Ira McDonald (Musici= an / Software Architect)
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music / High=20North Inc
<= span style=3D"color:#3333FF">http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto: bluer= oofmusic@gmail.com
Winter  579 Park Place  Saline, MI  48176  734-944-009= 4
Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434

 

On Mon, Dec 9, 2013 at 3:12 PM, Waltermire, David A= . <david= .waltermire@nist.gov> wrote:

+1. I = too like this approach. This has been a good discussion.

 

To direct = this dialog towards actionable changes to the use cases draft, is there sp= ecific draft text that should be updated to make the roles and their relevance to a use case or usage scenario more clear?

 

Thanks,

Dave

 

From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Kent_Landfield@McAfee.com
Sent: Sunday, December 08, 2013 12:20 PM


To: sacm@ietf.or= g
Subject: Re: [sacm] FW: New Version Notification for draft-ietf-sac= m-use-cases-05.txt

 

+1

 

I like the terminology Ira and Adam have= suggested.

 

Kent = Landfield

McAfee | An Intel Company
Direct: +1.972.963= .7096 
Mobile: +1.817.637= .8026
Web: www.mcafee.com

 

 

+1

 

Dan=

 

Speaking a= s contributor =96 better to say it clearly if there are reasons to wonder<= /span>

 

 

From: Adam Montville [mailto:Adam.Montville@cisecurity.org]
Sent: Friday, December 06, 2013 3:12 AM
To: Ira McDonald; Michael Hammer
Cc: Romascanu, Dan (Dan); dbharrington@comcast.net; david.waltermire@nist.gov; henk.birkholz@sit.fraunhofer.de; sacm@ietf.org
Subject: RE: [sacm] FW: New Version Notification for draft-ietf-sac= m-use-cases-05.txt

 

I like this set of termino= logy.  End User, Operator, Administrator, and Application.  Then= , Application can potentially have further specification as we move forwar= d.  For example, Analysis Application, Acquisition Application, and so = on.  

 

Whatever we choose, I woul= d prefer to choose terms that we can easily use consistently. 

 

Adam

 

(I'm assuming, but perhaps= shouldn't, that when I comment like this it's as a contributor)

 

Fro= m: Ira McDonald [blueroofmusic@gmail.com]
Sent: Thursday, December 05, 2013 8:48 AM
To: Michael Hammer
Cc: dromasc= a@avaya.com; dbharrington= @comcast.net; david.walte= rmire@nist.gov; Adam Montville; henk.= birkholz@sit.fraunhofer.de; sacm@ietf.org
Subject: Re: [sacm] FW: New Version Notification for draft-ietf-sac= m-use-cases-05.txt

Hi,

My two cents - End User, Operator, and A= dministrator are quite distinct

roles of actors in standards from many S= DOs - they have inherently

distinct default privileges - using thes= e common role terms consistently

would make SACM use = cases more accessible to non-participants in
the SACM WG.

BTW - there are a few other roles of act= ors that should probably be

used in SACM use cases, e.g., Applicatio= n - although tthat's a slippery

slope, because normal applications (brow= sers, email readers, etc.)

have very different privileges and respo= nsibilities from security-specific

applications (MDM ag= ents, anti-virus scanners, etc.).

Cheers,

- Ira


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

 

On Thu, Dec 5, 2013 at 9:12 AM, Michael = Hammer <michael.hammer@yaanatech.com> wrote:

Actor connotes human to me.

What would be wrong with using client or server if asymmetric, or user age= nt
if peering?
With adjectives to differentiate types.

Mike



-----Original Message-----
From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan)
Sent: Thursday, December 05, 2013 4:52 AM
To: David Harrington; 'Waltermire, David A.'; 'Adam Montville'; 'Henk
Birkholz'; sacm@ietf.or= g
Subject: Re: [sacm] FW: New Version Notification for
draft-ietf-sacm-use-cases-05.txt

I share DBH's concern. There may be significant differences in workflows a= nd
interface requirements between systems (networks, devices) and humans vs.<= br> systems (networks, devices) and applications. There may be significant
= differences if the humans are operators or end-users. Using one term (say<= br> 'actor') for all may create ambiguities. I am not sure that I understand t= he
advantages of the proposed abstraction.

Dan
(speaking as contributor)


> -----Original Message-----
> From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of David Harrington
> Sent: Thursday, December 05, 2013 7:11 AM
> To: 'Waltermire, David A.'; 'Adam Montville'; 'Henk Birkholz';
> sacm@ietf.org<= br> > Subject: Re: [sacm] FW: New Version Notification for draft-ietf-sacm-=
> use-cases-05.txt
>
> Hi,
>
> Using actor concerns me.
> I find it important to understand whether some content needs to be > parsed by a human (with our wonderful ability to parse), or a compute= r
> application (which is bound by a set of rules, and has great difficul= ty
> when the content is not consistent with the rules).
>
> Around 2003, the operators made it clear that CLIs were difficult to<= br> > work with, because queries would return information in variable forma= ts.
> While humans might be able to parse the output that might change from=
> vendor to vendor, model to model, and release to release, tools had > significant difficulty due to the lack of standardization. Operators<= br> > could try to deal with the lack of standardization by writing expect<= br> > scripts, but they would need to be updated constantly because what > worked for one release of a product might not be the same in the next=
> release.
> Humans can parse variable syntax, such as the natural language conten= t
> of syslog, but applications can have a hard time.
>
> I think is very important to know whether we are designing something = for
> human consumption or for computer consumption.
> "Actor" doesn't provide enough differentiation to know how = to design our
> solutions.
>
> David Harrington
> dbharri= ngton@comcast.net
> +1-603-828-14= 01
>
> > -----Original Message-----
> > From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Waltermire,
> > David A.
> > Sent: Wednesday, December 04, 2013 8:54 PM
> > To: Adam Montville; Henk Birkholz; sacm@ietf.org
> > Subject: Re: [sacm] FW: New Version Notification for
> > draft-ietf-sacm-use- cases-05.txt
> >
> > Comments inline.
> >
> > > -----Original Message-----
> > > From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Adam
> > > Montville
> > > Sent: Wednesday, December 04, 2013 8:38 PM
> > > To: Henk Birkholz; sacm@ietf.org
> > > Subject: Re: [sacm] FW: New Version Notification for
> draft-ietf-sacm-use-
> > > cases-05.txt
> > >
> > > Something I've found helpful in the past is to abstract a b= it
> > > further
> from
> > > "user", "operator", "application&q= uot; and simply reference all of them
> > > at
> once
> > > with the term "actor".
> >
> > Are we ok with the change to using actor? The current usage of &= quot;user",
> > "operator", "application" (specifically the = last two) was suggested a
> while
> > back to align with IETF terminology. Does use of "actor&quo= t; to reference
> > all
> three
> > concepts raise any concerns?
> >
> > > I also believe that listing *potential* acquisition methods= is
> > > useful in
> at least
> > > the following way: Including a multitude of acquisition met= hods
> > > clearly
> > signals
> > > our intent of finding information where it already exists, = while not
> > > necessarily precluding our ability to *get* information whe= n
> > > information does not exist.
> >
> > Adam, would you or Henk provide some example acquisition methods= for
> > discussion?
> >
> > > Finally, I, too, like the notion of a work-flow scenario. &= nbsp;I don't
> > > want
> to be
> > the
> > > one drawing a process diagram in an RFC, though. ;-)
> >
> > How would this differ from the workflow scenario text in section= 2?
> >
> > Are you suggesting representing this text in a visual form? If s= o,
> > would anyone like to make a contribution of some ascii art?
> >
> > > awm
> > > ________________________________________
> > > From: sacm [sacm-bounces@ietf.org] on behalf of Henk Birkholz
> > > [henk.birkholz@sit.fraunhofer.de]
> > > Sent: Friday, November 22, 2013 3:27 AM
> > > To: sacm= @ietf.org
> > > Subject: Re: [sacm] FW: New Version Notification for
> draft-ietf-sacm-use-
> > > cases-05.txt
> > >
> > > Regarding the first two question in section 2:
> > >
> > > 1.) Security automation today often supports the user/opera= tor, I
> think.
> > > There are cases a security-process can be fully automated, = of
> > > course,
> and in
> > > order to manage the sheer amount of security related system= events
> > > automation is essential, but it seems to me that the comple= xity and
> > > heterogeneity of root-causes (that might trigger the work-f= low) make
> > > the inclusion of a user/operator necessary.
> > >
> > > 2.) To include acquisition methods can provide an intuitive= insight
> about the
> > > scope and intend of the endpoint posture assessment domain,= I think.
> > > On one hand, that might bloat the use-case document a bit (= and maybe
> > renders
> > > the title "sacm use cases" too specific?). On the= other hand, I like
> > > the inclusion of a work-flow scenario and I think it is a g= ood place
> > > to
> highlight
> > > acquisition methods.
> > >
> > > - Henk
> > >
> > > On 11/21/2013 12:27 AM, Waltermire, David A. wrote:
> > > > I just posted an updated use case draft based on the e= ditorial
> sessions
> > > during the IETF 88 meeting in Vancouver, BC, Canada. My tha= nks to
> > > all
> that
> > > provided input.
> > > >
> > > > I used the word version that we edited as a starting p= oint. Here
> > > > is
> what I
> > > did:
> > > >
> > > > - I worked through the use cases we planned to remove = and made
> > > > sure
> > to
> > > merge in any concepts that would be lost. If you submitted = a
> > > previous
> use
> > > case that was removed, please double check that I didn't mi= ss
> anything.
> > > > - I broke up "Endpoint Identification and Assessm= ent" into 3
> > > > distinct
> and
> > > somewhat separable use cases: "Endpoint Identification= and
> > > Assessment Planning", "Endpoint Posture Attribute= Value Collection",
> > > "Posture Evaluation". Please let me know what you= think about this
> change.
> > > > - Addressed some aspects of the discussion thread base= d on the
> > > > working
> > > session changes. Please provide any suggested edits for asp= ects that
> > > I
> > might
> > > have missed or got wrong.
> > > >
> > > > The rest of the changes can be found in the draft's ch= ange log.
> > > >
> > > > If possible, I'd like to get to a fairly stable place = with this
> > > > draft
> in the next
> > > revision or two to allow for progress to be made on the
= > > > requirements. In addition to the embedded questions in the = document,
> > > I'd like to focus on
> > the
> > > following questions:
> > > >
> > > > Is the draft approachable for a newcomer to the effort= ? Do you see
> > > > the
> > > updated use case structure as an improvement?
> > > > Does this draft paint a complete enough picture? Are w= e missing
> > > > any
> > > important concepts?
> > > > Is there anything you can't live with?
> > > >
> > > > I hope to release at least one or two more updates to = this draft
> within the
> > > next few weeks before the holidays catch up on us.  I = know everyone
> > > is busy; timely comments are appreciated to allow for a qui= ck
> > > turnaround on the next revision.
> > > >
> > > > Thanks,
> > > > Dave
> > > >
> > > > -----Original Message-----
> > > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
> > > > Sent: Wednesday, November 20, 2013 5:58 PM
> > > > To: Waltermire, David A.; David Harrington
> > > > Subject: New Version Notification for
> > > > draft-ietf-sacm-use-cases-05.txt
> > > >
> > > >
> > > > A new version of I-D, draft-ietf-sacm-use-cases-05.txt= has been
> > > successfully submitted by David Waltermire and posted to th= e IETF
> > > repository.
> > > >
> > > > Filename:      draft-ietf-sacm-use-case= s
> > > > Revision:      05
> > > > Title:              = ;   Endpoint Security Posture Assessment -
> Enterprise Use
> > Cases
> > > > Creation date:         2013-11-20<= br> > > > > Group:              = ;   sacm
> > > > Number of pages: 24
> > > > URL:
> http://www.ietf.org/internet-drafts/draft-ietf-sacm-use-
> > cases-
> > > 05.txt
> > > > Status:
> http://datatracker.ietf.org/doc/draft-ietf-sacm-use-cases
> > > > Htmlized:
> http://tools.ietf.org/html/draft-ietf-sacm-use-cases-05
> > > > Diff:
> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sacm-use-cases-05
> > > >
> > > > Abstract:
> > > >     This memo documents a sampling of use ca= ses for securely
> aggregating
> > > >     configuration and operational data and e= valuating that data to
> > > >     determine an organization's security pos= ture.  From these
> operational
> > > >     use cases, we can derive common function= al capabilities and
> > > >     requirements to guide development of ven= dor-neutral,
> interoperable
> > > >     standards for aggregating and evaluating= data relevant to
> security
> > > >     posture.
> > > >
> > > >
> > > >
> > > >
> > > > Please note that it may take a couple of minutes from = the time of
> > > submission until the htmlized version and diff are availabl= e at
> tools.ietf.org.
> > > >
> > > > The IETF Secretariat
> > > >
> > > > _______________________________________________
> > > > sacm mailing list
> > > > sac= m@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/sacm
> > > >
> > >
> > >
> > >
> > > ...
> > >
> > > . . .
> > > _______________________________________________
> > > sacm mailing list
> > > sacm@iet= f.org
> > > https://www.ietf.org/mailman/listinfo/sacm
> > _______________________________________________
> > sacm mailing list
> > sacm@ietf.org=
> > https://www.ietf.org/mailman/listinfo/sacm
>
> _______________________________________________
> sacm mailing list
> sacm@ietf.org<= br> > https://www.ietf.org/mailman/listinfo/sacm
_______________________________________________
sacm mailing list
sacm@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/sacm


_______________________________________________
sacm mailing list
sacm@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/sacm

 


...

This message and attachments may contain= confidential information. If it appears that this message was sent to you= by mistake, any retention, dissemination, distribution or copying of this= message and attachments is strictly prohibited. Please notify the sender immediately and permanently delete the message a= nd any attachments.
. . .


_______________________________________________
sacm mailing list
sacm@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/sacm

 


...

. . .
--_000_05BCCEB107AF88469B9F99783D47C1D6065F5476CISEXCHANGE1msi_-- From michael.hammer@yaanatech.com Tue Dec 10 06:50:35 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75B771ADFDA for ; Tue, 10 Dec 2013 06:50:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S_DP0pcit-wb for ; Tue, 10 Dec 2013 06:50:27 -0800 (PST) Received: from email1.corp.yaanatech.com (webmail10.yaanatech.com [63.128.177.10]) by ietfa.amsl.com (Postfix) with ESMTP id 159D01AE106 for ; Tue, 10 Dec 2013 06:50:26 -0800 (PST) Received: from SC9-EX2K10MB1.corp.yaanatech.com ([fe80::149d:c2e1:8065:2a47]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Tue, 10 Dec 2013 06:50:21 -0800 From: Michael Hammer To: "Adam.Montville@cisecurity.org" , "ietfdbh@comcast.net" , "blueroofmusic@gmail.com" , "david.waltermire@nist.gov" Thread-Topic: [sacm] FW: New Version Notification for draft-ietf-sacm-use-cases-05.txt Thread-Index: AQHO9aMwITflDcU1YkOdON3YOdymj5pNgkrg Date: Tue, 10 Dec 2013 14:50:21 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBF073B5@sc9-ex2k10mb1.corp.yaanatech.com> References: <20131120225753.9031.68753.idtracker@ietfa.amsl.com> <528F23D0.3080504@sit.fraunhofer.de> <05BCCEB107AF88469B9F99783D47C1D6065E4769@CISEXCHANGE1.msisac.org.local> <025d01cef178$63f56840$2be038c0$@comcast.net> <9904FB1B0159DA42B0B887B7FA8119CA12952A08@AZ-FFEXMB04.global.avaya.com> <00C069FD01E0324C9FFCADF539701DB3BBF01B8D@sc9-ex2k10mb1.corp.yaanatech.com> <05BCCEB107AF88469B9F99783D47C1D6065EFE47@CISEXCHANGE1.msisac.org.local> <9904FB1B0159DA42B0B887B7FA8119CA129DBB1D@AZ-FFEXMB04.global.avaya.com> <4b451425cbec406d94fa1a82b32fa1ab@BLUPR09MB038.namprd09.prod.outlook.com> , <018701cef544$9d2ce730$d786b590$@comcast.net> <05BCCEB107AF88469B9F99783D47C1D6065F5476@CISEXCHANGE1.msisac.org.local> In-Reply-To: <05BCCEB107AF88469B9F99783D47C1D6065F5476@CISEXCHANGE1.msisac.org.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.47] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00E3_01CEF58D.3CD292B0" MIME-Version: 1.0 Cc: "sacm@ietf.org" Subject: Re: [sacm] FW: New Version Notification for draft-ietf-sacm-use-cases-05.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 14:50:35 -0000 ------=_NextPart_000_00E3_01CEF58D.3CD292B0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_00E4_01CEF58D.3CD292B0" ------=_NextPart_001_00E4_01CEF58D.3CD292B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit If they are formal terms defined in a document, I don't think capitalization is a problem. How else do you distinguish them from randomly chosen English words? After all the whole reason to distinguish MUST versus must is just that. But, might be good to clarify that with Editor. Mike From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Adam Montville Sent: Tuesday, December 10, 2013 7:25 AM To: ietfdbh; 'Ira McDonald'; 'Waltermire, David A.' Cc: sacm@ietf.org Subject: Re: [sacm] FW: New Version Notification for draft-ietf-sacm-use-cases-05.txt Thanks for pointing that out, David. This might be stylistic in some ways, but these aren't titles they are roles. From that perspective we could treat them as proper nouns, which would technically warrant capitalization. But, better to stick with what the Editor would prefer, I think. Adam _____ From: sacm [sacm-bounces@ietf.org] on behalf of ietfdbh [ietfdbh@comcast.net] Sent: Monday, December 09, 2013 7:08 PM To: 'Ira McDonald'; 'Waltermire, David A.' Cc: sacm@ietf.org Subject: Re: [sacm] FW: New Version Notification for draft-ietf-sacm-use-cases-05.txt Hi, I'd have to go look up a reference, but I believe the rfc editor considers it bad form to capitalize things that don't need to be capitalized. David Harrington ietfdbh@comcast.net +1-603-828-1401 From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Ira McDonald Sent: Monday, December 09, 2013 3:35 PM To: Waltermire, David A.; Ira McDonald Cc: sacm@ietf.org Subject: Re: [sacm] FW: New Version Notification for draft-ietf-sacm-use-cases-05.txt Hi Dave, I'm not sure if there's consensus about this, but I suggest that the current lowercase "operator", "administrator", etc. (e.g., in 2.1.1) should be titlecase (first letter capitalized). Also that a new section 1.1 Actors be added that defines these actor terms (one to three sentences each about what are typical actions or responsibilities for each actor). >From the original Design Goals for IPP (RFC 2567) here are some admittedly printing-specific definitions, but they give the right flavor: "3.1. END-USER An end-user of a printer accepting jobs through the Internet is one of the roles in which humans act. The end-user is the person that will submit a job to be printed on the printer. The wants and needs of the end-user are broken down into six categories: finding/locating a printer, creating a local instance of a printer, viewing printer status, viewing printer capabilities, submitting a print job, viewing print job status, altering the attributes of a print job. 3.2. OPERATOR An operator of a printer accepting jobs through the Internet is one of the roles in which humans act. The operator has the responsibility of monitoring the status of the printer as well as managing and controlling the jobs at the device. These responsibilities include but are not limited to the replenishing of supplies (ink, toner, paper, etc.), the clearing of minor errors (paper jams, etc.) and the re-prioritization of end-user jobs. Operator wants and needs will not be addressed by V1.0 of the protocol. The wants and needs of the operator include all those of the end-user but may include additional privileges. For example, an operator may be able to view all print jobs on a printer while the end-user might only be able to see his own jobs. 3.3. ADMINISTRATOR An administrator of a printer accepting jobs through the Internet is one of the roles in which humans act. The administrator has the responsibility of creating the printer instances and controlling the authorization of other end-users and operators. Administrator wants and needs will not be addressed by V1.0 of the protocol. The wants and needs of the administrator include all those of the end-user and, in some environments, some or all of those of the operator. Minimally, the administrator must also have the tools, programs, utilities and supporting protocols available to be able to: - create an instance of a printer - create, edit and maintain the list of authorized end-users - create, edit and maintain the list of authorized operators - create, edit and maintain the list of authorized administrators - create, customize, change or otherwise alter the manner in which the status capabilities and other information about printers and jobs are presented - create, customize, or change other printer or job features - administrate billing or other charge-back mechanisms - create sets of defaults - create sets of capabilities The administrator must have the capability to perform all the above tasks locally or remotely to the printer." >From later IPP Get-Notifications (RFC 3997), here are much shorter definitions: "2.1. Job-Submitting End User A human end user who submits a print job to an IPP Printer. This person may or may not be within the same security domain as the Printer. This person may or may not be geographically near the printer. 2.2. Administrator A human user who established policy for and configures the print system. 2.3. Operator A human user who carries out the policy established by the Administrator and controls the day-to-day running of the print system." As Nancy said, we need also: Application, System. Cheers, - Ira Ira McDonald (Musician / Software Architect) Co-Chair - TCG Trusted Mobility Solutions WG Chair - Linux Foundation Open Printing WG Secretary - IEEE-ISTO Printer Working Group Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG IETF Designated Expert - IPP & Printer MIB Blue Roof Music / High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto: blueroofmusic@gmail.com Winter 579 Park Place Saline, MI 48176 734-944-0094 Summer PO Box 221 Grand Marais, MI 49839 906-494-2434 On Mon, Dec 9, 2013 at 3:12 PM, Waltermire, David A. wrote: +1. I too like this approach. This has been a good discussion. To direct this dialog towards actionable changes to the use cases draft, is there specific draft text that should be updated to make the roles and their relevance to a use case or usage scenario more clear? Thanks, Dave From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Kent_Landfield@McAfee.com Sent: Sunday, December 08, 2013 12:20 PM To: sacm@ietf.org Subject: Re: [sacm] FW: New Version Notification for draft-ietf-sacm-use-cases-05.txt +1 I like the terminology Ira and Adam have suggested. Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: , "Dan (Dan)" Date: Sunday, December 8, 2013 7:43 AM To: Adam Montville , Ira McDonald , Michael Hammer Cc: "dbharrington@comcast.net" , David Waltermire , "sacm@ietf.org" , "henk.birkholz@sit.fraunhofer.de" Subject: Re: [sacm] FW: New Version Notification for draft-ietf-sacm-use-cases-05.txt +1 Dan Speaking as contributor - better to say it clearly if there are reasons to wonder From: Adam Montville [mailto:Adam.Montville@cisecurity.org] Sent: Friday, December 06, 2013 3:12 AM To: Ira McDonald; Michael Hammer Cc: Romascanu, Dan (Dan); dbharrington@comcast.net; david.waltermire@nist.gov; henk.birkholz@sit.fraunhofer.de; sacm@ietf.org Subject: RE: [sacm] FW: New Version Notification for draft-ietf-sacm-use-cases-05.txt I like this set of terminology. End User, Operator, Administrator, and Application. Then, Application can potentially have further specification as we move forward. For example, Analysis Application, Acquisition Application, and so on. Whatever we choose, I would prefer to choose terms that we can easily use consistently. Adam (I'm assuming, but perhaps shouldn't, that when I comment like this it's as a contributor) _____ From: Ira McDonald [blueroofmusic@gmail.com] Sent: Thursday, December 05, 2013 8:48 AM To: Michael Hammer Cc: dromasca@avaya.com; dbharrington@comcast.net; david.waltermire@nist.gov; Adam Montville; henk.birkholz@sit.fraunhofer.de; sacm@ietf.org Subject: Re: [sacm] FW: New Version Notification for draft-ietf-sacm-use-cases-05.txt Hi, My two cents - End User, Operator, and Administrator are quite distinct roles of actors in standards from many SDOs - they have inherently distinct default privileges - using these common role terms consistently would make SACM use cases more accessible to non-participants in the SACM WG. BTW - there are a few other roles of actors that should probably be used in SACM use cases, e.g., Application - although tthat's a slippery slope, because normal applications (browsers, email readers, etc.) have very different privileges and responsibilities from security-specific applications (MDM agents, anti-virus scanners, etc.). Cheers, - Ira Ira McDonald (Musician / Software Architect) Co-Chair - TCG Trusted Mobility Solutions WG Chair - Linux Foundation Open Printing WG Secretary - IEEE-ISTO Printer Working Group Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG IETF Designated Expert - IPP & Printer MIB Blue Roof Music / High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto: blueroofmusic@gmail.com Winter 579 Park Place Saline, MI 48176 734-944-0094 Summer PO Box 221 Grand Marais, MI 49839 906-494-2434 On Thu, Dec 5, 2013 at 9:12 AM, Michael Hammer wrote: Actor connotes human to me. What would be wrong with using client or server if asymmetric, or user agent if peering? With adjectives to differentiate types. Mike -----Original Message----- From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Thursday, December 05, 2013 4:52 AM To: David Harrington; 'Waltermire, David A.'; 'Adam Montville'; 'Henk Birkholz'; sacm@ietf.org Subject: Re: [sacm] FW: New Version Notification for draft-ietf-sacm-use-cases-05.txt I share DBH's concern. There may be significant differences in workflows and interface requirements between systems (networks, devices) and humans vs. systems (networks, devices) and applications. There may be significant differences if the humans are operators or end-users. Using one term (say 'actor') for all may create ambiguities. I am not sure that I understand the advantages of the proposed abstraction. Dan (speaking as contributor) > -----Original Message----- > From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of David Harrington > Sent: Thursday, December 05, 2013 7:11 AM > To: 'Waltermire, David A.'; 'Adam Montville'; 'Henk Birkholz'; > sacm@ietf.org > Subject: Re: [sacm] FW: New Version Notification for draft-ietf-sacm- > use-cases-05.txt > > Hi, > > Using actor concerns me. > I find it important to understand whether some content needs to be > parsed by a human (with our wonderful ability to parse), or a computer > application (which is bound by a set of rules, and has great difficulty > when the content is not consistent with the rules). > > Around 2003, the operators made it clear that CLIs were difficult to > work with, because queries would return information in variable formats. > While humans might be able to parse the output that might change from > vendor to vendor, model to model, and release to release, tools had > significant difficulty due to the lack of standardization. Operators > could try to deal with the lack of standardization by writing expect > scripts, but they would need to be updated constantly because what > worked for one release of a product might not be the same in the next > release. > Humans can parse variable syntax, such as the natural language content > of syslog, but applications can have a hard time. > > I think is very important to know whether we are designing something for > human consumption or for computer consumption. > "Actor" doesn't provide enough differentiation to know how to design our > solutions. > > David Harrington > dbharrington@comcast.net > +1-603-828-1401 > > > -----Original Message----- > > From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Waltermire, > > David A. > > Sent: Wednesday, December 04, 2013 8:54 PM > > To: Adam Montville; Henk Birkholz; sacm@ietf.org > > Subject: Re: [sacm] FW: New Version Notification for > > draft-ietf-sacm-use- cases-05.txt > > > > Comments inline. > > > > > -----Original Message----- > > > From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Adam > > > Montville > > > Sent: Wednesday, December 04, 2013 8:38 PM > > > To: Henk Birkholz; sacm@ietf.org > > > Subject: Re: [sacm] FW: New Version Notification for > draft-ietf-sacm-use- > > > cases-05.txt > > > > > > Something I've found helpful in the past is to abstract a bit > > > further > from > > > "user", "operator", "application" and simply reference all of them > > > at > once > > > with the term "actor". > > > > Are we ok with the change to using actor? The current usage of "user", > > "operator", "application" (specifically the last two) was suggested a > while > > back to align with IETF terminology. Does use of "actor" to reference > > all > three > > concepts raise any concerns? > > > > > I also believe that listing *potential* acquisition methods is > > > useful in > at least > > > the following way: Including a multitude of acquisition methods > > > clearly > > signals > > > our intent of finding information where it already exists, while not > > > necessarily precluding our ability to *get* information when > > > information does not exist. > > > > Adam, would you or Henk provide some example acquisition methods for > > discussion? > > > > > Finally, I, too, like the notion of a work-flow scenario. I don't > > > want > to be > > the > > > one drawing a process diagram in an RFC, though. ;-) > > > > How would this differ from the workflow scenario text in section 2? > > > > Are you suggesting representing this text in a visual form? If so, > > would anyone like to make a contribution of some ascii art? > > > > > awm > > > ________________________________________ > > > From: sacm [sacm-bounces@ietf.org] on behalf of Henk Birkholz > > > [henk.birkholz@sit.fraunhofer.de] > > > Sent: Friday, November 22, 2013 3:27 AM > > > To: sacm@ietf.org > > > Subject: Re: [sacm] FW: New Version Notification for > draft-ietf-sacm-use- > > > cases-05.txt > > > > > > Regarding the first two question in section 2: > > > > > > 1.) Security automation today often supports the user/operator, I > think. > > > There are cases a security-process can be fully automated, of > > > course, > and in > > > order to manage the sheer amount of security related system events > > > automation is essential, but it seems to me that the complexity and > > > heterogeneity of root-causes (that might trigger the work-flow) make > > > the inclusion of a user/operator necessary. > > > > > > 2.) To include acquisition methods can provide an intuitive insight > about the > > > scope and intend of the endpoint posture assessment domain, I think. > > > On one hand, that might bloat the use-case document a bit (and maybe > > renders > > > the title "sacm use cases" too specific?). On the other hand, I like > > > the inclusion of a work-flow scenario and I think it is a good place > > > to > highlight > > > acquisition methods. > > > > > > - Henk > > > > > > On 11/21/2013 12:27 AM, Waltermire, David A. wrote: > > > > I just posted an updated use case draft based on the editorial > sessions > > > during the IETF 88 meeting in Vancouver, BC, Canada. My thanks to > > > all > that > > > provided input. > > > > > > > > I used the word version that we edited as a starting point. Here > > > > is > what I > > > did: > > > > > > > > - I worked through the use cases we planned to remove and made > > > > sure > > to > > > merge in any concepts that would be lost. If you submitted a > > > previous > use > > > case that was removed, please double check that I didn't miss > anything. > > > > - I broke up "Endpoint Identification and Assessment" into 3 > > > > distinct > and > > > somewhat separable use cases: "Endpoint Identification and > > > Assessment Planning", "Endpoint Posture Attribute Value Collection", > > > "Posture Evaluation". Please let me know what you think about this > change. > > > > - Addressed some aspects of the discussion thread based on the > > > > working > > > session changes. Please provide any suggested edits for aspects that > > > I > > might > > > have missed or got wrong. > > > > > > > > The rest of the changes can be found in the draft's change log. > > > > > > > > If possible, I'd like to get to a fairly stable place with this > > > > draft > in the next > > > revision or two to allow for progress to be made on the > > > requirements. In addition to the embedded questions in the document, > > > I'd like to focus on > > the > > > following questions: > > > > > > > > Is the draft approachable for a newcomer to the effort? Do you see > > > > the > > > updated use case structure as an improvement? > > > > Does this draft paint a complete enough picture? Are we missing > > > > any > > > important concepts? > > > > Is there anything you can't live with? > > > > > > > > I hope to release at least one or two more updates to this draft > within the > > > next few weeks before the holidays catch up on us. I know everyone > > > is busy; timely comments are appreciated to allow for a quick > > > turnaround on the next revision. > > > > > > > > Thanks, > > > > Dave > > > > > > > > -----Original Message----- > > > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > > > Sent: Wednesday, November 20, 2013 5:58 PM > > > > To: Waltermire, David A.; David Harrington > > > > Subject: New Version Notification for > > > > draft-ietf-sacm-use-cases-05.txt > > > > > > > > > > > > A new version of I-D, draft-ietf-sacm-use-cases-05.txt has been > > > successfully submitted by David Waltermire and posted to the IETF > > > repository. > > > > > > > > Filename: draft-ietf-sacm-use-cases > > > > Revision: 05 > > > > Title: Endpoint Security Posture Assessment - > Enterprise Use > > Cases > > > > Creation date: 2013-11-20 > > > > Group: sacm > > > > Number of pages: 24 > > > > URL: > http://www.ietf.org/internet-drafts/draft-ietf-sacm-use- > > cases- > > > 05.txt > > > > Status: > http://datatracker.ietf.org/doc/draft-ietf-sacm-use-cases > > > > Htmlized: > http://tools.ietf.org/html/draft-ietf-sacm-use-cases-05 > > > > Diff: > http://www.ietf.org/rfcdiff?url2=draft-ietf-sacm-use-cases-05 > > > > > > > > Abstract: > > > > This memo documents a sampling of use cases for securely > aggregating > > > > configuration and operational data and evaluating that data to > > > > determine an organization's security posture. From these > operational > > > > use cases, we can derive common functional capabilities and > > > > requirements to guide development of vendor-neutral, > interoperable > > > > standards for aggregating and evaluating data relevant to > security > > > > posture. > > > > > > > > > > > > > > > > > > > > Please note that it may take a couple of minutes from the time of > > > submission until the htmlized version and diff are available at > tools.ietf.org. > > > > > > > > The IETF Secretariat > > > > > > > > _______________________________________________ > > > > sacm mailing list > > > > sacm@ietf.org > > > > https://www.ietf.org/mailman/listinfo/sacm > > > > > > > > > > > > > > > > ... > > > > > > . . . > > > _______________________________________________ > > > sacm mailing list > > > sacm@ietf.org > > > https://www.ietf.org/mailman/listinfo/sacm > > _______________________________________________ > > sacm mailing list > > sacm@ietf.org > > https://www.ietf.org/mailman/listinfo/sacm > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm ... This message and attachments may contain confidential information. If it appears that this message was sent to you by mistake, any retention, dissemination, distribution or copying of this message and attachments is strictly prohibited. Please notify the sender immediately and permanently delete the message and any attachments. . . . _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm ... . . . ------=_NextPart_001_00E4_01CEF58D.3CD292B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

If they are formal terms defined in a document, I don’t think = capitalization is a problem.

How else do you distinguish them from randomly chosen English = words?

After all the whole reason to distinguish MUST versus must is just = that.

But, might be good to clarify that with = Editor.

 

Mike

 

 

From:= = sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Adam = Montville
Sent: Tuesday, December 10, 2013 7:25 = AM
To: ietfdbh; 'Ira McDonald'; 'Waltermire, David = A.'
Cc: sacm@ietf.org
Subject: Re: [sacm] FW: New = Version Notification for = draft-ietf-sacm-use-cases-05.txt

 

= Thanks for pointing that out, David.  This might be stylistic in = some ways, but these aren't titles they are roles.  From that = perspective we could treat them as proper nouns, which would technically = warrant capitalization.  But, better to stick with what the Editor = would prefer, I think.

=  

= Adam

=  

= From:= sacm [sacm-bounces@ietf.org] on behalf of ietfdbh = [ietfdbh@comcast.net]
Sent: Monday, December 09, 2013 7:08 = PM
To: 'Ira McDonald'; 'Waltermire, David A.'
Cc: sacm@ietf.org
Subject: Re: = [sacm] FW: New Version Notification for = draft-ietf-sacm-use-cases-05.txt

Hi,

 

I’d have to go look up a reference, but I believe the rfc = editor considers it bad form to capitalize things that don’t need = to be capitalized.

 

 

David Harrington

ietfdbh@comca= st.net

+1-603-828-1401

= From:= sacm [mailto:sacm-bounces@ietf.= org] On Behalf Of Ira McDonald
Sent: Monday, = December 09, 2013 3:35 PM
To: Waltermire, David A.; Ira = McDonald
Cc: sacm@ietf.org
Subject: Re: = [sacm] FW: New Version Notification for = draft-ietf-sacm-use-cases-05.txt

 

Hi Dave,

I'm not sure if there's = consensus about this, but I suggest that the = current

lowercase "operator", = "administrator", etc. (e.g., in 2.1.1) should = be

titlecase = (first letter capitalized).

Also that a new section 1.1 Actors be added that = defines these actor
terms (one to three sentences each about what are = typical actions or
responsibilities for each = actor).

From the = original Design Goals for IPP (RFC 2567) here are some
admittedly = printing-specific definitions, but they give the right = flavor:

"3.1. END-USER

   An end-user of a = printer accepting jobs through the Internet is one
   of = the roles in which humans act.  The end-user is the person = that
   will submit a job to be printed on the = printer.

   The wants and needs of the end-user are = broken down into six
   categories: finding/locating a = printer, creating a local instance of
   a printer, viewing = printer status, viewing printer capabilities,
   submitting = a print job, viewing print job status, altering the
   = attributes of a print job.

3.2. OPERATOR

   An = operator of a printer accepting jobs through the Internet is = one
   of the roles in which humans act.  The operator = has the
   responsibility of monitoring the status of the = printer as well as
   managing and controlling the jobs at = the device.  These
   responsibilities include but are = not limited to the replenishing of
   supplies (ink, toner, = paper, etc.), the clearing of minor errors
   (paper jams, = etc.) and the re-prioritization of end-user jobs.
   = Operator wants and needs will not be addressed by V1.0 of = the
   protocol.

   The wants and needs of = the operator include all those of the end-user
   but may = include additional privileges.  For example, an operator = may
   be able to view all print jobs on a printer while = the end-user might
   only be able to see his own = jobs.

3.3. ADMINISTRATOR

   An administrator of = a printer accepting jobs through the Internet is
   one of = the roles in which humans act.  The administrator has = the
   responsibility of creating the printer instances and = controlling the
   authorization of other end-users and = operators.  Administrator wants
   and needs will not = be addressed by V1.0 of the protocol.

   The wants and = needs of the administrator include all those of the
   = end-user and, in some environments, some or all of those of = the
   operator.  Minimally, the administrator must = also have the tools,
   programs, utilities and supporting = protocols available to be able to:

   - create an = instance of a printer
   - create, edit and maintain the = list of authorized end-users
   - create, edit and maintain = the list of authorized operators
   - create, edit and = maintain the list of authorized
     = administrators
   - create, customize, change or otherwise = alter the manner in
     which the status = capabilities and other information about = printers
     and jobs are = presented
   - create, customize, or change other printer = or job features
   - administrate billing or other = charge-back mechanisms
   - create sets of = defaults
   - create sets of = capabilities

   The administrator must have the = capability to perform all the above
   tasks locally or = remotely to the printer."

From later IPP = Get-Notifications (RFC 3997), here are much = shorter

definitions:

"2.1.  = Job-Submitting End User

   A human end user who submits = a print job to an IPP Printer.  This
   person may or = may not be within the same security domain as the
   = Printer.  This person may or may not be geographically near = the
   printer.

2.2.  = Administrator

   A human user who established policy = for and configures the print
   system.

2.3.  = Operator

   A human user who carries out the policy = established by the
   Administrator and controls the = day-to-day running of the print
   = system."

As Nancy = said, we need also:  Application, = System.

Cheers,

- Ira


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

 

On Mon, Dec 9, 2013 at = 3:12 PM, Waltermire, David A. <david.waltermire@nist.gov> = wrote:

+1. I too like this approach. This has been a good = discussion.

 

To direct this dialog towards actionable changes to the use cases = draft, is there specific draft text that should be updated to make the = roles and their relevance to a use case or usage scenario more = clear?

 

Thanks,

Dave

 

= From:= sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Kent_Landfield@McAfee.com
Sent: Sunday, = December 08, 2013 12:20 PM


To: sacm@ietf.org
Subject: Re: [sacm] FW: = New Version Notification for = draft-ietf-sacm-use-cases-05.txt

<= /div>

 

+1

 

I like the terminology Ira = and Adam have suggested.

 

= Kent Landfield=

McAfee = | An Intel Company
Direct: +1.972.963.7096 
Mobile: +1.817.637.8026
Web: www.mcafee.com

 

From: <Romascanu>, "Dan (Dan)" <dromasca@avaya.com>
Date: Sunday, = December 8, 2013 7:43 AM
To: Adam Montville <Adam.Montville@cisecurity.org>, Ira McDonald = <blueroofmusic@gmail.com>, Michael Hammer <michael.hammer@yaanatech.com>
Cc: = "dbharrington@comcast.net" <dbharrington@comcast.net>, David Waltermire = <david.waltermire@nist.gov>, "sacm@ietf.org" = <sacm@ietf.org>, "henk.birkholz@sit.fraunhofer.de" <henk.birkholz@sit.fraunhofer.de>
Subject: = Re: [sacm] FW: New Version Notification for = draft-ietf-sacm-use-cases-05.txt

 

+1

 

Dan

 

Speaking as contributor – better to say it clearly if there are = reasons to wonder

 

 

= From:= Adam Montville [mailto:Adam.Montville@cisecurity.org] =
Sent: Friday, December 06, 2013 3:12 AM
To: Ira = McDonald; Michael Hammer
Cc: Romascanu, Dan (Dan); dbharrington@comcast.net; david.waltermire@nist.gov; henk.birkholz@sit.fraunhofer.de; sacm@ietf.org
Subject: RE: [sacm] FW: = New Version Notification for = draft-ietf-sacm-use-cases-05.txt

 

= I like this set of terminology.  End User, Operator, Administrator, = and Application.  Then, Application can potentially have further = specification as we move forward.  For example, Analysis = Application, Acquisition Application, and so on.  

=  

= Whatever we choose, I would prefer to choose terms that we can easily = use consistently. 

=  

= Adam

=  

= (I'm assuming, but perhaps shouldn't, that when I comment like this it's = as a contributor)

=  

= From:= Ira McDonald [blueroofmusic@gmail.com]
Sent: Thursday, = December 05, 2013 8:48 AM
To: Michael Hammer
Cc: dromasca@avaya.com; dbharrington@comcast.net; david.waltermire@nist.gov; Adam Montville; henk.birkholz@sit.fraunhofer.de; sacm@ietf.org
Subject: Re: [sacm] FW: = New Version Notification for = draft-ietf-sacm-use-cases-05.txt

Hi,

My two cents - End User, = Operator, and Administrator are quite = distinct

roles of actors in standards from many SDOs - they = have inherently

distinct default privileges - using these common = role terms consistently

would make SACM use cases more accessible to = non-participants in
the SACM WG.

BTW - there are a few = other roles of actors that should probably = be

used in SACM use cases, e.g., Application - = although tthat's a slippery

slope, because normal = applications (browsers, email readers, = etc.)

have very different privileges and = responsibilities from = security-specific

applications = (MDM agents, anti-virus scanners, = etc.).

Cheers,

- Ira


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

 

On Thu, Dec 5, 2013 at = 9:12 AM, Michael Hammer <michael.hammer@yaanatech.com> = wrote:

Actor connotes human to me.

What would be = wrong with using client or server if asymmetric, or user agent
if = peering?
With adjectives to differentiate = types.

Mike



-----Original = Message-----
From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Romascanu, Dan = (Dan)
Sent: Thursday, December 05, 2013 4:52 AM
To: David = Harrington; 'Waltermire, David A.'; 'Adam Montville'; = 'Henk
Birkholz'; sacm@ietf.org
Subject: Re: [sacm] FW: New = Version Notification for
draft-ietf-sacm-use-cases-05.txt

I = share DBH's concern. There may be significant differences in workflows = and
interface requirements between systems (networks, devices) and = humans vs.
systems (networks, devices) and applications. There may be = significant
differences if the humans are operators or end-users. = Using one term (say
'actor') for all may create ambiguities. I am not = sure that I understand the
advantages of the proposed = abstraction.

Dan
(speaking as contributor)


> = -----Original Message-----
> From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of David = Harrington
> Sent: Thursday, December 05, 2013 7:11 AM
> To: = 'Waltermire, David A.'; 'Adam Montville'; 'Henk Birkholz';
> sacm@ietf.org
> Subject: Re: [sacm] FW: New = Version Notification for draft-ietf-sacm-
> = use-cases-05.txt
>
> Hi,
>
> Using actor = concerns me.
> I find it important to understand whether some = content needs to be
> parsed by a human (with our wonderful = ability to parse), or a computer
> application (which is bound by = a set of rules, and has great difficulty
> when the content is not = consistent with the rules).
>
> Around 2003, the operators = made it clear that CLIs were difficult to
> work with, because = queries would return information in variable formats.
> While = humans might be able to parse the output that might change from
> = vendor to vendor, model to model, and release to release, tools = had
> significant difficulty due to the lack of standardization. = Operators
> could try to deal with the lack of standardization by = writing expect
> scripts, but they would need to be updated = constantly because what
> worked for one release of a product = might not be the same in the next
> release.
> Humans can = parse variable syntax, such as the natural language content
> of = syslog, but applications can have a hard time.
>
> I think = is very important to know whether we are designing something for
> = human consumption or for computer consumption.
> "Actor" = doesn't provide enough differentiation to know how to design our
> = solutions.
>
> David Harrington
> dbharrington@comcast.net
> +1-603-828-1401
>
> > -----Original = Message-----
> > From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of = Waltermire,
> > David A.
> > Sent: Wednesday, December = 04, 2013 8:54 PM
> > To: Adam Montville; Henk Birkholz; sacm@ietf.org
> > Subject: Re: [sacm] FW: = New Version Notification for
> > draft-ietf-sacm-use- = cases-05.txt
> >
> > Comments inline.
> = >
> > > -----Original Message-----
> > > = From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Adam
> = > > Montville
> > > Sent: Wednesday, December 04, 2013 = 8:38 PM
> > > To: Henk Birkholz; sacm@ietf.org
> > > Subject: Re: = [sacm] FW: New Version Notification for
> = draft-ietf-sacm-use-
> > > cases-05.txt
> > = >
> > > Something I've found helpful in the past is to = abstract a bit
> > > further
> from
> > > = "user", "operator", "application" and = simply reference all of them
> > > at
> once
> = > > with the term "actor".
> >
> > Are = we ok with the change to using actor? The current usage of = "user",
> > "operator", = "application" (specifically the last two) was suggested = a
> while
> > back to align with IETF terminology. Does = use of "actor" to reference
> > all
> = three
> > concepts raise any concerns?
> >
> = > > I also believe that listing *potential* acquisition methods = is
> > > useful in
> at least
> > > the = following way: Including a multitude of acquisition methods
> > = > clearly
> > signals
> > > our intent of = finding information where it already exists, while not
> > > = necessarily precluding our ability to *get* information when
> = > > information does not exist.
> >
> > Adam, = would you or Henk provide some example acquisition methods for
> = > discussion?
> >
> > > Finally, I, too, like = the notion of a work-flow scenario.  I don't
> > > = want
> to be
> > the
> > > one drawing a = process diagram in an RFC, though. ;-)
> >
> > How = would this differ from the workflow scenario text in section 2?
> = >
> > Are you suggesting representing this text in a visual = form? If so,
> > would anyone like to make a contribution of = some ascii art?
> >
> > > awm
> > > = ________________________________________
> > > From: sacm = [sacm-bounces@ietf.org] on behalf of Henk = Birkholz
> > > [henk.birkholz@sit.fraunhofer.de]
> > > = Sent: Friday, November 22, 2013 3:27 AM
> > > To: sacm@ietf.org
> > > Subject: Re: = [sacm] FW: New Version Notification for
> = draft-ietf-sacm-use-
> > > cases-05.txt
> > = >
> > > Regarding the first two question in section = 2:
> > >
> > > 1.) Security automation today = often supports the user/operator, I
> think.
> > > = There are cases a security-process can be fully automated, of
> = > > course,
> and in
> > > order to manage the = sheer amount of security related system events
> > > = automation is essential, but it seems to me that the complexity = and
> > > heterogeneity of root-causes (that might trigger = the work-flow) make
> > > the inclusion of a user/operator = necessary.
> > >
> > > 2.) To include = acquisition methods can provide an intuitive insight
> about = the
> > > scope and intend of the endpoint posture = assessment domain, I think.
> > > On one hand, that might = bloat the use-case document a bit (and maybe
> > = renders
> > > the title "sacm use cases" too = specific?). On the other hand, I like
> > > the inclusion of = a work-flow scenario and I think it is a good place
> > > = to
> highlight
> > > acquisition methods.
> > = >
> > > - Henk
> > >
> > > On = 11/21/2013 12:27 AM, Waltermire, David A. wrote:
> > > > = I just posted an updated use case draft based on the editorial
> = sessions
> > > during the IETF 88 meeting in Vancouver, BC, = Canada. My thanks to
> > > all
> that
> > = > provided input.
> > > >
> > > > I = used the word version that we edited as a starting point. Here
> = > > > is
> what I
> > > did:
> > = > >
> > > > - I worked through the use cases we = planned to remove and made
> > > > sure
> > = to
> > > merge in any concepts that would be lost. If you = submitted a
> > > previous
> use
> > > = case that was removed, please double check that I didn't miss
> = anything.
> > > > - I broke up "Endpoint = Identification and Assessment" into 3
> > > > = distinct
> and
> > > somewhat separable use cases: = "Endpoint Identification and
> > > Assessment = Planning", "Endpoint Posture Attribute Value = Collection",
> > > "Posture Evaluation". = Please let me know what you think about this
> change.
> = > > > - Addressed some aspects of the discussion thread based = on the
> > > > working
> > > session changes. = Please provide any suggested edits for aspects that
> > > = I
> > might
> > > have missed or got wrong.
> = > > >
> > > > The rest of the changes can be = found in the draft's change log.
> > > >
> > = > > If possible, I'd like to get to a fairly stable place with = this
> > > > draft
> in the next
> > > = revision or two to allow for progress to be made on the
> > = > requirements. In addition to the embedded questions in the = document,
> > > I'd like to focus on
> > = the
> > > following questions:
> > > = >
> > > > Is the draft approachable for a newcomer to = the effort? Do you see
> > > > the
> > > = updated use case structure as an improvement?
> > > > = Does this draft paint a complete enough picture? Are we missing
> = > > > any
> > > important concepts?
> > = > > Is there anything you can't live with?
> > > = >
> > > > I hope to release at least one or two more = updates to this draft
> within the
> > > next few = weeks before the holidays catch up on us.  I know everyone
> = > > is busy; timely comments are appreciated to allow for a = quick
> > > turnaround on the next revision.
> > = > >
> > > > Thanks,
> > > > = Dave
> > > >
> > > > -----Original = Message-----
> > > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
> > > > = Sent: Wednesday, November 20, 2013 5:58 PM
> > > > To: = Waltermire, David A.; David Harrington
> > > > Subject: = New Version Notification for
> > > > = draft-ietf-sacm-use-cases-05.txt
> > > >
> > = > >
> > > > A new version of I-D, = draft-ietf-sacm-use-cases-05.txt has been
> > > successfully = submitted by David Waltermire and posted to the IETF
> > > = repository.
> > > >
> > > > Filename: =      draft-ietf-sacm-use-cases
> > > > = Revision:      05
> > > > Title:   =               Endpoint Security = Posture Assessment -
> Enterprise Use
> > Cases
> = > > > Creation date:         = 2013-11-20
> > > > Group:         =         sacm
> > > > Number of pages: = 24
> > > > URL:
> http://www.ietf.org/internet-drafts/draft-ietf-sacm-use= -
> > cases-
> > > 05.txt
> > > = > Status:
> http://datatracker.ietf.org/doc/draft-ietf-sacm-use-cas= es
> > > > Htmlized:
> http://tools.ietf.org/html/draft-ietf-sacm-use-cases-05=
> > > > Diff:
> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sacm-use-= cases-05
> > > >
> > > > = Abstract:
> > > >     This memo documents a = sampling of use cases for securely
> aggregating
> > > = >     configuration and operational data and evaluating = that data to
> > > >     determine an = organization's security posture.  From these
> = operational
> > > >     use cases, we can = derive common functional capabilities and
> > > >   =   requirements to guide development of vendor-neutral,
> = interoperable
> > > >     standards for = aggregating and evaluating data relevant to
> security
> = > > >     posture.
> > > >
> = > > >
> > > >
> > > >
> = > > > Please note that it may take a couple of minutes from the = time of
> > > submission until the htmlized version and diff = are available at
> tools.ietf.org.
> > > >
> = > > > The IETF Secretariat
> > > >
> > = > > _______________________________________________
> > = > > sacm mailing list
> > > > sacm@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/sacm
> = > > >
> > >
> > >
> > = >
> > > ...
> > >
> > > . . = .
> > > = _______________________________________________
> > > sacm = mailing list
> > > sacm@ietf.org
> > > https://www.ietf.org/mailman/listinfo/sacm
> = > _______________________________________________
> > sacm = mailing list
> > sacm@ietf.org
> > https://www.ietf.org/mailman/listinfo/sacm
><= br>> _______________________________________________
> sacm = mailing list
> sacm@ietf.org
> https://www.ietf.org/mailman/listinfo/sacm
_____= __________________________________________
sacm mailing list
sacm@ietf.org
https://www.ietf.org/mailman/listinfo/sacm


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

 


...

This = message and attachments may contain confidential information. If it = appears that this message was sent to you by mistake, any retention, = dissemination, distribution or copying of this message and attachments = is strictly prohibited. Please notify the sender immediately and = permanently delete the message and any attachments.
. . = .

<= /div>


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

 


...


. . .

------=_NextPart_001_00E4_01CEF58D.3CD292B0-- ------=_NextPart_000_00E3_01CEF58D.3CD292B0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRPzCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggZCMIIFKqADAgECAhA4qwAv/66Wt1b/OVr7XecbMA0G CSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWdu LCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNz IDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw0xMTA5MDEw MDAwMDBaFw0yMTA4MzEyMzU5NTlaMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMg Q29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBl cnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHNDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMbsJ/0d Y/Q7HYrB0xzIyIKGtrhKhpKqgVxyyjANL55BIlcwISWQmqP0rCrGiBeGYXITdi7sA8snm48ggDfg 5IraVaZQD/y5XCNpiUKhuh+v7w75pMkK8fg3ssbZkkqufd+4RB+buj+MBv7YI09IUSNqYISo7icv YN+W8hoqjDyPAMxPy/ogjrw19uHwmrYF8/wdP8YUew7a8gXk04MCpsVpcLSp5Fbp2x1c9KY24mu1 Hiot3L677joEsDAIrV9obMa9BpaIhOfmqWQtvDgwu4gmw2dmZrS0d/nAoccOcu9m4uW5yuDzhXc1 mN7UHLD+ZnHiOMtufE9AVeuX2agYHu0CAwEAAaOCAkQwggJAMDgGCCsGAQUFBwEBBCwwKjAoBggr BgEFBQcwAYYcaHR0cDovL3BraS1vY3NwLnZlcmlzaWduLmNvbTASBgNVHRMBAf8ECDAGAQH/AgEA MGwGA1UdIARlMGMwYQYLYIZIAYb4RQEHFwEwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1h dXRoLmNvbS9jcHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwNAYD VR0fBC0wKzApoCegJYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0P AQH/BAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFWZXJpU2lnbk1QS0ktMi05NzAdBgNV HQ4EFgQUrfnDk3IttbkoYeSk12DVxApeGgEwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUA A4IBAQDWj8Ham4jys2xNH1gvugFRXXTBRujDuHuf1kDx7/8yuolrwA40Q5+kmeak8F1IM2KFhWH+ I4gijGCbK5xlSZTEojgkSKVcpVBLaOliIqeT6Jkibj1buxBCDh9MdUc0VgmP+L2MPPNcu9KWcFRw Yk3v0RC+nUgsXuyGaweC8D3hJScoLOAWdh6z/eViltKKPV8rrvtcwhO3ZWPLNHZDn9aHmaturZXB AD9GJ4H/Nd4jDkPcFF8y+cop78JSMPWZ3bmB+DolII2CaPK5IYV0ZgThhjkWMvIt1iqoyd7ZAAJP 4xggxaWBVraV3tOCrfh7Jb5kfC6gunAs+Pl14nRNB22EMIIG1zCCBb+gAwIBAgIQEB3dROkPDT0Q 6QYEc74tcjANBgkqhkiG9w0BAQUFADCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVj IENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQ ZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVh bCBTdWJzY3JpYmVyIENBIC0gRzQwHhcNMTMwNDAxMDAwMDAwWhcNMTQwNDAyMjM1OTU5WjCBzjEu MCwGA1UEAwwlUGVyc29uYSBOb3QgVmFsaWRhdGVkIC0gMTM2NDg0MjY5NDQ0MzErMCkGCSqGSIb3 DQEJARYcbWljaGFlbC5oYW1tZXJAeWFhbmF0ZWNoLmNvbTEPMA0GA1UECwwGUy9NSU1FMR4wHAYD VQQLDBVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxHzAdBgNVBAsMFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHTAbBgNVBAoMFFN5bWFudGVjIENvcnBvcmF0aW9uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAh2AtKQNowI8ILmNvdcY16moA8CH7hjSvGDNofwWsh4quEfZ6VQGtDhhOjUmW6JVq 719MH8FNJcVr8oAiVaK3nNeJTL2wO68LpgX6tcZ/z22pJoz98wHzgfWf3pfEUYrCqYg2V3m6oe0t kd+OaeY8DmPVSpG7as0rkoEzeNwCtmpYjkm96mBO6/AQwsowSLbSuqkEGykp1k47KiPBtxhbp2um IReh94vPrr1O9zXau9oGMvABJjigYQ2e5AhhhDdK8qOkhgkMAJN2nvLqY+VFrnFIsb5noQ/tP2M/ ct9qwRZ5kUaumRqE/XzV3rH8PoacZW/YvcwAp8Gr1ZaHCMRl+wIDAQABo4IC1TCCAtEwDAYDVR0T AQH/BAIwADAOBgNVHQ8BAf8EBAMCBaAwIAYDVR0lAQH/BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBTlvYUx4PMlUy6uvceJkDMK4jBDZjAnBgNVHREEIDAegRxtaWNoYWVsLmhhbW1l ckB5YWFuYXRlY2guY29tMB8GA1UdIwQYMBaAFK35w5NyLbW5KGHkpNdg1cQKXhoBMIIBKwYIKwYB BQUHAQEEggEdMIIBGTCCARUGCCsGAQUFBzAChoIBB2xkYXA6Ly9kaXJlY3RvcnkudmVyaXNpZ24u Y29tL0NOJTIwJTNEJTIwU3ltYW50ZWMlMjBDbGFzcyUyMDElMjBJbmRpdmlkdWFsJTIwU3Vic2Ny aWJlciUyMENBJTIwLSUyMEc0JTJDJTIwT1UlMjAlM0QlMjBQZXJzb25hJTIwTm90JTIwVmFsaWRh dGVkJTJDJTIwT1UlMjAlM0QlMjBTeW1hbnRlYyUyMFRydXN0JTIwTmV0d29yayUyQyUyME8lMjAl M0QlMjBTeW1hbnRlYyUyMENvcnBvcmF0aW9uJTJDJTIwQyUyMCUzRCUyMFVTP2NBQ2VydGlmaWNh dGU7YmluYXJ5MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1dGguY29tL2Nh XzU2MWMxMDM2OTBjOTdhNjkyNDdhMGVmMDcxYWM4MWFmL0xhdGVzdENSTC5jcmwwbAYDVR0gBGUw YzBhBgtghkgBhvhFAQcXATBSMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2Nw czAoBggrBgEFBQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTAqBgpghkgBhvhFARAD BBwwGgYRYIZIAYb4RQEQAQICBAGGsxcWBTEwOTIyMA0GCSqGSIb3DQEBBQUAA4IBAQAae/er4pfB TpqK6c/uJ9D8dVJzzNX26akkB8z/29totzbkpFAIlXRh02iNVK+GnsgS1gwu3FOvjgT5M4i+cNxD vTJVcnZNXns75JUGX3UsWQbtSySrVzQx8lMtwW6nXHM5GlEaY8/jKVpambG2q9OHjmwMTz7I4A+y KiiGCGdhE23dFOvku6t/oiwqFnXJmb4o75kbVevKEOd34MIj0P7Q8+1mZcNYEUTYKadoPXFyTWnO 2HTMvFcGgdLFKcqb13clWeW3/B5WjdBimpMjbvwi8ZbrhFdp7Y3NLKFSRH8W29rt0LW7zULxii0z 34NGsBkW9w95PLzTsqmKD4Yv5AkIMYIEkjCCBI4CAQEwgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYD VQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29y azEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMAkGBSsO AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMTIx MDE0NTAxOVowIwYJKoZIhvcNAQkEMRYEFHMCk/kdiD+XqXemfY/H7bc8JVWwMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAG7/n4j+SiLr0w4azz1ltlUVi84ZIHLvf+hbXWpiQ I2ycrgRSZoX9RKikRLc7JDWjulapouvMgV67Rozzwz/doP3dWYk36O6sSFKOPY+cZIiwnR26mx3x xIIzxPVEAFzaqPO6A7+VjUZweyG+Guj0NVKt8nU4zRzuy64p30Obj7plMWD0itSEuPRlYuk/g6ZH /uoX0uRNeLA9awDDV+1beSJNGGFaQhk4gQoRm+tR5NkZZ6W5p6qloCp1GVl7WVDWk1dqtfVMRY05 gOVaVRsR89BsZnzAndcAlA054mpqqAveu6WhvrUUl5ujbEuNQqfF/DclUj1kZjZNhIuXXXY2ywAA AAAAAA== ------=_NextPart_000_00E3_01CEF58D.3CD292B0-- From blueroofmusic@gmail.com Tue Dec 10 07:01:38 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1119C1ADFE5 for ; Tue, 10 Dec 2013 07:01:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, GB_I_LETTER=-2, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CalCYDg6uTFH for ; Tue, 10 Dec 2013 07:01:31 -0800 (PST) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 1D2DA1ADBCC for ; Tue, 10 Dec 2013 07:01:13 -0800 (PST) Received: by mail-ie0-f181.google.com with SMTP id e14so8796447iej.12 for ; Tue, 10 Dec 2013 07:01:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=5iDqmwOdKkKt15+9xiiNfdJjjUplx2N8LPtqwEt+7RI=; b=DPyU0hR/datqBg1V/vGP9fA8m92yed/iiz7bAXnZYdlLoM9T7lyw92Au8Ii+LVi3mi 1F+xctqVs9UUC7RTLnzQxYfWf0rVhN86lIUE0yfgBh4UWEgZ3Y2R4QIHY9k8pGy79JPs Ge5yhR8huSD0E4egQFKdpaw0iN1IPSTHNERvx1bB2fnmKguPVcg9S/mrjQehuGfQLt5S lob8FkNeHyitBOwbVfXYKQaJGFeVBMiE+v7usVoLi9slRYZEan/bMDkddiSNq2/lfgfe IqmrYSrogTBtDqGZMkeSoMHPuuwl290Pj60BquD9SA11+KKnSNJROemJb+pWzhD+SlnF aCcw== X-Received: by 10.50.92.8 with SMTP id ci8mr20232874igb.23.1386687667756; Tue, 10 Dec 2013 07:01:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.203.38 with HTTP; Tue, 10 Dec 2013 07:00:47 -0800 (PST) In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBF073B5@sc9-ex2k10mb1.corp.yaanatech.com> References: <20131120225753.9031.68753.idtracker@ietfa.amsl.com> <528F23D0.3080504@sit.fraunhofer.de> <05BCCEB107AF88469B9F99783D47C1D6065E4769@CISEXCHANGE1.msisac.org.local> <025d01cef178$63f56840$2be038c0$@comcast.net> <9904FB1B0159DA42B0B887B7FA8119CA12952A08@AZ-FFEXMB04.global.avaya.com> <00C069FD01E0324C9FFCADF539701DB3BBF01B8D@sc9-ex2k10mb1.corp.yaanatech.com> <05BCCEB107AF88469B9F99783D47C1D6065EFE47@CISEXCHANGE1.msisac.org.local> <9904FB1B0159DA42B0B887B7FA8119CA129DBB1D@AZ-FFEXMB04.global.avaya.com> <4b451425cbec406d94fa1a82b32fa1ab@BLUPR09MB038.namprd09.prod.outlook.com> <018701cef544$9d2ce730$d786b590$@comcast.net> <05BCCEB107AF88469B9F99783D47C1D6065F5476@CISEXCHANGE1.msisac.org.local> <00C069FD01E0324C9FFCADF539701DB3BBF073B5@sc9-ex2k10mb1.corp.yaanatech.com> From: Ira McDonald Date: Tue, 10 Dec 2013 10:00:47 -0500 Message-ID: To: Michael Hammer Content-Type: multipart/alternative; boundary=047d7b10cf27d9ebbe04ed2f6184 Cc: "ietfdbh@comcast.net" , "Adam.Montville@cisecurity.org" , "david.waltermire@nist.gov" , "sacm@ietf.org" Subject: Re: [sacm] FW: New Version Notification for draft-ietf-sacm-use-cases-05.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 15:01:38 -0000 --047d7b10cf27d9ebbe04ed2f6184 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, Actor roles are titlecase in IETF AAA Framework (RFC 2904). Cheers, - Ira Ira McDonald (Musician / Software Architect) Co-Chair - TCG Trusted Mobility Solutions WG Chair - Linux Foundation Open Printing WG Secretary - IEEE-ISTO Printer Working Group Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG IETF Designated Expert - IPP & Printer MIB Blue Roof Music / High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto: blueroofmusic@gmail.com Winter 579 Park Place Saline, MI 48176 734-944-0094 Summer PO Box 221 Grand Marais, MI 49839 906-494-2434 On Tue, Dec 10, 2013 at 9:50 AM, Michael Hammer < michael.hammer@yaanatech.com> wrote: > If they are formal terms defined in a document, I don=92t think > capitalization is a problem. > > How else do you distinguish them from randomly chosen English words? > > After all the whole reason to distinguish MUST versus must is just that. > > But, might be good to clarify that with Editor. > > > > Mike > > > > > > *From:* sacm [mailto:sacm-bounces@ietf.org] *On Behalf Of *Adam Montville > *Sent:* Tuesday, December 10, 2013 7:25 AM > *To:* ietfdbh; 'Ira McDonald'; 'Waltermire, David A.' > > *Cc:* sacm@ietf.org > *Subject:* Re: [sacm] FW: New Version Notification for > draft-ietf-sacm-use-cases-05.txt > > > > Thanks for pointing that out, David. This might be stylistic in some > ways, but these aren't titles they are roles. From that perspective we > could treat them as proper nouns, which would technically warrant > capitalization. But, better to stick with what the Editor would prefer, = I > think. > > > > Adam > > > ------------------------------ > > *From:* sacm [sacm-bounces@ietf.org] on behalf of ietfdbh [ > ietfdbh@comcast.net] > *Sent:* Monday, December 09, 2013 7:08 PM > *To:* 'Ira McDonald'; 'Waltermire, David A.' > *Cc:* sacm@ietf.org > *Subject:* Re: [sacm] FW: New Version Notification for > draft-ietf-sacm-use-cases-05.txt > > Hi, > > > > I=92d have to go look up a reference, but I believe the rfc editor consid= ers > it bad form to capitalize things that don=92t need to be capitalized. > > > > > > David Harrington > > ietfdbh@comcast.net > > +1-603-828-1401 > > *From:* sacm [mailto:sacm-bounces@ietf.org] *On Behalf Of *Ira McDonald > *Sent:* Monday, December 09, 2013 3:35 PM > *To:* Waltermire, David A.; Ira McDonald > *Cc:* sacm@ietf.org > *Subject:* Re: [sacm] FW: New Version Notification for > draft-ietf-sacm-use-cases-05.txt > > > > Hi Dave, > > I'm not sure if there's consensus about this, but I suggest that the > current > > lowercase "operator", "administrator", etc. (e.g., in 2.1.1) should be > > titlecase (first letter capitalized). > > Also that a new section 1.1 Actors be added that defines these actor > terms (one to three sentences each about what are typical actions or > responsibilities for each actor). > > From the original Design Goals for IPP (RFC 2567) here are some > admittedly printing-specific definitions, but they give the right flavor: > > "3.1. END-USER > > An end-user of a printer accepting jobs through the Internet is one > of the roles in which humans act. The end-user is the person that > will submit a job to be printed on the printer. > > The wants and needs of the end-user are broken down into six > categories: finding/locating a printer, creating a local instance of > a printer, viewing printer status, viewing printer capabilities, > submitting a print job, viewing print job status, altering the > attributes of a print job. > > 3.2. OPERATOR > > An operator of a printer accepting jobs through the Internet is one > of the roles in which humans act. The operator has the > responsibility of monitoring the status of the printer as well as > managing and controlling the jobs at the device. These > responsibilities include but are not limited to the replenishing of > supplies (ink, toner, paper, etc.), the clearing of minor errors > (paper jams, etc.) and the re-prioritization of end-user jobs. > Operator wants and needs will not be addressed by V1.0 of the > protocol. > > The wants and needs of the operator include all those of the end-user > but may include additional privileges. For example, an operator may > be able to view all print jobs on a printer while the end-user might > only be able to see his own jobs. > > 3.3. ADMINISTRATOR > > An administrator of a printer accepting jobs through the Internet is > one of the roles in which humans act. The administrator has the > responsibility of creating the printer instances and controlling the > authorization of other end-users and operators. Administrator wants > and needs will not be addressed by V1.0 of the protocol. > > The wants and needs of the administrator include all those of the > end-user and, in some environments, some or all of those of the > operator. Minimally, the administrator must also have the tools, > programs, utilities and supporting protocols available to be able to: > > - create an instance of a printer > - create, edit and maintain the list of authorized end-users > - create, edit and maintain the list of authorized operators > - create, edit and maintain the list of authorized > administrators > - create, customize, change or otherwise alter the manner in > which the status capabilities and other information about printers > and jobs are presented > - create, customize, or change other printer or job features > - administrate billing or other charge-back mechanisms > - create sets of defaults > - create sets of capabilities > > The administrator must have the capability to perform all the above > tasks locally or remotely to the printer." > > From later IPP Get-Notifications (RFC 3997), here are much shorter > > definitions: > > "2.1. Job-Submitting End User > > A human end user who submits a print job to an IPP Printer. This > person may or may not be within the same security domain as the > Printer. This person may or may not be geographically near the > printer. > > 2.2. Administrator > > A human user who established policy for and configures the print > system. > > 2.3. Operator > > A human user who carries out the policy established by the > Administrator and controls the day-to-day running of the print > system." > > As Nancy said, we need also: Application, System. > > Cheers, > > - Ira > > > Ira McDonald (Musician / Software Architect) > Co-Chair - TCG Trusted Mobility Solutions WG > Chair - Linux Foundation Open Printing WG > Secretary - IEEE-ISTO Printer Working Group > Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG > IETF Designated Expert - IPP & Printer MIB > Blue Roof Music / High North Inc > http://sites.google.com/site/blueroofmusic > http://sites.google.com/site/highnorthinc > mailto: blueroofmusic@gmail.com > Winter 579 Park Place Saline, MI 48176 734-944-0094 > Summer PO Box 221 Grand Marais, MI 49839 906-494-2434 > > > > On Mon, Dec 9, 2013 at 3:12 PM, Waltermire, David A. < > david.waltermire@nist.gov> wrote: > > +1. I too like this approach. This has been a good discussion. > > > > To direct this dialog towards actionable changes to the use cases draft, > is there specific draft text that should be updated to make the roles and > their relevance to a use case or usage scenario more clear? > > > > Thanks, > > Dave > > > > *From:* sacm [mailto:sacm-bounces@ietf.org] *On Behalf Of * > Kent_Landfield@McAfee.com > *Sent:* Sunday, December 08, 2013 12:20 PM > > > *To:* sacm@ietf.org > *Subject:* Re: [sacm] FW: New Version Notification for > draft-ietf-sacm-use-cases-05.txt > > > > +1 > > > > I like the terminology Ira and Adam have suggested. > > > > *Kent Landfield* > > *McAfee | An Intel Company* > Direct: +1.972.963.7096 > Mobile: +1.817.637.8026 > *Web: *www.mcafee.com > > > > *From: *, "Dan (Dan)" > *Date: *Sunday, December 8, 2013 7:43 AM > *To: *Adam Montville , Ira McDonald < > blueroofmusic@gmail.com>, Michael Hammer > *Cc: *"dbharrington@comcast.net" , David > Waltermire , "sacm@ietf.org" , = " > henk.birkholz@sit.fraunhofer.de" > *Subject: *Re: [sacm] FW: New Version Notification for > draft-ietf-sacm-use-cases-05.txt > > > > +1 > > > > Dan > > > > Speaking as contributor =96 better to say it clearly if there are reasons= to > wonder > > > > > > *From:* Adam Montville [mailto:Adam.Montville@cisecurity.org] > > *Sent:* Friday, December 06, 2013 3:12 AM > *To:* Ira McDonald; Michael Hammer > *Cc:* Romascanu, Dan (Dan); dbharrington@comcast.net; > david.waltermire@nist.gov; henk.birkholz@sit.fraunhofer.de; sacm@ietf.org > *Subject:* RE: [sacm] FW: New Version Notification for > draft-ietf-sacm-use-cases-05.txt > > > > I like this set of terminology. End User, Operator, Administrator, and > Application. Then, Application can potentially have further specificatio= n > as we move forward. For example, Analysis Application, Acquisition > Application, and so on. > > > > Whatever we choose, I would prefer to choose terms that we can easily use > consistently. > > > > Adam > > > > (I'm assuming, but perhaps shouldn't, that when I comment like this it's > as a contributor) > > > ------------------------------ > > *From:* Ira McDonald [blueroofmusic@gmail.com] > *Sent:* Thursday, December 05, 2013 8:48 AM > *To:* Michael Hammer > *Cc:* dromasca@avaya.com; dbharrington@comcast.net; > david.waltermire@nist.gov; Adam Montville; henk.birkholz@sit.fraunhofer.d= e; > sacm@ietf.org > *Subject:* Re: [sacm] FW: New Version Notification for > draft-ietf-sacm-use-cases-05.txt > > Hi, > > My two cents - End User, Operator, and Administrator are quite distinct > > roles of actors in standards from many SDOs - they have inherently > > distinct default privileges - using these common role terms consistently > > would make SACM use cases more accessible to non-participants in > the SACM WG. > > BTW - there are a few other roles of actors that should probably be > > used in SACM use cases, e.g., Application - although tthat's a slippery > > slope, because normal applications (browsers, email readers, etc.) > > have very different privileges and responsibilities from security-specifi= c > > applications (MDM agents, anti-virus scanners, etc.). > > Cheers, > > - Ira > > > Ira McDonald (Musician / Software Architect) > Co-Chair - TCG Trusted Mobility Solutions WG > Chair - Linux Foundation Open Printing WG > Secretary - IEEE-ISTO Printer Working Group > Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG > IETF Designated Expert - IPP & Printer MIB > Blue Roof Music / High North Inc > http://sites.google.com/site/blueroofmusic > http://sites.google.com/site/highnorthinc > mailto: blueroofmusic@gmail.com > Winter 579 Park Place Saline, MI 48176 734-944-0094 > Summer PO Box 221 Grand Marais, MI 49839 906-494-2434 > > > > On Thu, Dec 5, 2013 at 9:12 AM, Michael Hammer < > michael.hammer@yaanatech.com> wrote: > > Actor connotes human to me. > > What would be wrong with using client or server if asymmetric, or user > agent > if peering? > With adjectives to differentiate types. > > Mike > > > > -----Original Message----- > From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Romascanu, Dan > (Dan) > Sent: Thursday, December 05, 2013 4:52 AM > To: David Harrington; 'Waltermire, David A.'; 'Adam Montville'; 'Henk > Birkholz'; sacm@ietf.org > Subject: Re: [sacm] FW: New Version Notification for > draft-ietf-sacm-use-cases-05.txt > > I share DBH's concern. There may be significant differences in workflows > and > interface requirements between systems (networks, devices) and humans vs. > systems (networks, devices) and applications. There may be significant > differences if the humans are operators or end-users. Using one term (say > 'actor') for all may create ambiguities. I am not sure that I understand > the > advantages of the proposed abstraction. > > Dan > (speaking as contributor) > > > > -----Original Message----- > > From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of David Harrington > > Sent: Thursday, December 05, 2013 7:11 AM > > To: 'Waltermire, David A.'; 'Adam Montville'; 'Henk Birkholz'; > > sacm@ietf.org > > Subject: Re: [sacm] FW: New Version Notification for draft-ietf-sacm- > > use-cases-05.txt > > > > Hi, > > > > Using actor concerns me. > > I find it important to understand whether some content needs to be > > parsed by a human (with our wonderful ability to parse), or a computer > > application (which is bound by a set of rules, and has great difficulty > > when the content is not consistent with the rules). > > > > Around 2003, the operators made it clear that CLIs were difficult to > > work with, because queries would return information in variable formats= . > > While humans might be able to parse the output that might change from > > vendor to vendor, model to model, and release to release, tools had > > significant difficulty due to the lack of standardization. Operators > > could try to deal with the lack of standardization by writing expect > > scripts, but they would need to be updated constantly because what > > worked for one release of a product might not be the same in the next > > release. > > Humans can parse variable syntax, such as the natural language content > > of syslog, but applications can have a hard time. > > > > I think is very important to know whether we are designing something fo= r > > human consumption or for computer consumption. > > "Actor" doesn't provide enough differentiation to know how to design ou= r > > solutions. > > > > David Harrington > > dbharrington@comcast.net > > +1-603-828-1401 > > > > > -----Original Message----- > > > From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Waltermire, > > > David A. > > > Sent: Wednesday, December 04, 2013 8:54 PM > > > To: Adam Montville; Henk Birkholz; sacm@ietf.org > > > Subject: Re: [sacm] FW: New Version Notification for > > > draft-ietf-sacm-use- cases-05.txt > > > > > > Comments inline. > > > > > > > -----Original Message----- > > > > From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Adam > > > > Montville > > > > Sent: Wednesday, December 04, 2013 8:38 PM > > > > To: Henk Birkholz; sacm@ietf.org > > > > Subject: Re: [sacm] FW: New Version Notification for > > draft-ietf-sacm-use- > > > > cases-05.txt > > > > > > > > Something I've found helpful in the past is to abstract a bit > > > > further > > from > > > > "user", "operator", "application" and simply reference all of them > > > > at > > once > > > > with the term "actor". > > > > > > Are we ok with the change to using actor? The current usage of "user"= , > > > "operator", "application" (specifically the last two) was suggested a > > while > > > back to align with IETF terminology. Does use of "actor" to reference > > > all > > three > > > concepts raise any concerns? > > > > > > > I also believe that listing *potential* acquisition methods is > > > > useful in > > at least > > > > the following way: Including a multitude of acquisition methods > > > > clearly > > > signals > > > > our intent of finding information where it already exists, while no= t > > > > necessarily precluding our ability to *get* information when > > > > information does not exist. > > > > > > Adam, would you or Henk provide some example acquisition methods for > > > discussion? > > > > > > > Finally, I, too, like the notion of a work-flow scenario. I don't > > > > want > > to be > > > the > > > > one drawing a process diagram in an RFC, though. ;-) > > > > > > How would this differ from the workflow scenario text in section 2? > > > > > > Are you suggesting representing this text in a visual form? If so, > > > would anyone like to make a contribution of some ascii art? > > > > > > > awm > > > > ________________________________________ > > > > From: sacm [sacm-bounces@ietf.org] on behalf of Henk Birkholz > > > > [henk.birkholz@sit.fraunhofer.de] > > > > Sent: Friday, November 22, 2013 3:27 AM > > > > To: sacm@ietf.org > > > > Subject: Re: [sacm] FW: New Version Notification for > > draft-ietf-sacm-use- > > > > cases-05.txt > > > > > > > > Regarding the first two question in section 2: > > > > > > > > 1.) Security automation today often supports the user/operator, I > > think. > > > > There are cases a security-process can be fully automated, of > > > > course, > > and in > > > > order to manage the sheer amount of security related system events > > > > automation is essential, but it seems to me that the complexity and > > > > heterogeneity of root-causes (that might trigger the work-flow) mak= e > > > > the inclusion of a user/operator necessary. > > > > > > > > 2.) To include acquisition methods can provide an intuitive insight > > about the > > > > scope and intend of the endpoint posture assessment domain, I think= . > > > > On one hand, that might bloat the use-case document a bit (and mayb= e > > > renders > > > > the title "sacm use cases" too specific?). On the other hand, I lik= e > > > > the inclusion of a work-flow scenario and I think it is a good plac= e > > > > to > > highlight > > > > acquisition methods. > > > > > > > > - Henk > > > > > > > > On 11/21/2013 12:27 AM, Waltermire, David A. wrote: > > > > > I just posted an updated use case draft based on the editorial > > sessions > > > > during the IETF 88 meeting in Vancouver, BC, Canada. My thanks to > > > > all > > that > > > > provided input. > > > > > > > > > > I used the word version that we edited as a starting point. Here > > > > > is > > what I > > > > did: > > > > > > > > > > - I worked through the use cases we planned to remove and made > > > > > sure > > > to > > > > merge in any concepts that would be lost. If you submitted a > > > > previous > > use > > > > case that was removed, please double check that I didn't miss > > anything. > > > > > - I broke up "Endpoint Identification and Assessment" into 3 > > > > > distinct > > and > > > > somewhat separable use cases: "Endpoint Identification and > > > > Assessment Planning", "Endpoint Posture Attribute Value Collection"= , > > > > "Posture Evaluation". Please let me know what you think about this > > change. > > > > > - Addressed some aspects of the discussion thread based on the > > > > > working > > > > session changes. Please provide any suggested edits for aspects tha= t > > > > I > > > might > > > > have missed or got wrong. > > > > > > > > > > The rest of the changes can be found in the draft's change log. > > > > > > > > > > If possible, I'd like to get to a fairly stable place with this > > > > > draft > > in the next > > > > revision or two to allow for progress to be made on the > > > > requirements. In addition to the embedded questions in the document= , > > > > I'd like to focus on > > > the > > > > following questions: > > > > > > > > > > Is the draft approachable for a newcomer to the effort? Do you se= e > > > > > the > > > > updated use case structure as an improvement? > > > > > Does this draft paint a complete enough picture? Are we missing > > > > > any > > > > important concepts? > > > > > Is there anything you can't live with? > > > > > > > > > > I hope to release at least one or two more updates to this draft > > within the > > > > next few weeks before the holidays catch up on us. I know everyone > > > > is busy; timely comments are appreciated to allow for a quick > > > > turnaround on the next revision. > > > > > > > > > > Thanks, > > > > > Dave > > > > > > > > > > -----Original Message----- > > > > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > > > > Sent: Wednesday, November 20, 2013 5:58 PM > > > > > To: Waltermire, David A.; David Harrington > > > > > Subject: New Version Notification for > > > > > draft-ietf-sacm-use-cases-05.txt > > > > > > > > > > > > > > > A new version of I-D, draft-ietf-sacm-use-cases-05.txt has been > > > > successfully submitted by David Waltermire and posted to the IETF > > > > repository. > > > > > > > > > > Filename: draft-ietf-sacm-use-cases > > > > > Revision: 05 > > > > > Title: Endpoint Security Posture Assessment - > > Enterprise Use > > > Cases > > > > > Creation date: 2013-11-20 > > > > > Group: sacm > > > > > Number of pages: 24 > > > > > URL: > > http://www.ietf.org/internet-drafts/draft-ietf-sacm-use- > > > cases- > > > > 05.txt > > > > > Status: > > http://datatracker.ietf.org/doc/draft-ietf-sacm-use-cases > > > > > Htmlized: > > http://tools.ietf.org/html/draft-ietf-sacm-use-cases-05 > > > > > Diff: > > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sacm-use-cases-05 > > > > > > > > > > Abstract: > > > > > This memo documents a sampling of use cases for securely > > aggregating > > > > > configuration and operational data and evaluating that data t= o > > > > > determine an organization's security posture. From these > > operational > > > > > use cases, we can derive common functional capabilities and > > > > > requirements to guide development of vendor-neutral, > > interoperable > > > > > standards for aggregating and evaluating data relevant to > > security > > > > > posture. > > > > > > > > > > > > > > > > > > > > > > > > > Please note that it may take a couple of minutes from the time of > > > > submission until the htmlized version and diff are available at > > tools.ietf.org. > > > > > > > > > > The IETF Secretariat > > > > > > > > > > _______________________________________________ > > > > > sacm mailing list > > > > > sacm@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/sacm > > > > > > > > > > > > > > > > > > > > > ... > > > > > > > > . . . > > > > _______________________________________________ > > > > sacm mailing list > > > > sacm@ietf.org > > > > https://www.ietf.org/mailman/listinfo/sacm > > > _______________________________________________ > > > sacm mailing list > > > sacm@ietf.org > > > https://www.ietf.org/mailman/listinfo/sacm > > > > _______________________________________________ > > sacm mailing list > > sacm@ietf.org > > https://www.ietf.org/mailman/listinfo/sacm > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > > > > > ... > > This message and attachments may contain confidential information. If it > appears that this message was sent to you by mistake, any retention, > dissemination, distribution or copying of this message and attachments is > strictly prohibited. Please notify the sender immediately and permanently > delete the message and any attachments. > . . . > > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > > > > > ... > > > . . . > --047d7b10cf27d9ebbe04ed2f6184 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi,

Actor roles are titlecase = in IETF AAA Framework (RFC 2904).

Cheers,
- Ira

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



On Tue, Dec 10, 2013 at 9:50 AM, Michael= Hammer <michael.hammer@yaanatech.com> wrote:
=

If they are formal terms defined in a docume= nt, I don=92t think capitalization is a problem.

How else do you distingui= sh them from randomly chosen English words?

After all the whole reason to distinguish MUST v= ersus must is just that.

But, might be good to clarify that with Editor.<= /u>

=A0<= /p>

Mike

=A0<= /p>

=A0

From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Adam Montville
Sent: Tuesday, December 10, 2013 7:25 AM
To: ietfdbh; '= ;Ira McDonald'; 'Waltermire, David A.'


Cc: = sacm@ietf.org
Subject: Re: [sacm] FW: New Version Notification for draft-ietf-sacm= -use-cases-05.txt

=A0

Thanks for pointing that out, David. =A0This might be stylistic= in some ways, but these aren't titles they are roles. =A0From that per= spective we could treat them as proper nouns, which would technically warra= nt capitalization. =A0But, better to stick with what the Editor would prefe= r, I think.

=A0

<= div>

Adam

=A0

= From: sacm [sacm-bounces@ietf.org] on behalf of ietf= dbh [ietfdbh@comca= st.net]
Sent: Monday, December 09, 2013 7:08 PM
To: 'Ira McDon= ald'; 'Waltermire, David A.'
Cc: sacm@ietf.org
Subject: Re: [sa= cm] FW: New Version Notification for draft-ietf-sacm-use-cases-05.txt

Hi,

=A0=

I= =92d have to go look up a reference, but I believe the rfc editor considers= it bad form to capitalize things that don=92t need to be capitalized.

=A0=

=A0=

David Harrington

ietfdbh@comcas= t.net

+1-603-828-1401<= span style>

From:= sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Ira McDo= nald
Sent: Monday, December 09, 2013 3:35 PM
To: Waltermire, Da= vid A.; Ira McDonald
Cc: sacm@ietf.org
Subject: Re: [sacm] FW: New Version= Notification for draft-ietf-sacm-use-cases-05.txt

=A0

=

Hi Dave,

I'm not sure if there's consensus about this, but I sug= gest that the current

= lowercase "operator", "administrator", etc.= (e.g., in 2.1.1) should be

tit= lecase (first letter capitalized).

Also that a new s= ection 1.1 Actors be added that defines these actor
terms (one to three sentences each about what are typical actions or
res= ponsibilities for each actor).

From the original= Design Goals for IPP (RFC 2567) here are some
admittedly printing-specific definitions, but they give the right flavor:
"3.1. END-USER

=A0=A0 An end-user of a printer accepting = jobs through the Internet is one
=A0=A0 of the roles in which humans act= .=A0 The end-user is the person that
=A0=A0 will submit a job to be printed on the printer.

=A0=A0 The wa= nts and needs of the end-user are broken down into six
=A0=A0 categories= : finding/locating a printer, creating a local instance of
=A0=A0 a prin= ter, viewing printer status, viewing printer capabilities,
=A0=A0 submitting a print job, viewing print job status, altering the
= =A0=A0 attributes of a print job.

3.2. OPERATOR

=A0=A0 An ope= rator of a printer accepting jobs through the Internet is one
=A0=A0 of = the roles in which humans act.=A0 The operator has the
=A0=A0 responsibility of monitoring the status of the printer as well as=A0=A0 managing and controlling the jobs at the device.=A0 These
=A0=A0= responsibilities include but are not limited to the replenishing of
=A0= =A0 supplies (ink, toner, paper, etc.), the clearing of minor errors
=A0=A0 (paper jams, etc.) and the re-prioritization of end-user jobs.
= =A0=A0 Operator wants and needs will not be addressed by V1.0 of the
=A0= =A0 protocol.

=A0=A0 The wants and needs of the operator include all= those of the end-user
=A0=A0 but may include additional privileges.=A0 For example, an operator m= ay
=A0=A0 be able to view all print jobs on a printer while the end-user= might
=A0=A0 only be able to see his own jobs.

3.3. ADMINISTRATO= R

=A0=A0 An administrator of a printer accepting jobs through the Internet is=
=A0=A0 one of the roles in which humans act.=A0 The administrator has the=A0=A0 responsibility of creating the printer instances and controlling t= he
=A0=A0 authorization of other end-users and operators.=A0 Administrat= or wants
=A0=A0 and needs will not be addressed by V1.0 of the protocol.

=A0= =A0 The wants and needs of the administrator include all those of the
= =A0=A0 end-user and, in some environments, some or all of those of the
= =A0=A0 operator.=A0 Minimally, the administrator must also have the tools,<= br> =A0=A0 programs, utilities and supporting protocols available to be able to= :

=A0=A0 - create an instance of a printer
=A0=A0 - create, edit = and maintain the list of authorized end-users
=A0=A0 - create, edit and = maintain the list of authorized operators
=A0=A0 - create, edit and maintain the list of authorized
=A0=A0=A0=A0 a= dministrators
=A0=A0 - create, customize, change or otherwise alter the = manner in
=A0=A0=A0=A0 which the status capabilities and other informati= on about printers
=A0=A0=A0=A0 and jobs are presented
=A0=A0 - create, customize, or chang= e other printer or job features
=A0=A0 - administrate billing or other c= harge-back mechanisms
=A0=A0 - create sets of defaults
=A0=A0 - creat= e sets of capabilities

=A0=A0 The administrator must have the capability to perform all the ab= ove
=A0=A0 tasks locally or remotely to the printer."=

From later IPP Get= -Notifications (RFC 3997), here are much shorter

definitions:

"2.1.=A0 Job-Submitting End User

=A0=A0 A= human end user who submits a print job to an IPP Printer.=A0 This
=A0= =A0 person may or may not be within the same security domain as the
=A0=A0 Printer.=A0 This person may or may not be geographically near the=A0=A0 printer.

2.2.=A0 Administrator

=A0=A0 A human user wh= o established policy for and configures the print
=A0=A0 system.

= 2.3.=A0 Operator

=A0=A0 A human user who carries out the policy established by the
= =A0=A0 Administrator and controls the day-to-day running of the print
= =A0=A0 system."

As Nancy said, we need also:=A0 Application, System.<= /u>

Cheers,

- Ira


<= /u>

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

=A0

On Mon, Dec 9, 2013 at 3:12 PM, Wal= termire, David A. <david.waltermire@nist.gov> wrote:

+1. I too like this = approach. This has been a good discussion.=

=A0=

To = direct this dialog towards actionable changes to the use cases draft, is th= ere specific draft text that should be updated to make the roles and their = relevance to a use case or usage scenario more clear?=

=A0=

Tha= nks,

Dave

= =A0

From:= sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Kent_Landfield@McAfee.com
Sent: Sunday, December 08, 2013 12:20 PM


To:= sacm@ietf.org
Subject: Re: [sacm] FW: New Version Notification for draft-ietf-sacm-u= se-cases-05.txt

=A0=

+1<= u>

=A0

I like the terminology Ira an= d Adam have suggested.

=A0

Kent Landfield

McAfee | An Intel Company
Direct: +1.972.963.7096=A0
Mobile: +1.817.637.8026
Web:=A0www.mcafee.com

=A0

<= div style=3D"border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0in 0= in 0in">

From: <Romascanu>, "Dan (Dan)" <dromasca@avaya.com>
Date: Sunday, December 8, 2013 7:43 AM
To: Adam Montville = <Adam= .Montville@cisecurity.org>, Ira McDonald <blueroofmusic@gmail.com>, Mich= ael Hammer <michael.hammer@yaanatech.com>
Cc: "dbharrington@comcast.net" <dbharrington@comcast.net>, David Walte= rmire <da= vid.waltermire@nist.gov>, "sacm@ietf.org" <sacm@ietf.org>, "henk.birkholz@sit.fraunhofer.de" <henk.birkholz@sit.fraunhofer.de>
Subject: Re: [sacm] FW: New Version Notification for draft-ietf-sacm= -use-cases-05.txt

=A0

+1

=A0

Dan=

=A0=

Speaking as contributor = =96 better to say it clearly if there are reasons to wonder

=A0=

=A0=

From:= Adam Montville [mailto:Adam.Montville@cisecurity.org]
Sent: Friday, December 06, 2013 3:12 AM
To: Ira McDonald; = Michael Hammer
Cc: Romascanu, Dan (Dan); dbharrington@comcast.net; david.waltermire@ni= st.gov; henk.birkholz@sit.fraunhofer.de; sacm@ietf.org
Subject: RE: [sacm] FW: New Version Notification for draft-ietf-sacm= -use-cases-05.txt

=A0

I like this set of terminology. =A0End User, Operator, Administ= rator, and Application. =A0Then, Application can potentially have further s= pecification as we move forward. =A0For example, Analysis Application, Acqu= isition Application, and so on. =A0

=A0

Whatever we choos= e, I would prefer to choose terms that we can easily use consistently.=A0 <= /span>

=A0

Adam

=A0=

(I'm as= suming, but perhaps shouldn't, that when I comment like this it's a= s a contributor)

=A0

From= : Ira McDonald [blueroofmusic@gmail.com]
Sent: Thursday, December 05, 2013 8:48 AM
To: Michael Hamm= er
Cc: dr= omasca@avaya.com; dbharrington@comcast.net; david.waltermire@nist.gov; Adam Montville; <= a href=3D"mailto:henk.birkholz@sit.fraunhofer.de" target=3D"_blank">henk.bi= rkholz@sit.fraunhofer.de; sacm@ietf.org
Subject: Re: [sacm] FW: New Version Notification for draft-ietf-sacm= -use-cases-05.txt

Hi,

My two cents - End User, Operator, and Administrator are quite distin= ct

roles o= f actors in standards from many SDOs - they have inherently

distinct default privileges - usin= g these common role terms consistently

<= p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">would make= SACM use cases more accessible to non-participants in
the SACM WG.

BTW - there are a few other roles of actors that should probably be=

used= in SACM use cases, e.g., Application - although tthat's a slippery<= /u>

slope, because normal applica= tions (browsers, email readers, etc.)

have very different privileges and respons= ibilities from security-specific

applications (MDM agents, anti-virus scanners, etc.).

Cheers,

- Ira


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

=A0

On T= hu, Dec 5, 2013 at 9:12 AM, Michael Hammer <michael.hammer@yaanatech.com> = wrote:

Actor connotes human to me.

What = would be wrong with using client or server if asymmetric, or user agent
= if peering?
With adjectives to differentiate types.

Mike



-----Original Message-= ----
From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan)Sent: Thursday, December 05, 2013 4:52 AM
To: David Harrington; 'Waltermire, David A.'; 'Adam Montville&#= 39;; 'Henk
Birkholz'; sacm@ietf.org
Subject: Re: [sacm] FW: New Version Notificat= ion for
draft-ietf-sacm-use-cases-05.txt

I share DBH's concern. There ma= y be significant differences in workflows and
interface requirements bet= ween systems (networks, devices) and humans vs.
systems (networks, devic= es) and applications. There may be significant
differences if the humans are operators or end-users. Using one term (say'actor') for all may create ambiguities. I am not sure that I und= erstand the
advantages of the proposed abstraction.

Dan
(speak= ing as contributor)


> -----Original Message-----
> From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of David Harrington
> Sent: Thursday, December 05, 2013= 7:11 AM
> To: 'Waltermire, David A.'; 'Adam Montville'; 'Hen= k Birkholz';
> sacm@ietf.org
> Subject: Re: [sacm] FW: New Version Notification= for draft-ietf-sacm-
> use-cases-05.txt
>
> Hi,
>
> Using actor conce= rns me.
> I find it important to understand whether some content need= s to be
> parsed by a human (with our wonderful ability to parse), or= a computer
> application (which is bound by a set of rules, and has great difficult= y
> when the content is not consistent with the rules).
>
&g= t; Around 2003, the operators made it clear that CLIs were difficult to
> work with, because queries would return information in variable format= s.
> While humans might be able to parse the output that might change= from
> vendor to vendor, model to model, and release to release, too= ls had
> significant difficulty due to the lack of standardization. Operators> could try to deal with the lack of standardization by writing expect=
> scripts, but they would need to be updated constantly because what=
> worked for one release of a product might not be the same in the next<= br>> release.
> Humans can parse variable syntax, such as the natu= ral language content
> of syslog, but applications can have a hard ti= me.
>
> I think is very important to know whether we are designing som= ething for
> human consumption or for computer consumption.
> &= quot;Actor" doesn't provide enough differentiation to know how to = design our
> solutions.
>
> David Harrington
> dbharrington@comcast.net> +1-603-828-1401
>
> > -----Original Message-----
> > From: sacm [mailt= o:sacm-bounces@i= etf.org] On Behalf Of Waltermire,
> > David A.
> > Se= nt: Wednesday, December 04, 2013 8:54 PM
> > To: Adam Montville; Henk Birkholz; sacm@ietf.org
> > Subject: Re: [sacm] FW:= New Version Notification for
> > draft-ietf-sacm-use- cases-05.tx= t
> >
> > Comments inline.
> >
> > > ----= -Original Message-----
> > > From: sacm [mailto:sacm-bounces@ietf.org] On B= ehalf Of Adam
> > > Montville
> > > Sent: Wednesday, December 04, 20= 13 8:38 PM
> > > To: Henk Birkholz; sacm@ietf.org
> > > Subject: Re: [s= acm] FW: New Version Notification for
> draft-ietf-sacm-use-
> > > cases-05.txt
> > ><= br>> > > Something I've found helpful in the past is to abstra= ct a bit
> > > further
> from
> > > "use= r", "operator", "application" and simply reference= all of them
> > > at
> once
> > > with the term "actor&= quot;.
> >
> > Are we ok with the change to using actor? = The current usage of "user",
> > "operator", &= quot;application" (specifically the last two) was suggested a
> while
> > back to align with IETF terminology. Does use of &q= uot;actor" to reference
> > all
> three
> > co= ncepts raise any concerns?
> >
> > > I also believe th= at listing *potential* acquisition methods is
> > > useful in
> at least
> > > the following w= ay: Including a multitude of acquisition methods
> > > clearly<= br>> > signals
> > > our intent of finding information wh= ere it already exists, while not
> > > necessarily precluding our ability to *get* information when=
> > > information does not exist.
> >
> > Ad= am, would you or Henk provide some example acquisition methods for
> > discussion?
> >
> > > Finally, I, too, like the notion of a work-flow= scenario. =A0I don't
> > > want
> to be
> >= the
> > > one drawing a process diagram in an RFC, though. ;-)=
> >
> > How would this differ from the workflow scenario tex= t in section 2?
> >
> > Are you suggesting representing t= his text in a visual form? If so,
> > would anyone like to make a = contribution of some ascii art?
> >
> > > awm
> > > _________________________= _______________
> > > From: sacm [sacm-bounces@ietf.org] on behalf of Henk = Birkholz
> > > [henk.birkholz@sit.fraunhofer.de]
> > > Sent: Fr= iday, November 22, 2013 3:27 AM
> > > To: sacm@ietf.org
> > > Subject: Re: [sacm] FW: New Version Notification for
>= draft-ietf-sacm-use-
> > > cases-05.txt
> > >
&= gt; > > Regarding the first two question in section 2:
> > &= gt;
> > > 1.) Security automation today often supports the user/operat= or, I
> think.
> > > There are cases a security-process c= an be fully automated, of
> > > course,
> and in
> > > order to manage the sheer amount of security related system = events
> > > automation is essential, but it seems to me that the complex= ity and
> > > heterogeneity of root-causes (that might trigger = the work-flow) make
> > > the inclusion of a user/operator nece= ssary.
> > >
> > > 2.) To include acquisition methods can pro= vide an intuitive insight
> about the
> > > scope and int= end of the endpoint posture assessment domain, I think.
> > > O= n one hand, that might bloat the use-case document a bit (and maybe
> > renders
> > > the title "sacm use cases" to= o specific?). On the other hand, I like
> > > the inclusion of = a work-flow scenario and I think it is a good place
> > > to > highlight
> > > acquisition methods.
> > >
= > > > - Henk
> > >
> > > On 11/21/2013 12:= 27 AM, Waltermire, David A. wrote:
> > > > I just posted an = updated use case draft based on the editorial
> sessions
> > > during the IETF 88 meeting in Vancouver, BC= , Canada. My thanks to
> > > all
> that
> > >= provided input.
> > > >
> > > > I used the w= ord version that we edited as a starting point. Here
> > > > is
> what I
> > > did:
> > &= gt; >
> > > > - I worked through the use cases we planned= to remove and made
> > > > sure
> > to
> >= ; > merge in any concepts that would be lost. If you submitted a
> > > previous
> use
> > > case that was removed= , please double check that I didn't miss
> anything.
> >= > > - I broke up "Endpoint Identification and Assessment" = into 3
> > > > distinct
> and
> > > somewhat separab= le use cases: "Endpoint Identification and
> > > Assessmen= t Planning", "Endpoint Posture Attribute Value Collection",<= br> > > > "Posture Evaluation". Please let me know what you = think about this
> change.
> > > > - Addressed some as= pects of the discussion thread based on the
> > > > working<= br> > > > session changes. Please provide any suggested edits for aspe= cts that
> > > I
> > might
> > > have miss= ed or got wrong.
> > > >
> > > > The rest of = the changes can be found in the draft's change log.
> > > >
> > > > If possible, I'd like to get= to a fairly stable place with this
> > > > draft
> in= the next
> > > revision or two to allow for progress to be mad= e on the
> > > requirements. In addition to the embedded questions in the d= ocument,
> > > I'd like to focus on
> > the
>= ; > > following questions:
> > > >
> > > &= gt; Is the draft approachable for a newcomer to the effort? Do you see
> > > > the
> > > updated use case structure as an = improvement?
> > > > Does this draft paint a complete enough= picture? Are we missing
> > > > any
> > > impor= tant concepts?
> > > > Is there anything you can't live with?
> >= > >
> > > > I hope to release at least one or two mor= e updates to this draft
> within the
> > > next few weeks= before the holidays catch up on us. =A0I know everyone
> > > is busy; timely comments are appreciated to allow for a quic= k
> > > turnaround on the next revision.
> > > >=
> > > > Thanks,
> > > > Dave
> > &g= t; >
> > > > -----Original Message-----
> > > > From:= internet-dra= fts@ietf.org [mailto:internet-drafts@ietf.org]
> > > > Sent: Wednesday, November 20, 2013 5:58 PM
> >= > > To: Waltermire, David A.; David Harrington
> > > >= ; Subject: New Version Notification for
> > > > draft-ietf-s= acm-use-cases-05.txt
> > > >
> > > >
> > > > A new ver= sion of I-D, draft-ietf-sacm-use-cases-05.txt has been
> > > su= ccessfully submitted by David Waltermire and posted to the IETF
> >= ; > repository.
> > > >
> > > > Filename: =A0 =A0 =A0draft-ietf-= sacm-use-cases
> > > > Revision: =A0 =A0 =A005
> > = > > Title: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Endpoint Security Posture = Assessment -
> Enterprise Use
> > Cases
> > > > Creation date: =A0 =A0 =A0 =A0 2013-= 11-20
> > > > Group: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 sacm> > > > Number of pages: 24
> > > > URL:
>= ; http://www.ietf.org/internet-drafts/draft-ietf-sacm-use-<= br> > > cases-
> > > 05.txt
> > > > Status:> http://datatracker.ietf.org/doc/draft-ietf-sacm-use-case= s
> > > > Htmlized:
> http://tools.ietf.org/html= /draft-ietf-sacm-use-cases-05
> > > > Diff:
> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sacm-use-cases= -05
> > > >
> > > > Abstract:
> > > >= =A0 =A0 This memo documents a sampling of use cases for securely
> a= ggregating
> > > > =A0 =A0 configuration and operational dat= a and evaluating that data to
> > > > =A0 =A0 determine an organization's security postur= e. =A0From these
> operational
> > > > =A0 =A0 use cas= es, we can derive common functional capabilities and
> > > >= =A0 =A0 requirements to guide development of vendor-neutral,
> interoperable
> > > > =A0 =A0 standards for aggregating= and evaluating data relevant to
> security
> > > > = =A0 =A0 posture.
> > > >
> > > >
> >= > >
> > > >
> > > > Please note that it may take a c= ouple of minutes from the time of
> > > submission until the ht= mlized version and diff are available at
> tools.ietf.org.
> > > >
> > > > The IETF Secretariat
> >= ; > >
> > > > ________________________________________= _______
> > > > sacm mailing list
> > > > sacm@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/sacm
> &g= t; > >
> > >
> > >
> > >
> = > > ...
> > >
> > > . . .
> > > __________________= _____________________________
> > > sacm mailing list
> &= gt; > sacm@ietf.org
> > > https://www.ietf.org/mailman/listinfo/sacm
> > __= _____________________________________________
> > sacm mailing lis= t
> > sacm@ietf.org<= /a>
> > https://www.ietf.org/mailman/listinfo/sacm
>
&g= t; _______________________________________________
> sacm mailing list
> sacm@ietf.org
> https://www.ietf.org/mailman/listinfo/sacm
_______________________________________________
sacm mailing list
sacm@ietf.org
https://= www.ietf.org/mailman/listinfo/sacm


_______________________________________________
sacm mailing list=
sacm@ietf.orgh= ttps://www.ietf.org/mailman/listinfo/sacm

=A0

=


...

This message= and attachments may contain confidential information. If it appears that t= his message was sent to you by mistake, any retention, dissemination, distr= ibution or copying of this message and attachments is strictly prohibited. = Please notify the sender immediately and permanently delete the message and= any attachments.
. . .


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

=A0


...

<= /div>


. . .


--047d7b10cf27d9ebbe04ed2f6184-- From Adam.Montville@cisecurity.org Tue Dec 10 07:25:27 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F26891AE171 for ; Tue, 10 Dec 2013 07:25:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iAlgUUUNnIUI for ; Tue, 10 Dec 2013 07:25:23 -0800 (PST) Received: from mail1.bemta8.messagelabs.com (mail1.bemta8.messagelabs.com [216.82.243.194]) by ietfa.amsl.com (Postfix) with ESMTP id 770BE1ADF8B for ; Tue, 10 Dec 2013 07:25:23 -0800 (PST) Received: from [216.82.241.211:37465] by server-2.bemta-8.messagelabs.com id B4/BA-02718-E5237A25; Tue, 10 Dec 2013 15:25:18 +0000 X-Env-Sender: Adam.Montville@cisecurity.org X-Msg-Ref: server-16.tower-85.messagelabs.com!1386689117!26041673!1 X-Originating-IP: [69.195.43.86] X-StarScan-Received: X-StarScan-Version: 6.9.16; banners=cisecurity.org,-,- X-VirusChecked: Checked Received: (qmail 31287 invoked from network); 10 Dec 2013 15:25:17 -0000 Received: from mail.msisac.org (HELO mail.msisac.org) (69.195.43.86) by server-16.tower-85.messagelabs.com with AES128-SHA encrypted SMTP; 10 Dec 2013 15:25:17 -0000 Received: from CISEXCHANGE1.msisac.org.local ([fe80::4f0:b68d:e779:38c3]) by CISEXCHANGE2.msisac.org.local ([::1]) with mapi id 14.02.0347.000; Tue, 10 Dec 2013 10:23:03 -0500 From: Adam Montville To: "sacm@ietf.org" Thread-Topic: Preparing for 12/17 Interim Meeting Thread-Index: Ac71vAE+RYz9S8LeRMCBB03H/PqPqA== Date: Tue, 10 Dec 2013 15:23:11 +0000 Message-ID: <05BCCEB107AF88469B9F99783D47C1D6065F55F5@CISEXCHANGE1.msisac.org.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.252.39] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sacm] Preparing for 12/17 Interim Meeting X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 15:25:27 -0000 Hi, We are one week before the virtual interim scheduled for 12/17. We need to= do some preparations in order to make sure that we use our shared time in= an efficient manner.=20 1. We need at least one, better two note takers. Interim meetings must be = minuted, as all IETF WG meeting. Volunteering is appreciated.=20 2. The Use Case document will be the major point on the agenda. David and = David - do you plan to submit an update before the meeting? The sooner the= better, but not later than Friday 12/13 I suggest. Who of you will lead t= he discussion in the meeting? The goal is to discuss the open issues and c= lose as many of them as possible.=20 3. The 'Way Forward' plan included submission of the Requirements document= by 12/1. This did not happen. Nancy - do you still plan to do it? Will yo= u lead the discussion on this?=20 4. Do we need any time for the terminology document?=20 5. Are there other proposals for the agenda?=20 Thanks and Regards, Adam and Dan . . . From dromasca@avaya.com Tue Dec 10 07:53:09 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D9101ADFA4 for ; Tue, 10 Dec 2013 07:53:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gxQKzuVopayF for ; Tue, 10 Dec 2013 07:53:06 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 634031ADF96 for ; Tue, 10 Dec 2013 07:53:06 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq4MAKY3p1LGmAcV/2dsb2JhbABZgmYhOFOCf6EbA5UBGIEGFm0HgiUBAQEBAxIREVEGAQgNBAQBAQMCBgsBAg8DAgQfERQBBgEBBQUEEwgBCw6HTgMPAQyiIYRLikCIZw2BJIVDF4Epi0qBPiMPBygECAYGgk41gRMBA5YoAYhXhW6FOYMpgXE5 X-IronPort-AV: E=Sophos;i="4.93,865,1378872000"; d="scan'208";a="40402447" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by co300216-co-outbound.net.avaya.com with ESMTP; 10 Dec 2013 10:53:00 -0500 Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 10 Dec 2013 10:45:25 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC04.global.avaya.com ([135.64.58.14]) with mapi id 14.03.0146.000; Tue, 10 Dec 2013 16:52:58 +0100 From: "Romascanu, Dan (Dan)" To: "sacm@ietf.org" Thread-Topic: IETF 89 - Working Group/BOF/IRTF Scheduling Thread-Index: AQHO8GQP5CpJNaBycEKcxcw6GqReu5pNm3mg Date: Tue, 10 Dec 2013 15:52:57 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA129DFDE9@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [sacm] FW: IETF 89 - Working Group/BOF/IRTF Scheduling X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 15:53:09 -0000 DQpIaSwNCg0KU2NoZWR1bGluZyBmb3IgdGhlIElFVEYtODggbWVldGluZyBpbiBMb25kb24gaXMg bm93IG9wZW4uIA0KDQpPdXIgcGxhbiBpcyB0byByZXF1ZXN0IG9uZSAyIGhvdXJzIG1lZXRpbmcg c2xvdCwgYXMgd2UgaGFkIGF0IElFVEYtODguIEFueWJvZHkgYmVsaWV2ZXMgdGhhdCB3ZSBuZWVk IG1vcmUsIG9yIGxlc3MgdGltZT8gDQoNCkFsc28gcGxlYXNlIHNlbmQgdXMgeW91ciBsaXN0IG9m IGNyaXRpY2FsIGNvbmZsaWN0cywgYmV5b25kIHRoZSBvYnZpb3VzLiANCg0KVGhhbmtzIGFuZCBS ZWdhcmRzLA0KDQpBZGFtIGFuZCBEYW4NCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQpGcm9tOiBXR0NoYWlycyBbbWFpbHRvOndnY2hhaXJzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiBPZiBJRVRGIEFnZW5kYQ0KU2VudDogVHVlc2RheSwgRGVjZW1iZXIgMDMsIDIwMTMgMTA6 MTMgUE0NClRvOiBXb3JraW5nIEdyb3VwIENoYWlycw0KQ2M6IGlyc2dAaXJ0Zi5vcmcNClN1Ympl Y3Q6IElFVEYgODkgLSBXb3JraW5nIEdyb3VwL0JPRi9JUlRGIFNjaGVkdWxpbmcNCg0KLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCjg5dGggSUVURiDigJMgTG9uZG9uLCBFbmdsYW5kDQpNZWV0aW5nIERhdGVzOiBNYXJjaCAy IOKAkyA3LCAyMDE0DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KSUVURiBtZWV0aW5ncyBzdGFydCBNb25kYXkgbW9ybmlu ZyBhbmQgcnVuIHRocm91Z2ggRnJpZGF5IGFmdGVybm9vbiAoMTM6MzApLg0KDQpXZSBhcmUgYWNj ZXB0aW5nIHNjaGVkdWxpbmcgcmVxdWVzdHMgZm9yIGFsbCBXb3JraW5nIEdyb3VwcywgQk9Gcywg YW5kIFJlc2VhcmNoIEdyb3VwcyBzdGFydGluZyB0b2RheS4gIFRoZSBtaWxlc3RvbmVzIGFuZCBk ZWFkbGluZXMgZm9yIHNjaGVkdWxpbmctcmVsYXRlZCBhY3Rpdml0aWVzIGFyZSBhcyBmb2xsb3dz Og0KDQpOT1RFOiBjdXRvZmYgZGF0ZXMgYXJlIHN1YmplY3QgdG8gY2hhbmdlLg0KDQotIDIwMTMt MTItMDIgKE1vbmRheSk6IFdvcmtpbmcgR3JvdXAgYW5kIEJPRiBzY2hlZHVsaW5nIGJlZ2lucy4g VG8gcmVxdWVzdCBhIFdvcmtpbmcgR3JvdXAgc2Vzc2lvbiwgdXNlIHRoZSBJRVRGIE1lZXRpbmcg U2Vzc2lvbiBSZXF1ZXN0IFRvb2wuDQotIDIwMTQtMDEtMTcgKEZyaWRheSk6IEN1dC1vZmYgZGF0 ZSBmb3IgcmVxdWVzdHMgdG8gc2NoZWR1bGUgV29ya2luZyBHcm91cCBtZWV0aW5ncyBhdCBVVEMg MjM6NTkuIFRvIHJlcXVlc3QgYSBXb3JraW5nIEdyb3VwIHNlc3Npb24sIHVzZSB0aGUgSUVURiBN ZWV0aW5nIFNlc3Npb24gUmVxdWVzdCBUb29sLg0KLSAyMDE0LTAxLTE3IChGcmlkYXkpOiBDdXQt b2ZmIGRhdGUgZm9yIEJPRiBwcm9wb3NhbCByZXF1ZXN0cyB0byBBcmVhIERpcmVjdG9ycyBhdCBV VEMgMjM6NTkuIFRvIHJlcXVlc3QgYSBCT0YsIHBsZWFzZSBzZWUgaW5zdHJ1Y3Rpb25zIG9uIFJl cXVlc3RpbmcgYSBCT0YuDQotIDIwMTQtMDEtMjQgKEZyaWRheSk6IEN1dC1vZmYgZGF0ZSBmb3Ig QXJlYSBEaXJlY3RvcnMgdG8gYXBwcm92ZSBCT0ZzIGF0IFVUQyAyMzo1OS4NCi0gMjAxNC0wMS0z MSAoRnJpZGF5KTogUHJlbGltaW5hcnkgYWdlbmRhIHB1Ymxpc2hlZCBmb3IgY29tbWVudC4NCi0g MjAxNC0wMi0wMyAoTW9uZGF5KTogQ3V0LW9mZiBkYXRlIGZvciByZXF1ZXN0cyB0byByZXNjaGVk dWxlIFdvcmtpbmcgR3JvdXAgYW5kIEJPRiBtZWV0aW5ncyBVVEMgMjM6NTkuDQotIDIwMTQtMDIt MDcgKEZyaWRheSk6IEZpbmFsIGFnZW5kYSB0byBiZSBwdWJsaXNoZWQuDQotIDIwMTQtMDItMTcg KE1vbmRheSk6IERyYWZ0IFdvcmtpbmcgR3JvdXAgYWdlbmRhcyBkdWUgYnkgVVRDIDIzOjU5LCB1 cGxvYWQgdXNpbmcgSUVURiBNZWV0aW5nIE1hdGVyaWFscyBNYW5hZ2VtZW50IFRvb2wuDQotIDIw MTQtMDItMjQgKE1vbmRheSk6IFJldmlzZWQgV29ya2luZyBHcm91cCBhZ2VuZGFzIGR1ZSBieSBV VEMgMjM6NTksIHVwbG9hZCB1c2luZyBJRVRGIE1lZXRpbmcgTWF0ZXJpYWxzIE1hbmFnZW1lbnQg VG9vbC4NCi0gMjAxNC0wMy0yOCAoRnJpZGF5KTogUHJvY2VlZGluZ3Mgc3VibWlzc2lvbiBjdXRv ZmYgZGF0ZSBieSBVVEMgMjM6NTksIHVwbG9hZCB1c2luZyBJRVRGIE1lZXRpbmcgTWF0ZXJpYWxz IE1hbmFnZW1lbnQgVG9vbC4NCi0gMjAxNC0wNC0xOCAoRnJpZGF5KTogUHJvY2VlZGluZ3Mgc3Vi bWlzc2lvbiBjb3JyZWN0aW9ucyBjdXRvZmYgZGF0ZSBieSBVVEMgMjM6NTksIHVwbG9hZCB1c2lu ZyBJRVRGIE1lZXRpbmcgTWF0ZXJpYWxzIE1hbmFnZW1lbnQgVG9vbC4NCg0KU3VibWl0dGluZyBS ZXF1ZXN0cyBmb3IgV29ya2luZyBHcm91cCBhbmQgQk9GIFNlc3Npb25zDQoNClBsZWFzZSBzdWJt aXQgcmVxdWVzdHMgdG8gc2NoZWR1bGUgeW91ciBXb3JraW5nIEdyb3VwIHNlc3Npb25zIHVzaW5n IHRoZSAiSUVURiBNZWV0aW5nIFNlc3Npb24gUmVxdWVzdCBUb29sLCIgYSBXZWItYmFzZWQgdG9v bCBmb3Igc3VibWl0dGluZyBhbGwgb2YgdGhlIGluZm9ybWF0aW9uIHRoYXQgdGhlIFNlY3JldGFy aWF0IHJlcXVpcmVzIHRvIHNjaGVkdWxlIHlvdXIgc2Vzc2lvbnMuDQoNClRoZSBVUkwgZm9yIHRo ZSB0b29sIGlzOg0KDQpodHRwczovL3B1Yi5pZXRmLm9yZy9zcmVxLw0KDQpQbGVhc2Ugc2VuZCBy ZXF1ZXN0cyB0byBzY2hlZHVsZSB5b3VyIEJPRiBzZXNzaW9ucyB0byBhZ2VuZGFAaWV0Zi5vcmcu ICBQbGVhc2UgaW5jbHVkZSB0aGUgYWNyb255bSBvZiB5b3VyIEJPRiBpbiB0aGUgc3ViamVjdCBs aW5lIG9mIHRoZSBtZXNzYWdlLCBhbmQgaW5jbHVkZSBhbGwgb2YgdGhlIGluZm9ybWF0aW9uIHNw ZWNpZmllZCBpbiBpdGVtICg0KSBvZiAiUmVxdWVzdGluZyBNZWV0aW5nIFNlc3Npb25zIGF0IElF VEYgTWVldGluZ3MiIGluIHRoZSBib2R5LiAgKFRoaXMgZG9jdW1lbnQgaXMgaW5jbHVkZWQgYmVs b3cuKQ0KDQpTdWJtaXR0aW5nIFNlc3Npb24gQWdlbmRhcw0KDQpGb3IgdGhlIGNvbnZlbmllbmNl IG9mIG1lZXRpbmcgYXR0ZW5kZWVzLCB3ZSBhc2sgdGhhdCB5b3Ugc3VibWl0IHRoZSBhZ2VuZGFz IGZvciB5b3VyIFdvcmtpbmcgR3JvdXAgc2Vzc2lvbnMgYXMgZWFybHkgYXMgcG9zc2libGUuICBE cmFmdCBXb3JraW5nIEdyb3VwIGFnZW5kYXMgYXJlIGR1ZSBNb25kYXksIEZlYnJ1YXJ5IDE3dGgs IDIwMTQgYXQgVVRDIDIzOjU5LiAgUmV2aXNlZCBXb3JraW5nIEdyb3VwIGFnZW5kYXMgYXJlIGR1 ZSBubyBsYXRlciB0aGFuIE1vbmRheSwgRmVicnVhcnkgMjR0aCwgMjAxNCBhdCBVVEMgMjM6NTku ICBUaGUgcHJvcG9zZWQgYWdlbmRhIGZvciBhIEJPRiBzZXNzaW9uIHNob3VsZCBiZSBzdWJtaXR0 ZWQgYWxvbmcgd2l0aCB5b3VyIHJlcXVlc3QgZm9yIGEgc2Vzc2lvbi4gIFBsZWFzZSBiZSBzdXJl IHRvIGNvcHkgeW91ciBBcmVhIERpcmVjdG9yIG9uIHRoYXQgbWVzc2FnZS4NCg0KUGxlYXNlIHN1 Ym1pdCB0aGUgYWdlbmRhcyBmb3IgeW91ciBXb3JraW5nIEdyb3VwIHNlc3Npb25zIHVzaW5nIHRo ZSAiSUVURiBNZWV0aW5nIE1hdGVyaWFscyBNYW5hZ2VtZW50IFRvb2wsIiBhIFdlYi1iYXNlZCB0 b29sIGZvciBtYWtpbmcgeW91ciBtZWV0aW5nIGFnZW5kYSwgbWludXRlcywgYW5kIHByZXNlbnRh dGlvbiBzbGlkZXMgYXZhaWxhYmxlIHRvIHRoZSBjb21tdW5pdHkgYmVmb3JlLCBkdXJpbmcsIGFu ZCBhZnRlciBhbiBJRVRGIG1lZXRpbmcuICBJZiB5b3UgYXJlIGEgQk9GIGNoYWlyLCB0aGVuIHlv dSBtYXkgdXNlIHRoZSB0b29sIHRvIHN1Ym1pdCBhIHJldmlzZWQgYWdlbmRhIGFzIHdlbGwgYXMg b3RoZXIgbWF0ZXJpYWxzIGZvciB5b3VyIEJPRiBvbmNlIHRoZSBCT0YgaGFzIGJlZW4gYXBwcm92 ZWQuDQoNClRoZSBVUkwgZm9yIHRoZSB0b29sIGlzOg0KDQpodHRwczovL3B1Yi5pZXRmLm9yZy9w cm9jZWVkaW5ncy8NCg0KQWRkaXRpb25hbCBpbmZvcm1hdGlvbiBhYm91dCB0aGlzIHRvb2wgaXMg YXZhaWxhYmxlIGF0Og0KDQpodHRwOi8vd3d3LmlldGYub3JnL2luc3RydWN0aW9ucy9tZWV0aW5n X21hdGVyaWFsc190b29sLmh0bWwNCg0KQWdlbmRhcyBzdWJtaXR0ZWQgdmlhIHRoZSB0b29sIHdp bGwgYmUgYXZhaWxhYmxlIHRvIHRoZSBwdWJsaWMgb24gdGhlICJJRVRGIE1lZXRpbmcgTWF0ZXJp YWxzIiB3ZWJwYWdlIGFzIHNvb24gYXMgdGhleSBhcmUgc3VibWl0dGVkLg0KDQpUaGUgVVJMIGZv ciB0aGUgIklFVEYgODkgTWVldGluZyBNYXRlcmlhbHMiIFdlYiBwYWdlIGlzOg0KDQpodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL21lZXRpbmcvODkvbWF0ZXJpYWxzLmh0bWwNCg0KSWYgeW91 IGFyZSBhIFdvcmtpbmcgR3JvdXAgY2hhaXIsIHRoZW4geW91IGFscmVhZHkgaGF2ZSBhY2NvdW50 cyBvbiB0aGUgIklFVEYgTWVldGluZyBTZXNzaW9uIFJlcXVlc3QgVG9vbCIgYW5kIHRoZSAiSUVU RiBNZWV0aW5nIE1hdGVyaWFscyBNYW5hZ2VtZW50IFRvb2wuIiAgVGhlIHNhbWUgVXNlciBJRCBh bmQgcGFzc3dvcmQgd2lsbCB3b3JrIGZvciBib3RoIHRvb2xzLiAgSWYgeW91IGFyZSBhIEJPRiBj aGFpciB3aG8gaXMgbm90IGFsc28gYSBXb3JraW5nIEdyb3VwIGNoYWlyLCB0aGVuIHlvdSB3aWxs IGJlIGdpdmVuIGFuIGFjY291bnQgb24gdGhlICJJRVRGIE1lZXRpbmcgTWF0ZXJpYWxzIE1hbmFn ZW1lbnQgVG9vbCIgd2hlbiB5b3VyIEJPRiBoYXMgYmVlbiBhcHByb3ZlZC4gIElmIHlvdSByZXF1 aXJlIGFzc2lzdGFuY2UgaW4gdXNpbmcgZWl0aGVyIHRvb2wsIG9yIHdpc2ggdG8gcmVwb3J0IGEg YnVnLCB0aGVuIHBsZWFzZSBzZW5kIGEgbWVzc2FnZSB0bzoNCmlldGYtYWN0aW9uQGlldGYub3Jn Lg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09DQpGb3IgeW91ciBjb252ZW5pZW5jZSwgY29tcHJlaGVuc2l2ZSBpbmZvcm1hdGlv biBvbiByZXF1ZXN0aW5nIG1lZXRpbmcgc2Vzc2lvbnMgZm9yIElFVEYgODkgaXMgYmVsb3c6DQoN CjEuIFJlcXVlc3RzIHRvIHNjaGVkdWxlIFdvcmtpbmcgR3JvdXAgc2Vzc2lvbnMgc2hvdWxkIGJl IHN1Ym1pdHRlZCB1c2luZyB0aGUgIklFVEYgTWVldGluZyBTZXNzaW9uIFJlcXVlc3QgVG9vbCwi IGEgV2ViLWJhc2VkIHRvb2wgZm9yIHN1Ym1pdHRpbmcgYWxsIG9mIHRoZSBpbmZvcm1hdGlvbiBy ZXF1aXJlZCBieSB0aGUgU2VjcmV0YXJpYXQgdG8gc2NoZWR1bGUgeW91ciBzZXNzaW9ucy4gIFRo ZSBVUkwgZm9yIHRoZSB0b29sIGlzOg0KDQpodHRwczovL3B1Yi5pZXRmLm9yZy9zcmVxLw0KDQpJ bnN0cnVjdGlvbnMgZm9yIHVzaW5nIHRoZSB0b29sIGFyZSBhdmFpbGFibGUgYXQ6DQoNCmh0dHA6 Ly93d3cuaWV0Zi5vcmcvaW5zdHJ1Y3Rpb25zL3Nlc3Npb25fcmVxdWVzdF90b29sX2luc3RydWN0 aW9uLmh0bWwNCg0KSWYgeW91IHJlcXVpcmUgYW4gYWNjb3VudCBvbiB0aGlzIHRvb2wsIG9yIGFz c2lzdGFuY2UgaW4gdXNpbmcgaXQsIHRoZW4gcGxlYXNlIHNlbmQgYSBtZXNzYWdlIHRvIGlldGYt YWN0aW9uQGlldGYub3JnLiAgSWYgeW91IGFyZSB1bmFibGUgdG8gdXNlIHRoZSB0b29sLCB0aGVu IHlvdSBtYXkgc2VuZCB5b3VyIHJlcXVlc3QgdmlhIGUtbWFpbCB0byBhZ2VuZGFAaWV0Zi5vcmcs IHdpdGggYSBjb3B5IHRvIHRoZSBhcHByb3ByaWF0ZSBBcmVhIERpcmVjdG9yKHMpLg0KDQpSZXF1 ZXN0cyB0byBzY2hlZHVsZSBCT0Ygc2Vzc2lvbnMgbXVzdCBiZSBzZW50IHRvIGFnZW5kYUBpZXRm Lm9yZyB3aXRoIGEgY29weSB0byB0aGUgYXBwcm9wcmlhdGUgQXJlYSBEaXJlY3RvcihzKS4NCg0K V2hlbiBzdWJtaXR0aW5nIGEgV29ya2luZyBHcm91cCBvciBCT0Ygc2Vzc2lvbiByZXF1ZXN0IGJ5 IGUtbWFpbCwgcGxlYXNlIGluY2x1ZGUgdGhlIFdvcmtpbmcgR3JvdXAgb3IgQk9GIGFjcm9ueW0g aW4gdGhlIFN1YmplY3QgbGluZS4NCg0KMi4gQk9GcyB3aWxsIE5PVCBiZSBzY2hlZHVsZWQgdW5s ZXNzIHRoZSBBcmVhIERpcmVjdG9yIGFwcHJvdmVzIHRoZSBCT0YuIFRoZSBwcm9wb25lbnRzIGJl aGluZCBhIEJPRiBuZWVkIHRvIGNvbnRhY3QgYSByZWxldmFudCBBcmVhIERpcmVjdG9yLCBwcmVm ZXJhYmx5IHdlbGwgaW4gYWR2YW5jZSBvZiB0aGUgQk9GIGFwcHJvdmFsIGRlYWRsaW5lIGRhdGUu IFRoZSBBRCBuZWVkcyB0byBoYXZlIHRoZSBmdWxsIG5hbWUgb2YgdGhlIEJPRiwgaXRzIGFjcm9u eW0sIHN1Z2dlc3RlZCBuYW1lcyBvZiBjaGFpcnMsIGFuIGFnZW5kYSwgZnVsbCBkZXNjcmlwdGlv biBvZiB0aGUgQk9GIGFuZCB0aGUgaW5mb3JtYXRpb24gY292ZXJlZCBpbiBpdGVtIDQuIFBsZWFz ZSByZWFkIFJGQyA1NDM0IGZvciBpbnN0cnVjdGlvbnMgb24gaG93IHRvIGRyaXZlIGEgc3VjY2Vz c2Z1bCBCT0YgZWZmb3J0LiBUaGUgYXBwcm92YWwgZGVwZW5kcyBvbiwgZm9yIGluc3RhbmNlLCBJ bnRlcm5ldC1EcmFmdHMgYW5kIGxpc3QgZGlzY3Vzc2lvbiBvbiB0aGUgc3VnZ2VzdGVkIHRvcGlj LiBCT0YgYWdlbmRhIHJlcXVlc3RzLCBpZiBhcHByb3ZlZCwgd2lsbCBiZSBzdWJtaXR0ZWQgdG8g dGhlIElFVEYgU2VjcmV0YXJpYXQgYnkgdGhlIEFEcy4NCg0KMy4gQSBXb3JraW5nIEdyb3VwIG1h eSByZXF1ZXN0IGVpdGhlciBvbmUgb3IgdHdvIHNlc3Npb25zLiAgSWYgeW91ciBXb3JraW5nIEdy b3VwIHJlcXVpcmVzIG1vcmUgdGhhbiB0d28gc2Vzc2lvbnMsIHRoZW4geW91ciByZXF1ZXN0IG11 c3QgYmUgYXBwcm92ZWQgYnkgYW4gQXJlYSBEaXJlY3Rvci4gIEFkZGl0aW9uYWwgc2Vzc2lvbnMg d2lsbCBiZSBhc3NpZ25lZCwgYmFzZWQgb24gYXZhaWxhYmlsaXR5LCBhZnRlciBNb25kYXksIEZl YnJ1YXJ5IDNyZCwgMjAxNCwgdGhlIGN1dC1vZmYgZGF0ZSBmb3IgcmVxdWVzdHMgdG8gcmVzY2hl ZHVsZSBhIHNlc3Npb24uDQoNCjQuIFlvdSBNVVNUIHByb3ZpZGUgdGhlIGZvbGxvd2luZyBpbmZv cm1hdGlvbiBiZWZvcmUgYSBXb3JraW5nIEdyb3VwIG9yIEJPRiBzZXNzaW9uIHdpbGwgYmUgc2No ZWR1bGVkOg0KDQogICAgYS4gV29ya2luZyBHcm91cCBvciBCT0YgZnVsbCBuYW1lIHdpdGggYWNy b255bSBpbiBicmFja2V0czogDQoNCiAgICBiLiBBUkVBIHVuZGVyIHdoaWNoIFdvcmtpbmcgR3Jv dXAgb3IgQk9GIGFwcGVhcnM6DQoNCiAgICBjLiBDT05GTElDVFMgeW91IHdpc2ggdG8gYXZvaWQs IHBsZWFzZSBiZSBhcyBzcGVjaWZpYyBhcyBwb3NzaWJsZToNCg0KICAgIGQuIEV4cGVjdGVkIEF0 dGVuZGFuY2U6DQoNCiAgICBlLiBTcGVjaWFsIHJlcXVlc3RzOg0KDQogICAgZi4gTnVtYmVyIG9m IHNlc3Npb25zOg0KDQogICAgZy4gTGVuZ3RoIG9mIHNlc3Npb246IA0KICAgICAgIC0gMSBob3Vy IA0KICAgICAgIC0gMSAxLzIgaG91cnMNCiAgICAgICAtIDIgaG91cnMgDQogICAgICAgLSAyIDEv MiBob3Vycw0KDQpGb3IgbW9yZSBpbmZvcm1hdGlvbiBvbiBzY2hlZHVsaW5nIFdvcmtpbmcgR3Jv dXAgYW5kIEJPRiBzZXNzaW9ucywgcGxlYXNlIHJlZmVyIHRvIFJGQyAyNDE4IChCQ1AgMjUpLCAi SUVURiBXb3JraW5nIEdyb3VwIEd1aWRlbGluZXMgYW5kIFByb2NlZHVyZXMiIChodHRwOi8vd3d3 LmlldGYub3JnL3JmYy9yZmMyNDE4LnR4dCkuDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCkZvciB5b3VyIGNvbnZlbmllbmNl IHBsZWFzZSBmaW5kIGhlcmUgYSBsaXN0IG9mIHRoZSBJRVRGIEFyZWEgRGlyZWN0b3JzIHdpdGgg dGhlaXIgZS1tYWlsIGFkZHJlc3NlczoNCg0KSUVURiBDaGFpcg0KSmFyaSBBcmtrbyA8amFyaS5h cmtrb0BwaXVoYS5uZXQ+DQoNCkFwcGxpY2F0aW9ucyBBcmVhIChhcHApDQpCYXJyeSBMZWliYSA8 YmFycnlsZWliYUBjb21wdXRlci5vcmc+DQpQZXRlIFJlc25pY2sgPHByZXNuaWNrQHF1YWxjb21t LmNvbT4NCg0KSW50ZXJuZXQgQXJlYSAoaW50KQ0KQnJpYW4gSGFiZXJtYW4gPGJyaWFuQGlubm92 YXRpb25zbGFiLm5ldD4gVGVkIExlbW9uIDx0ZWQubGVtb25Abm9taW51bS5jb20+DQoNCk9wZXJh dGlvbnMgJiBNYW5hZ2VtZW50IEFyZWEgKG9wcykNCkJlbm9pdCBDbGFpc2UgPGJjbGFpc2VAY2lz Y28uY29tPg0KSm9lbCBKYWVnZ2xpIDxqb2VsamFAYm9ndXMuY29tPg0KDQpSZWFsLXRpbWUgQXBw bGljYXRpb25zIGFuZCBJbmZyYXN0cnVjdHVyZSBBcmVhIChyYWkpIEdvbnphbG8gQ2FtYXJpbGxv IDxnb256YWxvLmNhbWFyaWxsb0Blcmljc3Nvbi5jb20+IFJpY2hhcmQgQmFybmVzIDxybGJAaXB2 LnN4PiAgDQoNClJvdXRpbmcgQXJlYSAocnRnKQ0KU3Rld2FydCBCcnlhbnQgPHN0YnJ5YW50QGNp c2NvLmNvbT4NCkFkcmlhbiBGYXJyZWwgPGFkcmlhbkBvbGRkb2cuY28udWs+ICANCg0KU2VjdXJp dHkgQXJlYSAoc2VjKQ0KU3RlcGhlbiBGYXJyZWxsIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmll PiBTZWFuIFR1cm5lciA8dHVybmVyc0BpZWNhLmNvbT4gIA0KDQpUcmFuc3BvcnQgQXJlYSAodHN2 KQ0KTWFydGluIFN0aWVtZXJsaW5nIDxtYXJ0aW4uc3RpZW1lcmxpbmdAbmVjbGFiLmV1PiBTcGVu Y2VyIERhd2tpbnMgIDxzcGVuY2VyZGF3a2lucy5pZXRmQGdtYWlsLmNvbT4gID09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQo4OHRoIElF VEYgTWVldGluZyBBdHRlbmRhbmNlIE51bWJlcnMNCg0KNmxvIC0gNTINCjZtYW4gLSAxNDMNCjZ0 aXNjaCAtIDQ1DQphYmZhYiAtIDIwDQphbHRvICAtIDM1DQphcHBzYXdnL2FwcGFyZWEgLSAxMzgN CmFxbSAtIDEwOA0KYXFtICgybmQgc2Vzc2lvbikgLSA0NQ0KYXZ0Y29yZSAtIDUxDQphdnRleHQg 4oCTIDU5DQpiZmQgLSAxNw0KYm13ZyAtIDE5DQpjY2FtcCAtIDQ5DQpjY2FtcCAoMm5kIHNlc3Np b24pIC0gNDQNCmNkbmkgLSAzOQ0KY2x1ZSAtIDQxDQpjbHVlICgybmQgc2Vzc2lvbikgLSAzMg0K Y29yZSAtIDYyDQpjb3JlICgybmQgc2Vzc2lvbikgLSA1MA0KZGhjIC0gNTkNCmRpY2UgLSA2NQ0K ZGltZSAtIDIzDQpkaXNwYXRjaCAtIDU1DQpkbW0gLSAzNw0KZG5zb3AgLSAxMjUNCmRuc3NkIC0g MTA4DQplY3JpdCAtIDMxDQplbWFuIC0gMTkNCmZvcmNlcyAtIDQwDQpnZW9uZXQgKEJvRikgLSA5 OQ0KZ2VvcHJpdiAtIDQxDQpob21lbmV0IC0gMTU2DQpodHRwYXV0aCAtIDQzDQpodHRwYmlzIC0g ODkNCmh0dHBiaXMgKDJuZCBzZXNzaW9uKSAtIDEyNw0KaTJycyAtIDIyMw0KaWNjcmcgKFJHKSAt IDY4DQppY25yZyAoUkcpIC0gNDMNCmlkciAtIDkwDQppZ292dXBkYXRlIEJvRiAtIDIyMA0KaW5z aXBpZCAtIDMyDQppbnRhcmVhIChBRykgLSA5OA0KaXBmaXggLSAyMw0KaXBwbSAtIDQ4DQppcHNl Y21lIC0gMjcNCklSVEYgT3BlbiBNZWV0aW5nIC0gMTAwDQppc2lzIC0gNTgNCmpvc2UgLSA0Mg0K anNvbiAtIDQ5DQprYXJwIC0gMjINCmtpdHRlbiAtIDIzDQpsMnZwbiAtIDcxDQpsM3ZwbiAtIDY1 DQpsaXNwIC0gNTYNCmxtYXAgLSA1Mg0KbHdpZyAtIDM1DQptYW5ldCAtIDM1DQptYm9uZWQgLSAy NQ0KbWlmIC0gNDENCm1tdXNpYyAtIDY5DQptbXVzaWMgKDJuZCBzZXNzaW9uKSAtIDUzDQptcGxz IC0gNzENCm1wbHMgKDJuZCBzZXNzaW9uKSAtIDcyDQptcHRjcCAtIDQ1DQptcHRjcCAoMm5kIHNl c3Npb24pIC0gNzANCm5jcmcgKFJHKSAtIDMzDQpuZXRjb25mIC0gNjINCm5ldGV4dCAtIDI3DQpu ZXRtb2QgLSA2OQ0KbmZzdjQgLSAxNg0Kbm1yZyAoUkcpIC0gMzUNCm5tcmcgKFJHKSAoMm5kIHNl c3Npb24pIC0gMTcNCm50cCAoY29tYmluZWQgd2l0aCB0aWN0b2MpIC0gMzINCm52bzMgLSAxOTMN Cm53Y3JnIChQUkcpIC0gMjUNCm9hdXRoIC0gMzgNCm9wc2F3Zy9vcHNhcmVhIC0gNjgNCm9wc2Vj IC0gNDgNCm9zcGYgLSAzOA0KcGF3cyAtIDE3DQpwY2UgLSA3Mg0KcGNwIC0gMzANCnBlcnBhc3Mg KEJvRikgLSAzMTMNCnBpbSAtIDI0DQpwcHNwIC0gMTINCnByZWNpcyAtIDMyDQpwd2UzIC0gNDAN CnJhZGV4dCAtIDIwDQpyZmNmb3JtIChCb0YpIC0gNTINCnJtY2F0IC0gNjANCnJ0Y3dlYiAtIDE3 NA0KcnRjd2ViICgybmQgc2Vzc2lvbikgLSAxODgNCnJ0Z2FyZWEgKEFHKSAtIDEwMQ0KcnRnd2cg LSAxMTgNCnNhYWcgKEFHKSAtIDE0OA0Kc2FjbSAtIDQwDQpzY2ltIC0gMzINCnNkbnJnIChSRykg LSAyNTkNCnNpZHIgLSA2MQ0Kc2lwcmVjIC0gMzENCnNvZnR3aXJlIC0gNTINCnNwcmluZyAtIDE1 OA0Kc3RpciAtIDgyDQpzdGlyICgybmQgc2Vzc2lvbikgLSA3OQ0Kc3Rvcm0gLSAyMQ0KdGNwbSAt IDM2DQp0aWN0b2MgKGNvbWJpbmVkIHdpdGggbnRwKSAtIDMyDQp0bHMgLSAxMTENCnRyaWxsIC0g MzMNCnRzdmFyZWEgKEFHKSAtIDE1Mw0KdHN2d2cgLSA2Mw0KdHN2d2cgKDJuZCBzZXNzaW9uKSAt IDQ3DQp2Nm9wcyAtIDEzNQ0KdjZvcHMgKDJuZCBzZXNzaW9uKSAtIDkyDQp3ZWlyZHMgLSA1NQ0K d3Brb3BzIC0gMzQNCnhtcHAgLSAzMQ0KeHJibG9jayAtIDI0DQo= From dromasca@avaya.com Tue Dec 10 07:56:39 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AFFE1ADF7C for ; Tue, 10 Dec 2013 07:56:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LTkYOsAOtn1c for ; Tue, 10 Dec 2013 07:56:36 -0800 (PST) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 399F91AE052 for ; Tue, 10 Dec 2013 07:56:36 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoIMAOQ4p1KHCzI1/2dsb2JhbABZgmYhOFOCf6EblQQYgQYWbQeCJQEBAQEDEhERUQYBCA0EBAEBAwIGCwECDwMCBB8RFAEICgQTCAELDodOAw8BDKIahEuKQIhqDYEkhUMXgSmLSoE+IxYoBAgGBoJONYETAQOWKAGIV4VuhTmDKYFxOQ X-IronPort-AV: E=Sophos;i="4.93,865,1378872000"; d="scan'208";a="40675502" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 10 Dec 2013 10:56:27 -0500 Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES128-SHA; 10 Dec 2013 10:45:38 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC02.global.avaya.com ([135.64.58.12]) with mapi id 14.03.0146.000; Tue, 10 Dec 2013 16:56:16 +0100 From: "Romascanu, Dan (Dan)" To: "sacm@ietf.org" Thread-Topic: IETF 89 - Working Group/BOF/IRTF Scheduling Thread-Index: AQHO8GQP5CpJNaBycEKcxcw6GqReu5pNm3mggAAEV4A= Date: Tue, 10 Dec 2013 15:56:15 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA129DFE39@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [sacm] IETF 89 - Working Group/BOF/IRTF Scheduling X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 15:56:39 -0000 SXQgd2lsbCBiZSBJRVRGLTg5LCBvZiBjb3Vyc2UuIA0KDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPiBGcm9tOiBSb21hc2NhbnUsIERhbiAoRGFuKQ0KPiBTZW50OiBUdWVzZGF5 LCBEZWNlbWJlciAxMCwgMjAxMyA1OjUzIFBNDQo+IFRvOiBzYWNtQGlldGYub3JnDQo+IFN1Ympl Y3Q6IEZXOiBJRVRGIDg5IC0gV29ya2luZyBHcm91cC9CT0YvSVJURiBTY2hlZHVsaW5nDQo+IA0K PiANCj4gSGksDQo+IA0KPiBTY2hlZHVsaW5nIGZvciB0aGUgSUVURi04OCBtZWV0aW5nIGluIExv bmRvbiBpcyBub3cgb3Blbi4NCj4gDQo+IE91ciBwbGFuIGlzIHRvIHJlcXVlc3Qgb25lIDIgaG91 cnMgbWVldGluZyBzbG90LCBhcyB3ZSBoYWQgYXQgSUVURi04OC4NCj4gQW55Ym9keSBiZWxpZXZl cyB0aGF0IHdlIG5lZWQgbW9yZSwgb3IgbGVzcyB0aW1lPw0KPiANCj4gQWxzbyBwbGVhc2Ugc2Vu ZCB1cyB5b3VyIGxpc3Qgb2YgY3JpdGljYWwgY29uZmxpY3RzLCBiZXlvbmQgdGhlIG9idmlvdXMu DQo+IA0KPiBUaGFua3MgYW5kIFJlZ2FyZHMsDQo+IA0KPiBBZGFtIGFuZCBEYW4NCj4gDQo+IA0K PiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogV0dDaGFpcnMgW21haWx0 bzp3Z2NoYWlycy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSUVURg0KPiBBZ2VuZGEN Cj4gU2VudDogVHVlc2RheSwgRGVjZW1iZXIgMDMsIDIwMTMgMTA6MTMgUE0NCj4gVG86IFdvcmtp bmcgR3JvdXAgQ2hhaXJzDQo+IENjOiBpcnNnQGlydGYub3JnDQo+IFN1YmplY3Q6IElFVEYgODkg LSBXb3JraW5nIEdyb3VwL0JPRi9JUlRGIFNjaGVkdWxpbmcNCj4gDQo+IC0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IDg5 dGggSUVURiDigJMgTG9uZG9uLCBFbmdsYW5kDQo+IE1lZXRpbmcgRGF0ZXM6IE1hcmNoIDIg4oCT IDcsIDIwMTQNCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gSUVURiBtZWV0aW5ncyBzdGFydCBNb25kYXkgbW9ybmlu ZyBhbmQgcnVuIHRocm91Z2ggRnJpZGF5IGFmdGVybm9vbg0KPiAoMTM6MzApLg0KPiANCj4gV2Ug YXJlIGFjY2VwdGluZyBzY2hlZHVsaW5nIHJlcXVlc3RzIGZvciBhbGwgV29ya2luZyBHcm91cHMs IEJPRnMsIGFuZA0KPiBSZXNlYXJjaCBHcm91cHMgc3RhcnRpbmcgdG9kYXkuICBUaGUgbWlsZXN0 b25lcyBhbmQgZGVhZGxpbmVzIGZvcg0KPiBzY2hlZHVsaW5nLXJlbGF0ZWQgYWN0aXZpdGllcyBh cmUgYXMgZm9sbG93czoNCj4gDQo+IE5PVEU6IGN1dG9mZiBkYXRlcyBhcmUgc3ViamVjdCB0byBj aGFuZ2UuDQo+IA0KPiAtIDIwMTMtMTItMDIgKE1vbmRheSk6IFdvcmtpbmcgR3JvdXAgYW5kIEJP RiBzY2hlZHVsaW5nIGJlZ2lucy4gVG8NCj4gcmVxdWVzdCBhIFdvcmtpbmcgR3JvdXAgc2Vzc2lv biwgdXNlIHRoZSBJRVRGIE1lZXRpbmcgU2Vzc2lvbiBSZXF1ZXN0DQo+IFRvb2wuDQo+IC0gMjAx NC0wMS0xNyAoRnJpZGF5KTogQ3V0LW9mZiBkYXRlIGZvciByZXF1ZXN0cyB0byBzY2hlZHVsZSBX b3JraW5nDQo+IEdyb3VwIG1lZXRpbmdzIGF0IFVUQyAyMzo1OS4gVG8gcmVxdWVzdCBhIFdvcmtp bmcgR3JvdXAgc2Vzc2lvbiwgdXNlIHRoZQ0KPiBJRVRGIE1lZXRpbmcgU2Vzc2lvbiBSZXF1ZXN0 IFRvb2wuDQo+IC0gMjAxNC0wMS0xNyAoRnJpZGF5KTogQ3V0LW9mZiBkYXRlIGZvciBCT0YgcHJv cG9zYWwgcmVxdWVzdHMgdG8gQXJlYQ0KPiBEaXJlY3RvcnMgYXQgVVRDIDIzOjU5LiBUbyByZXF1 ZXN0IGEgQk9GLCBwbGVhc2Ugc2VlIGluc3RydWN0aW9ucyBvbg0KPiBSZXF1ZXN0aW5nIGEgQk9G Lg0KPiAtIDIwMTQtMDEtMjQgKEZyaWRheSk6IEN1dC1vZmYgZGF0ZSBmb3IgQXJlYSBEaXJlY3Rv cnMgdG8gYXBwcm92ZSBCT0ZzDQo+IGF0IFVUQyAyMzo1OS4NCj4gLSAyMDE0LTAxLTMxIChGcmlk YXkpOiBQcmVsaW1pbmFyeSBhZ2VuZGEgcHVibGlzaGVkIGZvciBjb21tZW50Lg0KPiAtIDIwMTQt MDItMDMgKE1vbmRheSk6IEN1dC1vZmYgZGF0ZSBmb3IgcmVxdWVzdHMgdG8gcmVzY2hlZHVsZSBX b3JraW5nDQo+IEdyb3VwIGFuZCBCT0YgbWVldGluZ3MgVVRDIDIzOjU5Lg0KPiAtIDIwMTQtMDIt MDcgKEZyaWRheSk6IEZpbmFsIGFnZW5kYSB0byBiZSBwdWJsaXNoZWQuDQo+IC0gMjAxNC0wMi0x NyAoTW9uZGF5KTogRHJhZnQgV29ya2luZyBHcm91cCBhZ2VuZGFzIGR1ZSBieSBVVEMgMjM6NTks DQo+IHVwbG9hZCB1c2luZyBJRVRGIE1lZXRpbmcgTWF0ZXJpYWxzIE1hbmFnZW1lbnQgVG9vbC4N Cj4gLSAyMDE0LTAyLTI0IChNb25kYXkpOiBSZXZpc2VkIFdvcmtpbmcgR3JvdXAgYWdlbmRhcyBk dWUgYnkgVVRDIDIzOjU5LA0KPiB1cGxvYWQgdXNpbmcgSUVURiBNZWV0aW5nIE1hdGVyaWFscyBN YW5hZ2VtZW50IFRvb2wuDQo+IC0gMjAxNC0wMy0yOCAoRnJpZGF5KTogUHJvY2VlZGluZ3Mgc3Vi bWlzc2lvbiBjdXRvZmYgZGF0ZSBieSBVVEMgMjM6NTksDQo+IHVwbG9hZCB1c2luZyBJRVRGIE1l ZXRpbmcgTWF0ZXJpYWxzIE1hbmFnZW1lbnQgVG9vbC4NCj4gLSAyMDE0LTA0LTE4IChGcmlkYXkp OiBQcm9jZWVkaW5ncyBzdWJtaXNzaW9uIGNvcnJlY3Rpb25zIGN1dG9mZiBkYXRlIGJ5DQo+IFVU QyAyMzo1OSwgdXBsb2FkIHVzaW5nIElFVEYgTWVldGluZyBNYXRlcmlhbHMgTWFuYWdlbWVudCBU b29sLg0KPiANCj4gU3VibWl0dGluZyBSZXF1ZXN0cyBmb3IgV29ya2luZyBHcm91cCBhbmQgQk9G IFNlc3Npb25zDQo+IA0KPiBQbGVhc2Ugc3VibWl0IHJlcXVlc3RzIHRvIHNjaGVkdWxlIHlvdXIg V29ya2luZyBHcm91cCBzZXNzaW9ucyB1c2luZyB0aGUNCj4gIklFVEYgTWVldGluZyBTZXNzaW9u IFJlcXVlc3QgVG9vbCwiIGEgV2ViLWJhc2VkIHRvb2wgZm9yIHN1Ym1pdHRpbmcgYWxsDQo+IG9m IHRoZSBpbmZvcm1hdGlvbiB0aGF0IHRoZSBTZWNyZXRhcmlhdCByZXF1aXJlcyB0byBzY2hlZHVs ZSB5b3VyDQo+IHNlc3Npb25zLg0KPiANCj4gVGhlIFVSTCBmb3IgdGhlIHRvb2wgaXM6DQo+IA0K PiBodHRwczovL3B1Yi5pZXRmLm9yZy9zcmVxLw0KPiANCj4gUGxlYXNlIHNlbmQgcmVxdWVzdHMg dG8gc2NoZWR1bGUgeW91ciBCT0Ygc2Vzc2lvbnMgdG8gYWdlbmRhQGlldGYub3JnLg0KPiBQbGVh c2UgaW5jbHVkZSB0aGUgYWNyb255bSBvZiB5b3VyIEJPRiBpbiB0aGUgc3ViamVjdCBsaW5lIG9m IHRoZQ0KPiBtZXNzYWdlLCBhbmQgaW5jbHVkZSBhbGwgb2YgdGhlIGluZm9ybWF0aW9uIHNwZWNp ZmllZCBpbiBpdGVtICg0KSBvZg0KPiAiUmVxdWVzdGluZyBNZWV0aW5nIFNlc3Npb25zIGF0IElF VEYgTWVldGluZ3MiIGluIHRoZSBib2R5LiAgKFRoaXMNCj4gZG9jdW1lbnQgaXMgaW5jbHVkZWQg YmVsb3cuKQ0KPiANCj4gU3VibWl0dGluZyBTZXNzaW9uIEFnZW5kYXMNCj4gDQo+IEZvciB0aGUg Y29udmVuaWVuY2Ugb2YgbWVldGluZyBhdHRlbmRlZXMsIHdlIGFzayB0aGF0IHlvdSBzdWJtaXQg dGhlDQo+IGFnZW5kYXMgZm9yIHlvdXIgV29ya2luZyBHcm91cCBzZXNzaW9ucyBhcyBlYXJseSBh cyBwb3NzaWJsZS4gIERyYWZ0DQo+IFdvcmtpbmcgR3JvdXAgYWdlbmRhcyBhcmUgZHVlIE1vbmRh eSwgRmVicnVhcnkgMTd0aCwgMjAxNCBhdCBVVEMgMjM6NTkuDQo+IFJldmlzZWQgV29ya2luZyBH cm91cCBhZ2VuZGFzIGFyZSBkdWUgbm8gbGF0ZXIgdGhhbiBNb25kYXksIEZlYnJ1YXJ5DQo+IDI0 dGgsIDIwMTQgYXQgVVRDIDIzOjU5LiAgVGhlIHByb3Bvc2VkIGFnZW5kYSBmb3IgYSBCT0Ygc2Vz c2lvbiBzaG91bGQNCj4gYmUgc3VibWl0dGVkIGFsb25nIHdpdGggeW91ciByZXF1ZXN0IGZvciBh IHNlc3Npb24uICBQbGVhc2UgYmUgc3VyZSB0bw0KPiBjb3B5IHlvdXIgQXJlYSBEaXJlY3RvciBv biB0aGF0IG1lc3NhZ2UuDQo+IA0KPiBQbGVhc2Ugc3VibWl0IHRoZSBhZ2VuZGFzIGZvciB5b3Vy IFdvcmtpbmcgR3JvdXAgc2Vzc2lvbnMgdXNpbmcgdGhlDQo+ICJJRVRGIE1lZXRpbmcgTWF0ZXJp YWxzIE1hbmFnZW1lbnQgVG9vbCwiIGEgV2ViLWJhc2VkIHRvb2wgZm9yIG1ha2luZw0KPiB5b3Vy IG1lZXRpbmcgYWdlbmRhLCBtaW51dGVzLCBhbmQgcHJlc2VudGF0aW9uIHNsaWRlcyBhdmFpbGFi bGUgdG8gdGhlDQo+IGNvbW11bml0eSBiZWZvcmUsIGR1cmluZywgYW5kIGFmdGVyIGFuIElFVEYg bWVldGluZy4gIElmIHlvdSBhcmUgYSBCT0YNCj4gY2hhaXIsIHRoZW4geW91IG1heSB1c2UgdGhl IHRvb2wgdG8gc3VibWl0IGEgcmV2aXNlZCBhZ2VuZGEgYXMgd2VsbCBhcw0KPiBvdGhlciBtYXRl cmlhbHMgZm9yIHlvdXIgQk9GIG9uY2UgdGhlIEJPRiBoYXMgYmVlbiBhcHByb3ZlZC4NCj4gDQo+ IFRoZSBVUkwgZm9yIHRoZSB0b29sIGlzOg0KPiANCj4gaHR0cHM6Ly9wdWIuaWV0Zi5vcmcvcHJv Y2VlZGluZ3MvDQo+IA0KPiBBZGRpdGlvbmFsIGluZm9ybWF0aW9uIGFib3V0IHRoaXMgdG9vbCBp cyBhdmFpbGFibGUgYXQ6DQo+IA0KPiBodHRwOi8vd3d3LmlldGYub3JnL2luc3RydWN0aW9ucy9t ZWV0aW5nX21hdGVyaWFsc190b29sLmh0bWwNCj4gDQo+IEFnZW5kYXMgc3VibWl0dGVkIHZpYSB0 aGUgdG9vbCB3aWxsIGJlIGF2YWlsYWJsZSB0byB0aGUgcHVibGljIG9uIHRoZQ0KPiAiSUVURiBN ZWV0aW5nIE1hdGVyaWFscyIgd2VicGFnZSBhcyBzb29uIGFzIHRoZXkgYXJlIHN1Ym1pdHRlZC4N Cj4gDQo+IFRoZSBVUkwgZm9yIHRoZSAiSUVURiA4OSBNZWV0aW5nIE1hdGVyaWFscyIgV2ViIHBh Z2UgaXM6DQo+IA0KPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL21lZXRpbmcvODkvbWF0 ZXJpYWxzLmh0bWwNCj4gDQo+IElmIHlvdSBhcmUgYSBXb3JraW5nIEdyb3VwIGNoYWlyLCB0aGVu IHlvdSBhbHJlYWR5IGhhdmUgYWNjb3VudHMgb24gdGhlDQo+ICJJRVRGIE1lZXRpbmcgU2Vzc2lv biBSZXF1ZXN0IFRvb2wiIGFuZCB0aGUgIklFVEYgTWVldGluZyBNYXRlcmlhbHMNCj4gTWFuYWdl bWVudCBUb29sLiIgIFRoZSBzYW1lIFVzZXIgSUQgYW5kIHBhc3N3b3JkIHdpbGwgd29yayBmb3Ig Ym90aA0KPiB0b29scy4gIElmIHlvdSBhcmUgYSBCT0YgY2hhaXIgd2hvIGlzIG5vdCBhbHNvIGEg V29ya2luZyBHcm91cCBjaGFpciwNCj4gdGhlbiB5b3Ugd2lsbCBiZSBnaXZlbiBhbiBhY2NvdW50 IG9uIHRoZSAiSUVURiBNZWV0aW5nIE1hdGVyaWFscw0KPiBNYW5hZ2VtZW50IFRvb2wiIHdoZW4g eW91ciBCT0YgaGFzIGJlZW4gYXBwcm92ZWQuICBJZiB5b3UgcmVxdWlyZQ0KPiBhc3Npc3RhbmNl IGluIHVzaW5nIGVpdGhlciB0b29sLCBvciB3aXNoIHRvIHJlcG9ydCBhIGJ1ZywgdGhlbiBwbGVh c2UNCj4gc2VuZCBhIG1lc3NhZ2UgdG86DQo+IGlldGYtYWN0aW9uQGlldGYub3JnLg0KPiA9PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT0NCj4gRm9yIHlvdXIgY29udmVuaWVuY2UsIGNvbXByZWhlbnNpdmUgaW5mb3JtYXRpb24gb24g cmVxdWVzdGluZyBtZWV0aW5nDQo+IHNlc3Npb25zIGZvciBJRVRGIDg5IGlzIGJlbG93Og0KPiAN Cj4gMS4gUmVxdWVzdHMgdG8gc2NoZWR1bGUgV29ya2luZyBHcm91cCBzZXNzaW9ucyBzaG91bGQg YmUgc3VibWl0dGVkIHVzaW5nDQo+IHRoZSAiSUVURiBNZWV0aW5nIFNlc3Npb24gUmVxdWVzdCBU b29sLCIgYSBXZWItYmFzZWQgdG9vbCBmb3Igc3VibWl0dGluZw0KPiBhbGwgb2YgdGhlIGluZm9y bWF0aW9uIHJlcXVpcmVkIGJ5IHRoZSBTZWNyZXRhcmlhdCB0byBzY2hlZHVsZSB5b3VyDQo+IHNl c3Npb25zLiAgVGhlIFVSTCBmb3IgdGhlIHRvb2wgaXM6DQo+IA0KPiBodHRwczovL3B1Yi5pZXRm Lm9yZy9zcmVxLw0KPiANCj4gSW5zdHJ1Y3Rpb25zIGZvciB1c2luZyB0aGUgdG9vbCBhcmUgYXZh aWxhYmxlIGF0Og0KPiANCj4gaHR0cDovL3d3dy5pZXRmLm9yZy9pbnN0cnVjdGlvbnMvc2Vzc2lv bl9yZXF1ZXN0X3Rvb2xfaW5zdHJ1Y3Rpb24uaHRtbA0KPiANCj4gSWYgeW91IHJlcXVpcmUgYW4g YWNjb3VudCBvbiB0aGlzIHRvb2wsIG9yIGFzc2lzdGFuY2UgaW4gdXNpbmcgaXQsIHRoZW4NCj4g cGxlYXNlIHNlbmQgYSBtZXNzYWdlIHRvIGlldGYtYWN0aW9uQGlldGYub3JnLiAgSWYgeW91IGFy ZSB1bmFibGUgdG8gdXNlDQo+IHRoZSB0b29sLCB0aGVuIHlvdSBtYXkgc2VuZCB5b3VyIHJlcXVl c3QgdmlhIGUtbWFpbCB0byBhZ2VuZGFAaWV0Zi5vcmcsDQo+IHdpdGggYSBjb3B5IHRvIHRoZSBh cHByb3ByaWF0ZSBBcmVhIERpcmVjdG9yKHMpLg0KPiANCj4gUmVxdWVzdHMgdG8gc2NoZWR1bGUg Qk9GIHNlc3Npb25zIG11c3QgYmUgc2VudCB0byBhZ2VuZGFAaWV0Zi5vcmcgd2l0aCBhDQo+IGNv cHkgdG8gdGhlIGFwcHJvcHJpYXRlIEFyZWEgRGlyZWN0b3IocykuDQo+IA0KPiBXaGVuIHN1Ym1p dHRpbmcgYSBXb3JraW5nIEdyb3VwIG9yIEJPRiBzZXNzaW9uIHJlcXVlc3QgYnkgZS1tYWlsLCBw bGVhc2UNCj4gaW5jbHVkZSB0aGUgV29ya2luZyBHcm91cCBvciBCT0YgYWNyb255bSBpbiB0aGUg U3ViamVjdCBsaW5lLg0KPiANCj4gMi4gQk9GcyB3aWxsIE5PVCBiZSBzY2hlZHVsZWQgdW5sZXNz IHRoZSBBcmVhIERpcmVjdG9yIGFwcHJvdmVzIHRoZSBCT0YuDQo+IFRoZSBwcm9wb25lbnRzIGJl aGluZCBhIEJPRiBuZWVkIHRvIGNvbnRhY3QgYSByZWxldmFudCBBcmVhIERpcmVjdG9yLA0KPiBw cmVmZXJhYmx5IHdlbGwgaW4gYWR2YW5jZSBvZiB0aGUgQk9GIGFwcHJvdmFsIGRlYWRsaW5lIGRh dGUuIFRoZSBBRA0KPiBuZWVkcyB0byBoYXZlIHRoZSBmdWxsIG5hbWUgb2YgdGhlIEJPRiwgaXRz IGFjcm9ueW0sIHN1Z2dlc3RlZCBuYW1lcyBvZg0KPiBjaGFpcnMsIGFuIGFnZW5kYSwgZnVsbCBk ZXNjcmlwdGlvbiBvZiB0aGUgQk9GIGFuZCB0aGUgaW5mb3JtYXRpb24NCj4gY292ZXJlZCBpbiBp dGVtIDQuIFBsZWFzZSByZWFkIFJGQyA1NDM0IGZvciBpbnN0cnVjdGlvbnMgb24gaG93IHRvIGRy aXZlDQo+IGEgc3VjY2Vzc2Z1bCBCT0YgZWZmb3J0LiBUaGUgYXBwcm92YWwgZGVwZW5kcyBvbiwg Zm9yIGluc3RhbmNlLA0KPiBJbnRlcm5ldC1EcmFmdHMgYW5kIGxpc3QgZGlzY3Vzc2lvbiBvbiB0 aGUgc3VnZ2VzdGVkIHRvcGljLiBCT0YgYWdlbmRhDQo+IHJlcXVlc3RzLCBpZiBhcHByb3ZlZCwg d2lsbCBiZSBzdWJtaXR0ZWQgdG8gdGhlIElFVEYgU2VjcmV0YXJpYXQgYnkgdGhlDQo+IEFEcy4N Cj4gDQo+IDMuIEEgV29ya2luZyBHcm91cCBtYXkgcmVxdWVzdCBlaXRoZXIgb25lIG9yIHR3byBz ZXNzaW9ucy4gIElmIHlvdXINCj4gV29ya2luZyBHcm91cCByZXF1aXJlcyBtb3JlIHRoYW4gdHdv IHNlc3Npb25zLCB0aGVuIHlvdXIgcmVxdWVzdCBtdXN0IGJlDQo+IGFwcHJvdmVkIGJ5IGFuIEFy ZWEgRGlyZWN0b3IuICBBZGRpdGlvbmFsIHNlc3Npb25zIHdpbGwgYmUgYXNzaWduZWQsDQo+IGJh c2VkIG9uIGF2YWlsYWJpbGl0eSwgYWZ0ZXIgTW9uZGF5LCBGZWJydWFyeSAzcmQsIDIwMTQsIHRo ZSBjdXQtb2ZmDQo+IGRhdGUgZm9yIHJlcXVlc3RzIHRvIHJlc2NoZWR1bGUgYSBzZXNzaW9uLg0K PiANCj4gNC4gWW91IE1VU1QgcHJvdmlkZSB0aGUgZm9sbG93aW5nIGluZm9ybWF0aW9uIGJlZm9y ZSBhIFdvcmtpbmcgR3JvdXAgb3INCj4gQk9GIHNlc3Npb24gd2lsbCBiZSBzY2hlZHVsZWQ6DQo+ IA0KPiAgICAgYS4gV29ya2luZyBHcm91cCBvciBCT0YgZnVsbCBuYW1lIHdpdGggYWNyb255bSBp biBicmFja2V0czoNCj4gDQo+ICAgICBiLiBBUkVBIHVuZGVyIHdoaWNoIFdvcmtpbmcgR3JvdXAg b3IgQk9GIGFwcGVhcnM6DQo+IA0KPiAgICAgYy4gQ09ORkxJQ1RTIHlvdSB3aXNoIHRvIGF2b2lk LCBwbGVhc2UgYmUgYXMgc3BlY2lmaWMgYXMgcG9zc2libGU6DQo+IA0KPiAgICAgZC4gRXhwZWN0 ZWQgQXR0ZW5kYW5jZToNCj4gDQo+ICAgICBlLiBTcGVjaWFsIHJlcXVlc3RzOg0KPiANCj4gICAg IGYuIE51bWJlciBvZiBzZXNzaW9uczoNCj4gDQo+ICAgICBnLiBMZW5ndGggb2Ygc2Vzc2lvbjoN Cj4gICAgICAgIC0gMSBob3VyDQo+ICAgICAgICAtIDEgMS8yIGhvdXJzDQo+ICAgICAgICAtIDIg aG91cnMNCj4gICAgICAgIC0gMiAxLzIgaG91cnMNCj4gDQo+IEZvciBtb3JlIGluZm9ybWF0aW9u IG9uIHNjaGVkdWxpbmcgV29ya2luZyBHcm91cCBhbmQgQk9GIHNlc3Npb25zLA0KPiBwbGVhc2Ug cmVmZXIgdG8gUkZDIDI0MTggKEJDUCAyNSksICJJRVRGIFdvcmtpbmcgR3JvdXAgR3VpZGVsaW5l cyBhbmQNCj4gUHJvY2VkdXJlcyIgKGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjL3JmYzI0MTgudHh0 KS4NCj4gPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09DQo+IEZvciB5b3VyIGNvbnZlbmllbmNlIHBsZWFzZSBmaW5kIGhlcmUgYSBs aXN0IG9mIHRoZSBJRVRGIEFyZWEgRGlyZWN0b3JzDQo+IHdpdGggdGhlaXIgZS1tYWlsIGFkZHJl c3NlczoNCj4gDQo+IElFVEYgQ2hhaXINCj4gSmFyaSBBcmtrbyA8amFyaS5hcmtrb0BwaXVoYS5u ZXQ+DQo+IA0KPiBBcHBsaWNhdGlvbnMgQXJlYSAoYXBwKQ0KPiBCYXJyeSBMZWliYSA8YmFycnls ZWliYUBjb21wdXRlci5vcmc+DQo+IFBldGUgUmVzbmljayA8cHJlc25pY2tAcXVhbGNvbW0uY29t Pg0KPiANCj4gSW50ZXJuZXQgQXJlYSAoaW50KQ0KPiBCcmlhbiBIYWJlcm1hbiA8YnJpYW5AaW5u b3ZhdGlvbnNsYWIubmV0PiBUZWQgTGVtb24NCj4gPHRlZC5sZW1vbkBub21pbnVtLmNvbT4NCj4g DQo+IE9wZXJhdGlvbnMgJiBNYW5hZ2VtZW50IEFyZWEgKG9wcykNCj4gQmVub2l0IENsYWlzZSA8 YmNsYWlzZUBjaXNjby5jb20+DQo+IEpvZWwgSmFlZ2dsaSA8am9lbGphQGJvZ3VzLmNvbT4NCj4g DQo+IFJlYWwtdGltZSBBcHBsaWNhdGlvbnMgYW5kIEluZnJhc3RydWN0dXJlIEFyZWEgKHJhaSkg R29uemFsbyBDYW1hcmlsbG8NCj4gPGdvbnphbG8uY2FtYXJpbGxvQGVyaWNzc29uLmNvbT4gUmlj aGFyZCBCYXJuZXMgPHJsYkBpcHYuc3g+DQo+IA0KPiBSb3V0aW5nIEFyZWEgKHJ0ZykNCj4gU3Rl d2FydCBCcnlhbnQgPHN0YnJ5YW50QGNpc2NvLmNvbT4NCj4gQWRyaWFuIEZhcnJlbCA8YWRyaWFu QG9sZGRvZy5jby51az4NCj4gDQo+IFNlY3VyaXR5IEFyZWEgKHNlYykNCj4gU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPiBTZWFuIFR1cm5lcg0KPiA8dHVybmVyc0Bp ZWNhLmNvbT4NCj4gDQo+IFRyYW5zcG9ydCBBcmVhICh0c3YpDQo+IE1hcnRpbiBTdGllbWVybGlu ZyA8bWFydGluLnN0aWVtZXJsaW5nQG5lY2xhYi5ldT4gU3BlbmNlciBEYXdraW5zDQo+IDxzcGVu Y2VyZGF3a2lucy5pZXRmQGdtYWlsLmNvbT4NCj4gPT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCj4gODh0aCBJRVRGIE1lZXRpbmcgQXR0 ZW5kYW5jZSBOdW1iZXJzDQo+IA0KPiA2bG8gLSA1Mg0KPiA2bWFuIC0gMTQzDQo+IDZ0aXNjaCAt IDQ1DQo+IGFiZmFiIC0gMjANCj4gYWx0byAgLSAzNQ0KPiBhcHBzYXdnL2FwcGFyZWEgLSAxMzgN Cj4gYXFtIC0gMTA4DQo+IGFxbSAoMm5kIHNlc3Npb24pIC0gNDUNCj4gYXZ0Y29yZSAtIDUxDQo+ IGF2dGV4dCDigJMgNTkNCj4gYmZkIC0gMTcNCj4gYm13ZyAtIDE5DQo+IGNjYW1wIC0gNDkNCj4g Y2NhbXAgKDJuZCBzZXNzaW9uKSAtIDQ0DQo+IGNkbmkgLSAzOQ0KPiBjbHVlIC0gNDENCj4gY2x1 ZSAoMm5kIHNlc3Npb24pIC0gMzINCj4gY29yZSAtIDYyDQo+IGNvcmUgKDJuZCBzZXNzaW9uKSAt IDUwDQo+IGRoYyAtIDU5DQo+IGRpY2UgLSA2NQ0KPiBkaW1lIC0gMjMNCj4gZGlzcGF0Y2ggLSA1 NQ0KPiBkbW0gLSAzNw0KPiBkbnNvcCAtIDEyNQ0KPiBkbnNzZCAtIDEwOA0KPiBlY3JpdCAtIDMx DQo+IGVtYW4gLSAxOQ0KPiBmb3JjZXMgLSA0MA0KPiBnZW9uZXQgKEJvRikgLSA5OQ0KPiBnZW9w cml2IC0gNDENCj4gaG9tZW5ldCAtIDE1Ng0KPiBodHRwYXV0aCAtIDQzDQo+IGh0dHBiaXMgLSA4 OQ0KPiBodHRwYmlzICgybmQgc2Vzc2lvbikgLSAxMjcNCj4gaTJycyAtIDIyMw0KPiBpY2NyZyAo UkcpIC0gNjgNCj4gaWNucmcgKFJHKSAtIDQzDQo+IGlkciAtIDkwDQo+IGlnb3Z1cGRhdGUgQm9G IC0gMjIwDQo+IGluc2lwaWQgLSAzMg0KPiBpbnRhcmVhIChBRykgLSA5OA0KPiBpcGZpeCAtIDIz DQo+IGlwcG0gLSA0OA0KPiBpcHNlY21lIC0gMjcNCj4gSVJURiBPcGVuIE1lZXRpbmcgLSAxMDAN Cj4gaXNpcyAtIDU4DQo+IGpvc2UgLSA0Mg0KPiBqc29uIC0gNDkNCj4ga2FycCAtIDIyDQo+IGtp dHRlbiAtIDIzDQo+IGwydnBuIC0gNzENCj4gbDN2cG4gLSA2NQ0KPiBsaXNwIC0gNTYNCj4gbG1h cCAtIDUyDQo+IGx3aWcgLSAzNQ0KPiBtYW5ldCAtIDM1DQo+IG1ib25lZCAtIDI1DQo+IG1pZiAt IDQxDQo+IG1tdXNpYyAtIDY5DQo+IG1tdXNpYyAoMm5kIHNlc3Npb24pIC0gNTMNCj4gbXBscyAt IDcxDQo+IG1wbHMgKDJuZCBzZXNzaW9uKSAtIDcyDQo+IG1wdGNwIC0gNDUNCj4gbXB0Y3AgKDJu ZCBzZXNzaW9uKSAtIDcwDQo+IG5jcmcgKFJHKSAtIDMzDQo+IG5ldGNvbmYgLSA2Mg0KPiBuZXRl eHQgLSAyNw0KPiBuZXRtb2QgLSA2OQ0KPiBuZnN2NCAtIDE2DQo+IG5tcmcgKFJHKSAtIDM1DQo+ IG5tcmcgKFJHKSAoMm5kIHNlc3Npb24pIC0gMTcNCj4gbnRwIChjb21iaW5lZCB3aXRoIHRpY3Rv YykgLSAzMg0KPiBudm8zIC0gMTkzDQo+IG53Y3JnIChQUkcpIC0gMjUNCj4gb2F1dGggLSAzOA0K PiBvcHNhd2cvb3BzYXJlYSAtIDY4DQo+IG9wc2VjIC0gNDgNCj4gb3NwZiAtIDM4DQo+IHBhd3Mg LSAxNw0KPiBwY2UgLSA3Mg0KPiBwY3AgLSAzMA0KPiBwZXJwYXNzIChCb0YpIC0gMzEzDQo+IHBp bSAtIDI0DQo+IHBwc3AgLSAxMg0KPiBwcmVjaXMgLSAzMg0KPiBwd2UzIC0gNDANCj4gcmFkZXh0 IC0gMjANCj4gcmZjZm9ybSAoQm9GKSAtIDUyDQo+IHJtY2F0IC0gNjANCj4gcnRjd2ViIC0gMTc0 DQo+IHJ0Y3dlYiAoMm5kIHNlc3Npb24pIC0gMTg4DQo+IHJ0Z2FyZWEgKEFHKSAtIDEwMQ0KPiBy dGd3ZyAtIDExOA0KPiBzYWFnIChBRykgLSAxNDgNCj4gc2FjbSAtIDQwDQo+IHNjaW0gLSAzMg0K PiBzZG5yZyAoUkcpIC0gMjU5DQo+IHNpZHIgLSA2MQ0KPiBzaXByZWMgLSAzMQ0KPiBzb2Z0d2ly ZSAtIDUyDQo+IHNwcmluZyAtIDE1OA0KPiBzdGlyIC0gODINCj4gc3RpciAoMm5kIHNlc3Npb24p IC0gNzkNCj4gc3Rvcm0gLSAyMQ0KPiB0Y3BtIC0gMzYNCj4gdGljdG9jIChjb21iaW5lZCB3aXRo IG50cCkgLSAzMg0KPiB0bHMgLSAxMTENCj4gdHJpbGwgLSAzMw0KPiB0c3ZhcmVhIChBRykgLSAx NTMNCj4gdHN2d2cgLSA2Mw0KPiB0c3Z3ZyAoMm5kIHNlc3Npb24pIC0gNDcNCj4gdjZvcHMgLSAx MzUNCj4gdjZvcHMgKDJuZCBzZXNzaW9uKSAtIDkyDQo+IHdlaXJkcyAtIDU1DQo+IHdwa29wcyAt IDM0DQo+IHhtcHAgLSAzMQ0KPiB4cmJsb2NrIC0gMjQNCg== From dbharrington@comcast.net Tue Dec 10 11:18:33 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09DAF1AE1D4 for ; Tue, 10 Dec 2013 11:18:33 -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_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9JtyBnUkZySh for ; Tue, 10 Dec 2013 11:18:31 -0800 (PST) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:16]) by ietfa.amsl.com (Postfix) with ESMTP id 078DE1AE06B for ; Tue, 10 Dec 2013 11:18:30 -0800 (PST) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta01.westchester.pa.mail.comcast.net with comcast id zo8f1m0040cZkys51vJR7S; Tue, 10 Dec 2013 19:18:25 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta10.westchester.pa.mail.comcast.net with comcast id zvJR1m00F2yZEBF3WvJRD7; Tue, 10 Dec 2013 19:18:25 +0000 From: "David Harrington" To: "'Adam Montville'" , References: <05BCCEB107AF88469B9F99783D47C1D6065F55F5@CISEXCHANGE1.msisac.org.local> In-Reply-To: <05BCCEB107AF88469B9F99783D47C1D6065F55F5@CISEXCHANGE1.msisac.org.local> Date: Tue, 10 Dec 2013 14:18:23 -0500 Message-ID: <029601cef5dc$983e19e0$c8ba4da0$@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKt+KGLt7UUCU2iz5x967OWY1Tzj5iPxtKg Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1386703105; bh=q3hxTfg6K2xXusp2eIvEv0FOSh/R2fOJ8IXspLM9IKQ=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=rGw60HPH/aruyZfgkU1Xj3+q1ctr93FzHaDZxSPAnbA8DrziOWwzYMHOlHOtiHN/x B0iykdzQHY13PDh1q00uwqAyqjMEeFKbTTWXyihhcnJhZcyB0GR0NQuEVGioBvkohf 2OWuCJCrlO4IS+vETF8T/8zaTFHCUfm19Jv0Kye85HQ2u3KQIYv1IdZ5d9COnbQMjY r+2Fg/EWBaPfb6dhW1rCmvyo+uHregB1Zcava3xV4SQBzcKaJhyPieYS606DlrI2EO zJrHsL2acT7c6Phtznfa56OLS0WVu2mwfs05gA78b9Zt0tcdT8CbO5uO5U/N8JLhnZ l2OpsTUFk1DUg== Subject: Re: [sacm] Preparing for 12/17 Interim Meeting X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 19:18:33 -0000 Hi, > 4. Do we need any time for the terminology document? If we are going to capitalize end-user, operator, administrator, etc., then we probably need to define these terms in the terminology draft, and that would require some discussion. If we do not capitalize them, then I think their definitions are fairly obvious and do not need to be included in the terminology draft, and don't need discussion. Personally, I think trying to nail down these terms to be something special is about as relevant as debating how many angels can fit on the head of a pin, and do not help this WG achieve its chartered goals. David Harrington dbharrington@comcast.net +1-603-828-1401 > -----Original Message----- > From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Adam Montville > Sent: Tuesday, December 10, 2013 10:23 AM > To: sacm@ietf.org > Subject: [sacm] Preparing for 12/17 Interim Meeting > > Hi, > > We are one week before the virtual interim scheduled for 12/17. We need to > do some preparations in order to make sure that we use our shared time in > an efficient manner. > > 1. We need at least one, better two note takers. Interim meetings must be > minuted, as all IETF WG meeting. Volunteering is appreciated. > > 2. The Use Case document will be the major point on the agenda. David and > David - do you plan to submit an update before the meeting? The sooner the > better, but not later than Friday 12/13 I suggest. Who of you will lead the > discussion in the meeting? The goal is to discuss the open issues and close as > many of them as possible. > > 3. The 'Way Forward' plan included submission of the Requirements > document by 12/1. This did not happen. Nancy - do you still plan to do it? Will > you lead the discussion on this? > > 4. Do we need any time for the terminology document? > > 5. Are there other proposals for the agenda? > > Thanks and Regards, > > Adam and Dan > > . . . > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm From dbharrington@comcast.net Tue Dec 10 11:20:56 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 033CC1ADFF5 for ; Tue, 10 Dec 2013 11:20:56 -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_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MsY3drdO3iin for ; Tue, 10 Dec 2013 11:20:54 -0800 (PST) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:211]) by ietfa.amsl.com (Postfix) with ESMTP id D0B861AE068 for ; Tue, 10 Dec 2013 11:20:53 -0800 (PST) Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by QMTA11.westchester.pa.mail.comcast.net with comcast id zsBc1m0090Fqzac5BvLo6E; Tue, 10 Dec 2013 19:20:48 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta08.westchester.pa.mail.comcast.net with comcast id zvLo1m0052yZEBF3UvLoo3; Tue, 10 Dec 2013 19:20:48 +0000 From: "David Harrington" To: "'Adam Montville'" , References: <05BCCEB107AF88469B9F99783D47C1D6065F55F5@CISEXCHANGE1.msisac.org.local> In-Reply-To: <05BCCEB107AF88469B9F99783D47C1D6065F55F5@CISEXCHANGE1.msisac.org.local> Date: Tue, 10 Dec 2013 14:20:46 -0500 Message-ID: <029701cef5dc$ed70b580$c8522080$@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKt+KGLt7UUCU2iz5x967OWY1Tzj5iPx/ZA Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1386703248; bh=Zso63+7dICkdKeMZezZUsiy/S3kUgLURHKynqsLR+aw=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=dJJUpo4MYl8kL+RVdIPBOZP/xvbSxBbqdLH9hFpbAP/CmzdCB51o80lEi8pHX6Pks hz50p1lpDbCrVsL5zDNscFm69XZ9O/dzZq5c7lGvB4gOSAPZDktfnQhTtT/PDbmP+/ hOiLCi8xj+3yK35OUrCbDxqOqvr1e3qfHI5PI2rCXiNBKCLA8LnUdlvaYcb1mF5AAh jqbIPGYblKrtQ7/10HpSuXi2hQETs+sMX7jmSPKteZejvZpcH4cS284jyUhifLmYyD 9EKNnnAxHaRuJ4JyxvtvB/n+DbPH8ww7i8KLzPY9KKBXG7JXqE4zhBHby7zawlsjSz w8FYHHRAZ19aA== Subject: Re: [sacm] Preparing for 12/17 Interim Meeting X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 19:20:56 -0000 > 2. The Use Case document will be the major point on the agenda. David and > David - do you plan to submit an update before the meeting? The sooner the > better, but not later than Friday 12/13 I suggest. Who of you will lead the > discussion in the meeting? The goal is to discuss the open issues and close as > many of them as possible. I plan to do a thorough review of the document later today. I will discuss with David W whether an update is needed, and who will lead the discussion. David Harrington dbharrington@comcast.net +1-603-828-1401 > -----Original Message----- > From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Adam Montville > Sent: Tuesday, December 10, 2013 10:23 AM > To: sacm@ietf.org > Subject: [sacm] Preparing for 12/17 Interim Meeting > > Hi, > > We are one week before the virtual interim scheduled for 12/17. We need to > do some preparations in order to make sure that we use our shared time in > an efficient manner. > > 1. We need at least one, better two note takers. Interim meetings must be > minuted, as all IETF WG meeting. Volunteering is appreciated. > > 2. The Use Case document will be the major point on the agenda. David and > David - do you plan to submit an update before the meeting? The sooner the > better, but not later than Friday 12/13 I suggest. Who of you will lead the > discussion in the meeting? The goal is to discuss the open issues and close as > many of them as possible. > > 3. The 'Way Forward' plan included submission of the Requirements > document by 12/1. This did not happen. Nancy - do you still plan to do it? Will > you lead the discussion on this? > > 4. Do we need any time for the terminology document? > > 5. Are there other proposals for the agenda? > > Thanks and Regards, > > Adam and Dan > > . . . > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm From david.waltermire@nist.gov Tue Dec 10 11:39:52 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D18A51AE068 for ; Tue, 10 Dec 2013 11:39:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wYhPxNbwBzeR for ; Tue, 10 Dec 2013 11:39:49 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0185.outbound.protection.outlook.com [207.46.163.185]) by ietfa.amsl.com (Postfix) with ESMTP id 8BE4C1ADFF5 for ; Tue, 10 Dec 2013 11:39:49 -0800 (PST) Received: from BLUPR09MB038.namprd09.prod.outlook.com (10.255.211.144) by BLUPR09MB039.namprd09.prod.outlook.com (10.255.211.153) with Microsoft SMTP Server (TLS) id 15.0.837.10; Tue, 10 Dec 2013 19:39:41 +0000 Received: from BLUPR09MB038.namprd09.prod.outlook.com ([169.254.11.67]) by BLUPR09MB038.namprd09.prod.outlook.com ([169.254.11.67]) with mapi id 15.00.0837.004; Tue, 10 Dec 2013 19:39:41 +0000 From: "Waltermire, David A." To: "Romascanu, Dan (Dan)" , "sacm@ietf.org" Thread-Topic: [sacm] IETF 89 - Working Group/BOF/IRTF Scheduling Thread-Index: AQHO9d+OJa+RgkOYhkmm/qPvErOH9A== Date: Tue, 10 Dec 2013 19:39:40 +0000 Message-ID: <7d830b39e9a74c90947bfa4c8bf7ba7e@BLUPR09MB038.namprd09.prod.outlook.com> References: <9904FB1B0159DA42B0B887B7FA8119CA129DFE39@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA129DFE39@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.6.16.52] x-forefront-prvs: 005671E15D x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(377454003)(51704005)(22804002)(13464003)(199002)(189002)(32444003)(377424004)(502244003)(76576001)(79102001)(47446002)(65816001)(15975445006)(47736001)(47976001)(74706001)(53806001)(76786001)(77096001)(74502001)(69226001)(63696002)(31966008)(85852003)(83072002)(33646001)(76796001)(54316002)(56776001)(50986001)(76482001)(46102001)(551544002)(87266001)(74366001)(74316001)(85306002)(56816005)(90146001)(81686001)(2656002)(87936001)(81542001)(561944002)(81816001)(74662001)(80022001)(4396001)(66066001)(54356001)(80976001)(51856001)(19580395003)(49866001)(81342001)(74876001)(19580405001)(77982001)(15202345003)(59766001)(83322001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR09MB039; H:BLUPR09MB038.namprd09.prod.outlook.com; CLIP:129.6.16.52; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov Subject: Re: [sacm] IETF 89 - Working Group/BOF/IRTF Scheduling X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 19:39:53 -0000 It may make sense to schedule a second Friday working meeting to do group e= dits on drafts. Dave ________________________________________ From: sacm on behalf of Romascanu, Dan (Dan) Sent: Tuesday, December 10, 2013 4:56:15 PM To: sacm@ietf.org Subject: Re: [sacm] IETF 89 - Working Group/BOF/IRTF Scheduling It will be IETF-89, of course. > -----Original Message----- > From: Romascanu, Dan (Dan) > Sent: Tuesday, December 10, 2013 5:53 PM > To: sacm@ietf.org > Subject: FW: IETF 89 - Working Group/BOF/IRTF Scheduling > > > Hi, > > Scheduling for the IETF-88 meeting in London is now open. > > Our plan is to request one 2 hours meeting slot, as we had at IETF-88. > Anybody believes that we need more, or less time? > > Also please send us your list of critical conflicts, beyond the obvious. > > Thanks and Regards, > > Adam and Dan > > > > -----Original Message----- > From: WGChairs [mailto:wgchairs-bounces@ietf.org] On Behalf Of IETF > Agenda > Sent: Tuesday, December 03, 2013 10:13 PM > To: Working Group Chairs > Cc: irsg@irtf.org > Subject: IETF 89 - Working Group/BOF/IRTF Scheduling > > ----------------------------------------------------------------- > 89th IETF =96 London, England > Meeting Dates: March 2 =96 7, 2014 > ----------------------------------------------------------------- > IETF meetings start Monday morning and run through Friday afternoon > (13:30). > > We are accepting scheduling requests for all Working Groups, BOFs, and > Research Groups starting today. The milestones and deadlines for > scheduling-related activities are as follows: > > NOTE: cutoff dates are subject to change. > > - 2013-12-02 (Monday): Working Group and BOF scheduling begins. To > request a Working Group session, use the IETF Meeting Session Request > Tool. > - 2014-01-17 (Friday): Cut-off date for requests to schedule Working > Group meetings at UTC 23:59. To request a Working Group session, use the > IETF Meeting Session Request Tool. > - 2014-01-17 (Friday): Cut-off date for BOF proposal requests to Area > Directors at UTC 23:59. To request a BOF, please see instructions on > Requesting a BOF. > - 2014-01-24 (Friday): Cut-off date for Area Directors to approve BOFs > at UTC 23:59. > - 2014-01-31 (Friday): Preliminary agenda published for comment. > - 2014-02-03 (Monday): Cut-off date for requests to reschedule Working > Group and BOF meetings UTC 23:59. > - 2014-02-07 (Friday): Final agenda to be published. > - 2014-02-17 (Monday): Draft Working Group agendas due by UTC 23:59, > upload using IETF Meeting Materials Management Tool. > - 2014-02-24 (Monday): Revised Working Group agendas due by UTC 23:59, > upload using IETF Meeting Materials Management Tool. > - 2014-03-28 (Friday): Proceedings submission cutoff date by UTC 23:59, > upload using IETF Meeting Materials Management Tool. > - 2014-04-18 (Friday): Proceedings submission corrections cutoff date by > UTC 23:59, upload using IETF Meeting Materials Management Tool. > > Submitting Requests for Working Group and BOF Sessions > > Please submit requests to schedule your Working Group sessions using the > "IETF Meeting Session Request Tool," a Web-based tool for submitting all > of the information that the Secretariat requires to schedule your > sessions. > > The URL for the tool is: > > https://pub.ietf.org/sreq/ > > Please send requests to schedule your BOF sessions to agenda@ietf.org. > Please include the acronym of your BOF in the subject line of the > message, and include all of the information specified in item (4) of > "Requesting Meeting Sessions at IETF Meetings" in the body. (This > document is included below.) > > Submitting Session Agendas > > For the convenience of meeting attendees, we ask that you submit the > agendas for your Working Group sessions as early as possible. Draft > Working Group agendas are due Monday, February 17th, 2014 at UTC 23:59. > Revised Working Group agendas are due no later than Monday, February > 24th, 2014 at UTC 23:59. The proposed agenda for a BOF session should > be submitted along with your request for a session. Please be sure to > copy your Area Director on that message. > > Please submit the agendas for your Working Group sessions using the > "IETF Meeting Materials Management Tool," a Web-based tool for making > your meeting agenda, minutes, and presentation slides available to the > community before, during, and after an IETF meeting. If you are a BOF > chair, then you may use the tool to submit a revised agenda as well as > other materials for your BOF once the BOF has been approved. > > The URL for the tool is: > > https://pub.ietf.org/proceedings/ > > Additional information about this tool is available at: > > http://www.ietf.org/instructions/meeting_materials_tool.html > > Agendas submitted via the tool will be available to the public on the > "IETF Meeting Materials" webpage as soon as they are submitted. > > The URL for the "IETF 89 Meeting Materials" Web page is: > > https://datatracker.ietf.org/meeting/89/materials.html > > If you are a Working Group chair, then you already have accounts on the > "IETF Meeting Session Request Tool" and the "IETF Meeting Materials > Management Tool." The same User ID and password will work for both > tools. If you are a BOF chair who is not also a Working Group chair, > then you will be given an account on the "IETF Meeting Materials > Management Tool" when your BOF has been approved. If you require > assistance in using either tool, or wish to report a bug, then please > send a message to: > ietf-action@ietf.org. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > For your convenience, comprehensive information on requesting meeting > sessions for IETF 89 is below: > > 1. Requests to schedule Working Group sessions should be submitted using > the "IETF Meeting Session Request Tool," a Web-based tool for submitting > all of the information required by the Secretariat to schedule your > sessions. The URL for the tool is: > > https://pub.ietf.org/sreq/ > > Instructions for using the tool are available at: > > http://www.ietf.org/instructions/session_request_tool_instruction.html > > If you require an account on this tool, or assistance in using it, then > please send a message to ietf-action@ietf.org. If you are unable to use > the tool, then you may send your request via e-mail to agenda@ietf.org, > with a copy to the appropriate Area Director(s). > > Requests to schedule BOF sessions must be sent to agenda@ietf.org with a > copy to the appropriate Area Director(s). > > When submitting a Working Group or BOF session request by e-mail, please > include the Working Group or BOF acronym in the Subject line. > > 2. BOFs will NOT be scheduled unless the Area Director approves the BOF. > The proponents behind a BOF need to contact a relevant Area Director, > preferably well in advance of the BOF approval deadline date. The AD > needs to have the full name of the BOF, its acronym, suggested names of > chairs, an agenda, full description of the BOF and the information > covered in item 4. Please read RFC 5434 for instructions on how to drive > a successful BOF effort. The approval depends on, for instance, > Internet-Drafts and list discussion on the suggested topic. BOF agenda > requests, if approved, will be submitted to the IETF Secretariat by the > ADs. > > 3. A Working Group may request either one or two sessions. If your > Working Group requires more than two sessions, then your request must be > approved by an Area Director. Additional sessions will be assigned, > based on availability, after Monday, February 3rd, 2014, the cut-off > date for requests to reschedule a session. > > 4. You MUST provide the following information before a Working Group or > BOF session will be scheduled: > > a. Working Group or BOF full name with acronym in brackets: > > b. AREA under which Working Group or BOF appears: > > c. CONFLICTS you wish to avoid, please be as specific as possible: > > d. Expected Attendance: > > e. Special requests: > > f. Number of sessions: > > g. Length of session: > - 1 hour > - 1 1/2 hours > - 2 hours > - 2 1/2 hours > > For more information on scheduling Working Group and BOF sessions, > please refer to RFC 2418 (BCP 25), "IETF Working Group Guidelines and > Procedures" (http://www.ietf.org/rfc/rfc2418.txt). > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > For your convenience please find here a list of the IETF Area Directors > with their e-mail addresses: > > IETF Chair > Jari Arkko > > Applications Area (app) > Barry Leiba > Pete Resnick > > Internet Area (int) > Brian Haberman Ted Lemon > > > Operations & Management Area (ops) > Benoit Claise > Joel Jaeggli > > Real-time Applications and Infrastructure Area (rai) Gonzalo Camarillo > Richard Barnes > > Routing Area (rtg) > Stewart Bryant > Adrian Farrel > > Security Area (sec) > Stephen Farrell Sean Turner > > > Transport Area (tsv) > Martin Stiemerling Spencer Dawkins > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > 88th IETF Meeting Attendance Numbers > > 6lo - 52 > 6man - 143 > 6tisch - 45 > abfab - 20 > alto - 35 > appsawg/apparea - 138 > aqm - 108 > aqm (2nd session) - 45 > avtcore - 51 > avtext =96 59 > bfd - 17 > bmwg - 19 > ccamp - 49 > ccamp (2nd session) - 44 > cdni - 39 > clue - 41 > clue (2nd session) - 32 > core - 62 > core (2nd session) - 50 > dhc - 59 > dice - 65 > dime - 23 > dispatch - 55 > dmm - 37 > dnsop - 125 > dnssd - 108 > ecrit - 31 > eman - 19 > forces - 40 > geonet (BoF) - 99 > geopriv - 41 > homenet - 156 > httpauth - 43 > httpbis - 89 > httpbis (2nd session) - 127 > i2rs - 223 > iccrg (RG) - 68 > icnrg (RG) - 43 > idr - 90 > igovupdate BoF - 220 > insipid - 32 > intarea (AG) - 98 > ipfix - 23 > ippm - 48 > ipsecme - 27 > IRTF Open Meeting - 100 > isis - 58 > jose - 42 > json - 49 > karp - 22 > kitten - 23 > l2vpn - 71 > l3vpn - 65 > lisp - 56 > lmap - 52 > lwig - 35 > manet - 35 > mboned - 25 > mif - 41 > mmusic - 69 > mmusic (2nd session) - 53 > mpls - 71 > mpls (2nd session) - 72 > mptcp - 45 > mptcp (2nd session) - 70 > ncrg (RG) - 33 > netconf - 62 > netext - 27 > netmod - 69 > nfsv4 - 16 > nmrg (RG) - 35 > nmrg (RG) (2nd session) - 17 > ntp (combined with tictoc) - 32 > nvo3 - 193 > nwcrg (PRG) - 25 > oauth - 38 > opsawg/opsarea - 68 > opsec - 48 > ospf - 38 > paws - 17 > pce - 72 > pcp - 30 > perpass (BoF) - 313 > pim - 24 > ppsp - 12 > precis - 32 > pwe3 - 40 > radext - 20 > rfcform (BoF) - 52 > rmcat - 60 > rtcweb - 174 > rtcweb (2nd session) - 188 > rtgarea (AG) - 101 > rtgwg - 118 > saag (AG) - 148 > sacm - 40 > scim - 32 > sdnrg (RG) - 259 > sidr - 61 > siprec - 31 > softwire - 52 > spring - 158 > stir - 82 > stir (2nd session) - 79 > storm - 21 > tcpm - 36 > tictoc (combined with ntp) - 32 > tls - 111 > trill - 33 > tsvarea (AG) - 153 > tsvwg - 63 > tsvwg (2nd session) - 47 > v6ops - 135 > v6ops (2nd session) - 92 > weirds - 55 > wpkops - 34 > xmpp - 31 > xrblock - 24 _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm From dromasca@avaya.com Tue Dec 10 11:44:32 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C8E91AE20D for ; Tue, 10 Dec 2013 11:44:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vi-WLqQRAtup for ; Tue, 10 Dec 2013 11:44:29 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id E44671AE1BA for ; Tue, 10 Dec 2013 11:44:28 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFAMhup1KHCzI1/2dsb2JhbABZgmYhOFO5HYEhFnSCJQEBAQECAQEBAQ8oNBAHBAIBCA0EBAEBCwsBAgYJByEGCxQJCAIEARIIAQsOh04DCQYBDKcIkyMNgSSFQxeMc4E+IzMFBgQIBgaDA4ETAQOWKAGIV4VuhTmDKYFxOQ X-IronPort-AV: E=Sophos;i="4.93,866,1378872000"; d="scan'208";a="40440872" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 10 Dec 2013 14:43:58 -0500 Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES128-SHA; 10 Dec 2013 14:33:18 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC04.global.avaya.com ([135.64.58.14]) with mapi id 14.03.0146.000; Tue, 10 Dec 2013 20:43:56 +0100 From: "Romascanu, Dan (Dan)" To: "Waltermire, David A." , "sacm@ietf.org" Thread-Topic: [sacm] IETF 89 - Working Group/BOF/IRTF Scheduling Thread-Index: AQHO8GQP5CpJNaBycEKcxcw6GqReu5pNm3mggAAEV4CAAC3GAIAAEXmQ Date: Tue, 10 Dec 2013 19:43:56 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA129E00B5@AZ-FFEXMB04.global.avaya.com> References: <9904FB1B0159DA42B0B887B7FA8119CA129DFE39@AZ-FFEXMB04.global.avaya.com> <7d830b39e9a74c90947bfa4c8bf7ba7e@BLUPR09MB038.namprd09.prod.outlook.com> In-Reply-To: <7d830b39e9a74c90947bfa4c8bf7ba7e@BLUPR09MB038.namprd09.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sacm] IETF 89 - Working Group/BOF/IRTF Scheduling X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 19:44:32 -0000 I suggest that we discuss this at the virtual interim. We need commitment a= t least from the principal contributors that they will be attending a secon= d Friday meeting. Regards, Dan =20 > -----Original Message----- > From: Waltermire, David A. [mailto:david.waltermire@nist.gov] > Sent: Tuesday, December 10, 2013 9:40 PM > To: Romascanu, Dan (Dan); sacm@ietf.org > Subject: Re: [sacm] IETF 89 - Working Group/BOF/IRTF Scheduling >=20 > It may make sense to schedule a second Friday working meeting to do > group edits on drafts. >=20 > Dave > ________________________________________ > From: sacm on behalf of Romascanu, Dan (Dan) > > Sent: Tuesday, December 10, 2013 4:56:15 PM > To: sacm@ietf.org > Subject: Re: [sacm] IETF 89 - Working Group/BOF/IRTF Scheduling >=20 > It will be IETF-89, of course. >=20 >=20 >=20 > > -----Original Message----- > > From: Romascanu, Dan (Dan) > > Sent: Tuesday, December 10, 2013 5:53 PM > > To: sacm@ietf.org > > Subject: FW: IETF 89 - Working Group/BOF/IRTF Scheduling > > > > > > Hi, > > > > Scheduling for the IETF-88 meeting in London is now open. > > > > Our plan is to request one 2 hours meeting slot, as we had at IETF-88. > > Anybody believes that we need more, or less time? > > > > Also please send us your list of critical conflicts, beyond the > obvious. > > > > Thanks and Regards, > > > > Adam and Dan > > > > > > > > -----Original Message----- > > From: WGChairs [mailto:wgchairs-bounces@ietf.org] On Behalf Of IETF > > Agenda > > Sent: Tuesday, December 03, 2013 10:13 PM > > To: Working Group Chairs > > Cc: irsg@irtf.org > > Subject: IETF 89 - Working Group/BOF/IRTF Scheduling > > > > ----------------------------------------------------------------- > > 89th IETF - London, England > > Meeting Dates: March 2 - 7, 2014 > > ----------------------------------------------------------------- > > IETF meetings start Monday morning and run through Friday afternoon > > (13:30). > > > > We are accepting scheduling requests for all Working Groups, BOFs, and > > Research Groups starting today. The milestones and deadlines for > > scheduling-related activities are as follows: > > > > NOTE: cutoff dates are subject to change. > > > > - 2013-12-02 (Monday): Working Group and BOF scheduling begins. To > > request a Working Group session, use the IETF Meeting Session Request > > Tool. > > - 2014-01-17 (Friday): Cut-off date for requests to schedule Working > > Group meetings at UTC 23:59. To request a Working Group session, use > > the IETF Meeting Session Request Tool. > > - 2014-01-17 (Friday): Cut-off date for BOF proposal requests to Area > > Directors at UTC 23:59. To request a BOF, please see instructions on > > Requesting a BOF. > > - 2014-01-24 (Friday): Cut-off date for Area Directors to approve BOFs > > at UTC 23:59. > > - 2014-01-31 (Friday): Preliminary agenda published for comment. > > - 2014-02-03 (Monday): Cut-off date for requests to reschedule Working > > Group and BOF meetings UTC 23:59. > > - 2014-02-07 (Friday): Final agenda to be published. > > - 2014-02-17 (Monday): Draft Working Group agendas due by UTC 23:59, > > upload using IETF Meeting Materials Management Tool. > > - 2014-02-24 (Monday): Revised Working Group agendas due by UTC 23:59, > > upload using IETF Meeting Materials Management Tool. > > - 2014-03-28 (Friday): Proceedings submission cutoff date by UTC > > 23:59, upload using IETF Meeting Materials Management Tool. > > - 2014-04-18 (Friday): Proceedings submission corrections cutoff date > > by UTC 23:59, upload using IETF Meeting Materials Management Tool. > > > > Submitting Requests for Working Group and BOF Sessions > > > > Please submit requests to schedule your Working Group sessions using > > the "IETF Meeting Session Request Tool," a Web-based tool for > > submitting all of the information that the Secretariat requires to > > schedule your sessions. > > > > The URL for the tool is: > > > > https://pub.ietf.org/sreq/ > > > > Please send requests to schedule your BOF sessions to agenda@ietf.org. > > Please include the acronym of your BOF in the subject line of the > > message, and include all of the information specified in item (4) of > > "Requesting Meeting Sessions at IETF Meetings" in the body. (This > > document is included below.) > > > > Submitting Session Agendas > > > > For the convenience of meeting attendees, we ask that you submit the > > agendas for your Working Group sessions as early as possible. Draft > > Working Group agendas are due Monday, February 17th, 2014 at UTC > 23:59. > > Revised Working Group agendas are due no later than Monday, February > > 24th, 2014 at UTC 23:59. The proposed agenda for a BOF session should > > be submitted along with your request for a session. Please be sure to > > copy your Area Director on that message. > > > > Please submit the agendas for your Working Group sessions using the > > "IETF Meeting Materials Management Tool," a Web-based tool for making > > your meeting agenda, minutes, and presentation slides available to the > > community before, during, and after an IETF meeting. If you are a BOF > > chair, then you may use the tool to submit a revised agenda as well as > > other materials for your BOF once the BOF has been approved. > > > > The URL for the tool is: > > > > https://pub.ietf.org/proceedings/ > > > > Additional information about this tool is available at: > > > > http://www.ietf.org/instructions/meeting_materials_tool.html > > > > Agendas submitted via the tool will be available to the public on the > > "IETF Meeting Materials" webpage as soon as they are submitted. > > > > The URL for the "IETF 89 Meeting Materials" Web page is: > > > > https://datatracker.ietf.org/meeting/89/materials.html > > > > If you are a Working Group chair, then you already have accounts on > > the "IETF Meeting Session Request Tool" and the "IETF Meeting > > Materials Management Tool." The same User ID and password will work > > for both tools. If you are a BOF chair who is not also a Working > > Group chair, then you will be given an account on the "IETF Meeting > > Materials Management Tool" when your BOF has been approved. If you > > require assistance in using either tool, or wish to report a bug, then > > please send a message to: > > ietf-action@ietf.org. > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > For your convenience, comprehensive information on requesting meeting > > sessions for IETF 89 is below: > > > > 1. Requests to schedule Working Group sessions should be submitted > > using the "IETF Meeting Session Request Tool," a Web-based tool for > > submitting all of the information required by the Secretariat to > > schedule your sessions. The URL for the tool is: > > > > https://pub.ietf.org/sreq/ > > > > Instructions for using the tool are available at: > > > > http://www.ietf.org/instructions/session_request_tool_instruction.html > > > > If you require an account on this tool, or assistance in using it, > > then please send a message to ietf-action@ietf.org. If you are unable > > to use the tool, then you may send your request via e-mail to > > agenda@ietf.org, with a copy to the appropriate Area Director(s). > > > > Requests to schedule BOF sessions must be sent to agenda@ietf.org with > > a copy to the appropriate Area Director(s). > > > > When submitting a Working Group or BOF session request by e-mail, > > please include the Working Group or BOF acronym in the Subject line. > > > > 2. BOFs will NOT be scheduled unless the Area Director approves the > BOF. > > The proponents behind a BOF need to contact a relevant Area Director, > > preferably well in advance of the BOF approval deadline date. The AD > > needs to have the full name of the BOF, its acronym, suggested names > > of chairs, an agenda, full description of the BOF and the information > > covered in item 4. Please read RFC 5434 for instructions on how to > > drive a successful BOF effort. The approval depends on, for instance, > > Internet-Drafts and list discussion on the suggested topic. BOF agenda > > requests, if approved, will be submitted to the IETF Secretariat by > > the ADs. > > > > 3. A Working Group may request either one or two sessions. If your > > Working Group requires more than two sessions, then your request must > > be approved by an Area Director. Additional sessions will be > > assigned, based on availability, after Monday, February 3rd, 2014, the > > cut-off date for requests to reschedule a session. > > > > 4. You MUST provide the following information before a Working Group > > or BOF session will be scheduled: > > > > a. Working Group or BOF full name with acronym in brackets: > > > > b. AREA under which Working Group or BOF appears: > > > > c. CONFLICTS you wish to avoid, please be as specific as possible: > > > > d. Expected Attendance: > > > > e. Special requests: > > > > f. Number of sessions: > > > > g. Length of session: > > - 1 hour > > - 1 1/2 hours > > - 2 hours > > - 2 1/2 hours > > > > For more information on scheduling Working Group and BOF sessions, > > please refer to RFC 2418 (BCP 25), "IETF Working Group Guidelines and > > Procedures" (http://www.ietf.org/rfc/rfc2418.txt). > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > For your convenience please find here a list of the IETF Area > > Directors with their e-mail addresses: > > > > IETF Chair > > Jari Arkko > > > > Applications Area (app) > > Barry Leiba > > Pete Resnick > > > > Internet Area (int) > > Brian Haberman Ted Lemon > > > > > > Operations & Management Area (ops) > > Benoit Claise > > Joel Jaeggli > > > > Real-time Applications and Infrastructure Area (rai) Gonzalo Camarillo > > Richard Barnes > > > > Routing Area (rtg) > > Stewart Bryant > > Adrian Farrel > > > > Security Area (sec) > > Stephen Farrell Sean Turner > > > > > > Transport Area (tsv) > > Martin Stiemerling Spencer Dawkins > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > 88th IETF Meeting Attendance Numbers > > > > 6lo - 52 > > 6man - 143 > > 6tisch - 45 > > abfab - 20 > > alto - 35 > > appsawg/apparea - 138 > > aqm - 108 > > aqm (2nd session) - 45 > > avtcore - 51 > > avtext - 59 > > bfd - 17 > > bmwg - 19 > > ccamp - 49 > > ccamp (2nd session) - 44 > > cdni - 39 > > clue - 41 > > clue (2nd session) - 32 > > core - 62 > > core (2nd session) - 50 > > dhc - 59 > > dice - 65 > > dime - 23 > > dispatch - 55 > > dmm - 37 > > dnsop - 125 > > dnssd - 108 > > ecrit - 31 > > eman - 19 > > forces - 40 > > geonet (BoF) - 99 > > geopriv - 41 > > homenet - 156 > > httpauth - 43 > > httpbis - 89 > > httpbis (2nd session) - 127 > > i2rs - 223 > > iccrg (RG) - 68 > > icnrg (RG) - 43 > > idr - 90 > > igovupdate BoF - 220 > > insipid - 32 > > intarea (AG) - 98 > > ipfix - 23 > > ippm - 48 > > ipsecme - 27 > > IRTF Open Meeting - 100 > > isis - 58 > > jose - 42 > > json - 49 > > karp - 22 > > kitten - 23 > > l2vpn - 71 > > l3vpn - 65 > > lisp - 56 > > lmap - 52 > > lwig - 35 > > manet - 35 > > mboned - 25 > > mif - 41 > > mmusic - 69 > > mmusic (2nd session) - 53 > > mpls - 71 > > mpls (2nd session) - 72 > > mptcp - 45 > > mptcp (2nd session) - 70 > > ncrg (RG) - 33 > > netconf - 62 > > netext - 27 > > netmod - 69 > > nfsv4 - 16 > > nmrg (RG) - 35 > > nmrg (RG) (2nd session) - 17 > > ntp (combined with tictoc) - 32 > > nvo3 - 193 > > nwcrg (PRG) - 25 > > oauth - 38 > > opsawg/opsarea - 68 > > opsec - 48 > > ospf - 38 > > paws - 17 > > pce - 72 > > pcp - 30 > > perpass (BoF) - 313 > > pim - 24 > > ppsp - 12 > > precis - 32 > > pwe3 - 40 > > radext - 20 > > rfcform (BoF) - 52 > > rmcat - 60 > > rtcweb - 174 > > rtcweb (2nd session) - 188 > > rtgarea (AG) - 101 > > rtgwg - 118 > > saag (AG) - 148 > > sacm - 40 > > scim - 32 > > sdnrg (RG) - 259 > > sidr - 61 > > siprec - 31 > > softwire - 52 > > spring - 158 > > stir - 82 > > stir (2nd session) - 79 > > storm - 21 > > tcpm - 36 > > tictoc (combined with ntp) - 32 > > tls - 111 > > trill - 33 > > tsvarea (AG) - 153 > > tsvwg - 63 > > tsvwg (2nd session) - 47 > > v6ops - 135 > > v6ops (2nd session) - 92 > > weirds - 55 > > wpkops - 34 > > xmpp - 31 > > xrblock - 24 > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm From ietfdbh@comcast.net Tue Dec 10 12:03:17 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59E0A1AE20D for ; Tue, 10 Dec 2013 12:03:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4 X-Spam-Level: X-Spam-Status: No, score=-4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id buJ4CF_oLhQP for ; Tue, 10 Dec 2013 12:03:06 -0800 (PST) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:16]) by ietfa.amsl.com (Postfix) with ESMTP id 87F531AE024 for ; Tue, 10 Dec 2013 12:03:05 -0800 (PST) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta01.westchester.pa.mail.comcast.net with comcast id zvPq1m00516LCl051w30wG; Tue, 10 Dec 2013 20:03:00 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta06.westchester.pa.mail.comcast.net with comcast id zw2z1m0082yZEBF3Sw2zln; Tue, 10 Dec 2013 20:02:59 +0000 From: "ietfdbh" To: "'Ira McDonald'" , "'Michael Hammer'" References: <20131120225753.9031.68753.idtracker@ietfa.amsl.com> <528F23D0.3080504@sit.fraunhofer.de> <05BCCEB107AF88469B9F99783D47C1D6065E4769@CISEXCHANGE1.msisac.org.local> <025d01cef178$63f56840$2be038c0$@comcast.net> <9904FB1B0159DA42B0B887B7FA8119CA12952A08@AZ-FFEXMB04.global.avaya.com> <00C069FD01E0324C9FFCADF539701DB3BBF01B8D@sc9-ex2k10mb1.corp.yaanatech.com> <05BCCEB107AF88469B9F99783D47C1D6065EFE47@CISEXCHANGE1.msisac.org.local> <9904FB1B0159DA42B0B887B7FA8119CA129DBB1D@AZ-FFEXMB04.global.avaya.com> <4b451425cbec406d94fa1a82b32fa1ab@BLUPR09MB038.namprd09.prod.outlook.com> <018701cef544$9d2ce730$d786b590$@comcast.net> <05BCCEB107AF88469B9F99783D47C1D606 5F5476@CISEXCH ANGE1.msisac.org.local> <00C069FD01E0324C9FFCADF539701DB3BBF073B5@sc9-ex2k10mb1.corp.yaanatech.com> In-Reply-To: Date: Tue, 10 Dec 2013 15:02:57 -0500 Message-ID: <029b01cef5e2$d21d4270$7657c750$@comcast.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_029C_01CEF5B8.E94F77D0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQDqYHUjRqa6AdCybnAKjK8iZl6ZEgHRoRLuAd5OVZsCKr/+CgJ7lTzzAQ4/IcwBus0sYgFPhFmkAlHlbqECl4tgtQH1NBIcATnrWRYCSft4xQGV9CYpAwQU4gUCBE4dagHancyAApcqGFabB+1MoA== Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1386705780; bh=hO001ji9e3OPMTqWEYrICyfc+MMpjxEKsi0AMKxUGrU=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=KkcgA7FVaXEscComP0S7LTxs/kosXOrUKjgyRMUW2xzA/HCkHSLceK6n2D1TFnG0k pLSSIq5zfNHUl4A3OeBjZTjJxz8dhih/l2GPnRGsSU5X0ysuHlY665HYVAv3D3I5+W wsLotIBzeiiIBhF204OqXBQIpEOOvsYwfykoRQVR1r/sWfHJQA7mMB/H/nlslfAWpT fFy1aZ/9CXsTcT0M2hptbY63RTiQmO6TcWPFENvIC+o6f+TqPVZ6nDXzYKUNPSCG5m MsmUDfs0IBN6K7EhwaP2RZQ+PEuW4ImPeE17AQvuKTjw/4F6cLwy+sVLJC/jcafXwu bEYpBg984fdnA== Cc: Adam.Montville@cisecurity.org, david.waltermire@nist.gov, sacm@ietf.org Subject: Re: [sacm] FW: New Version Notification for draft-ietf-sacm-use-cases-05.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 20:03:17 -0000 This is a multipart message in MIME format. ------=_NextPart_000_029C_01CEF5B8.E94F77D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I looked at rfc2904 (AAA Framework) I notice that both User and user are used ;-) I see that "AAA Server" is often capitalized, whereas other uses of the term server are not capitalized: print server, authorization servers, RADIUS server, etc. But, even "AAA server" is often not capitalized (sections 4.3, 6.1, 7, 8, 9) So, RFC2904 may not be good example of preferred usage. The RFC Editor guidelines call for consistency in capitalization across related documents. Our charter calls for the reuse of existing standards where possible. So I asked myself, do potential related documents (e.g., SNMP, NETCONF, NEA, etc.) use these terms (end-point, operator, administrator, and application), and do they capitalize them? RFC 3411 (SNMP Architecture) doesn't use them much, but when used they are in lower case. Application is used, but it is only capitalized when referring to a specific type of application, such as a "Command Responder Application". (and title and TOC and first word in a sentence of course), otherwise it is lowercase. RFC4741 (NETCONF) uses application in lowercase; they use administrator in lowercase. They don't use end-point or operator. RFC5209 (NEA Overview) uses application, administrator, operator in lowercase, except one use of "Enterprise Administrator". They don't use end-point. David Harrington ietfdbh@comcast.net +1-603-828-1401 From: Ira McDonald [mailto:blueroofmusic@gmail.com] Sent: Tuesday, December 10, 2013 10:01 AM To: Michael Hammer Cc: Adam.Montville@cisecurity.org; ietfdbh@comcast.net; david.waltermire@nist.gov; sacm@ietf.org Subject: Re: [sacm] FW: New Version Notification for draft-ietf-sacm-use-cases-05.txt Hi, Actor roles are titlecase in IETF AAA Framework (RFC 2904). Cheers, - Ira Ira McDonald (Musician / Software Architect) Co-Chair - TCG Trusted Mobility Solutions WG Chair - Linux Foundation Open Printing WG Secretary - IEEE-ISTO Printer Working Group Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG IETF Designated Expert - IPP & Printer MIB Blue Roof Music / High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto: blueroofmusic@gmail.com Winter 579 Park Place Saline, MI 48176 734-944-0094 Summer PO Box 221 Grand Marais, MI 49839 906-494-2434 On Tue, Dec 10, 2013 at 9:50 AM, Michael Hammer wrote: If they are formal terms defined in a document, I don't think capitalization is a problem. How else do you distinguish them from randomly chosen English words? After all the whole reason to distinguish MUST versus must is just that. But, might be good to clarify that with Editor. Mike From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Adam Montville Sent: Tuesday, December 10, 2013 7:25 AM To: ietfdbh; 'Ira McDonald'; 'Waltermire, David A.' Cc: sacm@ietf.org Subject: Re: [sacm] FW: New Version Notification for draft-ietf-sacm-use-cases-05.txt Thanks for pointing that out, David. This might be stylistic in some ways, but these aren't titles they are roles. From that perspective we could treat them as proper nouns, which would technically warrant capitalization. But, better to stick with what the Editor would prefer, I think. Adam _____ From: sacm [sacm-bounces@ietf.org] on behalf of ietfdbh [ietfdbh@comcast.net] Sent: Monday, December 09, 2013 7:08 PM To: 'Ira McDonald'; 'Waltermire, David A.' Cc: sacm@ietf.org Subject: Re: [sacm] FW: New Version Notification for draft-ietf-sacm-use-cases-05.txt Hi, I'd have to go look up a reference, but I believe the rfc editor considers it bad form to capitalize things that don't need to be capitalized. David Harrington ietfdbh@comcast.net +1-603-828-1401 From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Ira McDonald Sent: Monday, December 09, 2013 3:35 PM To: Waltermire, David A.; Ira McDonald Cc: sacm@ietf.org Subject: Re: [sacm] FW: New Version Notification for draft-ietf-sacm-use-cases-05.txt Hi Dave, I'm not sure if there's consensus about this, but I suggest that the current lowercase "operator", "administrator", etc. (e.g., in 2.1.1) should be titlecase (first letter capitalized). Also that a new section 1.1 Actors be added that defines these actor terms (one to three sentences each about what are typical actions or responsibilities for each actor). >From the original Design Goals for IPP (RFC 2567) here are some admittedly printing-specific definitions, but they give the right flavor: "3.1. END-USER An end-user of a printer accepting jobs through the Internet is one of the roles in which humans act. The end-user is the person that will submit a job to be printed on the printer. The wants and needs of the end-user are broken down into six categories: finding/locating a printer, creating a local instance of a printer, viewing printer status, viewing printer capabilities, submitting a print job, viewing print job status, altering the attributes of a print job. 3.2. OPERATOR An operator of a printer accepting jobs through the Internet is one of the roles in which humans act. The operator has the responsibility of monitoring the status of the printer as well as managing and controlling the jobs at the device. These responsibilities include but are not limited to the replenishing of supplies (ink, toner, paper, etc.), the clearing of minor errors (paper jams, etc.) and the re-prioritization of end-user jobs. Operator wants and needs will not be addressed by V1.0 of the protocol. The wants and needs of the operator include all those of the end-user but may include additional privileges. For example, an operator may be able to view all print jobs on a printer while the end-user might only be able to see his own jobs. 3.3. ADMINISTRATOR An administrator of a printer accepting jobs through the Internet is one of the roles in which humans act. The administrator has the responsibility of creating the printer instances and controlling the authorization of other end-users and operators. Administrator wants and needs will not be addressed by V1.0 of the protocol. The wants and needs of the administrator include all those of the end-user and, in some environments, some or all of those of the operator. Minimally, the administrator must also have the tools, programs, utilities and supporting protocols available to be able to: - create an instance of a printer - create, edit and maintain the list of authorized end-users - create, edit and maintain the list of authorized operators - create, edit and maintain the list of authorized administrators - create, customize, change or otherwise alter the manner in which the status capabilities and other information about printers and jobs are presented - create, customize, or change other printer or job features - administrate billing or other charge-back mechanisms - create sets of defaults - create sets of capabilities The administrator must have the capability to perform all the above tasks locally or remotely to the printer." >From later IPP Get-Notifications (RFC 3997), here are much shorter definitions: "2.1. Job-Submitting End User A human end user who submits a print job to an IPP Printer. This person may or may not be within the same security domain as the Printer. This person may or may not be geographically near the printer. 2.2. Administrator A human user who established policy for and configures the print system. 2.3. Operator A human user who carries out the policy established by the Administrator and controls the day-to-day running of the print system." As Nancy said, we need also: Application, System. Cheers, - Ira Ira McDonald (Musician / Software Architect) Co-Chair - TCG Trusted Mobility Solutions WG Chair - Linux Foundation Open Printing WG Secretary - IEEE-ISTO Printer Working Group Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG IETF Designated Expert - IPP & Printer MIB Blue Roof Music / High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto: blueroofmusic@gmail.com Winter 579 Park Place Saline, MI 48176 734-944-0094 Summer PO Box 221 Grand Marais, MI 49839 906-494-2434 On Mon, Dec 9, 2013 at 3:12 PM, Waltermire, David A. wrote: +1. I too like this approach. This has been a good discussion. To direct this dialog towards actionable changes to the use cases draft, is there specific draft text that should be updated to make the roles and their relevance to a use case or usage scenario more clear? Thanks, Dave From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Kent_Landfield@McAfee.com Sent: Sunday, December 08, 2013 12:20 PM To: sacm@ietf.org Subject: Re: [sacm] FW: New Version Notification for draft-ietf-sacm-use-cases-05.txt +1 I like the terminology Ira and Adam have suggested. Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: , "Dan (Dan)" Date: Sunday, December 8, 2013 7:43 AM To: Adam Montville , Ira McDonald , Michael Hammer Cc: "dbharrington@comcast.net" , David Waltermire , "sacm@ietf.org" , "henk.birkholz@sit.fraunhofer.de" Subject: Re: [sacm] FW: New Version Notification for draft-ietf-sacm-use-cases-05.txt +1 Dan Speaking as contributor - better to say it clearly if there are reasons to wonder From: Adam Montville [mailto:Adam.Montville@cisecurity.org] Sent: Friday, December 06, 2013 3:12 AM To: Ira McDonald; Michael Hammer Cc: Romascanu, Dan (Dan); dbharrington@comcast.net; david.waltermire@nist.gov; henk.birkholz@sit.fraunhofer.de; sacm@ietf.org Subject: RE: [sacm] FW: New Version Notification for draft-ietf-sacm-use-cases-05.txt I like this set of terminology. End User, Operator, Administrator, and Application. Then, Application can potentially have further specification as we move forward. For example, Analysis Application, Acquisition Application, and so on. Whatever we choose, I would prefer to choose terms that we can easily use consistently. Adam (I'm assuming, but perhaps shouldn't, that when I comment like this it's as a contributor) _____ From: Ira McDonald [blueroofmusic@gmail.com] Sent: Thursday, December 05, 2013 8:48 AM To: Michael Hammer Cc: dromasca@avaya.com; dbharrington@comcast.net; david.waltermire@nist.gov; Adam Montville; henk.birkholz@sit.fraunhofer.de; sacm@ietf.org Subject: Re: [sacm] FW: New Version Notification for draft-ietf-sacm-use-cases-05.txt Hi, My two cents - End User, Operator, and Administrator are quite distinct roles of actors in standards from many SDOs - they have inherently distinct default privileges - using these common role terms consistently would make SACM use cases more accessible to non-participants in the SACM WG. BTW - there are a few other roles of actors that should probably be used in SACM use cases, e.g., Application - although tthat's a slippery slope, because normal applications (browsers, email readers, etc.) have very different privileges and responsibilities from security-specific applications (MDM agents, anti-virus scanners, etc.). Cheers, - Ira Ira McDonald (Musician / Software Architect) Co-Chair - TCG Trusted Mobility Solutions WG Chair - Linux Foundation Open Printing WG Secretary - IEEE-ISTO Printer Working Group Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG IETF Designated Expert - IPP & Printer MIB Blue Roof Music / High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto: blueroofmusic@gmail.com Winter 579 Park Place Saline, MI 48176 734-944-0094 Summer PO Box 221 Grand Marais, MI 49839 906-494-2434 On Thu, Dec 5, 2013 at 9:12 AM, Michael Hammer wrote: Actor connotes human to me. What would be wrong with using client or server if asymmetric, or user agent if peering? With adjectives to differentiate types. Mike -----Original Message----- From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Thursday, December 05, 2013 4:52 AM To: David Harrington; 'Waltermire, David A.'; 'Adam Montville'; 'Henk Birkholz'; sacm@ietf.org Subject: Re: [sacm] FW: New Version Notification for draft-ietf-sacm-use-cases-05.txt I share DBH's concern. There may be significant differences in workflows and interface requirements between systems (networks, devices) and humans vs. systems (networks, devices) and applications. There may be significant differences if the humans are operators or end-users. Using one term (say 'actor') for all may create ambiguities. I am not sure that I understand the advantages of the proposed abstraction. Dan (speaking as contributor) > -----Original Message----- > From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of David Harrington > Sent: Thursday, December 05, 2013 7:11 AM > To: 'Waltermire, David A.'; 'Adam Montville'; 'Henk Birkholz'; > sacm@ietf.org > Subject: Re: [sacm] FW: New Version Notification for draft-ietf-sacm- > use-cases-05.txt > > Hi, > > Using actor concerns me. > I find it important to understand whether some content needs to be > parsed by a human (with our wonderful ability to parse), or a computer > application (which is bound by a set of rules, and has great difficulty > when the content is not consistent with the rules). > > Around 2003, the operators made it clear that CLIs were difficult to > work with, because queries would return information in variable formats. > While humans might be able to parse the output that might change from > vendor to vendor, model to model, and release to release, tools had > significant difficulty due to the lack of standardization. Operators > could try to deal with the lack of standardization by writing expect > scripts, but they would need to be updated constantly because what > worked for one release of a product might not be the same in the next > release. > Humans can parse variable syntax, such as the natural language content > of syslog, but applications can have a hard time. > > I think is very important to know whether we are designing something for > human consumption or for computer consumption. > "Actor" doesn't provide enough differentiation to know how to design our > solutions. > > David Harrington > dbharrington@comcast.net > +1-603-828-1401 > > > -----Original Message----- > > From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Waltermire, > > David A. > > Sent: Wednesday, December 04, 2013 8:54 PM > > To: Adam Montville; Henk Birkholz; sacm@ietf.org > > Subject: Re: [sacm] FW: New Version Notification for > > draft-ietf-sacm-use- cases-05.txt > > > > Comments inline. > > > > > -----Original Message----- > > > From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Adam > > > Montville > > > Sent: Wednesday, December 04, 2013 8:38 PM > > > To: Henk Birkholz; sacm@ietf.org > > > Subject: Re: [sacm] FW: New Version Notification for > draft-ietf-sacm-use- > > > cases-05.txt > > > > > > Something I've found helpful in the past is to abstract a bit > > > further > from > > > "user", "operator", "application" and simply reference all of them > > > at > once > > > with the term "actor". > > > > Are we ok with the change to using actor? The current usage of "user", > > "operator", "application" (specifically the last two) was suggested a > while > > back to align with IETF terminology. Does use of "actor" to reference > > all > three > > concepts raise any concerns? > > > > > I also believe that listing *potential* acquisition methods is > > > useful in > at least > > > the following way: Including a multitude of acquisition methods > > > clearly > > signals > > > our intent of finding information where it already exists, while not > > > necessarily precluding our ability to *get* information when > > > information does not exist. > > > > Adam, would you or Henk provide some example acquisition methods for > > discussion? > > > > > Finally, I, too, like the notion of a work-flow scenario. I don't > > > want > to be > > the > > > one drawing a process diagram in an RFC, though. ;-) > > > > How would this differ from the workflow scenario text in section 2? > > > > Are you suggesting representing this text in a visual form? If so, > > would anyone like to make a contribution of some ascii art? > > > > > awm > > > ________________________________________ > > > From: sacm [sacm-bounces@ietf.org] on behalf of Henk Birkholz > > > [henk.birkholz@sit.fraunhofer.de] > > > Sent: Friday, November 22, 2013 3:27 AM > > > To: sacm@ietf.org > > > Subject: Re: [sacm] FW: New Version Notification for > draft-ietf-sacm-use- > > > cases-05.txt > > > > > > Regarding the first two question in section 2: > > > > > > 1.) Security automation today often supports the user/operator, I > think. > > > There are cases a security-process can be fully automated, of > > > course, > and in > > > order to manage the sheer amount of security related system events > > > automation is essential, but it seems to me that the complexity and > > > heterogeneity of root-causes (that might trigger the work-flow) make > > > the inclusion of a user/operator necessary. > > > > > > 2.) To include acquisition methods can provide an intuitive insight > about the > > > scope and intend of the endpoint posture assessment domain, I think. > > > On one hand, that might bloat the use-case document a bit (and maybe > > renders > > > the title "sacm use cases" too specific?). On the other hand, I like > > > the inclusion of a work-flow scenario and I think it is a good place > > > to > highlight > > > acquisition methods. > > > > > > - Henk > > > > > > On 11/21/2013 12:27 AM, Waltermire, David A. wrote: > > > > I just posted an updated use case draft based on the editorial > sessions > > > during the IETF 88 meeting in Vancouver, BC, Canada. My thanks to > > > all > that > > > provided input. > > > > > > > > I used the word version that we edited as a starting point. Here > > > > is > what I > > > did: > > > > > > > > - I worked through the use cases we planned to remove and made > > > > sure > > to > > > merge in any concepts that would be lost. If you submitted a > > > previous > use > > > case that was removed, please double check that I didn't miss > anything. > > > > - I broke up "Endpoint Identification and Assessment" into 3 > > > > distinct > and > > > somewhat separable use cases: "Endpoint Identification and > > > Assessment Planning", "Endpoint Posture Attribute Value Collection", > > > "Posture Evaluation". Please let me know what you think about this > change. > > > > - Addressed some aspects of the discussion thread based on the > > > > working > > > session changes. Please provide any suggested edits for aspects that > > > I > > might > > > have missed or got wrong. > > > > > > > > The rest of the changes can be found in the draft's change log. > > > > > > > > If possible, I'd like to get to a fairly stable place with this > > > > draft > in the next > > > revision or two to allow for progress to be made on the > > > requirements. In addition to the embedded questions in the document, > > > I'd like to focus on > > the > > > following questions: > > > > > > > > Is the draft approachable for a newcomer to the effort? Do you see > > > > the > > > updated use case structure as an improvement? > > > > Does this draft paint a complete enough picture? Are we missing > > > > any > > > important concepts? > > > > Is there anything you can't live with? > > > > > > > > I hope to release at least one or two more updates to this draft > within the > > > next few weeks before the holidays catch up on us. I know everyone > > > is busy; timely comments are appreciated to allow for a quick > > > turnaround on the next revision. > > > > > > > > Thanks, > > > > Dave > > > > > > > > -----Original Message----- > > > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > > > Sent: Wednesday, November 20, 2013 5:58 PM > > > > To: Waltermire, David A.; David Harrington > > > > Subject: New Version Notification for > > > > draft-ietf-sacm-use-cases-05.txt > > > > > > > > > > > > A new version of I-D, draft-ietf-sacm-use-cases-05.txt has been > > > successfully submitted by David Waltermire and posted to the IETF > > > repository. > > > > > > > > Filename: draft-ietf-sacm-use-cases > > > > Revision: 05 > > > > Title: Endpoint Security Posture Assessment - > Enterprise Use > > Cases > > > > Creation date: 2013-11-20 > > > > Group: sacm > > > > Number of pages: 24 > > > > URL: > http://www.ietf.org/internet-drafts/draft-ietf-sacm-use- > > cases- > > > 05.txt > > > > Status: > http://datatracker.ietf.org/doc/draft-ietf-sacm-use-cases > > > > Htmlized: > http://tools.ietf.org/html/draft-ietf-sacm-use-cases-05 > > > > Diff: > http://www.ietf.org/rfcdiff?url2=draft-ietf-sacm-use-cases-05 > > > > > > > > Abstract: > > > > This memo documents a sampling of use cases for securely > aggregating > > > > configuration and operational data and evaluating that data to > > > > determine an organization's security posture. From these > operational > > > > use cases, we can derive common functional capabilities and > > > > requirements to guide development of vendor-neutral, > interoperable > > > > standards for aggregating and evaluating data relevant to > security > > > > posture. > > > > > > > > > > > > > > > > > > > > Please note that it may take a couple of minutes from the time of > > > submission until the htmlized version and diff are available at > tools.ietf.org. > > > > > > > > The IETF Secretariat > > > > > > > > _______________________________________________ > > > > sacm mailing list > > > > sacm@ietf.org > > > > https://www.ietf.org/mailman/listinfo/sacm > > > > > > > > > > > > > > > > ... > > > > > > . . . > > > _______________________________________________ > > > sacm mailing list > > > sacm@ietf.org > > > https://www.ietf.org/mailman/listinfo/sacm > > _______________________________________________ > > sacm mailing list > > sacm@ietf.org > > https://www.ietf.org/mailman/listinfo/sacm > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm ... This message and attachments may contain confidential information. If it appears that this message was sent to you by mistake, any retention, dissemination, distribution or copying of this message and attachments is strictly prohibited. Please notify the sender immediately and permanently delete the message and any attachments. . . . _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm ... . . . ------=_NextPart_000_029C_01CEF5B8.E94F77D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I looked at rfc2904 (AAA Framework)

 

I notice that both User and user are used ;-)

 

I see that “AAA Server” is often capitalized, whereas = other uses of the term server are not capitalized: print server, = authorization servers, RADIUS server, etc.

But, even “AAA server” is often not capitalized (sections = 4.3, 6.1, 7, 8, 9)

So, RFC2904 may not be good example of preferred = usage.

 

 

The RFC Editor guidelines call for consistency in capitalization = across related documents.

Our charter calls for the reuse of existing standards where = possible.

So I asked myself, do potential related documents (e.g., SNMP, = NETCONF, NEA, etc.) use these terms (end-point, operator, administrator, = and application), and do they capitalize them?

 

RFC 3411 (SNMP Architecture) doesn’t use them much, but when = used they are in lower case.

Application is used, but it is only capitalized when referring to a = specific type of application, such as a “Command Responder = Application”.

(and title and TOC and first word in a sentence of course), = otherwise it is lowercase.

 

RFC4741 (NETCONF) uses application in lowercase; they use = administrator in lowercase. They don’t use end-point or = operator.

 

RFC5209 (NEA Overview) uses application, administrator, operator in = lowercase, except one use of “Enterprise = Administrator”.

They don’t use end-point.

 

David Harrington

ietfdbh@comca= st.net

+1-603-828-1401

From:= = Ira McDonald [mailto:blueroofmusic@gmail.com]
Sent: Tuesday, = December 10, 2013 10:01 AM
To: Michael Hammer
Cc: = Adam.Montville@cisecurity.org; ietfdbh@comcast.net; = david.waltermire@nist.gov; sacm@ietf.org
Subject: Re: [sacm] = FW: New Version Notification for = draft-ietf-sacm-use-cases-05.txt

 

Hi,

Actor roles are = titlecase in IETF AAA Framework (RFC 2904).

Cheers,

- Ira


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

 

On Tue, Dec 10, 2013 at 9:50 AM, Michael Hammer <michael.hammer@yaanatech.com> = wrote:

If they are formal terms defined in a document, I don’t think = capitalization is a problem.

How else do you distinguish them from randomly chosen English = words?

After all the whole reason to distinguish MUST versus must is just = that.

But, might be good to clarify that with = Editor.

 

Mike

 

 

From:= = sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Adam = Montville
Sent: Tuesday, December 10, 2013 7:25 = AM
To: ietfdbh; 'Ira McDonald'; 'Waltermire, David = A.'


Cc: = sacm@ietf.org
Subject: Re: [sacm] FW: = New Version Notification for = draft-ietf-sacm-use-cases-05.txt

 <= /o:p>

Thanks for = pointing that out, David.  This might be stylistic in some ways, = but these aren't titles they are roles.  From that perspective we = could treat them as proper nouns, which would technically warrant = capitalization.  But, better to stick with what the Editor would = prefer, I think.

 

Adam<= o:p>

 

From:= = sacm [sacm-bounces@ietf.org] on behalf of ietfdbh [ietfdbh@comcast.net]
Sent: Monday, = December 09, 2013 7:08 PM
To: 'Ira McDonald'; 'Waltermire, = David A.'
Cc: sacm@ietf.org
Subject: Re: [sacm] FW: = New Version Notification for = draft-ietf-sacm-use-cases-05.txt

Hi,

 

I’d have to go look up a reference, but I believe the rfc = editor considers it bad form to capitalize things that don’t need = to be capitalized.

 

 

David Harrington

ietfdbh@comca= st.net

+1-603-828-1401

From:= = sacm [mailto:sacm-bounces@ietf.org] On Behalf Of = Ira McDonald
Sent: Monday, December 09, 2013 3:35 = PM
To: Waltermire, David A.; Ira McDonald
Cc: sacm@ietf.org
Subject: Re: [sacm] FW: = New Version Notification for = draft-ietf-sacm-use-cases-05.txt

 <= /o:p>

Hi = Dave,

I'm not = sure if there's consensus about this, but I suggest that the = current

lowercase = "operator", "administrator", etc. (e.g., in 2.1.1) = should be

titlecase (first = letter capitalized).

Also that a new = section 1.1 Actors be added that defines these actor
terms (one to = three sentences each about what are typical actions = or
responsibilities for each actor).

From the original = Design Goals for IPP (RFC 2567) here are some
admittedly = printing-specific definitions, but they give the right = flavor:

"3.1. END-USER

   An end-user of a = printer accepting jobs through the Internet is one
   of = the roles in which humans act.  The end-user is the person = that
   will submit a job to be printed on the = printer.

   The wants and needs of the end-user are = broken down into six
   categories: finding/locating a = printer, creating a local instance of
   a printer, viewing = printer status, viewing printer capabilities,
   submitting = a print job, viewing print job status, altering the
   = attributes of a print job.

3.2. OPERATOR

   An = operator of a printer accepting jobs through the Internet is = one
   of the roles in which humans act.  The operator = has the
   responsibility of monitoring the status of the = printer as well as
   managing and controlling the jobs at = the device.  These
   responsibilities include but are = not limited to the replenishing of
   supplies (ink, toner, = paper, etc.), the clearing of minor errors
   (paper jams, = etc.) and the re-prioritization of end-user jobs.
   = Operator wants and needs will not be addressed by V1.0 of = the
   protocol.

   The wants and needs of = the operator include all those of the end-user
   but may = include additional privileges.  For example, an operator = may
   be able to view all print jobs on a printer while = the end-user might
   only be able to see his own = jobs.

3.3. ADMINISTRATOR

   An administrator of = a printer accepting jobs through the Internet is
   one of = the roles in which humans act.  The administrator has = the
   responsibility of creating the printer instances and = controlling the
   authorization of other end-users and = operators.  Administrator wants
   and needs will not = be addressed by V1.0 of the protocol.

   The wants and = needs of the administrator include all those of the
   = end-user and, in some environments, some or all of those of = the
   operator.  Minimally, the administrator must = also have the tools,
   programs, utilities and supporting = protocols available to be able to:

   - create an = instance of a printer
   - create, edit and maintain the = list of authorized end-users
   - create, edit and maintain = the list of authorized operators
   - create, edit and = maintain the list of authorized
     = administrators
   - create, customize, change or otherwise = alter the manner in
     which the status = capabilities and other information about = printers
     and jobs are = presented
   - create, customize, or change other printer = or job features
   - administrate billing or other = charge-back mechanisms
   - create sets of = defaults
   - create sets of = capabilities

   The administrator must have the = capability to perform all the above
   tasks locally or = remotely to the printer."

From later = IPP Get-Notifications (RFC 3997), here are much = shorter

definitions:
"2.1.  Job-Submitting End User

   A human = end user who submits a print job to an IPP Printer.  = This
   person may or may not be within the same security = domain as the
   Printer.  This person may or may not = be geographically near the
   printer.

2.2.  = Administrator

   A human user who established policy = for and configures the print
   system.

2.3.  = Operator

   A human user who carries out the policy = established by the
   Administrator and controls the = day-to-day running of the print
   = system."

As Nancy said, we = need also:  Application, System.

Cheers,=

- = Ira


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

 <= /p>

On Mon, Dec = 9, 2013 at 3:12 PM, Waltermire, David A. <david.waltermire@nist.gov> = wrote:

+1. I too like this approach. This has been a good = discussion.

 

To direct this dialog towards actionable changes to the use cases = draft, is there specific draft text that should be updated to make the = roles and their relevance to a use case or usage scenario more = clear?

 

Thanks,

Dave

 

From:= = sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Kent_Landfield@McAfee.com
Sent: Sunday, = December 08, 2013 12:20 PM


To: sacm@ietf.org
Subject: Re: [sacm] FW: = New Version Notification for = draft-ietf-sacm-use-cases-05.txt

 <= /o:p>

+1

 <= /o:p>

I like the = terminology Ira and Adam have suggested.

 <= /o:p>

= Kent Landfield=

McAfee = | An Intel Company
Direct: +1.972.963.7096 
Mobile: +1.817.637.8026
Web: www.mcafee.com

 <= /o:p>

From: = <Romasca= nu>, "Dan (Dan)" <dromasca@avaya.com>
Date: Sunday, = December 8, 2013 7:43 AM
To: Adam Montville <Adam.Montville@cisecurity.org>, Ira McDonald = <blueroofmusic@gmail.com>, Michael Hammer <michael.hammer@yaanatech.com>
Cc: = "dbharrington@comcast.net" <dbharrington@comcast.net>, David Waltermire = <david.waltermire@nist.gov>, "sacm@ietf.org" = <sacm@ietf.org>, "henk.birkholz@sit.fraunhofer.de" <henk.birkholz@sit.fraunhofer.de>
Subject: = Re: [sacm] FW: New Version Notification for = draft-ietf-sacm-use-cases-05.txt

 <= /o:p>

+1

 

Dan

 

Speaking as contributor – better to say it clearly if there are = reasons to wonder

 

 

From:= = Adam Montville [mailto:Adam.Montville@cisecurity.org] =
Sent: Friday, December 06, 2013 3:12 AM
To: Ira = McDonald; Michael Hammer
Cc: Romascanu, Dan (Dan); dbharrington@comcast.net; david.waltermire@nist.gov; henk.birkholz@sit.fraunhofer.de; sacm@ietf.org
Subject: RE: [sacm] FW: = New Version Notification for = draft-ietf-sacm-use-cases-05.txt

 <= /o:p>

I like this = set of terminology.  End User, Operator, Administrator, and = Application.  Then, Application can potentially have further = specification as we move forward.  For example, Analysis = Application, Acquisition Application, and so on.   =

 

Whatever we = choose, I would prefer to choose terms that we can easily use = consistently. 

 

Adam<= o:p>

 

(I'm = assuming, but perhaps shouldn't, that when I comment like this it's as a = contributor)

 

From:= = Ira McDonald [blueroofmusic@gmail.com]
Sent: Thursday, = December 05, 2013 8:48 AM
To: Michael Hammer
Cc: dromasca@avaya.com; dbharrington@comcast.net; david.waltermire@nist.gov; Adam Montville; henk.birkholz@sit.fraunhofer.de; sacm@ietf.org
Subject: Re: [sacm] FW: = New Version Notification for = draft-ietf-sacm-use-cases-05.txt

Hi,

=

My two = cents - End User, Operator, and Administrator are quite = distinct

roles of = actors in standards from many SDOs - they have = inherently

distinct = default privileges - using these common role terms = consistently

would make SACM = use cases more accessible to non-participants in
the SACM = WG.

BTW - there = are a few other roles of actors that should probably = be

used in = SACM use cases, e.g., Application - although tthat's a = slippery

slope, = because normal applications (browsers, email readers, = etc.)

have very = different privileges and responsibilities from = security-specific

applications (MDM = agents, anti-virus scanners, etc.).

Cheers,=

- = Ira


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

 <= /p>

On Thu, Dec = 5, 2013 at 9:12 AM, Michael Hammer <michael.hammer@yaanatech.com> = wrote:

Actor = connotes human to me.

What would be wrong with using client or = server if asymmetric, or user agent
if peering?
With adjectives to = differentiate types.

Mike



----= -Original Message-----
From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Romascanu, Dan = (Dan)
Sent: Thursday, December 05, 2013 4:52 AM
To: David = Harrington; 'Waltermire, David A.'; 'Adam Montville'; = 'Henk
Birkholz'; sacm@ietf.org
Subject: Re: [sacm] FW: New = Version Notification for
draft-ietf-sacm-use-cases-05.txt

I = share DBH's concern. There may be significant differences in workflows = and
interface requirements between systems (networks, devices) and = humans vs.
systems (networks, devices) and applications. There may be = significant
differences if the humans are operators or end-users. = Using one term (say
'actor') for all may create ambiguities. I am not = sure that I understand the
advantages of the proposed = abstraction.

Dan
(speaking as contributor)


> = -----Original Message-----
> From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of David = Harrington
> Sent: Thursday, December 05, 2013 7:11 AM
> To: = 'Waltermire, David A.'; 'Adam Montville'; 'Henk Birkholz';
> sacm@ietf.org
> Subject: Re: [sacm] FW: New = Version Notification for draft-ietf-sacm-
> = use-cases-05.txt
>
> Hi,
>
> Using actor = concerns me.
> I find it important to understand whether some = content needs to be
> parsed by a human (with our wonderful = ability to parse), or a computer
> application (which is bound by = a set of rules, and has great difficulty
> when the content is not = consistent with the rules).
>
> Around 2003, the operators = made it clear that CLIs were difficult to
> work with, because = queries would return information in variable formats.
> While = humans might be able to parse the output that might change from
> = vendor to vendor, model to model, and release to release, tools = had
> significant difficulty due to the lack of standardization. = Operators
> could try to deal with the lack of standardization by = writing expect
> scripts, but they would need to be updated = constantly because what
> worked for one release of a product = might not be the same in the next
> release.
> Humans can = parse variable syntax, such as the natural language content
> of = syslog, but applications can have a hard time.
>
> I think = is very important to know whether we are designing something for
> = human consumption or for computer consumption.
> "Actor" = doesn't provide enough differentiation to know how to design our
> = solutions.
>
> David Harrington
> dbharrington@comcast.net
> +1-603-828-1401
>
> > -----Original = Message-----
> > From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of = Waltermire,
> > David A.
> > Sent: Wednesday, December = 04, 2013 8:54 PM
> > To: Adam Montville; Henk Birkholz; sacm@ietf.org
> > Subject: Re: [sacm] FW: = New Version Notification for
> > draft-ietf-sacm-use- = cases-05.txt
> >
> > Comments inline.
> = >
> > > -----Original Message-----
> > > = From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Adam
> = > > Montville
> > > Sent: Wednesday, December 04, 2013 = 8:38 PM
> > > To: Henk Birkholz; sacm@ietf.org
> > > Subject: Re: = [sacm] FW: New Version Notification for
> = draft-ietf-sacm-use-
> > > cases-05.txt
> > = >
> > > Something I've found helpful in the past is to = abstract a bit
> > > further
> from
> > > = "user", "operator", "application" and = simply reference all of them
> > > at
> once
> = > > with the term "actor".
> >
> > Are = we ok with the change to using actor? The current usage of = "user",
> > "operator", = "application" (specifically the last two) was suggested = a
> while
> > back to align with IETF terminology. Does = use of "actor" to reference
> > all
> = three
> > concepts raise any concerns?
> >
> = > > I also believe that listing *potential* acquisition methods = is
> > > useful in
> at least
> > > the = following way: Including a multitude of acquisition methods
> > = > clearly
> > signals
> > > our intent of = finding information where it already exists, while not
> > > = necessarily precluding our ability to *get* information when
> = > > information does not exist.
> >
> > Adam, = would you or Henk provide some example acquisition methods for
> = > discussion?
> >
> > > Finally, I, too, like = the notion of a work-flow scenario.  I don't
> > > = want
> to be
> > the
> > > one drawing a = process diagram in an RFC, though. ;-)
> >
> > How = would this differ from the workflow scenario text in section 2?
> = >
> > Are you suggesting representing this text in a visual = form? If so,
> > would anyone like to make a contribution of = some ascii art?
> >
> > > awm
> > > = ________________________________________
> > > From: sacm = [sacm-bounces@ietf.org] on behalf of Henk = Birkholz
> > > [henk.birkholz@sit.fraunhofer.de]
> > > = Sent: Friday, November 22, 2013 3:27 AM
> > > To: sacm@ietf.org
> > > Subject: Re: = [sacm] FW: New Version Notification for
> = draft-ietf-sacm-use-
> > > cases-05.txt
> > = >
> > > Regarding the first two question in section = 2:
> > >
> > > 1.) Security automation today = often supports the user/operator, I
> think.
> > > = There are cases a security-process can be fully automated, of
> = > > course,
> and in
> > > order to manage the = sheer amount of security related system events
> > > = automation is essential, but it seems to me that the complexity = and
> > > heterogeneity of root-causes (that might trigger = the work-flow) make
> > > the inclusion of a user/operator = necessary.
> > >
> > > 2.) To include = acquisition methods can provide an intuitive insight
> about = the
> > > scope and intend of the endpoint posture = assessment domain, I think.
> > > On one hand, that might = bloat the use-case document a bit (and maybe
> > = renders
> > > the title "sacm use cases" too = specific?). On the other hand, I like
> > > the inclusion of = a work-flow scenario and I think it is a good place
> > > = to
> highlight
> > > acquisition methods.
> > = >
> > > - Henk
> > >
> > > On = 11/21/2013 12:27 AM, Waltermire, David A. wrote:
> > > > = I just posted an updated use case draft based on the editorial
> = sessions
> > > during the IETF 88 meeting in Vancouver, BC, = Canada. My thanks to
> > > all
> that
> > = > provided input.
> > > >
> > > > I = used the word version that we edited as a starting point. Here
> = > > > is
> what I
> > > did:
> > = > >
> > > > - I worked through the use cases we = planned to remove and made
> > > > sure
> > = to
> > > merge in any concepts that would be lost. If you = submitted a
> > > previous
> use
> > > = case that was removed, please double check that I didn't miss
> = anything.
> > > > - I broke up "Endpoint = Identification and Assessment" into 3
> > > > = distinct
> and
> > > somewhat separable use cases: = "Endpoint Identification and
> > > Assessment = Planning", "Endpoint Posture Attribute Value = Collection",
> > > "Posture Evaluation". = Please let me know what you think about this
> change.
> = > > > - Addressed some aspects of the discussion thread based = on the
> > > > working
> > > session changes. = Please provide any suggested edits for aspects that
> > > = I
> > might
> > > have missed or got wrong.
> = > > >
> > > > The rest of the changes can be = found in the draft's change log.
> > > >
> > = > > If possible, I'd like to get to a fairly stable place with = this
> > > > draft
> in the next
> > > = revision or two to allow for progress to be made on the
> > = > requirements. In addition to the embedded questions in the = document,
> > > I'd like to focus on
> > = the
> > > following questions:
> > > = >
> > > > Is the draft approachable for a newcomer to = the effort? Do you see
> > > > the
> > > = updated use case structure as an improvement?
> > > > = Does this draft paint a complete enough picture? Are we missing
> = > > > any
> > > important concepts?
> > = > > Is there anything you can't live with?
> > > = >
> > > > I hope to release at least one or two more = updates to this draft
> within the
> > > next few = weeks before the holidays catch up on us.  I know everyone
> = > > is busy; timely comments are appreciated to allow for a = quick
> > > turnaround on the next revision.
> > = > >
> > > > Thanks,
> > > > = Dave
> > > >
> > > > -----Original = Message-----
> > > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
> > > > = Sent: Wednesday, November 20, 2013 5:58 PM
> > > > To: = Waltermire, David A.; David Harrington
> > > > Subject: = New Version Notification for
> > > > = draft-ietf-sacm-use-cases-05.txt
> > > >
> > = > >
> > > > A new version of I-D, = draft-ietf-sacm-use-cases-05.txt has been
> > > successfully = submitted by David Waltermire and posted to the IETF
> > > = repository.
> > > >
> > > > Filename: =      draft-ietf-sacm-use-cases
> > > > = Revision:      05
> > > > Title:   =               Endpoint Security = Posture Assessment -
> Enterprise Use
> > Cases
> = > > > Creation date:         = 2013-11-20
> > > > Group:         =         sacm
> > > > Number of pages: = 24
> > > > URL:
> http://www.ietf.org/internet-drafts/draft-ietf-sacm-use= -
> > cases-
> > > 05.txt
> > > = > Status:
> http://datatracker.ietf.org/doc/draft-ietf-sacm-use-cas= es
> > > > Htmlized:
> http://tools.ietf.org/html/draft-ietf-sacm-use-cases-05=
> > > > Diff:
> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sacm-use-= cases-05
> > > >
> > > > = Abstract:
> > > >     This memo documents a = sampling of use cases for securely
> aggregating
> > > = >     configuration and operational data and evaluating = that data to
> > > >     determine an = organization's security posture.  From these
> = operational
> > > >     use cases, we can = derive common functional capabilities and
> > > >   =   requirements to guide development of vendor-neutral,
> = interoperable
> > > >     standards for = aggregating and evaluating data relevant to
> security
> = > > >     posture.
> > > >
> = > > >
> > > >
> > > >
> = > > > Please note that it may take a couple of minutes from the = time of
> > > submission until the htmlized version and diff = are available at
> tools.ietf.org.
> > > >
> = > > > The IETF Secretariat
> > > >
> > = > > _______________________________________________
> > = > > sacm mailing list
> > > > sacm@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/sacm
> = > > >
> > >
> > >
> > = >
> > > ...
> > >
> > > . . = .
> > > = _______________________________________________
> > > sacm = mailing list
> > > sacm@ietf.org
> > > https://www.ietf.org/mailman/listinfo/sacm
> = > _______________________________________________
> > sacm = mailing list
> > sacm@ietf.org
> > https://www.ietf.org/mailman/listinfo/sacm
><= br>> _______________________________________________
> sacm = mailing list
> sacm@ietf.org
> https://www.ietf.org/mailman/listinfo/sacm
_____= __________________________________________
sacm mailing list
sacm@ietf.org
https://www.ietf.org/mailman/listinfo/sacm


______________= _________________________________
sacm mailing list
sacm@ietf.org
https://www.ietf.org/mailman/listinfo/sacm

 <= /o:p>


...=

This = message and attachments may contain confidential information. If it = appears that this message was sent to you by mistake, any retention, = dissemination, distribution or copying of this message and attachments = is strictly prohibited. Please notify the sender immediately and = permanently delete the message and any attachments.
. . = .


______________= _________________________________
sacm mailing list
sacm@ietf.org
https://www.ietf.org/mailman/listinfo/sacm

 <= /o:p>


...=


. . = .

 

------=_NextPart_000_029C_01CEF5B8.E94F77D0-- From dbharrington@comcast.net Tue Dec 10 12:29:22 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 088361AE19B for ; Tue, 10 Dec 2013 12:29: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_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7IY1N2axrMBu for ; Tue, 10 Dec 2013 12:29:17 -0800 (PST) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id 633A61AE1F2 for ; Tue, 10 Dec 2013 12:29:17 -0800 (PST) Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by qmta04.westchester.pa.mail.comcast.net with comcast id ztvK1m0030SCNGk54wVBJn; Tue, 10 Dec 2013 20:29:11 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta09.westchester.pa.mail.comcast.net with comcast id zwVB1m00L2yZEBF3VwVBhA; Tue, 10 Dec 2013 20:29:11 +0000 From: "David Harrington" To: "'Romascanu, Dan \(Dan\)'" , "'Waltermire, David A.'" , References: <9904FB1B0159DA42B0B887B7FA8119CA129DFE39@AZ-FFEXMB04.global.avaya.com> <7d830b39e9a74c90947bfa4c8bf7ba7e@BLUPR09MB038.namprd09.prod.outlook.com> <9904FB1B0159DA42B0B887B7FA8119CA129E00B5@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA129E00B5@AZ-FFEXMB04.global.avaya.com> Date: Tue, 10 Dec 2013 15:29:09 -0500 Message-ID: <02ac01cef5e6$7b38db50$71aa91f0$@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQF0jgjsR8dnySy7llRQifl+GOt4FwIKXfxIAm1o9rea3vKO4A== Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1386707351; bh=IhAh4UauNTnDq5v+4w4Y530TXvYN2f6nvgPyGkUuo/w=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=Tkcvd/lz1J2psVIkWCf0mBIHVj1d++/gMlsu411Qavfkj6awnphyITcYUY38IOSbB b+gFT9aNMSRMhrPyzHXWLhHdU2nvrzuZvhoV/vA/MzX3/TcUGuWU8l0pgSYbxHz9lJ 5OuynNpAeEa7eOFGFlnzmphZmkRChz2nfM7l4+zWnpSrYlnzITWImh61F8z9bmbgQh Dgsnves8EljlRuRS7BpvHFmy7SzeuewY65NzsWM3GLzcScDvz8EjFbm1DBJYeqMfe7 NjUriNfjiAaPq7zO4AbtGWaulD2IJn9PwQ0Mf4HQqKa9HbTfFVN2qqR68U61VkW4jk wYIW3UjI/pP/g== Subject: Re: [sacm] IETF 89 - Working Group/BOF/IRTF Scheduling X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 20:29:22 -0000 I do not expect to be attending ietf89. David Harrington dbharrington@comcast.net +1-603-828-1401 > -----Original Message----- > From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Romascanu, Dan > (Dan) > Sent: Tuesday, December 10, 2013 2:44 PM > To: Waltermire, David A.; sacm@ietf.org > Subject: Re: [sacm] IETF 89 - Working Group/BOF/IRTF Scheduling > > I suggest that we discuss this at the virtual interim. We need commitment at > least from the principal contributors that they will be attending a second > Friday meeting. > > Regards, > > Dan > > > > > -----Original Message----- > > From: Waltermire, David A. [mailto:david.waltermire@nist.gov] > > Sent: Tuesday, December 10, 2013 9:40 PM > > To: Romascanu, Dan (Dan); sacm@ietf.org > > Subject: Re: [sacm] IETF 89 - Working Group/BOF/IRTF Scheduling > > > > It may make sense to schedule a second Friday working meeting to do > > group edits on drafts. > > > > Dave > > ________________________________________ > > From: sacm on behalf of Romascanu, Dan (Dan) > > > > Sent: Tuesday, December 10, 2013 4:56:15 PM > > To: sacm@ietf.org > > Subject: Re: [sacm] IETF 89 - Working Group/BOF/IRTF Scheduling > > > > It will be IETF-89, of course. > > > > > > > > > -----Original Message----- > > > From: Romascanu, Dan (Dan) > > > Sent: Tuesday, December 10, 2013 5:53 PM > > > To: sacm@ietf.org > > > Subject: FW: IETF 89 - Working Group/BOF/IRTF Scheduling > > > > > > > > > Hi, > > > > > > Scheduling for the IETF-88 meeting in London is now open. > > > > > > Our plan is to request one 2 hours meeting slot, as we had at IETF-88. > > > Anybody believes that we need more, or less time? > > > > > > Also please send us your list of critical conflicts, beyond the > > obvious. > > > > > > Thanks and Regards, > > > > > > Adam and Dan > > > > > > > > > > > > -----Original Message----- > > > From: WGChairs [mailto:wgchairs-bounces@ietf.org] On Behalf Of IETF > > > Agenda > > > Sent: Tuesday, December 03, 2013 10:13 PM > > > To: Working Group Chairs > > > Cc: irsg@irtf.org > > > Subject: IETF 89 - Working Group/BOF/IRTF Scheduling > > > > > > ----------------------------------------------------------------- > > > 89th IETF - London, England > > > Meeting Dates: March 2 - 7, 2014 > > > ----------------------------------------------------------------- > > > IETF meetings start Monday morning and run through Friday afternoon > > > (13:30). > > > > > > We are accepting scheduling requests for all Working Groups, BOFs, and > > > Research Groups starting today. The milestones and deadlines for > > > scheduling-related activities are as follows: > > > > > > NOTE: cutoff dates are subject to change. > > > > > > - 2013-12-02 (Monday): Working Group and BOF scheduling begins. To > > > request a Working Group session, use the IETF Meeting Session Request > > > Tool. > > > - 2014-01-17 (Friday): Cut-off date for requests to schedule Working > > > Group meetings at UTC 23:59. To request a Working Group session, use > > > the IETF Meeting Session Request Tool. > > > - 2014-01-17 (Friday): Cut-off date for BOF proposal requests to Area > > > Directors at UTC 23:59. To request a BOF, please see instructions on > > > Requesting a BOF. > > > - 2014-01-24 (Friday): Cut-off date for Area Directors to approve BOFs > > > at UTC 23:59. > > > - 2014-01-31 (Friday): Preliminary agenda published for comment. > > > - 2014-02-03 (Monday): Cut-off date for requests to reschedule Working > > > Group and BOF meetings UTC 23:59. > > > - 2014-02-07 (Friday): Final agenda to be published. > > > - 2014-02-17 (Monday): Draft Working Group agendas due by UTC 23:59, > > > upload using IETF Meeting Materials Management Tool. > > > - 2014-02-24 (Monday): Revised Working Group agendas due by UTC > 23:59, > > > upload using IETF Meeting Materials Management Tool. > > > - 2014-03-28 (Friday): Proceedings submission cutoff date by UTC > > > 23:59, upload using IETF Meeting Materials Management Tool. > > > - 2014-04-18 (Friday): Proceedings submission corrections cutoff date > > > by UTC 23:59, upload using IETF Meeting Materials Management Tool. > > > > > > Submitting Requests for Working Group and BOF Sessions > > > > > > Please submit requests to schedule your Working Group sessions using > > > the "IETF Meeting Session Request Tool," a Web-based tool for > > > submitting all of the information that the Secretariat requires to > > > schedule your sessions. > > > > > > The URL for the tool is: > > > > > > https://pub.ietf.org/sreq/ > > > > > > Please send requests to schedule your BOF sessions to agenda@ietf.org. > > > Please include the acronym of your BOF in the subject line of the > > > message, and include all of the information specified in item (4) of > > > "Requesting Meeting Sessions at IETF Meetings" in the body. (This > > > document is included below.) > > > > > > Submitting Session Agendas > > > > > > For the convenience of meeting attendees, we ask that you submit the > > > agendas for your Working Group sessions as early as possible. Draft > > > Working Group agendas are due Monday, February 17th, 2014 at UTC > > 23:59. > > > Revised Working Group agendas are due no later than Monday, February > > > 24th, 2014 at UTC 23:59. The proposed agenda for a BOF session should > > > be submitted along with your request for a session. Please be sure to > > > copy your Area Director on that message. > > > > > > Please submit the agendas for your Working Group sessions using the > > > "IETF Meeting Materials Management Tool," a Web-based tool for > making > > > your meeting agenda, minutes, and presentation slides available to the > > > community before, during, and after an IETF meeting. If you are a BOF > > > chair, then you may use the tool to submit a revised agenda as well as > > > other materials for your BOF once the BOF has been approved. > > > > > > The URL for the tool is: > > > > > > https://pub.ietf.org/proceedings/ > > > > > > Additional information about this tool is available at: > > > > > > http://www.ietf.org/instructions/meeting_materials_tool.html > > > > > > Agendas submitted via the tool will be available to the public on the > > > "IETF Meeting Materials" webpage as soon as they are submitted. > > > > > > The URL for the "IETF 89 Meeting Materials" Web page is: > > > > > > https://datatracker.ietf.org/meeting/89/materials.html > > > > > > If you are a Working Group chair, then you already have accounts on > > > the "IETF Meeting Session Request Tool" and the "IETF Meeting > > > Materials Management Tool." The same User ID and password will work > > > for both tools. If you are a BOF chair who is not also a Working > > > Group chair, then you will be given an account on the "IETF Meeting > > > Materials Management Tool" when your BOF has been approved. If you > > > require assistance in using either tool, or wish to report a bug, then > > > please send a message to: > > > ietf-action@ietf.org. > > > > ========================================================== > ===== > > > For your convenience, comprehensive information on requesting > meeting > > > sessions for IETF 89 is below: > > > > > > 1. Requests to schedule Working Group sessions should be submitted > > > using the "IETF Meeting Session Request Tool," a Web-based tool for > > > submitting all of the information required by the Secretariat to > > > schedule your sessions. The URL for the tool is: > > > > > > https://pub.ietf.org/sreq/ > > > > > > Instructions for using the tool are available at: > > > > > > http://www.ietf.org/instructions/session_request_tool_instruction.html > > > > > > If you require an account on this tool, or assistance in using it, > > > then please send a message to ietf-action@ietf.org. If you are unable > > > to use the tool, then you may send your request via e-mail to > > > agenda@ietf.org, with a copy to the appropriate Area Director(s). > > > > > > Requests to schedule BOF sessions must be sent to agenda@ietf.org with > > > a copy to the appropriate Area Director(s). > > > > > > When submitting a Working Group or BOF session request by e-mail, > > > please include the Working Group or BOF acronym in the Subject line. > > > > > > 2. BOFs will NOT be scheduled unless the Area Director approves the > > BOF. > > > The proponents behind a BOF need to contact a relevant Area Director, > > > preferably well in advance of the BOF approval deadline date. The AD > > > needs to have the full name of the BOF, its acronym, suggested names > > > of chairs, an agenda, full description of the BOF and the information > > > covered in item 4. Please read RFC 5434 for instructions on how to > > > drive a successful BOF effort. The approval depends on, for instance, > > > Internet-Drafts and list discussion on the suggested topic. BOF agenda > > > requests, if approved, will be submitted to the IETF Secretariat by > > > the ADs. > > > > > > 3. A Working Group may request either one or two sessions. If your > > > Working Group requires more than two sessions, then your request must > > > be approved by an Area Director. Additional sessions will be > > > assigned, based on availability, after Monday, February 3rd, 2014, the > > > cut-off date for requests to reschedule a session. > > > > > > 4. You MUST provide the following information before a Working Group > > > or BOF session will be scheduled: > > > > > > a. Working Group or BOF full name with acronym in brackets: > > > > > > b. AREA under which Working Group or BOF appears: > > > > > > c. CONFLICTS you wish to avoid, please be as specific as possible: > > > > > > d. Expected Attendance: > > > > > > e. Special requests: > > > > > > f. Number of sessions: > > > > > > g. Length of session: > > > - 1 hour > > > - 1 1/2 hours > > > - 2 hours > > > - 2 1/2 hours > > > > > > For more information on scheduling Working Group and BOF sessions, > > > please refer to RFC 2418 (BCP 25), "IETF Working Group Guidelines and > > > Procedures" (http://www.ietf.org/rfc/rfc2418.txt). > > > > ========================================================== > ===== > > > For your convenience please find here a list of the IETF Area > > > Directors with their e-mail addresses: > > > > > > IETF Chair > > > Jari Arkko > > > > > > Applications Area (app) > > > Barry Leiba > > > Pete Resnick > > > > > > Internet Area (int) > > > Brian Haberman Ted Lemon > > > > > > > > > Operations & Management Area (ops) > > > Benoit Claise > > > Joel Jaeggli > > > > > > Real-time Applications and Infrastructure Area (rai) Gonzalo Camarillo > > > Richard Barnes > > > > > > Routing Area (rtg) > > > Stewart Bryant > > > Adrian Farrel > > > > > > Security Area (sec) > > > Stephen Farrell Sean Turner > > > > > > > > > Transport Area (tsv) > > > Martin Stiemerling Spencer Dawkins > > > > > > > ========================================================== > = > > > 88th IETF Meeting Attendance Numbers > > > > > > 6lo - 52 > > > 6man - 143 > > > 6tisch - 45 > > > abfab - 20 > > > alto - 35 > > > appsawg/apparea - 138 > > > aqm - 108 > > > aqm (2nd session) - 45 > > > avtcore - 51 > > > avtext - 59 > > > bfd - 17 > > > bmwg - 19 > > > ccamp - 49 > > > ccamp (2nd session) - 44 > > > cdni - 39 > > > clue - 41 > > > clue (2nd session) - 32 > > > core - 62 > > > core (2nd session) - 50 > > > dhc - 59 > > > dice - 65 > > > dime - 23 > > > dispatch - 55 > > > dmm - 37 > > > dnsop - 125 > > > dnssd - 108 > > > ecrit - 31 > > > eman - 19 > > > forces - 40 > > > geonet (BoF) - 99 > > > geopriv - 41 > > > homenet - 156 > > > httpauth - 43 > > > httpbis - 89 > > > httpbis (2nd session) - 127 > > > i2rs - 223 > > > iccrg (RG) - 68 > > > icnrg (RG) - 43 > > > idr - 90 > > > igovupdate BoF - 220 > > > insipid - 32 > > > intarea (AG) - 98 > > > ipfix - 23 > > > ippm - 48 > > > ipsecme - 27 > > > IRTF Open Meeting - 100 > > > isis - 58 > > > jose - 42 > > > json - 49 > > > karp - 22 > > > kitten - 23 > > > l2vpn - 71 > > > l3vpn - 65 > > > lisp - 56 > > > lmap - 52 > > > lwig - 35 > > > manet - 35 > > > mboned - 25 > > > mif - 41 > > > mmusic - 69 > > > mmusic (2nd session) - 53 > > > mpls - 71 > > > mpls (2nd session) - 72 > > > mptcp - 45 > > > mptcp (2nd session) - 70 > > > ncrg (RG) - 33 > > > netconf - 62 > > > netext - 27 > > > netmod - 69 > > > nfsv4 - 16 > > > nmrg (RG) - 35 > > > nmrg (RG) (2nd session) - 17 > > > ntp (combined with tictoc) - 32 > > > nvo3 - 193 > > > nwcrg (PRG) - 25 > > > oauth - 38 > > > opsawg/opsarea - 68 > > > opsec - 48 > > > ospf - 38 > > > paws - 17 > > > pce - 72 > > > pcp - 30 > > > perpass (BoF) - 313 > > > pim - 24 > > > ppsp - 12 > > > precis - 32 > > > pwe3 - 40 > > > radext - 20 > > > rfcform (BoF) - 52 > > > rmcat - 60 > > > rtcweb - 174 > > > rtcweb (2nd session) - 188 > > > rtgarea (AG) - 101 > > > rtgwg - 118 > > > saag (AG) - 148 > > > sacm - 40 > > > scim - 32 > > > sdnrg (RG) - 259 > > > sidr - 61 > > > siprec - 31 > > > softwire - 52 > > > spring - 158 > > > stir - 82 > > > stir (2nd session) - 79 > > > storm - 21 > > > tcpm - 36 > > > tictoc (combined with ntp) - 32 > > > tls - 111 > > > trill - 33 > > > tsvarea (AG) - 153 > > > tsvwg - 63 > > > tsvwg (2nd session) - 47 > > > v6ops - 135 > > > v6ops (2nd session) - 92 > > > weirds - 55 > > > wpkops - 34 > > > xmpp - 31 > > > xrblock - 24 > > _______________________________________________ > > sacm mailing list > > sacm@ietf.org > > https://www.ietf.org/mailman/listinfo/sacm > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm From ietf@rozanak.com Wed Dec 11 07:56:59 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B9821ADF5F; Wed, 11 Dec 2013 07:56:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I87Nd3Ltp-CA; Wed, 11 Dec 2013 07:56:57 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 2C0121ADC03; Wed, 11 Dec 2013 07:56:57 -0800 (PST) Received: from kopoli ([141.89.226.146]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0MUp6q-1W2zUv3QoG-00YriV; Wed, 11 Dec 2013 10:56:50 -0500 From: "Hosnieh Rafiee" To: , , , References: In-Reply-To: Date: Wed, 11 Dec 2013 16:56:41 +0100 Message-ID: <004101cef689$99b93f90$cd2bbeb0$@rozanak.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0042_01CEF691.FB7F0720" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac72iSvPgVYgbXT9Tp2rb9e4S1H5BQAABB3g Content-Language: en-us X-Provags-ID: V02:K0:zsorZVhW8HgeflfAdkqx44XEhAz1ybLvxGiEIOStOdR l6APmNSpArup54roxvO9Uil1wRt+vU2S8n5NF1qF2IZvqk9Urn 8+zdGx8jNCUMNu+jibJdw9ekKma8VAmZiEv4xBVQiSoEt5odYs 8+lqvf5E0supOsi8Cg3PsJ17ki+OfTmOzzDdPJUXyaa6ofnfy4 b7E16COcPOxjWS1Rfxi7JypZv7WKu96HJrB3L/k2K+ADOmr/u6 a+XNj0mY4xcXCqvKwJAPc4RHfHikBps5GLzWWJBatVoqfzW+JN dzgpMURtRaqsMwVc0Da//ZBinNwv0QGMi+U/S8QCQ1tDIQ+mtU q3lmcZ2n6HT80UoXWwaI= Subject: [sacm] new mailing list in security area X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 15:56:59 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0042_01CEF691.FB7F0720 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello, There is a new mailing list in security area. The discussion will be fruitful if there are people from different backgrounds and not only security (security, operational views, application layer, network layer, privacy, etc). I already invited the people who I could remember. If I missed to invite you, just feel free to join this mailing list. The purpose is to find solutions to automate authentication and use network layer for this means but at the same time take care of performance, privacy and the possibility of this solution. https://www.ietf.org/mailman/listinfo/secauth This is the description of this mailing list. This list is for the discussions relating to using the IP layer as a means of authentication in other upper layers, especially the application layer, by considering both security and privacy on one hand and performance on the other hand. The goal is to come up with the implementation of a library for this purpose. The focus is on both nodes with limited resources (battery, memory, etc) and other nodes. We are also discussing the possible implementation or implementation barriers from operational points of view. Looking forward to see your participations there :-) Thanks, Smile Hosnieh ------=_NextPart_000_0042_01CEF691.FB7F0720 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Hello,

 

There = is a new mailing list in security area. The discussion will be fruitful = if there are people from different backgrounds and not only security = (security, operational views, application layer, network layer, privacy, = etc). I already invited the people who I could remember. If I missed to = invite you, just feel free to join this mailing list. The purpose is to = find solutions to automate authentication and use network layer for this = means but at the same time take care of performance, privacy and the = possibility of this solution.

https://www.ietf.org/mail= man/listinfo/secauth

 

This = is the description of this mailing list.

 

This = list is for the discussions relating to using the IP layer as a  = means of authentication in other upper layers, especially the  = application layer, by considering both security and privacy on one  = hand and performance on the other hand. The goal is to come up = with  the implementation of a library for this purpose. The focus = is on  both nodes with limited resources (battery, memory, etc) and = other nodes.

We are also = discussing the possible implementation or implementation  barriers = from operational points of view.

 

Looking forward to see your participations there = :-)

 

 

Thanks,

 

Smile

 

= Hosnieh

 

 

------=_NextPart_000_0042_01CEF691.FB7F0720-- From scott.brim@gmail.com Wed Dec 11 11:02:32 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B33891ADBCD; Wed, 11 Dec 2013 11:02:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VrvwBGx2pYfh; Wed, 11 Dec 2013 11:02:31 -0800 (PST) Received: from mail-oa0-x230.google.com (mail-oa0-x230.google.com [IPv6:2607:f8b0:4003:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id D517A1AD8D5; Wed, 11 Dec 2013 11:02:30 -0800 (PST) Received: by mail-oa0-f48.google.com with SMTP id l6so7725320oag.21 for ; Wed, 11 Dec 2013 11:02:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=795yZDj7DdiP12YnAA7TxcketLfq0rVudJbrto9egtY=; b=lTDwakyGst7PvmVqYGCrcWxsxos8MAniri3M0aco11rnMLOu+KUi1KNBXFOuCEugkL 3OLPFIS9i74cUOBuhLSgqkdQZBCSth6JzP3YoaO8NWIvSMzhwiKnv7gsJ5oFwIzkWTQO 57DizCFCJvXurkFSVQ/5/xjpR/oW5BhiR22MkbCFwUWfcE6plWj6MeccMFVz1sO0oJ+Z UtBGr/CW4BysZJs1QQN7fsnAy1NzhCZB+ssdI/fv9hcL7Ruu2xe81lVVgbP+hhfK4kMV dwD8xvlNrKnGEY3uowFF3g60GpTJA1pwDzuftkHEMjbRH02w8Xp+XQgs2rWxeSgEAH2l km3Q== X-Received: by 10.60.146.229 with SMTP id tf5mr2362568oeb.27.1386788545081; Wed, 11 Dec 2013 11:02:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.48.9 with HTTP; Wed, 11 Dec 2013 11:02:04 -0800 (PST) In-Reply-To: <004101cef689$99b93f90$cd2bbeb0$@rozanak.com> References: <004101cef689$99b93f90$cd2bbeb0$@rozanak.com> From: Scott Brim Date: Wed, 11 Dec 2013 14:02:04 -0500 Message-ID: To: Hosnieh Rafiee Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Wed, 11 Dec 2013 11:06:05 -0800 Cc: IPv6 Ops WG , IETF Security Area Advisory Group , "<, apps-discuss@ietf.org>, " , sacm@ietf.org Subject: Re: [sacm] [apps-discuss] new mailing list in security area X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 19:02:32 -0000 On Wed, Dec 11, 2013 at 10:56 AM, Hosnieh Rafiee wrote: > The purpose > is to find solutions to automate authentication and use network layer for > this means but at the same time take care of performance, privacy and the > possibility of this solution. > > https://www.ietf.org/mailman/listinfo/secauth Hosnieh, I look forward to this. I start out skeptical, because I suspect that all the reasons for the end-to-end argument will be applicable here, but I remain open-minded. Scott From ietf@rozanak.com Wed Dec 11 12:13:49 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD7611AE0E3; Wed, 11 Dec 2013 12:13:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E6Jo81IobzgX; Wed, 11 Dec 2013 12:13:48 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 07E9E1ADFA1; Wed, 11 Dec 2013 12:13:48 -0800 (PST) Received: from kopoli (g231191095.adsl.alicedsl.de [92.231.191.95]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0LmbFL-1VIKM82IcN-00a1zI; Wed, 11 Dec 2013 15:13:42 -0500 From: "Hosnieh Rafiee" To: "'Mouse'" , , , , References: <004101cef689$99b93f90$cd2bbeb0$@rozanak.com> <201312111940.OAA29160@Chip.Rodents-Montreal.ORG> In-Reply-To: <201312111940.OAA29160@Chip.Rodents-Montreal.ORG> Date: Wed, 11 Dec 2013 21:13:30 +0100 Message-ID: <004201cef6ad$7b2991a0$717cb4e0$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEbq7nIPHMLdLerYKkR6aMsmA3rUQIznEoGm6RhcbA= Content-Language: en-us X-Provags-ID: V02:K0:oflu91ICOJRXypAx6hSBhPz7vQ4+vbOdldVUBGMY/Et hofng2iypgYTDfKHK0x1C/4hv746RJi9VZ3y73mZ3LMPV7FtGr NZlGxgw/5QelW9ArmkN4gC881vsmN22OJpcJA7e+a73C4ZnEyp EGBHWVovX4KbZ0KVIs2MJewgcqvKVpRiV5MwIDUUfe/41GJSQ0 553grgsCeCQj6yYyaEtdjPxjRFNwos8aFvrDXa1CXo6ME7Eiwc 72lEwpI6JvJHPkiBVoi1Sqagj5p5qfOD2lXpF0grRaUHl/Uq9I 9zSvaelSzxV+jS+YaTZEFyc77G7NNjV52EjL/a4kzSEfEzYyQT wW5oZHaFG5Y/QX8ad1bU= Subject: Re: [sacm] [saag] new mailing list in security area X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 20:13:49 -0000 Hi, > -----Original Message----- > From: saag [mailto:saag-bounces@ietf.org] On Behalf Of Mouse > Sent: Wednesday, December 11, 2013 8:40 PM > To: saag@ietf.org > Subject: Re: [saag] new mailing list in security area > > > There is a new mailing list in security area. [...] > > Sounds possibly up my alley. But... > > > Looking forward to see your participations there :-) > > ...it'd help if you gave the list management address (or at least the list post > address, to which I trust we can just append -request). All I saw was a Web > URL (oddly, present twice, with no explanation of why), and one that was > HTTPS and thus useless to me even if I were willing to use the Web to manage > email (which I'm not). To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/secauth or, via email, send a message with subject or body 'help' to secauth-request@ietf.org You can reach the person managing the list at: secauth-owner@ietf.org Send secaut mailing list submissions to: secauth@ietf.org thanks, smile, Hosnieh From dbharrington@comcast.net Wed Dec 11 16:53:04 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1083D1AE099 for ; Wed, 11 Dec 2013 16:53:04 -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_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RA7fJ-2g1c5Q for ; Wed, 11 Dec 2013 16:53:02 -0800 (PST) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:64]) by ietfa.amsl.com (Postfix) with ESMTP id 2B6B21AD791 for ; Wed, 11 Dec 2013 16:53:02 -0800 (PST) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta07.westchester.pa.mail.comcast.net with comcast id 0QP91n0041GhbT857QswVZ; Thu, 12 Dec 2013 00:52:56 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta07.westchester.pa.mail.comcast.net with comcast id 0Qsv1n00Z2yZEBF3TQswDL; Thu, 12 Dec 2013 00:52:56 +0000 From: "David Harrington" To: Date: Wed, 11 Dec 2013 19:52:53 -0500 Message-ID: <011401cef6d4$7da30b60$78e92220$@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac72bbqaB9GGgDuzTUivs2xqy9QVOw== Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1386809576; bh=eL7POvcOHlWY8ks6Pr1G0qTo43wxcdJC58GD/r1eWc8=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=TW5JpObqvHkxmZOhRJ/+lArOYhu2Li6iGO55KJ7WTVX8ZUu4BkREs5KN1PBBuh9xl 9qwFkHWrYHfvxg/DJQYkrgJ9DUrqiYrEcr0a17pH2OZHUuvbnzJVCSg6kcZGu1XBRu HaeIROvFm7vJWYl4B/A+2gDWxOOgD1H1vrXz061kCLpbCVVzeEH8LBK2X9S59OFmQd BRgGQnGjoWOGUkMtmxl1iF2WyDT50fwy5cO5mkecrB5qcia9SAfOwj5PvTzoN2M8zF cEHJ2Z21JIVsSmFDIbF/hqvfwDqcKXzsMj/Fg1HZKu69a0edCMMAAsaBGQZS27V9/T /kEhsIZHvZDWQ== Subject: [sacm] review of draft-ietf-sacm-use-cases-05 X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Dec 2013 00:53:04 -0000 Hi, I reviewed -05- and it appears reasonably mature. Can we move our focus from use cases to requirements and architecture? I have a few comments on the -05- revision, all editorial in nature. 1) Does this document utilize terms that are defined/maintained in the terminology doc? If so, we should have a section that points out where to find the term definitions, and to reference the terminology draft. 2) Section 2.1.1: "for the explicit use of" - does this mean data gathered by a network management system, for example, cannot be used to satisfy the needs of sacm? Wouldn't the following be appropriate? This use case describes the need for content to be defined and published to a data store, as well as queried and retrieved from the data store for posture collection and evaluation. 3) I find it difficult to understand this text because "content" is such an abstract word. What kind of content? Are we talking about things like policies here? Or are we talking about gathered operational data? Or a specification of a desired configuration? 4) This text talks about data models and information models. We should reference RFC3444, which differentiates information model from data model. 5) "multiple information models will be supported to address" - address is ambiguous here; do we mean address as in "address a problem", or as in "this is the address where the value of this attribute can be found (such as an OID for an SNMP object)"? Can we reword this? 6) the "Content Definition" section sounds like you're writing a charter for work to be done by this WG. Part of the problem here is that we have gone from active voice to passive voice, and have lost the "actors" involved. Who will define content to drive collection? Who will evaluate existing stores of content to find content to reuse? Who will develop content based on available data models which may be standardized or proprietary? I think changing this to active voice helps to identify some sentences that don't actually say much, and could be condensed. Content Definition: Defined content will drive collection and evaluation. < Content definers> may evaluate existing stores of content to find content to reuse and may create new content. < Content definers> may develop content based on available data models which may be standardized or proprietary. "Content" is "something that is contained" - not very descriptive. And we have a number of different containers (repositories) in the tentative architectures that have been discussed. It seems to me we are talking about policies or rules here (and we may want to limit this to SACM rules or SACM policies): Rule Definition: SACM rules will drive collection and evaluation. Rules may be designed by a variety of roles - application implementers may build SACM rules into their applications; administrators may define SACM rules based on organizational policies; operators may define SACM rules as needed for evaluation at runtime, and so on. Rule definers may choose to reuse rules from existing stores of rules and may create new rules. Rule definers may develop rules based on available standardized or proprietary data models, such as those used for network management and/or host management. I realize that using the term "rules" or the term "policies" invites debate about whether the term implies some special format. But our goal in this document to to reach a common understanding of the problems we are trying to solve. "content" seems so ambiguous as to be useless for achieving our goal here. 7) Here is a case where the generic "actor" might be appropriate: Content Retrieval: An actor (end-user, operator, administrator, application) acquires one or more specific content entries. The location of the content may be known a priori, or determined based on decisions made using information from a previous query. 8) in 2.1.2 Endpoint Discovery: The purpose of discovery is to determine the type of endpoint to be posture assessed. How about: Endpoint Discovery: The purpose of discovery is to determine the endpoint and how its posture should be assessed. 9) Identify Endpoint Targets: should this step include authentication of the target? 10) grammar: Identify Endpoint Targets Determine the candidate endpoint target(s) against which to perform the assessment. Depending on the assessment trigger, a single endpoint or multiple endpoints may be targeted based on discovered endpoint metadata. Content may describe the applicable targets for assessment. In this case the Content Query and/or Content Retrieval building blocks (see section 2.1.1) may be used to acquire this content. 11) Are these terms defined in terminology? Assessment, trigger, metadata 12) at very end of 2.1.4, "section Section 2" 13) at the very end of 2.1.4, "Completion of this process represents a complete assessment cycle as defined in section Section 2." Since this indicates completion of the section 2 process, I would expect section 3 to follow. But section continues with 2.1.5. 14) "(see section 2.1.4 ..." there is no close quote. 15) I think the 2.1.5 use case is a subset of 2.1.4 use case, specifically, the query of existing data is covered in Posture Attribute Value Query, condition 1. I think Posture Attribute Value Query should be modified to include the change detection, as part of establishing what needs to be queried. 16) In 2.2.1, we changed guides to checklist; "these checklist" needs to be plural. 17) " Like the Automated Checklist Verification usage scenario (see section 2.2.2), this usage scenario supports assessment of checklists." This should probably be "assessment based on checklists." 18) "a delta assessment" => "assessment of the delta" 19) in 2.2.5, Posture Attribute Value Collection, why "in the same way"? Maybe results could be handled in a different way. 20) I don't see "Search for signs of Infection", "Vulnerability Endpoint Identification", "Compromised Endpoint Identification", and "Suspicious Endpoint behavior", which were in -04-. They were moved into "Automated Checklist Verification". But the original usage scenarios did not mention checklists. Are we now limiting SACM to a checklist-driven approaches? Do the authors of the text in -04- agree that their use cases/usage scenarios are adequately captured in -05-? 21) 2.2.8 Others - Should "use cases" be "usage scenarios" here? David Harrington dbharrington@comcast.net +1-603-828-1401 From dromasca@avaya.com Thu Dec 12 13:02:51 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08A251AE4C9 for ; Thu, 12 Dec 2013 13:02:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.891 X-Spam-Level: X-Spam-Status: No, score=-1.891 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r5vrBoYF_PoM for ; Thu, 12 Dec 2013 13:02:49 -0800 (PST) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id DEB581ADFD6 for ; Thu, 12 Dec 2013 13:02:48 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFAEUjqlLGmAcV/2dsb2JhbAA/FwOCaSE4VbhYgR0WdIInAQEDEigsAiMBFQcOCgQGBjwkAgEEGxqHYgEMNqNGhEyOZ4tuEwSOMhEBDBMhKAeDCoETAQOfAYsogldSgXE5 X-IronPort-AV: E=Sophos;i="4.95,473,1384318800"; d="scan'208";a="41074792" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 12 Dec 2013 16:02:40 -0500 Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 12 Dec 2013 15:54:58 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC02.global.avaya.com ([135.64.58.12]) with mapi id 14.03.0146.000; Thu, 12 Dec 2013 22:02:39 +0100 From: "Romascanu, Dan (Dan)" To: "sacm@ietf.org" Thread-Topic: SACM WG Virtual Interim - draft agenda, logistics, preparation Thread-Index: Ac73fXzZtWoeaaprQUiNlBTt3NAWZg== Date: Thu, 12 Dec 2013 21:02:38 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA129E3C8B@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sacm] SACM WG Virtual Interim - draft agenda, logistics, preparation X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Dec 2013 21:02:51 -0000 Hi, This is a reminder that the SACM WG Virtual Interim will be hold on Tuesday= 12/17. The call details are reminded at the end of this email.=20 We still need at least one volunteer for taking notes. We cannot start the = meeting without a note taker! Here is the draft agenda. Please bash! 1. Logistics, notes takers - chairs - 5 min=20 2. WG status - chairs - 5 min=20 3. Use Cases - David and David - 75 min=20 4. Requirements - Nancy - 30 min=20 5. Way Forward - chairs - 5 min If you intend to use slides please send them to us before the meeting. The = slides will be included in the proceedings of IETF-89.=20 Thanks and Regards, Adam and Dan Topic: SACM WG Virtual Interim Meeting=20 Date: Tuesday, December 17, 2013=20 Time: 2:00 pm, Eastern Standard Time (New York, GMT-05:00)=20 Meeting Number: 314 306 861=20 Meeting Password: 1234=20 -------------------------------------------------------=20 To join the online meeting (Now from mobile devices!)=20 -------------------------------------------------------=20 1. Go to https://ietf.webex.com/ietf/j.php?ED=3D46248778&UID=3D0&PW=3DNODQ1= YWQ0N2Vl&RT=3DMiMxMQ%3D%3D=20 2. If requested, enter your name and email address.=20 3. If a password is required, enter the meeting password: 1234=20 4. Click "Join".=20 To view in other time zones or languages, please click the link:=20 https://ietf.webex.com/ietf/j.php?ED=3D46248778&UID=3D0&PW=3DNODQ1YWQ0N2Vl&= ORT=3DMiMxMQ%3D%3D=20 -------------------------------------------------------=20 To join the audio conference only=20 -------------------------------------------------------=20 Call-in toll number (US/Canada): 1-650-479-3208=20 Access code:314 306 861=20 From dromasca@avaya.com Mon Dec 16 05:54:59 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ECA11AE32B for ; Mon, 16 Dec 2013 05:54:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.138 X-Spam-Level: X-Spam-Status: No, score=-3.138 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KWKKddK2N7eT for ; Mon, 16 Dec 2013 05:54:56 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id A0BE91ADFC4 for ; Mon, 16 Dec 2013 05:54:56 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FAEkFr1LGmAcV/2dsb2JhbABPCoJpIYENuHCBIhZ0gicBAQMSCx06FwEVFQsJQiYBBBsah2IBoE2ETKJUF449K0KDGYETBJ8CiyiDKoIq X-IronPort-AV: E=Sophos;i="4.95,495,1384318800"; d="scan'208";a="35632352" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by de307622-de-outbound.net.avaya.com with ESMTP; 16 Dec 2013 08:54:54 -0500 Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 16 Dec 2013 08:46:58 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC02.global.avaya.com ([135.64.58.12]) with mapi id 14.03.0158.001; Mon, 16 Dec 2013 14:54:51 +0100 From: "Romascanu, Dan (Dan)" To: "sacm@ietf.org" Thread-Topic: comments and answers on draft-ietf-sacm-use-cases-05 Thread-Index: Ac76ZmOYdEGiM9z8SS+M5lqWHaqOFA== Date: Mon, 16 Dec 2013 13:54:51 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA129EE340@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sacm] comments and answers on draft-ietf-sacm-use-cases-05 X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Dec 2013 13:54:59 -0000 Here are a few comments on draft-ietf-sacm-use-cases-05, as well as answers= to part of the questions the editors implanted in the text.=20 Editorial comments:=20 1. The first paragraph in the Introduction needs to be either dropped or re= formulated without using the 'we' language. We need to have in mind the rea= der of the RFC a few years from now for which the stages of the process we = followed will have little relevance.=20 2. The latest editorial changes are not reflected yet in the introduction s= ections. For example the split of some of the use cases under usage scenari= os 3. 'Content' is widely used in the document. In some cases it looks like it= means configuration information, in other places status, in other places p= olicies or any combination of the above. There is a need for clarification = and in some cases of differentiation. Maybe it should be part of the defini= tions in the terminology I-D Answers to some of the QUESTIONS asked in text:=20 1. QUESTION: Since this is about security automation, can we drop the User and just use Application? Is there a better term to use here? Once the policy is selected, the rest seems like something we definitely would want to automate, so I dropped the User part. I believe that dropping the User part was the right decision.=20 2. QUESTION: It was suggested that mentioning several common acquisition methods, such as local API, WMI, Puppet, DCOM, SNMP, CMDB query, and NEA, without forcing any specific method would be good. I have concerns this could devolve into a "what about my favorite?" contest. OTOH, the charter does specifically call for use of existing standards where applicable, so the use cases document might be a good neutral location for such information, and might force us to consider what types of external interfaces we might need to support when we consider the requirements. It appears that the generic workflow sequence would be a good place to mention such common acquisition methods. I prefer remaining at the higher level here. We can mention that it is reco= mmended to used standard acquisition methods, but it is too early for a lis= t and we risk to fall in the rathole of 'my preferred method is missing' un= less we make the list so long that it becomes irrelevant. Listing and sorti= ng acquisition methods should be left for a later stage.=20 3. QUESTION: Evaluator generates a report or log or notification of some type? I believe that it typically does. The question is whether the log and/or no= tification are part of the posture assessment. I am not sure.=20 4. QUESTION: Is it just the type? Or is it to identify what endpoint instances to target for assessment using metadata such as the endpoint's organizationally expected type (e.g., expected function/role, etc.) =20 What is 'type'? We may miss a definition here. I thought that type is actua= lly the organizationally expected function/role, maybe also version.=20 5. QUESTION: Are we missing a building block that determines what previously collected data, if any, is suitable for evaluation and what data needs to be actually collected? Probably yes, taking into account usage scenations like 2.2.2, 2.2.3 which = rely on historical data.=20 Thanks and Regards, Dan (speaking as contributor) From dromasca@avaya.com Mon Dec 16 09:20:54 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23F761AE089 for ; Mon, 16 Dec 2013 09:20:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.128 X-Spam-Level: X-Spam-Status: No, score=-3.128 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.538, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pyii5jyEzrLU for ; Mon, 16 Dec 2013 09:20:52 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 168E31AE087 for ; Mon, 16 Dec 2013 09:20:52 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AigMAPo1r1LGmAcV/2dsb2JhbAA/FwOCaSE4VaNmA5UJgSUWdIInAQEDEigsAiMBFQcOCgQGBjwfBQIBBBsBGYdiAQw2oDWETI5nk34XjjcRAQwTSQeDC4ETBJ8CiyiCWFKBcTk X-IronPort-AV: E=Sophos;i="4.95,496,1384318800"; d="scan'208";a="41245780" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by co300216-co-outbound.net.avaya.com with ESMTP; 16 Dec 2013 12:20:51 -0500 Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 16 Dec 2013 12:12:54 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC01.global.avaya.com ([135.64.58.11]) with mapi id 14.03.0158.001; Mon, 16 Dec 2013 18:20:49 +0100 From: "Romascanu, Dan (Dan)" To: "sacm@ietf.org" Thread-Topic: virtual interim agenda uploaded Thread-Index: Ac76gymSXoa8ktnCRxCb+ujoSPBAJw== Date: Mon, 16 Dec 2013 17:20:49 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA129EE738@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sacm] virtual interim agenda uploaded X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Dec 2013 17:20:54 -0000 The SACM WG virtual interim agenda is now available at http://www.ietf.org/= proceedings/interim/2013/12/17/sacm/agenda/agenda-interim-2013-sacm-1. The meeting will take place tomorrow Tuesday 12/17, 2-4PM EST Webex information:=20 Topic: SACM WG Virtual Interim Meeting Date: Tuesday, December 17, 2013 Time: 2:00 pm, Eastern Standard Time (New York, GMT-05:00) Meeting Number: = 314 306 861 Meeting Password: 1234=20 ------------------------------------------------------- To join the online meeting (Now from mobile devices!) ------------------------------------------------------- 1. Go to https://ietf.webex.com/ietf/j.php?ED=3D46248778&UID=3D0&PW=3DNODQ1= YWQ0N2Vl&RT=3DMiMxMQ%3D%3D 2. If requested, enter your name and email address.=20 3. If a password is required, enter the meeting password: 1234 4. Click "Jo= in".=20 To view in other time zones or languages, please click the link:=20 https://ietf.webex.com/ietf/j.php?ED=3D46248778&UID=3D0&PW=3DNODQ1YWQ0N2Vl&= ORT=3DMiMxMQ%3D%3D=20 ------------------------------------------------------- To join the audio conference only ------------------------------------------------------- Call-in toll number (US/Canada): 1-650-479-3208=20 Access code:314 306 861=20 =20 From Adam.Montville@cisecurity.org Mon Dec 16 14:26:08 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEEE01AD8DC for ; Mon, 16 Dec 2013 14:26:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WihEMUkJbDs5 for ; Mon, 16 Dec 2013 14:26:07 -0800 (PST) Received: from mail1.bemta8.messagelabs.com (mail1.bemta8.messagelabs.com [216.82.243.197]) by ietfa.amsl.com (Postfix) with ESMTP id 723961AD8DB for ; Mon, 16 Dec 2013 14:26:07 -0800 (PST) Received: from [216.82.242.179:29897] by server-5.bemta-8.messagelabs.com id 29/36-11489-EFD7FA25; Mon, 16 Dec 2013 22:26:06 +0000 X-Env-Sender: Adam.Montville@cisecurity.org X-Msg-Ref: server-15.tower-86.messagelabs.com!1387232766!36241358!1 X-Originating-IP: [69.195.43.86] X-StarScan-Received: X-StarScan-Version: 6.9.16; banners=cisecurity.org,-,- X-VirusChecked: Checked Received: (qmail 9160 invoked from network); 16 Dec 2013 22:26:06 -0000 Received: from mail.msisac.org (HELO mail.msisac.org) (69.195.43.86) by server-15.tower-86.messagelabs.com with AES128-SHA encrypted SMTP; 16 Dec 2013 22:26:06 -0000 Received: from CISEXCHANGE2.msisac.org.local ([fe80::b899:f128:212e:984c]) by CISEXCHANGE1.msisac.org.local ([fe80::4f0:b68d:e779:38c3%13]) with mapi id 14.02.0347.000; Mon, 16 Dec 2013 17:23:48 -0500 From: Adam Montville To: "sacm@ietf.org" Thread-Topic: Note-takers for Interim Meeting Thread-Index: Ac76rbwj81cfmXAGSxGDWDOaMbgVYA== Date: Mon, 16 Dec 2013 22:23:37 +0000 Message-ID: <05BCCEB107AF88469B9F99783D47C1D60D677879@CISEXCHANGE2.msisac.org.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.252.39] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sacm] Note-takers for Interim Meeting X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Dec 2013 22:26:08 -0000 We are still in need of at least one (two would be best) note taker for to= morrow's interim meeting. Are there any volunteers? Regards, Adam . . . From dromasca@avaya.com Tue Dec 17 03:55:30 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C3901ADF5B for ; Tue, 17 Dec 2013 03:55:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.138 X-Spam-Level: X-Spam-Status: No, score=-3.138 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZAexTAZLCvOz for ; Tue, 17 Dec 2013 03:55:29 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 069CC1ADF10 for ; Tue, 17 Dec 2013 03:55:28 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtUMAK06sFLGmAcV/2dsb2JhbABZgmkhOFWjXAOUfwIIgR8WdIInAQEDEihRARUVFEIfBwEEGwEZh2IBDKEqhEyieI5hg1uBEwSfAosogyqCKg X-IronPort-AV: E=Sophos;i="4.95,501,1384318800"; d="scan'208";a="41362189" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by co300216-co-outbound.net.avaya.com with ESMTP; 17 Dec 2013 06:55:27 -0500 Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 17 Dec 2013 06:47:29 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC04.global.avaya.com ([135.64.58.14]) with mapi id 14.03.0158.001; Tue, 17 Dec 2013 12:55:26 +0100 From: "Romascanu, Dan (Dan)" To: "sacm@ietf.org" Thread-Topic: use cases presentation for the virtual interim Thread-Index: Ac77Ht69HyHfUYSsTbmdqFiwuDe3iA== Date: Tue, 17 Dec 2013 11:55:25 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA129F126E@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sacm] use cases presentation for the virtual interim X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2013 11:55:30 -0000 David Waltermire's presentation for the virtual interim today about the sta= tus of the Use Cases document is available at http://www.ietf.org/proceedin= gs/interim/2013/12/17/sacm/slides/slides-interim-2013-sacm-1-0.pptx.=20 Regards, Dan From ncamwing@cisco.com Tue Dec 17 10:56:05 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9A361AE298 for ; Tue, 17 Dec 2013 10:56:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.038 X-Spam-Level: X-Spam-Status: No, score=-15.038 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HXmRJ-GO38Xt for ; Tue, 17 Dec 2013 10:56:03 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id BCF991AE1FA for ; Tue, 17 Dec 2013 10:55:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15914; q=dns/txt; s=iport; t=1387306548; x=1388516148; h=from:to:subject:date:message-id:mime-version; bh=UoL8T7hmQazXSp/GtRSeSFw4DwrZrtZtLiKv2FYjNLU=; b=UvySdXL70dSym9tHBBaiCOPg2d4VeoSmdweQON8+oOPCl57+eMVBhsBq zLCni0lwrXoufgfQ+1e7QfLZcnBF1TclLSW8Y2vvaAQrkx0psz0dvzUbD py9e8zq1lCir5sAR87fVLyGtg2M1L37yy0Gz7tfr//hIgUb7sqVt2TWoB A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkYFAAWdsFKtJXG9/2dsb2JhbABZgkZEgQ24G4FuFnSCLC1eAYEAJwSIF6F4p2MXk08EmBaSFIMrgio X-IronPort-AV: E=Sophos;i="4.95,502,1384300800"; d="scan'208,217";a="292151106" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-5.cisco.com with ESMTP; 17 Dec 2013 18:55:48 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id rBHItmoq004374 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 17 Dec 2013 18:55:48 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.231]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0123.003; Tue, 17 Dec 2013 12:55:47 -0600 From: "Nancy Cam-Winget (ncamwing)" To: "sacm@ietf.org" Thread-Topic: review of draft-ietf-sacm-use-cases-05 Thread-Index: AQHO+1mY3hdWQNAUpECWXHLwWdSnFg== Date: Tue, 17 Dec 2013 18:55:47 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.155.84.102] Content-Type: multipart/alternative; boundary="_000_CED5DE31906C5ncamwingciscocom_" MIME-Version: 1.0 Subject: [sacm] review of draft-ietf-sacm-use-cases-05 X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2013 18:56:06 -0000 --_000_CED5DE31906C5ncamwingciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable In prep for the call, here are some comments to the draft .- Nancy Section Type Comments general tech/nit application can be an application that sits either = on the network or on the endpoint itself, so this needs to be clear 2 editorial worflow #1: "=85or the endpoint might trigger", we= can either clarify that either the application on the endpoint or on the (= network) can trigger the request for processing through an event. I think = the point is that it can be triggered manually (e.g. operator or user) or a= utomated through the application (either on the endpoint or on the network) 2 question #1 I'm okay with dropping user, but I think the clarif= ication of bi-directional trigger is needed 2 for the reference of this section, I believe application is= the application on the server (I don't think we want an endpoint to target= posture of other endpoints?) 2 the use of target and enpoint seems to be used to mean the = same thing? 2 question #2 given that this is a use case document, I suggest w= e not enumerate the known acquisition methods here 2 question #2 the evaluator may send the result of the comparison= as a simple "yes/no", or in a comprehensive form=85.I think the formats va= ry 2.1.1 nit I'm not sure that a requestor cares that the information co= me from a data store as in some cases the evaluation and information may be= obtained at the point it is requested (e.g. the posture assessment is done= right then vs. extracting it from a data store). nit "explicit use" is mainly because our charter speaks to post= ure only? I am concerned that we believe we will need multiple data m= odels for posture assessment? I can see different protocols and transports= , and different contextual data models for the general secure automation, b= ut the focus of this is for posture assessment only. nit By content you mean the set of attributes that can be colle= cted, published and queried? So "content" would be a collection of attribu= tes? We should probably add this to the terminology to clarify meaning and= intent. Also, content could be a set of attributes that map to only 1 index (e.g. e= ndpoint or mac address or device type?)?Content Retrieval seems to blur "co= ntent" as I'm not sure what a content entry could be then? nit Because a requestor or responder may provide information wi= thout having full physical store, I am not sure it makes sense to articulat= e it as such "e.g. content data store", as posture assessors especially dyn= amic ones may choose to do the collection realtime. technical one missing building block (which could be the inte= nt behind change detection?) is the asynchronous notification of content; t= hat is there is content publication and query, but we also discussed asynch= ronous notification (so it could be part of query or detection? or perhaps = explicitly clarified as its own building block?) 2.1.2 technical for the discovery, I describe it as an endpoint pro= file vs. type. That is, the type of assessment may be based on a set of at= tributes beginning with a device type (e.g. laptop, camera, printer, etc), = but other influencing attributes could be the device make, model, and perha= ps where or how the device is connecting (e.g. wired vs. wireless) nit we use "target" in section 2 to mean endpoint but this is a= group of endpoints, so could we just say that vs. "target"? question not sure what that means, prev collected data from = where? And for what purpose? I think we're OK with the blocks defined now 2.1.4 technical is posture attr query based on a specific individua= l target or a general profile to be used as targets are discovered? technical I'm not sure what content means in this building bl= ock? 2.1.5 nit I don't think this is an alternate use case to 2.1.4 but a = rather different one nit general comment on data store as the publisher of the infor= mation may or may not have a physical data store technical change detection I think the timeliness is really f= rom undeterministic timed query to realtime/on demand response question this is a separate use case where the posture infor= mation may be "mined" by different applications for different purposes than= just posture evaluation --_000_CED5DE31906C5ncamwingciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
In prep for the call, here are some commen= ts to the draft .- Nancy

Section Type Comments
general tech/nit application can be a= n application that sits either on the network or on the endpoint itself, so= this needs to be clear
2 editorial worflow #1: "= =85or the endpoint might trigger",&nb= sp; we can either clarify that either the application on the endpoint or= on the (network) can trigger the request for processing through an event.<= span style=3D"mso-spacerun:yes">  I think the point is that it can be triggered manually (e.g. operato= r or user) or automated through the application (either on the endpoint or = on the network)
2 question #1 I'm okay with droppi= ng user, but I think the clarification of bi-directional trigger is needed<= /td>
2 for the reference of= this section, I believe application is the application on the server (I do= n't think we want an endpoint to target posture of other endpoints?)
2 the use of target an= d enpoint seems to be used to mean the same thing?
2 question #2 given that this is a= use case document, I suggest we not enumerate the known acquisition method= s here
2 question #2 the evaluator may se= nd the result of the comparison as a simple "yes/no", or in a com= prehensive form=85.I think the formats vary
2.1.1 nit I'm not sure that a = requestor cares that the information come from a data store as in some case= s the evaluation and information may be obtained at the point it is request= ed (e.g. the posture assessment is done right then vs. extracting it from a data store).
nit "explicit use&q= uot; is mainly because our charter speaks to posture only?
I am concerned that = we believe we will need multiple data models for posture assessment?  I can see different protocols and transports, and different contextu= al data models for the general secure automation, but the focus of this is = for posture assessment only.
nit By content you mean = the set of attributes that can be collected, published and queried?  So "content" would be a collection of attributes?  We should probably add this to the terminology to clarify meaning an= d intent.
Also, content could be a set of attributes that map to only 1 index (e.g. e= ndpoint or mac address or device type?)?Content Retrieval seems to blur &qu= ot;content" as I'm not sure what a content entry could be then?
nit Because a requestor = or responder may provide information without having full physical store, I = am not sure it makes sense to articulate it as such "e.g. content data= store", as posture assessors especially dynamic ones may choose to do the collection realtime.
technical one missing building= block (which could be the intent behind change detection?) is the asynchro= nous notification of content; that is there is content publication and quer= y, but we also discussed asynchronous notification (so it could be part of query or detection? or perhaps explic= itly clarified as its own building block?)
2.1.2 technical for the discovery, I= describe it as an endpoint profile vs. type.  That is, the type of assessment may be based on a set of attributes = beginning with a device type (e.g. laptop, camera, printer, etc), but other= influencing attributes could be the device make, model, and perhaps where = or how the device is connecting (e.g. wired vs. wireless)
nit we use "target&= quot; in section 2 to mean endpoint but this is a group of endpoints, so co= uld we just say that vs. "target"? 
question not sure what that m= eans, prev collected data from where? And for what purpose?  I think we're OK with the blocks defined now
2.1.4 technical is posture attr quer= y based on a specific individual target or a general profile to be used as = targets are discovered?
technical I'm not sure what co= ntent means in this building block?
2.1.5 nit I don't think this i= s an alternate use case to 2.1.4 but a rather different one
nit general comment on d= ata store as the publisher of the information may or may not have a physica= l data store 
technical change detection I t= hink the timeliness is really from undeterministic timed query to realtime/= on demand response
question this is a separate u= se case where the posture information may be "mined" by different= applications for different purposes than just posture evaluation
--_000_CED5DE31906C5ncamwingciscocom_-- From Adam.Montville@cisecurity.org Tue Dec 17 11:00:07 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A03E61AE2A5 for ; Tue, 17 Dec 2013 11:00:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.889 X-Spam-Level: X-Spam-Status: No, score=-3.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, RCVD_IN_DNSWL_NONE=-0.0001, T_FILL_THIS_FORM_SHORT=0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wfQSTAlkBFgJ for ; Tue, 17 Dec 2013 11:00:04 -0800 (PST) Received: from mail1.bemta8.messagelabs.com (mail1.bemta8.messagelabs.com [216.82.243.208]) by ietfa.amsl.com (Postfix) with ESMTP id 646F61AE2B4 for ; Tue, 17 Dec 2013 11:00:04 -0800 (PST) Received: from [216.82.242.179:54769] by server-16.bemta-8.messagelabs.com id 72/64-20886-33F90B25; Tue, 17 Dec 2013 19:00:03 +0000 X-Env-Sender: Adam.Montville@cisecurity.org X-Msg-Ref: server-8.tower-86.messagelabs.com!1387306802!46509577!2 X-Originating-IP: [69.195.43.86] X-StarScan-Received: X-StarScan-Version: 6.9.16; banners=cisecurity.org,-,- X-VirusChecked: Checked Received: (qmail 16931 invoked from network); 17 Dec 2013 19:00:02 -0000 Received: from mail.msisac.org (HELO mail.msisac.org) (69.195.43.86) by server-8.tower-86.messagelabs.com with AES128-SHA encrypted SMTP; 17 Dec 2013 19:00:02 -0000 Received: from CISEXCHANGE2.msisac.org.local ([fe80::b899:f128:212e:984c]) by CISEXCHANGE1.msisac.org.local ([fe80::4f0:b68d:e779:38c3%13]) with mapi id 14.02.0347.000; Tue, 17 Dec 2013 13:57:43 -0500 From: Adam Montville To: "sacm@ietf.org" Thread-Topic: SACM WG Virtual Interim Meeting, Tuesday, December 17, 2013 Thread-Index: AQHO4WbFdet3TAQPJEWye46aFnoo25pY8V2g Date: Tue, 17 Dec 2013 18:57:32 +0000 Message-ID: <05BCCEB107AF88469B9F99783D47C1D60D67BB35@CISEXCHANGE2.msisac.org.local> References: <20131114182538.25032.72025.idtracker@ietfa.amsl.com> In-Reply-To: <20131114182538.25032.72025.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.252.39] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [sacm] FW: SACM WG Virtual Interim Meeting, Tuesday, December 17, 2013 X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2013 19:00:07 -0000 U0FDTSBJbnRlcmltIG1lZXRpbmcgaXMgc3RhcnRpbmcgaW4ganVzdCBhIGZldyBtaW51dGVzLiAg SGVyZSdzIHRoZSBXZWJFeCBpbmZvIGFnYWluIGluIGNhc2UgeW91IG1pc3NlZCBpdC4KCj4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0KPiBGcm9tOiBpZXRmLWFubm91bmNlLWJvdW5jZXNAaWV0 Zi5vcmcgW21haWx0bzppZXRmLWFubm91bmNlLQo+IGJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs ZiBPZiBJRVRGIFNlY3JldGFyaWF0Cj4gU2VudDogVGh1cnNkYXksIE5vdmVtYmVyIDE0LCAyMDEz IDEyOjI1IFBNCj4gVG86IElFVEYgQW5ub3VuY2VtZW50IExpc3QKPiBDYzogc2FjbUBpZXRmLm9y Zwo+IFN1YmplY3Q6IFNBQ00gV0cgVmlydHVhbCBJbnRlcmltIE1lZXRpbmcsIFR1ZXNkYXksIERl Y2VtYmVyIDE3LCAyMDEzCj4gCj4gVGhlIFNBQ00gV29ya2luZyBHcm91cCB3aWxsIGhvbGQgYSB2 aXJ0dWFsIGludGVyaW0gbWVldGluZyBvbiBUdWVzZGF5LAo+IERlY2VtYmVyIDE3LCAyMDEzIGF0 IDI6MDBwbSBFYXN0ZXJuIFN0YW5kYXJkIFRpbWUuCj4gCj4gV2ViRXggZGV0YWlscyBpbmNsdWRl ZCBiZWxvdzoKPiAKPiAqKioqIFlvdSBjYW4gZm9yd2FyZCB0aGlzIGVtYWlsIGludml0YXRpb24g dG8gYXR0ZW5kZWVzICoqKioKPiAKPiBIZWxsbyAsCj4gCj4gVG9waWM6IFNBQ00gV0cgVmlydHVh bCBJbnRlcmltIE1lZXRpbmcKPiBEYXRlOiBUdWVzZGF5LCBEZWNlbWJlciAxNywgMjAxMwo+IFRp bWU6IDI6MDAgcG0sIEVhc3Rlcm4gU3RhbmRhcmQgVGltZSAoTmV3IFlvcmssIEdNVC0wNTowMCkg TWVldGluZwo+IE51bWJlcjogMzE0IDMwNiA4NjEgTWVldGluZyBQYXNzd29yZDogMTIzNAo+IAo+ IAo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0KPiBUbyBqb2luIHRoZSBvbmxpbmUgbWVldGluZyAoTm93IGZyb20gbW9iaWxlIGRldmljZXMh KQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0KPiAxLiBHbyB0bwo+IGh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9FRD00NjI0 ODc3OCZVSUQ9MCZQVz1OT0RRMVlXUTAKPiBOMlZsJlJUPU1pTXhNUSUzRCUzRAo+IDIuIElmIHJl cXVlc3RlZCwgZW50ZXIgeW91ciBuYW1lIGFuZCBlbWFpbCBhZGRyZXNzLgo+IDMuIElmIGEgcGFz c3dvcmQgaXMgcmVxdWlyZWQsIGVudGVyIHRoZSBtZWV0aW5nIHBhc3N3b3JkOiAxMjM0IDQuIENs aWNrICJKb2luIi4KPiAKPiBUbyB2aWV3IGluIG90aGVyIHRpbWUgem9uZXMgb3IgbGFuZ3VhZ2Vz LCBwbGVhc2UgY2xpY2sgdGhlIGxpbms6Cj4gaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2ou cGhwP0VEPTQ2MjQ4Nzc4JlVJRD0wJlBXPU5PRFExWVdRMAo+IE4yVmwmT1JUPU1pTXhNUSUzRCUz RAo+IAo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0KPiBUbyBqb2luIHRoZSBhdWRpbyBjb25mZXJlbmNlIG9ubHkKPiAtLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCj4gQ2FsbC1pbiB0b2xs IG51bWJlciAoVVMvQ2FuYWRhKTogMS02NTAtNDc5LTMyMDgKPiAKPiBBY2Nlc3MgY29kZTozMTQg MzA2IDg2MQo+IAo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0KPiBGb3IgYXNzaXN0YW5jZQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KPiAxLiBHbyB0byBodHRwczovL2lldGYud2Vi ZXguY29tL2lldGYvbWMgMi4gT24gdGhlIGxlZnQgbmF2aWdhdGlvbiBiYXIsIGNsaWNrCj4gIlN1 cHBvcnQiLgo+IAo+IFlvdSBjYW4gY29udGFjdCBtZSBhdDoKPiBhdmV6emFAYW1zbC5jb20KPiAK PiAKPiBUbyBhZGQgdGhpcyBtZWV0aW5nIHRvIHlvdXIgY2FsZW5kYXIgcHJvZ3JhbSAoZm9yIGV4 YW1wbGUgTWljcm9zb2Z0Cj4gT3V0bG9vayksIGNsaWNrIHRoaXMgbGluazoKPiBodHRwczovL2ll dGYud2ViZXguY29tL2lldGYvai5waHA/RUQ9NDYyNDg3NzgmVUlEPTAmSUNTPU1JJkxEPTEmUkQK PiA9MiZTVD0xJlNIQTI9QUFBQUFua2l0R0w4L0dBRUNtUDJ5N3dSd3FkWk02Q0tLUmMtCj4gUzh5 NzhHN2NldDhKJlJUPU1pTXhNUSUzRCUzRAo+IAo+IFRoZSBwbGF5YmFjayBvZiBVQ0YgKFVuaXZl cnNhbCBDb21tdW5pY2F0aW9ucyBGb3JtYXQpIHJpY2ggbWVkaWEgZmlsZXMKPiByZXF1aXJlcyBh cHByb3ByaWF0ZSBwbGF5ZXJzLiBUbyB2aWV3IHRoaXMgdHlwZSBvZiByaWNoIG1lZGlhIGZpbGVz IGluIHRoZQo+IG1lZXRpbmcsIHBsZWFzZSBjaGVjayB3aGV0aGVyIHlvdSBoYXZlIHRoZSBwbGF5 ZXJzIGluc3RhbGxlZCBvbiB5b3VyCj4gY29tcHV0ZXIgYnkgZ29pbmcgdG8gaHR0cHM6Ly9pZXRm LndlYmV4LmNvbS9pZXRmL3N5c3RlbWRpYWdub3Npcy5waHAuCj4gCj4gU2lnbiB1cCBmb3IgYSBm cmVlIHRyaWFsIG9mIFdlYkV4Cj4gaHR0cDovL3d3dy53ZWJleC5jb20vZ28vbWNlbWZyZWV0cmlh bAo+IAo+IGh0dHA6Ly93d3cud2ViZXguY29tCj4gCj4gQ0NQOisxNjUwNDc5MzIwOHgzMTQzMDY4 NjEjCj4gCj4gSU1QT1JUQU5UIE5PVElDRTogVGhpcyBXZWJFeCBzZXJ2aWNlIGluY2x1ZGVzIGEg ZmVhdHVyZSB0aGF0IGFsbG93cyBhdWRpbwo+IGFuZCBhbnkgZG9jdW1lbnRzIGFuZCBvdGhlciBt YXRlcmlhbHMgZXhjaGFuZ2VkIG9yIHZpZXdlZCBkdXJpbmcgdGhlCj4gc2Vzc2lvbiB0byBiZSBy ZWNvcmRlZC4gQnkgam9pbmluZyB0aGlzIHNlc3Npb24sIHlvdSBhdXRvbWF0aWNhbGx5IGNvbnNl bnQgdG8KPiBzdWNoIHJlY29yZGluZ3MuIElmIHlvdSBkbyBub3QgY29uc2VudCB0byB0aGUgcmVj b3JkaW5nLCBkaXNjdXNzIHlvdXIKPiBjb25jZXJucyB3aXRoIHRoZSBtZWV0aW5nIGhvc3QgcHJp b3IgdG8gdGhlIHN0YXJ0IG9mIHRoZSByZWNvcmRpbmcgb3IgZG8gbm90Cj4gam9pbiB0aGUgc2Vz c2lvbi4gUGxlYXNlIG5vdGUgdGhhdCBhbnkgc3VjaCByZWNvcmRpbmdzIG1heSBiZSBzdWJqZWN0 IHRvCj4gZGlzY292ZXJ5IGluIHRoZSBldmVudCBvZiBsaXRpZ2F0aW9uLgo+IAo+IC4uLgoKLiAu IC4K From ncamwing@cisco.com Tue Dec 17 15:13:11 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0B9C1AD8F2 for ; Tue, 17 Dec 2013 15:13:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.038 X-Spam-Level: X-Spam-Status: No, score=-10.038 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LcXBqTS2kiZu for ; Tue, 17 Dec 2013 15:13:08 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id 962911AC7EE for ; Tue, 17 Dec 2013 15:13:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=51615; q=dns/txt; s=iport; t=1387321986; x=1388531586; h=from:to:subject:date:message-id:mime-version; bh=N51oN/53kXfDOeIX6N3tQtBgaK7n321gfmmaC+pObLY=; b=LYg9SXdf6LRJJI3OQ48h/bbqy72r2mVckYR64D4K4tYNqV1RKn23iQwH eD1heeJrVdHwu3xpo/fEJJ98OnEr+sSdqQAQbKORzwDPpiXTElYy2Zd7N guzH8ezDGiwcYOFM5mSm/FvEEJY8pgm8vlHRCeUa+NbVWB3V/5Bn+KBQw Q=; X-Files: SACM-UseCase-Requirements.xlsx : 36260 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlQFANjZsFKtJV2a/2dsb2JhbABZgkZEgQ26DhZ0ghwQgQsBCwFEMB8IBCGHdqFfqAQXk08BA5Azh2OSFIMrgio X-IronPort-AV: E=Sophos;i="4.95,504,1384300800"; d="xml'?xlsx'72,48?scan'72,48,72,217,208,48,145?jpeg'72,48,72,217,208,48,145,145?rels'72,48,72,217,208,48,145,145"; a="7488381" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-8.cisco.com with ESMTP; 17 Dec 2013 23:13:06 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id rBHND6EN021824 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 17 Dec 2013 23:13:06 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.231]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0123.003; Tue, 17 Dec 2013 17:13:05 -0600 From: "Nancy Cam-Winget (ncamwing)" To: "sacm@ietf.org" Thread-Topic: requirements spreadsheet Thread-Index: AQHO+32KHjiZ1wllSUK3bixQo/lKxw== Date: Tue, 17 Dec 2013 23:13:05 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.155.84.102] Content-Type: multipart/mixed; boundary="_004_CED61A7F90739ncamwingciscocom_" MIME-Version: 1.0 Subject: [sacm] requirements spreadsheet X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2013 23:13:11 -0000 --_004_CED61A7F90739ncamwingciscocom_ Content-Type: multipart/alternative; boundary="_000_CED61A7F90739ncamwingciscocom_" --_000_CED61A7F90739ncamwingciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, Attached is the spreadsheet I shared of proposed initial requirements and s= ome annotated notes of received feedback from today. Please feel free to provide more comments as I work towards incorporating t= hem into another revision of the draft. Thanks, nancy --_000_CED61A7F90739ncamwingciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <6B37EBB64D75FE4F97FD75BE28E0CB23@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi all,

Attached is the spreadsheet I shared of proposed initial requirements = and some annotated notes of received feedback from today.
Please feel free to provide more comments as I work towards incorporat= ing them into another revision of the draft.

Thanks, nancy
--_000_CED61A7F90739ncamwingciscocom_-- --_004_CED61A7F90739ncamwingciscocom_ Content-Type: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet; name="SACM-UseCase-Requirements.xlsx" Content-Description: SACM-UseCase-Requirements.xlsx Content-Disposition: attachment; filename="SACM-UseCase-Requirements.xlsx"; size=36260; creation-date="Tue, 17 Dec 2013 23:13:05 GMT"; modification-date="Tue, 17 Dec 2013 23:13:05 GMT" Content-ID: <977BD68BEC9CF44B88C1D20B55F97C0E@emea.cisco.com> Content-Transfer-Encoding: base64 UEsDBBQABgAIAAAAIQA8tZBocQEAAEwFAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADE lMtOwzAQRfdI/EPkLUrcdoEQatoFjyVUonyAiSeNqV/yuKX9eyYuRagKqSoqsYkVj+feMyOPx9ON 0dkaAipnSzYsBiwDWzmp7KJkr/PH/IZlGIWVQjsLJdsCsunk8mI833rAjLItlqyJ0d9yjlUDRmDh PFiK1C4YEek3LLgX1VIsgI8Gg2teORvBxjy2GmwyvodarHTMHja0vSOhdJbd7c61ViUT3mtViUig vI3yzrwAGnsS11Ye0OVfZAVlJnFslMer3x3ePSwOHJRpS0sBonqmdgYlIZuJEJ+EIXa+0fzDheWb c8uiv7QOQlfXqgLpqpWhrhXoAwiJDUA0ukhrYYSye+Ye/3QYeVqGZwZp60vCJ3KM/okj0l0Fnr5/ b0WSOVI4xq0GPHO1O9Fjzo0IIF9ioKk+O8BP7T4Our+z4DzS9Ac4vQv7MW2zc09CEKKC70HtuvTf jvR0nG54MHXQvk0SZIc3T2/h5BMAAP//AwBQSwMEFAAGAAgAAAAhAH3MVJ4NAQAA3QIAAAsACAJf cmVscy8ucmVscyCiBAIooAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAACskk1OwzAQhfdI3MGafeO0IIRQnW4QUncIhQNM7WliEv/IdiG9PYZF Q6QSVYKlPePn782b9WYwPXunELWzApZFCYysdErbRsBr/bS4BxYTWoW9syTgSBE21fXV+oV6TPlR bLWPLKvYKKBNyT9wHmVLBmPhPNlc2btgMOVjaLhH2WFDfFWWdzz81IBqosm2SkDYqhtg9dHnn/+i zQ0lVJiQSxdo4UMmC0lnL6zG0FASoJx8ztfxu6PI1MDPA91eDuT2ey3p0cmDIZvOeOY0JLKK1DwS ej9HtPxPoinzOJ+h5x8udDvnujmW1eUsv6/CGFdqD2ZnUfcjyCmoU61489R8xcUnS1l9AgAA//8D AFBLAwQUAAYACAAAACEAE/jtsPkAAABHAwAAGgAIAXhsL19yZWxzL3dvcmtib29rLnhtbC5yZWxz IKIEASigAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAvJLNasMwEITvhb6D2Hst2/2hhMi5 lEKubfoAQl5bJrYktNsfv31FQlMHgnsxPc4smvnY1XrzNfTiAyN13ikoshwEOuPrzrUK3nbPN48g iLWrde8dKhiRYFNdX61fsNecHpHtAomU4kiBZQ4rKclYHDRlPqBLk8bHQXOSsZVBm71uUZZ5/iDj NAOqs0yxrRXEbX0LYjeG1Px3tm+azuCTN+8DOr5QITlxYQrUsUVWcJBHs8gSKMjLDHdLMhCPfVri CeKo5+rvF623OmL9yjFdeEoxtedgiiVhPn3ck0Xk33WcLJKHyexhyn+GKX82I8++f/UNAAD//wMA UEsDBBQABgAIAAAAIQBckddi5QEAACgDAAAPAAAAeGwvd29ya2Jvb2sueG1sjFJNj5swEL1X6n+w fE8AB9IoCqzSfKiRqmq1anfPXjMJVrBNbVNYVf3vHUPZTdVLOWCPRzPvvZm3uetVTX6AddLonCbz mBLQwpRSX3L67etxtqLEea5LXhsNOX0BR++K9+82nbHXZ2OuBBtol9PK+2YdRU5UoLibmwY0Zs7G Ku4xtJfINRZ46SoAr+qIxfEyUlxqOnZY2//pYc5nKWBvRKtA+7GJhZp7pO8q2ThabM6yhsdREeFN 84Ur5N3XlNTc+UMpPZQ5zTA0Hfz1YNvmYytrzLIFi5c0Kl5V3lviKtOd9HWrtfEDXk5xWLz1ZmcU SnPuXgrf4iUksDZM51FC597ahJD0T1KXpkOUJMUOL1OI927IPMnSV4FEunx9+wTyUnnc0CoJj54/ PwQSKCQewKIbtGHEiDqcRA/6H+B7Ky2EqTncaFjCCYUmlNi1xIs9lUkgfVvTOiCC4w8V49rfqthN FQtV0QQpeC1wVuEY2qcxfpQIo0VrLYLvMPNnPtD7z84XGzxJa2VOf37I2OKQ7Rczlh0Xs212iGfJ csFmy/TIsnTHWJqxX5NfVP+PYZQU1jhz9nNhVDR6BT0mIugFDJZbjZYrNqpfb62oTntyrPkFVzbq QC6oZmIWTSYvfgMAAP//AwBQSwMEFAAGAAgAAAAhALdKfg2cAwAAliAAAA0AAAB4bC9zdHlsZXMu eG1s7FpbT9swFH6ftP8Q+R3SZMBGlQRtk6rxMIREJ+3VSZzUwpfIcaDl1+/YadqiUtoSD/EQHort +Fz8+ZyT+nOjqzln3gNRNZUiRsHpCHlEZDKnoozRn+nk5Bvyao1FjpkUJEYLUqOr5POnqNYLRu5m hGgPVIg6RjOtq7Hv19mMcFyfyooIeFJIxbGGrir9ulIE57UR4swPR6MLn2MqUKthzLNDlHCs7pvq JJO8wpqmlFG9sLqQx7PxdSmkwikDV+fBGc463bazpZ7TTMlaFvoU1PmyKGhGtr289C990JREhRS6 9jLZCB2jc1BtLIzvhXwUE/MIAFzOSqL6yXvADEZC5CdRJplUngZkwLHAjAjMSTvjJ2Y0VdQMFphT tmiHrZwFczmPU1iameUbP1pvkiiFgfey1eyxNXK5sH3GnKL4EoKqTGM0mYzsn5uV2Z2rYesoY6tA Ck3MwEASQUBrosQEOt6yPV1UEDECcq/deTtvz+xS4UUQnm8I+NYgBItUOeR6F8ImWtuhJGKk0LC9 ipYz81/LCj5TqTUkRhLlFJdSYAZNv5NYNmA5GWHsztSDv8VKd3gJyueFJxo+4fo6jxGUFhO4XRNW smy2CtsOGNglFIL8y0Ieriq2uGl4StTE1htrzY4aMNe9HxaAdf87o6XgxOQzuGcFbpXUJNO2HtqA 3uXPlw/mz4AP7OEQP2+O5yF+hvjpUw+H+BniZ4if//d9Y8ivIb+G/BryqzuovPd5Z6g/Q/05pP74 m3RASw5s8AJvowW8ebGXHwh2n8c76faEb7i6JQu362xvuIodXMNzXRuAGDYFd3yC96hwNSXzzpA/ L3YzG0d73q5jp+2ZVPQJFmn4xwzIDaLQR/PHEEmvQXLwBhywma7hPWZrj17Hnq09xvbZoUHcYfgG 2zbZIb03SMDnFOCqGHiG8QZCVTImH0nu/QJmUzEq7oFHt8kN75e0oUxTYVL9EnkzmufE3EoYVudw PbBsJ3ouHOmBGxQn/gQQS24UuUI6cAV14ArrwBXYoSuwQ1dgh67ADl2BHR4H9lbCQ13eiGdQ9mrC b4kD/95HHO7v+oh/7ScO5a2P9aAndkFP8IKe6AU94Qt64hf2xC/siR/czvXa//A4/G7MpRjrXrTP S5u9M1l/Z4c3eT5fX+PZp9pcqNsLvtW7HXTkpMAN09PVwxit279JThsOu7ScdUsfpLYqYrRut7PO 7E3l+gcFyT8AAAD//wMAUEsDBBQABgAIAAAAIQAw2XNOdgQAADcOAAAYAAAAeGwvd29ya3NoZWV0 cy9zaGVldDIueG1sjFdbj+I2FH6v1P8Q5R0SO0AAASvCaNWVdtVR9/YcgoFokjiNzQzTqv+959hD HDthtC+5nePv3L/Yqw/XsvCeWSNyXq19Mg59j1UZP+TVae1///ZxNPc9IdPqkBa8Ymv/lQn/w+b3 31YvvHkSZ8akBwiVWPtnKetlEIjszMpUjHnNKpAceVOmEl6bUyDqhqUHtagsAhqGs6BM88rXCMvm VzD48Zhn7IFnl5JVUoM0rEgl+C/OeS1uaGX2K3Bl2jxd6lHGyxog9nmRy1cF6ntltvx0qniT7guI +0omaXbDVi89+DLPGi74UY4BLtCO9mNeBIsAkDarQw4RYNq9hh3X/pYsdzTyg81KJehHzl5E59nD fO85f0LBp8PaDwFCsIJlGLkn/nZAghZlszLPN8SPqiqPjbdPBdvx4md+kGcoP1T/wI7ppZB/8Zc/ WH46S/g6hbgx/OXh9YGJDPKO5sHTjBeACFevzKF7IkhaelX3Fw0YT8fziIYRoYAh5CtmkvpedhGS lzejiBRoKOX0QyrTzarhLx50BIF1dYr9RZaAj/fbeh0EfgAfUHeLykoBHBTw9XlDVsEzor9pJH2N yNbYaY2Z77UYtNUIwKnWM4jD8Qxi1JEZzzxMYIS10h7iorUPii36vEVXGklfY2Fr7LRG3MEgYati uYgJ6yQPfZkZXyKVIROdtg9rWt8mLayS7XQBwH6rMW01LMMTy/At+MmgQdBt4YhrEYFUy7Qq8bBF 7C8n1E7ap0OWd7jGBiemX6x4oB066Ld4ZoOoqOugmhxbqFDCDqrbKvEQemKV3WRf1wcBHdOmvS3T yOr30zUfNA1r2ioQ1zQCOqZnw5Va9E1PsD4qhC1IjRFTa92bltAZnB3iOh6YybGCR5rrRP9mOsHP xrYLrxbZ+PTO2BHkECe7JsSdEjtId/qO4Kw7SIt2ghMUv+OxJoquDr3TDmSAKYzHCYrfsdOnBXqn 44lNDKrlDSMlKG7tUJcL1GInb6YN7QoP0IGxs8U/mrFj+lR3mS3tedFnDWr61PbCpg1nwBPS/cmQ Xr/1eYQaHdvOu0SSkC5nOMHuUOiMDb03Nu+TBunyQ2Qa4C2pXWm/tH36iO4Nl80f7fB2uaGP3yeH 6M7I0UFy2OLntmUiM0Y6OkvaK6WCtBs3Mm1llZIOUIf5jyUobr3o29F7l+7AR3cGhCI3OMTStdPF 6GVTLXbiMX1lxzNALF07XWIxECqpuBt2WzNyJ01vbfWOsU5P7EvanPJKeAU7Qp7CcQzT2uhtrH6R vFY7xD2XsAVVj2c4lDDYPoZjUD5yLm8vsC9FzK9MXmqPNzlsfNU5Y+3XvJFNmkvfO8P3fzgIioc6 X/sTupgsZjFdQALhVCXzrC8AWHaVn4VUd+/SwLp/Z5MwpHFERttZEo6meKGzOBzFMSVJvAsXszD8 73b+KGGT7Ry3Bg8fZZoF7Joxddia68PWZlVel4+ff3hf+AF249DWf1bsEcJUzz+/gsPqETfl4Ka+ KmeD9si3+R8AAP//AwBQSwMEFAAGAAgAAAAhADAPiGsRBwAA3h0AABMAAAB4bC90aGVtZS90aGVt ZTEueG1s7FlPbxtFFL8j8R1Ge29jJ3YaR3Wq2LFbaNNGsVvU43g99k4zu7OaGSfxDbVHJCREQVyQ uHFAQKVW4lI+TaAIitSvwJuZ3fVOPG6cEkBAc2i9s7/35r3f+zN/9uq145ihQyIk5UkzqF6uBIgk IR/SZNwM7va7lzYCJBVOhpjxhDSDKZHBta1337mKN1VEYoJAPpGbuBlESqWbKysyhGEsL/OUJPBu xEWMFTyK8cpQ4CPQG7OV1UplfSXGNAlQgmNQe2c0oiFBfa0y2MqVdxg8JkrqgZCJnlZNHAmDHR5U NUJOZZsJdIhZM4B5hvyoT45VgBiWCl40g4r5C1a2rq7gzUyIqQWyJbmu+cvkMoHhwaqZU4wHxaTV bq1xZafQbwBMzeM6nU67Uy30GQAOQ/DU2lLWWetuVFu5zhLI/pzX3a7UKzUXX9K/Nmdzo9Vq1RuZ LVapAdmftTn8RmW9tr3q4A3I4utz+Fpru91ed/AGZPHrc/julcZ6zcUbUMRocjCH1gHtdjPtBWTE 2Q0vfAPgG5UMPkNBNhTZpacY8UQtyrUYP+CiCwANZFjRBKlpSkY4hCxu43ggKNYT4E2CS2/sUCjn hvRcSIaCpqoZvJ9iqIiZvlfPv331/Cl69fzJycNnJw9/OHn06OTh91aXI3gDJ+Oy4MuvP/n9yw/R b0+/evn4Mz9elvE/f/fRTz9+6gdCBc0sevH5k1+ePXnxxce/fvPYA98WeFCG92lMJLpNjtA+j8E3 Q4xrORmI80n0I0wdCRyBbo/qjooc4O0pZj5ci7jk3RPQPHzA65MHjq29SEwU9cx8M4od4C7nrMWF l4Cbeq4Sw/1JMvZPLiZl3D7Gh7652zhxQtuZpNA186R0uG9HxDFzj+FE4TFJiEL6HT8gxOPdfUod XndpKLjkI4XuU9TC1EtJnw6cRJoJ3aAxxGXq8xlC7XCzew+1OPN5vUMOXSQUBGYe4/uEOTRexxOF Y5/KPo5ZmfBbWEU+I3tTEZZxHakg0mPCOOoMiZQ+mTsC/C0F/SaGfuUN+y6bxi5SKHrg03kLc15G 7vCDdoTj1Ift0SQqY9+TB5CiGO1x5YPvcrdC9DPEAScLw32PEifcZzeCu3TsmDRLEP1mIjyxvE64 k7+9KRthYroMtHSnU8c0eV3bZhT6tp3hbdtuBtuwiPmK58apZr0I9y9s0Tt4kuwRqIr5Jepth37b oYP/fIdeVMsX35dnrRi6tN6Q2L222XnHCzfeI8pYT00ZuSXN3lvCAjTswqCWM4dOUhzE0gh+6kqG CRzcWGAjgwRXH1AV9SKcwr69GmglY5mpHkuUcgnnRTPs1a3xsPdX9rRZ1+cQ2zkkVrt8aIfX9HB+ 3CjUGKvG5kybT7SmFSw72dqVTCn49iaTVbVRS89WNaaZpujMVrisKTbncqC8cA0GCzZhZ4NgPwQs r8OxX08N5x3MyFDzbmOUh8VE4a8JUea1dSTCQ2JD5AyX2Kya2OUpNOefds/myPnYLFgD0s42wqTF 4vxZkuRcwYxkEDxdTSwp1xZL0FEzaNRX6wEKcdoMRnDShZ9xCkGTei+I2Riui0IlbNaeWYumSGce N/xZVYXLiwUF45RxKqTawTKyMTSvslCxRM9k7V+t13SyXYwDnmaynBVrG5Ai/5gVEGo3tGQ0IqEq B7s0ormzj1kn5BNFRC8aHqEBm4h9DOEHTrU/QyrhwsIUtH6A2zXNtnnl9tas05TvtAzOjmOWRjjr lvp2Jq84Czf9pLDBPJXMA9+8thvnzu+KrviLcqWcxv8zV/RyADcIa0MdgRAudwVGulKaARcq4tCF 0oiGXQHrvukdkC1wQwuvgXy4Yjb/C3Ko/7c1Z3WYsoaDoNqnYyQoLCcqEoTsQVsy2XeGsmq29FiV LFNkMqpkrkyt2QNySFhf98B13YMDFEGqm26StQGDO51/7nNWQYOx3qOU683pZMXSaWvg79642GIG p07tJXT+5vwXJhar+2z1s/JGPF8jy47oF7NdUi2vCmfxazSyqd7QhGUW4NJaazvWnMer9dw4iOK8 xzBY7GdSuAdC+h9Y/6gImf1eoRfUPt+H3org84PlD0FWX9JdDTJIN0j7awD7Hjtok0mrstRmOx/N Wr5YX/BGtZj3FNnasmXifU6yi02UO51TixdJdsaww7UdW0g1RPZ0icLQKD+HmMCYD13lb1F88AAC vQO3/hNmv07JFJ5MHaR7wmTXgA+n2U8m7YJrs06fYTSSJftkhOjwOD9/FEzYErJfSPItskFrMZ1o heCa79DgCmZ4LWpXy0J49WzhQsLMDC27EDYXaj4F8H0sa9z6aAd422St17q4cqZY8mcoW8J4P2Xe k8+ylNmD4msD9QaUqePXU5YxBeTNJx584RQYjl49039h0bGZblJ26w8AAAD//wMAUEsDBBQABgAI AAAAIQCzYW4mxwQAAI4OAAAYAAAAeGwvd29ya3NoZWV0cy9zaGVldDEueG1sjFfbjuM2DH0v0H8w /D7xJY6dBEkWEzuLLjCLDjrt7rPiKIkxtuXaykymRf+9pBRblhQs9sU3HpKHFElLq0/XqnTeaNsV rF67wcR3HVrn7FDUp7X715+fH+au03FSH0jJarp2P2jnftr8+svqnbWv3ZlS7oCFulu7Z86bped1 +ZlWpJuwhtYgObK2Ihxe25PXNS0lB6FUlV7o+7FXkaJ2pYVl+zM22PFY5DRj+aWiNZdGWloSDvy7 c9F0vbUq/xlzFWlfL81DzqoGTOyLsuAfwqjrVPnyy6lmLdmXEPc1iEje2xYvlvmqyFvWsSOfgDlP ErVjXngLDyxtVocCIsC0Oy09rt3HYLkLA9fbrESCvhX0vRs9O5zsX2hJc04PsE6uw1nzRI88pWUJ yonr4ILsGXtFzS+A8cFHJzTQB8l58UYlehfMYFH/Fm7xGXx6g9Pxc0/gs1jE59bZk46mrPxeHPgZ WECxHOiRXEr+B3v/jRanM4evYFwkaHn4yGiXwzIhGXCSsxIswtWpCiw2yDG5ivt7b3Ayn4b+NAiR IP/AxIc3TakzvenA/aYzXYygTn7pOKt6fppqdFOF+011Np3EceTHmrcfmQBWgjHcbyaicMTYdu7J kEVyM8LJZtWydwcKHWLvGoJtEywxVvFF6stk4wfIFWIfEbx2Y1jztdvB17fNdL7y3mCl8htkKyEQ 2gDxdUQqEZC3AREZkOwOJNCt7CQEroOVWFHxILghwlCPECtjgSUpQ0Iprq2yM13orrY9BOMNdVna y5R6ZECyO5CpbmVnQ2JFQgsG0jZeLgwmVsGgVA8minRXWxsSJDoktSHRTIfsbEii1lAjDJXwA8Io NQjHuqutDbEI25DIiCm7A1HlIiphZ0MSVXRaTNgnqmf6ypfdI6aEhoZ2GaEdXLJoNtQfSo0MqKUX xLY2JDSSlNqQmeIurGSxmK7jxoBRbRJLFDGU6sRmRmVvbYhFzIbEBvcssYjhn17l18wYSg1iRj9t 70CMPkjvQIwiz+YWMZzwili/8PgVCeGPBcdktrAU8Qc10hQhjYaQEBsxGWna3sMYlZLew5idABj8 zY4LIcBhquIS7EZTRYjXLmRsmLUzo3m2NwwMMoWx2MmZPcbEamrI1IEdix1OR8WuT3Jgd1qAY0kh zcIRYj3LsdEl6T2MUfYZYCyOODwMzyqDaWDPltio2QwwllV90Ih4VIemYvNkxGPWsNxUidyKzdaw Oonyr9eCPq6GbIvxcbMDEGVHZUe3M54uUT/ussDu9gBbsc/dCGm3XzDuvxHS7rdw3G+QfOM/KcR6 5mZGJaZ3MLExRDLAmGsWjnvJ8pwKse45NjsUMINVuR2WO7aGnOhX0p6KunNK2HHDZnYC5eC0crsr X2A3LrZwe8Zh/ykez3DWoTCX/AmAj4zx/gW8oM0Xyi+Nw9oCNsji+LJ2G9bylhQcMgff/2EgKLOm gD9XuIgWcRIuoCnhsMaL3BaAWXrlTx0Xd+fSgt6/sL31w2QaPDzGW/9hhpcwTvyHJAmDbZL6i9j3 /+uPNRVsxo1T3N0zTUVyj15zKs5wc3mG26yq6/L56ZvzlR1g1w6F8HtNnyFM8fz9BQiLR0wx0JRX QdYbTpKb/wEAAP//AwBQSwMECgAAAAAAAAAhAO3Qg5NIWAAASFgAABcAAABkb2NQcm9wcy90aHVt Ym5haWwuanBlZ//Y/+AAEEpGSUYAAQEBAEgASAAA/+IHuElDQ19QUk9GSUxFAAEBAAAHqGFwcGwC IAAAbW50clJHQiBYWVogB9kAAgAZAAsAGgALYWNzcEFQUEwAAAAAYXBwbAAAAAAAAAAAAAAAAAAA AAAAAPbWAAEAAAAA0y1hcHBsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAALZGVzYwAAAQgAAABvZHNjbQAAAXgAAAVsY3BydAAABuQAAAA4d3RwdAAABxwAAAAU clhZWgAABzAAAAAUZ1hZWgAAB0QAAAAUYlhZWgAAB1gAAAAUclRSQwAAB2wAAAAOY2hhZAAAB3wA AAAsYlRSQwAAB2wAAAAOZ1RSQwAAB2wAAAAOZGVzYwAAAAAAAAAUR2VuZXJpYyBSR0IgUHJvZmls ZQAAAAAAAAAAAAAAFEdlbmVyaWMgUkdCIFByb2ZpbGUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAG1sdWMAAAAAAAAAHgAAAAxza1NLAAAAKAAAAXhockhS AAAAKAAAAaBjYUVTAAAAJAAAAchwdEJSAAAAJgAAAex1a1VBAAAAKgAAAhJmckZVAAAAKAAAAjx6 aFRXAAAAFgAAAmRpdElUAAAAKAAAAnpuYk5PAAAAJgAAAqJrb0tSAAAAFgAAAshjc0NaAAAAIgAA At5oZUlMAAAAHgAAAwBkZURFAAAALAAAAx5odUhVAAAAKAAAA0pzdlNFAAAAJgAAAqJ6aENOAAAA FgAAA3JqYUpQAAAAGgAAA4hyb1JPAAAAJAAAA6JlbEdSAAAAIgAAA8ZwdFBPAAAAJgAAA+hubE5M AAAAKAAABA5lc0VTAAAAJgAAA+h0aFRIAAAAJAAABDZ0clRSAAAAIgAABFpmaUZJAAAAKAAABHxw bFBMAAAALAAABKRydVJVAAAAIgAABNBhckVHAAAAJgAABPJlblVTAAAAJgAABRhkYURLAAAALgAA BT4AVgFhAGUAbwBiAGUAYwBuAP0AIABSAEcAQgAgAHAAcgBvAGYAaQBsAEcAZQBuAGUAcgBpAQ0A awBpACAAUgBHAEIAIABwAHIAbwBmAGkAbABQAGUAcgBmAGkAbAAgAFIARwBCACAAZwBlAG4A6ABy AGkAYwBQAGUAcgBmAGkAbAAgAFIARwBCACAARwBlAG4A6QByAGkAYwBvBBcEMAQzBDAEOwRMBD0E OAQ5ACAEPwRABD4ERAQwBDkEOwAgAFIARwBCAFAAcgBvAGYAaQBsACAAZwDpAG4A6QByAGkAcQB1 AGUAIABSAFYAQpAadSgAIABSAEcAQgAggnJfaWPPj/AAUAByAG8AZgBpAGwAbwAgAFIARwBCACAA ZwBlAG4AZQByAGkAYwBvAEcAZQBuAGUAcgBpAHMAawAgAFIARwBCAC0AcAByAG8AZgBpAGzHfLwY ACAAUgBHAEIAINUEuFzTDMd8AE8AYgBlAGMAbgD9ACAAUgBHAEIAIABwAHIAbwBmAGkAbAXkBegF 1QXkBdkF3AAgAFIARwBCACAF2wXcBdwF2QBBAGwAbABnAGUAbQBlAGkAbgBlAHMAIABSAEcAQgAt AFAAcgBvAGYAaQBsAMEAbAB0AGEAbADhAG4AbwBzACAAUgBHAEIAIABwAHIAbwBmAGkAbGZukBoA IABSAEcAQgAgY8+P8GWHTvZOAIIsACAAUgBHAEIAIDDXMO0w1TChMKQw6wBQAHIAbwBmAGkAbAAg AFIARwBCACAAZwBlAG4AZQByAGkAYwOTA7UDvQO5A7oDzAAgA8ADwQO/A8YDrwO7ACAAUgBHAEIA UABlAHIAZgBpAGwAIABSAEcAQgAgAGcAZQBuAOkAcgBpAGMAbwBBAGwAZwBlAG0AZQBlAG4AIABS AEcAQgAtAHAAcgBvAGYAaQBlAGwOQg4bDiMORA4fDiUOTAAgAFIARwBCACAOFw4xDkgOJw5EDhsA RwBlAG4AZQBsACAAUgBHAEIAIABQAHIAbwBmAGkAbABpAFkAbABlAGkAbgBlAG4AIABSAEcAQgAt AHAAcgBvAGYAaQBpAGwAaQBVAG4AaQB3AGUAcgBzAGEAbABuAHkAIABwAHIAbwBmAGkAbAAgAFIA RwBCBB4EMQRJBDgEOQAgBD8EQAQ+BEQEOAQ7BEwAIABSAEcAQgZFBkQGQQAgBioGOQYxBkoGQQAg AFIARwBCACAGJwZEBjkGJwZFAEcAZQBuAGUAcgBpAGMAIABSAEcAQgAgAFAAcgBvAGYAaQBsAGUA RwBlAG4AZQByAGUAbAAgAFIARwBCAC0AYgBlAHMAawByAGkAdgBlAGwAcwBldGV4dAAAAABDb3B5 cmlnaHQgMjAwNyBBcHBsZSBJbmMuLCBhbGwgcmlnaHRzIHJlc2VydmVkLgBYWVogAAAAAAAA81IA AQAAAAEWz1hZWiAAAAAAAAB0TQAAPe4AAAPQWFlaIAAAAAAAAFp1AACscwAAFzRYWVogAAAAAAAA KBoAABWfAAC4NmN1cnYAAAAAAAAAAQHNAABzZjMyAAAAAAABDEIAAAXe///zJgAAB5IAAP2R///7 ov///aMAAAPcAADAbP/hAHRFeGlmAABNTQAqAAAACAAEARoABQAAAAEAAAA+ARsABQAAAAEAAABG ASgAAwAAAAEAAgAAh2kABAAAAAEAAABOAAAAAAAAAEgAAAABAAAASAAAAAEAAqACAAQAAAABAAAB AKADAAQAAAABAAAAmwAAAAD/2wBDAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQH/2wBDAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQH/wAARCACbAQADAREAAhEB AxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQAAAF9 AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6 Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ip qrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEB AQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJB UQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RV VldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6 wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD+o/Q5fCw0 XShc6Foc9wNOsxNNNp1s8ssvkJvkkdoizuzZLOxJZiWJJNX03XzUb6+rT/rruB3HhbQfDHinVotL t9K8GacGBknvdVTSbG3ggUgSSKtz5Ul3IgYYt7VZZCSpk8qItKo/Vf8AgMX+V/xA639nvw74O8Tf Gj9pXwvqegeDfEWifD3UPhxoPhuaPSLC6t/s19outa1e3jhjdWv9pXd1f/Z72ez8mOWDT7CB4t1p uaW79vkB9g/8Kk+F3/RPPBn/AITmlf8AyLSA8v8AjV4R8L+BvhX438TeBfgt4c8ZeOrLRJrbwP4X 0zwjpN5ca14z1eWHRvCtnOjQxQW+lnX9Q0+TW9RvJ7bT9J0aO/1TUbq1sLO4uIwDyj9j/wAJar4j +E8+h/tCfCXTrD4wfDnxj4m8BeKta8Q/D3wZ4fbx5Z6ddR6r4P8AH+nW3hIX/gyWHxL4K1nw9Pq/ /CI6nqWhaf4rh8RaLbXIk0yaGIA+p/8AhUnwu/6J54M/8JzSv/kWgDzbx98M/h5Za98JIbTwP4Vt odU+JUun6jFBoWnRR31iPhx8RL8Wl2qW6i4thfWNleCGUNH9ptLebb5kKMAD0n/hUnwu/wCieeDP /Cc0r/5FoAP+FSfC7/onngz/AMJzSv8A5FoA/Nj9mS1+I3ib9rj9o3wV8Ufh5PL8JdB1D4hj4fJq nwV0jSPCel2+ifEiz0rwktp41k+HnhIzT6z4OvTdaJp+n+JvifH4nsLLV/EOqan4PutMtNJ1gA/S f/hUnwu/6J54M/8ACc0r/wCRaAOC+Kvwx+HWm/C/4kajp/gbwnZX9h4C8YXtje2ug6bBdWl5a+Ht Rntrq3njt1khngmjSWGVGDxyIrqQwBoA63SfhP8ADGXStMlk+H3g55JNPspJHfw7pTM7vbRszMxt iWZmJJJJJJJJzQBof8Kk+F3/AETzwZ/4Tmlf/ItAB/wqT4Xf9E88Gf8AhOaV/wDItAB/wqT4Xf8A RPPBn/hOaV/8i0AH/CpPhd/0TzwZ/wCE5pX/AMi0AH/CpPhd/wBE88Gf+E5pX/yLQAf8Kk+F3/RP PBn/AITmlf8AyLQAf8Kk+F3/AETzwZ/4Tmlf/ItAB/wqT4Xf9E88Gf8AhOaV/wDItAHwx8N9BsdW /aZ+Kvhr4raT4j8KTaL8RLvS/g18M9H+Cuk/8Kf8Y/B9Ph1oGoaf411P4hR/C/WP7S1q88UXPi1t Wlm+JOgSaHrWjab4a/siGF44dfAPuf8A4VJ8Lv8Aonngz/wnNK/+RaAD/hUnwu/6J54M/wDCc0r/ AORaAD/hUnwu/wCieeDP/Cc0r/5FoAP+FSfC7/onngz/AMJzSv8A5FoAP+FSfC7/AKJ54M/8JzSv /kWgA/4VJ8Lv+ieeDP8AwnNK/wDkWgA/4VJ8Lv8Aonngz/wnNK/+RaAD/hUnwu/6J54M/wDCc0r/ AORaAPC/2nvh54E8Pfs5fHXXtB8HeGtH1vR/hN491LSdW0zRdPstR03UbLw1qVxZ31jeW8CT213a zok1vPC6yRSorowYA0AYfgL9lT4R+JfBHhHxDqcXjY6jrfhzRtUvzafEbxvY2pvL6wgubg29laa5 Da2kBlkcxW1tFHBCmI4kVFAp3fd/eB4R8D/2efgb8fm+MKeP/AqT6t8Hvjl45+EOnvY/Evx54mt7 jSNB0/w3qtnqhn17UvtVle6imtmPULa3jitDcWRMJkQBqW4Hn37ZHjnwv/wTH+DOq/ET4FfCq88U 6r4v+JXwA+G8XhT/AISn4olJ734k+MvFPh19X/s/4faV4v8AG/iGbR7VJrqy8OeG/D2p6nqN1LKl nbvNPIsgB4R4K/4Lb/s+eItD0VNS+EH7ST+Nbzwb+zncana+DfF2l6/8MU+LP7RGh/AXWdI+FOk/ GXXviJ4R8Fq+kR/tDeD5l8Z+L7jwf4U1jT9H8W3FhqDXGjJaXoB1/jL/AIKweCk+JP8AwTW8HfC3 4VfEjxdov/BRTwt4L8eaRqPiX4nXfhvX/hr4R8c+LfAWk6Tc6voln4i1m21TU7fw5rnjXW7+z0/U 57YXfhW2tbO+vLW6vruxAP2q/wCER0//AKCXin/wr/E3/wAtaAD/AIRHT/8AoJeKf/Cv8Tf/AC1o A5PxL4M0iTUvA7TXXiGd4PFkkts83inxFK9rOfCfiqE3Fsz6mWguDBLPbmaIrJ5E88O7y5pFYA+c v2ofjzoX7NHin9mfS9c+1Dwx8d/i54x+GXiDxf4m+KfiLwxpXgaLw5+zz8afjXpupve3d82n3Nzr mr/Cqy8JQWd9eWCn+3pLq3luLq1hs7gA/MPw3/wXM+AEPw48Caz8Rvgx+09pfxV8V+Df2evEf/Cr fA+oXfinVvEM3xw+AOuftAXuq/Dey1DxvoniDxR4F8L6F4U8V+GrTxPfaPpD+KfGejz+GNDsbnU4 L5LQA+kvjB/wUCsvhX+0R8ePh/faP4d0X4RfsufCD4YfE74qa58Rf2gPEPgD4vfEG5+M3h3x7rng /SPgR4H8QGw8I67baJc+DLTRfE2o+NPHXhZJ9a1nUNI0tP7Q8OSxamAeFT/8Fz/2RofC2jeJh8Of 2rTJ4r8F+BfE/gfw9Jc2tv4h8eax4z+JN38K73wn4QsZfiUq6zdeB/FtlNYeNtet5T4Z0a5m0rTv 7Wm1TxD4csdXAP2B05vDXxR+B1j4/soPiBp+h/EX4UWvjC08P+MdW8U6Vr1lpXi7wgmtQaN4q8PX uqPJpur21pqC2WuaNd73s7xLqxn3NG+QD02y8IacLO0C6j4nVRawAKvi7xKqqBEmAqjVAFUDgAcA cCgC1/wiOn/9BLxT/wCFf4m/+WtAB/wiOn/9BLxT/wCFf4m/+WtAB/wiOn/9BLxT/wCFf4m/+WtA B/wiOn/9BLxT/wCFf4m/+WtAB/wiOn/9BLxT/wCFf4m/+WtAB/wiOn/9BLxT/wCFf4m/+WtAH898 v/Banw/8OfFPiGy+Nnwn1bUPD2seJPjr4e+FGn/s/fGbxb8R/ij/AGp8Gv2xp/2QtN8OfGLwV4ih 8IaX8PtU+JWqBfHngjWE8UX+iaro+m+JNGhLa1pdrBqIB9DaH/wV2/Zz8RfETTfhVYfDT9p7TvH+ s+JvDmk6b4S8Z694f+HfiEeF9Z+Fl58XNR+ImqaX49+LPhybSPDGj+HtO1PTbO1vSviXxl4n0vV/ D/gbQvEeo6Hr0WlgHh1z/wAFxfgl4aT/AISjx18Gv2jdF8F+KPhf8L/jJ4A0aPxT4Vh+IEHw08a/ CD4i/HjU/GPjIah8cYfCTJJ8KvAy+KfC3hDwvrOp+PNTlvofDDeHJfFF1HpcABbs/wDgtB4G0/xP rOm+Ofgh8XfD4XUPiX4V8J+C9K+Kvh7VfGPibxN8Mvj7+0H8JdT1G68Uaz8UfC/w78IaLceGv2ef GHiebR/GeqeH9eg1i2GiaPL4kt9Z8J6h4iAPsj9kX/gol8Bf2zfizqfws+GnhP8AaH0BI/AviTx/ 4Y8b+OtTGj+F/G2k+C5/g9D4ytdGtLH4har4u0zUvDv/AAvn4Y/abfxV4Z0BbuTV9Sh0+W6k0S+C gH6Uf8Ijp/8A0EvFP/hX+Jv/AJa0AH/CI6f/ANBLxT/4V/ib/wCWtAB/wiOn/wDQS8U/+Ff4m/8A lrQAf8Ijp/8A0EvFP/hX+Jv/AJa0AH/CI6f/ANBLxT/4V/ib/wCWtAB/wiOn/wDQS8U/+Ff4m/8A lrQB5x8YfBGiXnwo+JFpfza7qNlc+CfE0F3Yah4m8Q3lje20ukXaTWt5aXGpPBc208bNHPBMjRyx syOpUkUAcr8NvDXxbufh74IuNL+KXh7TdNm8K6FJYafP8MxqE1laPptube1lv/8AhNLP7ZJBEVje 6+y25nZTIYYy20AF7w38HPG3g19Wk8IeMfhj4Vk16+Op67J4b+BGk6G+takxkLahqzaZ4ytW1G+Y yyk3d4ZpyZJCZDvbIBftvAniPWPEV9aeOfEPhHxncaVH4I8TaRPf/DWwFtpeq6NrHiW60LU7Gyvt e1YWuuaJqMUmoabrVvPFe2k8sb2pt5bdZZADnbj9kz4K3cGp2t18Iv2fbm21rw3pXg3WLe4/Z++H 00GreENBvNP1DQ/CmpwyW7R3/hvRr/SNKvtK0O6WXS9OvNM0+5tLWGaytnjANL4b/s1+BfhL4Q+F /gXwFongvSPD3wW8KaR4I+Fq3fguHXNY8F+F9C09tK0vStG8Sa5rGo+IIY7bT3ltvNbUmuJY5pxN K5ml3AHsX9meLv8AoarD/wAJlf8A5cUAH9meLv8AoarD/wAJlf8A5cUAc1r+neKRf+ERJ4nsnZvE riJl8OIvly/8I14jbewOrN5ilFkjKZXmQPuym1gCh4++EmkfFbw7N4Q+KOmfDz4k+E7i6tL6fwv4 ++GGgeMfDs97YS+dY3k2ieIrrUdNkurKb97aXD2zTW0v7yF0bmgDjNY/Ze+E3iE66df+GPwJ1w+K L/w7qniY6x8CPAupnxFqfhCzl07wnqOum9jnOr3/AIX0+eax8O3mofaLjRLOaW202S2hkdCAaXjX 9nb4e/EnWrTxJ8RfAvwb8feIrDQNS8KWOv8AjX4LeDvFOtWXhbWIriHV/DVpquu/b7620DVYby7i 1LR4Z006+iuriO6t5UnlDAGA37JfwVew1LSW+EP7PjaXrGh6d4Y1fTW/Z++HxsNV8NaRqseu6T4e 1KzNube+0PS9bhh1jTtJuY5bCy1WKPULa3iu0WYAHpWt+Hdb0fwRq+mafrWjWGj6X4Vv7Cx0rTfC Vtp9lZaZY6RLb22n2FtbamlvZWttaxJbWsEEKw20KJHFGERVoA6K10zxZ9lttviqxC/Z4doPhpCQ vlrgE/2xycdT60AWP7M8Xf8AQ1WH/hMr/wDLigA/szxd/wBDVYf+Eyv/AMuKAD+zPF3/AENVh/4T K/8Ay4oAP7M8Xf8AQ1WH/hMr/wDLigA/szxd/wBDVYf+Eyv/AMuKAD+zPF3/AENVh/4TK/8Ay4oA 8Yb9l34TPZeO9Nf4YfAl9O+KWpRaz8TbBvgR4Fay+I2rwalJrMGq+O7UxmDxdqUOsTTarFfeII9Q uo9SlkvklF1I0pAI3/ZY+EMhYyfCz4CuX8SaD4xcv8BfAbF/F/hazl07wx4qbdEd3iTw5p889hoO uHOp6RZzS2un3VvBI6MAct40/Yn+A/xE8S/DLxb40+F/wh8Qax8HZYpvh0t78K9FOkeH3s/DknhL RQfD8d8mhanF4W8PyyWHgyHVtPvYvBmRceF00m5UTAA6vV/2W/hH4gh8U2+vfC74D63B451Nta8b Qav8B/AmpQ+MdZfVU119W8Ux3kUyeINTfXI01lr/AFZbu6bVUTUTKbxRMADudH+FWneHtXl8QaBY +AND16ddXSfW9H+Gmh6Zq8yeIJ9GudeWXUrK7gvZF1u58OeHrjV1eZhqU+g6NLe+dJpdi0AB2H9m eLv+hqsP/CZX/wCXFAB/Zni7/oarD/wmV/8AlxQAf2Z4u/6Gqw/8Jlf/AJcUAH9meLv+hqsP/CZX /wCXFAB/Zni7/oarD/wmV/8AlxQAf2Z4u/6Gqw/8Jlf/AJcUAcJ8UdP8Tx/Dfx49z4lsri3Twj4g aaBPDywPNGNLuS0Szf2rJ5RcZXzfLcpncEYjBAOi+EX/ACSz4d/9iX4b/wDTTa0AeiUAcva/8jpr f/Ys+GP/AE6eLaAOooAKACgAoA5bxF/yEfBn/Y0v/wCov4moA6mgAoAKACgDnfF//Ip+KP8AsXdb /wDTbc0AbNn/AMedr/17Qf8AopaALNABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQB578Wv8A kl/xC/7E3xH/AOmq6oAb8Iv+SWfDv/sS/Df/AKabWgD0SgDl7X/kdNb/AOxZ8Mf+nTxbQB1FABQA UAFAHLeIv+Qj4M/7Gl//AFF/E1AHU0AFABQAUAc74v8A+RT8Uf8AYu63/wCm25oA2bP/AI87X/r2 g/8ARS0AWaACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgDz34tf8AJL/iF/2JviP/ANNV1QA3 4Rf8ks+Hf/Yl+G//AE02tAHolAHL2v8AyOmt/wDYs+GP/Tp4toA6igAoAKACgDlvEX/IR8Gf9jS/ /qL+JqAOpoAKACgAoA53xf8A8in4o/7F3W//AE23NAGzZ/8AHna/9e0H/opaALNABQAUAFABQAUA FABQAUAFABQAUAFABQAUAFABQB578Wv+SX/EL/sTfEf/AKarqgBvwi/5JZ8O/wDsS/Df/pptaAPR KAOXtf8AkdNb/wCxZ8Mf+nTxbQB1FABQAUAFAHLeIv8AkI+DP+xpf/1F/E1AHU0AFABQAUAc74v/ AORT8Uf9i7rf/ptuaANmz/487X/r2g/9FLQBZoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKA PPfi1/yS/wCIX/Ym+I//AE1XVADfhF/ySz4d/wDYl+G//TTa0AeiUAcva/8AI6a3/wBiz4Y/9Oni 2gDqKACgAoAKAOW8Rf8AIR8Gf9jS/wD6i/iagDqaACgAoAKAOd8X/wDIp+KP+xd1v/023NAGzZ/8 edr/ANe0H/opaALNABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQB578Wv+SX/ABC/7E3xH/6a rqgBvwj/AOSWfDv/ALEvw3/6abWgDlfhD8bdO+LOq/Evw/F4Z17wxrvwr8T2HhfxJZ6ukE1q95qu g2HiOzOn6naM9ndyx6fqNumq2cbm40i+LWN4FnBUAHEftFftF+B/2XdI1r4ofECHVLnQ5Jfhb4Nt 7fSI7eS6m1nxh4p8U6Tpau93PbWttapK7y3V1czxxQxRsWbJGQDxvTf+CkXwV8QT61b+GPDfxE8Q XFnq/wAJ/Cvh+wtfD6w6z4u8bfGf4e+Dvil4N8JaVo1zcpf2+of8IR4ztNc1me/jgttKttI8Qec7 PpciOAdd4i/b1+DOgfCXwt8U0svF+sT+KfEHjrwvH8OdK0iK4+I+j658KrT4lX/xTsdd8N/axNpz eBbT4P8AxHOpyyuYrm58OtaWTzSXcBoA43RP+Cl/7PfiPTdT13RrLx/qHh6HVvh3beH9dtvC8smn eL/DfxI+MGrfAjSvHmhy/aAz+ENO+Jehapo2r6jOsclrALC+EDw6jCFAP0NoA5bxF/yEfBn/AGNL /wDqL+JqAOpoAKACgAoA+afiX8e/Dnhz4n6b+z/q3h/xXb6/8SPhr8Q/EnhDxMulibwnqT+DNF+3 eI9JfUI5mmtbzT9PvbO4knuLdLNpru1sRP8Aa7qCOQA4Hx1+3n+zr8J/iD44+FXjjxJqmmeIvhl4 S+GHiTxNPBod9qWnqvxN8a+EvAGkaTYy2Kzz3us6Tq3xB+HF94jsYYGfSdF8f+F9SlLRX4AAJrT9 vr9mfV9MW80Dxz/a2qS6/faBD4bbTNU07XJJNL+Mx+A2oag0F/ZxQwaYnxFjuNIsrq4miGpywPHZ rJMJI4wDX+E/7cX7NPxg8C+FvHPh34l6LaReJvD3hjX20HVTdWfiDRj4qk+GVpp2m6pp01qk8d2+ rfGL4baTE8aPb3t34u0drKWeC581QDU+En7Z/wCzX8brj4eab8P/AIn6NqHiH4peEF8deDPCt9Hd 6V4n1Lw08Or3KXsmkX0EU9q8lpoGt30VvMVmnsNLvL+BZLOMTsAee6J/wUQ/Zk17xV4s0Cy8axf2 N4SuLO1ufGcsF2nh/Vbi/wBE8M61ZRaButhfa2b7/hL9AsNNbTLW6TVLzU7NdOa6W5iLAG5pn7ev 7M2rahrtrB48FtZeGtY8ZeG9X1PU9K1bToh4k8F6x8LtDvdF02yuLIajrN3f6j8XvB9vpyabazvN NdtE8aMOADqLP9tL9lvUR4gbTfjP4S1JfC/hWz8ba2+nyahdx2nhi+tPBmoQaqs0Ni8VzGtl8RfA t3dRWrzXFjb+LNElvordLxSACzpX7ZH7MOuapc6PpPxn8HX9/baf4f1Nkt7m6aGe18VR+A5vD4sr s2gtdQutTg+KPw7ngsrGa4vBD4x0KWSBEvAVAPpigAoAKACgAoAKACgAoAKACgDz34tf8kv+IX/Y m+I//TVdUAeP/DnxR8VoPh74LtdM+Hnhy+06LwpocNlfTeNdYs7m6tV023SG5ltofAt7FbTSxhZG ijvLpImbas8oG8gHHfBP4deM/gHoGqeGfBHgD7ZpWq6vc65Onir4ueI/ENxHqV9JLPf3EN3c/DZL kvf3E0lxdyXEk8s0u3MgSONFAN7xl8M0/aCku/DPxj+GnhLUdI0XVPht4yt/Dl74o1LUdKvtS8Ja 34o1LRJtQiufBkMd/Zm9knjvdMuLQ280SJmVzIyxAHkmmf8ABPb4V6JZ3tpo+neINNa41r4Z+KNP v7b4ra2ureH/ABh8I/CHg7wD4L8Y6FqzeCm1C18R2ng3wNo/h69u7i5u7e/0651iKe1zqty5AIbT /gnl8LYfhvp/w2vdL1HUYNJ8WePPFWn+NX+Iur2vxHB+JMfxFtvGOj6j4vt/CAu9X07XbH4s/EPT 9S+2RefdWvia8DOkqQyoAIn/AATq+Dlr4c8UeE9G8Par4a0LxPf+FLlLLw98U9f09fDGleC/idr3 xm0Hwn4QY+DpjoXhK3+J3iPUvGMujRCVJtUNrul+z2kMKgH3fHL4wjjjj/svw7J5aKm+TxJqjyPt ULvkb/hFxudsZdsDcxJ70Ac7r8/iw6h4Q8zSvDwYeJXMITX9SYPL/wAI14jG2Qt4aQxx+WZG3qsj F1RNgV2kjAOl+0eMP+gR4a/8KLVP/mXoAPtHjD/oEeGv/Ci1T/5l6AD7R4w/6BHhr/wotU/+ZegA +0eMP+gR4a/8KLVP/mXoA+cfFvwIgf4qeI/2jpxfjx0vwn1P4dfYx8QdXn8JW/hSODVr+aCz8Mze Ehb295d396NRvrm3u7aTUrzTtIa9kkj021WIA8w8W/sC/Bf4geI9b+IOs+Aba3+IHizxFf8AjDWv HWk/EfxNp/ia61TU08FyQw/a18NS28em6Lc/Dv4f3ug2Atmh0278EeGJVMv9lxAgHR2f7FHwytH8 VufCEF5/wmGuaTr2prffEDXLhba40P8AaA1b9p3TrHS8+Elax0qH4ya7rHiVrFWdHS/nsmbySu0A 838Mf8E1vgf4RfwZPpHhzWftfgjVPB9/YXt18WPENxd6tp/w+uvgleeBvC3iOY+D1/tbwp4Un/Z2 +EbaNpDiMQf8ItEJJ5hc3HmAHoHwq/Yg+GXwa8e+H/iR4I8KRQ+JvDXhK08EadLqnj3VdVtv+Ef0 q38S6d4ft5YrnwaZRN4b0HxXq3hfQ7iCeCS28N/ZtMlNwkTNKAef6Z/wTW+BukWdtbWfhbUxc6XN 4Ym8NavJ8VfEMmseDz4Ft/AVr4Cj8LXp8H/8SyHwJb/DHwTF4VQxz/2euiw+abgvIXAOo1X9gj4Y axqMmt3ek6z/AMJCnia78baT4ii+KevR6z4c8aajf/B/V9U8WeH7seDiLDXdW1j4HeBNW1G6McyX F/HrEwiQarKiAGUP+Cc/wKg8KW3g3SvAa+H9Is7eS2tJNA+JfiPTdQtkntfgJZ3Pl3sXhUyN9rt/ 2a/hXHeRzCWG7XTtUjniki1aeMADLT/gnp8K9Dg+AmmeFfCek6JoXwF+Mvhr40aRpz+LNV1CfXdZ 8GfBXT/gx4Y0fVb+bwsszaJY2XhX4ceJ7qz2yR33iL4f6DdyqGiVowD7y+0eMP8AoEeGv/Ci1T/5 l6AD7R4w/wCgR4a/8KLVP/mXoAPtHjD/AKBHhr/wotU/+ZegA+0eMP8AoEeGv/Ci1T/5l6AD7R4w /wCgR4a/8KLVP/mXoAPtHjD/AKBHhr/wotU/+ZegA+0eMP8AoEeGv/Ci1T/5l6AD7R4w/wCgR4a/ 8KLVP/mXoAPtHjD/AKBHhr/wotU/+ZegA+0eMP8AoEeGv/Ci1T/5l6AOD+Kc/ik/DXx6LrS/D8du fCPiATyQa9qM0yRHS7ne8UUnh2BJZFXJWN54ldgFaRASwAN34Rf8ks+Hf/Yl+G//AE02tAHolAHL 2v8AyOmt/wDYs+GP/Tp4toA6igAoAKACgDlvEX/IR8Gf9jS//qL+JqAOpoAKACgAoA53xf8A8in4 o/7F3W//AE23NAGzZ/8AHna/9e0H/opaALNABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQB57 8Wv+SX/EL/sTfEf/AKarqgBvwi/5JZ8O/wDsS/Df/pptaAPRKAOXtf8AkdNb/wCxZ8Mf+nTxbQB1 FABQAUAFAHLeIv8AkI+DP+xpf/1F/E1AHU0AFABQAUAc74v/AORT8Uf9i7rf/ptuaANmz/487X/r 2g/9FLQBZoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKAPPfi1/yS/wCIX/Ym+I//AE1XVADf hF/ySz4d/wDYl+G//TTa0AeiUAcva/8AI6a3/wBiz4Y/9Oni2gDqKACgAoAKAOW8Rf8AIR8Gf9jS /wD6i/iagDqaACgAoAKAOd8X/wDIp+KP+xd1v/023NAH44fHX9rf9tn4e/H/AMXfCXwF4AuNe8I6 Z4ot/BGg+Ll+Ht7qFgbn9qPwR4b0/wDZP8QLqVtbPZ3mi/Cj4weGvivonxmuS7Q23hybwtqmvtYx XUE8wBhXf7eP7XHxC1zwp/wjPwe8QfDHRrb4yt4H1y2n8M3PiHWL3w/F8YvhH4TuovFFrcaVOPDm rWHhfVfFd/cajZyW+majY62L+wggi0D7ZcAH0r8Tv25fitoHxh8SfAzwB8CrvXfGWmfESDwZZ6tr dj4yh8KWug654o/ZU8OeFPHer6xp2hvp0ujalF8eviDqs9tp2qNPDbfCDWknls1XUbiwAPle9/4K bftMXfiW08Q2P7Oet6T4a0X4Mw69r3w6uPDfjC51238W+M779j2PR/GXibWrnQbCxg8D+E7f41/F G7g0zRtRt9c1LTPhz4pm1mOymsJW0MA9vj/bw/aXuU8L3l1+zvo3h7T/ABf488B/C/ToTN4v8U65 b+J/FvwF8AfE65137Dp+naXa6h4HtPG/xI0zwXPrtrdZ0Sy8OeI9W1GC7EF6uigHnHhr/gpl+0Af DXg2TX/gFZaprmp/DX4Z6l4pvdL0H4oadY+Gde8Z+Cvhj4k8R/FXV9PuPDd3LF8G/A+u+Pdb8DeJ NHsLq78eweJvh74pMEH2BC9kAei/Cb9uH4+/GP8AaN/Z4+Hlz8K3+G3grxA/iG6+IgutA8Z3V94q 0qL4RfFHXtD8caBqureGbTSNB+GOseLdA8NRaENWv7DxrJqUsWl6lZiK6aKUA8l1z9tz9tnxb8MU 0fwb8IZvB/ibxTF4B8JaD8RNa8Oa9feINH8S6vJ+y5rXjTxBrPhqLwza+H7XS7bwz8ePF2j6NPHZ 7LPxF8PNVvLuF4bS+trMA7/TP+CiP7ROr32r6bo37M016uhReNdd1S7vbfx3bSaJpngbwf8AGPxJ ffDjWQ/hy2t774uzy/C/w7btJojTeFZB8T/Dp0030lvHFqoBg+K/+CkX7Tnw88GeOde8b/swQf2t o9h4lHg+38Jad8QvEdlrviDwjqnw/a60rVFbS7CbTrXxVpPxHs7PwxqaXDout+FfEJeHUvtVnpdu AKn/AAUF/aU0vUdZuPEfwmsrSzbxx8UPDVkZPCnjyHw18PPC1t4/+Clp8OvFnxWmttC1DxDf3Ung n4gapdO/hC4ttL1GSWG4uLO2jsdQutJAPoL4CftofHD4q6lr9141/Zu1X4c+Hf8AhUvjvx54Ysr1 vEUnilPFHw58I/APxHq3hPxJFeaNZ2MUniO/+OFzo/hYWSi9ml+Hfidpbeaf7Ra6UAeGWv8AwUQ/ ak0zS7e98dfsyaR4fg1q30OCy8QWQ+IuqaB4NudWtP2X/EN74g8eW8Xh4ar/AMIxoOg/tL/2Vepp MY1CbxN8KfG5Mlppwux4eAPLtU/4KfftQTeKdM1yz/Zo1/Q/D2m/DD7X4g+HV94c8X3Wt6b4n8Xa v+yPBoXj/wAXa3caFptjb+BdCsPjB8TLrTtJ0jUrPXb2y8Ga9L4ji0+40y7GggH0bpX7WX7UH/Cu bT4iX3w8stPutb/bH+Dvw51fwvr2ha7qUXg/4MfEL4JfCvxHryaFqWg2enTazdaf8SfFOp+H9K8Y 6jBJo6Xl20OrGG3s5BaADvCv/BQH4ueI/wBnrxb8W7v4F/2HrmlfEv4P+CbBr7TvH58K6LpvxU0z wdqmv6j4rsG8PQ+Mpp/g1d+Jb7wj4/l0PS5dPuPEelmS0nsLUajDpgB5H4F/b1/az074cfC/x78Q PgbreraJoXgvwPqHxTGj+Gteh8ZeJvsP7MXwZ+O/xp8Up4cfw1G9jcaAfiN4m0fwT4U0VLK+8QeL /A+p+Gp/9OuBo9mAfVX7L37X/wAZ/jh8a/E3wx+IP7Pl98KNH8PfDnQPF0mrape3xvv7X13wv8L/ ABVa2UUd1axW+padcJ8RNX8Oyz2wgk0nxF8Pdetbl7yS9+zaQAfZ/wAWv+SX/EL/ALE3xH/6arqg Bvwi/wCSWfDv/sS/Df8A6abWgDyH9nj46+Jfiv4r+PHgnxfoOkaFrnwY8eaR4ZT+zv7VsrjWdG8Q eGLDxFpeuT6HrAmu7OwuWuL200jV0vp7PxJb2Eup2ltp8f8Ao5AOD/bL/aW1L9lLwXqnxQ0fwePH OqX+u/BnwFZ6Gw8Sy4fxr4v8VabNqIsPB3hvxd4q1Z9OtlnuI9L0Hw9qWo3kgVY4diyGgD5h8Mf8 FLvHfjiW7Xw/8FPDmnf2/wDEP9nn4O/D+TxB441j/hHZfiF8ePgl8OPje03iT4h6X4PuvBV1oHhX RPG2p6LFb+Er/Wdb8Sa7pvh60t7bTYPGFnd2IB0/iT/gpQ9n8HfB3iXw58PNA1D4u634q+NPhfxB 4Q1Xxfrem/DbSf8Ahn3R/wBoPXPHOt6H8Vx4Kl0rxRpHim2/Zy8Vx+AXsbKO8mg8Q6Fq+vWmnWdr fwuAeYaR/wAFW/FXizwD4p+IHhT4J+F2jk8M6F4/+FHhHXfiNqtn4y+Iei6t8X/ir8EbL4ZyaVpv gfVH0n45eL/G/wALmi8H+F4xf6Ktrr95NrusWNv4J127ugD9okJZFZlKMyqSpIYqSMlSRwSDxkcH qKAOR8WSSQz+FZolhaWLxDdSxLcTG2t2lj8JeKXjW4uRHMbeBnAE1wIZjDGWlEUhXYwB8Gw/txeO Yv2PPiz+05c/CrwdqmpfC/xJ43tLDTNE+Jd0PAvxL8B+CPElvot98UPAfiy98Hrqt94av421KPQG n8OJZ+JL/SRcaXrB8OazpevOAfSvjv466j4P/aA+APwdt/DGlar4d+NcPxTt7nxkvijytS8OeIPh z4WXxVFpMXhiPSLiPUrfUrJLpLu/k12wm06dbaJNOvBPLLbgH0bQAUAc74v/AORT8Uf9i7rf/ptu aAPiPxt/wUD+EPw+Xxgt74F+J3iCHwR4+8WfC59R0LTfAph8TeKvhL4A8XfEz4sJ4ej1zx5ot8LL 4Z+EvBHiPUNTu/ENroH9tXcEVp4KTxI91HIwB57J/wAFQvgrNr/hvTvDnwu+KGp6V4l+Il74em8W Xum+DtB0l/Bujn9oSw8TfFzS7efxRca5q3h/w94g/Zp8c6Ve6Lf6XonjK8t/7O1HStE1BpoLKYAj 0j/gqj8CPEem+Hdb0H4U/HW5fxZpun6pYy6r4J8N+Ho4dP8AEGv+D/Cnw8vdQvtY8X27XWm+PPFv xA8G6BoGo+HovEVnYX+pXx1yTSY9A1p7MAv/ABE/4KIeFvCHwc/Z2+IkHwj8Rr4q/aQ8EfCn4iRe EdSuPCk9l4A+Gvjr4n/A74a6xrfjXXrPXkXUYNJuvjn4Yi0iw8JWniTVNSuZ45LrRdPs4b424B5q /wDwVL8NeMtT+D+rfCX4SeLT8MPFtn4j8QeIPG/xI8Mp4aFvoFr4k/Zp8G+C9T8FWcOvfaNVsfFc /wC074OnOtWdvqi6O2nXvh7VNMsrv7feaMAbkv8AwVL+GGp/8Ia/gf4L/EfW7jxg3gO1i8Ja1a+C PDPiq98N/Ffxr+zL4d8A+KtNnfxdqPhg+G9X039pnRddfTdW1nTtZ+0abc6be6fpTPNeoAa+nf8A BU74EWmhy63rvg3x/O+mtrXh6bU/CegeHr3TLnxro+jP4xh+GmjRar4q0rxA3iG48B3Fh4mivb3S rDwQPtb6V/wlSayp06gD75+DnxO8O/Gn4faV8QfD2jaxodlf6r4t0C90LxLaabba9oPiTwF4w1zw B4u0PVY9J1DWNKa80XxX4V1fS3udL1XUdOuxZR3Vje3NrJBKwB6attboZCsEKmV3llKxIDJJIoSS STC/O8iAK7tlmUBWJFACSW1tKpSW3gkQnJWSKN1JDI4JVlIJDRxtk/xIh6qCABHs7SQSq9rbuJ/9 cHgjYTYCL+9DKRJ8sUQ+fPEaDoi4AJfLjyTsTJ3AnauSH27wTjJ3bE3Z+9sXP3RQBG9tbSI0clvA 8bqUdHijZHRgilGVlKspWOMFSCCI0BGFXAAjWdo5lL2tu5mjEMxaCJjNCvAilJU+ZGBwEfKjsKAH fZ4NnleRD5YaNhH5abA0RQxNs27d0ZjjMZxlCiFSNowAN+yWvlPB9mt/IlZnkh8mPypHd/Md3j27 HZ3+dmYEs/zEk80APMEBBUwxFSCCpjTBDII2BGMENGBGR0KAIflAFAAIIVlacQxCdkWJphGglaJS WWNpAN5RSSVQsVBJIGaAOC+LX/JL/iF/2JviP/01XVAHgHw+0X9pebwL4Pl8PfET4RWGhSeGtFfR 7LU/hP4m1PUbTTW0+3Nnb3+o2/xc0yC+u4oNiXF3DpthFcSh5Es7dWEagB4Q+D/x0+H0Op2/gXXv 2b/CEGtX51TV4vDfwA1zR49T1IxJB9uv1sfjHCLq68iOOETzb5FiRI1YIqqADq9K8FfE7Xdd1G1+ JPiH4VeJNQ0seC/EWjyw/CnU10+xu9J1PxLcaJqFvY6n8SNVkt9c0nUluru11WG8WSMSwCCG3kt3 muADCP7I/wAMjba5Zn4bfs6/ZPE2m6Bo3iK2/wCFAaWINb0nwrHokXhnTdUiHi3Ze2fh+Lw14dj0 aCcPHpqaHpK2ixCwthGAOsf2TPh7p/gC3+FFv4H+BbfDCz8RXnizT/h9d/Bgah4O0vxDf3N5eXWp aP4ev/HFzpejyPdajqFwsWmWtrbwy6hfvDDG17cmUAbq/wCyP8MvEH9sjXfht+zprA8R+KrTx1r4 1L9n/Srwaz40sIdbtrHxXqQn8WSfbPEFnb+JPEMNtqs++9hTXNWEcy/2hdeaAe6x6P8AESGNIovF /hCOKJFjjjT4f6kqJGihURFHj8BVVQFUDgAACgDl/FGh+OL2Tw5Yan4m8IX9rqGt3VjJbS+Ar82s kd14W8Sw3Md5by+OZkvLWeza5tpbUmIP56u8jJG0MwB5bD+yB8K7bwdcfDy3+GH7OEHgK7sf7Muv BkX7Pukp4YuNN+3adqZsJtEXxYNOktDqWj6Tfm3a3MRu9Nspyvm28TKAdMn7OfhqPxB4X8Vx+F/g cnifwRe6pqXg3xAvwStRrPhXUNbhS31m90DUh4y+16VdarbxRw6hPZSwyXcSLHOzqoFAHq/9l/Ej /ocvCX/hA6n/APN/QAf2X8SP+hy8Jf8AhA6n/wDN/QBg+KdN+Ia+GPEbT+L/AArLAug6u00UfgXU oZJIhp9wZI45m8dzLE7puVZWhlCMQ5ikA2kA+Zrj4f8A7PXxF+LXj74Qaxb/ALNniz4zyeG/AXxf +J/hPVvgbb6p4jv9Hu21zwt4F8YeJLq78Ttb6vd2osNY0q0lkurnVNKsrq3N3BZWGvaW+oAEFhq/ 7NPjTVvENhB4+/ZU1bUPh944ex1Ca7+HugfZ7Tx5o9o3xwvJNE1C78eraatrHh6X4iX/AI71e60O e8l0LW/EOuXmoyWmqyapgA6H4WeDfgHrmjaGnwb1z9lTU9FuPDehePdAtfAvw48NXEI8KXOuab4u 8PeK7Kx0nx80kGit4l03Sdf03VBBFaJren2d3DKl9axtGAVIvCH7OGu6L4VtYPE/7HuseHvgXYT+ I/BkEPgfwVf6T8JdL03WLP7TrmhrH8RJbTwbp1hr+j2An1G2/s+1tdW0y1SSZLu0jEYBjm3/AGZ/ h/r/AIb+Gtv4m/ZX8O6p4q8N+KfiRo+iad8LtDgsP+EUtJ/BfjLxF42v5rPxx/Zuj6Df3nhrwJ4g j13VJrPT9avPDOh3lldXc+h2zWoA3UYP2Z5NP8RW2v8AiD9l2z0HQfE/w8+BWp3PiH4S6Vp3h251 3xd4W+FXjH4Z+A9L1LUvGcOla3b6t4cv/hPe+GrXSbi8sGGn6DBass2iKlmAWfEnhf8AZt8GaTrP xU1m/wD2V7bStG1vw58GvE/jWy+Eug6hDoOpeJ/H/h7w3pfgrxNq+neNrgaJbx+O/EWhNqtnq81r aaHcXK6pq/2K2gmuowD1G7+IPhT4baXZW1v8Xfg3o+n6rrfg+4tdK8N+DDdPPf8Ax2+ImnaB4Z8R tpWhfEG4nTS/HnxC8bWssnimW3XSby/1m51a81Hy3uboAHUt8Q7dfCWqePv+F8fBl/A+i3E1pq/j CLTbSXwzpt5b3EVpNZXuux/E9tLtb2O7uLe0a0mukuBdXEFuY/OmjRgDC8PfGfQPE/hXRfGemftA fByPw/r/AIU8F+NrG51XQxolzF4Z+Ium2mreCdT1PTtX+JNlqGjx+JbG+tpNJi1W2tJ7t5PIijaZ WjABp2PxPs7/AML23jQfHL4UWHhm5sn1Aarrnhqbw9FbWsTaWk76jFrvxE0+50uS1k1zRYryDUob We0m1jTIrmOKS/tVlAOX+In7QXg34T6rBoPxC/aJ+DnhfXbi18Gamui6l4eki1WLQviB44sfhx4W 8T3Vh/wsU3Nr4Uv/ABpqVpok3ia4jj0TT53eXUL62t4pZlAPTdM1/WNa1GXR9H+Lvwu1bVoNI0/X 59L0zw6L/UYdC1dBLpWty2Vr8SZbmPSNTjIk0/UniFneoQ9tNKpzQBgWvxJsL5bNrL9oH4H3i6hp es67YNa2unXC32ieHJri28Q6xZmL4pOLnS9BuLW6g1nUIS9ppc1tcRX00EkMiqAY8Hxq8KXV7qmn 2/7SvwEmu9E8I6N4+1ZI4tMaPT/BHiHWtT8OaJ4turgfFL7PF4e1PX9G1PRbXVml+xSanatZecLi SFJACXXvjF4c8LvJF4i/aN+BejzQ+IfC3hO4hv7SxgntfE3je+fTPB+h3kDfE/zbTU/E1/HLa6Ja 3KRS6jLDOLYSCCYoAerf2X8SP+hy8Jf+EDqf/wA39AB/ZfxI/wChy8Jf+EDqf/zf0AcN8TtO8fR/ Dnx1JfeK/DF1Zp4T19rq3t/BOoWk88A0y5MsUN1J43vEtpXTKpO9rcrExDmGUDYQDsPhF/ySz4d/ 9iX4b/8ATTa0AeiUAcva/wDI6a3/ANiz4Y/9Oni2gDqKACgAoAKAOW8Rf8hHwZ/2NL/+ov4moA6m gAoAKACgDnfF/wDyKfij/sXdb/8ATbc0AfIWh/sP+A7D4+a/+00njz4oSfETxy3xBtPFtu3iu4Xw vqfgf4g+B/AvguLwJaeG0RdL0XTvCtr8L/hzqmia1o8Fn4lk1fwwtzqmr366lqMdwAfMnhb/AIJD fDvw4/w+hl+NvxR1HRvBHxF8FfEG78PRad4B0LRfFFx8OPDHwR8GeDrTWrHw74T0qKa4h8M/ArQN M1zV3WXUdc/4SPxbc3E0dxqFnJp4B6l8H/8Agnl4M+BfjLRPiPffGvx7rtl4H/Zuuv2cdF0vXz4T 0PwvoHgibw78NvDdzqiwaTo+l2dpfLZ/CzQdWeYCKCTX9V8T6ndiZNQsrbTQDl7b/gk78ENF0rTL Xwj4p8UeFtW0Oz8IrpmrafpPgqSO41HwL4f/AGRdJ8OzeItIn8NPpXiXS/7S/Y/8Ia9q+garbTaX qt9418dCWFBqGnNpoB5nq/8AwR7+BumWAN/8bPiDo2kQQaPFpc97/wAIBpstt4/1G8+CmnW9+3iA eG7LVZNB13Xvgz4BtdN+F8Go2/g6C51bWtH0HR7ZNW0y204A+oND/wCCffw38NfCeb4W6D4j1jTr YfGH4B/G3TL8aV4cu7bRPFvwB8OfB3w1oVpp2i3+l3Wn/wBh65ZfB+xbVrS6W4uo38Qav/Z97aBb H7MAYPwn/wCCePwj8HfDXXvA8fjfXPH/AIX8U+K/2atdjur+y8FmyuvDH7Kvjjw34z+Gnh3UbfQt Bs9G8T3OqTeGl03x74y1a1vfFPjCG7klv9UWey002YB474S/4JO/A7RLvW9T8I/E3xXrtzaxfDzS 7N9RvdB1iXwz4o+EOt/BnULfTIL2ys0bSNI1BPgT4E0vxJ4WhigktQNSmsZNOuJrUWYBt/CP/gmv 4T8O/szWHwNvvjHea7410Tx/8IfHHirxbonh34d3Ggad4/8AhF8IPAXwqsfD7/Dmfw3deDZ9Gl8G eGdOur2x8T6He61f6tqVv4tv7ltTTTZrcAl+Hf8AwSP+BPw98YeFPFCeKvGHiiDwbf8Awc1fSNN8 UxaBqn+n/CDwp8N/ClrbTzPpSwroevx/Cjwdrd9pFrZ20Vhrdm8+jy2NpHYWdiAcRrf/AASs/ZlP hq6hb42+LdOtYrb4beGNDu77xV4X/wCEf0Pxz8H4dPtPG2pjT1tbOxu/EXxI0L4Y+BdL+K2kXE2D H8J9J1GztdG1Kx1W9mAPqPxl+wH8KfGvib4Xa7daleW+kfDn4c/BH4aHwtHovha90fxD4b+AHxf8 GfGX4e211LqOjXl/Y2seueFJtL1ex067gstS0fVmjaFLqwsLqAA85+Bf/BND4J/BXXfiONC8eeMv EreMfglH8FdYt9W1XTn8S+F9F1n4dfDn4b6ne6Lq2mwWt5oA1vw78J/C19Z2KW8dtaatbXN7p+22 S0tbMA4fW/8Agkj8N/Fum22k+Lfi3441KxPw6i8A6pFpfhf4ZeGvt39jeBvi38NfC2p2p0PwbZ/2 PDY+EPjJ4nj8QaDpn2fQvF+tWul6xrthcS/2nDqIB0Xjf/glV8JfFbeNhpvjrxf4YtPGmraf4hm0 zS9P8MJZadrGgftDfFb9oXwzbWrRaPb3p8L6bq3xm8a+Frnws15/ZmoaIvh69kVNf0Cz1WgC7pn/ AASw+C3hwaRceFvEniDQ9V0LxJo3irTrxNG8H3ludT8PfGX4afGDQkvrG80CWLUrPRZvhtb+D9Ih vWmk07wvr2r29tOl2ba7hAP0/oAKAPPfi1/yS/4hf9ib4j/9NV1QA34Rf8ks+Hf/AGJfhv8A9NNr QB6JQBy9r/yOmt/9iz4Y/wDTp4toA6igAoAKACgDlvEX/IR8Gf8AY0v/AOov4moA6mgAoAKACgDn fF//ACKfij/sXdb/APTbc0Afkh8f/wBmD9ubW/iJ4y8b/Df4ralrng/xd8SvAMlr4F0745/FT4cL q3wr1D4j/s+3uqeCtZi0TytL+E+ifDbwZ4K+MNrceNPhZ/a3jr4h2XxN1CPVNJN1HcWuqgFb4f8A 7Cn7btprMKfFb9sjxx400Kd/gHba5LovxX+IXhf+1vCvga7+C138SfCf9jaTotnrdhqesf8ACC/E S0sviDp/xFtdY8YWHxJ1yLxpo/2zU7nULcA5C8/4J8/toeKNa8R+KPHfx18Na1rd1qf7Qdr4Ksof ih8a38O+A9G+Mvwx8HeHLXUdL07VE1B9ShsvGXgtdXXwD4jm1vStCt/E2palpXii61XTIk1MA7K4 /Yb/AG3NYm8Uyal+1fr2ktJF42vtDk0L4vfGlU8Q/Eg6D8ZF+HvxX1uzS606HwdYw+I/GXwpk1z4 GeGX1P4W2Nl8JrS4tU1k6vNpsIB6vffsxftEv8NLfwv4y8VH4j/Zf26/BPxqtLA+PvEWu+I3+B7+ MtDur/SNX8XeIoPCdv8A2t4A1C71Hx74c0fwzo/h+y0jSPCXhzw/pUuueKrWTxJrQBg/sv8A7HX7 U3wX8Zfs9/8ACVfGG2vfh18I/hv4H8G67ounfFj4u+J4dVs/CXwh8X/DzWvB0fg7xTbQeF9b03xv 8RdT8LfHZviH4glbxx4PvtAh+FWjRX3hGysdWUA4Cy/YP/bK0PQLUaX+0/f3WrRnRtI1nw2nxQ+L vhjwb4j+Huj6L8Cpb/wHpyaHI6/Dm/8AF/iTwL8V4tS+Jng7RI/G+j6Z8TJ7yzub+YXOmEAvWn7F X7bHhjUfElr8NPj14Y+Hvhz4h+MdV8b669r4x+JOvan4C1iTUvifqtvPocOq6dt+JGoa/L448JWf i3WPGOpaPe6lb/DLSZ9QGsz6oBo4Bkfs/wD7BP7XHwu+L3grxzrXx2m0nwAPiZrPxG8d/DTwl8av ib4ljutVvNG8C6NPc6/4o+I3g7W9b+M0XirTvCkujatpXi6bwo/hbTxaS+E9aimkljgAJ7D9mH/g ode6p8YfG2jfGSLwlf638U/jFJ4K8FeMfjT8U9d0rxB4R1nx1+1boXgPxRq/2O01vTfhanhX4efE 74M6p4R8CfD61v8ASNZHwv8ADsniabw94jgtZvD4B5bJ/wAExf2s7u38Y6dN8dPC1vaX/in4s+Ot NmuPGvxR8S2viHx98TPDnxu0/TvHt34Y120l0L4b+IvCV38UILK8PgYXSePLfUNa8QeJZV1nStHt 7gA931H9kP8Abev9X8BWi/HfTbbSdI/aD1zx/wDEbxnH8Y/jk/if4gfDi/8Ail4d1u00C28Esg8C +D7I/BuLxP8ACe7+HmgCDQ7e5k0PxVo/ivTimp6PdAHnfhj/AIJ+/tkeDvB/w28L+GPj3pnh2Hwr 8Nfhj8PbyLSviv8AGSKTSPFPgHwlpHhe2+NMWuJaQ618RLrR7nTda1zTfgv46l/4V/rQ8Zz6Hrmq fYfCWjT3oB9hfsyfBf8AaX+BHiyXRfG/j29+MXg7x/4f0/VvF3ivxT8SPGHiW/8AAnj/AMPxeIo9 WuPC+leMf7VupLD4gvrnhC3tNA0m40Pwv4csPAusXn2S31DU7O21UA+L/AH7KH/BSvRb/wAW6Jcf HJbW3jk8JeHn8T+Ivjf8WPFWl+KYdR0X4L6j4++MHhO21G31HV/Dvi2+8UfDrx6zfC2a10LwR4fb 4taxZ+GPENxpGnXC62Adp4Z/Yf8A2xtI8IeIZfiB+1X8VfF3ibSPCH7QGpeHpfCnxk8bwTaz8XPE Xhr4b2fwi8dWGhRWPgLS9NtNP1fwx411i9+FXinX/F/gXRtZ8WKNJ1E2VzfPbgH3p+ybp/7QWh/D XTdA/aJtLOfxta6P4d17XvFcXiptfl8R/EPx7YzePvitpml6aIGTw54B+HvjXxLe/Dr4b6e2pXk7 eFvDFsq29nptvpkl6AfUlAHnvxa/5Jf8Qv8AsTfEf/pquqAG/CL/AJJZ8O/+xL8N/wDpptaAPRKA OXtf+R01v/sWfDH/AKdPFtAHUUAFABQAUAct4i/5CPgz/saX/wDUX8TUAdTQAUAFABQBzvi//kU/ FH/Yu63/AOm25oA/KD44ah/wUR8S+P8AxTH8KE8S+EoPhp8VfE/iD4aRWfhDwVffDfxj8MtM/ZR+ Mcvga11fWtQ8b2es+MdU+IXxnvfCnhzxXoOuaPp1l4I1Y6Hq+jLaHSrbxJdAHP6l8Vv+CrfiLXvi 3b+F/hXb+B9E0LXNd1nwFN4m0DwD4gu9Zj8O/Dv4/wCrWPgKzktvEmkWsnhvxt478IfAnS7LxFcN qOuaZpXxI1i3n1+PUbW6m8JAHivw0/bD/wCCk3xn1/xj/wAK/wDCuipYaH+0Xf8AhTW9P1b4bl4v h94Cs9X8b6b4Shu2jktNQ1bTPGcmhBPGemy3Y+Ivw6g0/QtW1W+0bSvH+lXVsAe9ftT+Jv8AgpDa /tIeINS+BPg/xDqPw7+H+j6ungzTLSw8KQ+A/EXhzxL4S+EMOoeNNR1W78W/254u+Kfh7Xb/AON8 fhr4e6p4Qk8OWp8GeC9QAuJvEEkXiEA5O48df8FZNDu5JbXS7bxHN4q8V/BO/ubu9+HXhyHwd4G8 MX3wGg/4SODw/o1pqR8bX8Wt/HLSdRs/ifpmtSR6t4P068sLvwrqWjaZr7anoIBrav4l/wCClPiP V/D+pXOk+PrBpZPi/ofiz4d6V4U+H/hjwNp/iew+LvwHvfAB0bx/ovjh/HuqeBYvhRF8V7nQvGba hp15r2qQXOi+JNIA1eDR4QCTRfiV/wAFY9WRbyTwJpukx6LFN4m1rTdb8BeA7a61zxjp9z8Nl8Sf BfQJbL4k38bfC6GTVfG8Hgb4rySR+L/ElhpdzPqENvLaade6qAewfF3x9/wUIvv2l/Gfw9+EHgqT w78EJovhppOk/FPXNB8EeIoNFfU/H/wItfGfi7wtYzappd3qQtfAPir44S3OleJn1p7PW/h7pt7F pVrZ3em2HisA474HeJv+Chni79pH4da78dvBPiPwv4H8M/AjxHN4h8LeGrXwjpfw41bx54h+FH7P 2q6dc3OsxeOtR1XWfGkvxXHxw8Np4f1HTD4f8FaPomk3FrrKx6w2reJADyTTP2if+CpGj+Cbzxx4 4+EsmjWXhbwz8ePGl/peseF/CLX8mi/D/wAFeH/iV4Qh8Y6jot+trc3XiLULDxj8E9N03wfpXhvV rfV9R0Hx5InizQrTU5bYA7FPih/wVTl0RPG0vgrTH0fxfb6HcTeEdC8AeEp/Ffwt8J69on7M/jbW df0OHWvG9o3jf4h+DbTx/wDtA/D6z8L66LTR9d8RfCjT9QexlW9tofEIBoeD4f8Agpfo/jbUdOs9 U1KbwF8U/jdf6rLrvjXwl4L1TxD8H/h5B4x+GME9xpdofHN9ayJ4x8Iax4/vofDzQ6npvgS+8OWs OkWd0nmwa0AZWj/Ev/grHrCm6PgTTtGXR7e88Ua5p+tfD/wLbzap420mPw5NrnwS8MTWfxL1Bbv4 USXV1qFh4J+Lly8PjHxDZx6tcX9vYy2On3U4BYPxw/4KjaPoPirVZ/gdeeKL6VPE+kaZotr4Q+H+ n6joXxU1H4ffEifRNG0Ef8LSFp4m+AnhXx/pXwztrP4n61d2XivxBZeJteOpaMbewR7MA+/P2WPE /wAefE3hr4kt+0BoFzpGv6P8ZvHej+C9RfS9K0Gx8TfDWGTTrrwnq+k+H7G5vtR0iytY7u70CZPE Opatqmo6lo1/rNtq+o6HqOkXBAPp+gAoAKAPPfi1/wAkv+IX/Ym+I/8A01XVAEPwokMXwn8ASiOS Yx+B/D0nlQgNLKU0e2by4lZlDSPjagLKCxALAHNAHzn+yP8AHf4u/GnxD+0JafFj4ea18NG8D+Pv C9n4N8L634Ym0PUNH8LeJPAGgeIYNG1bV31bVLTxX4jsby5ubrXdW0kWukRSana2emxzWcUNzKAc 9+3H8X/jR8F/A0viP4A+HG8V/EvxD40+BHgHTNFg8Oab4q1C50/xf428VWOrjSNG1zxr8O/D8+sN ZRyQ6fJ4g8aaBo8M0oe5vQ/kowB+f/hn/go/8fvFCeJr3WPGfwS8B6ZJ4x/Za8HXfiV/C32/wt8I PB/xk+B3wc+Injr45a/4e1n4kaR8VW8JWHxB8c6j8M/Dmp/ELwr4G8C6Lqvibwq3iPxHqN54a8Ua TdgHa+Iv+Cj3xZu/2Xfh78R/DF34F0rUNZ8f/G7wdq/7SV94Guda+APim2+EVh+0jN4Bn8KeGrT4 lx+J9H8QfHbWPgv4A0q38Oa/qfm6JL8VYNB8N3niPxNdeG0uADx6+/4Kb/tVj4S/Gjx/dW/wq8J+ NPBnhyz8VWvwu1bwf9m1f4b/ABAsfib8cfB9z+zL4xl8V/FXwnP4y8fa/wCB/hhoHxJtrDwtBb/F DW7G+1a1+H3w819PFvgN7YA/oZtbgXVrbXSpLGtzbw3CpPBLbToJo1kCTW06pPbyqGxJBMiSxOCk iq6sAAcf43vItPj8P6hPe2umw2GsajezajfIZLLT4rTwZ4suJL69jE9sZLSzSM3N0gubYvBHIouI CfNUA/Jay/4KCeOD+wV8Yf2hbH4y/s7+IPHfhPVvHHiT4VeILzw9d6XY+PPg9oHjPRdC8Nav4p+F tn8TJNV8F+NPGq6oljomiXXiv+0dMtde8Gar4i8MW+u32p+D4QD678cftWWdh+1B+yx8MfBnxI+E msfD740T/Gfw94m05ZP7Q8ZzeKPAnhCHxDoE3h3X7bxRDpdrp4vv+JVfabJ4a1W51a61C3+x6tYt b/Z70A+5qACgDnfF/wDyKfij/sXdb/8ATbc0AfmT8Rf+Cjfij4Z+OPGHg3UfgRpFj4Z0bx9r/wAN PCPxQ8W/FfUPDHgYXfgnxN8G/C/ifxv8YNST4V6vD8KPh4ZvjNop8Oa7YXHj+fWdQ0e/029tNES9 s79QD5y8Z/8ABST9qHxh4d8SW3w2+FvhD4deMdavPAFt4C0PxFqGv6t4r8J+Hvif8MP2UvG1r4g+ KWjXPgW8TRdX0S++O3jXTvDFzYaZrPhzxHqfgbVrDVtMiHhXVhqoB3Fv/wAFVdW8H/Cb4h+K/F/w 38MSeJvhppPhmP8A4R7xP471jwX8QPiRr3iObRZYNf07wZofwm8TadoHwwuY9bk8K6d8TNT1u20i ++JWg6x4Tu9L0YCC+YAZp/8AwVF+JEN/eaj4o+FPgnRtJufFnjDw7o9jf+ONb8N6L4H8OXviH9k6 H4c+Ov2jvF+peBtUn+FVgPDn7QOparq15pGh+J9G1SOxgawaO3K38QBeuf8AgrP4us/Bmo/EHVv2 Vr3wt4VTwvba/ps3i34qTaLrUU2maJ+y14j8cpr2h3HwxWWK20rR/wBp63m8E6f4UuvGHjr4lXnw 68RaRonge01rVtI04gH6F/sv/FjxJ8WfDnxTu/E3k3M/gX9oT41fDXRtZtrBtMh1vwt4V8ZXf/CM zNZNHEYr/Q9Hv7XwfrbtFDNca94a1S5ure2u5p7aEA+l6ACgAoAQgEEEAgggg8gg9QQeoPegBaAC gAoAKACgAoAKACgDz34tf8kv+IX/AGJviP8A9NV1QB/Mb4q/b3/a28F+Jtf8IeGfjBe6X4c8Mavf aDoWmp4U8BXK2Gk6VO9nYWa3F74Vubydbe2hjiEt1cTzuF3Syu5LEAwP+Hjv7aX/AEW6/wD/AAjf hx/8x9AH2p+y/wDtd/tFeO/DfifxF4s+JN1q+sx65baKl6/h/wAI2rLplnp63tta+TY6Ba2xEV1q l/MJTCZ2NwVeVkSJUAPpw/tGfGcjB8bTEf8AYF8N857H/iT8jnoeO2KAKdn8e/itpxujp3ia30/7 deT6lffYPDPhKzF9qN0VN1qN6LbQohd39yUQ3F7cCS6nKIZZX2LgAt/8NF/Gbn/itp+eudG8OHJ7 HnR/vDAw33hgYPAoAP8Ahov4z/8AQ73H/gn8O/8AyooAq3H7QHxeuZLKWfxlPJJYXRvLRjpOgDyb k2l1ZmUBdKAYm2u7iLa4ZcSltu9UZQC5/wANG/GjOf8AhNp//BL4b9+39j47/wAvQUAJ/wANG/Gc 5/4rafnr/wASbw4Onp/xJ+PfGM980AJ/w0X8Z/8Aod7j/wAE/h3/AOVFAB/w0X8Z/wDod7j/AME/ h3/5UUAVrz9oH4wX1pdWV14znltry2ntbmI6ToCiWC4iaKaMsmkq6h43ZSyMrDOVYHBoAsJ+0V8Z Y0WNPGs4RFCKv9jeHDhVGAPm0ck4HHJPbPQUAO/4aM+M/wD0O0//AIJvDme/f+x8nqep46jmgA/4 aN+NH/Q7T9c/8gXw4eT/ANwfp7dO+M0AB/aN+M54PjaYjnrovhs5znOc6NyOTwePyFAB/wANGfGf /odpzjnnRvDh5ByDzo5zyc89wPQYAMzSvjZ8S/DVrLpnh3X7TQ9Ol1HV9ZlsdJ8NeFdPtZdX8R6t e+IfEGqSQWuiRRyahrmvapqWtateurXGoapf3l/dyS3NxLK4Bpf8NF/Gf/od7j/wT+Hf/lRQAf8A DRfxn/6He4/8E/h3/wCVFAB/w0X8Z/8Aod7j/wAE/h3/AOVFAB/w0X8Z/wDod7j/AME/h3/5UUAH /DRfxn/6He4/8E/h3/5UUAH/AA0X8Z/+h3uP/BP4d/8AlRQAf8NF/Gf/AKHe4/8ABP4d/wDlRQAf 8NF/Gf8A6He4/wDBP4d/+VFAB/w0X8Z/+h3uP/BP4d/+VFAB/wANF/Gf/od7j/wT+Hf/AJUUAH/D Rfxn/wCh3uP/AAT+Hf8A5UUAH/DRfxn/AOh3uP8AwT+Hf/lRQBn6v8efizrWl6jpGp+L57rTtTsr qwvrY6XoUYuLS7heC4hMkOlxzIJInZC0UiSDOVZWwaAP/9nOzs5QSwMEFAAGAAgAAAAhAGs5+8Sn DAAAjB8AABQAAAB4bC9zaGFyZWRTdHJpbmdzLnhtbKSZ3Y7cxhGF7w34HRrjC+8Cqx39xXYUaRey bAdCDCeWZei6h+yZ6SzJptnkrsZXeZo8WJ4kX1WTHA45MhAEMOQdstmsn1OnThdf3n4sC3PvmuhD 9Wr15PrxyrgqC7mvdq9Wv77/4dE3KxNbW+W2CJV7tTq4uLq9+fyzlzG2hmer+Gq1b9v6xXods70r bbwOtau4sw1NaVt+Nrt1rBtn87h3ri2L9dPHj79al9ZXK5OFrmpfrf78ZGW6yv/WuTfpwtfPVzcv o7952d78Gp15Y6N7uW5vXq7lWrr+i8tajJ5ffhPK0lVtnF9/f6gXW7jct6HxtpgvfgjNtggP5osn L8zqP//6d2hMu3dEJq+Dr1pT+t2+NW3jdzvXrK6MeXAms5VxnmWNyQrb+O2BZ2w7XJPnbV0XPrNi tuG/ky15RX/ponItBtxd6pb9S3Rx44gQcSe0pm5C5mIkT9xqQrfbGzHgHt+vjXnLRV/d6VPJZB/5 gTm+1W03bjDf5aa0VWeL4mAu3PXu2pDAxhIYw39ddM2l/GG7NpBPVg+vm3t00Xv/ac8Gx+bhVq/O 5PLtl6UJd/ZgHoiryZtQ1+Kv2HRlNl174mYK+hjerdn4R7lvEkpsMbhrCETlXO7yuRU7V+H3Agut y/bryrfz5dNkSu6JKP9Or2q8o2/jgIE+Mn0YJKrzWLHYFdsrE4MkMFlK4oLsnhXONnMrBAqSiMZt XUPlOhO26dGYPL8iSBtXeJBxYpzi4fRSbwzRhRDMxVuTh+pLYK5IAuEPFugLyIYywK7WNjvXmjrE tmv05QFzmnFNvL2cmyzmkkI1ND0NvfBAwml0rhw8ZhVwC6Z0vFUei7YEt9izu53vuvNAn3tAXCOH f1Zfk8EdeJJ1QgsSjdhRtVQRHlWB+qy4A95lY2fuqvBAFrPfOk/mpFBL1+5DHg1eLQhkAC5EMbfn eOvp/Ja8x93botMiK8F3JKT6+sbFrmhTDsl4KGuYJGKFFXeiL+vCGSHhdRXgHZLvuacLG7d3VSQK Qg8lpHU9JQG5Bhube9sc5vY8vX5yvbD/DOKlHCViUTKtkbbgTh3FkMxifLosDvoqvVJCiB9Y1YQS U3Pb4gjsAvaiWB/lpiRJHh4DI48JLKbbSKSog7Bp6R0gQ1PtwJ5QMrxGyntzuJmoTHYcsGkj74iC AlkJtqmaxOMEztzHa+M+to2lq8AxbLcw+PJ6HrmV+yiMzmKgupJtpa1BpBuXWcV4R2D2tmkpiVg7 e6fQHiwKLF0A+a2xJRGjlBtxUuMMVIcaljr0RaEcZkrA4gUSGtUy5K6IqTv09Xj0+VaagvAUBWZy v1W6oHCb0IYs8JhEG/erWIemjVf6+7gOg1rCQ5tYvEti3HMnm2cCjr5ZkMTE07JkSwnGkZ0IlVDX EImjnVBicVgE+ts+nlPA8TiIq0OVE1zBBr7c+/wUetI5Ap1ib+8lrduO0NX7Q6RPFAmGQglEfAQ2 ySztHWikKGEO6If0+awrhCK4CWpjl+3NSnulxgVEHWFNWbLk1LHQ0APIf4bWAB35obKlz3CV14jl 2T6E9K5ciF8qvygSf+OjJcmlW8aE5yQrvP0QuglJwsc0AdsiHWiSWleUSt+j+p1dfmXqblN4RBmV RO6p48a7HJz8Esyq33llHkJX5FJ2wjKjUSf788gHuJk4s5IkbOwGJ20u4CXP0iVwiRIofRWKsEMY hVEjCbdLZlKxizfX5vPPXhcxXI3uoRIHG+J550pby6aCHfME0sjdx54BxmYFXEqbiVmgBiA2Jnf3 PsMwlOHt5e2bPpbvHHETepZK6VtRQRkfQ0J6T6jwQZqOhCclAxcaSU1vM75XiyIXUVEJBueMIqxU +qTrNp0vRIibTRGyO3PxsPfgbroxnmr+N46emAvTVDuq27G99K7bS6EkCb6NhypDJlaBGgTqfjsR Sr3hf2EljqQnKGL+GFxSpPTCdcDKIZU2fGRJFpQSqW9p2J9+1wXrqKDRA5qbQlWgd0gZGSyXX8jQ va2pnJ5kyW0v8vQtbEUa6dancVoKDulviyYs7COREbsDegd3EDwuZhTNUOdTrQOutx6mlT4hiEFk v0/hukrw5pqW3bHL9P1qQ2/LgSYQWaJ343a+0gJQjUt/PIKyR3Bh6zbUVAPip7GUbSNZRwG7NrtM SUiai15ZdGhALadj9Y/hVnfT9sJwV0YbRmL6IdYPInMk+HuOP5MHEhgqwRWATM31AXWda0Dkr4Kq mms9OSG+iLXNODnWlJ0oy9UNkJHeuErakbYpTUkBa55KFavcG+tWdP5R0e046tQS5+E+nQpUJR/Z +J8dyi5CqYplSdbwmlszr7WR8rWA9QF5NTti6z17Kt3hopK7ygENz615TbEJgPTBumtge6cNVrTp HcryS4L497+lc4tEUSsY0eG2qlwQmXNjCPDYM8id0jE6YoIdaR+UrbCbp89JK+7VN5bYsQUPQCWQ AJlAS0X2K+nyGDZAHrKfW7HktYECNDKSKs3FrOTm20jFPT938U/zi6eHjDHPFEsBxivpuYIVFfF4 pBvr0Q8lYIksLD5qGbhztv15/A1iBVmqapDSPLZvDRYZG5ojZzQ5UJ2qCqlsgi7/qxDEiAvpj6Ou mOw2M+hmTtGQTsKMvELafAFAaE/AQRo/lKe46+hoqYH6iBjRlallazMdNMJaXGEIAzyTNFqOTcYQ U3Pw70mAU/GLJQMUz8jvFV3c5SuzQceMoZ8ce5OwO97qy0P6EHyq9Tns3h+C6FTzML1zv5kvFhe/ //nR48eLk8p3Str1uWHQTwH5M9/m9UCN2K+sc+ZI9Nf+NDmRrYPRR6maiH/UWQNhDEcXu9s1bpem PaXQEuX44NCfksyGI1CgKyi2PFDqZRCoSj19bvU7dX7Rxj7MNjxJmJwHhFDzRo6FQyUrCenZ9vw7 ns0vv55Iftlu74oamOmmApZh4zQ3wv1oLljmq6zokOMT8XCVaI1eNlMqKv8+KRwWfeXmp+EYqm0K D5VYR0uaUcNBfdAdTSvrD3RJa3AZMA6DrgUNpmAvGOyX79+cAyBNexAR5FFc87GUQG1t5gvfDrOF 46pp/zrh+Lm6naciGbZg0XT5q/lqYctFNt+TMSUo7f4cIaVhdnXNqU95LhH9II+meMIjIHxsi8Mg 0PbNavR9bkcy7+v55f/XkoGiTyUnp0eOML70DGELVJ0g9Ohv8UcOT0+XOJsGDaareZxTFKXZw5bI jQIaIE20dbEYriTfv5n7ro1sLf8ukvm/hcWWMjEXIpmlSiY90q+j/91Rj4NWHRWFxKXXD1oT6ED5 EHAwxI1DxFKqSldJD6RDK1gYxy1z936WObUwwfonZq3mDX9xmu4WXPxhPDf2FSxDrmqHzp56o0id v2LxqDgkk11VZsf+M840zEVhDzLNJrXDKfDYcdcMlykBvkJog01VICtlFIhomtjzwvz49Mr8+ExJ 68cFrDFMzeDh3imxTCcjvj1ozNhQP1JQTwe6gNwnL/1E4IWMTzg00ue1eZAYfvOd4vf+JweAe5sB bekUu4ZNrxhn6TxT3K9C9ahxdZd7Xf/puJHA4WglMRErtFAe+lEv1/qhTaWnHWq/H2XpZSmJalQK x7YoeryfsUorRMmw0QaU0u44R3Pc4qSk75OZx9g+aRo6UVETOE5gPCcNXeeXDeD9YOwfshhPJ74f UX/uDMaqCVOfTjkmaU9jHzrHOSXgK/nyEiifiym5c0gbhuUyzEWh8mmKQxstc+t3HfJLQsSHs+yO UQzjac5084RJXqZmqMfrI6VN5oF4ws6RIZh+sDmC5thkmsBBTcK662wjMpEAyThWGiLTm67YyEiI n6o7NXqSB8gvjdfkx4BHwCZmzA3+ARRuLBML3YIhx3zKcV6WyxBJhlQeoZtaZvqsJYo1HXM9Q2km aNMSEk/GU7uSHOgVXa4fK7gpZ3WF9gg0c8F9aWRJgxyvy1a4owdKGVNgC8s00LKLKth0OQkqScz4 dGStDmH6Ebc8cUnZfNADdT8cU/F9VJ1wXXtr/tGPOQZl3uv+Ukfkks/M1Tp4vViONr6Vjxv6IDB6 98Mb8+z58+cy+xfbth6VaZ5Nw4WVw4lSVsgTVGtqDkxT9J2TN+qNPg56kpQQiZbUqDuGBgSfaTzj YzrNEZJncfydTP4VvAyWUmwZ29WAiN10OCqnW1CWBtLX5q1EXOgDSx/kSH/k7Yt7byEvK99D9N2y RrA8MuvwxedyIe4m/DwWC5+4W8dwmGmGfO5udZoBafHZEceGgj+eV7RYjkwxr4Dvh88CE5O0LTFC l480G5GFE6mw5mv6zX8BAAD//wMAUEsDBBQABgAIAAAAIQCrmNfOnAEAAEQDAAAQAAgBZG9jUHJv cHMvYXBwLnhtbCCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJyTTW8bIRCG75Xy HxD3mI0TVZXFEkVOqhwa1aqd9EzZWS8KC5QZr+z++rJe2d5tD5V6m49XLw/DIO/3rWMdJLTBl/xm VnAG3oTK+m3JXzefrz9xhqR9pV3wUPIDIL9XVx/kKoUIiSwgyxYeS94QxYUQaBpoNc5y2+dOHVKr KadpK0JdWwOPwexa8CTmRfFRwJ7AV1Bdx7MhHxwXHf2vaRVMz4dvm0PMwEo+xOis0ZRvqV6sSQFD TexFG+spYMOe9gacFGOZzJxrMLtk6aAKKcapXBvtYJmPULV2CFJcCvIZdD++lbYJlexo0YGhkBja X3mAc85+aIQerOSdTlZ7yoC9bEiOsYtISX0P6R0bAEIpsmAoHsOxdhzbOzU/CnIwFfYGA0huTBE3 lhzg13qlE/2L+Mgw8A443+DnziboH3RCeebdITCTb8x8IJhIJkh/QCxDG7U/ZNZz9MX6d3yNm/Co CU5znxblutEJqvxUp/6lIJ/zyJPrTZaN9luoTpq/G/2+vA2fQt3czYrbIi/AqCbFZf3VbwAAAP// AwBQSwMEFAAGAAgAAAAhAGnIMmg/AQAAUQIAABEACAFkb2NQcm9wcy9jb3JlLnhtbCCiBAEooAAB AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAISSUUvDMBSF3wX/Q8l7m6TVOULbgcqeHAhWFN9C crcVmzQk0W7/3rSdtYOBj/eek++ee0m+Oqgm+gbr6lYXiCYERaBFK2u9K9BrtY6XKHKea8mbVkOB juDQqry+yoVhorXwbFsD1tfgokDSjglToL33hmHsxB4Ud0lw6CBuW6u4D6XdYcPFJ98BTglZYAWe S+457oGxmYjohJRiQpov2wwAKTA0oEB7h2lC8Z/Xg1Xu4oNBmTlV7Y8m7HSKO2dLMYqT++Dqydh1 XdJlQ4yQn+L3zdPLsGpc6/5WAlCZS8GEBe5bW+Z4XoTDNdz5TbjxtgZ5fwz6hZ4UQ9wRAjIKAdgY 91d5yx4eqzUqU0KzmNKY3FQkY9mC3WYf/ciz932gsaFOg/8lpjG9q1LC6JJROiP+Asbc55+g/AEA AP//AwBQSwECLQAUAAYACAAAACEAPLWQaHEBAABMBQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRl bnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQB9zFSeDQEAAN0CAAALAAAAAAAAAAAAAAAAAKoD AABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQAT+O2w+QAAAEcDAAAaAAAAAAAAAAAAAAAAAOgG AAB4bC9fcmVscy93b3JrYm9vay54bWwucmVsc1BLAQItABQABgAIAAAAIQBckddi5QEAACgDAAAP AAAAAAAAAAAAAAAAACEJAAB4bC93b3JrYm9vay54bWxQSwECLQAUAAYACAAAACEAt0p+DZwDAACW IAAADQAAAAAAAAAAAAAAAAAzCwAAeGwvc3R5bGVzLnhtbFBLAQItABQABgAIAAAAIQAw2XNOdgQA ADcOAAAYAAAAAAAAAAAAAAAAAPoOAAB4bC93b3Jrc2hlZXRzL3NoZWV0Mi54bWxQSwECLQAUAAYA CAAAACEAMA+IaxEHAADeHQAAEwAAAAAAAAAAAAAAAACmEwAAeGwvdGhlbWUvdGhlbWUxLnhtbFBL AQItABQABgAIAAAAIQCzYW4mxwQAAI4OAAAYAAAAAAAAAAAAAAAAAOgaAAB4bC93b3Jrc2hlZXRz L3NoZWV0MS54bWxQSwECLQAKAAAAAAAAACEA7dCDk0hYAABIWAAAFwAAAAAAAAAAAAAAAADlHwAA ZG9jUHJvcHMvdGh1bWJuYWlsLmpwZWdQSwECLQAUAAYACAAAACEAazn7xKcMAACMHwAAFAAAAAAA AAAAAAAAAABieAAAeGwvc2hhcmVkU3RyaW5ncy54bWxQSwECLQAUAAYACAAAACEAq5jXzpwBAABE AwAAEAAAAAAAAAAAAAAAAAA7hQAAZG9jUHJvcHMvYXBwLnhtbFBLAQItABQABgAIAAAAIQBpyDJo PwEAAFECAAARAAAAAAAAAAAAAAAAAA2IAABkb2NQcm9wcy9jb3JlLnhtbFBLBQYAAAAADAAMAAsD AACDigAAAAA= --_004_CED61A7F90739ncamwingciscocom_-- From mailer@doodle.com Wed Dec 18 07:55:13 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1630D1AE173 for ; Wed, 18 Dec 2013 07:55:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.428 X-Spam-Level: X-Spam-Status: No, score=-9.428 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iEx-szDjiPKv for ; Wed, 18 Dec 2013 07:55:10 -0800 (PST) Received: from worker1.doodle.com (worker1.doodle.com [188.92.145.81]) by ietfa.amsl.com (Postfix) with ESMTP id 17D521AE400 for ; Wed, 18 Dec 2013 07:55:09 -0800 (PST) Received: from worker1.doodle.com (localhost [127.0.0.1]) by worker1.doodle.com (Postfix) with ESMTP id C104A104E0A8 for ; Wed, 18 Dec 2013 16:55:04 +0100 (CET) Date: Wed, 18 Dec 2013 16:55:04 +0100 (CET) From: "Dan Romascanu (via Doodle)" To: Message-ID: <2049196682.1774850.1387382104788.POLL_INVITECONTACT_PARTICIPANT_INVITATION.doodle@worker1> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1774849_1199558881.1387382104787" Subject: [sacm] second SACM WG Virtual Meeting - all times EST X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Dan Romascanu List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Dec 2013 15:55:13 -0000 ------=_Part_1774849_1199558881.1387382104787 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi there, Dan Romascanu (dromasca@avaya.com) invites you to participate in the Doodle poll "second SACM WG Virtual Meeting - all times EST". Dan Romascanu says: the second SACM WG Virtual Meeting - second week of February 2014 =20 =20 all times EST Participate now https://doodle.com/vtrr6w49c4qrri82?tmail=3Dpoll_invitecontact_participant_= invitation&tlink=3Dpollbtn What is Doodle? Doodle is a web service that helps Dan Romascanu to find a suitable date for meeting with a group of people. Learn more about how Doodle works. (https://doodle.com/main.html?tlink=3DcheckOutLink&tmail=3Dpoll_inviteconta= ct_participant_invitation) ---------------------------------------------------------------------- You have received this e-mail because "Dan Romascanu" has invited you to participate in the Doodle poll "second SACM WG Virtual Meeting - all times EST." ---- Doodle AG, Werdstrasse 21, 8021 Z=C3=BCrich ------=_Part_1774849_1199558881.1387382104787 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable =
=09
Dan Romascanu invites you t= o participate in the Doodle poll "second SACM WG Virtual Meeting - all= times EST."
=09
=09 =09 =09
=09 =09=09 =09=09 =09=09=09=09=09=09=09 =09=09 =09=09=09=09=09 =09=09=09=09=09=09=09 =09=09=09=09=09=09=09=09 =09 =09=09=09=09=09=09=09 =09=09=09=09=09=09=09=09 =09
=09=09 =09=09=09 =09=09 =09 =09=09 =09=09 =09=09 =09 =09=09 =09=09=09 =09=09 =09=09 =09=09 =09=09 =09 =09=09 =09=09
=09=09 =09 =09=09 =09 =09=09=09 =09 =09=09=09
=09
=09=09 =09=09=09 =09=09=09=09 =09=09=09=09=09
=09=09=09=09=09=09
=09=09 =09=09=09 =09=09=09=09 =09=09=09=09=09 =09=09=09=09=09=09=09 =09=09=09=09=09=09=09=09 =09 =09=09=09=09=09=09=09 =09=09=09=09=09=09=09=09 =09 =09=09=09=09=09=09=09 =09=09=09=09=09=09=09=09 =09 =09=09=09=09=09=09=09 =09=09=09=09=09=09=09=09 =09 =09=09=09=09=09=09=09 =09=09=09=09=09=09=09=09 =09 =09 =09=09
=09=09=09=09=09=09
=09=09 =09=09 =09=09=09 =09=09=09=09 =09=09=09=09=09 =09=09=09=09 =09=09=09 =09=09
=09=09=09=09=09=09
"second SACM = WG Virtual Meeting - all times EST". =09=09=09=09=09=09
=09=09=09=09=09
=09=09 =09
=09=09 =09=09=09 =09=09=09=09 =09=09=09=09=09 =09=09=09=09 =09=09=09 =09=09
=09=09=09=09=09=09
=09=09=09=09=09=09=09Dan Romascanu says: =09=09=09=09=09=09
=09=09=09=09=09=09
=09=09=09=09=09=09=09the second SACM WG Virtual Meeting - second week of Fe= bruary 2014

all times EST =09=09=09=09=09=09
=09=09=09=09=09
=20 =09
=09=09 =09=09=09 =09=09=09=09 =09=09=09=09=09 =09=09=09=09 =09=09=09=09 =09=09=09=09=09 =09=09=09=09 =09=09=09=09 =09=09=09=09=09 =09=09=09=09 =09=09=09 =09=09
=
=09=09=09=09=09=09 =09=09=09=09=09=09 =09=09=09=09=09=09 =09=09=09=09=09=09=09 =09=09=09=09=09=09 =09=09=09=09=09=09 =09=09=09=09=09=09 =09=09=09=09=09
=09=09=09=09=09=09=09=09Participate now =09=09=09=09=09=09=09
=09=09=09=09=09
=
=09
=09=09 =09=09=09 =09=09=09=09 =09=09=09=09=09 =09=09=09=09=09 =09=09=09=09 =09=09=09 =09=09
=09=09=09=09=09=09 =09=09=09=09=09 =09=09=09=09=09=09
=20 =09=09=09=09=09=09=09 What is Doodle? Doodle is a web service that helps Dan Romascanu to find a suitable date= for meeting with a group of people. Learn more about how Doodle works.
=20 =09=09=09=09=09=09
=09=09=09=09=09
=09
=09=09 =09=09 =09 =09=09 =09=09 =09=09 =09 =09=09 =09 =09=09 =09 =09=09 =09 =09=09 =09=09 =09=09 =09 =09=09 =09=09 =20 =09=09
=09=09 =09You have received this e-mail because "Dan Romascanu&= quot; has invited you to participate in the Doodle poll "second SACM W= G Virtual Meeting - all times EST." =09=09
=09
=09 =09=09 =09=09=09 =09=09=09=09 =09=09=09=09=09
=09=09=09=09=09=09
Hel= lo SACM community.

I have not posted very much the last year and= a half or so, but have been paying close attention to all the traffic, bec= ause I am still interested.

A few questions come to mind.
<= br />1. Is the SACM charter complete yet?
2. Is the SACM working group= planning to take on the NIST SCAP product validation program? To this effe= ct, I was pretty glad to see the first SCAP 1.2 product validated posted in= the official NIST-SCAP website (http://nvd.nist.gov/scapproducts.cfm).&nbs= p; Congratulations to the Tripwire folks.
3. If NIST is working with I= ETF and SACM, will any information to this effect be posted at http://nvd.n= ist.gov/scapproducts.cfm ?

David Oliva

 

<= /div>

From adam@stoicsecurity.com Wed Dec 18 18:08:10 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 983811ADF69 for ; Wed, 18 Dec 2013 18:08:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ckBcMclWjXUj for ; Wed, 18 Dec 2013 18:08:08 -0800 (PST) Received: from p3plsmtpa06-05.prod.phx3.secureserver.net (p3plsmtpa06-05.prod.phx3.secureserver.net [173.201.192.106]) by ietfa.amsl.com (Postfix) with ESMTP id 558BA1ADF4D for ; Wed, 18 Dec 2013 18:08:08 -0800 (PST) Received: from [192.168.1.69] ([99.64.100.240]) by p3plsmtpa06-05.prod.phx3.secureserver.net with id 3E821n0045BBm5P01E84BS; Wed, 18 Dec 2013 19:08:06 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: "Adam W. Montville" In-Reply-To: <10358790.289924.1387413066277.JavaMail.root@vms170015> Date: Wed, 18 Dec 2013 20:08:01 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <647F5929-7F95-462E-B92D-E0793C4ED355@stoicsecurity.com> References: <10358790.289924.1387413066277.JavaMail.root@vms170015> To: david.oliva@verizon.net X-Mailer: Apple Mail (2.1827) Cc: Dave Waltermier , sacm@ietf.org Subject: Re: [sacm] SCAP moving on X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Dec 2013 02:08:10 -0000 Hi David, Welcome back. Please find my responses inline. Regards, Adam On Dec 18, 2013, at 6:31 PM, david.oliva@verizon.net wrote: > Hello SACM community. >=20 > I have not posted very much the last year and a half or so, but have = been paying close attention to all the traffic, because I am still = interested. >=20 > A few questions come to mind. >=20 > 1. Is the SACM charter complete yet? The charter has been complete since (IIRC) late June and was approved by = the IESG in early July. We held our first meeting as an IETF working = group during IETF 87. That's the long way to say that, yes the charter = is complete and can be found here: = http://datatracker.ietf.org/wg/sacm/charter/. > 2. Is the SACM working group planning to take on the NIST SCAP product = validation program? To this effect, I was pretty glad to see the first = SCAP 1.2 product validated posted in the official NIST-SCAP website = (http://nvd.nist.gov/scapproducts.cfm). Congratulations to the Tripwire = folks. While the IETF does have interoperability requirements (i.e. "running = code"), it does not itself operate any sort of validation program. = Thus, the SACM working group will not take on the NIST SCAP product = validation program, which may well continue to be operated by NIST - you = would need to ask them of their plans. > 3. If NIST is working with IETF and SACM, will any information to this = effect be posted at http://nvd.nist.gov/scapproducts.cfm ? Keep in mind that those participating in the SACM working group do so as = individuals irrespective of how they might be sponsored. That said, = where NIST decides to post information about the standards efforts with = which it may be involved is not within my purview. You'll have to get = an answer from NIST on this one :-) >=20 > David Oliva > =20 >=20 >=20 > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm From dromasca@avaya.com Thu Dec 19 02:30:51 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 077AC1AE2B8 for ; Thu, 19 Dec 2013 02:30:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.137 X-Spam-Level: X-Spam-Status: No, score=-5.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hNtJNjacKAX3 for ; Thu, 19 Dec 2013 02:30:49 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id D347E1AE06D for ; Thu, 19 Dec 2013 02:30:48 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMFAHrKslLGmAcV/2dsb2JhbABZFoIxIyE4VYMDnF6ZSRh9FnSCJQEBAQEDAQEBAg0RAggBQB0BCA0EBAEBBgEBAQIIFQMCBBUNAgELFAcBAQUFBBIBCAYUh2IBDKFrhEyKQZE0h38TBI5hLQqCbzWBEwSQM4ExAVmJWIJsiyiDK4Iq X-IronPort-AV: E=Sophos;i="4.95,512,1384318800"; d="txt'?jpg'145?scan'145,208,217,145";a="41733177" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by co300216-co-outbound.net.avaya.com with ESMTP; 19 Dec 2013 05:30:46 -0500 Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 19 Dec 2013 05:22:40 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC01.global.avaya.com ([135.64.58.11]) with mapi id 14.03.0158.001; Thu, 19 Dec 2013 11:30:44 +0100 From: "Romascanu, Dan (Dan)" To: "sacm@ietf.org" Thread-Topic: [sacm] second SACM WG Virtual Meeting - all times EST Thread-Index: AQHO/AmMDfsY+03ZjESfOp0+3G5hKJpbUfaA Date: Thu, 19 Dec 2013 10:30:43 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA129F5163@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: multipart/mixed; boundary="_007_9904FB1B0159DA42B0B887B7FA8119CA129F5163AZFFEXMB04globa_" MIME-Version: 1.0 Subject: [sacm] FW: second SACM WG Virtual Meeting - all times EST X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Dec 2013 10:30:51 -0000 --_007_9904FB1B0159DA42B0B887B7FA8119CA129F5163AZFFEXMB04globa_ Content-Type: multipart/related; boundary="_006_9904FB1B0159DA42B0B887B7FA8119CA129F5163AZFFEXMB04globa_"; type="multipart/alternative" --_006_9904FB1B0159DA42B0B887B7FA8119CA129F5163AZFFEXMB04globa_ Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA129F5163AZFFEXMB04globa_" --_000_9904FB1B0159DA42B0B887B7FA8119CA129F5163AZFFEXMB04globa_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkFsbCBmb2xrcyB3aG8gYXJlIGludGVyZXN0ZWQgaW4gcGFydGljaXBhdGluZyBpbiB0 aGUgc2Vjb25kIHZpcnR1YWwgaW50ZXJpbSBtZWV0aW5nIG9mIFNBQ00gZHVyaW5nIHRoZSBmaXJz dCB3ZWVrIG9mIEZlYnJ1YXJ5IOKAkyBwbGVhc2UgZW50ZXIgeW91ciBwcmVmZXJlbmNlcyBpbiB0 aGUgRG9vZGxlIHBvbGwgaWYgeW91IGRpZCBub3QgZG8gaXQgeWV0Lg0KDQpSZWdhcmRzLA0KDQpE YW4NCg0KDQoNCkZyb206IHNhY20gW21haWx0bzpzYWNtLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiBPZiBEYW4gUm9tYXNjYW51ICh2aWEgRG9vZGxlKQ0KU2VudDogV2VkbmVzZGF5LCBEZWNl bWJlciAxOCwgMjAxMyA1OjU1IFBNDQpUbzogc2FjbUBpZXRmLm9yZw0KU3ViamVjdDogW3NhY21d IHNlY29uZCBTQUNNIFdHIFZpcnR1YWwgTWVldGluZyAtIGFsbCB0aW1lcyBFU1QNCg0KRGFuIFJv bWFzY2FudSBpbnZpdGVzIHlvdSB0byBwYXJ0aWNpcGF0ZSBpbiB0aGUgRG9vZGxlIHBvbGwgInNl Y29uZCBTQUNNIFdHIFZpcnR1YWwgTWVldGluZyAtIGFsbCB0aW1lcyBFU1QuIg0KDQoNCg0KW0lt YWdlIHJlbW92ZWQgYnkgc2VuZGVyLl08aHR0cHM6Ly9kb29kbGUuY29tLz90bWFpbD1wb2xsX2lu dml0ZWNvbnRhY3RfcGFydGljaXBhbnRfaW52aXRhdGlvbiZ0bGluaz1sb2dvPg0KDQoNCg0KSGkg dGhlcmUsDQoNCg0KDQoNCg0KRGFuIFJvbWFzY2FudSAoZHJvbWFzY2FAYXZheWEuY29tKSBpbnZp dGVzIHlvdSB0byBwYXJ0aWNpcGF0ZSBpbiB0aGUgRG9vZGxlIHBvbGwgInNlY29uZCBTQUNNIFdH IFZpcnR1YWwgTWVldGluZyAtIGFsbCB0aW1lcyBFU1QiLg0KDQoNCkRhbiBSb21hc2NhbnUgc2F5 czoNCnRoZSBzZWNvbmQgU0FDTSBXRyBWaXJ0dWFsIE1lZXRpbmcgLSBzZWNvbmQgd2VlayBvZiBG ZWJydWFyeSAyMDE0DQoNCmFsbCB0aW1lcyBFU1QNCg0KDQoNClBhcnRpY2lwYXRlIG5vdzxodHRw czovL2Rvb2RsZS5jb20vdnRycjZ3NDljNHFycmk4Mj90bWFpbD1wb2xsX2ludml0ZWNvbnRhY3Rf cGFydGljaXBhbnRfaW52aXRhdGlvbiZ0bGluaz1wb2xsYnRuPg0KDQoNCg0KDQpbSW1hZ2UgcmVt b3ZlZCBieSBzZW5kZXIuXQ0KDQpXaGF0IGlzIERvb2RsZT8gRG9vZGxlIGlzIGEgd2ViIHNlcnZp Y2UgdGhhdCBoZWxwcyBEYW4gUm9tYXNjYW51IHRvIGZpbmQgYSBzdWl0YWJsZSBkYXRlIGZvciBt ZWV0aW5nIHdpdGggYSBncm91cCBvZiBwZW9wbGUuIExlYXJuIG1vcmUgYWJvdXQgaG93IERvb2Rs ZSB3b3Jrcy48aHR0cHM6Ly9kb29kbGUuY29tL21haW4uaHRtbD90bGluaz1jaGVja091dExpbmsm dG1haWw9cG9sbF9pbnZpdGVjb250YWN0X3BhcnRpY2lwYW50X2ludml0YXRpb24+DQoNCg0KDQpZ b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGUtbWFpbCBiZWNhdXNlICJEYW4gUm9tYXNjYW51IiBoYXMg aW52aXRlZCB5b3UgdG8gcGFydGljaXBhdGUgaW4gdGhlIERvb2RsZSBwb2xsICJzZWNvbmQgU0FD TSBXRyBWaXJ0dWFsIE1lZXRpbmcgLSBhbGwgdGltZXMgRVNULiINCg0KDQoNCkRvb2RsZSBBRywg V2VyZHN0cmFzc2UgMjEsIDgwMjEgWsO8cmljaA0KDQoNCg0KDQo= --_000_9904FB1B0159DA42B0B887B7FA8119CA129F5163AZFFEXMB04globa_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkNvdXJpZXI7DQoJcGFub3NlLTE6MiA3IDQgOSAyIDIgNSAyIDQgNDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIg NCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0K CXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCi8qIFN0eWxlIERl ZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJ e21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7 DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4u TXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRl eHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0Zv bGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0K CWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0 LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4 LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMjVpbiAxLjBpbiAxLjI1aW47fQ0KZGl2Lldv cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAy NiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+ DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5n PSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2Vj dGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPkhpLA0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BbGwgZm9sa3Mgd2hvIGFyZSBpbnRlcmVz dGVkIGluIHBhcnRpY2lwYXRpbmcgaW4gdGhlIHNlY29uZCB2aXJ0dWFsIGludGVyaW0gbWVldGlu ZyBvZiBTQUNNIGR1cmluZyB0aGUgZmlyc3Qgd2VlayBvZiBGZWJydWFyeSDigJMgcGxlYXNlIGVu dGVyIHlvdXIgcHJlZmVyZW5jZXMNCiBpbiB0aGUgRG9vZGxlIHBvbGwgaWYgeW91IGRpZCBub3Qg ZG8gaXQgeWV0LiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5EYW48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAj QjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBzYWNtIFtt YWlsdG86c2FjbS1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5EYW4gUm9t YXNjYW51ICh2aWEgRG9vZGxlKTxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIERlY2VtYmVy IDE4LCAyMDEzIDU6NTUgUE08YnI+DQo8Yj5Ubzo8L2I+IHNhY21AaWV0Zi5vcmc8YnI+DQo8Yj5T dWJqZWN0OjwvYj4gW3NhY21dIHNlY29uZCBTQUNNIFdHIFZpcnR1YWwgTWVldGluZyAtIGFsbCB0 aW1lcyBFU1Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbjtiYWNrZ3JvdW5kOndoaXRlIj5EYW4gUm9tYXNjYW51IGludml0ZXMgeW91IHRvIHBhcnRp Y2lwYXRlIGluIHRoZSBEb29kbGUgcG9sbCAmcXVvdDtzZWNvbmQgU0FDTSBXRyBWaXJ0dWFsIE1l ZXRpbmcgLSBhbGwgdGltZXMgRVNULiZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 IGFsaWduPSJjZW50ZXIiPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIw IiBjZWxsc3BhY2luZz0iMCIgY2VsbHBhZGRpbmc9IjAiIHdpZHRoPSIxMDAlIiBzdHlsZT0id2lk dGg6MTAwLjAlO21hcmdpbi1sZWZ0Oi41aW47YmFja2dyb3VuZDp3aGl0ZTtoZWlnaHQ6MTAwJSFp bXBvcnRhbnQ7d2lkdGg6MTAwJSFpbXBvcnRhbnQiPg0KPHRib2R5Pg0KPHRyPg0KPHRkIHZhbGln bj0idG9wIiBzdHlsZT0icGFkZGluZzowaW4gMGluIDBpbiAwaW4iPg0KPGRpdiBhbGlnbj0iY2Vu dGVyIj4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHNwYWNp bmc9IjAiIGNlbGxwYWRkaW5nPSIwIiB3aWR0aD0iNDgwIiBzdHlsZT0id2lkdGg6NS4waW47YmFj a2dyb3VuZDp3aGl0ZSI+DQo8dGJvZHk+DQo8dHIgc3R5bGU9ImhlaWdodDoyMS4wcHQiPg0KPHRk IGNvbHNwYW49IjQiIHN0eWxlPSJwYWRkaW5nOjBpbiAwaW4gMGluIDBpbjtoZWlnaHQ6MjEuMHB0 Ij48L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCBzdHlsZT0icGFkZGluZzowaW4gMGluIDBpbiAwaW4i Pg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxsc3BhY2luZz0i MCIgY2VsbHBhZGRpbmc9IjAiIHdpZHRoPSI0ODAiIHN0eWxlPSJ3aWR0aDo1LjBpbjtiYWNrZ3Jv dW5kOndoaXRlIiBpZD0idGVtcGxhdGVIZWFkZXIiPg0KPHRib2R5Pg0KPHRyIHN0eWxlPSJoZWln aHQ6MjEuMHB0Ij4NCjx0ZCBjb2xzcGFuPSI0IiBzdHlsZT0icGFkZGluZzowaW4gMGluIDBpbiAw aW47aGVpZ2h0OjIxLjBwdCI+PC90ZD4NCjwvdHI+DQo8dHIgc3R5bGU9ImhlaWdodDoxOS41cHQi Pg0KPHRkIHdpZHRoPSIxNSIgdmFsaWduPSJib3R0b20iIHN0eWxlPSJ3aWR0aDoxMS4yNXB0O3Bh ZGRpbmc6MGluIDBpbiAwaW4gMGluO2hlaWdodDoxOS41cHQiPg0KPC90ZD4NCjx0ZCB3aWR0aD0i MTIwIiB2YWxpZ249ImJvdHRvbSIgc3R5bGU9IndpZHRoOjEuMjVpbjtwYWRkaW5nOjBpbiAwaW4g MGluIDBpbjtoZWlnaHQ6MTkuNXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0 dHBzOi8vZG9vZGxlLmNvbS8/dG1haWw9cG9sbF9pbnZpdGVjb250YWN0X3BhcnRpY2lwYW50X2lu dml0YXRpb24mYW1wO3RsaW5rPWxvZ28iPjxzcGFuIHN0eWxlPSJib3JkZXI6c29saWQgd2luZG93 dGV4dCAxLjBwdDtwYWRkaW5nOjBpbjt0ZXh0LWRlY29yYXRpb246bm9uZSI+PGltZyBib3JkZXI9 IjAiIHdpZHRoPSIyNiIgaGVpZ2h0PSIyNiIgaWQ9Il94MDAwMF9pMTAyNSIgc3JjPSJjaWQ6aW1h Z2UwMDEuanBnQDAxQ0VGQ0I2LjFGODFBMkMwIiBhbHQ9IkltYWdlIHJlbW92ZWQgYnkgc2VuZGVy LiI+PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgd2lkdGg9IjMzMCIgdmFs aWduPSJib3R0b20iIHN0eWxlPSJ3aWR0aDoyNDcuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gMGlu O2hlaWdodDoxOS41cHQiPg0KPC90ZD4NCjx0ZCB3aWR0aD0iMTUiIHZhbGlnbj0iYm90dG9tIiBz dHlsZT0id2lkdGg6MTEuMjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDBpbjtoZWlnaHQ6MTkuNXB0 Ij4NCjwvdGQ+DQo8L3RyPg0KPHRyIHN0eWxlPSJoZWlnaHQ6OS4wcHQiPg0KPHRkIGNvbHNwYW49 IjQiIHN0eWxlPSJwYWRkaW5nOjBpbiAwaW4gMGluIDBpbjtoZWlnaHQ6OS4wcHQiPjwvdGQ+DQo8 L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8L3RkPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBpbiAw aW4gMGluIDBpbiI+PC90ZD4NCjx0ZCBzdHlsZT0icGFkZGluZzowaW4gMGluIDBpbiAwaW4iPjwv dGQ+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGluIDBpbiAwaW4gMGluIj48L3RkPg0KPC90cj4NCjx0 cj4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg I0UwRTdGMCAxLjBwdDtiYWNrZ3JvdW5kOiNGNUY5RkQ7cGFkZGluZzowaW4gMGluIDBpbiAwaW4i Pg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxsc3BhY2luZz0i MCIgY2VsbHBhZGRpbmc9IjAiIHdpZHRoPSIxMDAlIiBzdHlsZT0id2lkdGg6MTAwLjAlIj4NCjx0 Ym9keT4NCjx0cj4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6MTUuMHB0IDExLjI1 cHQgMGluIDExLjI1cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0 OjE4Ljc1cHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyMjIyMjIiPkhpIHRoZXJlLA0KPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjwvdGQ+DQo8dGQg c3R5bGU9InBhZGRpbmc6MGluIDBpbiAwaW4gMGluIj48L3RkPg0KPHRkIHN0eWxlPSJwYWRkaW5n OjBpbiAwaW4gMGluIDBpbiI+PC90ZD4NCjx0ZCBzdHlsZT0icGFkZGluZzowaW4gMGluIDBpbiAw aW4iPjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIHZhbGlnbj0idG9wIiBzdHlsZT0iYmFja2dyb3Vu ZDojRjVGOUZEO3BhZGRpbmc6MGluIDBpbiAwaW4gMGluIj4NCjx0YWJsZSBjbGFzcz0iTXNvTm9y bWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHNwYWNpbmc9IjAiIGNlbGxwYWRkaW5nPSIwIiB3aWR0 aD0iMTAwJSIgc3R5bGU9IndpZHRoOjEwMC4wJSI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgdmFsaWdu PSJ0b3AiIHN0eWxlPSJwYWRkaW5nOjBpbiAxMS4yNXB0IDBpbiAxMS4yNXB0Ij4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxMy41cHQiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM1 NzU3NTciPiZuYnNwOw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Ri b2R5Pg0KPC90YWJsZT4NCjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGluIDBpbiAwaW4gMGlu Ij48L3RkPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBpbiAwaW4gMGluIDBpbiI+PC90ZD4NCjx0ZCBz dHlsZT0icGFkZGluZzowaW4gMGluIDBpbiAwaW4iPjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIHZh bGlnbj0idG9wIiBzdHlsZT0iYmFja2dyb3VuZDojRjVGOUZEO3BhZGRpbmc6MGluIDExLjI1cHQg MTUuMHB0IDExLjI1cHQiPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIw IiBjZWxsc3BhY2luZz0iMCIgY2VsbHBhZGRpbmc9IjAiIHdpZHRoPSIxMDAlIiBzdHlsZT0id2lk dGg6MTAwLjAlIj4NCjx0Ym9keT4NCjx0cj4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRp bmc6MGluIDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhl aWdodDoxOC43NXB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojNTc1NzU3Ij5EYW4gUm9tYXNjYW51IChkcm9t YXNjYUBhdmF5YS5jb20pIGludml0ZXMgeW91IHRvIHBhcnRpY2lwYXRlIGluIHRoZSBEb29kbGUg cG9sbA0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyMjIyMjIiPiZxdW90O3NlY29uZCBTQUNNIFdH IFZpcnR1YWwgTWVldGluZyAtIGFsbCB0aW1lcyBFU1QmcXVvdDs8L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzU3NTc1NyI+Lg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Ri b2R5Pg0KPC90YWJsZT4NCjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGluIDBpbiAwaW4gMGlu Ij48L3RkPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBpbiAwaW4gMGluIDBpbiI+PC90ZD4NCjx0ZCBz dHlsZT0icGFkZGluZzowaW4gMGluIDBpbiAwaW4iPjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIHZh bGlnbj0idG9wIiBzdHlsZT0iYmFja2dyb3VuZDojRjVGOUZEO3BhZGRpbmc6MGluIDExLjI1cHQg MTMuNXB0IDExLjI1cHQiPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIw IiBjZWxsc3BhY2luZz0iMCIgY2VsbHBhZGRpbmc9IjAiIHdpZHRoPSIxMDAlIiBzdHlsZT0id2lk dGg6MTAwLjAlIj4NCjx0Ym9keT4NCjx0cj4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNEMEUzRkIgMi4yNXB0O3BhZGRpbmc6Ni4wcHQgMGlu IDYuMHB0IDEwLjVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6 MTYuNXB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTpDb3VyaWVy O2NvbG9yOiMyMjIyMjIiPkRhbiBSb21hc2NhbnUgc2F5czoNCjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNi41cHQiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OkNvdXJpZXI7Y29sb3I6IzU3NTc1 NyI+dGhlIHNlY29uZCBTQUNNIFdHIFZpcnR1YWwgTWVldGluZyAtIHNlY29uZCB3ZWVrIG9mIEZl YnJ1YXJ5IDIwMTQ8YnI+DQo8YnI+DQphbGwgdGltZXMgRVNUIDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8L3RkPg0KPHRkIHN0eWxlPSJw YWRkaW5nOjBpbiAwaW4gMGluIDBpbiI+PC90ZD4NCjx0ZCBzdHlsZT0icGFkZGluZzowaW4gMGlu IDBpbiAwaW4iPjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGluIDBpbiAwaW4gMGluIj48L3Rk Pg0KPC90cj4NCjx0cj4NCjx0ZCBzdHlsZT0iYmFja2dyb3VuZDojREZFQ0ZDO3BhZGRpbmc6MGlu IDBpbiAwaW4gMGluIj4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIg Y2VsbHNwYWNpbmc9IjAiIGNlbGxwYWRkaW5nPSIwIiB3aWR0aD0iMTAwJSIgc3R5bGU9IndpZHRo OjEwMC4wJSI+DQo8dGJvZHk+DQo8dHIgc3R5bGU9ImhlaWdodDo3LjVwdCI+DQo8dGQgd2lkdGg9 IjE1IiBjb2xzcGFuPSIzIiB2YWxpZ249InRvcCIgc3R5bGU9IndpZHRoOjExLjI1cHQ7cGFkZGlu ZzowaW4gMGluIDBpbiAwaW47aGVpZ2h0OjcuNXB0Ij4NCjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRk IHN0eWxlPSJwYWRkaW5nOjBpbiAwaW4gMGluIDBpbjtib3gtc2hhZG93OiAwcHggMHB4IDJweCAw IHJnYigwLCAwLCAwLjI4KTtib3JkZXItcmFkaXVzOiAzcHgiPg0KPHRhYmxlIGNsYXNzPSJNc29O b3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCIgc3R5bGU9ImJvcmRlci1zcGFj aW5nOiAxNHB4IDBweCI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgc3R5bGU9ImJhY2tncm91bmQ6IzAw NjZERDtwYWRkaW5nOjMuMHB0IDUuMjVwdCAzLjBwdCA1LjI1cHQiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDowaW47bWFyZ2luLXJpZ2h0OjIuMjVwdDtt YXJnaW4tYm90dG9tOjBpbjttYXJnaW4tbGVmdDoxMy41cHQ7bWFyZ2luLWJvdHRvbTouMDAwMXB0 O2xpbmUtaGVpZ2h0OjEzLjVwdCI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YSBo cmVmPSJodHRwczovL2Rvb2RsZS5jb20vdnRycjZ3NDljNHFycmk4Mj90bWFpbD1wb2xsX2ludml0 ZWNvbnRhY3RfcGFydGljaXBhbnRfaW52aXRhdGlvbiZhbXA7dGxpbms9cG9sbGJ0biI+PHNwYW4g c3R5bGU9ImNvbG9yOndoaXRlO3RleHQtZGVjb3JhdGlvbjpub25lIj5QYXJ0aWNpcGF0ZSZuYnNw O25vdzwvc3Bhbj48L2E+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L2I+PC9wPg0KPC90ZD4NCjwvdHI+ DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGluIDBpbiAw aW4gMGluIj48L3RkPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBpbiAwaW4gMGluIDBpbiI+PC90ZD4N CjwvdHI+DQo8dHIgc3R5bGU9ImhlaWdodDo3LjVwdCI+DQo8dGQgd2lkdGg9IjE1IiBjb2xzcGFu PSIzIiB2YWxpZ249InRvcCIgc3R5bGU9IndpZHRoOjExLjI1cHQ7cGFkZGluZzowaW4gMGluIDBp biAwaW47aGVpZ2h0OjcuNXB0Ij4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8 L3RkPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBpbiAwaW4gMGluIDBpbiI+PC90ZD4NCjx0ZCBzdHls ZT0icGFkZGluZzowaW4gMGluIDBpbiAwaW4iPjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGlu IDBpbiAwaW4gMGluIj48L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9 ImJvcmRlcjpzb2xpZCAjREZFQ0ZDIDEuMHB0O3BhZGRpbmc6MTEuMjVwdCAxMS4yNXB0IDExLjI1 cHQgMTEuMjVwdCI+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNl bGxzcGFjaW5nPSIwIiBjZWxscGFkZGluZz0iMCIgd2lkdGg9IjEwMCUiIHN0eWxlPSJ3aWR0aDox MDAuMCUiPg0KPHRib2R5Pg0KPHRyPg0KPHRkIHdpZHRoPSIzNSIgdmFsaWduPSJ0b3AiIHN0eWxl PSJ3aWR0aDoyNi4yNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJib3JkZXI6c29saWQgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5n OjBpbiI+PGltZyBib3JkZXI9IjAiIHdpZHRoPSIxMDAiIGhlaWdodD0iMTAwIiBpZD0iX3gwMDAw X2kxMDI2IiBzcmM9ImNpZDp+V1JEMDAwLmpwZyIgYWx0PSJJbWFnZSByZW1vdmVkIGJ5IHNlbmRl ci4iPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxl PSJwYWRkaW5nOjBpbiAwaW4gMGluIDBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImxpbmUtaGVpZ2h0OjE2LjVwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMyMjIyMjIiPldoYXQgaXMgRG9vZGxlPzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzU3NTc1NyI+IERvb2RsZSBpcyBhIHdlYiBzZXJ2aWNlIHRoYXQgaGVscHMNCiBEYW4g Um9tYXNjYW51IHRvIGZpbmQgYSBzdWl0YWJsZSBkYXRlIGZvciBtZWV0aW5nIHdpdGggYSBncm91 cCBvZiBwZW9wbGUuIDxhIGhyZWY9Imh0dHBzOi8vZG9vZGxlLmNvbS9tYWluLmh0bWw/dGxpbms9 Y2hlY2tPdXRMaW5rJmFtcDt0bWFpbD1wb2xsX2ludml0ZWNvbnRhY3RfcGFydGljaXBhbnRfaW52 aXRhdGlvbiI+DQpMZWFybiBtb3JlIGFib3V0IGhvdyBEb29kbGUgd29ya3MuPC9hPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4N CjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGluIDBpbiAwaW4gMGluIj48L3RkPg0KPHRkIHN0 eWxlPSJwYWRkaW5nOjBpbiAwaW4gMGluIDBpbiI+PC90ZD4NCjx0ZCBzdHlsZT0icGFkZGluZzow aW4gMGluIDBpbiAwaW4iPjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIHZhbGlnbj0idG9wIiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRjVGOUZEIDEuMHB0O3BhZGRpbmc6MGlu IDBpbiAwaW4gMGluIj4NCjxkaXYgYWxpZ249ImNlbnRlciI+DQo8dGFibGUgY2xhc3M9Ik1zb05v cm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxzcGFjaW5nPSIwIiBjZWxscGFkZGluZz0iMCI+DQo8 dGJvZHk+DQo8dHIgc3R5bGU9ImhlaWdodDouMjVpbiI+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGlu IDBpbiAwaW4gMGluO2hlaWdodDouMjVpbiI+PC90ZD4NCjwvdHI+DQo8dHI+DQo8dGQgdmFsaWdu PSJ0b3AiIHN0eWxlPSJwYWRkaW5nOjBpbiAxMS4yNXB0IDYuNzVwdCAxMS4yNXB0Ij4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxMi4wcHQiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojOTk5OTk5Ij5Zb3UgaGF2ZSByZWNlaXZlZCB0aGlzIGUtbWFpbCBi ZWNhdXNlICZxdW90O0RhbiBSb21hc2NhbnUmcXVvdDsgaGFzIGludml0ZWQgeW91IHRvIHBhcnRp Y2lwYXRlIGluIHRoZSBEb29kbGUgcG9sbCAmcXVvdDtzZWNvbmQgU0FDTSBXRyBWaXJ0dWFsIE1l ZXRpbmcNCiAtIGFsbCB0aW1lcyBFU1QuJnF1b3Q7IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv dGQ+DQo8L3RyPg0KPHRyIHN0eWxlPSJoZWlnaHQ6OS4wcHQiPg0KPHRkIHN0eWxlPSJwYWRkaW5n OjBpbiAwaW4gMGluIDBpbjtoZWlnaHQ6OS4wcHQiPjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwv dGFibGU+DQo8L2Rpdj4NCjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGluIDBpbiAwaW4gMGlu Ij48L3RkPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBpbiAwaW4gMGluIDBpbiI+PC90ZD4NCjx0ZCBz dHlsZT0icGFkZGluZzowaW4gMGluIDBpbiAwaW4iPjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIHZh bGlnbj0idG9wIiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjREREREREIDEu MHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gMGluIj4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFi bGUiIGJvcmRlcj0iMCIgY2VsbHNwYWNpbmc9IjAiIGNlbGxwYWRkaW5nPSIwIiB3aWR0aD0iMTAw JSIgc3R5bGU9IndpZHRoOjEwMC4wJSI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgdmFsaWduPSJ0b3Ai IHN0eWxlPSJwYWRkaW5nOjkuMHB0IDExLjI1cHQgMTUuMHB0IDExLjI1cHQiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjEyLjc1cHQiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojOTk5OTk5Ij5Eb29kbGUgQUcsIFdlcmRzdHJhc3NlIDIxLCA4MDIxIFrD vHJpY2gNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwv dGFibGU+DQo8L3RkPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBpbiAwaW4gMGluIDBpbiI+PC90ZD4N Cjx0ZCBzdHlsZT0icGFkZGluZzowaW4gMGluIDBpbiAwaW4iPjwvdGQ+DQo8dGQgc3R5bGU9InBh ZGRpbmc6MGluIDBpbiAwaW4gMGluIj48L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0K PC9kaXY+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_9904FB1B0159DA42B0B887B7FA8119CA129F5163AZFFEXMB04globa_-- --_006_9904FB1B0159DA42B0B887B7FA8119CA129F5163AZFFEXMB04globa_ Content-Type: image/jpeg; name="~WRD000.jpg" Content-Description: ~WRD000.jpg Content-Disposition: inline; filename="~WRD000.jpg"; size=823; creation-date="Thu, 19 Dec 2013 10:28:18 GMT"; modification-date="Thu, 19 Dec 2013 10:28:18 GMT" Content-ID: <~WRD000.jpg> Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCABkAGQDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD3+iii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo ooAKKKKACiiigAooooAKKKKACiiigD//2Q== --_006_9904FB1B0159DA42B0B887B7FA8119CA129F5163AZFFEXMB04globa_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=344; creation-date="Thu, 19 Dec 2013 10:30:42 GMT"; modification-date="Thu, 19 Dec 2013 10:30:42 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/wAALCAAaABoBAREA/8QAHwAAAQUBAQEB AQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1Fh ByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZ WmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXG x8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/9oACAEBAAA/APZqKKKKKKKKKKKKKKK/ /9k= --_006_9904FB1B0159DA42B0B887B7FA8119CA129F5163AZFFEXMB04globa_-- --_007_9904FB1B0159DA42B0B887B7FA8119CA129F5163AZFFEXMB04globa_ Content-Type: text/plain; name="ATT00001.txt" Content-Description: ATT00001.txt Content-Disposition: attachment; filename="ATT00001.txt"; size=127; creation-date="Wed, 18 Dec 2013 15:55:18 GMT"; modification-date="Wed, 18 Dec 2013 15:55:18 GMT" Content-ID: Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNhY20gbWFp bGluZyBsaXN0DQpzYWNtQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3NhY20NCg== --_007_9904FB1B0159DA42B0B887B7FA8119CA129F5163AZFFEXMB04globa_-- From dromasca@avaya.com Tue Dec 24 02:41:50 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22A131ADEA7 for ; Tue, 24 Dec 2013 02:41:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.262 X-Spam-Level: X-Spam-Status: No, score=0.262 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XBdWFOxYWcJS for ; Tue, 24 Dec 2013 02:41:48 -0800 (PST) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id A8A701ADEA3 for ; Tue, 24 Dec 2013 02:41:48 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFAP9juVKHCzI1/2dsb2JhbABZgmohgQ25e4EbFnSCJwEBAxIoUQEVFRRCHwcBBBsah2IBoTKETqR9F45qg1uBEwSfA4sogy2CKg X-IronPort-AV: E=Sophos;i="4.95,542,1384318800"; d="scan'208";a="42573812" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 24 Dec 2013 05:41:44 -0500 Received: from unknown (HELO AZ-FFEXHC03.global.avaya.com) ([135.64.58.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES128-SHA; 24 Dec 2013 05:30:36 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC03.global.avaya.com ([135.64.58.13]) with mapi id 14.03.0158.001; Tue, 24 Dec 2013 05:41:42 -0500 From: "Romascanu, Dan (Dan)" To: "sacm@ietf.org" Thread-Topic: second virtual interim date and time Thread-Index: Ac8AlLtYobYQvFyaQEK7uq2ZDFC3+Q== Date: Tue, 24 Dec 2013 10:41:42 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA129F7258@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sacm] second virtual interim date and time X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Dec 2013 10:41:50 -0000 Doodle has spoken and according to the results of the poll the best date fo= r the second virtual interim meeting of SACM is Tuesday February 4, 2014, 1= 1AM - 1PM EST.=20 I will go ahead and request our AD to approve the meeting and the secretari= at to set Webex.=20 Regards and Happy Holidays, Dan