From nobody Fri Dec 2 09:47:43 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7788A1297E7 for ; Fri, 2 Dec 2016 09:47:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.417 X-Spam-Level: X-Spam-Status: No, score=-17.417 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 gr83pWOepFwS for ; Fri, 2 Dec 2016 09:47:35 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B42C12971E for ; Fri, 2 Dec 2016 09:47:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6550; q=dns/txt; s=iport; t=1480700840; x=1481910440; h=subject:references:to:from:message-id:date:mime-version: in-reply-to; bh=URAYlGFqZH6OOMCFEW98vW66BjdOZJQshcL60SIUTOE=; b=Uq9VuSbWauM3j8rMndPXmubi/+6niP4vtsFVS+LyiHVRkJnNQU8bVcFR aaXtDaBYXt7uDEaiQEfGeCQVrEDEaV/MUS8tZv617a6NXPPWpjTCB6qEe 1RR5O3NQPtyA8zFFhP5iMPvwNWT6bJ1aiAU5vAktoeO6VByTje0T5qFqp Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ChAgBgs0FY/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzgBAQEBAXmBBqRRj1qFIoIGHgEKhXkCglsSAQIBAQEBAQEBYh0?= =?us-ascii?q?LhGgBAQEEAQEhSxscAwECAScDAgInHwcCCAYNBgIBAYhrDqwtgikviwEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEaBYY+gX2CXoRpgiw4gj8eBZR6hWmRFIoNhiyKHoNihA0?= =?us-ascii?q?mAi54Ew4jhTM9NIh+AQEB?= X-IronPort-AV: E=Sophos;i="5.33,287,1477958400"; d="scan'208,217";a="650403577" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Dec 2016 17:47:18 +0000 Received: from [10.60.67.90] (ams-bclaise-8919.cisco.com [10.60.67.90]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id uB2HlHsu023238 for ; Fri, 2 Dec 2016 17:47:18 GMT References: To: "supa@ietf.org" From: Benoit Claise X-Forwarded-Message-Id: Message-ID: <078ab961-132b-e0ad-4f92-7d741b62cf25@cisco.com> Date: Fri, 2 Dec 2016 18:47:15 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------AF0CC48B7E53E93542393F3F" Archived-At: Subject: [Supa] Fwd: Re: [yang-doctors] AUGEMNTATION AND ENUMERATIONS X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is to discuss SUPA \(Simplified Use of Policy Abstractions\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 17:47:41 -0000 This is a multi-part message in MIME format. --------------AF0CC48B7E53E93542393F3F Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit FYI. Regards, Benoit -------- Forwarded Message -------- Subject: Re: [yang-doctors] AUGEMNTATION AND ENUMERATIONS Date: Fri, 18 Nov 2016 05:17:15 +0000 From: Andy Bierman To: Benoit Claise , Bert Wijnen (IETF) , YANG Doctors Yes By design only identities can be extended from another module Enumerated can be extended in a new version of the original module Andy On Fri, Nov 18, 2016 at 12:43 Benoit Claise > wrote: On 11/18/2016 12:33 PM, Bert Wijnen (IETF) wrote: > Hi, I am sitting here in the SUPA WG and the > > discussion is thet ENUMS are not extensible via AUGMENTATION. NEW: discussion is thet ENUMS are not extensible via AUGMENTATION in submodules. Regards, Benoit > > So They used Identities instead. > > Is this indeed the only way, and if so, is this > > an acceptable approach? > > Bert > > > _______________________________________________ > yang-doctors mailing list > yang-doctors@ietf.org > https://www.ietf.org/mailman/listinfo/yang-doctors > . > _______________________________________________ yang-doctors mailing list yang-doctors@ietf.org https://www.ietf.org/mailman/listinfo/yang-doctors --------------AF0CC48B7E53E93542393F3F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit FYI.

Regards, Benoit


-------- Forwarded Message --------
Subject: Re: [yang-doctors] AUGEMNTATION AND ENUMERATIONS
Date: Fri, 18 Nov 2016 05:17:15 +0000
From: Andy Bierman <andy@yumaworks.com>
To: Benoit Claise <bclaise@cisco.com>, Bert Wijnen (IETF) <bwietf@bwijnen.net>, YANG Doctors <yang-doctors@ietf.org>


Yes By design only identities can be extended from another module Enumerated can be extended in a new version of the original module Andy

On Fri, Nov 18, 2016 at 12:43 Benoit Claise <bclaise@cisco.com> wrote:
On 11/18/2016 12:33 PM, Bert Wijnen (IETF) wrote:
> Hi, I am sitting here in the SUPA WG and the
>
> discussion is thet ENUMS are not extensible via AUGMENTATION.
NEW: discussion is thet ENUMS are not extensible via AUGMENTATION in
submodules.

Regards, Benoit
>
> So They used Identities instead.
>
> Is this indeed the only way, and if so, is this
>
> an acceptable approach?
>
> Bert
>
>
> _______________________________________________
> yang-doctors mailing list
> yang-doctors@ietf.org
> https://www.ietf.org/mailman/listinfo/yang-doctors
> .
>

_______________________________________________
yang-doctors mailing list
yang-doctors@ietf.org
https://www.ietf.org/mailman/listinfo/yang-doctors
--------------AF0CC48B7E53E93542393F3F-- From nobody Fri Dec 16 07:18:38 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84AD3129677; Fri, 16 Dec 2016 07:18:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.418 X-Spam-Level: X-Spam-Status: No, score=-17.418 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 aXbOczNU5WkL; Fri, 16 Dec 2016 07:18:34 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAC881295F3; Fri, 16 Dec 2016 07:18:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4306; q=dns/txt; s=iport; t=1481901514; x=1483111114; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=E/TrqtUpNrUoaliZVm4ym72DRb1FihqnjbwEbcRhxbs=; b=L4AzH7JJZR5VE9er77agRjdtNcRN98lpKz+vWGVDCo8++kdNOOHsSDCo PUyoWplyKU6wYp+QFjiCLlUPeAveda2yY99ZPi3E1ZgErP3Twxwe9PEBC F2DjvFOIiZQ9LZRqcWTqIIXUCn18uk/puEHhHDJJ0Vk9vcElpJuzcm4uV U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AcAQC1A1RY/xbLJq1dDgsBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM3AQEBAQF5LliNTnOVZZUNggkfC4V4AoJVFAECAQEBAQEBAWI?= =?us-ascii?q?ohGgBAQEEAQEQJjYLDAQLEQQBAQEnBycfCQgGAQwGAgEBHohJDpodAZAeixcBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEYBYY2gX0IglSKIQEEmnCJZIdRAoFyhQODJ4Y?= =?us-ascii?q?vijSDZYQPHzeBARMOKYNZF4EiPD00iH0BAQE?= X-IronPort-AV: E=Sophos;i="5.33,358,1477958400"; d="scan'208";a="647943061" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Dec 2016 15:18:31 +0000 Received: from [10.60.67.91] (ams-bclaise-89110.cisco.com [10.60.67.91]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id uBGFIVXB007679; Fri, 16 Dec 2016 15:18:31 GMT To: "Joel M. Halpern" , "Bert Wijnen (IETF)" , Georgios Karagiannis , Nevil Brownlee , "draft-cheng-supa-applicability@ietf.org" References: <7daae66b-1a6b-5591-8818-75ae1d7139a3@joelhalpern.com> From: Benoit Claise Message-ID: <19955746-00cd-7965-b44e-b65c8601df2f@cisco.com> Date: Fri, 16 Dec 2016 16:18:30 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <7daae66b-1a6b-5591-8818-75ae1d7139a3@joelhalpern.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: SUPA list Subject: Re: [Supa] We need some good examples of what SUPA can do ! X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is to discuss SUPA \(Simplified Use of Policy Abstractions\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2016 15:18:36 -0000 On 11/23/2016 3:33 PM, Joel M. Halpern wrote: > To some degree Bert, you are demonstrating the limitations of the > directive from the AD that SUPA is to use only ECA policies, not > declarative. Modeling the policy goal would be much easier. Ok. OLD: ensures that SNMP is blocked on ports at the edge of the administrative domain to prevent SNMP going out or coming in from outside the enterprise. NEW: send a (syslog/whatever) message if SNMP traffic is going out or coming in from outside the enterprise Let's walk before we run. Regards, B. > > I do believe that with a few extra definitions, we can create a set of > meaningful events to trigger. Mostly the insertion of ports at the > edge of the domain. And then the actions will be to create the filter > rules to block SNMP in both directions. > > I will be working with John to work out the exact modeling. > > Yours, > Joel > > On 11/23/16 5:54 AM, Bert Wijnen (IETF) wrote: >> On 23/11/2016 10:56, Georgios Karagiannis wrote: >>> Hi Bert, >>> >>> Thanks for your input. >>> Please note that I agree with Joel that the input is useful. >>> Can you please provide more details on what will be the Event >>> Condition Action? >> well, is that not my exact question? >> >> I am asking what ECA policies need to be setup/defined in order to >> achieve/effectuate a policy that >> >> ensures that SNMP is blocked on ports at the edge >> of the administrative domain to prevent SNMP going >> out or coming in from outside the enterprise. >> >> Bert >>> Best regards, >>> Georgios >>> >>> >>> -----Original Message----- >>> From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of Joel M. Halpern >>> Sent: Friday, November 18, 2016 2:45 AM >>> To: Bert Wijnen (IETF); Nevil Brownlee; >>> draft-cheng-supa-applicability@ietf.org >>> Cc: SUPA list >>> Subject: Re: [Supa] We need some good examples of what SUPA can do ! >>> >>> Thank you Bert. That is exactly the kind of request I am looking for. >>> >>> No, I do not think it will be simple to answer your question. But I >>> do think that showing how to do so will show both what we have and >>> what more we need. >>> >>> Yours, >>> Joel >>> >>> On 11/17/16 8:28 PM, Bert Wijnen (IETF) wrote: >>>> Could the proponets of the current (in my view still complex) IM and >>>> DM work out how one would define/configure/populate the policies for: >>>> >>>> ensure that SNMP is blocked on ports at the edge >>>> of the administrative domain to prevent SNMP going >>>> out or coming in from outside the enterprise. >>>> >>>> This should be simple, no? >>>> >>>> Thanks, Bert >>>> >>>> On 17/11/2016 18:31, Nevil Brownlee wrote: >>>>> Hi all: >>>>> >>>>> Your SUPA chairs met this morning with some of the SUPA I-D authors >>>>> to consider "how can we get people working on some simple examples to >>>>> demonstrate how SUPA could be used." >>>>> >>>>> One idea we considered was "we need a few good example uses, with >>>>> clear specs written for each - we could start with the examples in >>>>> our (draft) Applicability Statement. That considers five examples - >>>>> >>>>> 4.1. Use Case 1: Switched Ethernet services (SES) >>>>> 4.2. Use Case 2: Virtualized Private Clouds (VPC) >>>>> 4.3. Use Case 3: Traffic Manipulation cross DCs >>>>> 4.4. Use Case 4: Virtual SP >>>>> 4.5. Use Case 5: Instant VPN >>>>> 4.6. Use Case 6: traffic optimization and Qos assurance on ISP DC >>>>> >>>>> It would help SUPA a lot to have input, especially from network >>>>> operators, telling us "what do you actually want (SUPA to) do?" >>>>> >>>>> Do please give this some thought, and send your 'wishes' text to the >>>>> SUPA list! >>>>> >>>>> Cheers, Nevil >>>>> >>>> _______________________________________________ >>>> Supa mailing list >>>> Supa@ietf.org >>>> https://www.ietf.org/mailman/listinfo/supa >>>> >>> _______________________________________________ >>> Supa mailing list >>> Supa@ietf.org >>> https://www.ietf.org/mailman/listinfo/supa >>> >> > > _______________________________________________ > Supa mailing list > Supa@ietf.org > https://www.ietf.org/mailman/listinfo/supa > . > From nobody Fri Dec 16 07:23:17 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B5E5129596 for ; Fri, 16 Dec 2016 07:23:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.418 X-Spam-Level: X-Spam-Status: No, score=-17.418 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 6ecYLUjRmxBo for ; Fri, 16 Dec 2016 07:23:14 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DCEF129673 for ; Fri, 16 Dec 2016 07:23:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=614; q=dns/txt; s=iport; t=1481901794; x=1483111394; h=to:from:subject:message-id:date:mime-version: content-transfer-encoding; bh=nRot5oxdue/piHjInqmDJJtJzzlFIYvbgqhNmycn1OM=; b=UiXxa5MzNyxDtIGhyIu+fyG7EDbDG4iL7ScF1zjAIWUHnvMO/17wsZXS YNX5aajbu19b8h9GTPqT7SFHs8b+ItgoNct3HhTDqW/UK4T1jIUaLAWI8 9tamHuDd+fQzBV+TB6NSMyGJkvCkVJAy1vz05Q37CCr00/Xa/WM92Q2LF g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CyBgAsBlRY/xbLJq1EGhwBAQQBAQoBA?= =?us-ascii?q?YM3AQEBAQF5LlgBjU1zqGOCD4IJKohPFAECAQEBAQEBAWIdC0IOhDERFXYCJgJ?= =?us-ascii?q?fDQgBAR6ISQ4ul2eCCQGNdoIoixcBMYELhSuBfYoggl0FmnCGUopjgV1oh1mGL?= =?us-ascii?q?4lnTYd0HzeBARMOhXc9NIRGhDcBAQE?= X-IronPort-AV: E=Sophos;i="5.33,358,1477958400"; d="scan'208";a="647943127" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Dec 2016 15:23:10 +0000 Received: from [10.60.67.91] (ams-bclaise-89110.cisco.com [10.60.67.91]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id uBGFNAYK030752 for ; Fri, 16 Dec 2016 15:23:10 GMT To: "supa@ietf.org" From: Benoit Claise Message-ID: <94be5dc4-350f-c32b-9de7-04fa60bf5551@cisco.com> Date: Fri, 16 Dec 2016 16:23:09 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Supa] SUPA success X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is to discuss SUPA \(Simplified Use of Policy Abstractions\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2016 15:23:16 -0000 Dear all, As I mentioned a few times, reading the charter: "The working group will have succeeded when the SUPA policy constructs are re-used in future IETF specifications (and ideally specifications from other SDOs)" During the IETF hackathon, Joe Clark developed a YANG impact analysis tool. So we have http://yangcatalog.org/yang-search/impact_analysis.php?modules[]=ietf-supa-policy&recurse=0&rfcs=1, which is a good metric for the SUP success. Conclusion so far (which is fine at this point in time, but we should focus on this): the ietf-supa-policy is not yet reused. Regards, Benoit From nobody Fri Dec 16 08:59:49 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B6501293E0; Fri, 16 Dec 2016 08:59:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com 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 OokbFYwwRCKE; Fri, 16 Dec 2016 08:59:46 -0800 (PST) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 3375B1298D5; Fri, 16 Dec 2016 08:59:46 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 1A24A26843B; Fri, 16 Dec 2016 08:59:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1481907586; bh=iyUz8ZqUUXbdh1qNKGypw/XZlKULomG0ptzG5l9RS+M=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=jXS12ppL8FL7lQaDpSzCpsvVfzoFur+QC2SOH+hapiAzBZMM5pFMgsNHrQKKuOZT2 z6XjXQHM0Zllh7BxlqhbXO/gFv+yZZOnDQBD6PWX1AlMASmz4ei4HjT1vXRlAAPsGC EqbgTOqFK5RVxRbs3Ck7pmezaqjCD5JYhwXqJUPk= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 26E00250B3D; Fri, 16 Dec 2016 08:59:45 -0800 (PST) To: Benoit Claise , "Joel M. Halpern" , "Bert Wijnen (IETF)" , Georgios Karagiannis , Nevil Brownlee , "draft-cheng-supa-applicability@ietf.org" References: <7daae66b-1a6b-5591-8818-75ae1d7139a3@joelhalpern.com> <19955746-00cd-7965-b44e-b65c8601df2f@cisco.com> From: "Joel M. Halpern" Message-ID: <4fa6f4ec-4489-07b7-3b98-8216c5da0ea7@joelhalpern.com> Date: Fri, 16 Dec 2016 11:59:44 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <19955746-00cd-7965-b44e-b65c8601df2f@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: SUPA list Subject: Re: [Supa] We need some good examples of what SUPA can do ! X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is to discuss SUPA \(Simplified Use of Policy Abstractions\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2016 16:59:48 -0000 Thanks Benoit. I do not think that (block vs send syslog) is the hard part of the case. I think we can address the proposed case. In discussing it with John, we found that there were actually two different use cases in there. We are putting together enough explanation to send to the WG on the approach we think works, building on the SUPA model, to address these cases. We will an email out soon. Yours, Joel On 12/16/16 10:18 AM, Benoit Claise wrote: > On 11/23/2016 3:33 PM, Joel M. Halpern wrote: >> To some degree Bert, you are demonstrating the limitations of the >> directive from the AD that SUPA is to use only ECA policies, not >> declarative. Modeling the policy goal would be much easier. > Ok. > > OLD: > ensures that SNMP is blocked on ports at the edge > of the administrative domain to prevent SNMP going > out or coming in from outside the enterprise. > > NEW: > send a (syslog/whatever) message if SNMP traffic is going out or > coming in from outside the enterprise > > Let's walk before we run. > > Regards, B. >> >> I do believe that with a few extra definitions, we can create a set of >> meaningful events to trigger. Mostly the insertion of ports at the >> edge of the domain. And then the actions will be to create the filter >> rules to block SNMP in both directions. >> >> I will be working with John to work out the exact modeling. >> >> Yours, >> Joel >> >> On 11/23/16 5:54 AM, Bert Wijnen (IETF) wrote: >>> On 23/11/2016 10:56, Georgios Karagiannis wrote: >>>> Hi Bert, >>>> >>>> Thanks for your input. >>>> Please note that I agree with Joel that the input is useful. >>>> Can you please provide more details on what will be the Event >>>> Condition Action? >>> well, is that not my exact question? >>> >>> I am asking what ECA policies need to be setup/defined in order to >>> achieve/effectuate a policy that >>> >>> ensures that SNMP is blocked on ports at the edge >>> of the administrative domain to prevent SNMP going >>> out or coming in from outside the enterprise. >>> >>> Bert >>>> Best regards, >>>> Georgios >>>> >>>> >>>> -----Original Message----- >>>> From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of Joel M. Halpern >>>> Sent: Friday, November 18, 2016 2:45 AM >>>> To: Bert Wijnen (IETF); Nevil Brownlee; >>>> draft-cheng-supa-applicability@ietf.org >>>> Cc: SUPA list >>>> Subject: Re: [Supa] We need some good examples of what SUPA can do ! >>>> >>>> Thank you Bert. That is exactly the kind of request I am looking for. >>>> >>>> No, I do not think it will be simple to answer your question. But I >>>> do think that showing how to do so will show both what we have and >>>> what more we need. >>>> >>>> Yours, >>>> Joel >>>> >>>> On 11/17/16 8:28 PM, Bert Wijnen (IETF) wrote: >>>>> Could the proponets of the current (in my view still complex) IM and >>>>> DM work out how one would define/configure/populate the policies for: >>>>> >>>>> ensure that SNMP is blocked on ports at the edge >>>>> of the administrative domain to prevent SNMP going >>>>> out or coming in from outside the enterprise. >>>>> >>>>> This should be simple, no? >>>>> >>>>> Thanks, Bert >>>>> >>>>> On 17/11/2016 18:31, Nevil Brownlee wrote: >>>>>> Hi all: >>>>>> >>>>>> Your SUPA chairs met this morning with some of the SUPA I-D authors >>>>>> to consider "how can we get people working on some simple examples to >>>>>> demonstrate how SUPA could be used." >>>>>> >>>>>> One idea we considered was "we need a few good example uses, with >>>>>> clear specs written for each - we could start with the examples in >>>>>> our (draft) Applicability Statement. That considers five examples - >>>>>> >>>>>> 4.1. Use Case 1: Switched Ethernet services (SES) >>>>>> 4.2. Use Case 2: Virtualized Private Clouds (VPC) >>>>>> 4.3. Use Case 3: Traffic Manipulation cross DCs >>>>>> 4.4. Use Case 4: Virtual SP >>>>>> 4.5. Use Case 5: Instant VPN >>>>>> 4.6. Use Case 6: traffic optimization and Qos assurance on ISP DC >>>>>> >>>>>> It would help SUPA a lot to have input, especially from network >>>>>> operators, telling us "what do you actually want (SUPA to) do?" >>>>>> >>>>>> Do please give this some thought, and send your 'wishes' text to the >>>>>> SUPA list! >>>>>> >>>>>> Cheers, Nevil >>>>>> >>>>> _______________________________________________ >>>>> Supa mailing list >>>>> Supa@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/supa >>>>> >>>> _______________________________________________ >>>> Supa mailing list >>>> Supa@ietf.org >>>> https://www.ietf.org/mailman/listinfo/supa >>>> >>> >> >> _______________________________________________ >> Supa mailing list >> Supa@ietf.org >> https://www.ietf.org/mailman/listinfo/supa >> . >> > From nobody Fri Dec 16 09:32:58 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F3581279EB for ; Fri, 16 Dec 2016 09:32:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com 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 wdZCuwzQRhK5 for ; Fri, 16 Dec 2016 09:32:55 -0800 (PST) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 06D4A1294B6 for ; Fri, 16 Dec 2016 09:32:55 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id E56152686BD; Fri, 16 Dec 2016 09:32:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1481909574; bh=uH5uT6aUCusCsbDJAEViIRO3FUovOEWD4fwJSDwm1C8=; h=Subject:To:References:From:Date:In-Reply-To:From; b=GA7LyPZHOoU9KF2OuTrzjHGKBRNa7APoCgLOclgNn6OXeM/s1nj0pCVdeSq87Z9aQ vraw/GCqrObFq9T8ApfP63MSQvFyEiQQGjR+vzUigiWwhDI1ZVhjUkRrBm3rISztFu COtaVO7NIt3t8DTSUrNVGM0uJcQhlzvATTy65Hmk= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id BF66D241553; Fri, 16 Dec 2016 09:32:53 -0800 (PST) To: Benoit Claise , "supa@ietf.org" References: <94be5dc4-350f-c32b-9de7-04fa60bf5551@cisco.com> From: "Joel M. Halpern" Message-ID: <6ed59f4e-48da-8747-5fd5-dc290a0cec62@joelhalpern.com> Date: Fri, 16 Dec 2016 12:32:50 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <94be5dc4-350f-c32b-9de7-04fa60bf5551@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Supa] SUPA success X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is to discuss SUPA \(Simplified Use of Policy Abstractions\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2016 17:32:56 -0000 While your statement is true, it seems a bit odd. Since we have not yet add the ECA data model elements to the SUPA DM, it would have been a bit hard for anyone to use it up till now. Even when we add such, I expect people will want some indication from the WG that it is stable before they will use it. (And I as xo-author can not ask for any such indication until we have given the WG the YANG, and gien enough examples for folks to see how it works.) Yours, Joel On 12/16/16 10:23 AM, Benoit Claise wrote: > Dear all, > > As I mentioned a few times, reading the charter: "The working group will > have succeeded when the SUPA policy constructs are re-used in future > IETF specifications (and ideally specifications from other SDOs)" > > During the IETF hackathon, Joe Clark developed a YANG impact analysis tool. > So we have > http://yangcatalog.org/yang-search/impact_analysis.php?modules[]=ietf-supa-policy&recurse=0&rfcs=1, > which is a good metric for the SUP success. Conclusion so far (which is > fine at this point in time, but we should focus on this): the > ietf-supa-policy is not yet reused. > > Regards, Benoit > > > > _______________________________________________ > Supa mailing list > Supa@ietf.org > https://www.ietf.org/mailman/listinfo/supa > From nobody Mon Dec 19 13:23:55 2016 Return-Path: X-Original-To: supa@ietf.org Delivered-To: supa@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A7A312965F; Mon, 19 Dec 2016 13:23:53 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148218263301.12862.2723498559630894814.idtracker@ietfa.amsl.com> Date: Mon, 19 Dec 2016 13:23:53 -0800 Archived-At: Cc: bclaise@cisco.com, supa-chairs@ietf.org, supa@ietf.org, rfc-ise@rfc-editor.org Subject: [Supa] supa - New Meeting Session Request for IETF 98 X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.17 List-Id: "This list is to discuss SUPA \(Simplified Use of Policy Abstractions\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2016 21:23:53 -0000 A new meeting session request has just been submitted by Nevil Brownlee, a Chair of the supa working group. --------------------------------------------------------- Working Group Name: Simplified Use of Policy Abstractions Area Name: Operations and Management Area Session Requester: Nevil Brownlee Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 75 Conflicts to Avoid: First Priority: lime i2nsf netmod opsarea opsawg sdnrg pce Second Priority: rtgarea rtgwg i2rs Special Requests: ---------------------------------------------------------