From lnunez@c3isecurity.com Wed Aug 1 08:11:31 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24F0711E80EE for ; Wed, 1 Aug 2012 08:11:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.979 X-Spam-Level: X-Spam-Status: No, score=-2.979 tagged_above=-999 required=5 tests=[AWL=0.621, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L-RaGawxVS2j for ; Wed, 1 Aug 2012 08:11:30 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4CDEE11E80AD for ; Wed, 1 Aug 2012 08:11:30 -0700 (PDT) Received: by ggnc4 with SMTP id c4so8001426ggn.31 for ; Wed, 01 Aug 2012 08:11:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer:x-gm-message-state; bh=1XJmVGBs/GnywFzUC01vqYiy/5KYitgaJrnO/jAk9oc=; b=ekWO3UejyEZ8iB5Qk68lsr32/ciq7xpN388C/4VlE3Gtrn6FFvA5jADdA12nxdw74I EXOFnO1Zlwtp50GD6FotZKGHh5MG7dnE+myMjQLjjyWjP3pEcl0eFWcsf/eGOcpC4wfF QD2iBQJKoou9BWgO6MhDTKtCIu4YmZG7GRoZf90u4uks+rZp00BI44m9XhV6Y/b4SXop xmlAUqyAXPjFO5YzvPO6zWNVxzQiTc5AVIOc4eF7rNzbihWDjZCkSBOwE7JFMd7KAvBx CmApl4XYsnAQjv583dVbUoEtlP4BPrpLi7z/qbtONeMQlrwLVwMNo4qn0i9gG3DNlQkS l+Qg== Received: by 10.236.177.42 with SMTP id c30mr17089727yhm.37.1343833889761; Wed, 01 Aug 2012 08:11:29 -0700 (PDT) Received: from [192.168.1.32] (cpe-066-057-081-254.nc.res.rr.com. [66.57.81.254]) by mx.google.com with ESMTPS id t20sm3033642anl.19.2012.08.01.08.11.28 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 01 Aug 2012 08:11:28 -0700 (PDT) From: Luis Nunez Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 1 Aug 2012 11:11:28 -0400 Message-Id: To: sacm@ietf.org, mile@ietf.org Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQmKG5x0bPztqTjwX652WjupJYg7iZ3y2SXJreu2FpXga+Mevvx6XGAtvNY7oLsuY0eDDRhj Subject: [mile] VERIS X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 15:11:31 -0000 Anyone familiar with Vocabulary for Event Recording and Incident Sharing = (VERIS)? Is this something that competes with MILE? or does it = complement, cooperate with existing efforts? Information sharing issues are on the rise and I would like to make sure = we are aware of the various efforts under way. We want to as a = community avoid duplication. = http://securityblog.verizonbusiness.com/2012/08/01/announcing-veriscommuni= ty-net/ thanks. -ln= From krmaxwell@gmail.com Wed Aug 1 08:25:47 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A51B621F8999; Wed, 1 Aug 2012 08:25:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3YD4njBE0Sf1; Wed, 1 Aug 2012 08:25:47 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 881B521F8998; Wed, 1 Aug 2012 08:25:46 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so4750749wgb.13 for ; Wed, 01 Aug 2012 08:25:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=kiuumhZtuUYkOXQbeWAJKmk2pgdkx/GTTFGj0bqLCJA=; b=OBX5G4xuF8+AmVLWvJahAKR+4Mgqk6wiw9L73mvehixFjJH2+dnEsYQwvn5bQA8Utm 7QFBd6ubpkMENGEcn4xcSaGpXeqawq8C3T6E2Lkj7fw9LmKwyLWJAciQuJZnOBQ2DwxK tCeM73jiUkInBs9RpIBFH3LUKCUrwdKAmu2g1cal0XWerzAH3bLH7vWoWjpMuySzbD4+ FHrIc/c4paVl7PbI/1FpHcjHfX3popkLfQl/FOPlC8wbMtEXjSMgksqZ6u+06RYU8aBB GVKIZd7LDe0DTFUTmIH7KsQyq8M2QHh8ndcwh8loHyN8SE76a62VMVxsQgdQrBq+7+4r 5P2Q== Received: by 10.216.101.1 with SMTP id a1mr8411594weg.216.1343834745434; Wed, 01 Aug 2012 08:25:45 -0700 (PDT) MIME-Version: 1.0 Sender: krmaxwell@gmail.com Received: by 10.194.13.67 with HTTP; Wed, 1 Aug 2012 08:25:25 -0700 (PDT) In-Reply-To: References: From: Kyle Maxwell Date: Wed, 1 Aug 2012 10:25:25 -0500 X-Google-Sender-Auth: 1MFVq97Rwf5EqK0Kz3YMS3X-WVg Message-ID: To: Luis Nunez Content-Type: multipart/alternative; boundary=e0cb4e6ffa29a3717f04c635e882 Cc: mile@ietf.org, sacm@ietf.org Subject: Re: [mile] VERIS X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 15:25:47 -0000 --e0cb4e6ffa29a3717f04c635e882 Content-Type: text/plain; charset=ISO-8859-1 I'm on the VERIS team here at Verizon, so I can help answer any specific questions you might have. In a general sense, I don't believe VERIS and MILE really compete but are complementary to each other. On Wed, Aug 1, 2012 at 10:11 AM, Luis Nunez wrote: > Anyone familiar with Vocabulary for Event Recording and Incident Sharing > (VERIS)? Is this something that competes with MILE? or does it complement, > cooperate with existing efforts? > > Information sharing issues are on the rise and I would like to make sure > we are aware of the various efforts under way. We want to as a community > avoid duplication. > > > http://securityblog.verizonbusiness.com/2012/08/01/announcing-veriscommunity-net/ > > -- > Kyle Maxwell [ > kylem@xwell.org] > http://www.xwell.org > Twitter: @kylemaxwell > > --e0cb4e6ffa29a3717f04c635e882 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I'm on the VERIS team here at Verizon, so I can help answer any specifi= c questions you might have. In a general sense, I don't believe VERIS a= nd MILE really compete but are complementary to each other.=A0

On Wed, Aug 1, 2012 at 10:11 AM, Luis Nunez <lnunez@c3isecurity.com= > wrote:
Anyone familiar with Vocabulary for Event Recording and Incident Sharing (V= ERIS)? =A0Is this something that competes with MILE? or does it complement,= cooperate with existing efforts?

Information sharing issues are on the rise and I would like to make sure we= are aware of the various efforts under way. =A0We want to as a community a= void duplication.

http://securityblog.verizonbusiness.co= m/2012/08/01/announcing-veriscommunity-net/
--e0cb4e6ffa29a3717f04c635e882-- From osantos@cisco.com Wed Aug 1 08:43:39 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8815421F8B38; Wed, 1 Aug 2012 08:43:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ovf8texgGJS8; Wed, 1 Aug 2012 08:43:37 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 52C2621F8B36; Wed, 1 Aug 2012 08:43:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=osantos@cisco.com; l=10472; q=dns/txt; s=iport; t=1343835817; x=1345045417; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=TOhTVkhM9FpsV5s8I3LT87XRbKLCSWngFc6gkm6EgCs=; b=l8efBtreloJMZ/FYmN2d1iEi0YdTNhculf80wm90QfrC1WK6lLwqMU2Q 69b0qxjLyblh8wlrIEzu6naGhGcRa8UpwR5O5YatAMEJjVDTwzWRam+MS JLWMEiwPXOlvwwNrTDGz/dKRuw6VmvsmLXcFXZvfnzRXXiwBln8RMu1UI I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmEFAN5NGVCtJXG8/2dsb2JhbAArFwOCSqVeiBMBiFSBB4IgAQEBBBIBGigkDgICAQgHCgQBAQsdBxsXFAkIAgQBDQUIDA6HawspnDGgTwSLRYNogkFgA5FjhHiJcYMigWaCX4Ff X-IronPort-AV: E=Sophos;i="4.77,694,1336348800"; d="scan'208,217";a="107458554" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-7.cisco.com with ESMTP; 01 Aug 2012 15:43:36 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q71FhatM003314 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 1 Aug 2012 15:43:36 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.33]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0298.004; Wed, 1 Aug 2012 10:43:36 -0500 From: "Omar Santos (osantos)" To: Kyle Maxwell , Luis Nunez Thread-Topic: [mile] VERIS Thread-Index: AQHNb/fxuesp/mqjsEWw3KuN6FC7UJdFZ6CA//+u9NA= Date: Wed, 1 Aug 2012 15:43:34 +0000 Message-ID: <93ED586BE669044CA2F91C5F3BE4FD9017AF76A0@xmb-aln-x09.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.117.110.37] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19076.006 x-tm-as-result: No--39.601100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_93ED586BE669044CA2F91C5F3BE4FD9017AF76A0xmbalnx09ciscoc_" MIME-Version: 1.0 Cc: "mile@ietf.org" , "sacm@ietf.org" Subject: Re: [mile] VERIS X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 15:43:40 -0000 --_000_93ED586BE669044CA2F91C5F3BE4FD9017AF76A0xmbalnx09ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Kyle, Thank you! I was going over the documentation (at the link below) and the c= ase studies / other collateral material; and I do see a little overlap with= SACM: http://veriscommunity.net/doku.php If the community is interested, would you mind giving a brief overview of V= ERIS in a few weeks? I can setup a Webex and record the session for those o= f you that cannot make it... Regards, Omar Santos Incident Manager, PSIRT Security Research and Operations Cisco Systems, Inc. Email: os@cisco.com Phone: +1 919 392 8635 PGP Key: 0x3AF27EDC Cisco.com - http://www.cisco.com Cisco Security Advisories and Notices - http://www.cisco.com/go/psirt From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Kyl= e Maxwell Sent: Wednesday, August 01, 2012 11:25 AM To: Luis Nunez Cc: mile@ietf.org; sacm@ietf.org Subject: Re: [mile] VERIS I'm on the VERIS team here at Verizon, so I can help answer any specific qu= estions you might have. In a general sense, I don't believe VERIS and MILE = really compete but are complementary to each other. On Wed, Aug 1, 2012 at 10:11 AM, Luis Nunez > wrote: Anyone familiar with Vocabulary for Event Recording and Incident Sharing (V= ERIS)? Is this something that competes with MILE? or does it complement, c= ooperate with existing efforts? Information sharing issues are on the rise and I would like to make sure we= are aware of the various efforts under way. We want to as a community avo= id duplication. http://securityblog.verizonbusiness.com/2012/08/01/announcing-veriscommunit= y-net/ -- Kyle Maxwell [kylem@xwell.org] http://www.xwell.org Twitter: @kylemaxwell --_000_93ED586BE669044CA2F91C5F3BE4FD9017AF76A0xmbalnx09ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Kyle,

 <= /p>

Thank you! I was going ov= er the documentation (at the link below) and the case studies / other colla= teral material; and I do see a little overlap with SACM:<= /p>

 <= /p>

http:= //veriscommunity.net/doku.php

 <= /p>

If the community is inter= ested, would you mind giving a brief overview of VERIS in a few weeks? I ca= n setup a Webex and record the session for those of you that cannot make it…

 <= /p>

Regards,

 <= /p>

Omar Santos

Incident Manager, PSIRT

Security Research and Ope= rations

Cisco Systems, Inc.<= /o:p>

Email: os@cisco.com<= /o:p>

Phone: +1 919 392 863= 5

PGP Key: 0x3AF27EDC<= /o:p>

 <= /p>

Cisco.com - http://www.ci= sco.com <http://www.cisco.com/>

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

 <= /p>

From: mile-bou= nces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Kyle Maxwell
Sent: Wednesday, August 01, 2012 11:25 AM
To: Luis Nunez
Cc: mile@ietf.org; sacm@ietf.org
Subject: Re: [mile] VERIS

 

I'm on the VERIS team= here at Verizon, so I can help answer any specific questions you might hav= e. In a general sense, I don't believe VERIS and MILE really compete but ar= e complementary to each other. 

On Wed, Aug 1, 2012 at 10:11 AM, Luis Nunez <lnunez@c3isecurity.= com> wrote:

Anyone familiar with Vocabulary for Event Recording = and Incident Sharing (VERIS)?  Is this something that competes with MI= LE? or does it complement, cooperate with existing efforts?

Information sharing issues are on the rise and I would like to make sure we= are aware of the various efforts under way.  We want to as a communit= y avoid duplication.

http://securityblog.verizonbusiness.co= m/2012/08/01/announcing-veriscommunity-net/

--
Kyle Maxwell [kyle= m@xwell.org]
http://www.xwell.org=
Twitter: @kylemaxwell

--_000_93ED586BE669044CA2F91C5F3BE4FD9017AF76A0xmbalnx09ciscoc_-- From lnunez@c3isecurity.com Wed Aug 1 08:45:28 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6E2611E8091 for ; Wed, 1 Aug 2012 08:45:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.443 X-Spam-Level: X-Spam-Status: No, score=-3.443 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r77Lh1vwyUYG for ; Wed, 1 Aug 2012 08:45:27 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id BAC2421F8B3A for ; Wed, 1 Aug 2012 08:45:27 -0700 (PDT) Received: by yenq13 with SMTP id q13so8055887yen.31 for ; Wed, 01 Aug 2012 08:45:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=MM71n4o6E+5f25kcYBsPYrFvUSdDGzVuq2uDVzEiHF0=; b=QM81XFLef0jn6GXXrYPyAoMWoc10rYQS4u/+eKmnI7YzjzNdxbmKqxvZtV3FKRVs8a IQmwbNv2Hj5OtZtstas2BL9LX3x3CuOeLjac3A5DlmhIgplssWZvt38C/cTOuoMlwV+K RzWf4QuosElBRSUn/BxQwEN5DyM7HuSfyh3CMdIsIqQfdRJ9+64S0VUNZ1e9sNtTVZvn 5qZsb1FAL1zSzyL2g2MQKgyMvdMt79rm4AoG5eZqhj4I5AJZIkzNw5eHoo/n7oNYNjNV bRQ7OfAna/qMxPqOZkGdDOJsNqL1s9lZ77GpgwFIfr/umEpeB71b70OVlG1Zau1Z6pvO 4fAA== Received: by 10.101.3.19 with SMTP id f19mr5316082ani.58.1343835927218; Wed, 01 Aug 2012 08:45:27 -0700 (PDT) Received: from [192.168.1.32] (cpe-066-057-081-254.nc.res.rr.com. [66.57.81.254]) by mx.google.com with ESMTPS id q17sm117657anm.12.2012.08.01.08.45.24 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 01 Aug 2012 08:45:24 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_18E8B76E-1444-42BF-ACD2-0EF5B64F1831" From: Luis Nunez In-Reply-To: Date: Wed, 1 Aug 2012 11:45:22 -0400 Message-Id: <1A341665-F6E2-40F6-9DB0-7ABB62ED3190@c3isecurity.com> References: To: Kyle Maxwell X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQn23fTNBuQj05RgCdhJBORJzE70hoUwQfecg/1yiAfg4zpSB9qyPoA/N1qTiYX11BCVJQBH Cc: mile@ietf.org, sacm@ietf.org Subject: Re: [mile] VERIS X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 15:45:29 -0000 --Apple-Mail=_18E8B76E-1444-42BF-ACD2-0EF5B64F1831 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi Kyle, thanks for the info and offer to field questions. Maybe at some point = it would worth while to see the connections and relationships of VERIS = and MILE. Some of the things we as a community grapple with is how the = various frameworks/specifications interact and work together. thanks. -ln On Aug 1, 2012, at 11:25 AM, Kyle Maxwell wrote: > I'm on the VERIS team here at Verizon, so I can help answer any = specific questions you might have. In a general sense, I don't believe = VERIS and MILE really compete but are complementary to each other.=20 >=20 > On Wed, Aug 1, 2012 at 10:11 AM, Luis Nunez = wrote: > Anyone familiar with Vocabulary for Event Recording and Incident = Sharing (VERIS)? Is this something that competes with MILE? or does it = complement, cooperate with existing efforts? >=20 > Information sharing issues are on the rise and I would like to make = sure we are aware of the various efforts under way. We want to as a = community avoid duplication. >=20 > = http://securityblog.verizonbusiness.com/2012/08/01/announcing-veriscommuni= ty-net/ >=20 > --=20 > Kyle Maxwell [kylem@xwell.org] > http://www.xwell.org > Twitter: @kylemaxwell >=20 --Apple-Mail=_18E8B76E-1444-42BF-ACD2-0EF5B64F1831 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1 Hi Kyle,
thanks for the info and offer to field questions.  Maybe at some point it would worth while to see the connections and relationships of VERIS and MILE.  Some of the things we as a community grapple with is how the various frameworks/specifications interact and work together.

thanks.

-ln
On Aug 1, 2012, at 11:25 AM, Kyle Maxwell wrote:

I'm on the VERIS team here at Verizon, so I can help answer any specific questions you might have. In a general sense, I don't believe VERIS and MILE really compete but are complementary to each other. 

On Wed, Aug 1, 2012 at 10:11 AM, Luis Nunez <lnunez@c3isecurity.com> wrote:
Anyone familiar with Vocabulary for Event Recording and Incident Sharing (VERIS)?  Is this something that competes with MILE? or does it complement, cooperate with existing efforts?

Information sharing issues are on the rise and I would like to make sure we are aware of the various efforts under way.  We want to as a community avoid duplication.

http://securityblog.verizonbusiness.com/2012/08/01/announcing-veriscommunity-net/

--
Kyle Maxwell [kylem@xwell.org]
http://www.xwell.org
Twitter: @kylemaxwell


--Apple-Mail=_18E8B76E-1444-42BF-ACD2-0EF5B64F1831-- From kathleen.moriarty@emc.com Wed Aug 1 08:45:39 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D704811E80D7; Wed, 1 Aug 2012 08:45:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AS2WNIE-qHgK; Wed, 1 Aug 2012 08:45:39 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id D04B411E8087; Wed, 1 Aug 2012 08:45:38 -0700 (PDT) Received: from hop04-l1d11-si04.isus.emc.com (HOP04-L1D11-SI04.isus.emc.com [10.254.111.24]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q71FjZhx019632 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Aug 2012 11:45:36 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd01.lss.emc.com [10.254.221.251]) by hop04-l1d11-si04.isus.emc.com (RSA Interceptor); Wed, 1 Aug 2012 11:45:20 -0400 Received: from mxhub36.corp.emc.com (mxhub36.corp.emc.com [10.254.93.84]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q71Fg7Vh012010; Wed, 1 Aug 2012 11:45:18 -0400 Received: from mx15a.corp.emc.com ([169.254.1.189]) by mxhub36.corp.emc.com ([::1]) with mapi; Wed, 1 Aug 2012 11:43:21 -0400 From: To: , , Date: Wed, 1 Aug 2012 11:43:21 -0400 Thread-Topic: [sacm] VERIS Thread-Index: Ac1v+AEHmq/saP/lRRWbdnxHU/whoQAAfd3H Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [mile] [sacm] VERIS X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 15:45:40 -0000 Hi Luis, Veris actually compliments the work in MILE. They have done some really go= od work and would great to see some of their lessons learned benefit the MI= LE work (if/where possible). I think we have a few people on list from Ver= izon following the work. Their input would be very helpful in the update t= o RFC5070 as well as if they think we need to extend to hit other important= use cases. There are a number of complimentary efforts that would be very nice to see = come together so that we could have a consistent way to share and communica= te incident information, learning from all of the hands-on experience. We = hit on this a little yesterday where we need to figure out if we include so= me additional high-level information in IODEF (the example was for malware)= is needed and then we point to more detailed information. We do want to t= arget relevant use cases of data that people share who would be using this = work. Veris may have some other areas that could be very useful. The hurd= le with any proprietary format is the same that we ran into with the MITRE = work, we need to be able to have normative references and be clear on IP co= ncerns. If work is brought into the IETF, that makes it clear and would be= easier to unify the solutions. This will be up to the other organizations= and if they are interested in bringing the work into MILE. We do want to make sure that we map back to use cases as we extend IODEF to= ensure we are creating work that will be useful to the community (share th= e right things). The VERIS work has put a lot of thought into this for the= ir customers as I am sure the other vendor formats have as well. Other related spaces where work has been done include malware (Mandiant's O= penIOC) and forensics (x.dexf from Korea and also work from Google, AFF). = The work from Korea transferred the IP, so we can build on that. Hopefully= , we can help the community by combining efforts using open standards enabl= ing vendors to implement interoperable solutions. Thanks, Kathleen ________________________________________ From: sacm-bounces@ietf.org [sacm-bounces@ietf.org] On Behalf Of Luis Nunez= [lnunez@c3isecurity.com] Sent: Wednesday, August 01, 2012 11:11 AM To: sacm@ietf.org; mile@ietf.org Subject: [sacm] VERIS Anyone familiar with Vocabulary for Event Recording and Incident Sharing (V= ERIS)? Is this something that competes with MILE? or does it complement, c= ooperate with existing efforts? Information sharing issues are on the rise and I would like to make sure we= are aware of the various efforts under way. We want to as a community avo= id duplication. http://securityblog.verizonbusiness.com/2012/08/01/announcing-veriscommunit= y-net/ thanks. -ln _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm From kathleen.moriarty@emc.com Wed Aug 1 08:48:10 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B009D11E8091; Wed, 1 Aug 2012 08:48:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.529 X-Spam-Level: X-Spam-Status: No, score=-2.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ff-5lj2DTJGG; Wed, 1 Aug 2012 08:48:09 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 4B60711E8087; Wed, 1 Aug 2012 08:48:08 -0700 (PDT) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q71Fm0Fq009362 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Aug 2012 11:48:03 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd03.lss.emc.com [10.254.221.145]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Wed, 1 Aug 2012 11:47:37 -0400 Received: from mxhub09.corp.emc.com (mxhub09.corp.emc.com [10.254.92.104]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q71Flbk3014547; Wed, 1 Aug 2012 11:47:37 -0400 Received: from mx15a.corp.emc.com ([169.254.1.189]) by mxhub09.corp.emc.com ([10.254.92.104]) with mapi; Wed, 1 Aug 2012 11:47:37 -0400 From: To: , Date: Wed, 1 Aug 2012 11:46:29 -0400 Thread-Topic: [mile] VERIS Thread-Index: Ac1v/L6BrnMbNx8ZSgGmxjVn2wpnLgAABJkJ Message-ID: References: , <1A341665-F6E2-40F6-9DB0-7ABB62ED3190@c3isecurity.com> In-Reply-To: <1A341665-F6E2-40F6-9DB0-7ABB62ED3190@c3isecurity.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: mile@ietf.org, sacm@ietf.org Subject: Re: [mile] VERIS X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 15:48:10 -0000 We could also add a spot on the agenda for the next meeting as well. That = will be a few months out in Atlanta (as we are meeting now in Vancouver and= had the MILE session last night). A webex is a great idea as well. Thank you! Kathleen ________________________________________ From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of Luis Nunez= [lnunez@c3isecurity.com] Sent: Wednesday, August 01, 2012 11:45 AM To: Kyle Maxwell Cc: mile@ietf.org; sacm@ietf.org Subject: Re: [mile] VERIS Hi Kyle, thanks for the info and offer to field questions. Maybe at some point it w= ould worth while to see the connections and relationships of VERIS and MILE= . Some of the things we as a community grapple with is how the various fra= meworks/specifications interact and work together. thanks. -ln On Aug 1, 2012, at 11:25 AM, Kyle Maxwell wrote: I'm on the VERIS team here at Verizon, so I can help answer any specific qu= estions you might have. In a general sense, I don't believe VERIS and MILE = really compete but are complementary to each other. On Wed, Aug 1, 2012 at 10:11 AM, Luis Nunez > wrote: Anyone familiar with Vocabulary for Event Recording and Incident Sharing (V= ERIS)? Is this something that competes with MILE? or does it complement, c= ooperate with existing efforts? Information sharing issues are on the rise and I would like to make sure we= are aware of the various efforts under way. We want to as a community avo= id duplication. http://securityblog.verizonbusiness.com/2012/08/01/announcing-veriscommunit= y-net/ -- Kyle Maxwell [kylem@xwell.org] http://www.xwell.org Twitter: @kylemaxwell From rossella.mattioli@gmail.com Wed Aug 1 09:23:17 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0682911E8178 for ; Wed, 1 Aug 2012 09:23:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.231 X-Spam-Level: X-Spam-Status: No, score=-3.231 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, URI_HEX=0.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G+3demB+TX5H for ; Wed, 1 Aug 2012 09:23:16 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6D47E11E8175 for ; Wed, 1 Aug 2012 09:23:15 -0700 (PDT) Received: by wibhm11 with SMTP id hm11so3269326wib.13 for ; Wed, 01 Aug 2012 09:23:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=eK+g9gqh3rZBgE5fJ50JXfGptRvKh1T3ohsElAvNr2s=; b=oK2G2Zy7I0bNmX2+QISz4Rl8qJXdiB9AsPA/yeHL3KGB+4MR5ILxEDissJELcGJQDe e/kqEjxDIZu9gcA9lEIpnbn/FmKfeFyYWCI8UO+Kg7TrZjxBJDDdPs+yNuz1bMwy0TMM 2D5R0cwGFvn2o1BH0Ic5OHPCfrPgqPZ5wGgZ4ERxc9868/nMggp17S4g7isX48P1saUt 6gkRJvdxruRY0lMaWlycPFhsfJlYdqyO3O+YU/nNkwhIj1Ijj0mXa5cv+vSSFO1LiB3i mdoYQ5KUSCZA2t3SGqsg2y+z5+5qGvumlkQajqi8G0oBf33PLwo1IvgeHIzBuUACjZWt NCHw== Received: by 10.180.107.103 with SMTP id hb7mr17835290wib.3.1343838194507; Wed, 01 Aug 2012 09:23:14 -0700 (PDT) Received: from [10.232.174.251] ([217.200.200.236]) by mx.google.com with ESMTPS id cl8sm28638930wib.10.2012.08.01.09.23.11 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 01 Aug 2012 09:23:13 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Rossella Mattioli In-Reply-To: <173601cd6f2e$42463ad0$c6d2b070$@apwg.org> Date: Wed, 1 Aug 2012 18:23:09 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2A187C02-FC35-4634-BAF1-0404C5E3B75E@gmail.com> References: <173601cd6f2e$42463ad0$c6d2b070$@apwg.org> To: Pat Cain X-Mailer: Apple Mail (2.1278) Cc: mile@ietf.org Subject: Re: [mile] considerations for IETF 84 guidance / updating IODEF discussion X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 16:23:17 -0000 Hi Pat, thank you so much for your comments. My replies are inline. On Jul 31, 2012, at 5:07 PM, Pat Cain wrote: > Hi, >=20 > I have a couple of comments. > They should be prefaced by a pc> >=20 >=20 > -----Original Message----- > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf = Of > Rossella Mattioli > Sent: Thursday, July 26, 2012 12:42 PM > To: mile@ietf.org > Subject: [mile] considerations for IETF 84 guidance / updating IODEF > discussion >=20 > Hi all, >=20 > considering the agenda of IETF 84 I would like to submit to the list = some > thoughts on the guidance / updating IODEF discussion. > These gaps and overlaps emerged during the data set analysis of 89 = publicly > available data feeds for response teams I made for my research. > Hope they can be of help for next week meeting. >=20 > Pc> I am interested in the output of your research - paper, = thesis, > web page, etc. is it's available? You can find the abstract on my website = http://www.07011979.org/post/26825136212/information-exchange-framework-fo= r-cyber-security I'll send you the entire thesis in a direct mail. In case somebody else = is interested, please let me know. >=20 > Contact class: IODEF covers most of the available information within > contact@role. There are some values that are not directly mapping with > popular type of role such as sensor but this can be done via cross = reference > with the system@category for what concerns the sensor value. For what > concerns LEA and vulnerability reporter there are two ways of > implementation: >=20 > . implement the escape value to extend this attribute; >=20 > . foster the adoption of these values within the official data > schema. >=20 > Moreover since PGP is widely used within the security community an = ad-hoc > element should be considered for future implementation. >=20 > Pc> The PGP attribute you may want is the KeyID. I don't = know > how you guarantee integrity protection over the Incident Report, but = having > a modifyable KeyId value there when a report is forwarded could be > entertaining. I see your point. > Pc> I don't understand the sensor issue. The Contact class is to > identify the person or organization submitting the Incident. A = 'sensor' is > probably not a legal entity. The "sensor's operator" is what would go = into > the Contact element, no? Exactly, the sensor operator as for example Shadowserver > Time: the time classes offered by IODEF cover most of the values > encountered.There is one value that occurred in the data I analyzed = which > was not covered: next validation time. This gap can be fulfilled with = escape > value. >=20 > Pc> This could be useful. In your experience, do you see the need of any other value? =46rom the data I analyzed, this is the only one I encountered which was = not mappable with available values. >=20 > Address: to define an address IODEF already includes all the = granularity to > define IPv4, IPv6 and ASN numbers in the system and node classes. At = the > moment only domain data is not fully covered by the current data = schema and > in order to fulfill this gap two possible actions can be evaluated: >=20 > . to use the definition of the class from RFC 5901 and describe = the > information with the DomainData, DomainContacts and Nameservers = elements; >=20 > . to implement a new class regarding the domain data with an = update > of the IODEF data schema.=20 >=20 > Pc> You really don't want to do this. We made the DomainData > class since nobody had defined a way of expressing domain registration = data > in XML. Now that I'm populating that field out, I'm starting to hate = it. You > want to use whatever the WEIRDS WG ends up with. Although their spec = is > currently JSON, it could be used as is or XML-ed, but that is the = structured > domain data format of the future. >=20 Thank you so much for the feedback :) and also for the suggestion! I am going through WEIRDS drafts http://tools.ietf.org/wg/weirds/ > [snip] > ... All the enumeration discussion... > [snip] >=20 > Pc> So IODEF was completed a while back. And attacks and eCrime = have > evolved. IODEF is trying but has not kept up. Almost *all* of the = enumerated > lists have major deficiencies. Instead of just taking in new values, a = way > needs to be defined that allows IODEF to evolve with the attacks and > eCrimes. This may just mean making the enumerations 'open' so values = can be > added as necessary. Or maybe there's a "current list of enumerations" > informational RFC or website or something. But as soon as we define = new > enumerations we find that we need another one. I don't see a need to > standardize all the enumerated lists, tho. What about a very generic one, high level, which can be mapped with all = different vocabularies and/ or taxonomies? I am thinking about your = http://repoman.apwg.org/research/wiki/taxonomy4?version=3D6 and the = VERIS https://github.com/veris-opensource/verisc for example >=20 > Malware: IODEF does not include any specific class to malware samples. = The > reference class can be used to refer to a particular sample but there = are no > related enumeration or specific classes to identify which kind of = malware > infections occurs in the incident. In the RFC 5901 a first attempt is = made > both with the fraud@type value "malware distribution" and also with = the > relative class "included malware" and the subclass data, the > "FilesDownloaded" and "WindowsRegistryKeyModified" class. Considering = the > importance and the volume of these threats in the current scenario it = should > be discussed : >=20 > . improving the guidance of the current IODEF data model and = related > extensions; >=20 > . implementing a high level taxonomy of malware types and leave > further characterization to the interoperability with other cyber = security > formats. >=20 > The malware indicators should be hashes (MD5 or SHA1), the filetype = and the > version. As it can be noticed I do not refer to the name of the file. = Naming > a file can be not straightforward, where possible the name of the = malware > should be defined using the CARO Malware Naming Scheme, which even if = not > updated, is the most popular guideline among anti virus companies. In = this > respect, the need to a high level characterization arises to help the > handler in quickly identify the threat. Moreover IODEF Fraud extension = is > too generic for a complete in-depth categorization of the sample and = lacks > of detailed information regarding behaviors and other characteristics = that > could be of help in response of the threat. This effort could help in > understanding the infection and can be neighborly in the foreseen > integration with other cyber security exchange formats regarding = malware. >=20 > Pc> People who are slopping malware data around - bot in XML = and > in IODEF - are using the IEEE Malware schemas. You should use them, = too. This is exactly the point. The suggestion is to put a high level = characterization inside the incident document: - to allow the handler to quickly recognize the threat at first sight, = before digging into the MAEC, MMDEF, Cybox or other data - and to have a common baseline which could enable to compare statistics = between different organizations/regions etc. >=20 >=20 > Pc> A lot of your comments say "improving the guidance of the > current IODEF data model and related extensions". You should write a = draft. > Many people would be happy. I made the reference in order to insert these suggestions into the = discussion at IETF84. If this thread is considered interesting by the mailing list, I will be = happy to work on it. Regarding IETF84, I am trying to download yesterday meeting (sorry I was = not able to attend) but I get 404. Does anybody know when will be the recordings available? Thank you so much and looking forward to other comments, Rossella From kathleen.moriarty@emc.com Wed Aug 1 09:43:05 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B6DF11E81C7 for ; Wed, 1 Aug 2012 09:43:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.415 X-Spam-Level: X-Spam-Status: No, score=-2.415 tagged_above=-999 required=5 tests=[AWL=-0.184, BAYES_00=-2.599, URI_HEX=0.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yHns3bUrzHGH for ; Wed, 1 Aug 2012 09:43:03 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 1B7A111E81BC for ; Wed, 1 Aug 2012 09:43:02 -0700 (PDT) Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q71GglrT014841 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Aug 2012 12:42:48 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.221.251]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor); Wed, 1 Aug 2012 12:42:32 -0400 Received: from mxhub32.corp.emc.com (mxhub32.corp.emc.com [128.222.70.172]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q71GgUsu009685; Wed, 1 Aug 2012 12:42:30 -0400 Received: from mx15a.corp.emc.com ([169.254.1.189]) by mxhub32.corp.emc.com ([128.222.70.172]) with mapi; Wed, 1 Aug 2012 12:42:29 -0400 From: To: , Date: Wed, 1 Aug 2012 12:38:21 -0400 Thread-Topic: [mile] considerations for IETF 84 guidance / updating IODEF discussion Thread-Index: Ac1wAhVtqGLoJI+rTPypPNNJ/hn3vwAAfpok Message-ID: References: <173601cd6f2e$42463ad0$c6d2b070$@apwg.org>, <2A187C02-FC35-4634-BAF1-0404C5E3B75E@gmail.com> In-Reply-To: <2A187C02-FC35-4634-BAF1-0404C5E3B75E@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: mile@ietf.org Subject: Re: [mile] considerations for IETF 84 guidance / updating IODEF discussion X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 16:43:05 -0000 Thank you both for the comments. Others- please chime in! I will just add an option for the enumeration lists. I think a registry th= at lets us add values between data model updates could go a long way. We s= et one up for RFC6545 so we could add sharing groups or other enumerated va= lues to the lists without having to update the RFC. The registry can be fo= und here: http://www.iana.org/assignments/rid/rid.xml and is set up for any of the lists in the RID schema. The format is specif= ied in the IANA section of RFC6545, you specify the list, the value and a d= efinition. Expert review is required to add a value. Thanks, Kathleen ________________________________________ From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of Rossella M= attioli [rossella.mattioli@gmail.com] Sent: Wednesday, August 01, 2012 12:23 PM To: Pat Cain Cc: mile@ietf.org Subject: Re: [mile] considerations for IETF 84 guidance / updating IOD= EF discussion Hi Pat, thank you so much for your comments. My replies are inline. On Jul 31, 2012, at 5:07 PM, Pat Cain wrote: > Hi, > > I have a couple of comments. > They should be prefaced by a pc> > > > -----Original Message----- > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of > Rossella Mattioli > Sent: Thursday, July 26, 2012 12:42 PM > To: mile@ietf.org > Subject: [mile] considerations for IETF 84 guidance / updating IODEF > discussion > > Hi all, > > considering the agenda of IETF 84 I would like to submit to the list some > thoughts on the guidance / updating IODEF discussion. > These gaps and overlaps emerged during the data set analysis of 89 public= ly > available data feeds for response teams I made for my research. > Hope they can be of help for next week meeting. > > Pc> I am interested in the output of your research - paper, thesis, > web page, etc. is it's available? You can find the abstract on my website http://www.07011979.org/post/268251= 36212/information-exchange-framework-for-cyber-security I'll send you the entire thesis in a direct mail. In case somebody else is = interested, please let me know. > > Contact class: IODEF covers most of the available information within > contact@role. There are some values that are not directly mapping with > popular type of role such as sensor but this can be done via cross refere= nce > with the system@category for what concerns the sensor value. For what > concerns LEA and vulnerability reporter there are two ways of > implementation: > > . implement the escape value to extend this attribute; > > . foster the adoption of these values within the official data > schema. > > Moreover since PGP is widely used within the security community an ad-hoc > element should be considered for future implementation. > > Pc> The PGP attribute you may want is the KeyID. I don't know > how you guarantee integrity protection over the Incident Report, but havi= ng > a modifyable KeyId value there when a report is forwarded could be > entertaining. I see your point. > Pc> I don't understand the sensor issue. The Contact class is to > identify the person or organization submitting the Incident. A 'sensor' i= s > probably not a legal entity. The "sensor's operator" is what would go int= o > the Contact element, no? Exactly, the sensor operator as for example Shadowserver > Time: the time classes offered by IODEF cover most of the values > encountered.There is one value that occurred in the data I analyzed which > was not covered: next validation time. This gap can be fulfilled with esc= ape > value. > > Pc> This could be useful. In your experience, do you see the need of any other value? >From the data I analyzed, this is the only one I encountered which was not = mappable with available values. > > Address: to define an address IODEF already includes all the granularity = to > define IPv4, IPv6 and ASN numbers in the system and node classes. At the > moment only domain data is not fully covered by the current data schema a= nd > in order to fulfill this gap two possible actions can be evaluated: > > . to use the definition of the class from RFC 5901 and describe the > information with the DomainData, DomainContacts and Nameservers elements; > > . to implement a new class regarding the domain data with an update > of the IODEF data schema. > > Pc> You really don't want to do this. We made the DomainData > class since nobody had defined a way of expressing domain registration da= ta > in XML. Now that I'm populating that field out, I'm starting to hate it. = You > want to use whatever the WEIRDS WG ends up with. Although their spec is > currently JSON, it could be used as is or XML-ed, but that is the structu= red > domain data format of the future. > Thank you so much for the feedback :) and also for the suggestion! I am going through WEIRDS drafts http://tools.ietf.org/wg/weirds/ > [snip] > ... All the enumeration discussion... > [snip] > > Pc> So IODEF was completed a while back. And attacks and eCrime hav= e > evolved. IODEF is trying but has not kept up. Almost *all* of the enumera= ted > lists have major deficiencies. Instead of just taking in new values, a wa= y > needs to be defined that allows IODEF to evolve with the attacks and > eCrimes. This may just mean making the enumerations 'open' so values can = be > added as necessary. Or maybe there's a "current list of enumerations" > informational RFC or website or something. But as soon as we define new > enumerations we find that we need another one. I don't see a need to > standardize all the enumerated lists, tho. What about a very generic one, high level, which can be mapped with all dif= ferent vocabularies and/ or taxonomies? I am thinking about your http://repoman.apwg.org/research/wiki/taxonomy4?ve= rsion=3D6 and the VERIS https://github.com/veris-opensource/verisc for exam= ple > > Malware: IODEF does not include any specific class to malware samples. Th= e > reference class can be used to refer to a particular sample but there are= no > related enumeration or specific classes to identify which kind of malware > infections occurs in the incident. In the RFC 5901 a first attempt is mad= e > both with the fraud@type value "malware distribution" and also with the > relative class "included malware" and the subclass data, the > "FilesDownloaded" and "WindowsRegistryKeyModified" class. Considering the > importance and the volume of these threats in the current scenario it sho= uld > be discussed : > > . improving the guidance of the current IODEF data model and relate= d > extensions; > > . implementing a high level taxonomy of malware types and leave > further characterization to the interoperability with other cyber securit= y > formats. > > The malware indicators should be hashes (MD5 or SHA1), the filetype and t= he > version. As it can be noticed I do not refer to the name of the file. Nam= ing > a file can be not straightforward, where possible the name of the malware > should be defined using the CARO Malware Naming Scheme, which even if not > updated, is the most popular guideline among anti virus companies. In thi= s > respect, the need to a high level characterization arises to help the > handler in quickly identify the threat. Moreover IODEF Fraud extension is > too generic for a complete in-depth categorization of the sample and lack= s > of detailed information regarding behaviors and other characteristics tha= t > could be of help in response of the threat. This effort could help in > understanding the infection and can be neighborly in the foreseen > integration with other cyber security exchange formats regarding malware. > > Pc> People who are slopping malware data around - bot in XML an= d > in IODEF - are using the IEEE Malware schemas. You should use them, too. This is exactly the point. The suggestion is to put a high level characteri= zation inside the incident document: - to allow the handler to quickly recognize the threat at first sight, befo= re digging into the MAEC, MMDEF, Cybox or other data - and to have a common baseline which could enable to compare statistics be= tween different organizations/regions etc. > > > Pc> A lot of your comments say "improving the guidance of the > current IODEF data model and related extensions". You should write a dra= ft. > Many people would be happy. I made the reference in order to insert these suggestions into the discussi= on at IETF84. If this thread is considered interesting by the mailing list, I will be hap= py to work on it. Regarding IETF84, I am trying to download yesterday meeting (sorry I was no= t able to attend) but I get 404. Does anybody know when will be the recordings available? Thank you so much and looking forward to other comments, Rossella _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile From lnunez@c3isecurity.com Wed Aug 1 11:24:40 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF25311E81D3 for ; Wed, 1 Aug 2012 11:24:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.662 X-Spam-Level: X-Spam-Status: No, score=-4.662 tagged_above=-999 required=5 tests=[AWL=0.937, BAYES_00=-2.599, GB_I_INVITATION=-2, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ELhvkokvxTyt for ; Wed, 1 Aug 2012 11:24:38 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id B2B3E11E83AF for ; Wed, 1 Aug 2012 11:24:38 -0700 (PDT) Received: by yenq13 with SMTP id q13so8254473yen.31 for ; Wed, 01 Aug 2012 11:24:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=X9K5w0a38Rn00upwMs8GmLa8XHdDX5Q9qytcHe+KY8M=; b=Bq2U7e14UCwsZjtT+OeSJjs2JkVm9n6WnQkiT9LnbZ0eG71rTjnQ7Np6vP4DfOAQNR +0liLUMg1E00fj0598ZU8ZuRQklYHdRpr3KmjJEb3Qh2UjweF4nmHmC34Fg6yqyJIqRw PhORL5VpsAb4+7yXRyWC1JOymdLRjpgfEVBCWKv5AyyPu8yq87lxB5nIEmUk7O9qElcd VfZWEh2Yao7CWxLajXC53XjwikJBcTRdToYuodsAZoosEtQAFkKvy9mdcd6AbfUC8LfW aChVjuF1vXpzoGe8qz/DDaDYrPirkCDFuO75DxX6V6HThfbZ+bNymaH4Hv7Zas9Y98Z+ VVBw== Received: by 10.101.3.19 with SMTP id f19mr5468034ani.58.1343845478164; Wed, 01 Aug 2012 11:24:38 -0700 (PDT) Received: from [192.168.1.33] (cpe-066-057-081-254.nc.res.rr.com. [66.57.81.254]) by mx.google.com with ESMTPS id q17sm484820anm.12.2012.08.01.11.24.36 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 01 Aug 2012 11:24:37 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: Luis Nunez In-Reply-To: Date: Wed, 1 Aug 2012 14:24:35 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Waltermire, David A." X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQk3gQ6u6AvGpSfs9qizmP++s2GHFF5ukjZ0ZjAROWlnCRh45pDdhHUUfv38RIIg4NJmudLf Cc: mile@ietf.org, sacm@ietf.org Subject: Re: [mile] [sacm] Agenda and Remote Participation Info for the SACM BOF X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 18:24:41 -0000 Kent, Dave, can you add to the agenda the IPR issue with the specifications. I = think we need to inform the community what the issue is. It came up in = the MILE session and it directly impacts this group. If someone could = clearly articulate what the issue is, we can at least have a common = understanding among the community. Thanks. -ln On Jul 30, 2012, at 9:15 PM, Waltermire, David A. wrote: > As a reminder, the Security Automation and Continuous Monitoring = (SACM) effort is going to have a Side meeting at the IETF 84 meeting in = Vancouver later this week. A description of the meeting, the date/time, = web meeting details, and the agenda for the meeting follow. >=20 > SACM Side Meeting IETF 84 >=20 > Security Automation and Continuous Monitoring =96 SACM (pronounced as = Sack-em) >=20 > Side Meeting Chairs: David Waltermire, Kent Landfield >=20 > Description: A side meeting to continue the discussions around = security automation and continuous monitoring working group development = efforts. In this meeting we will be reviewing the Use Case document and = then focusing on a draft charter for the potential working group. >=20 > Here are the meeting specifics: >=20 > Date: Thursday, August 2, 2012 > Time: 18:30 =96 20:00 PDT > Room: Plaza C >=20 > Thanks to Nancy Cam-Winget for organizing the webex. See conference = call and web meeting details below. >=20 > Agenda:=20 > * Agenda Bashing > * Status of work since last IETF meeting > * Internet Draft Discussions to: > - support the charter/use cases > - other potential future drafts > * Discuss draft WG Charter >=20 > Current Drafts: > - http://www.ietf.org/id/draft-waltermire-sacm-use-cases-01.txt - = draft-waltermire-sacm-use-cases-01 - Analysis of Security Automation and = Continuous Monitoring (SACM) Use Cases > - http://www.ietf.org/id/draft-waltermire-content-repository-00.txt - = draft-waltermire-content-repository-00 - Automated XML Content Data = Exchange and Management >=20 > ________________________________________ > From: Nancy Cam-Winget (ncamwing) [ncamwing@cisco.com] > Sent: Monday, July 30, 2012 8:05 PM > To: Moriarty, Kathleen > Subject: FW: (Forward to attendees) Meeting invitation: SACM BOF >=20 > From: Nancy Cam-Winget = > > Reply-To: "ncamwing@cisco.com" = > > Date: Monday, July 30, 2012 5:04 PM > To: "ncamwing@cisco.com" = > > Subject: (Forward to attendees) Meeting invitation: SACM BOF >=20 > **** You can forward this email invitation to attendees **** >=20 > Hello , >=20 > Nancy Cam-Winget invites you to attend this online meeting. >=20 > Topic: SACM BOF > Date: Thursday, August 2, 2012 > Time: 6:30 pm, Pacific Daylight Time (San Francisco, GMT-07:00) > Meeting Number: 205 870 492 > Meeting Password: sacm >=20 >=20 > ------------------------------------------------------- > To join the online meeting (Now from mobile devices!) > ------------------------------------------------------- > 1. Go to = https://cisco.webex.com/ciscosales/j.php?ED=3D201187757&UID=3D0&PW=3DNZWYy= NWU2YWY3&RT=3DMiM0 > 2. Enter your name and email address. > 3. Enter the meeting password: sacm > 4. Click "Join Now". >=20 > To view in other time zones or languages, please click the link: > = https://cisco.webex.com/ciscosales/j.php?ED=3D201187757&UID=3D0&PW=3DNZWYy= NWU2YWY3&ORT=3DMiM0 >=20 > ---------------------------------------------------------------- > ALERT:Toll-Free Dial Restrictions for (408) and (919) Area Codes > ---------------------------------------------------------------- >=20 > The affected toll free numbers are: (866) 432-9903 for the San = Jose/Milpitas area and (866) 349-3520 for the RTP area. >=20 > Please dial the local access number for your area from the list below: > - San Jose/Milpitas (408) area: 525-6800 > - RTP (919) area: 392-3330 >=20 > ------------------------------------------------------- > To join the teleconference only > ------------------------------------------------------- > 1. Dial into Cisco WebEx (view all Global Access Numbers at > http://cisco.com/en/US/about/doing_business/conferencing/index.html > 2. Follow the prompts to enter the Meeting Number (listed above) or = Access Code followed by the # sign. >=20 > San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330 >=20 > US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117 >=20 > India: +91.80.4350.1111 Germany: +49.619.6773.9002 >=20 > Japan: +81.3.5763.9394 China: +86.10.8515.5666 >=20 > ------------------------------------------------------- > For assistance > ------------------------------------------------------- > 1. Go to https://cisco.webex.com/ciscosales/mc > 2. On the left navigation bar, click "Support". >=20 > You can contact me at: > ncamwing@cisco.com > 1-408-853 0532 >=20 > To add this meeting to your calendar program (for example Microsoft = Outlook), click this link: > = https://cisco.webex.com/ciscosales/j.php?ED=3D201187757&UID=3D0&ICS=3DMI&L= D=3D1&RD=3D2&ST=3D1&SHA2=3DTkz-bhelFlmrhUuPkK7v2d/0gsYehkMU1WW8szSvQnM=3D&= RT=3DMiM0 >=20 > The playback of UCF (Universal Communications Format) rich media files = requires appropriate players. To view this type of rich media files in = the meeting, please check whether you have the players installed on your = computer by going to = https://cisco.webex.com/ciscosales/systemdiagnosis.php. >=20 >=20 >=20 >=20 > http://www.webex.com >=20 > CCP:+14085256800x205870492# >=20 > IMPORTANT NOTICE: This WebEx service includes a feature that allows = audio and any documents and other materials exchanged or viewed during = the session to be recorded. By joining this session, you automatically = consent to such recordings. If you do not consent to the recording, = discuss your concerns with the meeting host prior to the start of the = recording or do not join the session. Please note that any such = recordings may be subject to discovery in the event of litigation. > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm From amontville@tripwire.com Wed Aug 1 11:33:05 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B18F11E83E3 for ; Wed, 1 Aug 2012 11:33:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.899 X-Spam-Level: X-Spam-Status: No, score=-3.899 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uj4qVQxeadM0 for ; Wed, 1 Aug 2012 11:33:04 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe004.messaging.microsoft.com [216.32.180.187]) by ietfa.amsl.com (Postfix) with ESMTP id 98A2611E810B for ; Wed, 1 Aug 2012 11:33:04 -0700 (PDT) Received: from mail186-co1-R.bigfish.com (10.243.78.227) by CO1EHSOBE016.bigfish.com (10.243.66.79) with Microsoft SMTP Server id 14.1.225.23; Wed, 1 Aug 2012 18:33:03 +0000 Received: from mail186-co1 (localhost [127.0.0.1]) by mail186-co1-R.bigfish.com (Postfix) with ESMTP id BB26DB201DB for ; Wed, 1 Aug 2012 18:33:03 +0000 (UTC) X-Forefront-Antispam-Report: CIP:174.47.84.216; KIP:(null); UIP:(null); IPV:NLI; H:PDXED01.tripwire.com; RD:174-47-84-216.static.twtelecom.net; EFVD:NLI X-SpamScore: -1 X-BigFish: VPS-1(zz14ffIzz1202hzz8275bhz2dh2a8h668h839h944he5bhf0ah107ah) Received: from mail186-co1 (localhost.localdomain [127.0.0.1]) by mail186-co1 (MessageSwitch) id 1343845981864192_651; Wed, 1 Aug 2012 18:33:01 +0000 (UTC) Received: from CO1EHSMHS009.bigfish.com (unknown [10.243.78.227]) by mail186-co1.bigfish.com (Postfix) with ESMTP id C71F7D40056 for ; Wed, 1 Aug 2012 18:33:01 +0000 (UTC) Received: from PDXED01.tripwire.com (174.47.84.216) by CO1EHSMHS009.bigfish.com (10.243.66.19) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 1 Aug 2012 18:33:01 +0000 Received: from PDXHB01.tripwire.com (172.30.0.53) by PDXED01.tripwire.com (192.168.192.5) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 1 Aug 2012 11:34:09 -0700 Received: from PDXMB02.tripwire.com ([fe80::f997:7b65:8e64:438e]) by PDXHB01.tripwire.com ([fe80::d495:98d2:7df4:2154%11]) with mapi id 14.01.0355.002; Wed, 1 Aug 2012 11:33:00 -0700 From: Adam Montville To: "mile@ietf.org" Thread-Topic: IODEF Reference Format for Enumerations Thread-Index: AQHNcBQUjnhk6vA+2ESPKvQXhGGTVA== Date: Wed, 1 Aug 2012 18:33:00 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [172.16.97.136] x-exclaimer-md-config: 79afcaa7-fdf4-4fa6-abe0-afeaa4640a4f Content-Type: text/plain; charset="us-ascii" Content-ID: <9673860BBC285141A55029EA9D2C5968@tripwire.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: tripwire.com Subject: [mile] IODEF Reference Format for Enumerations X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 18:33:05 -0000 Hello everyone, During yesterday's mile meeting we started several options with respect to referencing external enumeration - a topic that has been discussed on the list previously. I believe, but could be wrong, that the discussion we had yesterday implicitly eliminates the first option, which leaves the second and third options from which to choose. I also believe that the previous discussion on the list went toward option two. Keeping in mind that the SCI draft is essentially stuck until this referential issue is sorted out, I would like to propose that we move forward with the second option or continue this discussion to drive to the appropriate conclusion on relatively short order. Choosing option two now would preclude "opening" IODEF. Here are the options again: Option 1: Simple ID =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The first option would simply embed the relevant identifier in the ReferenceName element of the Reference class. This may look like the following: id http://www.example.com/path http://www.otherexample.com/path Description Using this option, a variety of specific identifier formats could be specified. CVE, for example, would start with "CVE-" and this convention may be registered in an IANA table. No changes to IODEF are required for this option. Option 2: ID with coupled ID type =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D The second option would prepend the identifier with it's type, which may look something like the following. id_type:id http://www.example.com/path http://www.otherexample.com/path Description Using this option, a variety of specific identifier types could be specified, such that the identifier itself would not necessarily be constrained, nor would new identifier formats necessarily need to be specified in the future. An IANA table may be used for this solution as well. No changes to IODEF would be required for this option. Option 3: ID with type expressed in Reference attribute =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D The third option would require opening IODEF to update the Reference class with an attribute, which may look something like the following. id http://www.example.com/path http://www.otherexample.com/path Description Changes to IODEF are required for this option. Regards, Adam From david.black@emc.com Wed Aug 1 18:35:30 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F5CE11E814F for ; Wed, 1 Aug 2012 18:35:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.462 X-Spam-Level: X-Spam-Status: No, score=-102.462 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dd2lGL9eJRkE for ; Wed, 1 Aug 2012 18:35:28 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 73A2A21F851B for ; Wed, 1 Aug 2012 18:34:59 -0700 (PDT) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q721Yumi003664 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Aug 2012 21:34:57 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.221.145]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Wed, 1 Aug 2012 21:34:40 -0400 Received: from mxhub05.corp.emc.com (mxhub05.corp.emc.com [128.222.70.202]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q721Yddd028212; Wed, 1 Aug 2012 21:34:39 -0400 Received: from mx15a.corp.emc.com ([169.254.1.189]) by mxhub05.corp.emc.com ([128.222.70.202]) with mapi; Wed, 1 Aug 2012 21:34:39 -0400 From: To: , Date: Wed, 1 Aug 2012 21:34:38 -0400 Thread-Topic: IODEF Reference Format for Enumerations Thread-Index: AQHNcBQUjnhk6vA+2ESPKvQXhGGTVJdFvWew Message-ID: <8D3D17ACE214DC429325B2B98F3AE71208E7FEC5@MX15A.corp.emc.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [mile] IODEF Reference Format for Enumerations X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 01:35:30 -0000 Adam, I have one small addition from the mile meeting yesterday: There was a debate about whether to require one of the URIs in whatever option is chosen to refer to the spec that the identifier came from. The clear conclusion from the meeting was to thoroughly rubbish and discard that idea ... and as the original proposer of that idea, I'm fine with that outcome ;-). Thanks, --David > -----Original Message----- > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of A= dam > Montville > Sent: Wednesday, August 01, 2012 2:33 PM > To: mile@ietf.org > Subject: [mile] IODEF Reference Format for Enumerations >=20 > Hello everyone, >=20 > During yesterday's mile meeting we started several options with respect t= o > referencing external enumeration - a topic that has been discussed on the > list previously. I believe, but could be wrong, that the discussion we > had yesterday implicitly eliminates the first option, which leaves the > second and third options from which to choose. I also believe that the > previous discussion on the list went toward option two. >=20 > Keeping in mind that the SCI draft is essentially stuck until this > referential issue is sorted out, I would like to propose that we move > forward with the second option or continue this discussion to drive to th= e > appropriate conclusion on relatively short order. Choosing option two no= w > would preclude "opening" IODEF. >=20 > Here are the options again: >=20 >=20 > Option 1: Simple ID > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > The first option would simply embed the relevant identifier in the > ReferenceName element of the Reference class. This may look like the > following: >=20 > > id > http://www.example.com/path > > http://www.otherexample.com/path > > Description > >=20 > Using this option, a variety of specific identifier formats could be > specified. CVE, for example, would start with "CVE-" and this convention > may be registered in an IANA table. >=20 > No changes to IODEF are required for this option. >=20 >=20 >=20 > Option 2: ID with coupled ID type > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > The second option would prepend the identifier with it's type, which may > look something like the following. >=20 > > id_type:id > http://www.example.com/path > > http://www.otherexample.com/path > > Description > >=20 > Using this option, a variety of specific identifier types could be > specified, such that the identifier itself would not necessarily be > constrained, nor would new identifier formats necessarily need to be > specified in the future. An IANA table may be used for this solution as > well. >=20 > No changes to IODEF would be required for this option. >=20 >=20 >=20 > Option 3: ID with type expressed in Reference attribute > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > The third option would require opening IODEF to update the Reference clas= s > with an attribute, which may look something like the following. >=20 > > id > http://www.example.com/path > > http://www.otherexample.com/path > > Description > >=20 >=20 >=20 > Changes to IODEF are required for this option. >=20 >=20 >=20 > Regards, >=20 > Adam >=20 >=20 > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile From amontville@tripwire.com Thu Aug 2 08:58:44 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CB9A11E80A6 for ; Thu, 2 Aug 2012 08:58:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.866 X-Spam-Level: X-Spam-Status: No, score=-3.866 tagged_above=-999 required=5 tests=[AWL=-0.267, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZhcA53X0CBUg for ; Thu, 2 Aug 2012 08:58:43 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe010.messaging.microsoft.com [216.32.180.30]) by ietfa.amsl.com (Postfix) with ESMTP id 974DD11E8087 for ; Thu, 2 Aug 2012 08:58:43 -0700 (PDT) Received: from mail24-va3-R.bigfish.com (10.7.14.249) by VA3EHSOBE008.bigfish.com (10.7.40.28) with Microsoft SMTP Server id 14.1.225.23; Thu, 2 Aug 2012 15:58:43 +0000 Received: from mail24-va3 (localhost [127.0.0.1]) by mail24-va3-R.bigfish.com (Postfix) with ESMTP id 03AD44004F for ; Thu, 2 Aug 2012 15:58:43 +0000 (UTC) X-Forefront-Antispam-Report: CIP:174.47.84.216; KIP:(null); UIP:(null); IPV:NLI; H:PDXED01.tripwire.com; RD:174-47-84-216.static.twtelecom.net; EFVD:NLI X-SpamScore: -31 X-BigFish: VPS-31(zzbb2dI98dI9371I542M1432I4015I14ffIzz1202hzz1033IL8275bh8275dhz2dh2a8h668h839h944he5bhf0ah107ah) Received: from mail24-va3 (localhost.localdomain [127.0.0.1]) by mail24-va3 (MessageSwitch) id 1343923094462609_15552; Thu, 2 Aug 2012 15:58:14 +0000 (UTC) Received: from VA3EHSMHS031.bigfish.com (unknown [10.7.14.251]) by mail24-va3.bigfish.com (Postfix) with ESMTP id 4556D2C0600; Thu, 2 Aug 2012 15:58:14 +0000 (UTC) Received: from PDXED01.tripwire.com (174.47.84.216) by VA3EHSMHS031.bigfish.com (10.7.99.41) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 2 Aug 2012 15:58:13 +0000 Received: from PDXHB01.tripwire.com (172.30.0.53) by PDXED01.tripwire.com (192.168.192.5) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 2 Aug 2012 08:59:19 -0700 Received: from PDXMB02.tripwire.com ([fe80::f997:7b65:8e64:438e]) by PDXHB01.tripwire.com ([fe80::d495:98d2:7df4:2154%11]) with mapi id 14.01.0355.002; Thu, 2 Aug 2012 08:58:12 -0700 From: Adam Montville To: "david.black@emc.com" , "mile@ietf.org" Thread-Topic: IODEF Reference Format for Enumerations Thread-Index: AQHNcBQUjnhk6vA+2ESPKvQXhGGTVJdFvWewgADxroA= Date: Thu, 2 Aug 2012 15:58:11 +0000 Message-ID: In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE71208E7FEC5@MX15A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [172.16.97.141] x-exclaimer-md-config: 79afcaa7-fdf4-4fa6-abe0-afeaa4640a4f Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: tripwire.com Subject: Re: [mile] IODEF Reference Format for Enumerations X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 15:58:44 -0000 Thanks for that clarification, David. Are there any opposed to moving forward with the second option? Regards, Adam On 8/1/12 6:34 PM, "david.black@emc.com" wrote: >Adam, > >I have one small addition from the mile meeting yesterday: > >There was a debate about whether to require one of the URIs in whatever >option is chosen to refer to the spec that the identifier came from. > >The clear conclusion from the meeting was to thoroughly rubbish and >discard that idea ... and as the original proposer of that idea, >I'm fine with that outcome ;-). > >Thanks, >--David > >> -----Original Message----- >> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of >>Adam >> Montville >> Sent: Wednesday, August 01, 2012 2:33 PM >> To: mile@ietf.org >> Subject: [mile] IODEF Reference Format for Enumerations >>=20 >> Hello everyone, >>=20 >> During yesterday's mile meeting we started several options with respect >>to >> referencing external enumeration - a topic that has been discussed on >>the >> list previously. I believe, but could be wrong, that the discussion we >> had yesterday implicitly eliminates the first option, which leaves the >> second and third options from which to choose. I also believe that the >> previous discussion on the list went toward option two. >>=20 >> Keeping in mind that the SCI draft is essentially stuck until this >> referential issue is sorted out, I would like to propose that we move >> forward with the second option or continue this discussion to drive to >>the >> appropriate conclusion on relatively short order. Choosing option two >>now >> would preclude "opening" IODEF. >>=20 >> Here are the options again: >>=20 >>=20 >> Option 1: Simple ID >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> The first option would simply embed the relevant identifier in the >> ReferenceName element of the Reference class. This may look like the >> following: >>=20 >> >> id >> http://www.example.com/path >> >> http://www.otherexample.com/path >> >> Description >> >>=20 >> Using this option, a variety of specific identifier formats could be >> specified. CVE, for example, would start with "CVE-" and this >>convention >> may be registered in an IANA table. >>=20 >> No changes to IODEF are required for this option. >>=20 >>=20 >>=20 >> Option 2: ID with coupled ID type >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D >> The second option would prepend the identifier with it's type, which may >> look something like the following. >>=20 >> >> id_type:id >> http://www.example.com/path >> >> http://www.otherexample.com/path >> >> Description >> >>=20 >> Using this option, a variety of specific identifier types could be >> specified, such that the identifier itself would not necessarily be >> constrained, nor would new identifier formats necessarily need to be >> specified in the future. An IANA table may be used for this solution as >> well. >>=20 >> No changes to IODEF would be required for this option. >>=20 >>=20 >>=20 >> Option 3: ID with type expressed in Reference attribute >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D >> The third option would require opening IODEF to update the Reference >>class >> with an attribute, which may look something like the following. >>=20 >> >> id >> http://www.example.com/path >> >> http://www.otherexample.com/path >> >> Description >> >>=20 >>=20 >>=20 >> Changes to IODEF are required for this option. >>=20 >>=20 >>=20 >> Regards, >>=20 >> Adam >>=20 >>=20 >> _______________________________________________ >> mile mailing list >> mile@ietf.org >> https://www.ietf.org/mailman/listinfo/mile > > From kathleen.moriarty@emc.com Thu Aug 2 10:50:28 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2C3A11E81D0 for ; Thu, 2 Aug 2012 10:50:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.534 X-Spam-Level: X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id svTgPPfrKpIa for ; Thu, 2 Aug 2012 10:50:21 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 3FB2E11E81B2 for ; Thu, 2 Aug 2012 10:50:21 -0700 (PDT) Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q72HoJEc030068 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 2 Aug 2012 13:50:20 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.221.251]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor) for ; Thu, 2 Aug 2012 13:50:01 -0400 Received: from mxhub25.corp.emc.com (mxhub25.corp.emc.com [10.254.110.181]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q72HnxS6032182 for ; Thu, 2 Aug 2012 13:49:59 -0400 Received: from mx15a.corp.emc.com ([169.254.1.189]) by mxhub25.corp.emc.com ([10.254.110.181]) with mapi; Thu, 2 Aug 2012 13:49:59 -0400 From: To: , Date: Thu, 2 Aug 2012 13:49:29 -0400 Thread-Topic: [mile] FW: Agenda and Remote Participation Info for the SACM Side Meeting Thread-Index: AQHNbrv/3oTSm1aEYE+q4CF9fYvZ0ZdG0Nwj Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [mile] FW: Agenda and Remote Participation Info for the SACM Side Meeting X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 17:50:29 -0000 The room location listed below is not correct, we will be meeting in Regenc= y A. Thank you! Kathleen ________________________________________ From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of kathleen.m= oriarty@emc.com [kathleen.moriarty@emc.com] Sent: Monday, July 30, 2012 9:28 PM To: mile@ietf.org Subject: [mile] FW: Agenda and Remote Participation Info for the SACM Side = Meeting FYI - ________________________________________ From: sacm-bounces@ietf.org [sacm-bounces@ietf.org] On Behalf Of Waltermire= , David A. [david.waltermire@nist.gov] Sent: Monday, July 30, 2012 9:15 PM To: sacm@ietf.org Subject: [sacm] Agenda and Remote Participation Info for the SACM Side meet= ing As a reminder, the Security Automation and Continuous Monitoring (SACM) eff= ort is going to have a Side meeting at the IETF 84 meeting in Vancouver lat= er this week. A description of the meeting, the date/time, web meeting det= ails, and the agenda for the meeting follow. SACM Side Meeting IETF 84 Security Automation and Continuous Monitoring =96 SACM (pronounced as Sack-= em) Side Meeting Chairs: David Waltermire, Kent Landfield Description: A side meeting to continue the discussions around security aut= omation and continuous monitoring working group development efforts. In thi= s meeting we will be reviewing the Use Case document and then focusing on a= draft charter for the potential working group. Here are the meeting specifics: Date: Thursday, August 2, 2012 Time: 18:30 =96 20:00 PDT Room: Plaza C Thanks to Nancy Cam-Winget for organizing the webex. See conference call an= d web meeting details below. Agenda: * Agenda Bashing * Status of work since last IETF meeting * Internet Draft Discussions to: - support the charter/use cases - other potential future drafts * Discuss draft WG Charter Current Drafts: - http://www.ietf.org/id/draft-waltermire-sacm-use-cases-01.txt - draft-wa= ltermire-sacm-use-cases-01 - Analysis of Security Automation and Continuous= Monitoring (SACM) Use Cases - http://www.ietf.org/id/draft-waltermire-content-repository-00.txt - draf= t-waltermire-content-repository-00 - Automated XML Content Data Exchange an= d Management ________________________________________ Hello , Nancy Cam-Winget invites you to attend this online meeting. Topic: SACM BOF Date: Thursday, August 2, 2012 Time: 6:30 pm, Pacific Daylight Time (San Francisco, GMT-07:00) Meeting Number: 205 870 492 Meeting Password: sacm ------------------------------------------------------- To join the online meeting (Now from mobile devices!) ------------------------------------------------------- 1. Go to https://cisco.webex.com/ciscosales/j.php?ED=3D201187757&UID=3D0&PW= =3DNZWYyNWU2YWY3&RT=3DMiM0 2. Enter your name and email address. 3. Enter the meeting password: sacm 4. Click "Join Now". To view in other time zones or languages, please click the link: https://cisco.webex.com/ciscosales/j.php?ED=3D201187757&UID=3D0&PW=3DNZWYyN= WU2YWY3&ORT=3DMiM0 ---------------------------------------------------------------- ALERT:Toll-Free Dial Restrictions for (408) and (919) Area Codes ---------------------------------------------------------------- The affected toll free numbers are: (866) 432-9903 for the San Jose/Milpita= s area and (866) 349-3520 for the RTP area. Please dial the local access number for your area from the list below: - San Jose/Milpitas (408) area: 525-6800 - RTP (919) area: 392-3330 ------------------------------------------------------- To join the teleconference only ------------------------------------------------------- 1. Dial into Cisco WebEx (view all Global Access Numbers at http://cisco.com/en/US/about/doing_business/conferencing/index.html 2. Follow the prompts to enter the Meeting Number (listed above) or Access = Code followed by the # sign. San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330 US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117 India: +91.80.4350.1111 Germany: +49.619.6773.9002 Japan: +81.3.5763.9394 China: +86.10.8515.5666 ------------------------------------------------------- For assistance ------------------------------------------------------- 1. Go to https://cisco.webex.com/ciscosales/mc 2. On the left navigation bar, click "Support". You can contact me at: ncamwing@cisco.com 1-408-853 0532 To add this meeting to your calendar program (for example Microsoft Outlook= ), click this link: https://cisco.webex.com/ciscosales/j.php?ED=3D201187757&UID=3D0&ICS=3DMI&LD= =3D1&RD=3D2&ST=3D1&SHA2=3DTkz-bhelFlmrhUuPkK7v2d/0gsYehkMU1WW8szSvQnM=3D&RT= =3DMiM0 The playback of UCF (Universal Communications Format) rich media files requ= ires appropriate players. To view this type of rich media files in the meet= ing, please check whether you have the players installed on your computer b= y going to https://cisco.webex.com/ciscosales/systemdiagnosis.php. http://www.webex.com CCP:+14085256800x205870492# IMPORTANT NOTICE: This WebEx service includes a feature that allows audio a= nd any documents and other materials exchanged or viewed during the session= to be recorded. By joining this session, you automatically consent to such= recordings. If you do not consent to the recording, discuss your concerns = with the meeting host prior to the start of the recording or do not join th= e session. Please note that any such recordings may be subject to discovery= in the event of litigation. _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile From kathleen.moriarty@emc.com Thu Aug 2 11:00:16 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D700521F866E for ; Thu, 2 Aug 2012 11:00:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u3-lJJrTQIyx for ; Thu, 2 Aug 2012 11:00:14 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 0A56A11E818C for ; Thu, 2 Aug 2012 11:00:05 -0700 (PDT) Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q72HxxEt007681 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 2 Aug 2012 14:00:03 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd03.lss.emc.com [10.254.221.145]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor) for ; Thu, 2 Aug 2012 13:59:47 -0400 Received: from mxhub27.corp.emc.com (mxhub27.corp.emc.com [10.254.110.183]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q72Hxkca010877 for ; Thu, 2 Aug 2012 13:59:46 -0400 Received: from mx15a.corp.emc.com ([169.254.1.189]) by mxhub27.corp.emc.com ([10.254.110.183]) with mapi; Thu, 2 Aug 2012 13:59:46 -0400 From: To: Date: Thu, 2 Aug 2012 13:59:15 -0400 Thread-Topic: [mile] FW: Agenda and Remote Participation Info for the SACM Side Meeting Thread-Index: AQHNbrv/3oTSm1aEYE+q4CF9fYvZ0ZdG0NwjgAACuyk= Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [mile] FW: Agenda and Remote Participation Info for the SACM Side Meeting X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 18:00:17 -0000 Make that Georgia A... =20 Thanks, Kathleen ________________________________________ From: Moriarty, Kathleen Sent: Thursday, August 02, 2012 1:49 PM To: kathleen.moriarty@emc.com; mile@ietf.org Subject: RE: [mile] FW: Agenda and Remote Participation Info for the SACM S= ide Meeting The room location listed below is not correct, we will be meeting in Regenc= y A. Thank you! Kathleen ________________________________________ From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of kathleen.m= oriarty@emc.com [kathleen.moriarty@emc.com] Sent: Monday, July 30, 2012 9:28 PM To: mile@ietf.org Subject: [mile] FW: Agenda and Remote Participation Info for the SACM Side = Meeting FYI - ________________________________________ From: sacm-bounces@ietf.org [sacm-bounces@ietf.org] On Behalf Of Waltermire= , David A. [david.waltermire@nist.gov] Sent: Monday, July 30, 2012 9:15 PM To: sacm@ietf.org Subject: [sacm] Agenda and Remote Participation Info for the SACM Side meet= ing As a reminder, the Security Automation and Continuous Monitoring (SACM) eff= ort is going to have a Side meeting at the IETF 84 meeting in Vancouver lat= er this week. A description of the meeting, the date/time, web meeting det= ails, and the agenda for the meeting follow. SACM Side Meeting IETF 84 Security Automation and Continuous Monitoring =96 SACM (pronounced as Sack-= em) Side Meeting Chairs: David Waltermire, Kent Landfield Description: A side meeting to continue the discussions around security aut= omation and continuous monitoring working group development efforts. In thi= s meeting we will be reviewing the Use Case document and then focusing on a= draft charter for the potential working group. Here are the meeting specifics: Date: Thursday, August 2, 2012 Time: 18:30 =96 20:00 PDT Room: Plaza C Thanks to Nancy Cam-Winget for organizing the webex. See conference call an= d web meeting details below. Agenda: * Agenda Bashing * Status of work since last IETF meeting * Internet Draft Discussions to: - support the charter/use cases - other potential future drafts * Discuss draft WG Charter Current Drafts: - http://www.ietf.org/id/draft-waltermire-sacm-use-cases-01.txt - draft-wa= ltermire-sacm-use-cases-01 - Analysis of Security Automation and Continuous= Monitoring (SACM) Use Cases - http://www.ietf.org/id/draft-waltermire-content-repository-00.txt - draf= t-waltermire-content-repository-00 - Automated XML Content Data Exchange an= d Management ________________________________________ Hello , Nancy Cam-Winget invites you to attend this online meeting. Topic: SACM BOF Date: Thursday, August 2, 2012 Time: 6:30 pm, Pacific Daylight Time (San Francisco, GMT-07:00) Meeting Number: 205 870 492 Meeting Password: sacm ------------------------------------------------------- To join the online meeting (Now from mobile devices!) ------------------------------------------------------- 1. Go to https://cisco.webex.com/ciscosales/j.php?ED=3D201187757&UID=3D0&PW= =3DNZWYyNWU2YWY3&RT=3DMiM0 2. Enter your name and email address. 3. Enter the meeting password: sacm 4. Click "Join Now". To view in other time zones or languages, please click the link: https://cisco.webex.com/ciscosales/j.php?ED=3D201187757&UID=3D0&PW=3DNZWYyN= WU2YWY3&ORT=3DMiM0 ---------------------------------------------------------------- ALERT:Toll-Free Dial Restrictions for (408) and (919) Area Codes ---------------------------------------------------------------- The affected toll free numbers are: (866) 432-9903 for the San Jose/Milpita= s area and (866) 349-3520 for the RTP area. Please dial the local access number for your area from the list below: - San Jose/Milpitas (408) area: 525-6800 - RTP (919) area: 392-3330 ------------------------------------------------------- To join the teleconference only ------------------------------------------------------- 1. Dial into Cisco WebEx (view all Global Access Numbers at http://cisco.com/en/US/about/doing_business/conferencing/index.html 2. Follow the prompts to enter the Meeting Number (listed above) or Access = Code followed by the # sign. San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330 US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117 India: +91.80.4350.1111 Germany: +49.619.6773.9002 Japan: +81.3.5763.9394 China: +86.10.8515.5666 ------------------------------------------------------- For assistance ------------------------------------------------------- 1. Go to https://cisco.webex.com/ciscosales/mc 2. On the left navigation bar, click "Support". You can contact me at: ncamwing@cisco.com 1-408-853 0532 To add this meeting to your calendar program (for example Microsoft Outlook= ), click this link: https://cisco.webex.com/ciscosales/j.php?ED=3D201187757&UID=3D0&ICS=3DMI&LD= =3D1&RD=3D2&ST=3D1&SHA2=3DTkz-bhelFlmrhUuPkK7v2d/0gsYehkMU1WW8szSvQnM=3D&RT= =3DMiM0 The playback of UCF (Universal Communications Format) rich media files requ= ires appropriate players. To view this type of rich media files in the meet= ing, please check whether you have the players installed on your computer b= y going to https://cisco.webex.com/ciscosales/systemdiagnosis.php. http://www.webex.com CCP:+14085256800x205870492# IMPORTANT NOTICE: This WebEx service includes a feature that allows audio a= nd any documents and other materials exchanged or viewed during the session= to be recorded. By joining this session, you automatically consent to such= recordings. If you do not consent to the recording, discuss your concerns = with the meeting host prior to the start of the recording or do not join th= e session. Please note that any such recordings may be subject to discovery= in the event of litigation. _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile From bakerj@mitre.org Fri Aug 3 08:27:46 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9337821F8D33; Fri, 3 Aug 2012 08:27:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KTx0YkpQPQPa; Fri, 3 Aug 2012 08:27:45 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id BDDBF21F8CA7; Fri, 3 Aug 2012 08:27:45 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 2862521B082B; Fri, 3 Aug 2012 11:27:45 -0400 (EDT) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 11E8721B0034; Fri, 3 Aug 2012 11:27:45 -0400 (EDT) Received: from IMCMBX03.MITRE.ORG ([169.254.3.146]) by IMCCAS04.MITRE.ORG ([129.83.29.81]) with mapi id 14.02.0309.002; Fri, 3 Aug 2012 11:27:44 -0400 From: "Baker, Jon" To: "mile@ietf.org" Thread-Topic: IPR and Transfer Considerations Thread-Index: Ac1xjIVDTlxzAl8JRGy9/mutJ1mmJA== Date: Fri, 3 Aug 2012 15:27:44 +0000 Message-ID: <6C1C15D8B5510B4B8FF132B10D38651301FECBF1@IMCMBX03.MITRE.ORG> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.51] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sacm@ietf.org" Subject: [mile] IPR and Transfer Considerations X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 15:27:46 -0000 During the MILE WG session there were questions raised related to MITRE IPR= . I would like to make sure that the list is aware that MITRE has accommoda= ted all IPR related requests that have been made by this group. There are t= hree issues that have been raised: 1- Shortly before the Paris meeting (IETF 83) a concern was raised about th= e wording in the disclaimer portion of our terms of use pages not aligning = well with the wording that that IETF uses. At that time we made a small cha= nge to the disclaimer for all the relevant efforts we support. To the best = of my knowledge, this issue was addressed.=20 2- At the Paris meeting it was clear that there was confusion about the lic= ensing of CVE and several other efforts. I was asked, "How much does CVE co= st?" This too has been addressed. CVE and these other efforts are clearly f= ree to use. =20 3- Lastly, during the MILE WG session Tuesday of this week, it was made cle= ar that MITRE needs to post IPR disclosures for all of the relevant efforts= that MITRE supports. As of August 2, 2012 IPR disclosures have been submit= ted. I don't think they have been posted by the IETF yet.=20 Are there other IPR concerns that we are not aware of? There were also questions raised about MITRE's willingness to transfer IPR = to the IETF. I attended the Paris meeting (IETF 83) and during the SACM sid= e meeting was given the opportunity to discuss MITRE's perspective on this = topic. At the time I talked through what MITRE sees as the key distinctions= to be made when considering transferring a given effort to any other organ= ization. As a reminder I discussed the following: REGISTRIES VS. LANGUAGES=20 ---------------------------------- Roughly speaking, efforts can be grouped into two primary categories: regis= tries of named objects (e.g. CVE) and languages for defining structured con= tent (e.g. OVAL). As a rule, languages are good candidates to go to formal = standards bodies as they mature. In contrast, while registries may be refer= red to by the work developed in standards bodies as external dependencies; = standards bodies do not typically operate registries. EFFORTS HAVE MULTIPLE SUBCOMPONENTS ------------------------------------------------------ Registries tend to have three primary sub-components, including: i) the syntax of the namespace, ii) the registry of officially recognized objects and iii) definitions of acceptable use (which may include product testing = requirements). Languages tend to have four primary sub-components, including: i) the specification of the language, ii) repositories of content written in that language, iii) a reference implementation that can be used to verify both the la= nguage and content authored in the language and iv) definitions of acceptable use (which may include product testing r= equirements). These components need to be considered separately.=20 USG EFFORTS VS. MITRE MANAGED EFFORTS ------------------------------------------------------- In considering the transition of MITRE efforts to standards bodies and how = these decisions will be made, it is important to clearly distinguish betwee= n US Government (USG) efforts and efforts that our sponsors have directed M= ITRE to operate as a neutral 3rd party under our FFRDC charter. As you might imagine this leads to a sort of matrix that must be considered= to ultimately ensure that a successful and appropriate transition is made = for any given effort. Outside the MILE and SACM lists there are many organi= zations that depend upon the efforts that MITRE has led for many years, in = some cases it is several hundred or more. In fact, it is hard to imagine an= INFOSEC professional in the US that has not used CVE (either directly or i= ndirectly) in their career and CVE is translations are available in many o= ther languages too. MITRE has a responsibility to ensure the stability of t= hese efforts and not lose sight of the community that depends upon them tod= ay. Rest assured that MITRE and our sponsors view successful transfer of standa= rds to international bodies as the ultimate goal of much of our standards w= ork. MITRE is actively following the MILE and SACM lists, has raised awaren= ess of the relevant IETF activities in the existing standards related forum= s that we host, and is actively engaging with our sponsors on the topic of = international standards.=20 Thanks, Jon =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Jonathan O. Baker G022 - IA Industry Collaboration The MITRE Corporation Email: bakerj@mitre.org From turners@ieca.com Fri Aug 3 11:12:02 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10E9B21F8E05 for ; Fri, 3 Aug 2012 11:12:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.738 X-Spam-Level: X-Spam-Status: No, score=-101.738 tagged_above=-999 required=5 tests=[AWL=0.527, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uOBCMAR+9KHY for ; Fri, 3 Aug 2012 11:12:01 -0700 (PDT) Received: from gateway12.websitewelcome.com (gateway12.websitewelcome.com [67.18.82.6]) by ietfa.amsl.com (Postfix) with ESMTP id 5BCA221F8E04 for ; Fri, 3 Aug 2012 11:12:01 -0700 (PDT) Received: by gateway12.websitewelcome.com (Postfix, from userid 5007) id B64F4804F0C26; Fri, 3 Aug 2012 13:12:01 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway12.websitewelcome.com (Postfix) with ESMTP id A4586804F0BC7 for ; Fri, 3 Aug 2012 13:12:01 -0500 (CDT) Received: from [130.129.37.148] (port=54458 helo=dhcp-2594.meeting.ietf.org) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1SxMLw-00015k-HO; Fri, 03 Aug 2012 13:12:00 -0500 Message-ID: <501C146F.6070205@ieca.com> Date: Fri, 03 Aug 2012 11:11:59 -0700 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: "Baker, Jon" References: <6C1C15D8B5510B4B8FF132B10D38651301FECBF1@IMCMBX03.MITRE.ORG> In-Reply-To: <6C1C15D8B5510B4B8FF132B10D38651301FECBF1@IMCMBX03.MITRE.ORG> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (dhcp-2594.meeting.ietf.org) [130.129.37.148]:54458 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 5 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: "mile@ietf.org" Subject: Re: [mile] IPR and Transfer Considerations X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 18:12:02 -0000 On 8/3/12 8:27 AM, Baker, Jon wrote: > During the MILE WG session there were questions raised related to MITRE IPR. I would like to make sure that the list is aware that MITRE has accommodated all IPR related requests that have been made by this group. There are three issues that have been raised: > > 1- Shortly before the Paris meeting (IETF 83) a concern was raised about the wording in the disclaimer portion of our terms of use pages not aligning well with the wording that that IETF uses. At that time we made a small change to the disclaimer for all the relevant efforts we support. To the best of my knowledge, this issue was addressed. > > 2- At the Paris meeting it was clear that there was confusion about the licensing of CVE and several other efforts. I was asked, "How much does CVE cost?" This too has been addressed. CVE and these other efforts are clearly free to use. > > 3- Lastly, during the MILE WG session Tuesday of this week, it was made clear that MITRE needs to post IPR disclosures for all of the relevant efforts that MITRE supports. As of August 2, 2012 IPR disclosures have been submitted. I don't think they have been posted by the IETF yet. I checked with the secretariat and they've been submitted. Thanks. > Are there other IPR concerns that we are not aware of? This is hard to answer without having seen the disclosure. MILE WG: When they're posted review them. spt > There were also questions raised about MITRE's willingness to transfer IPR to the IETF. I attended the Paris meeting (IETF 83) and during the SACM side meeting was given the opportunity to discuss MITRE's perspective on this topic. At the time I talked through what MITRE sees as the key distinctions to be made when considering transferring a given effort to any other organization. As a reminder I discussed the following: > > REGISTRIES VS. LANGUAGES > ---------------------------------- > Roughly speaking, efforts can be grouped into two primary categories: registries of named objects (e.g. CVE) and languages for defining structured content (e.g. OVAL). As a rule, languages are good candidates to go to formal standards bodies as they mature. In contrast, while registries may be referred to by the work developed in standards bodies as external dependencies; standards bodies do not typically operate registries. > > EFFORTS HAVE MULTIPLE SUBCOMPONENTS > ------------------------------------------------------ > Registries tend to have three primary sub-components, including: > i) the syntax of the namespace, > ii) the registry of officially recognized objects and > iii) definitions of acceptable use (which may include product testing requirements). > Languages tend to have four primary sub-components, including: > i) the specification of the language, > ii) repositories of content written in that language, > iii) a reference implementation that can be used to verify both the language and content authored in the language and > iv) definitions of acceptable use (which may include product testing requirements). > These components need to be considered separately. > > USG EFFORTS VS. MITRE MANAGED EFFORTS > ------------------------------------------------------- > In considering the transition of MITRE efforts to standards bodies and how these decisions will be made, it is important to clearly distinguish between US Government (USG) efforts and efforts that our sponsors have directed MITRE to operate as a neutral 3rd party under our FFRDC charter. > > > As you might imagine this leads to a sort of matrix that must be considered to ultimately ensure that a successful and appropriate transition is made for any given effort. Outside the MILE and SACM lists there are many organizations that depend upon the efforts that MITRE has led for many years, in some cases it is several hundred or more. In fact, it is hard to imagine an INFOSEC professional in the US that has not used CVE (either directly or indirectly) in their career and CVE is translations are available in many other languages too. MITRE has a responsibility to ensure the stability of these efforts and not lose sight of the community that depends upon them today. > > Rest assured that MITRE and our sponsors view successful transfer of standards to international bodies as the ultimate goal of much of our standards work. MITRE is actively following the MILE and SACM lists, has raised awareness of the relevant IETF activities in the existing standards related forums that we host, and is actively engaging with our sponsors on the topic of international standards. > > Thanks, > > Jon > > ============================================ > Jonathan O. Baker > G022 - IA Industry Collaboration > The MITRE Corporation > Email: bakerj@mitre.org > > > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile > From bakerj@mitre.org Tue Aug 7 06:03:44 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D72D521F8678 for ; Tue, 7 Aug 2012 06:03:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 65W3YhkgKVOk for ; Tue, 7 Aug 2012 06:03:43 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id A784521F8687 for ; Tue, 7 Aug 2012 06:03:42 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id B7BED21C007A; Tue, 7 Aug 2012 09:03:41 -0400 (EDT) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 8FDC021C007C; Tue, 7 Aug 2012 09:03:41 -0400 (EDT) Received: from IMCMBX03.MITRE.ORG ([169.254.3.146]) by IMCCAS02.MITRE.ORG ([129.83.29.69]) with mapi id 14.02.0309.002; Tue, 7 Aug 2012 09:03:41 -0400 From: "Baker, Jon" To: "David.Misell@bcs.org" , Sean Turner Thread-Topic: [mile] IPR and Transfer Considerations Thread-Index: Ac10nPlvZvn4bwL9Qy2D7OCDEvaANQ== Date: Tue, 7 Aug 2012 13:03:40 +0000 Message-ID: <6C1C15D8B5510B4B8FF132B10D38651302006510@IMCMBX03.MITRE.ORG> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.52] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "mile@ietf.org" , "dennis.groves@owasp.org" Subject: Re: [mile] IPR and Transfer Considerations X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 13:03:45 -0000 VGhlcmUgYXJlIGEgZmV3IGl0ZW1zIHRoYXQgd2FycmFudCBjbGFyaWZ5aW5nIGZvciB0aGUgd29y a2luZyBncm91cCByZWxhdGVkIHRvIE1JVFJFIElQUiBhbmQgdGhlIHN0YW5kYXJkaXphdGlvbiBl ZmZvcnRzIE1JVFJFIHN1cHBvcnRzLiBNSVRSRSBob2xkcyBhIHRyYWRlbWFyayBhbmQgY29weXJp Z2h0IG9uIHRoZSB2YXJpb3VzIHN0YW5kYXJkaXphdGlvbiBlZmZvcnRzIHdlIHN1cHBvcnQgZm9y IHRoZSBzb2xlIHB1cnBvc2Ugb2YgZW5zdXJpbmcgdGhleSByZW1haW4gb3BlbiBhbmQgZnJlZSB0 byB1c2UuIEFwcGx5aW5nIGEgY29weXJpZ2h0IGFuZCBob2xkaW5nIGEgdHJhZGVtYXJrIGFyZSB0 aGUgZXNzZW50aWFsIHRvb2xzIHRoYXQgYXJlIHVzZWQgdG8gZW5zdXJlIHRoZSBlZmZvcnRzIHdl IG1hbmFnZSByZW1haW4gb3BlbiBhbmQgZnJlZSB0byB1c2UuIEluIG15IHJldmlldyBvZiBvdGhl ciBvcmdhbml6YXRpb25zIHRoYXQgb3BlcmF0ZSBzdGFuZGFyZGl6YXRpb24gZWZmb3J0cyB0cmFk ZW1hcmsgYW5kIGNvcHlyaWdodCBhcmUgd2lkZWx5ICB1c2VkIGZvciB0aGlzIHB1cnBvc2UuIA0K DQpUaGUgZm9sbG93aW5nIHRleHQgd2FzIGNvcGllZCBmcm9tIHRoZSBGQVEgYWJvdXQgdGhpcyBv biB0aGUgT1ZBTCB3ZWIgc2l0ZSAoaHR0cHM6Ly9vdmFsLm1pdHJlLm9yZy9hYm91dC9mYXFzLmh0 bWwjYTE4KSBhbmQgcHJvdmlkZXMgdGhlIGdlbmVyYWwgc3RhdGVtZW50IHRoYXQgTUlUUkUgaGFz IHB1YmxpY2x5IG1hZGUgb24gdGhpcyBtYXR0ZXI6IA0KDQrigJxNSVRSRSBoYXMgY29weXJpZ2h0 ZWQgdGhlIE9WQUwgTGFuZ3VhZ2UgZm9yIHRoZSBiZW5lZml0IG9mIHRoZSBjb21tdW5pdHkgaW4g b3JkZXIgdG8gZW5zdXJlIGl0IHJlbWFpbnMgYSBmcmVlIGFuZCBvcGVuIHN0YW5kYXJkLCBhcyB3 ZWxsIGFzIHRvIGxlZ2FsbHkgcHJvdGVjdCB0aGUgb25nb2luZyB1c2Ugb2YgaXQgYW5kIGFueSBy ZXN1bHRpbmcgY29udGVudCBieSBnb3Zlcm5tZW50LCB2ZW5kb3JzLCBhbmQvb3IgdXNlcnMuIE1J VFJFIGhhcyB0cmFkZW1hcmtlZCDCriB0aGUgT1ZBTCBhY3JvbnltIGFuZCB0aGUgT1ZBTCBsb2dv IHRvIHByb3RlY3QgdGhlaXIgc29sZSBhbmQgb25nb2luZyB1c2UgYnkgdGhlIE9WQUwgZWZmb3J0 IHdpdGhpbiB0aGUgaW5mb3JtYXRpb24gc2VjdXJpdHkgYXJlbmEu4oCdDQoNClRoaXMgc2FtZSBy YXRpb25hbCBoYXMgYmVlbiB1c2VkIGZvciBhbGwgb3RoZXIgc3RhbmRhcmRpemF0aW9uIGVmZm9y dHMgdGhhdCBNSVRSRSBoYXMgbWFuYWdlZC4gDQoNCg0KUmVnYXJkaW5nIG1hcmtldGluZywgTUlU UkUgb3BlcmF0ZXMgYSBib290aCBhdCBhcHByb3hpbWF0ZWx5IDYgY29uZmVyZW5jZXMgKFJTQSwg QmxhY2tIYXQsIGFuZCBhIGZldyBvdGhlcnMpIHBlciB5ZWFyIGFzIGFuIG91dHJlYWNoIGFjdGl2 aXR5IGZvciB0aGUgdmFyaW91cyBzdGFuZGFyZGl6YXRpb24gZWZmb3J0cyB3ZSBzdXBwb3J0LiBU aGlzIGJvb3RoIGhlbHBzIHVzIGNvbm5lY3Qgd2l0aCBzb2Z0d2FyZSB2ZW5kb3JzIGFuZCBlbmQg dXNlcnMgaW4gYSB3YXkgdGhhdCB3ZSBzaW1wbHkgY291bGQgbm90IGRvIG90aGVyd2lzZS4gUmFp c2luZyBhd2FyZW5lc3Mgb2YgdGhlIHZhcmlvdXMgc3RhbmRhcmRpemF0aW9uIGVmZm9ydHMgYW5k IGVuZ2FnaW5nIHdpdGggdGhlIGNvbW11bml0eSBvZiB1c2VycyBhbmQgaW1wbGVtZW50ZXJzIGlz IGNydWNpYWwgdG8gdGhlIHN1Y2Nlc3Mgb2YgYW55IGdpdmVuIGVmZm9ydC4gDQoNCg0KTUlUUkUg aGFzIG5ldmVyIGNvbGxlY3RlZCBhIHJveWFsdHkgZm9yIHVzZSBvZiBDVkUgb3IgYW55IG9mIHRo ZSBlZmZvcnRzIHdlIHN1cHBvcnQuIENvbGxlY3Rpbmcgc3VjaCBhIHJveWFsdHkgd291bGQgYmUg Y291bnRlciB0byB0aGUgbmF0dXJlIG9mIE1JVFJFIGFzIGEgbm90IGZvciBwcm9maXQgY2hhcnRl ZCB0byB3b3JrIGluIHRoZSBwdWJsaWMgaW50ZXJlc3QuIE1JVFJFIGhhcyBvcGVyYXRlZCBDVkUg aW4gdGhpcyB3YXkgZm9yIG92ZXIgMTIgeWVhcnMgYW5kIE9WQUwgZm9yIG5lYXJseSAxMCB5ZWFy cy4NCg0KQXMgYW4gaW50ZXJlc3RpbmcgYXNpZGUsIE1JVFJFIGhhcyB3b3JrZWQgd2l0aCBPV0FT UCBmb3Igc2V2ZXJhbCB5ZWFycyByZWxhdGVkIHRvIGVmZm9ydHMgbGlrZSBDVkUsIENXRSwgYW5k IENBUEVDLiBJIGJlbGlldmUgdGhlcmUgaXMgYWxzbyBhbiBhY3RpdmUgT1dBU1AgcHJvamVjdCB1 c2luZyBPVkFMIGFuZCBvdGhlciBlZmZvcnRzIE1JVFJFIHN1cHBvcnRzLiBJZiB5b3Ugc2VhcmNo IHRoZSBPV0FTUCBzaXRlIHlvdSB3aWxsIGZpbmQgbWFueSByZWxhdGVkIGl0ZW1zLg0KDQpBbHNv IG5vdGUgdGhhdCBTV0lEcyBhcmUgYW4gSVNPIHN0YW5kYXJkICgxOTc3MC0yKS4gTUlUUkUgaXMg bm90IGludm9sdmVkIGluIHRoZSBkZXZlbG9wbWVudCBvZiB0aGUgU1dJRCBzdGFuZGFyZCBvdGhl ciB0aGFuIHdlIGhhdmUgYWN0aXZlbHkgd29ya2VkIHdpdGggVGFnVmF1bHQgdG8gZGV0ZXJtaW5l IGhvdyBiZXN0IHRvIGludGVncmF0ZSBDUEUgYW5kIFNXSUQgdGFncy4gVGhlIGNvbm5lY3Rpb24g aXMgZmFpcmx5IGxvZ2ljYWwgaW4gdGhhdCBTV0lEIHRhZ3MgbmVlZCBhbiBpZGVudGlmaWVyIGZv ciBpbnN0YWxsZWQgc29mdHdhcmUgYW5kIENQRSBOYW1lcyBwcm92aWRlIGEgc3RhbmRhcmQgaWRl bnRpZmllciBmb3IgdGhhdCBwdXJwb3NlLg0KDQpSZWdhcmRpbmcgWENDREYsIE1JVFJFIGhhcyBh Y3RlZCBhcyB0aGUgY29tbXVuaXR5IG1vZGVyYXRvciBvZiBYQ0NERiBmb3Igc2V2ZXJhbCB5ZWFy cyBhbmQgd2FzIGludm9sdmVkIGluIHRoZSBlYXJseSBzdGFnZXMgb2YgdGhlIGNyZWF0aW9uIG9m IFhDQ0RGLiBYQ0NERiB3YXMgY3JlYXRlZCBieSBOZWFsIFppcmluZyBhdCB0aGUgTlNBIGFuZCBw dWJsaXNoZWQgYXMgYSBOSVNUIElSLiBNSVRSRSBkb2VzIG5vdCBob2xkIGFueSBJUFIgcmVsYXRl ZCB0byBYQ0NERi4gDQoNCklmIHRoZSBNSUxFIHdvcmtpbmcgZ3JvdXAgaGFzIGZ1cnRoZXIgcXVl c3Rpb25zIGFib3V0IHRoZSBzdGFuZGFyZGl6YXRpb24gZWZmb3J0cyBNSVRSRSBzdXBwb3J0cyB3 ZSB3b3VsZCBiZSBoYXBweSB0byBoZWxwLg0KDQpUaGFua3MsDQoNCkpvbg0KDQo9PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KSm9uYXRoYW4gTy4gQmFrZXINCkcw MjIgLSBJQSBJbmR1c3RyeSBDb2xsYWJvcmF0aW9uDQpUaGUgTUlUUkUgQ29ycG9yYXRpb24NCkVt YWlsOiBiYWtlcmpAbWl0cmUub3JnDQoNCg0KPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ RnJvbTogRGF2aWQgTWlzZWxsIFttYWlsdG86ZGF2aWQubWlzZWxsQGJ0aW50ZXJuZXQuY29tXQ0K PlNlbnQ6IEZyaWRheSwgQXVndXN0IDAzLCAyMDEyIDY6MjQgUE0NCj5UbzogU2VhbiBUdXJuZXIN Cj5DYzogQmFrZXIsIEpvbjsgbWlsZUBpZXRmLm9yZzsgZGVubmlzLmdyb3Zlc0Bvd2FzcC5vcmcN Cj5TdWJqZWN0OiBSZTogW21pbGVdIElQUiBhbmQgVHJhbnNmZXIgQ29uc2lkZXJhdGlvbnMNCj4N Cj5TZWFuLA0KPg0KPkkgaGFkIGFuIGluIGRlcHRoIGNvbnZlcnNhdGlvbiBmb2xsb3dpbmcgdGhl IGNvbmZlcmVuY2UgY2FsbCBhdCB3aGljaCBJDQo+cmFpc2VkIHNvbWUgb2YgdGhlc2UgaXNzdWVz Lg0KPg0KPlRvIGJlIGZyYW5rIHRoZSBNSVRSRSBJUFIgaXMgYSBtYXJrZXRpbmcgY2FtcGFpZ24g c3VwcG9ydGluZyB0aGUNCj5mb2xsb3dpbmcgYnJhbmRlZCBUZXJtcyBmcm9tIHRoZSBDUEUgd2Vi IHNpdGUgY3BlLm1pdHJlLm9yZzthcyB3aXRuZXNzZWQNCj5hdCB2YXJpb3VzIHNlY3VyaXR5IGlu ZHVzdHJ5IGV2ZW50cyBzaW5jZSAyMDA5Lg0KPg0KPg0KPkdvaW5nIGZvcndhcmQgdm9sdW50ZWVy IHNlY3RvciwgSUVURiBhbmQgT1dBU1AsIEJDUyBhbmQgSUVUIHdpbGwgYWxsDQo+aGF2ZSBzaW1p bGFyIHdvcmtzIGluIHByb2dyZXNzLCBhbHNvIHBvdGVudGlhbGx5IGluIHN1cHBvcnQgb2YgTklT VCA4MDANCj5iZXN0IHByYWN0aXNlIHJlY29tbWVuZGF0aW9ucy4NCj4NCj5JZiB3ZSBhcmUgdG8g cHJvZ3Jlc3MgdGhpcywgdGhlIGJlc3QgZm9ybWF0IG1heSBiZSB0byBhZG9wdCBjcmVhdGl2ZQ0K PmNvbW1vbnMsIHJlbmFtZSBhbmQgYXZvaWQgdGhlIGZvbGxvd2luZyBicmFuZGVkIHRlcm1zLCB1 bmxlc3MgdGhleSBjYW4NCj5iZSBpbiBzb21lIHdheSBvcGVuZWQgIHRvIG1vcmUgdGhhbiAiZnJl ZSBmb3IgIHB1YmxpYyB1c2UiLCB3aGljaCB3b3VsZA0KPmFsbG93IFVTIGVuZm9yY2VtZW50IG9m IElQUiBpbiBhIHVuaWxhdGVyYWwgd2F5LCBhcyBpcyBjdXJyZW50bHkgYmVpbmcNCj5sZWdpc2xh dGVkIGZvci4NCj4NCj4NCj5Gb3IgZXhhbXBsZSBob3cgd291bGQgSSBiZSBhYmxlIHRvIHRyYWlu IENWRSB0ZXJtcyBtaXJyb3JlZCB0byBOSVNUIDgwMA0KPnNlcmllcyBiZXN0IHByYWN0aWNlIHdp dGhvdXQgcGF5aW5nIE1JVFJFIGEgcm95YWx0eS4NCj4NCj4NCj5Db25maWd1cmF0aW9ucyAoQ0NF KQ0KPg0KPlZ1bG5lcmFiaWxpdGllcyAoQ1ZFKQ0KPg0KPlNvZnR3YXJlIFdlYWtuZXNzIFR5cGVz IChDV0UpDQo+DQo+QXR0YWNrIFBhdHRlcm5zIChDQVBFQykNCj4NCj5DeWJlciBPYnNlcnZhYmxl cyAoQ3liT1gpDQo+DQo+TG9nIEZvcm1hdCAoQ0VFKQ0KPg0KPg0KPlNvZnR3YXJlIElEIFRhZ3Mg KFNXSURzKQ0KPg0KPk1hbHdhcmUgKE1BRUMpDQo+DQo+Q2hlY2tsaXN0IExhbmd1YWdlIChYQ0NE RikNCj4NCj5Bc3Nlc3NtZW50IExhbmd1YWdlIChPVkFMKQ0KPg0KPlNlY3VyaXR5IENvbnRlbnQg QXV0b21hdGlvbiAoU0NBUCkNCj4NCj5NYWtpbmcgU2VjdXJpdHkgTWVhc3VyYWJsZQ0KPg0KPg0K PldoYXQgYXNzdXJhbmNlIGNhbiB5b3UgZ2l2ZSB0aGEgbm8gSVBSIHByb3RlY3Rpb24gd2lsbCBi ZSBleGVydGVkIGF0IGFueQ0KPnBvaW50IGluIHRoZSBmdXR1cmUgb24gYmVoYWxmIG9mIE1JVFJF IGJ5IFVTIGdvdmVybm1lbnQsIGhvdyBjYW4gd2UNCj5hc3N1cmUgYSBjcmVhdGl2ZSBjb21tb25z IHN0eWxlIGFwcHJvYWNoLg0KPg0KPllvdXJzIEZhaXRoZnVsbHksDQo+DQo+RGF2ZQ0KPg0KPkRh dmlkIFMgTWlzZWxsIE1TYyAoSW5mb3JtYXRpb24gU2VjdXJpdHkgUkhVTCkgTUJDUyBDSVNTUA0K Pg0KPg0KPk9uIEZyaSwgMjAxMi0wOC0wMyBhdCAxMToxMSAtMDcwMCwgU2VhbiBUdXJuZXIgd3Jv dGU6DQo+PiBPbiA4LzMvMTIgODoyNyBBTSwgQmFrZXIsIEpvbiB3cm90ZToNCj4+ID4gRHVyaW5n IHRoZSBNSUxFIFdHIHNlc3Npb24gdGhlcmUgd2VyZSBxdWVzdGlvbnMgcmFpc2VkIHJlbGF0ZWQg dG8gTUlUUkUNCj5JUFIuIEkgd291bGQgbGlrZSB0byBtYWtlIHN1cmUgdGhhdCB0aGUgbGlzdCBp cyBhd2FyZSB0aGF0IE1JVFJFIGhhcw0KPmFjY29tbW9kYXRlZCBhbGwgSVBSIHJlbGF0ZWQgcmVx dWVzdHMgdGhhdCBoYXZlIGJlZW4gbWFkZSBieSB0aGlzIGdyb3VwLg0KPlRoZXJlIGFyZSB0aHJl ZSBpc3N1ZXMgdGhhdCBoYXZlIGJlZW4gcmFpc2VkOg0KPj4gPg0KPj4gPiAxLSBTaG9ydGx5IGJl Zm9yZSB0aGUgUGFyaXMgbWVldGluZyAoSUVURiA4MykgYSBjb25jZXJuIHdhcyByYWlzZWQgYWJv dXQNCj50aGUgd29yZGluZyBpbiB0aGUgZGlzY2xhaW1lciBwb3J0aW9uIG9mIG91ciB0ZXJtcyBv ZiB1c2UgcGFnZXMgbm90IGFsaWduaW5nDQo+d2VsbCB3aXRoIHRoZSB3b3JkaW5nIHRoYXQgdGhh dCBJRVRGIHVzZXMuIEF0IHRoYXQgdGltZSB3ZSBtYWRlIGEgc21hbGwNCj5jaGFuZ2UgdG8gdGhl IGRpc2NsYWltZXIgZm9yIGFsbCB0aGUgcmVsZXZhbnQgZWZmb3J0cyB3ZSBzdXBwb3J0LiBUbyB0 aGUgYmVzdCBvZg0KPm15IGtub3dsZWRnZSwgdGhpcyBpc3N1ZSB3YXMgYWRkcmVzc2VkLg0KPj4g Pg0KPj4gPiAyLSBBdCB0aGUgUGFyaXMgbWVldGluZyBpdCB3YXMgY2xlYXIgdGhhdCB0aGVyZSB3 YXMgY29uZnVzaW9uIGFib3V0IHRoZQ0KPmxpY2Vuc2luZyBvZiBDVkUgYW5kIHNldmVyYWwgb3Ro ZXIgZWZmb3J0cy4gSSB3YXMgYXNrZWQsICJIb3cgbXVjaCBkb2VzIENWRQ0KPmNvc3Q/IiBUaGlz IHRvbyBoYXMgYmVlbiBhZGRyZXNzZWQuIENWRSBhbmQgdGhlc2Ugb3RoZXIgZWZmb3J0cyBhcmUg Y2xlYXJseQ0KPmZyZWUgdG8gdXNlLg0KPj4gPg0KPj4gPiAzLSBMYXN0bHksIGR1cmluZyB0aGUg TUlMRSBXRyBzZXNzaW9uIFR1ZXNkYXkgb2YgdGhpcyB3ZWVrLCBpdCB3YXMgbWFkZQ0KPmNsZWFy IHRoYXQgTUlUUkUgbmVlZHMgdG8gcG9zdCBJUFIgZGlzY2xvc3VyZXMgZm9yIGFsbCBvZiB0aGUg cmVsZXZhbnQgZWZmb3J0cw0KPnRoYXQgTUlUUkUgc3VwcG9ydHMuIEFzIG9mIEF1Z3VzdCAyLCAy MDEyIElQUiBkaXNjbG9zdXJlcyBoYXZlIGJlZW4NCj5zdWJtaXR0ZWQuIEkgZG9uJ3QgdGhpbmsg dGhleSBoYXZlIGJlZW4gcG9zdGVkIGJ5IHRoZSBJRVRGIHlldC4NCj4+DQo+PiBJIGNoZWNrZWQg d2l0aCB0aGUgc2VjcmV0YXJpYXQgYW5kIHRoZXkndmUgYmVlbiBzdWJtaXR0ZWQuICBUaGFua3Mu DQo+Pg0KPj4gPiBBcmUgdGhlcmUgb3RoZXIgSVBSIGNvbmNlcm5zIHRoYXQgd2UgYXJlIG5vdCBh d2FyZSBvZj8NCj4+DQo+PiBUaGlzIGlzIGhhcmQgdG8gYW5zd2VyIHdpdGhvdXQgaGF2aW5nIHNl ZW4gdGhlIGRpc2Nsb3N1cmUuDQo+Pg0KPj4gTUlMRSBXRzogV2hlbiB0aGV5J3JlIHBvc3RlZCBy ZXZpZXcgdGhlbS4NCj4+DQo+PiBzcHQNCj4+DQo+PiA+IFRoZXJlIHdlcmUgYWxzbyBxdWVzdGlv bnMgcmFpc2VkIGFib3V0IE1JVFJFJ3Mgd2lsbGluZ25lc3MgdG8gdHJhbnNmZXIgSVBSDQo+dG8g dGhlIElFVEYuIEkgYXR0ZW5kZWQgdGhlIFBhcmlzIG1lZXRpbmcgKElFVEYgODMpIGFuZCBkdXJp bmcgdGhlIFNBQ00gc2lkZQ0KPm1lZXRpbmcgd2FzIGdpdmVuIHRoZSBvcHBvcnR1bml0eSB0byBk aXNjdXNzIE1JVFJFJ3MgcGVyc3BlY3RpdmUgb24gdGhpcw0KPnRvcGljLiBBdCB0aGUgdGltZSBJ IHRhbGtlZCB0aHJvdWdoIHdoYXQgTUlUUkUgc2VlcyBhcyB0aGUga2V5IGRpc3RpbmN0aW9ucyB0 bw0KPmJlIG1hZGUgd2hlbiBjb25zaWRlcmluZyB0cmFuc2ZlcnJpbmcgYSBnaXZlbiBlZmZvcnQg dG8gYW55IG90aGVyDQo+b3JnYW5pemF0aW9uLiBBcyBhIHJlbWluZGVyIEkgZGlzY3Vzc2VkIHRo ZSBmb2xsb3dpbmc6DQo+PiA+DQo+PiA+IFJFR0lTVFJJRVMgVlMuIExBTkdVQUdFUw0KPj4gPiAt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+PiA+IFJvdWdobHkgc3BlYWtpbmcs IGVmZm9ydHMgY2FuIGJlIGdyb3VwZWQgaW50byB0d28gcHJpbWFyeSBjYXRlZ29yaWVzOg0KPnJl Z2lzdHJpZXMgb2YgbmFtZWQgb2JqZWN0cyAoZS5nLiBDVkUpIGFuZCBsYW5ndWFnZXMgZm9yIGRl ZmluaW5nIHN0cnVjdHVyZWQNCj5jb250ZW50IChlLmcuIE9WQUwpLiBBcyBhIHJ1bGUsIGxhbmd1 YWdlcyBhcmUgZ29vZCBjYW5kaWRhdGVzIHRvIGdvIHRvIGZvcm1hbA0KPnN0YW5kYXJkcyBib2Rp ZXMgYXMgdGhleSBtYXR1cmUuIEluIGNvbnRyYXN0LCB3aGlsZSByZWdpc3RyaWVzIG1heSBiZSBy ZWZlcnJlZA0KPnRvIGJ5IHRoZSB3b3JrIGRldmVsb3BlZCBpbiBzdGFuZGFyZHMgYm9kaWVzIGFz IGV4dGVybmFsIGRlcGVuZGVuY2llczsNCj5zdGFuZGFyZHMgYm9kaWVzIGRvIG5vdCB0eXBpY2Fs bHkgb3BlcmF0ZSByZWdpc3RyaWVzLg0KPj4gPg0KPj4gPiBFRkZPUlRTIEhBVkUgTVVMVElQTEUg U1VCQ09NUE9ORU5UUw0KPj4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCj4+ID4gUmVnaXN0cmllcyB0ZW5kIHRvIGhhdmUgdGhyZWUgcHJp bWFyeSBzdWItY29tcG9uZW50cywgaW5jbHVkaW5nOg0KPj4gPiAgICAgICBpKSB0aGUgc3ludGF4 IG9mIHRoZSBuYW1lc3BhY2UsDQo+PiA+ICAgICAgIGlpKSB0aGUgcmVnaXN0cnkgb2Ygb2ZmaWNp YWxseSByZWNvZ25pemVkIG9iamVjdHMgYW5kDQo+PiA+ICAgICAgIGlpaSkgZGVmaW5pdGlvbnMg b2YgYWNjZXB0YWJsZSB1c2UgKHdoaWNoIG1heSBpbmNsdWRlIHByb2R1Y3QgdGVzdGluZw0KPnJl cXVpcmVtZW50cykuDQo+PiA+IExhbmd1YWdlcyB0ZW5kIHRvIGhhdmUgZm91ciBwcmltYXJ5IHN1 Yi1jb21wb25lbnRzLCBpbmNsdWRpbmc6DQo+PiA+ICAgICAgIGkpIHRoZSBzcGVjaWZpY2F0aW9u IG9mIHRoZSBsYW5ndWFnZSwNCj4+ID4gICAgICAgaWkpIHJlcG9zaXRvcmllcyBvZiBjb250ZW50 IHdyaXR0ZW4gaW4gdGhhdCBsYW5ndWFnZSwNCj4+ID4gICAgICAgaWlpKSBhIHJlZmVyZW5jZSBp bXBsZW1lbnRhdGlvbiB0aGF0IGNhbiBiZSB1c2VkIHRvIHZlcmlmeSBib3RoIHRoZQ0KPmxhbmd1 YWdlIGFuZCBjb250ZW50IGF1dGhvcmVkIGluIHRoZSBsYW5ndWFnZSBhbmQNCj4+ID4gICAgICAg aXYpIGRlZmluaXRpb25zIG9mIGFjY2VwdGFibGUgdXNlICh3aGljaCBtYXkgaW5jbHVkZSBwcm9k dWN0IHRlc3RpbmcNCj5yZXF1aXJlbWVudHMpLg0KPj4gPiBUaGVzZSBjb21wb25lbnRzIG5lZWQg dG8gYmUgY29uc2lkZXJlZCBzZXBhcmF0ZWx5Lg0KPj4gPg0KPj4gPiBVU0cgRUZGT1JUUyBWUy4g TUlUUkUgTUFOQUdFRCBFRkZPUlRTDQo+PiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+ID4gSW4gY29uc2lkZXJpbmcgdGhlIHRyYW5z aXRpb24gb2YgTUlUUkUgZWZmb3J0cyB0byBzdGFuZGFyZHMgYm9kaWVzIGFuZCBob3cNCj50aGVz ZSBkZWNpc2lvbnMgd2lsbCBiZSBtYWRlLCBpdCBpcyBpbXBvcnRhbnQgdG8gY2xlYXJseSBkaXN0 aW5ndWlzaCBiZXR3ZWVuIFVTDQo+R292ZXJubWVudCAoVVNHKSBlZmZvcnRzIGFuZCBlZmZvcnRz IHRoYXQgb3VyIHNwb25zb3JzIGhhdmUgZGlyZWN0ZWQgTUlUUkUNCj50byBvcGVyYXRlIGFzIGEg bmV1dHJhbCAzcmQgcGFydHkgdW5kZXIgb3VyIEZGUkRDIGNoYXJ0ZXIuDQo+PiA+DQo+PiA+DQo+ PiA+IEFzIHlvdSBtaWdodCBpbWFnaW5lIHRoaXMgbGVhZHMgdG8gYSBzb3J0IG9mIG1hdHJpeCB0 aGF0IG11c3QgYmUgY29uc2lkZXJlZA0KPnRvIHVsdGltYXRlbHkgZW5zdXJlIHRoYXQgYSBzdWNj ZXNzZnVsIGFuZCBhcHByb3ByaWF0ZSB0cmFuc2l0aW9uIGlzIG1hZGUgZm9yDQo+YW55IGdpdmVu IGVmZm9ydC4gT3V0c2lkZSB0aGUgTUlMRSBhbmQgU0FDTSBsaXN0cyB0aGVyZSBhcmUgbWFueQ0K Pm9yZ2FuaXphdGlvbnMgdGhhdCBkZXBlbmQgdXBvbiB0aGUgZWZmb3J0cyB0aGF0IE1JVFJFIGhh cyBsZWQgZm9yIG1hbnkNCj55ZWFycywgaW4gc29tZSBjYXNlcyBpdCBpcyBzZXZlcmFsIGh1bmRy ZWQgb3IgbW9yZS4gSW4gZmFjdCwgaXQgaXMgaGFyZCB0byBpbWFnaW5lDQo+YW4gSU5GT1NFQyBw cm9mZXNzaW9uYWwgaW4gdGhlIFVTIHRoYXQgaGFzIG5vdCB1c2VkIENWRSAoZWl0aGVyIGRpcmVj dGx5IG9yDQo+aW5kaXJlY3RseSkgIGluIHRoZWlyIGNhcmVlciBhbmQgQ1ZFIGlzIHRyYW5zbGF0 aW9ucyBhcmUgYXZhaWxhYmxlIGluIG1hbnkgb3RoZXINCj5sYW5ndWFnZXMgdG9vLiBNSVRSRSBo YXMgYSByZXNwb25zaWJpbGl0eSB0byBlbnN1cmUgdGhlIHN0YWJpbGl0eSBvZiB0aGVzZQ0KPmVm Zm9ydHMgYW5kIG5vdCBsb3NlIHNpZ2h0IG9mIHRoZSBjb21tdW5pdHkgdGhhdCBkZXBlbmRzIHVw b24gdGhlbSB0b2RheS4NCj4+ID4NCj4+ID4gUmVzdCBhc3N1cmVkIHRoYXQgTUlUUkUgYW5kIG91 ciBzcG9uc29ycyB2aWV3IHN1Y2Nlc3NmdWwgdHJhbnNmZXIgb2YNCj5zdGFuZGFyZHMgdG8gaW50 ZXJuYXRpb25hbCBib2RpZXMgYXMgdGhlIHVsdGltYXRlIGdvYWwgb2YgbXVjaCBvZiBvdXINCj5z dGFuZGFyZHMgd29yay4gTUlUUkUgaXMgYWN0aXZlbHkgZm9sbG93aW5nIHRoZSBNSUxFIGFuZCBT QUNNIGxpc3RzLCBoYXMNCj5yYWlzZWQgYXdhcmVuZXNzIG9mIHRoZSByZWxldmFudCBJRVRGIGFj dGl2aXRpZXMgaW4gdGhlIGV4aXN0aW5nIHN0YW5kYXJkcw0KPnJlbGF0ZWQgZm9ydW1zIHRoYXQg d2UgaG9zdCwgYW5kIGlzIGFjdGl2ZWx5IGVuZ2FnaW5nIHdpdGggb3VyIHNwb25zb3JzIG9uIHRo ZQ0KPnRvcGljIG9mIGludGVybmF0aW9uYWwgc3RhbmRhcmRzLg0KPj4gPg0KPj4gPiBUaGFua3Ms DQo+PiA+DQo+PiA+IEpvbg0KPj4gPg0KPj4gPiA9PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PQ0KPj4gPiBKb25hdGhhbiBPLiBCYWtlcg0KPj4gPiBHMDIyIC0gSUEg SW5kdXN0cnkgQ29sbGFib3JhdGlvbg0KPj4gPiBUaGUgTUlUUkUgQ29ycG9yYXRpb24NCj4+ID4g RW1haWw6IGJha2VyakBtaXRyZS5vcmcNCj4+ID4NCj4+ID4NCj4+ID4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ID4gbWlsZSBtYWlsaW5nIGxpc3QN Cj4+ID4gbWlsZUBpZXRmLm9yZw0KPj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL21pbGUNCj4+ID4NCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+PiBtaWxlIG1haWxpbmcgbGlzdA0KPj4gbWlsZUBpZXRmLm9yZw0KPj4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9taWxlDQo+DQo+LS0NCj5LaW5k IFJlZ2FyZHMsDQo+ZGF2ZQ0KPkRhdmlkIFMuIE1pc2VsbCwNCj4wNzcxMDM4MDA0NA0KPg0KDQo= From shanna@juniper.net Tue Aug 7 13:58:44 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3B3C11E80B8 for ; Tue, 7 Aug 2012 13:58:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.588 X-Spam-Level: X-Spam-Status: No, score=-106.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NKUs7LCoT7IM for ; Tue, 7 Aug 2012 13:58:43 -0700 (PDT) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by ietfa.amsl.com (Postfix) with ESMTP id 5E9C311E80D3 for ; Tue, 7 Aug 2012 13:58:36 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKUCGBdxMeYb5fGuPlP3j6tZys2zxaFbXg@postini.com; Tue, 07 Aug 2012 13:58:37 PDT Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 7 Aug 2012 13:58:23 -0700 Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by p-cldfe02-hq.jnpr.net (172.24.192.60) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 7 Aug 2012 13:58:22 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Tue, 7 Aug 2012 16:58:22 -0400 From: Stephen Hanna To: "Baker, Jon" , "David.Misell@bcs.org" , Sean Turner Date: Tue, 7 Aug 2012 16:58:21 -0400 Thread-Topic: [mile] IPR and Transfer Considerations Thread-Index: Ac10nPlvZvn4bwL9Qy2D7OCDEvaANQAQjZXw Message-ID: References: <6C1C15D8B5510B4B8FF132B10D38651302006510@IMCMBX03.MITRE.ORG> In-Reply-To: <6C1C15D8B5510B4B8FF132B10D38651302006510@IMCMBX03.MITRE.ORG> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "mile@ietf.org" , "dennis.groves@owasp.org" Subject: Re: [mile] IPR and Transfer Considerations X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 20:58:44 -0000 TUlMRSBmb2xrcywNCg0KSSBmb3VuZCB0aGUgTUlUUkUgSVBSIGRpc2Nsb3N1cmVzLiBUaGV5J3Jl IG5vdCBsaW5rZWQgdG8gTUlMRSBpbiB0aGUNCklFVEYncyBJUFIgZGlzY2xvc3VyZSB0b29sLiBI ZXJlJ3MgYSBVUkwgdGhhdCB5b3UgY2FuIHVzZSB0byBmaW5kIHRoZW06DQoNCmh0dHA6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9pcHIvc2VhcmNoLz9vcHRpb249cGF0ZW50X3NlYXJjaCZwYXRlbnRf c2VhcmNoPW1pdHJlDQoNCk5vdyBJJ2xsIGdvIGRvIHNvbWUgc3R1ZHlpbmcgb2YgdGhlbS4uLg0K DQpUaGFua3MsDQoNClN0ZXZlDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJv bTogbWlsZS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bWlsZS1ib3VuY2VzQGlldGYub3JnXSBP biBCZWhhbGYgT2YNCj4gQmFrZXIsIEpvbg0KPiBTZW50OiBUdWVzZGF5LCBBdWd1c3QgMDcsIDIw MTIgOTowNCBBTQ0KPiBUbzogRGF2aWQuTWlzZWxsQGJjcy5vcmc7IFNlYW4gVHVybmVyDQo+IENj OiBtaWxlQGlldGYub3JnOyBkZW5uaXMuZ3JvdmVzQG93YXNwLm9yZw0KPiBTdWJqZWN0OiBSZTog W21pbGVdIElQUiBhbmQgVHJhbnNmZXIgQ29uc2lkZXJhdGlvbnMNCj4gDQo+IFRoZXJlIGFyZSBh IGZldyBpdGVtcyB0aGF0IHdhcnJhbnQgY2xhcmlmeWluZyBmb3IgdGhlIHdvcmtpbmcgZ3JvdXAN Cj4gcmVsYXRlZCB0byBNSVRSRSBJUFIgYW5kIHRoZSBzdGFuZGFyZGl6YXRpb24gZWZmb3J0cyBN SVRSRSBzdXBwb3J0cy4NCj4gTUlUUkUgaG9sZHMgYSB0cmFkZW1hcmsgYW5kIGNvcHlyaWdodCBv biB0aGUgdmFyaW91cyBzdGFuZGFyZGl6YXRpb24NCj4gZWZmb3J0cyB3ZSBzdXBwb3J0IGZvciB0 aGUgc29sZSBwdXJwb3NlIG9mIGVuc3VyaW5nIHRoZXkgcmVtYWluIG9wZW4NCj4gYW5kIGZyZWUg dG8gdXNlLiBBcHBseWluZyBhIGNvcHlyaWdodCBhbmQgaG9sZGluZyBhIHRyYWRlbWFyayBhcmUg dGhlDQo+IGVzc2VudGlhbCB0b29scyB0aGF0IGFyZSB1c2VkIHRvIGVuc3VyZSB0aGUgZWZmb3J0 cyB3ZSBtYW5hZ2UgcmVtYWluDQo+IG9wZW4gYW5kIGZyZWUgdG8gdXNlLiBJbiBteSByZXZpZXcg b2Ygb3RoZXIgb3JnYW5pemF0aW9ucyB0aGF0IG9wZXJhdGUNCj4gc3RhbmRhcmRpemF0aW9uIGVm Zm9ydHMgdHJhZGVtYXJrIGFuZCBjb3B5cmlnaHQgYXJlIHdpZGVseSAgdXNlZCBmb3INCj4gdGhp cyBwdXJwb3NlLg0KPiANCj4gVGhlIGZvbGxvd2luZyB0ZXh0IHdhcyBjb3BpZWQgZnJvbSB0aGUg RkFRIGFib3V0IHRoaXMgb24gdGhlIE9WQUwgd2ViDQo+IHNpdGUgKGh0dHBzOi8vb3ZhbC5taXRy ZS5vcmcvYWJvdXQvZmFxcy5odG1sI2ExOCkgYW5kIHByb3ZpZGVzIHRoZQ0KPiBnZW5lcmFsIHN0 YXRlbWVudCB0aGF0IE1JVFJFIGhhcyBwdWJsaWNseSBtYWRlIG9uIHRoaXMgbWF0dGVyOg0KPiAN Cj4g4oCcTUlUUkUgaGFzIGNvcHlyaWdodGVkIHRoZSBPVkFMIExhbmd1YWdlIGZvciB0aGUgYmVu ZWZpdCBvZiB0aGUNCj4gY29tbXVuaXR5IGluIG9yZGVyIHRvIGVuc3VyZSBpdCByZW1haW5zIGEg ZnJlZSBhbmQgb3BlbiBzdGFuZGFyZCwgYXMNCj4gd2VsbCBhcyB0byBsZWdhbGx5IHByb3RlY3Qg dGhlIG9uZ29pbmcgdXNlIG9mIGl0IGFuZCBhbnkgcmVzdWx0aW5nDQo+IGNvbnRlbnQgYnkgZ292 ZXJubWVudCwgdmVuZG9ycywgYW5kL29yIHVzZXJzLiBNSVRSRSBoYXMgdHJhZGVtYXJrZWQgwq4N Cj4gdGhlIE9WQUwgYWNyb255bSBhbmQgdGhlIE9WQUwgbG9nbyB0byBwcm90ZWN0IHRoZWlyIHNv bGUgYW5kIG9uZ29pbmcNCj4gdXNlIGJ5IHRoZSBPVkFMIGVmZm9ydCB3aXRoaW4gdGhlIGluZm9y bWF0aW9uIHNlY3VyaXR5IGFyZW5hLuKAnQ0KPiANCj4gVGhpcyBzYW1lIHJhdGlvbmFsIGhhcyBi ZWVuIHVzZWQgZm9yIGFsbCBvdGhlciBzdGFuZGFyZGl6YXRpb24gZWZmb3J0cw0KPiB0aGF0IE1J VFJFIGhhcyBtYW5hZ2VkLg0KPiANCj4gDQo+IFJlZ2FyZGluZyBtYXJrZXRpbmcsIE1JVFJFIG9w ZXJhdGVzIGEgYm9vdGggYXQgYXBwcm94aW1hdGVseSA2DQo+IGNvbmZlcmVuY2VzIChSU0EsIEJs YWNrSGF0LCBhbmQgYSBmZXcgb3RoZXJzKSBwZXIgeWVhciBhcyBhbiBvdXRyZWFjaA0KPiBhY3Rp dml0eSBmb3IgdGhlIHZhcmlvdXMgc3RhbmRhcmRpemF0aW9uIGVmZm9ydHMgd2Ugc3VwcG9ydC4g VGhpcyBib290aA0KPiBoZWxwcyB1cyBjb25uZWN0IHdpdGggc29mdHdhcmUgdmVuZG9ycyBhbmQg ZW5kIHVzZXJzIGluIGEgd2F5IHRoYXQgd2UNCj4gc2ltcGx5IGNvdWxkIG5vdCBkbyBvdGhlcndp c2UuIFJhaXNpbmcgYXdhcmVuZXNzIG9mIHRoZSB2YXJpb3VzDQo+IHN0YW5kYXJkaXphdGlvbiBl ZmZvcnRzIGFuZCBlbmdhZ2luZyB3aXRoIHRoZSBjb21tdW5pdHkgb2YgdXNlcnMgYW5kDQo+IGlt cGxlbWVudGVycyBpcyBjcnVjaWFsIHRvIHRoZSBzdWNjZXNzIG9mIGFueSBnaXZlbiBlZmZvcnQu DQo+IA0KPiANCj4gTUlUUkUgaGFzIG5ldmVyIGNvbGxlY3RlZCBhIHJveWFsdHkgZm9yIHVzZSBv ZiBDVkUgb3IgYW55IG9mIHRoZQ0KPiBlZmZvcnRzIHdlIHN1cHBvcnQuIENvbGxlY3Rpbmcgc3Vj aCBhIHJveWFsdHkgd291bGQgYmUgY291bnRlciB0byB0aGUNCj4gbmF0dXJlIG9mIE1JVFJFIGFz IGEgbm90IGZvciBwcm9maXQgY2hhcnRlZCB0byB3b3JrIGluIHRoZSBwdWJsaWMNCj4gaW50ZXJl c3QuIE1JVFJFIGhhcyBvcGVyYXRlZCBDVkUgaW4gdGhpcyB3YXkgZm9yIG92ZXIgMTIgeWVhcnMg YW5kIE9WQUwNCj4gZm9yIG5lYXJseSAxMCB5ZWFycy4NCj4gDQo+IEFzIGFuIGludGVyZXN0aW5n IGFzaWRlLCBNSVRSRSBoYXMgd29ya2VkIHdpdGggT1dBU1AgZm9yIHNldmVyYWwgeWVhcnMNCj4g cmVsYXRlZCB0byBlZmZvcnRzIGxpa2UgQ1ZFLCBDV0UsIGFuZCBDQVBFQy4gSSBiZWxpZXZlIHRo ZXJlIGlzIGFsc28gYW4NCj4gYWN0aXZlIE9XQVNQIHByb2plY3QgdXNpbmcgT1ZBTCBhbmQgb3Ro ZXIgZWZmb3J0cyBNSVRSRSBzdXBwb3J0cy4gSWYNCj4geW91IHNlYXJjaCB0aGUgT1dBU1Agc2l0 ZSB5b3Ugd2lsbCBmaW5kIG1hbnkgcmVsYXRlZCBpdGVtcy4NCj4gDQo+IEFsc28gbm90ZSB0aGF0 IFNXSURzIGFyZSBhbiBJU08gc3RhbmRhcmQgKDE5NzcwLTIpLiBNSVRSRSBpcyBub3QNCj4gaW52 b2x2ZWQgaW4gdGhlIGRldmVsb3BtZW50IG9mIHRoZSBTV0lEIHN0YW5kYXJkIG90aGVyIHRoYW4g d2UgaGF2ZQ0KPiBhY3RpdmVseSB3b3JrZWQgd2l0aCBUYWdWYXVsdCB0byBkZXRlcm1pbmUgaG93 IGJlc3QgdG8gaW50ZWdyYXRlIENQRQ0KPiBhbmQgU1dJRCB0YWdzLiBUaGUgY29ubmVjdGlvbiBp cyBmYWlybHkgbG9naWNhbCBpbiB0aGF0IFNXSUQgdGFncyBuZWVkDQo+IGFuIGlkZW50aWZpZXIg Zm9yIGluc3RhbGxlZCBzb2Z0d2FyZSBhbmQgQ1BFIE5hbWVzIHByb3ZpZGUgYSBzdGFuZGFyZA0K PiBpZGVudGlmaWVyIGZvciB0aGF0IHB1cnBvc2UuDQo+IA0KPiBSZWdhcmRpbmcgWENDREYsIE1J VFJFIGhhcyBhY3RlZCBhcyB0aGUgY29tbXVuaXR5IG1vZGVyYXRvciBvZiBYQ0NERg0KPiBmb3Ig c2V2ZXJhbCB5ZWFycyBhbmQgd2FzIGludm9sdmVkIGluIHRoZSBlYXJseSBzdGFnZXMgb2YgdGhl IGNyZWF0aW9uDQo+IG9mIFhDQ0RGLiBYQ0NERiB3YXMgY3JlYXRlZCBieSBOZWFsIFppcmluZyBh dCB0aGUgTlNBIGFuZCBwdWJsaXNoZWQgYXMNCj4gYSBOSVNUIElSLiBNSVRSRSBkb2VzIG5vdCBo b2xkIGFueSBJUFIgcmVsYXRlZCB0byBYQ0NERi4NCj4gDQo+IElmIHRoZSBNSUxFIHdvcmtpbmcg Z3JvdXAgaGFzIGZ1cnRoZXIgcXVlc3Rpb25zIGFib3V0IHRoZQ0KPiBzdGFuZGFyZGl6YXRpb24g ZWZmb3J0cyBNSVRSRSBzdXBwb3J0cyB3ZSB3b3VsZCBiZSBoYXBweSB0byBoZWxwLg0KPiANCj4g VGhhbmtzLA0KPiANCj4gSm9uDQo+IA0KPiA9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PQ0KPiBKb25hdGhhbiBPLiBCYWtlcg0KPiBHMDIyIC0gSUEgSW5kdXN0cnkg Q29sbGFib3JhdGlvbg0KPiBUaGUgTUlUUkUgQ29ycG9yYXRpb24NCj4gRW1haWw6IGJha2VyakBt aXRyZS5vcmcNCj4gDQo+IA0KPiA+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPkZyb206 IERhdmlkIE1pc2VsbCBbbWFpbHRvOmRhdmlkLm1pc2VsbEBidGludGVybmV0LmNvbV0NCj4gPlNl bnQ6IEZyaWRheSwgQXVndXN0IDAzLCAyMDEyIDY6MjQgUE0NCj4gPlRvOiBTZWFuIFR1cm5lcg0K PiA+Q2M6IEJha2VyLCBKb247IG1pbGVAaWV0Zi5vcmc7IGRlbm5pcy5ncm92ZXNAb3dhc3Aub3Jn DQo+ID5TdWJqZWN0OiBSZTogW21pbGVdIElQUiBhbmQgVHJhbnNmZXIgQ29uc2lkZXJhdGlvbnMN Cj4gPg0KPiA+U2VhbiwNCj4gPg0KPiA+SSBoYWQgYW4gaW4gZGVwdGggY29udmVyc2F0aW9uIGZv bGxvd2luZyB0aGUgY29uZmVyZW5jZSBjYWxsIGF0IHdoaWNoDQo+IEkNCj4gPnJhaXNlZCBzb21l IG9mIHRoZXNlIGlzc3Vlcy4NCj4gPg0KPiA+VG8gYmUgZnJhbmsgdGhlIE1JVFJFIElQUiBpcyBh IG1hcmtldGluZyBjYW1wYWlnbiBzdXBwb3J0aW5nIHRoZQ0KPiA+Zm9sbG93aW5nIGJyYW5kZWQg VGVybXMgZnJvbSB0aGUgQ1BFIHdlYiBzaXRlIGNwZS5taXRyZS5vcmc7YXMNCj4gd2l0bmVzc2Vk DQo+ID5hdCB2YXJpb3VzIHNlY3VyaXR5IGluZHVzdHJ5IGV2ZW50cyBzaW5jZSAyMDA5Lg0KPiA+ DQo+ID4NCj4gPkdvaW5nIGZvcndhcmQgdm9sdW50ZWVyIHNlY3RvciwgSUVURiBhbmQgT1dBU1As IEJDUyBhbmQgSUVUIHdpbGwgYWxsDQo+ID5oYXZlIHNpbWlsYXIgd29ya3MgaW4gcHJvZ3Jlc3Ms IGFsc28gcG90ZW50aWFsbHkgaW4gc3VwcG9ydCBvZiBOSVNUDQo+IDgwMA0KPiA+YmVzdCBwcmFj dGlzZSByZWNvbW1lbmRhdGlvbnMuDQo+ID4NCj4gPklmIHdlIGFyZSB0byBwcm9ncmVzcyB0aGlz LCB0aGUgYmVzdCBmb3JtYXQgbWF5IGJlIHRvIGFkb3B0IGNyZWF0aXZlDQo+ID5jb21tb25zLCBy ZW5hbWUgYW5kIGF2b2lkIHRoZSBmb2xsb3dpbmcgYnJhbmRlZCB0ZXJtcywgdW5sZXNzIHRoZXkg Y2FuDQo+ID5iZSBpbiBzb21lIHdheSBvcGVuZWQgIHRvIG1vcmUgdGhhbiAiZnJlZSBmb3IgIHB1 YmxpYyB1c2UiLCB3aGljaA0KPiB3b3VsZA0KPiA+YWxsb3cgVVMgZW5mb3JjZW1lbnQgb2YgSVBS IGluIGEgdW5pbGF0ZXJhbCB3YXksIGFzIGlzIGN1cnJlbnRseSBiZWluZw0KPiA+bGVnaXNsYXRl ZCBmb3IuDQo+ID4NCj4gPg0KPiA+Rm9yIGV4YW1wbGUgaG93IHdvdWxkIEkgYmUgYWJsZSB0byB0 cmFpbiBDVkUgdGVybXMgbWlycm9yZWQgdG8gTklTVA0KPiA4MDANCj4gPnNlcmllcyBiZXN0IHBy YWN0aWNlIHdpdGhvdXQgcGF5aW5nIE1JVFJFIGEgcm95YWx0eS4NCj4gPg0KPiA+DQo+ID5Db25m aWd1cmF0aW9ucyAoQ0NFKQ0KPiA+DQo+ID5WdWxuZXJhYmlsaXRpZXMgKENWRSkNCj4gPg0KPiA+ U29mdHdhcmUgV2Vha25lc3MgVHlwZXMgKENXRSkNCj4gPg0KPiA+QXR0YWNrIFBhdHRlcm5zIChD QVBFQykNCj4gPg0KPiA+Q3liZXIgT2JzZXJ2YWJsZXMgKEN5Yk9YKQ0KPiA+DQo+ID5Mb2cgRm9y bWF0IChDRUUpDQo+ID4NCj4gPg0KPiA+U29mdHdhcmUgSUQgVGFncyAoU1dJRHMpDQo+ID4NCj4g Pk1hbHdhcmUgKE1BRUMpDQo+ID4NCj4gPkNoZWNrbGlzdCBMYW5ndWFnZSAoWENDREYpDQo+ID4N Cj4gPkFzc2Vzc21lbnQgTGFuZ3VhZ2UgKE9WQUwpDQo+ID4NCj4gPlNlY3VyaXR5IENvbnRlbnQg QXV0b21hdGlvbiAoU0NBUCkNCj4gPg0KPiA+TWFraW5nIFNlY3VyaXR5IE1lYXN1cmFibGUNCj4g Pg0KPiA+DQo+ID5XaGF0IGFzc3VyYW5jZSBjYW4geW91IGdpdmUgdGhhIG5vIElQUiBwcm90ZWN0 aW9uIHdpbGwgYmUgZXhlcnRlZCBhdA0KPiBhbnkNCj4gPnBvaW50IGluIHRoZSBmdXR1cmUgb24g YmVoYWxmIG9mIE1JVFJFIGJ5IFVTIGdvdmVybm1lbnQsIGhvdyBjYW4gd2UNCj4gPmFzc3VyZSBh IGNyZWF0aXZlIGNvbW1vbnMgc3R5bGUgYXBwcm9hY2guDQo+ID4NCj4gPllvdXJzIEZhaXRoZnVs bHksDQo+ID4NCj4gPkRhdmUNCj4gPg0KPiA+RGF2aWQgUyBNaXNlbGwgTVNjIChJbmZvcm1hdGlv biBTZWN1cml0eSBSSFVMKSBNQkNTIENJU1NQDQo+ID4NCj4gPg0KPiA+T24gRnJpLCAyMDEyLTA4 LTAzIGF0IDExOjExIC0wNzAwLCBTZWFuIFR1cm5lciB3cm90ZToNCj4gPj4gT24gOC8zLzEyIDg6 MjcgQU0sIEJha2VyLCBKb24gd3JvdGU6DQo+ID4+ID4gRHVyaW5nIHRoZSBNSUxFIFdHIHNlc3Np b24gdGhlcmUgd2VyZSBxdWVzdGlvbnMgcmFpc2VkIHJlbGF0ZWQgdG8NCj4gTUlUUkUNCj4gPklQ Ui4gSSB3b3VsZCBsaWtlIHRvIG1ha2Ugc3VyZSB0aGF0IHRoZSBsaXN0IGlzIGF3YXJlIHRoYXQg TUlUUkUgaGFzDQo+ID5hY2NvbW1vZGF0ZWQgYWxsIElQUiByZWxhdGVkIHJlcXVlc3RzIHRoYXQg aGF2ZSBiZWVuIG1hZGUgYnkgdGhpcw0KPiBncm91cC4NCj4gPlRoZXJlIGFyZSB0aHJlZSBpc3N1 ZXMgdGhhdCBoYXZlIGJlZW4gcmFpc2VkOg0KPiA+PiA+DQo+ID4+ID4gMS0gU2hvcnRseSBiZWZv cmUgdGhlIFBhcmlzIG1lZXRpbmcgKElFVEYgODMpIGEgY29uY2VybiB3YXMgcmFpc2VkDQo+IGFi b3V0DQo+ID50aGUgd29yZGluZyBpbiB0aGUgZGlzY2xhaW1lciBwb3J0aW9uIG9mIG91ciB0ZXJt cyBvZiB1c2UgcGFnZXMgbm90DQo+IGFsaWduaW5nDQo+ID53ZWxsIHdpdGggdGhlIHdvcmRpbmcg dGhhdCB0aGF0IElFVEYgdXNlcy4gQXQgdGhhdCB0aW1lIHdlIG1hZGUgYQ0KPiBzbWFsbA0KPiA+ Y2hhbmdlIHRvIHRoZSBkaXNjbGFpbWVyIGZvciBhbGwgdGhlIHJlbGV2YW50IGVmZm9ydHMgd2Ug c3VwcG9ydC4gVG8NCj4gdGhlIGJlc3Qgb2YNCj4gPm15IGtub3dsZWRnZSwgdGhpcyBpc3N1ZSB3 YXMgYWRkcmVzc2VkLg0KPiA+PiA+DQo+ID4+ID4gMi0gQXQgdGhlIFBhcmlzIG1lZXRpbmcgaXQg d2FzIGNsZWFyIHRoYXQgdGhlcmUgd2FzIGNvbmZ1c2lvbg0KPiBhYm91dCB0aGUNCj4gPmxpY2Vu c2luZyBvZiBDVkUgYW5kIHNldmVyYWwgb3RoZXIgZWZmb3J0cy4gSSB3YXMgYXNrZWQsICJIb3cg bXVjaA0KPiBkb2VzIENWRQ0KPiA+Y29zdD8iIFRoaXMgdG9vIGhhcyBiZWVuIGFkZHJlc3NlZC4g Q1ZFIGFuZCB0aGVzZSBvdGhlciBlZmZvcnRzIGFyZQ0KPiBjbGVhcmx5DQo+ID5mcmVlIHRvIHVz ZS4NCj4gPj4gPg0KPiA+PiA+IDMtIExhc3RseSwgZHVyaW5nIHRoZSBNSUxFIFdHIHNlc3Npb24g VHVlc2RheSBvZiB0aGlzIHdlZWssIGl0IHdhcw0KPiBtYWRlDQo+ID5jbGVhciB0aGF0IE1JVFJF IG5lZWRzIHRvIHBvc3QgSVBSIGRpc2Nsb3N1cmVzIGZvciBhbGwgb2YgdGhlIHJlbGV2YW50DQo+ IGVmZm9ydHMNCj4gPnRoYXQgTUlUUkUgc3VwcG9ydHMuIEFzIG9mIEF1Z3VzdCAyLCAyMDEyIElQ UiBkaXNjbG9zdXJlcyBoYXZlIGJlZW4NCj4gPnN1Ym1pdHRlZC4gSSBkb24ndCB0aGluayB0aGV5 IGhhdmUgYmVlbiBwb3N0ZWQgYnkgdGhlIElFVEYgeWV0Lg0KPiA+Pg0KPiA+PiBJIGNoZWNrZWQg d2l0aCB0aGUgc2VjcmV0YXJpYXQgYW5kIHRoZXkndmUgYmVlbiBzdWJtaXR0ZWQuICBUaGFua3Mu DQo+ID4+DQo+ID4+ID4gQXJlIHRoZXJlIG90aGVyIElQUiBjb25jZXJucyB0aGF0IHdlIGFyZSBu b3QgYXdhcmUgb2Y/DQo+ID4+DQo+ID4+IFRoaXMgaXMgaGFyZCB0byBhbnN3ZXIgd2l0aG91dCBo YXZpbmcgc2VlbiB0aGUgZGlzY2xvc3VyZS4NCj4gPj4NCj4gPj4gTUlMRSBXRzogV2hlbiB0aGV5 J3JlIHBvc3RlZCByZXZpZXcgdGhlbS4NCj4gPj4NCj4gPj4gc3B0DQo+ID4+DQo+ID4+ID4gVGhl cmUgd2VyZSBhbHNvIHF1ZXN0aW9ucyByYWlzZWQgYWJvdXQgTUlUUkUncyB3aWxsaW5nbmVzcyB0 bw0KPiB0cmFuc2ZlciBJUFINCj4gPnRvIHRoZSBJRVRGLiBJIGF0dGVuZGVkIHRoZSBQYXJpcyBt ZWV0aW5nIChJRVRGIDgzKSBhbmQgZHVyaW5nIHRoZQ0KPiBTQUNNIHNpZGUNCj4gPm1lZXRpbmcg d2FzIGdpdmVuIHRoZSBvcHBvcnR1bml0eSB0byBkaXNjdXNzIE1JVFJFJ3MgcGVyc3BlY3RpdmUg b24NCj4gdGhpcw0KPiA+dG9waWMuIEF0IHRoZSB0aW1lIEkgdGFsa2VkIHRocm91Z2ggd2hhdCBN SVRSRSBzZWVzIGFzIHRoZSBrZXkNCj4gZGlzdGluY3Rpb25zIHRvDQo+ID5iZSBtYWRlIHdoZW4g Y29uc2lkZXJpbmcgdHJhbnNmZXJyaW5nIGEgZ2l2ZW4gZWZmb3J0IHRvIGFueSBvdGhlcg0KPiA+ b3JnYW5pemF0aW9uLiBBcyBhIHJlbWluZGVyIEkgZGlzY3Vzc2VkIHRoZSBmb2xsb3dpbmc6DQo+ ID4+ID4NCj4gPj4gPiBSRUdJU1RSSUVTIFZTLiBMQU5HVUFHRVMNCj4gPj4gPiAtLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4+ID4gUm91Z2hseSBzcGVha2luZywgZWZmb3J0 cyBjYW4gYmUgZ3JvdXBlZCBpbnRvIHR3byBwcmltYXJ5DQo+IGNhdGVnb3JpZXM6DQo+ID5yZWdp c3RyaWVzIG9mIG5hbWVkIG9iamVjdHMgKGUuZy4gQ1ZFKSBhbmQgbGFuZ3VhZ2VzIGZvciBkZWZp bmluZw0KPiBzdHJ1Y3R1cmVkDQo+ID5jb250ZW50IChlLmcuIE9WQUwpLiBBcyBhIHJ1bGUsIGxh bmd1YWdlcyBhcmUgZ29vZCBjYW5kaWRhdGVzIHRvIGdvIHRvDQo+IGZvcm1hbA0KPiA+c3RhbmRh cmRzIGJvZGllcyBhcyB0aGV5IG1hdHVyZS4gSW4gY29udHJhc3QsIHdoaWxlIHJlZ2lzdHJpZXMg bWF5IGJlDQo+IHJlZmVycmVkDQo+ID50byBieSB0aGUgd29yayBkZXZlbG9wZWQgaW4gc3RhbmRh cmRzIGJvZGllcyBhcyBleHRlcm5hbCBkZXBlbmRlbmNpZXM7DQo+ID5zdGFuZGFyZHMgYm9kaWVz IGRvIG5vdCB0eXBpY2FsbHkgb3BlcmF0ZSByZWdpc3RyaWVzLg0KPiA+PiA+DQo+ID4+ID4gRUZG T1JUUyBIQVZFIE1VTFRJUExFIFNVQkNPTVBPTkVOVFMNCj4gPj4gPiAtLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPj4gPiBSZWdpc3RyaWVz IHRlbmQgdG8gaGF2ZSB0aHJlZSBwcmltYXJ5IHN1Yi1jb21wb25lbnRzLCBpbmNsdWRpbmc6DQo+ ID4+ID4gICAgICAgaSkgdGhlIHN5bnRheCBvZiB0aGUgbmFtZXNwYWNlLA0KPiA+PiA+ICAgICAg IGlpKSB0aGUgcmVnaXN0cnkgb2Ygb2ZmaWNpYWxseSByZWNvZ25pemVkIG9iamVjdHMgYW5kDQo+ ID4+ID4gICAgICAgaWlpKSBkZWZpbml0aW9ucyBvZiBhY2NlcHRhYmxlIHVzZSAod2hpY2ggbWF5 IGluY2x1ZGUNCj4gcHJvZHVjdCB0ZXN0aW5nDQo+ID5yZXF1aXJlbWVudHMpLg0KPiA+PiA+IExh bmd1YWdlcyB0ZW5kIHRvIGhhdmUgZm91ciBwcmltYXJ5IHN1Yi1jb21wb25lbnRzLCBpbmNsdWRp bmc6DQo+ID4+ID4gICAgICAgaSkgdGhlIHNwZWNpZmljYXRpb24gb2YgdGhlIGxhbmd1YWdlLA0K PiA+PiA+ICAgICAgIGlpKSByZXBvc2l0b3JpZXMgb2YgY29udGVudCB3cml0dGVuIGluIHRoYXQg bGFuZ3VhZ2UsDQo+ID4+ID4gICAgICAgaWlpKSBhIHJlZmVyZW5jZSBpbXBsZW1lbnRhdGlvbiB0 aGF0IGNhbiBiZSB1c2VkIHRvIHZlcmlmeQ0KPiBib3RoIHRoZQ0KPiA+bGFuZ3VhZ2UgYW5kIGNv bnRlbnQgYXV0aG9yZWQgaW4gdGhlIGxhbmd1YWdlIGFuZA0KPiA+PiA+ICAgICAgIGl2KSBkZWZp bml0aW9ucyBvZiBhY2NlcHRhYmxlIHVzZSAod2hpY2ggbWF5IGluY2x1ZGUgcHJvZHVjdA0KPiB0 ZXN0aW5nDQo+ID5yZXF1aXJlbWVudHMpLg0KPiA+PiA+IFRoZXNlIGNvbXBvbmVudHMgbmVlZCB0 byBiZSBjb25zaWRlcmVkIHNlcGFyYXRlbHkuDQo+ID4+ID4NCj4gPj4gPiBVU0cgRUZGT1JUUyBW Uy4gTUlUUkUgTUFOQUdFRCBFRkZPUlRTDQo+ID4+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+PiA+IEluIGNvbnNpZGVyaW5nIHRo ZSB0cmFuc2l0aW9uIG9mIE1JVFJFIGVmZm9ydHMgdG8gc3RhbmRhcmRzIGJvZGllcw0KPiBhbmQg aG93DQo+ID50aGVzZSBkZWNpc2lvbnMgd2lsbCBiZSBtYWRlLCBpdCBpcyBpbXBvcnRhbnQgdG8g Y2xlYXJseSBkaXN0aW5ndWlzaA0KPiBiZXR3ZWVuIFVTDQo+ID5Hb3Zlcm5tZW50IChVU0cpIGVm Zm9ydHMgYW5kIGVmZm9ydHMgdGhhdCBvdXIgc3BvbnNvcnMgaGF2ZSBkaXJlY3RlZA0KPiBNSVRS RQ0KPiA+dG8gb3BlcmF0ZSBhcyBhIG5ldXRyYWwgM3JkIHBhcnR5IHVuZGVyIG91ciBGRlJEQyBj aGFydGVyLg0KPiA+PiA+DQo+ID4+ID4NCj4gPj4gPiBBcyB5b3UgbWlnaHQgaW1hZ2luZSB0aGlz IGxlYWRzIHRvIGEgc29ydCBvZiBtYXRyaXggdGhhdCBtdXN0IGJlDQo+IGNvbnNpZGVyZWQNCj4g PnRvIHVsdGltYXRlbHkgZW5zdXJlIHRoYXQgYSBzdWNjZXNzZnVsIGFuZCBhcHByb3ByaWF0ZSB0 cmFuc2l0aW9uIGlzDQo+IG1hZGUgZm9yDQo+ID5hbnkgZ2l2ZW4gZWZmb3J0LiBPdXRzaWRlIHRo ZSBNSUxFIGFuZCBTQUNNIGxpc3RzIHRoZXJlIGFyZSBtYW55DQo+ID5vcmdhbml6YXRpb25zIHRo YXQgZGVwZW5kIHVwb24gdGhlIGVmZm9ydHMgdGhhdCBNSVRSRSBoYXMgbGVkIGZvciBtYW55DQo+ ID55ZWFycywgaW4gc29tZSBjYXNlcyBpdCBpcyBzZXZlcmFsIGh1bmRyZWQgb3IgbW9yZS4gSW4g ZmFjdCwgaXQgaXMNCj4gaGFyZCB0byBpbWFnaW5lDQo+ID5hbiBJTkZPU0VDIHByb2Zlc3Npb25h bCBpbiB0aGUgVVMgdGhhdCBoYXMgbm90IHVzZWQgQ1ZFIChlaXRoZXINCj4gZGlyZWN0bHkgb3IN Cj4gPmluZGlyZWN0bHkpICBpbiB0aGVpciBjYXJlZXIgYW5kIENWRSBpcyB0cmFuc2xhdGlvbnMg YXJlIGF2YWlsYWJsZSBpbg0KPiBtYW55IG90aGVyDQo+ID5sYW5ndWFnZXMgdG9vLiBNSVRSRSBo YXMgYSByZXNwb25zaWJpbGl0eSB0byBlbnN1cmUgdGhlIHN0YWJpbGl0eSBvZg0KPiB0aGVzZQ0K PiA+ZWZmb3J0cyBhbmQgbm90IGxvc2Ugc2lnaHQgb2YgdGhlIGNvbW11bml0eSB0aGF0IGRlcGVu ZHMgdXBvbiB0aGVtDQo+IHRvZGF5Lg0KPiA+PiA+DQo+ID4+ID4gUmVzdCBhc3N1cmVkIHRoYXQg TUlUUkUgYW5kIG91ciBzcG9uc29ycyB2aWV3IHN1Y2Nlc3NmdWwgdHJhbnNmZXINCj4gb2YNCj4g PnN0YW5kYXJkcyB0byBpbnRlcm5hdGlvbmFsIGJvZGllcyBhcyB0aGUgdWx0aW1hdGUgZ29hbCBv ZiBtdWNoIG9mIG91cg0KPiA+c3RhbmRhcmRzIHdvcmsuIE1JVFJFIGlzIGFjdGl2ZWx5IGZvbGxv d2luZyB0aGUgTUlMRSBhbmQgU0FDTSBsaXN0cywNCj4gaGFzDQo+ID5yYWlzZWQgYXdhcmVuZXNz IG9mIHRoZSByZWxldmFudCBJRVRGIGFjdGl2aXRpZXMgaW4gdGhlIGV4aXN0aW5nDQo+IHN0YW5k YXJkcw0KPiA+cmVsYXRlZCBmb3J1bXMgdGhhdCB3ZSBob3N0LCBhbmQgaXMgYWN0aXZlbHkgZW5n YWdpbmcgd2l0aCBvdXINCj4gc3BvbnNvcnMgb24gdGhlDQo+ID50b3BpYyBvZiBpbnRlcm5hdGlv bmFsIHN0YW5kYXJkcy4NCj4gPj4gPg0KPiA+PiA+IFRoYW5rcywNCj4gPj4gPg0KPiA+PiA+IEpv bg0KPiA+PiA+DQo+ID4+ID4gPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT0NCj4gPj4gPiBKb25hdGhhbiBPLiBCYWtlcg0KPiA+PiA+IEcwMjIgLSBJQSBJbmR1c3Ry eSBDb2xsYWJvcmF0aW9uDQo+ID4+ID4gVGhlIE1JVFJFIENvcnBvcmF0aW9uDQo+ID4+ID4gRW1h aWw6IGJha2VyakBtaXRyZS5vcmcNCj4gPj4gPg0KPiA+PiA+DQo+ID4+ID4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4gPiBtaWxlIG1haWxpbmcg bGlzdA0KPiA+PiA+IG1pbGVAaWV0Zi5vcmcNCj4gPj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL21pbGUNCj4gPj4gPg0KPiA+PiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+PiBtaWxlIG1haWxpbmcgbGlzdA0KPiA+PiBt aWxlQGlldGYub3JnDQo+ID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v bWlsZQ0KPiA+DQo+ID4tLQ0KPiA+S2luZCBSZWdhcmRzLA0KPiA+ZGF2ZQ0KPiA+RGF2aWQgUy4g TWlzZWxsLA0KPiA+MDc3MTAzODAwNDQNCj4gPg0KPiANCj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gbWlsZSBtYWlsaW5nIGxpc3QNCj4gbWlsZUBp ZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21pbGUNCg== From ietf@meetecho.com Tue Aug 7 15:46:22 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F32F21F8668 for ; Tue, 7 Aug 2012 15:46:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.016 X-Spam-Level: X-Spam-Status: No, score=0.016 tagged_above=-999 required=5 tests=[AWL=0.735, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p9kLFJhAM0RC for ; Tue, 7 Aug 2012 15:46:21 -0700 (PDT) Received: from smtplq02.aruba.it (smtplqs-out17.aruba.it [62.149.158.57]) by ietfa.amsl.com (Postfix) with SMTP id 9541B21F8667 for ; Tue, 7 Aug 2012 15:46:19 -0700 (PDT) Received: (qmail 25091 invoked by uid 89); 7 Aug 2012 22:46:17 -0000 Received: from unknown (HELO smtp2.aruba.it) (62.149.158.222) by smtplq02.aruba.it with SMTP; 7 Aug 2012 22:46:17 -0000 Received: (qmail 28667 invoked by uid 89); 7 Aug 2012 22:46:17 -0000 Received: from unknown (HELO ?192.168.1.154?) (alex@meetecho.com@87.11.150.210) by smtp2.ad.aruba.it with ESMTPA; 7 Aug 2012 22:46:17 -0000 Message-ID: <50219AAA.30002@meetecho.com> Date: Wed, 08 Aug 2012 00:46:02 +0200 From: Meetecho IETF support User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: mile@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: smtplq02.aruba.it 1.6.2 0/1000/N Subject: [mile] Meetecho session recording available X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 22:46:22 -0000 Dear all, the full recording (synchronized video, audio, slides and jabber room) of MILE session at IETF-84 is available. You can watch it by accessing the following URL: http://ietf84.conf.meetecho.com/index.php/Recorded_Sessions#IETF84_MILE For the chair(s): please feel free to put the link to the recording in the minutes, if you think this might be useful. In case of problems with the playout, just drop an e-mail to team@meetecho.com. Cheers, the Meetecho team -- Meetecho s.r.l. Web Conferencing and Collaboration Tools www.meetecho.com From sm@resistor.net Tue Aug 7 19:17:32 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8681211E810C for ; Tue, 7 Aug 2012 19:17:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oQfgRXfznHLt for ; Tue, 7 Aug 2012 19:17:28 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 100CA11E80E9 for ; Tue, 7 Aug 2012 19:17:27 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q782HLql000487; Tue, 7 Aug 2012 19:17:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1344392246; bh=yg8pZLny5tBtGmxy34l2mQHKE0O8CwOUIrFNg3p2rPM=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=Rdg/yAWcL6+VrgkxwZUxILx8Y9TM1UeU7Rg2c41cr7DDxzdEfPaX3a8WmrGMKJloc 9WowdT8sXFlA+Tw0+Yo1Bps/yq/zE3VDwaJVLtzJEesh+e4RiBdgfTlPS501zzNP8Z +blTHET43Bf94Z0BGksk6K6JhVfz3AcyJ/5v9zJo= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1344392246; i=@resistor.net; bh=yg8pZLny5tBtGmxy34l2mQHKE0O8CwOUIrFNg3p2rPM=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=0A1shl0nSlGGmSSOCkr/l26sNHtki4c4eCw9Nx+Plet9HSNJBOPPl2blGVnwbVaa7 AXFE3xvSiyOB0xKfpNd6QBKGWbpsm/ABLzFihYGMhsNRk8KyOIJK4fryoNhOOF7h4l lGyBklZVgWi8Fgy9xKZHsWwrGMFEHO5Rqck7fQBM= Message-Id: <6.2.5.6.2.20120807190817.0914eff8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 07 Aug 2012 19:14:26 -0700 To: "Baker, Jon" From: SM In-Reply-To: <6C1C15D8B5510B4B8FF132B10D38651302006510@IMCMBX03.MITRE.OR G> References: <6C1C15D8B5510B4B8FF132B10D38651302006510@IMCMBX03.MITRE.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: mile@ietf.org Subject: Re: [mile] IPR and Transfer Considerations X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 02:17:32 -0000 Hi Jon, At 06:03 07-08-2012, Baker, Jon wrote: >There are a few items that warrant clarifying for the working group >related to MITRE IPR and the standardization efforts MITRE supports. >MITRE holds a trademark and copyright on the various standardization >efforts we support for the sole purpose of ensuring they remain open >and free to use. Applying a copyright and holding a trademark are >the essential tools that are used to ensure the efforts we manage >remain open and free to use. In my review of other organizations >that operate standardization efforts trademark and copyright are >widely used for this purpose. Is it MITRE's position that its copyright, or any other, notice has to be included in draft-ietf-mile-sci-04? Regards, -sm From bakerj@mitre.org Wed Aug 8 05:17:21 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DCC021F8622 for ; Wed, 8 Aug 2012 05:17:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q7f4616Es2w4 for ; Wed, 8 Aug 2012 05:17:20 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id C700221F861D for ; Wed, 8 Aug 2012 05:17:19 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 2F1EB21B1D3B; Wed, 8 Aug 2012 08:17:19 -0400 (EDT) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 1D73021B06F8; Wed, 8 Aug 2012 08:17:19 -0400 (EDT) Received: from IMCMBX03.MITRE.ORG ([169.254.3.146]) by IMCCAS01.MITRE.ORG ([129.83.29.68]) with mapi id 14.02.0309.002; Wed, 8 Aug 2012 08:17:18 -0400 From: "Baker, Jon" To: SM Thread-Topic: [mile] IPR and Transfer Considerations Thread-Index: Ac10nPlvZvn4bwL9Qy2D7OCDEvaANQAbvzCxABNzjDA= Date: Wed, 8 Aug 2012 12:17:18 +0000 Message-ID: <6C1C15D8B5510B4B8FF132B10D386513020107F1@IMCMBX03.MITRE.ORG> References: <6C1C15D8B5510B4B8FF132B10D38651302006510@IMCMBX03.MITRE.ORG> <6.2.5.6.2.20120807190817.0914eff8@resistor.net> In-Reply-To: <6.2.5.6.2.20120807190817.0914eff8@resistor.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.51] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mile@ietf.org" Subject: Re: [mile] IPR and Transfer Considerations X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 12:17:21 -0000 If copyrighted material is used then the copyright notification must be inc= luded. This is mentioned on the terms of use page for each of the efforts w= e support and can be found in the IPR disclosures I posted. If a trademarked name is used then the trademark must be recognized. Take a= look at the NIST publication for SCAP (http://csrc.nist.gov/publications/n= istpubs/800-126-rev2/SP800-126r2.pdf). It includes the following text: "OVAL and CVE are registered trademarks, and CCE, CPE, and OCIL are tradema= rks, of The MITRE Corporation." The document then also includes the registered trademark on the first use o= f OVAL, which occurs in the executive summary section.=20 I would expect something similar in an IETF draft. A colleague of mine poin= ted out that if you do a Google search for "is a registered trademark of" s= ite:ietf.org/rfc/ that you'll come up with plenty of examples of registered= trademarks in RFCs. Thanks, Jon =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Jonathan O. Baker G022 - IA Industry Collaboration The MITRE Corporation Email: bakerj@mitre.org >-----Original Message----- >From: SM [mailto:sm@resistor.net] >Sent: Tuesday, August 07, 2012 10:14 PM >To: Baker, Jon >Cc: mile@ietf.org >Subject: Re: [mile] IPR and Transfer Considerations > >Hi Jon, >At 06:03 07-08-2012, Baker, Jon wrote: >>There are a few items that warrant clarifying for the working group >>related to MITRE IPR and the standardization efforts MITRE supports. >>MITRE holds a trademark and copyright on the various standardization >>efforts we support for the sole purpose of ensuring they remain open >>and free to use. Applying a copyright and holding a trademark are >>the essential tools that are used to ensure the efforts we manage >>remain open and free to use. In my review of other organizations >>that operate standardization efforts trademark and copyright are >>widely used for this purpose. > >Is it MITRE's position that its copyright, or any other, notice has >to be included in draft-ietf-mile-sci-04? > >Regards, >-sm From lnunez@c3isecurity.com Wed Aug 8 09:51:09 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B89721F8762 for ; Wed, 8 Aug 2012 09:51:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.662 X-Spam-Level: X-Spam-Status: No, score=-3.662 tagged_above=-999 required=5 tests=[AWL=-0.064, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ElGDeM8pw-bb for ; Wed, 8 Aug 2012 09:51:05 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id D66BE21F8748 for ; Wed, 8 Aug 2012 09:51:04 -0700 (PDT) Received: by yenm5 with SMTP id m5so1093959yen.31 for ; Wed, 08 Aug 2012 09:51:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=iG82yUYXif8bcl/98r2pROl06e0ARzP7h1klHW+tbY8=; b=La4qZ4hi9OjYK5MaJFi8v2kDzxl8Ehw/AJOEXNEr5RREYPNouO6fIs+gWORIStBlW5 5mQqwD4bwZ4SwIm09Ftb0R2UQyNQTVotSs7IrqL9+sNvy2cfd+/H/dasyKA1/4xbBL9y +3CEwhQMY5b41J4+b6s3Ryb+4D2eA2xnQwbAiggl+8Hq5oFPI9UVr47Teq4clq6v44Rh GI3d7vkdt/OSltkpERjQwTwUzGgpxRg4m3FU4EDvPHbByitbGt5ZUl2dAsBPBq6P/Ore fHw76RG9gW2ZbqIlTNV4524HmzfU22RjsZmZmwAmdQ/nAqx24QIwR9etHABwgr66cqQk Vttw== Received: by 10.236.197.69 with SMTP id s45mr726074yhn.74.1344444664231; Wed, 08 Aug 2012 09:51:04 -0700 (PDT) Received: from [192.168.1.40] (cpe-066-057-081-254.nc.res.rr.com. [66.57.81.254]) by mx.google.com with ESMTPS id w5sm20682654anl.10.2012.08.08.09.51.01 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 08 Aug 2012 09:51:03 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_1B1AB343-8765-4616-A0D2-96CADBEF1F60" From: Luis Nunez In-Reply-To: Date: Wed, 8 Aug 2012 12:50:59 -0400 Message-Id: References: <6905825.18402.1344435730391.JavaMail.root@vms170025> To: "Waltermire, David A." X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQl+UHgLOVCIx/QhckAtIbMMYIrTzHgV0SkjmR6eMkhlHI3Ux5sjrICgYrzs3tUfPOfi984f Cc: Ruben Oliva , mile@ietf.org, sacm@ietf.org Subject: Re: [mile] [sacm] Strategic alignment of security with business in SACM in an international context X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 16:51:09 -0000 --Apple-Mail=_1B1AB343-8765-4616-A0D2-96CADBEF1F60 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I had mention the Cloud Security Matrix (Cloud Security Alliance) in = another thread. 1. is this something we can use as basis for mapping the various = regulations to a common id? 2. Is this SACM or MILE GRC related work? thanks. -ln On Aug 8, 2012, at 12:37 PM, Waltermire, David A. wrote: > The challenge we will likely face in scoping down the effort is that = we might not be able to work on the full stack that supports low-level = data collection, as well as higher level security processes and = controls. This is because we will likely need to charter around a lower = layer of function. This is why we need to scope as part of this work an = architecture document that illustrates how the smaller scope of work = fits into the larger picture that supports alignment with international = compliance models. > =20 > To say it a different way, we need to define a comprehensive picture = of the =93end state=94, even though we may only get part way there based = on an initial SACM charter. > =20 > We can use documents like ISO 27001 as guidance in producing the = architecture document to insure that the end state aligns well with your = concerns below. > =20 > Sincerely, > Dave > =20 > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf = Of david.oliva@verizon.net > Sent: Wednesday, August 08, 2012 10:22 AM > To: lnunez@c3isecurity.com; sacm@ietf.org > Subject: [sacm] Strategic alignment of security with business in SACM = in an international context > =20 > =20 > Luis and all: >=20 > Unless we can demonstrate that the technologies and specifications we = are developing align with the security objectives of international = compliance models (such as ISO 27001) we cannot demonstrate strategic = alignment of business and security objectives in their context.=20 >=20 > Strategic alignment of security objectives with business objectives = can be at least partially joined via SACM thru the SP 800-53 to ISO = 27001 mapping table. If this were to happen to SACM then the validated = products will have less appeal and less marketability. The validated = products will work fine, but they will work with limited capability and = scope. For example, currently validated SCAP 1.0 products do not use = the Open Checklist Interactive Language (OCIL). OCIL is an open = specification (created by the security community for use by anybody, any = developer, any country) that facilitates non-automated assessment of = security processes. OCIL would allow an ISO 27001 compliance assessor = in Germany to create a question =93Does the organization comply ISO/IEC = 27001:2005 para 4.2.2 e) =91Does the organization implement a training = and awareness programme=92=94 and answer =91yes=92 or =91no=92. Then = the results can be accessed and read whether the organization uses = product X or product Y because OCIL is an open security specification. = Another example of OCIL is a rather mundane security function of = universal use. OCIL allows an ISO 27001 security compliance officer to = answer =91yes=92 or =91no=92 to the question =93Is the door shut?=94 and = make the result electronically readable whether he/she uses product X or = product Y. As for business, the flexibility of OCIL allows a company to = create a question =93Did the company reach our 7% profit strategic = objective over the past 10 years?=94 and able to answer it =91yes=92 or = =91no=92 with product X, Y, or Z and ensure interoperability. >=20 > =20 >=20 > David Oliva >=20 > =20 >=20 >=20 > =20 > =20 > On 08/07/12, Luis Nunez wrote: > =20 > Thanks the comment. I am glad someone agrees with me :) > =20 > -ln > =20 > On Aug 7, 2012, at 11:46 AM, david.oliva@verizon.net wrote: >=20 >=20 > Luis and all: > =20 > You are on target. > SACM is not a law enforcement thing, but is a facilitator of legal = issues in association with the protection of private information and = health-related information. >=20 > I think a couple of examples to show how SACM facilitates legal issues = about personal information is in order. >=20 > A SACM configuration scanner is able to monitor the configuration of = security controls as specified in ISO/IEC 27001:2005. This can be = accomplished when tier IV SCAP content is used because the output maps = the finding (compliance or non-compliance) of the scanner to security = control ISO/IEC 27001:2005 paragraph A.10.6.2 =93Security of Network = Services=94. Thus a SACM scanner is able to assist in international = governance compliance about personal information because SP 800-53 maps = to ISO 27001. >=20 > A SACM vulnerability scanner is able to meet compliance with ISO = 27001, para A.12.6.1 =93Control of technical vulnerabilities=94 because = a SACM scanner using SCAP tier IV content can map its output to the ISO = governance. SACM Vulnerability scanning can address aspects of = confidentiality of personal information by identifying software = vulnerabilities of the databases that house them, and do it in the = context of an international set of security standards. >=20 > =20 > David Oliva > =20 > =20 > =20 > On 08/06/12, Luis Nunez wrote: > =20 > Looking at it another way I could see security automation as a way to = discover if a system is configured to meet privacy policies . =20 > =20 > Security automation is an enabler for transparency so that = individuals and organizations may understand the complex computing = environment. > =20 > Thanks for bring up this issue. As a community we may want to look at = building content around privacy controls. > =20 > -ln > =20 > On Aug 6, 2012, at 12:42 PM, wrote: >=20 >=20 > None of the efforts we are talking about for SACM are targeted toward = PII or individuals. They are targeted at the configuration of the = platforms deployed in the enterprise to assure they comply with the = site's security policy. PII is not collected. This is not monitoring of = individual or employee actions. I am not a lawyer and will not speak as = one. We will let the lawyer's decide at the appropriate time. > =20 > Kent Landfield >=20 > McAfee | An Intel Company > Direct: +1.972.963.7096=20 > Mobile: +1.817.637.8026 > Web: www.mcafee.com > =20 > From: Martin Rex > Reply-To: "mrex@sap.com" > Date: Monday, August 6, 2012 11:32 AM > To: "tony@yaanatech.com" > Cc: "mrex@sap.com" , "sacm@ietf.org" > Subject: Re: [sacm] Legal aspects of System monitoring > =20 > Tony Rutkowski wrote: > Martin Rex wrote: > =20 > In Germany, an employer monitoring a company-owned PC that an employee = uses > for communication (EMail, VoiP, IM) would be unconditionally illegal. > =20 > Really? > =20 > No kidding! > =20 > =20 > =20 > That is not consistent with comments > I've seen concerning German law. > =20 > There is a significant amount of mis-information floating the = internet. > And a mindboggling large number of lawyers are making wild guesses, = rather > that doing research. > =20 > The decisions of the german federal constitional court (GFCC) have = been > quite consistent over the past decade about what with respect to > encroaching on the general right of personality, informational > self-determination, freedom of conduct and created a "fundamental = right > to the guarantee of the integrity and confidentiality of information > technology systems". The court has set the minimum requirements that > are prerequisite to such encroachment, such as the prerequisite of a > clear formal statute law, which needs to be limited to situation where > real facts create probable cause. > =20 > The original GFCC decision in german language is quite comprehensible > (to me, at least), while I'm having some difficulties understanding > the english translation (and the english translation is shorter!?). > =20 > BVerfG-Entscheidung "1 BvR 370/07 vom 27.2.2008" Randnummer 196- > http://www.bverfg.de/entscheidungen/rs20080227_1bvr037007.html#abs196 > =20 > english translation of "1 BvR 370/07 vom 27.2.2008" > = http://www.bverfg.de/entscheidungen/rs20080227_1bvr037007en.html#abs130 > =20 > =20 > To be *unconditionally* illegal, would > preclude almost any rationally required > maintenance or threat mitigation. > =20 > It is possible to perform maintenance and threat mitigation entirely > without "monitoring" systems. > =20 > A mere threat is insufficient for monitoring, if that involves = collecting > PII data, i.e. data from which a persons conduct can be infered. > =20 > =20 > =20 > It is fair to observe that recent German > Constitutional Court decisions impose > constraints, but they certainly are > not "unconditional." > =20 > One of the prerequisite is a clear formal statute law, > which currently does not exist for the purposes "sacm" is about. > =20 > quoting from the above GFCC decision: > =20 > 2. The fundamental right to the guarantee of the confidentiality and > integrity of information technology systems is not unrestricted. > Encroachments may be justified both for preventive purposes, and for > criminal prosecution. The individual must only accept such = restrictions > of his or her right which are based on a statutory foundation that > is constitutional. > =20 > =20 > This currently makes collecting data about peoples conduct = "unconditionally" > illegal for most practical purposes (exempting from prosecution only > individual occasions of justified self-defence against an imminent > vicious attack based on real facts that create probable cause). > =20 > This applies to all surveillance that impairs persons "freedom of = conduct". > The majority of past decisions of specific events was about = surveillance > with a camera, but the GFCC decision makes it crystal clear that > this applies to *any* kind of surveillance. Different to monitoring = of > computer systems, there is statutory law for camera surveillance, > that allows optical surveillance under certain conditions > (Art. 6b BDSG "BundesDatenSchutzGesetz). > =20 > The lack of a formal statutory foundation makes surveillance illegal > and entitles subjects to "cease and desist" rulings and sometimes > damages. > =20 > In one more recent (and constitutionally correct) rulings, an employer > had put up a camera that had in view not only the entrance door, but > also two workplaces. The employees protested against this camera, > but the employer would not "fix" it, so at least one employee sued, > The court confirmed that this camera surveillance at the workplace > was illegal due to its chilling effect alone, and since it had been > installed for a whole year, the employee was arwarded 4 month of = income > as damages (for the chilling effect). > =20 > Another recent decision was about evidence from a covert video > surveillance showing an employee taking a package of cigarettes > on two occasions, where the German Federal Labour Court > (the supreme court for labor related issues) remanded the decision > to the trial court because it had failed to establish whether the > covert video surveillance really met all constitutional prerequisites > otherwise the video surveillance would have been illegal and not > be admissible as evidence in court. > (German decision: http://lexetius.com/2012,2351) > =20 > The German Federal Constitional Court neutered numerous laws during = the > last decade due to lack of clarity and/or overbroad encroachment of > the personal right of self-determination and the right to = confidentiality > of telecommunications. > =20 > See also the GFCC decision about the scanning of license plates > (the decision 1 BvR 2074/05 vom 11.3.2008 in german) > http://www.bverfg.de/entscheidungen/rs20080311_1bvr2-07405.html > =20 > where it confirmed that data collection requires formal statue law, > and that the law in question wasn't limited to probable cause and > therefore unconstitutional. > =20 > =20 > The only currently existing formal statue law in Germany, that could = be > used in some limited fashion for "Monitoring" is Art.100 TKG, > http://www.gesetze-im-internet.de/tkg_2004/__100.html > but that statue is clearly limited in purpose, it will not allow that = data > to be used for automatic surveillance of "employee conduct" with = respect > to "company-defined policies". Employers try hard to avoid TKG for = their > networks (for which they will have to formally register), but that = also > means that they do not have a formal statutory law for performing any > kind of surveillance/monitoring as described in Art. 100 TKG for = systems > that are used by employees for telecommunications and a significant = part > of their daily activies. > =20 > =20 > -Martin > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > =20 > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > =20 > =20 >=20 > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm --Apple-Mail=_1B1AB343-8765-4616-A0D2-96CADBEF1F60 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I had mention the Cloud Security Matrix (Cloud = Security Alliance) in another thread.
1. is this something we can = use as basis for mapping the various regulations to a common = id?
2. Is this SACM or MILE GRC related = work?

thanks.
-ln

On Aug 8, 2012, at 12:37 PM, Waltermire, David A. wrote:

The = challenge we will likely face in scoping down the effort is that we = might not be able to work on the full stack that supports low-level data = collection, as well as higher level security processes and = controls.  This is because we will likely need to charter around a = lower layer of function.  This is why we need to scope as part of = this work an architecture document that illustrates how the smaller = scope of work fits into the larger picture that supports alignment with = international compliance models.
To = say it a different way, we need to define a comprehensive picture of the = =93end state=94, even though we may only get part way there based on an = initial SACM charter.
 
We can use documents like ISO = 27001 as guidance in producing the architecture document to insure that = the end state aligns well with your concerns = below.
Dave
 
From: sacm-bounces@ietf.org = [mailto:sacm-bounces@ietf.org] On Behalf Of david.oliva@verizon.net
= Sent: Wednesday, = August 08, 2012 10:22 AM
To: lnunez@c3isecurity.com; = sacm@ietf.org
Subject: [sacm] Strategic alignment = of security with business in SACM in an international = context
 

David Oliva

On 08/07/12, Luis = Nunez<lnunez@c3isecurity.com> = wrote:
On Aug 7, 2012, at = 11:46 AM, david.oliva@verizon.net wrote:
SACM is not a law enforcement thing, but is = a facilitator of legal issues in association with the protection of = private information and health-related information.

A SACM = configuration scanner is able to monitor the configuration of security = controls as specified in ISO/IEC 27001:2005.  This can be = accomplished when tier IV SCAP content is used because the output maps = the finding (compliance or non-compliance) of the scanner to security = control ISO/IEC 27001:2005 paragraph A.10.6.2 =93Security of Network = Services=94.  Thus a SACM scanner is able to assist in = international governance compliance about personal information because = SP 800-53 maps to ISO 27001.A SACM vulnerability scanner is = able to meet compliance with ISO 27001, para A.12.6.1 =93Control of = technical vulnerabilities=94 because a SACM scanner using SCAP tier IV = content can map its output to the ISO governance.  SACM = Vulnerability scanning can address aspects of confidentiality of = personal information by identifying software vulnerabilities of the = databases that house them, and do it in the context of an international = set of security standards.David = OlivaOn 08/06/12, Luis = Nunez<On Aug 6, 2012, at = 12:42 PM, <None of the efforts we = are talking about for SACM are targeted toward PII or individuals. They = are targeted at the configuration of the platforms deployed in the = enterprise to assure they comply with the site's security policy. =  PII is not collected. This is not monitoring of individual or = employee actions.  I am not a lawyer and will not speak as one. We = will let the lawyer's decide at the appropriate = time.

Tony Rutkowski = wrote:
Martin Rex = wrote:
In Germany, an employer monitoring a = company-owned PC that an employee = uses
for communication (EMail, VoiP, IM) would be unconditionally = illegal.
No = kidding!
 
That is not consistent with = comments
I've seen concerning German = law.
There is a significant amount of = mis-information floating the = internet.
And a mindboggling large number of lawyers are = making wild guesses, rather
that doing = research.
 
The decisions of the = german federal constitional court (GFCC) have = been
quite consistent over the past decade about what with respect = to
encroaching on the general right of personality, = informational
self-determination, freedom of conduct and = created a "fundamental right
to the guarantee of the = integrity and confidentiality of = information
technology systems".  The court has = set the minimum requirements that
are prerequisite to such = encroachment, such as the prerequisite of = a
clear formal statute law, which needs to be limited to = situation where
real facts create = probable cause.
The original GFCC decision in german language = is quite comprehensible
(to me, at least), while = I'm having some difficulties = understanding
the english translation (and the english = translation is shorter!?).
BVerfG-Entscheidung "1 BvR 370/07 vom = 27.2.2008" Randnummer 196-
sacm@ietf.org
, "David.Misell@bcs.org" , Sean Turner Thread-Topic: [mile] IPR and Transfer Considerations Thread-Index: Ac10nPlvZvn4bwL9Qy2D7OCDEvaANQAQjZXwACtneYA= Date: Wed, 8 Aug 2012 17:39:46 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [172.16.97.202] x-exclaimer-md-config: 79afcaa7-fdf4-4fa6-abe0-afeaa4640a4f Content-Type: text/plain; charset="us-ascii" Content-ID: <66B30765230E3C4A8DD071C558A52A72@tripwire.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CRA-Verdict: 174.47.84.216$juniper.net%12218%2%tripwire.com%True%True%0$ X-OriginatorOrg: tripwire.com Cc: "mile@ietf.org" , "dennis.groves@owasp.org" Subject: Re: [mile] IPR and Transfer Considerations X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 17:39:56 -0000 On 8/7/12 1:58 PM, "Stephen Hanna" wrote: >I found the MITRE IPR disclosures. They're not linked to MILE in the >IETF's IPR disclosure tool. Here's a URL that you can use to find them: > >http://datatracker.ietf.org/ipr/search/?option=3Dpatent_search&patent_sear= ch >=3Dmitre > >Now I'll go do some studying of them... Steve, I've looked at those entries and something eludes me. They all reference "patents." But, it seems that it *could* be that the wording uses "Patent" as a generic term to include trademarks and copyrights (for example, section 1 is worded as follows: "Patent Holder/Applicant ('Patent Holder')"). Just an honest question here, but if we're concerned about copyright/trademark issues, why are the IPR disclosures in terms of patents? From lnunez@c3isecurity.com Wed Aug 8 14:48:10 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93DA621F85CE for ; Wed, 8 Aug 2012 14:48:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.503 X-Spam-Level: X-Spam-Status: No, score=-3.503 tagged_above=-999 required=5 tests=[AWL=-0.204, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ETYv0uVnlAHu for ; Wed, 8 Aug 2012 14:48:10 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id D955321F8585 for ; Wed, 8 Aug 2012 14:48:09 -0700 (PDT) Received: by yhq56 with SMTP id 56so1449926yhq.31 for ; Wed, 08 Aug 2012 14:48:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=fhTMlV3SsJYiGbiczayCj3TpHl/mml4uzC37aq/6tZI=; b=D6WYZcJEOZzv46qxFEIzECUN7UIUVUR9gKZfyt/KEQ4Z/d2lrTmenvLoR+sJKd1fWr eOwQYJNDoLllw0QHeObo6Jklm7kpbLjNqnQamxGdCzTetsfCJGxJPIJTnkIn/sOm4ry7 8QCq1hsWG1jPrGGU6EbM3NPU+ABG8yHTy8gvy88KdOUDAUxpAz9A05OKxMrP+wxyjUfE Rg6Ilx1AHi+AYCvEvEPCpyxS/UncYBNaw8G84dm9VofNI7tJjzVaTHUfGacaZNKMXLLL JG3FAzKGZHxpAq/+4rFu/A8RRgfNAw9uOtkd4Lr8j9GrRXLvgdAb6bFIgO/LUPCI4VnM 4V0g== Received: by 10.236.155.234 with SMTP id j70mr18158309yhk.124.1344462489439; Wed, 08 Aug 2012 14:48:09 -0700 (PDT) Received: from [192.168.1.46] (cpe-066-057-081-254.nc.res.rr.com. [66.57.81.254]) by mx.google.com with ESMTPS id d66sm44285757yhe.1.2012.08.08.14.48.07 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 08 Aug 2012 14:48:08 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Luis Nunez In-Reply-To: <13907973c00.7901413989719813492.-7814053128682371062@netfrontiers.com> Date: Wed, 8 Aug 2012 17:48:07 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <5AB51D51-9781-4056-BAA9-86332F30D22E@c3isecurity.com> References: <13907973c00.7901413989719813492.-7814053128682371062@netfrontiers.com> To: dcougias@netfrontiers.com X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQk1FT/kzuaPccIWv5LXXW62zB3+jOVq2YJ6+JNRWToX1oZfWOgN7ObT8r3SVUvk4fohCFvO Cc: Ruben Oliva , mile@ietf.org, sacm@ietf.org Subject: Re: [mile] =?iso-8859-1?q?=5Bsacm=5D_Strategic_alignment_of_security_?= =?iso-8859-1?q?with_business_in_SACM_in=A0=A0=A0=A0an_international_conte?= =?iso-8859-1?q?xt?= X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 21:48:10 -0000 I would be interested in reviewing a copy. BTW are there any IPR attached to the UCF document. Thanks dorian. -ln On Aug 8, 2012, at 2:55 PM, Dorian Cougias wrote: > The UCF will provide a common mapping for you, with unique and = persistent IDs. >=20 > I can provide UCF spreadsheets to those of you who need them. >=20 >=20 >=20 > Dorian J. Cougias > Compliance Scientist > Unified Compliance Framework >=20 From turners@ieca.com Wed Aug 8 17:08:53 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EDC121F864A for ; Wed, 8 Aug 2012 17:08:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.112 X-Spam-Level: X-Spam-Status: No, score=-102.112 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nj-gz2Lj5TW8 for ; Wed, 8 Aug 2012 17:08:52 -0700 (PDT) Received: from gateway14.websitewelcome.com (gateway14.websitewelcome.com [67.18.21.25]) by ietfa.amsl.com (Postfix) with ESMTP id D22C221F8650 for ; Wed, 8 Aug 2012 17:08:50 -0700 (PDT) Received: by gateway14.websitewelcome.com (Postfix, from userid 5007) id 67E54D4F9B660; Wed, 8 Aug 2012 19:08:50 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway14.websitewelcome.com (Postfix) with ESMTP id 52362D4F9B603 for ; Wed, 8 Aug 2012 19:08:50 -0500 (CDT) Received: from [108.18.174.220] (port=59897 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1SzGIz-0004M3-5o; Wed, 08 Aug 2012 19:08:49 -0500 Message-ID: <5022FF8F.1080206@ieca.com> Date: Wed, 08 Aug 2012 20:08:47 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Adam Montville References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [108.18.174.220]:59897 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 8 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: "mile@ietf.org" , "dennis.groves@owasp.org" Subject: Re: [mile] IPR and Transfer Considerations X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 00:08:53 -0000 On 8/8/12 1:39 PM, Adam Montville wrote: > On 8/7/12 1:58 PM, "Stephen Hanna" wrote: > >> I found the MITRE IPR disclosures. They're not linked to MILE in the >> IETF's IPR disclosure tool. Here's a URL that you can use to find them: >> >> http://datatracker.ietf.org/ipr/search/?option=patent_search&patent_search >> =mitre >> >> Now I'll go do some studying of them... > > > Steve, I've looked at those entries and something eludes me. They all > reference "patents." But, it seems that it *could* be that the wording > uses "Patent" as a generic term to include trademarks and copyrights (for > example, section 1 is worded as follows: "Patent Holder/Applicant ('Patent > Holder')"). > > Just an honest question here, but if we're concerned about > copyright/trademark issues, why are the IPR disclosures in terms of > patents? I think this stems from the way the IPR disclosure page is set up. You can disclose any kind of IPR: patents, trademarks, copyrights, etc. spt From david.waltermire@nist.gov Thu Aug 9 06:06:39 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62E6021F86C8; Thu, 9 Aug 2012 06:06:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.034 X-Spam-Level: X-Spam-Status: No, score=-6.034 tagged_above=-999 required=5 tests=[AWL=-0.388, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BAD_LINEBREAK=0.5, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GJhmReWHhCSn; Thu, 9 Aug 2012 06:06:34 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 7529321F8687; Thu, 9 Aug 2012 06:06:33 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 9 Aug 2012 09:06:24 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Thu, 9 Aug 2012 09:06:31 -0400 From: "Waltermire, David A." To: "'david.oliva@verizon.net'" , "'dcougias@netfrontiers.com'" , "'lnunez@c3isecurity.com'" Date: Thu, 9 Aug 2012 09:05:05 -0400 Thread-Topic: =?utf-8?B?UmU6IFtzYWNtXSBTdHJhdGVnaWMgYWxpZ25tZW50IG9mIHNlY3VyaXR5IHc=?= =?utf-8?B?aXRoIGJ1c2luZXNzIGluIFNBQ00gaW7CoMKgwqDCoGFuIGludGVybmF0aW9u?= =?utf-8?B?YWwgY29udGV4dA==?= Thread-Index: Ac12LmGvLHtvzMKtTl6y2SOAWBZV3wAATaxu Message-ID: In-Reply-To: <23623150.93912.1344517069256.JavaMail.root@vms170025> 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_D7A0423E5E193F40BE6E94126930C4930B9F5B7E79MBCLUSTERxcha_" MIME-Version: 1.0 Cc: "'mile@ietf.org'" , "'sacm@ietf.org'" Subject: Re: [mile] =?utf-8?q?=5Bsacm=5D_Strategic_alignment_of_security_with_?= =?utf-8?q?business_in_SACM_in=C2=A0=C2=A0=C2=A0=C2=A0an_international_con?= =?utf-8?q?text?= X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 13:06:39 -0000 --_000_D7A0423E5E193F40BE6E94126930C4930B9F5B7E79MBCLUSTERxcha_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTogZGF2aWQub2xpdmFA dmVyaXpvbi5uZXQgPGRhdmlkLm9saXZhQHZlcml6b24ubmV0Pg0KVG86IGRjb3VnaWFzQG5ldGZy b250aWVycy5jb20gPGRjb3VnaWFzQG5ldGZyb250aWVycy5jb20+OyBsbnVuZXpAYzNpc2VjdXJp dHkuY29tIDxsbnVuZXpAYzNpc2VjdXJpdHkuY29tPg0KQ2M6IFdhbHRlcm1pcmUsIERhdmlkIEEu OyBkYXZpZC5vbGl2YUB2ZXJpem9uLm5ldCA8ZGF2aWQub2xpdmFAdmVyaXpvbi5uZXQ+OyBtaWxl QGlldGYub3JnIDxtaWxlQGlldGYub3JnPjsgc2FjbUBpZXRmLm9yZyA8c2FjbUBpZXRmLm9yZz4N ClNlbnQ6IFRodSBBdWcgMDkgMDg6NTc6NDkgMjAxMg0KU3ViamVjdDogUmU6IFJlOiBbc2FjbV0g U3RyYXRlZ2ljIGFsaWdubWVudCBvZiBzZWN1cml0eSB3aXRoIGJ1c2luZXNzIGluIFNBQ00gaW4g ICAgYW4gaW50ZXJuYXRpb25hbCBjb250ZXh0DQoNClBoZW5vbWVuYWwhDQoNCkNhbiB5b3UgcGxl YXNlIHNlbmQgbWUgKHVzKSBvbmU/DQoNCkRhdmlkIE9saXZhDQoNCg0KT24gMDgvMDgvMTIsIERv cmlhbiBDb3VnaWFzPGRjb3VnaWFzQG5ldGZyb250aWVycy5jb20+IHdyb3RlOg0KDQpUaGUgVUNG IHdpbGwgcHJvdmlkZSBhIGNvbW1vbiBtYXBwaW5nIGZvciB5b3UsIHdpdGggdW5pcXVlIGFuZCBw ZXJzaXN0ZW50IElEcy4NCg0KSSBjYW4gcHJvdmlkZSBVQ0Ygc3ByZWFkc2hlZXRzIHRvIHRob3Nl IG9mIHlvdSB3aG8gbmVlZCB0aGVtLg0KDQoNCg0KRG9yaWFuIEouIENvdWdpYXMNCkNvbXBsaWFu Y2UgU2NpZW50aXN0DQpVbmlmaWVkIENvbXBsaWFuY2UgRnJhbWV3b3JrDQoNCg== --_000_D7A0423E5E193F40BE6E94126930C4930B9F5B7E79MBCLUSTERxcha_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGRpdj48Zm9udCBzaXplPTIgY29sb3I9bmF2eSBmYWNlPUFyaWFsPg0KSTwvZm9udD48L2Rpdj4N Cjxicj48ZGl2PjxociBzaXplPTIgd2lkdGg9IjEwMCUiIGFsaWduPWNlbnRlciB0YWJpbmRleD0t MT4NCjxmb250IGZhY2U9VGFob21hIHNpemU9Mj4NCjxiPkZyb208L2I+OiBkYXZpZC5vbGl2YUB2 ZXJpem9uLm5ldCAmbHQ7ZGF2aWQub2xpdmFAdmVyaXpvbi5uZXQmZ3Q7DTxicj48Yj5UbzwvYj46 IGRjb3VnaWFzQG5ldGZyb250aWVycy5jb20gJmx0O2Rjb3VnaWFzQG5ldGZyb250aWVycy5jb20m Z3Q7OyBsbnVuZXpAYzNpc2VjdXJpdHkuY29tICZsdDtsbnVuZXpAYzNpc2VjdXJpdHkuY29tJmd0 Ow08YnI+PGI+Q2M8L2I+OiBXYWx0ZXJtaXJlLCBEYXZpZCBBLjsgZGF2aWQub2xpdmFAdmVyaXpv bi5uZXQgJmx0O2RhdmlkLm9saXZhQHZlcml6b24ubmV0Jmd0OzsgbWlsZUBpZXRmLm9yZyAmbHQ7 bWlsZUBpZXRmLm9yZyZndDs7IHNhY21AaWV0Zi5vcmcgJmx0O3NhY21AaWV0Zi5vcmcmZ3Q7DTxi cj48Yj5TZW50PC9iPjogVGh1IEF1ZyAwOSAwODo1Nzo0OSAyMDEyPGJyPjxiPlN1YmplY3Q8L2I+ OiBSZTogUmU6IFtzYWNtXSBTdHJhdGVnaWMgYWxpZ25tZW50IG9mIHNlY3VyaXR5IHdpdGggYnVz aW5lc3MgaW4gU0FDTSBpbsKgwqDCoMKgYW4gaW50ZXJuYXRpb25hbCBjb250ZXh0DTxicj48L2Zv bnQ+PGJyPjwvZGl2Pg0KPGRpdiBzdHlsZT0iRk9OVC1GQU1JTFk6IEFyaWFsOyBDT0xPUjogIzAw MDAwMDsgRk9OVC1TSVpFOiAxMnB4Ij48RElWPlBoZW5vbWVuYWwhPC9ESVY+PERJVj4mbmJzcDs8 L0RJVj48RElWPkNhbiB5b3UgcGxlYXNlIHNlbmQgbWUgKHVzKSBvbmU/PC9ESVY+PERJVj4mbmJz cDs8L0RJVj48RElWPkRhdmlkIE9saXZhPC9ESVY+PERJVj4mbmJzcDs8L0RJVj48RElWPiZuYnNw OzwvRElWPjxESVYgc3R5bGU9Ik1BUkdJTjogNXB4IDBweDsgQk9SREVSLVRPUDogI2JjYmNiYyAx cHggc29saWQiPjwvRElWPjxTUEFOIHN0eWxlPSJGT05ULUZBTUlMWTogYXJpYWw7IENPTE9SOiAj MDAwMDAwOyBGT05ULVNJWkU6IDEycHgiPk9uIDA4LzA4LzEyLCA8U1BBTj5Eb3JpYW4gQ291Z2lh cyZsdDtkY291Z2lhc0BuZXRmcm9udGllcnMuY29tJmd0OzwvU1BBTj4gd3JvdGU6PC9TUEFOPjxE SVY+Jm5ic3A7PC9ESVY+PERJViBzdHlsZT0iRk9OVC1GQU1JTFk6IGFyaWFsOyBDT0xPUjogIzAw MDAwMDsgRk9OVC1TSVpFOiAxMnB4Ij5UaGUgVUNGIHdpbGwgcHJvdmlkZSBhIGNvbW1vbiBtYXBw aW5nIGZvciB5b3UsIHdpdGggdW5pcXVlIGFuZCBwZXJzaXN0ZW50IElEcy48QlI+PEJSPkkgY2Fu IHByb3ZpZGUgVUNGIHNwcmVhZHNoZWV0cyB0byB0aG9zZSBvZiB5b3Ugd2hvIG5lZWQgdGhlbS48 QlI+PEJSPjxESVY+PEJSPjwvRElWPjxESVY+PEJSPjwvRElWPjxESVY+RG9yaWFuIEouIENvdWdp YXM8L0RJVj48RElWPkNvbXBsaWFuY2UgU2NpZW50aXN0PC9ESVY+PERJVj5VbmlmaWVkIENvbXBs aWFuY2UgRnJhbWV3b3JrPC9ESVY+PEJSPjwvRElWPjwvZGl2Pg0K --_000_D7A0423E5E193F40BE6E94126930C4930B9F5B7E79MBCLUSTERxcha_-- From david.waltermire@nist.gov Thu Aug 9 06:08:24 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C81A21F86D6; Thu, 9 Aug 2012 06:08:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.02 X-Spam-Level: X-Spam-Status: No, score=-6.02 tagged_above=-999 required=5 tests=[AWL=-0.374, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BAD_LINEBREAK=0.5, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MnE+emBCcL37; Thu, 9 Aug 2012 06:08:23 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 0557E21F86C8; Thu, 9 Aug 2012 06:08:22 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 9 Aug 2012 09:08:13 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Thu, 9 Aug 2012 09:08:20 -0400 From: "Waltermire, David A." To: "'david.oliva@verizon.net'" , "'dcougias@netfrontiers.com'" , "'lnunez@c3isecurity.com'" Date: Thu, 9 Aug 2012 09:06:53 -0400 Thread-Topic: =?utf-8?B?UmU6IFtzYWNtXSBTdHJhdGVnaWMgYWxpZ25tZW50IG9mIHNlY3VyaXR5IHc=?= =?utf-8?B?aXRoIGJ1c2luZXNzIGluIFNBQ00gaW7CoMKgwqDCoGFuIGludGVybmF0aW9u?= =?utf-8?B?YWwgY29udGV4dA==?= Thread-Index: Ac12LmGvLHtvzMKtTl6y2SOAWBZV3wAAXcIv Message-ID: In-Reply-To: <23623150.93912.1344517069256.JavaMail.root@vms170025> 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_D7A0423E5E193F40BE6E94126930C4930B9F5B7E7AMBCLUSTERxcha_" MIME-Version: 1.0 Cc: "'mile@ietf.org'" , "'sacm@ietf.org'" Subject: Re: [mile] =?utf-8?q?=5Bsacm=5D_Strategic_alignment_of_security_with_?= =?utf-8?q?business_in_SACM_in=C2=A0=C2=A0=C2=A0=C2=A0an_international_con?= =?utf-8?q?text?= X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 13:08:24 -0000 --_000_D7A0423E5E193F40BE6E94126930C4930B9F5B7E7AMBCLUSTERxcha_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U29ycnkuIEZhdCBmaW5nZXJlZCBzZW5kLiBJdCBtaWdodCBiZSBiZXN0IHRvIGtlZXAgYW55IGNv cHlyaWdodGVkIG1hdGVyaWFsIG9mZiB0aGUgbGlzdCwgdW5sZXNzIGl0IGlzIGJlaW5nIGNvbnRy aWJ1dGVkIHRvIHRoZSBJRVRGIGFzIGFuIEkvRC4NCg0KVGhhbmtzLA0KRGF2ZQ0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTogZGF2aWQub2xpdmFAdmVyaXpvbi5uZXQg PGRhdmlkLm9saXZhQHZlcml6b24ubmV0Pg0KVG86IGRjb3VnaWFzQG5ldGZyb250aWVycy5jb20g PGRjb3VnaWFzQG5ldGZyb250aWVycy5jb20+OyBsbnVuZXpAYzNpc2VjdXJpdHkuY29tIDxsbnVu ZXpAYzNpc2VjdXJpdHkuY29tPg0KQ2M6IFdhbHRlcm1pcmUsIERhdmlkIEEuOyBkYXZpZC5vbGl2 YUB2ZXJpem9uLm5ldCA8ZGF2aWQub2xpdmFAdmVyaXpvbi5uZXQ+OyBtaWxlQGlldGYub3JnIDxt aWxlQGlldGYub3JnPjsgc2FjbUBpZXRmLm9yZyA8c2FjbUBpZXRmLm9yZz4NClNlbnQ6IFRodSBB dWcgMDkgMDg6NTc6NDkgMjAxMg0KU3ViamVjdDogUmU6IFJlOiBbc2FjbV0gU3RyYXRlZ2ljIGFs aWdubWVudCBvZiBzZWN1cml0eSB3aXRoIGJ1c2luZXNzIGluIFNBQ00gaW4gICAgYW4gaW50ZXJu YXRpb25hbCBjb250ZXh0DQoNClBoZW5vbWVuYWwhDQoNCkNhbiB5b3UgcGxlYXNlIHNlbmQgbWUg KHVzKSBvbmU/DQoNCkRhdmlkIE9saXZhDQoNCg0KT24gMDgvMDgvMTIsIERvcmlhbiBDb3VnaWFz PGRjb3VnaWFzQG5ldGZyb250aWVycy5jb20+IHdyb3RlOg0KDQpUaGUgVUNGIHdpbGwgcHJvdmlk ZSBhIGNvbW1vbiBtYXBwaW5nIGZvciB5b3UsIHdpdGggdW5pcXVlIGFuZCBwZXJzaXN0ZW50IElE cy4NCg0KSSBjYW4gcHJvdmlkZSBVQ0Ygc3ByZWFkc2hlZXRzIHRvIHRob3NlIG9mIHlvdSB3aG8g bmVlZCB0aGVtLg0KDQoNCg0KRG9yaWFuIEouIENvdWdpYXMNCkNvbXBsaWFuY2UgU2NpZW50aXN0 DQpVbmlmaWVkIENvbXBsaWFuY2UgRnJhbWV3b3JrDQoNCg== --_000_D7A0423E5E193F40BE6E94126930C4930B9F5B7E7AMBCLUSTERxcha_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGRpdj48Zm9udCBzaXplPTIgY29sb3I9bmF2eSBmYWNlPUFyaWFsPg0KU29ycnkuICBGYXQgZmlu Z2VyZWQgc2VuZC4gIEl0IG1pZ2h0IGJlIGJlc3QgdG8ga2VlcCBhbnkgY29weXJpZ2h0ZWQgbWF0 ZXJpYWwgb2ZmIHRoZSBsaXN0LCB1bmxlc3MgaXQgaXMgYmVpbmcgY29udHJpYnV0ZWQgdG8gdGhl IElFVEYgYXMgYW4gSS9ELjxicj48YnI+VGhhbmtzLDxicj5EYXZlPC9mb250PjwvZGl2Pg0KPGJy PjxkaXY+PGhyIHNpemU9MiB3aWR0aD0iMTAwJSIgYWxpZ249Y2VudGVyIHRhYmluZGV4PS0xPg0K PGZvbnQgZmFjZT1UYWhvbWEgc2l6ZT0yPg0KPGI+RnJvbTwvYj46IGRhdmlkLm9saXZhQHZlcml6 b24ubmV0ICZsdDtkYXZpZC5vbGl2YUB2ZXJpem9uLm5ldCZndDsNPGJyPjxiPlRvPC9iPjogZGNv dWdpYXNAbmV0ZnJvbnRpZXJzLmNvbSAmbHQ7ZGNvdWdpYXNAbmV0ZnJvbnRpZXJzLmNvbSZndDs7 IGxudW5lekBjM2lzZWN1cml0eS5jb20gJmx0O2xudW5lekBjM2lzZWN1cml0eS5jb20mZ3Q7DTxi cj48Yj5DYzwvYj46IFdhbHRlcm1pcmUsIERhdmlkIEEuOyBkYXZpZC5vbGl2YUB2ZXJpem9uLm5l dCAmbHQ7ZGF2aWQub2xpdmFAdmVyaXpvbi5uZXQmZ3Q7OyBtaWxlQGlldGYub3JnICZsdDttaWxl QGlldGYub3JnJmd0Ozsgc2FjbUBpZXRmLm9yZyAmbHQ7c2FjbUBpZXRmLm9yZyZndDsNPGJyPjxi PlNlbnQ8L2I+OiBUaHUgQXVnIDA5IDA4OjU3OjQ5IDIwMTI8YnI+PGI+U3ViamVjdDwvYj46IFJl OiBSZTogW3NhY21dIFN0cmF0ZWdpYyBhbGlnbm1lbnQgb2Ygc2VjdXJpdHkgd2l0aCBidXNpbmVz cyBpbiBTQUNNIGluwqDCoMKgwqBhbiBpbnRlcm5hdGlvbmFsIGNvbnRleHQNPGJyPjwvZm9udD48 YnI+PC9kaXY+DQo8ZGl2IHN0eWxlPSJGT05ULUZBTUlMWTogQXJpYWw7IENPTE9SOiAjMDAwMDAw OyBGT05ULVNJWkU6IDEycHgiPjxESVY+UGhlbm9tZW5hbCE8L0RJVj48RElWPiZuYnNwOzwvRElW PjxESVY+Q2FuIHlvdSBwbGVhc2Ugc2VuZCBtZSAodXMpIG9uZT88L0RJVj48RElWPiZuYnNwOzwv RElWPjxESVY+RGF2aWQgT2xpdmE8L0RJVj48RElWPiZuYnNwOzwvRElWPjxESVY+Jm5ic3A7PC9E SVY+PERJViBzdHlsZT0iTUFSR0lOOiA1cHggMHB4OyBCT1JERVItVE9QOiAjYmNiY2JjIDFweCBz b2xpZCI+PC9ESVY+PFNQQU4gc3R5bGU9IkZPTlQtRkFNSUxZOiBhcmlhbDsgQ09MT1I6ICMwMDAw MDA7IEZPTlQtU0laRTogMTJweCI+T24gMDgvMDgvMTIsIDxTUEFOPkRvcmlhbiBDb3VnaWFzJmx0 O2Rjb3VnaWFzQG5ldGZyb250aWVycy5jb20mZ3Q7PC9TUEFOPiB3cm90ZTo8L1NQQU4+PERJVj4m bmJzcDs8L0RJVj48RElWIHN0eWxlPSJGT05ULUZBTUlMWTogYXJpYWw7IENPTE9SOiAjMDAwMDAw OyBGT05ULVNJWkU6IDEycHgiPlRoZSBVQ0Ygd2lsbCBwcm92aWRlIGEgY29tbW9uIG1hcHBpbmcg Zm9yIHlvdSwgd2l0aCB1bmlxdWUgYW5kIHBlcnNpc3RlbnQgSURzLjxCUj48QlI+SSBjYW4gcHJv dmlkZSBVQ0Ygc3ByZWFkc2hlZXRzIHRvIHRob3NlIG9mIHlvdSB3aG8gbmVlZCB0aGVtLjxCUj48 QlI+PERJVj48QlI+PC9ESVY+PERJVj48QlI+PC9ESVY+PERJVj5Eb3JpYW4gSi4gQ291Z2lhczwv RElWPjxESVY+Q29tcGxpYW5jZSBTY2llbnRpc3Q8L0RJVj48RElWPlVuaWZpZWQgQ29tcGxpYW5j ZSBGcmFtZXdvcms8L0RJVj48QlI+PC9ESVY+PC9kaXY+DQo= --_000_D7A0423E5E193F40BE6E94126930C4930B9F5B7E7AMBCLUSTERxcha_-- From tony@yaanatech.com Thu Aug 9 06:46:12 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B01021F8688; Thu, 9 Aug 2012 06:46:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZM1QVy2wJp1m; Thu, 9 Aug 2012 06:46:12 -0700 (PDT) Received: from extmail1.prd.yaanatech.com (extmail1.prd.yaanatech.com [205.140.198.37]) by ietfa.amsl.com (Postfix) with ESMTP id 2E03D21F8687; Thu, 9 Aug 2012 06:46:12 -0700 (PDT) Received: from [192.168.0.4] (pool-173-72-150-118.clppva.fios.verizon.net [173.72.150.118]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by extmail1.prd.yaanatech.com (Postfix) with ESMTP id D62CD58081; Thu, 9 Aug 2012 13:46:10 +0000 (UTC) Message-ID: <5023BF21.6030205@yaanatech.com> Date: Thu, 09 Aug 2012 09:46:09 -0400 From: Tony Rutkowski Organization: Yaana Technologies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120731 Thunderbird/15.0 MIME-Version: 1.0 To: "Waltermire, David A." References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------040907080601000108040801" Cc: "'david.oliva@verizon.net'" , "'mile@ietf.org'" , "'dcougias@netfrontiers.com'" , "'sacm@ietf.org'" Subject: Re: [mile] =?iso-8859-1?q?=5Bsacm=5D_Strategic_alignment_of_security_?= =?iso-8859-1?q?with_business_in_SACM_in=A0=A0=A0=A0an_international_conte?= =?iso-8859-1?q?xt?= X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: tony@yaanatech.com List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 13:46:12 -0000 This is a multi-part message in MIME format. --------------040907080601000108040801 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit David, I don't think you really want to have such a requirement. Almost everything is explicitly or implicitly copyrighted. IETF material itself asserts a copyright. What is relevant is any restrictions associated with the copyright. It seems inappropriate for a technical body to effectively require a copyright analysis of everything potentially sent to a list. Work would cease. --tony On 8/9/2012 9:06 AM, Waltermire, David A. wrote: > Sorry. Fat fingered send. It might be best to keep any copyrighted > material off the list, unless it is being contributed to the IETF as > an I/D. --------------040907080601000108040801 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
David,

I don't think you really want to have such a requirement.
Almost everything is explicitly or implicitly copyrighted.
IETF material itself asserts a copyright.  What is relevant
is any restrictions associated with the copyright.  It seems
inappropriate for a technical body to effectively require
a copyright analysis of everything potentially sent to a list.
Work would cease.

--tony


On 8/9/2012 9:06 AM, Waltermire, David A. wrote:
Sorry. Fat fingered send. It might be best to keep any copyrighted material off the list, unless it is being contributed to the IETF as an I/D.

--------------040907080601000108040801-- From kathleen.moriarty@emc.com Thu Aug 9 08:01:00 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8950721F861B for ; Thu, 9 Aug 2012 08:01:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.535 X-Spam-Level: X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gNvdmEj2WOPG for ; Thu, 9 Aug 2012 08:00:59 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id BB87321F85E4 for ; Thu, 9 Aug 2012 08:00:59 -0700 (PDT) Received: from hop04-l1d11-si04.isus.emc.com (HOP04-L1D11-SI04.isus.emc.com [10.254.111.24]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q79F0wFQ017746 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 9 Aug 2012 11:00:58 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd01.lss.emc.com [10.254.221.251]) by hop04-l1d11-si04.isus.emc.com (RSA Interceptor) for ; Thu, 9 Aug 2012 11:00:51 -0400 Received: from mxhub02.corp.emc.com (mxhub02.corp.emc.com [10.254.141.104]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q79ExAr7016819 for ; Thu, 9 Aug 2012 11:00:49 -0400 Received: from mx15a.corp.emc.com ([169.254.1.189]) by mxhub02.corp.emc.com ([10.254.141.104]) with mapi; Thu, 9 Aug 2012 11:00:38 -0400 From: "Moriarty, Kathleen" To: "mile@ietf.org" Date: Thu, 9 Aug 2012 11:00:37 -0400 Thread-Topic: Reminder about IETF IPR Policy Thread-Index: Ac12P7wbmjwJ7VIFQzqe2s32/iGBPg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_F5063677821E3B4F81ACFB7905573F2403C6BB18MX15Acorpemccom_" MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: [mile] Reminder about IETF IPR Policy X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 15:01:00 -0000 --_000_F5063677821E3B4F81ACFB7905573F2403C6BB18MX15Acorpemccom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear MILE WG: As MILE WG chairs, we would like to minimize or hopefully even eliminate late disclosures relating to documents under consideration within the MILE WG. Therefore you might see us send "reminder" messages in the future to authors or to the MILE WG email list as a whole, asking people whether they know of Intellectual Property Rights (IPR) relating to specific documents. In order to comply with IETF processes and avoid unnecessary delays, document authors and contributors to our discussions in the MILE WG are asked to pay careful attention to these messages and to reply in a timely fashion. Please note that these messages are only reminders of existing IETF policy, and we are all bound by that policy even in the absence of such reminder messages. Everyone who participates in the Internet Standards Process (whether by posting to IETF mailing lists, authoring documents, attending IETF meetings, or in other ways) needs to be aware of the IETF rules with regard to IPR. These rules are described in BCP79 and can be referenced through . In addition, online tools for filing IPR disclosures can be found at . Finally, existing disclosures can be searched online at . Also note that these are personal requirements applying to all IETF participants as individuals, and that these requirements also apply to all participants in the MILE WG. Thanks, Kathleen & Brian (MILE WG Co-chairs) --_000_F5063677821E3B4F81ACFB7905573F2403C6BB18MX15Acorpemccom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear MILE WG:
 
   As MILE WG chairs, we would like to minimize or hopefully= even
   eliminate late disclosures relating to documents under co= nsideration
   within the MILE WG.  Therefore you might see us send= "reminder"
   messages in the future to authors or to the MILE WG email= list as a
   whole, asking people whether they know of Intellectual Pr= operty
   Rights (IPR) relating to specific documents.  In ord= er to comply with
   IETF processes and avoid unnecessary delays, document aut= hors and
   contributors to our discussions in the MILE WG are asked = to pay
   careful attention to these messages and to reply in a tim= ely fashion.
 
   Please note that these messages are only reminders of exi= sting IETF
   policy, and we are all bound by that policy even in the a= bsence of
   such reminder messages.  Everyone who participates i= n the Internet
   Standards Process (whether by posting to IETF mailing lis= ts,
   authoring documents, attending IETF meetings, or in other= ways) needs
   to be aware of the IETF rules with regard to IPR.  T= hese rules are
   described in BCP79 and can be referenced through
   <http:= //www.ietf.org/ipr/policy.html>.  In addition, online tools for=
   filing IPR disclosures can be found at
   <h= ttp://www.ietf.org/ipr/file-disclosure>.  Finally, existing
   disclosures can be searched online at
 
   Also note that these are personal requirements applying t= o all IETF
   participants as individuals, and that these requirements = also apply
   to all participants in the MILE WG.
 
   Thanks,
 
   Kathleen & Brian
   (MILE WG Co-chairs)
 
 
 --_000_F5063677821E3B4F81ACFB7905573F2403C6BB18MX15Acorpemccom_-- From amontville@tripwire.com Thu Aug 9 09:06:56 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A90B21F87FC; Thu, 9 Aug 2012 09:06:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.644 X-Spam-Level: X-Spam-Status: No, score=-3.644 tagged_above=-999 required=5 tests=[AWL=-0.345, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nYc1VSGr4l9R; Thu, 9 Aug 2012 09:06:55 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe002.messaging.microsoft.com [216.32.180.185]) by ietfa.amsl.com (Postfix) with ESMTP id 70C7621F87E8; Thu, 9 Aug 2012 09:06:55 -0700 (PDT) Received: from mail220-co1-R.bigfish.com (10.243.78.248) by CO1EHSOBE015.bigfish.com (10.243.66.78) with Microsoft SMTP Server id 14.1.225.23; Thu, 9 Aug 2012 16:06:55 +0000 Received: from mail220-co1 (localhost [127.0.0.1]) by mail220-co1-R.bigfish.com (Postfix) with ESMTP id 1758FC03C3; Thu, 9 Aug 2012 16:06:55 +0000 (UTC) X-Forefront-Antispam-Report: CIP:174.47.84.216; KIP:(null); UIP:(null); IPV:NLI; H:PDXED01.tripwire.com; RD:174-47-84-216.static.twtelecom.net; EFVD:NLI X-SpamScore: -2 X-BigFish: VPS-2(z3e13hzbb2dI98dI9371Izz1202hz31izz2dh2a8h668h839he5bhf0ah107ah) Received: from mail220-co1 (localhost.localdomain [127.0.0.1]) by mail220-co1 (MessageSwitch) id 1344528413892850_5878; Thu, 9 Aug 2012 16:06:53 +0000 (UTC) Received: from CO1EHSMHS020.bigfish.com (unknown [10.243.78.239]) by mail220-co1.bigfish.com (Postfix) with ESMTP id D7B9A50004A; Thu, 9 Aug 2012 16:06:53 +0000 (UTC) Received: from PDXED01.tripwire.com (174.47.84.216) by CO1EHSMHS020.bigfish.com (10.243.66.30) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 9 Aug 2012 16:06:52 +0000 Received: from PDXHB01.tripwire.com (172.30.0.53) by PDXED01.tripwire.com (192.168.192.5) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 9 Aug 2012 09:08:50 -0700 Received: from PDXMB02.tripwire.com ([fe80::f997:7b65:8e64:438e]) by PDXHB01.tripwire.com ([fe80::d495:98d2:7df4:2154%11]) with mapi id 14.01.0355.002; Thu, 9 Aug 2012 09:06:51 -0700 From: Adam Montville To: "Waltermire, David A." , "'david.oliva@verizon.net'" , "'dcougias@netfrontiers.com'" , "'lnunez@c3isecurity.com'" Thread-Topic: =?iso-8859-1?Q?[sacm]_Strategic_alignment_of_security_with_business_in_SA?= =?iso-8859-1?Q?CM_in=A0=A0=A0=A0an_international_context?= Thread-Index: AQHNdkj8/1tomtWW7E2gKZo0ZkPNzA== Date: Thu, 9 Aug 2012 16:06:51 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [172.16.97.206] x-exclaimer-md-config: 79afcaa7-fdf4-4fa6-abe0-afeaa4640a4f Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: tripwire.com Cc: "'mile@ietf.org'" , "'sacm@ietf.org'" Subject: Re: [mile] =?iso-8859-1?q?=5Bsacm=5D_Strategic_alignment_of_security_?= =?iso-8859-1?q?with_business_in_SACM_in=A0=A0=A0=A0an_international_conte?= =?iso-8859-1?q?xt?= X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 16:06:56 -0000 On 8/9/12 6:06 AM, "Waltermire, David A." wrote: >It might be best to keep any copyrighted material off the list, unless it >is being contributed to the IETF as an I/D. Perhaps this is prudent. Also, I don't think we need a full copy - the actual prose is quite sparse. We should be able to get by, at least for now, with just the TOC (I sent a link out yesterday). From amontville@tripwire.com Thu Aug 9 09:09:20 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B5AD21F87FF for ; Thu, 9 Aug 2012 09:09:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.783 X-Spam-Level: X-Spam-Status: No, score=-3.783 tagged_above=-999 required=5 tests=[AWL=-0.184, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xq4HmNX0SETq for ; Thu, 9 Aug 2012 09:09:19 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe004.messaging.microsoft.com [216.32.180.187]) by ietfa.amsl.com (Postfix) with ESMTP id 72AA021F87E8 for ; Thu, 9 Aug 2012 09:09:19 -0700 (PDT) Received: from mail87-co1-R.bigfish.com (10.243.78.250) by CO1EHSOBE014.bigfish.com (10.243.66.77) with Microsoft SMTP Server id 14.1.225.23; Thu, 9 Aug 2012 16:09:18 +0000 Received: from mail87-co1 (localhost [127.0.0.1]) by mail87-co1-R.bigfish.com (Postfix) with ESMTP id 30EA7400281; Thu, 9 Aug 2012 16:09:18 +0000 (UTC) X-Forefront-Antispam-Report: CIP:174.47.84.216; KIP:(null); UIP:(null); IPV:NLI; H:PDXED01.tripwire.com; RD:174-47-84-216.static.twtelecom.net; EFVD:NLI X-SpamScore: -5 X-BigFish: VPS-5(zzbb2dI98dI9371I1432I1447Izz1202hzz8275bhz2dh2a8h668h839h944he5bhf0ah107ah) Received: from mail87-co1 (localhost.localdomain [127.0.0.1]) by mail87-co1 (MessageSwitch) id 1344528556121188_20189; Thu, 9 Aug 2012 16:09:16 +0000 (UTC) Received: from CO1EHSMHS016.bigfish.com (unknown [10.243.78.227]) by mail87-co1.bigfish.com (Postfix) with ESMTP id 1B5C7440049; Thu, 9 Aug 2012 16:09:16 +0000 (UTC) Received: from PDXED01.tripwire.com (174.47.84.216) by CO1EHSMHS016.bigfish.com (10.243.66.26) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 9 Aug 2012 16:09:14 +0000 Received: from PDXHB01.tripwire.com (172.30.0.53) by PDXED01.tripwire.com (192.168.192.5) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 9 Aug 2012 09:11:12 -0700 Received: from PDXMB02.tripwire.com ([fe80::f997:7b65:8e64:438e]) by PDXHB01.tripwire.com ([fe80::d495:98d2:7df4:2154%11]) with mapi id 14.01.0355.002; Thu, 9 Aug 2012 09:09:13 -0700 From: Adam Montville To: Sean Turner Thread-Topic: [mile] IPR and Transfer Considerations Thread-Index: Ac10nPlvZvn4bwL9Qy2D7OCDEvaANQAQjZXwACtneYAAHEEGgAAS346A Date: Thu, 9 Aug 2012 16:09:12 +0000 Message-ID: In-Reply-To: <5022FF8F.1080206@ieca.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [172.16.97.206] x-exclaimer-md-config: 79afcaa7-fdf4-4fa6-abe0-afeaa4640a4f Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CRA-Verdict: 174.47.84.216$juniper.net%12218%2%tripwire.com%True%True%0$ X-OriginatorOrg: tripwire.com Cc: "mile@ietf.org" , "dennis.groves@owasp.org" Subject: Re: [mile] IPR and Transfer Considerations X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 16:09:20 -0000 On 8/8/12 5:08 PM, "Sean Turner" wrote: >>Just an honest question here, but if we're concerned about >>copyright/trademark issues, why are the IPR disclosures in terms of >>patents? > >I think this stems from the way the IPR disclosure page is set up. You >can disclose any kind of IPR: patents, trademarks, copyrights, etc. Thanks for the follow-up, Sean. I'll take this for what it's worth and simply remain confused, but move on :-) From stpeter@stpeter.im Thu Aug 9 09:23:33 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39FA321F86E3 for ; Thu, 9 Aug 2012 09:23:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.776 X-Spam-Level: X-Spam-Status: No, score=-102.776 tagged_above=-999 required=5 tests=[AWL=-0.177, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PYqK2Qzhq9iO for ; Thu, 9 Aug 2012 09:23:32 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 7AC9521F86D9 for ; Thu, 9 Aug 2012 09:23:32 -0700 (PDT) Received: from [192.168.0.4] (unknown [67.177.192.224]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id A7564404EA; Thu, 9 Aug 2012 10:23:40 -0600 (MDT) Message-ID: <5023E401.6060205@stpeter.im> Date: Thu, 09 Aug 2012 10:23:29 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Adam Montville References: In-Reply-To: X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "mile@ietf.org" , "dennis.groves@owasp.org" Subject: Re: [mile] IPR and Transfer Considerations X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 16:23:33 -0000 On 8/9/12 10:09 AM, Adam Montville wrote: > On 8/8/12 5:08 PM, "Sean Turner" wrote: > >>> Just an honest question here, but if we're concerned about >>> copyright/trademark issues, why are the IPR disclosures in terms of >>> patents? >> >> I think this stems from the way the IPR disclosure page is set up. You >> can disclose any kind of IPR: patents, trademarks, copyrights, etc. > > > Thanks for the follow-up, Sean. I'll take this for what it's worth and > simply remain confused, but move on :-) Having been involved in an IPR disclosure about a trademark, I will vouch that you can complete such disclosures. However, the disclosures (or lack thereof) that tend to derail technical work typically involve patents, not copyrights or trademarks. (Rant about the overly-general term "IPR" elided...) Peter -- Peter Saint-Andre https://stpeter.im/ From turners@ieca.com Fri Aug 10 05:31:33 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD0BE21F860D for ; Fri, 10 Aug 2012 05:31:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.113 X-Spam-Level: X-Spam-Status: No, score=-102.113 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N2-01yrX2LjO for ; Fri, 10 Aug 2012 05:31:32 -0700 (PDT) Received: from gateway04.websitewelcome.com (gateway04.websitewelcome.com [67.18.10.5]) by ietfa.amsl.com (Postfix) with ESMTP id 56D8E21F85E7 for ; Fri, 10 Aug 2012 05:31:32 -0700 (PDT) Received: by gateway04.websitewelcome.com (Postfix, from userid 5007) id 5CCE0DEAAB99C; Fri, 10 Aug 2012 07:31:27 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway04.websitewelcome.com (Postfix) with ESMTP id 50208DEAAB940 for ; Fri, 10 Aug 2012 07:31:27 -0500 (CDT) Received: from [108.18.174.220] (port=52688 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1SzoNB-0002UH-QD; Fri, 10 Aug 2012 07:31:25 -0500 Message-ID: <5024FF1C.8010905@ieca.com> Date: Fri, 10 Aug 2012 08:31:24 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Adam Montville References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [108.18.174.220]:52688 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 22 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: "mile@ietf.org" , "dennis.groves@owasp.org" Subject: Re: [mile] IPR and Transfer Considerations X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 12:31:33 -0000 On 8/9/12 12:09 PM, Adam Montville wrote: > On 8/8/12 5:08 PM, "Sean Turner" wrote: > >>> Just an honest question here, but if we're concerned about >>> copyright/trademark issues, why are the IPR disclosures in terms of >>> patents? >> >> I think this stems from the way the IPR disclosure page is set up. You >> can disclose any kind of IPR: patents, trademarks, copyrights, etc. > > > Thanks for the follow-up, Sean. I'll take this for what it's worth and > simply remain confused, but move on :-) I'll bring this up with the IESG and see if we can maybe make it clearer. spt From jhowie@cloudsecurityalliance.org Tue Aug 14 21:39:26 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FCEB21E805E for ; Tue, 14 Aug 2012 21:39:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.398 X-Spam-Level: X-Spam-Status: No, score=0.398 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WIA62C0kyASc for ; Tue, 14 Aug 2012 21:39:15 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4511521E80AB for ; Tue, 14 Aug 2012 21:39:12 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so1772593obb.31 for ; Tue, 14 Aug 2012 21:39:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :in-reply-to:mime-version:content-type:x-gm-message-state; bh=JvBnGMmRBlPNPO8BF0ZJfI7s/nP7Fa1TI8pgKmcbW2w=; b=ZFTIus5bk3TpAhyPUykU+r/dFPRd+khATzPv/cXwdUXASgwX6X5ahg3YurxC8hG/0q 9VRSRDhAATDMRhUnPapkOX0R4IVI9ZGt+tdhxcpO//vUw/e5VNl1SY/sCzqhAH+jAhS/ EOg4Nl4Wbmie4EsFvpI7tjyfiOFL4snIAVzRN6GzlBAZ8PpQIUwuxXnV4sXiQscozqU1 6PrnURbimhO62zq3mnZlh6BCcTE2qLQrhHaQUmJJVSwnsn7TZ0adedGvvFSpEFiAVraZ ieMqpexj5DoxZW7YYrA1gl0crqhLte5P6MwXptXeptiKs1yFOhWEYEmQdR9eoHyWVwSn lseQ== Received: by 10.50.213.39 with SMTP id np7mr16044261igc.51.1345005550552; Tue, 14 Aug 2012 21:39:10 -0700 (PDT) Received: from [192.168.1.41] (c-67-170-52-163.hsd1.wa.comcast.net. [67.170.52.163]) by mx.google.com with ESMTPS id gx1sm1016665igb.16.2012.08.14.21.39.05 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 14 Aug 2012 21:39:09 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.2.3.120616 Date: Tue, 14 Aug 2012 21:39:04 -0700 From: John Howie To: Luis Nunez , "Waltermire, David A." Message-ID: Thread-Topic: [mile] [sacm] Strategic alignment of security with business in SACM in an international context In-Reply-To: Mime-version: 1.0 Content-type: multipart/mixed; boundary="B_3427825151_10020701" X-Gm-Message-State: ALoCoQnKdTiLTAugNpYvVFCtrMSWAp+Ki4QYOQn+67L9s6uh6P3y52c/+6ZSDHHrbaH9kpnRL4Ax Cc: Ruben Oliva , mile@ietf.org, sacm@ietf.org, Becky Swain Subject: Re: [mile] [sacm] Strategic alignment of security with business in SACM in an international context X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 04:39:26 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3427825151_10020701 Content-type: multipart/alternative; boundary="B_3427825152_10010932" --B_3427825152_10010932 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi all, The Cloud Security Alliance intellectual property, including the Cloud Controls Matrix, can be used royalty free with attribution, should you wish to use it. We are making some updates to the Cloud Controls Matrix, and I have Cc'ed Becky Swain who can answer any questions you might have about th= e updates. Regards, John From: Luis Nunez Date: Wednesday, August 8, 2012 9:50 AM To: "Waltermire, David A." Cc: Ruben Oliva , , Subject: Re: [mile] [sacm] Strategic alignment of security with business i= n SACM in an international context I had mention the Cloud Security Matrix (Cloud Security Alliance) in anothe= r thread. 1. is this something we can use as basis for mapping the various regulation= s to a common id? 2. Is this SACM or MILE GRC related work? thanks. -ln On Aug 8, 2012, at 12:37 PM, Waltermire, David A. wrote: > The challenge we will likely face in scoping down the effort is that we m= ight > not be able to work on the full stack that supports low-level data collec= tion, > as well as higher level security processes and controls. This is because= we > will likely need to charter around a lower layer of function. This is wh= y we > need to scope as part of this work an architecture document that illustra= tes > how the smaller scope of work fits into the larger picture that supports > alignment with international compliance models. > =20 > To say it a different way, we need to define a comprehensive picture of t= he > =B3end state=B2, even though we may only get part way there based on an initi= al > SACM charter. > =20 > We can use documents like ISO 27001 as guidance in producing the architec= ture > document to insure that the end state aligns well with your concerns belo= w. > =20 > Sincerely, > Dave > =20 > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > david.oliva@verizon.net > Sent: Wednesday, August 08, 2012 10:22 AM > To: lnunez@c3isecurity.com; sacm@ietf.org > Subject: [sacm] Strategic alignment of security with business in SACM in = an > international context > =20 > =20 > Luis and all: > Unless we can demonstrate that the technologies and specifications we are > developing align with the security objectives of international compliance > models (such as ISO 27001) we cannot demonstrate strategic alignment of > business and security objectives in their context. > Strategic alignment of security objectives with business objectives can b= e at > least partially joined via SACM thru the SP 800-53 to ISO 27001 mapping t= able. > If this were to happen to SACM then the validated products will have less > appeal and less marketability. The validated products will work fine, but= they > will work with limited capability and scope. For example, currently vali= dated > SCAP 1.0 products do not use the Open Checklist Interactive Language (OCI= L). > OCIL is an open specification (created by the security community for use = by > anybody, any developer, any country) that facilitates non-automated asses= sment > of security processes. OCIL would allow an ISO 27001 compliance assessor= in > Germany to create a question =B3Does the organization comply ISO/IEC 27001:= 2005 > para 4.2.2 e) =8CDoes the organization implement a training and awareness > programme=B9=B2 and answer =8Cyes=B9 or =8Cno=B9. Then the results can be accessed a= nd > read whether the organization uses product X or product Y because OCIL is= an > open security specification. Another example of OCIL is a rather mundane > security function of universal use. OCIL allows an ISO 27001 security > compliance officer to answer =8Cyes=B9 or =8Cno=B9 to the question =B3Is the door s= hut?=B2 > and make the result electronically readable whether he/she uses product X= or > product Y. As for business, the flexibility of OCIL allows a company to > create a question =B3Did the company reach our 7% profit strategic objectiv= e > over the past 10 years?=B2 and able to answer it =8Cyes=B9 or =8Cno=B9 with product= X, > Y, or Z and ensure interoperability. > =20 > David Oliva > =20 >=20 > =20 > =20 > On 08/07/12, Luis Nunez wrote: > =20 > Thanks the comment. I am glad someone agrees with me :) > =20 > -ln > =20 > On Aug 7, 2012, at 11:46 AM, david.oliva@verizon.net wrote: >=20 >=20 > Luis and all: > =20 > You are on target. > SACM is not a law enforcement thing, but is a facilitator of legal issues= in > association with the protection of private information and health-related > information. > I think a couple of examples to show how SACM facilitates legal issues ab= out > personal information is in order. > A SACM configuration scanner is able to monitor the configuration of secu= rity > controls as specified in ISO/IEC 27001:2005. This can be accomplished wh= en > tier IV SCAP content is used because the output maps the finding (complia= nce > or non-compliance) of the scanner to security control ISO/IEC 27001:2005 > paragraph A.10.6.2 =B3Security of Network Services=B2. Thus a SACM scanner i= s > able to assist in international governance compliance about personal > information because SP 800-53 maps to ISO 27001. > A SACM vulnerability scanner is able to meet compliance with ISO 27001, p= ara > A.12.6.1 =B3Control of technical vulnerabilities=B2 because a SACM scanner us= ing > SCAP tier IV content can map its output to the ISO governance. SACM > Vulnerability scanning can address aspects of confidentiality of personal > information by identifying software vulnerabilities of the databases that > house them, and do it in the context of an international set of security > standards. >=20 > =20 > David Oliva > =20 > =20 > =20 > On 08/06/12, Luis Nunez wrote: > =20 > Looking at it another way I could see security automation as a way to dis= cover > if a system is configured to meet privacy policies . > =20 > Security automation is an enabler for transparency so that individuals a= nd > organizations may understand the complex computing environment. > =20 > Thanks for bring up this issue. As a community we may want to look at > building content around privacy controls. > =20 > -ln > =20 > On Aug 6, 2012, at 12:42 PM, wrote: >=20 >=20 > None of the efforts we are talking about for SACM are targeted toward PII= or > individuals. They are targeted at the configuration of the platforms depl= oyed > in the enterprise to assure they comply with the site's security policy. = PII > is not collected. This is not monitoring of individual or employee action= s. I > am not a lawyer and will not speak as one. We will let the lawyer's decid= e at > the appropriate time. > =20 > Kent Landfield >=20 > McAfee | An Intel Company > Direct: +1.972.963.7096 > Mobile: +1.817.637.8026 > Web: www.mcafee.com > =20 > From: Martin Rex > Reply-To: "mrex@sap.com" > Date: Monday, August 6, 2012 11:32 AM > To: "tony@yaanatech.com" > Cc: "mrex@sap.com" , "sacm@ietf.org" > Subject: Re: [sacm] Legal aspects of System monitoring > =20 >> Tony Rutkowski wrote: >>> Martin Rex wrote: >>>> =20 >>>> In Germany, an employer monitoring a company-owned PC that an employee= uses >>>> for communication (EMail, VoiP, IM) would be unconditionally illegal. >>> =20 >>> Really? >> =20 >> No kidding! >> =20 >> =20 >>> =20 >>> That is not consistent with comments >>> I've seen concerning German law. >> =20 >> There is a significant amount of mis-information floating the internet. >> And a mindboggling large number of lawyers are making wild guesses, rath= er >> that doing research. >> =20 >> The decisions of the german federal constitional court (GFCC) have been >> quite consistent over the past decade about what with respect to >> encroaching on the general right of personality, informational >> self-determination, freedom of conduct and created a "fundamental right >> to the guarantee of the integrity and confidentiality of information >> technology systems". The court has set the minimum requirements that >> are prerequisite to such encroachment, such as the prerequisite of a >> clear formal statute law, which needs to be limited to situation where >> real facts create probable cause. >> =20 >> The original GFCC decision in german language is quite comprehensible >> (to me, at least), while I'm having some difficulties understanding >> the english translation (and the english translation is shorter!?). >> =20 >> BVerfG-Entscheidung "1 BvR 370/07 vom 27.2.2008" Randnummer 196- >> http://www.bverfg.de/entscheidungen/rs20080227_1bvr037007.html#abs196 >> =20 >> english translation of "1 BvR 370/07 vom 27.2.2008" >> http://www.bverfg.de/entscheidungen/rs20080227_1bvr037007en.html#abs130 >> =20 >> =20 >>> To be *unconditionally* illegal, would >>> preclude almost any rationally required >>> maintenance or threat mitigation. >> =20 >> It is possible to perform maintenance and threat mitigation entirely >> without "monitoring" systems. >> =20 >> A mere threat is insufficient for monitoring, if that involves collectin= g >> PII data, i.e. data from which a persons conduct can be infered. >> =20 >> =20 >>> =20 >>> It is fair to observe that recent German >>> Constitutional Court decisions impose >>> constraints, but they certainly are >>> not "unconditional." >> =20 >> One of the prerequisite is a clear formal statute law, >> which currently does not exist for the purposes "sacm" is about. >> =20 >> quoting from the above GFCC decision: >> =20 >> 2. The fundamental right to the guarantee of the confidentiality and >> integrity of information technology systems is not unrestricted. >> Encroachments may be justified both for preventive purposes, and for >> criminal prosecution. The individual must only accept such restrictio= ns >> of his or her right which are based on a statutory foundation that >> is constitutional. >> =20 >> =20 >> This currently makes collecting data about peoples conduct "unconditiona= lly" >> illegal for most practical purposes (exempting from prosecution only >> individual occasions of justified self-defence against an imminent >> vicious attack based on real facts that create probable cause). >> =20 >> This applies to all surveillance that impairs persons "freedom of conduc= t". >> The majority of past decisions of specific events was about surveillance >> with a camera, but the GFCC decision makes it crystal clear that >> this applies to *any* kind of surveillance. Different to monitoring of >> computer systems, there is statutory law for camera surveillance, >> that allows optical surveillance under certain conditions >> (Art. 6b BDSG "BundesDatenSchutzGesetz). >> =20 >> The lack of a formal statutory foundation makes surveillance illegal >> and entitles subjects to "cease and desist" rulings and sometimes >> damages. >> =20 >> In one more recent (and constitutionally correct) rulings, an employer >> had put up a camera that had in view not only the entrance door, but >> also two workplaces. The employees protested against this camera, >> but the employer would not "fix" it, so at least one employee sued, >> The court confirmed that this camera surveillance at the workplace >> was illegal due to its chilling effect alone, and since it had been >> installed for a whole year, the employee was arwarded 4 month of income >> as damages (for the chilling effect). >> =20 >> Another recent decision was about evidence from a covert video >> surveillance showing an employee taking a package of cigarettes >> on two occasions, where the German Federal Labour Court >> (the supreme court for labor related issues) remanded the decision >> to the trial court because it had failed to establish whether the >> covert video surveillance really met all constitutional prerequisites >> otherwise the video surveillance would have been illegal and not >> be admissible as evidence in court. >> (German decision: http://lexetius.com/2012,2351) >> =20 >> The German Federal Constitional Court neutered numerous laws during the >> last decade due to lack of clarity and/or overbroad encroachment of >> the personal right of self-determination and the right to confidentialit= y >> of telecommunications. >> =20 >> See also the GFCC decision about the scanning of license plates >> (the decision 1 BvR 2074/05 vom 11.3.2008 in german) >> http://www.bverfg.de/entscheidungen/rs20080311_1bvr2-07405.html >> =20 >> where it confirmed that data collection requires formal statue law, >> and that the law in question wasn't limited to probable cause and >> therefore unconstitutional. >> =20 >> =20 >> The only currently existing formal statue law in Germany, that could be >> used in some limited fashion for "Monitoring" is Art.100 TKG, >> http://www.gesetze-im-internet.de/tkg_2004/__100.html >> but that statue is clearly limited in purpose, it will not allow that da= ta >> to be used for automatic surveillance of "employee conduct" with respect >> to "company-defined policies". Employers try hard to avoid TKG for thei= r >> networks (for which they will have to formally register), but that also >> means that they do not have a formal statutory law for performing any >> kind of surveillance/monitoring as described in Art. 100 TKG for systems >> that are used by employees for telecommunications and a significant part >> of their daily activies. >> =20 >> =20 >> -Martin >> _______________________________________________ >> sacm mailing list >> sacm@ietf.org >> https://www.ietf.org/mailman/listinfo/sacm >> =20 > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > =20 > =20 >=20 >=20 > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile --B_3427825152_10010932 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
Hi all,
=
The Cloud Security Alliance intellectual property, including = the Cloud Controls Matrix, can be used royalty free with attribution, should= you wish to use it. We are making some updates to the Cloud Controls Matrix= , and I have Cc'ed Becky Swain who can answer any questions you might have a= bout the updates.

Regards,

John

From: = Luis Nunez <lnunez@c3isec= urity.com>
Date: Wednesday,= August 8, 2012 9:50 AM
To: "Walte= rmire, David A." <david.walter= mire@nist.gov>
Cc: Ruben Ol= iva <david.oliva@verizon.net= >, <mile@ietf.org>, <sacm@ietf.org>
Subject: Re: [mile] [sacm] Strategic alignment of security with b= usiness in SACM in an international context

I had mention the Cloud Se= curity Matrix (Cloud Security Alliance) in another thread.
1. is this so= mething we can use as basis for mapping the various regulations to a common = id?
2. Is this SACM or MILE GRC related work?

=
thanks.
-ln

On Aug 8, 2012, at 12:37 = PM, Waltermire, David A. wrote:

<= blockquote type=3D"cite">
The challenge we will likely face in scoping down the eff= ort is that we might not be able to work on the full stack that supports low= -level data collection, as well as higher level security processes and contr= ols.  This is because we will likely need to charter around a lower lay= er of function.  This is why we need to scope as part of this work an a= rchitecture document that illustrates how the smaller scope of work fits int= o the larger picture that supports alignment with international compliance m= odels.
 
To say it a different way, we need to define a comprehensive picture= of the “end state”, even though we may only get part way there = based on an initial SACM charter.
&n= bsp;
We can use documents like ISO 27001 as gu= idance in producing the architecture document to insure that the end state a= ligns well with your concerns below.
 
Sincerely,<= /o:p>
Dave
 
From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of davi= d.oliva@verizon.net
Sent:&= nbsp;Wednesday, August 08, 2012 10:22 AM
To: ln= unez@c3isecurity.com; sacm@ietf.orgSubject: [sacm] Str= ategic alignment of security with business in SACM in an international conte= xt
 
 

Luis and all:

Unless we can demonstrate tha= t the technologies and specifications we are developing align with the secur= ity objectives of international compliance models (such as ISO 27001) we can= not demonstrate strategic alignment of business and security objectives in t= heir context. 

Strategic alignment of security objecti= ves with business objectives can be at least partially joined via SACM thru = the SP 800-53 to ISO 27001 mapping table.  If this were to happen to SA= CM then the validated products will have less appeal and less marketability.= The validated products will work fine, but they will work with limited capa= bility and scope.  For example, currently validated SCAP 1.0 products d= o not use the Open Checklist Interactive Language (OCIL).   OCIL i= s an open specification (created by the security community for use by anybod= y, any developer, any country) that facilitates non-automated assessment of = security processes.  OCIL would allow an ISO 27001 compliance assessor = in Germany to create a question “Does the organization comply ISO/IEC = 27001:2005 para 4.2.2 e) ‘Does the organization implement a training a= nd awareness programme’” and answer ‘yes’ or ‘= no’.  Then the results can be accessed and read whether the organ= ization uses product X or product Y because OCIL is an open security specifi= cation.  Another example of OCIL is a rather mundane security function = of universal use.  OCIL allows an ISO 27001 security compliance officer= to answer ‘yes’ or ‘no’ to the question “Is t= he door shut?” and make the result electronically readable whether he/= she uses product X or product Y.  As for business, the flexibility of O= CIL allows a company to create a question “Did the company reach our 7= % profit strategic objective over the past 10 years?” and able to answ= er it ‘yes’ or ‘no’ with product X, Y, or Z and ensu= re interoperability.

 

David Oliva

 

 
=  
On 08/07/12, Luis Nunez<= lnunez@c3isecurity.com> wrote:
 <= /o:p>
Thanks the comment.  I am glad someone agree= s with me :)
 
<= div>
 
<= span style=3D"font-size: 9pt; font-family: Arial, sans-serif; color: black; ">= On Aug 7, 2012, at 11:46 AM, david.oliva@verizon.net wrote:


 Luis and all:
 
You are on target.

SACM is not a law enforcement thing, but is a facilitator = of legal issues in association with the protection of private information an= d health-related information.=

I think a couple of examples to show how SACM facilitates legal issue= s about personal information is in order.

A SACM configuration scanner is able to monitor the confi= guration of security controls as specified in ISO/IEC 27001:2005.  This= can be accomplished when tier IV SCAP content is used because the output ma= ps the finding (compliance or non-compliance) of the scanner to security con= trol ISO/IEC 27001:2005 paragraph A.10.6.2 “Security of Network Servic= es”.  Thus a SACM scanner is able to assist in international gove= rnance compliance about personal information because SP 800-53 maps to ISO 2= 7001.

A SACM vulnerabil= ity scanner is able to meet compliance with ISO 27001, para A.12.6.1 “= Control of technical vulnerabilities” because a SACM scanner using SCA= P tier IV content can map its output to the ISO governance.  SACM Vulne= rability scanning can address aspects of confidentiality of personal informa= tion by identifying software vulnerabilities of the databases that house the= m, and do it in the context of an international set of security standards.

 =
David Oliva
 
 
 
On 08/06/12, Luis Nunez<lnunez@c3isecurity.com> wrote:
 = ;
Looking at it another way I could see secu= rity automation as a way to discover if a system is configured to meet priva= cy policies .  
 
Security automation is an enabler for transparency  so that i= ndividuals and organizations may understand the complex computing environmen= t.
 
=
=  
-ln
<= span style=3D"font-size: 9pt; font-family: Arial, sans-serif; color: black; ">=  
On Aug 6, 2012, at 12:42 PM, <Kent_Landfield@McAfee.com> wrote:


None of the efforts we are talking about for SACM are = targeted toward PII or individuals. They are targeted at the configuration o= f the platforms deployed in the enterprise to assure they comply with the si= te's security policy.  PII is not collected. This is not monitoring of = individual or employee actions.  I am not a lawyer and will not speak a= s one. We will let the lawyer's decide at the appropriate time.
 
Kent LandfieldMcAfee | A= n Intel Company
Direct: +1= .972.963.7096 
Mobile: +1.817.= 637.8026
We= b: 
From: <= /span>Martin Rex <mrex@sap.com>=
Reply-To: "mrex@sap.com" <mrex@sap.com>=
Date: Monday, Aug= ust 6, 2012 11:32 AM
To: "tony@yaanatech.com" <tony@yaanatech.com>
Cc: "mrex@sap.com" <mrex@sap.com>, "sacm@ietf.org" &= lt;sacm@ietf.org>
Subject: Re: [sacm] Legal aspects of System moni= toring
&nbs= p;
Tony Rutkowski wrote:
Martin Rex wrote:
 
<= div>
In Germany, an employer monitoring a company-o= wned PC that an employee uses
for communication (EMail, VoiP, IM) would be unconditionally i= llegal.
 
Real= ly?
 
No kiddi= ng!
 <= /o:p>
 
 =
That is not consistent wit= h comments
I've = seen concerning German law.
<= div style=3D"margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bott= om: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "> 
There is a significant amount of mis-information floating th= e internet.
And = a mindboggling large number of lawyers are making wild guesses, rather<= /o:p>
that doing research.<= o:p>
 
The decisions of the germ= an federal constitional court (GFCC) have been
=
quite consistent over the past decade about w= hat with respect to
encroaching on the general right of personality, informational
self-determination, freed= om of conduct and created a "fundamental right
=
to the guarantee of the integrity and confide= ntiality of information
technology systems".  The court has set the minimum requir= ements that
are = prerequisite to such encroachment, such as the prerequisite of a<= /span>
clear formal statute law, w= hich needs to be limited to situation where
<= span style=3D"color: black; ">real facts create probable cause.
 
=
The original GFCC decision in german la= nguage is quite comprehensible
(to me, at least), while I'm having some difficulties underst= anding
the engli= sh translation (and the english translation is shorter!?).=
 
BVerfG-Entscheidung "1 BvR 370/07 vom 27.2= .2008" Randnummer 196-
 =
english translation of "1 = BvR 370/07 vom 27.2.2008"
 = ;
 
To be *uncondit= ionally* illegal, would
preclude almost any rationally required
maintenance or threat mitigation.=
 
It is possible to perf= orm maintenance and threat mitigation entirely
=
without "monitoring" systems.
 
<= /div>
A mere threat is insufficient for monito= ring, if that involves collecting
PII data, i.e. data from which a persons conduct can be in= fered.
&nbs= p;
 <= /span>
 
It is fair to observe t= hat recent German
constraints, but they certainly are
not "unconditional."<= /span>
 
One of the prerequisite= is a clear formal statute law,
which currently does not exist for the purposes "sacm" is ab= out.
 =
quoting from the abo= ve GFCC decision:
 &= nbsp;2. The fundamental right to the guarantee of the confidentiality and
  integr= ity of information technology systems is not unrestricted.=
  Encroachments may be = justified both for preventive purposes, and for
  criminal prosecution.  = ;The individual must only accept such restrictions
  of his or her right which are= based on a statutory foundation that
  is constitutional.
=
 
<= span style=3D"color: black; "> 
This currently makes collecting data about peoples conduc= t "unconditionally"
illegal for most practical purposes (exempting from prosecution only
individual occasion= s of justified self-defence against an imminent
vicious attack based on real facts that crea= te probable cause).
 
This = applies to all surveillance that impairs persons "freedom of conduct".<= /o:p>
The majority of past = decisions of specific events was about surveillance
<= /div>
with a camera, but the GFCC decision mak= es it crystal clear that
this applies to *any* kind of surveillance.  Different to= monitoring of
c= omputer systems, there is statutory law for camera surveillance,<= /span>
that allows optical surveil= lance under certain conditions
(Art. 6b BDSG "BundesDatenSchutzGesetz).
 
=
The lack of a formal statutory foundation mak= es surveillance illegal
and entitles subjects to "cease and desist" rulings and sometimes
damages.
 <= /div>
In one more recent (and constituti= onally correct) rulings, an employer
had put up a camera that had in view not only the entra= nce door, but
al= so two workplaces.  The employees protested against this camera,
but the employer = would not "fix" it, so at least one employee sued,
The court confirmed that this camera surv= eillance at the workplace
was illegal due to its chilling effect alone, and since it had bee= n
installed for = a whole year, the employee was arwarded 4 month of income<= /div>
as damages (for the chilling effec= t).
 <= /o:p>
Another recent decisi= on was about evidence from a covert video
=
surveillance showing an employee taking a package = of cigarettes
on= two occasions, where the German Federal Labour Court
(the supreme court for labor related i= ssues) remanded the decision
to the trial court because it had failed to establish whether t= he
covert video = surveillance really met all constitutional prerequisites
be admissible as evidence in court.
 
The German F= ederal Constitional Court neutered numerous laws during the
last decade due to lack of clari= ty and/or overbroad encroachment of
the personal right of self-determination and the right t= o confidentiality
 
= See also the GFCC decision about the scanning of license plates
(the decision 1 BvR 2074/05 = vom 11.3.2008 in german)
 
where it confirmed that data collect= ion requires formal statue law,
and that the law in question wasn't limited to probable caus= e and
therefore = unconstitutional.
&n= bsp;
The only current= ly existing formal statue law in Germany, that could be
used in some limited fashion for "Mo= nitoring" is Art.100 TKG,
but that statue is clearly limited= in purpose, it will not allow that data
<= div style=3D"margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bott= om: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; ">to be used for automatic surveillance of "employee = conduct" with respect
to "company-defined policies".  Employers try hard to avoid = TKG for their
ne= tworks (for which they will have to formally register), but that also
means that they do not= have a formal statutory law for performing any
kind of surveillance/monitoring as described= in Art. 100 TKG for systems
that are used by employees for telecommunications and a signifi= cant part
of the= ir daily activies.
&= nbsp;
-Martin
_______________________= ________________________
sacm mailing list
_______________________________________________
sacm= mailing list
sacm@ietf.org
https://www.ietf.org/mailman/listinfo/sacm
 
 <= /o:p>

___________________________= ____________________
sacm mailing list
sacm@ietf.= org
https://www.ietf.org/m= ailman/listinfo/sacm


_______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/m= ailman/listinfo/mile --B_3427825152_10010932-- --B_3427825151_10020701 Content-type: image/png; name="JHOWIE Email Signature[98].png" Content-ID: Content-disposition: inline; filename="JHOWIE Email Signature[98].png" Content-transfer-encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAYsAAABkCAYAAAB3hRxoAAAgAElEQVR4nOy9eZRc1X3v+9ln qLl6VHdL3ZonS0JqgQSWcAy4hYPBxDSxceLY4sZcYsnPLwvBfQlEedda6wnHPJGbGLEcB5Tn gGOBE4MdRGyLYCNhsEECWkC30ICm1tAautVTzVXnnL3fH+fU0FJLaiTAvvH5shpVnbOns6tq //Zv+m6hlFL48OHDhw8f54H2mx6ADx8+fPj47YcvLHz48OHDxwXhCwsfPnz48HFB+MLChw8f PnxcEL6w8OHDhw8fF4QvLHz48OHDxwXhCwsfPnz48HFB+MLChw8fPnxcEL6w8OHDhw8fF4Qv LHz48OHDxwXhCwsfPnz48HFB+MLChw8fPnxcEL6w8OHDhw8fF4QvLHz4uET0dW3huR3Hf9PD 8OHjA4UvLMYKpQCXzb3E6V7xovJOqaRy66ni34jmVKmQQpUquWUr6xebUaULisq2itfKZUbe k6Xy3nDwOenHhtyBJxHLHiV5gXJHN1/PTT89etH9JLseHdlProvbheDRrnLPh19+nFuFQHh/ t9//NH02QI6nVwqWPbyjVLZv+4MIcTtdueKVQR5dJnhwxyDkdnCruJUdSbfus3+9rNSmEIJb K9rx4aMSvrAYK4QAhPuydK38ovJOqaRw65V+jCOaE6VCAlGq5JatrF9sRpQuCCrbKl4rlxl5 TyuV94YzYhw+zg1r+DRszV+4YKiN1uoIALZ9MR3lYWueUlXLogfIW+6V3J7HmXrtHUx77CV6 Bwbo7txEcs3naVyzBQhxxe+vYOuqXzDoVd/z/BPARl7Z5QmbwZ18ZyvMGR8HIEECy+2I7p9u ZfWmTnp7euju7uY7t8+7iAfw8bsAX1iMEaWdu/dX1h689yWtQOLu5mVZe6jUFoqtKQnlVlAo ZEUfSkkUDihZoUvIct8KlPTKKbe220JFFxXjRfoqxXuGWfnGZseTf10W/LfeT3Hjbwar6Hzm 29y+UGCagpWPbvcW/hxPrryd+x8u1lvGk12DZ3WDCbQGCRffh02qSjdz/ORbd8Dyp/jbL19D Q20tUxbcwj+9tBYeeJgdOZjysZuBJ9g5CHCcV5/uBGDzr/YB0LfzRTpZy9XNxqiPOX7aXBqa m5kyZQrNtaGLnCwf/9XhC4sxQqiicqFQJUVAgZAglLdjL+/5hSqVACFQMoed7UcWUp5Jq9Jo JUvvytqEhvvxiDP+ACQChRCq4o7G2TqDJ2SEAk2glIPMp3DyKU+o+Rgrcns2svhLD/DItm6y A7tZe2gNrWueLWsDWzdw/YZuul9az4avrqYjCWCR3LeRNd8N09nbw+a1/Xxp1Q9HMWsFofOr fGXlSlauXMnKO1axqXTPon8bLL9pPpVLfcOcq4AElgVG85WsppPNOwdhsJP7Ou9m86a1bFr1 C5LAns1raF13Aw2jPFdwGqz6+h3cs3Ilt99+P3tyoxTy4QMYfavh42wIUGctxgKlNEAhhDzD l6FQCIRQ2OkBskd2YKdOEJ64iGDTXISml4WG8IQRRYlU6XkQRZHjFhdlQ1PleATSva5ACVVR U7kdIMkNHCHX/QqB6mbCUz6KCETf50n6r4t9v/wXWP4Udy6ZggHcvWEta5Z2k/wWkE/Quq6D Ly+ZAnYbbTxTqpfvh3WP3c2Chjizbr0T1pzLrNXOTX/4h8QKQOp1NmzceoERBSpeN3PT2lau fXEnf85L0N7GJ29oopUV7OpbzqsPwJ2d5zAvJWD5re18Zn6MQiFKvb8i+DgH/K/Ge4QqL8Fl D4W3wAtRLuWWVCg7R+bEOwy//ROMSDWRqVeXy5faO9OR4GkDpYve4i+EKyBKQqNsWXIvuf93 /R3F164wk+kBMvtfJb3vl1TNvZ6wf/T6BWECtLqvrXw/jKsr/2DMIOBuw63KSvaId8WLZ5er hJWH1pv47I03EgKwW2j/0prS7eA02Lizj+8zp3TteMd/AC1EPFPZ5TffCYs3snHFNpb/0Z0Y oUbubO3kn3+wkW0sZ+Os+Khd5/vhqrY/YNkC3/zk4/zwzVBjRaWVqKQ5eA5j5SCtLDKfQhbS SMfylAaBchxkuh+ZT6NFWtDCdWUXtBCgHKSVxsmnkIUMSjrFXkodK+kgpeubEEjX9KUUSkqU U0A6ljc+gSxqQNJBFjLIfAolJVZmkHzvTjSzBqN2IsLw9wnnhD3IngPH6e45CZ3uUj9+/s3w 0D08e2AQO3eAx/7iPri7ldGX4DKCY+nPBDrzZWFiWyRKN+PcfNdaeOBaHt6yh2QuR9+e5/ja TQ/Ruu7PKa7x8XltLGcD923opP33WoA4H/9aOxtW3UfninbmnkcWnOzrITk4SF9fH4PJi/HQ +/hdgL9ijBGquKEvbeVdX4O0C1jDPeR792ClBzHC1QTrZxOom4QIRlG2hZPsRWX6MOITMGP1 XjsKaWUoDB6l0L8POz2IEa0n1DQfo6YZTTcAhSyksBInQGiY8fGIQNQzb4HKJykMHEaYEcza SQg96CotToFc7wHyJ97BsZOYDbNRjoVMnUQLTMSIjEMI81yP6sM+xt/MbGUjsOKJTmqB2mWr 2bR6F+0z69wy7evYvfZGDM7wg18MLEoajIuig9v9eTYs+0teemyAa6+fyyqvRPvaTbx475Jy ldAs2lfAxg2ruaLFlQzzrrsV2MTqP/zYOX7oJs1LW1l1/Uwe8K60retgy72LLvWJfPwXhFDK t0eMDaqU84BwF/vC0FGGd20hs287zvBBpJ1GGHHMmulEZ19NdesfIIDB1x4nuec/qV56F3VX fBpQWEPHGOzcTPrd7cjMcYSdRJi1BJoWEG/9JLFpH0WYYXKn9jLc+TNQDtULbybcNBel6Qgl yRw/wOAr/4BZN5naJbdjxsZRGOpheOcLpN99CWe4GyXT6NEpGKEacr2vEZv1ecYt+wpmdQNQ aeryMQK2Tc6GUGjkMmvncmSBeOg3YbaxySWzEI4T8rd5Pj5k+F+5MUN4QgKQNoWhYyR2/pz0 /hcJNc0levWfQjCOPXiY/Im3MCIxNNNE5vLYhTwoByMUBCUpDBxm8K2fkO95i3DzbKIz/gx0 k2zPLpJdG1BvZzDrZhKsb6AweIRC734CjbPQAhE3bwOQTg5r8AjWcB96/WSE0JCZYYbf/Amp d7cQmryE6Me/gjCjWKd2kd61GRwLEY8gDLP8TD5Gh2GMuiAbodAFTU8fHAxC8d9c7z5+t+EL i/cKAbKQI9v9Fsl3niM0cSE1H/0CoYZpgI5snoY9dT5aIIpmhsgPn8LJFDCrJ6NHa5BWjvTh HWT3/5LQpCuo++gfEaifDGgE6xqw+3dRGOzHGT6KjMVw0qdRsoBZMxEzXAfCdVgrK4OTHcAI VROINaIJRebULtIHthJsmEn1wk8RHv8RhGbgTJiEVIpCehd6QHcjsXz48OHjPcAXFmOCKsU/ CelgDR0n09MFukbkI9cQHOcKCiUVmhklUOuGpCpp4WSHUXYGPdaEbgYpDPeQPfI2IlRLbM4n CYyb7IbfCoERriHUfBkyuwPHSiLtLDLVj8rlMEL1EIziZdshc2kKQ0dAD2JWTcCRisyxnShL Ept1LeGmWSBMlAJhmGhmCM1sQAtXIzRfo/Dhw8d7gx8NNSaUaTaknSc/eBgnccJ1ZFdPQAhv GoWbpFdMeFPSQWaGoJBChMahBcM4ydNYQ/vQI9UE6l0hUwqzVRLlWCjlRaRIBzszjMJGC4cQ opybYWeTOAP7EYE4es1khNCxB0+jaQIjNg6hB72oXoWTGcIaOoJujiMQbgBfs/Dhw8d7hC8s xgg3Ixt3sS5kkXYGLRhFD0VLOdjufSj6ApRjYSWOYudOERg3GyPWgLQsZC6LbgTRzZhbQTmg wMmlyZ980zU7VU1C6BGcTBJhCIRulLpHgbRt7MS7aLqGGR0HwkBZFiIQROnCo/rwQmydLE7m FFqwGi3WhND9SCgfPny8N/jCYqwQFYl4RgAhAjjpBE4mgVCuZiCUQjoFKGkGCgoJVH4YLVCD ZkRBF2iBMMrK4uQHQSmEZqDsNLnBI1jJQ+ixKEasHqWZ4BRQjgOa5obFagIlHZxEL042hzAC Jc1GCXAsq5z/IQQoiZ1MIQcPgRFBj9b6PotLxPkoye1cjgtnKuTo2vI0jz/5HId/q+k1bJLJ D2+Agwe28+Tjj/PygcGz39s5cn4KyG8UvrAYK7xEC2GYGLFG9HCcfH8nmWNvUhg6ijN8kszJ vaQPvEHm1D6cfBqURGYyKGWhmUEQAi0Uw4iNozB4lMyh7RSGjmInTpHs3kGq6yegNRKeshQ9 FAUlEZoEK4s9eJzC0HGcxEkyR3eQ2r8Np2AholGE5uZdaEJgZ5PYp49SGOqhMHyCbO8hMt1v kzv1DiIQQgtV4UdBjRGDXTx4+8IyffdfP00f56Ekz3VxQzjMA9tHIQuswOFnV9N6/f28+st/ 59f7RjJF2X07uL+iT7HsHl7+0CSKzeGuPQx6i3Jyx99TVRVm+4U42seEJM89vLKCDn0ZDz+3 p+L2dj43cyn/3wuv8uqbp856v+OBMOEbnnw/BuLjIuE7uMcIJbw8Cz1IYNwMIjM/gZUZJvHW Tykc6UAZYWRmEJRGZObvEYg3IJSBoxyMcBQt4gqLUP00orNvYvitZxl882lSh36NZgRR6UHQ glTN/wNis69FD8UhkyA46SoKw6cZfOMHpA/8EhGKoHIpCv0nMCMNBOLjELoGuklkxiIKg3sZ fO17pA++iAhEwLKxhvoRAQ09FvZozH1cGMe5v66VNW3r6OjeTH32AI/+1UYODt6GGWqjNVSm JC8lw4fm8lhnB0w9f3hronsLres28ui9C0besA+zpnExDyxfT2fP7Uw0T/HD/zmXa6dm2G09 ypwP+tea62Rq62K2JRRL4hCft5yOjls4B1PIe8L2B9u56T54qqOb62dFePc/vsXSm+ZCxwB3 Laolt++XbGUdie/fSxzI7XhwxPvk8d10frHp0gfi46LhaxZjhCifPYQRiROb/XHqlnyR4Ph5 WBmBTOUxaidTtfDTxOcuw4iNA10j1DSf8OxPE4hWAwI9XE1s1kepW/o5Qk3zkSkHJ5HHHD+X 6qtuo/qyGzBj4wDQQhGisz5OvPVmzKpp2GmJzNqYjR8hvuD3ic67kcC4maAbaEaA+Iyl1LTe QqB2LnZKIAuC0ORW4gt/n+j8LxBuWYBuBM73mD48JLv+gzW0sW3TvSya0syUOdfwzWceZUnt +SjJbV7/9l/wXHcWsNnx+D3lw4oefI4c0PXo7bSu6qTzvlbEskep1EGSuzfxAG10fOcuFjTX Utswh5XrO2hnA893DlKmPL+/1O7DWw57tUfvD3I8ec/t/PX97q7+wR2DHH/5URYWd/gLV/Jy nw0kefTTiwFYWiUQtz9Okn4eveNbdOeA3A5WLrydv77HOyzp1gc57Gkg9vEtrFxYbG8hQqys OHgJyHXx7fu2snrzRm5bNIXaeANLvriWTStg1fe3kzrwNOHF9wH3USUE3/7ZxhHvH+1K0vP8 3/D1XxwDYHDHkywrjv/2RzluA/ZhHi5pZAt5fHtfqe+VC2/lnttdbWbH+6Il/Y5CXQRk5Wvp uH8Vd+SIEsXrjlJKKke696V0lCPdklIWqzpKKa8t6SglpZIV12RF56WepPTuS6/nYpuOcqSj pJTeGCv7cirGWB5bZbvqjGcqvio/oaMcu6CcfEo5maSyM0nl5JJK2nmvPW8MhZxy8hklHaty 0pR0CsrJp5WTTbp/+bSSTqFyMsptWFnl5FJuuVxSOfmMcvJZ91+7UFHeUdLKlctmk+57K+e2 b+Xcef0QUZz/iiveNVl61PI8O6o4d+4nMnIuPkx0PtKmaH1EJUa9164A9di2btX90noFbWpb QimlEmp9K2pdx4BKdD6ioE290J1VKrtbrQC1vjOhrOyA2ry2VbF6k+oZSJzd7ll9um2u3Tag lEqoR9pQtK5WHb0DatsjyxWsUPstdc7+SnW4W720e7fqGbDU/s1PqM27e5VSA+qJ5ajWddvc nvZvUtCqNu3uUb0DWaWyHaqt+GzZDtUOqn3dC6q3t0OtALX8qf1Kqax6oh3Vtn6bsqwetb4V 1f5Ix8gJq2ynArsfa1ewXg0opfZvWq1grdrd06sS1tnvO9a3qdZ1HUpZ+9UKUCue6FCJRLd6 at161ZlQ6qW1KNofUwNKqd6ORxQsV7uz5XG3rt2kdu/frwYs5eMicVGKbdmQoUrsp2XIEoG2 QisxqxaLa8Uj4ESZervcQFnRKbKxnnVCg6is4trqpaok7S6T9ImSS1qU6VmF24+A0jGkrmXG OyQIDVV5sp1yn0CJ4pOUHd1CN+BckUUKEJrrqzgTQiCEiQiMVnckBYcQGsIIjdFgqCGMIMIY 2edv1PAkyp+98uZZCIEqfZCSkkceKH4HKqkUfxOw8kD9OW6eh5K8iH2vbAb6+cW/PcwbDLEN 2Ld1H3ctWERLdT2twYk0146071j5xLn7LHbdD+seW82ihjj86T20ffUvOJ2F4XP2Nwv6Ye22 NVwzp9Zt5MY/gu2/4PHHD/N2D9Rf5X4P4y0TaaOeiVObaQhRJNUtIUEb/+uuZTSE4M/Xt7H8 4GmgkUICZk0dh2GECdZD04TRH+Ksb3ug/Pwt08a7/zY3EAfMM94XYfe8yQba6PzsIuIhuO3e u4Akj24FWt7lnx58EPIHgE76LJhjuuPe8Je3MMcn1r0kXJwV1FvPinTZ7m+9fOqbRHiHeXoL svByFJTCsh2kAkdJHCnBK6vrCg0N3RAYmu6tFBW0VcWFHQ2QKCUQmru4I9zbAoGDwrYlUjoo BY7CDSEVAk1oaJqGoQl0TaBpFQcUKU/IlYSfGxCrhHcsqSrThislcJTEPcWuggZEuGJIKwkW vPkpEptzhs9AnSHEzrFEnknfVclcfqYP4r2U/ZDgMuUWNwKu1BDeRqP0+XmfbYlqvXQux9kb hg8Dk65og1W/otteyYIzfiUXpiQH8gngZj553XWYhQLXbbuN8bPnnV2/AtOuaINVO+iF8gKZ 3MUznXCrWTEIc5RNxjn7s8gDwVKVHM/eE6b9oRU8sfmPmdMCb5cezKLf/QfOsbCOvGcCYWKz YEP7TDYArcvX8+MbpoxScyu/2pdk0aLik9ns3LwR1q6gFs46EOpcc2RnU6Pf74flf3wtn7w8 SrpwNds67mFeGEqhaed5Jh9jw0W6zCSl3bl3qIKqWIxExQIMAsdR2I7k9HCGAz0D9PSn6BtK k0jlUBKikSDjx8WIhE2mNVUzs7meSFAvncvg/luhdSjh7vRVcSyuozGdL3BiIEX3ySFO9KdI ZwoMp/JoKHRDp64mTnXYYPy4OBMb4kyojREwNTThhqW6Y1YoobzFv2Kh8hbzXEFy7HSS/kQO Q1PeIufeC5kGDTUR6qojGFrxlLyioBht0TtLLRsd51rkR7v8Xsp+CHA3DJ7ALQqHknQtQlLW DYsVS6rIb2TsDVfdTDtraP0/r2f/N9qps47x/b/9AUvWfvO8LLPFUy4mXdEGbIXxq7lmSpy+ A3tIXODnVnv5DbSxlK/cfzMb776BuN3Dj/5qKVtZzWOL4kDSPdnuwe/xx9/5Iv0/+hZbmUV1 GOrP2Z9F+eQNgCx7HoLVL3yDLy6DRx+pGEB8PMvYyvOvH2DeVY3Ez/Og5cU6S/8+aFu9nj+b 38z4GfOpO/MxQ/P42gr4/OI1XNG9hquaYNdP/pbPb4THdl9+3jk5E6GZi2nnDr7/4y7mfXY8 L37vx7R88U4mLIWNvzrJ39/5ZRpIcmD/AGEDxhDH7GOMuChh4e62i2/wtvXFLOfyGW9SCTL5 Am/tP0XXwVP09Axz+HSGI8MZepJZjmQchIKGkM6M2hCxgMmU2jAfmVzPkvmTaJ3RRCRkIJX0 9pwuykJKYNmSntNJdh7q450Dp+jpHeLYYJajiQKDOYsjGQuEwNQFc2IhasMaE+IhJtRGmdhU xdSWOuZPa2RKUxWaplFiwhCeSUoVtSaQUnH41BCbfrWPnftPEgrouOdtu9pGLGxy5byJfObq GVTHwiipitOCKB5jKn4XYwqEt72gRK/uwt1MePsNV69SeGYqV7zKUgsfMkKL+P7uTXxtbjsz N7iXWlc8xp/E4eQYqjdcczeb1nZw/dTiadqtPLV/OzNqjXMLm/gSftT5FHe0ttNSPPuobTXb etZS3KsHE8CmrzJ141cBWP9Cjxsldc7+zuykllueWs3c6xt5AGhro+K87yl8dn07114/kzWt 6xnY/nFgpPnIPONfsMn3w9ajh7ixZpjN6z7P9ayj9+17K45xDXHb+v2sz3yWa6c+VBrf+hf2 8+U5Ywu1KvVnLODvNq1lZnsrDwG0raP7ToNb/t8O7v7EYhrNO9xyy58g8f0pJQ3NT0O9dFwk RXnZrq6UKplXRNHkIqBgSTrePcHr7xxhS+cxnj8yjJUsEDMUtbqGqemYmitkHKUo2A55pTHg OKCbtM9r4HPXzeGTV82gJhr0zFmeOPL6PD2cYfvuHl7uOMy2A7282pNAy9nUh3WimkATYHqm JonCchQFKUk5DglHYQaCLBwf52PTx/F7Cydx1WUTmdRQhfKsQ1oxEc8ThsOpApte2cv9T3XQ 3ZsAU3cT7xDoAIbGHy6Zxvo7fo/GuiqUkhVmJ+Wazn7HQldLGqb32bmTq4pZgyMLS1XeiHg2 vNE1sg8XuVwOwwhxMedFFZP0Qu+R0jyXSwLhMyjSkzy8sAo2JrhrrkmO0FnMuGPuz86Rs0OM VszO5SAUGttOMrkdUbWUzb2KGxug7+UHaby2i93Z74/qI7BzObIWhONjbP+84zfOopAffd58 vB+4xBlVpS1faXcoBAXL4ZWuo3z/hXf4lzd7ELk8s6MGxA0cpXBQSAV5hLe5VOiGRgSNeEBH oNiy6wS9qQI10TAfnT+JeNg9DEgpiVIaQ8kcP3vlXb73y/386tBpGoTDnJCBEzRxPLOPVIp8 cXQK0CGoGYRMgyYBGoqek8M8fHSA/+ju429sh/qPzyUSMsq+GE+jcST0DWbo3HeKI6dTzKsN UXDKT64DAzZYOQunIEfOUdEX8TsmKCrhrv0Ka+gIheEezOrJmDUtFLVRa/g4VqKXUNNcVDBc mndRsTH5TeG9LvSVMMa66J7V5zl23J0wnLHBiI9qgh9zf8bZgqayjTEjPpunVrdxU2P5M1q3 ufuczmQjFCL+fvgOzjH+c86bj0vGRQqLSq+p5rqclUQTGnnL4bnt+/n7TW+xrbuPOcEATjRI XkmkdBcAXZQXAYVCerZpTShs6Tqy6wMG+48M8vB/vM3/ZWpcd/kUd4OqafQPp3nihV18Z3MX hwZSzIuFyCmdnCORKNcqXvJ1eP9TrqBxlAB0bKXQkERNjVmmTrUUZCy7ZEsXosI3ImA4keHF rsNs33OSegOytsJRlMxjDgIpHVI5ixOJDPX1VQTM8pLnbbEvTWBUKoHlhxutYIXj/EL9jeZk P+P+qP2MqDRKeVXaSxS9OlbiFENvPEvq3X+kesn/Q83lt6IZJoXhPk7/6ntoFAh8YjJaMORt IkRJUz3n2Ecdw39VxFmRSMBv1ZkWtdz2zS1Ya5JkLTDjowsxH//745IM6MX1TynQhEYym+OV d3r43s93svfYILNCOnmhyEtPIChXOgWEhq4AKTGFQhe654RwF2YJWEoRDRq8dKifzn0nGM5k ERoUbMmO/af4zvO7kNkcMyMmGccVRBKBjoEhBEIqlCPBdtCVJKCBqenoAkCiCTeEM68U6VCA z189g7YrZxDxwkZK67JnNklk8nTsPcG2EwnqQob7zOVZACEJCMinCxw4MUwqn6csJMY+o2pE BVdwliyFonzNHdrIsi7brRpRt9QGckTbShXbFVT2o4pmonMOvNjKWBZoL4KttLdwQA9iVLWh h+rdNqTCGuojt/+nIEwQuhtJJ86wVKlye7/LCP2WLsZGKE78t3RsPt4fXKRmUQxpLO6rFQXH Ycee4/yPf3kNu3+YuFDkFUil0IRn2tcEJ6QiJgymTYijCcXu3gQB2yYqREnz0NxtPbYjaRAO P+86xryZ47n+iqn0DaZ45tf7OTqQZHrAICuLpjAHlCADWAGDOU0xasMBLKnoT1t0D2Sx0lmE JmjQBY5QKKlBQOeziybyubaPMLmhyl0Ki4uop52kcjad3X10dfcTcByk0JGeA7wYDqYpQVAo knmLd08MsTRjURcLl4XKeTWBkXOrUC7LbTF0VDnIfBY71YdTSIAIYMbr0UM1YATcMXh5Jcou YKVPY6cH0TSBHqnFCNWCGfRCUd1PzqVEd5D5NFayD6eQQgvFCcSaEGYEhI6y89i5ITQtiB6u KjnnFRKVSaFkBmHG0AJREAqZSyHtPJoZRBWyFFKnUcrCrGrBjNZjxhuJzrqS8IyFhMbNRNPA zvRR6N+PCDYjggZ2phdQGOEqnHwWaafRg1XumCq1M8fCyQ2DUuiRWoRmlL6XPnz4eP9xcdFQ FYGORT9FT1+S5944zKFj/UwMGwgdlBToQpR23QPo/OmiCVw1t5lx9VVoKA4fH+DFt4/y0t7T RDUNBxCiGDkE0oFXTyS47eQQSkHfYIp3Dp7CQYAGWilcxo3XX9RcTdsVE7ls1niCZgBbQjaX J5nMcPTEIK/t7+f1w0NoloUZEHxqwQS+0DaXKU0VYSMViWQSjf6hLK/s7OH1kwlmxYLkpfKM bwKQpfAsoekU8ja9w1ks2y49Q9lqdyEzVMU2uhhm6hTI9nWTO76b/Ml3cVLHEcEYgZpJhJoX Ep58GVowhlASa/gEuRP7yfa8g5U4jDACmPFJhFvmEm6eix6to6hJ2Kl+cn0HKZw+Qu7UXmS2 D72qmWDDbKJTFhGsm0R+uI/0vi0EaluITvsYWiDs1ncs0kfeoHBqH+HpSwm3XIayCqSP7aTQ dwA9EMVOD5M/vRchC8TmfwZ9+kcpJE6SPSXgbh8AACAASURBVLGHQFULQphYyX7S+7aS3vdr ZCFH4cQRhsTzmHUTqZl9HdnTB8gdfp3Y7N8n1DTDMzC6kWWFoRMk9r6AEa2jas71iGDMlxU+ fHyAuDQHt7cDl1Kyt7ufx17rpjGgU5AKJUEKb1ftKKRhsnhqA1/4VCtLLpuMobm/7WS2QDgW 4aWDgxjCQUiB7SgsFIZp0jwuwJx4hHg4QLZgcfx0kqHhDIZSpV09gJQgNY2Zk+u5fulHaJ3W MGKoUipODmeY+vZRGt44ROfRfqyISfvVM5k/Y4JXSCE0VV6UhCCTs9l/bID93X2IbAFCYZyC l1khvIx0KZHoBAWczhbY35vCsdxIdFHSvcborvC0BHcT7WANnWD47afJHHgFPdSMFh6HMzhM /ugW7PSnCDROQQ9GsNN9JN59kVTnRpC16OFJWM4QmUOvkT3SSO3H/ozYtKsRRgCZTZDe9yuG O/8NO1vAjE5BGFHyR3aSO/gzdPMvMGK1FE4fIfnmI4Rnf4bIpMUQCLtjtAsk924ls+dfEbEH CU2YhywkyB56g+SbT6CZEURsEnqwEYlE5pJIaZE/+Q6Jbf9IePZnCU6YCfksuZP7KfQeQSkT pyAQPQfAtnGmfZR870GGt/8DenwqgXETEHoMhEBaWdLdrzP86/9F7MqVSMf2wnI/HFnR17WF DmsONy5qfh9aG+TlZ99kxqeX0fybDuCxc6NGWL0fqJyzEfP3Afbp4/3FJdJ9uNnKvcNZdh05 zcSAjh4IIYSGrRRI976mScY3VHNP++VcNbcFQ5Rt7rGgycfmTuBjc5roePckBQQT66O01ASY NbmehbOauWxyPTOaa7EsRcaS1NdEyQVsqkM6luPZsD3BkbQlpxMZHCldrcYbraYJxleHueVj 01k6bzxv7utF0wSL5kwgGnCPRC1ThHhucqVIZnJ0HOjlZE6ycGINStMIFZMGcLPPpWfnNzSJ bikiApzSuCrmbAwrmZu9LEHoSCtH9mQnVu9RIpOupmrRZwg1zMROnabQtx8RrsEIVyNzKZIH fk12/3aCEz9BfMEfEKqbgpMbIrlzC4m3/pHc8b1EJi5GYJE6/CZDnT9FM5uov/JGwpOvwAjG yPZ0YSdOEpq4AGlnsAYPI0KzMeMtoBtl17Xj4KQt9KqZGJEql3Ilm8ROnUSZDYQmX0H1VbcS qJuCtAvooSq0QAgKNsouYMSa0M0YelUzNYtvRaZ6kKqO+mu+QKBuqnsMrBEgUNuMUX8lhb5d 2IOzCYybDlKR6+smufvnBJp/n9p5N2N4ETDvu6AY7OLBu5Zz38ZOANpXP8U/ffM2l6I8vw31 fgiL5Ltc2349LyUUzWf4rQ889zCfvWkVneDmEzx/L1M+wEV1xwNhFm99ArXli5A8Tle3xdwF U97bIpHrYmW4lX3rXmLLvdeULlfOWeXrEX36+K3GJfksSr4LoZjaUsdXbmqtcJeCVtrqKWZP rGPhrPEEDL3CMevmHdTXRPmDK6dThSIUMrl8bguXT29gSlM10YhJwDAwdY1M3mLWxFr+5IYF WI7EqNiqF7vSDEEibXFqMENzfQwly25dITRCgQATx5mMq46CgFAxeF5zXQSuwlKOBzZ0jZkT avjCNbPdsXuO4KIcUqWIKFcbcaSkJh4iEg0VOy15eC689S1mjxcLCXBspGOBlUdmkziFDEa8 AaOqAZRAMwLkTp8gu3Mzdj5P9bTPEahuRAgbPRDGrB8P4UacdBrl2NjZIVK7fwaOTdWiTxGd fjVGuBqEIDJlMcqx0Mww+YFDWEMH0cwqzKrm8oFJSmFnB3GsFEbVeLRgBCEEdiGLNXyI4Ph5 VF1+M+EJcxBm2HtmzT01MJPAsQbcA5gC3jnlSic/1Elo/K0Ex01GC8W9iZUEaydjVE3HOtWF nfo4gXHTsTP9pLtfQ2ZTxFuvwaid4B0Te4mRZmfhAhTl70Oal22DEY7QThtncQHndvCVm1bx pRd28+IVYV7+4VayWeADDISadWeZBjy377u0Lg6SUPe+py77Xn+GDQD3baTrrmtYUPR4V85Z xevKPn38duOS9inKo8Oor4rw6aume/m4RU9GRUKVUhi6gaFruBxMbtJD8bcdDQX41EensWRe C3XRALFogIBpYGgVwkBBKGgyd8o4Zk2qBY8jyoVWLuQtyAHDXdyEdnZSl6YJIkGDYrSSlBKh FU1LWjnoSAjqqsLcvHQGjrcWlYxKqlIIFbMF3Fua0DAN158hKrSbC8MtK4V38p6uY46bjlnb QvroTrIDBwhNvIz4jGsItSzACMdR+QTWqXfJp4ZA18gef4PCwG43EkwInORpRCGJwgFpYyeT 5I+/TqDpCsItCzAiNa4rRUmEHkDoAVASVSggMycRwWr0aCNo3ldFSWS6D5VPoEfq0YwgIHAK eZzhdwjOuYZQy3yEGS0HCnjz5aRzaCEdPRj0TvEDJ2+h0oOIiAnCwM2Gd7mkjOpGzOom0ic3 YWdSoBzyA8dIvvMUwaaPE//IJyAQKgvj9xEjKMrjAM188xl3p7yjstyeZ/na3HY2AtDGY9v+ jS8vaSDX9SjhVZDYspI40PXorXw9v4Zn7loEyS7ub29lzVagFaCdNZwBj6epuqae2toGbln5 Ze+GzY7H/5LFd7iZ0MvXbeaf7r2REC519+cWf4mtAMsfoeexlfR/91ZW5dew5a5FkOvi9vDX uSfxDIviOZ685yvsrIvwwJoNrOsY4JbOv+Hr+Xv5V2sz4cXuiKrEfazvOELwLyZz+H/28M1l zcBx7hctNHYmWLmgUpTk+PnfrWHFE5uo/1I7z7z+DRZcM9IcfCZ6nnf7fGYGPHv/HbSv2eTO 5Oqn2PTN29y5e/x2Wv8lwvL+DWzshBWPbOMfVi7BOMczN3OYh++4hVUbO4FWHtv2C7685Pzj 8HFhXFLorECQtx2GU3mS6TzZdI50OksmXSCTtshk8mTSBYRwk53dZGrBSJ4nMAyNxuoIM1uq aKyLEgmaGJpAqmKIp/T6A10TFPIO2XSebMZy+0nn3b4yBTJZ928gkaV3MOX+DRT/Et6/w/T2 J+gfTpOzHG9BVygh3aQ/XA0hkcpxejBNIp0nk816z5Yjn7cwhEbANLALkky6QDpTcPvPFEil cyQyec9EVhH6OhYoV8MRgNBNQg2zqfvon1Bz+c2YkWryR3dx+lePM/jGJgqJXqxcivzAQbAU uhHESZwk338Ya+go1uARVD6NUTeD0PipCAPsoWMgagmMm4oWDJeEn0KgpERJlwVWWmkK/W+h BUKYVeVzu5WSFAZ7IH8ao246RnycW9eyUY5CDwcRmu62K0qxXTh2BqeQQQs2owUCJY1T2gWk A0YwTJGLS3hfTKEZmDW1yEIGK5vFyQ2RPdKJcHSi06/AiDYgPHPh+43uV/4NWv+YeefdVh9g zdx2etZtZiA7wEvrq7hj6f9gjw2WlYet+VJJK5/gkEfQtOWhVtb0r2V3by8v3Ll89KbjC1m3 upWvLm5k2T2P0tXnVk52fZfFd7zNC91ZVHY3kftuYkNXEuwD/NXiLzHriQ4SiW6eWpCnP+v2 218ihrLoIeHxOlkk397IA2sivLR7N8unxckkejg0bBGa80fs37waWMvunl5unzeJq25t44Fv PE8OyO15njW087EzT0UafJ0vbWrlv3/2Fv5kfRtrNvz8TOLas1DsEztBqnE5+xMWVu9LVD3w eR7r8ugF80nYuoHrN3TT/dJ6Nnx1NR1JzvnMLz8wlVXJexhQit6Or7mfyW/18bX/e+CSkvIU 8O7RAf795b0cOHACTRfeJtILkFcOZiDIFz61gKsXtBAJmIwkh1Ne8pxbXvPclEUzj1axK5dK IpTg1GCS723upHPfKUK6KLHNFs0QSgqEcNx6QkMgvfa8tvFCRzUYP6GOzyydyeKPNGMaGoqy UOpLZPnRi7vZsasH2yp44bwCRwgmNlXz2WvnEIuHeWrLO+w72IeG9GSgQCK4bGYjyz+1gOZx 1YzMDzjfDlh5PFTucysEwggSappFoLaZ2LwbyB55k+GOx0nv3USwtoHQ+FlIKw+6IDrt48Tm tiECFZFBrpMBPRhDMzUcKwO67moRRaJEL/mt0rro2Aolc2iBAMIMl0YtZQE71Y9TSGDEmtCC VYCDKtigdDQzMOIbIoSGVBJ7qAeVGcCsnoEWirrz5OSwE8fRAvUY8fqSqculdHE9QoG68RjR y7AHj5LYkyP1ziYCLVcRnbYEYQZwtbf3n2/rvBTlRfQd5iHa2HbXjdSG4JoVq2ldtZRt+7/D 50w8reFMJNn5NKz+9p8zp6GWOV+7l7ZVq0ZhWQ1x4zffprv9ab654vO0PvQdXujpoOYcVORf qzo4CnX3SC3oLJxBXV7mvDJoaRlJER6/7W5Y1c7ryS8TffZbcPe3yiYmDwde2AB8iUkGmEtu hVXreP3hL3LNWfxUo8CYwhfvNHn5mR/yi373kCMsL6LwHJTw75mu3E8CuSRcms9CQW9/ih/t OMqeg70oTQN0kI5nspFEQiH+5IZWDKHjLqQuSqcWlJuiaKsu2qfK+8WigBFUR8PMmzqODa8e 4VTfMJbLuYEmXNOW24Z7TQk3R8EVXsUdqAJNRwiNmng/qVQe09BY/JFmQEMIScGWHDw+wObX DvGfXSdcC4xwI65qwgH+W2M10ViAdD7P28eGePatEyA8P4aSYMGn84LPXmuVxq/A45i68MwW ze8qn6SQPI0WimGGqjCrG2DK5eRPLyN3dBuykAIjgBFv8FIP0mjBKEbMXeWUYyMLGTQjihaI oQCjqhnpDJPrPYCVHkQLxV0TVS6HZSXRzDhmuNoV4pqGtHPIfBoVDKGcAvnTh8mdPIyyMhiR OvRgFCefxBo6ghZtRo9Wg9BHCF6kg5XqQxWGMcZNxwhXIYRA5lPIxClEcDwiGEU5lltDN10y QQRGzWT0usvIHnqF/PEgemwKVfOux4hUe/P1wcQ/nY+ivIhc/xHgbJK6unDYpWXtPMQArpvh zDLhMR5YOGXJbTz6di8zRCP3PN3JY4xORW6fcp3w56L2BsAYOYqR1OUjYcEIYWc0t/FIK2z8 0dNE7utkfedVZ9QY5KffcY1xLeZ9pas/fuEA19w248IPmuvi9nArPXev597PzGHamWMpooIS /j3Tlfu4JFxybEXBdshYkjnVYRxPm8A7A6KgFLGwSXN9hICpQ9ExXHKDl1+75m3vvkf1UEkb LlAoKYiETNqumMY/mCY//OVenu/sISoUEV2gKYWjBJbS0Us7dO/XUExyK/YDZAoOP3rjGPMm 1zJ/xniChoZSGn2JFB17T3CyP8WEmElN0EQqh7TjUFcf47r5E5ncVMuJ00nmNMV5p8rNQDc0 1yczWLDJ2xb5vOWZYySlDPXzQniCwg0PTXV3kN7/Cka0lvD4GQgjSCHZS+HkuxjxyZh10zAi dQQaZ6OFHLIHXkUPxgiOnwbSIX/6JIXESSJTriQ+YylaIIxZ1UCwYSaF3sMMd/6E6KT5IB1y fYexhk8Sm/spjOlXInQdLTQJq+8gyd3PEWiYgswMku7eSb5nN3qwytUQhI7MDWOn+zCikzEi tZ7/p7wREApkZhAnnyIYrgXD/eU6eTeCCscmd3I3AgctVEN4wkL0iOvoNqvGY1Y3k937I0Qo SvVVXyEysRUQ5Qz0D0BejIWiPDRzKcu5g2/96w4e+/I8Ov7123SygtktBvG6JbSyiq1da2g3 X2D5qq3UrwcIM3sZ3PTAD/nq03/Kwe8+yFaqzhImyT3P8o/bYtzxuY9h9HbxCrBs9ngmRdsY jYp8dOrulUSqquhc9TQH/o9ZDP/o2yP6GkldfgY8YdczmKQlHCceivOZdav56k2fB1bTvWCk Cco+/DKrtrbyQm8HyxrcZWXHw8tYfP9PWXPbXRec71xPFxtp5aW1d3H1wBYegRECYzS8Z7py H5eEi9PfVfnXqZCkHUnBcWk98lKSdaAgIWs7FBxFKFDM/C3vA5X3n/SEh/LOvnC1ACgeeu26 OdzFR/McyfFokOsun8zdty7i4TuW8EfXfYTq8bWcyENPxqZXKixHUFCCvBLkHcg6iqxD6S/n hb8GlMWeo0P0nHbto0opTvUl+PmOIyRyNqYGWUdSkAJN6DRUhRG6xqmBDCeH0hQch4JU5Gyb vHQoSJdCP5W16R1Mky1YnpmNMSxqxcAAXIGrmTipbtL7fszgaxsZfPUJEm89hQhCbN4ygk2z 0YIxQo2zqVr0FfR4Lcl3fkz/qxsZeOOHpPdvQtgp9HAtaCYIjWDtBGqv/G+EmiaSObCJgW2P M/DaE2QOPocwDfSIS1ht1kykqnU5QsuQeGsjg6/8C8ldPwU7iVEdItA0CREMuMLdskBkMGua MaLj3LGrkssfJRROPoUWsgiMm4YRrnHNjsFqzPqJKOsI6b3/yXDnv2P17kVJy5sKhdAM9GgM TJvghN8jOv0qtECE0tcEWaGBvo/wKMqXb7iDmY111LW08t3MbKbHK+my5/CNF9az8Y7FmCLM 0jt6eKzjGy5leHwh69a2c0drHXVzv1Nh0TL45F++QPumr9Johlnxq3G0cfbuOFwVo+uO62ms ClM383pYu4m1NzZ71OdVXD/V1c4aZ/4xbw7YJeruh77USjjcyE3/NkxVGOZ87n7u5gFmVlWx +BlG7auISoEVn3cDq1sfYm5dFf+4yz0pvPkTt7EcaF9/W4kyvYjdz/0ztN/HxxrKq3Jr+93Q +V3eTY5Oc175OjTjJh5bAddWCcyp17PJm6szy4/AqM/s0ZV33kGjKRBmFTP/5tdkz9WGjzHj 4ijKi6YjBZu37+O/f+9V6hIZbARKSKQSGJqg4DjEQiY//PotzJnW5JmYivJJljilUtkCR/uS NNZGiIeDGLrmLTRqpD3ay4CWbmo1QkAmb3Ho1DA9p4YYHkxy/HSGXScTvHV8mEO9abBt6jSB zcgkPjTQlcIBFs9r4f/+k6UsnN5IIpPj2Zf38vWN28GWmJpys8VxT9ebND7G4mmN1FWFGUpl eefwALuODqAciS40hCYYthyaG+LcfXMrNy2dSWNt1PObXHgLXMm85GSGyfXupzB4CidbQDoK M2wSaGgm0DAdI1ztzY/EySbI9uwh338Kadug6ZixMKGGqQTqJiECIc8MpqMKOTIn36HQfxI7 WwAhMGMRQhNmEqhp9iKcFHZqgMzRLqzBIaSSmNEIgbpG7EwKIRyCE+YRqGpytZ3efaAFCDXO 8kxEmqtRoYG0SR/biZ3qI9x8GWbVeE/7tMn1HiJzeBeOLdGCAcJNkwk1TncFggRVGKLvV0+Q 2fskVYu+Ru2iW9GCsYp5Kh/f+0HhwhTlNsmkPSrtdi6XxAjFR1Hh3TrxC1Cw5nK5URlWz0lF Pip199j6Ohs2Llu519bgyyysu5avd1vc9gElfLwnevRyJZ+u/EPAxc1ixS9TSDefQqNiIRea d4SB+yM+ejrFtIkNhExROpeiGGKaLdhs33WcH770LpdPqWHe9CbmTW2gNh5C1zRP4/BOshPu mRDJTIGhZI7mcXHCAZP5UxqYP2UcUsJQpsDh3iGO9Q5zqneYvYf72bK7l77BNCGPykkqiaY8 bUe5lCSaZzXZd2yIZ187TKZQoEY3sNG8PAqFoxR7jgzy6v5+bKkwdI0aUydqCNA0pAIdSVRT iLzFoVMJktkCjbXRMU2rayErOusVeqSa6NQriU4drawsvVJoaOEaYjOXEpt5dpulj0y40UwE gkQnLyY6efRBFIMAjNg4qua2nXfMUkEg3kQgXhkrX4yxcgWZ0Ayiky8vPyPukbRgEGqaRahp 1lnPppRAYJE68ibZg68QnvRpojOXoAUiZ0yYKLX6QeHCFOUG8fjoP6VzU2afu85Y+j4nFfmo 1N1j62uUxkacd7Fn09/RyTqu/wAzA98TPXq5kk9X/iHgkj91M6gzMRpgeDgNepEzqRSMibIV v+zq4bLpTTTXxVDKwXVEQy5v8db+U/zghZ384I0j/Og1jaXT67l16QyumDWeaRPrqYkE0DRV IiRMZHK8uOMwO7tPc93lE5k2oY6G6iiG59uuiwapmdrIgimNFGyb46eTNLy0i4ee3Ymj3NBb DQ3h5UkoASFdxzR0snmbnQd7efNALyaaG+ur3LM33KVPI2oaVAXcHa2Dm70tK2znSoGpaaRt m8NDGfK587ocR6C87HkO/pImpCrue/e8c83L15UXiTbSiV5KMKR0CjhIT9iUjsGt1GfKGQuq dO65e/ApVNgtvWd1Hdheho3wMhuL4ylGdLmNeQLOO3NbFC2NqhTXUBoCIISikDhN6t3XEaqP 8IyrCdaXHaVCVRT+YAxRPs7AzC98n+xyn1n2dxWXLCzisTAfaapi69EBorqGU/rVu5QVtoIn Xz/K0pmNmAsmURUNIXAYSGbZc6SPH7ywhy1vHqVJ1zB1eOfgAFsODPKZeeO55erpfOLySTTU xggYgkzeZvveEzz8bCcv7+vjuj0nuGnhJJbMaaKxNkY0HCIeDRAyDYQAXdOIRUK01FcT1AW2 rdxzs5UCTcN2bPJKo6UuTG08xMETg/zizSPkc3mCWnHPDhKJprkkIJWmrLIFT4EX7y+FwBSC obzi+EAWy3ZKczWm/W/RL+w1rYr+muKW3yskRjTm+TqKi7+ASibacoPFBI5iiLInGryogiLj rpu7UOzfLaMVnQTecxdFlUIWE2hGzIlAK9V1LyjwzuI+O4LJjbwqPoo7DomTGUSPNFC9eAXh llkjkiJL7VaGj/n4QDG6Oc3H7wou6bMXAprrIlw1tYZ/fUUwK+BmH7suBXcpsZVGIJXhoU07 uO5QL1fMdM0Vbx3q47Xdx9nb3U/QAFu6SXgBHaYLxTv7T/LysUH+ORbk2sUxsBRvvnuSf/5Z F329A0yLaZw4OsBjPcM89dJuZrbUMWdKPTPHV9FYHSESMhlIFHjr0Gl+3XUEy3GIGG4OhESg KwFKR5g6s5uriUeCvNJ5mO37TmFoOpoARxYXIc0TFO6zOaWV1F0nNXTPzao8k5WOliuQ60+S zmQqZuxC4kKVtAuX9oOKLXhZEBQjxMrOo3KzJdp44Zl7SsKg2EVxMXdpWlTJ5l8KZqZ44FBl MMKIPXwxtFlAUUi6rz39wxNGxd2/+whuHouiggamGNxQ0no88ezVD4+fQ6hxtnu/eMa7KJ75 4Q1wDOHIPnz4uHRcJEV5aR9JU32M+TObCERMNE2C1DxruvRI9twDefYeT9LR8w4ZdgEaISGJ Kwh6Z3CXw1rdaA1TEyxqqWXqhGpChsa7x/r5ybaD/KjjGDOjGgqNvKOwrQL9WcnB03k2vX2c XHGn6VGIawLGCYew5h21WqEFOEIwsaWGqc219A2leGPPcQYTGWoCbvyFprn+jaBpEA+bBAwd Kb2FTbhaRsFxSBUcrIKFFGVzjTQ00tJhIFkgZ0lCpZCO861sxfihSmNQUVZUaA6egqOKZqPi Dt6TZ6X7YmR9N2BAjOhLlCqVtRVRoUW467F3fjiyIvS5rP1QTKykQjsQgJAIpVMkfil6f874 EnlmsLIhzL3vaUZ60WNUHnFZUECJpMuHDx8fKC5Ss/Bsz0phajqTx9fxucsn8Ou3jrkWCSp2 4x4iuiKqKusDwvUHSDSvnkQTAltpVI+v465P///tnXt0XPV17z/nzIxmRk9LRvJDNn4bm4fM M5gmJMiBLEibjFduadog0pCuijTNLWKtNL1Ke9O7xF03S9yVFUTTXJmsVr4JcklFKPJdxA7F VmIIiBjZRgZL2JItyZZsS5bGmtHMnJnz2PePc+YhWZaMMY8k5+s18jzOb/9eM799fnvv33df x+rlCzl7Psaeg4O8uP8Ey/1gieLY3MGrCnmqFxRhQVq8pAmr7Tt9A2cRF1tReFVBNwRPMI+v fGwFa5aXc+CdYX7+5ggLfL5MCz0AikpJaSF337icirICdD298Nn3yaOTMQ72nOXocBhFtc1W JnZIsGYJIxNxogmNQDp5j23Azyyg2bt2Z9HLZMVTnEXYXnnTy3G2pOLoV4d80CmTkZlrpcko lvQbZOqwMsrGcpSL4hyIS0+Rc1ef3kU4MizFcpqYu/8QZx1P5/rwODsJJRMNllG0mT475RwF ZSnYPFWOY0Mcfq0sEUiOalCY/tqFCxfvGy6TotxZNJwf//LyYmqqNzI2EeWdE+P483yYIo4Z x44SQgQ1Q+pnL3iWE5GkKqCIYIhC0J/Hx69ZzJ/cuZ7N1y1DLDh07AzP/rqPsaiG36MgqnM3 jIKlqLbzO70QCw5lhl2n4dSoOnZ8SwTdhKVXFfCZj63i07euRkvpvHhgkCNnI6wOeDEsUFEw LIsFRUE+97HV/Mld61lcWohuGmQXdjgTnqLQ6+HoyASWZROgWgL5XhXTMDkxGmVyKkV5cX5W F2Tu3jNEJZmdRJqnKne07V1ErilKyBIZKpmdQOZgo+T6U9JKJ/t8WjrVjM1quh9kutM7PWNZ JZK+q08rmPQHSmYO0tVnlVvGZ5LpteQodsXxl5BRYlnD2IelDjQG+4fJr1xDud7Pzv/3Nqvu +Sw3lF9Zy70WHmQ4ks+KFeWX/IPUwmGihgHeAKWll+ZLGOt9mV+9BZ/aeifvvQsavS+/yADX ce+dl3BC+wpjbLCfeHElK0qvhLs9yuu7f0Gs8lNsuSGQ87z8submdxWXdShPcp6JgN/n4dYN lXzlnuuoqCghkOdFMwWPouJB8AAexeZ6cm6sURUFL/bOwBIBj5eiBflcf+0y/jp0E5+8aQXF +X5My6IgkMeyihIWlhXgy8vDsBRMy15w87Dl2HsZZ4HJ5JF26lTETlCkKHjyPJSWF7Pl1tX8 +T1VXL2omLdPjPLLw6dZ5rN3S4pi4VXAQGXBVQVUb1rGsvISCoN5lBbmU1oYoLQwjwVFAcoX FFBWmIdXAcUy8YodMOzHg5aEE+EE5Q85VQAAIABJREFUsUSWUC69W5DMYqnk3J1DOle2WIZN smcZ2d2HqYORstMHKs6CrsexUjE7cVP6DlxxFn/HFCQ5Q5I26aTft8uk83OnbVdWRlFY2MrP 3sVkw3VVJW0WchhysRWeSK5RyZnsjF/Bfm6R3ull1UH64Iyi2IY8Na18Mmr0g0f/jr9k5dq1 /OVzvQz+4nFCD4R49cyVPt4V5am7VrJ25d02Od6cMDi8exsPblIIlpVRUVFBRVkxPmUr218e mbee577+Se6//zniV2LV047w9U+GuG/X4BUQ9i6r7t1Oxcq1rPzBm4DG4OHXOdA7X//nQPgQ tffdz6O7jk9//q7m5ncf7zH5kWo7HEVYUODjntvWsry8hJ929NJxfJS8RIqJpIGScuLqLbu0 Kth+Cp9Kic9LYVGAqxeVUH3DMj5xwzJWVZaR57HjkAI+DzeuW8Q/lhXQM3SOPd2neGtwnOhk At20iKUMDN0Eh+E107i070K18Pt9BPO8lBQG2bCilHtvWc6mNUtYVlHCmfEob50Y42QkwdKg D8MpZgosKPCx6eqFrFm6gIDPk8kRbvcZVFUo8HtZUlaA1+clhse+TkxUFBI6nI1qpHLDZ8WJ 5XF2Oln3QNYybyVj6BPDiKTIK7saNVCM6HH0c0NYouMrWY43vxQjcZ7EUBeYJoGrN+EtLM9G QqE45qlcW409V2om2imtUGzFm+OqyCg0W55tVsq0M2d3YKuW9G7OfpU1FuXsKjKbh/Tybznt sw+/ZJJOCTlmr/S4fDjqouL2h2hquo8//NwGhp44BtTyB+uKMDRtlvMABlrUwDvLwby5EeQT /72ZlsJPcUvmWMBssjR2f/t27vtuNzX1zex56lNsWL2QyPHX2FYb4qFPnmDxcBf35qTbMzQN I30GwRjmQAdQ+3GyJ2Iup80GmuGFgV46gPrN2V3FtPqyb6IZs50XMdA04+LnRWat2smqt+gW WpqaWfOH10L0TR6q2kxH3S7k+/Mno5qtjdETR+gGGu9YTfTEc5nns83NrH2cIf/CQ4Wz93U+ WZmyc8yRphk5hw5nHKK8wniPdJ3OPa+ioKoqZcVBbr12GX+19Sb+5/23ctcty1m+ZhGVFcVU LihiSWkxS8qKWbKwhMryElatWczdt6+mbutN/P2ffYzPfXw965bbisKynINZqkJxvp/Vy8r4 1M2r+Mbnb+Kxms089NkbqL51BdesW8KyJaVULiyhsqzEll9axLKFRVSWFbNi0QKuv3YJn//4 Ov72/lt4ZOvN3HXTaq5eXIwlFuMRjaSo3LRhMWvXLmb92iVsWLeIdesXcfsNy6i+YTmF+f7s gDn8VWlHsd/nYVF5MdetX8zGaxZzzbrFrF2/mLXrK7hlQwUbFy8gz+/JjFf2f8l5nZ0OxdRJ jh7nfNd/EB/4DZaRRBEhOdpH+OCzTB3rxEpGAQs9Ok7k8M+Z6u0gGT6FmBpk/AW2cp5+QD9H eZBWCLkHHOxgBGbc1StKVpFlr02b4lRnZ5TrVUg7xdPfkbRI2/9hU7A7Cg1IO+8tZwymj8ts 4/RBQOMXP3iUR54/hbcozJGuDuApqm5X8AWDbHlsr31jgcbr27+NovgIFgfxKQ+ye1CzifEU ha3bDgPw8uNbUJQHOawBI7vZpChsffIAxuBLfPP+r/HmlH3nFj68kwczsjax7fUxAAZ3NnDf d7tpaG3jtsQuPr15I/d98YtsrO3kT1vaqKKbo2ec299oL48/uAlfMEjQp7D9cBRj9CidQM0d 1xC4WJuB3u0PoihbORAFwi+z1WknwMjL29ik+Aj6FIIbHwDg+vWLIHyAb29RMvVtOxwFDLsO X5BgMIiy5VEO2KwhjB3YwVbFRzAYxKc8Sq82V71htm9VUJRNbPIF+ewPD9C/51956JEDLCg4 wtbizXYuiyfuQ9nyv/nRgwrKpscYARjby5aMnCi7H3/QaeMWHtyqoGzZRhgY7n4FqGLD1aXT nk+fm4uX793xMIqisPXBLficPqXZ1WfrK1o/2x7ekhmvrY/t5sKNyxxz5NSnbFIIBj/D61F7 brYoPoJBH1u2bkFRNrGj/wrzsst7giWmiJhi2X8ty3lXJKYlZeDMhPQMjsrbx0bkyLFTcujI oLzZe1KOHBuRI/0j8s7gqAydPS+ReFKsjEhTLMt05Dj/LEtMK3OFmKYp5yZjMnAmLEeHxuRI /4gcOTYsbx0bkYM9Q/Jmz5Ac6RuWI8eG5Uj/iBw7OSanxiISS+ppCSKWKaZpyUQkIf3D43J0 cFSODo3JsaExOTZkPz8+EpbxSExM05reW8sSy7LbZ1oik5GEHBsak3cG0+XHnNej0j88IZNR zS5vmWJaplimIZaREjH1bH8tS0QsMeITMrH/pzKw7Qsy9st/FjMeFtPQJHzg3+X4P90qp//z e5KaCotYliTHT8poxw9k7JV/Fe3ccTGNlIgldvtMS8Q0xDJT9sMynbrsNmfH1cx8JpbpXK87 r+25tMS+xhJHtmWJZeoZ2emyIs64WHZfp7XBMjL9NEXEtIXZ5UzTGRvLLufUJWKJZWa/Vx8s BqQehFCLRBJdUuNorVB9g9RUIVQ3yYSI9LXVCSDVdS2yq63R1mz1u0QS3VILQk2bJBJdEnLK tw3o0tdaI4C09CRkdJ9dpqkrIjKxT6pBqG2W7u52u0xVk0zIsNSDVNW3SltDtUBIWtpb7DbV tEkk0ilVII1dEyISkZaQXVd9S5s019VIS1dkWj0XbbMkpLUGgTrpE5FEV5MA0tg5KjK6R6pA qKqV5uYG+zk10pUQ6WystvvT2Sed7a3SNarLQHu9AFLX2in7mmscORMio3vsPlbVSmt7q9SG 6qUnMUe9OWNfXVsnLXvekbZaBGqlZ6xb6qvsz+qamqW9c1j2Ndrj062LDLTWOn2eyOlzozTV h+w+17VLQhJZeXruc7nImF1Yvr2uyn5dXSf1NfZYNHdHLtLXiLTUIBCS9q5uaa5BoEr2TUz/ 9s01R221Tn1VNVLftEcSc8zNlcR7VBams3zafzOLi+W8noG5fvKm6SgEK/dCe+XJrBWO0jDn WDysWWvOqceylY29KM1x4UWl2wpM0n8vUYhlpMRMRCQVGRVt9KhoI0dEGzsmxtQ5MfVEZrHV I2fl3K+aZeBHX5GJrufFTMXE1ONy7rUfS19TlYzu+5GYibiImGIkJkU70yPaWJ+YKeebYZli JmNixMKSPHdCEqfflvhIjyTPj4iZnBLLNB1lYWbaZCYiYsYjkhw/KfGRI5KcGBIjNimmrokp ppiSXsQtEVO3+xE+KdrpHtFOvyOpyJiYybiIo5QsS8QykmLGI6KdOyGJMz2SDA+JEZ8Uy0yJ 6ShZy7Kmt0GLiqVrYibjYpn2eJjJmK1YP2g4P/RQU5ckeloFkKr6XSKi24txtb2IN1QhUC8D IiLSJ3VpBZNetGtaZE9rXWYr2dLZJY2OshkVka6mkEC17JsQ6Wmpca4LSU21fX1ta0+m/uZ9 e6QWpLZ9WETvkmqQ+n2jMrqnXqBKdg3rove12YtM475p3cnWM0eb9T5bQda0ii4i3c2hjNx0 21q6EyKSkKbqrMLc5yiLqpoG6RzWRWRUGqvTC3ytvWBSJe0DiRlyHMxRb7rv1fW7nIsH7PaH WiSSqdtWDiIifY6CaO/ptse5qkGGZdRur6OMZHSXAFLT0jND3nTZ2TGbq3x6PGulT0QGnBuB i/VVH2hz5rhKamsdpeN8F7KY63s1kKmvxxGbrqd5lrm5kniPObjTkfNZtlg7NFLBkhwbd8Z2 TSZqJ5uGyP5fVdMRMpZ9bdrunmuGUHLiaiTzx47KgYwsRVEcCg5HgkA6rFRVBHFSp4qIzVSR 06+0eWlaSKuStdArjkM3bUgRxQ4Lnd4fcloDWAap8Em0kR6MyXHMRBTLTKJ4VbwF5QSXXUug 8jpU1YcYKfTYGJYoeArLUTwBRE9gxTUUJQ/V5wNVwUppaGODmBOn8JUtgRJnpFJTxE+9TWps EDM2gaknbT9FII/gkusouPpmPPklYJokxwdInDqCael48GJMTWBo51FUP3mlFfgr7UNxqjcP O492kuTEEInTR9HPDWPpCXuc/HnkV1aRv+w6PIESLD2Gdm6A1OljJM+ftp3yHh++knIKVtxM 3sLlKKoPEYPE2An00T47l3deAF+gED0eJrCkCkVRiA3sJ698PYGFy3J8Je8/oiffogNovH0V Z4/+BIBHv3w3GD083w5V9ddTGj1DVzdUN4ZYARj9B3kCqN6ykSIMkhGg/fs8+nQ3NQ2N8J2/ 4/kfNNDeDQ17/oxyorywtx1oYE1plF/ueRqoobktxJK8v+Hvn76JDUtLiR7+FVDDjeUpfgps mniVxz5zPx3ApiMv8A9f+y7UtHLXUi+JA+MAfPHzufkmonSn6/Ge4XsXa3N4hE4g9Onb8TLI v32tHahjXYXB22/abdt8QwB6d/BIB1Q33EQpcOe3fko7/0Do777D5u4SIq98glc7oKq2ka/f s5rCmof56Y03U14UZbvTx1s25vgwLlqvl7Nv7Afgy1++y7l2iI5uqP6LKooY4+DuDqhuZp2z klXccDMAT/y3R+johvpdf8HS6En2dkBV/RdYA7z+b80AfKKqEsKHsvKmyc4ds5N8b77yjV9l DbBz/9NALesX6XTO0tfEuD0/tY2Pcs+GMr76jSY23bBiOoXKXN+rdBsbv+okc9I46szNp24I YMyYmyuJy/RZKDOez/wBK+lozJxH1mmpKMr0R2aJzbpGM9EzSu4bufZ2R46aK0slnf1t+nvp 1zNaqdgH79L/q+qMdinpENDcuhWyfoH0JwqqQ0aYLouSvULEQI8MEz/1GqnxXhRfAWrhUvTx M0x2tRI58hJi6IBgGjpW5BQer4U3uABFVRA9jhmPoPiW4M0vtUkLk5PETrzG+e7n0c72gpmy 6zNMkqffQhvej4WCt7ASxRLivS8w2fUM2uhRsAwsI442fIjznds5/9qPmDr2n5hWCsVbgHaq i/CrTxF5ey+WNmn3wUyRONvP+UPtRLv/g9TkMIo3AJZF4tgzxE68ipWMY6amiJ/sJnLoeaLv /BxJJcCbjz7WQ+TAvxPtfQkjOgoKmIkI2tBvmDr+S0w9gSTjxIfeINr9c4zoOImzPUQObMeI jtm+lw/QdTGwfz9QRdXyIobefBMIUbXSizF4mHZgy80rwDmT09H6DDv37uRvv3A/AHWhTUAp 11ZXA910U8OjX76bfKD96XaobuIbW8pBG+C1dqB2I2UEKbsKYJii5dezaZWPzhcP5tiyo/gW beTeKnjiofvp2txAXaiKJ772EE+FGuj54ZecBceOvNv142fYueMxtmzdTlQbztYzR5ujJw/S AURe28FjW1fyXYCa26j0QioO0E3btifZ6vgrNm+6Gq1/J49vO8ym/1JDHcBCf4ZTvDse4Jrb bqNC7+WFX/cDQRZfVQU8zfP/vpNtj27lydfDc9bbnx77Srt30RNH6ADuvWk5RI/zfAfQ8VOe 2nkADShadi0hoKO9A6obefTepdn2dD7HticfZvMj7UCIG1cVZeRV37R82vNpc3Mp5e9YD4zw 5l4gdDOVgdn7mp4fKtZw26b1hLt288v+KFrvDhRF4cHth+f8XmXrW+18L7zkUZWZm8+k5+a2 2VhC3yOu8E7l9xpWju/GEnFs8JZYRlK08RMS7XtZpk4dFH3qnJiJiEwe3i3Hf7hVhnb8teix iIhlSuL0URna8VU52foXEj99VMQyRRs9JsM/+0cZ/PFDEnlnjy3v3HE5vet/ysln/lYivR1i pqbsRpi6xIYOytTx1yQZOS1WKibambdkpP1/SP8/f04m3nhGzOSU6FNjMtrRJMee/JwM/uS/ yvnuFyQVPS169LSMv/oT6W+6Wwb/7zckNvK2iGVKMnxSzrz4fTn+fz4vox0/lNhwt6QiZ0U7 1ycTXT+TyZ49YsbDEht+S07+7Jsy8C8PyLnX/020iRNiRM9KtP/XcnLHN2XgXz4nU32viJiG 6JGzEn6jVc6+9D2ZGuiS5Fi/jO19QoZ+/JcyeeQlOdvxTzLUcq/Eht7M8et8ENClLW1D1yPS XI1Q3SwRERne1ZDxN4iI9LTVZ0xMEJKWzuGMlLR5oLqxU0RGHfOBbY4RERHHl2GbM0QiPW2O ycZ51LVJQiRrimlol9FIRCIJ2+YyMdAnwxMzDNORbqmvzspo2DVwQT0XbbPel/EBVNXY5qNQ c7ddV1dzpky6ja09CUn0tEyT1d4TERFdOptrc9532iEio53Njk3dtqvvG9bnqNcZ+1BzxqTS 3VKTMVGJjDo2/6zpSPTujI+jtS89Nrrsaah27Pwhu/3VjTI6Q9402dPG7FLKZ+cz1Nw1R18H pCmUM8fUSOeEyPAe+3vVsGd4zjma3n9nyntaM6Y+cubmSuPy8lm4uAhyzxfYrxFQRLC0SfTo KGZ8EjF1FK+P1OQw5w89hzdYzuI/asAbyGdq6DDhl3+Ip3gBCz/+V/jLVhA/uZ+JV1pRA0FK PvZF8iur0M4cZfzlJ1G8FZTd8SUCi9egqF4sI4kxeQYjdg4rpaF4vGBqRPp+gzbURelt91N8 /R9iJSKce7mZeN9vKLvzYYqurcbjLwQR4qfeYOKVFiwdrtpSS3DROiJHX+H8b57Fv2glpXf8 Of7SSruvgs0krKigR5k89CLn39hOcNUfUHLTVrz5V9mRt6bOxOvPEnvrn7nqMz+g+Lq7EV1D nzxJ4tQRkudP4S9dijZyyGHb9YLHC/okC259iOCSDWS2q+8rwhzY+RO+GXqEjto29G1/PH9o p6ERNSD4bvMwzC6MaDQBviBFmRBIjb2P/ymf/rv2GddW05XYy80XnEuzZfiCRRcPy7xomw0n HDOAncYr51MtSpQiimZ+5ITHXhAGa2hEEzrBYNH0XCCGRjTBjPwfc9Q7D7Solgkt7d3xKBsf eIKa5i5+8vDNM66L4i2yDzC+uxreQ/lZ+2rn2tB137QcI4Zm4M2dsEv8XvXu3sGBVBnLS1Ps +l6I77bXMSDfvyBB1XvF7/uhxCsLwQ4Ddc4SKIqCWDqp8DCJ4bdIjh3BmBpFsTREzUNMkKkI asEybHNVEit6BgUv3uJKFH8QwcKYOo+hnSdYsRpf4VUoqFi6hjl1DP+iSjxFi2xFEY8SP3OU xPAB9Ik+xEo4Fjw/qYlRUPyo/iIU1YNlGpiJKKrfi3fBUpS8AscnY2EZBlYqDL7FqP5CTD1J 8uRvEIGCVXfgKyh1/D7pZFaKHd47OUri1H6wAoieItbXherLc1SohTE5gkJhhgDXiE1gxCbw FFyFNxUGI44IBJffTGKwG1/xQrz5y1HzPsAEytGjPBR6hG6qaf/WH13aD8Qb4LLSRcwujKKi mXkYAmz51vNEavo51HuM8FSKvMJSVm640bFbX4qMmZdcrM25SYRmXBAooohZPrrYWQFvYPaE S94AFzZvjnrnQcCpw+h/lo0PPAGhZp6coSjs67KVXs50XVb5Wftq59qYefTEO3MQL+l7FeVA 6wM88HT6dYi27u9ccUUBrrK4gshhbbK92iCgR84yeeQXxAb24ytZSmBxFd78YkwtinayB7EE tagY1aMgho4eO4uJgrewAtXnZKxLnMdKRfEGSvH47bSnVtJAkib4PCiqilgGU0NvEDnwHIo3 n8CiNXgWXIViWiTOvoMZ6ca38Bq8RYtRVA9mUsOMTaEGi1Hz8jJtFsCMRdCjPQSWrsWbXwGi kwofR/EU4C9fg+IvsHdL6dPfYqGIiqnFMSeHsJQ8xAqgR8btgABFQQQ8wUXkb/wzvGWVGWeW ER3FjEfwlq7GX7EKtWAh/vINzgFDBSUviCdYQo4T6P1F0e28HolA0Ucvb0PR0jXcufSDp9b4 bYF3zVYikQjBot8nKvUivvQT4Qs/jKLD+9r3358xfd/hOOol6xQ3jQSJ0aNoJw/iL1xEyY0h /IuvQVFURE+iKEWkxodQ/YW201pLoUfOAOApqED1BGxndGwS9CRKsBjFa+82JKnZWf7y7IyC VlIj3v8GeuQ0ZZ+opWD17SjePBSxUEuWkhjuRPUG7HzcomDGw4hl4ilcgOL1OdFeKmBg6Tpi mnj8duSVOCfvRRQsK0tXrmbc+w7ExEpF8JVeR+kdf4y3sILpXmk7IEH1BUD14C1eTNE19yCm ZbfB6yMvvxzF58dXupw0kZbi8X4A5qcsAvPdlbv4iOISdlS/owh8ADc3rrK4ghBIx8ragbeW iWiTiK7hKV+Ct2ghqtePGEnMxHnMyBlQFTyBUpvp0DKQ+Biq6sVbtAjF50dSSQzDAJ8XT14A PCoYSYz4OVALUIMl4FEQ3cBMxlH9BXjyF+DxF4CYmJqGpcVAC6OWFaDkFSKSwoydA0XBW7AI j9f+mmXCiRMaqhKAQAGqoiCKgppfjsTD6OGT+ApLUPKCYBqYegJFUfEEClHyAniKF4ORwIyN k1dS4URMmVi6Zp/0zyuyQ3ERFI8PPL7s+Am24sS2btnZOKafOnfhwsWHA1dZXDEImUQSirPP UD2o/iJUj5fUuSNog8sxys5jxM+ijbxNrO91ULx4SxajKB5Mw8BMnAWlxPYtoGLqGpYWR/UF UfP8KIqKpcdt30feArzBq0D1oqgWqq8AK3aO5NABVK8fU4+jnztO/MQhrFQKtSCIqtrmLiN6 CrFMfKUrUAKFtnJTACOGMTWG4l+Kr3AhqAqKN0jw6s2kJn/BZPfPMKZG8JUsxoieQxvrw79w DYXr78RXvIjgqmqi3buJdj+HcX4znsKrMLUwxvgJPCVLKFhzJ76SJfYuzGHPhWwIclrjSno8 M5+6cOHiw4SrLK4Y0iTcmfx0qN48AuVr0SqvQxvqJPLOr/EEe0GJI9Yk3oAHb8FiexeheGx9 412MN1iKx+8HsTAT51GAQPk6PAWlgGKfSZA4/tIV+EqWoqge8OaRv2Ij5vmDJE4eIjkZtlvi 1cFj4l2wBF/RQhSPN3PQ0VtYhq9kCR6vnzTdvKnrKB6FvIXr8JYsAdWD6g1QsPo2rOgo8RO7 mepNofrLED0K1iDBRWtQPF68+WUUrNqMNTWONrKfqd5fgb8IrCSq5xz5CypQPLk8WfYhFyUn 210uhftv/45ijGcf/1+MbPgGf/P5+X0NhqGB91IiqjRe3tbAL/0h6r9y+7v+EV96Pe8/LogA cvHRxRUPxv09huX8yWUsMY2UJMPDEunfLxMHX5DJ7t0SHTgkiTP9Ej99TGJnjosej9jXanGJ n+6XxOgJMVOaiJhixCYlcXZAtNHjYibS10UlcfaExM8cFyMeEUmTrsTDEjt9VM4ffknGu9ol emy/JM4el8TZExIbPirJ8RExjZTdpolTEh/pk1TknM0plWlvQrRzQxI/3Sep6JiYpp7+QPTJ sxI71SuTb74o4/vbJPrOqxI7fVT0WFjEMux+60nRz5+W2NDb Ej74gky88R8SPX5QEmeP2/KM lEjOeRSxcslZPgwOqMvDRM8eqQ9VCYSkMzL7NX1ttdnY+UiPNNeFsmcValskHSof6Wm3+aac WPmWziz5Q9+e5gyvVO4ZjX0NVZKlg8jBZdYzb3/mkCuSkK72JjvWv6ZVMsUTfdJcWz2tjF2j Lp2t9dPOIOwauPLnAlxcWbjK4grCcris0q/Si7iIJaaREkM7L6YWdYj3rOwjc711kYNn0wiz 5njPhpmMipEIi2WkMjxWGV4rh8jPmqO8LT6HByuHq8uyTDG1iOhTY2IZyZw+WDnSHPpBLSxG bNwmA5whJ9vXuZi8PgqYkD2trdI1nF3M0koAEKoaZXi2YnqPTSTocPREupoEqqSuvjZzqK2x a0IkkibKq5HmliZbMcw4AEioXtra26W5sTnDB2TzJ1VfsLBfTj2X0p+LypUJac45ZBZq6sqW 6WwUqJGWtlapcw4KNnVNiDjEh6G6ugwHln1w0cVHGa6y+EDwYd4xX8m651Ewv4PQB1qnndgW Eenb1Srtu+xTs1V17aLPUi690Dfsce6lExMSSYiIJOxTydjMpD0O8V2jQzvaWuMs4rpDHlfd IH2z3HTbyiIkXTOUxbuu5xL7czG5kuiTlqY22dVikyU2do7OUjqtUNInjxMy6pw8TzPDVuco GRcfTbjK4orDmvHcuuCjXKba93XpzWHrnVbXZbHtzlbUmvGZlXPRjHGw0lfMMT4fISQmhqVv YEA6HdqF1q4+GRgYzS6kfbYSSVNozCjtUG7XSPeMhT6zW6hqlNEMnXiaQdRhFK1ukpHuXBoN hzKjvS8jJ60sLmYCu9R6Msykc/bnYnKz6G4KyUwaCn1gl9SGQpmdSG3rDNkTnRlqjrbZNKKL jxTeY/IjFy5ycCnEMb8l5DJHflTJ2pUr2Xz/dwF44Ja1rFzZkiH26z9os6F+4pbKCwtrx/jV 00DNfazLCX4f2fsklfd9B6hh30vfojxN8Fd9M5UBYKyfjm6o2nw957r2AFDb2Ma+XS2EgO88 8RJ2/iCNw6+0A4vI93EB3k09aWbSOftzMbmZT6J07W0HtrCuIofAw4CFq1ZRWW2/PtY/4iSM AsIHeLRsM08DDbsG+OM1H7UjkC4uwIetrVy4+ChCj0zIxESPk3Rol4xGJjKmE5G0gzk0e4KZ iE0ol2ta6U7ntAg1ZPwO6euqGuzcEwNOwpuGPaOZnYND/eckUmqVhEjWH5Imz8vBu63nkvpz MbkZ9GQSPc2KiJPUydnJJAZ2OU776mlOdhcfbbg7CxcuZoG3qJTSYJxOYPPmjZQXlVJeGiDc u5dnn93OU892A/DKMzvpDRvTykaPvUI7sGllCQCDO79N1QNPABD6g+UceGYbz748CD4fRUD3 d55mx85tPHL/E0A9X/pk+p69nbZnd7P90a/zFFD/0F0EgHDXizwF1NbcSe555cup51L6c1G5 aBzYvZMd29voBBg+wLN7D6PISKGAAAABdklEQVQBh7c/ytZvb2P37md57MFv0IG9kykae5nP rryPdoCqzeSd/E+2bd/JyBXOAOrifcCHra1cuPjIQp+Qzj37ZCDn9r2rqXqGL2G6nV5EMilI m7vtgrvqZ5bJUn9Po6KuqpN96RDS0U77bt151LV0Ov6SdOrPC/0Vl1PPpfTnonJz0sVmHmmn eXv99OvrW2VYF4nkUJ1nH7OEALv4yMGlKHfh4kpDO8DW4C3Q3M3zD98w7+WGFiWhMwuvkYFm 81tnWF213h0ENz5AdeM+9n7rznfVrIvX8z7BoSifkyrdxW8NXGXhwoULFy7mheuzcOHChQsX 88JVFi5cuHDhYl64ysKFCxcuXMwLV1m4cOHChYt54SoLFy5cuHAxL1xl4cKFCxcu5oWrLFy4 cOHCxbxwlYULFy5cuJgXrrJw4cKFCxfzwlUWLly4cOFiXrjKwoULFy5czAtXWbhw4cKFi3nh KgsXLly4cDEvXGXhwoULFy7mxf8Hjr/QRiQ5puUAAAAASUVORK5CYII= --B_3427825151_10020701-- From lnunez@c3isecurity.com Wed Aug 15 08:45:57 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 625CF21E80F4 for ; Wed, 15 Aug 2012 08:45:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.625 X-Spam-Level: X-Spam-Status: No, score=-3.625 tagged_above=-999 required=5 tests=[AWL=-0.027, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L4cJrT4EDT3s for ; Wed, 15 Aug 2012 08:45:54 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 722BA21E80F3 for ; Wed, 15 Aug 2012 08:45:54 -0700 (PDT) Received: by ghbg16 with SMTP id g16so2091053ghb.31 for ; Wed, 15 Aug 2012 08:45:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=VTqM08bgBkHakMu0BIbNOyCa2z3yDFE/65cnyOjASRU=; b=S2vFWO270ySL86gqlPnR1LpliKYws0JJ4X1e6S6vplTFwC1SWY/IqF7xg8mIzo5j+8 KbYLC5AXxaCjO1OLJz9N/HurUfI+4ToGWpFoIUDA37kvOFzOzUot4qltfaJatFTo2Ib1 vg/IouXKfU0KQGUJDkMbkoL0h59SUvGm1QOiaZSoaPvQn5Vfg5yF5SsWgNZ8MquUIDVE jg0rM/dMJO0kbt68JHTtsmHRKitjCfwcqtiWuuWAIbszgMcGTgK2K7b4+PDv6s2MAuDi JlapOqRFN7GY01vCXYDiBEl7zcAdLjY2b0prnSAokUJRVs/uBbX3AIK2MZ1/mC2jrVQq Tc4A== Received: by 10.236.141.42 with SMTP id f30mr16828411yhj.120.1345045553952; Wed, 15 Aug 2012 08:45:53 -0700 (PDT) Received: from [192.168.1.16] (cpe-066-057-081-254.nc.res.rr.com. [66.57.81.254]) by mx.google.com with ESMTPS id y10sm3279881yhd.6.2012.08.15.08.45.51 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 15 Aug 2012 08:45:52 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_943AAED8-1F4F-4A8F-B898-BC1D19BAD440" From: Luis Nunez In-Reply-To: <002e01cd7af0$8985f610$9c91e230$@cloudsecurityalliance.org> Date: Wed, 15 Aug 2012 11:45:49 -0400 Message-Id: <34D73D4A-9582-4BD4-AFF6-A812B1053211@c3isecurity.com> References: <002e01cd7af0$8985f610$9c91e230$@cloudsecurityalliance.org> To: Becky Swain X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQlhoPNCqCShhRjr8IHXHnhllHSLlZgf3xIWAK50rOrPInyhLMOtEuRinv8n+pwW28mgDwfr Cc: 'Ruben Oliva' , mile@ietf.org, sacm@ietf.org Subject: Re: [mile] [sacm] Cloud Control Matrix X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 15:45:57 -0000 --Apple-Mail=_943AAED8-1F4F-4A8F-B898-BC1D19BAD440 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 John, thanks for the information and intro. Hi Becky, CCM is a worth while effort that contributes tremendously to community. Some questions I have is: 1. Do you see CCM expand to other controls sets or what is currently = mapped good enough for coverage?=20 2. CCM is for cloud environments, is there a difference if you apply to = non-cloud environments? Looking to see if there is gap in mapping if = CCM is applied to non-cloud environments. Thanks. -ln =20 On Aug 15, 2012, at 10:16 AM, Becky Swain wrote: > John, thanks for adding me to the communication thread. > =20 > Luis et al, if there are any questions on CCM or specifically on what = is changing for CCM v2.0, please let me know how I could assist. > =20 > Becky Swain > (mobile) +1 (650) 520-0263 > (skype) rebeccadswain > (twitter) @rebeccadswain > =20 > From: John Howie [mailto:jhowie@cloudsecurityalliance.org]=20 > Sent: Tuesday, August 14, 2012 9:39 PM > To: Luis Nunez; Waltermire, David A. > Cc: Ruben Oliva; mile@ietf.org; sacm@ietf.org; Becky Swain > Subject: Re: [mile] [sacm] Strategic alignment of security with = business in SACM in an international context > =20 > Hi all, > =20 > The Cloud Security Alliance intellectual property, including the Cloud = Controls Matrix, can be used royalty free with attribution, should you = wish to use it. We are making some updates to the Cloud Controls Matrix, = and I have Cc'ed Becky Swain who can answer any questions you might have = about the updates. > =20 > Regards, > =20 > John > > =20 > From: Luis Nunez > Date: Wednesday, August 8, 2012 9:50 AM > To: "Waltermire, David A." > Cc: Ruben Oliva , , = > Subject: Re: [mile] [sacm] Strategic alignment of security with = business in SACM in an international context > =20 > I had mention the Cloud Security Matrix (Cloud Security Alliance) in = another thread. > 1. is this something we can use as basis for mapping the various = regulations to a common id? > 2. Is this SACM or MILE GRC related work? > =20 > thanks. > -ln > =20 > On Aug 8, 2012, at 12:37 PM, Waltermire, David A. wrote: >=20 >=20 > The challenge we will likely face in scoping down the effort is that = we might not be able to work on the full stack that supports low-level = data collection, as well as higher level security processes and = controls. This is because we will likely need to charter around a lower = layer of function. This is why we need to scope as part of this work an = architecture document that illustrates how the smaller scope of work = fits into the larger picture that supports alignment with international = compliance models. > =20 > To say it a different way, we need to define a comprehensive picture = of the =93end state=94, even though we may only get part way there based = on an initial SACM charter. > =20 > We can use documents like ISO 27001 as guidance in producing the = architecture document to insure that the end state aligns well with your = concerns below. > =20 > Sincerely, > Dave > =20 > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf = Of david.oliva@verizon.net > Sent: Wednesday, August 08, 2012 10:22 AM > To: lnunez@c3isecurity.com; sacm@ietf.org > Subject: [sacm] Strategic alignment of security with business in SACM = in an international context > =20 > =20 > Luis and all: >=20 > Unless we can demonstrate that the technologies and specifications we = are developing align with the security objectives of international = compliance models (such as ISO 27001) we cannot demonstrate strategic = alignment of business and security objectives in their context.=20 >=20 > Strategic alignment of security objectives with business objectives = can be at least partially joined via SACM thru the SP 800-53 to ISO = 27001 mapping table. If this were to happen to SACM then the validated = products will have less appeal and less marketability. The validated = products will work fine, but they will work with limited capability and = scope. For example, currently validated SCAP 1.0 products do not use = the Open Checklist Interactive Language (OCIL). OCIL is an open = specification (created by the security community for use by anybody, any = developer, any country) that facilitates non-automated assessment of = security processes. OCIL would allow an ISO 27001 compliance assessor = in Germany to create a question =93Does the organization comply ISO/IEC = 27001:2005 para 4.2.2 e) =91Does the organization implement a training = and awareness programme=92=94 and answer =91yes=92 or =91no=92. Then = the results can be accessed and read whether the organization uses = product X or product Y because OCIL is an open security specification. = Another example of OCIL is a rather mundane security function of = universal use. OCIL allows an ISO 27001 security compliance officer to = answer =91yes=92 or =91no=92 to the question =93Is the door shut?=94 and = make the result electronically readable whether he/she uses product X or = product Y. As for business, the flexibility of OCIL allows a company to = create a question =93Did the company reach our 7% profit strategic = objective over the past 10 years?=94 and able to answer it =91yes=92 or = =91no=92 with product X, Y, or Z and ensure interoperability. >=20 > =20 >=20 > David Oliva >=20 > =20 >=20 > =20 > =20 > On 08/07/12, Luis Nunez wrote: > =20 > Thanks the comment. I am glad someone agrees with me :) > =20 > -ln > =20 > On Aug 7, 2012, at 11:46 AM, david.oliva@verizon.net wrote: >=20 >=20 >=20 > Luis and all: > =20 > You are on target. > SACM is not a law enforcement thing, but is a facilitator of legal = issues in association with the protection of private information and = health-related information. >=20 > I think a couple of examples to show how SACM facilitates legal issues = about personal information is in order. >=20 > A SACM configuration scanner is able to monitor the configuration of = security controls as specified in ISO/IEC 27001:2005. This can be = accomplished when tier IV SCAP content is used because the output maps = the finding (compliance or non-compliance) of the scanner to security = control ISO/IEC 27001:2005 paragraph A.10.6.2 =93Security of Network = Services=94. Thus a SACM scanner is able to assist in international = governance compliance about personal information because SP 800-53 maps = to ISO 27001. >=20 > A SACM vulnerability scanner is able to meet compliance with ISO = 27001, para A.12.6.1 =93Control of technical vulnerabilities=94 because = a SACM scanner using SCAP tier IV content can map its output to the ISO = governance. SACM Vulnerability scanning can address aspects of = confidentiality of personal information by identifying software = vulnerabilities of the databases that house them, and do it in the = context of an international set of security standards. >=20 > =20 > David Oliva > =20 > =20 > =20 > On 08/06/12, Luis Nunez wrote: > =20 > Looking at it another way I could see security automation as a way to = discover if a system is configured to meet privacy policies . =20 > =20 > Security automation is an enabler for transparency so that = individuals and organizations may understand the complex computing = environment. > =20 > Thanks for bring up this issue. As a community we may want to look at = building content around privacy controls. > =20 > -ln > =20 > On Aug 6, 2012, at 12:42 PM, wrote: >=20 >=20 >=20 > None of the efforts we are talking about for SACM are targeted toward = PII or individuals. They are targeted at the configuration of the = platforms deployed in the enterprise to assure they comply with the = site's security policy. PII is not collected. This is not monitoring of = individual or employee actions. I am not a lawyer and will not speak as = one. We will let the lawyer's decide at the appropriate time. > =20 > Kent Landfield >=20 > McAfee | An Intel Company > Direct: +1.972.963.7096=20 > Mobile: +1.817.637.8026 > Web: www.mcafee.com > =20 > From: Martin Rex > Reply-To: "mrex@sap.com" > Date: Monday, August 6, 2012 11:32 AM > To: "tony@yaanatech.com" > Cc: "mrex@sap.com" , "sacm@ietf.org" > Subject: Re: [sacm] Legal aspects of System monitoring > =20 > Tony Rutkowski wrote: > Martin Rex wrote: > =20 > In Germany, an employer monitoring a company-owned PC that an employee = uses > for communication (EMail, VoiP, IM) would be unconditionally illegal. > =20 > Really? > =20 > No kidding! > =20 > =20 > =20 > That is not consistent with comments > I've seen concerning German law. > =20 > There is a significant amount of mis-information floating the = internet. > And a mindboggling large number of lawyers are making wild guesses, = rather > that doing research. > =20 > The decisions of the german federal constitional court (GFCC) have = been > quite consistent over the past decade about what with respect to > encroaching on the general right of personality, informational > self-determination, freedom of conduct and created a "fundamental = right > to the guarantee of the integrity and confidentiality of information > technology systems". The court has set the minimum requirements that > are prerequisite to such encroachment, such as the prerequisite of a > clear formal statute law, which needs to be limited to situation where > real facts create probable cause. > =20 > The original GFCC decision in german language is quite comprehensible > (to me, at least), while I'm having some difficulties understanding > the english translation (and the english translation is shorter!?). > =20 > BVerfG-Entscheidung "1 BvR 370/07 vom 27.2.2008" Randnummer 196- > http://www.bverfg.de/entscheidungen/rs20080227_1bvr037007.html#abs196 > =20 > english translation of "1 BvR 370/07 vom 27.2.2008" > = http://www.bverfg.de/entscheidungen/rs20080227_1bvr037007en.html#abs130 > =20 > =20 > To be *unconditionally* illegal, would > preclude almost any rationally required > maintenance or threat mitigation. > =20 > It is possible to perform maintenance and threat mitigation entirely > without "monitoring" systems. > =20 > A mere threat is insufficient for monitoring, if that involves = collecting > PII data, i.e. data from which a persons conduct can be infered. > =20 > =20 > =20 > It is fair to observe that recent German > Constitutional Court decisions impose > constraints, but they certainly are > not "unconditional." > =20 > One of the prerequisite is a clear formal statute law, > which currently does not exist for the purposes "sacm" is about. > =20 > quoting from the above GFCC decision: > =20 > 2. The fundamental right to the guarantee of the confidentiality and > integrity of information technology systems is not unrestricted. > Encroachments may be justified both for preventive purposes, and for > criminal prosecution. The individual must only accept such = restrictions > of his or her right which are based on a statutory foundation that > is constitutional. > =20 > =20 > This currently makes collecting data about peoples conduct = "unconditionally" > illegal for most practical purposes (exempting from prosecution only > individual occasions of justified self-defence against an imminent > vicious attack based on real facts that create probable cause). > =20 > This applies to all surveillance that impairs persons "freedom of = conduct". > The majority of past decisions of specific events was about = surveillance > with a camera, but the GFCC decision makes it crystal clear that > this applies to *any* kind of surveillance. Different to monitoring = of > computer systems, there is statutory law for camera surveillance, > that allows optical surveillance under certain conditions > (Art. 6b BDSG "BundesDatenSchutzGesetz). > =20 > The lack of a formal statutory foundation makes surveillance illegal > and entitles subjects to "cease and desist" rulings and sometimes > damages. > =20 > In one more recent (and constitutionally correct) rulings, an employer > had put up a camera that had in view not only the entrance door, but > also two workplaces. The employees protested against this camera, > but the employer would not "fix" it, so at least one employee sued, > The court confirmed that this camera surveillance at the workplace > was illegal due to its chilling effect alone, and since it had been > installed for a whole year, the employee was arwarded 4 month of = income > as damages (for the chilling effect). > =20 > Another recent decision was about evidence from a covert video > surveillance showing an employee taking a package of cigarettes > on two occasions, where the German Federal Labour Court > (the supreme court for labor related issues) remanded the decision > to the trial court because it had failed to establish whether the > covert video surveillance really met all constitutional prerequisites > otherwise the video surveillance would have been illegal and not > be admissible as evidence in court. > (German decision: http://lexetius.com/2012,2351) > =20 > The German Federal Constitional Court neutered numerous laws during = the > last decade due to lack of clarity and/or overbroad encroachment of > the personal right of self-determination and the right to = confidentiality > of telecommunications. > =20 > See also the GFCC decision about the scanning of license plates > (the decision 1 BvR 2074/05 vom 11.3.2008 in german) > http://www.bverfg.de/entscheidungen/rs20080311_1bvr2-07405.html > =20 > where it confirmed that data collection requires formal statue law, > and that the law in question wasn't limited to probable cause and > therefore unconstitutional. > =20 > =20 > The only currently existing formal statue law in Germany, that could = be > used in some limited fashion for "Monitoring" is Art.100 TKG, > http://www.gesetze-im-internet.de/tkg_2004/__100.html > but that statue is clearly limited in purpose, it will not allow that = data > to be used for automatic surveillance of "employee conduct" with = respect > to "company-defined policies". Employers try hard to avoid TKG for = their > networks (for which they will have to formally register), but that = also > means that they do not have a formal statutory law for performing any > kind of surveillance/monitoring as described in Art. 100 TKG for = systems > that are used by employees for telecommunications and a significant = part > of their daily activies. > =20 > =20 > -Martin > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > =20 > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > =20 > =20 >=20 > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > =20 > _______________________________________________ mile mailing list = mile@ietf.org https://www.ietf.org/mailman/listinfo/mile --Apple-Mail=_943AAED8-1F4F-4A8F-B898-BC1D19BAD440 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 John,
thanks for the information and = intro.

Hi Becky,
CCM is a worth while = effort that contributes tremendously to = community.

Some questions I have = is:
1. Do you see CCM expand to other controls sets or what is = currently mapped good enough for coverage? 
2. CCM is for = cloud environments, is there a difference if you apply to non-cloud = environments?  Looking to see if there is gap in mapping if CCM is = applied to non-cloud = environments.

Thanks.

-l= n
 
On Aug 15, 2012, at 10:16 AM, Becky = Swain wrote:

John, = thanks for adding me to the communication = thread.
Luis et = al, if there are any questions on CCM or specifically on what is = changing for CCM v2.0, please let me know how I could = assist.
Becky Swain
 +1 (650) = 520-0263
(skype) rebeccadswain
 @rebeccadswain
From: John Howie = [mailto:jhowie@cloudsecurityalliance.org] 
Sent: Tuesday, August 14, 2012 = 9:39 PM
To: Luis Nunez; Waltermire, = David A.
Cc: Ruben Oliva; mile@ietf.org; sacm@ietf.org; Becky Swain
Subject: Re: [mile] [sacm] Strategic = alignment of security with business in SACM in an international = context
Hi = all,
The Cloud Security Alliance intellectual property, including = the Cloud Controls Matrix, can be used royalty free with attribution, = should you wish to use it. We are making some updates to the Cloud = Controls Matrix, and I have Cc'ed Becky Swain who can answer any = questions you might have about the = updates.
 
 
John
 


The challenge we will likely face = in scoping down the effort is that we might not be able to work on the = full stack that supports low-level data collection, as well as higher = level security processes and controls.  This is because we will = likely need to charter around a lower layer of function.  This is = why we need to scope as part of this work an architecture document that = illustrates how the smaller scope of work fits into the larger picture = that supports alignment with international compliance = models.To = say it a different way, we need to define a comprehensive picture of the = =93end state=94, even though we may only get part way there based on an = initial SACM charter.We = can use documents like ISO 27001 as guidance in producing the = architecture document to insure that the end state aligns well with your = concerns below.
sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of  Wednesday, August 08, 2012 = 10:22 AM
To: lnunez@c3isecurity.com; sacm@ietf.org
Subject: [sacm] Strategic alignment = of security with business in SACM in an international = context Unless we can demonstrate that the = technologies and specifications we are developing align with the = security objectives of international compliance models (such as ISO = 27001) we cannot demonstrate strategic alignment of business and = security objectives in their context. 

Strategic = alignment of security objectives with business objectives can be at = least partially joined via SACM thru the SP 800-53 to ISO 27001 mapping = table.  If this were to happen to SACM then the validated products = will have less appeal and less marketability. The validated products = will work fine, but they will work with limited capability and = scope.  For example, currently validated SCAP 1.0 products do not = use the Open Checklist Interactive Language (OCIL).   OCIL is = an open specification (created by the security community for use by = anybody, any developer, any country) that facilitates non-automated = assessment of security processes.  OCIL would allow an ISO 27001 = compliance assessor in Germany to create a question =93Does the = organization comply ISO/IEC 27001:2005 para 4.2.2 e) =91Does the = organization implement a training and awareness programme=92=94 and = answer =91yes=92 or =91no=92.  Then the results can be accessed and = read whether the organization uses product X or product Y because OCIL = is an open security specification.  Another example of OCIL is a = rather mundane security function of universal use.  OCIL allows an = ISO 27001 security compliance officer to answer =91yes=92 or =91no=92 to = the question =93Is the door shut?=94 and make the result electronically = readable whether he/she uses product X or product Y.  As for = business, the flexibility of OCIL allows a company to create a question = =93Did the company reach our 7% profit strategic objective over the past = 10 years?=94 and able to answer it =91yes=92 or =91no=92 with product X, = Y, or Z and ensure interoperability. 

 

 



 Luis and all:I think a couple of examples to = show how SACM facilitates legal issues about personal information is in = order.

A SACM configuration scanner is able to = monitor the configuration of security controls as specified in ISO/IEC = 27001:2005.  This can be accomplished when tier IV SCAP content is = used because the output maps the finding (compliance or non-compliance) = of the scanner to security control ISO/IEC 27001:2005 paragraph A.10.6.2 = =93Security of Network Services=94.  Thus a SACM scanner is able to = assist in international governance compliance about personal information = because SP 800-53 maps to ISO 27001.A SACM vulnerability scanner is = able to meet compliance with ISO 27001, para A.12.6.1 =93Control of = technical vulnerabilities=94 because a SACM scanner using SCAP tier IV = content can map its output to the ISO governance.  SACM = Vulnerability scanning can address aspects of confidentiality of = personal information by identifying software vulnerabilities of the = databases that house them, and do it in the context of an international = set of security standards. David = Oliva 

  



None of the efforts we = are talking about for SACM are targeted toward PII or individuals. They = are targeted at the configuration of the platforms deployed in the = enterprise to assure they comply with the site's security policy. =  PII is not collected. This is not monitoring of individual or = employee actions.  I am not a lawyer and will not speak as one. We = will let the lawyer's decide at the appropriate = time.
Kent = Landfield

McAfee | An Intel = Company
Direct: = +1.972.963.7096 
Mobile: = +1.817.637.8026
Web: 
From: Martin Rex < "mrex@sap.com" <mrex@sap.com>
Date: Monday, August 6, 2012 = 11:32 AM
To: "tony@yaanatech.com" < "mrex@sap.com" <mrex@sap.com>, "sacm@ietf.org" <sacm@ietf.org>
Subject: Re: [sacm] Legal = aspects of System monitoringTony = Rutkowski wrote:
Martin Rex = wrote:
In Germany, an employer = monitoring a company-owned PC that an employee = uses
for communication = (EMail, VoiP, IM) would be unconditionally = illegal.
No = kidding!
That is not consistent = with comments
I've seen concerning = German = law.
There is a significant = amount of mis-information floating the = internet.
And a mindboggling large = number of lawyers are making wild guesses, = rather
that doing = research.
The decisions of the = german federal constitional court (GFCC) have = been
quite consistent over = the past decade about what with respect = to
encroaching on the general right of = personality, = informational
self-determination, = freedom of conduct and created a "fundamental = right
to the guarantee of the = integrity and confidentiality of = information
technology = systems".  The court has set the minimum requirements = that
are prerequisite to such = encroachment, such as the prerequisite of = a
clear formal statute law, which needs to be = limited to situation = where
real facts create = probable cause.
The original GFCC = decision in german language is quite = comprehensible
(to me, at least), while = I'm having some difficulties = understanding
the english translation = (and the english translation is = shorter!?).
BVerfG-Entscheidung "1 = BvR 370/07 vom 27.2.2008" Randnummer = 196-
sacm@ietf.org
 mile@ietf.org  To: John Howie , Luis Nunez , "Waltermire, David A." Date: Thu, 16 Aug 2012 03:16:24 -0400 Thread-Topic: [mile] [sacm] Strategic alignment of security with business in SACM in an international context Thread-Index: Ac16oAo1GneTJJwhSu+vlKaM5fsktgA3wDI4 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: Ruben Oliva , "mile@ietf.org" , "sacm@ietf.org" , Becky Swain Subject: Re: [mile] [sacm] Strategic alignment of security with business in SACM in an international context X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 07:18:13 -0000 Thank you very much for the disclosure and offer, this could be extremely h= elpful! We will also need a form filled in on the IETF site for the disclosure, I'l= l email you separately. Thank you, Kathleen ________________________________________ From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of John Howie= [jhowie@cloudsecurityalliance.org] Sent: Wednesday, August 15, 2012 12:39 AM To: Luis Nunez; Waltermire, David A. Cc: Ruben Oliva; mile@ietf.org; sacm@ietf.org; Becky Swain Subject: Re: [mile] [sacm] Strategic alignment of security with business in= SACM in an international context Hi all, The Cloud Security Alliance intellectual property, including the Cloud Cont= rols Matrix, can be used royalty free with attribution, should you wish to = use it. We are making some updates to the Cloud Controls Matrix, and I have= Cc'ed Becky Swain who can answer any questions you might have about the up= dates. Regards, John [cid:A936CCB9-0FA0-4F17-97F6-B45ABC11EFA3] From: Luis Nunez > Date: Wednesday, August 8, 2012 9:50 AM To: "Waltermire, David A." > Cc: Ruben Oliva >, = >, = > Subject: Re: [mile] [sacm] Strategic alignment of security with business in= SACM in an international context I had mention the Cloud Security Matrix (Cloud Security Alliance) in anothe= r thread. 1. is this something we can use as basis for mapping the various regulation= s to a common id? 2. Is this SACM or MILE GRC related work? thanks. -ln On Aug 8, 2012, at 12:37 PM, Waltermire, David A. wrote: The challenge we will likely face in scoping down the effort is that we mig= ht not be able to work on the full stack that supports low-level data colle= ction, as well as higher level security processes and controls. This is be= cause we will likely need to charter around a lower layer of function. Thi= s is why we need to scope as part of this work an architecture document tha= t illustrates how the smaller scope of work fits into the larger picture th= at supports alignment with international compliance models. To say it a different way, we need to define a comprehensive picture of the= =93end state=94, even though we may only get part way there based on an in= itial SACM charter. We can use documents like ISO 27001 as guidance in producing the architectu= re document to insure that the end state aligns well with your concerns bel= ow. Sincerely, Dave From: sacm-bounces@ietf.org [mailto:sacm-boun= ces@ietf.org] On Behalf Of david.oliva@verizon.net Sent: Wednesday, August 08, 2012 10:22 AM To: lnunez@c3isecurity.com; sacm@ietf.org Subject: [sacm] Strategic alignment of security with business in SACM in an= international context Luis and all: Unless we can demonstrate that the technologies and specifications we are d= eveloping align with the security objectives of international compliance mo= dels (such as ISO 27001) we cannot demonstrate strategic alignment of busin= ess and security objectives in their context. Strategic alignment of security objectives with business objectives can be = at least partially joined via SACM thru the SP 800-53 to ISO 27001 mapping = table. If this were to happen to SACM then the validated products will hav= e less appeal and less marketability. The validated products will work fine= , but they will work with limited capability and scope. For example, curre= ntly validated SCAP 1.0 products do not use the Open Checklist Interactive = Language (OCIL). OCIL is an open specification (created by the security c= ommunity for use by anybody, any developer, any country) that facilitates n= on-automated assessment of security processes. OCIL would allow an ISO 270= 01 compliance assessor in Germany to create a question =93Does the organiza= tion comply ISO/IEC 27001:2005 para 4.2.2 e) =91Does the organization imple= ment a training and awareness programme=92=94 and answer =91yes=92 or =91no= =92. Then the results can be accessed and read whether the organization us= es product X or product Y because OCIL is an open security specification. = Another example of OCIL is a rather mundane security function of universal = use. OCIL allows an ISO 27001 security compliance officer to answer =91yes= =92 or =91no=92 to the question =93Is the door shut?=94 and make the result= electronically readable whether he/she uses product X or product Y. As fo= r business, the flexibility of OCIL allows a company to create a question = =93Did the company reach our 7% profit strategic objective over the past 10= years?=94 and able to answer it =91yes=92 or =91no=92 with product X, Y, o= r Z and ensure interoperability. David Oliva On 08/07/12, Luis Nunez> wrote: Thanks the comment. I am glad someone agrees with me :) -ln On Aug 7, 2012, at 11:46 AM, david.oliva@verizon.net wrote: Luis and all: You are on target. SACM is not a law enforcement thing, but is a facilitator of legal issues i= n association with the protection of private information and health-related= information. I think a couple of examples to show how SACM facilitates legal issues abou= t personal information is in order. A SACM configuration scanner is able to monitor the configuration of securi= ty controls as specified in ISO/IEC 27001:2005. This can be accomplished w= hen tier IV SCAP content is used because the output maps the finding (compl= iance or non-compliance) of the scanner to security control ISO/IEC 27001:2= 005 paragraph A.10.6.2 =93Security of Network Services=94. Thus a SACM sca= nner is able to assist in international governance compliance about persona= l information because SP 800-53 maps to ISO 27001. A SACM vulnerability scanner is able to meet compliance with ISO 27001, par= a A.12.6.1 =93Control of technical vulnerabilities=94 because a SACM scanne= r using SCAP tier IV content can map its output to the ISO governance. SAC= M Vulnerability scanning can address aspects of confidentiality of personal= information by identifying software vulnerabilities of the databases that = house them, and do it in the context of an international set of security st= andards. David Oliva On 08/06/12, Luis Nunez> wrote: Looking at it another way I could see security automation as a way to disco= ver if a system is configured to meet privacy policies . Security automation is an enabler for transparency so that individuals and= organizations may understand the complex computing environment. Thanks for bring up this issue. As a community we may want to look at buil= ding content around privacy controls. -ln On Aug 6, 2012, at 12:42 PM, > wrote: None of the efforts we are talking about for SACM are targeted toward PII o= r individuals. They are targeted at the configuration of the platforms depl= oyed in the enterprise to assure they comply with the site's security polic= y. PII is not collected. This is not monitoring of individual or employee = actions. I am not a lawyer and will not speak as one. We will let the lawy= er's decide at the appropriate time. Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: Martin Rex > Reply-To: "mrex@sap.com" > Date: Monday, August 6, 2012 11:32 AM To: "tony@yaanatech.com" > Cc: "mrex@sap.com" >= , "sacm@ietf.org" > Subject: Re: [sacm] Legal aspects of System monitoring Tony Rutkowski wrote: Martin Rex wrote: In Germany, an employer monitoring a company-owned PC that an employee uses for communication (EMail, VoiP, IM) would be unconditionally illegal. Really? No kidding! That is not consistent with comments I've seen concerning German law. There is a significant amount of mis-information floating the internet. And a mindboggling large number of lawyers are making wild guesses, rather that doing research. The decisions of the german federal constitional court (GFCC) have been quite consistent over the past decade about what with respect to encroaching on the general right of personality, informational self-determination, freedom of conduct and created a "fundamental right to the guarantee of the integrity and confidentiality of information technology systems". The court has set the minimum requirements that are prerequisite to such encroachment, such as the prerequisite of a clear formal statute law, which needs to be limited to situation where real facts create probable cause. The original GFCC decision in german language is quite comprehensible (to me, at least), while I'm having some difficulties understanding the english translation (and the english translation is shorter!?). BVerfG-Entscheidung "1 BvR 370/07 vom 27.2.2008" Randnummer 196- http://www.bverfg.de/entscheidungen/rs20080227_1bvr037007.html#abs196 english translation of "1 BvR 370/07 vom 27.2.2008" http://www.bverfg.de/entscheidungen/rs20080227_1bvr037007en.html#abs130 To be *unconditionally* illegal, would preclude almost any rationally required maintenance or threat mitigation. It is possible to perform maintenance and threat mitigation entirely without "monitoring" systems. A mere threat is insufficient for monitoring, if that involves collecting PII data, i.e. data from which a persons conduct can be infered. It is fair to observe that recent German Constitutional Court decisions impose constraints, but they certainly are not "unconditional." One of the prerequisite is a clear formal statute law, which currently does not exist for the purposes "sacm" is about. quoting from the above GFCC decision: 2. The fundamental right to the guarantee of the confidentiality and integrity of information technology systems is not unrestricted. Encroachments may be justified both for preventive purposes, and for criminal prosecution. The individual must only accept such restrictions of his or her right which are based on a statutory foundation that is constitutional. This currently makes collecting data about peoples conduct "unconditionally= " illegal for most practical purposes (exempting from prosecution only individual occasions of justified self-defence against an imminent vicious attack based on real facts that create probable cause). This applies to all surveillance that impairs persons "freedom of conduct". The majority of past decisions of specific events was about surveillance with a camera, but the GFCC decision makes it crystal clear that this applies to *any* kind of surveillance. Different to monitoring of computer systems, there is statutory law for camera surveillance, that allows optical surveillance under certain conditions (Art. 6b BDSG "BundesDatenSchutzGesetz). The lack of a formal statutory foundation makes surveillance illegal and entitles subjects to "cease and desist" rulings and sometimes damages. In one more recent (and constitutionally correct) rulings, an employer had put up a camera that had in view not only the entrance door, but also two workplaces. The employees protested against this camera, but the employer would not "fix" it, so at least one employee sued, The court confirmed that this camera surveillance at the workplace was illegal due to its chilling effect alone, and since it had been installed for a whole year, the employee was arwarded 4 month of income as damages (for the chilling effect). Another recent decision was about evidence from a covert video surveillance showing an employee taking a package of cigarettes on two occasions, where the German Federal Labour Court (the supreme court for labor related issues) remanded the decision to the trial court because it had failed to establish whether the covert video surveillance really met all constitutional prerequisites otherwise the video surveillance would have been illegal and not be admissible as evidence in court. (German decision: http://lexetius.com/2012,2351) The German Federal Constitional Court neutered numerous laws during the last decade due to lack of clarity and/or overbroad encroachment of the personal right of self-determination and the right to confidentiality of telecommunications. See also the GFCC decision about the scanning of license plates (the decision 1 BvR 2074/05 vom 11.3.2008 in german) http://www.bverfg.de/entscheidungen/rs20080311_1bvr2-07405.html where it confirmed that data collection requires formal statue law, and that the law in question wasn't limited to probable cause and therefore unconstitutional. The only currently existing formal statue law in Germany, that could be used in some limited fashion for "Monitoring" is Art.100 TKG, http://www.gesetze-im-internet.de/tkg_2004/__100.html but that statue is clearly limited in purpose, it will not allow that data to be used for automatic surveillance of "employee conduct" with respect to "company-defined policies". Employers try hard to avoid TKG for their networks (for which they will have to formally register), but that also means that they do not have a formal statutory law for performing any kind of surveillance/monitoring as described in Art. 100 TKG for systems that are used by employees for telecommunications and a significant part of their daily activies. -Martin _______________________________________________ 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 _______________________________________________ mile mailing list mile@ietf= .org https://www.ietf.org/mailman/listinfo/mile From david.waltermire@nist.gov Fri Aug 17 09:03:57 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62A1511E80A5; Fri, 17 Aug 2012 09:03:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.494 X-Spam-Level: X-Spam-Status: No, score=-6.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fd8GAVl46quI; Fri, 17 Aug 2012 09:03:56 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id EFE0921F852D; Fri, 17 Aug 2012 09:03:55 -0700 (PDT) Received: from WSXGHUB2.xchange.nist.gov (129.6.18.19) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 17 Aug 2012 12:03:12 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Fri, 17 Aug 2012 12:01:37 -0400 From: "Waltermire, David A." To: David Misell , Sean Turner Date: Fri, 17 Aug 2012 12:03:31 -0400 Thread-Topic: Re: [mile] IPR and Transfer Considerations Thread-Index: Ac11eHa/XXpvwEZjSw2lLT1nSZgzqAHGJtEg Message-ID: References: <1344032465.4236.17.camel@ubuntu> <50228291.1000002@ieca.com> In-Reply-To: <50228291.1000002@ieca.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "mile@ietf.org" , "dennis.groves@owasp.org" , "sacm@ietf.org" Subject: Re: [mile] IPR and Transfer Considerations X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 16:03:57 -0000 DQpEYXZpZCwNCg0KTXkgYXBvbG9naWVzIGZvciBub3QgcmVzcG9uZGluZyB0byB0aGlzIGVhcmxp ZXIuDQoNCk5JU1Qgd291bGQgbGlrZSB0byBzdWJtaXQgSW50ZXJuZXQgRHJhZnRzIChJL0RzKSBm b3IgcmVsZXZhbnQgTklTVCBwdWJsaWNhdGlvbnMgdGhhdCBhcmUgaW4gc2NvcGUgd2l0aCB0aGUg TUlMRSBvciBTQUNNIGNoYXJ0ZXJzLiAgVGhlIE5JU1QgcHVibGljYXRpb25zIGFyZSBub3Qgc3Vi amVjdCB0byB0cmFkZW1hcmsgb3IgY29weXJpZ2h0IGlzc3Vlcy4gICAgQW55dGhpbmcgTklTVCBw dWJsaXNoZXMgaXMgYXZhaWxhYmxlIGluIHRoZSBwdWJsaWMgZG9tYWluIGFjY29yZGluZyB0byBU aXRsZSAxNyBvZiB0aGUgVW5pdGVkIFN0YXRlcyBDb2RlLiAgV2Ugd291bGQgYmUgaGFwcHkgdG8g c3VibWl0IGRpc2Nsb3N1cmVzIGZvciBhbnkgTklTVCBwdWJsaWNhdGlvbnMgdGhhdCB3b3VsZCBi ZSBuZWVkZWQgdG8gcmVpdGVyYXRlIHRoaXMuDQoNClRvIGFkZHJlc3MgdGhlIHNwZWNpZmljYXRp b24gcmVmZXJlbmNlIGNvbmNlcm4sIG9uZSBvcHRpb24gd291bGQgYmUgdG8gcHVibGlzaCBleGlz dGluZyBzcGVjaWZpY2F0aW9ucyBhcyBJRVRGIGluZGl2aWR1YWwgY29udHJpYnV0aW9ucy4gIEkg aGF2ZSBiZWVuIHRvbGQgdGhhdCBpdCBtYXkgYmUgcG9zc2libGUgdG8gcHVibGlzaCBhbiBpbmZv cm1hdGlvbmFsIFJGQyBiYXNlZCBvbiB0aGUgY3VycmVudCBzcGVjaWZpY2F0aW9uIHJldmlzaW9u cy4gIFRoaXMgcHJvdmlkZXMgYSBtZWFucyB0byByZWZlcmVuY2UgdGhlIGluaXRpYWwgc3VibWlz c2lvbiB3aGlsZSBhbGxvd2luZyB0aGUgc3BlY2lmaWNhdGlvbiB0byBldm9sdmUgYXMgd2VsbC4N Cg0KSSBsb29rIGZvcndhcmQgdG8gd29ya2luZyB0aHJvdWdoIHRoZXNlIGlzc3VlcyBzbyB0aGF0 IHdlIGNhbiBmb2N1cyBiYWNrIG9uIHRoZSB0ZWNobmljYWwgd29yayBhdCBoYW5kLg0KDQpTaW5j ZXJlbHksDQpEYXZlDQoNCi0tLS0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0tLS0NClN1Ympl Y3Q6IFJlOiBbbWlsZV0gSVBSIGFuZCBUcmFuc2ZlciBDb25zaWRlcmF0aW9ucw0KRGF0ZTogRnJp LCAwMyBBdWcgMjAxMiAyMjoyMTowNSArMDAwMA0KRnJvbTogRGF2aWQgTWlzZWxsIDxkYXZpZC5t aXNlbGxAYnRpbnRlcm5ldC5jb20+DQpSZXBseS1UbzogRGF2aWQuTWlzZWxsQGJjcy5vcmcNCk9y Z2FuaXphdGlvbjogQ3liZXJBd2FyZQ0KVG86IFNlYW4gVHVybmVyIDx0dXJuZXJzQGllY2EuY29t Pg0KQ0M6IEJha2VyLCBKb24gPGJha2VyakBtaXRyZS5vcmc+LCBtaWxlQGlldGYub3JnIDxtaWxl QGlldGYub3JnPiwgZGVubmlzLmdyb3Zlc0Bvd2FzcC5vcmcNCg0KU2VhbiwNCg0KSSBoYWQgYW4g aW4gZGVwdGggY29udmVyc2F0aW9uIGZvbGxvd2luZyB0aGUgY29uZmVybmNlIGNhbGwgYXQgd2hp Y2ggSSByZWFzaWVkIHNvbWVvZiB0aGVzZSBpc3N1ZXMuDQoNClRvIGJlIGZyYW5rIHRoZSBNSVRS RSBJUFIgaXMgYSBtYXJrZXRpbmcgY2FtcGFpZ24gc3VwcG9ydGluZyB0aGUgZm9sbG93aW5nIGJy YW5kZWQgVGVybXMgZnJvbXRoZSBDUEUgd2ViIHNpdGUgY3BlLm1pdHJlLm9yZzthcyB3aXRobmVz c2VkIGF0IHZhcmlvdXMgc2VjdWlydHkgaW5kdWN0cnkgZXZlbnQgc2luY2UgMjAwOS4NCg0KDQpH b2luZyBmb3J3YXJkIHZvbHVudGVlciBzZWN0b3IsIElFVEYgYW5kIE9XQVNQLCBCQ1MgYW5kIElF VCB3aWxsIGFsbCBoYXZlIHNpbWlsYXIgd29ya3MgaW4gcHJvZ3Jlc3MsIGFsc28gcG90ZW50aWFs bHkgaW4gc3VwcG9ydCBvZiBOSVNUIDgwMCBiZXN0IHByYWN0aXNlIHJlY29tbWVuZGF0aW9ucy4N Cg0KSWYgd2UgYXJlIHRvIHByb2dyZXNzIHRoaXMsIHRoZSBiZXN0IGZvcm1hdCBtYXkgYmUgdG8g YWRvcHQgY3JlYXRpdmUgY29tbW9ucywgcmVuYW1lIGFuZCBhdm9pZCB0aGUgZm9sbG93aW5nIGJy YW5kZWQgdGVybXMsIHVubGVzcyB0aGV5IGNhbiBiZSBpbiBzb21lIHdheSBvcGVuZWQgIHRvIG1v cmUgdGhhbiAiZnJlZSBmb3IgIHB1YmxpYyB1c2UiLCB3aGljaCB3b3VsZCBhbGxvdyBVUyBlbmZv cmNlbWVudCBvZiBJUFIgaW4gYSB1bmlsYXRlcmFsIHdheSwgYXMgaXMgY3VycmVudGx5IGJlaW5n IGxlZ2lzdGFsdGVkIGZvci4NCg0KDQpmb3IgZXhhbXBsZSBob3cgd291bGQgSSBiZSBhYmxlIHRv IHRyYWluIENWRSB0ZXJtcyBtaXJyb2VkIHRvIE5JU1QgODAwIHNlcmllcyBiZXN0IHByYWN0aWNl IHdpdGhvdXQgcGF5aW5nIE1JVFJFIGEgcm95YWx0eS4NCg0KDQoNCkNvbmZpZ3VyYXRpb25zIChD Q0UpDQoNClZ1bG5lcmFiaWxpdGllcyAoQ1ZFKQ0KDQpTb2Z0d2FyZSBXZWFrbmVzcyBUeXBlcyAo Q1dFKQ0KDQpBdHRhY2sgUGF0dGVybnMgKENBUEVDKQ0KDQpDeWJlciBPYnNlcnZhYmxlcyAoQ3li T1gpDQoNCkxvZyBGb3JtYXQgKENFRSkNCg0KDQpTb2Z0d2FyZSBJRCBUYWdzIChTV0lEcykNCg0K TWFsd2FyZSAoTUFFQykNCg0KQ2hlY2tsaXN0IExhbmd1YWdlIChYQ0NERikNCg0KQXNzZXNzbWVu dCBMYW5ndWFnZSAoT1ZBTCkNCg0KU2VjdXJpdHkgQ29udGVudCBBdXRvbWF0aW9uIChTQ0FQKQ0K DQpNYWtpbmcgU2VjdXJpdHkgTWVhc3VyYWJsZQ0KDQoNCldoYXQgYXNzdXJhbmNlIGNhbiB5b3Ug Z2l2ZSB0aGEgbm8gSVBSIHByb3RlY3Rpb24gd2lsbCBiZSBleGVydGVkIGF0IGFueSBwb2ludCBp biB0aGUgZnV0dXJlIG9uIGJlaGFsZiBvZiBNSVRSRSBieSBVUyBnb3Zlcm5tZW50LCBob3cgY2Fu IHdlIGFzc3VyZSBhIGNyZWF0aXZlIGNvbW1vbnMgc3R5bGUgYXBwcm9hY2guDQoNCllvdXJzIEZh aXRoZnVsbHksDQoNCkRhdmUNCg0KRGF2aWQgUyBNaXNlbGwgTVNjIChJbmZvcm1hdGlvbiBTZWN1 cml0eSBSSFVMKSBNQkNTIENJU1NQDQoNCg0KT24gRnJpLCAyMDEyLTA4LTAzIGF0IDExOjExIC0w NzAwLCBTZWFuIFR1cm5lciB3cm90ZToNCj4gT24gOC8zLzEyIDg6MjcgQU0sIEJha2VyLCBKb24g d3JvdGU6DQo+ID4gRHVyaW5nIHRoZSBNSUxFIFdHIHNlc3Npb24gdGhlcmUgd2VyZSBxdWVzdGlv bnMgcmFpc2VkIHJlbGF0ZWQgdG8gTUlUUkUgSVBSLiBJIHdvdWxkIGxpa2UgdG8gbWFrZSBzdXJl IHRoYXQgdGhlIGxpc3QgaXMgYXdhcmUgdGhhdCBNSVRSRSBoYXMgYWNjb21tb2RhdGVkIGFsbCBJ UFIgcmVsYXRlZCByZXF1ZXN0cyB0aGF0IGhhdmUgYmVlbiBtYWRlIGJ5IHRoaXMgZ3JvdXAuIFRo ZXJlIGFyZSB0aHJlZSBpc3N1ZXMgdGhhdCBoYXZlIGJlZW4gcmFpc2VkOg0KPiA+DQo+ID4gMS0g U2hvcnRseSBiZWZvcmUgdGhlIFBhcmlzIG1lZXRpbmcgKElFVEYgODMpIGEgY29uY2VybiB3YXMg cmFpc2VkIGFib3V0IHRoZSB3b3JkaW5nIGluIHRoZSBkaXNjbGFpbWVyIHBvcnRpb24gb2Ygb3Vy IHRlcm1zIG9mIHVzZSBwYWdlcyBub3QgYWxpZ25pbmcgd2VsbCB3aXRoIHRoZSB3b3JkaW5nIHRo YXQgdGhhdCBJRVRGIHVzZXMuIEF0IHRoYXQgdGltZSB3ZSBtYWRlIGEgc21hbGwgY2hhbmdlIHRv IHRoZSBkaXNjbGFpbWVyIGZvciBhbGwgdGhlIHJlbGV2YW50IGVmZm9ydHMgd2Ugc3VwcG9ydC4g VG8gdGhlIGJlc3Qgb2YgbXkga25vd2xlZGdlLCB0aGlzIGlzc3VlIHdhcyBhZGRyZXNzZWQuDQo+ ID4NCj4gPiAyLSBBdCB0aGUgUGFyaXMgbWVldGluZyBpdCB3YXMgY2xlYXIgdGhhdCB0aGVyZSB3 YXMgY29uZnVzaW9uIGFib3V0IHRoZSBsaWNlbnNpbmcgb2YgQ1ZFIGFuZCBzZXZlcmFsIG90aGVy IGVmZm9ydHMuIEkgd2FzIGFza2VkLCAiSG93IG11Y2ggZG9lcyBDVkUgY29zdD8iIFRoaXMgdG9v IGhhcyBiZWVuIGFkZHJlc3NlZC4gQ1ZFIGFuZCB0aGVzZSBvdGhlciBlZmZvcnRzIGFyZSBjbGVh cmx5IGZyZWUgdG8gdXNlLg0KPiA+DQo+ID4gMy0gTGFzdGx5LCBkdXJpbmcgdGhlIE1JTEUgV0cg c2Vzc2lvbiBUdWVzZGF5IG9mIHRoaXMgd2VlaywgaXQgd2FzIG1hZGUgY2xlYXIgdGhhdCBNSVRS RSBuZWVkcyB0byBwb3N0IElQUiBkaXNjbG9zdXJlcyBmb3IgYWxsIG9mIHRoZSByZWxldmFudCBl ZmZvcnRzIHRoYXQgTUlUUkUgc3VwcG9ydHMuIEFzIG9mIEF1Z3VzdCAyLCAyMDEyIElQUiBkaXNj bG9zdXJlcyBoYXZlIGJlZW4gc3VibWl0dGVkLiBJIGRvbid0IHRoaW5rIHRoZXkgaGF2ZSBiZWVu IHBvc3RlZCBieSB0aGUgSUVURiB5ZXQuDQo+DQo+IEkgY2hlY2tlZCB3aXRoIHRoZSBzZWNyZXRh cmlhdCBhbmQgdGhleSd2ZSBiZWVuIHN1Ym1pdHRlZC4gIFRoYW5rcy4NCj4NCj4gPiBBcmUgdGhl cmUgb3RoZXIgSVBSIGNvbmNlcm5zIHRoYXQgd2UgYXJlIG5vdCBhd2FyZSBvZj8NCj4NCj4gVGhp cyBpcyBoYXJkIHRvIGFuc3dlciB3aXRob3V0IGhhdmluZyBzZWVuIHRoZSBkaXNjbG9zdXJlLg0K Pg0KPiBNSUxFIFdHOiBXaGVuIHRoZXkncmUgcG9zdGVkIHJldmlldyB0aGVtLg0KPg0KPiBzcHQN Cj4NCj4gPiBUaGVyZSB3ZXJlIGFsc28gcXVlc3Rpb25zIHJhaXNlZCBhYm91dCBNSVRSRSdzIHdp bGxpbmduZXNzIHRvIHRyYW5zZmVyIElQUiB0byB0aGUgSUVURi4gSSBhdHRlbmRlZCB0aGUgUGFy aXMgbWVldGluZyAoSUVURiA4MykgYW5kIGR1cmluZyB0aGUgU0FDTSBzaWRlIG1lZXRpbmcgd2Fz IGdpdmVuIHRoZSBvcHBvcnR1bml0eSB0byBkaXNjdXNzIE1JVFJFJ3MgcGVyc3BlY3RpdmUgb24g dGhpcyB0b3BpYy4gQXQgdGhlIHRpbWUgSSB0YWxrZWQgdGhyb3VnaCB3aGF0IE1JVFJFIHNlZXMg YXMgdGhlIGtleSBkaXN0aW5jdGlvbnMgdG8gYmUgbWFkZSB3aGVuIGNvbnNpZGVyaW5nIHRyYW5z ZmVycmluZyBhIGdpdmVuIGVmZm9ydCB0byBhbnkgb3RoZXIgb3JnYW5pemF0aW9uLiBBcyBhIHJl bWluZGVyIEkgZGlzY3Vzc2VkIHRoZSBmb2xsb3dpbmc6DQo+ID4NCj4gPiBSRUdJU1RSSUVTIFZT LiBMQU5HVUFHRVMNCj4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4g Um91Z2hseSBzcGVha2luZywgZWZmb3J0cyBjYW4gYmUgZ3JvdXBlZCBpbnRvIHR3byBwcmltYXJ5 IGNhdGVnb3JpZXM6IHJlZ2lzdHJpZXMgb2YgbmFtZWQgb2JqZWN0cyAoZS5nLiBDVkUpIGFuZCBs YW5ndWFnZXMgZm9yIGRlZmluaW5nIHN0cnVjdHVyZWQgY29udGVudCAoZS5nLiBPVkFMKS4gQXMg YSBydWxlLCBsYW5ndWFnZXMgYXJlIGdvb2QgY2FuZGlkYXRlcyB0byBnbyB0byBmb3JtYWwgc3Rh bmRhcmRzIGJvZGllcyBhcyB0aGV5IG1hdHVyZS4gSW4gY29udHJhc3QsIHdoaWxlIHJlZ2lzdHJp ZXMgbWF5IGJlIHJlZmVycmVkIHRvIGJ5IHRoZSB3b3JrIGRldmVsb3BlZCBpbiBzdGFuZGFyZHMg Ym9kaWVzIGFzIGV4dGVybmFsIGRlcGVuZGVuY2llczsgc3RhbmRhcmRzIGJvZGllcyBkbyBub3Qg dHlwaWNhbGx5IG9wZXJhdGUgcmVnaXN0cmllcy4NCj4gPg0KPiA+IEVGRk9SVFMgSEFWRSBNVUxU SVBMRSBTVUJDT01QT05FTlRTDQo+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4gUmVnaXN0cmllcyB0ZW5kIHRvIGhhdmUgdGhyZWUg cHJpbWFyeSBzdWItY29tcG9uZW50cywgaW5jbHVkaW5nOg0KPiA+ICAgICAgIGkpIHRoZSBzeW50 YXggb2YgdGhlIG5hbWVzcGFjZSwNCj4gPiAgICAgICBpaSkgdGhlIHJlZ2lzdHJ5IG9mIG9mZmlj aWFsbHkgcmVjb2duaXplZCBvYmplY3RzIGFuZA0KPiA+ICAgICAgIGlpaSkgZGVmaW5pdGlvbnMg b2YgYWNjZXB0YWJsZSB1c2UgKHdoaWNoIG1heSBpbmNsdWRlIHByb2R1Y3QgdGVzdGluZyByZXF1 aXJlbWVudHMpLg0KPiA+IExhbmd1YWdlcyB0ZW5kIHRvIGhhdmUgZm91ciBwcmltYXJ5IHN1Yi1j b21wb25lbnRzLCBpbmNsdWRpbmc6DQo+ID4gICAgICAgaSkgdGhlIHNwZWNpZmljYXRpb24gb2Yg dGhlIGxhbmd1YWdlLA0KPiA+ICAgICAgIGlpKSByZXBvc2l0b3JpZXMgb2YgY29udGVudCB3cml0 dGVuIGluIHRoYXQgbGFuZ3VhZ2UsDQo+ID4gICAgICAgaWlpKSBhIHJlZmVyZW5jZSBpbXBsZW1l bnRhdGlvbiB0aGF0IGNhbiBiZSB1c2VkIHRvIHZlcmlmeSBib3RoIHRoZSBsYW5ndWFnZSBhbmQg Y29udGVudCBhdXRob3JlZCBpbiB0aGUgbGFuZ3VhZ2UgYW5kDQo+ID4gICAgICAgaXYpIGRlZmlu aXRpb25zIG9mIGFjY2VwdGFibGUgdXNlICh3aGljaCBtYXkgaW5jbHVkZSBwcm9kdWN0IHRlc3Rp bmcgcmVxdWlyZW1lbnRzKS4NCj4gPiBUaGVzZSBjb21wb25lbnRzIG5lZWQgdG8gYmUgY29uc2lk ZXJlZCBzZXBhcmF0ZWx5Lg0KPiA+DQo+ID4gVVNHIEVGRk9SVFMgVlMuIE1JVFJFIE1BTkFHRUQg RUZGT1JUUw0KPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCj4gPiBJbiBjb25zaWRlcmluZyB0aGUgdHJhbnNpdGlvbiBvZiBNSVRSRSBl ZmZvcnRzIHRvIHN0YW5kYXJkcyBib2RpZXMgYW5kIGhvdyB0aGVzZSBkZWNpc2lvbnMgd2lsbCBi ZSBtYWRlLCBpdCBpcyBpbXBvcnRhbnQgdG8gY2xlYXJseSBkaXN0aW5ndWlzaCBiZXR3ZWVuIFVT IEdvdmVybm1lbnQgKFVTRykgZWZmb3J0cyBhbmQgZWZmb3J0cyB0aGF0IG91ciBzcG9uc29ycyBo YXZlIGRpcmVjdGVkIE1JVFJFIHRvIG9wZXJhdGUgYXMgYSBuZXV0cmFsIDNyZCBwYXJ0eSB1bmRl ciBvdXIgRkZSREMgY2hhcnRlci4NCj4gPg0KPiA+DQo+ID4gQXMgeW91IG1pZ2h0IGltYWdpbmUg dGhpcyBsZWFkcyB0byBhIHNvcnQgb2YgbWF0cml4IHRoYXQgbXVzdCBiZSBjb25zaWRlcmVkIHRv IHVsdGltYXRlbHkgZW5zdXJlIHRoYXQgYSBzdWNjZXNzZnVsIGFuZCBhcHByb3ByaWF0ZSB0cmFu c2l0aW9uIGlzIG1hZGUgZm9yIGFueSBnaXZlbiBlZmZvcnQuIE91dHNpZGUgdGhlIE1JTEUgYW5k IFNBQ00gbGlzdHMgdGhlcmUgYXJlIG1hbnkgb3JnYW5pemF0aW9ucyB0aGF0IGRlcGVuZCB1cG9u IHRoZSBlZmZvcnRzIHRoYXQgTUlUUkUgaGFzIGxlZCBmb3IgbWFueSB5ZWFycywgaW4gc29tZSBj YXNlcyBpdCBpcyBzZXZlcmFsIGh1bmRyZWQgb3IgbW9yZS4gSW4gZmFjdCwgaXQgaXMgaGFyZCB0 byBpbWFnaW5lIGFuIElORk9TRUMgcHJvZmVzc2lvbmFsIGluIHRoZSBVUyB0aGF0IGhhcyBub3Qg dXNlZCBDVkUgKGVpdGhlciBkaXJlY3RseSBvciBpbmRpcmVjdGx5KSAgaW4gdGhlaXIgY2FyZWVy IGFuZCBDVkUgaXMgdHJhbnNsYXRpb25zIGFyZSBhdmFpbGFibGUgaW4gbWFueSBvdGhlciBsYW5n dWFnZXMgdG9vLiBNSVRSRSBoYXMgYSByZXNwb25zaWJpbGl0eSB0byBlbnN1cmUgdGhlIHN0YWJp bGl0eSBvZiB0aGVzZSBlZmZvcnRzIGFuZCBub3QgbG9zZSBzaWdodCBvZiB0aGUgY29tbXVuaXR5 IHRoYXQgZGVwZW5kcyB1cG9uIHRoZW0gdG9kYXkuDQo+ID4NCj4gPiBSZXN0IGFzc3VyZWQgdGhh dCBNSVRSRSBhbmQgb3VyIHNwb25zb3JzIHZpZXcgc3VjY2Vzc2Z1bCB0cmFuc2ZlciBvZiBzdGFu ZGFyZHMgdG8gaW50ZXJuYXRpb25hbCBib2RpZXMgYXMgdGhlIHVsdGltYXRlIGdvYWwgb2YgbXVj aCBvZiBvdXIgc3RhbmRhcmRzIHdvcmsuIE1JVFJFIGlzIGFjdGl2ZWx5IGZvbGxvd2luZyB0aGUg TUlMRSBhbmQgU0FDTSBsaXN0cywgaGFzIHJhaXNlZCBhd2FyZW5lc3Mgb2YgdGhlIHJlbGV2YW50 IElFVEYgYWN0aXZpdGllcyBpbiB0aGUgZXhpc3Rpbmcgc3RhbmRhcmRzIHJlbGF0ZWQgZm9ydW1z IHRoYXQgd2UgaG9zdCwgYW5kIGlzIGFjdGl2ZWx5IGVuZ2FnaW5nIHdpdGggb3VyIHNwb25zb3Jz IG9uIHRoZSB0b3BpYyBvZiBpbnRlcm5hdGlvbmFsIHN0YW5kYXJkcy4NCj4gPg0KPiA+IFRoYW5r cywNCj4gPg0KPiA+IEpvbg0KPiA+DQo+ID4gPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT0NCj4gPiBKb25hdGhhbiBPLiBCYWtlcg0KPiA+IEcwMjIgLSBJQSBJbmR1 c3RyeSBDb2xsYWJvcmF0aW9uDQo+ID4gVGhlIE1JVFJFIENvcnBvcmF0aW9uDQo+ID4gRW1haWw6 IGJha2VyakBtaXRyZS5vcmcNCj4gPg0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBtaWxlIG1haWxpbmcgbGlzdA0KPiA+IG1pbGVA aWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21pbGUN Cj4gPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiBtaWxlIG1haWxpbmcgbGlzdA0KPiBtaWxlQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbWlsZQ0KDQotLQ0KS2luZCBSZWdhcmRzLA0KZGF2ZQ0KRGF2 aWQgUy4gTWlzZWxsLA0KMDc3MTAzODAwNDQNCg0KDQoNCg0K From dcougias@netfrontiers.com Wed Aug 8 11:55:18 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 699B821F86CA for ; Wed, 8 Aug 2012 11:55:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.704 X-Spam-Level: X-Spam-Status: No, score=-2.704 tagged_above=-999 required=5 tests=[AWL=-0.298, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_HTML_MOSTLY=0.001, MPART_ALT_DIFF=0.739, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wVKt024Zkw7j for ; Wed, 8 Aug 2012 11:55:18 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id EACB421F86BB for ; Wed, 8 Aug 2012 11:55:17 -0700 (PDT) Received: by yenm5 with SMTP id m5so1250133yen.31 for ; Wed, 08 Aug 2012 11:55:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:reply-to:to:cc:message-id:references:subject:mime-version :content-type:user-agent:x-mailer:x-gm-message-state; bh=amD2SPWYi4u47AbVjstM9FlSele0ftgEquah/afZfKo=; b=Eygm+xv4GIZdj4XOtQ9Djfj2joDoRhVV7Bjk6aonOfyYxdZH1fC5liA9p538mv5Hx+ ewETSiLlA1LEBFdFZ/ZRImlBmMPhCOvY7ubdNQhGrL9VlXlkTdNtzI3AvQ5Zb+ZDfesw MJAdc8mu6aIOHP6LhPLOS0sJLamua2QFkkOjTV1HU7Gkapa+D4AnK3A6p+eRVFAE5iNf FN+cSAtR+oj89DoiEvsqCKM09VaIvHTxLSMpZU4zYaZ7eyF0oCnLDWP8Tn0zwBZddTHz I8ocDDp46ALfl4ONYdiU1H9qV1DtQPM8KCeQrtIeKXGgxBAxjd5i0GtUOuDKeYCPFENJ Hiig== Received: by 10.66.76.170 with SMTP id l10mr2649030paw.57.1344452117090; Wed, 08 Aug 2012 11:55:17 -0700 (PDT) Received: from sender1.zohomail.com (sender1.zohomail.com. [72.5.230.103]) by mx.google.com with ESMTPS id mu8sm940751pbc.49.2012.08.08.11.55.16 (version=SSLv3 cipher=OTHER); Wed, 08 Aug 2012 11:55:16 -0700 (PDT) Date: Wed, 08 Aug 2012 11:55:15 -0700 From: Dorian Cougias To: Message-ID: <13907973c00.7901413989719813492.-7814053128682371062@netfrontiers.com> References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_41137_666322672.1344452115455" User-Agent: Zoho Mail X-Mailer: Zoho Mail X-Gm-Message-State: ALoCoQlQGNGGtKuyZRPlTLFUHHcQkqAag1VZ/gx8jp2eZ57V2Ad3851RpfGBPWTjzUk2vWb0p2LW X-Mailman-Approved-At: Mon, 20 Aug 2012 02:27:04 -0700 Cc: Ruben Oliva , mile@ietf.org, sacm@ietf.org Subject: Re: [mile] =?utf-8?q?=5Bsacm=5D_Strategic_alignment_of_security_with_?= =?utf-8?q?business_in_SACM_in=C2=A0=C2=A0=C2=A0=C2=A0an_international_con?= =?utf-8?q?text?= X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcougias@netfrontiers.com List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 18:55:18 -0000 ------=_Part_41137_666322672.1344452115455 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit ------=_Part_41137_666322672.1344452115455 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 7bit The UCF will provide a common mapping for you, with unique and persistent IDs.

I can provide UCF spreadsheets to those of you who need them.



Dorian J. Cougias
Compliance Scientist
Unified Compliance Framework

------=_Part_41137_666322672.1344452115455-- From dcougias@netfrontiers.com Wed Aug 8 22:20:34 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7435E21E8048 for ; Wed, 8 Aug 2012 22:20:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.605 X-Spam-Level: X-Spam-Status: No, score=-2.605 tagged_above=-999 required=5 tests=[AWL=-0.199, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_HTML_MOSTLY=0.001, MPART_ALT_DIFF=0.739, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tDcW4qwzviyu for ; Wed, 8 Aug 2012 22:20:33 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id AD60511E8197 for ; Wed, 8 Aug 2012 22:20:33 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so294954pbb.31 for ; Wed, 08 Aug 2012 22:20:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:reply-to:to:cc:message-id:in-reply-to:references:subject :mime-version:content-type:user-agent:x-mailer:x-gm-message-state; bh=cjdTylvRZ76zB/JsMoblBxre+yJMYqVZTmSyK3nGhqA=; b=QLezAqaHhgfOsV4f8z4wyCBQICPDspFGwdFxNXszf/HCyCSmBnNQ4A0vMuCKOSSXyB B7056Wv3c5+YREEjRpZ4/J6qQDFaUlZZM1HfqS016RbkrUZjx1hofk4fiqpPLMBpsLyI sNN5WjGvjnXLOw9SOJcParLJcNBIHksLAjvdA0I4R5bBwbiOGMQ8UEYf8TKfHm2PAhZ1 OvsV/rYcU48I7OuEXEviCof5dwvUDdjFKOHtRYweA7zIPY3SE5Jk3jbMBFwX8Kx2xE6R gRDkwfuKxn47EtA4RuHsL6POlZ884sPn4JCSHxRwv7Wps25vTYNOIRv2Fi3WkYLrzOS7 YCNw== Received: by 10.68.216.130 with SMTP id oq2mr1070941pbc.128.1344489632350; Wed, 08 Aug 2012 22:20:32 -0700 (PDT) Received: from sender1.zohomail.com (sender1.zohomail.com. [72.5.230.103]) by mx.google.com with ESMTPS id ro7sm403005pbc.8.2012.08.08.22.20.31 (version=SSLv3 cipher=OTHER); Wed, 08 Aug 2012 22:20:31 -0700 (PDT) Date: Wed, 08 Aug 2012 22:20:30 -0700 From: Dorian Cougias To: Message-ID: <13909d3ab47.-5115805132147148239.9049257756692791623@netfrontiers.com> In-Reply-To: <5AB51D51-9781-4056-BAA9-86332F30D22E@c3isecurity.com> References: <5AB51D51-9781-4056-BAA9-86332F30D22E@c3isecurity.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_49826_1053857104.1344489630534" User-Agent: Zoho Mail X-Mailer: Zoho Mail X-Gm-Message-State: ALoCoQmoIZNAJ8LEAGmyA+pjZ+N9Sunu2f1KsbWTMIL7p+C0hRIUZIhnx/gIWpdQDFC6HxWyt3fo X-Mailman-Approved-At: Mon, 20 Aug 2012 02:27:04 -0700 Cc: Ruben Oliva , mile@ietf.org, dcougias@netfrontiers.com, sacm@ietf.org Subject: Re: [mile] =?utf-8?q?=5Bsacm=5D_Strategic_alignment_of_security_with_?= =?utf-8?q?business_in_SACM_in=C2=A0=C2=A0=C2=A0=C2=A0an_international_con?= =?utf-8?q?text?= X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcougias@netfrontiers.com List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 05:20:35 -0000 ------=_Part_49826_1053857104.1344489630534 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit ------=_Part_49826_1053857104.1344489630534 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = Yes, the UCF is fully copyrighted. However, we make specific wr= itten allowances.



Dorian J. Cou= gias
Compliance Scientist
Unified Compliance Framework<= /div>

---- On Wed, 08 Aug 2012 14:48:07 -0700 lnunez@c3isecurity.com wrote -= ---
I would be interested in reviewing a copy.



BTW = are there any IPR attached to the UCF document.



Thanks d= orian.



-ln

On Aug 8, 2012, at 2:55 PM, Dorian C= ougias wrote:



> The UCF will provide a common mapping= for you, with unique and persistent IDs.

>

> I ca= n provide UCF spreadsheets to those of you who need them.

>
>

>

> Dorian J. Cougias

> C= ompliance Scientist

> Unified Compliance Framework

>= ;



------=_Part_49826_1053857104.1344489630534-- From dcougias@netfrontiers.com Wed Aug 8 22:20:40 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BB4221E8053 for ; Wed, 8 Aug 2012 22:20:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=-0.119, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_HTML_MOSTLY=0.001, MPART_ALT_DIFF=0.739, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CrNeIyTDFr4A for ; Wed, 8 Aug 2012 22:20:40 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 41C6821E8048 for ; Wed, 8 Aug 2012 22:20:39 -0700 (PDT) Received: by yhq56 with SMTP id 56so65493yhq.31 for ; Wed, 08 Aug 2012 22:20:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:reply-to:to:cc:message-id:in-reply-to:references:subject :mime-version:content-type:user-agent:x-mailer:x-gm-message-state; bh=DmS5q0L3WsxqeCdkF8GoOWkIs0fxkBk2BT2tH79fm4w=; b=YQqNRD92wjHGxcxu63jmnnX9ssDsQub2tWbPAoJhgv6mGTnKvsF7bcwjk8TniwQHX9 F67iIMXszLtTj/Dbcucrm1aeRrb0qcoGdrrkUv8zucKhcNzYq+KR78OYafJuy732hmfw CHQvoqju9LZSgSthraZ3PqGEE5dz0K6SSydj/1hdFw9SxkVGwdUNpto+s9nHQwMKKx18 JYIOsBlyIdIosBwvOc0I8tOukWOlTG1jcxEtcIz61xPfYPkMVFCbYtnoJPDVR3yfKyEW 10JAaXV3VsxA5b4LsFsYIlDci4XOElUufzub1mI+cdjtBkwLejCF2ZgmcuFQ/SjNiKhW WO8A== Received: by 10.66.88.198 with SMTP id bi6mr39110793pab.23.1344489639001; Wed, 08 Aug 2012 22:20:39 -0700 (PDT) Received: from sender1.zohomail.com (sender1.zohomail.com. [72.5.230.103]) by mx.google.com with ESMTPS id os2sm400910pbc.16.2012.08.08.22.20.38 (version=SSLv3 cipher=OTHER); Wed, 08 Aug 2012 22:20:38 -0700 (PDT) Date: Wed, 08 Aug 2012 22:20:37 -0700 From: Dorian Cougias To: Message-ID: <13909d3c6f5.6849302158992868120.-1337740793655790815@netfrontiers.com> In-Reply-To: <5AB51D51-9781-4056-BAA9-86332F30D22E@c3isecurity.com> References: <5AB51D51-9781-4056-BAA9-86332F30D22E@c3isecurity.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_50636_1477024047.1344489637620" User-Agent: Zoho Mail X-Mailer: Zoho Mail X-Gm-Message-State: ALoCoQkKQdsmdSc1io4QH901pmJD3CRHyGqSm/gDssAArvv7ki4Juy41SX9r2e8WEGnbtWzHem5i X-Mailman-Approved-At: Mon, 20 Aug 2012 02:27:04 -0700 Cc: Ruben Oliva , mile@ietf.org, dcougias@netfrontiers.com, sacm@ietf.org Subject: Re: [mile] =?utf-8?q?=5Bsacm=5D_Strategic_alignment_of_security_with_?= =?utf-8?q?business_in_SACM_in=C2=A0=C2=A0=C2=A0=C2=A0an_international_con?= =?utf-8?q?text?= X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcougias@netfrontiers.com List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 05:20:40 -0000 ------=_Part_50636_1477024047.1344489637620 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit ------=_Part_50636_1477024047.1344489637620 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = Yes, the UCF is fully copyrighted. However, we make specific wr= itten allowances.



Dorian J. Cou= gias
Compliance Scientist
Unified Compliance Framework<= /div>

---- On Wed, 08 Aug 2012 14:48:07 -0700 lnunez@c3isecurity.com wrote -= ---
I would be interested in reviewing a copy.



BTW = are there any IPR attached to the UCF document.



Thanks d= orian.



-ln

On Aug 8, 2012, at 2:55 PM, Dorian C= ougias wrote:



> The UCF will provide a common mapping= for you, with unique and persistent IDs.

>

> I ca= n provide UCF spreadsheets to those of you who need them.

>
>

>

> Dorian J. Cougias

> C= ompliance Scientist

> Unified Compliance Framework

>= ;



------=_Part_50636_1477024047.1344489637620-- From david.oliva@verizon.net Thu Aug 9 05:58:05 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCFAF21F86BD; Thu, 9 Aug 2012 05:58:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.381 X-Spam-Level: X-Spam-Status: No, score=-0.381 tagged_above=-999 required=5 tests=[AWL=0.211, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, MIME_8BIT_HEADER=0.3, MIME_HTML_ONLY=1.457, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XT5JaYIrhGdN; Thu, 9 Aug 2012 05:58:05 -0700 (PDT) Received: from vms173001pub.verizon.net (vms173001pub.verizon.net [206.46.173.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17C5221F86A8; Thu, 9 Aug 2012 05:58:04 -0700 (PDT) Received: from vms170025pub.verizon.net ([unknown] [192.168.1.3]) by vms173001.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0M8H00JP7O0DJ8IX@vms173001.mailsrvcs.net>; Thu, 09 Aug 2012 07:57:49 -0500 (CDT) Received: from 96.241.55.45 ([96.241.55.45]) by vms170025 (Verizon Webmail) with HTTP; Thu, 09 Aug 2012 07:57:49 -0500 (CDT) Date: Thu, 09 Aug 2012 07:57:49 -0500 (CDT) From: david.oliva@verizon.net To: dcougias@netfrontiers.com, lnunez@c3isecurity.com Message-id: <23623150.93912.1344517069256.JavaMail.root@vms170025> MIME-version: 1.0 Content-type: text/html; charset=UTF-8 Content-transfer-encoding: 7bit X-Mailer: Verizon Webmail X-Originating-IP: [96.241.55.45] X-Mailman-Approved-At: Mon, 20 Aug 2012 02:27:04 -0700 Cc: david.oliva@verizon.net, mile@ietf.org, sacm@ietf.org Subject: Re: [mile] =?utf-8?q?=5Bsacm=5D_Strategic_alignment_of_security_with_?= =?utf-8?q?business_in_SACM_in=C2=A0=C2=A0=C2=A0=C2=A0an_international_con?= =?utf-8?q?text?= X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 12:58:06 -0000
Phenomenal!
 
Can you please send me (us) one?
 
David Oliva
 
 
On 08/08/12, Dorian Cougias<dcougias@netfrontiers.com> wrote:
 
The UCF will provide a common mapping for you, with unique and persistent IDs.

I can provide UCF spreadsheets to those of you who need them.



Dorian J. Cougias
Compliance Scientist
Unified Compliance Framework

From tonynad@microsoft.com Thu Aug 9 07:53:34 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C218421F871E; Thu, 9 Aug 2012 07:53:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.056 X-Spam-Level: X-Spam-Status: No, score=-2.056 tagged_above=-999 required=5 tests=[AWL=1.110, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P3EuoXIUVE1M; Thu, 9 Aug 2012 07:53:33 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe004.messaging.microsoft.com [65.55.88.14]) by ietfa.amsl.com (Postfix) with ESMTP id 8C8D021F871D; Thu, 9 Aug 2012 07:53:33 -0700 (PDT) Received: from mail248-tx2-R.bigfish.com (10.9.14.244) by TX2EHSOBE002.bigfish.com (10.9.40.22) with Microsoft SMTP Server id 14.1.225.23; Thu, 9 Aug 2012 14:53:33 +0000 Received: from mail248-tx2 (localhost [127.0.0.1]) by mail248-tx2-R.bigfish.com (Postfix) with ESMTP id 2F4395C0105; Thu, 9 Aug 2012 14:53:33 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC104.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -20 X-BigFish: VS-20(z3e13hzbb2dI98dI9371Ic85dhzz1202h1082kzz8275ch1033IL8275bh8275dhz2fh2a8h683h839hd25hf0ah107ah) Received-SPF: pass (mail248-tx2: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=tonynad@microsoft.com; helo=TK5EX14MLTC104.redmond.corp.microsoft.com ; icrosoft.com ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT001.namprd03.prod.outlook.com; R:internal; EFV:INT Received: from mail248-tx2 (localhost.localdomain [127.0.0.1]) by mail248-tx2 (MessageSwitch) id 1344524010811349_30640; Thu, 9 Aug 2012 14:53:30 +0000 (UTC) Received: from TX2EHSMHS029.bigfish.com (unknown [10.9.14.240]) by mail248-tx2.bigfish.com (Postfix) with ESMTP id B9A581BC0045; Thu, 9 Aug 2012 14:53:30 +0000 (UTC) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (131.107.125.8) by TX2EHSMHS029.bigfish.com (10.9.99.129) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 9 Aug 2012 14:53:30 +0000 Received: from co1outboundpool.messaging.microsoft.com (157.54.51.80) by mail.microsoft.com (157.54.79.159) with Microsoft SMTP Server (TLS) id 14.2.298.5; Thu, 9 Aug 2012 14:53:29 +0000 Received: from mail180-co1-R.bigfish.com (10.243.78.249) by CO1EHSOBE003.bigfish.com (10.243.66.66) with Microsoft SMTP Server id 14.1.225.23; Thu, 9 Aug 2012 14:53:28 +0000 Received: from mail180-co1 (localhost [127.0.0.1]) by mail180-co1-R.bigfish.com (Postfix) with ESMTP id BED7FC4026B; Thu, 9 Aug 2012 14:53:28 +0000 (UTC) Received: from mail180-co1 (localhost.localdomain [127.0.0.1]) by mail180-co1 (MessageSwitch) id 1344524006868813_19240; Thu, 9 Aug 2012 14:53:26 +0000 (UTC) Received: from CO1EHSMHS028.bigfish.com (unknown [10.243.78.254]) by mail180-co1.bigfish.com (Postfix) with ESMTP id C80622C0058; Thu, 9 Aug 2012 14:53:26 +0000 (UTC) Received: from BL2PRD0310HT001.namprd03.prod.outlook.com (157.56.240.21) by CO1EHSMHS028.bigfish.com (10.243.66.38) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 9 Aug 2012 14:53:25 +0000 Received: from BL2PRD0310MB362.namprd03.prod.outlook.com ([169.254.12.203]) by BL2PRD0310HT001.namprd03.prod.outlook.com ([10.255.97.36]) with mapi id 14.16.0175.005; Thu, 9 Aug 2012 14:53:25 +0000 From: Anthony Nadalin To: "tony@yaanatech.com" , "Waltermire, David A." Thread-Topic: =?iso-8859-1?Q?[sacm]_[mile]__Strategic_alignment_of_security_with_busine?= =?iso-8859-1?Q?ss_in_SACM_in=A0=A0=A0=A0an_international_context?= Thread-Index: AQHNdjVmI5aVfzU+bEGRQzPjkLgmxZdRj9kQ Date: Thu, 9 Aug 2012 14:53:24 +0000 Message-ID: References: <5023BF21.6030205@yaanatech.com> In-Reply-To: <5023BF21.6030205@yaanatech.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.192.56] Content-Type: multipart/alternative; boundary="_000_B26C1EF377CB694EAB6BDDC8E624B6E75E9DCB06BL2PRD0310MB362_" MIME-Version: 1.0 X-OrganizationHeadersPreserved: BL2PRD0310HT001.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%YAANATECH.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%NIST.GOV$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%VERIZON.NET$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%C3ISECURITY.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%NETFRONTIERS.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14MLTC104.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14MLTC104.redmond.corp.microsoft.com X-OriginatorOrg: microsoft.com X-Mailman-Approved-At: Mon, 20 Aug 2012 02:27:04 -0700 Cc: "'david.oliva@verizon.net'" , "'mile@ietf.org'" , "'dcougias@netfrontiers.com'" , "'sacm@ietf.org'" Subject: Re: [mile] =?iso-8859-1?q?=5Bsacm=5D___Strategic_alignment_of_securit?= =?iso-8859-1?q?y_with_business_in_SACM_in=A0=A0=A0=A0an_international_con?= =?iso-8859-1?q?text?= X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 14:53:34 -0000 --_000_B26C1EF377CB694EAB6BDDC8E624B6E75E9DCB06BL2PRD0310MB362_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I think David is referring to the ISO type of document which is a pay per c= opy with various distribution restrictions, which I know you knew about bef= ore you asked for a copy on this list as you have complained about the ISO = documentation model many times in various fora. From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Ton= y Rutkowski Sent: Thursday, August 09, 2012 6:46 AM To: Waltermire, David A. Cc: 'david.oliva@verizon.net'; 'lnunez@c3isecurity.com'; 'mile@ietf.org'; '= dcougias@netfrontiers.com'; 'sacm@ietf.org' Subject: Re: [sacm] [mile] Strategic alignment of security with business in= SACM in an international context David, I don't think you really want to have such a requirement. Almost everything is explicitly or implicitly copyrighted. IETF material itself asserts a copyright. What is relevant is any restrictions associated with the copyright. It seems inappropriate for a technical body to effectively require a copyright analysis of everything potentially sent to a list. Work would cease. --tony On 8/9/2012 9:06 AM, Waltermire, David A. wrote: Sorry. Fat fingered send. It might be best to keep any copyrighted material= off the list, unless it is being contributed to the IETF as an I/D. --_000_B26C1EF377CB694EAB6BDDC8E624B6E75E9DCB06BL2PRD0310MB362_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I think David is referrin= g to the ISO type of document which is a pay per copy with various distribu= tion restrictions, which I know you knew about before you asked for a copy on this list as you have complained about the ISO documen= tation model many times in various fora.

 <= /p>

From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.o= rg] On Behalf Of Tony Rutkowski
Sent: Thursday, August 09, 2012 6:46 AM
To: Waltermire, David A.
Cc: 'david.oliva@verizon.net'; 'lnunez@c3isecurity.com'; 'mile@ietf.= org'; 'dcougias@netfrontiers.com'; 'sacm@ietf.org'
Subject: Re: [sacm] [mile] Strategic alignment of security with busi= ness in SACM in    an international context<= /span>

 

David,

I don't think you really want to have such a requirement.
Almost everything is explicitly or implicitly copyrighted.
IETF material itself asserts a copyright.  What is relevant
is any restrictions associated with the copyright.  It seems
inappropriate for a technical body to effectively require
a copyright analysis of everything potentially sent to a list.
Work would cease.

--tony


On 8/9/2012 9:06 AM, Waltermire, David A. wrote:

Sorry. Fat fingered send. It m= ight be best to keep any copyrighted material off the list, unless it is be= ing contributed to the IETF as an I/D.

 

--_000_B26C1EF377CB694EAB6BDDC8E624B6E75E9DCB06BL2PRD0310MB362_-- From kathleen.moriarty@emc.com Mon Aug 20 06:43:54 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2E2C21F85C3 for ; Mon, 20 Aug 2012 06:43:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.828 X-Spam-Level: X-Spam-Status: No, score=-1.828 tagged_above=-999 required=5 tests=[AWL=-0.719, BAYES_05=-1.11, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YTmArvaRFZPq for ; Mon, 20 Aug 2012 06:43:53 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 3CFEF21F8513 for ; Mon, 20 Aug 2012 06:43:53 -0700 (PDT) Received: from hop04-l1d11-si04.isus.emc.com (HOP04-L1D11-SI04.isus.emc.com [10.254.111.24]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q7KDhphX031020 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 20 Aug 2012 09:43:52 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd03.lss.emc.com [10.254.221.145]) by hop04-l1d11-si04.isus.emc.com (RSA Interceptor) for ; Mon, 20 Aug 2012 09:43:38 -0400 Received: from mxhub05.corp.emc.com (mxhub05.corp.emc.com [128.222.70.202]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q7KDfMb2017062 for ; Mon, 20 Aug 2012 09:43:38 -0400 Received: from mx15a.corp.emc.com ([169.254.1.66]) by mxhub05.corp.emc.com ([128.222.70.202]) with mapi; Mon, 20 Aug 2012 09:40:25 -0400 From: "Moriarty, Kathleen" To: "mile@ietf.org" Date: Mon, 20 Aug 2012 09:40:23 -0400 Thread-Topic: SCI document and WG decision Thread-Index: Ac1+2VlhBTQIdwl7SaqzSzRvyN6ZRA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_F5063677821E3B4F81ACFB7905573F24057186ECMX15Acorpemccom_" MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: [mile] SCI document and WG decision X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 13:43:54 -0000 --_000_F5063677821E3B4F81ACFB7905573F24057186ECMX15Acorpemccom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, At the IETF meeting in Vancouver, the WG consensus was to remove the refere= nced specifications from the SCI draft so that the document could progress = without IP issues. In this model, the draft would have empty tables and th= e WG would then decide which specifications or standards references would g= et added into the document. The thought was that the WG could think more c= arefully about what specifications were important to reference to meet rele= vant use cases for the community. The process would include a review of th= e specification to ensure we could reference it, including that the specifi= cation or standard is a document that the IETF can normatively reference. Does the WG agree on this approach? (consensus needs to be shown on the li= st in one direction or another to formalize and move forward). We will give this a two week period for responses, finishing the morning of= September 3rd. Thank you in advance! Kathleen --_000_F5063677821E3B4F81ACFB7905573F24057186ECMX15Acorpemccom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hello,
 
At the IETF meeting in Vancouver, the WG consensus was to remove the r= eferenced specifications from the SCI draft so that the document could prog= ress without IP issues.  In this model, the draft would have empty tab= les and the WG would then decide which specifications or standards references would get added into the document.&n= bsp; The thought was that the WG could think more carefully about what spec= ifications were important to reference to meet relevant use cases for the c= ommunity.  The process would include a review of the specification to ensure we could reference it, including th= at the specification or standard is a document that the IETF can normativel= y reference.
 
Does the WG agree on this approach?  (consensus needs to be shown= on the list in one direction or another to formalize and move forward).
 
We will give this a two week period for responses, finishing the morni= ng of September 3rd.
 
Thank you in advance! 
Kathleen
 
 
 --_000_F5063677821E3B4F81ACFB7905573F24057186ECMX15Acorpemccom_-- From amontville@tripwire.com Mon Aug 20 06:55:31 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE1DB21F8690 for ; Mon, 20 Aug 2012 06:55:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.926 X-Spam-Level: X-Spam-Status: No, score=-3.926 tagged_above=-999 required=5 tests=[AWL=-0.327, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pQ9LdMwsNLau for ; Mon, 20 Aug 2012 06:55:30 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe002.messaging.microsoft.com [216.32.180.185]) by ietfa.amsl.com (Postfix) with ESMTP id 760AA21F8681 for ; Mon, 20 Aug 2012 06:55:30 -0700 (PDT) Received: from mail42-co1-R.bigfish.com (10.243.78.230) by CO1EHSOBE004.bigfish.com (10.243.66.67) with Microsoft SMTP Server id 14.1.225.23; Mon, 20 Aug 2012 13:55:29 +0000 Received: from mail42-co1 (localhost [127.0.0.1]) by mail42-co1-R.bigfish.com (Postfix) with ESMTP id BEF2B5C0166 for ; Mon, 20 Aug 2012 13:55:29 +0000 (UTC) X-Forefront-Antispam-Report: CIP:174.47.84.215; KIP:(null); UIP:(null); IPV:NLI; H:zgw01.tripwire.com; RD:174-47-84-215.static.twtelecom.net; EFVD:NLI X-SpamScore: -7 X-BigFish: VPS-7(zzbb2dI98dI9371I1432Ic540Kzz1202hzz8275bhz2dh2a8h668h839h944he5bhf0ah107ah) Received: from mail42-co1 (localhost.localdomain [127.0.0.1]) by mail42-co1 (MessageSwitch) id 1345470927170908_6170; Mon, 20 Aug 2012 13:55:27 +0000 (UTC) Received: from CO1EHSMHS024.bigfish.com (unknown [10.243.78.248]) by mail42-co1.bigfish.com (Postfix) with ESMTP id 27CC16C03CD for ; Mon, 20 Aug 2012 13:55:27 +0000 (UTC) Received: from zgw01.tripwire.com (174.47.84.215) by CO1EHSMHS024.bigfish.com (10.243.66.34) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 20 Aug 2012 13:55:25 +0000 Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.tripwire.com (Proprietary) with SMTP id 3B90423211D2 for ; Mon, 20 Aug 2012 06:54:34 -0700 (PDT) Received: from PDXED01.tripwire.com (unknown [192.168.192.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by zgw01.tripwire.com (Proprietary) with ESMTPS id 9F6A323211CB; Mon, 20 Aug 2012 06:54:33 -0700 (PDT) Received: from PDXHB01.tripwire.com (172.30.0.53) by PDXED01.tripwire.com (192.168.192.5) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 20 Aug 2012 06:57:08 -0700 Received: from PDXMB02.tripwire.com ([fe80::f997:7b65:8e64:438e]) by PDXHB01.tripwire.com ([fe80::d495:98d2:7df4:2154%11]) with mapi id 14.01.0355.002; Mon, 20 Aug 2012 06:55:24 -0700 From: Adam Montville To: "Moriarty, Kathleen" , "mile@ietf.org" Thread-Topic: [mile] SCI document and WG decision Thread-Index: Ac1+2VlhBTQIdwl7SaqzSzRvyN6ZRAAAhioA Date: Mon, 20 Aug 2012 13:55:23 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [172.30.0.234] x-exclaimer-md-config: 79afcaa7-fdf4-4fa6-abe0-afeaa4640a4f Content-Type: text/plain; charset="us-ascii" Content-ID: <9333EEE881C3C64CA028919FA0AB6388@tripwire.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-VPM-MSG-ID: 03e91eaa-5a0a-4f03-a499-93de229152c6 X-VPM-HOST: zgw01.tripwire.com X-VPM-ENC-REGIME: Plaintext X-VPM-CERT-FLAG: 0 X-VPM-IS-HYBRID: 0 X-OriginatorOrg: tripwire.com Subject: Re: [mile] SCI document and WG decision X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 13:55:31 -0000 On 8/20/12 6:40 AM, "Moriarty, Kathleen" wrote: >Hello, >=20 >At the IETF meeting in Vancouver, the WG consensus was to remove the >referenced specifications from the SCI draft so that the document could >progress without IP issues. In this model, the draft would have empty >tables and the WG would then decide which > specifications or standards references would get added into the >document. The thought was that the WG could think more carefully about >what specifications were important to reference to meet relevant use >cases for the community. The process would include > a review of the specification to ensure we could reference it, including >that the specification or standard is a document that the IETF can >normatively reference. >=20 >Does the WG agree on this approach? (consensus needs to be shown on the >list in one direction or another to formalize and move forward). >=20 >We will give this a two week period for responses, finishing the morning >of September 3rd. >=20 >Thank you in advance! >Kathleen >=20 >=20 > I agree. From Kent_Landfield@mcafee.com Mon Aug 20 08:52:46 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 354AC21F84FD for ; Mon, 20 Aug 2012 08:52:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.557 X-Spam-Level: X-Spam-Status: No, score=-6.557 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bbDdnng5NTnJ for ; Mon, 20 Aug 2012 08:52:45 -0700 (PDT) Received: from dalsmrelay2.nai.com (dalsmrelay2.nai.com [205.227.136.216]) by ietfa.amsl.com (Postfix) with ESMTP id 8167221F84FB for ; Mon, 20 Aug 2012 08:52:45 -0700 (PDT) Received: from DALEXHT1.corp.nai.org (unknown [10.64.5.51]) by dalsmrelay2.nai.com with smtp id 4e10_e565_c7c49c27_c8b9_4cc5_9a35_86745765dcde; Mon, 20 Aug 2012 10:52:37 -0500 Received: from AMERDALEXMB1.corp.nai.org ([fe80::387d:3d79:ad3b:b517]) by DALEXHT1.corp.nai.org ([::1]) with mapi; Mon, 20 Aug 2012 10:50:08 -0500 From: To: , Date: Mon, 20 Aug 2012 10:51:11 -0500 Thread-Topic: [mile] SCI document and WG decision Thread-Index: Ac1+63jJjwwCVE39Qa6kH1rCUzn7fg== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CC57C6F93A874kentlandfieldmcafeecom_" MIME-Version: 1.0 Subject: Re: [mile] SCI document and WG decision X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 15:52:46 -0000 --_000_CC57C6F93A874kentlandfieldmcafeecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable While I agree with what the working group decided in Vancouver, does the MI= TRE IPR submissions change anything? Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: , Kathleen Moriarty > Date: Monday, August 20, 2012 8:40 AM To: "mile@ietf.org" > Subject: [mile] SCI document and WG decision Hello, At the IETF meeting in Vancouver, the WG consensus was to remove the refere= nced specifications from the SCI draft so that the document could progress = without IP issues. In this model, the draft would have empty tables and th= e WG would then decide which specifications or standards references would g= et added into the document. The thought was that the WG could think more c= arefully about what specifications were important to reference to meet rele= vant use cases for the community. The process would include a review of th= e specification to ensure we could reference it, including that the specifi= cation or standard is a document that the IETF can normatively reference. Does the WG agree on this approach? (consensus needs to be shown on the li= st in one direction or another to formalize and move forward). We will give this a two week period for responses, finishing the morning of= September 3rd. Thank you in advance! Kathleen --_000_CC57C6F93A874kentlandfieldmcafeecom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Whil= e I agree with what the working group decided in Vancouver, does the MITRE = IPR submissions change anything?

Kent Landfield

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

=
From: <Moriarty>, Kathleen Moriarty <kathleen.moriarty@emc.com>
Date: Monday, August 20, 2012 8:40 AM
To: "mile@ietf.org" <mile@ietf.org&= gt;
Subject: [mile] SCI documen= t and WG decision

=
Hello,
 
At the IETF meeting in Vancouver, the WG consensus was to remove t= he referenced specifications from the SCI draft so that the document could = progress without IP issues.  In this model, the draft would have empty= tables and the WG would then decide which specifications or standards references would get added into the document.&= nbsp; The thought was that the WG could think more carefully about what spe= cifications were important to reference to meet relevant use cases for the = community.  The process would include a review of the specification to ensure we could reference it, including t= hat the specification or standard is a document that the IETF can normative= ly reference.
 
Does the WG agree on this approach= ?  (consensus needs to be shown on the list in one direction or anothe= r to formalize and move forward).
 
We will give t= his a two week period for responses, finishing the morning of September 3rd.
 
Thank you i= n advance! 
Kathleen
 
 
 --_000_CC57C6F93A874kentlandfieldmcafeecom_-- From kathleen.moriarty@emc.com Mon Aug 20 08:58:22 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2322C21F8688 for ; Mon, 20 Aug 2012 08:58:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zb0BWCWvw913 for ; Mon, 20 Aug 2012 08:58:21 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 3954A21F8687 for ; Mon, 20 Aug 2012 08:58:20 -0700 (PDT) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q7KFwEsb005428 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Aug 2012 11:58:19 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.130]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Mon, 20 Aug 2012 11:57:59 -0400 Received: from mxhub18.corp.emc.com (mxhub18.corp.emc.com [10.254.93.47]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q7KFvxZJ015097; Mon, 20 Aug 2012 11:57:59 -0400 Received: from mx15a.corp.emc.com ([169.254.1.66]) by mxhub18.corp.emc.com ([10.254.93.47]) with mapi; Mon, 20 Aug 2012 11:57:36 -0400 From: "Moriarty, Kathleen" To: "Kent_Landfield@mcafee.com" , "mile@ietf.org" Date: Mon, 20 Aug 2012 11:57:57 -0400 Thread-Topic: [mile] SCI document and WG decision Thread-Index: Ac1+63jJjwwCVE39Qa6kH1rCUzn7fgAANL9w Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_F5063677821E3B4F81ACFB7905573F240571877EMX15Acorpemccom_" MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [mile] SCI document and WG decision X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 15:58:22 -0000 --_000_F5063677821E3B4F81ACFB7905573F240571877EMX15Acorpemccom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The question is open for the WG to decide the best approach. Do we re-eval= uate what the most useful specifications and standards are for the WG (this= will guide implementations) or do we try to accommodate all of the specifi= cations? We will run into issues with not having normative references in s= ome instances and that will delay or potentially stop publication if none a= re produced. Thank you, Kathleen From: Kent_Landfield@mcafee.com [mailto:Kent_Landfield@mcafee.com] Sent: Monday, August 20, 2012 11:51 AM To: Moriarty, Kathleen; mile@ietf.org Subject: Re: [mile] SCI document and WG decision While I agree with what the working group decided in Vancouver, does the MI= TRE IPR submissions change anything? Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: , Kathleen Moriarty > Date: Monday, August 20, 2012 8:40 AM To: "mile@ietf.org" > Subject: [mile] SCI document and WG decision Hello, At the IETF meeting in Vancouver, the WG consensus was to remove the refere= nced specifications from the SCI draft so that the document could progress = without IP issues. In this model, the draft would have empty tables and th= e WG would then decide which specifications or standards references would g= et added into the document. The thought was that the WG could think more c= arefully about what specifications were important to reference to meet rele= vant use cases for the community. The process would include a review of th= e specification to ensure we could reference it, including that the specifi= cation or standard is a document that the IETF can normatively reference. Does the WG agree on this approach? (consensus needs to be shown on the li= st in one direction or another to formalize and move forward). We will give this a two week period for responses, finishing the morning of= September 3rd. Thank you in advance! Kathleen --_000_F5063677821E3B4F81ACFB7905573F240571877EMX15Acorpemccom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The question is open for the WG to decide the best approach.&nbs= p; Do we re-evaluate what the most useful specifications and standards are = for the WG (this will guide implementations) or do we try to accommodate al= l of the specifications?  We will run into issues with not having norm= ative references in some instances and that will delay or potentially stop = publication if none are produced.

 

Thank you,<= o:p>

Kathleen=

 

<= p class=3DMsoNormal>From: Kent_Landfield@mcafee.com [mailto:Kent_Landfield@mc= afee.com]
Sent: Monday, August 20, 2012 11:51 AM
To: M= oriarty, Kathleen; mile@ietf.org
Subject: Re: [mile] SCI document= and WG decision

 

While I agree with what the working group decided in Vancouver, does = the MITRE IPR submissions change anything?

=

 

Kent Landfield

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

 

From: <Moriarty&g= t;, Kathleen Moriarty <kath= leen.moriarty@emc.com>
Date: Monday, August 20, 2012 8:40 = AM
To: "mile@ietf.org&q= uot; <mile@ietf.org>
Subje= ct: [mile] SCI document and WG decision

 <= /p>

Hello= ,

 

At the IETF meeting in Va= ncouver, the WG consensus was to remove the referenced specifications from = the SCI draft so that the document could progress without IP issues.  = In this model, the draft would have empty tables and the WG would then deci= de which specifications or standards references would get added into the do= cument.  The thought was that the WG could think more carefully about = what specifications were important to reference to meet relevant use cases = for the community.  The process would include a review of the specific= ation to ensure we could reference it, including that the specification or = standard is a document that the IETF can normatively reference.<= /span>

 

=

Does the WG agree on this approach?&nb= sp; (consensus needs to be shown on the list in one direction or another to= formalize and move forward).

 

We will give this a two week period for responses, finishing the morning= of September 3rd.

<= /div>

 

=

Thank you in advance! 

Kathleen

<= div>

 

 

= --_000_F5063677821E3B4F81ACFB7905573F240571877EMX15Acorpemccom_-- From pkampana@cisco.com Mon Aug 20 10:24:22 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACE5721F861A for ; Mon, 20 Aug 2012 10:24:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.531 X-Spam-Level: X-Spam-Status: No, score=-10.531 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y+h1vEZKmZsH for ; Mon, 20 Aug 2012 10:24:21 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id E660721F8616 for ; Mon, 20 Aug 2012 10:24:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkampana@cisco.com; l=7924; q=dns/txt; s=iport; t=1345483461; x=1346693061; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=jJaECPbQ6tEMttKfO5YWg744xvPxlUoRINKgAr+NhPE=; b=RgcH1YH/yrfZrHTK1MU+s8sCHvimE4YA/TwSOlOn7yM+yhsaUj7osOYm fsV1TNG8NxFrx0AAUFmph2ekIe4+hHjVZ67tD9IBQxJnZUVv94SUE7lPS 1gIdy9H17f+ZyPEodN+02xCGU805XWzPd05CkxhhJeKCdWUc929U9Zor5 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAIhyMlCtJXG8/2dsb2JhbABFgkq4D4EHgiABAQEEEgEaXAIBCBEEAQELHQcyFAkIAQEEARIIDA6Ha5kPoBOLC4YyYAOjfIFmgmE X-IronPort-AV: E=Sophos;i="4.77,798,1336348800"; d="scan'208,217";a="113447265" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-8.cisco.com with ESMTP; 20 Aug 2012 17:24:18 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q7KHOITp013694 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 20 Aug 2012 17:24:18 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.216]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0298.004; Mon, 20 Aug 2012 12:24:18 -0500 From: "Panos Kampanakis (pkampana)" To: "Moriarty, Kathleen" , "mile@ietf.org" Thread-Topic: SCI document and WG decision Thread-Index: Ac1+2VlhBTQIdwl7SaqzSzRvyN6ZRAAHwZEQ Date: Mon, 20 Aug 2012 17:24:17 +0000 Message-ID: <1C9F17D1873AFA47A969C4DD98F98A75057C6A@xmb-rcd-x10.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.89.107] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19126.004 x-tm-as-result: No--34.586400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_1C9F17D1873AFA47A969C4DD98F98A75057C6Axmbrcdx10ciscocom_" MIME-Version: 1.0 Subject: Re: [mile] SCI document and WG decision X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 17:24:22 -0000 --_000_1C9F17D1873AFA47A969C4DD98F98A75057C6Axmbrcdx10ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 Panos From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Mor= iarty, Kathleen Sent: Monday, August 20, 2012 9:40 AM To: mile@ietf.org Subject: [mile] SCI document and WG decision Hello, At the IETF meeting in Vancouver, the WG consensus was to remove the refere= nced specifications from the SCI draft so that the document could progress = without IP issues. In this model, the draft would have empty tables and th= e WG would then decide which specifications or standards references would g= et added into the document. The thought was that the WG could think more c= arefully about what specifications were important to reference to meet rele= vant use cases for the community. The process would include a review of th= e specification to ensure we could reference it, including that the specifi= cation or standard is a document that the IETF can normatively reference. Does the WG agree on this approach? (consensus needs to be shown on the li= st in one direction or another to formalize and move forward). We will give this a two week period for responses, finishing the morning of= September 3rd. Thank you in advance! Kathleen --_000_1C9F17D1873AFA47A969C4DD98F98A75057C6Axmbrcdx10ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1<= /p>

Panos

 <= /p>

 <= /p>

From: mile-bou= nces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Moriarty, Kathleen
Sent: Monday, August 20, 2012 9:40 AM
To: mile@ietf.org
Subject: [mile] SCI document and WG decision

 

Hello,

 

At the IETF meeting in Vancouver, the W= G consensus was to remove the referenced specifications from the SCI draft = so that the document could progress without IP issues.  In this model, the draft would have empty tables and the WG would then dec= ide which specifications or standards references would get added into the d= ocument.  The thought was that the WG could think more carefully about= what specifications were important to reference to meet relevant use cases for the community.  The process = would include a review of the specification to ensure we could reference it= , including that the specification or standard is a document that the IETF = can normatively reference.

 

Does the WG agree on this approach?&nbs= p; (consensus needs to be shown on the list in one direction or another to = formalize and move forward).

 

We will give this a two week period for= responses, finishing the morning of September 3rd<= /span>.

 

Thank you in advance! 

Kathleen

 

 

--_000_1C9F17D1873AFA47A969C4DD98F98A75057C6Axmbrcdx10ciscocom_-- From david.black@emc.com Thu Aug 30 23:30:12 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D06AA21F8526 for ; Thu, 30 Aug 2012 23:30:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.478 X-Spam-Level: X-Spam-Status: No, score=-102.478 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r+t2yDEtgLjV for ; Thu, 30 Aug 2012 23:30:11 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id F297B21F84FA for ; Thu, 30 Aug 2012 23:30:10 -0700 (PDT) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q7V6U7Pn005786 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 31 Aug 2012 02:30:08 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.226]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor) for ; Fri, 31 Aug 2012 02:29:48 -0400 Received: from mxhub11.corp.emc.com (mxhub11.corp.emc.com [10.254.92.106]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q7V6Tltb003962 for ; Fri, 31 Aug 2012 02:29:48 -0400 Received: from mx15a.corp.emc.com ([169.254.1.66]) by mxhub11.corp.emc.com ([10.254.92.106]) with mapi; Fri, 31 Aug 2012 02:29:47 -0400 From: "Black, David" To: "Moriarty, Kathleen" , "mile@ietf.org" Date: Fri, 31 Aug 2012 02:29:45 -0400 Thread-Topic: SCI document and WG decision Thread-Index: Ac1+2VlhBTQIdwl7SaqzSzRvyN6ZRAIZ09Gg Message-ID: <8D3D17ACE214DC429325B2B98F3AE7120A44218B@MX15A.corp.emc.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_8D3D17ACE214DC429325B2B98F3AE7120A44218BMX15Acorpemccom_" MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [mile] SCI document and WG decision X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2012 06:30:12 -0000 --_000_8D3D17ACE214DC429325B2B98F3AE7120A44218BMX15Acorpemccom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Kathleen, The Vancouver mile meeting minutes (which I scribed) include: Sean [AD] and Kathleen [WG co-chair] agree that it is procedurally ok for the SCI draft to include specs that are ok for a standards- track RFC to normatively reference, and deal with the rest of the specs as submissions to the registry created by the RFC. The designated expert for the registry (Kathleen) will get to decide on the additional submissions following guidance in the published SCI document, but the initial registry must not be completely empty. I support the proposed course of action as long as it's consistent with the above. The SCI draft creates one new registry, "IODEF Structured Cyber Security Information Specifications", one of whose fields is the applicable extended class(es). Hence, it would suffice for the draft to have a single entry in that new registry that references one of the extended classes. If the result is exactly one specification entry in the new registry's initial contents, the selection of the mandatory-to-implement SCI specification becomes rather easy ;-). Thanks, --David From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Mor= iarty, Kathleen Sent: Monday, August 20, 2012 9:40 AM To: mile@ietf.org Subject: [mile] SCI document and WG decision Hello, At the IETF meeting in Vancouver, the WG consensus was to remove the refere= nced specifications from the SCI draft so that the document could progress = without IP issues. In this model, the draft would have empty tables and th= e WG would then decide which specifications or standards references would g= et added into the document. The thought was that the WG could think more c= arefully about what specifications were important to reference to meet rele= vant use cases for the community. The process would include a review of th= e specification to ensure we could reference it, including that the specifi= cation or standard is a document that the IETF can normatively reference. Does the WG agree on this approach? (consensus needs to be shown on the li= st in one direction or another to formalize and move forward). We will give this a two week period for responses, finishing the morning of= September 3rd. Thank you in advance! Kathleen --_000_8D3D17ACE214DC429325B2B98F3AE7120A44218BMX15Acorpemccom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Kathleen,=

 

The Vancouver mile meeting minutes (which I scribed) include:

 

   Sean [AD] and Kathleen [WG co-chair] agree that it is pr= ocedurally

   ok for the SC= I draft to include specs that are ok for a standards-

   track RFC to normatively reference, and deal = with the rest of the

   spe= cs as submissions to the registry created by the RFC.  The designated<= o:p>

   expert for the registry = (Kathleen) will get to decide on the

=    additional submissions following guidance in the published SCI=

   document, but the initi= al registry must not be completely empty.

 

I support the proposed co= urse of action as long as it’s consistent

with the above.

 = ;

The SCI draft creates one new registry, = "IODEF Structured Cyber Security

Information Specifications", one of whose fields is the applicable

extended class(es).  Hence, it wou= ld suffice for the draft to have a

si= ngle entry in that new registry that references one of the extended

classes.

 

If the result is exactly on= e specification entry in the new registry’s

initial contents, the selection of the mandatory-to-implement = SCI

specification becomes rather easy= ;-).

 

=

Thanks,
--David

 

From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Beh= alf Of Moriarty, Kathleen
Sent: Monday, August 20, 2012 9:40 = AM
To: mile@ietf.org
Subject: [mile] SCI document and W= G decision

 = ;

Hello,

 

At the IETF me= eting in Vancouver, the WG consensus was to remove the referenced specifica= tions from the SCI draft so that the document could progress without IP iss= ues.  In this model, the draft would have empty tables and the WG woul= d then decide which specifications or standards references would get added = into the document.  The thought was that the WG could think more caref= ully about what specifications were important to reference to meet relevant= use cases for the community.  The process would include a review of t= he specification to ensure we could reference it, including that the specif= ication or standard is a document that the IETF can normatively reference.<= o:p>

 

<= /div>

Does the WG agree on this approach?  (consensu= s needs to be shown on the list in one direction or another to formalize an= d move forward).

 <= /o:p>

We will give this a two week perio= d for responses, finishing the morning of September 3rd.

 

Thank you in advance! 

Kathleen

&nbs= p;

 

= --_000_8D3D17ACE214DC429325B2B98F3AE7120A44218BMX15Acorpemccom_--