From nobody Tue Oct 7 04:28:18 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79B3B1A1B8E for ; Tue, 7 Oct 2014 04:28:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.685 X-Spam-Level: X-Spam-Status: No, score=-7.685 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id whTH4cMJoZ-m for ; Tue, 7 Oct 2014 04:28:14 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A83BC1A1B4E for ; Tue, 7 Oct 2014 04:28:14 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmQMABzNM1TGmAcV/2dsb2JhbABfgkgjIyAzWQO4VAYFk14iAQuHSwKBERYBAXEJhAUBAQMSG14BFQUQVhcPAQQbARmIHAEMnRWEbJ9yhiCJUwEBHoJuD0QkgR4FkXaMeYNEgxqGa4cSg2OBezmBAgEBAQ X-IronPort-AV: E=Sophos; i="5.04,669,1406606400"; d="scan'208,217"; a="85926091" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by co300216-co-outbound.net.avaya.com with ESMTP; 07 Oct 2014 07:28:13 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 07 Oct 2014 07:28:04 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC01.global.avaya.com ([135.64.58.11]) with mapi id 14.03.0174.001; Tue, 7 Oct 2014 13:28:03 +0200 From: "Romascanu, Dan (Dan)" To: "sacm@ietf.org" Thread-Topic: one week until the 10/14 virtual interim Thread-Index: Ac/iIcCvFWIvRNxLTt6ERp39WqMIsQ== Date: Tue, 7 Oct 2014 11:28:03 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C8C2543@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA5C8C2543AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/1_Ix-zcFxnquDql8nxMug8Lfu18 Subject: [sacm] one week until the 10/14 virtual interim X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 11:28:16 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA5C8C2543AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, There is one week left until the Virtual Interim scheduled for 10/14. I have uploaded a preliminary agenda at http://www.ietf.org/proceedings/int= erim/2014/10/14/sacm/agenda/agenda-interim-2014-sacm-5. According to the Way Forward slides the following should happen until the i= nterim meeting: - 2014-10-10 - Submit Requirements Update, WGLC - 2014-10-10 - Adopt Architecture I-D - 2014-10-10 - Adopt Information Model I-D I am waiting for the requirements I-D update to start the WGLC. I believe that we have consensus for the adoption of the architecture and i= nformation model I-Ds as WG items. I will check again the mail list archive= s to make sure that we did not miss something, and issue the consensus mess= ages afterwards. Please comment on the agenda and let me know if there are other suggestions= or requests for the interim. Regards, Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA5C8C2543AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

There is one week left until the Virtual Interim sch= eduled for 10/14.

 

I have uploaded a preliminary agenda at http://www.ietf.org/proceedings/interim/2014/10/14/sacm/agenda/agenda-inter= im-2014-sacm-5.

 

According to the Way Forward slides the following sh= ould happen until the interim meeting:

 

-     &= nbsp;    2014-10-10 – Submit = Requirements Update, WGLC

-     &= nbsp;    2014-10-10 – Adopt A= rchitecture I-D

-     &= nbsp;    2014-10-10 – Adopt I= nformation Model I-D

 

I am waiting for the requirements I-D update to star= t the WGLC.

 

I believe that we have consensus for the adoption of= the architecture and information model I-Ds as WG items. I will check agai= n the mail list archives to make sure that we did not miss something, and i= ssue the consensus messages afterwards.

 

Please comment on the agenda and let me know if ther= e are other suggestions or requests for the interim.

 

Regards,

 

Dan

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA5C8C2543AZFFEXMB04globa_-- From nobody Fri Oct 10 09:47:29 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C8441A1F70 for ; Fri, 10 Oct 2014 09:47:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.685 X-Spam-Level: X-Spam-Status: No, score=-7.685 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hc5uq3rfOSz7 for ; Fri, 10 Oct 2014 09:47:26 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 536AB1A88EB for ; Fri, 10 Oct 2014 09:41:43 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj4NAK8LOFTGmAcV/2dsb2JhbABggkgjI1NYBLdLDAEBAQEBAQaDJI4rgW2HTQKBBRYBAXEJhAMBAQEBAxILEFwCAQgNBAEDAQELHQcyFAMGCAEBBBMIGogcAQygWZ9NAQEBAQEFAQEBAQEBAQEBGYYgiVMBAR43AQaDJ4EeBZF5hEKIPjyDCoMbigSDfoN3bIEPOYECAQEB X-IronPort-AV: E=Sophos; i="5.04,693,1406606400"; d="scan'208,217"; a="86522468" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by co300216-co-outbound.net.avaya.com with ESMTP; 10 Oct 2014 12:41:00 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 10 Oct 2014 12:41:00 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC04.global.avaya.com ([135.64.58.14]) with mapi id 14.03.0174.001; Fri, 10 Oct 2014 18:40:59 +0200 From: "Romascanu, Dan (Dan)" To: "sacm@ietf.org" Thread-Topic: Confirm Consensus - SACM Architecture as WG I-D Thread-Index: Ac/RuP0utXm0qQukT7qzbdr5CrYjXgS78p3g Date: Fri, 10 Oct 2014 16:40:59 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C8C68BF@AZ-FFEXMB04.global.avaya.com> References: <9904FB1B0159DA42B0B887B7FA8119CA5C89D5FA@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA5C89D5FA@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA5C8C68BFAZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/HJWVFMfCEuhADIKGi98TadwKQlw Subject: Re: [sacm] Confirm Consensus - SACM Architecture as WG I-D X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2014 16:47:28 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA5C8C68BFAZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I have seen no objection to the call for consensus. Document editors - plea= se submit the next version of the I-D as draft-ietf-sacm-architecture-00. Thanks and Regards, Dan From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Tuesday, September 16, 2014 5:18 PM To: sacm@ietf.org Subject: [sacm] Confirm Consensus - SACM Architecture as WG I-D There was consensus in the SACM WG interim meeting last week to create a SA= CM Architecture WG I-D based on the merging of http://datatracker.ietf.org/= doc/draft-camwinget-sacm-architecture/ and http://datatracker.ietf.org/doc/= draft-shah-sacm-tnc-architecture/ . This message calls for the mail list confirmation of this decision. Please = send your opinions and especially concerns (if any) with arguments to the W= G mail list until Tuesday 9/23 COB. Thanks and Regards, Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA5C8C68BFAZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,<= /p>

 

I have seen no objecti= on to the call for consensus. Document editors – please submit the ne= xt version of the I-D as draft-ietf-sacm-architecture-00.

 

Thanks and Regards,

 

Dan<= /p>

 

 

From: sacm [ma= ilto:sacm-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan)
Sent: Tuesday, September 16, 2014 5:18 PM
To: sacm@ietf.org
Subject: [sacm] Confirm Consensus - SACM Architecture as WG I-D=

 

There was consensus in the SACM WG interim meeting l= ast week to create a SACM Architecture WG I-D based on the merging of http://datatracker.ietf.org/doc/draft-camwinget-sacm-architecture/ = and http://datatracker.ietf.org/doc/draft-shah-sacm-tnc-architecture/ .

 

This message calls for the mail list confirmation of= this decision. Please send your opinions and especially concerns (if any) = with arguments to the WG mail list until Tuesday 9/23 COB.

 

Thanks and Regards,

 

Dan

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA5C8C68BFAZFFEXMB04globa_-- From nobody Fri Oct 10 09:47:33 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F7B71A1F70 for ; Fri, 10 Oct 2014 09:47:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.685 X-Spam-Level: X-Spam-Status: No, score=-7.685 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z0AydFUNvtNK for ; Fri, 10 Oct 2014 09:47:28 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83A881A8965 for ; Fri, 10 Oct 2014 09:41:43 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AisNAAMLOFTGmAcV/2dsb2JhbABggkgjI1NYBLdXAQEBAQEBBpM8h00CgQUWAQFxCYQDAQEBAQMSCxBcAgEIDQQEAQELHQcyFAkIAQEEEwgaiBwBDKBZn00BAQEBAQEBAQEBAQEBAQEBAQEBAQETBIYgiVMBAR4tCgEGgyeBHgWReYRCiD6DRoMbhGOFIYN+g3dsgQ85gQIBAQE X-IronPort-AV: E=Sophos; i="5.04,693,1406606400"; d="scan'208,217"; a="75768900" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by de307622-de-outbound.net.avaya.com with ESMTP; 10 Oct 2014 12:41:40 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 10 Oct 2014 12:41:39 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC04.global.avaya.com ([135.64.58.14]) with mapi id 14.03.0174.001; Fri, 10 Oct 2014 18:41:38 +0200 From: "Romascanu, Dan (Dan)" To: "sacm@ietf.org" Thread-Topic: Confirm Consensus - SACM Information Model as WG I-D Thread-Index: Ac/Sa1wysYDc+9XiQL+QrB3WKiKmYQSPaUhA Date: Fri, 10 Oct 2014 16:41:37 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C8C68CC@AZ-FFEXMB04.global.avaya.com> References: <9904FB1B0159DA42B0B887B7FA8119CA5C89E59C@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA5C89E59C@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA5C8C68CCAZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/9jzvRXgOb_q2Mku06jQZzIC6D1I Subject: Re: [sacm] Confirm Consensus - SACM Information Model as WG I-D X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2014 16:47:30 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA5C8C68CCAZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I have seen no objection to the call for consensus. Document editors - plea= se submit the next version of the I-D as draft-ietf-sacm-information-model-= 00. Thanks and Regards, Dan From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Wednesday, September 17, 2014 2:35 PM To: sacm@ietf.org Subject: [sacm] Confirm Consensus - SACM Information Model as WG I-D There was consensus in the SACM WG interim meeting last week to create a SA= CM Information Model WG I-D based on https://datatracker.ietf.org/doc/draft= -combined-sacm-information-model/. This message calls for the mail list confirmation of this decision. Please = send your opinions and especially concerns (if any) with arguments to the W= G mail list until Wednesday 9/24 COB. Thanks and Regards, Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA5C8C68CCAZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,<= /p>

 

I have seen no objecti= on to the call for consensus. Document editors – please submit the ne= xt version of the I-D as draft-ietf-sacm-information-model-00.

 

Thanks and Regards,

 

Dan<= /p>

 

 

From: sacm [ma= ilto:sacm-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan)
Sent: Wednesday, September 17, 2014 2:35 PM
To: sacm@ietf.org
Subject: [sacm] Confirm Consensus - SACM Information Model as WG I-D=

 

There was consensus in the SACM WG interim meeting l= ast week to create a SACM Information Model WG I-D based on https://datatracker.ietf.org/doc/draft-combined-sacm-information-model/= .

 

This message calls for the mail list confirmation of= this decision. Please send your opinions and especially concerns (if any) = with arguments to the WG mail list until Wednesday 9/24 COB.

 

Thanks and Regards,

 

Dan

 

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA5C8C68CCAZFFEXMB04globa_-- From nobody Fri Oct 10 09:49:50 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F058A1A8A70 for ; Fri, 10 Oct 2014 09:49:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.685 X-Spam-Level: X-Spam-Status: No, score=-7.685 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dk1cES0R_wOH for ; Fri, 10 Oct 2014 09:49:40 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1123B1A8F3F for ; Fri, 10 Oct 2014 09:44:34 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApgLAK8LOFTGmAcV/2dsb2JhbABggkgjI1NOCgS3SwwBAQEBAQEGkz6HSwKBBRYBAXqEAwEBAQEDEhtcAgEIDQQBAwEBCx0HMhQDBggBAQQBEggBGYgcAQygWZ9NAQEBAQEBAQMBAQEBAQEBAQEBAReGIIlTAQEeNwGDLYEeBZF5jQCDRoMbhmyHFoN3bIEPOYECAQEB X-IronPort-AV: E=Sophos; i="5.04,693,1406606400"; d="scan'208,217"; a="86522914" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by co300216-co-outbound.net.avaya.com with ESMTP; 10 Oct 2014 12:44:33 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 10 Oct 2014 12:44:32 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC04.global.avaya.com ([135.64.58.14]) with mapi id 14.03.0174.001; Fri, 10 Oct 2014 18:44:31 +0200 From: "Romascanu, Dan (Dan)" To: "Romascanu, Dan (Dan)" , "sacm@ietf.org" Thread-Topic: one week until the 10/14 virtual interim Thread-Index: Ac/iIcCvFWIvRNxLTt6ERp39WqMIsQCh165g Date: Fri, 10 Oct 2014 16:44:31 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C8C68E6@AZ-FFEXMB04.global.avaya.com> References: <9904FB1B0159DA42B0B887B7FA8119CA5C8C2543@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA5C8C2543@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA5C8C68E6AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/wDVCC7Zz75VcKzfBdhgWSweD8X8 Subject: Re: [sacm] one week until the 10/14 virtual interim X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2014 16:49:43 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA5C8C68E6AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Four days are left until the meeting. We are looking forward for the contributions due to be posted today. Also, = if there are any comments or requests for the agenda, please let us know. As always, we will need two note takers at the Tuesday interim. Volunteerin= g will be appreciated. Regards, Dan From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Tuesday, October 07, 2014 2:28 PM To: sacm@ietf.org Subject: [sacm] one week until the 10/14 virtual interim Hi, There is one week left until the Virtual Interim scheduled for 10/14. I have uploaded a preliminary agenda at http://www.ietf.org/proceedings/int= erim/2014/10/14/sacm/agenda/agenda-interim-2014-sacm-5. According to the Way Forward slides the following should happen until the i= nterim meeting: - 2014-10-10 - Submit Requirements Update, WGLC - 2014-10-10 - Adopt Architecture I-D - 2014-10-10 - Adopt Information Model I-D I am waiting for the requirements I-D update to start the WGLC. I believe that we have consensus for the adoption of the architecture and i= nformation model I-Ds as WG items. I will check again the mail list archive= s to make sure that we did not miss something, and issue the consensus mess= ages afterwards. Please comment on the agenda and let me know if there are other suggestions= or requests for the interim. Regards, Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA5C8C68E6AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Four days are left unt= il the meeting.

 

We are looking forward= for the contributions due to be posted today. Also, if there are any comme= nts or requests for the agenda, please let us know.

 

As always, we will nee= d two note takers at the Tuesday interim. Volunteering will be appreciated.

 

Regards,


Dan

 

 

 

 

From: sacm [ma= ilto:sacm-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan)
Sent: Tuesday, October 07, 2014 2:28 PM
To: sacm@ietf.org
Subject: [sacm] one week until the 10/14 virtual interim<= /span>

 

Hi,

 

There is one week left until the Virtual Interim sch= eduled for 10/14.

 

I have uploaded a preliminary agenda at http://www.ietf.org/proceedings/interim/2014/10/14/sacm/agenda/agenda-inter= im-2014-sacm-5.

 

According to the Way Forward slides the following sh= ould happen until the interim meeting:

 

-     &= nbsp;    2014-10-10 – Submit = Requirements Update, WGLC

-     &= nbsp;    2014-10-10 – Adopt A= rchitecture I-D

-     &= nbsp;    2014-10-10 – Adopt I= nformation Model I-D

 

I am waiting for the requirements I-D update to star= t the WGLC.

 

I believe that we have consensus for the adoption of= the architecture and information model I-Ds as WG items. I will check agai= n the mail list archives to make sure that we did not miss something, and i= ssue the consensus messages afterwards.

 

Please comment on the agenda and let me know if ther= e are other suggestions or requests for the interim.

 

Regards,

 

Dan

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA5C8C68E6AZFFEXMB04globa_-- From nobody Fri Oct 10 09:51:28 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 071261A6EDE for ; Fri, 10 Oct 2014 09:51:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.685 X-Spam-Level: X-Spam-Status: No, score=-7.685 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KP9L8g99lSXI for ; Fri, 10 Oct 2014 09:51:25 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C561B1A6EE8 for ; Fri, 10 Oct 2014 09:46:59 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj0NAGAMOFTGmAcV/2dsb2JhbABggkgjI1NYBLdLDAEBAQEBAQaDJI4rgW2HTQKBBRYBAXEJhAMBAQEBAxILEF4BCA0EAQMBAQsdORQDBgkBBBMIGogcAQybboRsn00LAQEBHoYgiVMBAR43B4MngR4FkXmEQog+PIMKgxuKBIN+g3dsgQ85gQIBAQE X-IronPort-AV: E=Sophos; i="5.04,693,1406606400"; d="scan'208,217"; a="75769539" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by de307622-de-outbound.net.avaya.com with ESMTP; 10 Oct 2014 12:46:57 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 10 Oct 2014 12:46:56 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC04.global.avaya.com ([135.64.58.14]) with mapi id 14.03.0174.001; Fri, 10 Oct 2014 18:46:55 +0200 From: "Romascanu, Dan (Dan)" To: "sacm@ietf.org" Thread-Topic: Confirm Consensus - SACM Architecture as WG I-D Thread-Index: Ac/kqcqzs0NhCL7gSUmVCbx/OdTY+g== Date: Fri, 10 Oct 2014 16:46:55 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C8C6900@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA5C8C6900AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/NBoajT8NuqBBnHyL9GjwU7mKiPU Subject: Re: [sacm] Confirm Consensus - SACM Architecture as WG I-D X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2014 16:51:27 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA5C8C6900AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I have seen no objection to the call for consensus. Document editors - plea= se submit the next version of the I-D as draft-ietf-sacm-architecture-00. Thanks and Regards, Dan From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Tuesday, September 16, 2014 5:18 PM To: sacm@ietf.org Subject: [sacm] Confirm Consensus - SACM Architecture as WG I-D There was consensus in the SACM WG interim meeting last week to create a SA= CM Architecture WG I-D based on the merging of http://datatracker.ietf.org/= doc/draft-camwinget-sacm-architecture/ and http://datatracker.ietf.org/doc/= draft-shah-sacm-tnc-architecture/ . This message calls for the mail list confirmation of this decision. Please = send your opinions and especially concerns (if any) with arguments to the W= G mail list until Tuesday 9/23 COB. Thanks and Regards, Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA5C8C6900AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,<= /p>

 

I have seen no objecti= on to the call for consensus. Document editors – please submit the ne= xt version of the I-D as draft-ietf-sacm-architecture-00.

 

Thanks and Regards,

 

Dan<= /p>

 

 

From: sacm [ma= ilto:sacm-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan)
Sent: Tuesday, September 16, 2014 5:18 PM
To: sacm@ietf.org
Subject: [sacm] Confirm Consensus - SACM Architecture as WG I-D=

 

There was consensus in the SACM WG interim meeting l= ast week to create a SACM Architecture WG I-D based on the merging of http://datatracker.ietf.org/doc/draft-camwinget-sacm-architecture/ = and http://datatracker.ietf.org/doc/draft-shah-sacm-tnc-architecture/ .

 

This message calls for the mail list confirmation of= this decision. Please send your opinions and especially concerns (if any) = with arguments to the WG mail list until Tuesday 9/23 COB.

 

Thanks and Regards,

 

Dan

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA5C8C6900AZFFEXMB04globa_-- From nobody Fri Oct 10 09:51:47 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DBC31A6EE8 for ; Fri, 10 Oct 2014 09:51:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.685 X-Spam-Level: X-Spam-Status: No, score=-7.685 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vdowyd-3TV68 for ; Fri, 10 Oct 2014 09:51:43 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62CB41A8A07 for ; Fri, 10 Oct 2014 09:47:15 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AisNAGAMOFSHCzIm/2dsb2JhbABggkgjI1NYBLdXAQEBAQEBBpM8h00CgQUWAQFxCYQDAQEBAQMSCxBeAQgNBAQBAQsdORQJCQEEEwgaiBwBDJtuhGyfTQEBAQcBAQEBAQEBFwSGIIlTAQEeLQoHgyeBHgWReYRCiD6DRoMbhGOFIYN+g3dsgQ85gQIBAQE X-IronPort-AV: E=Sophos; i="5.04,693,1406606400"; d="scan'208,217"; a="88943671" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 10 Oct 2014 12:47:13 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES128-SHA; 10 Oct 2014 12:47:13 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC04.global.avaya.com ([135.64.58.14]) with mapi id 14.03.0174.001; Fri, 10 Oct 2014 18:47:12 +0200 From: "Romascanu, Dan (Dan)" To: "sacm@ietf.org" Thread-Topic: Confirm Consensus - SACM Information Model as WG I-D Thread-Index: Ac/kqdW9w4sFXLDSTSCk5dFf8P/rOA== Date: Fri, 10 Oct 2014 16:47:11 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C8C6908@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA5C8C6908AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/MM-o2DKEsv9AKuc4XxP6BOw_7HM Subject: Re: [sacm] Confirm Consensus - SACM Information Model as WG I-D X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2014 16:51:45 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA5C8C6908AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I have seen no objection to the call for consensus. Document editors - plea= se submit the next version of the I-D as draft-ietf-sacm-information-model-= 00. Thanks and Regards, Dan From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Wednesday, September 17, 2014 2:35 PM To: sacm@ietf.org Subject: [sacm] Confirm Consensus - SACM Information Model as WG I-D There was consensus in the SACM WG interim meeting last week to create a SA= CM Information Model WG I-D based on https://datatracker.ietf.org/doc/draft= -combined-sacm-information-model/. This message calls for the mail list confirmation of this decision. Please = send your opinions and especially concerns (if any) with arguments to the W= G mail list until Wednesday 9/24 COB. Thanks and Regards, Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA5C8C6908AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,<= /p>

 

I have seen no objecti= on to the call for consensus. Document editors – please submit the ne= xt version of the I-D as draft-ietf-sacm-information-model-00.

 

Thanks and Regards,

 

Dan<= /p>

 

 

From: sacm [ma= ilto:sacm-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan)
Sent: Wednesday, September 17, 2014 2:35 PM
To: sacm@ietf.org
Subject: [sacm] Confirm Consensus - SACM Information Model as WG I-D=

 

There was consensus in the SACM WG interim meeting l= ast week to create a SACM Information Model WG I-D based on https://datatracker.ietf.org/doc/draft-combined-sacm-information-model/= .

 

This message calls for the mail list confirmation of= this decision. Please send your opinions and especially concerns (if any) = with arguments to the WG mail list until Wednesday 9/24 COB.

 

Thanks and Regards,

 

Dan

 

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA5C8C6908AZFFEXMB04globa_-- From nobody Fri Oct 10 16:55:03 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5309D1A020A; Fri, 10 Oct 2014 16:55:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hp_PxjxYDA2X; Fri, 10 Oct 2014 16:54:59 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AC091A019B; Fri, 10 Oct 2014 16:54:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3.p4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141010235459.7952.84182.idtracker@ietfa.amsl.com> Date: Fri, 10 Oct 2014 16:54:59 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/OrbxYUK8x5Y3LoJaKhMHBp7sojU Cc: sacm@ietf.org Subject: [sacm] I-D Action: draft-ietf-sacm-requirements-01.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2014 23:55:00 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Security Automation and Continuous Monitoring Working Group of the IETF. Title : Secure Automation and Continuous Monitoring (SACM) Requirements Authors : Nancy Cam-Winget Lisa Lorenzin Filename : draft-ietf-sacm-requirements-01.txt Pages : 11 Date : 2014-10-10 Abstract: This document defines the scope and set of requirements for the Secure Automation and Continuous Monitoring working group. The requirements and scope are based on the agreed upon use cases. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sacm-requirements/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sacm-requirements-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-sacm-requirements-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Oct 10 16:56:42 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28C151A01EA for ; Fri, 10 Oct 2014 16:56:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.286 X-Spam-Level: X-Spam-Status: No, score=-15.286 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BGtecI4icLF5 for ; Fri, 10 Oct 2014 16:56:39 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B91721A01D0 for ; Fri, 10 Oct 2014 16:56:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1145; q=dns/txt; s=iport; t=1412985399; x=1414194999; h=from:to:subject:date:message-id:mime-version; bh=X9IFptisx78cf8i5Hy5J9/uf2oSYeQYQ2kuiQY/JOPQ=; b=WBGzcBLEcZXCMQL5M/A9bJwVFJa4H8QEdx6flup0qFII3UqvdYQXt/42 xmtiUlW4rn1Kye15mPmLahskltuh2BjG+Ol/sIwhKqqj0FtRdMNxYVTQP ZFCjO7GEWQdluHY6Q8u4q9GwSQw1SnPA9Q7I4Ro2lLFIy4zPiva9Q5Ajw c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsgHAGhxOFStJV2Y/2dsb2JhbABggkgjI1NZA7sNjiuBbYhSFgFyCYN6EIELAQsBdCcEiFEBDJtipFeVFgWReYRChxCBapQngUcMAYIjgjSBAgEBAQ X-IronPort-AV: E=Sophos; i="5.04,696,1406592000"; d="scan'208,217"; a="85977212" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-2.cisco.com with ESMTP; 10 Oct 2014 23:56:39 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s9ANudsk013148 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 10 Oct 2014 23:56:39 GMT Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0195.001; Fri, 10 Oct 2014 18:56:38 -0500 From: "Nancy Cam-Winget (ncamwing)" To: "sacm@ietf.org" Thread-Topic: draft-ietf-sacm-requirements-01 posted Thread-Index: AQHP5OXUtFErpnScMUyqZxtu+KSFXA== Date: Fri, 10 Oct 2014 23:56:37 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.155.84.85] Content-Type: multipart/alternative; boundary="_000_D05DC044D06F6ncamwingciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/FQdlZFu40hJqOMoec89qkw_gHYk Subject: [sacm] draft-ietf-sacm-requirements-01 posted X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2014 23:56:41 -0000 --_000_D05DC044D06F6ncamwingciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, An updated version of the Requirements draft has been posted to : http://da= tatracker.ietf.org/doc/draft-ietf-sacm-requirements/ Thanks, nancy --_000_D05DC044D06F6ncamwingciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
All,

An updated version of the Requirements draft has been posted to : = ;h= ttp://datatracker.ietf.org/doc/draft-ietf-sacm-requirements/

Thanks, nancy
--_000_D05DC044D06F6ncamwingciscocom_-- From nobody Mon Oct 13 17:51:52 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 227101A1A6C for ; Mon, 13 Oct 2014 17:51:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22_MKkXv87At for ; Mon, 13 Oct 2014 17:51:48 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0073.outbound.protection.outlook.com [207.46.100.73]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DEB91A004C for ; Mon, 13 Oct 2014 17:51:48 -0700 (PDT) Received: from BN1PR06MB200.namprd06.prod.outlook.com (10.242.215.154) by BN1PR06MB198.namprd06.prod.outlook.com (10.242.215.145) with Microsoft SMTP Server (TLS) id 15.0.1049.19; Tue, 14 Oct 2014 00:51:45 +0000 Received: from BN1PR06MB200.namprd06.prod.outlook.com ([169.254.5.218]) by BN1PR06MB200.namprd06.prod.outlook.com ([169.254.5.218]) with mapi id 15.00.1049.012; Tue, 14 Oct 2014 00:51:44 +0000 From: "Kahn, Clifford" To: "sacm@ietf.org" Thread-Topic: Should the SACM information model I-D discuss the graph model? Thread-Index: Ac/nSMQK0iOT3gcHQG2M2xg6vl9jSQ== Date: Tue, 14 Oct 2014 00:51:44 +0000 Message-ID: <3d271715e7a94abda61c7194eae5ba6a@BN1PR06MB200.namprd06.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [66.129.239.10] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR06MB198; x-exchange-antispam-report-test: UriScan:; x-forefront-prvs: 03648EFF89 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(377424004)(189002)(199003)(229853001)(76576001)(31966008)(21056001)(2351001)(66066001)(40100003)(101416001)(120916001)(99396003)(106356001)(122556002)(99286002)(95666004)(76482002)(107046002)(107886001)(64706001)(20776003)(105586002)(54356999)(50986999)(85852003)(4396001)(86362001)(74316001)(97736003)(92566001)(33646002)(2501002)(77096002)(2656002)(108616004)(46102003)(80022003)(87936001)(110136001)(85306004)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN1PR06MB198; H:BN1PR06MB200.namprd06.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: pulsesecure.net Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/pF25HsGHkvcdYwdIGVVDGCRYD1k Subject: [sacm] Should the SACM information model I-D discuss the graph model? X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 00:51:50 -0000 Dear SACM WG: At the 2014-09-10 virtual meeting, we debated, but did not resolve, whether= the SACM information model I-D should discuss the graph model. I recall ta= king an action item to write to the list about it. This belated memo fulfil= ls that action item. >From the minutes of the September meeting: * Dan - how does the Graph Model (5) related to the Info model (4)=20 * Lisa - sect 4 is about organization. Sec 5 is about enumeration=20 * Dan R - We may want to talk about the graph representation as an appendix= or separate document that explains the usage of the more complex structure= s. I don't think we need to list all the elements, instances and attributes= and representing them through the graph model. Maybe we need an example or= two. I'm still fighting whether graph model belongs here as an appendix or= a separate document.=20 * Jim Bieda - Graph model seems like an implementation choice. Is it a shou= ld or a must or an option.=20 * Lisa - Open question? Jim - there is an opportunity to work this for the = next call and meeting.=20 * Dave W - if we don't use graph notation in this document, then what shoul= d be use instead?=20 * Dan R - maybe UML. Also, maybe section 6 should be merged into section 5.= =20 * Lisa - Looking for helping writing section 6 without graph terminology. (= chuckles).=20 Here are my further comments.=20 I don't know how suitable a graph model is. Endpoint attribute assertions a= re at the heart of the proposed information model (see section 4.7 of the I= -D). Endpoint attribute assertions seem like tuples. They seem relational. = Maybe there is a good graph notation for them; maybe we will adopt it. But = it seems productive to *first* refine and agree on concepts like endpoint a= ttribute assertion, and *then* work out how to represent them.=20 Even so, let us suppose for a moment that we decided to use the graph model= approach proposed in section 5 of draft-combined-sacm-information-model-00= . That decision would leave open issues. Should hardware component, hardwar= e instance, software component, and software instance be four identifier ty= pes? (See Figure 1 of the I-D.) Or should all of these be captured in a Yan= g description of the endpoint? The Yang description would be attached to a= n endpoint identifier, as metadata. Both representations seem to have meri= t. It seems premature to answer the question now. It seems better handled i= n a data model document. =20 In conclusion, it seems premature to focus on a graph model. The UML notati= on in Figure 1 of the I-D floats at a higher level; this level seems more s= uitable for the information model. Can we agree to take section 5 out of th= e body of the information model I-D? We can move it to an appendix for now,= and consider it when we work on data models. =20 Best, Cliff Clifford Kahn Principal Engineer/Technical Lead Pulse Secure From nobody Mon Oct 13 20:00:00 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D5D01A1BCD for ; Mon, 13 Oct 2014 19:59:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gyGg4SBThx4r for ; Mon, 13 Oct 2014 19:59:55 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0638.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::638]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D9D21A6EE5 for ; Mon, 13 Oct 2014 19:59:55 -0700 (PDT) Received: from BN1PR06MB200.namprd06.prod.outlook.com (10.242.215.154) by BN1PR06MB197.namprd06.prod.outlook.com (10.242.215.144) with Microsoft SMTP Server (TLS) id 15.0.1049.19; Tue, 14 Oct 2014 02:59:31 +0000 Received: from BN1PR06MB200.namprd06.prod.outlook.com ([169.254.5.218]) by BN1PR06MB200.namprd06.prod.outlook.com ([169.254.5.218]) with mapi id 15.00.1049.012; Tue, 14 Oct 2014 02:59:30 +0000 From: "Kahn, Clifford" To: "sacm@ietf.org" Thread-Topic: Proposed additions to problem statement of SACM information model I-D Thread-Index: Ac/nWnsYETrfzYURRCqvCQxuINbvLg== Date: Tue, 14 Oct 2014 02:59:29 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [66.129.239.10] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR06MB197; x-exchange-antispam-report-test: UriScan:; x-forefront-prvs: 03648EFF89 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(199003)(189002)(76482002)(74316001)(66066001)(64706001)(54356999)(101416001)(92566001)(80022003)(46102003)(20776003)(76576001)(85852003)(50986999)(105586002)(95666004)(77096002)(31966008)(108616004)(85306004)(2501002)(99286002)(120916001)(4396001)(107886001)(2351001)(40100003)(229853001)(107046002)(21056001)(86362001)(33646002)(110136001)(97736003)(106356001)(2656002)(87936001)(122556002)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN1PR06MB197; H:BN1PR06MB200.namprd06.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: pulsesecure.net Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/KAYfYewzS3hENw2naih0tGQIM78 Subject: [sacm] Proposed additions to problem statement of SACM information model I-D X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 02:59:57 -0000 The following additions motivate the core concept of the "endpoint attribut= e assertion". 2.2 Referring to an Endpoint How to refer to an endpoint is problematic. Ideally, an endpoint would have= a unique identifier. These identifiers would have a one-to-one relationshi= p with endpoints. Every observation of an endpoint, or inference about an e= ndpoint would be labeled with its identifier.=20 However: - An external posture attribute collector typically cannot observe the uniq= ue identifier directly. An external posture attribute collector should be a= ble to report exactly what it has observed, unembellished. It should not ha= ve to *infer* which endpoint it has observed; that inference should be leav= able to other SACM components. So, SACM cannot require that every observati= on include the unique endpoint identifier.=20 - Internal posture attribute collectors are not present on all endpoints. T= hey are not present on "dumb" devices such as Internet of Things (IoT) devi= ces, or on Bring Your Own Device (BYOD) devices. In these cases, *no* obser= vers have direct access to the unique endpoint identifier.=20 - An endpoint identifier is generally subject to cloning, when a system ima= ge is cloned. Then it is no longer unique.=20 - Suppose the endpoint identifier is highly clone resistant -- such a uniqu= e certificate within a trusted platform module (TPM). Even so, it is possi= ble to replace all of the software -- for example, changing a Windows machi= ne to a Linux machine. Is it still the same endpoint? For SACM purposes, i= t isn't really the same endpoint. =20 So SACM components must be able to put disparate observations together and = form a picture of an endpoint -- somewhat like a detective. The SACM inform= ation model must facilitate this. 2.3 Dealing with Uncertainty With many information models, the information is considered certain. So it = is OK to blur the difference between the representation and the thing repre= sented. In SACM, information is not certain. Attackers may develop countermeasures = to fool some SACM components. Attackers may compromise some SACM componen= ts. =20 So the model must let SACM components and humans reason with uncertainty. T= herea are no facts, only assertions. =20 SACM components must be able to cross check observations and inferences aga= inst each other. They should be able to give weight if an observation or in= ference is corroborated by more than one method.=20 SACM components must be able to consider the reputation of the observer or = inferer. That reputation should account for the method of observing or inf= erring, the implementer of the SACM component that made the observation or = inference, and the compliance status of the endpoint on which the observati= on or inference was made. For example, if some observers are found to be v= ulnerable to a Day 1 exploit, observations from those observers deserve les= s weight. =20 Clifford Kahn Principal Engineer/Technical Lead From nobody Mon Oct 13 21:28:07 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 824FC1A6F85 for ; Mon, 13 Oct 2014 21:28:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fo093lmt1j2n for ; Mon, 13 Oct 2014 21:28:03 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0606.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:606]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83CF51A6F84 for ; Mon, 13 Oct 2014 21:28:03 -0700 (PDT) Received: from BN1PR06MB200.namprd06.prod.outlook.com (10.242.215.154) by BN1PR06MB199.namprd06.prod.outlook.com (10.242.215.150) with Microsoft SMTP Server (TLS) id 15.0.1049.19; Tue, 14 Oct 2014 04:27:38 +0000 Received: from BN1PR06MB200.namprd06.prod.outlook.com ([169.254.5.218]) by BN1PR06MB200.namprd06.prod.outlook.com ([169.254.5.218]) with mapi id 15.00.1049.012; Tue, 14 Oct 2014 04:27:38 +0000 From: "Kahn, Clifford" To: "sacm@ietf.org" Thread-Topic: Revised UML diagram for information model Thread-Index: Ac/nZSaGGLimUdLiSLi3Fs0GclgoHw== Date: Tue, 14 Oct 2014 04:27:37 +0000 Message-ID: <12f4b2dbfbcb4b5bb4e59d80562ffba3@BN1PR06MB200.namprd06.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [67.207.101.114] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR06MB199; x-exchange-antispam-report-test: UriScan:; x-forefront-prvs: 03648EFF89 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(199003)(189002)(50986999)(4396001)(87936001)(85852003)(2656002)(86362001)(92566001)(76576001)(99936001)(110136001)(74316001)(54356999)(31966008)(76482002)(33646002)(120916001)(108616004)(85306004)(105586002)(66066001)(106356001)(95666004)(99286002)(2351001)(229853001)(107886001)(107046002)(40100003)(20776003)(64706001)(2501002)(97736003)(21056001)(101416001)(77096002)(80022003)(46102003)(122556002)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN1PR06MB199; H:BN1PR06MB200.namprd06.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: multipart/mixed; boundary="_002_12f4b2dbfbcb4b5bb4e59d80562ffba3BN1PR06MB200namprd06pro_" MIME-Version: 1.0 X-OriginatorOrg: pulsesecure.net Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/txVURlhq8chB4wXFgnElsH0mUsE Subject: [sacm] Revised UML diagram for information model X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 04:28:05 -0000 --_002_12f4b2dbfbcb4b5bb4e59d80562ffba3BN1PR06MB200namprd06pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, We talked about making the information model treat all of the SACM componen= ts the same. The architecture distinguishes kinds of components; the inform= ation model does not need to.=20 The diagram in draft-combined-sacm-information-model-00 says that every End= point Attribute Assertion is directly paired with an endpoint. That is wish= ful thinking. True: many attribute-value pairs (AVP) refer to things in th= e upper half of the diagram - addresses, software components, locations, en= dpoints (by unique identifier), etc.=20 I didn't have time to revise the text to match. But here is a revised diagr= am.=20 Best, Cliff P.S. Apologies to my fellow editors. We haven't found time to collaborate = since the last virtual meeting. I seem to be on a roll today; I hope these = late contributions are on the right track. Clifford Kahn Principal Engineer/Technical Lead Pulse Secure --_002_12f4b2dbfbcb4b5bb4e59d80562ffba3BN1PR06MB200namprd06pro_ Content-Type: text/plain; name="figure_1.txt" Content-Description: figure_1.txt Content-Disposition: attachment; filename="figure_1.txt"; size=2757; creation-date="Tue, 14 Oct 2014 04:24:16 GMT"; modification-date="Tue, 14 Oct 2014 04:24:16 GMT" Content-Transfer-Encoding: base64 ICArLS0tLS0tLS0tKyArLS0tLS0tLS0tKyAgICAgICAgICAgICAgKy0tLS0tLS0tK19fX19fX19f X19fX19fX19fX19fDQogIHxIYXJkd2FyZSB8IHxTb2Z0d2FyZSB8ICAgIF9fX19fX19fX198TG9j YXRpb258Kl9fX19fX19fX19fX19fXyAgICB8DQogIHxDb21wb25lbnR8IHxDb21wb25lbnR8ICAg fCAgICAgICAgICorLS0tLS0tLS0rKiAgICAgICAgICAgICAgIHwgICB8DQogICstLS0tLS0tLS0r ICstLS0tLS0tLS0rICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICB8 DQogICAgICAgfDEgICAgICAgICAgfDEgICAgICAgfCAgICAgICAgICstLS0tLS0tLS0tKyAgICAg ICAgICAgICAgIHwgICB8DQogICAgICAgfCogICAgICAgICAgfCogICAgICAgfCAgIF9fX19fX3xD cmVkZW50aWFsfF9fX19fX19fX19fXyAgIHwgICB8DQogICstLS0tLS0tLS0rICstLS0tLS0tLSsg ICAgfCAgfCAgICAgKistLS0tLS0tLS0tKyogICAgICAgICAgIHwqIHwqICB8DQogIHxIYXJkd2Fy ZSB8IHxTb2Z0d2FyZXwgICAgfCAgfCAgICAgICAgICstLS0tLS0tLS0rICAgICAgICAgKy0tLS0r ICB8DQogIHxJbnN0YW5jZSB8IHxJbnN0YW5jZXwgICAgfCAgfCAgICAgICAgIHxOZXR3b3JrICB8 X19fX19fX19ffFVzZXJ8ICB8DQogICstLS0tLS0tLS0rICstLS0tLS0tLSsgICAgfCAgfCAgICAg ICAgIHxTZXNzaW9uICB8KiAgICAwLi4xKy0tLS0rICB8DQogICAgICAgfCogICAgICB8KiAgICAg ICAgICAqfCAqfCAgICAgICAgIHwtIC0gLSAtIC18ICAgICAgICAgICAgICAgICp8DQogICAgICAg fCAgICAgICB8X19fMSstLS0tLS0tLS0tLSsxX19fX19fKnxOZXR3b3JrICB8X19fX19fX19fXyst LS0tLS0tKw0KICAgICAgIHxfX19fX19fX19fX198IEVuZHBvaW50ICB8X19fX18gICB8SW50ZXJm YWNlfCogICAgIDEuLip8QWRkcmVzc3wNCiAgICAgICAgICAgICAgICAgICAxfCAgICAgICAgICAg fDAuLjEgfCAgKy0tLS0tLS0tLSsgICAgICAgICAgKy0tLS0tLS0rDQogICAgICAgICAgICAgICAg ICAgICstLS0tLS0tLS0tLSsgICAgIHwgICAgICAxfA0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHwqICAgICB8ICAgICAgIHxfX19fXystLS0tLS0tLS0tLS0tKw0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHxfX19fX198ICAgICAgICAgICAgKnxBdXRob3JpemF0aW9ufA0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBwYXJ0LW9mPiAgICAgICAgICAgICstLS0t LS0tLS0tLS0tKw0KICAuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uDQogICAgICAgICAgICAgICAgICB8MC4uMQ0KICAg ICAgICAgICAgICAgICAgfA0KICAgICAgICAgICAgICAgICAgfCoNCiAgICAgICAgICAgICAgICAg Ky0tLSsgICAgICAgICstLS0tLS0tLS0rX19fX19fPl9fX19fXystLS0tLS0tKw0KICAgICAgICAg ICAgICAgICB8QVZQfF9fX19fX19ffEVuZHBvaW50IHwqICAgICAgICAgICAxfFN1bW1hcnl8DQog ICAgICAgICAgICAgICAgICstLS0rMS4uKiAgIDF8QXR0cmlidXRlfF9fX19fX18gICAgICArLS0t LS0tLSsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHxBc3NlcnRpb258MC4uMSAgIHwg ICAgICAgICp8DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tKyAgICAg ICB8ICAgICAgICAgfA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCogICB8KiAg ICAgICAgfCAgICAgICAgIHwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHxeICAg fF9fX18+X19fX3wgICAgICAgIF58DQogICAgICAgICAgICAgICAgICAgICAgYXNzZXJ0ZWQtYnl8 ICAgICA8YmFzZWQtb24gICAgICAgICAgfHN1bW1hcml6ZWQtYnkNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHwxICAgICAgICAgICAgICAgICAgICAgICB8DQogICAgICAgICAgICAg LS0tLS0tLS0tLS0tICAgICArLS0tLS0tLS0tKyAgICAgICAgICAgICAgICAgfA0KICAgICAgICAg ICAgIHwgICAgICAgICAgfF9fPl9ffFNBQ00gICAgIHxfX19fX19fX19fX19fX19fX3wNCiAgICAg ICAgICAgICB8R3VpZGFuY2UgIHwxICAgKnxDb21wb25lbnR8MQ0KICAgICAgICAgICAgIC0tLS0t LS0tLS0tLSAgICAgKy0tLS0tLS0tLSsNCg0KICAgICAgICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICAgICAgICAgMSAgICAg TXVsdGlwbGljaXR5IHN5bWJvbHMgICAgPiA8IERpcmVjdGlvbiBvZiBjYXVzYXRpb24uICBGb3IN CiAgICAgICAgIDAuLjEgIGZvdW5kIGluIFVNTCAyICAgICAgICAgIHYgXiBleGFtcGxlLCBndWlk YW5jZSBhZmZlY3RzDQogICAgICAgICAqICAgICBjbGFzcyBkaWFncmFtcyAgICAgICAgICAgICAg YWZmZWN0cyBhIFNBQ00gY29tcG9uZW50Lg0KICAgICAgICAgMS4uKg0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgLi4uLi4gQWJvdmUgdGhpcyBsaW5lIGlzIHRoZQ0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbW9uaXRvcmFibGUgd29y bGQNCiAgICAgICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCg0KICAgICAgICAgICAgICAgICAgICBGaWd1cmUgMTogRWxlbWVu dHMgYW5kIE11bHRpcGxpY2l0eQ0K --_002_12f4b2dbfbcb4b5bb4e59d80562ffba3BN1PR06MB200namprd06pro_-- From nobody Tue Oct 14 03:10:27 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D05401A701D for ; Tue, 14 Oct 2014 03:09:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.686 X-Spam-Level: X-Spam-Status: No, score=-7.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GTnZuc1wvKE2 for ; Tue, 14 Oct 2014 03:09:52 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDE7C1A701F for ; Tue, 14 Oct 2014 03:09:51 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApALANH1PFSHCzIm/2dsb2JhbABbgmsjU1gEgwK1bJM8h00CG3oWAQFxC4QCAQEBAQIBEhERUQQCAQgNBAQBAQMCBgsSAwICAjAUAQYBAQUDAgQTCAwOiBQIAQymIYpPlQ8BAQEBAQUBAQEBAQEBAQEZgSyEdIZnglwRAR84BgSCbTaBHgWReYRCgXaGSDyDCoMbhEWFP4N+g3dsgQ85gQIBAQE X-IronPort-AV: E=Sophos;i="5.04,716,1406606400"; d="scan'208";a="87184260" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by co300216-co-outbound.net.avaya.com with ESMTP; 14 Oct 2014 06:09:50 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES128-SHA; 14 Oct 2014 06:09:50 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC04.global.avaya.com ([135.64.58.14]) with mapi id 14.03.0174.001; Tue, 14 Oct 2014 12:09:48 +0200 From: "Romascanu, Dan (Dan)" To: "sacm@ietf.org" Thread-Topic: NOMCOM 2014 - nominations extended for RAI, OAM, TSV and INT - Oct 20 Thread-Index: AQHP5vcgEP1T24P/1kyFKwj3wTVzPJwvX/Aw Date: Tue, 14 Oct 2014 10:09:48 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C8CB452@AZ-FFEXMB04.global.avaya.com> References: <20141013150506.31387.47470.idtracker@ietfa.amsl.com> In-Reply-To: <20141013150506.31387.47470.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/PaP395D7OqAhFGkdP6nbA9eu7Gs Subject: [sacm] FW: NOMCOM 2014 - nominations extended for RAI, OAM, TSV and INT - Oct 20 X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 10:09:55 -0000 X-List-Received-Date: Tue, 14 Oct 2014 10:09:55 -0000 QSBtZXNzYWdlIGZyb20gdGhlIE5PTUNPTSBjaGFpci4gUGxlYXNlIGNvbnNpZGVyIGhlbHBpbmcg Tk9NQ09NIGluIHRoZWlyIGltcG9ydGFudCB0YXNrLiANCg0KUmVnYXJkcywNCg0KRGFuDQoNCg0K PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBpZXRmIFttYWlsdG86aWV0Zi1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTm9tQ29tIENoYWlyIDIwMTQNCj4gU2VudDog TW9uZGF5LCBPY3RvYmVyIDEzLCAyMDE0IDY6MDUgUE0NCj4gVG86IFdvcmtpbmcgR3JvdXAgQ2hh aXJzDQo+IENjOiBpZXRmQGlldGYub3JnDQo+IFN1YmplY3Q6IE5PTUNPTSAyMDE0IC0gbm9taW5h dGlvbnMgZXh0ZW5kZWQgZm9yIFJBSSwgT0FNLCBUU1YgYW5kIElOVCAtDQo+IE9jdCAyMA0KPiAN Cj4ge2Fwb2xvZ2llcyBpZiB5b3Ugc2VlIHRoaXMgbXVsdGlwbGUgdGltZXN9DQo+IA0KPiBUaGUg MjAxNC0xNSBOb21pbmF0aW5nIENvbW1pdHRlZSAoTm9tY29tKSB3aWxsIHN0aWxsIGFjY2VwdCBu b21pbmF0aW9ucw0KPiBmcm9tIG5vdyB1bnRpbCBPY3RvYmVyIDIwLCAyMDE0IEFUIE1JRE5JR0hU IEVEVCBmb3IgdGhlIElFU0cgcG9zaXRpb25zIG9mDQo+IEFyZWEgRGlyZWN0b3IgZm9yOg0KPiAg ICAtIFJBSSAtIDINCj4gICAgLSBPQU0gLSAxDQo+ICAgIC0gVFNWIC0gMQ0KPiAgICAtIElOVCAt IDINCj4gICAgLSBHRU4gLSAxICAgIChJRVRGIENoYWlyKQ0KPiANCj4gYXJlYS4gIFdoaWxlIGlu IGVhY2ggY2FzZSB3ZSBoYXZlIGFuIGluY3VtYmVudCB3aG8gaXMgd2lsbGluZyB0byBjb250aW51 ZSwNCj4gYW5kIGluIHR3byBvZiB0aG9zZSBhcmVhcyB3ZSBoYXZlIG9uZSBhZGRpdGlvbmFsIGNh bmRpZGF0ZTsgd2Ugd291bGQgZGVhcmx5DQo+IGxpa2UgdG8gYmUgYmUgc2VsZWN0aW5nIGZyb20g YSBzbGlnaHRseSBsYXJnZXIgZmllbGQuDQo+IA0KPiBJdCBpcyBpbXBvc3NpYmxlIGZvciB0aGUg Tk9NQ09NIHRvIGJlIHN1cmUgdGhhdCB3ZSBoYXZlIHRoZSBiZXN0IGNhbmRpZGF0ZQ0KPiBpZiB3 ZSBoYXZlIG9ubHkgb25lIHBvc3NpYmxlIGNhbmRpZGF0ZS4gRXZlbiBpZiB0aGUgeW91IHRoaW5r IHRoZSBpbmN1bWJlbnQNCj4gaXMgdGhlIGJlc3QgcGVyc29uIGZvciB0aGUgam9iLCBpdCBpcyBp bXBvcnRhbnQsIGlmIG9ubHkgZm9yIHN1Y2Nlc3Npb24gcGxhbm5pbmcsDQo+IHRvIGtub3cgd2hv IGVsc2UgY291bGQgZG8gdGhlIGpvYi4NCj4gDQo+IEF0IGxlYXN0IG9uZSBvZiB0aGVzZSBpbmN1 bWJlbnRzIGhhdmUgc2FpZCBjbGVhcmx5IHRoYXQgdGhpcyByZWFsbHkgaGFzIGJlY29tZQ0KPiBh IDUwJSBjb21taXRtZW50IG9mIGEgNDAgaG91ciB3ZWVrLCBpLmUuIGl0IGlzIHBvc3NpYmxlIHRv IGRvIHNpZ25pZmljYW50IHdvcmsNCj4gb24gYSAiZGF5IGpvYiINCj4gDQo+IEZvciB0aGUgYWJv dmUgZml2ZSBwb3NpdGlvbnMgdGhlcmUgYXJlIDkgbm9taW5lZXMgd2hvIGhhdmUgbmVpdGhlcg0K PiBhY2NlcHRlZCBub3IgZGVjbGluZWQuICBJZiB5b3Ugbm9taW5hdGVkIHNvbWVvbmUgYW5kIHRo ZWlyIG5hbWUgZG9lcyBub3QNCj4gYXBwZWFyIGF0Og0KPiAgaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9ub21jb20vMjAxNC9mZWVkYmFjay8gDQo+IHRoYXQncyBiZWNhdXNlIHRoZXkgaGF2 ZSBlaXRoZXIgZGVjbGluZWQsIG9yIHRoZXkgaGF2ZSBub3QgaW5kaWNhdGVkDQo+IHRoaW5ncyBv bmUgd2F5IG9yIG90aGVyLiAgIFBlcmhhcHMgdGhleSBhcmUgc3RpbGwgZGVjaWRpbmcsIG9yIHBl cmhhcHMNCj4gdGhleSBuZXZlciBnb3QgdGhlIGVtYWlsLCB5b3UgY2FuIGhlbHAgdGhlIG5vbWNv bSBieSBjb25maXJtaW5nIHdpdGgNCj4gdGhlbS4NCj4gDQo+ID09PT0NCj4gDQo+IE5vbWluYXRp b25zIG1heSBiZSBtYWRlIGJ5IHNlbGVjdGluZyB0aGUgTm9taW5hdGUgbGluayBhdCB0aGUgdG9w IG9mIHRoZQ0KPiBOb21jb20gMjAxNCBob21lIHBhZ2UsIG9yIGJ5IHZpc2l0aW5nIHRoZSBmb2xs b3dpbmcgVVJMOg0KPiANCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9ub21jb20vMjAx NC9ub21pbmF0ZS8NCj4gDQo+ICAge05vdGUgdGhhdCBub21pbmF0aW9ucyBtYWRlIHVzaW5nIHRo ZSB3ZWIgdG9vbCByZXF1aXJlIGFuIGlldGYub3JnDQo+ICAgIGRhdGF0cmFja2VyIGFjY291bnQu IFlvdSBjYW4gY3JlYXRlIGEgZGF0YXRyYWNrZXIgaWV0Zi5vcmcgYWNjb3VudA0KPiAgICBpZiB5 b3UgZG9uJ3QgaGF2ZSBvbmUgYWxyZWFkeSBieSB2aXNpdGluZyB0aGUgZm9sbG93aW5nIFVSTDoN Cj4gICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9hY2NvdW50cy9jcmVhdGUvIH0N Cj4gDQo+IE5vbWluYXRpb25zIG1heSBhbHNvIGJlIG1hZGUgYnkgZW1haWwgdG8gbm9tY29tMTRA aWV0Zi5vcmcuDQo+IA0KPiBJZiB1c2UgZW1haWwsIHBsZWFzZSBpbmNsdWRlIHRoZSB3b3JkICJO b21pbmF0ZSIgaW4gdGhlIFN1YmplY3QgYW5kIGluZGljYXRlDQo+IGluIHRoZSBlbWFpbCB3aG8g aXMgYmVpbmcgbm9taW5hdGVkLCB0aGVpciBlbWFpbCBhZGRyZXNzICh0byBjb25maXJtDQo+IGFj Y2VwdGFuY2Ugb2YgdGhlIG5vbWluYXRpb24pLCBhbmQgdGhlIHBvc2l0aW9uIGZvciB3aGljaCB5 b3UgYXJlIG1ha2luZw0KPiB0aGUgbm9taW5hdGlvbi4gSWYgeW91IHdpc2ggdG8gbm9taW5hdGUg c29tZW9uZSB2aWEgZW1haWwgZm9yIG1vcmUgdGhhbg0KPiBvbmUgcG9zaXRpb24sIHBsZWFzZSB1 c2Ugc2VwYXJhdGUgZW1haWxzIHRvIGRvIHNvLg0KPiANCj4gU2VsZi1ub21pbmF0aW9uIGlzIHdl bGNvbWUhDQo+IA0KPiBOb21Db20gMjAxNC0xNSB3aWxsIGZvbGxvdyB0aGUgcG9saWN5IGZvciAi T3BlbiBEaXNjbG9zdXJlIG9mIFdpbGxpbmcNCj4gTm9taW5lZXMiIGRlc2NyaWJlZCBpbiBSRkMg NTY4MC4gIEFzIHN0YXRlZCBpbiBSRkMgNTY4MDogIlRoZSBsaXN0IG9mDQo+IG5vbWluZWVzIHdp bGxpbmcgdG8gYmUgY29uc2lkZXJlZCBmb3IgcG9zaXRpb25zIHVuZGVyIHJldmlldyBpbiB0aGUg Y3VycmVudA0KPiBOb21jb20gY3ljbGUgaXMgbm90IGNvbmZpZGVudGlhbCIuIFdpbGxpbmcgbm9t aW5lZXMgZm9yIGVhY2ggcG9zaXRpb24gd2lsbCBiZQ0KPiBsaXN0ZWQgaW4gYSBwdWJsaWNseSBh Y2Nlc3NpYmxlIHdheSAtIGFueW9uZSB3aXRoIGEgZGF0YXRyYWNrZXIgYWNjb3VudCBtYXkNCj4g YWNjZXNzIHRoZSBsaXN0cy4gIEluIGFsbCBvdGhlciB3YXlzLCB0aGUgY29uZmlkZW50aWFsaXR5 IHJlcXVpcmVtZW50cyBvZiBSRkMNCj4gMzc3Ny9CQ1AxMCByZW1haW4gaW4gZWZmZWN0LiAgQWxs IGZlZWRiYWNrIGFuZCBhbGwgTm9tY29tIGRlbGliZXJhdGlvbnMgd2lsbA0KPiByZW1haW4gY29u ZmlkZW50aWFsIGFuZCB3aWxsIG5vdCBiZSBkaXNjbG9zZWQuDQo+IA0KPiBQbGVhc2Ugc3VibWl0 IHlvdXIgbm9taW5hdGlvbnMgYXMgZWFybHkgYXMgcG9zc2libGUgZm9yIHRoZSBzYWtlIG9mIHlv dXINCj4gbm9taW5lZXMuIE5vdGUgdGhhdCBub21pbmF0aW9ucyBzaG91bGQgbm90IHdhaXQgZm9y IG1hbmFnZW1lbnQNCj4gcGVybWlzc2lvbiwgYXMgaXQgaXMgZWFzaWVyIHRvIGRlY2xpbmUgdGhl IG5vbWluYXRpb24sIHRoYW4gcHV0IG9uZSBpbiBsYXRlLg0KPiBXZSd2ZSBzZXQgdGhlIHF1ZXN0 aW9ubmFpcmUgc3VibWlzc2lvbiBkZWFkbGluZSBmb3IgT2N0b2JlciAyNSwgMjAxNC4NCj4gDQo+ IFRoZSBOb21jb20gYXBwb2ludHMgaW5kaXZpZHVhbHMgdG8gZmlsbCB0aGUgb3BlbiBzbG90cyBv biB0aGUgSUFPQywgdGhlIElBQiwNCj4gYW5kIHRoZSBJRVNHLiBUaGUgbGlzdCBvZiBwZW9wbGUg YW5kIHBvc3RzIHdob3NlIHRlcm1zIGVuZCB3aXRoIHRoZSBNYXJjaA0KPiAyMDE1IElFVEYgbWVl dGluZywgYW5kIHRodXMgdGhlIHBvc2l0aW9ucyBmb3Igd2hpY2ggdGhpcyBOb21jb20gaXMNCj4g cmVzcG9uc2libGUsIGZvbGxvd3M6DQo+IA0KPiBJQU9DOg0KPiBSYW5keSBCdXNoDQo+IA0KPiBJ QUI6DQo+IEpvZWwgSGFscGVybioNCj4gUnVzcyBIb3VzbGV5DQo+IEVsaW90IExlYXINCj4gWGlu ZyBMaQ0KPiBBbmRyZXcgU3VsbGl2YW4NCj4gRGF2ZSBUaGFsZXINCj4gDQo+IElFU0c6DQo+IFBl dGUgUmVzbmljayogKEFwcGxpY2F0aW9ucykNCj4gVGVkIExlbW9uIChJbnRlcm5ldCkNCj4gSm9l bCBKYWVnZ2xpIChPcGVyYXRpb25zIGFuZCBNYW5hZ2VtZW50KSBSaWNoYXJkIEJhcm5lcyAoUkFJ KSBBZHJpYW4NCj4gRmFycmVsKiAoUm91dGluZykgU3RlcGhlbiBGYXJyZWxsIChTZWN1cml0eSkg U3BlbmNlciBEYXdraW5zIChUcmFuc3BvcnQpIEphcmkNCj4gQXJra28gKEdlbikNCj4gDQo+ICot IGtub3duIHRvIGhhdmUgZGVjbGluZSB0byBydW4gYWdhaW4uDQo+IA0KPiBQTEVBU0UgTk9URSBU SEFUIElUIElTIExJS0VMWSBUSEFUIEFQUExJQ0FUSU9OUyBBUkVBIFdJTEwgTk9UIEJFDQo+IEZJ TExFRCBBVCBUSEUgSUVTRyBSRVFVRVNULg0KPiANCj4gUGxlYXNlIGJlIHJlc291cmNlZnVsIGlu IGlkZW50aWZ5aW5nIHBvc3NpYmxlIGNhbmRpZGF0ZXMgZm9yIHRoZXNlIHBvc2l0aW9ucywNCj4g YXMgZGV2ZWxvcGluZyBvdXIgdGFsZW50IGlzIGEgdmVyeSBjcnVjaWFsIHJlcXVpcmVtZW50IGZv ciB0aGUgSUVURiwgYW5kIGFsc28sDQo+IHBsZWFzZSBjb25zaWRlciBhY2NlcHRpbmcgYSBub21p bmF0aW9uLiAgWW91J2xsIGZpbmQgZXh0ZW5zaXZlIGluZm9ybWF0aW9uDQo+IGFib3V0IHNwZWNp ZmljIHBvc2l0aW9ucywgZGV2ZWxvcGVkIGJ5IHRoZSBJQUIsIElFU0csIGFuZCBJQU9DLCB1bmRl cg0KPiBpbmRpdmlkdWFsIHRhYnMgYXQ6DQo+IA0KPiAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvbm9tY29tLzIwMTQvcmVxdWlyZW1lbnRzLw0KPiANCj4gSW4gYWRkaXRpb24gdG8gbm9t aW5hdGlvbnMsIHRoZSBOb21jb20gc2Vla3MgY29tbXVuaXR5IGlucHV0IG9uIHRoZQ0KPiBwb3Np dGlvbnMgdGhlbXNlbHZlcy4gIFdlIG5lZWQgYW5kIHdlbGNvbWUgdGhlIGNvbW11bml0eSdzIHZp ZXdzIGFuZA0KPiBpbnB1dCBvbiB0aGUgam9icyB3aXRoaW4gZWFjaCBvcmdhbml6YXRpb24uIElm IHlvdSBoYXZlIGlkZWFzIG9uIHRoZSBwb3NpdGlvbnMnDQo+IHJlc3BvbnNpYmlsaXRpZXMgKG1v cmUsIGxlc3MsIGRpZmZlcmVudCksIHBsZWFzZSBsZXQgdXMga25vdy4NCj4gDQo+IFBsZWFzZSBz ZW5kIHN1Z2dlc3Rpb25zIGFuZCBmZWVkYmFjayBhYm91dCB0aGlzIHRvIG5vbWNvbTE0QGlldGYu b3JnLg0KPiANCj4gVGhhbmsgeW91IGZvciB5b3VyIGhlbHAgaW4gaWRlbnRpZnlpbmcgcXVhbGlm aWVkIG5vbWluZWVzIQ0KPiANCj4gTWljaGFlbCBSaWNoYXJkc29uDQo+IE5vbWNvbSBDaGFpciAy MDE0LTE1DQo+IG5vbWNvbS1jaGFpci0yMDE0QGlldGYub3JnLCBtY3Irbm9tY29tQHNhbmRlbG1h bi5jYQ0KDQo= From nobody Tue Oct 14 04:38:54 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 420D51A8704 for ; Tue, 14 Oct 2014 04:38:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.685 X-Spam-Level: X-Spam-Status: No, score=-7.685 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id isCQ42rFgvcv for ; Tue, 14 Oct 2014 04:38:51 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D9511A8702 for ; Tue, 14 Oct 2014 04:38:51 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApcLAOgKPVTGmAcV/2dsb2JhbABbgkgjI1NYBLhsBpsJAoEVFgEBcQuEAgEBAQEDEgsQXAIBCA0EBAEBCx0HMhQJCAEBBBMIGogcAaY4n14BAQEBAQEBAQEBAQEBAQEBAQEBAQEXhiCJdDcBgy2BHgWReY0Ag0aDG4oEg36Dd2yBSIECAQEB X-IronPort-AV: E=Sophos; i="5.04,716,1406606400"; d="scan'208,217"; a="87199831" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by co300216-co-outbound.net.avaya.com with ESMTP; 14 Oct 2014 07:38:50 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 14 Oct 2014 07:38:50 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC02.global.avaya.com ([135.64.58.12]) with mapi id 14.03.0174.001; Tue, 14 Oct 2014 13:38:49 +0200 From: "Romascanu, Dan (Dan)" To: "sacm@ietf.org" Thread-Topic: IETF 91: call for agenda items Thread-Index: Ac/bWcC68MxPOhEuQz2AdnSXn6bJBgMSRzzg Date: Tue, 14 Oct 2014 11:38:48 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C8CB5BE@AZ-FFEXMB04.global.avaya.com> References: <9904FB1B0159DA42B0B887B7FA8119CA5C8AF7F9@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA5C8AF7F9@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA5C8CB5BEAZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/IVovfYAbTDNb3sdH7_EJv3T-XdM Subject: Re: [sacm] IETF 91: call for agenda items X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 11:38:53 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA5C8CB5BEAZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, The preliminary agenda shows the two SACM WG meetings scheduled as follows: MONDAY, November 10, 2014 0900-1130 Morning Session I Kahili 1/2 SEC sacm Security Automation and Conti= nuous Monitoring WG FRIDAY, November 14, 2014 0900-1130 Morning Session I Kahili 1/2 SEC sacm Security Automation and Conti= nuous Monitoring WG Note that this scheduling is subject to change. Please send your requests for agenda items and proposals about how to best = use the meeting and inter-meetings time. Thanks and Regards, Dan From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Sunday, September 28, 2014 11:21 PM To: sacm@ietf.org Subject: [sacm] IETF 91: call for agenda items Hi, We have entered a request for two meetings at IETF 91, same duration as at = IETF 90. Please send your requests and proposals for the agenda. Thanks and Regards, Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA5C8CB5BEAZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,<= /p>

 

The preliminary agenda= shows the two SACM WG meetings scheduled as follows:

 

MONDAY, November 10, 2014

0900-1130  Morning Session I

Kahili 1/2       = ;      SEC     sacm  &nbs= p;        Security Automation and Continuous = Monitoring WG

 

 

FRIDAY, November 14, 2014
0900-1130  Morning Session I
Kahili 1/2      &=
nbsp;      SEC     sacm  =
         Security Automation and Continu=
ous Monitoring WG

 

Note that this schedul= ing is subject to change.

 

Please send your reque= sts for agenda items and proposals about how to best use the meeting and in= ter-meetings time.

 

Thanks and Regards,

 

Dan<= /p>

 

 

From: sacm [ma= ilto:sacm-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan)
Sent: Sunday, September 28, 2014 11:21 PM
To: sacm@ietf.org
Subject: [sacm] IETF 91: call for agenda items

 

Hi,

 

We have entered a request for two meetings at IETF 9= 1, same duration as at IETF 90.

 

Please send your requests and proposals for the agen= da.

 

Thanks and Regards,

 

Dan

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA5C8CB5BEAZFFEXMB04globa_-- From nobody Tue Oct 14 06:48:17 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C0181A8829; Tue, 14 Oct 2014 06:48:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m9mcatTtLyuW; Tue, 14 Oct 2014 06:48:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5101A1A874D; Tue, 14 Oct 2014 06:48:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141014134813.23104.20724.idtracker@ietfa.amsl.com> Date: Tue, 14 Oct 2014 06:48:13 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/uaRB0pVUvnRWXT-tRAXYI_lrzXk Cc: sacm@ietf.org Subject: [sacm] I-D Action: draft-ietf-sacm-architecture-00.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 13:48:15 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Security Automation and Continuous Monitoring Working Group of the IETF. Title : Secure Automation and Continuous Monitoring (SACM) Architecture Authors : Nancy Cam-Winget Brian Ford Lisa Lorenzin Ira E McDonald Aaron Woland Filename : draft-ietf-sacm-architecture-00.txt Pages : 11 Date : 2014-10-13 Abstract: This document describes an architecture for standardization of interfaces, protocols and information models related to security automation and continuous monitoring. It describes the basic architecture, components and their interfaces defined to enable the collection, acquisition and verification of Posture and Posture Assessments. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sacm-architecture/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sacm-architecture-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Oct 14 09:48:36 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EFF21A8AB6 for ; Tue, 14 Oct 2014 09:48:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8H7IoP-agfqP for ; Tue, 14 Oct 2014 09:48:32 -0700 (PDT) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A83641A8AAE for ; Tue, 14 Oct 2014 09:48:32 -0700 (PDT) Received: by mail-ig0-f172.google.com with SMTP id r2so15310436igi.11 for ; Tue, 14 Oct 2014 09:48:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=pNoR4ZCB5Lh9hn/qs3ZmJjpOHMoSjAvlxPBC2FZwHXE=; b=HvIPkVqtYLqFBjDhj9iVAPTViVS/zdXEt85489pyVAiozA8eWIhMty2xOe7zD3mXkN UkNoK91LjGzaqf7djm+FDRQtK3LrRxxQhrYyBmblhgfs41+burtarqbHw0xrVCknAoF0 dYqXCt4MRJ1DL1YeIq0LoeBAICotLU90Zab5YwsfpuCnG7gvMgubVlVJOTXjpzAyZtF4 fPeyYQPmoGbz3Wo0psF+GkJvx4lwZ8W7CEDmBN9yv6TwIzVkQR18lVgkKp2GrJCjGAj3 bpffqpJcbB638h/4pPJuFcdMKuxWU7h6JPrnGR+3+BvId0fTx5NW2SWrdqXCvm9FNwGC 1XkQ== X-Received: by 10.50.1.51 with SMTP id 19mr7873808igj.33.1413305312077; Tue, 14 Oct 2014 09:48:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.172.212 with HTTP; Tue, 14 Oct 2014 09:48:11 -0700 (PDT) From: Ira McDonald Date: Tue, 14 Oct 2014 12:48:11 -0400 Message-ID: To: "sacm@ietf.org" , Ira McDonald Content-Type: multipart/alternative; boundary=047d7bdc15d015edce050564c905 Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/1wuWMC_WmpPUZ7aa7puatLePuTc Subject: [sacm] Link to NIST Asset ID report referred to today X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 16:48:34 -0000 --047d7bdc15d015edce050564c905 Content-Type: text/plain; charset=UTF-8 http://csrc.nist.gov/publications/nistir/ir7693/NISTIR-7693.pdf Ira McDonald (Musician / Software Architect) Co-Chair - TCG Trusted Mobility Solutions WG Chair - Linux Foundation Open Printing WG Secretary - IEEE-ISTO Printer Working Group Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG IETF Designated Expert - IPP & Printer MIB Blue Roof Music / High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto: blueroofmusic@gmail.com Winter 579 Park Place Saline, MI 48176 734-944-0094 Summer PO Box 221 Grand Marais, MI 49839 906-494-2434 --047d7bdc15d015edce050564c905 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
http://csrc.nist.gov/publications/nistir/ir7693/NISTIR-76= 93.pdf

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

--047d7bdc15d015edce050564c905-- From nobody Wed Oct 15 07:12:53 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43FFC1A701F for ; Wed, 15 Oct 2014 07:12:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IrIa4iYaNxcn for ; Wed, 15 Oct 2014 07:12:48 -0700 (PDT) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6D941A6FA8 for ; Wed, 15 Oct 2014 07:12:48 -0700 (PDT) Received: by mail-ob0-f175.google.com with SMTP id wn1so1074369obc.20 for ; Wed, 15 Oct 2014 07:12:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:date:subject:to :message-id:mime-version; bh=RmM1zzN5M5QRFgyp1wP8CjQv8GvRBtdI65MXz/alUoI=; b=Z547+LKIqngixGi9rpg5Vj/6tKNM319qlW2Yjs8cnrwGxRByhQhWRiQjtPK2LfSeGP FHcp6K8c42/h8OKWDzPqci+R9OC1zEmQCJZfFXgUOIRWWN0VtA6NMBwBn/wsVOthi6HO tZGNArPeJ22gR55Z0NcFcAljTxmLXHo+ZhJSM0r+oHP4K/Ba5ai0wYjgeW7cQBZo6Cc2 L5ZAm4SXjPMUy5qD7JS7+XDJcelwEgNRo/ZtnN+vxtUzCeoQa4bdI2YY78dNKe4z6Xa8 p21c2rZEIhK2UrC24oug6prqexozYguBDKHoF4K238SLtHDgWsC4MgV/7LQPvUCPxlUI s46g== X-Received: by 10.60.65.195 with SMTP id z3mr2109312oes.57.1413382368072; Wed, 15 Oct 2014 07:12:48 -0700 (PDT) Received: from ?IPv6:2602:306:3406:4f00:4964:82d0:8b94:f44a? ([2602:306:3406:4f00:4964:82d0:8b94:f44a]) by mx.google.com with ESMTPSA id j8sm11523357oeq.11.2014.10.15.07.12.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 15 Oct 2014 07:12:47 -0700 (PDT) From: "Adam W. Montville" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Wed, 15 Oct 2014 09:12:47 -0500 To: sacm@ietf.org Message-Id: <8280EF2B-3986-463E-A549-B582A8F88F0D@gmail.com> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/5J8XciCtq8fyBDMk9_XOXg4HM2I Subject: [sacm] Comments on draft-ietf-sacm-requirements-01 X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 14:12:50 -0000 Nancy, Nice update to the draft, thank you! =20 I have a few wording changes I would recommend, and I=92m not sure if = you want those now or after the next submission, which would give you = the opportunity to clean things up first (you mentioned cleaning things = up a bit during the last virtual interim). I=92m holding the nits for = now. G-013 (Discovery) mentions the need for discovering the information = that=92s available in the ecosystem, and that may imply that = capabilities are discoverable as well. Should this be made explicit? I = see that it=92s mentioned in ARCH-005, so that may be sufficient. How are REQ-009 and IM-014 different (aside from one being specific to = the information model)? Is there a need to express requirements in terms of real numbers or = otherwise speak to requirements that would affect operations in a given = deployment? For example, if we want to limit network bandwidth = consumption to some throttled level, or if we want to provide the = ability in the architecture to accommodate such throttling, etc. I = don=92t see these types of things mentioned in the requirements = document, and they may turn into something important down the road (some = enterprises would yield terabytes of data each day under certain = circumstances). If things like this fall under one of the existing = architectural requirements, perhaps we should consider how to make that = clear. Finally, do we need additional authors to help build out the information = model requirement descriptions? Regards, Adam From nobody Wed Oct 15 07:30:17 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7432B1A8700 for ; Wed, 15 Oct 2014 07:30:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HQO03u1AoRjh for ; Wed, 15 Oct 2014 07:30:14 -0700 (PDT) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E385B1A7D85 for ; Wed, 15 Oct 2014 07:30:13 -0700 (PDT) Received: by mail-oi0-f41.google.com with SMTP id u20so1037192oif.28 for ; Wed, 15 Oct 2014 07:30:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:date:subject:to:message-id:mime-version; bh=AV/1zu9HoEzLXKTTDnXgLD8lhbkwbb9MPyfDxXeq4pY=; b=qqQMI/StiF/s5Yf1/hmqUH8AZ5TFMa1hn3e7WhNL2PhiWEyDIazbY5CPrAXyxFY8M1 w6emcsBFKWMKdmCDFiFzebFKxi8HiTp/nhTIHeKm6EFdZcXRKYZJvv73pW1E3e/uWIl0 ahT/UBaz9vJ+4Z7r5QjorXd+ibq6tNVu1Ganskf39nNZFjsUqRzKzB6sMCmFYm2ZDwHA 8RinX1fkrCPzCD8/KcW7O9u3lzuisQ+900qn3m3NydysJ+3QGGhXVQCR6MDmGWhGX1w3 ZuYpPC0xc6JJFFRfRiVKmsLb17NU/nq0oKLave7nazEejn7iEpNV2U/Mz1CB4utRapeB hJnw== X-Received: by 10.182.49.198 with SMTP id w6mr11080504obn.43.1413383413360; Wed, 15 Oct 2014 07:30:13 -0700 (PDT) Received: from ?IPv6:2602:306:3406:4f00:4964:82d0:8b94:f44a? ([2602:306:3406:4f00:4964:82d0:8b94:f44a]) by mx.google.com with ESMTPSA id w21sm8409365oie.7.2014.10.15.07.30.12 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 15 Oct 2014 07:30:12 -0700 (PDT) From: "Adam W. Montville" Content-Type: multipart/signed; boundary="Apple-Mail=_FB088ACE-ECA2-4916-A8CD-BE1CE07606EA"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Wed, 15 Oct 2014 09:30:13 -0500 To: sacm@ietf.org Message-Id: Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/wOLwR4D00DqmTpW4IEkJ-mal64E Subject: [sacm] Comments on draft-ietf-sacm-architecture-00 X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 14:30:15 -0000 --Apple-Mail=_FB088ACE-ECA2-4916-A8CD-BE1CE07606EA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Nancy, The following are comments I have about the architecture draft. Again, = holding nits until some later time after additional cleanup has been = performed. I=92m not clear about what=92s being mapped to the SACM Architecture in = Section 3. The reason, I think, is because the draft *is* the SACM = Architecture, but then Section 3 seems to imply that what we=92ve = described is something more than the SACM Architecture when it says: = =93=85the architectural components shown in Figure 1 can be further = refined as=85=94. I=92m confident that we=92ll find confused readers when the draft goes = out for wider review in IESG, apps, etc., but most important, I think = we=92ll find confused readers for the draft=92s consumers (no pun = intended) - those who will read the draft in six months or a year and = try to implement things. How do others feel about this? Adam --Apple-Mail=_FB088ACE-ECA2-4916-A8CD-BE1CE07606EA Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJUPoT1AAoJEILmIVe/2cgG6w0IALSMFdDyVZdsvyySL55nVmIk 6LWpFIlTUAhiI97kHY+lnhprW3PmcD+fzn1L7UdGrR02gg7FJfeUJA1dHqkpnlgX 4U9rjrOYn5SWPyMndrwH0PA5nLaQxN3X9tmo/+lLA5zYBtFgn2IYAVef+oWRDzdV 0eP/nJ0vMUhM39aL9tojmXNp5PtPWdDHjrnFNVJ515rBkbgdR1Cs/DZ/KZd93ZBh /kN1+19Q74LH65JA5hf0vqjYx30nLwftMnvP9gNIU9kehK1WqAuJrdzcaWdpeblD UkFOvxbsh2PcbRcHsFPWr+qIm9/fMx+0f10aqNq7XZ330dWkeeLmjvkf/5lIpwg= =3eZ/ -----END PGP SIGNATURE----- --Apple-Mail=_FB088ACE-ECA2-4916-A8CD-BE1CE07606EA-- From nobody Wed Oct 15 08:08:51 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44F241A8782 for ; Wed, 15 Oct 2014 08:08:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 69CZas7IdswE for ; Wed, 15 Oct 2014 08:08:43 -0700 (PDT) Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C71BD1A87D1 for ; Wed, 15 Oct 2014 08:08:09 -0700 (PDT) Received: by mail-ob0-f170.google.com with SMTP id uz6so1203747obc.1 for ; Wed, 15 Oct 2014 08:08:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:date:subject:to :message-id:mime-version; bh=/wWsn8dnUBH7wWm24skAk6FC/EntqS0mPOV7Uvk7M0Q=; b=HN3B7ZRwQTOM76O3FZhvoFMsjgYFwB6ClV3+lA12P0J8Y4O31cVI/OHUnS9hlCSGJC 31b8ym5oOyk5EkiTJ78W7+yQR5ROJvhKTIWfN7yoxx3l9xuaoOYFC8eUV8sHYc4UfQT+ VKn5u4kHtdzFVPSX93ml4BZZWJoWnkm61flkBVO/hg+710bOMrovwu/tKDAGz71eIHOd XYeHG16n2G7SeCcjTRD7ab+5JQhdqAA3oDEylSz+kD1qmQ0riJ+HWEzPYRKx2x2mzOXy sH3PEr4EiHr/EaXDOrtVqqeAv39zUvxvlj294mHpQb2fx2gYW9gjZ142dFVr9kS36eQb DKlw== X-Received: by 10.182.89.194 with SMTP id bq2mr11421283obb.12.1413385689230; Wed, 15 Oct 2014 08:08:09 -0700 (PDT) Received: from ?IPv6:2602:306:3406:4f00:4964:82d0:8b94:f44a? ([2602:306:3406:4f00:4964:82d0:8b94:f44a]) by mx.google.com with ESMTPSA id ny3sm11682850obc.1.2014.10.15.08.08.08 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 15 Oct 2014 08:08:08 -0700 (PDT) From: "Adam W. Montville" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Wed, 15 Oct 2014 10:08:10 -0500 To: sacm@ietf.org Message-Id: Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/Ec-FsU9HfSeS6hnfG-aLs5Hxzxs Subject: [sacm] Comments on draft-combined-sacm-information-model-00 X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 15:08:46 -0000 Lisa, Below are a few comments on the combined information model draft - these = aren=92t necessarily the only comments I have, but they are those I = think are warranted to make at this point. As with my recent comments = concerning the architecture and requirements drafts, I=92m holding nits = until a later stage. I apologize for not getting these out to the list = sooner, as I did review the draft a few weeks ago. In Section 4.1 there=92s an =93EDITOR=92S NOTE=94 suggesting that the = endpoints to which a given endpoint connects affects its security = posture. So, the logic goes something like this: Endpoint A connects to = endpoint B, therefore endpoint A=92s posture is affected. I assert this = is not true. =20 We have defined posture, based on the definition found in RFC5209, as = =93configuration and/or status of hardware or software on an endpoint as = it pertains to an organization=92s security policy.=94 There is no = mention of connection to other endpoints in this definition. Even if we = wanted to expand the definition, I would argue strongly against, taking = the position that how endpoint B affects endpoint A is in terms of it=92s = risk profile, not it=92s posture. The desired posture for endpoint A = may change based on the posture and/or behavioral characteristics of = endpoint B, but endpoint A=92s posture does not change. In short, I want to avoid bringing this dimension into our present body = of work without precluding the ability in the future. In Section 4.1.3 I=92d encourage consistency of granularity in what we = view as an =93asset". The granularity is pretty intense when you = examine it closely - I=92m not against a fine granularity (quite for it = in fact). On one hand, we=92re being as fine grained as saying that a =93patch=94 = and javascript are examples of software assets (the latter implying that = the Web page containing or referencing that javascript is an asset as = well, and the former possibly implying that the executable installing = the patch is the asset over the patch information itself), and on the = other hand, we=92re conflating assets in the harmful software example of = an =93entertainment app that contains malware.=94 Is it the = entertainment app or the malware that is harmful? If we=92re going to = be as granular as this section is, then I=92d like to be more consistent = so we don=92t run into trouble down the road. In Section 4.7.7 there=92s a nuance we may want to capture. The = non-technical example is a good one. The example is that =93closed=94 = is an attribute of a door, and that a closed door tends to stay closed = until something opens it. I=92d like to be more explicit to say that = =93closed=94 and "open=94 are always attributes of a door, but that they = are either true or false at some point in time, and that they can never = be true at the same time. The attribute itself doesn=92t actually = change, but it=92s state does. So, the previous statement of =93An = attribute tends to stay true until something causes a change=94 isn=92t = exactly right. Instead, the state of an attribute tends to stay true = until something causes a change. Put another way, I don=92t enjoy the = idea of attributes coming and going and would rather have attributes = attached with state information. Finally, I see a lot of off-list discussions reflected in the draft - = discussions I would prefer to see on the list. This is especially true = now that the information model has been adopted (and even though there = is not yet an official WG draft). I understand that there might be a = desire for a few more iterations (at least one more) before we create a = WG submission, but I would much rather prefer on-list communication = about this draft than off-list. Regards, Adam =20 From nobody Wed Oct 15 08:11:32 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51CF41A879A for ; Wed, 15 Oct 2014 08:11:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lYlkY-jLSgZw for ; Wed, 15 Oct 2014 08:11:28 -0700 (PDT) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F6F81A87BE for ; Wed, 15 Oct 2014 08:10:36 -0700 (PDT) Received: by mail-ob0-f175.google.com with SMTP id wn1so1186018obc.20 for ; Wed, 15 Oct 2014 08:10:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:date:subject:to:message-id:mime-version; bh=yJ/w1K8TVTHTjN6eWov+V6cioQ3cNnwEFCEb7VhQaSc=; b=ZTsJJo1c4LCYodmawqsngKA9uEcKFi1YOWRd3Wqyy3aowfozp1wYbdGqk9aT5ztnKR 70yw1p4jOeXwhw/UoGdDf0gnysBx+uM5YaHokE8qN3hs7m51RBzl2uinvCgceoOMo78+ wSJznanfrKjQEANUSlUjdKfTRegNhiippn0HgLXmqZvgwWaSBvDa6L6c7+oLITA0/u+o jWOdDc9u952108lBJSI9EBX7u7P9Xfu7zcFVPNp+fhWEKgLdymBU3dh2/SNTtAkQjELz IcNssZDaPlM9QH5LvsdtBDTRwjcewgHl0K5d9LleG5NAgojPsVgBWrZQ6LeXmm6WvpHJ LuSA== X-Received: by 10.60.173.39 with SMTP id bh7mr11559351oec.32.1413385835529; Wed, 15 Oct 2014 08:10:35 -0700 (PDT) Received: from ?IPv6:2602:306:3406:4f00:4964:82d0:8b94:f44a? ([2602:306:3406:4f00:4964:82d0:8b94:f44a]) by mx.google.com with ESMTPSA id w82sm8464421oiw.27.2014.10.15.08.10.34 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 15 Oct 2014 08:10:34 -0700 (PDT) From: "Adam W. Montville" Content-Type: multipart/signed; boundary="Apple-Mail=_93211D8C-D39C-4184-9A1F-034489242D53"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Wed, 15 Oct 2014 10:10:36 -0500 To: sacm@ietf.org Message-Id: <40F7B859-9106-45D2-8C94-C80AF21CCF40@gmail.com> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/ld7nT_OFTyJuYcNwEjheQLNOduY Subject: [sacm] Issue Tracking X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 15:11:30 -0000 --Apple-Mail=_93211D8C-D39C-4184-9A1F-034489242D53 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 All: We have a lot of work represented in the drafts we have in play, and I = see a lot of comments and conversations inside the drafts - and after = the virtual interim yesterday, it feels like there=92s a lot to manage. Does it make sense for this working group to start leveraging the Trac = system to manage our body of work for each respective draft? I ask the question as a form of encouragement for draft authors/editors = to look at the Trac system as an option for ensuring that the work that = needs to get done gets done. Regards, Adam --Apple-Mail=_93211D8C-D39C-4184-9A1F-034489242D53 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJUPo5sAAoJEILmIVe/2cgGqHEIAJpJM/lEkzc4hu1K4LbspOfu 7LDLD2wVk6GR1lxQwf/fWOXv43V8CyC0bOm9HRTBejF8dWr2zckKCJ1csAkcnXLv DvMBWTxqOF9NfJ2aXqWi0qZ3YMphgGS6OzDcRRahZQmWll+EPovjSuygJAXUL1uU ta81Oq47NRd8qAPnNLjaeuAhxtBZDdMcIF6hXJCGXNUXLYnPyesBM3eZaV3HIUZ6 o4N9dbdKYeRNHrPmNYSFsd1LYcSJQKZqhJpwyRCAiFMHmSlugjmFq+x4/1AJIlFE Tiv3z8YdRuB+h8l5PdHVi3XeExwypFyCCJW1FmGrmyaRFd+que3nmX2T5L1HBdM= =79OP -----END PGP SIGNATURE----- --Apple-Mail=_93211D8C-D39C-4184-9A1F-034489242D53-- From nobody Wed Oct 15 08:48:37 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8466D1A8873 for ; Wed, 15 Oct 2014 08:48:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sgs52JEdo1Kx for ; Wed, 15 Oct 2014 08:48:31 -0700 (PDT) Received: from mail-ob0-x230.google.com (mail-ob0-x230.google.com [IPv6:2607:f8b0:4003:c01::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82ADC1A8862 for ; Wed, 15 Oct 2014 08:48:29 -0700 (PDT) Received: by mail-ob0-f176.google.com with SMTP id m8so1249275obr.21 for ; Wed, 15 Oct 2014 08:48:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:date:references:to:message-id :mime-version; bh=DtjJP5LsphPdW77yes/YdFsjYzH1NLM+RWOGFCCFuaQ=; b=ghlr8Bn+h+IUKOUfRRXg0O0uJ+v0vCUQgB1FsvcZkgoFU37dPybCpQIh3qoZOs6N0E HVBPM+P6wrXwtvf60TZsNXBgkuV/GiYyLENSvwuZmVvUQf0gxaU6Gxu7rhm27xipx9OR RTwHG00D6azuWJrSMeDCOUj/fQ42PrzaMAMbHd6zvPDT0l1neyck5QeS3BbkB0tpPoFH V0mcAhQCGSZu9h1PO+uoAME9K69EEQGbANN+VFCcUtIeoeqytvf259KbJTn6nmzddxgv GC3Qh3+geF6SOmj1R/xW80vjWWa7dYSrB0UIlvLQ/ubzT2VxaYh5BBv2gwc5Es2cPa6j t4zg== X-Received: by 10.202.205.147 with SMTP id d141mr2776873oig.67.1413388108865; Wed, 15 Oct 2014 08:48:28 -0700 (PDT) Received: from [192.168.1.55] (99-64-100-240.lightspeed.austtx.sbcglobal.net. [99.64.100.240]) by mx.google.com with ESMTPSA id mw13sm4333385obb.9.2014.10.15.08.48.27 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 15 Oct 2014 08:48:28 -0700 (PDT) From: "Adam W. Montville" Content-Type: multipart/signed; boundary="Apple-Mail=_7096365E-2F7F-4C47-96F8-2DE19ECA5273"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Wed, 15 Oct 2014 10:48:31 -0500 References: <4A95BA014132FF49AE685FAB4B9F17F645E1298B@dfweml701-chm> To: sacm@ietf.org Message-Id: <73635403-0601-42C4-8262-B1E293AB89B9@gmail.com> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/7wFvlAvoeYa-FZQTRyptTcfgnXw Subject: [sacm] Fwd: [I2nsf] I2NSF BOF request has been approved for IETF 91 in Honolulu. X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 15:48:33 -0000 --Apple-Mail=_7096365E-2F7F-4C47-96F8-2DE19ECA5273 Content-Type: multipart/alternative; boundary="Apple-Mail=_999E96E3-E21E-43D7-9477-460A679DA060" --Apple-Mail=_999E96E3-E21E-43D7-9477-460A679DA060 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 All, this may be of interest to us. Read a bit about the effort and = review the archive here: https://www.ietf.org/mailman/listinfo/i2nsf. On some level, this work is overlapping with what we=92re trying to = achieve in SACM. Abstractly, they=92re seeking to do the same sorts of = things we=92re trying to do. Begin forwarded message: > From: Linda Dunbar > Subject: [I2nsf] I2NSF BOF request has been approved for IETF 91 in = Honolulu. > Date: October 3, 2014 at 10:28:20 AM CDT > To: "I2NSF@ietf.org" > Cc: "Zarny, Myo" >=20 > Dear All, > =20 > Good news: our proposed I2NSF BOF has been approved for IETF 91 in = Honolulu. We requested a non-working forming BOF to focus on use cases, = survey of existing IETF defined schemes that are potential solutions, = and relationship with relevant industry initiatives. =20 > We are seeking proposals for presentations and drafts for the IETF 91 = I2NSF BOF. Here are the area of interests: > =20 > - Use cases for service request and verification from network = operators or 3rd party provided network security functions > - Use cases of integrating of connectivity (e.g. VPN) with = Network Security Functions > - Use cases of 3rd party managed network security functions = for edge network > - Use cases of 3rd party managed network security functions = for subscribers/end-users > - Use cases of data center operators managed network security = functions for tenants > - trust model for 3rd party provided network security = functions > - survey of existing IETF defined schemes that are potential = solutions, > - Current Open NF activities at OpenDayLight, > - Current OpenStack activities on Group Policies, > - Implication of issues/validation associated with = distributed network security functions. For example: distributed virtual = firewall, distributed denial of service (DDoS) attacks, > - etc. > Thank you. > Linda & Myo > =20 > =20 > _______________________________________________ > I2nsf mailing list > I2nsf@ietf.org > https://www.ietf.org/mailman/listinfo/i2nsf --Apple-Mail=_999E96E3-E21E-43D7-9477-460A679DA060 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 All, = this may be of interest to us.  Read a bit about the effort and = review the archive here: https://www.ietf.org/= mailman/listinfo/i2nsf.

On some level, this work = is overlapping with what we=92re trying to achieve in SACM. =  Abstractly, they=92re seeking to do the same sorts of things we=92re= trying to do.

Begin forwarded message:

From: Linda Dunbar <linda.dunbar@huawei.com>
Subject: = [I2nsf] I2NSF BOF = request has been approved for IETF 91 in = Honolulu.
Date: = October 3, 2014 at = 10:28:20 AM CDT
Cc: "Zarny, Myo" <Myo.Zarny@gs.com>
=
Dear = All,
 
Good news: our proposed I2NSF BOF has been = approved for IETF 91 in Honolulu. We requested a non-working forming BOF = to focus on use cases, survey of existing IETF defined schemes that are = potential solutions, and relationship with relevant industry = initiatives.   
We are = seeking proposals for presentations and drafts for the IETF 91 I2NSF = BOF. Here are the area of interests:
 
-          Use cases for service = request and verification from network operators or 3rd party provided network = security functions
-          Use cases of = integrating of connectivity (e.g. VPN) with Network Security = Functions
-          Use cases of = 3rd party = managed network security functions for edge = network
-          Use cases of = 3rd party = managed network security functions for = subscribers/end-users
-          Use cases of data = center operators managed network security functions for = tenants
-          trust model for = 3rd party = provided network security functions
-          survey = of existing IETF defined schemes that are potential solutions,
-          Current = Open NF activities at OpenDayLight,
-          Current = OpenStack activities on Group Policies,
-          Implication of = issues/validation associated with distributed network security = functions. For example: distributed virtual firewall, distributed denial = of service (DDoS) attacks,
-          etc.
Thank you.
Linda & Myo
 
 
________________________________= _______________
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf

= --Apple-Mail=_999E96E3-E21E-43D7-9477-460A679DA060-- --Apple-Mail=_7096365E-2F7F-4C47-96F8-2DE19ECA5273 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJUPpdPAAoJEILmIVe/2cgGm3MH/jyMXOz2jVRGZqjNLLQaHBss ySrIFW5cBhE/lLwKMJgcyddXsj/FF05QeIR0GipMkyfMe32JNrQIQn2QJbmapkfP 567U/7HD/cRtWXBZw02Gac948sMUpiCki3LBLeRgUWknznY5g8AlY0fL3DJnTQZB 5hTD7bGxPm6wP3UlFvF0JzoQgPXaX1YTZg1HYLoTo8myIx1b9znK+zLh0lrsY8Bp vlPjZSf3qfXDhEh72aPZYWELfpHK4RHXhPNX+zz6hhIp01ZKk4m6+kIl7QgxM1lG vxRcOfNb+KjQ+mm3Oez83SbzMJA1bT0Wrhq6zUHmKhukp+7J/UA4PvRcRGxOSTY= =itUC -----END PGP SIGNATURE----- --Apple-Mail=_7096365E-2F7F-4C47-96F8-2DE19ECA5273-- From nobody Wed Oct 15 21:10:45 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38F741A0169 for ; Wed, 15 Oct 2014 21:10:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N4EScnPWEzSt for ; Wed, 15 Oct 2014 21:10:41 -0700 (PDT) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F8CB1A0164 for ; Wed, 15 Oct 2014 21:10:41 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id b6so2161303lbj.3 for ; Wed, 15 Oct 2014 21:10:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=YRYHmqHqrUJIRs/4pZIkG4RhSRH5cpGnUE7GtKoeT50=; b=UAOZ9O3gFWv2lmAe8J7n79L6uUcII99B4t2Og2WgnPziS+UrTDz0GUR/tiG7hJY99P 79efgbD0bTjywMZChUUaTXYE71DlJtaFLQ8hdRvBz6uiUCqZu3MoPG6yNgmYqj9X8M9y oePAIErzwfPp3CLn6IeugfBnBaxBw4WGvypHa4am+/NWd5rqPRvtHrP1NR9jGvI6L/oV HoqKAjZtJopP2UpcRGajIDzp4pDd7/QvCtvq8Kz5/kqpuHoVH6vIu1204Wt6V9lRzdD2 Qz7FPdXpaE1SdW/GoxDVXAMG6A3Fs8yVuO61xbors4aEcsDYz3jh85F/BFegPKpLChxi sc6w== MIME-Version: 1.0 X-Received: by 10.152.120.73 with SMTP id la9mr16696605lab.23.1413432639646; Wed, 15 Oct 2014 21:10:39 -0700 (PDT) Received: by 10.25.143.203 with HTTP; Wed, 15 Oct 2014 21:10:39 -0700 (PDT) Date: Thu, 16 Oct 2014 10:10:39 +0600 Message-ID: From: Fahima Ahmed Khan Etha To: sacm@ietf.org Content-Type: multipart/alternative; boundary=089e011766e56674060505826e42 Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/qNTtwzNvE19LIuSUGRzoh9JyxpU Subject: [sacm] How to know if you are really hacked or not X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 04:10:44 -0000 --089e011766e56674060505826e42 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear All, It might be an off topic. But I am seeking guidance from all of you. If any hacker group claimed that you are hacked... How to proof or find out its authenticity? Please share your view. Best regards, Fahima On 15 October 2014 21:08, Adam W. Montville wrote: > Lisa, > > Below are a few comments on the combined information model draft - these > aren=E2=80=99t necessarily the only comments I have, but they are those I= think are > warranted to make at this point. As with my recent comments concerning t= he > architecture and requirements drafts, I=E2=80=99m holding nits until a la= ter > stage. I apologize for not getting these out to the list sooner, as I di= d > review the draft a few weeks ago. > > In Section 4.1 there=E2=80=99s an =E2=80=9CEDITOR=E2=80=99S NOTE=E2=80=9D= suggesting that the endpoints to > which a given endpoint connects affects its security posture. So, the > logic goes something like this: Endpoint A connects to endpoint B, > therefore endpoint A=E2=80=99s posture is affected. I assert this is not= true. > > We have defined posture, based on the definition found in RFC5209, as > =E2=80=9Cconfiguration and/or status of hardware or software on an endpoi= nt as it > pertains to an organization=E2=80=99s security policy.=E2=80=9D There is= no mention of > connection to other endpoints in this definition. Even if we wanted to > expand the definition, I would argue strongly against, taking the positio= n > that how endpoint B affects endpoint A is in terms of it=E2=80=99s risk p= rofile, > not it=E2=80=99s posture. The desired posture for endpoint A may change = based on > the posture and/or behavioral characteristics of endpoint B, but endpoint > A=E2=80=99s posture does not change. > > In short, I want to avoid bringing this dimension into our present body o= f > work without precluding the ability in the future. > > In Section 4.1.3 I=E2=80=99d encourage consistency of granularity in what= we view > as an =E2=80=9Casset". The granularity is pretty intense when you examin= e it > closely - I=E2=80=99m not against a fine granularity (quite for it in fac= t). > > On one hand, we=E2=80=99re being as fine grained as saying that a =E2=80= =9Cpatch=E2=80=9D and > javascript are examples of software assets (the latter implying that the > Web page containing or referencing that javascript is an asset as well, a= nd > the former possibly implying that the executable installing the patch is > the asset over the patch information itself), and on the other hand, we= =E2=80=99re > conflating assets in the harmful software example of an =E2=80=9Centertai= nment app > that contains malware.=E2=80=9D Is it the entertainment app or the malwa= re that is > harmful? If we=E2=80=99re going to be as granular as this section is, th= en I=E2=80=99d > like to be more consistent so we don=E2=80=99t run into trouble down the = road. > > In Section 4.7.7 there=E2=80=99s a nuance we may want to capture. The > non-technical example is a good one. The example is that =E2=80=9Cclosed= =E2=80=9D is an > attribute of a door, and that a closed door tends to stay closed until > something opens it. I=E2=80=99d like to be more explicit to say that =E2= =80=9Cclosed=E2=80=9D and > "open=E2=80=9D are always attributes of a door, but that they are either = true or > false at some point in time, and that they can never be true at the same > time. The attribute itself doesn=E2=80=99t actually change, but it=E2=80= =99s state does. > So, the previous statement of =E2=80=9CAn attribute tends to stay true un= til > something causes a change=E2=80=9D isn=E2=80=99t exactly right. Instead,= the state of an > attribute tends to stay true until something causes a change. Put anothe= r > way, I don=E2=80=99t enjoy the idea of attributes coming and going and wo= uld rather > have attributes attached with state information. > > Finally, I see a lot of off-list discussions reflected in the draft - > discussions I would prefer to see on the list. This is especially true n= ow > that the information model has been adopted (and even though there is not > yet an official WG draft). I understand that there might be a desire for= a > few more iterations (at least one more) before we create a WG submission, > but I would much rather prefer on-list communication about this draft tha= n > off-list. > > Regards, > > Adam > > > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > --089e011766e56674060505826e42 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Dear All,

It might be an off topic. But I am seeking guidance from all of you.

If any hacker group claimed that you are hacked... How to proof or find out its authenticity?

Please share your view.

= Best regards,

Fahima


On 15 October 201= 4 21:08, Adam W. Montville <adam.w.montville@gmail.com> wrote:
Lisa,

Below are a few comments on the combined information model draft - these ar= en=E2=80=99t necessarily the only comments I have, but they are those I thi= nk are warranted to make at this point.=C2=A0 As with my recent comments co= ncerning the architecture and requirements drafts, I=E2=80=99m holding nits= until a later stage.=C2=A0 I apologize for not getting these out to the li= st sooner, as I did review the draft a few weeks ago.

In Section 4.1 there=E2=80=99s an =E2=80=9CEDITOR=E2=80=99S NOTE=E2=80=9D s= uggesting that the endpoints to which a given endpoint connects affects its= security posture.=C2=A0 So, the logic goes something like this: Endpoint A= connects to endpoint B, therefore endpoint A=E2=80=99s posture is affected= .=C2=A0 I assert this is not true.

We have defined posture, based on the definition found in RFC5209, as =E2= =80=9Cconfiguration and/or status of hardware or software on an endpoint as= it pertains to an organization=E2=80=99s security policy.=E2=80=9D=C2=A0 T= here is no mention of connection to other endpoints in this definition.=C2= =A0 Even if we wanted to expand the definition, I would argue strongly agai= nst, taking the position that how endpoint B affects endpoint A is in terms= of it=E2=80=99s risk profile, not it=E2=80=99s posture.=C2=A0 The desired = posture for endpoint A may change based on the posture and/or behavioral ch= aracteristics of endpoint B, but endpoint A=E2=80=99s posture does not chan= ge.

In short, I want to avoid bringing this dimension into our present body of = work without precluding the ability in the future.

In Section 4.1.3 I=E2=80=99d encourage consistency of granularity in what w= e view as an =E2=80=9Casset".=C2=A0 The granularity is pretty intense = when you examine it closely - I=E2=80=99m not against a fine granularity (q= uite for it in fact).

On one hand, we=E2=80=99re being as fine grained as saying that a =E2=80=9C= patch=E2=80=9D and javascript are examples of software assets (the latter i= mplying that the Web page containing or referencing that javascript is an a= sset as well, and the former possibly implying that the executable installi= ng the patch is the asset over the patch information itself), and on the ot= her hand, we=E2=80=99re conflating assets in the harmful software example o= f an =E2=80=9Centertainment app that contains malware.=E2=80=9D=C2=A0 Is it= the entertainment app or the malware that is harmful?=C2=A0 If we=E2=80=99= re going to be as granular as this section is, then I=E2=80=99d like to be = more consistent so we don=E2=80=99t run into trouble down the road.

In Section 4.7.7 there=E2=80=99s a nuance we may want to capture.=C2=A0 The= non-technical example is a good one.=C2=A0 The example is that =E2=80=9Ccl= osed=E2=80=9D is an attribute of a door, and that a closed door tends to st= ay closed until something opens it.=C2=A0 I=E2=80=99d like to be more expli= cit to say that =E2=80=9Cclosed=E2=80=9D and "open=E2=80=9D are always= attributes of a door, but that they are either true or false at some point= in time, and that they can never be true at the same time.=C2=A0 The attri= bute itself doesn=E2=80=99t actually change, but it=E2=80=99s state does.= =C2=A0 So, the previous statement of =E2=80=9CAn attribute tends to stay tr= ue until something causes a change=E2=80=9D isn=E2=80=99t exactly right.=C2= =A0 Instead, the state of an attribute tends to stay true until something c= auses a change.=C2=A0 Put another way, I don=E2=80=99t enjoy the idea of at= tributes coming and going and would rather have attributes attached with st= ate information.

Finally, I see a lot of off-list discussions reflected in the draft - discu= ssions I would prefer to see on the list.=C2=A0 This is especially true now= that the information model has been adopted (and even though there is not = yet an official WG draft).=C2=A0 I understand that there might be a desire = for a few more iterations (at least one more) before we create a WG submiss= ion, but I would much rather prefer on-list communication about this draft = than off-list.

Regards,

Adam



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

--089e011766e56674060505826e42-- From nobody Thu Oct 16 04:30:05 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9929D1AD062 for ; Thu, 16 Oct 2014 04:30:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ybj-KpZQebT for ; Thu, 16 Oct 2014 04:30:02 -0700 (PDT) Received: from mail-qg0-x232.google.com (mail-qg0-x232.google.com [IPv6:2607:f8b0:400d:c04::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3EFB1AD061 for ; Thu, 16 Oct 2014 04:30:01 -0700 (PDT) Received: by mail-qg0-f50.google.com with SMTP id q108so2282573qgd.23 for ; Thu, 16 Oct 2014 04:30:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=e3Z9jgMXI2hJVIKPAbgcWUwkfFdr/LkG6KBL7TkC4jg=; b=Tuxrmrs3f92bYruJNsK6UltYYgwRb7TBaMIMkp9TBI/sJ1HVRxpetm2YRRV1KOREci oWpjv6Kw9Eh+sBG6jBJurx9UICGyGwHiqxKiVthUgsBpjp/tQeprNenBukjLFmJEMoQR E3RM7igNdJfQuSd0i67I8kYIe1rxIWS3AMlgsUb3d+lD6nC1Ellk5//MQoaKnPeSl1ZC YdusJodLWrllr0H6RgyVkvAcXYXpnOgwzs7SVH+S0t4Lzb2WsZHOXAK75UIKB4+NjErl mhUJ/1wTYsOYLB3pIDqt3rwC9AzTiEmshJbjOjPO7JsbfklbLNB8Lo1yO9wWJTLcIh6h Jlwg== X-Received: by 10.224.22.17 with SMTP id l17mr1111368qab.56.1413459001018; Thu, 16 Oct 2014 04:30:01 -0700 (PDT) Received: from [192.168.1.3] (209-6-114-252.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.114.252]) by mx.google.com with ESMTPSA id w6sm20743445qas.26.2014.10.16.04.29.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 16 Oct 2014 04:29:59 -0700 (PDT) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: multipart/alternative; boundary=Apple-Mail-46FCCF4D-3D39-46CF-8E51-090707F939FE Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (11D257) In-Reply-To: Date: Thu, 16 Oct 2014 07:29:59 -0400 Content-Transfer-Encoding: 7bit Message-Id: <38CC2084-96C4-4CB9-A0C6-2E444340D96E@gmail.com> References: To: Fahima Ahmed Khan Etha Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/4yzSzkbWQrYCX_ft4JkF0S8DHNc Cc: "sacm@ietf.org" Subject: Re: [sacm] How to know if you are really hacked or not X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 11:30:04 -0000 --Apple-Mail-46FCCF4D-3D39-46CF-8E51-090707F939FE Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable If interested in this discussion, let's respond on the SAAG list and not acr= oss all lists. Thank you, Kathleen Sent from my iPhone > On Oct 16, 2014, at 12:10 AM, Fahima Ahmed Khan Etha wr= ote: >=20 > Dear All, >=20 > It might be an off topic. But I am seeking guidance from all of you. >=20 > If any hacker group claimed that you are hacked... How to proof or find ou= t its authenticity? >=20 > Please share your view. >=20 > Best regards, > Fahima >=20 >=20 >> On 15 October 2014 21:08, Adam W. Montville w= rote: >> Lisa, >>=20 >> Below are a few comments on the combined information model draft - these a= ren=E2=80=99t necessarily the only comments I have, but they are those I thi= nk are warranted to make at this point. As with my recent comments concerni= ng the architecture and requirements drafts, I=E2=80=99m holding nits until a= later stage. I apologize for not getting these out to the list sooner, as I= did review the draft a few weeks ago. >>=20 >> In Section 4.1 there=E2=80=99s an =E2=80=9CEDITOR=E2=80=99S NOTE=E2=80=9D= suggesting that the endpoints to which a given endpoint connects affects it= s security posture. So, the logic goes something like this: Endpoint A conn= ects to endpoint B, therefore endpoint A=E2=80=99s posture is affected. I a= ssert this is not true. >>=20 >> We have defined posture, based on the definition found in RFC5209, as =E2= =80=9Cconfiguration and/or status of hardware or software on an endpoint as i= t pertains to an organization=E2=80=99s security policy.=E2=80=9D There is n= o mention of connection to other endpoints in this definition. Even if we w= anted to expand the definition, I would argue strongly against, taking the p= osition that how endpoint B affects endpoint A is in terms of it=E2=80=99s r= isk profile, not it=E2=80=99s posture. The desired posture for endpoint A m= ay change based on the posture and/or behavioral characteristics of endpoint= B, but endpoint A=E2=80=99s posture does not change. >>=20 >> In short, I want to avoid bringing this dimension into our present body o= f work without precluding the ability in the future. >>=20 >> In Section 4.1.3 I=E2=80=99d encourage consistency of granularity in what= we view as an =E2=80=9Casset". The granularity is pretty intense when you e= xamine it closely - I=E2=80=99m not against a fine granularity (quite for it= in fact). >>=20 >> On one hand, we=E2=80=99re being as fine grained as saying that a =E2=80=9C= patch=E2=80=9D and javascript are examples of software assets (the latter im= plying that the Web page containing or referencing that javascript is an ass= et as well, and the former possibly implying that the executable installing t= he patch is the asset over the patch information itself), and on the other h= and, we=E2=80=99re conflating assets in the harmful software example of an =E2= =80=9Centertainment app that contains malware.=E2=80=9D Is it the entertain= ment app or the malware that is harmful? If we=E2=80=99re going to be as gr= anular as this section is, then I=E2=80=99d like to be more consistent so we= don=E2=80=99t run into trouble down the road. >>=20 >> In Section 4.7.7 there=E2=80=99s a nuance we may want to capture. The no= n-technical example is a good one. The example is that =E2=80=9Cclosed=E2=80= =9D is an attribute of a door, and that a closed door tends to stay closed u= ntil something opens it. I=E2=80=99d like to be more explicit to say that =E2= =80=9Cclosed=E2=80=9D and "open=E2=80=9D are always attributes of a door, bu= t that they are either true or false at some point in time, and that they ca= n never be true at the same time. The attribute itself doesn=E2=80=99t actu= ally change, but it=E2=80=99s state does. So, the previous statement of =E2= =80=9CAn attribute tends to stay true until something causes a change=E2=80=9D= isn=E2=80=99t exactly right. Instead, the state of an attribute tends to s= tay true until something causes a change. Put another way, I don=E2=80=99t e= njoy the idea of attributes coming and going and would rather have attribute= s attached with state information. >>=20 >> Finally, I see a lot of off-list discussions reflected in the draft - dis= cussions I would prefer to see on the list. This is especially true now tha= t the information model has been adopted (and even though there is not yet a= n official WG draft). I understand that there might be a desire for a few m= ore iterations (at least one more) before we create a WG submission, but I w= ould much rather prefer on-list communication about this draft than off-list= . >>=20 >> Regards, >>=20 >> Adam >>=20 >>=20 >>=20 >> _______________________________________________ >> 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 --Apple-Mail-46FCCF4D-3D39-46CF-8E51-090707F939FE Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
If interested in this discussion, let'= s respond on the SAAG list and not across all lists.

Thank you,
Kathleen

Sent from my iPhone

On O= ct 16, 2014, at 12:10 AM, Fahima Ahmed Khan Etha <etha4u@gmail.com> wrote:

Dear All,

It might be an off topic. But I am seeking guidance from all of you.

If any hacker group claimed that you are hacked... How to proof or find out its authenticity?

Please share your view.

<= span style=3D"font-size:12pt;font-family:"Times New Roman","s= erif"">Best regards,

Fahima


On 15 October 2014= 21:08, Adam W. Montville <adam.w.montville@gmail.com> wrote:
Lisa,

Below are a few comments on the combined information model draft - these are= n=E2=80=99t necessarily the only comments I have, but they are those I think= are warranted to make at this point.  As with my recent comments conce= rning the architecture and requirements drafts, I=E2=80=99m holding nits unt= il a later stage.  I apologize for not getting these out to the list so= oner, as I did review the draft a few weeks ago.

In Section 4.1 there=E2=80=99s an =E2=80=9CEDITOR=E2=80=99S NOTE=E2=80=9D su= ggesting that the endpoints to which a given endpoint connects affects its s= ecurity posture.  So, the logic goes something like this: Endpoint A co= nnects to endpoint B, therefore endpoint A=E2=80=99s posture is affected.&nb= sp; I assert this is not true.

We have defined posture, based on the definition found in RFC5209, as =E2=80= =9Cconfiguration and/or status of hardware or software on an endpoint as it p= ertains to an organization=E2=80=99s security policy.=E2=80=9D  There i= s no mention of connection to other endpoints in this definition.  Even= if we wanted to expand the definition, I would argue strongly against, taki= ng the position that how endpoint B affects endpoint A is in terms of it=E2=80= =99s risk profile, not it=E2=80=99s posture.  The desired posture for e= ndpoint A may change based on the posture and/or behavioral characteristics o= f endpoint B, but endpoint A=E2=80=99s posture does not change.

In short, I want to avoid bringing this dimension into our present body of w= ork without precluding the ability in the future.

In Section 4.1.3 I=E2=80=99d encourage consistency of granularity in what we= view as an =E2=80=9Casset".  The granularity is pretty intense when yo= u examine it closely - I=E2=80=99m not against a fine granularity (quite for= it in fact).

On one hand, we=E2=80=99re being as fine grained as saying that a =E2=80=9Cp= atch=E2=80=9D and javascript are examples of software assets (the latter imp= lying that the Web page containing or referencing that javascript is an asse= t as well, and the former possibly implying that the executable installing t= he patch is the asset over the patch information itself), and on the other h= and, we=E2=80=99re conflating assets in the harmful software example of an =E2= =80=9Centertainment app that contains malware.=E2=80=9D  Is it the ente= rtainment app or the malware that is harmful?  If we=E2=80=99re going t= o be as granular as this section is, then I=E2=80=99d like to be more consis= tent so we don=E2=80=99t run into trouble down the road.

In Section 4.7.7 there=E2=80=99s a nuance we may want to capture.  The n= on-technical example is a good one.  The example is that =E2=80=9Cclose= d=E2=80=9D is an attribute of a door, and that a closed door tends to stay c= losed until something opens it.  I=E2=80=99d like to be more explicit t= o say that =E2=80=9Cclosed=E2=80=9D and "open=E2=80=9D are always attributes= of a door, but that they are either true or false at some point in time, an= d that they can never be true at the same time.  The attribute itself d= oesn=E2=80=99t actually change, but it=E2=80=99s state does.  So, the p= revious statement of =E2=80=9CAn attribute tends to stay true until somethin= g causes a change=E2=80=9D isn=E2=80=99t exactly right.  Instead, the s= tate of an attribute tends to stay true until something causes a change.&nbs= p; Put another way, I don=E2=80=99t enjoy the idea of attributes coming and g= oing and would rather have attributes attached with state information.

Finally, I see a lot of off-list discussions reflected in the draft - discus= sions I would prefer to see on the list.  This is especially true now t= hat the information model has been adopted (and even though there is not yet= an official WG draft).  I understand that there might be a desire for a= few more iterations (at least one more) before we create a WG submission, b= ut I would much rather prefer on-list communication about this draft than of= f-list.

Regards,

Adam



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

____________________= ___________________________
sacm mailing list
sacm@ietf.org
https://www.ietf.org/mailman= /listinfo/sacm
= --Apple-Mail-46FCCF4D-3D39-46CF-8E51-090707F939FE-- From nobody Fri Oct 17 20:18:38 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7B2D1A011E for ; Fri, 17 Oct 2014 20:18:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cQiWpbW0fH89 for ; Fri, 17 Oct 2014 20:18:33 -0700 (PDT) Received: from plainfield.sei.cmu.edu (plainfield.sei.cmu.edu [192.58.107.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1B951A0103 for ; Fri, 17 Oct 2014 20:18:33 -0700 (PDT) Received: from timber.sei.cmu.edu (timber.sei.cmu.edu [10.64.21.23]) by plainfield.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id s9I3IWVH027902 for ; Fri, 17 Oct 2014 23:18:32 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1413602312; bh=8ZyikytNWuG1Mcux2s1hCFrvoJR3Ypx4BD+r/8H8ojI=; h=From:To:Subject:Date:Message-ID:Content-Type:Content-ID: Content-Transfer-Encoding:MIME-Version:Sender:Reply-To:Cc: In-Reply-To:References; b=JWa+mf+SC8AWAs2kiuoHyC+2DQwpv45zNHS+RoYIJDsqVeq55fxA1dJZO3W0vTFwG V2hFhaeuzOBazxRH7D8O0exmW9uBuqz1NeJiL2e0mfjO8/Er4DjtxOWi2VAtuCaca4 PttsUgcL/YrJIKCg/OtCXPf1IQ94xvoKcf91Oy58= Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by timber.sei.cmu.edu (8.14.4/8.14.4/1456) with ESMTP id s9I3I62c020290 for ; Fri, 17 Oct 2014 23:18:06 -0400 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.02.0347.000; Fri, 17 Oct 2014 23:18:06 -0400 From: Chris Inacio To: "sacm@ietf.org" Thread-Topic: Review of draft-ietf-sacm-requirements-01 Thread-Index: AQHP6oIhhPwCy40tBUmyTonEaR/dvA== Date: Sat, 18 Oct 2014 03:18:05 +0000 Message-ID: <8FE2AE53-743C-4042-912A-E036411F0508@cert.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.96.32] Content-Type: text/plain; charset="Windows-1252" Content-ID: <935B0D919B6EF84D895D410CD417ACBF@sei.cmu.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/QVHbQgtRv4A-kvdzPUcpG4UazjU Subject: [sacm] Review of draft-ietf-sacm-requirements-01 X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Oct 2014 03:18:37 -0000 I did a detailed reading of the draft and have a bunch of comments. But I = will start with high level impressions first. The draft starts really strong in the requirements, but tails off towards t= he end - the requirements aren=92t as well developed or clear. Where it is= clear that Nancy has spent some time capturing solid requirements, I would= like to say kudos to her - she=92s captured a lot of details in a relative= ly short amount of text and actually made me think about the overall archit= ecture in some new ways. I would ask for a more careful usage of MUST, SHOULD, MAY. I would like to= think of the requirements in terms of =93absolutely have to have=94 =3D> M= UST and =93desirable to have=94 =3D> SHOULD or MAY, depending. It isn=92t = clear to me, entirely, that everything isn=92t intended to be a MUST, in wh= ich case, maybe this isn=92t a useful comment. But I think there might be = some room in some of the requirements for leeway. More detailed comments: Section 2.1 Should you create a 2.1 =93Introduction=94 section for the text preceding= requirement G-001? While I don=92t believe that the text in the list 1-5 = are requirements, maybe we should be crystal clear on that. Then 2.2 would be the =93General Requirements=94 section. G-001 - I really want this split into 3 subsections of requirements,=20 * transport=20 * info model * query lang It=92s beast of a requirement as it stands now. Also, I=92m not excited b= y the =93allow support for non-standard and future extensions=94. I find i= t peculiar that a SDO would be requiring the development of a standard to a= llow for non-standards to be included in the standards. (In the future, I = will create a sentence with more uses of the word =93standard=94. :) ) G-003 - remove the final =93defined=94 in the paragraph. G-004 - reword: =93=85 protocols, transports are suitable to implementatio= ns are suitable to fit in =85=94 Maybe something like: =93that the data m= odel, protocols, and transports are suitably implemented to fit into the di= fferent deployment models and scenarios.=94 G-006 / GN-005: =93mandatory to implement data attributes=94 =3D> needs to= be changed to get rid of "data attributes=94 or we need to establish what = this means in terms of the requirements doc. I=92m fairly certain I unders= tand it, but if you ask me while/after building a sacm compliant implementa= tion if that is met, I don=92t think I=92ll know. We might really mean tha= t the info model must have a set of IEs that will be mandatory to implement= in all data models, and systems that support multiple data models must sup= port the ability to transparently exchange all mandatory to implement IE=92= s across all DM=92s. (But we didn=92t say that. :) ) REQ-002: Does this imply accepting multiple data models (& info models?) i= n the =93SACM protocol=94? Does this imply how much of SACM is a metaproto= col, possibly? Is SACM possibly a way to negotiate various disparate proto= cols (capabilities & versions) and maybe a query / response protocol? I th= ink this requirement creates FAR reaching implications. How does this requi= rement fit with G-006 / GN-005 which requires an explicit set of mandatory = to implement data attributes? REQ-006: =93The query operation may be a synchronous or asynchronous reques= t.=94 First, an IETF comment, is that =93may=94 a =93MAY=94? From an impl= ementors point of view: OUCH. I would really prefer you pick one or both, = but settle that THE PROTOCOL/STANDARD *MUST* support some set, but IMPLEMEN= TATIONS *MAY* choose and negotiate. If you don=92t choose, just remove the= line from the requirements, it doesn=92t help anyone in the future as it s= tands now. REQ-009: I actually don=92t understand that requirement. ARCH-001: A little caution on the sizes used, if concrete numbers are real= ly desired. If sacm is deployed at Ft. Bragg in the US, it=92s human popul= ation is 238,646 [http://www.army-technology.com/features/feature-largest-m= ilitary-bases-world-united-states/]. If each of those folks has a cell pho= ne, a desktop, and 1-2 other devices we=92re in the millions. If Ft. Bragg= implements something like an IoT and manages it with sacm, then I think th= at number gets a whole lot higher. I=92m pretty sure that all the planes, = helicopters, etc. probably have *at least* 1 IP address each. ARCH-004: =93systems can utilize an already established mutually agreed up= on native data format, which may be standard or implementation-specific=94.= I understand why one might want that statement there, but it should be dr= opped. (1) No one meeting in the sacm room could ever prevent this from ha= ppening if they wanted to (2) putting this in the requirements doesn=92t he= lp the design of the IM, DM, or any other protocols or operations. IM-009: Please expand the text. (Lisa, I know you explained this, verball= y, already, but it needs to be written down.) IM-011: remove =93- for example=94. The follow on text is either a requir= ement or not. IM-014: Does this imply that using sacm protocols the sensors/agents can b= e configured via a sacm initiated request? IM-015: Does this imply something like a simple calculus that lets me logi= cal / arithmetically / statistically define new =93virtual=94 readings from= actual readings? Does this language have to be supported at every sensor/= agent? Also, we need a firm definition on the =93point of collection=94. T-002: Reword please. I take it to mean the following: =93Data Integrity:= For protocols which do not provide for data integrity in the transport lay= er, a sufficient data integrity mechanism MUST be provided." Security Considerations: I really like this section, especially as someone= who (in theory at least) does reviews for the security directorate. BUT (= you knew it was coming,) shouldn=92t the last 3 paragraphs in the security = considerations section actually be requirements?, say SEC-001, SEC-002, SEC= -003? :) I hope this helps. And I=92ll see if I can plow through the info model thi= s weekend. Chris From nobody Mon Oct 20 08:17:05 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9A041A016B for ; Mon, 20 Oct 2014 08:17:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Va_9XQzkneNO for ; Mon, 20 Oct 2014 08:17:01 -0700 (PDT) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C4B11A8F50 for ; Mon, 20 Oct 2014 07:59:57 -0700 (PDT) Received: by mail-oi0-f49.google.com with SMTP id a3so3764392oib.36 for ; Mon, 20 Oct 2014 07:59:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:date:subject:to:message-id:mime-version; bh=iRiYvL1xvNRibJ2kqv37lwXntfjBrwHvkCfiLTWqFL4=; b=ZIDD3cN/3/1iCgmib4SuZTCweudq5tiUD+Zz2/WthitewyhYBz/dt0Xo41LdsH00G+ ZmHVshfyk5c7gf8J5Kudq63qNperFpzNqt5CZhN9UFmDSG9tU/casyg9FeBPN4PBhMjT llqC5csAShaB/V54P+nuu1cFlv+YXzILoAfGCbLfdPZzAOt7O4MnSejPQaS5EFMRdqEy 5hRj2UX+Za+7IMJp1AKN0zb/WGov25bksq7S2lYZzj9HxP8ClAUJjM73ZH+axIesIqpr eYmkCxUefbamBIaBsiWotXbwb212kxHnYN4Pkh6XLtYVzUUPbgHlMDeemvobbGhg6nCh Q0yg== X-Received: by 10.60.57.41 with SMTP id f9mr23455693oeq.17.1413817196649; Mon, 20 Oct 2014 07:59:56 -0700 (PDT) Received: from ?IPv6:2602:306:3406:4f00:a1fc:27cf:5922:ac35? ([2602:306:3406:4f00:a1fc:27cf:5922:ac35]) by mx.google.com with ESMTPSA id n2sm3961151oel.17.2014.10.20.07.59.55 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 20 Oct 2014 07:59:56 -0700 (PDT) From: "Adam W. Montville" Content-Type: multipart/alternative; boundary="Apple-Mail=_175742BF-F33A-41EE-B9CD-D61D58031B55" Date: Mon, 20 Oct 2014 09:59:54 -0500 To: sacm@ietf.org Message-Id: <57D79B91-35B9-46D8-BBD5-00EFCCBA29CD@gmail.com> Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/jUgRjbRY-ATl9yyU1U3p7Pa1M9s Subject: [sacm] Call for Review and Commentary for Upcoming Draft Submissions X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 15:17:03 -0000 --Apple-Mail=_175742BF-F33A-41EE-B9CD-D61D58031B55 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 All: I hope you had a good weekend! I originally tried to post this directly to authors using the IETF = tools, but each was sent back as undeliverable, so I=E2=80=99m posting = here instead=E2=80=A6. I thought I'd reach out to see whether there has been enough (any?) = review for the documents we need submissions on by 10/27. I know that I = provided some feedback on each of the drafts, and Chris has provided = feedback on the requirements document. Are you confident that your draft(s) update will be submitted in one = week? For those of you who have not yet reviewed the drafts and provided = comments, please do so. All the documents can be found here: = http://datatracker.ietf.org/wg/sacm/documents/ = Regards, Adam= --Apple-Mail=_175742BF-F33A-41EE-B9CD-D61D58031B55 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 All:

I hope you had a good = weekend!

I = originally tried to post this directly to authors using the IETF tools, = but each was sent back as undeliverable, so I=E2=80=99m posting here = instead=E2=80=A6.

I thought I'd reach out = to see whether there has been enough (any?) review for the documents we = need submissions on by 10/27.  I know that I provided some feedback = on each of the drafts, and Chris has provided feedback on the = requirements document.

Are you confident = that your draft(s) update will be submitted in one week?

For those of you who = have not yet reviewed the drafts and provided comments, please do so. =  All the documents can be found here: http://datatracker.ietf.org/wg/sacm/documents/

Regards,

Adam
= --Apple-Mail=_175742BF-F33A-41EE-B9CD-D61D58031B55-- From nobody Mon Oct 20 10:26:57 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0366C1A8771 for ; Mon, 20 Oct 2014 10:26:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K0fMzvk8Ui5h for ; Mon, 20 Oct 2014 10:26:45 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B47F11A8780 for ; Mon, 20 Oct 2014 10:26:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3216; q=dns/txt; s=iport; t=1413826005; x=1415035605; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=rdjoYxl7KDa4n/m0w9W3QwoPP0Ey8KrGFwoDUhr7U+0=; b=JTmX7sjA1hu1yHZb0+VBYy84ZCBTmhMTLhxBoizSxbVFx8b4kJieAK8g EVa1jQmAstTjnoQsw3OrcO15M1nZGiFp8C4ny52PR862kuE051ebQugn7 YDotSjdNBu8ksiD3z1DC8/9M8DCVxFKSujUKlu3ynjsVZpLN4NH3+Nb4o c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFAMVERVStJV2d/2dsb2JhbABcgmsjU1gEzCEKh00CgRMWAX2EAwEBBAEBAWsdAQgSVQYLFw4CBAESiCsDEQEMvzgNhi4BAQEBAQUBAQEBAQEYBIpTg0qBXSQ6hEsFkgGJSIIRgTCDRooQQoZag3dsAYEGQYEDAQEB X-IronPort-AV: E=Sophos;i="5.04,757,1406592000"; d="scan'208";a="364794587" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-7.cisco.com with ESMTP; 20 Oct 2014 17:26:45 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s9KHQjSu026454 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 20 Oct 2014 17:26:45 GMT Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0195.001; Mon, 20 Oct 2014 12:26:44 -0500 From: "Nancy Cam-Winget (ncamwing)" To: "Adam W. Montville" , "sacm@ietf.org" Thread-Topic: [sacm] Comments on draft-ietf-sacm-requirements-01 Thread-Index: AQHP7IsEclk0QRgbNk+Vp5ZqcLh03w== Date: Mon, 20 Oct 2014 17:26:44 +0000 Message-ID: In-Reply-To: <8280EF2B-3986-463E-A549-B582A8F88F0D@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.155.84.114] Content-Type: text/plain; charset="Windows-1252" Content-ID: <8687C974DF89D249A99850F97E8D50F2@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/l-mqoOl3gid77HjT-QScIvSCN1Q Subject: Re: [sacm] Comments on draft-ietf-sacm-requirements-01 X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 17:26:49 -0000 Hi Adam, Thanks for the review, please see further below: On 10/15/14, 7:12 AM, "Adam W. Montville" wrote: >Nancy, > >Nice update to the draft, thank you! > >I have a few wording changes I would recommend, and I=B9m not sure if you >want those now or after the next submission, which would give you the >opportunity to clean things up first (you mentioned cleaning things up a >bit during the last virtual interim). I=B9m holding the nits for now. [NCW] If you give them to me by EOB tomorrow, I will try to work them in=8A= . > >G-013 (Discovery) mentions the need for discovering the information >that=B9s available in the ecosystem, and that may imply that capabilities >are discoverable as well. Should this be made explicit? I see that it=B9= s >mentioned in ARCH-005, so that may be sufficient. [NCW] What is a capability in this instance? I think originally the text was to require discovery of =B3capabilities=B2 and the response was to be m= ore explicit e.g. The notion that in the ecosystem there may be different information that can be shared in specific instances of a data model and protocol. Would it be more clear to say that? > >How are REQ-009 and IM-014 different (aside from one being specific to >the information model)? [NCW] None, other than the REQ- are viewed from use cases and IM- are imposed on the information model to be designed. Perhaps we should revisit the Use Case section and fold those in (now that we=B9re closer to an architecture and functional components) that we can deprecate this section and fold the requirements to the other sections? > >Is there a need to express requirements in terms of real numbers or >otherwise speak to requirements that would affect operations in a given >deployment? For example, if we want to limit network bandwidth >consumption to some throttled level, or if we want to provide the ability >in the architecture to accommodate such throttling, etc. I don=B9t see >these types of things mentioned in the requirements document, and they >may turn into something important down the road (some enterprises would >yield terabytes of data each day under certain circumstances). If things >like this fall under one of the existing architectural requirements, >perhaps we should consider how to make that clear. [NCW] It depends on how the group wants to handle the proposal. In the past (in EAP and NEA) we used the requirements as the criteria to ensure that the proposals were meeting all the requirements and where there were gaps, they had to call out the specific requirement and explain how it fell short or not=8A. I think it is up to the group to decide how they want to best make use of the requirements=8A. > >Finally, do we need additional authors to help build out the information >model requirement descriptions? [NCW] I am fine making the edits and additions, if others want to help that=B9s great. BUT most important is to get actual feedback from the grou= p! > >Regards, > >Adam > > >_______________________________________________ >sacm mailing list >sacm@ietf.org >https://www.ietf.org/mailman/listinfo/sacm From nobody Mon Oct 20 10:31:46 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96E4B1A87A1 for ; Mon, 20 Oct 2014 10:31:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FJa4sEHAiC4b for ; Mon, 20 Oct 2014 10:31:42 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C23721A02BE for ; Mon, 20 Oct 2014 10:31:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1833; q=dns/txt; s=iport; t=1413826303; x=1415035903; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=MDYGFKR6MsltSV3eMlF51mrsOxiII0KSr4abOXAqWZY=; b=Fxald1uLp5f0/YMIRMZPM8knedmn8wYfGwRdW2CWHDBcbGAipMQd/iYk 6Vu8QcvwAhnnSJhZVGw3FduPbNRCiczJw7zz81+CrGetibv8ut0O0qlM2 SdVEeSW5kxjIzmNhx8vJdIQuopmzffAUbDeaiYfaqfLWvASVIs8bN35Zz c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAGBGRVStJA2L/2dsb2JhbABcgmsjgSsE03gCgRMWAX2EAwIEgQsBCBJVERcOAgQBEogrAxEBvzwNhi4BAQEBAQUBAQEBAQEcjh2CATqESwEEkgGJSIIRgTCDRoMthyWGWoN3bAGBR4EDAQEB X-IronPort-AV: E=Sophos;i="5.04,757,1406592000"; d="scan'208";a="364834709" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-6.cisco.com with ESMTP; 20 Oct 2014 17:31:42 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s9KHVgs7032502 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 20 Oct 2014 17:31:42 GMT Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0195.001; Mon, 20 Oct 2014 12:31:41 -0500 From: "Nancy Cam-Winget (ncamwing)" To: "Adam W. Montville" , "sacm@ietf.org" Thread-Topic: [sacm] Comments on draft-ietf-sacm-architecture-00 Thread-Index: AQHP7Iu2NPu1kVSDbkiPBrZ7MAZ9CA== Date: Mon, 20 Oct 2014 17:31:41 +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.3.8.130913 x-originating-ip: [10.155.84.114] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/4ZeEMMHJr_aJT1SxswSalA7r4IU Subject: Re: [sacm] Comments on draft-ietf-sacm-architecture-00 X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 17:31:44 -0000 Hi Adam, Thanks for that great feedback. Admittedly, I think as an architecture, we need to allow for other components that will want to generate and consume posture information =8A..but feedback was to try to incorporate som= e of the text from the information model draft that included some workflows for posture assessment. Section 3 attempts to map the workflow called a =B3Producer/Consumer Comple= x Example=B2 in Figure 5 of the joint info model draft as the sample map of how a specific function e.g. =B3collector=B2, =B3evaluator=B2, etc can be m= apped to the general =B3producer=B2/=B3consumer=B2 architecture. I understand the wording needs work, so I=B9ll take a look at it=8Abut plea= se feel free to make wording adjustments to make it more clear=8A.and I=B9ll a= lso do same. Thanks, Nancy On 10/15/14, 7:30 AM, "Adam W. Montville" wrote: >Hi Nancy, > >The following are comments I have about the architecture draft. Again, >holding nits until some later time after additional cleanup has been >performed. > >I=B9m not clear about what=B9s being mapped to the SACM Architecture in >Section 3. The reason, I think, is because the draft *is* the SACM >Architecture, but then Section 3 seems to imply that what we=B9ve describe= d >is something more than the SACM Architecture when it says: =B3=8Athe >architectural components shown in Figure 1 can be further refined as=8A=B2= . > >I=B9m confident that we=B9ll find confused readers when the draft goes out >for wider review in IESG, apps, etc., but most important, I think we=B9ll >find confused readers for the draft=B9s consumers (no pun intended) - thos= e >who will read the draft in six months or a year and try to implement >things. > >How do others feel about this? > >Adam From nobody Mon Oct 20 10:33:43 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2E671A8714 for ; Mon, 20 Oct 2014 10:33:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AyWdTXh13DLq for ; Mon, 20 Oct 2014 10:33:39 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5239A1A02BE for ; Mon, 20 Oct 2014 10:33:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1020; q=dns/txt; s=iport; t=1413826419; x=1415036019; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=83eemDbzPXBp72yP7s+Uqn+nIo9jjGKndUmXzWflo0w=; b=EYbxn7r0bieX/77PH3Qby+VoOsfE2pQar8lLCgk+qJrMwBnwJX6w9h+o Z1zOGokRaE9q243iXKQjd3K76WPntQjBp9Pj5fpeXddlFikgXeNPkglp6 awts9ofHsZEHqBgSNHuH/CT3WA8VuMYn497p9+a7dM5KBd0mJjQtftA5t I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAGxGRVStJV2c/2dsb2JhbABcgmsjgSsE03gCgRMWAX2EAwIEgQsBCBJVERcOAgQBEogrAxEBvzsNhi4BAQEBAQUBAQEBAQEcjQ4BgQ6CATqESwEEj2WCHIlIghGMf4JJhlqCDoFpbAGBR4EDAQEB X-IronPort-AV: E=Sophos;i="5.04,757,1406592000"; d="scan'208";a="88698536" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-7.cisco.com with ESMTP; 20 Oct 2014 17:33:38 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s9KHXche026360 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 20 Oct 2014 17:33:38 GMT Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0195.001; Mon, 20 Oct 2014 12:33:38 -0500 From: "Nancy Cam-Winget (ncamwing)" To: "Adam W. Montville" , "sacm@ietf.org" Thread-Topic: [sacm] Issue Tracking Thread-Index: AQHP7Iv7Zg/m7n8270+ML/uhje9gaw== Date: Mon, 20 Oct 2014 17:33:38 +0000 Message-ID: In-Reply-To: <40F7B859-9106-45D2-8C94-C80AF21CCF40@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.155.84.114] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/0ymzyAbqf5xc15fGmswErcpfTPk Subject: Re: [sacm] Issue Tracking X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 17:33:41 -0000 My opinion: it depends on the quantity, complexity and controversy of the issues that may take time to resolve. >From the drafts I=B9ve been working on: requirements and architecture, I don=B9t think I=B9ve had such a large quantity to have to track them thru t= he tracker system=8A.but if that changes, then I can see us using the trac system Nancy. On 10/15/14, 8:10 AM, "Adam W. Montville" wrote: >All: > >We have a lot of work represented in the drafts we have in play, and I >see a lot of comments and conversations inside the drafts - and after the >virtual interim yesterday, it feels like there=B9s a lot to manage. > >Does it make sense for this working group to start leveraging the Trac >system to manage our body of work for each respective draft? > >I ask the question as a form of encouragement for draft authors/editors >to look at the Trac system as an option for ensuring that the work that >needs to get done gets done. > >Regards, > >Adam From nobody Mon Oct 20 11:02:38 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19E5F1A8A86 for ; Mon, 20 Oct 2014 11:02:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RAnCTJaScm28 for ; Mon, 20 Oct 2014 11:02:29 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A42E41A8A79 for ; Mon, 20 Oct 2014 11:02:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9728; q=dns/txt; s=iport; t=1413828150; x=1415037750; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=HG0DJ6yJRZ40WHwNmDKithVwgRfbjvVXIZ/MkdCJJ2Q=; b=A3QKWkDqE7wX8ET4lG8m2kF7/VlzavRQuFpX9Eavpyl6taiJ7TM5ekzw Fdg6RX2h91TPk0Lm7m9NdWraQn35NBXwW6A2A8eHWd1ad3a728kMllzmj bb3h8qnbnXzhoIq8C1cts7X+SEG1KQrHPJIG55mNxTSPpM+17LzQqU5mK g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFADpNRVStJV2T/2dsb2JhbABcgmsjU1gEzCEMh0sCgRMWAX2EAwEBBAEBAWsdAQgSWwsXDgIEARKIPwEMxXABAQEBAQUBAQEBAQEckB46hEsFj2WCHItZgTCDRpEsg3dsgUiBAwEBAQ X-IronPort-AV: E=Sophos;i="5.04,757,1406592000"; d="scan'208";a="361732814" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-9.cisco.com with ESMTP; 20 Oct 2014 18:02:29 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s9KI2Sqd023223 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 20 Oct 2014 18:02:28 GMT Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0195.001; Mon, 20 Oct 2014 13:02:28 -0500 From: "Nancy Cam-Winget (ncamwing)" To: Chris Inacio , "sacm@ietf.org" Thread-Topic: [sacm] Review of draft-ietf-sacm-requirements-01 Thread-Index: AQHP7JACTWXRb3xgsUG4sqpiPDyqvw== Date: Mon, 20 Oct 2014 18:02:27 +0000 Message-ID: In-Reply-To: <8FE2AE53-743C-4042-912A-E036411F0508@cert.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.155.84.114] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/mtJDTf01eVmD9KaClcAE0G004nA Subject: Re: [sacm] Review of draft-ietf-sacm-requirements-01 X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 18:02:37 -0000 Thanks Chris! See below: On 10/17/14, 8:18 PM, "Chris Inacio" wrote: > > >I did a detailed reading of the draft and have a bunch of comments. But >I will start with high level impressions first. > >The draft starts really strong in the requirements, but tails off towards >the end - the requirements aren=B9t as well developed or clear. Where it >is clear that Nancy has spent some time capturing solid requirements, I >would like to say kudos to her - she=B9s captured a lot of details in a >relatively short amount of text and actually made me think about the >overall architecture in some new ways. > >I would ask for a more careful usage of MUST, SHOULD, MAY. I would like >to think of the requirements in terms of =B3absolutely have to have=B2 =3D= > >MUST and =B3desirable to have=B2 =3D> SHOULD or MAY, depending. It isn=B9= t clear >to me, entirely, that everything isn=B9t intended to be a MUST, in which >case, maybe this isn=B9t a useful comment. But I think there might be som= e >room in some of the requirements for leeway. [NCW] Fair points and I=B9ll try to bring better consistency to them=8A.but= if you see some you=B9re passionate about getting the right language please highlight them so I can ensure they=B9re addressed. > >More detailed comments: > >Section 2.1 > Should you create a 2.1 =B3Introduction=B2 section for the text precedin= g >requirement G-001? While I don=B9t believe that the text in the list 1-5 >are requirements, maybe we should be crystal clear on that. > Then 2.2 would be the =B3General Requirements=B2 section. [NCW] Right, is is meant to be preface before getting straight into the general requirements=8A.I=B9ll see about breaking it into an overview or so= me such subsection=8A > >G-001 - I really want this split into 3 subsections of requirements, > * transport=20 > * info model > * query lang > > It=B9s beast of a requirement as it stands now. Also, I=B9m not excited = by >the =B3allow support for non-standard and future extensions=B2. I find it >peculiar that a SDO would be requiring the development of a standard to >allow for non-standards to be included in the standards. (In the future, >I will create a sentence with more uses of the word =B3standard=B2. :) ) [NCW] So, =B3general=B2 is meant to imply that it applies to all the sections. Do you suggest moving it or having it reasserted in each of the other sections (e.g. Transport, info model..etc)? The intent is to allow for future proofing the standards too as we have to recognize that we will not be able to standardize =B3every posture attribut= e type and action=B2. So we have to allow for the extensibility for new type= s to come in=8A.then it=B9ll be up to the group whether these are managed through IANA or not=8A.. I will try to rework the text so it=B9s not explicitly stating allowance fo= r vendor specific extensions (but that will be very highly likely to happen :-) > >G-003 - remove the final =B3defined=B2 in the paragraph. [NCW] OK > >G-004 - reword: =B3=8A protocols, transports are suitable to implementati= ons >are suitable to fit in =8A=B2 Maybe something like: =B3that the data mod= el, >protocols, and transports are suitably implemented to fit into the >different deployment models and scenarios.=B2 [NCW] OK > >G-006 / GN-005: =B3mandatory to implement data attributes=B2 =3D> needs t= o be >changed to get rid of "data attributes=B2 or we need to establish what thi= s >means in terms of the requirements doc. I=B9m fairly certain I understand >it, but if you ask me while/after building a sacm compliant >implementation if that is met, I don=B9t think I=B9ll know. We might real= ly >mean that the info model must have a set of IEs that will be mandatory to >implement in all data models, and systems that support multiple data >models must support the ability to transparently exchange all mandatory >to implement IE=B9s across all DM=B9s. (But we didn=B9t say that. :) ) [NCW] Hmmm=8A.so attributes are defined in the terminology draft=8A.would y= ou rather I remove =B3data=B2? > >REQ-002: Does this imply accepting multiple data models (& info models?) >in the =B3SACM protocol=B2? Does this imply how much of SACM is a >metaprotocol, possibly? Is SACM possibly a way to negotiate various >disparate protocols (capabilities & versions) and maybe a query / >response protocol? I think this requirement creates FAR reaching >implications. How does this requirement fit with G-006 / GN-005 which >requires an explicit set of mandatory to implement data attributes? [NCW] I believe so (e.g. There may exist multiple data models) so given the existence of multiple, we have to put requirements of at least a set of attributes (or perhaps a data model and the data model includes a MUST set of attributes) that are mandatory to implement. The negotiation is part of the discovery in G-013 > >REQ-006: =B3The query operation may be a synchronous or asynchronous >request.=B2 First, an IETF comment, is that =B3may=B2 a =B3MAY=B2? From = an >implementors point of view: OUCH. I would really prefer you pick one or >both, but settle that THE PROTOCOL/STANDARD *MUST* support some set, but >IMPLEMENTATIONS *MAY* choose and negotiate. If you don=B9t choose, just >remove the line from the requirements, it doesn=B9t help anyone in the >future as it stands now. [NCW] This is why its left as an uncapped =B3may=B2 as imho SACM can MUST support for both types of requests. But the operation could be one or the other, or a task could use both. > >REQ-009: I actually don=B9t understand that requirement. [NCW] This was the outcome of a WG discussion to ensure that we explicitly stated that the task of collection and doing something with the collected result could be separable=8A..don=B9t recall the particular use case, but i= t was agreed that it needed to be called out explicitly. > >ARCH-001: A little caution on the sizes used, if concrete numbers are >really desired. If sacm is deployed at Ft. Bragg in the US, it=B9s human >population is 238,646 >[http://www.army-technology.com/features/feature-largest-military-bases-wo >rld-united-states/]. If each of those folks has a cell phone, a desktop, >and 1-2 other devices we=B9re in the millions. If Ft. Bragg implements >something like an IoT and manages it with sacm, then I think that number >gets a whole lot higher. I=B9m pretty sure that all the planes, >helicopters, etc. probably have *at least* 1 IP address each. [NCW] I=B9m OK saying =8Cvery large=B9, but somehow my notes from the discussions said that I had to quantify. But I agree that we could group to the many millions. > >ARCH-004: =B3systems can utilize an already established mutually agreed >upon native data format, which may be standard or >implementation-specific=B2. I understand why one might want that statemen= t >there, but it should be dropped. (1) No one meeting in the sacm room >could ever prevent this from happening if they wanted to (2) putting this >in the requirements doesn=B9t help the design of the IM, DM, or any other >protocols or operations. [NCW] OK by me. > >IM-009: Please expand the text. (Lisa, I know you explained this, >verbally, already, but it needs to be written down.) [NCW] Yes, will likely need to expand on most of the 1 sentence reqmts in the IM section=8A. > >IM-011: remove =B3- for example=B2. The follow on text is either a >requirement or not. {NCW] OK > >IM-014: Does this imply that using sacm protocols the sensors/agents can >be configured via a sacm initiated request? [NCW] This again goes back to REQ-009 discussions=8A.but I think its more prescriptive of the =B3collection task=B2 which I=B9m not sure we want to explicitly defined? I=B9m not sure it=B9s really in scope for the charter, = but will have to have Dan, Adam and Kathleen weigh in=8A. > >IM-015: Does this imply something like a simple calculus that lets me >logical / arithmetically / statistically define new =B3virtual=B2 readings >from actual readings? Does this language have to be supported at every >sensor/agent? Also, we need a firm definition on the =B3point of >collection=B2. [NCW] My response is same as above. The intent is to assert that a request could be comprised of multiple requests, I=B9m not sure we want to be prescriptive of =B3how=B2 in the requirements draft. > >T-002: Reword please. I take it to mean the following: =B3Data Integrity= : >For protocols which do not provide for data integrity in the transport >layer, a sufficient data integrity mechanism MUST be provided." [NCW] Hmmm=8A.my bad. It is to state that data integrity SHOULD be provide= d at the transport layer. > >Security Considerations: I really like this section, especially as >someone who (in theory at least) does reviews for the security >directorate. BUT (you knew it was coming,) shouldn=B9t the last 3 >paragraphs in the security considerations section actually be >requirements?, say SEC-001, SEC-002, SEC-003? :) [NCW] Agreed. I=B9m thinking that Requirements don=B9t warrant =B3considerations=B2 but rather a set of requirements with appropriate language, e.g. MUST, SHOULD, etc > > > >I hope this helps. And I=B9ll see if I can plow through the info model >this weekend. [NCW] Many thanks for the thorough review!!! Am working on incorporating them this week=8A > >Chris > >_______________________________________________ >sacm mailing list >sacm@ietf.org >https://www.ietf.org/mailman/listinfo/sacm From nobody Tue Oct 21 02:13:48 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AC421A01AA for ; Tue, 21 Oct 2014 02:13:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hujVaLyTFHwJ for ; Tue, 21 Oct 2014 02:13:33 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE7731A01BA for ; Tue, 21 Oct 2014 02:13:32 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak8LAFsXRlSHCzIm/2dsb2JhbABcgmsjU1gEuH8BAQEBAQeSWyIKh00CgQ4WAQF8hAIBAQEBAwEBAQ9cFwQCAQgNBAEDAQEBCh0HIQYLFAMGCAIEARIIGogJAxEBDKRMmQcNhi4BAQEBAQEEAQEBAQEBAQEBAQETBIYjhmsBgQ6CAzgGgyeBHgWSAYlHAYoihG6CSYZag3dsAYFHgQMBAQE X-IronPort-AV: E=Sophos;i="5.04,760,1406606400"; d="scan'208";a="77427689" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by de307622-de-outbound.net.avaya.com with ESMTP; 21 Oct 2014 05:13:30 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC03.global.avaya.com) ([135.64.58.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES128-SHA; 21 Oct 2014 05:13:29 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC03.global.avaya.com ([135.64.58.13]) with mapi id 14.03.0174.001; Tue, 21 Oct 2014 05:13:27 -0400 From: "Romascanu, Dan (Dan)" To: "Nancy Cam-Winget (ncamwing)" , "Adam W. Montville" , "sacm@ietf.org" Thread-Topic: [sacm] Issue Tracking Thread-Index: AQHP7Iv7Zg/m7n8270+ML/uhje9ga5w6RN3Q Date: Tue, 21 Oct 2014 09:13:27 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C8D43C7@AZ-FFEXMB04.global.avaya.com> References: <40F7B859-9106-45D2-8C94-C80AF21CCF40@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: text/plain; charset="windows-1257" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/sKa5K7rJPMYsp6J4BZdiRYYJ2CM Subject: Re: [sacm] Issue Tracking X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 09:13:46 -0000 Can we put this issue on the agenda of the meeting at IETF-91?=20 Is there a volunteer to drive this discussion - somebody who has used the i= ssue tracking system in another WG, can make a short demo on the screen and= share the pros and cons according to her/his experience?=20 Thanks and Regards, Dan > -----Original Message----- > From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Nancy Cam- > Winget (ncamwing) > Sent: Monday, October 20, 2014 8:34 PM > To: Adam W. Montville; sacm@ietf.org > Subject: Re: [sacm] Issue Tracking >=20 > My opinion: it depends on the quantity, complexity and controversy of the > issues that may take time to resolve. > >From the drafts I=B9ve been working on: requirements and architecture, I > don=B9t think I=B9ve had such a large quantity to have to track them thru= the > tracker system=D0.but if that changes, then I can see us using the trac s= ystem >=20 > Nancy. >=20 > On 10/15/14, 8:10 AM, "Adam W. Montville" > > wrote: >=20 > >All: > > > >We have a lot of work represented in the drafts we have in play, and I > >see a lot of comments and conversations inside the drafts - and after > >the virtual interim yesterday, it feels like there=B9s a lot to manage. > > > >Does it make sense for this working group to start leveraging the Trac > >system to manage our body of work for each respective draft? > > > >I ask the question as a form of encouragement for draft authors/editors > >to look at the Trac system as an option for ensuring that the work that > >needs to get done gets done. > > > >Regards, > > > >Adam >=20 > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm From nobody Tue Oct 21 06:49:14 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96ADD1A6F05 for ; Tue, 21 Oct 2014 06:49:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q-2DlI8tXMjQ for ; Tue, 21 Oct 2014 06:49:02 -0700 (PDT) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3BC81A6EED for ; Tue, 21 Oct 2014 06:49:00 -0700 (PDT) Received: by mail-oi0-f52.google.com with SMTP id a3so934366oib.25 for ; Tue, 21 Oct 2014 06:49:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=PTiV2IgGkhHlXhA+mOBeo12mT4CmsT5V3q/97llqd5Q=; b=bHREzuR4KQqnVvsoT5NOoj47/rehzSlVkPCzUOn46rDpzreboBerb5gfHmrACQpFkm SeaApJQFpNJeSglwzEW1ogZErIu9CKZuU2nFktOCM1qB+fxlJHB/T9BQXqvIz5LaF9EI swY1q6Xo2fjT7bzNLGPYfmw0ynjZpYZHbxcHqT4wMRfOTxk0NqoRg+5yIzOOVHDrkdOw ry3QBHXbryqZDoFXtHSs2jI9v7WPeEIyk5bmYVeFcP3sk0pNaIW8EBo0rNucGXXRgxZw wZrqe1dgu2aFWsqZ9hbkRmb8OhOFDyb/j6+lUvYy6JGxmr/wOBEKHtfv4fNotp4/wbj/ mx8g== X-Received: by 10.202.178.131 with SMTP id b125mr2071664oif.72.1413899340328; Tue, 21 Oct 2014 06:49:00 -0700 (PDT) Received: from ?IPv6:2602:306:3406:4f00:95fb:a684:df57:ca98? ([2602:306:3406:4f00:95fb:a684:df57:ca98]) by mx.google.com with ESMTPSA id yp6sm5226653obc.19.2014.10.21.06.48.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 21 Oct 2014 06:48:59 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: "Adam W. Montville" In-Reply-To: Date: Tue, 21 Oct 2014 08:48:58 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <085D6890-5AC4-48CC-984E-D00914ECE864@gmail.com> References: To: "Nancy Cam-Winget (ncamwing)" X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/ta5bu-aoSI5_mzCjrwcqCz_n3Ys Cc: "sacm@ietf.org" Subject: Re: [sacm] Comments on draft-ietf-sacm-requirements-01 X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 13:49:07 -0000 > On Oct 20, 2014, at 12:26 PM, Nancy Cam-Winget (ncamwing) = wrote: >=20 > Hi Adam, > Thanks for the review, please see further below: >=20 > On 10/15/14, 7:12 AM, "Adam W. Montville" > wrote: >=20 >> Nancy, >>=20 >> Nice update to the draft, thank you! >>=20 >> I have a few wording changes I would recommend, and I=B9m not sure if = you >> want those now or after the next submission, which would give you the >> opportunity to clean things up first (you mentioned cleaning things = up a >> bit during the last virtual interim). I=B9m holding the nits for = now. > [NCW] If you give them to me by EOB tomorrow, I will try to work them = in=8A. >=20 >>=20 >> G-013 (Discovery) mentions the need for discovering the information >> that=B9s available in the ecosystem, and that may imply that = capabilities >> are discoverable as well. Should this be made explicit? I see that = it=B9s >> mentioned in ARCH-005, so that may be sufficient. > [NCW] What is a capability in this instance? I think originally the = text > was to require discovery of =B3capabilities=B2 and the response was to = be more > explicit e.g. The notion that in the ecosystem there may be different > information that can be shared in specific instances of a data model = and > protocol. Would it be more clear to say that? Yes, that might clarify. What I was looking at is some recognition that = we=92re going to eventually need to agree on a controlled vocabulary for = what a =93capability=94 is. >=20 >>=20 >> How are REQ-009 and IM-014 different (aside from one being specific = to >> the information model)? > [NCW] None, other than the REQ- are viewed from use cases and IM- are > imposed on the information model to be designed. Perhaps we should > revisit the Use Case section and fold those in (now that we=B9re = closer to > an architecture and functional components) that we can deprecate this > section and fold the requirements to the other sections? I=92m not sure of the appropriate action to take on this one. On one = hand, it can be confusing to have the same requirement stated twice. On = the other hand, if one requirement pertains to =93meeting use cases=94 = and another pertains to the information model, they might be considered = separate requirements. =20 Do others have helpful advice? >=20 >>=20 >> Is there a need to express requirements in terms of real numbers or >> otherwise speak to requirements that would affect operations in a = given >> deployment? For example, if we want to limit network bandwidth >> consumption to some throttled level, or if we want to provide the = ability >> in the architecture to accommodate such throttling, etc. I don=B9t = see >> these types of things mentioned in the requirements document, and = they >> may turn into something important down the road (some enterprises = would >> yield terabytes of data each day under certain circumstances). If = things >> like this fall under one of the existing architectural requirements, >> perhaps we should consider how to make that clear. > [NCW] It depends on how the group wants to handle the proposal. In = the > past (in EAP and NEA) we used the requirements as the criteria to = ensure > that the proposals were meeting all the requirements and where there = were > gaps, they had to call out the specific requirement and explain how it > fell short or not=8A. > I think it is up to the group to decide how they want to best make use = of > the requirements=8A. I mentioned this specifically because it was a comment I had heard back = in August. I was hoping my comment would elicit further comments from = the interested parties, but that does not appear to have happened. For = now, and until we gain some clarity, I guess we=92ll leave it as is, = unless others opine. >=20 >>=20 >> Finally, do we need additional authors to help build out the = information >> model requirement descriptions? > [NCW] I am fine making the edits and additions, if others want to help > that=B9s great. BUT most important is to get actual feedback from the = group! +1 =20 >=20 >>=20 >> Regards, >>=20 >> Adam >>=20 >>=20 >> _______________________________________________ >> sacm mailing list >> sacm@ietf.org >> https://www.ietf.org/mailman/listinfo/sacm >=20 From nobody Tue Oct 21 06:52:51 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A55601A6F62 for ; Tue, 21 Oct 2014 06:52:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NRxfEZ01mbhF for ; Tue, 21 Oct 2014 06:52:45 -0700 (PDT) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80A331A6F5B for ; Tue, 21 Oct 2014 06:51:54 -0700 (PDT) Received: by mail-oi0-f41.google.com with SMTP id u20so959117oif.28 for ; Tue, 21 Oct 2014 06:51:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Rc6GTJLj89QAl9oZt8yU9d2yUbcbuQooi8mYYACKU9E=; b=n6Pvk68NlpiFgnLaYbjuwtLDBrEgWXBNdo1151p+s8YXGxZDV40h/b6AYi2NgmyUm0 MP51BRT4C43C4AeBns35fDnJ9CJpMNsoB8sOw4medRQ+qYL/PVMxpBqPUql+whugy9m/ bLSeZ3Mpzk+gYnR83H6lG623pOYtiG3LW3Q+YiVyBi7GJiYWo0uVjMcohyMa9TaAj4lH a29SfYqjK8RAQQkiwgbHeQLv5ckg9/Cx/G9hz+GmlmwJydhNCR6zfMMOM0Ik9NkcU4Da KcKr28K33GDYSM9aSTQyQYQYTy4g+/7o7BpaBxyQdkS7d7+tkGman0A3dneESlZ5rMrY TbNA== X-Received: by 10.60.147.234 with SMTP id tn10mr1897078oeb.79.1413899513877; Tue, 21 Oct 2014 06:51:53 -0700 (PDT) Received: from ?IPv6:2602:306:3406:4f00:95fb:a684:df57:ca98? ([2602:306:3406:4f00:95fb:a684:df57:ca98]) by mx.google.com with ESMTPSA id c191sm5216010oid.14.2014.10.21.06.51.52 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 21 Oct 2014 06:51:53 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: "Adam W. Montville" In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA5C8D43C7@AZ-FFEXMB04.global.avaya.com> Date: Tue, 21 Oct 2014 08:51:52 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <3C84082B-7DF3-4000-8244-AA3F0A648E20@gmail.com> References: <40F7B859-9106-45D2-8C94-C80AF21CCF40@gmail.com> <9904FB1B0159DA42B0B887B7FA8119CA5C8D43C7@AZ-FFEXMB04.global.avaya.com> To: "Dan (Dan) Romascanu" X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/MjE7FWT32tjpaeZv4fHyoyQU2YM Cc: "Nancy Cam-Winget \(ncamwing\)" , "sacm@ietf.org" Subject: Re: [sacm] Issue Tracking X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 13:52:47 -0000 Dan, that=E2=80=99s a great idea. While I=E2=80=99m not sure how much = experience either have with the tracking system, I know that Dave W. and = Lisa were looking into how they might leverage it. If no one with more = experience steps forward, and if they have the time, I would nominate = them. Adam > On Oct 21, 2014, at 4:13 AM, Romascanu, Dan (Dan) = wrote: >=20 > Can we put this issue on the agenda of the meeting at IETF-91?=20 >=20 > Is there a volunteer to drive this discussion - somebody who has used = the issue tracking system in another WG, can make a short demo on the = screen and share the pros and cons according to her/his experience?=20 >=20 > Thanks and Regards, >=20 > Dan >=20 >=20 >> -----Original Message----- >> From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Nancy Cam- >> Winget (ncamwing) >> Sent: Monday, October 20, 2014 8:34 PM >> To: Adam W. Montville; sacm@ietf.org >> Subject: Re: [sacm] Issue Tracking >>=20 >> My opinion: it depends on the quantity, complexity and controversy of = the >> issues that may take time to resolve. >>> =46rom the drafts I=C2=B9ve been working on: requirements and = architecture, I >> don=C2=B9t think I=C2=B9ve had such a large quantity to have to track = them thru the >> tracker system=C5=A0.but if that changes, then I can see us using the = trac system >>=20 >> Nancy. >>=20 >> On 10/15/14, 8:10 AM, "Adam W. Montville" >> >> wrote: >>=20 >>> All: >>>=20 >>> We have a lot of work represented in the drafts we have in play, and = I >>> see a lot of comments and conversations inside the drafts - and = after >>> the virtual interim yesterday, it feels like there=C2=B9s a lot to = manage. >>>=20 >>> Does it make sense for this working group to start leveraging the = Trac >>> system to manage our body of work for each respective draft? >>>=20 >>> I ask the question as a form of encouragement for draft = authors/editors >>> to look at the Trac system as an option for ensuring that the work = that >>> needs to get done gets done. >>>=20 >>> Regards, >>>=20 >>> Adam >>=20 >> _______________________________________________ >> sacm mailing list >> sacm@ietf.org >> https://www.ietf.org/mailman/listinfo/sacm From nobody Tue Oct 21 07:45:39 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B1861A6F7F for ; Tue, 21 Oct 2014 07:45:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4uM8qVtS3PpZ for ; Tue, 21 Oct 2014 07:45:30 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0061.outbound.protection.outlook.com [207.46.100.61]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1545F1A86E5 for ; Tue, 21 Oct 2014 07:45:30 -0700 (PDT) Received: from BLUPR06MB433.namprd06.prod.outlook.com (10.141.27.142) by BLUPR06MB436.namprd06.prod.outlook.com (10.141.27.155) with Microsoft SMTP Server (TLS) id 15.0.1054.13; Tue, 21 Oct 2014 14:45:28 +0000 Received: from BLUPR06MB433.namprd06.prod.outlook.com ([169.254.4.164]) by BLUPR06MB433.namprd06.prod.outlook.com ([169.254.4.164]) with mapi id 15.00.1054.004; Tue, 21 Oct 2014 14:45:28 +0000 From: "Lorenzin, Lisa" To: "Adam W. Montville" , "Dan (Dan) Romascanu" Thread-Topic: [sacm] Issue Tracking Thread-Index: AQHP7TZSzWtJ51ZxuUyYbnmHSbBi3Zw6nrGg Date: Tue, 21 Oct 2014 14:45:28 +0000 Message-ID: References: <40F7B859-9106-45D2-8C94-C80AF21CCF40@gmail.com> <9904FB1B0159DA42B0B887B7FA8119CA5C8D43C7@AZ-FFEXMB04.global.avaya.com> <3C84082B-7DF3-4000-8244-AA3F0A648E20@gmail.com> In-Reply-To: <3C84082B-7DF3-4000-8244-AA3F0A648E20@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [66.129.239.13] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BLUPR06MB436; x-exchange-antispam-report-test: UriScan:; x-forefront-prvs: 0371762FE7 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(13464003)(479174003)(377454003)(51704005)(24454002)(189002)(199003)(20776003)(97736003)(15975445006)(92566001)(66066001)(108616004)(46102003)(80022003)(101416001)(64706001)(86362001)(85306004)(93886004)(21056001)(4396001)(19580405001)(19580395003)(76176999)(50986999)(40100003)(122556002)(33646002)(87936001)(85852003)(2656002)(31966008)(120916001)(99396003)(105586002)(76482002)(54356999)(74316001)(106116001)(99286002)(106356001)(107046002)(77096002)(95666004)(76576001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR06MB436; H:BLUPR06MB433.namprd06.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: pulsesecure.net Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/w6FQ5WQGMhxOVmHW6g0sIbZY9i4 Cc: "Nancy Cam-Winget \(ncamwing\)" , "sacm@ietf.org" Subject: Re: [sacm] Issue Tracking X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 14:45:37 -0000 SW4gdGhlIGFic2VuY2Ugb2Ygc29tZW9uZSB3aXRoIHJlYWwtd29ybGQgZXhwZXJpZW5jZSwgSSdt IGhhcHB5IHRvIGNyZWF0ZSBzb21lIGV4YW1wbGUgdGlja2V0cyBhbmQgZ2l2ZSBhIHF1aWNrIGRl bW8uLi4NCg0KUmVnYXJkcywNCkxpc2ENCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZy b206IHNhY20gW21haWx0bzpzYWNtLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBZGFt IFcuIE1vbnR2aWxsZQ0KU2VudDogVHVlc2RheSwgT2N0b2JlciAyMSwgMjAxNCA4OjUyIEFNDQpU bzogRGFuIChEYW4pIFJvbWFzY2FudQ0KQ2M6IE5hbmN5IENhbS1XaW5nZXQgKG5jYW13aW5nKTsg c2FjbUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtzYWNtXSBJc3N1ZSBUcmFja2luZw0KDQpEYW4s IHRoYXTigJlzIGEgZ3JlYXQgaWRlYS4gIFdoaWxlIEnigJltIG5vdCBzdXJlIGhvdyBtdWNoIGV4 cGVyaWVuY2UgZWl0aGVyIGhhdmUgd2l0aCB0aGUgdHJhY2tpbmcgc3lzdGVtLCBJIGtub3cgdGhh dCBEYXZlIFcuIGFuZCBMaXNhIHdlcmUgbG9va2luZyBpbnRvIGhvdyB0aGV5IG1pZ2h0IGxldmVy YWdlIGl0LiAgSWYgbm8gb25lIHdpdGggbW9yZSBleHBlcmllbmNlIHN0ZXBzIGZvcndhcmQsIGFu ZCBpZiB0aGV5IGhhdmUgdGhlIHRpbWUsIEkgd291bGQgbm9taW5hdGUgdGhlbS4NCg0KQWRhbQ0K DQo+IE9uIE9jdCAyMSwgMjAxNCwgYXQgNDoxMyBBTSwgUm9tYXNjYW51LCBEYW4gKERhbikgPGRy b21hc2NhQGF2YXlhLmNvbT4gd3JvdGU6DQo+IA0KPiBDYW4gd2UgcHV0IHRoaXMgaXNzdWUgb24g dGhlIGFnZW5kYSBvZiB0aGUgbWVldGluZyBhdCBJRVRGLTkxPyANCj4gDQo+IElzIHRoZXJlIGEg dm9sdW50ZWVyIHRvIGRyaXZlIHRoaXMgZGlzY3Vzc2lvbiAtIHNvbWVib2R5IHdobyBoYXMgdXNl ZCB0aGUgaXNzdWUgdHJhY2tpbmcgc3lzdGVtIGluIGFub3RoZXIgV0csIGNhbiBtYWtlIGEgc2hv cnQgZGVtbyBvbiB0aGUgc2NyZWVuIGFuZCBzaGFyZSB0aGUgcHJvcyBhbmQgY29ucyBhY2NvcmRp bmcgdG8gaGVyL2hpcyBleHBlcmllbmNlPyANCj4gDQo+IFRoYW5rcyBhbmQgUmVnYXJkcywNCj4g DQo+IERhbg0KPiANCj4gDQo+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gRnJvbTog c2FjbSBbbWFpbHRvOnNhY20tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE5hbmN5IENh bS0NCj4+IFdpbmdldCAobmNhbXdpbmcpDQo+PiBTZW50OiBNb25kYXksIE9jdG9iZXIgMjAsIDIw MTQgODozNCBQTQ0KPj4gVG86IEFkYW0gVy4gTW9udHZpbGxlOyBzYWNtQGlldGYub3JnDQo+PiBT dWJqZWN0OiBSZTogW3NhY21dIElzc3VlIFRyYWNraW5nDQo+PiANCj4+IE15IG9waW5pb246IGl0 IGRlcGVuZHMgb24gdGhlIHF1YW50aXR5LCBjb21wbGV4aXR5IGFuZCBjb250cm92ZXJzeSBvZiB0 aGUNCj4+IGlzc3VlcyB0aGF0IG1heSB0YWtlIHRpbWUgdG8gcmVzb2x2ZS4NCj4+PiBGcm9tIHRo ZSBkcmFmdHMgScK5dmUgYmVlbiB3b3JraW5nIG9uOiByZXF1aXJlbWVudHMgYW5kIGFyY2hpdGVj dHVyZSwgSQ0KPj4gZG9uwrl0IHRoaW5rIEnCuXZlIGhhZCBzdWNoIGEgbGFyZ2UgcXVhbnRpdHkg dG8gaGF2ZSB0byB0cmFjayB0aGVtIHRocnUgdGhlDQo+PiB0cmFja2VyIHN5c3RlbcWgLmJ1dCBp ZiB0aGF0IGNoYW5nZXMsIHRoZW4gSSBjYW4gc2VlIHVzIHVzaW5nIHRoZSB0cmFjIHN5c3RlbQ0K Pj4gDQo+PiAJTmFuY3kuDQo+PiANCj4+IE9uIDEwLzE1LzE0LCA4OjEwIEFNLCAiQWRhbSBXLiBN b250dmlsbGUiDQo+PiA8YWRhbS53Lm1vbnR2aWxsZUBnbWFpbC5jb20+DQo+PiB3cm90ZToNCj4+ IA0KPj4+IEFsbDoNCj4+PiANCj4+PiBXZSBoYXZlIGEgbG90IG9mIHdvcmsgcmVwcmVzZW50ZWQg aW4gdGhlIGRyYWZ0cyB3ZSBoYXZlIGluIHBsYXksIGFuZCBJDQo+Pj4gc2VlIGEgbG90IG9mIGNv bW1lbnRzIGFuZCBjb252ZXJzYXRpb25zIGluc2lkZSB0aGUgZHJhZnRzIC0gYW5kIGFmdGVyDQo+ Pj4gdGhlIHZpcnR1YWwgaW50ZXJpbSB5ZXN0ZXJkYXksIGl0IGZlZWxzIGxpa2UgdGhlcmXCuXMg YSBsb3QgdG8gbWFuYWdlLg0KPj4+IA0KPj4+IERvZXMgaXQgbWFrZSBzZW5zZSBmb3IgdGhpcyB3 b3JraW5nIGdyb3VwIHRvIHN0YXJ0IGxldmVyYWdpbmcgdGhlIFRyYWMNCj4+PiBzeXN0ZW0gdG8g bWFuYWdlIG91ciBib2R5IG9mIHdvcmsgZm9yIGVhY2ggcmVzcGVjdGl2ZSBkcmFmdD8NCj4+PiAN Cj4+PiBJIGFzayB0aGUgcXVlc3Rpb24gYXMgYSBmb3JtIG9mIGVuY291cmFnZW1lbnQgZm9yIGRy YWZ0IGF1dGhvcnMvZWRpdG9ycw0KPj4+IHRvIGxvb2sgYXQgdGhlIFRyYWMgc3lzdGVtIGFzIGFu IG9wdGlvbiBmb3IgZW5zdXJpbmcgdGhhdCB0aGUgd29yayB0aGF0DQo+Pj4gbmVlZHMgdG8gZ2V0 IGRvbmUgZ2V0cyBkb25lLg0KPj4+IA0KPj4+IFJlZ2FyZHMsDQo+Pj4gDQo+Pj4gQWRhbQ0KPj4g DQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4g c2FjbSBtYWlsaW5nIGxpc3QNCj4+IHNhY21AaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vc2FjbQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0Kc2FjbSBtYWlsaW5nIGxpc3QNCnNhY21AaWV0Zi5vcmcNCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2FjbQ0K From nobody Wed Oct 22 13:18:15 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DB351A1A13 for ; Wed, 22 Oct 2014 13:18:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.402 X-Spam-Level: X-Spam-Status: No, score=-2.402 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QoknKJ927Efd for ; Wed, 22 Oct 2014 13:18:11 -0700 (PDT) Received: from shetland.sei.cmu.edu (shetland.sei.cmu.edu [192.58.107.44]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E3871A19EA for ; Wed, 22 Oct 2014 13:18:10 -0700 (PDT) Received: from pawpaw.sei.cmu.edu (pawpaw.sei.cmu.edu [10.64.21.22]) by shetland.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id s9MKI8cs020897; Wed, 22 Oct 2014 16:18:08 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1414009088; bh=Hr0euggUsd3c75rD5JLJUigllldWiNs2ToLSeSdZMs0=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-ID:Content-Transfer-Encoding:MIME-Version: Sender:Reply-To; b=YDPmGD2BHAP//K1DBOu2DFUxKpr5LGLmDs04ziyhluMnSkiu1Wr+7C6PemwH9wppv wNkDXduKLVvlCgeL5WUp7hlssQZ3QTek/ol1GqKTY7eKCxaZEi7il4r/o9uPpEy+R6 qxJA/ewmMcq05M90ZSUIT5fG37IUFUT9wMvE9gO0= Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by pawpaw.sei.cmu.edu (8.14.4/8.14.4/1456) with ESMTP id s9MKIC67029273; Wed, 22 Oct 2014 16:18:12 -0400 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.02.0347.000; Wed, 22 Oct 2014 16:18:05 -0400 From: Chris Inacio To: "Nancy Cam-Winget (ncamwing)" Thread-Topic: [sacm] Review of draft-ietf-sacm-requirements-01 Thread-Index: AQHP6oIhhPwCy40tBUmyTonEaR/dvJw5jg2AgANKjgA= Date: Wed, 22 Oct 2014 20:18:04 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.51.97] Content-Type: text/plain; charset="Windows-1252" Content-ID: <08BAAFC02EBC2D479FB7A8F64015A24F@sei.cmu.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/dUS-7Jc8rVxdLHX8WyUVla6YhqY Cc: "sacm@ietf.org" Subject: Re: [sacm] Review of draft-ietf-sacm-requirements-01 X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 20:18:14 -0000 On Oct 20, 2014, at 2:02 PM, Nancy Cam-Winget (ncamwing) wrote: > Thanks Chris! >=20 > See below: >=20 > On 10/17/14, 8:18 PM, "Chris Inacio" wrote: >=20 >>=20 >>=20 >> I did a detailed reading of the draft and have a bunch of comments. But >> I will start with high level impressions first. >>=20 >> The draft starts really strong in the requirements, but tails off toward= s >> the end - the requirements aren=B9t as well developed or clear. Where i= t >> is clear that Nancy has spent some time capturing solid requirements, I >> would like to say kudos to her - she=B9s captured a lot of details in a >> relatively short amount of text and actually made me think about the >> overall architecture in some new ways. >>=20 >> I would ask for a more careful usage of MUST, SHOULD, MAY. I would like >> to think of the requirements in terms of =B3absolutely have to have=B2 = =3D> >> MUST and =B3desirable to have=B2 =3D> SHOULD or MAY, depending. It isn= =B9t clear >> to me, entirely, that everything isn=B9t intended to be a MUST, in which >> case, maybe this isn=B9t a useful comment. But I think there might be s= ome >> room in some of the requirements for leeway. > [NCW] Fair points and I=B9ll try to bring better consistency to them=8A.b= ut if > you see some you=B9re passionate about getting the right language please > highlight them so I can ensure they=B9re addressed. >=20 >>=20 >> More detailed comments: >>=20 >> Section 2.1 >> Should you create a 2.1 =B3Introduction=B2 section for the text preced= ing >> requirement G-001? While I don=B9t believe that the text in the list 1-= 5 >> are requirements, maybe we should be crystal clear on that. >> Then 2.2 would be the =B3General Requirements=B2 section. > [NCW] Right, is is meant to be preface before getting straight into the > general requirements=8A.I=B9ll see about breaking it into an overview or = some > such subsection=8A >=20 >>=20 >> G-001 - I really want this split into 3 subsections of requirements, >> * transport=20 >> * info model >> * query lang >>=20 >> It=B9s beast of a requirement as it stands now. Also, I=B9m not excite= d by >> the =B3allow support for non-standard and future extensions=B2. I find = it >> peculiar that a SDO would be requiring the development of a standard to >> allow for non-standards to be included in the standards. (In the future= , >> I will create a sentence with more uses of the word =B3standard=B2. :) ) > [NCW] So, =B3general=B2 is meant to imply that it applies to all the > sections. Do you suggest moving it or having it reasserted in each of th= e > other sections (e.g. Transport, info model..etc)? >=20 [CMI] I was thinking more of a G-001 that was more decomposed within G-001= . Just so that the overall point of the set of requirements was still main= tained as a high-level adaptable architecture, but maybe break out the piec= es (still under G-001) as separate (unnumbered) bullets. Especially for po= sterity, and folks who aren=92t necessarily intimating involved now. > The intent is to allow for future proofing the standards too as we have t= o > recognize that we will not be able to standardize =B3every posture attrib= ute > type and action=B2. So we have to allow for the extensibility for new ty= pes > to come in=8A.then it=B9ll be up to the group whether these are managed > through IANA or not=8A.. > I will try to rework the text so it=B9s not explicitly stating allowance = for > vendor specific extensions (but that will be very highly likely to happen > :-) >=20 [cmi] I=92m sure it will be likely to happen. I believe the =93ility=94 we= can add to our work is extensibility, an escape hatch. What *I* would cle= arly want in the protocol/IM/DM (someplace) is the ability to (1) mark a pi= ece of data/protocol/information as vendor specific (2) ensure that even wh= en adding vendor specific enhancements, those can be ignored by other imple= mentations with the biggest loss being *only* those vendor specific pieces.= I have ideas how to do that at the IM / DM layer, but how one does that a= t the transport level is pretty far beyond my thoughts at the moment. >>=20 >> G-003 - remove the final =B3defined=B2 in the paragraph. > [NCW] OK >=20 >>=20 >> G-004 - reword: =B3=8A protocols, transports are suitable to implementa= tions >> are suitable to fit in =8A=B2 Maybe something like: =B3that the data m= odel, >> protocols, and transports are suitably implemented to fit into the >> different deployment models and scenarios.=B2 > [NCW] OK >=20 >>=20 >> G-006 / GN-005: =B3mandatory to implement data attributes=B2 =3D> needs= to be >> changed to get rid of "data attributes=B2 or we need to establish what t= his >> means in terms of the requirements doc. I=B9m fairly certain I understa= nd >> it, but if you ask me while/after building a sacm compliant >> implementation if that is met, I don=B9t think I=B9ll know. We might re= ally >> mean that the info model must have a set of IEs that will be mandatory t= o >> implement in all data models, and systems that support multiple data >> models must support the ability to transparently exchange all mandatory >> to implement IE=B9s across all DM=B9s. (But we didn=B9t say that. :) ) > [NCW] Hmmm=8A.so attributes are defined in the terminology draft=8A.would= you > rather I remove =B3data=B2? >=20 [cmi] That=92s my mistake for not finding the terminology; I looked for = =93data attributes=94 not just attributes. But I=92m still stuck on if tha= t applies more to IM or DM. I=92ll defer to you / the group. I don=92t ha= ve a solution for my discomfort with this requirement, so maybe its really = a fault in me. :) >>=20 >> REQ-002: Does this imply accepting multiple data models (& info models?= ) >> in the =B3SACM protocol=B2? Does this imply how much of SACM is a >> metaprotocol, possibly? Is SACM possibly a way to negotiate various >> disparate protocols (capabilities & versions) and maybe a query / >> response protocol? I think this requirement creates FAR reaching >> implications. How does this requirement fit with G-006 / GN-005 which >> requires an explicit set of mandatory to implement data attributes? > [NCW] I believe so (e.g. There may exist multiple data models) so given > the existence of multiple, we have to put requirements of at least a set > of attributes (or perhaps a data model and the data model includes a MUST > set of attributes) that are mandatory to implement. The negotiation is > part of the discovery in G-013 >=20 [cmi] Okay, I understand what you wrote. I just want to make sure that the= whole group understands this requirement, and its implications. >>=20 >> REQ-006: =B3The query operation may be a synchronous or asynchronous >> request.=B2 First, an IETF comment, is that =B3may=B2 a =B3MAY=B2? Fro= m an >> implementors point of view: OUCH. I would really prefer you pick one or >> both, but settle that THE PROTOCOL/STANDARD *MUST* support some set, but >> IMPLEMENTATIONS *MAY* choose and negotiate. If you don=B9t choose, just >> remove the line from the requirements, it doesn=B9t help anyone in the >> future as it stands now. > [NCW] This is why its left as an uncapped =B3may=B2 as imho SACM can MUST > support for both types of requests. > But the operation could be one or the other, or a task could use both. >=20 >>=20 >> REQ-009: I actually don=B9t understand that requirement. > [NCW] This was the outcome of a WG discussion to ensure that we explicitl= y > stated that the task of collection and doing something with the collected > result could be separable=8A..don=B9t recall the particular use case, but= it > was agreed that it needed to be called out explicitly. >=20 [cmi] I was the one who pushed for the 2 modes of analysis. :) My point, = way back, was that collection should enable (well, really, the standard sho= uld not ``MUST'' enable, but instead, the standard MUST not prevent) storag= e and 2 modes of analytics against the system. (1) Immediate alerting agai= nst a non-compliant attribute (2) retrospective analysis of the state of th= e universe. Immediate alerting on something like ``firewall disabled=92=92= on endpoint seems obvious; but just as obvious to me is: all machines wer= e complaint 3 months ago, but we learn today that complaint software compon= ent X was zero-day targeted 3-months ago. What machines had software X at = version Y starting at 3-months ago to now? >>=20 >> ARCH-001: A little caution on the sizes used, if concrete numbers are >> really desired. If sacm is deployed at Ft. Bragg in the US, it=B9s huma= n >> population is 238,646 >> [http://www.army-technology.com/features/feature-largest-military-bases-= wo >> rld-united-states/]. If each of those folks has a cell phone, a desktop= , >> and 1-2 other devices we=B9re in the millions. If Ft. Bragg implements >> something like an IoT and manages it with sacm, then I think that number >> gets a whole lot higher. I=B9m pretty sure that all the planes, >> helicopters, etc. probably have *at least* 1 IP address each. > [NCW] I=B9m OK saying =8Cvery large=B9, but somehow my notes from the > discussions said that I had to quantify. But I agree that we could group > to the many millions. >=20 >>=20 >> ARCH-004: =B3systems can utilize an already established mutually agreed >> upon native data format, which may be standard or >> implementation-specific=B2. I understand why one might want that statem= ent >> there, but it should be dropped. (1) No one meeting in the sacm room >> could ever prevent this from happening if they wanted to (2) putting thi= s >> in the requirements doesn=B9t help the design of the IM, DM, or any othe= r >> protocols or operations. > [NCW] OK by me. >=20 >>=20 >> IM-009: Please expand the text. (Lisa, I know you explained this, >> verbally, already, but it needs to be written down.) > [NCW] Yes, will likely need to expand on most of the 1 sentence reqmts in > the IM section=8A. >=20 >>=20 >> IM-011: remove =B3- for example=B2. The follow on text is either a >> requirement or not. > {NCW] OK >=20 >>=20 >> IM-014: Does this imply that using sacm protocols the sensors/agents ca= n >> be configured via a sacm initiated request? > [NCW] This again goes back to REQ-009 discussions=8A.but I think its more > prescriptive of the =B3collection task=B2 which I=B9m not sure we want to > explicitly defined? I=B9m not sure it=B9s really in scope for the charter= , but > will have to have Dan, Adam and Kathleen weigh in=8A. >=20 >=20 >>=20 >> IM-015: Does this imply something like a simple calculus that lets me >> logical / arithmetically / statistically define new =B3virtual=B2 readin= gs >> from actual readings? Does this language have to be supported at every >> sensor/agent? Also, we need a firm definition on the =B3point of >> collection=B2. > [NCW] My response is same as above. The intent is to assert that a > request could be comprised of multiple requests, I=B9m not sure we want t= o > be prescriptive of =B3how=B2 in the requirements draft. >=20 >>=20 >> T-002: Reword please. I take it to mean the following: =B3Data Integri= ty: >> For protocols which do not provide for data integrity in the transport >> layer, a sufficient data integrity mechanism MUST be provided." > [NCW] Hmmm=8A.my bad. It is to state that data integrity SHOULD be provi= ded > at the transport layer. >=20 >>=20 >> Security Considerations: I really like this section, especially as >> someone who (in theory at least) does reviews for the security >> directorate. BUT (you knew it was coming,) shouldn=B9t the last 3 >> paragraphs in the security considerations section actually be >> requirements?, say SEC-001, SEC-002, SEC-003? :) > [NCW] Agreed. I=B9m thinking that Requirements don=B9t warrant > =B3considerations=B2 but rather a set of requirements with appropriate > language, e.g. MUST, SHOULD, etc >=20 >>=20 >>=20 >>=20 >> I hope this helps. And I=B9ll see if I can plow through the info model >> this weekend. > [NCW] Many thanks for the thorough review!!! Am working on incorporatin= g > them this week=8A >=20 >>=20 >> Chris >>=20 >> _______________________________________________ >> sacm mailing list >> sacm@ietf.org >> https://www.ietf.org/mailman/listinfo/sacm >=20 From nobody Thu Oct 23 11:03:00 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0465E1ACE44 for ; Thu, 23 Oct 2014 11:02:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g8DRoXIpGSXz for ; Thu, 23 Oct 2014 11:02:56 -0700 (PDT) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A52491A8AD2 for ; Thu, 23 Oct 2014 11:02:56 -0700 (PDT) Received: by mail-pa0-f47.google.com with SMTP id kx10so1510106pab.20 for ; Thu, 23 Oct 2014 11:02:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:date:subject:to:message-id:mime-version; bh=uTOoaFemVj29pF0X3vXFHhlvwxdxxx2A3LzP6Bc1G+4=; b=A3UzNNObKYUN+jeCOT2Tc5L8fuK9q6hCODsKWjfdyWI8jSHSkoZbMne6CrsuuGUnaI +hKp+Yz06ENljtj74fDII+1prRVtRe8JaszgxChBO0qEVzWd3LXvjZTQF993oHN8XVR0 amXo5SiovYV3411eu7mOnQCMjw0i69RQKJkHuzKrIzyBs5DTPep2wk+xh5ht/k++jp+S xywKSvDeNobm27YyRhcXGV96OwJ8H405drB/YtqXETf0m+jkZbGGlrEHcv5LzJiLgY0W cKMlZARqMbvKXrf+solo27xJnims+ErNo6Y0sbLRM9YdkrK2JMbyoyWvVOJm0gwGMaaP 4igQ== X-Received: by 10.66.65.233 with SMTP id a9mr6354738pat.107.1414087376301; Thu, 23 Oct 2014 11:02:56 -0700 (PDT) Received: from ?IPv6:2602:306:3406:4f00:b07a:a28a:435b:2fbc? ([2602:306:3406:4f00:b07a:a28a:435b:2fbc]) by mx.google.com with ESMTPSA id y1sm2013189pbw.89.2014.10.23.11.02.54 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 23 Oct 2014 11:02:55 -0700 (PDT) From: "Adam W. Montville" Content-Type: multipart/alternative; boundary="Apple-Mail=_74AB6ECB-4858-4932-9488-85157F0392E5" Date: Thu, 23 Oct 2014 13:02:53 -0500 To: sacm@ietf.org Message-Id: <2630AB4E-8E68-46AB-84B5-32A2C5D0B883@gmail.com> Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/lN1hmXc5VTATPHzFcgWB3ukcsuc Subject: [sacm] October 2014 Virtual Interim Notes Posted X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2014 18:02:58 -0000 --Apple-Mail=_74AB6ECB-4858-4932-9488-85157F0392E5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 All: I=E2=80=99ve summarized and posted notes for the October Virtual Interim = here: = http://www.ietf.org/proceedings/interim/2014/10/14/sacm/minutes/minutes-in= terim-2014-sacm-5 = . Many thanks to Jim, Nancy, and Lisa for their outstanding notes! As always, if you review the notes and see something that doesn=E2=80=99t = look right, let me know. Regards, Adam= --Apple-Mail=_74AB6ECB-4858-4932-9488-85157F0392E5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 All:

I=E2=80= =99ve summarized and posted notes for the October Virtual Interim = here: http://www.ietf.org/proceedings/interim/2014/10/14/sacm/minutes= /minutes-interim-2014-sacm-5.

Many thanks to Jim, Nancy, and Lisa for = their outstanding notes!

As always, if you review the notes and see something that = doesn=E2=80=99t look right, let me know.

Regards,

Adam
= --Apple-Mail=_74AB6ECB-4858-4932-9488-85157F0392E5-- From nobody Thu Oct 23 11:09:38 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16FF51A8999 for ; Thu, 23 Oct 2014 11:09:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F7sBXIaOB9VM for ; Thu, 23 Oct 2014 11:09:34 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 757981A892C for ; Thu, 23 Oct 2014 11:09:34 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApILAAhESVSHCzIm/2dsb2JhbABcgkgjIyA0WQO5EwYFkzsbAQmHTQKBEhYBAXELhAQBAQMSG14BDAkVViYBBBsBGYgfAQykRoRtn1OGJYoCgm4PRCSBHgWSBZNtjhiDeII0gQMBAQE X-IronPort-AV: E=Sophos; i="5.04,776,1406606400"; d="scan'208,217"; a="91473796" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 23 Oct 2014 14:09:14 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC03.global.avaya.com) ([135.64.58.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES128-SHA; 23 Oct 2014 14:09:13 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC03.global.avaya.com ([135.64.58.13]) with mapi id 14.03.0174.001; Thu, 23 Oct 2014 14:09:12 -0400 From: "Romascanu, Dan (Dan)" To: "sacm@ietf.org" Thread-Topic: sacm wg meetings at ietf-91 - preliminary agenda Thread-Index: Ac/u7HH+wc4Su47wTt6pk1jW2XP/KA== Date: Thu, 23 Oct 2014 18:09:11 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C8DA2C5@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA5C8DA2C5AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/eg-_IAYioCVIPPS8S2ChyC7bSjE Subject: [sacm] sacm wg meetings at ietf-91 - preliminary agenda X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2014 18:09:36 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA5C8DA2C5AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I uploaded a preliminary agenda for the two meetings at IETF-91 at http://w= ww.ietf.org/proceedings/91/agenda/agenda-91-sacm. It is very sketchy, I exp= ect bashing and more content to come in the next few days. Thanks and Regards, Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA5C8DA2C5AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I uploaded a preliminary agenda for the two meetings= at IETF-91 at http:/= /www.ietf.org/proceedings/91/agenda/agenda-91-sacm. It is very sketchy,= I expect bashing and more content to come in the next few days.

 

Thanks and Regards,

 

Dan

 

 

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA5C8DA2C5AZFFEXMB04globa_-- From nobody Fri Oct 24 08:58:09 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95E131A1B4E; Fri, 24 Oct 2014 08:58:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K-PgRnjc84O3; Fri, 24 Oct 2014 08:57:55 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 32F7C1A1B3A; Fri, 24 Oct 2014 08:57:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141024155746.23457.95510.idtracker@ietfa.amsl.com> Date: Fri, 24 Oct 2014 08:57:46 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/cHfpHNgKuv0Xi3L4TWyfnUPnULw Cc: sacm@ietf.org Subject: [sacm] I-D Action: draft-ietf-sacm-information-model-00.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 15:58:06 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Security Automation and Continuous Monitoring Working Group of the IETF. Title : SACM Information Model Authors : David Waltermire Kim Watson Clifford Kahn Lisa Lorenzin Filename : draft-ietf-sacm-information-model-00.txt Pages : 77 Date : 2014-10-24 Abstract: TODO: reconcile (TNC)This document proposes an information model for endpoint posture assessment. It describes the information needed to perform certain assessment activities and to communicate and respond to the assessments.(/TNC) (wandw)This document defines an information model for aggregated configuration and operational data, so that the data can be evaluated to determine an organization's security posture.(/wandw) The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sacm-information-model/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sacm-information-model-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Oct 25 08:21:31 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAAC51A0118; Sat, 25 Oct 2014 08:21:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wT1ZCbHAtH6i; Sat, 25 Oct 2014 08:21:22 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D55541A00D8; Sat, 25 Oct 2014 08:21:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141025152122.24379.82244.idtracker@ietfa.amsl.com> Date: Sat, 25 Oct 2014 08:21:22 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/OSWOiym0c9DeR1RptE2hLSceGyQ Cc: sacm@ietf.org Subject: [sacm] I-D Action: draft-ietf-sacm-requirements-02.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Oct 2014 15:21:26 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Security Automation and Continuous Monitoring Working Group of the IETF. Title : Secure Automation and Continuous Monitoring (SACM) Requirements Authors : Nancy Cam-Winget Lisa Lorenzin Filename : draft-ietf-sacm-requirements-02.txt Pages : 12 Date : 2014-10-24 Abstract: This document defines the scope and set of requirements for the Secure Automation and Continuous Monitoring working group. The requirements and scope are based on the agreed upon use cases. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sacm-requirements/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sacm-requirements-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-sacm-requirements-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Oct 31 14:29:36 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C77EA1A1BC4 for ; Fri, 31 Oct 2014 14:29:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TpqqnHPDlWUp for ; Fri, 31 Oct 2014 14:29:33 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08BDC1A1BED for ; Fri, 31 Oct 2014 14:29:13 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMLAHD+U1SHCzIm/2dsb2JhbABcgkgjI1RcuWcGk0GHTQKBGRYBAQEBAQFxC4QEAQEDEhteAQwJFVYmAQQbGogfAQymbYRxn0UBCgEBARoEhjeKKC2DOIEeBZIVhE2IR4NKgx6OL4N4gjSBAwEBAQ X-IronPort-AV: E=Sophos; i="5.07,295,1413259200"; d="scan'208,217"; a="78946798" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by de307622-de-outbound.net.avaya.com with ESMTP; 31 Oct 2014 17:29:11 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES128-SHA; 31 Oct 2014 17:29:10 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC02.global.avaya.com ([135.64.58.12]) with mapi id 14.03.0174.001; Fri, 31 Oct 2014 22:29:09 +0100 From: "Romascanu, Dan (Dan)" To: "sacm@ietf.org" Thread-Topic: final IETF-91 agenda due Monday 11/3! Thread-Index: Ac/1UbPyRKS0rA24SsS9KNN6Vo7bbw== Date: Fri, 31 Oct 2014 21:29:08 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C8E6D57@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA5C8E6D57AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/4J44nF9Xm8KQR9AUpzmgcpZp0oM Subject: [sacm] final IETF-91 agenda due Monday 11/3! X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 21:29:35 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA5C8E6D57AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The preliminary agenda of the meetings at IETF-91 is available at https://d= atatracker.ietf.org/meeting/91/agenda/sacm/. The final agenda is due Monday= 11/3. Please let us know if there are any missing items or changes you wan= t to bring to the agenda. Thanks and Regards, Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA5C8E6D57AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The preliminary agenda of the meetings at IETF-91 is= available at https://da= tatracker.ietf.org/meeting/91/agenda/sacm/. The final agenda is due Mon= day 11/3. Please let us know if there are any missing items or changes you = want to bring to the agenda.

 

Thanks and Regards,

 

Dan

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA5C8E6D57AZFFEXMB04globa_-- From nobody Fri Oct 31 15:49:40 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88C451A8549 for ; Fri, 31 Oct 2014 15:49:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.512 X-Spam-Level: X-Spam-Status: No, score=-5.512 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t_V1IdiExobz for ; Fri, 31 Oct 2014 15:49:34 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B79F1A70FE for ; Fri, 31 Oct 2014 15:49:34 -0700 (PDT) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s9VMnXZ7013724 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Fri, 31 Oct 2014 18:49:33 -0400 Received: from Shawns-MacBook-Air.local (vpn-58-70.rdu2.redhat.com [10.10.58.70]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s9VMnWkp007238 for ; Fri, 31 Oct 2014 18:49:32 -0400 Message-ID: <545411FC.4060503@redhat.com> Date: Fri, 31 Oct 2014 18:49:32 -0400 From: Shawn Wells User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: sacm@ietf.org References: <9904FB1B0159DA42B0B887B7FA8119CA5C8E6D57@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA5C8E6D57@AZ-FFEXMB04.global.avaya.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/8S91NWfiiQb8IuncxE917LbGz7U Subject: [sacm] How do I engage with SACM? X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 22:49:37 -0000 Hello, By way of introduction, I work for Red Hat where I collaborate with governments and industries on security standards. Sometimes this is policy work (ICD 503, starting to get involved in NIAPs cPP's) while other times it's creating SCAP content and helping form standardized baselines (e.g. STIGs and USGCB). In attending a SCAP Developer workshop at MITRE a month(ish) ago, I met Adam and others who pointed me to the SACM working group as a place to further Continuous Monitoring standards. After being on the mailing list for a month(ish), I'm still not really sure how to engage in a meaningful way. I've read the charter [1] but noticed there are no future milestones planned. I've read through the various documents [2] but there isn't guidance on how to contribute to them, submit patches, etc. How does one become engaged with SACM? Is there a code repository where patches can be submitted against the information model, requirements, and use case docs? Where can I find out on work planned, or even better, where can I submit ideas? There hasn't been much traffic on the mailing list, leading me to believe I may just be looking in the wrong places. On the mailing list I've seen some EMails on "hey, there's a new draft!" but I'm still searching for the conversations that drive that draft, and how to participate in it (through driving ideas, authoring sections, etc). Thanks for any pointers! Shawn [1] https://datatracker.ietf.org/wg/sacm/charter/ [2] https://datatracker.ietf.org/wg/sacm/documents/ From nobody Fri Oct 31 15:58:15 2014 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 554341A86F7 for ; Fri, 31 Oct 2014 15:58:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tYq5MbmX_Zk5 for ; Fri, 31 Oct 2014 15:58:11 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1090E1A86F5 for ; Fri, 31 Oct 2014 15:58:10 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoLABgTVFSHCzIm/2dsb2JhbABcgmsjVFMJuRhPBpMfHQqHTQKBFRYBAQEBAQF8hAIBAQEBAwEBAQ8oNBcEAgEIDQQEAQELFAkHJwsUCQgCBAESCAEZiB8BBwWrLp9CAQEBAQEBAQECAQEBAQEBAQEBAQEXhjeKCAEBHjMFBoIwUySBHgWGeosehE+IR4NNgx8Shm9FgmGECYN4bAGBDjmBAwEBAQ X-IronPort-AV: E=Sophos;i="5.07,295,1413259200"; d="scan'208";a="90144942" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by co300216-co-outbound.net.avaya.com with ESMTP; 31 Oct 2014 18:58:09 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES128-SHA; 31 Oct 2014 18:58:09 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC01.global.avaya.com ([135.64.58.11]) with mapi id 14.03.0174.001; Fri, 31 Oct 2014 23:58:07 +0100 From: "Romascanu, Dan (Dan)" To: Shawn Wells , "sacm@ietf.org" Thread-Topic: [sacm] How do I engage with SACM? Thread-Index: AQHP9Vz27z/MKYhRp02oJ8LWpug1YpxKz6Ow Date: Fri, 31 Oct 2014 22:58:07 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C8E6E3A@AZ-FFEXMB04.global.avaya.com> References: <9904FB1B0159DA42B0B887B7FA8119CA5C8E6D57@AZ-FFEXMB04.global.avaya.com> <545411FC.4060503@redhat.com> In-Reply-To: <545411FC.4060503@redhat.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sacm/qMQauwuH2nxboGOIz3Kld8rCKh8 Subject: Re: [sacm] How do I engage with SACM? X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 22:58:13 -0000 Hi Shawn,=20 Welcome.=20 One reading that you may find useful is http://www.ietf.org/tao.html.=20 You can contribute in many ways to the work in SACM (and this is true for o= ther WGs).=20 - submit comments to the WG documents on the mail list - attend the meetings - we have f2f meetings three times a year (the closes= t one is very soon - http://www.ietf.org/meeting/91/index.html) and virtual= meetings which are announced several weeks on advance - submit your own contributions as individual submission Internet-Drafts; t= here is no need for a preliminary discussion, however it would be good to r= ead archives and other WG documents to make sure that your proposals are wi= thin the WG scope and are not duplicating existing work;=20 The milestones in the charter need an update. This issue is on the agenda o= f the WG meeting at IETF-91. We are also looking into using a tracker tool for keeping track of comments= and issues. Also on the agenda of the WG meeting at IETF-91.=20 I hope that this helps. Please do not hesitate to ask other questions.=20 Regards, Dan (one of the SACM WG co-chairs) > -----Original Message----- > From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Shawn Wells > Sent: Saturday, November 01, 2014 12:50 AM > To: sacm@ietf.org > Subject: [sacm] How do I engage with SACM? >=20 > Hello, >=20 > By way of introduction, I work for Red Hat where I collaborate with > governments and industries on security standards. Sometimes this is polic= y > work (ICD 503, starting to get involved in NIAPs cPP's) while other times= it's > creating SCAP content and helping form standardized baselines (e.g. STIGs > and USGCB). In attending a SCAP Developer workshop at MITRE a month(ish) > ago, I met Adam and others who pointed me to the SACM working group as a > place to further Continuous Monitoring standards. >=20 > After being on the mailing list for a month(ish), I'm still not reall= y sure how > to engage in a meaningful way. I've read the charter [1] but noticed ther= e are > no future milestones planned. I've read through the various documents [2] > but there isn't guidance on how to contribute to them, submit patches, et= c. >=20 > How does one become engaged with SACM? Is there a code repository > where patches can be submitted against the information model, > requirements, and use case docs? Where can I find out on work planned, or > even better, where can I submit ideas? There hasn't been much traffic on > the mailing list, leading me to believe I may just be looking in the wron= g > places. On the mailing list I've seen some EMails on "hey, there's a new > draft!" but I'm still searching for the conversations that drive that dra= ft, and > how to participate in it (through driving ideas, authoring sections, etc)= . >=20 > Thanks for any pointers! >=20 > Shawn >=20 > [1] https://datatracker.ietf.org/wg/sacm/charter/ > [2] https://datatracker.ietf.org/wg/sacm/documents/ >=20 > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm