From nobody Mon Jul 3 06:59:56 2017 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 2C47A131628; Mon, 3 Jul 2017 06:59:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: supa@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149909039414.4017.3763247270248594953@ietfa.amsl.com> Date: Mon, 03 Jul 2017 06:59:54 -0700 Archived-At: Subject: [Supa] I-D Action: draft-ietf-supa-policy-based-management-framework-02.txt X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.22 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, 03 Jul 2017 13:59:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Simplified Use of Policy Abstractions of the IETF. Title : SUPA Policy-based Management Framework Authors : Will(Shucheng) Liu Chongfeng Xie John Strassner Georgios Karagiannis Maxim Klyus Jun Bi Filename : draft-ietf-supa-policy-based-management-framework-02.txt Pages : 15 Date : 2017-07-03 Abstract: Simplified Use of Policy Abstractions (SUPA) defines base YANG data models to encode policy, which point to device-, technology-, and service-specific YANG models developed elsewhere. Policy rules within an operator's environment can be used to express high-level, possibly network-wide policies to a network management function (within a controller, an orchestrator, or a network element). The network management function can then control the configuration and/or monitoring of network elements and services. This document describes the SUPA basic framework, its elements and interfaces. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-supa-policy-based-management-framework/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-supa-policy-based-management-framework-02 https://datatracker.ietf.org/doc/html/draft-ietf-supa-policy-based-management-framework-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-supa-policy-based-management-framework-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 Mon Jul 3 07:00:50 2017 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 E549B131629; Mon, 3 Jul 2017 07:00:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 Ywm8mxGrjz7G; Mon, 3 Jul 2017 07:00:46 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD85E13164D; Mon, 3 Jul 2017 07:00:18 -0700 (PDT) Received: from 172.18.7.190 (EHLO LHREML710-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DQI01727; Mon, 03 Jul 2017 14:00:16 +0000 (GMT) Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by LHREML710-CAH.china.huawei.com (10.201.108.33) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 3 Jul 2017 15:00:15 +0100 Received: from DGGEML403-HUB.china.huawei.com (10.3.17.33) by nkgeml414-hub.china.huawei.com (10.98.56.75) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 3 Jul 2017 22:00:12 +0800 Received: from DGGEML510-MBX.china.huawei.com ([169.254.2.202]) by DGGEML403-HUB.china.huawei.com ([fe80::74d9:c659:fbec:21fa%31]) with mapi id 14.03.0301.000; Mon, 3 Jul 2017 22:00:09 +0800 From: "Liushucheng (Will Liu)" To: Marc Blanchet CC: "draft-ietf-supa-policy-based-management-framework@ietf.org" , "supa@ietf.org" Thread-Topic: review of draft-ietf-supa-policy-based-management-framework Thread-Index: AQHS2K+9qNHp/kbYHkCaJ004NHuBd6JCVBxA Date: Mon, 3 Jul 2017 14:00:08 +0000 Message-ID: References: <47757855-5A48-40B1-AA8F-472D52CA1E17@viagenie.ca> In-Reply-To: <47757855-5A48-40B1-AA8F-472D52CA1E17@viagenie.ca> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.79.69] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.595A4DF1.0082, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.2.202, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 604cf8a9ab4c13a2f80fe9f571dcfdbe Archived-At: Subject: Re: [Supa] review of draft-ietf-supa-policy-based-management-framework X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.22 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: Mon, 03 Jul 2017 14:00:49 -0000 RGVhciBNYXJjLA0KDQpUaGFua3MgZm9yIHlvdXIgY29tbWVudHMuIFdlJ3ZlIHVwZGF0ZWQgdGhl IGRyYWZ0IGFjY29yZGluZyB0byB0aGVtLiANCkZvciB5b3VyIGxhcmdlciBjb21tZW50LCB0aGUg dGVhbSBhcmUgd29ya2luZyBvbiBvdGhlciBkb2N1bWVudHMgaW5jbHVkaW5nIEluZm9ybWF0aW9u IG1vZGVsIGFuZCBEYXRhIG1vZGVsLiANCg0KUmVnYXJkcywgLyDoh7TnpLwhIA0KV2lsbCBMSVUg IC8g5YiY5qCR5oiQDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IE1hcmMg QmxhbmNoZXQgW21haWx0bzptYXJjLmJsYW5jaGV0QHZpYWdlbmllLmNhXSANClNlbnQ6IFR1ZXNk YXksIE1heSAzMCwgMjAxNyAzOjE0IEFNDQpUbzogc3VwYUBpZXRmLm9yZzsgZHJhZnQtaWV0Zi1z dXBhLXBvbGljeS1iYXNlZC1tYW5hZ2VtZW50LWZyYW1ld29ya0BpZXRmLm9yZw0KU3ViamVjdDog cmV2aWV3IG9mIGRyYWZ0LWlldGYtc3VwYS1wb2xpY3ktYmFzZWQtbWFuYWdlbWVudC1mcmFtZXdv cmsNCg0KSGVsbG8sDQogIHNvbWUgY29tbWVudHMgb24gZHJhZnQtaWV0Zi1zdXBhLXBvbGljeS1i YXNlZC1tYW5hZ2VtZW50LWZyYW1ld29yay4NCi0gbWlub3IgZWRpdG9yaWFsIGJlbG93LiBzZWFy Y2ggZm9yIDxNQj4uIE5vdGUgdGhhdCBJIHN0YXJ0ZWQgdG8gc3VnZ2VzdCB0byB1c2UgdGhlIHBy ZXNlbnQgdGVuc2UgaW5zdGVhZCBvZiB0aGUgZnV0dXJlIGluIHRoZSB0ZXh0LCBidXQgdGhhdCBt aWdodCBiZSByZWxhdGVkIHRvIHRoZSBwb2ludCBiZWxvdy4NCi0gbGFyZ2VyIGNvbW1lbnQ6IEni gJltIG5vdCBzdXJlIHdoYXQgdG8gZG8gd2l0aCB0aGlzIGRvY3VtZW50LiBJdCBsb29rcyBsaWtl IGEgbGFyZ2Ugd2lzaCBsaXN0IG9mIGZlYXR1cmVzLiBJIGd1ZXNzIEnigJltIHByb2JhYmx5IHRv byB1c2VkIHRvIGltcGxlbWVudGF0aW9uL3Byb3RvY29sIGRldGFpbHMuIEkgZ3Vlc3MgSSB3aWxs IHdhaXQgdW50aWwgdG8gc2VlIHRoZSBhY3R1YWwgcHJvdG9jb2wveWFuZyBtb2RlbHMuDQoNClJl Z2FyZHMsIE1hcmMuDQoNCj09PT09PT09PT09PT09PT09PT09PQ0KDQpBYnN0cmFjdA0KDQogICAg U2ltcGxpZmllZCBVc2Ugb2YgUG9saWN5IEFic3RyYWN0aW9ucyAoU1VQQSkgZGVmaW5lcyBiYXNl IFlBTkcgZGF0YQ0KICAgIG1vZGVscyB0byBlbmNvZGUgcG9saWN5LCB3aGljaCB3aWxsIHBvaW50 IHRvIGRldmljZS0sIHRlY2hub2xvZ3ktLA0KICAgIGFuZCBzZXJ2aWNlLXNwZWNpZmljIFlBTkcg bW9kZWxzIGRldmVsb3BlZCBpbiBvdGhlciB3b3JraW5nIGdyb3Vwcy4NCjxNQj5JJ20gbm90IHN1 cmUgaGF2aW5nIGEgcmVmZXJlbmNlIHRvIElFVEYgc3RydWN0dXJlICh3b3JraW5nIGdyb3Vwcykg aXMgYXBwcm9wcmlhdGUuIEJlY2F1c2Ugc2VydmljZS1zcGVjaWZpYyBtb2RlbHMgY291bGQgYmUg ZGV2ZWxvcGVkIG91dHNpZGUgb2YgSUVURiB3Zywgb3IgYXMgaW5kaXZpZHVhbCwgb3IgYXMgYW5v dGhlciBTRE8gd2csIC4uLg0Kc3VnZ2VzdGluZzogInNlcnZpY2Utc3BlY2lmaWMgWUFORyBtb2Rl bHMgZGV2ZWxvcGVkIGVsc2V3aGVyZS4iDQo8L01CPg0KDQrigKYNCg0KICAgIFNpbXBsaWZpZWQg VXNlIG9mIFBvbGljeSBBYnN0cmFjdGlvbnMgKFNVUEEpIHdpbGwgZGVmaW5lIGEgZ2VuZXJpYw0K PE1CPnMvd2lsbCBkZWZpbmUvZGVmaW5lcy88L01CPg0KICAgIHBvbGljeSBpbmZvcm1hdGlvbiBt b2RlbCAoR1BJTSkgW0ktRC5pZXRmLXN1cGEtZ2VuZXJpYy1wb2xpY3ktaW5mby0NCiAgICBtb2Rl bF0gZm9yIHVzZSBpbiBuZXR3b3JrIG9wZXJhdGlvbnMgYW5kIG1hbmFnZW1lbnQgYXBwbGljYXRp b25zLg0KICAgIFRoZSBHUElNIGRlZmluZXMgY29uY2VwdHMgYW5kIHRlcm1pbm9sb2d5IG5lZWRl ZCBieSBwb2xpY3kgDQptYW5hZ2VtZW50DQogICAgaW5kZXBlbmRlbnQgb2YgdGhlIGZvcm0gYW5k IGNvbnRlbnQgb2YgdGhlIHBvbGljeSBydWxlLiAgVGhlIEVDQQ0KPE1CPmV4cGFuZCBFQ0Egd2hl biB1c2VkIGZpcnN0IHRpbWUuIEV2ZW50LUNvbmRpdGlvbi1BY3Rpb24gKEVDQSk8L01CPg0KICAg IFBvbGljeSBSdWxlIEluZm9ybWF0aW9uIE1vZGVsIChFUFJJTSkgW0ktRC5pZXRmLXN1cGEtZ2Vu ZXJpYy1wb2xpY3ktDQogICAgaW5mby1tb2RlbF0gZXh0ZW5kcyB0aGUgR1BJTSB0byBkZWZpbmUg aG93IHRvIGJ1aWxkIHBvbGljeSBydWxlcw0KICAgIGFjY29yZGluZyB0byB0aGUgZXZlbnQtY29u ZGl0aW9uLWFjdGlvbiBwYXJhZGlnbS4NCg0KDQogICAgVGhlIEVQUklNIGRlZmluZXMgYW4gRXZl bnQtQ29uZGl0aW9uLUFjdGlvbiAoRUNBKSBwb2xpY3kNCg0KPE1CPm5vIG5lZWQgdG8gZXhwYW5k IEVDQSwgc2luY2UgaXQgaXMgc3VnZ2VzdGVkIHRvIGJlIGV4cGFuZGVkIGluIGl0cyANCmZpcnN0 IHVzZSBhYm92ZTwvTUI+DQoNCiAgYXMgYW4NCiAgICBleGFtcGxlIG9mIGltcGVyYXRpdmUgcG9s aWNpZXMuICBBbiBFQ0EgcG9saWN5IHJ1bGUgaXMgYWN0aXZhdGVkIA0Kd2hlbg0KICAgIGl0cyBl dmVudCBjbGF1c2UgaXMgdHJ1ZTsgdGhlIGNvbmRpdGlvbiBjbGF1c2UgaXMgdGhlbiBldmFsdWF0 ZWQgDQphbmQsDQogICAgaWYgdHJ1ZSwgc2lnbmFscyB0aGUgZXhlY3V0aW9uIG9mIG9uZSBvciBt b3JlIGFjdGlvbnMgaW4gdGhlIGFjdGlvbg0KICAgIGNsYXVzZS4gIFRoaXMgdHlwZSBvZiBwb2xp Y3kgZXhwbGljaXRseSBkZWZpbmVzIHRoZSBjdXJyZW50IGFuZA0KICAgIGRlc2lyZWQgc3RhdGVz IG9mIHRoZSBzeXN0ZW0gYmVpbmcgbWFuYWdlZC4gIEltcGVyYXRpdmUgcG9saWN5IHJ1bGVzDQog ICAgcmVxdWlyZSBhZGRpdGlvbmFsIG1hbmFnZW1lbnQgZnVuY3Rpb25zLCB3aGljaCBhcmUgZXhw bGFpbmVkIGluDQogICAgc2VjdGlvbiAyLjIgYmVsb3cuDQoNCuKApg0KICAgIFRoZSBTVVBBIHNj b3BlIGlzIGxpbWl0ZWQgdG8gcG9saWN5IGluZm9ybWF0aW9uIGFuZCBkYXRhIG1vZGVscy4NCiAg ICBTVVBBIHdpbGwgbm90IGRlZmluZSBuZXR3b3JrIHJlc291cmNlIGRhdGEgbW9kZWxzIG9yIG5l dHdvcmsgc2VydmljZQ0KPE1CPnMvd2lsbCBub3QvZG9lcyBub3QvPC9NQj4NCiAgICBkYXRhIG1v ZGVsczsgYm90aCBhcmUgb3V0IG9mIHNjb3BlLiAgSW5zdGVhZCwgU1VQQSB3aWxsIG1ha2UgdXNl IG9mDQo8TUI+cy93aWxsIG1ha2UvbWFrZXMvPC9NQj4NCiAgICBuZXR3b3JrIHJlc291cmNlIGRh dGEgbW9kZWxzIGRlZmluZWQgYnkgb3RoZXIgV0dzIG9yIFNET3MuDQoNCiAgICBEZWNsYXJhdGl2 ZSBwb2xpY2llcyB0aGF0IHNwZWNpZnkgdGhlIGdvYWxzIHRvIGJlIGFjaGlldmVkIGJ1dCBub3QN CiAgICBob3cgdG8gYWNoaWV2ZSB0aG9zZSBnb2FscyAoYWxzbyBjYWxsZWQgImludGVudC1iYXNl ZCIgcG9saWNpZXMpIGFyZQ0KICAgIG91dCBvZiBzY29wZSBmb3IgdGhlIGluaXRpYWwgcGhhc2Ug b2YgU1VQQS4NCg0K From nobody Mon Jul 3 07:02:08 2017 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 4DC4512EB9B for ; Mon, 3 Jul 2017 07:02:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 GzNQPQp64p7G for ; Mon, 3 Jul 2017 07:02:04 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72E9C129462 for ; Mon, 3 Jul 2017 07:02:03 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DQI02000; Mon, 03 Jul 2017 14:02:02 +0000 (GMT) Received: from DGGEML403-HUB.china.huawei.com (10.3.17.33) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 3 Jul 2017 15:02:01 +0100 Received: from DGGEML510-MBX.china.huawei.com ([169.254.2.202]) by DGGEML403-HUB.china.huawei.com ([fe80::74d9:c659:fbec:21fa%31]) with mapi id 14.03.0301.000; Mon, 3 Jul 2017 22:01:53 +0800 From: "Liushucheng (Will Liu)" To: Johannes Merkle CC: "supa@ietf.org" Thread-Topic: review for draft-ietf-supa-policy-based-management-framework Thread-Index: AQHS6agud63mWLnjlk2CICe6J02KPqJCFFrg Date: Mon, 3 Jul 2017 14:01:53 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.79.69] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.595A4E5A.008B, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.2.202, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: ac17bab59862326d03f95bd734b6aace Archived-At: Subject: Re: [Supa] review for draft-ietf-supa-policy-based-management-framework X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.22 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: Mon, 03 Jul 2017 14:02:06 -0000 RGVhciBKb2hhbm5lcywNCg0KTWFueSB0aGFua3MgZm9yIHlvdXIgZGV0YWlsZWQgcmV2aWV3LiBX ZSd2ZSB1cGRhdGVkIHRoZSBkcmFmdCBhY2NvcmRpbmcgdG8gYWxsIHlvdXIgY29tbWVudHMuIFBs ZWFzZSBjaGVjayBzb21lIHJlc3BvbnNlcyBiZWxvdyBpbmxpbmUgd2l0aCBbV2lsbF0uDQoNCg0K LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEpvaGFubmVzIE1lcmtsZSBbbWFpbHRv OmpvaGFubmVzLm1lcmtsZUBzZWN1bmV0LmNvbV0gDQpTZW50OiBUdWVzZGF5LCBKdW5lIDIwLCAy MDE3IDU6MzMgUE0NClRvOiBzdXBhQGlldGYub3JnDQpDYzogTGl1c2h1Y2hlbmcgKFdpbGwgTGl1 KSA8bGl1c2h1Y2hlbmdAaHVhd2VpLmNvbT4NClN1YmplY3Q6IHJldmlldyBmb3IgZHJhZnQtaWV0 Zi1zdXBhLXBvbGljeS1iYXNlZC1tYW5hZ2VtZW50LWZyYW1ld29yaw0KDQpJIGhhdmUgY29uZHVj dGVkIGEgcmV2aWV3IG9mIGRyYWZ0LWlldGYtc3VwYS1wb2xpY3ktYmFzZWQtbWFuYWdlbWVudC1m cmFtZXdvcmsuIFRoZXNlIGFyZSBteSBjb21tZW50czoNCg0KLSBHZW5lcmFsbHksIHRoZSBzcGVj aWZpY2F0aW9uIGlzIHZlcnkgYWJzdHJhY3QgYW5kIG5vdCBlYXN5IHRvIHVuZGVyc3RhbmQuIEZv ciBpbnN0YW5jZSwgaXQgaXMgbm90IGV4cGxhaW5lZCwgd2hhdCBleGFjdGx5IHRoZSB0cmFuc2xh dGlvbiBvZiB0aGUgaW5mb3JtYXRpb24gbW9kZWxzIHRvIGRhdGEgbW9kZWxzIG1lYW5zLiBNYXli ZSBJIGxhY2sgdGhlIG5lY2Vzc2FyeSBleHBlcmllbmNlIGluIHRoZSBmaWVsZCBvZiBuZXR3b3Jr IG1hbmFnZW1lbnQuIEkgd2FzIGFsc28gc3VycHJpc2VkIHRoYXQgdGhlIElEIGRvZXMgbm90IGRl ZmluZSBhbnkgc3BlY2lmaWMgc3ludGF4IG9yIHNlbWFudGljLiBGb3IgYW4gSUQgLyBSRkMsIHRo ZSBzcGVjaWZpY2F0aW9uIGlzIHF1aXRlIHZhZ3VlIGFuZCB1bnNwZWNpZmljLCBhbmQgaXQgcmVh ZHMgbGlrZSBhbiBpbnRyb2R1Y3Rpb24uDQoNCltXaWxsXSBUaGUgcmVsYXRpb25zaGlwIG9mIElN IGFuZCBETSBjYW4gYmUgZm91bmRlZCBpbiBSRkMgMzQ0NC4gV2UndmUgYWRkZWQgdGhpcyByZWZl cmVuY2UgaW50byB0aGUgZHJhZnQuIA0KVGhlIHRyYW5zbGF0aW9uIG9mIElNIHRvIERNIChvciBp biBzb21lIHBhcmFncmFwaHMgd2UgdXNlZCAibWFwIiksY2FuIGJlIGZvdW5kIGF0IHRoZSBib29r IFBvbGljeS1iYXNlZCBOZXR3b3JrIE1hbmFnZW1lbnQ6IFNvbHV0aW9ucyBmb3IgdGhlIE5leHQg R2VuZXJhdGlvbiBieSBKb2huLCAgIkEgbW9kZWwgbWFwcGluZyBpcyBhIHRyYW5zbGF0aW9uIGZy b20gb25lIHR5cGUgb2YgbW9kZWwgdG8gYW5vdGhlciB0eXBlIG9mIG1vZGVsLiBNb2RlbCBtYXBw aW5nIGNoYW5nZXMgdGhlIHJlcHJlc2VudGF0aW9uIGFuZC9vciAgbGV2ZWwgb2YgYWJzdHJhY3Rp b24gdXNlZCBpbiBvbmUgbW9kZWwgdG8gYW5vdGhlciByZXByZXNlbnRhdGlvbiBhbmQvb3IgbGV2 ZWwgb2YgYWJzdHJhY3Rpb24gaW4gYW5vdGhlciBtb2RlbC4gVGhlIG1vc3Qgb21tb24gZm9ybSBv ZiBtb2RlbCBtYXBwaW5nIGlzIGZyb20gYW4gaW5mb3JtYXRpb24gbW9kZWwgdG8gYSBkYXRhIG1v ZGVsLi4uIiANClRoZSBkZXRhaWxlZCBleGFtcGxlIGNhbiBiZSBmb3VuZGVkIGF0IHRoZSBkcmFm dCBkcmFmdC1pZXRmLXN1cGEtZ2VuZXJpYy1wb2xpY3ktZGF0YS1tb2RlbCwgd2hpY2ggaXMgbWFw cGVkIGZyb20gZHJhZnQtaWV0Zi1zdXBhLWdlbmVyaWMtcG9saWN5LWluZm8tbW9kZWwuDQoNCi0g QWJzdHJhY3Q6DQpZQU5HIGRhdGEgbW9kZWxzIHRvIGVuY29kZSBwb2xpY3ksIHdoaWNoIHdpbGwg cG9pbnQgdG8gc2hvdWxkIGJlIFlBTkcgZGF0YSBtb2RlbHMgdG8gZW5jb2RlIHBvbGljaWVzLCB3 aGljaCBwb2ludCB0byBvciBZQU5HIGRhdGEgbW9kZWxzIHRvIGVuY29kZSBhIHBvbGljeSwgd2hp Y2ggcG9pbnRzIHRvDQoNClNlY3Rpb24gMSwNCg0KM3JkIHBhcmFncmFwaDoNCiAgIFRoZSBHUElN IGRlZmluZXMgY29uY2VwdHMgYW5kIHRlcm1pbm9sb2d5IG5lZWRlZCBieSBwb2xpY3kgbWFuYWdl bWVudA0KICAgaW5kZXBlbmRlbnQgb2YgdGhlIGZvcm0gYW5kIGNvbnRlbnQgb2YgdGhlIHBvbGlj eSBydWxlLiAgVGhlIEVDQSBXaGF0IGRvZXMgImZvcm0iIGV4YWN0bHkgbWVhbiBoZXJlLiBTeW50 YXg/IFN0cnVjdHVyZT8gRW5jb2Rpbmc/DQogDQpbV2lsbF0gZm9ybSBoZXJlIHJlZmVycyB0byB0 aGUgd2F5IG9mIGV4cHJlc3NpbmcgY29udGVudCwgc3VjaCBhcyBkYXRhIHJlcG9zaXRvcnksIGRh dGEgZGVmaW5pdGlvbiBsYW5ndWFnZSwgcXVlcnkgbGFuZ3VhZ2UsIGltcGxlbWVudGF0aW9uIGxh bmd1YWdlLCBhbmQgcHJvdG9jb2wgKHR5cGljYWxseSBvbmUgb3IgbW9yZSBvZiB0aGVzZSkuDQoN CjR0aCBwYXJhZ3JhcGg6DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIFRoZSBHUElNIGFuZCB0aGUgRVBSSU0NCiAgIHdpbGwgYm90aCBiZSB0cmFuc2xh dGVkIGludG8gY29ycmVzcG9uZGluZyBZQU5HIFtSRkM2MDIwXVtSRkM2MDIwYmlzXQ0KICAgbW9k dWxlcyB0aGF0IGRlZmluZSBwb2xpY3kgY29uY2VwdHMsDQpJIHN1Z2dlc3QgdG8gcmVwbGFjZSAi d2lsbCIgYnkgImNhbiIuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYWRkaXRp b25hbCBZQU5HIG1vZHVsZXMgbWF5IGFsc28gYmUNCiAgIGRlZmluZWQgZnJvbSB0aGUgR1BJTSBh bmQvb3IgRVBSSU0gdG8gbWFuYWdlIHNwZWNpZmljIGZ1bmN0aW9ucy4NCkkgc3VnZ2VzdCB0byBj aGFuZ2UgImRlZmluZWQiIHRvICJkZXJpdmVkIg0KDQpTZWN0aW9uIDINCg0KR2VuZXJhbDogVGhl IGZvbGxvd2luZyBUZXJtcyBhcmUgbWlzc2luZzogU1VQQSwgRUNBLCBZQU5HLCBFTVMsIEVNUy9O TVMvQ29udHJvbGxlciwgT1NTL0JTUy9PcmNoZXN0cmF0b3INCg0KM3JkIFBhcmFncmFwZ2ggKEdQ RE0pOg0KICB0aGUgc2VydmljZShzKSB0byBiZSBtYW5hZ2VkIHVzaW5nIHBvbGljeS4NCnNob3Vs ZCBiZQ0KICB0aGUgc2VydmljZShzKSB0byBiZSBtYW5hZ2VkIHVzaW5nIHBvbGljaWVzLg0Kb3IN CiAgdGhlIHNlcnZpY2UocykgdG8gYmUgbWFuYWdlZCB1c2luZyBhIHBvbGljeS4NCg0KU2VjdGlv biAzLjE6DQoNCjFzdCBwYXJhZ3JhcGg6DQogIGluZm9ybWF0aW9uIChlLmcuLCBwYXJ0IG9mIGEg c2VudGVuY2UgdGhhdCB3YXMgY3V0IG91dCkuKSBUaGUgbWVhbmluZyBvZiAic2VudGVuY2UiIGlu IHRoaXMgY29udGV4dCBpcyBub3QgY2xlYXIgdG8gbWUuDQpbV2lsbF0gc2VudGVuY2UgaGVyZSBp cyB1c2VkIHRvIGV4cGxhaW4gdGhlIGNvbmNlcHQgb2Ygc25pcHBldCBhcyBhdXRob3JzIHJlY2Vp dmVkIG1hbnkgY29tbWVudHMgdGhhdCB0aGUgdGVybSAic25pcHBldCIgaXMgbm90IGNsZWFyLiBB IHNlbnRlbmNlIHJlZmVycyB0byBhIGNvbXBsZXRlIGV4cHJlc3Npb24gd2hpbGUgc25pcHBldCBp cyBwYXJ0IG9mIGl0Lg0KDQoybmQgcGFyYWdyYXBoOg0KICAgb3BlcmF0b3IgaW50ZXJhY3RzIHdp dGggdGhlIGludGVyZmFjZSwgd2hpY2ggaXMgdGhlbiB0cmFuc2xhdGVkIHRvDQogICBjb25maWd1 cmF0aW9uIHNuaXBwZXRzLg0KSSBkb24ndCB1bmRlcnN0YW5kLiBUaGUgaW50ZXJmYWNlIGlzIHRy YW5zbGF0ZWQgdG8gY29uZmlndXJhdGlvbiBkYXRhPw0KW1dpbGxdIEZpeGVkLiAiV2hpY2giIGhl cmUgcmVmZXJzIHRvIHRoZSBwb2xpY2llcyBpbnB1dCBieSBvcGVyYXRvcnMuIFdlIGFjdHVhbGx5 IGRpZCBhIGRlbW8gaW4gQnVlbm9zIEFpcmVzIHRvIHNob3cgdGhlIHBvbGljeSBpbnB1dCB3ZWJz aXRlIGZvciBvcGVyYXRvcnMuIA0KDQozcmQgcGFyYWdyYXBoOg0KICAgTm90ZSB0aGF0IFlBTkcg bW9kZWxzIG1heSBub3QgZXhpc3QuDQpJbiB3aGljaCBjb250ZXh0Pw0KW1dpbGxdRml4ZWQuICAi dGhhdCBZQU5HIG1vZGVscyIgcmVmZXIgdG8gUmVzb3VyY2UgYW5kIFNlcnZpY2UgWUFORyBkYXRh IG1vZGVscy4gDQoNCjd0aCBwYXJhZ3JhcGggKDFzdCBwYXJhZ3JhcGggb24gcGFnZSA2KToNCiAg IHR5cGVzIG9mIHBvbGljaWVzOiBFQ0EgcG9saWN5IHJ1bGVzIGFuZCBkZWNsYXJhdGl2ZSBwb2xp Y3kNCiAgIHN0YXRlbWVudHMuDQpUaGUgZGlzdGluY3Rpb24gYmV0d2VlbiBFQ0EgcG9saWNpZXMg YW5kIGRlY2xhcmF0aXZlIHBvbGljaWVzIGlzIG5vdCBleHBsYWluZWQuIEZ1cnRoZXJtb3JlLCB5 b3UgY291bGQgbWVudGlvbiBhbHJlYWR5IGhlcmUsIHRoYXQgZGVjbGFyYXRpdmUgcG9saWNpZXMg YXJlIG91dC1vZi1zY29wZSBmb3IgdGhpcyBJRC4NCltXaWxsXSBGaXhlZC4gVGhlcmUgaXMgdGhl IGV4cGxhbmF0aW9uIGluIHNlY3Rpb24gT3BlcmF0aW9uOiAiRGVjbGFyYXRpdmUgcG9saWNpZXMg dGhhdCBzcGVjaWZ5IHRoZSBnb2FscyB0byBiZSBhY2hpZXZlZCBidXQgbm90IGhvdyB0byBhY2hp ZXZlIHRob3NlIGdvYWxzIChhbHNvIGNhbGxlZCAiaW50ZW50LWJhc2VkIiBwb2xpY2llcykgYXJl IG91dCBvZiBzY29wZSBmb3IgdGhlIGluaXRpYWwgcGhhc2Ugb2YgU1VQQS4iIFdlIG5vdyBtb3Zl IHRoaXMgc2VudGVuY2UgdG8gdGhlIHRlcm1pbm9sb2d5IHNlY3Rpb24uDQoNCjl0aCBwYXJhZ3Jh cGg6DQogICBEdXJpbmcgdGhlIHJ1biB0aW1lLCBjb21wb25lbnRzIGNvbW11bmljYXRlIHdpdGgg dGhlIGRhdGEgaW5zdGFuY2VzDQogICBmb3IgbWFuYWdlbWVudCBhbmQgbW9uaXRvcmluZy4NCkkg ZG9uJ3QgdW5kZXJzdGFuZCB3aGF0IHlvdSBtZWFuIGJ5ICJkYXRhIGluc3RhbmNlIiBhbmQgaG93 IGl0IGNvdWxkIGNvbW11bmljYXRlPw0KW1dpbGxdIEZpeGVkIGJ5IHJlbW92aW5nIHRoZSBzZWN0 aW9uIGFzIHRoaXMgcGFyYWdyYXBoIGlzIG1pc3NpbmcgbGVhZGluZyBhbmQgbm90IG5lY2Vzc2Fy eSBleHBsYW5hdGlvbiBmb3IgdGhlIGZpZ3VyZSBiZWxvdy4NCg0KRmlndXJlIDI6DQpTb21lIHNw YWNlcyBhcmUgbWlzc2luZzogRUNBUG9saWN5UnVsZSBhbmQgUG9saWN5UnVsZQ0KDQpGaWd1cmUg MjogT1NTL0JTUyBPcmNoZXN0cmF0b3IgaXMgc2hvd24gYnV0IG5vdCBsaXN0ZWQgaW4gdGhlIGV4 cGxhbmF0aW9uIGFib3ZlLg0KDQpFeHBsYW5hdGlvbiBvZiBGaWd1cmUgMjoNCg0KICBFQ0EgUG9s aWN5IFJ1bGUgSW5mb3JtYXRpb24gRGF0YSBNb2RlbCAoRVBSSU0pOg0Kc2hvdWxkIGJlDQogIEVD QSBQb2xpY3kgUnVsZSBJbmZvcm1hdGlvbiBNb2RlbCAoRVBSSU0pOg0KDQogICBOZXR3b3JrIFNl cnZpY2UgYW5kIFJlc291cmNlIERhdGEgTW9kZWxzOiBtb2RlbHMgb2YgdGhlIHNlcnZpY2UgYXMg VGhlc2UgYXJlIG5vdCBzaG93biBpbiBGaWd1cmUgMi4NCltXaWxsXSBGaXhlZC4gVGhpcyBpcyBm b3IgZXhwbGFpbmluZyBGaWd1cmUgMS4gV2Ugbm93IGNoYW5nZSBpdCB0byAiIFJlc291cmNlIGFu ZCBTZXJ2aWNlIFlBTkcgRGF0YSBNb2RlbHMiIGFuZCBtb3ZlIHRoaXMgcGFyYWdyYXBoIGFmdGVy IGZpZ3VyZSAxLg0KDQpCZWxvdyBGaWd1cmUgMzoNCg0KICAgUG9saWNpZXMgYXJlIHVzZWQgdG8g Y29udHJvbCB0aGUgbWFuYWdlbWVudCBvZiByZXNvdXJjZXMgYW5kDQogICBzZXJ2aWNlcywgd2hp bGUgZGF0YSBmcm9tIHJlc291cmNlcyBhbmQgc2VydmljZXMgYXJlIHVzZWQgdG8gc2VsZWN0DQog ICBhbmQvb3IgbW9kaWZ5IHBvbGljaWVzIGR1cmluZyBydW50aW1lLg0KVGhlIGxhdHRlciB0eXBl IG9mIGludGVyYWN0aW9uIHNob3VsZCBiZSBtZW50aW9uZWQgaW4gdGhlIGV4cGxhbmF0aW9uIG9m IHRoZSBjb21tdW5pY2F0aW9uICgxKS4gVGh1cw0KICAgICAgKDEpIHBvbGljeSBtYW5hZ2VzIGFu ZCBjYW4gYWRqdXN0IHNlcnZpY2UgYmVoYXZpb3IgYXMgbmVjZXNzYXJ5DQogICAgICAoMToxLi5u KQ0Kc2hvdWxkIGJlDQogICAgICAoMSkgcG9saWN5IG1hbmFnZXMgYW5kIGNhbiBhZGp1c3Qgc2Vy dmljZSBiZWhhdmlvciBhcyBuZWNlc3NhcnkNCiAgICAgICgxOjEuLm4pLiBJbiBhZGRpdGlvbiwg ZGF0YSBmcm9tIHJlc291cmNlcyBhbmQgc2VydmljZXMgYXJlIHVzZWQgdG8gc2VsZWN0DQogICBh bmQvb3IgbW9kaWZ5IHBvbGljaWVzIGR1cmluZyBydW50aW1lLg0KDQoNClNlY3Rpb24gMy4zLCAx c3QgcGFyYWdyYXBoOg0KICBFUlBJTSAtLT4gRVBSSU0NCltXaWxsXSBGaXhlZCBhYm92ZSBvbmVz Lg0KDQpSZWdhcmRzLCAvIOiHtOekvCEgDQpXaWxsIExJVSAgLyDliJjmoJHmiJANCg0K From nobody Mon Jul 3 07:02:38 2017 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 C1FCE131648 for ; Mon, 3 Jul 2017 07:02:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 tuVNeVLizJOh for ; Mon, 3 Jul 2017 07:02:25 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A513131638 for ; Mon, 3 Jul 2017 07:02:20 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml706-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DJQ76141; Mon, 03 Jul 2017 14:02:17 +0000 (GMT) Received: from DGGEML401-HUB.china.huawei.com (10.3.17.32) by lhreml706-cah.china.huawei.com (10.201.108.47) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 3 Jul 2017 15:02:16 +0100 Received: from DGGEML510-MBX.china.huawei.com ([169.254.2.202]) by DGGEML401-HUB.china.huawei.com ([fe80::89ed:853e:30a9:2a79%31]) with mapi id 14.03.0301.000; Mon, 3 Jul 2017 22:02:09 +0800 From: "Liushucheng (Will Liu)" To: Gunter Wang CC: "supa@ietf.org" Thread-Topic: supa framework review Thread-Index: AdLW2HYlX7EHN3QaQsKi96TSuuMNmgdGjHyQ Date: Mon, 3 Jul 2017 14:02:08 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.79.69] Content-Type: multipart/alternative; boundary="_000_C9B5F12337F6F841B35C404CF0554ACB8A32B237dggeml510mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090201.595A4E6A.012F, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.2.202, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: eaadbde84d1dcd539b4a4586eb50cdfb Archived-At: Subject: Re: [Supa] supa framework review X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.22 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: Mon, 03 Jul 2017 14:02:29 -0000 --_000_C9B5F12337F6F841B35C404CF0554ACB8A32B237dggeml510mbxchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 RGVhciBHdW50ZXIsDQoNCk1hbnkgdGhhbmtzIGZvciB5b3VyIGRldGFpbGVkIGNvbW1lbnRzLiBX ZaGvdmUganVzdCB1cGRhdGVkIHRoZSBkcmFmdCB1c2luZyBhbGwgb2YgdGhlbS4gUGxlYXNlIGhh dmUgYSBsb29rIGF0IHRoZSBuZXcgdmVyc2lvbiBhbmQgbGV0IHVzIGtub3cgaWYgdGhlcmUgaXMg YW55dGhpbmcgbWlzc2luZy4NCg0KUmVnYXJkcywgLyDWwsDxIQ0KV2lsbCBMSVUgIC8gwfXK97PJ DQoNCkZyb206IFNVUEEgW21haWx0bzpzdXBhLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiBHdW50ZXIgV2FuZw0KU2VudDogU2F0dXJkYXksIE1heSAyNywgMjAxNyA3OjAxIFBNDQpUbzog c3VwYUBpZXRmLm9yZw0KU3ViamVjdDogW1N1cGFdIHN1cGEgZnJhbWV3b3JrIHJldmlldw0KDQpI aSwgYWxsDQoNCkFmdGVyIHJldmlld2luZyB0aGUgc3VwYSBhcmNoaXRlY3R1cmUgZHJhZnQsICBJ IGdpdmUgc29tZSBvZiB0aGUgY29tbWVudHMgYXMgZm9sbG93cywNCg0KKiBTZWN0aW9uIDEsIHBh Z2UgMjoNCg0KPiBUaGUgcmFwaWQgZ3Jvd3RoIGluIHRoZSB2YXJpZXR5IGFuZCBpbXBvcnRhbmNl IG9mIHRyYWZmaWMgZmxvd2luZw0Kb3ZlciBpbmNyZWFzaW5nbHkgY29tcGxleCBlbnRlcnByaXNl IGFuZCBzZXJ2aWNlIHByb3ZpZGVyIG5ldHdvcmsNCmFyY2hpdGVjdHVyZXMgbWFrZXMgdGhlIHRh c2sgb2YgbmV0d29yayBvcGVyYXRpb25zIGFuZCBtYW5hZ2VtZW50DQphcHBsaWNhdGlvbnMgZGVw bG95aW5nIG5ldyBzZXJ2aWNlcyBtdWNoIG1vcmUgZGlmZmljdWx0LiBJbg0KYWRkaXRpb24sIG5l dHdvcmsgb3BlcmF0b3JzIHdhbnQgdG8gZGVwbG95IG5ldyBzZXJ2aWNlcyBxdWlja2x5IGFuZA0K ZWZmaWNpZW50bHkuDQoNCkl0IHNvdW5kcyBsaWtlIHRoYXQgdGhlIGdyb3d0aCBvZiBpbXBvcnRh bmNlIG9mIC4uLiBtYWtlcyB0aGUgdGFzayBtb3JlIGRpZmZpY3VsdC4gSXQgZG9lc24ndCBtYWtl IHNlbnNlLg0KDQpUcmFmZmljIGZsb3cgb3ZlciBpbmNyZWFzaW5nbHkgY29tcGxleCBlbnRlcnBy aXNlIGFuZCBzZXJ2aWNlIHByb3ZpZGVyIG5ldHdvcmsgYmVjb21lcyBtb3JlIGFuZCBtb3JlIGlt cG9ydGFudC4gTWVhbndoaWxlLCB0aGUgcmFwaWQgZ3Jvd3RoIG9mIHRoZSB2YXJpZXR5IG1ha2Vz IHRoZSB0YXNrIG9mIG5ldHdvcmsgb3BlcmF0aW9ucyBhbmQgbWFuYWdlbWVudCBhcHBsaWNhdGlv bnMgZGVwbG95aW5nIG5ldyBzZXJ2aWNlcyBtdWNoIG1vcmUgZGlmZmljdWx0LCBNb3Jlb3Zlciwg bmV0d29yayBvcGVyYXRvcnMgd2FudCB0byBkZXBsb3kgbmV3IHNlcnZpY2VzIHF1aWNrbHkgYW5k IGVmZmljaWVudGx5Lg0KDQoqIFNlY3Rpb24gMy4xLCBwYWdlIDQ6DQoNCj5Ob3RlIHRoYXQgWUFO RyBtb2RlbHMgbWF5IG5vdCBleGlzdC4gSW4gdGhpcyBjYXNlLCB0aGUgU1VQQSBnZW5lcmljDQpw b2xpY3kgWUFORyBkYXRhIG1vZHVsZXMgc2VydmUgYXMgYW4gZXh0ZW5zaWJsZSBiYXNpcyB0byBk ZXZlbG9wIG5ldw0KWUFORyBkYXRhIG1vZGVscyBmb3IgdGhlIFNlcnZpY2UgSW50ZXJmYWNlIExv Z2ljIHRvIGNyZWF0ZQ0KYXBwcm9wcmlhdGUgaW5wdXQgbWVjaGFuaXNtcyBmb3IgdGhlIG9wZXJh dG9yIHRvIGRlZmluZSBwb2xpY2llcy4NClRoaXMgdHJhbnNmZXJzIHRoZSB3b3JrIHNwZWNpZmll ZCBieSB0aGUgUmVzb3VyY2UgYW5kIFNlcnZpY2UgWUFORw0KZGF0YSBtb2RlbHMgc3BlY2lmaWVk IGluIElFVEYgaW50byB0aGUgU2VydmljZSBJbnRlcmZhY2UgTG9naWMsIHdoaWNoDQppcyB0aGVu IHRyYW5zbGF0ZWQgdG8gY29uZmlndXJhdGlvbiBzbmlwcGV0cy4NCg0KYWxyZWFkeSBleHBsYWlu ZWQgaW4gYWJvdmUgcGFyYWdyYXBoLCBkZWxldGUgaXQ/IFRvbyBsb25nIHRvIHVuZGVyc3RhbmQN Cg0KQ2hhbmdlIHRvDQpOb3RlIHRoYXQgWUFORyBtb2RlbHMgbWF5IG5vdCBleGlzdC4gSW4gdGhp cyBjYXNlLCB0aGUgU1VQQSBnZW5lcmljDQpwb2xpY3kgWUFORyBkYXRhIG1vZHVsZXMgc2VydmUg YXMgYW4gZXh0ZW5zaWJsZSBiYXNpcyB0byBkZXZlbG9wIG5ldw0KWUFORyBkYXRhIG1vZGVscyBm b3IgdGhlIFNlcnZpY2UgSW50ZXJmYWNlIExvZ2ljDQpUaGlzIHRyYW5zZmVycyB0aGUgd29yayBz cGVjaWZpZWQgYnkgdGhlIFJlc291cmNlIGFuZCBTZXJ2aWNlIFlBTkcNCmRhdGEgbW9kZWxzIHNw ZWNpZmllZCBpbiBJRVRGIGludG8gdGhlIFNlcnZpY2UgSW50ZXJmYWNlIExvZ2ljLg0KDQoNCioq IEVkaXRvcmlhbCAqKg0KDQpTZWN0aW9uIDEsIHBhZ2UgMw0KPlRoZSBFQ0ENClBvbGljeSBSdWxl IEluZm9ybWF0aW9uIE1vZGVsIChFUFJJTSkgW0ktRC5pZXRmLXN1cGEtZ2VuZXJpYy1wb2xpY3lp bmZvLQ0KbW9kZWxdIGV4dGVuZHMgdGhlIEdQSU0gdG8gZGVmaW5lIGhvdyB0byBidWlsZCBwb2xp Y3kgcnVsZXMNCmFjY29yZGluZyB0byB0aGUgZXZlbnQtY29uZGl0aW9uLWFjdGlvbiBwYXJhZGln bS4NCg0KUGxlYXNlIGNoYW5nZSB0byAiVGhlIEVDQQ0KUG9saWN5IFJ1bGUgSW5mb3JtYXRpb24g TW9kZWwgKEVQUklNKSBbSS1ELmlldGYtc3VwYS1nZW5lcmljLXBvbGljeWluZm8tDQptb2RlbF0g ZXh0ZW5kcyB0aGUgR1BJTSBieSBkZWZpbmluZyBob3cgdG8gYnVpbGQgcG9saWN5IHJ1bGVzDQph Y2NvcmRpbmcgdG8gdGhlIGV2ZW50LWNvbmRpdGlvbi1hY3Rpb24gcGFyYWRpZ20uDQoNCg0KDQoN CiogU2VjdGlvbiAyLCBwYWdlIDM6DQoNCg0KPkVQUklNOiBFQ0EgUG9saWN5IFJ1bGUgSW5mb3Jt YXRpb24gTW9kZWwsIHdoaWNoIGV4dGVuZHMgdGhlIEdQSU0gdG8NCmRlZmluZSBob3cgdG8gYnVp bGQgcG9saWN5IHJ1bGVzIGFjY29yZGluZyB0byB0aGUgZXZlbnQtY29uZGl0aW9uYWN0aW9uDQpw YXJhZGlnbS4NCg0KQ2hhbmdlIHRvDQpFUFJJTTogRUNBIFBvbGljeSBSdWxlIEluZm9ybWF0aW9u IE1vZGVsLCB3aGljaCBleHRlbmRzIHRoZSBHUElNIGJ5IGRlZmluaW5nIGhvdyB0byBidWlsZCBw b2xpY3kgcnVsZXMgYWNjb3JkaW5nIHRvIHRoZSBldmVudC1jb25kaXRpb25hY3Rpb24NCnBhcmFk aWdtLg0KDQoNCiogU2VjdGlvbiAyIGFuZCBwYWdlIDM6DQoNCj5HUERNOiBHZW5lcmljIFBvbGlj eSBEYXRhIE1vZGVscyBbSS1ELmlldGYtc3VwYS1nZW5lcmljLXBvbGljeS1kYXRhbW9kZWxdLA0K YXJlIGNyZWF0ZWQgZnJvbSB0aGUgR1BJTS4gVGhlc2UgWUFORyBkYXRhIG1vZGVsIHBvbGljaWVz DQphcmUgdXNlZCB0byBjb250cm9sIHRoZSBjb25maWd1cmF0aW9uIG9mIG5ldHdvcmsgZWxlbWVu dHMgdGhhdCBtb2RlbA0KdGhlIHNlcnZpY2UocykgdG8gYmUgbWFuYWdlZCB1c2luZyBwb2xpY3ku DQoNCkNoYW5nZSB0bw0KR1BETTogR2VuZXJpYyBQb2xpY3kgRGF0YSBNb2RlbHMgW0ktRC5pZXRm LXN1cGEtZ2VuZXJpYy1wb2xpY3ktZGF0YW1vZGVsXSwNCmFyZSBjcmVhdGVkIGZyb20gdGhlIEdQ SU0uIFRoZXNlIFlBTkcgZGF0YSBtb2RlbCBwb2xpY2llcw0KYXJlIHVzZWQgdG8gY29udHJvbCB0 aGUgY29uZmlndXJhdGlvbiBvZiBuZXR3b3JrIGVsZW1lbnRzIHRoYXQgbW9kZWwNCnRoZSBzZXJ2 aWNlKHMpIHRvIGJlIG1hbmFnZWQuDQoNCiogU2VjdGlvbiAzLjEgYW5kIHBhZ2UgNToNCj5GaWd1 cmUgMSBpcyBleGVtcGxhcnkuIFRoZSBPcGVyYXRvciBhY3RvciBzaG93biBpbiBGaWd1cmUgMSBj YW4NCmludGVyYWN0IHdpdGggU1VQQSBpbiBvdGhlciB3YXlzIG5vdCBzaG93biBpbiBGaWd1cmUg MS4NCg0KQ2hhbmdlIHRvDQpGaWd1cmUgMSBpcyBleGVtcGxhcnkuIFRoZSBPcGVyYXRvciBhY3Rv ciBjYW4NCmludGVyYWN0IHdpdGggU1VQQSBpbiBvdGhlciB3YXlzIG5vdCBzaG93biBpbiBGaWd1 cmUgMS4NCg0KKiBTZWN0aW9uIDMuMSBhbmQgcGFnZSA2Og0KDQo+QSBzZXQgb2YgR2VuZXJpYyBQ b2xpY3kgRGF0YSBNb2RlbHMgKEdQRE0pIGFyZSB0aGVuIGNyZWF0ZWQgZnJvbSB0aGUNCkdQSU0u IFRoZXNlIFlBTkcgZGF0YSBtb2RlbCBwb2xpY2llcyBhcmUgdGhlbiB1c2VkIHRvIGNvbnRyb2wg dGhlDQpjb25maWd1cmF0aW9uIG9mIG5ldHdvcmsgZWxlbWVudHMgdGhhdCBtb2RlbCB0aGUgc2Vy dmljZShzKSB0byBiZQ0KbWFuYWdlZCB1c2luZyBwb2xpY3kuDQoNCkNoYW5nZSB0bw0KQSBzZXQg b2YgR2VuZXJpYyBQb2xpY3kgRGF0YSBNb2RlbHMgKEdQRE0pIGFyZSB0aGVuIGNyZWF0ZWQgZnJv bSB0aGUNCkdQSU0uIFRoZXNlIFlBTkcgZGF0YSBtb2RlbCBwb2xpY2llcyBhcmUgdGhlbiB1c2Vk IHRvIGNvbnRyb2wgdGhlDQpjb25maWd1cmF0aW9uIG9mIG5ldHdvcmsgZWxlbWVudHMgdGhhdCBt b2RlbCB0aGUgc2VydmljZShzKSB0byBiZQ0KbWFuYWdlZC4NCg0KKiBTZWN0aW9uIDMuMSBhbmQg cGFnZSA3Og0KDQo+RUNBIFBvbGljeSBSdWxlIERhdGEgTW9kZWw6IGEgbW9kZWwgb2YgcG9saWN5 IHJ1bGVzLCBkZXJpdmVkIGZyb20NCkVQUklNLCB0aGF0IGNvbnNpc3Qgb2YgYW4gZXZlbnQgY2xh dXNlLCBhIGNvbmRpdGlvbiBjbGF1c2UsIGFuZCBhbg0KYWN0aW9uIGNsYXVzZS4NCg0KQ2hhbmdl IHRvDQpFQ0EgUG9saWN5IFJ1bGUgRGF0YSBNb2RlbDogYSBtb2RlbCBvZiBwb2xpY3kgcnVsZXMs IGRlcml2ZWQgZnJvbQ0KRVBSSU0sIHdoaWxlIGVhY2ggcG9saWN5IHJ1bGUgY29uc2lzdHMgb2Yg YW4gZXZlbnQgY2xhdXNlLCBhIGNvbmRpdGlvbiBjbGF1c2UsIGFuZCBhbg0KYWN0aW9uIGNsYXVz ZS4NCg0KKiBTZWN0aW9uIDMuMSBhbmQgcGFnZSA4Og0KDQo+TGluZSAoMSkgYW5kICgyKQ0KY29u bmVjdGluZyBwb2xpY3kgdG8gcmVzb3VyY2UgYW5kIHBvbGljeSB0byBzZXJ2aWNlIGFyZSBzYW1l LCBhbmQNCmxpbmUgKDMpIGNvbm5lY3RpbmcgcmVzb3VyY2UgdG8gc2VydmljZSBpcyBkaWZmZXJl bnQgYXMgaXShr3MNCm5hdmlnYWJsZSBvbmx5IGZyb20gcmVzb3VyY2UgdG8gc2VydmljZS4NCg0K Q2hhbmdlIHRvDQpMaW5lICgxKSBhbmQgKDIpDQpjb25uZWN0aW5nIHBvbGljeSB0byByZXNvdXJj ZSBhbmQgcG9saWN5IHRvIHNlcnZpY2UgYXJlIHRoZSBzYW1lLCBhbmQNCmxpbmUgKDMpIGNvbm5l Y3RpbmcgcmVzb3VyY2UgdG8gc2VydmljZSBpcyBkaWZmZXJlbnQgYXMgaXShr3MNCm5hdmlnYWJs ZSBvbmx5IGZyb20gcmVzb3VyY2UgdG8gc2VydmljZS4NCg0KKiBTZWN0aW9uIDMuMyBhbmQgcGFn ZSA4Og0KDQo+VGhlIEdQSU0gcHJvdmlkZXMgYSBjb21tb24gdm9jYWJ1bGFyeSBmb3IgcmVwcmVz ZW50aW5nIGNvbmNlcHRzIHRoYXQNCmFyZSBjb21tb24gdG8gZXhwcmVzc2luZyBkaWZmZXJlbnQg dHlwZXMgb2YgcG9saWN5LCBidXQgd2hpY2ggYXJlDQppbmRlcGVuZGVudCBvZiBsYW5ndWFnZSwg cHJvdG9jb2wsIHJlcG9zaXRvcnksIGFuZCBsZXZlbCBvZg0KYWJzdHJhY3Rpb24uDQoNCkNoYW5n ZSB0bw0KVGhlIEdQSU0gcHJvdmlkZXMgYSBjb21tb24gdm9jYWJ1bGFyeSBmb3IgcmVwcmVzZW50 aW5nIGNvbmNlcHRzIHRoYXQNCmFyZSBjb21tb24gdG8gZGlmZmVyZW50IHR5cGVzIG9mIHBvbGlj eSwgYnV0IHdoaWNoIGFyZQ0KaW5kZXBlbmRlbnQgb2YgbGFuZ3VhZ2UsIHByb3RvY29sLCByZXBv c2l0b3J5LCBhbmQgbGV2ZWwgb2YNCmFic3RyYWN0aW9uLg0KDQoqIFNlY3Rpb24gMy4zIGFuZCBw YWdlIDk6DQoNCj5UaGUgR1BJTSBwcm92aWRlcyBhIGNvbW1vbiB2b2NhYnVsYXJ5IGZvciByZXBy ZXNlbnRpbmcgY29uY2VwdHMgdGhhdA0KYXJlIGNvbW1vbiB0byBleHByZXNzaW5nIGRpZmZlcmVu dCB0eXBlcyBvZiBwb2xpY3ksDQoNCmNoYW5nZSB0bw0KVGhlIEdQSU0gcHJvdmlkZXMgYSBjb21t b24gdm9jYWJ1bGFyeSBmb3IgcmVwcmVzZW50aW5nIGNvbmNlcHRzIHRoYXQNCmFyZSBjb21tb24g dG8gZGlmZmVyZW50IHR5cGVzIG9mIHBvbGljeSwNCg0KKiBTZWN0aW9uIDMuNCBhbmQgcGFnZSAx MDoNCg0KPlRoZSBZQU5HIG1vZHVsZSBkZXJpdmVkIGZyb20gdGhlIEdQSU0gY29udGFpbnMgY29u Y2VwdHMgYW5kDQp0ZXJtaW5vbG9neSBmb3IgdGhlIGNvbW1vbiBvcGVyYXRpb24gYW5kIGFkbWlu aXN0cmF0aW9uIG9mIHBvbGljeS0NCmJhc2VkIHN5c3RlbXMsIGFzIHdlbGwgYXMgYW4gZXh0ZW5z aWJsZSBzdHJ1Y3R1cmUgZm9yIHBvbGljeSBydWxlcyBvZg0KZGlmZmVyZW50IHBhcmFkaWdtcy4g VGhlIFlBTkcgbW9kdWxlIGRlcml2ZWQgZnJvbSB0aGUgRVBSSU0gZXh0ZW5kcw0KdGhlIGdlbmVy aWMgbmF0dXJlIG9mIHRoZSBHUElNIHRvIHJlcHJlc2VudCBwb2xpY2llcyB1c2luZyBhbiBldmVu dC0NCmNvbmRpdGlvbi1hY3Rpb24gc3RydWN0dXJlLg0KVGhlIGFib3ZlIHNlcXVlbmNlIGFsbG93 cyBmb3IgdGhlIGFkZGl0aW9uIG9mIG5ldywgYXMgd2VsbCBhcyB0aGUNCmVkaXRpbmcgb2YgZXhp c3RpbmcgbW9kZWwgZWxlbWVudHMgaW4gdGhlIEdQSU0gYW5kIEVQUklNLiBJbg0KcHJhY3RpY2Us IHRoZSBpbXBsZW1lbnRhdGlvbiBzZXF1ZW5jZSBtYXkgYmUgbXVjaCBzaW1wbGVyLg0KU3BlY2lm aWNhbGx5LCBpdCBpcyB1bmxpa2VseSB0aGF0IHRoZSBHUElNIHdpbGwgbmVlZCB0byBiZSBjaGFu Z2VkLg0KSW4gYWRkaXRpb24sIGNoYW5nZXMgdG8gdGhlIEVQUklNIHdpbGwgbGlrZWx5IGJlIGZv Y3VzZWQgb24gZmluZS0NCnR1bmluZyB0aGUgYmVoYXZpb3Igb2ZmZXJlZCBieSBhIHNwZWNpZmlj IHNldCBvZiBtb2RlbCBlbGVtZW50cy4NCg0KQ2hhbmdlIHRvDQpUaGUgWUFORyBtb2R1bGUgZGVy aXZlZCBmcm9tIHRoZSBHUElNIGNvbnRhaW5zIGNvbmNlcHRzIGFuZA0KdGVybWlub2xvZ3kgZm9y IHRoZSBjb21tb24gb3BlcmF0aW9uIGFuZCBhZG1pbmlzdHJhdGlvbiBvZiBwb2xpY3ktDQpiYXNl ZCBzeXN0ZW1zLCBhcyB3ZWxsIGFzIGFuIGV4dGVuc2libGUgc3RydWN0dXJlIGZvciBwb2xpY3kg cnVsZXMgb2YNCmRpZmZlcmVudCBwYXJhZGlnbXMuIFRoZSBZQU5HIG1vZHVsZSBkZXJpdmVkIGZy b20gdGhlIEVQUklNIGV4dGVuZHMNCnRoZSBnZW5lcmljIG5hdHVyZSBvZiB0aGUgR1BJTSBieSBy ZXByZXNlbnRpbmcgcG9saWNpZXMgdXNpbmcgYW4gZXZlbnQNCmNvbmRpdGlvbi1hY3Rpb24gc3Ry dWN0dXJlLg0KVGhlIGFib3ZlIHNlcXVlbmNlIGFsbG93cyBmb3IgdGhlIGFkZGl0aW9uIG9mIG5l dywgYXMgd2VsbCBhcyB0aGUNCmVkaXRpbmcgb2YgZXhpc3RpbmcgbW9kZWwgZWxlbWVudHMgaW4g dGhlIEdQSU0gYW5kIEVQUklNLiBJbg0KcHJhY3RpY2UsIHRoZSBpbXBsZW1lbnRhdGlvbiBzZXF1 ZW5jZSBtYXkgYmUgbXVjaCBzaW1wbGVyLg0KU3BlY2lmaWNhbGx5LCBpdCBpcyB1bmxpa2VseSB0 aGF0IHRoZSBHUElNIHdpbGwgbmVlZCB0byBiZSBjaGFuZ2VkLg0KQ2hhbmdlcyB0byB0aGUgRVBS SU0gd2lsbCBsaWtlbHkgYmUgZm9jdXNlZCBvbiBmaW5lLQ0KdHVuaW5nIHRoZSBiZWhhdmlvciBv ZmZlcmVkIGJ5IGEgc3BlY2lmaWMgc2V0IG9mIG1vZGVsIGVsZW1lbnRzLg0KDQpCUi9HdW50ZXIN Cg0K --_000_C9B5F12337F6F841B35C404CF0554ACB8A32B237dggeml510mbxchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Dear Gunter,

 

Many thanks for your detailed comment= s. We=A1=AFve just updated the draft using all of them. Please have a look = at the new version and let us know if there is anything missing.

 

Regar= ds, / =D6=C2=C0=F1!

Will = LIU  / =C1=F5=CA=F7=B3=C9

 

From: S= UPA [mailto:supa-bounces@ietf.org] On Behalf Of Gunter Wang
Sent: Saturday, May 27, 2017 7:01 PM
To: supa@ietf.org
Subject: [Supa] supa framework review

 

Hi, all

 = ;

After reviewing the supa architecture draft,  I give some of the= comments as follows,

 

* Section 1= , page 2:

 

> The ra= pid growth in the variety and importance of traffic flowing

over increa= singly complex enterprise and service provider network<= o:p>

architectur= es makes the task of network operations and management<= o:p>

application= s deploying new services much more difficult. In

addition, n= etwork operators want to deploy new services quickly and

efficiently= .

 

It sound= s like that the growth of importance of ... makes the task more difficult. = It doesn't make sense.

 

Traffic = flow over increasingly complex enterprise and service provider network beco= mes more and more important. Meanwhile, the rapid growth of the variety makes the task of network operations and management = applications deploying new services much more difficult, Moreover, network = operators want to deploy new services quickly and efficiently.

 

* Section 3= .1, page 4:

 

>Note th= at YANG models may not exist. In this case, the SUPA generic

policy YANG= data modules serve as an extensible basis to develop new

YANG data m= odels for the Service Interface Logic to create

appropriate= input mechanisms for the operator to define policies.<= o:p>

This transf= ers the work specified by the Resource and Service YANG

data models= specified in IETF into the Service Interface Logic, which

is then tra= nslated to configuration snippets.

 

already = explained in above paragraph, delete it? Too long to understand<= span style=3D"font-size:11.0pt;font-family:"Calibri",sans-serif;c= olor:black">

 

Change to

Note that Y= ANG models may not exist. In this case, the SUPA generic

policy YANG= data modules serve as an extensible basis to develop new

YANG data m= odels for the Service Interface Logic

This transf= ers the work specified by the Resource and Service YANG

data models= specified in IETF into the Service Interface Logic.

 

 

** Editorial **<= /span>

 

Section 1, = page 3

>The ECA=

Policy Rule= Information Model (EPRIM) [I-D.ietf-supa-generic-policyinfo-

model] exte= nds the GPIM to define how to build policy rules

according t= o the event-condition-action paradigm.

 

Please chan= ge to "The ECA

Policy Rule= Information Model (EPRIM) [I-D.ietf-supa-generic-policyinfo-

model] exte= nds the GPIM by defining how to build policy rules=

according t= o the event-condition-action paradigm.

 

 

 

 

* Section 2, page 3:

 

 

>EPRIM: = ECA Policy Rule Information Model, which extends the GPIM to

define how = to build policy rules according to the event-conditionaction

paradigm.

 

Change to=

EPRIM: ECA = Policy Rule Information Model, which extends the GPIM by defining how to bu= ild policy rules according to the event-conditionaction

paradigm.

 

 

* Section 2 and page 3:

 

>GPDM: G= eneric Policy Data Models [I-D.ietf-supa-generic-policy-datamodel],<= span style=3D"font-size:11.0pt;font-family:"Calibri",sans-serif;c= olor:black">

are created= from the GPIM. These YANG data model policies

are used to= control the configuration of network elements that model

the service= (s) to be managed using policy.

 

Change to

GPDM: Gener= ic Policy Data Models [I-D.ietf-supa-generic-policy-datamodel],

are created= from the GPIM. These YANG data model policies

are used to= control the configuration of network elements that model

the service= (s) to be managed.

 

* Section 3.1 and page 5:

>Figure = 1 is exemplary. The Operator actor shown in Figure 1 can

interact wi= th SUPA in other ways not shown in Figure 1.=

 

Change to

Figure 1 is= exemplary. The Operator actor can

interact wi= th SUPA in other ways not shown in Figure 1.=

 

* Section 3.1 and page 6:

 

>A set o= f Generic Policy Data Models (GPDM) are then created from the

GPIM. These= YANG data model policies are then used to control the<= o:p>

configurati= on of network elements that model the service(s) to be<= o:p>

managed usi= ng policy.

 

Change to

A set of Ge= neric Policy Data Models (GPDM) are then created from the

GPIM. These= YANG data model policies are then used to control the<= o:p>

configurati= on of network elements that model the service(s) to be<= o:p>

managed.

 

* Section 3.1 and page 7:

 

>ECA Pol= icy Rule Data Model: a model of policy rules, derived from

EPRIM, that= consist of an event clause, a condition clause, and an

action clau= se.

 

Change to

ECA Policy = Rule Data Model: a model of policy rules, derived from<= o:p>

EPRIM, while each policy ru= le consists of an event clause, a condition clause, and an

action clau= se.

 

* Section 3.1 and page 8:

 

>Line (1= ) and (2)

connecting = policy to resource and policy to service are same, and<= o:p>

line (3) co= nnecting resource to service is different as it=A1=AFs<= o:p>

navigable o= nly from resource to service.

 

Change to

Line (1) an= d (2)

connecting = policy to resource and policy to service are the same, and=

line (3) co= nnecting resource to service is different as it=A1=AFs<= o:p>

navigable o= nly from resource to service.

 

* Section 3.3 and page 8:

 

>The GPI= M provides a common vocabulary for representing concepts that

are common = to expressing different types of policy, but which are<= o:p>

independent= of language, protocol, repository, and level of

abstraction= .

 

Change to

The GPIM pr= ovides a common vocabulary for representing concepts that

are common = to different types of policy, but which are<= /span>

independent= of language, protocol, repository, and level of

abstraction= .

 

* Section 3.3 and page 9:

 

>The GPI= M provides a common vocabulary for representing concepts that

are common = to expressing different types of policy,

 

change to

The GPIM pr= ovides a common vocabulary for representing concepts that

are common = to different types of policy,

 

* Section 3.4 and page 10:<= o:p>

 

>The YAN= G module derived from the GPIM contains concepts and

terminology= for the common operation and administration of policy-

based syste= ms, as well as an extensible structure for policy rules of

different p= aradigms. The YANG module derived from the EPRIM extends

the generic= nature of the GPIM to represent policies using an event-

condition-a= ction structure.

The above s= equence allows for the addition of new, as well as the<= o:p>

editing of = existing model elements in the GPIM and EPRIM. In<= /o:p>

practice, t= he implementation sequence may be much simpler.

Specificall= y, it is unlikely that the GPIM will need to be changed.

In addition= , changes to the EPRIM will likely be focused on fine-<= o:p>

tuning the = behavior offered by a specific set of model elements.

 

Change to

The YANG mo= dule derived from the GPIM contains concepts and

terminology= for the common operation and administration of policy-

based syste= ms, as well as an extensible structure for policy rules of

different p= aradigms. The YANG module derived from the EPRIM extends

the generic= nature of the GPIM by representing policies using an event

condition-a= ction structure.

The above s= equence allows for the addition of new, as well as the<= o:p>

editing of = existing model elements in the GPIM and EPRIM. In<= /o:p>

practice, t= he implementation sequence may be much simpler.

Specificall= y, it is unlikely that the GPIM will need to be changed.

Changes to = the EPRIM will likely be focused on fine-

tuning the = behavior offered by a specific set of model elements.

 

BR/Gunter

 

--_000_C9B5F12337F6F841B35C404CF0554ACB8A32B237dggeml510mbxchi_-- From nobody Mon Jul 3 09:16:28 2017 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 6E2BC129AD1; Mon, 3 Jul 2017 09:16:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 TNaIYjC217JF; Mon, 3 Jul 2017 09:16:20 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0123.outbound.protection.outlook.com [104.47.1.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E29FB128A32; Mon, 3 Jul 2017 09:16:19 -0700 (PDT) Received: from DB6PR0601MB2167.eurprd06.prod.outlook.com (10.168.57.26) by DB6PR0601MB2168.eurprd06.prod.outlook.com (10.168.57.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1220.11; Mon, 3 Jul 2017 16:16:16 +0000 Received: from DB6PR0601MB2167.eurprd06.prod.outlook.com ([fe80::d82f:5230:5e12:43b4]) by DB6PR0601MB2167.eurprd06.prod.outlook.com ([fe80::d82f:5230:5e12:43b4%13]) with mapi id 15.01.1220.015; Mon, 3 Jul 2017 16:16:17 +0000 From: "Diego R. Lopez" To: Benoit Claise CC: "King, Daniel" , SUPA list , "ops-ads@ietf.org" , "supa-chairs@ietf.org" Thread-Topic: [Supa] SUPA Update Thread-Index: AdLlx7FI0gJYsnA1SY+UuT+jZNMvmgADbe8AAPFY1oAAYHD9AAI+yDMA Date: Mon, 3 Jul 2017 16:16:16 +0000 Message-ID: <77C6AB0B-58D5-45CD-A6D7-C3271AD76E81@telefonica.com> References: <65174429B5AF4C45BD0798810EC48E0A942C73B2@EX-0-MB2.lancs.local> <666784c3-d4df-9fa1-9661-d8e182e2c7da@cisco.com> <3790BAEB-0E40-413B-BD84-60EE2E9CF483@telefonica.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=telefonica.com; x-originating-ip: [195.76.232.154] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB6PR0601MB2168; 7:7220WnSNrpbG+TvpoJf/gtTTx6cfIhbkh4c1v+qeaDUaN3cCnyS1k7tJr1y7wU0SGrjVv8D4B3A+Q3r/s48NqakEWb0XDyY2//eDm0d6pHoxi+Lp0N9qF8Qtpn2hPgi1swhZN1BXQJWcvk0It4frt8e0Y+XhsmdlvpbvFbzYIrVOca0Xn8XI+wLoe2zdtI5iTyOCI0LITKYupuRfSrutsSWA2Kdaz8qyBfOuzqjOdnTFQcecqY+lOfSfBcggtQzvNNfODeIoegzSE521nadcUNactmTjMXrD5f9tpUNdiMz1AG8AgDUmPGWwMdXJWwIMzpXcAXrbZHRSCCw+GHneudoHApW2hE8+HzbY8SO1N7CKgcDZqMq0hYF2AFZkO6XkBoBezDRVnHW9iUtdjxqLlEXHVJ7e7zph5nG1dItPMun5EFMW5sLGdDQBdtH2SCVz3zqeI8v1YRpCSEsbG4m1f1Iq0kD2ho8DcR7cgNn8nchIDtb4lsX+TTkNSD2yMvu7IwGRm+HVVle+Vrwuy2V3LakucEBngCIOJvTs0RbKbauJA8fN/K9wYwVYazpt916VzYCFxj6ABapk2SZ9PllrroAG1eIs539pRO/maGPqcts0W5JRg6lQiRwPOZYVhWS1QY1Cn9pvUGjF8t1xJYIpeFmGAkMBoLEq7UdHXJzdi4ttZLOPlETk5C/XFzp7tlRuH4bCDDLt1qKlgsGVi4VdByF0H4WtZWehcnwrWsBeGKlW3Vp6LU07uV5tqw1AW3eq0nfdMbehJ9Ve3mho8b8oOxWyavGzqqLuzJa2OBcPKB4= x-ms-office365-filtering-correlation-id: 3541a7ea-c5b7-4818-9f88-08d4c22ed564 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(48565401081)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DB6PR0601MB2168; x-ms-traffictypediagnostic: DB6PR0601MB2168: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(278178393323532)(40392960112811)(236129657087228)(192374486261705)(788757137089)(95692535739014)(92977632026198)(167848164394848)(5213294742642); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(100000703101)(100105400095)(3002001)(10201501046)(6055026)(6041248)(20161123564025)(20161123560025)(20161123558100)(20161123555025)(201703131423075)(201702281528075)(201702281529075)(201703061421075)(201703061406153)(20161123562025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DB6PR0601MB2168; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DB6PR0601MB2168; x-forefront-prvs: 035748864E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39400400002)(39410400002)(39450400003)(39860400002)(39840400002)(39850400002)(252514010)(40134004)(24454002)(6506006)(6436002)(66066001)(33656002)(82746002)(83716003)(7110500001)(966005)(14454004)(53546010)(3846002)(102836003)(6116002)(15650500001)(93886004)(6486002)(229853002)(478600001)(5250100002)(189998001)(3660700001)(36756003)(236005)(6512007)(7736002)(54896002)(6306002)(50986999)(6246003)(5660300001)(3280700002)(38730400002)(2900100001)(53386004)(99286003)(110136004)(2950100002)(2420400007)(25786009)(6916009)(76176999)(10710500007)(54356999)(2906002)(53936002)(81166006)(8676002)(4326008)(8936002)(606006)(575784001)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6PR0601MB2168; H:DB6PR0601MB2167.eurprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_77C6AB0B58D545CDA6D7C3271AD76E81telefonicacom_" MIME-Version: 1.0 X-OriginatorOrg: telefonica.com X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jul 2017 16:16:16.9657 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9744600e-3e04-492e-baa1-25ec245c6f10 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0601MB2168 Archived-At: Subject: Re: [Supa] SUPA Update X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.22 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: Mon, 03 Jul 2017 16:16:26 -0000 --_000_77C6AB0B58D545CDA6D7C3271AD76E81telefonicacom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Benoit, In the CogNet project (http://www.cognet.5g-ppp.eu) we are applying the dat= a models to express the policy rules (and the events and actions) derived f= rom the application of the so-called Smart Engine. We are discussing about = following a similar path in SHIELD (https://www.shield-h2020.eu) to express= security policies, and advocating for it in 5G-TRANSFORMER (http://5g-tran= sformer.eu) when expressing rules for policy-based management. The results = of these projects are being or will be transferred to our operational pract= ices, as well as what is being defined in I2NSF, where SUPA seems the natur= al data model for expressing policies to the Security Controller. Is tis the kind of statement you were asking for? Be goode, On 22 Jun 2017, at 07:58 , Benoit Claise > wrote: Hi Diego, Can you expand on the re-usability aspects. What is being reused? the information model, the data model, something else= ? I hope more than the concepts. What are you, yourself, reusing? Regards, Benoit Hi Benoit, While I cannot talk for YANG module authors, and it is true that the WG has= a significant delay in its deliverables, I =91d like to stress that SUPA h= as produced reusable work that is being used elsewhere, and a closing of th= e group before it finishes its commitments would damage these other works. = I am directly involved in the I2NSF WG (that is progressing quite well in m= y opinion), and in several collaborative European projects related with 5G = and security, including a number of network operators that are experimentin= g with SUPA-based policy statements. And I am aware of the ONUG interest as= well, though not being involved I cannot detail what they are targeting no= w. So I would ask you to reconsider the decision of closing SUPA at IETF 99. Be goode, On 15 Jun 2017, at 14:46 , Benoit Claise > wrote: Dear all, After the last IETF, I put a calendar reminder on June 16th to decide on th= e next steps for SUPA. This is inline with the our previous meeting minutes, so it should not come= as a surprise. Granted, this is one day earlier than foreseen, but the IESG agenda coordin= ation call takes place today, and it was important from a scheduling point = of view to understand if SUPA would meet. The chairs informed me that no SU= PA meeting is required in Prague. That triggered this discussion, just one = day earlier. Our meeting minutes: https://www.ietf.org/mail-archive/web/supa/current/msg= 01612.html At the SUPA WG at IETF 98 (Tuesday, 28 March) we discussed the progress of the WG. Benoit (our AD) summed up the situation, pointing out that our drafts are not updated very frequently, and that the SUPA mailing list has been very quiet between meetings. At the meeting the authors of the SUPA Information model and the SUPA Data Model drafts said that those drafts should be ready for WG Last Call by 1 June, so that they could be sent to IESG for approval by about 1 July. After summing up the pros and cons for SUPA continuing, Benoit concluded by saying that the WG will be closed at IETF 99 (Prague, 16 July) unless there is substantive progress on the Information Model and especially on the Data Model drafts by one month before the Prague meeting. 'Substantive progress' here means seeing comments on and/or reviews of these drafts demonstrating that people - outside the small group of authors - have carefully read the drafts, or better, that they are actually using SUPA's Information and Data Models. I've been watching the list. Since the last IETF meeting, we received two new drafts ... draft-ietf-supa-generic-policy-info-model-03.txt draft-ietf-supa-generic-policy-data-model-03.txt ... and some draft reviews: gunter.wang@ericsson.com on on draft-ietf-= supa-policy-based-management-framework: Good feedback but it seems like only editorial to me. Tony tianxu@chinamobile.com on draft-cheng-s= upa-applicability: Some editorial comments and three technical ones: 1. I wonder the meaning of section 3, the part copied from framework = draft, may not be needed. 2. I suggest to replace the title of 4.2.2.and 4.2.3 with detailed in= formation instead of writing just Example 1 / 2. 3. The writer wrote =93We will define "edgeInterface" role and "Enter= priseDomain" later in this note=94 but I failed to find the explanation fo= r these two term. Benoit =3D> it's more like one technical comment, the last one. Haining Wang: 18901341229@189.cn on draft-ietf-s= upa-generic-policy-data-model-03: I understand that the GPIM YANG model provides an example of how to convert= IM to DM (for general policy), and John=92s SNMP blocking example (https:/= /mailarchive.ietf.org/arch/msg/supa/DWEzaSBK6KBdsmQ0FE2-eypTzeY) exposes so= me details. But I am sorry that the whole picture is still not clear to me.= It would be nice if the ECA Data Model part can explain in more details. March Blanchet on draft-ietf-supa-policy-based-management-framework: - larger comment: I=92m not sure what to do with this document. It looks li= ke a large wish list of features. I guess I=92m probably too used to implem= entation/protocol details. I guess I will wait until to see the actual prot= ocol/yang models. Let's analyze the situation: I don't consider those reviews (btw a single one the DM, none on the IM) as= "substantive progress". I don't see interest from YANG module authors, ready to reuse the SUPA YANG= constructs. Being a year late according to the charter milestones, the window of opport= unity to produce reusable work has been closing rapidly. I believe that SUPA had multiple chances to make it happen, and failed to d= eliver. With this in mind, I don't see how I should conclude anything else than thi= s WG will be closing at IETF 99. Regards, Benoit (OPS AD) Dear supa=92rs, We have cancelled our formal meeting in Prague. This decision was taken bas= ed on a proposed plan to focus effort on completing the existing WG items a= nd prepare for closure of the supa working group sometime between IETF 99 a= nd 100. A plan that is yet to be approved by Benoit. During the last working group meeting Benoit stated: =93the WG will be closed at IETF 99 (Prague, 16 July) unless there is subst= antive progress on the Information Model and especially on the Data Model d= raft by one month before the Prague meeting.=94 The authors of the Data Model and Information Model I-Ds did submit new ver= sions but we only received one review. However, Nevil and I are working wit= h the IM and DM authors to gather reviewers in preparation of Last Call. Es= sentially, we are working to prep folks who would be able to review the doc= uments we Last Call, ideally these should be from policy/yang implementers. The Framework I-D has also received a review which is positive, and I am in= the process of reviewing the document myself to also help prepare the docu= ment for Last Call. Additionally, the Applicability I-D (a non-working grou= p document) received a review which is also useful. We have also seen notifications from other SDOs following supa, specificall= y: - ONUG: Investigating I2NSF combined with the SUPA data model and framework - ETSI Experiential Networked Intelligence (ENI): New initiative defining c= ontext aware networking systems, SUPA was identified as a key building bloc= k - MEF Open Lifecycle Service Orchestrator (LSO): Using SUPA between functio= nal components However, the indication from ONUG, ETSI and MEF does not materially change = the situation of SUPA but it does demonstrate wider interest in our work, a= nd at least some responsibility for supa/IETF to complete it (if possible).= If you are aware of near-term implementations now is the time to highlight= them. Again, we felt we did not need a WG meeting in Prague to progress the worki= ng group I-Ds, and given the IETF agenda coordination call (is today) we ha= d to cancel the supa WG session request ASAP, and unfortunately before we h= ad a chance to communicate the current situation to the rest of the working= group. Apologies for any surprise when you saw the cancellation notificati= on, and the lack of opportunity for wider discussion. As mentioned our proposed plan has been submitted to Benoit and is yet to b= e approved, therefore we will wait for his thoughts and ultimate decision. The SUPA Chairs would sincerely like to thank everyone for their participat= ion and especially the authors of I-Ds for their efforts. BR, Nevil and Dan. _______________________________________________ SUPA mailing list SUPA@ietf.org https://www.ietf.org/mailman/listinfo/supa -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D http://people.tid.es/diego.lopez/ e-mail: diego.r.lopez@telefonica.com Tel: +34 913 129 041 Mobile: +34 682 051 091 ---------------------------------- ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o= copia sin autorizaci=F3n puede estar prohibida en virtud de la legislaci= =F3n vigente. Si ha recibido este mensaje por error, le rogamos que nos lo = comunique inmediatamente por esta misma v=EDa y proceda a su destrucci=F3n. The information contained in this transmission is privileged and confidenti= al information intended only for the use of the individual or entity named = above. If the reader of this message is not the intended recipient, you are= hereby notified that any dissemination, distribution or copying of this co= mmunication is strictly prohibited. If you have received this transmission = in error, do not read it. Please immediately reply to the sender that you h= ave received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, div= ulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o pode estar proibida em virtude= da legisla=E7=E3o vigente. Se recebeu esta mensagem por erro, rogamos-lhe = que nos o comunique imediatamente por esta mesma via e proceda a sua destru= i=E7=E3o -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D http://people.tid.es/diego.lopez/ e-mail: diego.r.lopez@telefonica.com Tel: +34 913 129 041 Mobile: +34 682 051 091 ---------------------------------- ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o= copia sin autorizaci=F3n puede estar prohibida en virtud de la legislaci= =F3n vigente. Si ha recibido este mensaje por error, le rogamos que nos lo = comunique inmediatamente por esta misma v=EDa y proceda a su destrucci=F3n. The information contained in this transmission is privileged and confidenti= al information intended only for the use of the individual or entity named = above. If the reader of this message is not the intended recipient, you are= hereby notified that any dissemination, distribution or copying of this co= mmunication is strictly prohibited. If you have received this transmission = in error, do not read it. Please immediately reply to the sender that you h= ave received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, div= ulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o pode estar proibida em virtude= da legisla=E7=E3o vigente. Se recebeu esta mensagem por erro, rogamos-lhe = que nos o comunique imediatamente por esta mesma via e proceda a sua destru= i=E7=E3o --_000_77C6AB0B58D545CDA6D7C3271AD76E81telefonicacom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable Hi Benoit,

In the CogNet project (http://www.cognet.5g-ppp.eu) we are applying the data mo= dels to express the policy rules (and the events and actions) derived from = the application of the so-called Smart Engine. We are discussing about following a similar path in SHIELD (https://www.shield-h2020.eu) to express security policies, and advocating for it in 5G-TRANSFORMER (<= a href=3D"http://5g-transformer.eu" class=3D"">http://5g-transformer.eu= ) when expressing rules for policy-based management. The results of these pr= ojects are being or will be transferred to our operational practices, as we= ll as what is being defined in I2NSF, where SUPA seems the natural data mod= el for expressing policies to the Security Controller.

Is tis the kind of statement you were asking for?

Be goode,

On 22 Jun 2017, at 07:58 , Benoit Claise <bclaise@cisco.com> wrote:

Hi Diego,

Can you expand on the re-usability aspects.
What is being reused? the information model, the data model, something else= ? I hope more than the concepts.
What are you, yourself, reusing?

Regards, Benoit
Hi Benoit,

While I cannot talk for YANG module authors, and it is true= that the WG has a significant delay in its deliverables, I =91d like to st= ress that SUPA has produced reusable work that is being used elsewhere, and= a closing of the group before it finishes its commitments would damage these other works. I am directly involved in = the I2NSF WG (that is progressing quite well in my opinion), and in several= collaborative European projects related with 5G and security, including a = number of network operators that are experimenting with SUPA-based policy statements. And I am aware of the= ONUG interest as well, though not being involved I cannot detail what they= are targeting now.

So I would ask you to reconsider the decision of closing SU= PA at IETF 99.

Be goode,

On 15 Jun 2017, at 14:46 , Benoit Claise <bclaise@cisco.co= m> wrote:

Dear all,

After the last IETF, I put a calendar reminder on June 16th to decide on th= e next steps for SUPA.
This is inline with the our previous meeting minutes, so it should not come= as a surprise.
Granted, this is one day earlier than foreseen, but the IESG agenda coordin= ation call takes place today, and it was important from a scheduling point = of view to understand if SUPA would meet. The chairs informed me that no SU= PA meeting is required in Prague. That triggered this discussion, just one day earlier.

Our meeting minutes: https://www.ietf.org/mail-archive/web/supa/current/msg01612.html
At the SUPA WG at IETF 98 (Tuesday, =
28 March) we discussed the
progress of the WG.  Benoit (our AD) summed up the situation, pointing
out that our drafts are not updated very frequently, and that the SUPA
mailing list has been very quiet between meetings.

At the meeting the authors of the SUPA Information model and the SUPA
Data Model drafts said that those drafts should be ready for WG Last
Call by 1 June, so that they could be sent to IESG for approval by
about 1 July.

After summing up the pros and cons for SUPA continuing, Benoit
concluded by saying that the WG will be closed at IETF 99 (Prague, 16
July) unless there is substantive progress on the Information Model
and especially on the Data Model drafts by one month before the Prague
meeting.  'Substantive progress' here means seeing comments on and/or
reviews of these drafts demonstrating that people - outside the small
group of authors - have carefully read the drafts, or better, that they
are actually using SUPA's Information and Data Models.
I've been watching the list.
Since the last IETF meeting, we received two new drafts ...
    draft-ietf-supa-generic-policy-in= fo-model-03.txt
    draft-ietf-supa-generic-policy-data-model-03.txt
... and some draft reviews:
gunter.wang@ericsson.co= m on on draft-ietf-supa-policy-based-management-framework:
Good feedback but it seems like only editorial to me= .
Tony tianxu@chinamobile.com on draft-cheng-supa-applicability:
Some editorial comments and three technical ones:

1.       I wonder the meaning of sectio= n 3, the part copied from framework draft, may not be needed.

2.       I suggest to replace the title= of 4.2.2.and 4.2.3 with detailed information instead of writing just  = ; Example 1 / 2.

3. =       The writer wrote =93We will define "edgeInterface= " role and "EnterpriseDomain" later in  this note=94 bu= t I failed to find the explanation for these two term.
Benoit =3D> it's more like one technical comment,= the last one.

Haining Wang: 18901341229@189.cn on draft-ietf-supa-generic-policy-data-model-03:
I understand that th= e GPIM YANG model provides an example of how to convert IM to DM (for gener= al policy), and John=92s SNMP blocking example (https://mailarchive.ietf.org/arch/msg/supa/DWEzaSBK6KBdsmQ= 0FE2-eypTzeY) exposes some details. But I am sorry that the whole picture is still not c= lear to me. It would be nice if the ECA Data Model part can explain in more= details.

March Blanchet on draft-ietf-supa-policy-based-management-framework:
- larger comment: I=92m not sure what to do with thi= s document. It looks like a large wish list of features. I guess I=92m prob= ably too used to implementation/protocol details. I guess I will wait until= to see the actual protocol/yang models.

Let's analyze the situation:
I don't consider those reviews (btw a single one the DM, none on the IM) as= "substantive progress".
I don't see interest from YANG module authors, ready to reuse the SUPA YANG= constructs.
Being a year late according to the charter milestones, the window of opport= unity to produce reusable work has been closing rapidly.
I believe that SUPA had multiple chances to make it happen, and failed to d= eliver.
With this in mind, I don't see how I should conclude anything else than thi= s WG will be closing at IETF 99.

Regards, Benoit (OPS AD)

Dear supa=92rs,

 

We have cancelled our formal meeting in Prague. This= decision was taken based on a proposed plan to focus effort on completing = the existing WG items and prepare for closure of the supa working group som= etime between IETF 99 and 100. A plan that is yet to be approved by Benoit.

 

During the last working group meeting Benoit stated:=

 

=93the WG will be closed at IETF 99 (Prague, 16 July= ) unless there is substantive progress on the Information Model and especia= lly on the Data Model draft by one month before the Prague meeting.=94

 

The authors of the Data Model and Information Model = I-Ds did submit new versions but we only received one review. However, Nevi= l and I are working with the IM and DM authors to gather reviewers in prepa= ration of Last Call. Essentially, we are working to prep folks who would be able to review the documents we = Last Call, ideally these should be from policy/yang implementers.

 

The Framework I-D has also received a review which i= s positive, and I am in the process of reviewing the document myself to als= o help prepare the document for Last Call. Additionally, the Applicability = I-D (a non-working group document) received a review which is also useful.

 

We have also seen notifications from other SDOs foll= owing supa, specifically:

- ONUG: Investigating I2NSF combined with the SUPA d= ata model and framework

- ETSI Experiential Networked Intelligence (ENI): Ne= w initiative defining context aware networking systems, SUPA was identified= as a key building block

- MEF Open Lifecycle Service Orchestrator (LSO): Usi= ng SUPA between functional components

 

However, the indication from ONUG, ETSI and MEF does= not materially change the situation of SUPA but it does demonstrate wider = interest in our work, and at least some responsibility for supa/IETF to com= plete it (if possible). If you are aware of near-term implementations now is the time to highlight them.

 

Again, we felt we did not need a WG meeting in Pragu= e to progress the working group I-Ds, and given the IETF agenda coordinatio= n call (is today) we had to cancel the supa WG session request ASAP, and un= fortunately before we had a chance to communicate the current situation to the rest of the working group. Apo= logies for any surprise when you saw the cancellation notification, and the= lack of opportunity for wider discussion.

 

As mentioned our proposed plan has been submitted to= Benoit and is yet to be approved, therefore we will wait for his thoughts = and ultimate decision.

 

The SUPA Chairs would sincerely like to thank everyo= ne for their participation and especially the authors of I-Ds for their eff= orts.

 

BR, Nevil and Dan.


_______________________________________________
SUPA mailing list
SUPA@i= etf.org
https://www.ietf.org/mailman/listinfo/supa

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

e-mail: diego.r.lopez@telefonica.com
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------



Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o copia sin autorizaci=F3n puede e= star prohibida en virtud de la legislaci=F3n vigente. Si ha recibido este m= ensaje por error, le rogamos que nos lo comunique inmediatamente por esta m= isma v=EDa y proceda a su destrucci=F3n.

The information contained in this transmission is privileged and confidenti= al information intended only for the use of the individual or entity named = above. If the reader of this message is not the intended recipient, you are= hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If y= ou have received this transmission in error, do not read it. Please immedia= tely reply to the sender that you have received this communication in error= and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, divulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o p= ode estar proibida em virtude da legisla=E7=E3o vigente. Se recebeu esta me= nsagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mes= ma via e proceda a sua destrui=E7=E3o


--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.= es/diego.lopez/

e-mail: diego.r.lopez@telefonica.com
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------



Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o copia sin autorizaci=F3n puede e= star prohibida en virtud de la legislaci=F3n vigente. Si ha recibido este m= ensaje por error, le rogamos que nos lo comunique inmediatamente por esta m= isma v=EDa y proceda a su destrucci=F3n.

The information contained in this transmission is privileged and confidenti= al information intended only for the use of the individual or entity named = above. If the reader of this message is not the intended recipient, you are= hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If y= ou have received this transmission in error, do not read it. Please immedia= tely reply to the sender that you have received this communication in error= and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, divulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o p= ode estar proibida em virtude da legisla=E7=E3o vigente. Se recebeu esta me= nsagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mes= ma via e proceda a sua destrui=E7=E3o
 --_000_77C6AB0B58D545CDA6D7C3271AD76E81telefonicacom_-- From nobody Mon Jul 3 19:36:34 2017 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 0711F13010D; Mon, 3 Jul 2017 19:36:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 NFbDyB-s1EEp; Mon, 3 Jul 2017 19:36:30 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B681F127698; Mon, 3 Jul 2017 19:36:27 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DQI79791; Tue, 04 Jul 2017 02:36:25 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 4 Jul 2017 03:36:24 +0100 Received: from DGGEML406-HUB.china.huawei.com (10.3.17.50) by nkgeml412-hub.china.huawei.com (10.98.56.73) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 4 Jul 2017 10:36:09 +0800 Received: from DGGEML510-MBX.china.huawei.com ([169.254.2.202]) by dggeml406-hub.china.huawei.com ([10.3.17.50]) with mapi id 14.03.0301.000; Tue, 4 Jul 2017 10:36:05 +0800 From: "Liushucheng (Will Liu)" To: "supa@ietf.org" CC: "draft-ietf-supa-policy-based-management-framework@ietf.org" , Marc Blanchet , Johannes Merkle , Gunter Wang Thread-Topic: [Supa] I-D Action: draft-ietf-supa-policy-based-management-framework-02.txt Thread-Index: AQHS9ASvJkKv7zwGa0iYbOsjNa5/IKJC8SWQ Date: Tue, 4 Jul 2017 02:36:04 +0000 Message-ID: References: <149909039414.4017.3763247270248594953@ietfa.amsl.com> In-Reply-To: <149909039414.4017.3763247270248594953@ietfa.amsl.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.79.69] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.595AFF2A.0035, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.2.202, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: ae6482f1f576ea10e9e3b03ff39e6a29 Archived-At: Subject: [Supa] FW: I-D Action: draft-ietf-supa-policy-based-management-framework-02.txt X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.22 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: Tue, 04 Jul 2017 02:36:33 -0000 Dear all, We just updated the framework draft. Many thanks for the review and detaile= d comments we received on the list from Johannes, Marc and Gunter as well a= s the offline discussions. We've addressed all the comments. The main updates are in section 1, 2, 3.1= and 3.2 to make the draft clear and easy to understand. You may check the = changes via: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-supa-policy-bas= ed-management-framework-02 The comments and our corresponding responses can be found at: https://www.ietf.org/mail-archive/web/supa/current/msg01643.html https://www.ietf.org/mail-archive/web/supa/current/msg01642.html https://www.ietf.org/mail-archive/web/supa/current/msg01641.html Your comments to the new version are welcome! Regards,=20 Will LIU=20 -----Original Message----- From: SUPA [mailto:supa-bounces@ietf.org] On Behalf Of internet-drafts@ietf= .org Sent: Monday, July 03, 2017 10:00 PM To: i-d-announce@ietf.org Cc: supa@ietf.org Subject: [Supa] I-D Action: draft-ietf-supa-policy-based-management-framewo= rk-02.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Simplified Use of Policy Abstractions of t= he IETF. Title : SUPA Policy-based Management Framework Authors : Will(Shucheng) Liu Chongfeng Xie John Strassner Georgios Karagiannis Maxim Klyus Jun Bi Filename : draft-ietf-supa-policy-based-management-framework-02.txt Pages : 15 Date : 2017-07-03 Abstract: Simplified Use of Policy Abstractions (SUPA) defines base YANG data models to encode policy, which point to device-, technology-, and service-specific YANG models developed elsewhere. Policy rules within an operator's environment can be used to express high-level, possibly network-wide policies to a network management function (within a controller, an orchestrator, or a network element). The network management function can then control the configuration and/or monitoring of network elements and services. This document describes the SUPA basic framework, its elements and interfaces. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-supa-policy-based-management-fr= amework/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-supa-policy-based-management-framewo= rk-02 https://datatracker.ietf.org/doc/html/draft-ietf-supa-policy-based-manageme= nt-framework-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-supa-policy-based-management= -framework-02 Please note that it may take a couple of minutes from the time of submissio= n 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/ _______________________________________________ SUPA mailing list SUPA@ietf.org https://www.ietf.org/mailman/listinfo/supa From nobody Wed Jul 5 06:40:04 2017 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 A50C6132053; Wed, 5 Jul 2017 06:40:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 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.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 R5GCV8hxjW01; Wed, 5 Jul 2017 06:39:59 -0700 (PDT) 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 09B6E132A30; Wed, 5 Jul 2017 06:39:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=47128; q=dns/txt; s=iport; t=1499261998; x=1500471598; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=kNz63EZFsA7USnF1Ur7/BXZYiK3Q9EBk53wbS7A9xpw=; b=YcXko8UbBYkihu/fx8Fjmymob6pmDcnGz/2wMmIGorzVlC7S/hIm6JXa pQ2FOADwE8vSlUoNy8mM5WTLTmHLnyk7jcH/uZMR6E8q2i4+laDx30Boy b+c6811BcEQuEFZL+HFJVj284Iqjgs7YR0l/MBTjlLfASfraKyXv7BthR 8=; X-IronPort-AV: E=Sophos;i="5.40,312,1496102400"; d="scan'208,217";a="655886500" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Jul 2017 13:39:56 +0000 Received: from [10.55.221.38] (ams-bclaise-nitro5.cisco.com [10.55.221.38]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v65DdsHx031350; Wed, 5 Jul 2017 13:39:56 GMT To: "Diego R. Lopez" Cc: "King, Daniel" , SUPA list , "ops-ads@ietf.org" , "supa-chairs@ietf.org" , Benoit Claise References: <65174429B5AF4C45BD0798810EC48E0A942C73B2@EX-0-MB2.lancs.local> <666784c3-d4df-9fa1-9661-d8e182e2c7da@cisco.com> <3790BAEB-0E40-413B-BD84-60EE2E9CF483@telefonica.com> <77C6AB0B-58D5-45CD-A6D7-C3271AD76E81@telefonica.com> From: Benoit Claise Message-ID: <38bdf7e3-8d65-beeb-327f-f962f3b8f7da@cisco.com> Date: Wed, 5 Jul 2017 15:39:54 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <77C6AB0B-58D5-45CD-A6D7-C3271AD76E81@telefonica.com> Content-Type: multipart/alternative; boundary="------------E396D48C2CC808942E2AD81F" Content-Language: en-US Archived-At: Subject: Re: [Supa] SUPA Update X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.22 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: Wed, 05 Jul 2017 13:40:04 -0000 This is a multi-part message in MIME format. --------------E396D48C2CC808942E2AD81F Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi Diego, Thanks for the discussion. So you're applying the SUPA data model (draft-ietf-supa-generic-policy-data-model-04) ? Can you please share how you reuse them and what's your experience? Regards, Benoit > Hi Benoit, > > In the CogNet project (http://www.cognet.5g-ppp.eu) we are applying > the data models to express the policy rules (and the events and > actions) derived from the application of the so-called Smart Engine. > We are discussing about following a similar path in SHIELD > (https://www.shield-h2020.eu) to express security policies, and > advocating for it in 5G-TRANSFORMER (http://5g-transformer.eu) when > expressing rules for policy-based management. The results of these > projects are being or will be transferred to our operational > practices, as well as what is being defined in I2NSF, where SUPA seems > the natural data model for expressing policies to the Security Controller. > > Is tis the kind of statement you were asking for? > > Be goode, > >> On 22 Jun 2017, at 07:58 , Benoit Claise > > wrote: >> >> Hi Diego, >> >> Can you expand on the re-usability aspects. >> What is being reused? the information model, the data model, >> something else? I hope more than the concepts. >> What are you, yourself, reusing? >> >> Regards, Benoit >>> Hi Benoit, >>> >>> While I cannot talk for YANG module authors, and it is true that the >>> WG has a significant delay in its deliverables, I ‘d like to stress >>> that SUPA has produced reusable work that is being used elsewhere, >>> and a closing of the group before it finishes its commitments would >>> damage these other works. I am directly involved in the I2NSF WG >>> (that is progressing quite well in my opinion), and in several >>> collaborative European projects related with 5G and security, >>> including a number of network operators that are experimenting with >>> SUPA-based policy statements. And I am aware of the ONUG interest as >>> well, though not being involved I cannot detail what they are >>> targeting now. >>> >>> So I would ask you to reconsider the decision of closing SUPA at >>> IETF 99. >>> >>> Be goode, >>> >>>> On 15 Jun 2017, at 14:46 , Benoit Claise >>> > wrote: >>>> >>>> Dear all, >>>> >>>> After the last IETF, I put a calendar reminder on June 16th to >>>> decide on the next steps for SUPA. >>>> This is inline with the our previous meeting minutes, so it should >>>> not come as a surprise. >>>> Granted, this is one day earlier than foreseen, but the IESG agenda >>>> coordination call takes place today, and it was important from a >>>> scheduling point of view to understand if SUPA would meet. The >>>> chairs informed me that no SUPA meeting is required in Prague. That >>>> triggered this discussion, just one day earlier. >>>> >>>> Our meeting minutes: >>>> https://www.ietf.org/mail-archive/web/supa/current/msg01612.html >>>> >>>> At the SUPA WG at IETF 98 (Tuesday, 28 March) we discussed the >>>> progress of the WG. Benoit (our AD) summed up the situation, pointing >>>> out that our drafts are not updated very frequently, and that the SUPA >>>> mailing list has been very quiet between meetings. >>>> >>>> At the meeting the authors of the SUPA Information model and the SUPA >>>> Data Model drafts said that those drafts should be ready for WG Last >>>> Call by 1 June, so that they could be sent to IESG for approval by >>>> about 1 July. >>>> >>>> After summing up the pros and cons for SUPA continuing, Benoit >>>> concluded by saying that the WG will be closed at IETF 99 (Prague, 16 >>>> July) unless there is substantive progress on the Information Model >>>> and especially on the Data Model drafts by one month before the Prague >>>> meeting. 'Substantive progress' here means seeing comments on and/or >>>> reviews of these drafts demonstrating that people - outside the small >>>> group of authors - have carefully read the drafts, or better, that they >>>> are actually using SUPA's Information and Data Models. >>>> >>>> I've been watching the list. >>>> Since the last IETF meeting, we received two new drafts ... >>>> >>>> draft-ietf-supa-generic-policy-info-model-03.txt >>>> draft-ietf-supa-generic-policy-data-model-03.txt >>>> >>>> ... and some draft reviews: >>>> >>>> gunter.wang@ericsson.com on on >>>> draft-ietf-supa-policy-based-management-framework: >>>> >>>> Good feedback but it seems like only editorial to me. >>>> >>>> Tony tianxu@chinamobile.com on draft-cheng-supa-applicability: >>>> >>>> Some editorial comments and three technical ones: >>>> >>>> 1. I wonder the meaning of section 3, the part >>>> copied from framework draft, may not be needed. >>>> >>>> 2. I suggest to replace the title of 4.2.2.and >>>> 4.2.3 with detailed information instead of writing just >>>> Example 1 / 2. >>>> >>>> 3. The writer wrote “We will define >>>> "edgeInterface" role and "EnterpriseDomain" later in >>>> this note” but I failed to find the explanation for >>>> these two term. >>>> >>>> Benoit => it's more like one technical comment, the >>>> last one. >>>> >>>> >>>> Haining Wang: 18901341229@189.cn on >>>> draft-ietf-supa-generic-policy-data-model-03: >>>> >>>> I understand that the GPIM YANG model provides an >>>> example of how to convert IM to DM (for general >>>> policy), and John’s SNMP blocking example >>>> (https://mailarchive.ietf.org/arch/msg/supa/DWEzaSBK6KBdsmQ0FE2-eypTzeY) >>>> exposes some details. But I am sorry that the whole >>>> picture is still not clear to me. It would be nice if >>>> the ECA Data Model part can explain in more details. >>>> >>>> March Blanchet on >>>> draft-ietf-supa-policy-based-management-framework: >>>> >>>> - larger comment: I’m not sure what to do with this >>>> document. It looks like a large wish list of features. >>>> I guess I’m probably too used to >>>> implementation/protocol details. I guess I will wait >>>> until to see the actual protocol/yang models. >>>> >>>> >>>> Let's analyze the situation: >>>> I don't consider those reviews (btw a single one the DM, none on >>>> the IM) as "substantive progress". >>>> I don't see interest from YANG module authors, ready to reuse the >>>> SUPA YANG constructs. >>>> Being a year late according to the charter milestones, the window >>>> of opportunity to produce reusable work has been closing rapidly. >>>> I believe that SUPA had multiple chances to make it happen, and >>>> failed to deliver. >>>> With this in mind, I don't see how I should conclude anything else >>>> than this WG will be closing at IETF 99. >>>> >>>> Regards, Benoit (OPS AD) >>>>> >>>>> Dear supa’rs, >>>>> >>>>> We have cancelled our formal meeting in Prague. This decision was >>>>> taken based on a proposed plan to focus effort on completing the >>>>> existing WG items and prepare for closure of the supa working >>>>> group sometime between IETF 99 and 100. A plan that is yet to be >>>>> approved by Benoit. >>>>> >>>>> During the last working group meeting Benoit stated: >>>>> >>>>> “the WG will be closed at IETF 99 (Prague, 16 July) unless there >>>>> is substantive progress on the Information Model and especially on >>>>> the Data Model draft by one month before the Prague meeting.” >>>>> >>>>> The authors of the Data Model and Information Model I-Ds did >>>>> submit new versions but we only received one review. However, >>>>> Nevil and I are working with the IM and DM authors to gather >>>>> reviewers in preparation of Last Call. Essentially, we are working >>>>> to prep folks who would be able to review the documents we Last >>>>> Call, ideally these should be from policy/yang implementers. >>>>> >>>>> The Framework I-D has also received a review which is positive, >>>>> and I am in the process of reviewing the document myself to also >>>>> help prepare the document for Last Call. Additionally, the >>>>> Applicability I-D (a non-working group document) received a review >>>>> which is also useful. >>>>> >>>>> We have also seen notifications from other SDOs following supa, >>>>> specifically: >>>>> >>>>> - ONUG: Investigating I2NSF combined with the SUPA data model and >>>>> framework >>>>> >>>>> - ETSI Experiential Networked Intelligence (ENI): New initiative >>>>> defining context aware networking systems, SUPA was identified as >>>>> a key building block >>>>> >>>>> - MEF Open Lifecycle Service Orchestrator (LSO): Using SUPA >>>>> between functional components >>>>> >>>>> However, the indication from ONUG, ETSI and MEF does not >>>>> materially change the situation of SUPA but it does demonstrate >>>>> wider interest in our work, and at least some responsibility for >>>>> supa/IETF to complete it (if possible). If you are aware of >>>>> near-term implementations now is the time to highlight them. >>>>> >>>>> Again, we felt we did not need a WG meeting in Prague to progress >>>>> the working group I-Ds, and given the IETF agenda coordination >>>>> call (is today) we had to cancel the supa WG session request ASAP, >>>>> and unfortunately before we had a chance to communicate the >>>>> current situation to the rest of the working group. Apologies for >>>>> any surprise when you saw the cancellation notification, and the >>>>> lack of opportunity for wider discussion. >>>>> >>>>> As mentioned our proposed plan has been submitted to Benoit and is >>>>> yet to be approved, therefore we will wait for his thoughts and >>>>> ultimate decision. >>>>> >>>>> The SUPA Chairs would sincerely like to thank everyone for their >>>>> participation and especially the authors of I-Ds for their efforts. >>>>> >>>>> BR, Nevil and Dan. >>>>> >>>> >>>> _______________________________________________ >>>> SUPA mailing list >>>> SUPA@ietf.org >>>> https://www.ietf.org/mailman/listinfo/supa >>> >>> -- >>> "Esta vez no fallaremos, Doctor Infierno" >>> >>> Dr Diego R. Lopez >>> Telefonica I+D >>> http://people.tid.es/diego.lopez/ >>> >>> e-mail: diego.r.lopez@telefonica.com >>> Tel: +34 913 129 041 >>> Mobile: +34 682 051 091 >>> ---------------------------------- >>> >>> >>> ------------------------------------------------------------------------ >>> >>> Este mensaje y sus adjuntos se dirigen exclusivamente a su >>> destinatario, puede contener información privilegiada o confidencial >>> y es para uso exclusivo de la persona o entidad de destino. Si no es >>> usted. el destinatario indicado, queda notificado de que la lectura, >>> utilización, divulgación y/o copia sin autorización puede estar >>> prohibida en virtud de la legislación vigente. Si ha recibido este >>> mensaje por error, le rogamos que nos lo comunique inmediatamente >>> por esta misma vía y proceda a su destrucción. >>> >>> The information contained in this transmission is privileged and >>> confidential information intended only for the use of the individual >>> or entity named above. If the reader of this message is not the >>> intended recipient, you are hereby notified that any dissemination, >>> distribution or copying of this communication is strictly >>> prohibited. If you have received this transmission in error, do not >>> read it. Please immediately reply to the sender that you have >>> received this communication in error and then delete it. >>> >>> Esta mensagem e seus anexos se dirigem exclusivamente ao seu >>> destinatário, pode conter informação privilegiada ou confidencial e >>> é para uso exclusivo da pessoa ou entidade de destino. Se não é >>> vossa senhoria o destinatário indicado, fica notificado de que a >>> leitura, utilização, divulgação e/ou cópia sem autorização pode >>> estar proibida em virtude da legislação vigente. Se recebeu esta >>> mensagem por erro, rogamos-lhe que nos o comunique imediatamente por >>> esta mesma via e proceda a sua destruição >> > > -- > "Esta vez no fallaremos, Doctor Infierno" > > Dr Diego R. Lopez > Telefonica I+D > http://people.tid.es/diego.lopez/ > > e-mail: diego.r.lopez@telefonica.com > Tel: +34 913 129 041 > Mobile: +34 682 051 091 > ---------------------------------- > > > ------------------------------------------------------------------------ > > Este mensaje y sus adjuntos se dirigen exclusivamente a su > destinatario, puede contener información privilegiada o confidencial y > es para uso exclusivo de la persona o entidad de destino. Si no es > usted. el destinatario indicado, queda notificado de que la lectura, > utilización, divulgación y/o copia sin autorización puede estar > prohibida en virtud de la legislación vigente. Si ha recibido este > mensaje por error, le rogamos que nos lo comunique inmediatamente por > esta misma vía y proceda a su destrucción. > > The information contained in this transmission is privileged and > confidential information intended only for the use of the individual > or entity named above. If the reader of this message is not the > intended recipient, you are hereby notified that any dissemination, > distribution or copying of this communication is strictly prohibited. > If you have received this transmission in error, do not read it. > Please immediately reply to the sender that you have received this > communication in error and then delete it. > > Esta mensagem e seus anexos se dirigem exclusivamente ao seu > destinatário, pode conter informação privilegiada ou confidencial e é > para uso exclusivo da pessoa ou entidade de destino. Se não é vossa > senhoria o destinatário indicado, fica notificado de que a leitura, > utilização, divulgação e/ou cópia sem autorização pode estar proibida > em virtude da legislação vigente. Se recebeu esta mensagem por erro, > rogamos-lhe que nos o comunique imediatamente por esta mesma via e > proceda a sua destruição --------------E396D48C2CC808942E2AD81F Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Hi Diego,

Thanks for the discussion.
So you're applying the SUPA data model (draft-ietf-supa-generic-policy-data-model-04)?
Can you please share how you reuse them and what's your experience?

Regards, Benoit
Hi Benoit,

In the CogNet project (http://www.cognet.5g-ppp.eu) we are applying the data models to express the policy rules (and the events and actions) derived from the application of the so-called Smart Engine. We are discussing about following a similar path in SHIELD (https://www.shield-h2020.eu) to express security policies, and advocating for it in 5G-TRANSFORMER (http://5g-transformer.eu) when expressing rules for policy-based management. The results of these projects are being or will be transferred to our operational practices, as well as what is being defined in I2NSF, where SUPA seems the natural data model for expressing policies to the Security Controller.

Is tis the kind of statement you were asking for?

Be goode,

On 22 Jun 2017, at 07:58 , Benoit Claise <bclaise@cisco.com> wrote:

Hi Diego,

Can you expand on the re-usability aspects.
What is being reused? the information model, the data model, something else? I hope more than the concepts.
What are you, yourself, reusing?

Regards, Benoit
Hi Benoit,

While I cannot talk for YANG module authors, and it is true that the WG has a significant delay in its deliverables, I ‘d like to stress that SUPA has produced reusable work that is being used elsewhere, and a closing of the group before it finishes its commitments would damage these other works. I am directly involved in the I2NSF WG (that is progressing quite well in my opinion), and in several collaborative European projects related with 5G and security, including a number of network operators that are experimenting with SUPA-based policy statements. And I am aware of the ONUG interest as well, though not being involved I cannot detail what they are targeting now.

So I would ask you to reconsider the decision of closing SUPA at IETF 99.

Be goode,

On 15 Jun 2017, at 14:46 , Benoit Claise <bclaise@cisco.com> wrote:

Dear all,

After the last IETF, I put a calendar reminder on June 16th to decide on the next steps for SUPA.
This is inline with the our previous meeting minutes, so it should not come as a surprise.
Granted, this is one day earlier than foreseen, but the IESG agenda coordination call takes place today, and it was important from a scheduling point of view to understand if SUPA would meet. The chairs informed me that no SUPA meeting is required in Prague. That triggered this discussion, just one day earlier.

Our meeting minutes: https://www.ietf.org/mail-archive/web/supa/current/msg01612.html
At the SUPA WG at IETF 98 (Tuesday, 28 March) we discussed the
progress of the WG.  Benoit (our AD) summed up the situation, pointing
out that our drafts are not updated very frequently, and that the SUPA
mailing list has been very quiet between meetings.

At the meeting the authors of the SUPA Information model and the SUPA
Data Model drafts said that those drafts should be ready for WG Last
Call by 1 June, so that they could be sent to IESG for approval by
about 1 July.

After summing up the pros and cons for SUPA continuing, Benoit
concluded by saying that the WG will be closed at IETF 99 (Prague, 16
July) unless there is substantive progress on the Information Model
and especially on the Data Model drafts by one month before the Prague
meeting.  'Substantive progress' here means seeing comments on and/or
reviews of these drafts demonstrating that people - outside the small
group of authors - have carefully read the drafts, or better, that they
are actually using SUPA's Information and Data Models.
I've been watching the list.
Since the last IETF meeting, we received two new drafts ...
    draft-ietf-supa-generic-policy-info-model-03.txt
    draft-ietf-supa-generic-policy-data-model-03.txt
... and some draft reviews:
gunter.wang@ericsson.com on on draft-ietf-supa-policy-based-management-framework:
Good feedback but it seems like only editorial to me.
Tony tianxu@chinamobile.com on draft-cheng-supa-applicability:
Some editorial comments and three technical ones:

1.       I wonder the meaning of section 3, the part copied from framework draft, may not be needed.

2.       I suggest to replace the title of 4.2.2.and 4.2.3 with detailed information instead of writing just   Example 1 / 2.

3.       The writer wrote “We will define "edgeInterface" role and "EnterpriseDomain" later in  this note” but I failed to find the explanation for these two term.
Benoit => it's more like one technical comment, the last one.

Haining Wang: 18901341229@189.cn on draft-ietf-supa-generic-policy-data-model-03:
I understand that the GPIM YANG model provides an example of how to convert IM to DM (for general policy), and John’s SNMP blocking example (https://mailarchive.ietf.org/arch/msg/supa/DWEzaSBK6KBdsmQ0FE2-eypTzeY) exposes some details. But I am sorry that the whole picture is still not clear to me. It would be nice if the ECA Data Model part can explain in more details.

March Blanchet on draft-ietf-supa-policy-based-management-framework:
- larger comment: I’m not sure what to do with this document. It looks like a large wish list of features. I guess I’m probably too used to implementation/protocol details. I guess I will wait until to see the actual protocol/yang models.

Let's analyze the situation:
I don't consider those reviews (btw a single one the DM, none on the IM) as "substantive progress".
I don't see interest from YANG module authors, ready to reuse the SUPA YANG constructs.
Being a year late according to the charter milestones, the window of opportunity to produce reusable work has been closing rapidly.
I believe that SUPA had multiple chances to make it happen, and failed to deliver.
With this in mind, I don't see how I should conclude anything else than this WG will be closing at IETF 99.

Regards, Benoit (OPS AD)

Dear supa’rs,

 

We have cancelled our formal meeting in Prague. This decision was taken based on a proposed plan to focus effort on completing the existing WG items and prepare for closure of the supa working group sometime between IETF 99 and 100. A plan that is yet to be approved by Benoit.

 

During the last working group meeting Benoit stated:

 

“the WG will be closed at IETF 99 (Prague, 16 July) unless there is substantive progress on the Information Model and especially on the Data Model draft by one month before the Prague meeting.”

 

The authors of the Data Model and Information Model I-Ds did submit new versions but we only received one review. However, Nevil and I are working with the IM and DM authors to gather reviewers in preparation of Last Call. Essentially, we are working to prep folks who would be able to review the documents we Last Call, ideally these should be from policy/yang implementers.

 

The Framework I-D has also received a review which is positive, and I am in the process of reviewing the document myself to also help prepare the document for Last Call. Additionally, the Applicability I-D (a non-working group document) received a review which is also useful.

 

We have also seen notifications from other SDOs following supa, specifically:

- ONUG: Investigating I2NSF combined with the SUPA data model and framework

- ETSI Experiential Networked Intelligence (ENI): New initiative defining context aware networking systems, SUPA was identified as a key building block

- MEF Open Lifecycle Service Orchestrator (LSO): Using SUPA between functional components

 

However, the indication from ONUG, ETSI and MEF does not materially change the situation of SUPA but it does demonstrate wider interest in our work, and at least some responsibility for supa/IETF to complete it (if possible). If you are aware of near-term implementations now is the time to highlight them.

 

Again, we felt we did not need a WG meeting in Prague to progress the working group I-Ds, and given the IETF agenda coordination call (is today) we had to cancel the supa WG session request ASAP, and unfortunately before we had a chance to communicate the current situation to the rest of the working group. Apologies for any surprise when you saw the cancellation notification, and the lack of opportunity for wider discussion.

 

As mentioned our proposed plan has been submitted to Benoit and is yet to be approved, therefore we will wait for his thoughts and ultimate decision.

 

The SUPA Chairs would sincerely like to thank everyone for their participation and especially the authors of I-Ds for their efforts.

 

BR, Nevil and Dan.


_______________________________________________
SUPA mailing list
SUPA@ietf.org
https://www.ietf.org/mailman/listinfo/supa

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

e-mail: diego.r.lopez@telefonica.com
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------



Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição


--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

e-mail: diego.r.lopez@telefonica.com
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------



Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição

--------------E396D48C2CC808942E2AD81F-- From nobody Wed Jul 5 13:38:07 2017 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 6FCCD131575; Wed, 5 Jul 2017 13:38:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.7 X-Spam-Level: X-Spam-Status: No, score=-4.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 QoAMRDK-Uesx; Wed, 5 Jul 2017 13:38:00 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40130.outbound.protection.outlook.com [40.107.4.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D6AC12ECCE; Wed, 5 Jul 2017 13:37:58 -0700 (PDT) Received: from DB6PR0601MB2167.eurprd06.prod.outlook.com (10.168.57.26) by DB6PR0601MB2167.eurprd06.prod.outlook.com (10.168.57.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1220.11; Wed, 5 Jul 2017 20:37:56 +0000 Received: from DB6PR0601MB2167.eurprd06.prod.outlook.com ([fe80::d82f:5230:5e12:43b4]) by DB6PR0601MB2167.eurprd06.prod.outlook.com ([fe80::d82f:5230:5e12:43b4%13]) with mapi id 15.01.1220.018; Wed, 5 Jul 2017 20:37:56 +0000 From: "Diego R. Lopez" To: Benoit Claise CC: "King, Daniel" , SUPA list , "ops-ads@ietf.org" , "supa-chairs@ietf.org" Thread-Topic: [Supa] SUPA Update Thread-Index: AdLlx7FI0gJYsnA1SY+UuT+jZNMvmgADbe8AAPFY1oAAYHD9AAI+yDMAAF8fegAADplcgA== Date: Wed, 5 Jul 2017 20:37:55 +0000 Message-ID: <1D8D8D7F-96D1-49F1-B494-043CA99150BE@telefonica.com> References: <65174429B5AF4C45BD0798810EC48E0A942C73B2@EX-0-MB2.lancs.local> <666784c3-d4df-9fa1-9661-d8e182e2c7da@cisco.com> <3790BAEB-0E40-413B-BD84-60EE2E9CF483@telefonica.com> <77C6AB0B-58D5-45CD-A6D7-C3271AD76E81@telefonica.com> <38bdf7e3-8d65-beeb-327f-f962f3b8f7da@cisco.com> In-Reply-To: <38bdf7e3-8d65-beeb-327f-f962f3b8f7da@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=diego.r.lopez@telefonica.com; x-originating-ip: [195.69.7.6] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB6PR0601MB2167; 7:iMTc/cI2iiPR0Y6ZTQte16QE97aFr1/+C26W4IIXmkHzt4yySqSdnDLhvMgzB9nlFFjdfB2YzVYqKVDptVfosEogMOwzQLdTFHORMipmt+u2qLfvJLXHV4EVnrBy6plKz9NmHAenjr8FOkw6fGFASbpZN9z4Y6JMGiQOH0B1/xecVzwCOL4o+SfHYML01lA1a2JHwnqW+VajNS0La8BDLLpb0GgkWbLbszxOSZTq2YqAWU2zUcAHW4U4JDMgve+f+NrcaWe86r4ts2B6ie3e/lZRQV6kCsPrSe4EVaA0Jgni5aLR+/Gt57XKBI7pbSgiCyp2x0p6llcHM4TNbQp9YZpL2L/biL2G2SJz2BVoXqHIYTUYrtSAtWSRVZj4csNWsHtORGQd8YIHbniAlJ7n/SnQkCPUK9/tHxe/559OzpEla+mdBZ4JMQ5PVV/DaWowgjxITGarJjE8uVg45Fbmqp8M21gzmhZPsr+Tcvk64SXZtsGlcoLLRN2ETzVjNtAz9MH4EqlQKIpCE9hieJzT/C6LzhPaRaImQ0NsX0EQ6zGYu4y+THPzdeWS30qqMZ+WqzPrOCZzDw7kwVg9CD3sJl5DH29kTwGp2hw7gnW0e+vFBFh5ScTDsEUOBJnOZMePZPj0Fzz6QrhPH55s+BPfImvL4Z2XTXia8aOWeTcwAx7B2MIZ57d8MBdtMGobWOgBgd1dRjxt1hDGY1RXUBtFzhdgqXjhdszqqA5f2VHi1m/wkVLxxwHMRa+FkZkZmREoTuJWCv+vwjThE81VHLY2kd5JPDl5caLM4pwUeYblbtI= x-ms-office365-filtering-correlation-id: 11887675-d670-44e6-bedc-08d4c3e5b78c x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(48565401081)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DB6PR0601MB2167; x-ms-traffictypediagnostic: DB6PR0601MB2167: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(278178393323532)(40392960112811)(120809045254105)(236129657087228)(192374486261705)(788757137089)(48057245064654)(95692535739014)(92977632026198); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(100000703101)(100105400095)(3002001)(6055026)(6041248)(20161123555025)(20161123562025)(201703131423075)(201702281528075)(201702281529075)(201703061421075)(201703061406153)(20161123564025)(20161123558100)(20161123560025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DB6PR0601MB2167; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DB6PR0601MB2167; x-forefront-prvs: 0359162B6D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39400400002)(39410400002)(39860400002)(39850400002)(39450400003)(39840400002)(25724002)(24454002)(252514010)(40134004)(51914003)(68736007)(2900100001)(8936002)(38730400002)(5660300001)(53376002)(110136004)(6486002)(229853002)(6246003)(10710500007)(53386004)(6506006)(66066001)(93886004)(76176999)(54356999)(5250100002)(50986999)(2906002)(4326008)(3660700001)(25786009)(2420400007)(478600001)(36756003)(54906002)(6306002)(14454004)(81166006)(83716003)(86362001)(8676002)(33656002)(53546010)(575784001)(966005)(102836003)(236005)(6116002)(82746002)(7110500001)(6436002)(3846002)(3280700002)(53936002)(189998001)(99286003)(606006)(54896002)(6512007)(6916009)(15650500001)(2950100002)(7736002)(12290500005)(15398625002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6PR0601MB2167; H:DB6PR0601MB2167.eurprd06.prod.outlook.com; FPR:; SPF:None; MLV:nov; PTR:InfoNoRecords; LANG:en; received-spf: None (protection.outlook.com: telefonica.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_1D8D8D7F96D149F1B494043CA99150BEtelefonicacom_" MIME-Version: 1.0 X-OriginatorOrg: telefonica.com X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jul 2017 20:37:55.9370 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9744600e-3e04-492e-baa1-25ec245c6f10 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0601MB2167 Archived-At: Subject: Re: [Supa] SUPA Update X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.22 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: Wed, 05 Jul 2017 20:38:05 -0000 --_000_1D8D8D7F96D149F1B494043CA99150BEtelefonicacom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Benoit, The most detailed discussion of the application of the SUPA data model can = be found in the CogNet deliverable D6.2, =93Integrated Platform and Perform= ance Reports. Release 1=94, which is a public document available at http://= www.cognet.5g-ppp.eu/wp-content/uploads/2017/05/CogNet_D62.pdf The discussi= on of how SUPA is used is fundamentally made in sections 3 and 4, and appen= dix B. I was thinking about summarizing this to augment the applicability statemen= t, but I am afraid I have not found time for it yet=85 Be goode, On 5 Jul 2017, at 15:39 , Benoit Claise > wrote: Hi Diego, Thanks for the discussion. So you're applying the SUPA data model (draft-ietf-supa-generic-policy-data= -model-04)? Can you please share how you reuse them and what's your experience? Regards, Benoit Hi Benoit, In the CogNet project (http://www.cognet.5g-ppp.eu) we are applying the data models to express the policy rules (and the= events and actions) derived from the application of the so-called Smart En= gine. We are discussing about following a similar path in SHIELD (https://w= ww.shield-h2020.eu) to express security polic= ies, and advocating for it in 5G-TRANSFORMER (http://5g-transformer.eu) when expressing rules for policy-based management. = The results of these projects are being or will be transferred to our opera= tional practices, as well as what is being defined in I2NSF, where SUPA see= ms the natural data model for expressing policies to the Security Controlle= r. Is tis the kind of statement you were asking for? Be goode, On 22 Jun 2017, at 07:58 , Benoit Claise > wrote: Hi Diego, Can you expand on the re-usability aspects. What is being reused? the information model, the data model, something else= ? I hope more than the concepts. What are you, yourself, reusing? Regards, Benoit Hi Benoit, While I cannot talk for YANG module authors, and it is true that the WG has= a significant delay in its deliverables, I =91d like to stress that SUPA h= as produced reusable work that is being used elsewhere, and a closing of th= e group before it finishes its commitments would damage these other works. = I am directly involved in the I2NSF WG (that is progressing quite well in m= y opinion), and in several collaborative European projects related with 5G = and security, including a number of network operators that are experimentin= g with SUPA-based policy statements. And I am aware of the ONUG interest as= well, though not being involved I cannot detail what they are targeting no= w. So I would ask you to reconsider the decision of closing SUPA at IETF 99. Be goode, On 15 Jun 2017, at 14:46 , Benoit Claise > wrote: Dear all, After the last IETF, I put a calendar reminder on June 16th to decide on th= e next steps for SUPA. This is inline with the our previous meeting minutes, so it should not come= as a surprise. Granted, this is one day earlier than foreseen, but the IESG agenda coordin= ation call takes place today, and it was important from a scheduling point = of view to understand if SUPA would meet. The chairs informed me that no SU= PA meeting is required in Prague. That triggered this discussion, just one = day earlier. Our meeting minutes: https://www.ietf.org/mail-archive/web/supa/current/msg= 01612.html At the SUPA WG at IETF 98 (Tuesday, 28 March) we discussed the progress of the WG. Benoit (our AD) summed up the situation, pointing out that our drafts are not updated very frequently, and that the SUPA mailing list has been very quiet between meetings. At the meeting the authors of the SUPA Information model and the SUPA Data Model drafts said that those drafts should be ready for WG Last Call by 1 June, so that they could be sent to IESG for approval by about 1 July. After summing up the pros and cons for SUPA continuing, Benoit concluded by saying that the WG will be closed at IETF 99 (Prague, 16 July) unless there is substantive progress on the Information Model and especially on the Data Model drafts by one month before the Prague meeting. 'Substantive progress' here means seeing comments on and/or reviews of these drafts demonstrating that people - outside the small group of authors - have carefully read the drafts, or better, that they are actually using SUPA's Information and Data Models. I've been watching the list. Since the last IETF meeting, we received two new drafts ... draft-ietf-supa-generic-policy-info-model-03.txt draft-ietf-supa-generic-policy-data-model-03.txt ... and some draft reviews: gunter.wang@ericsson.com on on draft-ietf-= supa-policy-based-management-framework: Good feedback but it seems like only editorial to me. Tony tianxu@chinamobile.com on draft-cheng-s= upa-applicability: Some editorial comments and three technical ones: 1. I wonder the meaning of section 3, the part copied from framework = draft, may not be needed. 2. I suggest to replace the title of 4.2.2.and 4.2.3 with detailed in= formation instead of writing just Example 1 / 2. 3. The writer wrote =93We will define "edgeInterface" role and "Enter= priseDomain" later in this note=94 but I failed to find the explanation fo= r these two term. Benoit =3D> it's more like one technical comment, the last one. Haining Wang: 18901341229@189.cn on draft-ietf-s= upa-generic-policy-data-model-03: I understand that the GPIM YANG model provides an example of how to convert= IM to DM (for general policy), and John=92s SNMP blocking example (https:/= /mailarchive.ietf.org/arch/msg/supa/DWEzaSBK6KBdsmQ0FE2-eypTzeY) exposes so= me details. But I am sorry that the whole picture is still not clear to me.= It would be nice if the ECA Data Model part can explain in more details. March Blanchet on draft-ietf-supa-policy-based-management-framework: - larger comment: I=92m not sure what to do with this document. It looks li= ke a large wish list of features. I guess I=92m probably too used to implem= entation/protocol details. I guess I will wait until to see the actual prot= ocol/yang models. Let's analyze the situation: I don't consider those reviews (btw a single one the DM, none on the IM) as= "substantive progress". I don't see interest from YANG module authors, ready to reuse the SUPA YANG= constructs. Being a year late according to the charter milestones, the window of opport= unity to produce reusable work has been closing rapidly. I believe that SUPA had multiple chances to make it happen, and failed to d= eliver. With this in mind, I don't see how I should conclude anything else than thi= s WG will be closing at IETF 99. Regards, Benoit (OPS AD) Dear supa=92rs, We have cancelled our formal meeting in Prague. This decision was taken bas= ed on a proposed plan to focus effort on completing the existing WG items a= nd prepare for closure of the supa working group sometime between IETF 99 a= nd 100. A plan that is yet to be approved by Benoit. During the last working group meeting Benoit stated: =93the WG will be closed at IETF 99 (Prague, 16 July) unless there is subst= antive progress on the Information Model and especially on the Data Model d= raft by one month before the Prague meeting.=94 The authors of the Data Model and Information Model I-Ds did submit new ver= sions but we only received one review. However, Nevil and I are working wit= h the IM and DM authors to gather reviewers in preparation of Last Call. Es= sentially, we are working to prep folks who would be able to review the doc= uments we Last Call, ideally these should be from policy/yang implementers. The Framework I-D has also received a review which is positive, and I am in= the process of reviewing the document myself to also help prepare the docu= ment for Last Call. Additionally, the Applicability I-D (a non-working grou= p document) received a review which is also useful. We have also seen notifications from other SDOs following supa, specificall= y: - ONUG: Investigating I2NSF combined with the SUPA data model and framework - ETSI Experiential Networked Intelligence (ENI): New initiative defining c= ontext aware networking systems, SUPA was identified as a key building bloc= k - MEF Open Lifecycle Service Orchestrator (LSO): Using SUPA between functio= nal components However, the indication from ONUG, ETSI and MEF does not materially change = the situation of SUPA but it does demonstrate wider interest in our work, a= nd at least some responsibility for supa/IETF to complete it (if possible).= If you are aware of near-term implementations now is the time to highlight= them. Again, we felt we did not need a WG meeting in Prague to progress the worki= ng group I-Ds, and given the IETF agenda coordination call (is today) we ha= d to cancel the supa WG session request ASAP, and unfortunately before we h= ad a chance to communicate the current situation to the rest of the working= group. Apologies for any surprise when you saw the cancellation notificati= on, and the lack of opportunity for wider discussion. As mentioned our proposed plan has been submitted to Benoit and is yet to b= e approved, therefore we will wait for his thoughts and ultimate decision. The SUPA Chairs would sincerely like to thank everyone for their participat= ion and especially the authors of I-Ds for their efforts. BR, Nevil and Dan. _______________________________________________ SUPA mailing list SUPA@ietf.org https://www.ietf.org/mailman/listinfo/supa -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D http://people.tid.es/diego.lopez/ e-mail: diego.r.lopez@telefonica.com Tel: +34 913 129 041 Mobile: +34 682 051 091 ---------------------------------- ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o= copia sin autorizaci=F3n puede estar prohibida en virtud de la legislaci= =F3n vigente. Si ha recibido este mensaje por error, le rogamos que nos lo = comunique inmediatamente por esta misma v=EDa y proceda a su destrucci=F3n. The information contained in this transmission is privileged and confidenti= al information intended only for the use of the individual or entity named = above. If the reader of this message is not the intended recipient, you are= hereby notified that any dissemination, distribution or copying of this co= mmunication is strictly prohibited. If you have received this transmission = in error, do not read it. Please immediately reply to the sender that you h= ave received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, div= ulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o pode estar proibida em virtude= da legisla=E7=E3o vigente. Se recebeu esta mensagem por erro, rogamos-lhe = que nos o comunique imediatamente por esta mesma via e proceda a sua destru= i=E7=E3o -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D http://people.tid.es/diego.lopez/ e-mail: diego.r.lopez@telefonica.com Tel: +34 913 129 041 Mobile: +34 682 051 091 ---------------------------------- ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o= copia sin autorizaci=F3n puede estar prohibida en virtud de la legislaci= =F3n vigente. Si ha recibido este mensaje por error, le rogamos que nos lo = comunique inmediatamente por esta misma v=EDa y proceda a su destrucci=F3n. The information contained in this transmission is privileged and confidenti= al information intended only for the use of the individual or entity named = above. If the reader of this message is not the intended recipient, you are= hereby notified that any dissemination, distribution or copying of this co= mmunication is strictly prohibited. If you have received this transmission = in error, do not read it. Please immediately reply to the sender that you h= ave received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, div= ulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o pode estar proibida em virtude= da legisla=E7=E3o vigente. Se recebeu esta mensagem por erro, rogamos-lhe = que nos o comunique imediatamente por esta mesma via e proceda a sua destru= i=E7=E3o -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D http://people.tid.es/diego.lopez/ e-mail: diego.r.lopez@telefonica.com Tel: +34 913 129 041 Mobile: +34 682 051 091 ---------------------------------- ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o= copia sin autorizaci=F3n puede estar prohibida en virtud de la legislaci= =F3n vigente. Si ha recibido este mensaje por error, le rogamos que nos lo = comunique inmediatamente por esta misma v=EDa y proceda a su destrucci=F3n. The information contained in this transmission is privileged and confidenti= al information intended only for the use of the individual or entity named = above. If the reader of this message is not the intended recipient, you are= hereby notified that any dissemination, distribution or copying of this co= mmunication is strictly prohibited. If you have received this transmission = in error, do not read it. Please immediately reply to the sender that you h= ave received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, div= ulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o pode estar proibida em virtude= da legisla=E7=E3o vigente. Se recebeu esta mensagem por erro, rogamos-lhe = que nos o comunique imediatamente por esta mesma via e proceda a sua destru= i=E7=E3o --_000_1D8D8D7F96D149F1B494043CA99150BEtelefonicacom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <4D78B3A55BA3524AB3EDEB295730D526@eurprd06.prod.outlook.com> Content-Transfer-Encoding: quoted-printable Hi Benoit,

The most detailed discussion of the application of the SUPA= data model can be found in the CogNet deliverable D6.2, =93Integrated Plat= form and Performance Reports. Release 1=94, which is a public document avai= lable at http://www.cognet.5g-ppp.eu/wp-content/uplo= ads/2017/05/CogNet_D62.pdf The discussion of how SUPA is used is fundamentally made in sections 3 and= 4, and appendix B. 

I was thinking about summarizing this to augment the applic= ability statement, but I am afraid I have not found time for it yet=85

Be goode,

On 5 Jul 2017, at 15:39 , Benoit Claise <bclaise@cisco.com> wrote:

Hi Diego,

Thanks for the discussion.
So you're applying the SUPA data model (draft-ietf-= supa-generic-policy-data-model-04)?
Can you please share how you reuse them and what's your experience?

Regards, Benoit
Hi Benoit,

In the CogNet project (http://www.cognet.5g-ppp.eu) w= e are applying the data models to express the policy rules (and the events = and actions) derived from the application of the so-called Smart Engine. We are discussing about following a similar= path in SHIELD (https://www.shield-h2020.eu) to express security pol= icies, and advocating for it in 5G-TRANSFORMER (http://5g-transformer.eu) when expressing rules for policy-based manag= ement. The results of these projects are being or will be transferred to ou= r operational practices, as well as what is being defined in I2NSF, where SUPA seems the natural data model for exp= ressing policies to the Security Controller.

Is tis the kind of statement you were asking for?

Be goode,

On 22 Jun 2017, at 07:58 , Benoit Claise <bclaise@cisco.co= m> wrote:

Hi Diego,

Can you expand on the re-usability aspects.
What is being reused? the information model, the data model, something else= ? I hope more than the concepts.
What are you, yourself, reusing?

Regards, Benoit
Hi Benoit,

While I cannot talk for YANG module authors, and it is true= that the WG has a significant delay in its deliverables, I =91d like to st= ress that SUPA has produced reusable work that is being used elsewhere, and= a closing of the group before it finishes its commitments would damage these other works. I am directly involved in = the I2NSF WG (that is progressing quite well in my opinion), and in several= collaborative European projects related with 5G and security, including a = number of network operators that are experimenting with SUPA-based policy statements. And I am aware of the= ONUG interest as well, though not being involved I cannot detail what they= are targeting now.

So I would ask you to reconsider the decision of closing SU= PA at IETF 99.

Be goode,

On 15 Jun 2017, at 14:46 , Benoit Claise <bclaise@cisco.co= m> wrote:

Dear all,

After the last IETF, I put a calendar reminder on June 16th to decide on th= e next steps for SUPA.
This is inline with the our previous meeting minutes, so it should not come= as a surprise.
Granted, this is one day earlier than foreseen, but the IESG agenda coordin= ation call takes place today, and it was important from a scheduling point = of view to understand if SUPA would meet. The chairs informed me that no SU= PA meeting is required in Prague. That triggered this discussion, just one day earlier.

Our meeting minutes: https://www.ietf.org/mail-archive/web/supa/current/msg01612.html
At the SUPA WG at IETF 98 (Tuesday, =
28 March) we discussed the
progress of the WG.  Benoit (our AD) summed up the situation, pointing
out that our drafts are not updated very frequently, and that the SUPA
mailing list has been very quiet between meetings.

At the meeting the authors of the SUPA Information model and the SUPA
Data Model drafts said that those drafts should be ready for WG Last
Call by 1 June, so that they could be sent to IESG for approval by
about 1 July.

After summing up the pros and cons for SUPA continuing, Benoit
concluded by saying that the WG will be closed at IETF 99 (Prague, 16
July) unless there is substantive progress on the Information Model
and especially on the Data Model drafts by one month before the Prague
meeting.  'Substantive progress' here means seeing comments on and/or
reviews of these drafts demonstrating that people - outside the small
group of authors - have carefully read the drafts, or better, that they
are actually using SUPA's Information and Data Models.
I've been watching the list.
Since the last IETF meeting, we received two new drafts ...
    draft-ietf-supa-generic-policy-in= fo-model-03.txt
    draft-ietf-supa-generic-policy-data-model-03.txt
... and some draft reviews:
gunter.wang@ericsson.co= m on on draft-ietf-supa-policy-based-management-framework:
Good feedback but it seems like only editorial to me= .
Tony tianxu@chinamobile.com on draft-cheng-supa-applicability:
Some editorial comments and three technical ones:

1.       I wonder the meaning of sec= tion 3, the part copied from framework draft, may not be needed.

2.       I suggest to replace the ti= tle of 4.2.2.and 4.2.3 with detailed information instead of writing just   Example 1 / 2.

3.       The writer wrote =93We will d= efine "edgeInterface" role and "EnterpriseDomain" later= in  this note=94 but I failed to find the explanation for these two term.
Benoit =3D> it's more like one technical comment,= the last one.

Haining Wang: 18901341229@189.cn on draft-ietf-supa-generic-policy-data-model-03:
I understand that th= e GPIM YANG model provides an example of how to convert IM to DM (for gener= al policy), and John=92s SNMP blocking example (https://mailarchive.ietf.org/arch/msg/supa/DWEzaSBK6KBdsmQ= 0FE2-eypTzeY) exposes some details. But I am sorry that the whole picture is still not c= lear to me. It would be nice if the ECA Data Model part can explain in more= details.

March Blanchet on draft-ietf-supa-policy-based-management-framework:
- larger comment: I=92m not sure what to do with thi= s document. It looks like a large wish list of features. I guess I=92m prob= ably too used to implementation/protocol details. I guess I will wait until= to see the actual protocol/yang models.

Let's analyze the situation:
I don't consider those reviews (btw a single one the DM, none on the IM) as= "substantive progress".
I don't see interest from YANG module authors, ready to reuse the SUPA YANG= constructs.
Being a year late according to the charter milestones, the window of opport= unity to produce reusable work has been closing rapidly.
I believe that SUPA had multiple chances to make it happen, and failed to d= eliver.
With this in mind, I don't see how I should conclude anything else than thi= s WG will be closing at IETF 99.

Regards, Benoit (OPS AD)

Dear supa=92rs,

 

We have cancelled our formal meeting in Prague. This= decision was taken based on a proposed plan to focus effort on completing = the existing WG items and prepare for closure of the supa working group som= etime between IETF 99 and 100. A plan that is yet to be approved by Benoit.

 

During the last working group meeting Benoit stated:=

 

=93the WG will be closed at IETF 99 (Prague, 16 July= ) unless there is substantive progress on the Information Model and especia= lly on the Data Model draft by one month before the Prague meeting.=94

 

The authors of the Data Model and Information Model = I-Ds did submit new versions but we only received one review. However, Nevi= l and I are working with the IM and DM authors to gather reviewers in prepa= ration of Last Call. Essentially, we are working to prep folks who would be able to review the documents we = Last Call, ideally these should be from policy/yang implementers.

 

The Framework I-D has also received a review which i= s positive, and I am in the process of reviewing the document myself to als= o help prepare the document for Last Call. Additionally, the Applicability = I-D (a non-working group document) received a review which is also useful.

 

We have also seen notifications from other SDOs foll= owing supa, specifically:

- ONUG: Investigating I2NSF combined with the SUPA d= ata model and framework

- ETSI Experiential Networked Intelligence (ENI): Ne= w initiative defining context aware networking systems, SUPA was identified= as a key building block

- MEF Open Lifecycle Service Orchestrator (LSO): Usi= ng SUPA between functional components

 

However, the indication from ONUG, ETSI and MEF does= not materially change the situation of SUPA but it does demonstrate wider = interest in our work, and at least some responsibility for supa/IETF to com= plete it (if possible). If you are aware of near-term implementations now is the time to highlight them.

 

Again, we felt we did not need a WG meeting in Pragu= e to progress the working group I-Ds, and given the IETF agenda coordinatio= n call (is today) we had to cancel the supa WG session request ASAP, and un= fortunately before we had a chance to communicate the current situation to the rest of the working group. Apo= logies for any surprise when you saw the cancellation notification, and the= lack of opportunity for wider discussion.

 

As mentioned our proposed plan has been submitted to= Benoit and is yet to be approved, therefore we will wait for his thoughts = and ultimate decision.

 

The SUPA Chairs would sincerely like to thank everyo= ne for their participation and especially the authors of I-Ds for their eff= orts.

 

BR, Nevil and Dan.


_______________________________________________
SUPA mailing list
SUPA@i= etf.org
https://www.ietf.org/mailman/listinfo/= supa

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

e-mail: diego.r.lopez@telefonica.com
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------



Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o copia sin autorizaci=F3n puede e= star prohibida en virtud de la legislaci=F3n vigente. Si ha recibido este m= ensaje por error, le rogamos que nos lo comunique inmediatamente por esta m= isma v=EDa y proceda a su destrucci=F3n.

The information contained in this transmission is privileged and confidenti= al information intended only for the use of the individual or entity named = above. If the reader of this message is not the intended recipient, you are= hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If y= ou have received this transmission in error, do not read it. Please immedia= tely reply to the sender that you have received this communication in error= and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, divulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o p= ode estar proibida em virtude da legisla=E7=E3o vigente. Se recebeu esta me= nsagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mes= ma via e proceda a sua destrui=E7=E3o


--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

e-mail: diego.r.lopez@telefonica.com
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------



Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o copia sin autorizaci=F3n puede e= star prohibida en virtud de la legislaci=F3n vigente. Si ha recibido este m= ensaje por error, le rogamos que nos lo comunique inmediatamente por esta m= isma v=EDa y proceda a su destrucci=F3n.

The information contained in this transmission is privileged and confidenti= al information intended only for the use of the individual or entity named = above. If the reader of this message is not the intended recipient, you are= hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If y= ou have received this transmission in error, do not read it. Please immedia= tely reply to the sender that you have received this communication in error= and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, divulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o p= ode estar proibida em virtude da legisla=E7=E3o vigente. Se recebeu esta me= nsagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mes= ma via e proceda a sua destrui=E7=E3o


--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.= es/diego.lopez/

e-mail: diego.r.lopez@telefonica.com
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------



Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o copia sin autorizaci=F3n puede e= star prohibida en virtud de la legislaci=F3n vigente. Si ha recibido este m= ensaje por error, le rogamos que nos lo comunique inmediatamente por esta m= isma v=EDa y proceda a su destrucci=F3n.

The information contained in this transmission is privileged and confidenti= al information intended only for the use of the individual or entity named = above. If the reader of this message is not the intended recipient, you are= hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If y= ou have received this transmission in error, do not read it. Please immedia= tely reply to the sender that you have received this communication in error= and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, divulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o p= ode estar proibida em virtude da legisla=E7=E3o vigente. Se recebeu esta me= nsagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mes= ma via e proceda a sua destrui=E7=E3o
 --_000_1D8D8D7F96D149F1B494043CA99150BEtelefonicacom_-- From nobody Wed Jul 5 14:07:23 2017 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 B0037124217; Wed, 5 Jul 2017 14:07:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 j9C6jR0kS8tu; Wed, 5 Jul 2017 14:07:15 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A32F8131A30; Wed, 5 Jul 2017 14:07:13 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DJU92594; Wed, 05 Jul 2017 21:07:11 +0000 (GMT) Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 5 Jul 2017 22:07:10 +0100 Received: from SJCEML702-CHM.china.huawei.com ([169.254.4.142]) by SJCEML701-CHM.china.huawei.com ([169.254.3.186]) with mapi id 14.03.0301.000; Wed, 5 Jul 2017 14:07:03 -0700 From: Linda Dunbar To: "Diego R. Lopez" , Benoit Claise CC: "King, Daniel" , "ops-ads@ietf.org" , "supa-chairs@ietf.org" , SUPA list Thread-Topic: [Supa] SUPA Update Thread-Index: AdLlx7FI0gJYsnA1SY+UuT+jZNMvmgASGQcAAPFY1YAAYHD9AAI+yIAAAF8fLgAADplcgAANs8sg Date: Wed, 5 Jul 2017 21:07:02 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F6593DD0F8@SJCEML702-CHM.china.huawei.com> References: <65174429B5AF4C45BD0798810EC48E0A942C73B2@EX-0-MB2.lancs.local> <666784c3-d4df-9fa1-9661-d8e182e2c7da@cisco.com> <3790BAEB-0E40-413B-BD84-60EE2E9CF483@telefonica.com> <77C6AB0B-58D5-45CD-A6D7-C3271AD76E81@telefonica.com> <38bdf7e3-8d65-beeb-327f-f962f3b8f7da@cisco.com> <1D8D8D7F-96D1-49F1-B494-043CA99150BE@telefonica.com> In-Reply-To: <1D8D8D7F-96D1-49F1-B494-043CA99150BE@telefonica.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.196] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F6593DD0F8SJCEML702CHMchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.595D5500.0075, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.142, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: abe8c1d9bc3291f6de9952ea901e7a36 Archived-At: Subject: Re: [Supa] SUPA Update X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.22 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: Wed, 05 Jul 2017 21:07:22 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F6593DD0F8SJCEML702CHMchi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Diego, Thanks for the link. Do you mean Section 3.2.2.3 using SUPA data model to configure a policy? "supa-policy": { "supa-policy-validity-period": { "start": "2015-11-09T00:42:57.527404Z" } "supa-policy-target": { "topicName": "demoX", "domainName": "systemX", "subNetwork": "192.168.1.1", "instanceName": "rack1" } "supa-policy-statement": { "event": { "event-name": "noisy-neighbor", "event-value-type": "float", "event-value": "5.1" "instanceName": "compute0.vm3", } "condition": { "condition-name": "noisy-neighbor", "condition-operator": ">", "condition-threshold": "5.0", "supa-script-content": { "script-Java": "if (value > 5.0) return TRUE" } } "action": { "action-name": "noisy-neighbor", "action-type": "migrate-vm" "action-param1": { "param-type": "entity" "param-value": "compute2" "instanceName": "compute2" } } } } Thanks, Linda From: SUPA [mailto:supa-bounces@ietf.org] On Behalf Of Diego R. Lopez Sent: Wednesday, July 05, 2017 3:38 PM To: Benoit Claise Cc: King, Daniel ; ops-ads@ietf.org; supa-chairs@ie= tf.org; SUPA list Subject: Re: [Supa] SUPA Update Hi Benoit, The most detailed discussion of the application of the SUPA data model can = be found in the CogNet deliverable D6.2, "Integrated Platform and Performan= ce Reports. Release 1", which is a public document available at http://www.= cognet.5g-ppp.eu/wp-content/uploads/2017/05/CogNet_D62.pdf The discussion o= f how SUPA is used is fundamentally made in sections 3 and 4, and appendix = B. I was thinking about summarizing this to augment the applicability statemen= t, but I am afraid I have not found time for it yet... Be goode, On 5 Jul 2017, at 15:39 , Benoit Claise > wrote: Hi Diego, Thanks for the discussion. So you're applying the SUPA data model (draft-ietf-supa-generic-policy-data= -model-04)? Can you please share how you reuse them and what's your experience? Regards, Benoit Hi Benoit, In the CogNet project (http://www.cognet.5g-ppp.eu) we are applying the data models to express the policy rules (and the= events and actions) derived from the application of the so-called Smart En= gine. We are discussing about following a similar path in SHIELD (https://w= ww.shield-h2020.eu) to express security polic= ies, and advocating for it in 5G-TRANSFORMER (http://5g-transformer.eu) when expressing rules for policy-based management. = The results of these projects are being or will be transferred to our opera= tional practices, as well as what is being defined in I2NSF, where SUPA see= ms the natural data model for expressing policies to the Security Controlle= r. Is tis the kind of statement you were asking for? Be goode, On 22 Jun 2017, at 07:58 , Benoit Claise > wrote: Hi Diego, Can you expand on the re-usability aspects. What is being reused? the information model, the data model, something else= ? I hope more than the concepts. What are you, yourself, reusing? Regards, Benoit Hi Benoit, While I cannot talk for YANG module authors, and it is true that the WG has= a significant delay in its deliverables, I 'd like to stress that SUPA has= produced reusable work that is being used elsewhere, and a closing of the = group before it finishes its commitments would damage these other works. I = am directly involved in the I2NSF WG (that is progressing quite well in my = opinion), and in several collaborative European projects related with 5G an= d security, including a number of network operators that are experimenting = with SUPA-based policy statements. And I am aware of the ONUG interest as w= ell, though not being involved I cannot detail what they are targeting now. So I would ask you to reconsider the decision of closing SUPA at IETF 99. Be goode, On 15 Jun 2017, at 14:46 , Benoit Claise > wrote: Dear all, After the last IETF, I put a calendar reminder on June 16th to decide on th= e next steps for SUPA. This is inline with the our previous meeting minutes, so it should not come= as a surprise. Granted, this is one day earlier than foreseen, but the IESG agenda coordin= ation call takes place today, and it was important from a scheduling point = of view to understand if SUPA would meet. The chairs informed me that no SU= PA meeting is required in Prague. That triggered this discussion, just one = day earlier. Our meeting minutes: https://www.ietf.org/mail-archive/web/supa/current/msg= 01612.html At the SUPA WG at IETF 98 (Tuesday, 28 March) we discussed the progress of the WG. Benoit (our AD) summed up the situation, pointing out that our drafts are not updated very frequently, and that the SUPA mailing list has been very quiet between meetings. At the meeting the authors of the SUPA Information model and the SUPA Data Model drafts said that those drafts should be ready for WG Last Call by 1 June, so that they could be sent to IESG for approval by about 1 July. After summing up the pros and cons for SUPA continuing, Benoit concluded by saying that the WG will be closed at IETF 99 (Prague, 16 July) unless there is substantive progress on the Information Model and especially on the Data Model drafts by one month before the Prague meeting. 'Substantive progress' here means seeing comments on and/or reviews of these drafts demonstrating that people - outside the small group of authors - have carefully read the drafts, or better, that they are actually using SUPA's Information and Data Models. I've been watching the list. Since the last IETF meeting, we received two new drafts ... draft-ietf-supa-generic-policy-info-model-03.txt draft-ietf-supa-generic-policy-data-model-03.txt ... and some draft reviews: gunter.wang@ericsson.com on on draft-ietf-= supa-policy-based-management-framework: Good feedback but it seems like only editorial to me. Tony tianxu@chinamobile.com on draft-cheng-s= upa-applicability: Some editorial comments and three technical ones: 1. I wonder the meaning of section 3, the part copied from framework = draft, may not be needed. 2. I suggest to replace the title of 4.2.2.and 4.2.3 with detailed in= formation instead of writing just Example 1 / 2. 3. The writer wrote "We will define "edgeInterface" role and "Enterpr= iseDomain" later in this note" but I failed to find the explanation for th= ese two term. Benoit =3D> it's more like one technical comment, the last one. Haining Wang: 18901341229@189.cn on draft-ietf-s= upa-generic-policy-data-model-03: I understand that the GPIM YANG model provides an example of how to convert= IM to DM (for general policy), and John's SNMP blocking example (https://m= ailarchive.ietf.org/arch/msg/supa/DWEzaSBK6KBdsmQ0FE2-eypTzeY) exposes some= details. But I am sorry that the whole picture is still not clear to me. I= t would be nice if the ECA Data Model part can explain in more details. March Blanchet on draft-ietf-supa-policy-based-management-framework: - larger comment: I'm not sure what to do with this document. It looks like= a large wish list of features. I guess I'm probably too used to implementa= tion/protocol details. I guess I will wait until to see the actual protocol= /yang models. Let's analyze the situation: I don't consider those reviews (btw a single one the DM, none on the IM) as= "substantive progress". I don't see interest from YANG module authors, ready to reuse the SUPA YANG= constructs. Being a year late according to the charter milestones, the window of opport= unity to produce reusable work has been closing rapidly. I believe that SUPA had multiple chances to make it happen, and failed to d= eliver. With this in mind, I don't see how I should conclude anything else than thi= s WG will be closing at IETF 99. Regards, Benoit (OPS AD) Dear supa'rs, We have cancelled our formal meeting in Prague. This decision was taken bas= ed on a proposed plan to focus effort on completing the existing WG items a= nd prepare for closure of the supa working group sometime between IETF 99 a= nd 100. A plan that is yet to be approved by Benoit. During the last working group meeting Benoit stated: "the WG will be closed at IETF 99 (Prague, 16 July) unless there is substan= tive progress on the Information Model and especially on the Data Model dra= ft by one month before the Prague meeting." The authors of the Data Model and Information Model I-Ds did submit new ver= sions but we only received one review. However, Nevil and I are working wit= h the IM and DM authors to gather reviewers in preparation of Last Call. Es= sentially, we are working to prep folks who would be able to review the doc= uments we Last Call, ideally these should be from policy/yang implementers. The Framework I-D has also received a review which is positive, and I am in= the process of reviewing the document myself to also help prepare the docu= ment for Last Call. Additionally, the Applicability I-D (a non-working grou= p document) received a review which is also useful. We have also seen notifications from other SDOs following supa, specificall= y: - ONUG: Investigating I2NSF combined with the SUPA data model and framework - ETSI Experiential Networked Intelligence (ENI): New initiative defining c= ontext aware networking systems, SUPA was identified as a key building bloc= k - MEF Open Lifecycle Service Orchestrator (LSO): Using SUPA between functio= nal components However, the indication from ONUG, ETSI and MEF does not materially change = the situation of SUPA but it does demonstrate wider interest in our work, a= nd at least some responsibility for supa/IETF to complete it (if possible).= If you are aware of near-term implementations now is the time to highlight= them. Again, we felt we did not need a WG meeting in Prague to progress the worki= ng group I-Ds, and given the IETF agenda coordination call (is today) we ha= d to cancel the supa WG session request ASAP, and unfortunately before we h= ad a chance to communicate the current situation to the rest of the working= group. Apologies for any surprise when you saw the cancellation notificati= on, and the lack of opportunity for wider discussion. As mentioned our proposed plan has been submitted to Benoit and is yet to b= e approved, therefore we will wait for his thoughts and ultimate decision. The SUPA Chairs would sincerely like to thank everyone for their participat= ion and especially the authors of I-Ds for their efforts. BR, Nevil and Dan. _______________________________________________ SUPA mailing list SUPA@ietf.org https://www.ietf.org/mailman/listinfo/supa -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D http://people.tid.es/diego.lopez/ e-mail: diego.r.lopez@telefonica.com Tel: +34 913 129 041 Mobile: +34 682 051 091 ---------------------------------- ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o= copia sin autorizaci=F3n puede estar prohibida en virtud de la legislaci= =F3n vigente. Si ha recibido este mensaje por error, le rogamos que nos lo = comunique inmediatamente por esta misma v=EDa y proceda a su destrucci=F3n. The information contained in this transmission is privileged and confidenti= al information intended only for the use of the individual or entity named = above. If the reader of this message is not the intended recipient, you are= hereby notified that any dissemination, distribution or copying of this co= mmunication is strictly prohibited. If you have received this transmission = in error, do not read it. Please immediately reply to the sender that you h= ave received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, div= ulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o pode estar proibida em virtude= da legisla=E7=E3o vigente. Se recebeu esta mensagem por erro, rogamos-lhe = que nos o comunique imediatamente por esta mesma via e proceda a sua destru= i=E7=E3o -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D http://people.tid.es/diego.lopez/ e-mail: diego.r.lopez@telefonica.com Tel: +34 913 129 041 Mobile: +34 682 051 091 ---------------------------------- ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o= copia sin autorizaci=F3n puede estar prohibida en virtud de la legislaci= =F3n vigente. Si ha recibido este mensaje por error, le rogamos que nos lo = comunique inmediatamente por esta misma v=EDa y proceda a su destrucci=F3n. The information contained in this transmission is privileged and confidenti= al information intended only for the use of the individual or entity named = above. If the reader of this message is not the intended recipient, you are= hereby notified that any dissemination, distribution or copying of this co= mmunication is strictly prohibited. If you have received this transmission = in error, do not read it. Please immediately reply to the sender that you h= ave received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, div= ulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o pode estar proibida em virtude= da legisla=E7=E3o vigente. Se recebeu esta mensagem por erro, rogamos-lhe = que nos o comunique imediatamente por esta mesma via e proceda a sua destru= i=E7=E3o -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D http://people.tid.es/diego.lopez/ e-mail: diego.r.lopez@telefonica.com Tel: +34 913 129 041 Mobile: +34 682 051 091 ---------------------------------- ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o= copia sin autorizaci=F3n puede estar prohibida en virtud de la legislaci= =F3n vigente. Si ha recibido este mensaje por error, le rogamos que nos lo = comunique inmediatamente por esta misma v=EDa y proceda a su destrucci=F3n. The information contained in this transmission is privileged and confidenti= al information intended only for the use of the individual or entity named = above. If the reader of this message is not the intended recipient, you are= hereby notified that any dissemination, distribution or copying of this co= mmunication is strictly prohibited. If you have received this transmission = in error, do not read it. Please immediately reply to the sender that you h= ave received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, div= ulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o pode estar proibida em virtude= da legisla=E7=E3o vigente. Se recebeu esta mensagem por erro, rogamos-lhe = que nos o comunique imediatamente por esta mesma via e proceda a sua destru= i=E7=E3o --_000_4A95BA014132FF49AE685FAB4B9F17F6593DD0F8SJCEML702CHMchi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Diego,

 

Thanks for the link.

 

Do you mean Section 3.2.2.3 using SUP= A data model to configure a policy?

 

“supa-policy": {

“supa-policy-validity-period= 221;: {

“start”: "2015-11-09= T00:42:57.527404Z"

}

“supa-policy-target”: {

“topicName": “demoX&= #8221;,

“domainName": “syste= mX”,

“subNetwork”: “192.= 168.1.1”,

“instanceName”: “ra= ck1”

}

“supa-policy-statement”: = {

“event": {

“event-name”: “nois= y-neighbor”,

“event-value-type”: ̶= 0;float”,

“event-value”: “5.1= ”

“instanceName”: “co= mpute0.vm3”,

}

“condition": {<= /span>

“condition-name”: “= noisy-neighbor”,

“condition-operator”: = 220;>”,

“condition-threshold”: &#= 8220;5.0”,

“supa-script-content”: {<= o:p>

“script-Java”: “if = (value > 5.0) return TRUE”

}

}

“action": {

“action-name”: “noi= sy-neighbor”,

“action-type”: “mig= rate-vm”

“action-param1”: {

“param-type”: “enti= ty”

“param-value”: “com= pute2”

“instanceName”: “co= mpute2”

}

}

}

}

&nbs= p;

 

Thanks, Linda

 

 

From: SUPA [mailto:supa-bounces@ietf= .org] On Behalf Of Diego R. Lopez
Sent: Wednesday, July 05, 2017 3:38 PM
To: Benoit Claise <bclaise@cisco.com>
Cc: King, Daniel <d.king@lancaster.ac.uk>; ops-ads@ietf.org; s= upa-chairs@ietf.org; SUPA list <supa@ietf.org>
Subject: Re: [Supa] SUPA Update

 

Hi Benoit,

 

The most detailed discussion of the application of t= he SUPA data model can be found in the CogNet deliverable D6.2, “Inte= grated Platform and Performance Reports. Release 1”, which is a publi= c document available at http://www.cognet.5g-ppp.eu/wp-content/= uploads/2017/05/CogNet_D62.pdf The discussion of how SUPA is used is fundamentally made in sections 3 and= 4, and appendix B. 

 

I was thinking about summarizing this to augment the= applicability statement, but I am afraid I have not found time for it yet&= #8230;

 

Be goode,

 

On 5 Jul 2017, at 15:39 , Benoit Claise <bclaise@cisco.com> wrote:

 

Hi Diego,

Thanks for the discussion.
So you're applying the SUPA data model (draft-ietf-supa-generi= c-policy-data-model-04)?
Can you please share how you reuse them and what's your experience?

Regards, Benoit

Hi Benoit,

 

In the CogNet project (http://www.cognet.5g-ppp.eu) we are applying the data model= s to express the policy rules (and the events and actions) derived from the= application of the so-called Smart Engine. We are discussing about following a similar path in SHIELD (https://www.shield-h2020.eu) to expr= ess security policies, and advocating for it in 5G-TRANSFORMER (http://5g-transformer.eu) when expressing rules for policy-based management. The results of these pr= ojects are being or will be transferred to our operational practices, as we= ll as what is being defined in I2NSF, where SUPA seems the natural data mod= el for expressing policies to the Security Controller.

 

Is tis the kind of statement you were asking for?

 

Be goode,

 

On 22 Jun 2017, at 07:58 , Benoit Claise <bclaise@cisco.com> wrote:

 

Hi Diego,

Can you expand on the re-usability aspects.
What is being reused? the information model, the data model, something else= ? I hope more than the concepts.
What are you, yourself, reusing?

Regards, Benoit

Hi Benoit,

 

While I cannot talk for YANG module authors, and it = is true that the WG has a significant delay in its deliverables, I ‘d= like to stress that SUPA has produced reusable work that is being used els= ewhere, and a closing of the group before it finishes its commitments would damage these other works. I am directly = involved in the I2NSF WG (that is progressing quite well in my opinion), an= d in several collaborative European projects related with 5G and security, = including a number of network operators that are experimenting with SUPA-based policy statements. And I am aware o= f the ONUG interest as well, though not being involved I cannot detail what= they are targeting now.

 

So I would ask you to reconsider the decision of clo= sing SUPA at IETF 99.

 

Be goode,

 

On 15 Jun 2017, at 14:46 , Benoit Claise <bclaise@cisco.com> wrote:

 

Dear all,

After the last IETF, I put a calendar reminder on June 16th to decide on th= e next steps for SUPA.
This is inline with the our previous meeting minutes, so it should not come= as a surprise.
Granted, this is one day earlier than foreseen, but the IESG agenda coordin= ation call takes place today, and it was important from a scheduling point = of view to understand if SUPA would meet. The chairs informed me that no SU= PA meeting is required in Prague. That triggered this discussion, just one day earlier.

Our meeting minutes: https://www.ietf.org/mail-archive/web/supa/current/msg01612.html

At the SUPA WG at IETF 98 (Tuesday, 28 March) we discussed the
progress of the WG.  Benoit (our AD) summed up the situation, poi=
nting
out that our drafts are not updated very frequently, and that the SUPA=

mailing list has been very quiet between meetings.
 
At the meeting the authors of the SUPA Information model and the SUPA<=
o:p>
Data Model drafts said that those drafts should be ready for WG Last
Call by 1 June, so that they could be sent to IESG for approval by
about 1 July.
 
After summing up the pros and cons for SUPA continuing, Benoit
concluded by saying that the WG will be closed at IETF 99 (Prague, 16<=
o:p>
July) unless there is substantive progress on the Information Model
and especially on the Data Model drafts by one month before the Prague=

meeting.  'Substantive progress' here means seeing comments on an=
d/or
reviews of these drafts demonstrating that people - outside the small<=
o:p>
group of authors - have carefully read the drafts, or better, that the=
y
are actually using SUPA's Information and Data Models.

I've been watching the list.

Since the last IETF meeting, we received two new dra= fts ...

    draft-ietf-supa-generic-policy-in= fo-model-03.txt
    draft-ietf-supa-generic-policy-data-model-03.txt

... and some draft reviews:

gunter.w= ang@ericsson.com on on draft-ietf-supa-policy-based-management-framewor= k:

Good feedback but it seems like only editorial to me= .

Tony tianx= u@chinamobile.com on draft-cheng-supa-applicability:

Some editorial comments and three technical ones:

1.       I wonder the meaning of section 3, the pa= rt copied from framework draft, may not be needed.

2.       I suggest to replace the title of 4.2.2.a= nd 4.2.3 with detailed information instead of writing just   Example 1 / 2.

3.       The writer wrote “We = will define "edgeInterface" role and "EnterpriseDomain"= later in  this note” but I failed to find the explanation for t= hese two term.

Benoit =3D> it's more like one technical comment,= the last one.


Haining Wang: 18901341229@189.cn = on draft-ietf-supa-generic-policy-data-model-03:

I understand that the= GPIM YANG model provides an example of how to convert IM to DM (for genera= l policy), and John’s SNMP blocking example (https://mailarch= ive.ietf.org/arch/msg/supa/DWEzaSBK6KBdsmQ0FE2-eypTzeY) exposes some details. But I am sorry that the whole picture is still not c= lear to me. It would be nice if the ECA Data Model part can explain in more= details.

March Blanchet on draft-ietf-supa-policy-based-manag= ement-framework:

- larger comment: I’m not sure what to do with= this document. It looks like a large wish list of features. I guess I̵= 7;m probably too used to implementation/protocol details. I guess I will wa= it until to see the actual protocol/yang models.


Let's analyze the situation:
I don't consider those reviews (btw a single one the DM, none on the IM) as= "substantive progress".
I don't see interest from YANG module authors, ready to reuse the SUPA YANG= constructs.
Being a year late according to the charter milestones, the window of opport= unity to produce reusable work has been closing rapidly.
I believe that SUPA had multiple chances to make it happen, and failed to d= eliver.
With this in mind, I don't see how I should conclude anything else than thi= s WG will be closing at IETF 99.

Regards, Benoit (OPS AD)

Dear supa’rs,

 

We have cancelled our formal meeting in Prague. This decision was = taken based on a proposed plan to focus effort on completing the existing W= G items and prepare for closure of the supa working group sometime between IETF 99 and 100. A plan that is yet to= be approved by Benoit.

 

During the last working group meeting Benoit stated:

 

“the WG will be closed at IETF 99 (Prague, 16 July) unless t= here is substantive progress on the Information Model and especially on the= Data Model draft by one month before the Prague meeting.”

 

The authors of the Data Model and Information Model I-Ds did submi= t new versions but we only received one review. However, Nevil and I are wo= rking with the IM and DM authors to gather reviewers in preparation of Last Call. Essentially, we are working = to prep folks who would be able to review the documents we Last Call, ideal= ly these should be from policy/yang implementers.

 

The Framework I-D has also received a review which is positive, an= d I am in the process of reviewing the document myself to also help prepare= the document for Last Call. Additionally, the Applicability I-D (a non-working group document) received a review whi= ch is also useful.

 

We have also seen notifications from other SDOs following supa, sp= ecifically:

- ONUG: Investigating I2NSF combined with the SUPA data model and = framework

- ETSI Experiential Networked Intelligence (ENI): New initiative d= efining context aware networking systems, SUPA was identified as a key buil= ding block

- MEF Open Lifecycle Service Orchestrator (LSO): Using SUPA betwee= n functional components

 

However, the indication from ONUG, ETSI and MEF does not materiall= y change the situation of SUPA but it does demonstrate wider interest in ou= r work, and at least some responsibility for supa/IETF to complete it (if possible). If you are aware of near-term = implementations now is the time to highlight them.

 

Again, we felt we did not need a WG meeting in Prague to progress = the working group I-Ds, and given the IETF agenda coordination call (is tod= ay) we had to cancel the supa WG session request ASAP, and unfortunately before we had a chance to communicate the = current situation to the rest of the working group. Apologies for any surpr= ise when you saw the cancellation notification, and the lack of opportunity= for wider discussion.

 

As mentioned our proposed plan has been submitted to Benoit and is= yet to be approved, therefore we will wait for his thoughts and ultimate d= ecision.

 

The SUPA Chairs would sincerely like to thank everyone for their p= articipation and especially the authors of I-Ds for their efforts.

 

BR, Nevil and Dan.

 

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

 

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lo= pez/

e-mail: diego.r.lopez@telef= onica.com
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------

 

 


Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o copia sin autorizaci=F3n puede e= star prohibida en virtud de la legislaci=F3n vigente. Si ha recibido este m= ensaje por error, le rogamos que nos lo comunique inmediatamente por esta m= isma v=EDa y proceda a su destrucci=F3n.

The information contained in this transmission is privileged and confidenti= al information intended only for the use of the individual or entity named = above. If the reader of this message is not the intended recipient, you are= hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If y= ou have received this transmission in error, do not read it. Please immedia= tely reply to the sender that you have received this communication in error= and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, divulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o p= ode estar proibida em virtude da legisla=E7=E3o vigente. Se recebeu esta me= nsagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mes= ma via e proceda a sua destrui=E7=E3o

 

 

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lo= pez/

e-mail: diego.r.lopez@telef= onica.com
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------

 

 


Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o copia sin autorizaci=F3n puede e= star prohibida en virtud de la legislaci=F3n vigente. Si ha recibido este m= ensaje por error, le rogamos que nos lo comunique inmediatamente por esta m= isma v=EDa y proceda a su destrucci=F3n.

The information contained in this transmission is privileged and confidenti= al information intended only for the use of the individual or entity named = above. If the reader of this message is not the intended recipient, you are= hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If y= ou have received this transmission in error, do not read it. Please immedia= tely reply to the sender that you have received this communication in error= and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, divulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o p= ode estar proibida em virtude da legisla=E7=E3o vigente. Se recebeu esta me= nsagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mes= ma via e proceda a sua destrui=E7=E3o

 

 

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lo= pez/

e-mail: diego.r.lopez@telef= onica.com
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------

 

 


Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o copia sin autorizaci=F3n puede e= star prohibida en virtud de la legislaci=F3n vigente. Si ha recibido este m= ensaje por error, le rogamos que nos lo comunique inmediatamente por esta m= isma v=EDa y proceda a su destrucci=F3n.

The information contained in this transmission is privileged and confidenti= al information intended only for the use of the individual or entity named = above. If the reader of this message is not the intended recipient, you are= hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If y= ou have received this transmission in error, do not read it. Please immedia= tely reply to the sender that you have received this communication in error= and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, divulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o p= ode estar proibida em virtude da legisla=E7=E3o vigente. Se recebeu esta me= nsagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mes= ma via e proceda a sua destrui=E7=E3o

--_000_4A95BA014132FF49AE685FAB4B9F17F6593DD0F8SJCEML702CHMchi_-- From nobody Wed Jul 5 19:40:18 2017 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 A8AD812EC4D; Wed, 5 Jul 2017 19:40:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no 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 klrElVsXqnB4; Wed, 5 Jul 2017 19:40:12 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B5C3129B67; Wed, 5 Jul 2017 19:40:10 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DQM67755; Thu, 06 Jul 2017 02:40:08 +0000 (GMT) Received: from DGGEMM401-HUB.china.huawei.com (10.3.20.209) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 6 Jul 2017 03:40:07 +0100 Received: from DGGEMM505-MBX.china.huawei.com ([169.254.1.152]) by DGGEMM401-HUB.china.huawei.com ([10.3.20.209]) with mapi id 14.03.0301.000; Thu, 6 Jul 2017 10:40:00 +0800 From: youlizhao To: SUPA list , Benoit Claise CC: "ops-ads@ietf.org" , "supa-chairs@ietf.org" , "King, Daniel" Thread-Topic: [Supa] SUPA Update Thread-Index: AdLlx7FI0gJYsnA1SY+UuT+jZNMvmv//lVMA//f1DaD/1xjTUA== Date: Thu, 6 Jul 2017 02:39:59 +0000 Message-ID: <7AD05E972D7A0F47B3368775A9FF85FC9E8F59@DGGEMM505-MBX.china.huawei.com> References: <65174429B5AF4C45BD0798810EC48E0A942C73B2@EX-0-MB2.lancs.local> <666784c3-d4df-9fa1-9661-d8e182e2c7da@cisco.com> <7AD05E972D7A0F47B3368775A9FF85FC9E54C3@DGGEMM505-MBX.china.huawei.com> In-Reply-To: <7AD05E972D7A0F47B3368775A9FF85FC9E54C3@DGGEMM505-MBX.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.63.184.92] Content-Type: multipart/alternative; boundary="_000_7AD05E972D7A0F47B3368775A9FF85FC9E8F59DGGEMM505MBXchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.595DA309.003B, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.152, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 0c41c3032265ace0f7de60d339e3cc59 Archived-At: Subject: Re: [Supa] SUPA Update X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.22 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: Thu, 06 Jul 2017 02:40:17 -0000 --_000_7AD05E972D7A0F47B3368775A9FF85FC9E8F59DGGEMM505MBXchina_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 RGVhciBBbGwsDQoNCkJlbG93IGFyZSBteSB0aG91Z2h0IG9uIEVDQSBETSBiYXNlZCBvbiB0aGUg bWF0ZXJpYWxzIEkgcmVhZCBhbmQgdGhlIHByb2plY3QgSSBhbSBkb2luZy4gQW55IGNvbW1lbnRz IHdvdWxkIGJlIHdlbGNvbWUuDQoNClRoZSBkaXNjdXNzaW9ucyBhcmUgYmFzZWQgb24gYW4gRUNB IFBvbGljeSBETSBkcmFmdCBbZWNhLWRhdGEtbW9kZWxdLiBBY2NvcmRpbmcgdG8gb3VyIHVuZGVy c3RhbmRpbmcsIGl0IGlzIGFsaWduZWQgd2l0aCB0aGUgRUNBIFBvbGljeSBJTSBbZWNhLWluZm8t bW9kZWxdLg0KDQpXZSBhcHByZWNpYXRlIHRoYXQgdGhlIGRyYWZ0IFtkcmFmdC1jaGVuLXN1cGEt ZWNhLWRhdGEtbW9kZWwtMDVdIHByb3ZpZGVzIHRoZSBlbnRpdHkvc2NyaXB0IGFic3RyYWN0aW9u IHRoYXQgYWxsb3dzIGV4dGVuc2lvbiBmb3IgZGlmZmVyZW50IHNjZW5hcmlvcywgYW5kIHRoZXkg bWF0Y2ggb3VyIGltcGxlbWVudGF0aW9uLiBJbiBwYXJ0aWN1bGFyLCBvdXIgRUNBIHBvbGljeSBw YXJzZXIgY2FuIHJlYWQgZW50aXR5IGZpZWxkcyAob3Igc2NyaXB0IGZpZWxkcyksIGFuZCBtYXAg dGhlbSB0byB0aGUgQ0xJIGNvbW1hbmQgcGFyYW1ldGVycyAob3Igc2NyaXB0IGltcGxlbWVudGF0 aW9uKS4NCg0KSG93ZXZlciwgd2UgZm91bmQgdGhhdCB0aGUgY3VycmVudCBkZWZpbml0aW9uIHN0 aWxsIG1ha2VzIERNIHBhcnNpbmcgY29tcGxpY2F0ZS4gTm90ZSB0aGF0LCBpbiBbZHJhZnQtY2hl bi1zdXBhLWVjYS1kYXRhLW1vZGVsLTA1XSwgdGhlIGNvbmRpdGlvbi1saXN0IGNsYXVzZSBtYXkg c3RpbGwgaW52b2x2ZSB3aXRoIG5ldHdvcmsgZGV0YWlscyAoZS5nLiwgYmFuZHdpZHRoIGFuZCB0 aHJlc2hvbGQgaW4gdGhlIHNlcnZpY2UtZmxvdyBleGFtcGxlKSwgYW5kIHRoZSBhY3Rpb24tbGlz dCBjbGF1c2UgbWF5IHN0aWxsIGNvbnRhaW4gdGhlIGRlY2lzaW9uIGxvZ2ljIChpLmUuLCB3aGVu IHRoZSBiYW5kd2lkdGggZXhjZWVkcyBhIHRocmVzaG9sZCkgdG8gdHJpZ2dlciBhbiBhY3Rpb24u IFRvIGV4dHJhY3QgdGhlIKGwcmVhbKGxIGNvbmRpdGlvbiwgb3VyIHBvbGljeSBwYXJzZXIgbmVl ZHMgdG8gdW5kZXJzdGFuZCB0aGUgYWN0aW9uLWxpc3QgY2xhdXNlLCBhbmQgdGhlbiBnZW5lcmF0 ZSB0aGUgobBjb25kaXRpb26hsSBsb2dpYyBpbiByZWFsIGltcGxlbWVudGF0aW9uLg0KDQpUbyBt YWtlIHRoaW5ncyBtb3JlIGNvbXBsaWNhdGUsIHNvbWV0aW1lcyB3ZSBuZWVkIHRvIGp1ZGdlIHNl dmVyYWwgY29uZGl0aW9ucyB0byB0cmlnZ2VyIGFuIGFjdGlvbiAoZS5nLiwgaW4gQ2lzY28gRUVN IFtDaXNjb0VFTSwgUGFnZXMgNjksIDM0MiwgMzY4XSBhbmQgc29tZSBTRC1XQU4gZXhhbXBsZXMg aW4gSHVhd2VpIFNELVdBTiBzb2x1dGlvbiBbSHVhd2VpLVNELVdBTl0pLiBJbiBhZGRpdGlvbiwg c29tZSBjb25zdHJhaW50cyBtYXkgYmUgYWRkZWQsIGUuZy4sIHRoZSBjb25qdW5jdGl2ZS10eXBl IGR1cmF0aW9uIHRoYXQgaW5kaWNhdGVzIGhvdyBsb25nIHRoZSBjb25qdW5jdGl2ZSByZWxhdGlv bnNoaXAgc2hvdWxkIGhvbGQuIEhvd2V2ZXIsIHRoZSBjdXJyZW50IG1vZGVsIGlzIHdlYWsgb24g ZXhwcmVzc2luZyB0aGUgY2FwYWJpbGl0eSAoYWx0aG91Z2ggY29uanVuY3RpdmUtdHlwZSBpcyBk ZWZpbmVkIGluIFtlY2EtZGF0YS1tb2RlbF0sIGhvdyB0byB1c2UgaXQgaXMgbm90IGNsZWFyKS4N Cg0KQmFzZWQgb24gdGhlIGFib3ZlIGFyZ3VtZW50cywgd2Ugd291bGQgbGlrZSB0byBzdWdnZXN0 IHRoZSBmb2xsb3dpbmcgY2hhbmdlczoNCihhKSBBIGNsZWFyIHNlcGFyYXRpb24gb2YgZXZlbnRz LCBjb25kaXRpb25zLCBhbmQgYWN0aW9ucyBpcyB3ZWxjb21lIHNvIHRoYXQgb3VyIHBhcnNlciBj YW4ganVzdCBjYXJlIGRpZmZlcmVudCBwYXJ0cyBhbmQgZGlyZWN0bHkgbWFwIHRoZW0gdG8gaW1w bGVtZW50YXRpb247DQooYikgVGhlIGNvbmRpdGlvbiBjbGF1c2UgY2FuIGJlIGVucmljaGVkIHRv IGV4cHJlc3MgdGhlIGNvbmp1bmN0aXZlLXR5cGUsIGNvbmp1bmN0aXZlLWR1cmF0aW9uLCBhbmQg b3RoZXIgcG9zc2libGUgZmllbGRzLg0KDQpUaGFua3MhDQoNCg0KUmVnYXJkcywNCkxlbw0KDQoN CltlY2EtaW5mby1tb2RlbF0gR2VuZXJpYyBQb2xpY3kgSW5mb3JtYXRpb24gTW9kZWwgZm9yIFNV UEENCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zdHJhc3NuZXItc3VwYS1nZW5l cmljLXBvbGljeS1pbmZvLW1vZGVsLTA1DQpbZWNhLWRhdGEtbW9kZWxdIEVDQSBQb2xpY3kgWUFO RyBEYXRhIE1vZGVsDQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtY2hlbi1zdXBh LWVjYS1kYXRhLW1vZGVsLTA1DQpbQ2lzY28tRUVNXSBFbWJlZGRlZCBFdmVudCBNYW5hZ2VyIENv bmZpZ3VyYXRpb24gR3VpZGUsDQpodHRwOi8vd3d3LmNpc2NvLmNvbS9jL2VuL3VzL3RkL2RvY3Mv aW9zLXhtbC9pb3MvZWVtL2NvbmZpZ3VyYXRpb24vMTItMnN4L2VlbS0xMi0yc3gtYm9vay5wZGYN CltIdWF3ZWktU0QtV0FOXSBIdWF3ZWkgU0QtV0FOIFNvbHV0aW9uIEJyb2NodXJlDQpodHRwOi8v ZS5odWF3ZWkuY29tL2VuL3NvbHV0aW9ucy90ZWNobmljYWwvc2RuL2VudGVycHJpc2Utd2FuL3Nk LXdhbg0KDQpGcm9tOiBTVVBBIFttYWlsdG86c3VwYS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYgT2YgeW91bGl6aGFvDQpTZW50OiAyMDE3xOo21MIyMMjVIDE1OjM4DQpUbzogQmVub2l0IENs YWlzZSA8YmNsYWlzZUBjaXNjby5jb20+OyBLaW5nLCBEYW5pZWwgPGQua2luZ0BsYW5jYXN0ZXIu YWMudWs+DQpDYzogb3BzLWFkc0BpZXRmLm9yZzsgc3VwYS1jaGFpcnNAaWV0Zi5vcmc7IFNVUEEg bGlzdCA8c3VwYUBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbU3VwYV0gU1VQQSBVcGRhdGUNCg0K RGVhciBCZW5vaXQgQUQsDQoNClRoYW5rcyBmb3IgcHVzaGluZyBhbmQgbW9uaXRvcmluZyB0aGUg U1VQQSBXRyBwcm9ncmVzcy4NCg0KSSBhbSBzb3JyeSB0byBzZWUgdGhlIGVtYWlsIGJlbG93LiBJ IGFtIGFuIGVuZ2luZWVyIGluIEh1YXdlaSwgYW5kIHJlY2VudGx5IHdlIGhhdmUgYmVlbiBkZXZl bG9waW5nIHRoZSBjb2RlIG9mIFNVUEEgRUNBIHBvbGljeSB0byBjb250cm9sIHRoZSBuZXR3b3Jr LiBJbiBwYXJ0aWN1bGFyLCB3ZSBwcm92aWRlIHJlc3RmdWwgaW50ZXJmYWNlIHRvIHVzZXJzIGZv ciBjb25maWd1cmluZyBFQ0EgcG9saWNpZXMgZm9sbG93aW5nIHRoZSBFQ0EgRE0uDQoNClRvIGJl IGhvbmVzdCwgSU1PLCB0aGUgRUNBIElNIGFuZCBETSBhcmUgbm90IG1hdHVyZSBlbm91Z2ggZm9y IGRpcmVjdCBpbXBsZW1lbnRhdGlvbi4gV2UgYXJlIHJldmlzaW5nIHNvbWUgcGFydHMgZmFjaWxp dGF0aW5nIHRoZSBpbXBsZW1lbnRhdGlvbi4NCg0KQWx0aG91Z2ggdGhlIFNVUEEgSU0gYW5kIERN IHN0aWxsIGNvbnRhaW4gZmxhd3MsIHdlIGhvcGVkIHRvIHNlZSB0aGVtIGNvbXBsZXRlZCAoYWxz byBvdGhlciBkb2N1bWVudHMsIGUuZy4sIFNVUEEgZnJhbWV3b3JrKSBzbyB0aGF0IHdlIGNhbiBj b21wbGV0ZSBvdXIgb3duIGltcGxlbWVudGF0aW9ucyBiYXNlZCBvbiBTVVBBIHN0YW5kYXJkIHdv cmsuDQoNClRoYW5rcyBmb3IgeW91ciBjb25zaWRlcmF0aW9uLg0KDQoNClJlZ2FyZHMsDQpMZW8N Cg0KRnJvbTogU1VQQSBbbWFpbHRvOnN1cGEtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m IEJlbm9pdCBDbGFpc2UNClNlbnQ6IDIwMTfE6jbUwjE1yNUgMjA6NDcNClRvOiBLaW5nLCBEYW5p ZWwgPGQua2luZ0BsYW5jYXN0ZXIuYWMudWs8bWFpbHRvOmQua2luZ0BsYW5jYXN0ZXIuYWMudWs+ PjsgU1VQQSBsaXN0IDxzdXBhQGlldGYub3JnPG1haWx0bzpzdXBhQGlldGYub3JnPj4NCkNjOiBv cHMtYWRzQGlldGYub3JnPG1haWx0bzpvcHMtYWRzQGlldGYub3JnPjsgc3VwYS1jaGFpcnNAaWV0 Zi5vcmc8bWFpbHRvOnN1cGEtY2hhaXJzQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtTdXBhXSBT VVBBIFVwZGF0ZQ0KDQpEZWFyIGFsbCwNCg0KQWZ0ZXIgdGhlIGxhc3QgSUVURiwgSSBwdXQgYSBj YWxlbmRhciByZW1pbmRlciBvbiBKdW5lIDE2dGggdG8gZGVjaWRlIG9uIHRoZSBuZXh0IHN0ZXBz IGZvciBTVVBBLg0KVGhpcyBpcyBpbmxpbmUgd2l0aCB0aGUgb3VyIHByZXZpb3VzIG1lZXRpbmcg bWludXRlcywgc28gaXQgc2hvdWxkIG5vdCBjb21lIGFzIGEgc3VycHJpc2UuDQpHcmFudGVkLCB0 aGlzIGlzIG9uZSBkYXkgZWFybGllciB0aGFuIGZvcmVzZWVuLCBidXQgdGhlIElFU0cgYWdlbmRh IGNvb3JkaW5hdGlvbiBjYWxsIHRha2VzIHBsYWNlIHRvZGF5LCBhbmQgaXQgd2FzIGltcG9ydGFu dCBmcm9tIGEgc2NoZWR1bGluZyBwb2ludCBvZiB2aWV3IHRvIHVuZGVyc3RhbmQgaWYgU1VQQSB3 b3VsZCBtZWV0LiBUaGUgY2hhaXJzIGluZm9ybWVkIG1lIHRoYXQgbm8gU1VQQSBtZWV0aW5nIGlz IHJlcXVpcmVkIGluIFByYWd1ZS4gVGhhdCB0cmlnZ2VyZWQgdGhpcyBkaXNjdXNzaW9uLCBqdXN0 IG9uZSBkYXkgZWFybGllci4NCg0KT3VyIG1lZXRpbmcgbWludXRlczogaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9zdXBhL2N1cnJlbnQvbXNnMDE2MTIuaHRtbA0KDQpBdCB0 aGUgU1VQQSBXRyBhdCBJRVRGIDk4IChUdWVzZGF5LCAyOCBNYXJjaCkgd2UgZGlzY3Vzc2VkIHRo ZQ0KDQpwcm9ncmVzcyBvZiB0aGUgV0cuICBCZW5vaXQgKG91ciBBRCkgc3VtbWVkIHVwIHRoZSBz aXR1YXRpb24sIHBvaW50aW5nDQoNCm91dCB0aGF0IG91ciBkcmFmdHMgYXJlIG5vdCB1cGRhdGVk IHZlcnkgZnJlcXVlbnRseSwgYW5kIHRoYXQgdGhlIFNVUEENCg0KbWFpbGluZyBsaXN0IGhhcyBi ZWVuIHZlcnkgcXVpZXQgYmV0d2VlbiBtZWV0aW5ncy4NCg0KDQoNCkF0IHRoZSBtZWV0aW5nIHRo ZSBhdXRob3JzIG9mIHRoZSBTVVBBIEluZm9ybWF0aW9uIG1vZGVsIGFuZCB0aGUgU1VQQQ0KDQpE YXRhIE1vZGVsIGRyYWZ0cyBzYWlkIHRoYXQgdGhvc2UgZHJhZnRzIHNob3VsZCBiZSByZWFkeSBm b3IgV0cgTGFzdA0KDQpDYWxsIGJ5IDEgSnVuZSwgc28gdGhhdCB0aGV5IGNvdWxkIGJlIHNlbnQg dG8gSUVTRyBmb3IgYXBwcm92YWwgYnkNCg0KYWJvdXQgMSBKdWx5Lg0KDQoNCg0KQWZ0ZXIgc3Vt bWluZyB1cCB0aGUgcHJvcyBhbmQgY29ucyBmb3IgU1VQQSBjb250aW51aW5nLCBCZW5vaXQNCg0K Y29uY2x1ZGVkIGJ5IHNheWluZyB0aGF0IHRoZSBXRyB3aWxsIGJlIGNsb3NlZCBhdCBJRVRGIDk5 IChQcmFndWUsIDE2DQoNCkp1bHkpIHVubGVzcyB0aGVyZSBpcyBzdWJzdGFudGl2ZSBwcm9ncmVz cyBvbiB0aGUgSW5mb3JtYXRpb24gTW9kZWwNCg0KYW5kIGVzcGVjaWFsbHkgb24gdGhlIERhdGEg TW9kZWwgZHJhZnRzIGJ5IG9uZSBtb250aCBiZWZvcmUgdGhlIFByYWd1ZQ0KDQptZWV0aW5nLiAg J1N1YnN0YW50aXZlIHByb2dyZXNzJyBoZXJlIG1lYW5zIHNlZWluZyBjb21tZW50cyBvbiBhbmQv b3INCg0KcmV2aWV3cyBvZiB0aGVzZSBkcmFmdHMgZGVtb25zdHJhdGluZyB0aGF0IHBlb3BsZSAt IG91dHNpZGUgdGhlIHNtYWxsDQoNCmdyb3VwIG9mIGF1dGhvcnMgLSBoYXZlIGNhcmVmdWxseSBy ZWFkIHRoZSBkcmFmdHMsIG9yIGJldHRlciwgdGhhdCB0aGV5DQoNCmFyZSBhY3R1YWxseSB1c2lu ZyBTVVBBJ3MgSW5mb3JtYXRpb24gYW5kIERhdGEgTW9kZWxzLg0KSSd2ZSBiZWVuIHdhdGNoaW5n IHRoZSBsaXN0Lg0KU2luY2UgdGhlIGxhc3QgSUVURiBtZWV0aW5nLCB3ZSByZWNlaXZlZCB0d28g bmV3IGRyYWZ0cyAuLi4NCiAgICBkcmFmdC1pZXRmLXN1cGEtZ2VuZXJpYy1wb2xpY3ktaW5mby1t b2RlbC0wMy50eHQNCiAgICBkcmFmdC1pZXRmLXN1cGEtZ2VuZXJpYy1wb2xpY3ktZGF0YS1tb2Rl bC0wMy50eHQNCi4uLiBhbmQgc29tZSBkcmFmdCByZXZpZXdzOg0KZ3VudGVyLndhbmdAZXJpY3Nz b24uY29tPG1haWx0bzpndW50ZXIud2FuZ0Blcmljc3Nvbi5jb20+IG9uIG9uIGRyYWZ0LWlldGYt c3VwYS1wb2xpY3ktYmFzZWQtbWFuYWdlbWVudC1mcmFtZXdvcms6DQpHb29kIGZlZWRiYWNrIGJ1 dCBpdCBzZWVtcyBsaWtlIG9ubHkgZWRpdG9yaWFsIHRvIG1lLg0KVG9ueSB0aWFueHVAY2hpbmFt b2JpbGUuY29tPG1haWx0bzp0aWFueHVAY2hpbmFtb2JpbGUuY29tPiBvbiBkcmFmdC1jaGVuZy1z dXBhLWFwcGxpY2FiaWxpdHk6DQpTb21lIGVkaXRvcmlhbCBjb21tZW50cyBhbmQgdGhyZWUgdGVj aG5pY2FsIG9uZXM6DQoxLiAgICAgICBJIHdvbmRlciB0aGUgbWVhbmluZyBvZiBzZWN0aW9uIDMs IHRoZSBwYXJ0IGNvcGllZCBmcm9tIGZyYW1ld29yayBkcmFmdCwgbWF5IG5vdCBiZSBuZWVkZWQu DQoyLiAgICAgICBJIHN1Z2dlc3QgdG8gcmVwbGFjZSB0aGUgdGl0bGUgb2YgNC4yLjIuYW5kIDQu Mi4zIHdpdGggZGV0YWlsZWQgaW5mb3JtYXRpb24gaW5zdGVhZCBvZiB3cml0aW5nIGp1c3QgICBF eGFtcGxlIDEgLyAyLg0KMy4gICAgICAgVGhlIHdyaXRlciB3cm90ZSChsFdlIHdpbGwgZGVmaW5l ICJlZGdlSW50ZXJmYWNlIiByb2xlIGFuZCAiRW50ZXJwcmlzZURvbWFpbiIgbGF0ZXIgaW4gIHRo aXMgbm90ZaGxIGJ1dCBJIGZhaWxlZCB0byBmaW5kIHRoZSBleHBsYW5hdGlvbiBmb3IgdGhlc2Ug dHdvIHRlcm0uDQpCZW5vaXQgPT4gaXQncyBtb3JlIGxpa2Ugb25lIHRlY2huaWNhbCBjb21tZW50 LCB0aGUgbGFzdCBvbmUuDQoNCkhhaW5pbmcgV2FuZzogMTg5MDEzNDEyMjlAMTg5LmNuPG1haWx0 bzoxODkwMTM0MTIyOUAxODkuY24+IG9uIGRyYWZ0LWlldGYtc3VwYS1nZW5lcmljLXBvbGljeS1k YXRhLW1vZGVsLTAzOg0KSSB1bmRlcnN0YW5kIHRoYXQgdGhlIEdQSU0gWUFORyBtb2RlbCBwcm92 aWRlcyBhbiBleGFtcGxlIG9mIGhvdyB0byBjb252ZXJ0IElNIHRvIERNIChmb3IgZ2VuZXJhbCBw b2xpY3kpLCBhbmQgSm9obqGvcyBTTk1QIGJsb2NraW5nIGV4YW1wbGUgKGh0dHBzOi8vbWFpbGFy Y2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvc3VwYS9EV0V6YVNCSzZLQmRzbVEwRkUyLWV5cFR6ZVkp IGV4cG9zZXMgc29tZSBkZXRhaWxzLiBCdXQgSSBhbSBzb3JyeSB0aGF0IHRoZSB3aG9sZSBwaWN0 dXJlIGlzIHN0aWxsIG5vdCBjbGVhciB0byBtZS4gSXQgd291bGQgYmUgbmljZSBpZiB0aGUgRUNB IERhdGEgTW9kZWwgcGFydCBjYW4gZXhwbGFpbiBpbiBtb3JlIGRldGFpbHMuDQpNYXJjaCBCbGFu Y2hldCBvbiBkcmFmdC1pZXRmLXN1cGEtcG9saWN5LWJhc2VkLW1hbmFnZW1lbnQtZnJhbWV3b3Jr Og0KLSBsYXJnZXIgY29tbWVudDogSaGvbSBub3Qgc3VyZSB3aGF0IHRvIGRvIHdpdGggdGhpcyBk b2N1bWVudC4gSXQgbG9va3MgbGlrZSBhIGxhcmdlIHdpc2ggbGlzdCBvZiBmZWF0dXJlcy4gSSBn dWVzcyBJoa9tIHByb2JhYmx5IHRvbyB1c2VkIHRvIGltcGxlbWVudGF0aW9uL3Byb3RvY29sIGRl dGFpbHMuIEkgZ3Vlc3MgSSB3aWxsIHdhaXQgdW50aWwgdG8gc2VlIHRoZSBhY3R1YWwgcHJvdG9j b2wveWFuZyBtb2RlbHMuDQoNCkxldCdzIGFuYWx5emUgdGhlIHNpdHVhdGlvbjoNCkkgZG9uJ3Qg Y29uc2lkZXIgdGhvc2UgcmV2aWV3cyAoYnR3IGEgc2luZ2xlIG9uZSB0aGUgRE0sIG5vbmUgb24g dGhlIElNKSBhcyAic3Vic3RhbnRpdmUgcHJvZ3Jlc3MiLg0KSSBkb24ndCBzZWUgaW50ZXJlc3Qg ZnJvbSBZQU5HIG1vZHVsZSBhdXRob3JzLCByZWFkeSB0byByZXVzZSB0aGUgU1VQQSBZQU5HIGNv bnN0cnVjdHMuDQpCZWluZyBhIHllYXIgbGF0ZSBhY2NvcmRpbmcgdG8gdGhlIGNoYXJ0ZXIgbWls ZXN0b25lcywgdGhlIHdpbmRvdyBvZiBvcHBvcnR1bml0eSB0byBwcm9kdWNlIHJldXNhYmxlIHdv cmsgaGFzIGJlZW4gY2xvc2luZyByYXBpZGx5Lg0KSSBiZWxpZXZlIHRoYXQgU1VQQSBoYWQgbXVs dGlwbGUgY2hhbmNlcyB0byBtYWtlIGl0IGhhcHBlbiwgYW5kIGZhaWxlZCB0byBkZWxpdmVyLg0K V2l0aCB0aGlzIGluIG1pbmQsIEkgZG9uJ3Qgc2VlIGhvdyBJIHNob3VsZCBjb25jbHVkZSBhbnl0 aGluZyBlbHNlIHRoYW4gdGhpcyBXRyB3aWxsIGJlIGNsb3NpbmcgYXQgSUVURiA5OS4NCg0KUmVn YXJkcywgQmVub2l0IChPUFMgQUQpDQpEZWFyIHN1cGGhr3JzLA0KDQpXZSBoYXZlIGNhbmNlbGxl ZCBvdXIgZm9ybWFsIG1lZXRpbmcgaW4gUHJhZ3VlLiBUaGlzIGRlY2lzaW9uIHdhcyB0YWtlbiBi YXNlZCBvbiBhIHByb3Bvc2VkIHBsYW4gdG8gZm9jdXMgZWZmb3J0IG9uIGNvbXBsZXRpbmcgdGhl IGV4aXN0aW5nIFdHIGl0ZW1zIGFuZCBwcmVwYXJlIGZvciBjbG9zdXJlIG9mIHRoZSBzdXBhIHdv cmtpbmcgZ3JvdXAgc29tZXRpbWUgYmV0d2VlbiBJRVRGIDk5IGFuZCAxMDAuIEEgcGxhbiB0aGF0 IGlzIHlldCB0byBiZSBhcHByb3ZlZCBieSBCZW5vaXQuDQoNCkR1cmluZyB0aGUgbGFzdCB3b3Jr aW5nIGdyb3VwIG1lZXRpbmcgQmVub2l0IHN0YXRlZDoNCg0KobB0aGUgV0cgd2lsbCBiZSBjbG9z ZWQgYXQgSUVURiA5OSAoUHJhZ3VlLCAxNiBKdWx5KSB1bmxlc3MgdGhlcmUgaXMgc3Vic3RhbnRp dmUgcHJvZ3Jlc3Mgb24gdGhlIEluZm9ybWF0aW9uIE1vZGVsIGFuZCBlc3BlY2lhbGx5IG9uIHRo ZSBEYXRhIE1vZGVsIGRyYWZ0IGJ5IG9uZSBtb250aCBiZWZvcmUgdGhlIFByYWd1ZSBtZWV0aW5n LqGxDQoNClRoZSBhdXRob3JzIG9mIHRoZSBEYXRhIE1vZGVsIGFuZCBJbmZvcm1hdGlvbiBNb2Rl bCBJLURzIGRpZCBzdWJtaXQgbmV3IHZlcnNpb25zIGJ1dCB3ZSBvbmx5IHJlY2VpdmVkIG9uZSBy ZXZpZXcuIEhvd2V2ZXIsIE5ldmlsIGFuZCBJIGFyZSB3b3JraW5nIHdpdGggdGhlIElNIGFuZCBE TSBhdXRob3JzIHRvIGdhdGhlciByZXZpZXdlcnMgaW4gcHJlcGFyYXRpb24gb2YgTGFzdCBDYWxs LiBFc3NlbnRpYWxseSwgd2UgYXJlIHdvcmtpbmcgdG8gcHJlcCBmb2xrcyB3aG8gd291bGQgYmUg YWJsZSB0byByZXZpZXcgdGhlIGRvY3VtZW50cyB3ZSBMYXN0IENhbGwsIGlkZWFsbHkgdGhlc2Ug c2hvdWxkIGJlIGZyb20gcG9saWN5L3lhbmcgaW1wbGVtZW50ZXJzLg0KDQpUaGUgRnJhbWV3b3Jr IEktRCBoYXMgYWxzbyByZWNlaXZlZCBhIHJldmlldyB3aGljaCBpcyBwb3NpdGl2ZSwgYW5kIEkg YW0gaW4gdGhlIHByb2Nlc3Mgb2YgcmV2aWV3aW5nIHRoZSBkb2N1bWVudCBteXNlbGYgdG8gYWxz byBoZWxwIHByZXBhcmUgdGhlIGRvY3VtZW50IGZvciBMYXN0IENhbGwuIEFkZGl0aW9uYWxseSwg dGhlIEFwcGxpY2FiaWxpdHkgSS1EIChhIG5vbi13b3JraW5nIGdyb3VwIGRvY3VtZW50KSByZWNl aXZlZCBhIHJldmlldyB3aGljaCBpcyBhbHNvIHVzZWZ1bC4NCg0KV2UgaGF2ZSBhbHNvIHNlZW4g bm90aWZpY2F0aW9ucyBmcm9tIG90aGVyIFNET3MgZm9sbG93aW5nIHN1cGEsIHNwZWNpZmljYWxs eToNCi0gT05VRzogSW52ZXN0aWdhdGluZyBJMk5TRiBjb21iaW5lZCB3aXRoIHRoZSBTVVBBIGRh dGEgbW9kZWwgYW5kIGZyYW1ld29yaw0KLSBFVFNJIEV4cGVyaWVudGlhbCBOZXR3b3JrZWQgSW50 ZWxsaWdlbmNlIChFTkkpOiBOZXcgaW5pdGlhdGl2ZSBkZWZpbmluZyBjb250ZXh0IGF3YXJlIG5l dHdvcmtpbmcgc3lzdGVtcywgU1VQQSB3YXMgaWRlbnRpZmllZCBhcyBhIGtleSBidWlsZGluZyBi bG9jaw0KLSBNRUYgT3BlbiBMaWZlY3ljbGUgU2VydmljZSBPcmNoZXN0cmF0b3IgKExTTyk6IFVz aW5nIFNVUEEgYmV0d2VlbiBmdW5jdGlvbmFsIGNvbXBvbmVudHMNCg0KSG93ZXZlciwgdGhlIGlu ZGljYXRpb24gZnJvbSBPTlVHLCBFVFNJIGFuZCBNRUYgZG9lcyBub3QgbWF0ZXJpYWxseSBjaGFu Z2UgdGhlIHNpdHVhdGlvbiBvZiBTVVBBIGJ1dCBpdCBkb2VzIGRlbW9uc3RyYXRlIHdpZGVyIGlu dGVyZXN0IGluIG91ciB3b3JrLCBhbmQgYXQgbGVhc3Qgc29tZSByZXNwb25zaWJpbGl0eSBmb3Ig c3VwYS9JRVRGIHRvIGNvbXBsZXRlIGl0IChpZiBwb3NzaWJsZSkuIElmIHlvdSBhcmUgYXdhcmUg b2YgbmVhci10ZXJtIGltcGxlbWVudGF0aW9ucyBub3cgaXMgdGhlIHRpbWUgdG8gaGlnaGxpZ2h0 IHRoZW0uDQoNCkFnYWluLCB3ZSBmZWx0IHdlIGRpZCBub3QgbmVlZCBhIFdHIG1lZXRpbmcgaW4g UHJhZ3VlIHRvIHByb2dyZXNzIHRoZSB3b3JraW5nIGdyb3VwIEktRHMsIGFuZCBnaXZlbiB0aGUg SUVURiBhZ2VuZGEgY29vcmRpbmF0aW9uIGNhbGwgKGlzIHRvZGF5KSB3ZSBoYWQgdG8gY2FuY2Vs IHRoZSBzdXBhIFdHIHNlc3Npb24gcmVxdWVzdCBBU0FQLCBhbmQgdW5mb3J0dW5hdGVseSBiZWZv cmUgd2UgaGFkIGEgY2hhbmNlIHRvIGNvbW11bmljYXRlIHRoZSBjdXJyZW50IHNpdHVhdGlvbiB0 byB0aGUgcmVzdCBvZiB0aGUgd29ya2luZyBncm91cC4gQXBvbG9naWVzIGZvciBhbnkgc3VycHJp c2Ugd2hlbiB5b3Ugc2F3IHRoZSBjYW5jZWxsYXRpb24gbm90aWZpY2F0aW9uLCBhbmQgdGhlIGxh Y2sgb2Ygb3Bwb3J0dW5pdHkgZm9yIHdpZGVyIGRpc2N1c3Npb24uDQoNCkFzIG1lbnRpb25lZCBv dXIgcHJvcG9zZWQgcGxhbiBoYXMgYmVlbiBzdWJtaXR0ZWQgdG8gQmVub2l0IGFuZCBpcyB5ZXQg dG8gYmUgYXBwcm92ZWQsIHRoZXJlZm9yZSB3ZSB3aWxsIHdhaXQgZm9yIGhpcyB0aG91Z2h0cyBh bmQgdWx0aW1hdGUgZGVjaXNpb24uDQoNClRoZSBTVVBBIENoYWlycyB3b3VsZCBzaW5jZXJlbHkg bGlrZSB0byB0aGFuayBldmVyeW9uZSBmb3IgdGhlaXIgcGFydGljaXBhdGlvbiBhbmQgZXNwZWNp YWxseSB0aGUgYXV0aG9ycyBvZiBJLURzIGZvciB0aGVpciBlZmZvcnRzLg0KDQpCUiwgTmV2aWwg YW5kIERhbi4NCg0K --_000_7AD05E972D7A0F47B3368775A9FF85FC9E8F59DGGEMM505MBXchina_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Dear All,

 

Below are my thought on ECA DM based = on the materials I read and the project I am doing. Any comments would be w= elcome.

 

The discussions are based on an ECA P= olicy DM draft [eca-data-model]. According to our understanding, it is alig= ned with the ECA Policy IM [eca-info-model].

 

We appreciate that the draft [draft-chen-supa-eca-data= -model-05] provides the entity/script abstraction that allows extension for different scenarios, and they match our implemen= tation. In particular, our ECA policy parser can read entity fields (or scr= ipt fields), and map them to the CLI command parameters (or script implemen= tation).

 

However, we found that the current de= finition still makes DM parsing complicate. Note that, in [draft-chen-supa-= eca-data-model-05], the condition-list clause may still involve with network details (e.g., bandwidth and threshold in t= he service-flow example), and the action-list clause may still contain the = decision logic (i.e., when the bandwidth exceeds a threshold) to trigger an= action. To extract the =A1=B0real=A1=B1 condition, our policy parser needs to understand the action-list clause, and then gen= erate the =A1=B0condition=A1=B1 logic in real implementation.

 

To make things more complicate, somet= imes we need to judge several conditions to trigger an action (e.g., in Cis= co EEM [CiscoEEM, Pages 69, 342, 368] and some SD-WAN examples in Huawei SD-WAN solution [Huawei-SD-WAN]). In addition, s= ome constraints may be added, e.g., the conjunctive-type duration that indi= cates how long the conjunctive relationship should hold. However, the curre= nt model is weak on expressing the capability (although conjunctive-type is defined in [eca-data-model], how = to use it is not clear).

 

Based on the above arguments, we woul= d like to suggest the following changes:

(a) A clear separation of events, con= ditions, and actions is welcome so that our parser can just care different = parts and directly map them to implementation;

(b) The condition clause can be enric= hed to express the conjunctive-type, conjunctive-duration, and other possib= le fields.

 

Thanks!

 

 

Regards,

Leo

 

 

[eca-info-model] Generic Policy Infor= mation Model for SUPA

https://tools.ietf.org/html/draft-strassner-su= pa-generic-policy-info-model-05

[eca-data-model] ECA Policy YANG Data= Model

https://tools.ietf.org/html/draft-chen-supa-eca-data-model-05<= /span>

[Cisco-EEM] Embedded Event Manager Co= nfiguration Guide,

http://www.cisco.com/c/en/us/t= d/docs/ios-xml/ios/eem/configuration/12-2sx/eem-12-2sx-book.pdf<= o:p>

[Huawei-SD-WAN] Huawei SD-WAN Solutio= n Brochure

http://e.huawei.com/en/solutions/technical/sdn/enterpri= se-wan/sd-wan

 

From: SUPA [mailto:supa-bounces@ietf.org] On Behalf Of youlizhao
Sent: 2017=C4=EA6=D4=C220= =C8=D5 15:38
To: Benoit Claise <bclaise@cisco.com>; King, Daniel <d.king= @lancaster.ac.uk>
Cc: ops-ads@ietf.org; supa-chairs@ietf.org; SUPA list <supa@ietf.= org>
Subject: Re: [Supa] SUPA Update

 

Dear Benoit AD,

 

Thanks for pushing and monitoring the= SUPA WG progress.

 

I am sorry to see the email below. I = am an engineer in Huawei, and recently we have been developing the code of = SUPA ECA policy to control the network. In particular, we provide restful interface to users for configuring ECA policies followi= ng the ECA DM.

 

To be honest, IMO, the ECA IM and DM = are not mature enough for direct implementation. We are revising some parts= facilitating the implementation.

 

Although the SUPA IM and DM still con= tain flaws, we hoped to see them completed (also other documents, e.g., SUP= A framework) so that we can complete our own implementations based on SUPA standard work.

 

Thanks for your consideration.

 

 

Regards,

Leo

 

From: SUPA [mailto:supa-bounces@ietf= .org] On Behalf Of Benoit Claise
Sent: 2017=C4=EA6=D4=C215= =C8=D5 20:47
To: King, Daniel <d.kin= g@lancaster.ac.uk>; SUPA list <s= upa@ietf.org>
Cc: ops-ads@ietf.org; supa-chairs@ietf.org
Subject: Re: [Supa] SUPA Update

 

Dear all,

After the last IETF, I put a calendar reminder on June 16th to decide on th= e next steps for SUPA.
This is inline with the our previous meeting minutes, so it should not come= as a surprise.
Granted, this is one day earlier than foreseen, but the IESG agenda coordin= ation call takes place today, and it was important from a scheduling point = of view to understand if SUPA would meet. The chairs informed me that no SU= PA meeting is required in Prague. That triggered this discussion, just one day earlier.

Our meeting minutes: https://www.ietf.org/mail-archive/web/supa/current/msg01612.html

At the SUPA WG at IETF 98 (Tuesday, 28 March) we discussed the
progress of the WG.  Benoit (our AD) summed up the situation, poi=
nting
out that our drafts are not updated very frequently, and that the SUPA=

mailing list has been very quiet between meetings.
 
At the meeting the authors of the SUPA Information model and the SUPA<=
o:p>
Data Model drafts said that those drafts should be ready for WG Last
Call by 1 June, so that they could be sent to IESG for approval by
about 1 July.
 
After summing up the pros and cons for SUPA continuing, Benoit
concluded by saying that the WG will be closed at IETF 99 (Prague, 16<=
o:p>
July) unless there is substantive progress on the Information Model
and especially on the Data Model drafts by one month before the Prague=

meeting.  'Substantive progress' here means seeing comments on an=
d/or
reviews of these drafts demonstrating that people - outside the small<=
o:p>
group of authors - have carefully read the drafts, or better, that the=
y
are actually using SUPA's Information and Data Models.

I've been watching the list.

Since the last IETF meeting, we received two new dra= fts ...

    draft-ietf-supa-generic-policy-in= fo-model-03.txt
    draft-ietf-supa-generic-policy-data-model-03.txt

... and some draft reviews:

gunter.w= ang@ericsson.com on on draft-ietf-supa-policy-based-management-framewor= k:

Good feedback but it seems like only editorial to me= .

Tony tianx= u@chinamobile.com on draft-cheng-supa-applicability:

Some editorial comments and three technical ones:

1.       I wonder the meaning of section 3, the pa= rt copied from framework draft, may not be needed.

2.       I suggest to replace the title of 4.2.2.a= nd 4.2.3 with detailed information instead of writing just   Example 1 / 2.

3.       The writer wrote =A1=B0We w= ill define "edgeInterface" role and "EnterpriseDomain" = later in  this note=A1=B1 but I failed to find the explanation for the= se two term.

Benoit =3D> it's more like one technical comment,= the last one.


Haining Wang: 18901341229@189.cn = on draft-ietf-supa-generic-policy-data-model-03:

I understand that the= GPIM YANG model provides an example of how to convert IM to DM (for genera= l policy), and John=A1=AFs SNMP blocking example (https://mailarchi= ve.ietf.org/arch/msg/supa/DWEzaSBK6KBdsmQ0FE2-eypTzeY) exposes some details. But I am sorry that the whole picture is still not c= lear to me. It would be nice if the ECA Data Model part can explain in more= details.

March Blanchet on draft-ietf-supa-policy-based-manag= ement-framework:

- larger comment: I=A1=AFm not sure what to do with = this document. It looks like a large wish list of features. I guess I=A1=AF= m probably too used to implementation/protocol details. I guess I will wait= until to see the actual protocol/yang models.


Let's analyze the situation:
I don't consider those reviews (btw a single one the DM, none on the IM) as= "substantive progress".
I don't see interest from YANG module authors, ready to reuse the SUPA YANG= constructs.
Being a year late according to the charter milestones, the window of opport= unity to produce reusable work has been closing rapidly.
I believe that SUPA had multiple chances to make it happen, and failed to d= eliver.
With this in mind, I don't see how I should conclude anything else than thi= s WG will be closing at IETF 99.

Regards, Benoit (OPS AD)

Dear supa=A1=AFrs,

 

We have cancelled our formal meeting in Prague. This decision was = taken based on a proposed plan to focus effort on completing the existing W= G items and prepare for closure of the supa working group sometime between IETF 99 and 100. A plan that is yet to= be approved by Benoit.

 

During the last working group meeting Benoit stated:

 

=A1=B0the WG will be closed at IETF 99 (Prague, 16 July) unless th= ere is substantive progress on the Information Model and especially on the = Data Model draft by one month before the Prague meeting.=A1=B1

 

The authors of the Data Model and Information Model I-Ds did submi= t new versions but we only received one review. However, Nevil and I are wo= rking with the IM and DM authors to gather reviewers in preparation of Last Call. Essentially, we are working = to prep folks who would be able to review the documents we Last Call, ideal= ly these should be from policy/yang implementers.

 

The Framework I-D has also received a review which is positive, an= d I am in the process of reviewing the document myself to also help prepare= the document for Last Call. Additionally, the Applicability I-D (a non-working group document) received a review whi= ch is also useful.

 

We have also seen notifications from other SDOs following supa, sp= ecifically:

- ONUG: Investigating I2NSF combined with the SUPA data model and = framework

- ETSI Experiential Networked Intelligence (ENI): New initiative d= efining context aware networking systems, SUPA was identified as a key buil= ding block

- MEF Open Lifecycle Service Orchestrator (LSO): Using SUPA betwee= n functional components

 

However, the indication from ONUG, ETSI and MEF does not materiall= y change the situation of SUPA but it does demonstrate wider interest in ou= r work, and at least some responsibility for supa/IETF to complete it (if possible). If you are aware of near-term = implementations now is the time to highlight them.

 

Again, we felt we did not need a WG meeting in Prague to progress = the working group I-Ds, and given the IETF agenda coordination call (is tod= ay) we had to cancel the supa WG session request ASAP, and unfortunately before we had a chance to communicate the = current situation to the rest of the working group. Apologies for any surpr= ise when you saw the cancellation notification, and the lack of opportunity= for wider discussion.

 

As mentioned our proposed plan has been submitted to Benoit and is= yet to be approved, therefore we will wait for his thoughts and ultimate d= ecision.

 

The SUPA Chairs would sincerely like to thank everyone for their p= articipation and especially the authors of I-Ds for their efforts.

 

BR, Nevil and Dan.

 

--_000_7AD05E972D7A0F47B3368775A9FF85FC9E8F59DGGEMM505MBXchina_-- From nobody Wed Jul 5 19:50:48 2017 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 55F7F12EC4D; Wed, 5 Jul 2017 19:50:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 x2FXParFnDNT; Wed, 5 Jul 2017 19:50:36 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0094.outbound.protection.outlook.com [104.47.0.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE0421286D6; Wed, 5 Jul 2017 19:50:35 -0700 (PDT) Received: from DB6PR0601MB2167.eurprd06.prod.outlook.com (10.168.57.26) by DB6PR0601MB2166.eurprd06.prod.outlook.com (10.168.57.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1220.11; Thu, 6 Jul 2017 02:50:31 +0000 Received: from DB6PR0601MB2167.eurprd06.prod.outlook.com ([fe80::d82f:5230:5e12:43b4]) by DB6PR0601MB2167.eurprd06.prod.outlook.com ([fe80::d82f:5230:5e12:43b4%13]) with mapi id 15.01.1220.018; Thu, 6 Jul 2017 02:50:32 +0000 From: "Diego R. Lopez" To: Linda Dunbar CC: Benoit Claise , "King, Daniel" , "ops-ads@ietf.org" , "supa-chairs@ietf.org" , SUPA list Thread-Topic: [Supa] SUPA Update Thread-Index: AdLlx7FI0gJYsnA1SY+UuT+jZNMvmgADbe8AAPFY1oAAYHD9AAI+yDMAAF8fegAADplcgAABBFMAAAv+1QA= Date: Thu, 6 Jul 2017 02:50:31 +0000 Message-ID: <386D9D59-920C-4F22-A783-C41F3D25300A@telefonica.com> References: <65174429B5AF4C45BD0798810EC48E0A942C73B2@EX-0-MB2.lancs.local> <666784c3-d4df-9fa1-9661-d8e182e2c7da@cisco.com> <3790BAEB-0E40-413B-BD84-60EE2E9CF483@telefonica.com> <77C6AB0B-58D5-45CD-A6D7-C3271AD76E81@telefonica.com> <38bdf7e3-8d65-beeb-327f-f962f3b8f7da@cisco.com> <1D8D8D7F-96D1-49F1-B494-043CA99150BE@telefonica.com> <4A95BA014132FF49AE685FAB4B9F17F6593DD0F8@SJCEML702-CHM.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F6593DD0F8@SJCEML702-CHM.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: huawei.com; dkim=none (message not signed) header.d=none;huawei.com; dmarc=none action=none header.from=telefonica.com; x-originating-ip: [195.76.232.154] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB6PR0601MB2166; 7:63bV6203KNaBMqKMISD6R1nbrKDylUaFkG6ljHGZd48LwQX0AKEO/Cm6XASvBTs94XEUcZ10m+XrFOqW0OM1auEQ81TAieLYeFAn17yk/OXzL65a/F6U9pavF97E+uGe9GU32ea46iDJG0IYMJZ7Ddx9A2TVCstoq9MyN0F9cjBqVIEPETtePOiZx/Vo0P4G2iguic6BN4ououwiQfBdcxaDftqEUp8GGkzKfg0JELXKXV9gx5AurfAwko42IjoczMmA9p0v237dG3P+9rrIC1gO84IK1N4dwnKE44MkgRJ2CZTnjMqx3B9BnmxdaeXG9Sf4CTjdxmV+BrWk+q0q9E80rposqYWnI0xf+6uhEpw9Dn3BJM6rIJS0SeubV8RueC0e/tfMoQhOxQzM1BLZjPO5oeUEpD+gAbpAozJ8H7hB10+WMsfRdGxzJ2lVT0uZDJY3ro+ZhZLbJD+huItHLGS/HjYc670E0fHCJIgu5CDdlHFa7BuMTngdtjyMQMYOKYnwzw1WnxfNOnq0TEBhAvtirBnuSopFXZTPkVL61JB5eyA4ylQ6wawQ9JFEtMor8/0xuy5bsMchiWhl+Epc9Yk1YV8GQWF1jqrs8yikrPMsSMDcNLqeO8HYKv//MoEMko5I0gCcMnmila9teaUuYXW2M+hhTpoTiET/5/1Iy9nBjiy57urJDjQrUlA86cuezOnmFvu/+ZvNOJi37GN1zwyf9fQYMVb/aoSq+6hMm1YFH/easJ4LzBzJRwQZ4p3dkC0M8MHoLORV++QMYaihQ9MKMc/v7mWsahBhq3F7ay0= x-ms-office365-filtering-correlation-id: 4e4fc440-aa3b-4f44-d395-08d4c419c4c0 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(48565401081)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DB6PR0601MB2166; x-ms-traffictypediagnostic: DB6PR0601MB2166: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(278178393323532)(40392960112811)(120809045254105)(236129657087228)(192374486261705)(50582790962513)(788757137089)(48057245064654)(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(2017060910041)(8121501046)(3002001)(93006095)(93001095)(10201501046)(100000703101)(100105400095)(6055026)(6041248)(20161123560025)(20161123555025)(20161123564025)(20161123558100)(201703131423075)(201702281528075)(201702281529075)(201703061421075)(201703061406153)(20161123562025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DB6PR0601MB2166; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DB6PR0601MB2166; x-forefront-prvs: 03607C04F0 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(39850400002)(39400400002)(39860400002)(39410400002)(39840400002)(39450400003)(40134004)(377454003)(51914003)(25724002)(252514010)(24454002)(93886004)(54896002)(8676002)(478600001)(6436002)(36756003)(3280700002)(25786009)(966005)(2420400007)(15650500001)(606006)(66066001)(14454004)(6506006)(83716003)(7736002)(6306002)(10710500007)(54906002)(82746002)(81166006)(68736007)(99286003)(3660700001)(86362001)(5660300001)(575784001)(102836003)(6512007)(236005)(8936002)(110136004)(6116002)(3846002)(189998001)(53546010)(5250100002)(38730400002)(2900100001)(53936002)(2950100002)(54356999)(6916009)(4326008)(50986999)(229853002)(53376002)(6486002)(53386004)(7110500001)(76176999)(33656002)(6246003)(2906002)(53946003)(12290500005)(15398625002)(579004)(559001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6PR0601MB2166; H:DB6PR0601MB2167.eurprd06.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_386D9D59920C4F22A783C41F3D25300Atelefonicacom_" MIME-Version: 1.0 X-OriginatorOrg: telefonica.com X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jul 2017 02:50:31.8348 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9744600e-3e04-492e-baa1-25ec245c6f10 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0601MB2166 Archived-At: Subject: Re: [Supa] SUPA Update X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.22 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: Thu, 06 Jul 2017 02:50:46 -0000 --_000_386D9D59920C4F22A783C41F3D25300Atelefonicacom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Linda, Actually, SUPA application is described along 3.2.3, 3.2.4, and 4.3. Append= ix B is a deployment guide for the CogNet infrastructure, including example= s of the SUPA constructs used. Be goode, On 5 Jul 2017, at 23:07 , Linda Dunbar > wrote: Diego, Thanks for the link. Do you mean Section 3.2.2.3 using SUPA data model to configure a policy? =93supa-policy": { =93supa-policy-validity-period=94: { =93start=94: "2015-11-09T00:42:57.527404Z" } =93supa-policy-target=94: { =93topicName": =93demoX=94, =93domainName": =93systemX=94, =93subNetwork=94: =93192.168.1.1=94, =93instanceName=94: =93rack1=94 } =93supa-policy-statement=94: { =93event": { =93event-name=94: =93noisy-neighbor=94, =93event-value-type=94: =93float=94, =93event-value=94: =935.1=94 =93instanceName=94: =93compute0.vm3=94, } =93condition": { =93condition-name=94: =93noisy-neighbor=94, =93condition-operator=94: =93>=94, =93condition-threshold=94: =935.0=94, =93supa-script-content=94: { =93script-Java=94: =93if (value > 5.0) return TRUE=94 } } =93action": { =93action-name=94: =93noisy-neighbor=94, =93action-type=94: =93migrate-vm=94 =93action-param1=94: { =93param-type=94: =93entity=94 =93param-value=94: =93compute2=94 =93instanceName=94: =93compute2=94 } } } } Thanks, Linda From: SUPA [mailto:supa-bounces@ietf.org] On Behalf Of Diego R. Lopez Sent: Wednesday, July 05, 2017 3:38 PM To: Benoit Claise > Cc: King, Daniel >; o= ps-ads@ietf.org; supa-chairs@ietf.org; SUPA list > Subject: Re: [Supa] SUPA Update Hi Benoit, The most detailed discussion of the application of the SUPA data model can = be found in the CogNet deliverable D6.2, =93Integrated Platform and Perform= ance Reports. Release 1=94, which is a public document available at http://= www.cognet.5g-ppp.eu/wp-content/uploads/2017/05/CogNet_D62.pdf The discussi= on of how SUPA is used is fundamentally made in sections 3 and 4, and appen= dix B. I was thinking about summarizing this to augment the applicability statemen= t, but I am afraid I have not found time for it yet=85 Be goode, On 5 Jul 2017, at 15:39 , Benoit Claise > wrote: Hi Diego, Thanks for the discussion. So you're applying the SUPA data model (draft-ietf-supa-generic-policy-data= -model-04)? Can you please share how you reuse them and what's your experience? Regards, Benoit Hi Benoit, In the CogNet project (http://www.cognet.5g-ppp.eu) we are applying the data models to express the policy rules (and the= events and actions) derived from the application of the so-called Smart En= gine. We are discussing about following a similar path in SHIELD (https://w= ww.shield-h2020.eu) to express security polic= ies, and advocating for it in 5G-TRANSFORMER (http://5g-transformer.eu) when expressing rules for policy-based management. = The results of these projects are being or will be transferred to our opera= tional practices, as well as what is being defined in I2NSF, where SUPA see= ms the natural data model for expressing policies to the Security Controlle= r. Is tis the kind of statement you were asking for? Be goode, On 22 Jun 2017, at 07:58 , Benoit Claise > wrote: Hi Diego, Can you expand on the re-usability aspects. What is being reused? the information model, the data model, something else= ? I hope more than the concepts. What are you, yourself, reusing? Regards, Benoit Hi Benoit, While I cannot talk for YANG module authors, and it is true that the WG has= a significant delay in its deliverables, I =91d like to stress that SUPA h= as produced reusable work that is being used elsewhere, and a closing of th= e group before it finishes its commitments would damage these other works. = I am directly involved in the I2NSF WG (that is progressing quite well in m= y opinion), and in several collaborative European projects related with 5G = and security, including a number of network operators that are experimentin= g with SUPA-based policy statements. And I am aware of the ONUG interest as= well, though not being involved I cannot detail what they are targeting no= w. So I would ask you to reconsider the decision of closing SUPA at IETF 99. Be goode, On 15 Jun 2017, at 14:46 , Benoit Claise > wrote: Dear all, After the last IETF, I put a calendar reminder on June 16th to decide on th= e next steps for SUPA. This is inline with the our previous meeting minutes, so it should not come= as a surprise. Granted, this is one day earlier than foreseen, but the IESG agenda coordin= ation call takes place today, and it was important from a scheduling point = of view to understand if SUPA would meet. The chairs informed me that no SU= PA meeting is required in Prague. That triggered this discussion, just one = day earlier. Our meeting minutes: https://www.ietf.org/mail-archive/web/supa/current/msg= 01612.html At the SUPA WG at IETF 98 (Tuesday, 28 March) we discussed the progress of the WG. Benoit (our AD) summed up the situation, pointing out that our drafts are not updated very frequently, and that the SUPA mailing list has been very quiet between meetings. At the meeting the authors of the SUPA Information model and the SUPA Data Model drafts said that those drafts should be ready for WG Last Call by 1 June, so that they could be sent to IESG for approval by about 1 July. After summing up the pros and cons for SUPA continuing, Benoit concluded by saying that the WG will be closed at IETF 99 (Prague, 16 July) unless there is substantive progress on the Information Model and especially on the Data Model drafts by one month before the Prague meeting. 'Substantive progress' here means seeing comments on and/or reviews of these drafts demonstrating that people - outside the small group of authors - have carefully read the drafts, or better, that they are actually using SUPA's Information and Data Models. I've been watching the list. Since the last IETF meeting, we received two new drafts ... draft-ietf-supa-generic-policy-info-model-03.txt draft-ietf-supa-generic-policy-data-model-03.txt ... and some draft reviews: gunter.wang@ericsson.com on on draft-ietf-= supa-policy-based-management-framework: Good feedback but it seems like only editorial to me. Tony tianxu@chinamobile.com on draft-cheng-s= upa-applicability: Some editorial comments and three technical ones: 1. I wonder the meaning of section 3, the part copied from framework = draft, may not be needed. 2. I suggest to replace the title of 4.2.2.and 4.2.3 with detailed in= formation instead of writing just Example 1 / 2. 3. The writer wrote =93We will define "edgeInterface" role and "Enter= priseDomain" later in this note=94 but I failed to find the explanation fo= r these two term. Benoit =3D> it's more like one technical comment, the last one. Haining Wang: 18901341229@189.cn on draft-ietf-s= upa-generic-policy-data-model-03: I understand that the GPIM YANG model provides an example of how to convert= IM to DM (for general policy), and John=92s SNMP blocking example (https:/= /mailarchive.ietf.org/arch/msg/supa/DWEzaSBK6KBdsmQ0FE2-eypTzeY) exposes so= me details. But I am sorry that the whole picture is still not clear to me.= It would be nice if the ECA Data Model part can explain in more details. March Blanchet on draft-ietf-supa-policy-based-management-framework: - larger comment: I=92m not sure what to do with this document. It looks li= ke a large wish list of features. I guess I=92m probably too used to implem= entation/protocol details. I guess I will wait until to see the actual prot= ocol/yang models. Let's analyze the situation: I don't consider those reviews (btw a single one the DM, none on the IM) as= "substantive progress". I don't see interest from YANG module authors, ready to reuse the SUPA YANG= constructs. Being a year late according to the charter milestones, the window of opport= unity to produce reusable work has been closing rapidly. I believe that SUPA had multiple chances to make it happen, and failed to d= eliver. With this in mind, I don't see how I should conclude anything else than thi= s WG will be closing at IETF 99. Regards, Benoit (OPS AD) Dear supa=92rs, We have cancelled our formal meeting in Prague. This decision was taken bas= ed on a proposed plan to focus effort on completing the existing WG items a= nd prepare for closure of the supa working group sometime between IETF 99 a= nd 100. A plan that is yet to be approved by Benoit. During the last working group meeting Benoit stated: =93the WG will be closed at IETF 99 (Prague, 16 July) unless there is subst= antive progress on the Information Model and especially on the Data Model d= raft by one month before the Prague meeting.=94 The authors of the Data Model and Information Model I-Ds did submit new ver= sions but we only received one review. However, Nevil and I are working wit= h the IM and DM authors to gather reviewers in preparation of Last Call. Es= sentially, we are working to prep folks who would be able to review the doc= uments we Last Call, ideally these should be from policy/yang implementers. The Framework I-D has also received a review which is positive, and I am in= the process of reviewing the document myself to also help prepare the docu= ment for Last Call. Additionally, the Applicability I-D (a non-working grou= p document) received a review which is also useful. We have also seen notifications from other SDOs following supa, specificall= y: - ONUG: Investigating I2NSF combined with the SUPA data model and framework - ETSI Experiential Networked Intelligence (ENI): New initiative defining c= ontext aware networking systems, SUPA was identified as a key building bloc= k - MEF Open Lifecycle Service Orchestrator (LSO): Using SUPA between functio= nal components However, the indication from ONUG, ETSI and MEF does not materially change = the situation of SUPA but it does demonstrate wider interest in our work, a= nd at least some responsibility for supa/IETF to complete it (if possible).= If you are aware of near-term implementations now is the time to highlight= them. Again, we felt we did not need a WG meeting in Prague to progress the worki= ng group I-Ds, and given the IETF agenda coordination call (is today) we ha= d to cancel the supa WG session request ASAP, and unfortunately before we h= ad a chance to communicate the current situation to the rest of the working= group. Apologies for any surprise when you saw the cancellation notificati= on, and the lack of opportunity for wider discussion. As mentioned our proposed plan has been submitted to Benoit and is yet to b= e approved, therefore we will wait for his thoughts and ultimate decision. The SUPA Chairs would sincerely like to thank everyone for their participat= ion and especially the authors of I-Ds for their efforts. BR, Nevil and Dan. _______________________________________________ SUPA mailing list SUPA@ietf.org https://www.ietf.org/mailman/listinfo/supa -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D http://people.tid.es/diego.lopez/ e-mail: diego.r.lopez@telefonica.com Tel: +34 913 129 041 Mobile: +34 682 051 091 ---------------------------------- ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o= copia sin autorizaci=F3n puede estar prohibida en virtud de la legislaci= =F3n vigente. Si ha recibido este mensaje por error, le rogamos que nos lo = comunique inmediatamente por esta misma v=EDa y proceda a su destrucci=F3n. The information contained in this transmission is privileged and confidenti= al information intended only for the use of the individual or entity named = above. If the reader of this message is not the intended recipient, you are= hereby notified that any dissemination, distribution or copying of this co= mmunication is strictly prohibited. If you have received this transmission = in error, do not read it. Please immediately reply to the sender that you h= ave received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, div= ulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o pode estar proibida em virtude= da legisla=E7=E3o vigente. Se recebeu esta mensagem por erro, rogamos-lhe = que nos o comunique imediatamente por esta mesma via e proceda a sua destru= i=E7=E3o -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D http://people.tid.es/diego.lopez/ e-mail: diego.r.lopez@telefonica.com Tel: +34 913 129 041 Mobile: +34 682 051 091 ---------------------------------- ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o= copia sin autorizaci=F3n puede estar prohibida en virtud de la legislaci= =F3n vigente. Si ha recibido este mensaje por error, le rogamos que nos lo = comunique inmediatamente por esta misma v=EDa y proceda a su destrucci=F3n. The information contained in this transmission is privileged and confidenti= al information intended only for the use of the individual or entity named = above. If the reader of this message is not the intended recipient, you are= hereby notified that any dissemination, distribution or copying of this co= mmunication is strictly prohibited. If you have received this transmission = in error, do not read it. Please immediately reply to the sender that you h= ave received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, div= ulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o pode estar proibida em virtude= da legisla=E7=E3o vigente. Se recebeu esta mensagem por erro, rogamos-lhe = que nos o comunique imediatamente por esta mesma via e proceda a sua destru= i=E7=E3o -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D http://people.tid.es/diego.lopez/ e-mail: diego.r.lopez@telefonica.com Tel: +34 913 129 041 Mobile: +34 682 051 091 ---------------------------------- ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o= copia sin autorizaci=F3n puede estar prohibida en virtud de la legislaci= =F3n vigente. Si ha recibido este mensaje por error, le rogamos que nos lo = comunique inmediatamente por esta misma v=EDa y proceda a su destrucci=F3n. The information contained in this transmission is privileged and confidenti= al information intended only for the use of the individual or entity named = above. If the reader of this message is not the intended recipient, you are= hereby notified that any dissemination, distribution or copying of this co= mmunication is strictly prohibited. If you have received this transmission = in error, do not read it. Please immediately reply to the sender that you h= ave received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, div= ulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o pode estar proibida em virtude= da legisla=E7=E3o vigente. Se recebeu esta mensagem por erro, rogamos-lhe = que nos o comunique imediatamente por esta mesma via e proceda a sua destru= i=E7=E3o -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D http://people.tid.es/diego.lopez/ e-mail: diego.r.lopez@telefonica.com Tel: +34 913 129 041 Mobile: +34 682 051 091 ---------------------------------- ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o= copia sin autorizaci=F3n puede estar prohibida en virtud de la legislaci= =F3n vigente. Si ha recibido este mensaje por error, le rogamos que nos lo = comunique inmediatamente por esta misma v=EDa y proceda a su destrucci=F3n. The information contained in this transmission is privileged and confidenti= al information intended only for the use of the individual or entity named = above. If the reader of this message is not the intended recipient, you are= hereby notified that any dissemination, distribution or copying of this co= mmunication is strictly prohibited. If you have received this transmission = in error, do not read it. Please immediately reply to the sender that you h= ave received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, div= ulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o pode estar proibida em virtude= da legisla=E7=E3o vigente. Se recebeu esta mensagem por erro, rogamos-lhe = que nos o comunique imediatamente por esta mesma via e proceda a sua destru= i=E7=E3o --_000_386D9D59920C4F22A783C41F3D25300Atelefonicacom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <1F1C5D98F506D34D9016651F8A99E7D2@eurprd06.prod.outlook.com> Content-Transfer-Encoding: quoted-printable Hi Linda,

Actually, SUPA application is described along 3.2.3, 3.2.4,= and 4.3. Appendix B is a deployment guide for the CogNet infrastructure, i= ncluding examples of the SUPA constructs used.

Be goode,

On 5 Jul 2017, at 23:07 , Linda Dunbar <linda.dunbar@huawei.com> wrote= :

Diego,
 
Thanks for the link.
 
Do you mean Section 3.2.2.3 using SUPA data mod= el to configure a policy?
 
=93supa-policy": {
=93supa-policy-validity-period=94: {
=93start=94: "2015-11-09T00:42:57.527404Z&= quot;
}
=93supa-policy-target=94: {
=93topicName": =93demoX=94,
=93domainName": =93systemX=94,
=93subNetwork=94: =93192.168.1.1=94,
=93instanceName=94: =93rack1=94=
}
=93supa-policy-statement=94: {<= /o:p>
=93event": {<= /div>
=93event-name=94: =93noisy-neighbor=94,
=93event-value-type=94: =93float=94,
=93event-value=94: =935.1=94
=93instanceName=94: =93compute0.vm3=94,
}
=93condition": {
=93condition-name=94: =93noisy-neighbor=94,
=93condition-operator=94: =93>=94,
=93condition-threshold=94: =935.0=94,
=93supa-script-content=94: {
=93script-Java=94: =93if (value > 5.0) retur= n TRUE=94
}
}
=93action": {=
=93action-name=94: =93noisy-neighbor=94,
=93action-type=94: =93migrate-vm=94
=93action-param1=94: {
=93param-type=94: =93entity=94<= /o:p>
=93param-value=94: =93compute2=94
=93instanceName=94: =93compute2=94
}
}
}
}
 
 
Thanks, Linda
 
 
From:&= nbsp;SUPA [mailto:supa-bounces@ietf.or= g] On Behalf Of Diego R. L= opez
Sent: W= ednesday, July 05, 2017 3:38 PM
To: Ben= oit Claise <bclaise@cisco.com>
Cc: Kin= g, Daniel <d.king@lancaster.ac.uk>= ; ops-ads@ietf.org; <= a href=3D"mailto:supa-chairs@ietf.org" style=3D"color: purple; text-decorat= ion: underline;" class=3D"">supa-chairs@ietf.org; SUPA list <supa@ietf.org>
Subject: Re: [Supa] SUPA Update
 
Hi Benoit, 
 
The most detailed discussion of the application of the SUPA data model can = be found in the CogNet deliverable D6.2, =93Integrated Platform and Perform= ance Reports. Release 1=94, which is a public document available at http:/= /www.cognet.5g-ppp.eu/wp-content/uploads/2017/05/CogNet_D62.pdf The discussion of how SUPA is used is fundamentally made in sections 3 and 4, = and appendix B. 
 
I was thinking about summarizing this to augment the applicability statemen= t, but I am afraid I have not found time for it yet=85
 
Be goode,
 
On 5 Jul 2017, at 15:39 , Benoit Claise <bclai= se@cisco.com> wrote:
 
Hi Diego,

Thanks for the discussion.
So you're applying the SUPA data model (draft-ietf-supa-generic-policy-da= ta-model-04)?
Can you please share how you reuse them and what's your experience?

Regards, Benoit
Hi Benoit, 
 
In the CogNet project (http://www.cognet.5g-p= pp.eu) we are applying the data models to express the policy rules (and= the events and actions) derived from the application of the so-called Smart Engine. We are discussing about fol= lowing a similar path in SHIELD (https://www.= shield-h2020.eu) to express security policies, and advocating for it in 5G-TRANSFORMER (http://5g-transformer.eu) when expressing rules for policy-based = management. The results of these projects are being or will be transferred to our operational practices, as well as = what is being defined in I2NSF, where SUPA seems the natural data model for= expressing policies to the Security Controller.
 
Is tis the kind of statement you were asking for?
 
Be goode,
 
On 22 Jun 2017, at 07:58 , Benoit Claise <bcla= ise@cisco.com> wrote:
 
Hi Diego,

Can you expand on the re-usability aspects.
What is being reused? the information model, the data model, something else= ? I hope more than the concepts.
What are you, yourself, reusing? = ;

Regards, Benoit
Hi Benoit, 
 
While I cannot talk for YANG module authors, and it is true that the WG has= a significant delay in its deliverables, I =91d like to stress that SUPA h= as produced reusable work that is being used elsewhere, and a closing of th= e group before it finishes its commitments would damage these other works. I am directly involved in the I2NSF WG (th= at is progressing quite well in my opinion), and in several collaborative E= uropean projects related with 5G and security, including a number of networ= k operators that are experimenting with SUPA-based policy statements. And I am aware of the ONUG interest as = well, though not being involved I cannot detail what they are targeting now= .
 
So I would ask you to reconsider the decision of closing SUPA at IETF 99.
 
Be goode,
 
On 15 Jun 2017, at 14:46 , Benoit Claise <bcla= ise@cisco.com> wrote:
 
Dear all,

After the last IETF, I put a calendar reminder on June 16th to decide on th= e next steps for SUPA.
This is inline with the our previous meeting minutes, so it should not come= as a surprise.
Granted, this is one day earlier than foreseen, but the IESG agenda coordin= ation call takes place today, and it was important from a scheduling point = of view to understand if SUPA would meet. The chairs informed me that no SU= PA meeting is required in Prague. That triggered this discussion, just one day earlier.

Our meeting minutes: https://www.i= etf.org/mail-archive/web/supa/current/msg01612.html
At the SUPA WG at IETF 98 (Tuesday, 28 March) we disc=
ussed the
progress of the WG.  Benoit (our AD) summed up t=
he situation, pointing
out that our drafts are not updated very frequently, =
and that the SUPA
mailing list has been very quiet between meetings.
 
At the meeting the authors of the SUPA Information mo=
del and the SUPA
Data Model drafts said that those drafts should be re=
ady for WG Last
Call by 1 June, so that they could be sent to IESG fo=
r approval by
about 1 July.
 
After summing up the pros and cons for SUPA continuin=
g, Benoit
concluded by saying that the WG will be closed at IET=
F 99 (Prague, 16
July) unless there is substantive progress on the Inf=
ormation Model
and especially on the Data Model drafts by one month =
before the Prague
meeting.  'Substantive progress' here means seei=
ng comments on and/or
reviews of these drafts demonstrating that people - o=
utside the small
group of authors - have carefully read the drafts, or=
 better, that they
are actually using SUPA's Information and Data Models=
.
I've been watching the list.
Since the last IETF meeting, we received two new drafts ...=
    draft-ietf-supa-generic-policy-info-model-03.txt
    draft-ietf-supa-generic-policy-data-model-03.txt
... and some draft reviews:
gunter.wang@ericsson.com on on draft-ietf-supa-policy-based-man= agement-framework:
Good feedback but it seems like only editorial to me.=
Tony tianxu@chinamobile.com=  on draft-cheng-supa-applicability:
Some editorial comments and three technical ones:
1.       I wonder the meaning of section 3, the part c= opied from framework draft, may not be needed.=
2.       I suggest to replace the title of 4.2.2.and 4= .2.3 with detailed information instead of writing just   Example 1 / 2= .
3.       The writer wrote =93We will define "edge= Interface" role and "EnterpriseDomain" later in  this n= ote=94 but I failed to find the explanation for these two term.
Benoit =3D> it's more like one technical comment, the last one.

Haining Wang: 18901341229@189.cn on draft-ietf-supa-generic-policy-data-model-03:

I understand that the GPIM YANG model provides an example of how to convert= IM to DM (for general policy), and John=92s SNMP blocking example (https://ma= ilarchive.ietf.org/arch/msg/supa/DWEzaSBK6KBdsmQ0FE2-eypTzeY) exposes some details. But I am sorry that the whole picture is still not c= lear to me. It would be nice if the ECA Data Model part can explain in more= details.

March Blanchet on draft-ietf-supa-policy-based-management-framework:
- larger comment: I=92m not sure what to do with this document. It looks li= ke a large wish list of features. I guess I=92m probably too used to implem= entation/protocol details. I guess I will wait until to see the actual prot= ocol/yang models.

Let's analyze the situation:
I don't consider those reviews (btw a single one the DM, none on the IM) as= "substantive progress".
I don't see interest from YANG module authors, ready to reuse the SUPA YANG= constructs. 
Being a year late according to the charter milestones, the window of opport= unity to produce reusable work has been closing rapidly.
I believe that SUPA had multiple chances to make it happen, and failed to d= eliver.
With this in mind, I don't see how I should conclude anything else than thi= s WG will be closing at IETF 99.

Regards, Benoit (OPS AD)

Dear supa=92rs,
 
We have cancelled our formal meeting in Prague. This decision was taken bas= ed on a proposed plan to focus effort on completing the existing WG items a= nd prepare for closure of the supa working group sometime between IETF 99 a= nd 100. A plan that is yet to be approved by Benoit.
 
During the last working group meeting Benoit stated:<= /div>
 
=93the WG will be closed at IETF 99 (Prague, 16 July) unless there is subst= antive progress on the Information Model and especially on the Data Model d= raft by one month before the Prague meeting.=94 
 
The authors of the Data Model and Information Model I-Ds did submit new ver= sions but we only received one review. However, Nevil and I are working wit= h the IM and DM authors to gather reviewers in preparation of Last Call. Es= sentially, we are working to prep folks who would be able to review the documents we Last Call, ideally thes= e should be from policy/yang implementers.
 
The Framework I-D has also received a review which is positive, and I am in= the process of reviewing the document myself to also help prepare the docu= ment for Last Call. Additionally, the Applicability I-D (a non-working grou= p document) received a review which is also useful.
 
We have also seen notifications from other SDOs following supa, specificall= y:
- ONUG: Investigating I2NSF combined with the SUPA data model and framework=
- ETSI Experiential Networked Intelligence (ENI): New initiative defining c= ontext aware networking systems, SUPA was identified as a key building bloc= k
- MEF Open Lifecycle Service Orchestrator (LSO): Using SUPA between functio= nal components
 
However, the indication from ONUG, ETSI and MEF does not materially change = the situation of SUPA but it does demonstrate wider interest in our work, a= nd at least some responsibility for supa/IETF to complete it (if possible).= If you are aware of near-term implementations now is the time to highlight them.
 
Again, we felt we did not need a WG meeting in Prague to progress the worki= ng group I-Ds, and given the IETF agenda coordination call (is today) we ha= d to cancel the supa WG session request ASAP, and unfortunately before we h= ad a chance to communicate the current situation to the rest of the working group. Apologies for any surprise whe= n you saw the cancellation notification, and the lack of opportunity for wi= der discussion.
 
As mentioned our proposed plan has been submitted to Benoit and is yet to b= e approved, therefore we will wait for his thoughts and ultimate decision.<= o:p class=3D"">
 
The SUPA Chairs would sincerely like to thank everyone for their participat= ion and especially the authors of I-Ds for their efforts.
 
BR, Nevil and Dan.
 
_______________________________________________
SUPA mailing list
SUPA@ietf.org
https://www.ietf.org/mailman/li= stinfo/supa
 
--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/
e-mail: diego.r.lopez@telefonica.com
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------
 
 

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o copia sin autorizaci=F3n puede e= star prohibida en virtud de la legislaci=F3n vigente. Si ha recibido este m= ensaje por error, le rogamos que nos lo comunique inmediatamente por esta m= isma v=EDa y proceda a su destrucci=F3n.

The information contained in this transmission is privileged and confidenti= al information intended only for the use of the individual or entity named = above. If the reader of this message is not the intended recipient, you are= hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If y= ou have received this transmission in error, do not read it. Please immedia= tely reply to the sender that you have received this communication in error= and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, divulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o p= ode estar proibida em virtude da legisla=E7=E3o vigente. Se recebeu esta me= nsagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mes= ma via e proceda a sua destrui=E7=E3o
 
 
--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/
e-mail: diego.r.lopez@telefonica.com
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------
 
 

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o copia sin autorizaci=F3n puede e= star prohibida en virtud de la legislaci=F3n vigente. Si ha recibido este m= ensaje por error, le rogamos que nos lo comunique inmediatamente por esta m= isma v=EDa y proceda a su destrucci=F3n.

The information contained in this transmission is privileged and confidenti= al information intended only for the use of the individual or entity named = above. If the reader of this message is not the intended recipient, you are= hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If y= ou have received this transmission in error, do not read it. Please immedia= tely reply to the sender that you have received this communication in error= and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, divulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o p= ode estar proibida em virtude da legisla=E7=E3o vigente. Se recebeu esta me= nsagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mes= ma via e proceda a sua destrui=E7=E3o
 
 
--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/
e-mail: diego.r.lopez@telefonica.com
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------
 
 

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o copia sin autorizaci=F3n puede e= star prohibida en virtud de la legislaci=F3n vigente. Si ha recibido este m= ensaje por error, le rogamos que nos lo comunique inmediatamente por esta m= isma v=EDa y proceda a su destrucci=F3n.

The information contained in this transmission is privileged and confidenti= al information intended only for the use of the individual or entity named = above. If the reader of this message is not the intended recipient, you are= hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If y= ou have received this transmission in error, do not read it. Please immedia= tely reply to the sender that you have received this communication in error= and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, divulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o p= ode estar proibida em virtude da legisla=E7=E3o vigente. Se recebeu esta me= nsagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mes= ma via e proceda a sua destrui=E7=E3o

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.= es/diego.lopez/

e-mail: diego.r.lopez@telefonica.com
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------



Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o copia sin autorizaci=F3n puede e= star prohibida en virtud de la legislaci=F3n vigente. Si ha recibido este m= ensaje por error, le rogamos que nos lo comunique inmediatamente por esta m= isma v=EDa y proceda a su destrucci=F3n.

The information contained in this transmission is privileged and confidenti= al information intended only for the use of the individual or entity named = above. If the reader of this message is not the intended recipient, you are= hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If y= ou have received this transmission in error, do not read it. Please immedia= tely reply to the sender that you have received this communication in error= and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, divulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o p= ode estar proibida em virtude da legisla=E7=E3o vigente. Se recebeu esta me= nsagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mes= ma via e proceda a sua destrui=E7=E3o
 --_000_386D9D59920C4F22A783C41F3D25300Atelefonicacom_-- From nobody Wed Jul 5 21:52:17 2017 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 995A5131450; Wed, 5 Jul 2017 21:52:16 -0700 (PDT) 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 TgAw0-sDOCMC; Wed, 5 Jul 2017 21:52:14 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 779E613013D; Wed, 5 Jul 2017 21:52:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 5FA1D1C04E0; Wed, 5 Jul 2017 21:52:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1499316734; bh=UqnqGQePWr9ux007gcLavURhR5L9J7vsP05cSURC+o0=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=cT+aLxnBQahRSmKUqQC1/GUecgte6UwY+qZA+wtBgO0ohLKUSvIPFlhrRjE0b6Ne4 Ma618EBilgDVskE2PN9iYKlRJgcruDt+8H2MYiWcl9Osas1NVRVhpvhtpHR+mx/MGw egfBWU/c1ZDidmreep3m+HP0DMxeuhbmG/1AcZL4= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [50.225.209.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 12F301C02FE; Wed, 5 Jul 2017 21:52:11 -0700 (PDT) To: youlizhao , SUPA list , Benoit Claise Cc: "King, Daniel" , "ops-ads@ietf.org" , "supa-chairs@ietf.org" References: <65174429B5AF4C45BD0798810EC48E0A942C73B2@EX-0-MB2.lancs.local> <666784c3-d4df-9fa1-9661-d8e182e2c7da@cisco.com> <7AD05E972D7A0F47B3368775A9FF85FC9E54C3@DGGEMM505-MBX.china.huawei.com> <7AD05E972D7A0F47B3368775A9FF85FC9E8F59@DGGEMM505-MBX.china.huawei.com> From: "Joel M. Halpern" Message-ID: Date: Thu, 6 Jul 2017 00:52:11 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <7AD05E972D7A0F47B3368775A9FF85FC9E8F59@DGGEMM505-MBX.china.huawei.com> Content-Type: text/plain; charset=gbk; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Supa] SUPA Update X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.22 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: Thu, 06 Jul 2017 04:52:17 -0000 I have not reviewed the Chen draft until now. A brief review shows that it does not follow the patterns or approach defined in the IETF SUPA Information Model and the correspnding generic data model. This matters as those models use exactly the strong separation you ask for. Yours, Joel On 7/5/17 10:39 PM, youlizhao wrote: > Dear All, > > Below are my thought on ECA DM based on the materials I read and the > project I am doing. Any comments would be welcome. > > The discussions are based on an ECA Policy DM draft [eca-data-model]. > According to our understanding, it is aligned with the ECA Policy IM > [eca-info-model]. > > We appreciate that the draft [draft-chen-supa-eca-data-model-05] > provides the entity/script abstraction that allows extension for > different scenarios, and they match our implementation. In particular, > our ECA policy parser can read entity fields (or script fields), and map > them to the CLI command parameters (or script implementation). > > However, we found that the current definition still makes DM parsing > complicate. Note that, in [draft-chen-supa-eca-data-model-05], the > condition-list clause may still involve with network details (e.g., > bandwidth and threshold in the service-flow example), and the > action-list clause may still contain the decision logic (i.e., when the > bandwidth exceeds a threshold) to trigger an action. To extract the > ¡°real¡± condition, our policy parser needs to understand the action-list > clause, and then generate the ¡°condition¡± logic in real implementation. > > To make things more complicate, sometimes we need to judge several > conditions to trigger an action (e.g., in Cisco EEM [CiscoEEM, Pages 69, > 342, 368] and some SD-WAN examples in Huawei SD-WAN solution > [Huawei-SD-WAN]). In addition, some constraints may be added, e.g., the > conjunctive-type duration that indicates how long the conjunctive > relationship should hold. However, the current model is weak on > expressing the capability (although conjunctive-type is defined in > [eca-data-model], how to use it is not clear). > > Based on the above arguments, we would like to suggest the following > changes: > > (a) A clear separation of events, conditions, and actions is welcome so > that our parser can just care different parts and directly map them to > implementation; > > (b) The condition clause can be enriched to express the > conjunctive-type, conjunctive-duration, and other possible fields. > > Thanks! > > Regards, > > Leo > > [eca-info-model] Generic Policy Information Model for SUPA > > https://tools.ietf.org/html/draft-strassner-supa-generic-policy-info-model-05 > > > [eca-data-model] ECA Policy YANG Data Model > > https://tools.ietf.org/html/draft-chen-supa-eca-data-model-05 > > [Cisco-EEM] Embedded Event Manager Configuration Guide, > > http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/eem/configuration/12-2sx/eem-12-2sx-book.pdf > > [Huawei-SD-WAN] Huawei SD-WAN Solution Brochure > > http://e.huawei.com/en/solutions/technical/sdn/enterprise-wan/sd-wan > > *From:*SUPA [mailto:supa-bounces@ietf.org] *On Behalf Of *youlizhao > *Sent:* 2017Äê6ÔÂ20ÈÕ15:38 > *To:* Benoit Claise ; King, Daniel > > *Cc:* ops-ads@ietf.org; supa-chairs@ietf.org; SUPA list > *Subject:* Re: [Supa] SUPA Update > > Dear Benoit AD, > > Thanks for pushing and monitoring the SUPA WG progress. > > I am sorry to see the email below. I am an engineer in Huawei, and > recently we have been developing the code of SUPA ECA policy to control > the network. In particular, we provide restful interface to users for > configuring ECA policies following the ECA DM. > > To be honest, IMO, the ECA IM and DM are not mature enough for direct > implementation. We are revising some parts facilitating the implementation. > > Although the SUPA IM and DM still contain flaws, we hoped to see them > completed (also other documents, e.g., SUPA framework) so that we can > complete our own implementations based on SUPA standard work. > > Thanks for your consideration. > > Regards, > > Leo > > *From:*SUPA [mailto:supa-bounces@ietf.org] *On Behalf Of *Benoit Claise > *Sent:* 2017Äê6ÔÂ15ÈÕ20:47 > *To:* King, Daniel >; SUPA list > > *Cc:* ops-ads@ietf.org ; supa-chairs@ietf.org > > *Subject:* Re: [Supa] SUPA Update > > Dear all, > > After the last IETF, I put a calendar reminder on June 16th to decide on > the next steps for SUPA. > This is inline with the our previous meeting minutes, so it should not > come as a surprise. > Granted, this is one day earlier than foreseen, but the IESG agenda > coordination call takes place today, and it was important from a > scheduling point of view to understand if SUPA would meet. The chairs > informed me that no SUPA meeting is required in Prague. That triggered > this discussion, just one day earlier. > > Our meeting minutes: > https://www.ietf.org/mail-archive/web/supa/current/msg01612.html > > At the SUPA WG at IETF 98 (Tuesday, 28 March) we discussed the > > progress of the WG. Benoit (our AD) summed up the situation, pointing > > out that our drafts are not updated very frequently, and that the SUPA > > mailing list has been very quiet between meetings. > > At the meeting the authors of the SUPA Information model and the SUPA > > Data Model drafts said that those drafts should be ready for WG Last > > Call by 1 June, so that they could be sent to IESG for approval by > > about 1 July. > > After summing up the pros and cons for SUPA continuing, Benoit > > concluded by saying that the WG will be closed at IETF 99 (Prague, 16 > > July) unless there is substantive progress on the Information Model > > and especially on the Data Model drafts by one month before the Prague > > meeting. 'Substantive progress' here means seeing comments on and/or > > reviews of these drafts demonstrating that people - outside the small > > group of authors - have carefully read the drafts, or better, that they > > are actually using SUPA's Information and Data Models. > > I've been watching the list. > > Since the last IETF meeting, we received two new drafts ... > > draft-ietf-supa-generic-policy-info-model-03.txt > draft-ietf-supa-generic-policy-data-model-03.txt > > ... and some draft reviews: > > gunter.wang@ericsson.com on on > draft-ietf-supa-policy-based-management-framework: > > Good feedback but it seems like only editorial to me. > > Tony tianxu@chinamobile.com on > draft-cheng-supa-applicability: > > Some editorial comments and three technical ones: > > 1. I wonder the meaning of section 3, the part copied > from framework draft, may not be needed. > > 2. I suggest to replace the title of 4.2.2.and 4.2.3 > with detailed information instead of writing just Example > 1 / 2. > > 3. The writer wrote ¡°We will define "edgeInterface" > role and "EnterpriseDomain" later in this note¡± but I > failed to find the explanation for these two term. > > Benoit => it's more like one technical comment, the last one. > > > Haining Wang: 18901341229@189.cn on > draft-ietf-supa-generic-policy-data-model-03: > > I understand that the GPIM YANG model provides an example of > how to convert IM to DM (for general policy), and John¡¯s > SNMP blocking example > (https://mailarchive.ietf.org/arch/msg/supa/DWEzaSBK6KBdsmQ0FE2-eypTzeY) > exposes some details. But I am sorry that the whole picture > is still not clear to me. It would be nice if the ECA Data > Model part can explain in more details. > > March Blanchet on draft-ietf-supa-policy-based-management-framework: > > - larger comment: I¡¯m not sure what to do with this > document. It looks like a large wish list of features. I > guess I¡¯m probably too used to implementation/protocol > details. I guess I will wait until to see the actual > protocol/yang models. > > > Let's analyze the situation: > I don't consider those reviews (btw a single one the DM, none on the IM) > as "substantive progress". > I don't see interest from YANG module authors, ready to reuse the SUPA > YANG constructs. > Being a year late according to the charter milestones, the window of > opportunity to produce reusable work has been closing rapidly. > I believe that SUPA had multiple chances to make it happen, and failed > to deliver. > With this in mind, I don't see how I should conclude anything else than > this WG will be closing at IETF 99. > > Regards, Benoit (OPS AD) > > Dear supa¡¯rs, > > We have cancelled our formal meeting in Prague. This decision was > taken based on a proposed plan to focus effort on completing the > existing WG items and prepare for closure of the supa working group > sometime between IETF 99 and 100. A plan that is yet to be approved > by Benoit. > > During the last working group meeting Benoit stated: > > ¡°the WG will be closed at IETF 99 (Prague, 16 July) unless there is > substantive progress on the Information Model and especially on the > Data Model draft by one month before the Prague meeting.¡± > > The authors of the Data Model and Information Model I-Ds did submit > new versions but we only received one review. However, Nevil and I > are working with the IM and DM authors to gather reviewers in > preparation of Last Call. Essentially, we are working to prep folks > who would be able to review the documents we Last Call, ideally > these should be from policy/yang implementers. > > The Framework I-D has also received a review which is positive, and > I am in the process of reviewing the document myself to also help > prepare the document for Last Call. Additionally, the Applicability > I-D (a non-working group document) received a review which is also > useful. > > We have also seen notifications from other SDOs following supa, > specifically: > > - ONUG: Investigating I2NSF combined with the SUPA data model and > framework > > - ETSI Experiential Networked Intelligence (ENI): New initiative > defining context aware networking systems, SUPA was identified as a > key building block > > - MEF Open Lifecycle Service Orchestrator (LSO): Using SUPA between > functional components > > However, the indication from ONUG, ETSI and MEF does not materially > change the situation of SUPA but it does demonstrate wider interest > in our work, and at least some responsibility for supa/IETF to > complete it (if possible). If you are aware of near-term > implementations now is the time to highlight them. > > Again, we felt we did not need a WG meeting in Prague to progress > the working group I-Ds, and given the IETF agenda coordination call > (is today) we had to cancel the supa WG session request ASAP, and > unfortunately before we had a chance to communicate the current > situation to the rest of the working group. Apologies for any > surprise when you saw the cancellation notification, and the lack of > opportunity for wider discussion. > > As mentioned our proposed plan has been submitted to Benoit and is > yet to be approved, therefore we will wait for his thoughts and > ultimate decision. > > The SUPA Chairs would sincerely like to thank everyone for their > participation and especially the authors of I-Ds for their efforts. > > BR, Nevil and Dan. > > > > _______________________________________________ > SUPA mailing list > SUPA@ietf.org > https://www.ietf.org/mailman/listinfo/supa > From nobody Wed Jul 5 21:54:43 2017 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 B64D7131450; Wed, 5 Jul 2017 21:54:41 -0700 (PDT) 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 frVc_O4dxDWG; Wed, 5 Jul 2017 21:54:38 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 D326513013D; Wed, 5 Jul 2017 21:54:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id BF6781C04E0; Wed, 5 Jul 2017 21:54:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1499316878; bh=I6TWXnCeRhOsb1iLknpHiJFs1qH+Bfo8E7olihGb+ig=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=kJuxqA+ah3VOffLc92Z4FrPoxdaPYgV9dPquILuBzqnRg97Cif4mpbVY04XPuQvng qH1FJ5Coqd1kuJPvPj7tv5yNvC3HqVBI+fTPJufF9Jn7pkgnf+RtL5J8H3na+s6z1C +EZxcUdwwov3iwddPujYEyc2pup/UNhlFkkDjKGE= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [50.225.209.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id CCF7D1C02FE; Wed, 5 Jul 2017 21:54:37 -0700 (PDT) To: youlizhao , SUPA list , Benoit Claise Cc: "King, Daniel" , "ops-ads@ietf.org" , "supa-chairs@ietf.org" References: <65174429B5AF4C45BD0798810EC48E0A942C73B2@EX-0-MB2.lancs.local> <666784c3-d4df-9fa1-9661-d8e182e2c7da@cisco.com> <7AD05E972D7A0F47B3368775A9FF85FC9E54C3@DGGEMM505-MBX.china.huawei.com> <7AD05E972D7A0F47B3368775A9FF85FC9E8F59@DGGEMM505-MBX.china.huawei.com> From: "Joel M. Halpern" Message-ID: <375d88aa-d1d5-b89a-6a0b-ec2c4afff05c@joelhalpern.com> Date: Thu, 6 Jul 2017 00:54:36 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=gbk; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Supa] SUPA Update X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.22 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: Thu, 06 Jul 2017 04:54:42 -0000 I just noticed that the Chen draft is long expired. So it is not the authors' fault that it does not follow the strong separation approach that the SUPA WG is now using. (My apologies to the authors if my note implied any fault by them.) yours, Joel On 7/6/17 12:52 AM, Joel M. Halpern wrote: > I have not reviewed the Chen draft until now. > A brief review shows that it does not follow the patterns or approach > defined in the IETF SUPA Information Model and the correspnding generic > data model. > > This matters as those models use exactly the strong separation you ask for. > > Yours, > Joel > > On 7/5/17 10:39 PM, youlizhao wrote: >> Dear All, >> >> Below are my thought on ECA DM based on the materials I read and the >> project I am doing. Any comments would be welcome. >> >> The discussions are based on an ECA Policy DM draft [eca-data-model]. >> According to our understanding, it is aligned with the ECA Policy IM >> [eca-info-model]. >> >> We appreciate that the draft [draft-chen-supa-eca-data-model-05] >> provides the entity/script abstraction that allows extension for >> different scenarios, and they match our implementation. In particular, >> our ECA policy parser can read entity fields (or script fields), and >> map them to the CLI command parameters (or script implementation). >> >> However, we found that the current definition still makes DM parsing >> complicate. Note that, in [draft-chen-supa-eca-data-model-05], the >> condition-list clause may still involve with network details (e.g., >> bandwidth and threshold in the service-flow example), and the >> action-list clause may still contain the decision logic (i.e., when >> the bandwidth exceeds a threshold) to trigger an action. To extract >> the ¡°real¡± condition, our policy parser needs to understand the >> action-list clause, and then generate the ¡°condition¡± logic in real >> implementation. >> >> To make things more complicate, sometimes we need to judge several >> conditions to trigger an action (e.g., in Cisco EEM [CiscoEEM, Pages >> 69, 342, 368] and some SD-WAN examples in Huawei SD-WAN solution >> [Huawei-SD-WAN]). In addition, some constraints may be added, e.g., >> the conjunctive-type duration that indicates how long the conjunctive >> relationship should hold. However, the current model is weak on >> expressing the capability (although conjunctive-type is defined in >> [eca-data-model], how to use it is not clear). >> >> Based on the above arguments, we would like to suggest the following >> changes: >> >> (a) A clear separation of events, conditions, and actions is welcome >> so that our parser can just care different parts and directly map them >> to implementation; >> >> (b) The condition clause can be enriched to express the >> conjunctive-type, conjunctive-duration, and other possible fields. >> >> Thanks! >> >> Regards, >> >> Leo >> >> [eca-info-model] Generic Policy Information Model for SUPA >> >> https://tools.ietf.org/html/draft-strassner-supa-generic-policy-info-model-05 >> >> >> [eca-data-model] ECA Policy YANG Data Model >> >> https://tools.ietf.org/html/draft-chen-supa-eca-data-model-05 >> >> [Cisco-EEM] Embedded Event Manager Configuration Guide, >> >> http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/eem/configuration/12-2sx/eem-12-2sx-book.pdf >> >> >> [Huawei-SD-WAN] Huawei SD-WAN Solution Brochure >> >> http://e.huawei.com/en/solutions/technical/sdn/enterprise-wan/sd-wan >> >> *From:*SUPA [mailto:supa-bounces@ietf.org] *On Behalf Of *youlizhao >> *Sent:* 2017Äê6ÔÂ20ÈÕ15:38 >> *To:* Benoit Claise ; King, Daniel >> >> *Cc:* ops-ads@ietf.org; supa-chairs@ietf.org; SUPA list >> *Subject:* Re: [Supa] SUPA Update >> >> Dear Benoit AD, >> >> Thanks for pushing and monitoring the SUPA WG progress. >> >> I am sorry to see the email below. I am an engineer in Huawei, and >> recently we have been developing the code of SUPA ECA policy to >> control the network. In particular, we provide restful interface to >> users for configuring ECA policies following the ECA DM. >> >> To be honest, IMO, the ECA IM and DM are not mature enough for direct >> implementation. We are revising some parts facilitating the >> implementation. >> >> Although the SUPA IM and DM still contain flaws, we hoped to see them >> completed (also other documents, e.g., SUPA framework) so that we can >> complete our own implementations based on SUPA standard work. >> >> Thanks for your consideration. >> >> Regards, >> >> Leo >> >> *From:*SUPA [mailto:supa-bounces@ietf.org] *On Behalf Of *Benoit Claise >> *Sent:* 2017Äê6ÔÂ15ÈÕ20:47 >> *To:* King, Daniel > >; SUPA list > > >> *Cc:* ops-ads@ietf.org ; supa-chairs@ietf.org >> >> *Subject:* Re: [Supa] SUPA Update >> >> Dear all, >> >> After the last IETF, I put a calendar reminder on June 16th to decide >> on the next steps for SUPA. >> This is inline with the our previous meeting minutes, so it should not >> come as a surprise. >> Granted, this is one day earlier than foreseen, but the IESG agenda >> coordination call takes place today, and it was important from a >> scheduling point of view to understand if SUPA would meet. The chairs >> informed me that no SUPA meeting is required in Prague. That triggered >> this discussion, just one day earlier. >> >> Our meeting minutes: >> https://www.ietf.org/mail-archive/web/supa/current/msg01612.html >> >> At the SUPA WG at IETF 98 (Tuesday, 28 March) we discussed the >> >> progress of the WG. Benoit (our AD) summed up the situation, >> pointing >> >> out that our drafts are not updated very frequently, and that the >> SUPA >> >> mailing list has been very quiet between meetings. >> >> At the meeting the authors of the SUPA Information model and the SUPA >> >> Data Model drafts said that those drafts should be ready for WG Last >> >> Call by 1 June, so that they could be sent to IESG for approval by >> >> about 1 July. >> >> After summing up the pros and cons for SUPA continuing, Benoit >> >> concluded by saying that the WG will be closed at IETF 99 (Prague, 16 >> >> July) unless there is substantive progress on the Information Model >> >> and especially on the Data Model drafts by one month before the >> Prague >> >> meeting. 'Substantive progress' here means seeing comments on and/or >> >> reviews of these drafts demonstrating that people - outside the small >> >> group of authors - have carefully read the drafts, or better, that >> they >> >> are actually using SUPA's Information and Data Models. >> >> I've been watching the list. >> >> Since the last IETF meeting, we received two new drafts ... >> >> draft-ietf-supa-generic-policy-info-model-03.txt >> draft-ietf-supa-generic-policy-data-model-03.txt >> >> ... and some draft reviews: >> >> gunter.wang@ericsson.com on on >> draft-ietf-supa-policy-based-management-framework: >> >> Good feedback but it seems like only editorial to me. >> >> Tony tianxu@chinamobile.com on >> draft-cheng-supa-applicability: >> >> Some editorial comments and three technical ones: >> >> 1. I wonder the meaning of section 3, the part copied >> from framework draft, may not be needed. >> >> 2. I suggest to replace the title of 4.2.2.and 4.2.3 >> with detailed information instead of writing just Example >> 1 / 2. >> >> 3. The writer wrote ¡°We will define "edgeInterface" >> role and "EnterpriseDomain" later in this note¡± but I >> failed to find the explanation for these two term. >> >> Benoit => it's more like one technical comment, the last one. >> >> >> Haining Wang: 18901341229@189.cn on >> draft-ietf-supa-generic-policy-data-model-03: >> >> I understand that the GPIM YANG model provides an example of >> how to convert IM to DM (for general policy), and John¡¯s >> SNMP blocking example >> >> (https://mailarchive.ietf.org/arch/msg/supa/DWEzaSBK6KBdsmQ0FE2-eypTzeY) >> exposes some details. But I am sorry that the whole picture >> is still not clear to me. It would be nice if the ECA Data >> Model part can explain in more details. >> >> March Blanchet on >> draft-ietf-supa-policy-based-management-framework: >> >> - larger comment: I¡¯m not sure what to do with this >> document. It looks like a large wish list of features. I >> guess I¡¯m probably too used to implementation/protocol >> details. I guess I will wait until to see the actual >> protocol/yang models. >> >> >> Let's analyze the situation: >> I don't consider those reviews (btw a single one the DM, none on the >> IM) as "substantive progress". >> I don't see interest from YANG module authors, ready to reuse the SUPA >> YANG constructs. >> Being a year late according to the charter milestones, the window of >> opportunity to produce reusable work has been closing rapidly. >> I believe that SUPA had multiple chances to make it happen, and failed >> to deliver. >> With this in mind, I don't see how I should conclude anything else >> than this WG will be closing at IETF 99. >> >> Regards, Benoit (OPS AD) >> >> Dear supa¡¯rs, >> >> We have cancelled our formal meeting in Prague. This decision was >> taken based on a proposed plan to focus effort on completing the >> existing WG items and prepare for closure of the supa working group >> sometime between IETF 99 and 100. A plan that is yet to be approved >> by Benoit. >> >> During the last working group meeting Benoit stated: >> >> ¡°the WG will be closed at IETF 99 (Prague, 16 July) unless there is >> substantive progress on the Information Model and especially on the >> Data Model draft by one month before the Prague meeting.¡± >> >> The authors of the Data Model and Information Model I-Ds did submit >> new versions but we only received one review. However, Nevil and I >> are working with the IM and DM authors to gather reviewers in >> preparation of Last Call. Essentially, we are working to prep folks >> who would be able to review the documents we Last Call, ideally >> these should be from policy/yang implementers. >> >> The Framework I-D has also received a review which is positive, and >> I am in the process of reviewing the document myself to also help >> prepare the document for Last Call. Additionally, the Applicability >> I-D (a non-working group document) received a review which is also >> useful. >> >> We have also seen notifications from other SDOs following supa, >> specifically: >> >> - ONUG: Investigating I2NSF combined with the SUPA data model and >> framework >> >> - ETSI Experiential Networked Intelligence (ENI): New initiative >> defining context aware networking systems, SUPA was identified as a >> key building block >> >> - MEF Open Lifecycle Service Orchestrator (LSO): Using SUPA between >> functional components >> >> However, the indication from ONUG, ETSI and MEF does not materially >> change the situation of SUPA but it does demonstrate wider interest >> in our work, and at least some responsibility for supa/IETF to >> complete it (if possible). If you are aware of near-term >> implementations now is the time to highlight them. >> >> Again, we felt we did not need a WG meeting in Prague to progress >> the working group I-Ds, and given the IETF agenda coordination call >> (is today) we had to cancel the supa WG session request ASAP, and >> unfortunately before we had a chance to communicate the current >> situation to the rest of the working group. Apologies for any >> surprise when you saw the cancellation notification, and the lack of >> opportunity for wider discussion. >> >> As mentioned our proposed plan has been submitted to Benoit and is >> yet to be approved, therefore we will wait for his thoughts and >> ultimate decision. >> >> The SUPA Chairs would sincerely like to thank everyone for their >> participation and especially the authors of I-Ds for their efforts. >> >> BR, Nevil and Dan. >> >> >> >> _______________________________________________ >> SUPA mailing list >> SUPA@ietf.org >> https://www.ietf.org/mailman/listinfo/supa >> From nobody Sun Jul 9 02:58:49 2017 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 E0050128961 for ; Sun, 9 Jul 2017 02:58:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, HTML_NONELEMENT_30_40=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 o_HT-hXhGdaT for ; Sun, 9 Jul 2017 02:58:46 -0700 (PDT) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20B8C1276AF for ; Sun, 9 Jul 2017 02:58:46 -0700 (PDT) Received: by mail-oi0-x22d.google.com with SMTP id p188so55637682oia.0 for ; Sun, 09 Jul 2017 02:58:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=aL0AmnnjJGaIuhJzTD5q3Yvl23eS5uXXkfuPhiw9duc=; b=i5/3b1q2ySF0W9S4cSmFuov/BZ68q1to94VeocfGzRgSkPW6FerW+plUmc/zYT4Ew/ BCnwN6WTE3MWFGXCaHmo2mEewgFe/3iGD5PEEiBtU5SpYlffgomFXgj201zVhmpZGBmT Ocp0nynVecKduPkGW5o4UnpMH4gurxdHM8uQvZkdKNgJ3jdolPEl6Q6nQcNLsIf/JnsU Xr+atA+xZp8ic5nsoy0pQNBvlPCGElyIZ3Rxif9K+FvBvGSOxzqBNGVjP2Q2YqrGSHlI SfFa29qlulVE9UbZlJYTLD2IK6PO77hT4lxZurmEqUNfP3PF6AAd1ZgwDxtDxFMs6TCG ma9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=aL0AmnnjJGaIuhJzTD5q3Yvl23eS5uXXkfuPhiw9duc=; b=eA+liWB4FgZH5T5ue/+A7m9TCM0LqUMWhjnXIQ781YCq1jAlgo+cr9IF59QRNAp/5H J9Nv1bpSd2ol23PYHcy6PEjPtLD5Tr9NOY3GQorQGYdPbQAFcwyT19XzaMaGkbcKNrev gmaVfxR4qcfEhi/1ekyYnwvc7HRqbkgLFKkZL+pQ4TAz/8MRPnfIAGY/97K4jO2sxhHw 4wT10ziJ5QrEeATeOg25KgS8v6fmjO3+ilT9N5QjxqkYLUq1Nm8NlH7bG8UFKJkWSVak pWW7OAOaDEZSWxJsw+VrFyf+JvXHSPNFU5iPn8JMa8Vt7+yhxCEwWVBTzRQKQ/n/EBSb /yiw== X-Gm-Message-State: AIVw111oETXtPCNd3ilKP1xn3EuUKU38wTMU5ZG9YOFylbxVpEE6gMsC y7AJoeC80nQAmY5R0/oilZvQqazQ2DPq X-Received: by 10.202.1.209 with SMTP id 200mr6085599oib.110.1499594325390; Sun, 09 Jul 2017 02:58:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.161.19 with HTTP; Sun, 9 Jul 2017 02:58:44 -0700 (PDT) From: Yangyang Wang Date: Sun, 9 Jul 2017 17:58:44 +0800 Message-ID: To: supa@ietf.org Cc: liushucheng@huawei.com, Jun Bi Content-Type: multipart/alternative; boundary="001a1137be78127b030553df83b6" Archived-At: Subject: [Supa] review for draft-ietf-supa-policy-based-management-framework-02 X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.22 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: Sun, 09 Jul 2017 09:58:48 -0000 --001a1137be78127b030553df83b6 Content-Type: text/plain; charset="UTF-8" I have reviewed draft-ietf-supa-policy-based-management-framework. My comments are as follows: 1) This draft contains many concepts that are very abstract. I suggest this draft may briefly describe the contents and the goal of this draft and its significance. Some simple and concrete instances can be added in the descriptions of the management framework to help clarify the abstract concepts and framework in this draft. 2) "Traffic flow over increasingly complex enterprise and service provider network becomes more and more important" may be change to "The management of Traffic flow over increasingly complex enterprise and service provider network becomes more and more important ? 3) "OSS:Operations/Operational Support System, are computer systems" should be "OSS: Operations/Operational Support Systems, are computer systems". 4) "Imperative policy rules require additional management functions, which are explained in section 2.2 below" may be "Imperative policy rules require additional management functions, which are explained in section 3.2 below" 5) "(1:1..n) in (1) and (2) below figure 3 shows one policy rule is able to manages and can adjust one or multiple services/resources." may be "(1:1..n) in (1) and (2) below figure 3 show one policy rule is able to manage and adjust one or multiple services/resources." ? 6) "The Operator actor shown can interact with SUPA in other ways not shown in Figure 1" may be "The Operator actor, shown in figure 1, can interact with SUPA in other ways not shown in Figure 1" Best regards, Yangyang --001a1137be78127b030553df83b6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I have reviewed=C2=A0=C2=A0draft-ietf-supa-policy-bas= ed-management-framework. My comments are as follows:

1) This draft contains many concepts that are very abstract. I suggest th= is draft may briefly describe the contents and the goal =C2=A0of this draft= and its significance. Some simple and concrete instances can be added in t= he descriptions of the management framework to help clarify the abstract co= ncepts and framework in this draft.

2) "Traff= ic flow over increasingly complex enterprise and service provider network b= ecomes more and more important" may be change to "The management = of Traffic flow over increasingly complex enterprise and service provider n= etwork becomes more and more important ?

3) "= OSS:Operations/Operational Support System, are computer systems" shoul= d be "OSS: Operations/Operational Support Systems, are computer system= s".

4) "Imperative policy rules require = additional=C2=A0management functions, which are explained in section 2.2 be= low" may be =C2=A0"Imperative policy rules require additional=C2= =A0management functions, which are explained in section 3.2 below"

5) "(1:1..n) in (1)=C2=A0and (2) below figure 3 = shows one policy rule is able to manages and=C2=A0can adjust one or multipl= e services/resources." may be "(1:1..n) in (1)=C2=A0and (2) below= figure 3 show one policy rule is able to manage and adjust one or multiple= services/resources." ?

6) "The Operator= actor shown can interact with=C2=A0SUPA in other ways not shown in Figure = 1" may be "The Operator actor, shown in figure 1, can interact wi= th=C2=A0SUPA in other ways not shown in Figure 1"

=



Best regards,
<= div>Yangyang

--001a1137be78127b030553df83b6-- From nobody Tue Jul 11 02:23:32 2017 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 C5D421272E1; Tue, 11 Jul 2017 02:23:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 5ZRciwhLJ8e5; Tue, 11 Jul 2017 02:23:27 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FB881296C9; Tue, 11 Jul 2017 02:23:26 -0700 (PDT) Received: from 172.18.7.190 (EHLO LHREML714-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DQW57592; Tue, 11 Jul 2017 09:23:24 +0000 (GMT) Received: from DGGEMM405-HUB.china.huawei.com (10.3.20.213) by LHREML714-CAH.china.huawei.com (10.201.108.37) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 11 Jul 2017 10:23:23 +0100 Received: from DGGEMM505-MBS.china.huawei.com ([169.254.2.93]) by DGGEMM405-HUB.china.huawei.com ([10.3.20.213]) with mapi id 14.03.0301.000; Tue, 11 Jul 2017 17:23:14 +0800 From: youlizhao To: "Joel M. Halpern" CC: "King, Daniel" , "ops-ads@ietf.org" , "supa-chairs@ietf.org" , SUPA list , Benoit Claise Thread-Topic: [Supa] SUPA Update Thread-Index: AdLlx7FI0gJYsnA1SY+UuT+jZNMvmv//lVMA//f1DaD/1xjTUIBRbo+AgAAArQD/91UuUA== Date: Tue, 11 Jul 2017 09:23:13 +0000 Message-ID: <7AD05E972D7A0F47B3368775A9FF85FC9EF68F@DGGEMM505-MBS.china.huawei.com> References: <65174429B5AF4C45BD0798810EC48E0A942C73B2@EX-0-MB2.lancs.local> <666784c3-d4df-9fa1-9661-d8e182e2c7da@cisco.com> <7AD05E972D7A0F47B3368775A9FF85FC9E54C3@DGGEMM505-MBX.china.huawei.com> <7AD05E972D7A0F47B3368775A9FF85FC9E8F59@DGGEMM505-MBX.china.huawei.com> <375d88aa-d1d5-b89a-6a0b-ec2c4afff05c@joelhalpern.com> In-Reply-To: <375d88aa-d1d5-b89a-6a0b-ec2c4afff05c@joelhalpern.com> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.63.185.181] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.5964990D.0029, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.2.93, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 0c41c3032265ace0f7de60d339e3cc59 Archived-At: Subject: Re: [Supa] SUPA Update X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.22 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: Tue, 11 Jul 2017 09:23:31 -0000 SGkgSm9lbCwNCg0KVGhhbmtzIGZvciB5b3VyIHJlcGx5LiBJIHdpbGwgdGFrZSBhIGxvb2sgYXQg dGhlIFNVUEEgSU0gYW5kIGdlbmVyaWMgRE0uDQpXb3VsZCB5b3UgbWluZCBhZHZpc2luZyBtZSB3 aGljaCBwYXJ0cyBjb3JyZXNwb25kIHRvIHRoZSBzZXBhcmF0aW9uPyBNYW55IHRoYW5rcyEgDQoN Cg0KUmVnYXJkcywNCkxlbw0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQpMaXpoYW8gKExlbykgWW91LCBQaEQNClNlbmlvciBSZXNlYXJjaCBFbmdpbmVlcg0KSHVhd2Vp IFRlY2hub2xvZ2llcyBDby4sTHRkDQp5b3VsaXpoYW9AaHVhd2VpLmNvbQ0KVGVsOiArODYtMTMw NC05NDItNzQ4Nw0Kd3d3LmxpbmtlZGluLmNvbS9pbi9saXpoYW8teW91DQotLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpG cm9tOiBKb2VsIE0uIEhhbHBlcm4gW21haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tXSANClNlbnQ6 IDIwMTfE6jfUwjbI1SAxMjo1NQ0KVG86IHlvdWxpemhhbyA8eW91bGl6aGFvQGh1YXdlaS5jb20+ OyBTVVBBIGxpc3QgPHN1cGFAaWV0Zi5vcmc+OyBCZW5vaXQgQ2xhaXNlIDxiY2xhaXNlQGNpc2Nv LmNvbT4NCkNjOiBLaW5nLCBEYW5pZWwgPGQua2luZ0BsYW5jYXN0ZXIuYWMudWs+OyBvcHMtYWRz QGlldGYub3JnOyBzdXBhLWNoYWlyc0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtTdXBhXSBTVVBB IFVwZGF0ZQ0KDQpJIGp1c3Qgbm90aWNlZCB0aGF0IHRoZSBDaGVuIGRyYWZ0IGlzIGxvbmcgZXhw aXJlZC4gIFNvIGl0IGlzIG5vdCB0aGUgYXV0aG9ycycgZmF1bHQgdGhhdCBpdCBkb2VzIG5vdCBm b2xsb3cgdGhlIHN0cm9uZyBzZXBhcmF0aW9uIGFwcHJvYWNoIHRoYXQgdGhlIFNVUEEgV0cgaXMg bm93IHVzaW5nLg0KKE15IGFwb2xvZ2llcyB0byB0aGUgYXV0aG9ycyBpZiBteSBub3RlIGltcGxp ZWQgYW55IGZhdWx0IGJ5IHRoZW0uKQ0KDQp5b3VycywNCkpvZWwNCg0KT24gNy82LzE3IDEyOjUy IEFNLCBKb2VsIE0uIEhhbHBlcm4gd3JvdGU6DQo+IEkgaGF2ZSBub3QgcmV2aWV3ZWQgdGhlIENo ZW4gZHJhZnQgdW50aWwgbm93Lg0KPiBBIGJyaWVmIHJldmlldyBzaG93cyB0aGF0IGl0IGRvZXMg bm90IGZvbGxvdyB0aGUgcGF0dGVybnMgb3IgYXBwcm9hY2ggDQo+IGRlZmluZWQgaW4gdGhlIElF VEYgU1VQQSBJbmZvcm1hdGlvbiBNb2RlbCBhbmQgdGhlIGNvcnJlc3BuZGluZyANCj4gZ2VuZXJp YyBkYXRhIG1vZGVsLg0KPiANCj4gVGhpcyBtYXR0ZXJzIGFzIHRob3NlIG1vZGVscyB1c2UgZXhh Y3RseSB0aGUgc3Ryb25nIHNlcGFyYXRpb24geW91IGFzayBmb3IuDQo+IA0KPiBZb3VycywNCj4g Sm9lbA0KPiANCj4gT24gNy81LzE3IDEwOjM5IFBNLCB5b3VsaXpoYW8gd3JvdGU6DQo+PiBEZWFy IEFsbCwNCj4+DQo+PiBCZWxvdyBhcmUgbXkgdGhvdWdodCBvbiBFQ0EgRE0gYmFzZWQgb24gdGhl IG1hdGVyaWFscyBJIHJlYWQgYW5kIHRoZSANCj4+IHByb2plY3QgSSBhbSBkb2luZy4gQW55IGNv bW1lbnRzIHdvdWxkIGJlIHdlbGNvbWUuDQo+Pg0KPj4gVGhlIGRpc2N1c3Npb25zIGFyZSBiYXNl ZCBvbiBhbiBFQ0EgUG9saWN5IERNIGRyYWZ0IFtlY2EtZGF0YS1tb2RlbF0uIA0KPj4gQWNjb3Jk aW5nIHRvIG91ciB1bmRlcnN0YW5kaW5nLCBpdCBpcyBhbGlnbmVkIHdpdGggdGhlIEVDQSBQb2xp Y3kgSU0gDQo+PiBbZWNhLWluZm8tbW9kZWxdLg0KPj4NCj4+IFdlIGFwcHJlY2lhdGUgdGhhdCB0 aGUgZHJhZnQgW2RyYWZ0LWNoZW4tc3VwYS1lY2EtZGF0YS1tb2RlbC0wNV0NCj4+IHByb3ZpZGVz IHRoZSBlbnRpdHkvc2NyaXB0IGFic3RyYWN0aW9uIHRoYXQgYWxsb3dzIGV4dGVuc2lvbiBmb3Ig DQo+PiBkaWZmZXJlbnQgc2NlbmFyaW9zLCBhbmQgdGhleSBtYXRjaCBvdXIgaW1wbGVtZW50YXRp b24uIEluIA0KPj4gcGFydGljdWxhciwgb3VyIEVDQSBwb2xpY3kgcGFyc2VyIGNhbiByZWFkIGVu dGl0eSBmaWVsZHMgKG9yIHNjcmlwdCANCj4+IGZpZWxkcyksIGFuZCBtYXAgdGhlbSB0byB0aGUg Q0xJIGNvbW1hbmQgcGFyYW1ldGVycyAob3Igc2NyaXB0IGltcGxlbWVudGF0aW9uKS4NCj4+DQo+ PiBIb3dldmVyLCB3ZSBmb3VuZCB0aGF0IHRoZSBjdXJyZW50IGRlZmluaXRpb24gc3RpbGwgbWFr ZXMgRE0gcGFyc2luZyANCj4+IGNvbXBsaWNhdGUuIE5vdGUgdGhhdCwgaW4gW2RyYWZ0LWNoZW4t c3VwYS1lY2EtZGF0YS1tb2RlbC0wNV0sIHRoZSANCj4+IGNvbmRpdGlvbi1saXN0IGNsYXVzZSBt YXkgc3RpbGwgaW52b2x2ZSB3aXRoIG5ldHdvcmsgZGV0YWlscyAoZS5nLiwgDQo+PiBiYW5kd2lk dGggYW5kIHRocmVzaG9sZCBpbiB0aGUgc2VydmljZS1mbG93IGV4YW1wbGUpLCBhbmQgdGhlIA0K Pj4gYWN0aW9uLWxpc3QgY2xhdXNlIG1heSBzdGlsbCBjb250YWluIHRoZSBkZWNpc2lvbiBsb2dp YyAoaS5lLiwgd2hlbiANCj4+IHRoZSBiYW5kd2lkdGggZXhjZWVkcyBhIHRocmVzaG9sZCkgdG8g dHJpZ2dlciBhbiBhY3Rpb24uIFRvIGV4dHJhY3QgDQo+PiB0aGUgobByZWFsobEgY29uZGl0aW9u LCBvdXIgcG9saWN5IHBhcnNlciBuZWVkcyB0byB1bmRlcnN0YW5kIHRoZSANCj4+IGFjdGlvbi1s aXN0IGNsYXVzZSwgYW5kIHRoZW4gZ2VuZXJhdGUgdGhlIKGwY29uZGl0aW9uobEgbG9naWMgaW4g cmVhbCANCj4+IGltcGxlbWVudGF0aW9uLg0KPj4NCj4+IFRvIG1ha2UgdGhpbmdzIG1vcmUgY29t cGxpY2F0ZSwgc29tZXRpbWVzIHdlIG5lZWQgdG8ganVkZ2Ugc2V2ZXJhbCANCj4+IGNvbmRpdGlv bnMgdG8gdHJpZ2dlciBhbiBhY3Rpb24gKGUuZy4sIGluIENpc2NvIEVFTSBbQ2lzY29FRU0sIFBh Z2VzIA0KPj4gNjksIDM0MiwgMzY4XSBhbmQgc29tZSBTRC1XQU4gZXhhbXBsZXMgaW4gSHVhd2Vp IFNELVdBTiBzb2x1dGlvbiANCj4+IFtIdWF3ZWktU0QtV0FOXSkuIEluIGFkZGl0aW9uLCBzb21l IGNvbnN0cmFpbnRzIG1heSBiZSBhZGRlZCwgZS5nLiwgDQo+PiB0aGUgY29uanVuY3RpdmUtdHlw ZSBkdXJhdGlvbiB0aGF0IGluZGljYXRlcyBob3cgbG9uZyB0aGUgY29uanVuY3RpdmUgDQo+PiBy ZWxhdGlvbnNoaXAgc2hvdWxkIGhvbGQuIEhvd2V2ZXIsIHRoZSBjdXJyZW50IG1vZGVsIGlzIHdl YWsgb24gDQo+PiBleHByZXNzaW5nIHRoZSBjYXBhYmlsaXR5IChhbHRob3VnaCBjb25qdW5jdGl2 ZS10eXBlIGlzIGRlZmluZWQgaW4gDQo+PiBbZWNhLWRhdGEtbW9kZWxdLCBob3cgdG8gdXNlIGl0 IGlzIG5vdCBjbGVhcikuDQo+Pg0KPj4gQmFzZWQgb24gdGhlIGFib3ZlIGFyZ3VtZW50cywgd2Ug d291bGQgbGlrZSB0byBzdWdnZXN0IHRoZSBmb2xsb3dpbmcNCj4+IGNoYW5nZXM6DQo+Pg0KPj4g KGEpIEEgY2xlYXIgc2VwYXJhdGlvbiBvZiBldmVudHMsIGNvbmRpdGlvbnMsIGFuZCBhY3Rpb25z IGlzIHdlbGNvbWUgDQo+PiBzbyB0aGF0IG91ciBwYXJzZXIgY2FuIGp1c3QgY2FyZSBkaWZmZXJl bnQgcGFydHMgYW5kIGRpcmVjdGx5IG1hcCANCj4+IHRoZW0gdG8gaW1wbGVtZW50YXRpb247DQo+ Pg0KPj4gKGIpIFRoZSBjb25kaXRpb24gY2xhdXNlIGNhbiBiZSBlbnJpY2hlZCB0byBleHByZXNz IHRoZSANCj4+IGNvbmp1bmN0aXZlLXR5cGUsIGNvbmp1bmN0aXZlLWR1cmF0aW9uLCBhbmQgb3Ro ZXIgcG9zc2libGUgZmllbGRzLg0KPj4NCj4+IFRoYW5rcyENCj4+DQo+PiBSZWdhcmRzLA0KPj4N Cj4+IExlbw0KPj4NCj4+IFtlY2EtaW5mby1tb2RlbF0gR2VuZXJpYyBQb2xpY3kgSW5mb3JtYXRp b24gTW9kZWwgZm9yIFNVUEENCj4+DQo+PiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtc3RyYXNzbmVyLXN1cGEtZ2VuZXJpYy1wb2xpY3ktaW5mby0NCj4+IG1vZGVsLTA1DQo+Pg0K Pj4NCj4+IFtlY2EtZGF0YS1tb2RlbF0gRUNBIFBvbGljeSBZQU5HIERhdGEgTW9kZWwNCj4+DQo+ PiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtY2hlbi1zdXBhLWVjYS1kYXRhLW1v ZGVsLTA1DQo+Pg0KPj4gW0Npc2NvLUVFTV0gRW1iZWRkZWQgRXZlbnQgTWFuYWdlciBDb25maWd1 cmF0aW9uIEd1aWRlLA0KPj4NCj4+IGh0dHA6Ly93d3cuY2lzY28uY29tL2MvZW4vdXMvdGQvZG9j cy9pb3MteG1sL2lvcy9lZW0vY29uZmlndXJhdGlvbi8xMg0KPj4gLTJzeC9lZW0tMTItMnN4LWJv b2sucGRmDQo+Pg0KPj4NCj4+IFtIdWF3ZWktU0QtV0FOXSBIdWF3ZWkgU0QtV0FOIFNvbHV0aW9u IEJyb2NodXJlDQo+Pg0KPj4gaHR0cDovL2UuaHVhd2VpLmNvbS9lbi9zb2x1dGlvbnMvdGVjaG5p Y2FsL3Nkbi9lbnRlcnByaXNlLXdhbi9zZC13YW4NCj4+DQo+PiAqRnJvbToqU1VQQSBbbWFpbHRv OnN1cGEtYm91bmNlc0BpZXRmLm9yZ10gKk9uIEJlaGFsZiBPZiAqeW91bGl6aGFvDQo+PiAqU2Vu dDoqIDIwMTfE6jbUwjIwyNUxNTozOA0KPj4gKlRvOiogQmVub2l0IENsYWlzZSA8YmNsYWlzZUBj aXNjby5jb20+OyBLaW5nLCBEYW5pZWwgDQo+PiA8ZC5raW5nQGxhbmNhc3Rlci5hYy51az4NCj4+ ICpDYzoqIG9wcy1hZHNAaWV0Zi5vcmc7IHN1cGEtY2hhaXJzQGlldGYub3JnOyBTVVBBIGxpc3Qg DQo+PiA8c3VwYUBpZXRmLm9yZz4NCj4+ICpTdWJqZWN0OiogUmU6IFtTdXBhXSBTVVBBIFVwZGF0 ZQ0KPj4NCj4+IERlYXIgQmVub2l0IEFELA0KPj4NCj4+IFRoYW5rcyBmb3IgcHVzaGluZyBhbmQg bW9uaXRvcmluZyB0aGUgU1VQQSBXRyBwcm9ncmVzcy4NCj4+DQo+PiBJIGFtIHNvcnJ5IHRvIHNl ZSB0aGUgZW1haWwgYmVsb3cuIEkgYW0gYW4gZW5naW5lZXIgaW4gSHVhd2VpLCBhbmQgDQo+PiBy ZWNlbnRseSB3ZSBoYXZlIGJlZW4gZGV2ZWxvcGluZyB0aGUgY29kZSBvZiBTVVBBIEVDQSBwb2xp Y3kgdG8gDQo+PiBjb250cm9sIHRoZSBuZXR3b3JrLiBJbiBwYXJ0aWN1bGFyLCB3ZSBwcm92aWRl IHJlc3RmdWwgaW50ZXJmYWNlIHRvIA0KPj4gdXNlcnMgZm9yIGNvbmZpZ3VyaW5nIEVDQSBwb2xp Y2llcyBmb2xsb3dpbmcgdGhlIEVDQSBETS4NCj4+DQo+PiBUbyBiZSBob25lc3QsIElNTywgdGhl IEVDQSBJTSBhbmQgRE0gYXJlIG5vdCBtYXR1cmUgZW5vdWdoIGZvciBkaXJlY3QgDQo+PiBpbXBs ZW1lbnRhdGlvbi4gV2UgYXJlIHJldmlzaW5nIHNvbWUgcGFydHMgZmFjaWxpdGF0aW5nIHRoZSAN Cj4+IGltcGxlbWVudGF0aW9uLg0KPj4NCj4+IEFsdGhvdWdoIHRoZSBTVVBBIElNIGFuZCBETSBz dGlsbCBjb250YWluIGZsYXdzLCB3ZSBob3BlZCB0byBzZWUgdGhlbSANCj4+IGNvbXBsZXRlZCAo YWxzbyBvdGhlciBkb2N1bWVudHMsIGUuZy4sIFNVUEEgZnJhbWV3b3JrKSBzbyB0aGF0IHdlIGNh biANCj4+IGNvbXBsZXRlIG91ciBvd24gaW1wbGVtZW50YXRpb25zIGJhc2VkIG9uIFNVUEEgc3Rh bmRhcmQgd29yay4NCj4+DQo+PiBUaGFua3MgZm9yIHlvdXIgY29uc2lkZXJhdGlvbi4NCj4+DQo+ PiBSZWdhcmRzLA0KPj4NCj4+IExlbw0KPj4NCj4+ICpGcm9tOipTVVBBIFttYWlsdG86c3VwYS1i b3VuY2VzQGlldGYub3JnXSAqT24gQmVoYWxmIE9mICpCZW5vaXQgDQo+PiBDbGFpc2UNCj4+ICpT ZW50OiogMjAxN8TqNtTCMTXI1TIwOjQ3DQo+PiAqVG86KiBLaW5nLCBEYW5pZWwgPGQua2luZ0Bs YW5jYXN0ZXIuYWMudWsgDQo+PiA8bWFpbHRvOmQua2luZ0BsYW5jYXN0ZXIuYWMudWs+PjsgU1VQ QSBsaXN0IDxzdXBhQGlldGYub3JnIA0KPj4gPG1haWx0bzpzdXBhQGlldGYub3JnPj4NCj4+ICpD YzoqIG9wcy1hZHNAaWV0Zi5vcmcgPG1haWx0bzpvcHMtYWRzQGlldGYub3JnPjsgDQo+PiBzdXBh LWNoYWlyc0BpZXRmLm9yZyA8bWFpbHRvOnN1cGEtY2hhaXJzQGlldGYub3JnPg0KPj4gKlN1Ympl Y3Q6KiBSZTogW1N1cGFdIFNVUEEgVXBkYXRlDQo+Pg0KPj4gRGVhciBhbGwsDQo+Pg0KPj4gQWZ0 ZXIgdGhlIGxhc3QgSUVURiwgSSBwdXQgYSBjYWxlbmRhciByZW1pbmRlciBvbiBKdW5lIDE2dGgg dG8gZGVjaWRlIA0KPj4gb24gdGhlIG5leHQgc3RlcHMgZm9yIFNVUEEuDQo+PiBUaGlzIGlzIGlu bGluZSB3aXRoIHRoZSBvdXIgcHJldmlvdXMgbWVldGluZyBtaW51dGVzLCBzbyBpdCBzaG91bGQg DQo+PiBub3QgY29tZSBhcyBhIHN1cnByaXNlLg0KPj4gR3JhbnRlZCwgdGhpcyBpcyBvbmUgZGF5 IGVhcmxpZXIgdGhhbiBmb3Jlc2VlbiwgYnV0IHRoZSBJRVNHIGFnZW5kYSANCj4+IGNvb3JkaW5h dGlvbiBjYWxsIHRha2VzIHBsYWNlIHRvZGF5LCBhbmQgaXQgd2FzIGltcG9ydGFudCBmcm9tIGEg DQo+PiBzY2hlZHVsaW5nIHBvaW50IG9mIHZpZXcgdG8gdW5kZXJzdGFuZCBpZiBTVVBBIHdvdWxk IG1lZXQuIFRoZSBjaGFpcnMgDQo+PiBpbmZvcm1lZCBtZSB0aGF0IG5vIFNVUEEgbWVldGluZyBp cyByZXF1aXJlZCBpbiBQcmFndWUuIFRoYXQgDQo+PiB0cmlnZ2VyZWQgdGhpcyBkaXNjdXNzaW9u LCBqdXN0IG9uZSBkYXkgZWFybGllci4NCj4+DQo+PiBPdXIgbWVldGluZyBtaW51dGVzOiANCj4+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvc3VwYS9jdXJyZW50L21zZzAx NjEyLmh0bWwNCj4+DQo+PiAgICAgQXQgdGhlIFNVUEEgV0cgYXQgSUVURiA5OCAoVHVlc2RheSwg MjggTWFyY2gpIHdlIGRpc2N1c3NlZCB0aGUNCj4+DQo+PiAgICAgcHJvZ3Jlc3Mgb2YgdGhlIFdH LiAgQmVub2l0IChvdXIgQUQpIHN1bW1lZCB1cCB0aGUgc2l0dWF0aW9uLCANCj4+IHBvaW50aW5n DQo+Pg0KPj4gICAgIG91dCB0aGF0IG91ciBkcmFmdHMgYXJlIG5vdCB1cGRhdGVkIHZlcnkgZnJl cXVlbnRseSwgYW5kIHRoYXQgdGhlIA0KPj4gU1VQQQ0KPj4NCj4+ICAgICBtYWlsaW5nIGxpc3Qg aGFzIGJlZW4gdmVyeSBxdWlldCBiZXR3ZWVuIG1lZXRpbmdzLg0KPj4NCj4+ICAgICBBdCB0aGUg bWVldGluZyB0aGUgYXV0aG9ycyBvZiB0aGUgU1VQQSBJbmZvcm1hdGlvbiBtb2RlbCBhbmQgdGhl IA0KPj4gU1VQQQ0KPj4NCj4+ICAgICBEYXRhIE1vZGVsIGRyYWZ0cyBzYWlkIHRoYXQgdGhvc2Ug ZHJhZnRzIHNob3VsZCBiZSByZWFkeSBmb3IgV0cgDQo+PiBMYXN0DQo+Pg0KPj4gICAgIENhbGwg YnkgMSBKdW5lLCBzbyB0aGF0IHRoZXkgY291bGQgYmUgc2VudCB0byBJRVNHIGZvciBhcHByb3Zh bCANCj4+IGJ5DQo+Pg0KPj4gICAgIGFib3V0IDEgSnVseS4NCj4+DQo+PiAgICAgQWZ0ZXIgc3Vt bWluZyB1cCB0aGUgcHJvcyBhbmQgY29ucyBmb3IgU1VQQSBjb250aW51aW5nLCBCZW5vaXQNCj4+ DQo+PiAgICAgY29uY2x1ZGVkIGJ5IHNheWluZyB0aGF0IHRoZSBXRyB3aWxsIGJlIGNsb3NlZCBh dCBJRVRGIDk5IA0KPj4gKFByYWd1ZSwgMTYNCj4+DQo+PiAgICAgSnVseSkgdW5sZXNzIHRoZXJl IGlzIHN1YnN0YW50aXZlIHByb2dyZXNzIG9uIHRoZSBJbmZvcm1hdGlvbiANCj4+IE1vZGVsDQo+ Pg0KPj4gICAgIGFuZCBlc3BlY2lhbGx5IG9uIHRoZSBEYXRhIE1vZGVsIGRyYWZ0cyBieSBvbmUg bW9udGggYmVmb3JlIHRoZSANCj4+IFByYWd1ZQ0KPj4NCj4+ICAgICBtZWV0aW5nLiAgJ1N1YnN0 YW50aXZlIHByb2dyZXNzJyBoZXJlIG1lYW5zIHNlZWluZyBjb21tZW50cyBvbiANCj4+IGFuZC9v cg0KPj4NCj4+ICAgICByZXZpZXdzIG9mIHRoZXNlIGRyYWZ0cyBkZW1vbnN0cmF0aW5nIHRoYXQg cGVvcGxlIC0gb3V0c2lkZSB0aGUgDQo+PiBzbWFsbA0KPj4NCj4+ICAgICBncm91cCBvZiBhdXRo b3JzIC0gaGF2ZSBjYXJlZnVsbHkgcmVhZCB0aGUgZHJhZnRzLCBvciBiZXR0ZXIsIA0KPj4gdGhh dCB0aGV5DQo+Pg0KPj4gICAgIGFyZSBhY3R1YWxseSB1c2luZyBTVVBBJ3MgSW5mb3JtYXRpb24g YW5kIERhdGEgTW9kZWxzLg0KPj4NCj4+IEkndmUgYmVlbiB3YXRjaGluZyB0aGUgbGlzdC4NCj4+ DQo+PiBTaW5jZSB0aGUgbGFzdCBJRVRGIG1lZXRpbmcsIHdlIHJlY2VpdmVkIHR3byBuZXcgZHJh ZnRzIC4uLg0KPj4NCj4+ICAgICAgICAgIGRyYWZ0LWlldGYtc3VwYS1nZW5lcmljLXBvbGljeS1p bmZvLW1vZGVsLTAzLnR4dA0KPj4gICAgICAgICAgZHJhZnQtaWV0Zi1zdXBhLWdlbmVyaWMtcG9s aWN5LWRhdGEtbW9kZWwtMDMudHh0DQo+Pg0KPj4gLi4uIGFuZCBzb21lIGRyYWZ0IHJldmlld3M6 DQo+Pg0KPj4gICAgICAgICBndW50ZXIud2FuZ0Blcmljc3Nvbi5jb20gPG1haWx0bzpndW50ZXIu d2FuZ0Blcmljc3Nvbi5jb20+IG9uIG9uDQo+PiAgICAgICAgIGRyYWZ0LWlldGYtc3VwYS1wb2xp Y3ktYmFzZWQtbWFuYWdlbWVudC1mcmFtZXdvcms6DQo+Pg0KPj4gICAgICAgICAgICAgR29vZCBm ZWVkYmFjayBidXQgaXQgc2VlbXMgbGlrZSBvbmx5IGVkaXRvcmlhbCB0byBtZS4NCj4+DQo+PiAg ICAgICAgIFRvbnkgdGlhbnh1QGNoaW5hbW9iaWxlLmNvbSA8bWFpbHRvOnRpYW54dUBjaGluYW1v YmlsZS5jb20+IG9uDQo+PiAgICAgICAgIGRyYWZ0LWNoZW5nLXN1cGEtYXBwbGljYWJpbGl0eToN Cj4+DQo+PiAgICAgICAgICAgICBTb21lIGVkaXRvcmlhbCBjb21tZW50cyBhbmQgdGhyZWUgdGVj aG5pY2FsIG9uZXM6DQo+Pg0KPj4gICAgICAgICAgICAgMS4gICAgICAgSSB3b25kZXIgdGhlIG1l YW5pbmcgb2Ygc2VjdGlvbiAzLCB0aGUgcGFydCBjb3BpZWQNCj4+ICAgICAgICAgICAgIGZyb20g ZnJhbWV3b3JrIGRyYWZ0LCBtYXkgbm90IGJlIG5lZWRlZC4NCj4+DQo+PiAgICAgICAgICAgICAy LiAgICAgICBJIHN1Z2dlc3QgdG8gcmVwbGFjZSB0aGUgdGl0bGUgb2YgNC4yLjIuYW5kIDQuMi4z DQo+PiAgICAgICAgICAgICB3aXRoIGRldGFpbGVkIGluZm9ybWF0aW9uIGluc3RlYWQgb2Ygd3Jp dGluZyBqdXN0ICAgRXhhbXBsZQ0KPj4gICAgICAgICAgICAgMSAvIDIuDQo+Pg0KPj4gICAgICAg ICAgICAgMy4gICAgICAgVGhlIHdyaXRlciB3cm90ZSChsFdlIHdpbGwgZGVmaW5lICJlZGdlSW50 ZXJmYWNlIg0KPj4gICAgICAgICAgICAgcm9sZSBhbmQgIkVudGVycHJpc2VEb21haW4iIGxhdGVy IGluICB0aGlzIG5vdGWhsSBidXQgSQ0KPj4gICAgICAgICAgICAgZmFpbGVkIHRvIGZpbmQgdGhl IGV4cGxhbmF0aW9uIGZvciB0aGVzZSB0d28gdGVybS4NCj4+DQo+PiAgICAgICAgICAgICBCZW5v aXQgPT4gaXQncyBtb3JlIGxpa2Ugb25lIHRlY2huaWNhbCBjb21tZW50LCB0aGUgbGFzdCBvbmUu DQo+Pg0KPj4NCj4+ICAgICAgICAgSGFpbmluZyBXYW5nOiAxODkwMTM0MTIyOUAxODkuY24gPG1h aWx0bzoxODkwMTM0MTIyOUAxODkuY24+IG9uDQo+PiAgICAgICAgIGRyYWZ0LWlldGYtc3VwYS1n ZW5lcmljLXBvbGljeS1kYXRhLW1vZGVsLTAzOg0KPj4NCj4+ICAgICAgICAgICAgIEkgdW5kZXJz dGFuZCB0aGF0IHRoZSBHUElNIFlBTkcgbW9kZWwgcHJvdmlkZXMgYW4gZXhhbXBsZSBvZg0KPj4g ICAgICAgICAgICAgaG93IHRvIGNvbnZlcnQgSU0gdG8gRE0gKGZvciBnZW5lcmFsIHBvbGljeSks IGFuZCBKb2huoa9zDQo+PiAgICAgICAgICAgICBTTk1QIGJsb2NraW5nIGV4YW1wbGUNCj4+ICAg ICAgICAgICAgIA0KPj4gKGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvc3Vw YS9EV0V6YVNCSzZLQmRzbVEwRkUyLWV5cFR6ZVkpDQo+PiAgICAgICAgICAgICBleHBvc2VzIHNv bWUgZGV0YWlscy4gQnV0IEkgYW0gc29ycnkgdGhhdCB0aGUgd2hvbGUgcGljdHVyZQ0KPj4gICAg ICAgICAgICAgaXMgc3RpbGwgbm90IGNsZWFyIHRvIG1lLiBJdCB3b3VsZCBiZSBuaWNlIGlmIHRo ZSBFQ0EgRGF0YQ0KPj4gICAgICAgICAgICAgTW9kZWwgcGFydCBjYW4gZXhwbGFpbiBpbiBtb3Jl IGRldGFpbHMuDQo+Pg0KPj4gICAgICAgICBNYXJjaCBCbGFuY2hldCBvbg0KPj4gZHJhZnQtaWV0 Zi1zdXBhLXBvbGljeS1iYXNlZC1tYW5hZ2VtZW50LWZyYW1ld29yazoNCj4+DQo+PiAgICAgICAg ICAgICAtIGxhcmdlciBjb21tZW50OiBJoa9tIG5vdCBzdXJlIHdoYXQgdG8gZG8gd2l0aCB0aGlz DQo+PiAgICAgICAgICAgICBkb2N1bWVudC4gSXQgbG9va3MgbGlrZSBhIGxhcmdlIHdpc2ggbGlz dCBvZiBmZWF0dXJlcy4gSQ0KPj4gICAgICAgICAgICAgZ3Vlc3MgSaGvbSBwcm9iYWJseSB0b28g dXNlZCB0byBpbXBsZW1lbnRhdGlvbi9wcm90b2NvbA0KPj4gICAgICAgICAgICAgZGV0YWlscy4g SSBndWVzcyBJIHdpbGwgd2FpdCB1bnRpbCB0byBzZWUgdGhlIGFjdHVhbA0KPj4gICAgICAgICAg ICAgcHJvdG9jb2wveWFuZyBtb2RlbHMuDQo+Pg0KPj4NCj4+IExldCdzIGFuYWx5emUgdGhlIHNp dHVhdGlvbjoNCj4+IEkgZG9uJ3QgY29uc2lkZXIgdGhvc2UgcmV2aWV3cyAoYnR3IGEgc2luZ2xl IG9uZSB0aGUgRE0sIG5vbmUgb24gdGhlDQo+PiBJTSkgYXMgInN1YnN0YW50aXZlIHByb2dyZXNz Ii4NCj4+IEkgZG9uJ3Qgc2VlIGludGVyZXN0IGZyb20gWUFORyBtb2R1bGUgYXV0aG9ycywgcmVh ZHkgdG8gcmV1c2UgdGhlIA0KPj4gU1VQQSBZQU5HIGNvbnN0cnVjdHMuDQo+PiBCZWluZyBhIHll YXIgbGF0ZSBhY2NvcmRpbmcgdG8gdGhlIGNoYXJ0ZXIgbWlsZXN0b25lcywgdGhlIHdpbmRvdyBv ZiANCj4+IG9wcG9ydHVuaXR5IHRvIHByb2R1Y2UgcmV1c2FibGUgd29yayBoYXMgYmVlbiBjbG9z aW5nIHJhcGlkbHkuDQo+PiBJIGJlbGlldmUgdGhhdCBTVVBBIGhhZCBtdWx0aXBsZSBjaGFuY2Vz IHRvIG1ha2UgaXQgaGFwcGVuLCBhbmQgDQo+PiBmYWlsZWQgdG8gZGVsaXZlci4NCj4+IFdpdGgg dGhpcyBpbiBtaW5kLCBJIGRvbid0IHNlZSBob3cgSSBzaG91bGQgY29uY2x1ZGUgYW55dGhpbmcg ZWxzZSANCj4+IHRoYW4gdGhpcyBXRyB3aWxsIGJlIGNsb3NpbmcgYXQgSUVURiA5OS4NCj4+DQo+ PiBSZWdhcmRzLCBCZW5vaXQgKE9QUyBBRCkNCj4+DQo+PiAgICAgRGVhciBzdXBhoa9ycywNCj4+ DQo+PiAgICAgV2UgaGF2ZSBjYW5jZWxsZWQgb3VyIGZvcm1hbCBtZWV0aW5nIGluIFByYWd1ZS4g VGhpcyBkZWNpc2lvbiB3YXMNCj4+ICAgICB0YWtlbiBiYXNlZCBvbiBhIHByb3Bvc2VkIHBsYW4g dG8gZm9jdXMgZWZmb3J0IG9uIGNvbXBsZXRpbmcgdGhlDQo+PiAgICAgZXhpc3RpbmcgV0cgaXRl bXMgYW5kIHByZXBhcmUgZm9yIGNsb3N1cmUgb2YgdGhlIHN1cGEgd29ya2luZyBncm91cA0KPj4g ICAgIHNvbWV0aW1lIGJldHdlZW4gSUVURiA5OSBhbmQgMTAwLiBBIHBsYW4gdGhhdCBpcyB5ZXQg dG8gYmUgYXBwcm92ZWQNCj4+ICAgICBieSBCZW5vaXQuDQo+Pg0KPj4gICAgIER1cmluZyB0aGUg bGFzdCB3b3JraW5nIGdyb3VwIG1lZXRpbmcgQmVub2l0IHN0YXRlZDoNCj4+DQo+PiAgICAgobB0 aGUgV0cgd2lsbCBiZSBjbG9zZWQgYXQgSUVURiA5OSAoUHJhZ3VlLCAxNiBKdWx5KSB1bmxlc3Mg dGhlcmUgaXMNCj4+ICAgICBzdWJzdGFudGl2ZSBwcm9ncmVzcyBvbiB0aGUgSW5mb3JtYXRpb24g TW9kZWwgYW5kIGVzcGVjaWFsbHkgb24gdGhlDQo+PiAgICAgRGF0YSBNb2RlbCBkcmFmdCBieSBv bmUgbW9udGggYmVmb3JlIHRoZSBQcmFndWUgbWVldGluZy6hsQ0KPj4NCj4+ICAgICBUaGUgYXV0 aG9ycyBvZiB0aGUgRGF0YSBNb2RlbCBhbmQgSW5mb3JtYXRpb24gTW9kZWwgSS1EcyBkaWQgc3Vi bWl0DQo+PiAgICAgbmV3IHZlcnNpb25zIGJ1dCB3ZSBvbmx5IHJlY2VpdmVkIG9uZSByZXZpZXcu IEhvd2V2ZXIsIE5ldmlsIGFuZCBJDQo+PiAgICAgYXJlIHdvcmtpbmcgd2l0aCB0aGUgSU0gYW5k IERNIGF1dGhvcnMgdG8gZ2F0aGVyIHJldmlld2VycyBpbg0KPj4gICAgIHByZXBhcmF0aW9uIG9m IExhc3QgQ2FsbC4gRXNzZW50aWFsbHksIHdlIGFyZSB3b3JraW5nIHRvIHByZXAgZm9sa3MNCj4+ ICAgICB3aG8gd291bGQgYmUgYWJsZSB0byByZXZpZXcgdGhlIGRvY3VtZW50cyB3ZSBMYXN0IENh bGwsIGlkZWFsbHkNCj4+ICAgICB0aGVzZSBzaG91bGQgYmUgZnJvbSBwb2xpY3kveWFuZyBpbXBs ZW1lbnRlcnMuDQo+Pg0KPj4gICAgIFRoZSBGcmFtZXdvcmsgSS1EIGhhcyBhbHNvIHJlY2VpdmVk IGEgcmV2aWV3IHdoaWNoIGlzIHBvc2l0aXZlLCBhbmQNCj4+ICAgICBJIGFtIGluIHRoZSBwcm9j ZXNzIG9mIHJldmlld2luZyB0aGUgZG9jdW1lbnQgbXlzZWxmIHRvIGFsc28gaGVscA0KPj4gICAg IHByZXBhcmUgdGhlIGRvY3VtZW50IGZvciBMYXN0IENhbGwuIEFkZGl0aW9uYWxseSwgdGhlIEFw cGxpY2FiaWxpdHkNCj4+ICAgICBJLUQgKGEgbm9uLXdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQpIHJl Y2VpdmVkIGEgcmV2aWV3IHdoaWNoIGlzIGFsc28NCj4+ICAgICB1c2VmdWwuDQo+Pg0KPj4gICAg IFdlIGhhdmUgYWxzbyBzZWVuIG5vdGlmaWNhdGlvbnMgZnJvbSBvdGhlciBTRE9zIGZvbGxvd2lu ZyBzdXBhLA0KPj4gICAgIHNwZWNpZmljYWxseToNCj4+DQo+PiAgICAgLSBPTlVHOiBJbnZlc3Rp Z2F0aW5nIEkyTlNGIGNvbWJpbmVkIHdpdGggdGhlIFNVUEEgZGF0YSBtb2RlbCBhbmQNCj4+ICAg ICBmcmFtZXdvcmsNCj4+DQo+PiAgICAgLSBFVFNJIEV4cGVyaWVudGlhbCBOZXR3b3JrZWQgSW50 ZWxsaWdlbmNlIChFTkkpOiBOZXcgaW5pdGlhdGl2ZQ0KPj4gICAgIGRlZmluaW5nIGNvbnRleHQg YXdhcmUgbmV0d29ya2luZyBzeXN0ZW1zLCBTVVBBIHdhcyBpZGVudGlmaWVkIGFzIGENCj4+ICAg ICBrZXkgYnVpbGRpbmcgYmxvY2sNCj4+DQo+PiAgICAgLSBNRUYgT3BlbiBMaWZlY3ljbGUgU2Vy dmljZSBPcmNoZXN0cmF0b3IgKExTTyk6IFVzaW5nIFNVUEEgYmV0d2Vlbg0KPj4gICAgIGZ1bmN0 aW9uYWwgY29tcG9uZW50cw0KPj4NCj4+ICAgICBIb3dldmVyLCB0aGUgaW5kaWNhdGlvbiBmcm9t IE9OVUcsIEVUU0kgYW5kIE1FRiBkb2VzIG5vdCBtYXRlcmlhbGx5DQo+PiAgICAgY2hhbmdlIHRo ZSBzaXR1YXRpb24gb2YgU1VQQSBidXQgaXQgZG9lcyBkZW1vbnN0cmF0ZSB3aWRlciBpbnRlcmVz dA0KPj4gICAgIGluIG91ciB3b3JrLCBhbmQgYXQgbGVhc3Qgc29tZSByZXNwb25zaWJpbGl0eSBm b3Igc3VwYS9JRVRGIHRvDQo+PiAgICAgY29tcGxldGUgaXQgKGlmIHBvc3NpYmxlKS4gSWYgeW91 IGFyZSBhd2FyZSBvZiBuZWFyLXRlcm0NCj4+ICAgICBpbXBsZW1lbnRhdGlvbnMgbm93IGlzIHRo ZSB0aW1lIHRvIGhpZ2hsaWdodCB0aGVtLg0KPj4NCj4+ICAgICBBZ2Fpbiwgd2UgZmVsdCB3ZSBk aWQgbm90IG5lZWQgYSBXRyBtZWV0aW5nIGluIFByYWd1ZSB0byBwcm9ncmVzcw0KPj4gICAgIHRo ZSB3b3JraW5nIGdyb3VwIEktRHMsIGFuZCBnaXZlbiB0aGUgSUVURiBhZ2VuZGEgY29vcmRpbmF0 aW9uIGNhbGwNCj4+ICAgICAoaXMgdG9kYXkpIHdlIGhhZCB0byBjYW5jZWwgdGhlIHN1cGEgV0cg c2Vzc2lvbiByZXF1ZXN0IEFTQVAsIGFuZA0KPj4gICAgIHVuZm9ydHVuYXRlbHkgYmVmb3JlIHdl IGhhZCBhIGNoYW5jZSB0byBjb21tdW5pY2F0ZSB0aGUgY3VycmVudA0KPj4gICAgIHNpdHVhdGlv biB0byB0aGUgcmVzdCBvZiB0aGUgd29ya2luZyBncm91cC4gQXBvbG9naWVzIGZvciBhbnkNCj4+ ICAgICBzdXJwcmlzZSB3aGVuIHlvdSBzYXcgdGhlIGNhbmNlbGxhdGlvbiBub3RpZmljYXRpb24s IGFuZCB0aGUgbGFjayBvZg0KPj4gICAgIG9wcG9ydHVuaXR5IGZvciB3aWRlciBkaXNjdXNzaW9u Lg0KPj4NCj4+ICAgICBBcyBtZW50aW9uZWQgb3VyIHByb3Bvc2VkIHBsYW4gaGFzIGJlZW4gc3Vi bWl0dGVkIHRvIEJlbm9pdCBhbmQgaXMNCj4+ICAgICB5ZXQgdG8gYmUgYXBwcm92ZWQsIHRoZXJl Zm9yZSB3ZSB3aWxsIHdhaXQgZm9yIGhpcyB0aG91Z2h0cyBhbmQNCj4+ICAgICB1bHRpbWF0ZSBk ZWNpc2lvbi4NCj4+DQo+PiAgICAgVGhlIFNVUEEgQ2hhaXJzIHdvdWxkIHNpbmNlcmVseSBsaWtl IHRvIHRoYW5rIGV2ZXJ5b25lIGZvciB0aGVpcg0KPj4gICAgIHBhcnRpY2lwYXRpb24gYW5kIGVz cGVjaWFsbHkgdGhlIGF1dGhvcnMgb2YgSS1EcyBmb3IgdGhlaXIgZWZmb3J0cy4NCj4+DQo+PiAg ICAgQlIsIE5ldmlsIGFuZCBEYW4uDQo+Pg0KPj4NCj4+DQo+PiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gU1VQQSBtYWlsaW5nIGxpc3QNCj4+IFNV UEFAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3Vw YQ0KPj4NCg== From nobody Mon Jul 17 14:40:24 2017 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 1F536126CC7; Mon, 17 Jul 2017 14:40:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: supa@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.56.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150032761698.24443.14233169765084125696@ietfa.amsl.com> Date: Mon, 17 Jul 2017 14:40:17 -0700 Archived-At: Subject: [Supa] I-D Action: draft-ietf-supa-policy-based-management-framework-03.txt X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.22 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, 17 Jul 2017 21:40:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Simplified Use of Policy Abstractions of the IETF. Title : SUPA Policy-based Management Framework Authors : Will(Shucheng) Liu Chongfeng Xie John Strassner Georgios Karagiannis Maxim Klyus Jun Bi Filename : draft-ietf-supa-policy-based-management-framework-03.txt Pages : 16 Date : 2017-07-17 Abstract: Simplified Use of Policy Abstractions (SUPA) defines base YANG data models to encode policy, which point to device-, technology-, and service-specific YANG models developed elsewhere. Policy rules within an operator's environment can be used to express high-level, possibly network-wide policies to a network management function (within a controller, an orchestrator, or a network element). The network management function can then control the configuration and/or monitoring of network elements and services. This document describes the SUPA basic framework, its elements and interfaces. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-supa-policy-based-management-framework/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-supa-policy-based-management-framework-03 https://datatracker.ietf.org/doc/html/draft-ietf-supa-policy-based-management-framework-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-supa-policy-based-management-framework-03 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 Mon Jul 17 14:40:37 2017 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 496AB131CCC for ; Mon, 17 Jul 2017 14:40:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 XcekH-PlJrsz for ; Mon, 17 Jul 2017 14:40:20 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB6AE131CBE for ; Mon, 17 Jul 2017 14:40:19 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DRK35377; Mon, 17 Jul 2017 21:40:17 +0000 (GMT) Received: from DGGEML403-HUB.china.huawei.com (10.3.17.33) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 17 Jul 2017 22:40:16 +0100 Received: from DGGEML510-MBX.china.huawei.com ([169.254.2.91]) by DGGEML403-HUB.china.huawei.com ([fe80::74d9:c659:fbec:21fa%31]) with mapi id 14.03.0301.000; Tue, 18 Jul 2017 05:40:09 +0800 From: "Liushucheng (Will Liu)" To: Yangyang Wang , "supa@ietf.org" CC: Jun Bi Thread-Topic: review for draft-ietf-supa-policy-based-management-framework-02 Thread-Index: AQHS+Jn44FjGj2gvHk29le5AJ48JE6JYhIDg Date: Mon, 17 Jul 2017 21:40:09 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.210.172.137] Content-Type: multipart/alternative; boundary="_000_C9B5F12337F6F841B35C404CF0554ACB8A34CEA1dggeml510mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.596D2EC2.006F, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.2.91, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: bb55e05d6c02c9fda306123f009ff697 Archived-At: Subject: Re: [Supa] review for draft-ietf-supa-policy-based-management-framework-02 X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.22 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: Mon, 17 Jul 2017 21:40:23 -0000 --_000_C9B5F12337F6F841B35C404CF0554ACB8A34CEA1dggeml510mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgWWFuZ3lhbmcsDQoNCk1hbnkgdGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzLiBTb21lIHJlc3Bv bnNlcyBiZWxvdyBpbmxpbmUuDQoNCg0KRnJvbTogWWFuZ3lhbmcgV2FuZyBbbWFpbHRvOnd5eXN0 YXJAZ21haWwuY29tXQ0KU2VudDogU3VuZGF5LCBKdWx5IDA5LCAyMDE3IDExOjU5IEFNDQpUbzog c3VwYUBpZXRmLm9yZw0KQ2M6IExpdXNodWNoZW5nIChXaWxsIExpdSkgPGxpdXNodWNoZW5nQGh1 YXdlaS5jb20+OyBKdW4gQmkgPGp1bmJpQHRzaW5naHVhLmVkdS5jbj4NClN1YmplY3Q6IHJldmll dyBmb3IgZHJhZnQtaWV0Zi1zdXBhLXBvbGljeS1iYXNlZC1tYW5hZ2VtZW50LWZyYW1ld29yay0w Mg0KDQpJIGhhdmUgcmV2aWV3ZWQgIGRyYWZ0LWlldGYtc3VwYS1wb2xpY3ktYmFzZWQtbWFuYWdl bWVudC1mcmFtZXdvcmsuIE15IGNvbW1lbnRzIGFyZSBhcyBmb2xsb3dzOg0KDQoxKSBUaGlzIGRy YWZ0IGNvbnRhaW5zIG1hbnkgY29uY2VwdHMgdGhhdCBhcmUgdmVyeSBhYnN0cmFjdC4gSSBzdWdn ZXN0IHRoaXMgZHJhZnQgbWF5IGJyaWVmbHkgZGVzY3JpYmUgdGhlIGNvbnRlbnRzIGFuZCB0aGUg Z29hbCAgb2YgdGhpcyBkcmFmdCBhbmQgaXRzIHNpZ25pZmljYW5jZS4gU29tZSBzaW1wbGUgYW5k IGNvbmNyZXRlIGluc3RhbmNlcyBjYW4gYmUgYWRkZWQgaW4gdGhlIGRlc2NyaXB0aW9ucyBvZiB0 aGUgbWFuYWdlbWVudCBmcmFtZXdvcmsgdG8gaGVscCBjbGFyaWZ5IHRoZSBhYnN0cmFjdCBjb25j ZXB0cyBhbmQgZnJhbWV3b3JrIGluIHRoaXMgZHJhZnQuDQpbV2lsbF0gVGhlIGdvYWwgb2YgdGhp cyBkcmFmdCBpcyBkZXNjcmliaW5nIHRoZSBTVVBBIGJhc2ljIGZyYW1ld29yaywgaXRzIGVsZW1l bnRzIGFuZCBpbnRlcmZhY2VzLiBJIGd1ZXNzIHlvdSB3YW50ZWQgdG8gYXNrIGFib3V0IHRoZSBn b2FsIG9mIFNVUEE/IFRoZSBTVVBBIHdvcmtpbmcgZ3JvdXAgZGVmaW5lcyBhIGRhdGEgbW9kZWws IHRvIGJlIHVzZWQgdG8gcmVwcmVzZW50IGhpZ2gtbGV2ZWwsIHBvc3NpYmx5IG5ldHdvcmstd2lk ZSBwb2xpY2llcywgd2hpY2ggY2FuIGJlIGlucHV0IHRvIGEgbmV0d29yayBtYW5hZ2VtZW50IGZ1 bmN0aW9uICh3aXRoaW4gYSBjb250cm9sbGVyLCBhbiBvcmNoZXN0cmF0b3IsIG9yIGEgbmV0d29y ayBlbGVtZW50KS4gUHJvY2Vzc2luZyB0aGF0IGlucHV0IG1vc3QgcHJvYmFibHkgcmVzdWx0cyBp biBuZXR3b3JrIGNvbmZpZ3VyYXRpb24gY2hhbmdlcy4NClNvbWUgc2ltcGxlIGluc3RhbmNlcyB3 aWxsIGJlIGFkZGVkIGFuZCBhbHNvIHJlZmVyIHRvIHRoZSBhcHBsaWNhYmlsaXR5IGRyYWZ0IFtJ LUQuY2hlbmctc3VwYS1hcHBsaWNhYmlsaXR5XS4NCg0KMikgIlRyYWZmaWMgZmxvdyBvdmVyIGlu Y3JlYXNpbmdseSBjb21wbGV4IGVudGVycHJpc2UgYW5kIHNlcnZpY2UgcHJvdmlkZXIgbmV0d29y ayBiZWNvbWVzIG1vcmUgYW5kIG1vcmUgaW1wb3J0YW50IiBtYXkgYmUgY2hhbmdlIHRvICJUaGUg bWFuYWdlbWVudCBvZiBUcmFmZmljIGZsb3cgb3ZlciBpbmNyZWFzaW5nbHkgY29tcGxleCBlbnRl cnByaXNlIGFuZCBzZXJ2aWNlIHByb3ZpZGVyIG5ldHdvcmsgYmVjb21lcyBtb3JlIGFuZCBtb3Jl IGltcG9ydGFudCA/DQpbV2lsbF0gTm8gZXhhY3RseS4gIEhlcmUgd2UgbWVhbiBmaXJzdGx5IHRo ZSB0cmFmZmljIGlzIG1vcmUgYW5kIG1vcmUgaW1wb3J0YW50LCBzZWNvbmQgdGhlIHZhcmlldHkg bWFrZXMgZGVwbG95aW5nIG5ldyBzZXJ2aWNlIG1vcmUgZGlmZmljdWx0LCBsZWFkaW5nIHRvIHRo ZSBtZWNoYW5pc21zIG9mIHBvbGljeS1iYXNlZCBtYW5hZ2VtZW50IHdoaWNoIGRlYWxzIHdpdGgg YWJvdmUgaXNzdWVzLg0KDQozKSAiT1NTOk9wZXJhdGlvbnMvT3BlcmF0aW9uYWwgU3VwcG9ydCBT eXN0ZW0sIGFyZSBjb21wdXRlciBzeXN0ZW1zIiBzaG91bGQgYmUgIk9TUzogT3BlcmF0aW9ucy9P cGVyYXRpb25hbCBTdXBwb3J0IFN5c3RlbXMsIGFyZSBjb21wdXRlciBzeXN0ZW1zIi4NCg0KNCkg IkltcGVyYXRpdmUgcG9saWN5IHJ1bGVzIHJlcXVpcmUgYWRkaXRpb25hbCBtYW5hZ2VtZW50IGZ1 bmN0aW9ucywgd2hpY2ggYXJlIGV4cGxhaW5lZCBpbiBzZWN0aW9uIDIuMiBiZWxvdyIgbWF5IGJl ICAiSW1wZXJhdGl2ZSBwb2xpY3kgcnVsZXMgcmVxdWlyZSBhZGRpdGlvbmFsIG1hbmFnZW1lbnQg ZnVuY3Rpb25zLCB3aGljaCBhcmUgZXhwbGFpbmVkIGluIHNlY3Rpb24gMy4yIGJlbG93Ig0KDQo1 KSAiKDE6MS4ubikgaW4gKDEpIGFuZCAoMikgYmVsb3cgZmlndXJlIDMgc2hvd3Mgb25lIHBvbGlj eSBydWxlIGlzIGFibGUgdG8gbWFuYWdlcyBhbmQgY2FuIGFkanVzdCBvbmUgb3IgbXVsdGlwbGUg c2VydmljZXMvcmVzb3VyY2VzLiIgbWF5IGJlICIoMToxLi5uKSBpbiAoMSkgYW5kICgyKSBiZWxv dyBmaWd1cmUgMyBzaG93IG9uZSBwb2xpY3kgcnVsZSBpcyBhYmxlIHRvIG1hbmFnZSBhbmQgYWRq dXN0IG9uZSBvciBtdWx0aXBsZSBzZXJ2aWNlcy9yZXNvdXJjZXMuIiA/DQoNCjYpICJUaGUgT3Bl cmF0b3IgYWN0b3Igc2hvd24gY2FuIGludGVyYWN0IHdpdGggU1VQQSBpbiBvdGhlciB3YXlzIG5v dCBzaG93biBpbiBGaWd1cmUgMSIgbWF5IGJlICJUaGUgT3BlcmF0b3IgYWN0b3IsIHNob3duIGlu IGZpZ3VyZSAxLCBjYW4gaW50ZXJhY3Qgd2l0aCBTVVBBIGluIG90aGVyIHdheXMgbm90IHNob3du IGluIEZpZ3VyZSAxIg0KW1dpbGxdIEFsbCB0aGUgYWJvdmUgYXJlIGZpeGVkLg0KDQpSZWdhcmRz LA0KV2lsbA0KDQo= --_000_C9B5F12337F6F841B35C404CF0554ACB8A34CEA1dggeml510mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVC My0xMWQxLUEyOUYtMDBBQTAwQzE0ODgyIiB4bWxuczptPSJodHRwOi8vc2NoZW1hcy5taWNyb3Nv ZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9S RUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250 ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBj b250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8c3R5bGU+PCEt LQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTrlrovk vZM7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0K QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIg MiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxA5a6L5L2TIjsNCglwYW5v c2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1z b05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFy Z2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1NjNDMTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Izk1NEY3MjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xp c3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGNtOw0K CW1hcmdpbi1yaWdodDowY207DQoJbWFyZ2luLWJvdHRvbTowY207DQoJbWFyZ2luLWxlZnQ6MzYu MHB0Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIu MHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7fQ0KZGl2LldvcmRTZWN0 aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4N CjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlv dXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286 c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1V UyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rp b24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij5IaSBZYW5neWFuZyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi Pk1hbnkgdGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzLiBTb21lIHJlc3BvbnNlcyBiZWxvdyBpbmxp bmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5n OjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IFlhbmd5YW5nIFdhbmcgW21h aWx0bzp3eXlzdGFyQGdtYWlsLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBTdW5kYXksIEp1bHkg MDksIDIwMTcgMTE6NTkgQU08YnI+DQo8Yj5Ubzo8L2I+IHN1cGFAaWV0Zi5vcmc8YnI+DQo8Yj5D Yzo8L2I+IExpdXNodWNoZW5nIChXaWxsIExpdSkgJmx0O2xpdXNodWNoZW5nQGh1YXdlaS5jb20m Z3Q7OyBKdW4gQmkgJmx0O2p1bmJpQHRzaW5naHVhLmVkdS5jbiZndDs8YnI+DQo8Yj5TdWJqZWN0 OjwvYj4gcmV2aWV3IGZvciBkcmFmdC1pZXRmLXN1cGEtcG9saWN5LWJhc2VkLW1hbmFnZW1lbnQt ZnJhbWV3b3JrLTAyPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkkgaGF2ZSByZXZpZXdlZCZuYnNwOyZuYnNwO2RyYWZ0LWlldGYtc3VwYS1wb2xp Y3ktYmFzZWQtbWFuYWdlbWVudC1mcmFtZXdvcmsuIE15IGNvbW1lbnRzIGFyZSBhcyBmb2xsb3dz OjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MSkgVGhpcyBk cmFmdCBjb250YWlucyBtYW55IGNvbmNlcHRzIHRoYXQgYXJlIHZlcnkgYWJzdHJhY3QuIEkgc3Vn Z2VzdCB0aGlzIGRyYWZ0IG1heSBicmllZmx5IGRlc2NyaWJlIHRoZSBjb250ZW50cyBhbmQgdGhl IGdvYWwgJm5ic3A7b2YgdGhpcyBkcmFmdCBhbmQgaXRzIHNpZ25pZmljYW5jZS4gU29tZSBzaW1w bGUgYW5kIGNvbmNyZXRlIGluc3RhbmNlcyBjYW4gYmUgYWRkZWQgaW4gdGhlIGRlc2NyaXB0aW9u cyBvZg0KIHRoZSBtYW5hZ2VtZW50IGZyYW1ld29yayB0byBoZWxwIGNsYXJpZnkgdGhlIGFic3Ry YWN0IGNvbmNlcHRzIGFuZCBmcmFtZXdvcmsgaW4gdGhpcyBkcmFmdC48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj5bV2lsbF0gVGhlIGdvYWwgb2YgdGhpcyBkcmFmdCBpcyBkZXNjcmli aW5nIHRoZSBTVVBBIGJhc2ljIGZyYW1ld29yaywgaXRzIGVsZW1lbnRzIGFuZCBpbnRlcmZhY2Vz LiBJIGd1ZXNzIHlvdSB3YW50ZWQgdG8gYXNrIGFib3V0IHRoZSBnb2FsIG9mIFNVUEE/IFRoZQ0K IFNVUEEgd29ya2luZyBncm91cCBkZWZpbmVzIGEgZGF0YSBtb2RlbCwgdG8gYmUgdXNlZCB0byBy ZXByZXNlbnQgaGlnaC1sZXZlbCwgcG9zc2libHkgbmV0d29yay13aWRlIHBvbGljaWVzLCB3aGlj aCBjYW4gYmUgaW5wdXQgdG8gYSBuZXR3b3JrIG1hbmFnZW1lbnQgZnVuY3Rpb24gKHdpdGhpbiBh IGNvbnRyb2xsZXIsIGFuIG9yY2hlc3RyYXRvciwgb3IgYSBuZXR3b3JrIGVsZW1lbnQpLiBQcm9j ZXNzaW5nIHRoYXQgaW5wdXQgbW9zdCBwcm9iYWJseQ0KIHJlc3VsdHMgaW4gbmV0d29yayBjb25m aWd1cmF0aW9uIGNoYW5nZXMuPG86cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+U29tZSBz aW1wbGUgaW5zdGFuY2VzIHdpbGwgYmUgYWRkZWQgYW5kIGFsc28gcmVmZXIgdG8gdGhlIGFwcGxp Y2FiaWxpdHkgZHJhZnQgW0ktRC5jaGVuZy1zdXBhLWFwcGxpY2FiaWxpdHldLg0KPG86cD48L286 cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9pPjwvYj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4yKSAmcXVvdDtUcmFmZmlj IGZsb3cgb3ZlciBpbmNyZWFzaW5nbHkgY29tcGxleCBlbnRlcnByaXNlIGFuZCBzZXJ2aWNlIHBy b3ZpZGVyIG5ldHdvcmsgYmVjb21lcyBtb3JlIGFuZCBtb3JlIGltcG9ydGFudCZxdW90OyBtYXkg YmUgY2hhbmdlIHRvICZxdW90O1RoZSBtYW5hZ2VtZW50IG9mIFRyYWZmaWMgZmxvdyBvdmVyIGlu Y3JlYXNpbmdseSBjb21wbGV4IGVudGVycHJpc2UgYW5kIHNlcnZpY2UgcHJvdmlkZXIgbmV0d29y ayBiZWNvbWVzDQogbW9yZSBhbmQgbW9yZSBpbXBvcnRhbnQgPzxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPltX aWxsXSBObyBleGFjdGx5LiAmbmJzcDtIZXJlIHdlIG1lYW4gZmlyc3RseSB0aGUgdHJhZmZpYyBp cyBtb3JlIGFuZCBtb3JlIGltcG9ydGFudCwgc2Vjb25kIHRoZSB2YXJpZXR5IG1ha2VzIGRlcGxv eWluZyBuZXcgc2VydmljZSBtb3JlIGRpZmZpY3VsdCwgbGVhZGluZw0KIHRvIHRoZSBtZWNoYW5p c21zIG9mIHBvbGljeS1iYXNlZCBtYW5hZ2VtZW50IHdoaWNoIGRlYWxzIHdpdGggYWJvdmUgaXNz dWVzLjwvc3Bhbj48L2k+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjMp ICZxdW90O09TUzpPcGVyYXRpb25zL09wZXJhdGlvbmFsIFN1cHBvcnQgU3lzdGVtLCBhcmUgY29t cHV0ZXIgc3lzdGVtcyZxdW90OyBzaG91bGQgYmUgJnF1b3Q7T1NTOiBPcGVyYXRpb25zL09wZXJh dGlvbmFsIFN1cHBvcnQgU3lzdGVtcywgYXJlIGNvbXB1dGVyIHN5c3RlbXMmcXVvdDsuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjQpICZxdW90 O0ltcGVyYXRpdmUgcG9saWN5IHJ1bGVzIHJlcXVpcmUgYWRkaXRpb25hbCZuYnNwO21hbmFnZW1l bnQgZnVuY3Rpb25zLCB3aGljaCBhcmUgZXhwbGFpbmVkIGluIHNlY3Rpb24gMi4yIGJlbG93JnF1 b3Q7IG1heSBiZSAmbmJzcDsmcXVvdDtJbXBlcmF0aXZlIHBvbGljeSBydWxlcyByZXF1aXJlIGFk ZGl0aW9uYWwmbmJzcDttYW5hZ2VtZW50IGZ1bmN0aW9ucywgd2hpY2ggYXJlIGV4cGxhaW5lZCBp biBzZWN0aW9uIDMuMiBiZWxvdyZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj41KSAmcXVvdDsoMToxLi5uKSBpbiAoMSkmbmJzcDthbmQg KDIpIGJlbG93IGZpZ3VyZSAzIHNob3dzIG9uZSBwb2xpY3kgcnVsZSBpcyBhYmxlIHRvIG1hbmFn ZXMgYW5kJm5ic3A7Y2FuIGFkanVzdCBvbmUgb3IgbXVsdGlwbGUgc2VydmljZXMvcmVzb3VyY2Vz LiZxdW90OyBtYXkgYmUgJnF1b3Q7KDE6MS4ubikgaW4gKDEpJm5ic3A7YW5kICgyKSBiZWxvdyBm aWd1cmUgMyBzaG93IG9uZSBwb2xpY3kgcnVsZSBpcyBhYmxlIHRvIG1hbmFnZSBhbmQgYWRqdXN0 IG9uZQ0KIG9yIG11bHRpcGxlIHNlcnZpY2VzL3Jlc291cmNlcy4mcXVvdDsgPzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj42KSAmcXVvdDtUaGUg T3BlcmF0b3IgYWN0b3Igc2hvd24gY2FuIGludGVyYWN0IHdpdGgmbmJzcDtTVVBBIGluIG90aGVy IHdheXMgbm90IHNob3duIGluIEZpZ3VyZSAxJnF1b3Q7IG1heSBiZSAmcXVvdDtUaGUgT3BlcmF0 b3IgYWN0b3IsIHNob3duIGluIGZpZ3VyZSAxLCBjYW4gaW50ZXJhY3Qgd2l0aCZuYnNwO1NVUEEg aW4gb3RoZXIgd2F5cyBub3Qgc2hvd24gaW4gRmlndXJlIDEmcXVvdDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJj b2xvcjojMUY0OTdEIj5bV2lsbF0gPC9zcGFuPjwvaT48L2I+PHNwYW4gc3R5bGU9ImNvbG9yOiMx RjQ5N0QiPkFsbCB0aGUgYWJvdmUgYXJlIGZpeGVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5SZWdhcmRzLDxvOnA+PC9vOnA+ PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPldpbGw8bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_C9B5F12337F6F841B35C404CF0554ACB8A34CEA1dggeml510mbxchi_-- From nobody Mon Jul 17 22:34:01 2017 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 B44A012706D for ; Mon, 17 Jul 2017 22:34:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 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_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz 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 89sXDDwFmtt2 for ; Mon, 17 Jul 2017 22:33:58 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43751120227 for ; Mon, 17 Jul 2017 22:33:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1500356038; x=1531892038; h=to:from:subject:message-id:date:mime-version: content-transfer-encoding; bh=Cl20l59DRokmJWIIP+odEXDnnAswXMfq9ZxcfAZRvn8=; b=KuozdDkh+2al+ZOqDPQi9LsdNUhX612UY47AJ+vUJOuWMDEuVUIyHwCH 5RycecJSJvs6ckzxc0nsjA5k8VemW2nyAaUie/LrlFWoI60VRj9jtUahg xc373ljTkKEjB/j2QDd4vS8XW+c9k9ZffyVbBgZpN5tHUWXcUP8yCyOd5 Qta6d0VaX7dtHU09CTQ5xa3rrt9WVwn84e4/bkqAN33bdKQ/iIUhz/Js+ el+qNNetQLKY5qKGiIBoPPem8oAwM1Nyjkx8sRl5dBb/6pACox4AnXy4J AitUMaZQHZMOYJ9A6qzfyBEmgm0tITE72gqS72bqura3QoiouXlPbH02B Q==; X-IronPort-AV: E=Sophos;i="5.40,376,1496059200"; d="scan'208";a="166206440" X-Ironport-HAT: BAD-REPUTATION - $RELAY-AUTH-THROTTLE X-Ironport-Source: 88.208.109.142 - Outgoing - Outgoing-SSL Received: from unknown (HELO [192.168.11.250]) ([88.208.109.142]) by mx4-int.auckland.ac.nz with ESMTP; 18 Jul 2017 17:33:53 +1200 To: SUPA list From: Nevil Brownlee Message-ID: <83a7e5d3-47f4-271f-c19b-178d5537ea85@auckland.ac.nz> Date: Tue, 18 Jul 2017 17:33:41 +1200 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Supa] WG Last Call started for SUPA Framework draft version -03 X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.22 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: Tue, 18 Jul 2017 05:34:01 -0000 Hi SUPA folk: A new revision of the SUPA Framework draft has just been posted. This version addresses all reviewer concerns to date, so we've started a two-week WG Last Call for it. Please take another look at it, and send coments to the SUPA list. Even a brief "I agree with pubishing" note is useful at this stage! Cheers, Nevil -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand From nobody Tue Jul 18 07:03:54 2017 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 7E89412F3CB for ; Tue, 18 Jul 2017 07:03:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 GwN7p2Fldl-5 for ; Tue, 18 Jul 2017 07:03:51 -0700 (PDT) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A837A12EC36 for ; Tue, 18 Jul 2017 07:03:51 -0700 (PDT) Received: by mail-oi0-x229.google.com with SMTP id q4so17868663oif.1 for ; Tue, 18 Jul 2017 07:03:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UzS6q150I+ali575QVgffl4UV1vmN1xA8fnYpTwvY0Q=; b=Wwhq4ZsUYVGge/299cuJzq81YeOb4vMNDW7WvN4336t5O2+CM9zcvh56OP1RMlGBxv IR8Ewj4w6rv3NusyS5xYdj9JUa51TjBF6NrY+NltmRRHGkqAFz0kVEDhd2/IdVXbG+bn kQ5aBakHRkChiyeqBfkPIaHmkmY0lLt+xVXRuplJPn2fqB+M8sfFVE17TEFachXkTOCd hVOPyubUyLHcSQXm1maLvox4pxs0EDjbZVhGhhntUUEp9MyJahdb4LFGX4PTt0skilwA D+VI1Mp3kgILoErB3Qs2VnQW0rPNrT/YUJWvVc0wfnNQ+fnEcQMOM8vyR5QQLY7pE6zH 0Ofg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UzS6q150I+ali575QVgffl4UV1vmN1xA8fnYpTwvY0Q=; b=XsjsgAJ1HavuY+HvrLLhii8GzMARTurzRWAKQh30z0T8wmvnxGaF5XHGIOgcXNANLZ OykGAhV9XB5b41slKowuehjnEuHsVtZPetH5fVCQxh/StRvOBr8TZ7ji+epnfATi3xg3 99/xm+iQ/UUaUIxdD5jOaXM9yYNgUCFB19aHa+0zQiPk190roAABW6KOplzF1drk5YXd K725glDSBfDsZu13c1tiXwSisO+SUKkntv4C1ALlnA7RIpiewgOf5vlpQU/NVfBVAykR uEtn2wQf53nvxt9p9Kdch9n6+qodvQIoWztyykeJqtxtAWHd9RUVuU7x5NFeTvuzqUuR 47ZQ== X-Gm-Message-State: AIVw110jeZs8X9kMQFDs2A2DZMqvoVvwkytLjnwq0kEk+uIEQYguFwIJ wZfyWhbBn4dfIs4eDEcQlYtxjZ2vVA== X-Received: by 10.202.192.11 with SMTP id q11mr1341829oif.228.1500386630945; Tue, 18 Jul 2017 07:03:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.161.19 with HTTP; Tue, 18 Jul 2017 07:03:50 -0700 (PDT) In-Reply-To: <83a7e5d3-47f4-271f-c19b-178d5537ea85@auckland.ac.nz> References: <83a7e5d3-47f4-271f-c19b-178d5537ea85@auckland.ac.nz> From: Yangyang Wang Date: Tue, 18 Jul 2017 22:03:50 +0800 Message-ID: To: Nevil Brownlee Cc: SUPA list Content-Type: multipart/alternative; boundary="001a113dbbe229d444055497fc97" Archived-At: Subject: Re: [Supa] WG Last Call started for SUPA Framework draft version -03 X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.22 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: Tue, 18 Jul 2017 14:03:53 -0000 --001a113dbbe229d444055497fc97 Content-Type: text/plain; charset="UTF-8" Dear all, After double review of this version, I see my previous comments are addressed. I do think it is ready for a WGLC. Best regards Yangyang 2017/7/18 On Tue, Jul 18, 2017 at 1:33 PM, Nevil Brownlee wrote: > > Hi SUPA folk: > > A new revision of the SUPA Framework draft has just been posted. > This version addresses all reviewer concerns to date, so we've started > a two-week WG Last Call for it. > > Please take another look at it, and send coments to the SUPA list. > Even a brief "I agree with pubishing" note is useful at this stage! > > Cheers, Nevil > > -- > --------------------------------------------------------------------- > Nevil Brownlee Computer Science Department | ITS > Phone: +64 9 373 7599 x88941 The University of Auckland > FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand > > _______________________________________________ > SUPA mailing list > SUPA@ietf.org > https://www.ietf.org/mailman/listinfo/supa > --001a113dbbe229d444055497fc97 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear all,


After double review of this version, I see my previous comment= s are addressed. I do think it is ready for a WGLC.



Best regards

=
Yangyang
2017/7/18


On Tue, Jul 18, 2017= at 1:33 PM, Nevil Brownlee <n.brownlee@auckland.ac.nz> wrote:

Hi SUPA folk:

A new revision of the SUPA Framework draft has just been posted.
This version addresses all reviewer concerns to date, so we've started<= br> a two-week WG Last Call for it.

Please take another look at it, and send coments to the SUPA list.
Even a brief "I agree with pubishing" note is useful at this stag= e!

Cheers, Nevil

--
-----------------------------------------------------------------= ----
=C2=A0Nevil Brownlee=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 Computer Science Department | ITS
=C2=A0Phone: +64 9 373 7599 x88941=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0The University of Auckland
=C2=A0FAX: +64 9 373 7453=C2=A0 =C2=A0Private Bag 92019, Auckland 1142, New= Zealand

_______________________________________________
SUPA mailing list
SUPA@ietf.org
https://www.ietf.org/mailman/listinfo/supa

--001a113dbbe229d444055497fc97-- From nobody Tue Jul 18 19:03:43 2017 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 93F331274D2 for ; Tue, 18 Jul 2017 19:03:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.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 sNHl7LAZEvDn for ; Tue, 18 Jul 2017 19:03:40 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 7E2D8126DFF for ; Tue, 18 Jul 2017 19:03:39 -0700 (PDT) X-AuditID: c1b4fb25-607ff70000001eeb-bd-596ebdf9060e Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id AD.B0.07915.9FDBE695; Wed, 19 Jul 2017 04:03:37 +0200 (CEST) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.69) with Microsoft SMTP Server (TLS) id 14.3.352.0; Wed, 19 Jul 2017 04:02:38 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=XFLSATdqldcRa0nyKopSDmrcw719/SjD5nji4oddm3o=; b=PqGXVqXNpN6fy8WJHxPFCS+BbmJftSnwY1RJK6PZSecKHiQ8kLkZXJOf3Un966Ms5zdJdpaENfHTrzdCU3EUCVI9m/LCFZrrDyWwe2hSlrvc/oD/1L6NMhlMaiJy2kcPunhg5YLZozbAG6Y+de58s6t108frSGQVMO+iyrEynak= Received: from DBXPR07MB238.eurprd07.prod.outlook.com (10.141.11.15) by DBXPR07MB109.eurprd07.prod.outlook.com (10.242.138.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.4; Wed, 19 Jul 2017 02:02:37 +0000 Received: from DBXPR07MB238.eurprd07.prod.outlook.com ([fe80::78be:9673:776c:815c]) by DBXPR07MB238.eurprd07.prod.outlook.com ([fe80::78be:9673:776c:815c%15]) with mapi id 15.01.1282.011; Wed, 19 Jul 2017 02:02:37 +0000 From: Gunter Wang To: "supa@ietf.org" Thread-Topic: =?gb2312?B?UkWjultTdXBhXSBXRyBMYXN0IENhbGwgc3RhcnRlZCBmb3IgU1VQQSBGcmFt?= =?gb2312?Q?ework_draft_version_-03?= Thread-Index: AdMAMsew+nV04/nlTayzw5AujggO+g== Date: Wed, 19 Jul 2017 02:02:37 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [183.240.196.24] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DBXPR07MB109; 7:9tHOQFzwBEcvVXBWSqHLQyQFjlL3HEx5lF74R1BHsiNkVcs4O0oFZ++jHQsGNkPyfIjdntmzNLqYnxsBQS373VpMk/XGO8Z1AAPngT/YgqPOO4RNTCFa8ec8JcSAWgB3pLozfaMrNpqwSu8xrSqTBBhL5ZclNwG8CeMEE2l7aXALjMIjKJe3GLVhCSkseG3fGp5rIetXjBNnm5KYJCv0s6ViJ51LBDuaO72totTuH3VU2g9aKt9bqsD8FMp83qvWZBt1CWsi1CID9pV9taeA2xk3zQSkN2KmcRA/yt8tkimvOi4Z7JoGmJn27t5cNprdCn/++bREpMLbHRoqFwtpBaqiAbsoTpj0jB9GQNWF6mIwhx050+oZe0obd4hebPwqSyYpraeI9EyoYeaK4Mt5Rj5zamAPS5Sa0YLla5cQBvmGDo3dEyTZqXe9wW4CqUxizNj5nOkgZI8KBNwR4Lc2Fv+2AA00ZbLsijM5SEG6fRL7cXR/mgqjJklWaXXewJJF8h2rKPe0el2ZOcsYHZ8Mz/E2u3vsHlQO53db4KtqyjIAoSUwFbFvMjlysXJxVPTfJuN8ypGIJ5XK9TdmQ/9ZCNtRFJsKHlgmKpDleAPT25Vx8mXHWKRMHYnebquWH6+NZAn7WZOOYp8Q3SJzVN5PZ2ql0x5hzfoZ8hehJoAl9yJTcqUnrBTLXXXurbK5w+lPUaWvUD+pmAoGVyjAjC/d62C81UPSMvRH4oIm/a7TOVCszs35Rjmw6yx9fcIvxU1szqBPZjU5ycWIcVfUVz1uGBdaWsEjEqu+ZL53jXuY1qs= x-ms-office365-filtering-correlation-id: a5866b44-f85e-475c-007f-08d4ce4a3aca x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DBXPR07MB109; x-ms-traffictypediagnostic: DBXPR07MB109: x-exchange-antispam-report-test: UriScan:(151999592597050)(278178393323532)(26388249023172)(236129657087228)(148574349560750)(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(2017060910075)(93006095)(93001095)(10201501046)(100000703101)(100105400095)(3002001)(6041248)(20161123564025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123560025)(20161123562025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DBXPR07MB109; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DBXPR07MB109; x-forefront-prvs: 0373D94D15 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39410400002)(39450400003)(39840400002)(39400400002)(39850400002)(377454003)(13464003)(50986999)(54356999)(6506006)(2900100001)(3660700001)(25786009)(53546010)(7736002)(33656002)(5250100002)(5640700003)(2501003)(189998001)(66066001)(478600001)(86362001)(6436002)(2906002)(966005)(102836003)(99286003)(54896002)(790700001)(3846002)(53936002)(5630700001)(6116002)(55016002)(9686003)(3280700002)(2351001)(74316002)(110136004)(8936002)(6306002)(1730700003)(38730400002)(6916009)(7696004)(5660300001)(14454004)(16234385003)(81166006); DIR:OUT; SFP:1101; SCL:1; SRVR:DBXPR07MB109; H:DBXPR07MB238.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DBXPR07MB238003EB97C95913CC6128687A60DBXPR07MB238eurprd_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jul 2017 02:02:37.2539 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBXPR07MB109 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SbUhTYRTHe+69u7uOBrepeDDtZWGhrmUl0geJDHojhEoN9YtOvczZnLYt y4SYX2y6sjI30oHOGEZSmkvTTIOWomYwqSnMnGIuKy1WlKhp2q53gd9+5/z+PM85Dw+Fiyy8 UEqh0jJqlUwpJgVETWrHsb1LPaq0mNKJwEPmtib8CDpptS5hZ1C6ID6HUSqKGPW+w5mC3DHT A6LQcfqKdeQOX4fKj1egAAroWDB7XXgFElAiuheBbWiF4IoBBPa6ZpItCPomDqN90yRnqjGY WXvN44opBEODKz5DUSQtgZbWcPbcIHoX3Gs281gOpIvhw+IjxPWvwRujGatAfB9LoWo32yXo CHjydJFkWUinw9uGNj7LiA4H08dJjGWcDoExTz3GTU2DtduBcxwMX6dX16dBtAHBj7pRf0gM +i4L4jgc3tUbEBsCepKEvl6vP5QIw54bJCeGMZjuZ/dnRSQM6UcITlQi+PR7lM8JBdwvs+Gc cPDghavHf0cYNC50+dnJg1v9O7j1Q8HtLEcch8GX8R4et1ABuEwd2G20p3bDfrUbVO36e2yB wRoPwfWjoE637M/shGrDFJ/jSHDetfs5Ghob5nAL4jehYA2jycqXHzgoZdSKbI2mQCVVMVob 8v2bV23LEZ3o/bcEO6IpJN4spH1/SMSTFWmK8+0IKFwcJCzt9rWEObLiq4y6IEN9Sclo7Ggr RYhDhAkvh1NFtFymZS4wTCGj/m8xKiBUhzYlt4xJLOe/p8V1Lsybgv64UpKVz4y/WmMzJ7al yMs9wfF6d0zqrP1yfqM3RlDW4c4q0cd6/56ixPLZ3DJ3XOLZ7Q9nrs/b2ot0TF4YuTZucFe1 r1CfJatzdulAXmvAapLBmu2VPHee+92gzTA+1ppO/CxxXDRW4tFHQ7xJYkKTK9sfhas1sn89 Ham3MwMAAA== Archived-At: Subject: [Supa] =?gb2312?b?UkWjuiBXRyBMYXN0IENhbGwgc3RhcnRlZCBmb3IgU1VQ?= =?gb2312?b?QSBGcmFtZXdvcmsgZHJhZnQgdmVyc2lvbiAtMDM=?= X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.22 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: Wed, 19 Jul 2017 02:03:42 -0000 --_000_DBXPR07MB238003EB97C95913CC6128687A60DBXPR07MB238eurprd_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 DQpJIGRpZCBhIHRob3JvdWdoIHJldmlldyBvZiB0aGlzIGRvY3VtZW50IGEgd2hpbGUgYWdvLiBU aGUgbmV3IHZlcnNpb24gYWRkcmVzc2VkIG15IHByZXZpb3VzIGNvbW1lbnRzIGFuZCBJIHRoaW5r IHRoaXMgZG9jdW1lbnQgaXMgbm93IHJlYWR5IGZvciBwdWJsaWNhdGlvbi4NCg0KDQotLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogU1VQQSBbbWFpbHRvOnN1cGEtYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmIE9mIE5ldmlsIEJyb3dubGVlDQpTZW50OiBUdWVzZGF5LCBKdWx5IDE4 LCAyMDE3IDc6MzQgQU0NClRvOiBTVVBBIGxpc3QgPHN1cGFAaWV0Zi5vcmc+DQpTdWJqZWN0OiBb U3VwYV0gV0cgTGFzdCBDYWxsIHN0YXJ0ZWQgZm9yIFNVUEEgRnJhbWV3b3JrIGRyYWZ0IHZlcnNp b24gLTAzDQoNCg0KSGkgU1VQQSBmb2xrOg0KDQpBIG5ldyByZXZpc2lvbiBvZiB0aGUgU1VQQSBG cmFtZXdvcmsgZHJhZnQgaGFzIGp1c3QgYmVlbiBwb3N0ZWQuDQpUaGlzIHZlcnNpb24gYWRkcmVz c2VzIGFsbCByZXZpZXdlciBjb25jZXJucyB0byBkYXRlLCBzbyB3ZSd2ZSBzdGFydGVkIGEgdHdv LXdlZWsgV0cgTGFzdCBDYWxsIGZvciBpdC4NCg0KUGxlYXNlIHRha2UgYW5vdGhlciBsb29rIGF0 IGl0LCBhbmQgc2VuZCBjb21lbnRzIHRvIHRoZSBTVVBBIGxpc3QuDQpFdmVuIGEgYnJpZWYgIkkg YWdyZWUgd2l0aCBwdWJpc2hpbmciIG5vdGUgaXMgdXNlZnVsIGF0IHRoaXMgc3RhZ2UhDQoNCkNo ZWVycywgTmV2aWwNCg0KLS0NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICBOZXZpbCBCcm93bmxlZSAgICAgICAg ICAgICAgICAgICAgQ29tcHV0ZXIgU2NpZW5jZSBEZXBhcnRtZW50IHwgSVRTDQogIFBob25lOiAr NjQgOSAzNzMgNzU5OSB4ODg5NDEgICAgICAgICAgICAgVGhlIFVuaXZlcnNpdHkgb2YgQXVja2xh bmQNCiAgRkFYOiArNjQgOSAzNzMgNzQ1MyAgIFByaXZhdGUgQmFnIDkyMDE5LCBBdWNrbGFuZCAx MTQyLCBOZXcgWmVhbGFuZA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KU1VQQSBtYWlsaW5nIGxpc3QNClNVUEFAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3VwYQ0K --_000_DBXPR07MB238003EB97C95913CC6128687A60DBXPR07MB238eurprd_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

 

I did a thorough review of this docu= ment a while ago. The new version addressed my previous comments and I thin= k this document is now ready for publication.

 

 

-----Original Message-----

From: SUPA [mailto:supa-bounces@ietf= .org] On Behalf Of Nevil Brownlee

Sent: Tuesday, July 18, 2017 7:34 AM=

To: SUPA list <supa@ietf.org><= o:p>

Subject: [Supa] WG Last Call started= for SUPA Framework draft version -03

 

 

Hi SUPA folk:

 

A new revision of the SUPA Framework= draft has just been posted.

This version addresses all reviewer = concerns to date, so we've started a two-week WG Last Call for it.

 

Please take another look at it, and = send coments to the SUPA list.

Even a brief "I agree with pubi= shing" note is useful at this stage!

 

Cheers, Nevil

 

--

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

  Nevil Brownlee  &nb= sp;            =      Computer Science Department | ITS

  Phone: +64 9 373 7599 x88= 941            = The University of Auckland

  FAX: +64 9 373 7453 =   Private Bag 92019, Auckland 1142, New Zealand

 

____________________________________= ___________

SUPA mailing list<= /p>

SUPA@ietf.org

https://www.ietf.org/mailman/listinf= o/supa

--_000_DBXPR07MB238003EB97C95913CC6128687A60DBXPR07MB238eurprd_-- From nobody Thu Jul 20 15:06:23 2017 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 21A26129AB2 for ; Thu, 20 Jul 2017 15:06:22 -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, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 4Zlj_YiBoN0G for ; Thu, 20 Jul 2017 15:06:19 -0700 (PDT) Received: from chinatelecom.cn (prt-mail.chinatelecom.cn [42.123.76.222]) by ietfa.amsl.com (Postfix) with ESMTP id B0D6F13178E for ; Thu, 20 Jul 2017 15:06:15 -0700 (PDT) HMM_SOURCE_IP: 172.18.0.80:32517.2123452144 HMM_ATTACHE_NUM: 0000 HMM_SOURCE_TYPE: SMTP Received: from clientip-125.33.65.81 (unknown [172.18.0.80]) by chinatelecom.cn (HERMES) with ESMTP id A1178280029 for ; Fri, 21 Jul 2017 06:06:11 +0800 (CST) Received: from ip<125.33.65.81> ([172.18.0.80]) by App0022 with ESMTP id 49865c50-74b7-4980-8628-9b0a4bd8ecf8 for supa@ietf.org; Fri Jul 21 06:06:12 2017 0/X-Total-Score: 0: X-Real-From: xiechf.bri@chinatelecom.cn X-Receive-IP: 172.18.0.80 X-MEDUSA-Status: 0 Date: Fri, 21 Jul 2017 06:06:07 +0800 From: "xiechf.bri@chinatelecom.cn" To: supa References: X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7, 2, 8, 379[cn] Mime-Version: 1.0 Message-ID: <201707210606071825500@chinatelecom.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart230625180152_=----" Archived-At: Subject: [Supa] =?gb2312?b?u9i4tDogUkWjuiBXRyBMYXN0IENhbGwgc3RhcnRlZCBm?= =?gb2312?b?b3IgU1VQQSBGcmFtZXdvcmsgZHJhZnQgdmVyc2lvbiAtMDM=?= X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.22 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: Thu, 20 Jul 2017 22:06:22 -0000 This is a multi-part message in MIME format. ------=_001_NextPart230625180152_=---- Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 VGhhbmtzIGZvciBHdW50ZXKhr3MgcmV2aWV3IGFuZCBzdXBwb3J0LiAgQXMgYSBjby1hdXRob3Ig YW5kIGFuIG9wZXJhdG9yIHdobyB3b3VsZCBsaWtlIHRvIHRyeSBTVVBBIGluIG91ciBmdXR1cmUg bWFuYWdlbWVudCBzeXN0ZW0sIEkgc3VwcG9ydCB0aGUgcHVibGljYXRpb24gZm9yIHRoaXMgZG9j dW1lbnQgYW5kIGFjY2VsZXJhdGUgdGhlIHByb2dyZXNzIG9mIG90aGVyIFNVUEEgZG9jdW1lbnRz LiAgDQoNCkNob25nZmVuZw0KDQoNCg0KeGllY2hmLmJyaUBjaGluYXRlbGVjb20uY24NCiANCrei vP7Iy6O6IEd1bnRlciBXYW5nDQq3osvNyrG85KO6IDIwMTctMDctMTkgMTA6MDINCsrVvP7Iy6O6 IHN1cGFAaWV0Zi5vcmcNCtb3zOKjuiBSRaO6W1N1cGFdIFdHIExhc3QgQ2FsbCBzdGFydGVkIGZv ciBTVVBBIEZyYW1ld29yayBkcmFmdCB2ZXJzaW9uIC0wMw0KIA0KSSBkaWQgYSB0aG9yb3VnaCBy ZXZpZXcgb2YgdGhpcyBkb2N1bWVudCBhIHdoaWxlIGFnby4gVGhlIG5ldyB2ZXJzaW9uIGFkZHJl c3NlZCBteSBwcmV2aW91cyBjb21tZW50cyBhbmQgSSB0aGluayB0aGlzIGRvY3VtZW50IGlzIG5v dyByZWFkeSBmb3IgcHVibGljYXRpb24uDQogDQogDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KRnJvbTogU1VQQSBbbWFpbHRvOnN1cGEtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m IE5ldmlsIEJyb3dubGVlDQpTZW50OiBUdWVzZGF5LCBKdWx5IDE4LCAyMDE3IDc6MzQgQU0NClRv OiBTVVBBIGxpc3QgPHN1cGFAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbU3VwYV0gV0cgTGFzdCBDYWxs IHN0YXJ0ZWQgZm9yIFNVUEEgRnJhbWV3b3JrIGRyYWZ0IHZlcnNpb24gLTAzDQogDQogDQpIaSBT VVBBIGZvbGs6DQogDQpBIG5ldyByZXZpc2lvbiBvZiB0aGUgU1VQQSBGcmFtZXdvcmsgZHJhZnQg aGFzIGp1c3QgYmVlbiBwb3N0ZWQuDQpUaGlzIHZlcnNpb24gYWRkcmVzc2VzIGFsbCByZXZpZXdl ciBjb25jZXJucyB0byBkYXRlLCBzbyB3ZSd2ZSBzdGFydGVkIGEgdHdvLXdlZWsgV0cgTGFzdCBD YWxsIGZvciBpdC4NCiANClBsZWFzZSB0YWtlIGFub3RoZXIgbG9vayBhdCBpdCwgYW5kIHNlbmQg Y29tZW50cyB0byB0aGUgU1VQQSBsaXN0Lg0KRXZlbiBhIGJyaWVmICJJIGFncmVlIHdpdGggcHVi aXNoaW5nIiBub3RlIGlzIHVzZWZ1bCBhdCB0aGlzIHN0YWdlIQ0KIA0KQ2hlZXJzLCBOZXZpbA0K IA0KLS0NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KICBOZXZpbCBCcm93bmxlZSAgICAgICAgICAgICAgICAgICAg Q29tcHV0ZXIgU2NpZW5jZSBEZXBhcnRtZW50IHwgSVRTDQogIFBob25lOiArNjQgOSAzNzMgNzU5 OSB4ODg5NDEgICAgICAgICAgICAgVGhlIFVuaXZlcnNpdHkgb2YgQXVja2xhbmQNCiAgRkFYOiAr NjQgOSAzNzMgNzQ1MyAgIFByaXZhdGUgQmFnIDkyMDE5LCBBdWNrbGFuZCAxMTQyLCBOZXcgWmVh bGFuZA0KIA0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N ClNVUEEgbWFpbGluZyBsaXN0DQpTVVBBQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3N1cGENCg== ------=_001_NextPart230625180152_=---- Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: quoted-printable =0A
=0A=0A

Hi all,


I'm glad to see that the update fixed=0Athe issues of my commen= ts. For my side, I confirm the document is ready to move=0Aforward.=


Best wishes

<= p class=3D"MsoPlainText" style=3D"margin: 0px 0cm; font-size: 10.5pt; font= -family: Calibri, sans-serif;">Tony Tina

China Mobile


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

=B7=A2=BC=FE=C8=CB: SUPA [mail= to:supa-bounces@ietf.org]=0A=B4=FA=B1=ED Nevil Brownlee
=0A=B7=A2=CB=CD=CA=B1=BC=E4: 2017=C4=EA7=D4=C218=C8=D5,= =D0=C7=C6=DA=B6=FE 13:34
=0A=CA=D5=BC=FE=C8=CB: SUPA li= st
=0A=D6=F7=CC=E2= : [Supa] WG Last Call started for SUPA=0AFrame= work draft version -03

 

 

Hi SUPA folk:

 

A new revision of the SUPA = Framework=0Adraft has just been posted.

This version addresses all reviewe= r=0Aconcerns to date, so we've started

a two-week WG Last Call for it.

 

Please take another look at it, and send=0Acoments to the SUPA list.

E= ven a brief "I agree with=0Apubishing" note is useful at this stage!<= /o:p>

=  

Cheers, Nevil

 

--

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

 =0ANev= il Brownlee     =             &n= bsp; =0AComputer Science Department | ITS

 =0APhone: +64 9 373 7599 x88941         &nbs= p;  =0AThe University of Auckland

 =0AFAX: +64 9 373 7453   Private Bag=0A92019, Auckland 1142, New Zealand

 

_______________________________________________

=

SUPA mailing list

SUP= A@ietf.org

=0A=0A=0A

https://www.ietf.org/mailman/listinfo/supa

=0A
=0A

=0A
tianxu@chinamobile.com
=0A ------=_001_NextPart587504387164_=------ From nobody Fri Jul 28 04:30:13 2017 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 63F4C1322CE for ; Fri, 28 Jul 2017 04:30:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.922 X-Spam-Level: X-Spam-Status: No, score=-0.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no 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 tf9ANY3ZwKcF for ; Fri, 28 Jul 2017 04:30:08 -0700 (PDT) Received: from sendg.mailex.chinaunicom.cn (sendg.mailex.chinaunicom.cn [210.53.66.230]) by ietfa.amsl.com (Postfix) with ESMTP id 7CC8A131897 for ; Fri, 28 Jul 2017 04:30:07 -0700 (PDT) X-AuditID: 0a000f34-f792f6d00000195d-ab-597b203de81a Received: from M10-CEN-MLHUB01.cnc.intra ( [10.0.192.41]) by sendg.mailex.chinaunicom.cn (Symantec Messaging Gateway) with SMTP id 97.0F.06493.D302B795; Fri, 28 Jul 2017 19:30:05 +0800 (HKT) Received: from M10-HQ-ML06.hq.cnc.intra (10.249.213.76) by M10-CEN-MLHUB01.cnc.intra (10.0.192.41) with Microsoft SMTP Server (TLS) id 8.3.406.0; Fri, 28 Jul 2017 19:30:04 +0800 Received: from ying-PC (10.1.8.141) by M10-HQ-ML06.hq.cnc.intra (10.249.213.76) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Fri, 28 Jul 2017 19:30:00 +0800 Date: Fri, 28 Jul 2017 19:29:55 +0800 From: =?utf-8?B?WWluZyBDaGVuZw==?= To: =?utf-8?B?TmV2aWwgQnJvd25sZWU=?= , =?utf-8?B?U1VQQSBsaXN0?= Message-ID: <201707281929553066141@chinaunicom.cn> X-mailer: Foxmail 6, 15, 201, 26 [cn] MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=====003_Dragon151401314028_=====" X-Originating-IP: [10.1.8.141] X-ClientProxiedBy: M10-HQ-MLF34.hq.cnc.intra (10.126.8.113) To M10-HQ-ML06.hq.cnc.intra (10.249.213.76) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFLMWRmVeSWpSXmKPExsXCxXBAU9dWoTrS4OtLCYvXt+4yWszesorZ gcnj9++HjB5LlvxkCmCK4rJJSc3JLEst0rdL4Mo4d28DU8GEJYwV8/ZuYmpgfDCfsYuRk0NC wERi1tcjULaYxIV769lAbCGBA4wSL3ZldTFyAdlbGSVa/7ayQiSWMEocmW0AYrMIqErcOref HcRmE7CXaNq+C6xGRCBHYumS92C2sEChxPltz1m6GDk4eAWMJL7fkYXYpSpxta2PCcTmFRCU ODnzCVgJs0CwxJzd7CCmkIC6xPJbdhDVchL/tl9lgbAzJTqndDNPYBSYhaR5FkIzhKkpsX6X PkgFs4CixJTuh+wQtoZE65y57MjiCxjZVjFyBfu6WxhbGOj6G21iBIcwv8kOxocLXQ8xCnAw KvHwPvhYGSnEmlhWXJl7iFGCg1lJhPe5bHWkEG9KYmVValF+fFFpTmrxIUZpDhYlcV7z+3mR QgLpiSWp2ampBalFMFkmDk6pBkaW029lI/ZcPXsqKWSBVbzXPHE7cSnx4n6FsKxoWa2U2tM3 93YLX1uSltxbNvvLRvZpO3MlJN5N+Jaho/FMYU2bGotl54PAV6GHFSN3lPssSjtqO/14iNs0 jbelIQfc5pcLfTrU6qkgHr3D4R5bc/yOGb4s+3UXJpwVXN7klinx62Cr4cGTV5VYijMSDbWY i4oTAWo7CiBdAgAA Archived-At: Subject: Re: [Supa] =?utf-8?q?WG_Last_Call_started_for_SUPA_Framework_draft_v?= =?utf-8?q?ersion_-03?= X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.22 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, 28 Jul 2017 11:30:11 -0000 --=====003_Dragon151401314028_===== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWxsLCANCg0KSSB0b29rIGEgbG9vayBhdCBkcmFmdC1pZXRmLXN1cGEtcG9saWN5LWJhc2Vk LW1hbmFnZW1ldG4tZnJhbWV3b3JrLTAzLiBUaGUgcmVsYXRpb25zaGlwIGJldHdlZW4gU1VQQSBm cmFtZXdvcmsgYW5kIG5ldHdvcmsgY29tcG9uZW50cyAoZS5nLiwgb3JjaGVzdHJhdG9yL2NvbnRy b2xsZXIvTkUpIGlzIHdlbGwgZWxhYm9yYXRlZC4gSG93IHRvIGdlbmVyYXRlIERNIGlzIGFsc28g d2VsbCBleHBsYWluZWQuIEkgYXBwcmVjaWF0ZSB0aGUgZWZmb3J0cy4gDQoNCkkgc3VwcG9ydCB0 aGlzIGRvY3VtZW50IHB1YmxpY2F0aW9uLiBUaGlzIGlzIGEgZ29vZCBzdGFydCBmb3IgdGhlIFNV UEEgd29yay4gDQogDQpTb21lIHNtYWxsIGNvbW1lbnRzOg0KIA0KKDEpIElNTywgaW4gYWRkaXRp b24gdG8gR2VuZXJpYyAmIEVDQSBETXMsIHRoZXJlIHNob3VsZCBiZSBzcGVjaWZpYyAmIEVDQSBE TXMgdGhhdCBhcmUgZGlyZWN0bHkgdXNlZCBmb3IgbWFuYWdpbmcgdGhlIG5ldHdvcmsuIEZvciBl eGFtcGxlLCB0aGUgU05NUCBibG9ja2luZyBjYXNlIGFuZCB0aGUgdmlydHVhbCBtYWNoaW5lIG1p Z3JhdGlvbiBjYXNlcyBhcmUgZGlmZmVyZW50LCBpbXBseWluZyBkaWZmZXJlbnQgRXZlbnRzLCBD b25kaXRpb25zIGFuZCBBY3Rpb25zIGRlZmluaXRpb25zLiANCiANClRoZSBhdXRob3JzIGRvIG5v dCBtZW50aW9uIHRoZSBzcGVjaWZpYyBETXMgaW4gdGhlIGRyYWZ0LiBCdXQgSSBiZWxpZXZlLCB0 aGUgU2VydmljZSBJbnRlcmZhY2UgTG9naWMgKGluIEZpZ3VyZSAxKSBjYW4gYmUgZXh0ZW5kZWQg KG9yIGFyZSBhbHJlYWR5IGRlZmluZWQgYnV0IG5vdCBleHBsaWNpdGx5IHdyaXR0ZW4gZG93bikg dG8gZ2VuZXJhdGUgc3VjaCBzcGVjaWZpYyBETXMsIHNpbmNlIGl0cyBpbnB1dHMgYXJlIGdlbmVy aWMgRE0gYW5kIHJlc291cmNlL3NlcnZpY2UgWUFORyBETSAobmV0d29yayBzcGVjaWZpYyBETXMp LiANCiANCigyKSBJIGRvIG5vdCBzZWUgdGhlIFJlc291cmNlIGFuZCBTZXJ2aWNlIFlBTkcgRGF0 YSBtb2RlbHMgYmxvY2sgaW4gRmlndXJlIDIsIGFsdGhvdWdoIHRoZXkgYXJlIG1lbnRpb25lZCBp biB0aGUgdGV4dHMgZGVzY3JpcHRpbmcgRmlndXJlIDIgKFBhZ2UgNywgdGhlIHBhcmFncmFwaCBh Ym92ZSBGaWd1cmUgMikuIA0KIA0KSSBiZWxpZXZlLCB0aGV5IG1pZ2h0IGJlIGFkZGVkIGludG8g U1VQQSBQb2xpY3kgRGF0YSBNb2RlbCBibG9jaywgYW5kIGJhc2VkIG9uIHRoZSByZXNvdXJjZS9z ZXJ2aWNlIFlBTkcgRE0sIHRoZSBtYW5hZ2VtZW50IHN5c3RlbSBnZW5lcmF0ZXMgY29uZmlndXJh dGlvbiBjb21tYW5kcyB0byBpbXBhY3Qgb3JjaGVzdHJhdG9yLCBjb250cm9sbGVyIGFuZCBORS4g DQogDQooMykgRm9yIHRoZSBzdWJ0aXRsZSBvZiAzLjQuLCBkbyB0aGUgYXV0aG9ycyBtZWFuIEdl bmVyaWMgWUFORyAqRGF0YSogTW9kdWxlcz8NCiANCig0KSBUaGUgdGV4dHMgY29udGFpbiAqTm90 ZSBmcm9tIEVkaXRvciouIFRoZXJlIGFyZSB0d28gcGxhY2VzLiBBcmUgdGhleSB0ZW1wb3Jhcnkg cmVtYXJrcz8NCg0KDQpCUiwNCllpbmcNCg0KDQoyMDE3LTA3LTI4IA0KDQoNCg0KWWluZyBDSEVO RyAg56iL6I65DQpUZWNobm9sb2d5IERlcGFydG1lbnQsIENoaW5hIFVuaWNvbSDkuK3lm73ogZTp gJrpm4blm6LmioDmnK/pg6gNClRlbDogKzg2LTEwLTY2MjU5Mzk0DQpNb2JpbGU6ICs4Ni0xODYw MTEwMjk3MSANCg0KDQoNCuWPkeS7tuS6uu+8miBOZXZpbCBCcm93bmxlZSANCuWPkemAgeaXtumX tO+8miAyMDE3LTA3LTE4ICAxMzozNDoxOCANCuaUtuS7tuS6uu+8miBTVVBBIGxpc3QgDQrmioTp gIHvvJogDQrkuLvpopjvvJogW1N1cGFdIFdHIExhc3QgQ2FsbCBzdGFydGVkIGZvciBTVVBBIEZy YW1ld29yayBkcmFmdCB2ZXJzaW9uIC0wMyANCiANCkhpIFNVUEEgZm9sazoNCkEgbmV3IHJldmlz aW9uIG9mIHRoZSBTVVBBIEZyYW1ld29yayBkcmFmdCBoYXMganVzdCBiZWVuIHBvc3RlZC4NClRo aXMgdmVyc2lvbiBhZGRyZXNzZXMgYWxsIHJldmlld2VyIGNvbmNlcm5zIHRvIGRhdGUsIHNvIHdl J3ZlIHN0YXJ0ZWQNCmEgdHdvLXdlZWsgV0cgTGFzdCBDYWxsIGZvciBpdC4NClBsZWFzZSB0YWtl IGFub3RoZXIgbG9vayBhdCBpdCwgYW5kIHNlbmQgY29tZW50cyB0byB0aGUgU1VQQSBsaXN0Lg0K RXZlbiBhIGJyaWVmICJJIGFncmVlIHdpdGggcHViaXNoaW5nIiBub3RlIGlzIHVzZWZ1bCBhdCB0 aGlzIHN0YWdlIQ0KQ2hlZXJzLCBOZXZpbA0KLS0NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICBOZXZpbCBCcm93 bmxlZSAgICAgICAgICAgICAgICAgICAgQ29tcHV0ZXIgU2NpZW5jZSBEZXBhcnRtZW50IHwgSVRT DQogIFBob25lOiArNjQgOSAzNzMgNzU5OSB4ODg5NDEgICAgICAgICAgICAgVGhlIFVuaXZlcnNp dHkgb2YgQXVja2xhbmQNCiAgRkFYOiArNjQgOSAzNzMgNzQ1MyAgIFByaXZhdGUgQmFnIDkyMDE5 LCBBdWNrbGFuZCAxMTQyLCBOZXcgWmVhbGFuZA0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NClNVUEEgbWFpbGluZyBsaXN0DQpTVVBBQGlldGYub3JnDQpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N1cGENCg== --=====003_Dragon151401314028_===== Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 77u/PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u YWwvL0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0 PXV0Zi04IiBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZT4NCjxNRVRBIG5hbWU9R0VORVJBVE9SIGNv bnRlbnQ9Ik1TSFRNTCAxMC4wMC45MjAwLjE2NTIxIj4NCjxTVFlMRT5AZm9udC1mYWNlIHsNCglm b250LWZhbWlseTog5a6L5L2TOw0KfQ0KQGZvbnQtZmFjZSB7DQoJZm9udC1mYW1pbHk6IFZlcmRh bmE7DQp9DQpAZm9udC1mYWNlIHsNCglmb250LWZhbWlseTogQOWui+S9kzsNCn0NCkBwYWdlIFNl Y3Rpb24xIHtzaXplOiA1OTUuM3B0IDg0MS45cHQ7IG1hcmdpbjogNzIuMHB0IDkwLjBwdCA3Mi4w cHQgOTAuMHB0OyBsYXlvdXQtZ3JpZDogMTUuNnB0OyB9DQpQLk1zb05vcm1hbCB7DQoJRk9OVC1T SVpFOiAxMC41cHQ7IEZPTlQtRkFNSUxZOiAiVGltZXMgTmV3IFJvbWFuIjsgVEVYVC1BTElHTjog anVzdGlmeTsgTUFSR0lOOiAwY20gMGNtIDBwdDsgVEVYVC1KVVNUSUZZOiBpbnRlci1pZGVvZ3Jh cGgNCn0NCkxJLk1zb05vcm1hbCB7DQoJRk9OVC1TSVpFOiAxMC41cHQ7IEZPTlQtRkFNSUxZOiAi VGltZXMgTmV3IFJvbWFuIjsgVEVYVC1BTElHTjoganVzdGlmeTsgTUFSR0lOOiAwY20gMGNtIDBw dDsgVEVYVC1KVVNUSUZZOiBpbnRlci1pZGVvZ3JhcGgNCn0NCkRJVi5Nc29Ob3JtYWwgew0KCUZP TlQtU0laRTogMTAuNXB0OyBGT05ULUZBTUlMWTogIlRpbWVzIE5ldyBSb21hbiI7IFRFWFQtQUxJ R046IGp1c3RpZnk7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IFRFWFQtSlVTVElGWTogaW50ZXItaWRl b2dyYXBoDQp9DQpBOmxpbmsgew0KCUNPTE9SOiBibHVlOyBURVhULURFQ09SQVRJT046IHVuZGVy bGluZQ0KfQ0KU1BBTi5Nc29IeXBlcmxpbmsgew0KCUNPTE9SOiBibHVlOyBURVhULURFQ09SQVRJ T046IHVuZGVybGluZQ0KfQ0KQTp2aXNpdGVkIHsNCglDT0xPUjogcHVycGxlOyBURVhULURFQ09S QVRJT046IHVuZGVybGluZQ0KfQ0KU1BBTi5Nc29IeXBlcmxpbmtGb2xsb3dlZCB7DQoJQ09MT1I6 IHB1cnBsZTsgVEVYVC1ERUNPUkFUSU9OOiB1bmRlcmxpbmUNCn0NClNQQU4uRW1haWxTdHlsZTE3 IHsNCglGT05ULUZBTUlMWTogVmVyZGFuYTsgRk9OVC1XRUlHSFQ6IG5vcm1hbDsgQ09MT1I6IHdp bmRvd3RleHQ7IEZPTlQtU1RZTEU6IG5vcm1hbDsgVEVYVC1ERUNPUkFUSU9OOiBub25lOyBtc28t c3R5bGUtdHlwZTogcGVyc29uYWwtY29tcG9zZQ0KfQ0KRElWLlNlY3Rpb24xIHsNCglwYWdlOiBT ZWN0aW9uMQ0KfQ0KVU5LTk9XTiB7DQoJRk9OVC1TSVpFOiAxMHB0DQp9DQpCTE9DS1FVT1RFIHsN CglNQVJHSU4tQk9UVE9NOiAwcHg7IE1BUkdJTi1MRUZUOiAyZW07IE1BUkdJTi1UT1A6IDBweA0K fQ0KT0wgew0KCU1BUkdJTi1CT1RUT006IDBweDsgTUFSR0lOLVRPUDogMHB4DQp9DQpVTCB7DQoJ TUFSR0lOLUJPVFRPTTogMHB4OyBNQVJHSU4tVE9QOiAwcHgNCn0NCjwvU1RZTEU+DQo8L0hFQUQ+ DQo8Qk9EWSBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogdmVyZGFuYTsgTUFS R0lOOiAxMHB4Ij4NCjxESVY+PD94bWw6bmFtZXNwYWNlIHByZWZpeCA9ICJvIiBucyA9ICJ1cm46 c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpvZmZpY2UiIA0KLz48bzpwPg0KPFAgY2xhc3M9 TXNvTm9ybWFsIA0Kc3R5bGU9IlRFWFQtQUxJR046IGxlZnQ7IE1BUkdJTjogMGNtIDBjbSAwcHQ7 IG1zby1wYWdpbmF0aW9uOiB3aWRvdy1vcnBoYW4iIA0KYWxpZ249bGVmdD48U1BBTiBsYW5nPUVO LVVTIA0Kc3R5bGU9IkZPTlQtU0laRTogMTJwdDsgRk9OVC1GQU1JTFk6ICdUaW1lcyBOZXcgUm9t YW4nLHNlcmlmOyBtc28tZmFyZWFzdC1mb250LWZhbWlseTog5a6L5L2TOyBtc28tZm9udC1rZXJu aW5nOiAwcHQiPkhpIA0KYWxsLCA8L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsIA0Kc3R5 bGU9IlRFWFQtQUxJR046IGxlZnQ7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IG1zby1wYWdpbmF0aW9u OiB3aWRvdy1vcnBoYW4iIA0KYWxpZ249bGVmdD48U1BBTiBsYW5nPUVOLVVTIA0Kc3R5bGU9IkZP TlQtU0laRTogMTJwdDsgRk9OVC1GQU1JTFk6ICdUaW1lcyBOZXcgUm9tYW4nLHNlcmlmOyBtc28t ZmFyZWFzdC1mb250LWZhbWlseTog5a6L5L2TOyBtc28tZm9udC1rZXJuaW5nOiAwcHQiPjxvOnA+ PC9vOnA+PC9TUEFOPiZuYnNwOzwvUD4NCjxQIGNsYXNzPU1zb05vcm1hbCANCnN0eWxlPSJURVhU LUFMSUdOOiBsZWZ0OyBNQVJHSU46IDBjbSAwY20gMHB0OyBtc28tcGFnaW5hdGlvbjogd2lkb3ct b3JwaGFuOyBtc28tbWFyZ2luLXRvcC1hbHQ6IGF1dG87IG1zby1tYXJnaW4tYm90dG9tLWFsdDog YXV0byIgDQphbGlnbj1sZWZ0PjxTUEFOIGxhbmc9RU4tVVMgDQpzdHlsZT0iRk9OVC1TSVpFOiAx MnB0OyBGT05ULUZBTUlMWTogJ1RpbWVzIE5ldyBSb21hbicsc2VyaWY7IG1zby1mYXJlYXN0LWZv bnQtZmFtaWx5OiDlrovkvZM7IG1zby1mb250LWtlcm5pbmc6IDBwdCI+SSANCnRvb2sgYSBsb29r IGF0IGRyYWZ0LWlldGYtc3VwYS1wb2xpY3ktYmFzZWQtbWFuYWdlbWV0bi1mcmFtZXdvcmstMDMu IFRoZSANCnJlbGF0aW9uc2hpcCBiZXR3ZWVuIFNVUEEgZnJhbWV3b3JrIGFuZCBuZXR3b3JrIGNv bXBvbmVudHMgKGUuZy4sIA0Kb3JjaGVzdHJhdG9yL2NvbnRyb2xsZXIvTkUpIGlzIHdlbGwgZWxh Ym9yYXRlZC4gSG93IHRvIGdlbmVyYXRlIERNIGlzIGFsc28gd2VsbCANCmV4cGxhaW5lZC4gSSBh cHByZWNpYXRlIHRoZSBlZmZvcnRzLiA8L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsIA0K c3R5bGU9IlRFWFQtQUxJR046IGxlZnQ7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IG1zby1wYWdpbmF0 aW9uOiB3aWRvdy1vcnBoYW47IG1zby1tYXJnaW4tdG9wLWFsdDogYXV0bzsgbXNvLW1hcmdpbi1i b3R0b20tYWx0OiBhdXRvIiANCmFsaWduPWxlZnQ+PFNQQU4gbGFuZz1FTi1VUyANCnN0eWxlPSJG T05ULVNJWkU6IDEycHQ7IEZPTlQtRkFNSUxZOiAnVGltZXMgTmV3IFJvbWFuJyxzZXJpZjsgbXNv LWZhcmVhc3QtZm9udC1mYW1pbHk6IOWui+S9kzsgbXNvLWZvbnQta2VybmluZzogMHB0Ij48bzpw PjwvbzpwPjwvU1BBTj4mbmJzcDs8L1A+DQo8UCBjbGFzcz1Nc29Ob3JtYWwgDQpzdHlsZT0iTUFS R0lOOiAwY20gMGNtIDBwdDsgbXNvLXBhZ2luYXRpb246IHdpZG93LW9ycGhhbiI+PFNQQU4gbGFu Zz1FTi1VUyANCnN0eWxlPSJGT05ULVNJWkU6IDEycHQ7IEZPTlQtRkFNSUxZOiAnVGltZXMgTmV3 IFJvbWFuJyxzZXJpZjsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IOWui+S9kzsgbXNvLWZvbnQt a2VybmluZzogMHB0Ij5JIA0Kc3VwcG9ydCB0aGlzIGRvY3VtZW50IHB1YmxpY2F0aW9uLiBUaGlz IGlzIGEgZ29vZCBzdGFydCBmb3IgdGhlIFNVUEEgd29yay4gDQo8bzpwPjwvbzpwPjwvU1BBTj48 L1A+DQo8UCBjbGFzcz1Nc29Ob3JtYWwgDQpzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdDsgbXNv LXBhZ2luYXRpb246IHdpZG93LW9ycGhhbiI+PFNQQU4gbGFuZz1FTi1VUyANCnN0eWxlPSJGT05U LVNJWkU6IDEycHQ7IEZPTlQtRkFNSUxZOiAnVGltZXMgTmV3IFJvbWFuJyxzZXJpZjsgbXNvLWZh cmVhc3QtZm9udC1mYW1pbHk6IOWui+S9kzsgbXNvLWZvbnQta2VybmluZzogMHB0Ij4mbmJzcDs8 bzpwPjwvbzpwPjwvU1BBTj48L1A+DQo8UCBjbGFzcz1Nc29Ob3JtYWwgDQpzdHlsZT0iTUFSR0lO OiAwY20gMGNtIDBwdDsgbXNvLXBhZ2luYXRpb246IHdpZG93LW9ycGhhbiI+PFNQQU4gbGFuZz1F Ti1VUyANCnN0eWxlPSJGT05ULVNJWkU6IDEycHQ7IEZPTlQtRkFNSUxZOiAnVGltZXMgTmV3IFJv bWFuJyxzZXJpZjsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IOWui+S9kzsgbXNvLWZvbnQta2Vy bmluZzogMHB0Ij5Tb21lIA0Kc21hbGwgY29tbWVudHM6PG86cD48L286cD48L1NQQU4+PC9QPg0K PFAgY2xhc3M9TXNvTm9ybWFsIA0Kc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQ7IG1zby1wYWdp bmF0aW9uOiB3aWRvdy1vcnBoYW4iPjxTUEFOIGxhbmc9RU4tVVMgDQpzdHlsZT0iRk9OVC1TSVpF OiAxMnB0OyBGT05ULUZBTUlMWTogJ1RpbWVzIE5ldyBSb21hbicsc2VyaWY7IG1zby1mYXJlYXN0 LWZvbnQtZmFtaWx5OiDlrovkvZM7IG1zby1mb250LWtlcm5pbmc6IDBwdCI+PG86cD4mbmJzcDs8 L286cD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsIA0Kc3R5bGU9IlRFWFQtQUxJR046 IGxlZnQ7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IG1zby1wYWdpbmF0aW9uOiB3aWRvdy1vcnBoYW47 IG1zby1tYXJnaW4tdG9wLWFsdDogYXV0bzsgbXNvLW1hcmdpbi1ib3R0b20tYWx0OiBhdXRvIiAN CmFsaWduPWxlZnQ+PFNQQU4gbGFuZz1FTi1VUyANCnN0eWxlPSJGT05ULVNJWkU6IDEycHQ7IEZP TlQtRkFNSUxZOiAnVGltZXMgTmV3IFJvbWFuJyxzZXJpZjsgbXNvLWZhcmVhc3QtZm9udC1mYW1p bHk6IOWui+S9kzsgbXNvLWZvbnQta2VybmluZzogMHB0Ij4oMSkgDQpJTU8sIGluIGFkZGl0aW9u IHRvIEdlbmVyaWMgJmFtcDsgRUNBIERNcywgdGhlcmUgc2hvdWxkIGJlIHNwZWNpZmljICZhbXA7 IEVDQSANCkRNcyB0aGF0IGFyZSBkaXJlY3RseSB1c2VkIGZvciBtYW5hZ2luZyB0aGUgbmV0d29y ay4gRm9yIGV4YW1wbGUsIHRoZSBTTk1QIA0KYmxvY2tpbmcgY2FzZSBhbmQgdGhlIHZpcnR1YWwg bWFjaGluZSBtaWdyYXRpb24gY2FzZXMgYXJlIGRpZmZlcmVudCwgaW1wbHlpbmcgDQpkaWZmZXJl bnQgRXZlbnRzLCBDb25kaXRpb25zIGFuZCBBY3Rpb25zIGRlZmluaXRpb25zLiA8bzpwPjwvbzpw PjwvU1BBTj48L1A+DQo8UCBjbGFzcz1Nc29Ob3JtYWwgDQpzdHlsZT0iVEVYVC1BTElHTjogbGVm dDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgbXNvLXBhZ2luYXRpb246IHdpZG93LW9ycGhhbjsgbXNv LW1hcmdpbi10b3AtYWx0OiBhdXRvOyBtc28tbWFyZ2luLWJvdHRvbS1hbHQ6IGF1dG8iIA0KYWxp Z249bGVmdD48U1BBTiBsYW5nPUVOLVVTIA0Kc3R5bGU9IkZPTlQtU0laRTogMTJwdDsgRk9OVC1G QU1JTFk6ICdUaW1lcyBOZXcgUm9tYW4nLHNlcmlmOyBtc28tZmFyZWFzdC1mb250LWZhbWlseTog 5a6L5L2TOyBtc28tZm9udC1rZXJuaW5nOiAwcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9TUEFOPjwv UD4NCjxQIGNsYXNzPU1zb05vcm1hbCANCnN0eWxlPSJURVhULUFMSUdOOiBsZWZ0OyBNQVJHSU46 IDBjbSAwY20gMHB0OyBtc28tcGFnaW5hdGlvbjogd2lkb3ctb3JwaGFuOyBtc28tbWFyZ2luLXRv cC1hbHQ6IGF1dG87IG1zby1tYXJnaW4tYm90dG9tLWFsdDogYXV0byIgDQphbGlnbj1sZWZ0PjxT UEFOIGxhbmc9RU4tVVMgDQpzdHlsZT0iRk9OVC1TSVpFOiAxMnB0OyBGT05ULUZBTUlMWTogJ1Rp bWVzIE5ldyBSb21hbicsc2VyaWY7IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiDlrovkvZM7IG1z by1mb250LWtlcm5pbmc6IDBwdCI+VGhlIA0KYXV0aG9ycyBkbyBub3QgbWVudGlvbiB0aGUgc3Bl Y2lmaWMgRE1zIGluIHRoZSBkcmFmdC4gQnV0IEkgYmVsaWV2ZSwgdGhlIFNlcnZpY2UgDQpJbnRl cmZhY2UgTG9naWMgKGluIEZpZ3VyZSAxKSBjYW4gYmUgZXh0ZW5kZWQgKG9yIGFyZSBhbHJlYWR5 IGRlZmluZWQgYnV0IG5vdCANCmV4cGxpY2l0bHkgd3JpdHRlbiBkb3duKSB0byBnZW5lcmF0ZSBz dWNoIHNwZWNpZmljIERNcywgc2luY2UgaXRzIGlucHV0cyBhcmUgDQpnZW5lcmljIERNIGFuZCBy ZXNvdXJjZS9zZXJ2aWNlIFlBTkcgRE0gKG5ldHdvcmsgc3BlY2lmaWMgRE1zKS4gDQo8bzpwPjwv bzpwPjwvU1BBTj48L1A+DQo8UCBjbGFzcz1Nc29Ob3JtYWwgDQpzdHlsZT0iVEVYVC1BTElHTjog bGVmdDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgbXNvLXBhZ2luYXRpb246IHdpZG93LW9ycGhhbjsg bXNvLW1hcmdpbi10b3AtYWx0OiBhdXRvOyBtc28tbWFyZ2luLWJvdHRvbS1hbHQ6IGF1dG8iIA0K YWxpZ249bGVmdD48U1BBTiBsYW5nPUVOLVVTIA0Kc3R5bGU9IkZPTlQtU0laRTogMTJwdDsgRk9O VC1GQU1JTFk6ICdUaW1lcyBOZXcgUm9tYW4nLHNlcmlmOyBtc28tZmFyZWFzdC1mb250LWZhbWls eTog5a6L5L2TOyBtc28tZm9udC1rZXJuaW5nOiAwcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9TUEFO PjwvUD4NCjxQIGNsYXNzPU1zb05vcm1hbCANCnN0eWxlPSJURVhULUFMSUdOOiBsZWZ0OyBNQVJH SU46IDBjbSAwY20gMHB0OyBtc28tcGFnaW5hdGlvbjogd2lkb3ctb3JwaGFuOyBtc28tbWFyZ2lu LXRvcC1hbHQ6IGF1dG87IG1zby1tYXJnaW4tYm90dG9tLWFsdDogYXV0byIgDQphbGlnbj1sZWZ0 PjxTUEFOIGxhbmc9RU4tVVMgDQpzdHlsZT0iRk9OVC1TSVpFOiAxMnB0OyBGT05ULUZBTUlMWTog J1RpbWVzIE5ldyBSb21hbicsc2VyaWY7IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiDlrovkvZM7 IG1zby1mb250LWtlcm5pbmc6IDBwdCI+KDIpIA0KSSBkbyBub3Qgc2VlIHRoZSBSZXNvdXJjZSBh bmQgU2VydmljZSBZQU5HIERhdGEgbW9kZWxzIGJsb2NrIGluIEZpZ3VyZSAyLCANCmFsdGhvdWdo IHRoZXkgYXJlIG1lbnRpb25lZCBpbiB0aGUgdGV4dHMgZGVzY3JpcHRpbmcgRmlndXJlIDIgKFBh Z2UgNywgdGhlIA0KcGFyYWdyYXBoIGFib3ZlIEZpZ3VyZSAyKS4gPG86cD48L286cD48L1NQQU4+ PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsIA0Kc3R5bGU9IlRFWFQtQUxJR046IGxlZnQ7IE1BUkdJ TjogMGNtIDBjbSAwcHQ7IG1zby1wYWdpbmF0aW9uOiB3aWRvdy1vcnBoYW47IG1zby1tYXJnaW4t dG9wLWFsdDogYXV0bzsgbXNvLW1hcmdpbi1ib3R0b20tYWx0OiBhdXRvIiANCmFsaWduPWxlZnQ+ PFNQQU4gbGFuZz1FTi1VUyANCnN0eWxlPSJGT05ULVNJWkU6IDEycHQ7IEZPTlQtRkFNSUxZOiAn VGltZXMgTmV3IFJvbWFuJyxzZXJpZjsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IOWui+S9kzsg bXNvLWZvbnQta2VybmluZzogMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvU1BBTj48L1A+DQo8UCBj bGFzcz1Nc29Ob3JtYWwgDQpzdHlsZT0iVEVYVC1BTElHTjogbGVmdDsgTUFSR0lOOiAwY20gMGNt IDBwdDsgbXNvLXBhZ2luYXRpb246IHdpZG93LW9ycGhhbjsgbXNvLW1hcmdpbi10b3AtYWx0OiBh dXRvOyBtc28tbWFyZ2luLWJvdHRvbS1hbHQ6IGF1dG8iIA0KYWxpZ249bGVmdD48U1BBTiBsYW5n PUVOLVVTIA0Kc3R5bGU9IkZPTlQtU0laRTogMTJwdDsgRk9OVC1GQU1JTFk6ICdUaW1lcyBOZXcg Um9tYW4nLHNlcmlmOyBtc28tZmFyZWFzdC1mb250LWZhbWlseTog5a6L5L2TOyBtc28tZm9udC1r ZXJuaW5nOiAwcHQiPkkgDQpiZWxpZXZlLCB0aGV5IG1pZ2h0IGJlIGFkZGVkIGludG8gU1VQQSBQ b2xpY3kgRGF0YSBNb2RlbCBibG9jaywgYW5kIGJhc2VkIG9uIHRoZSANCnJlc291cmNlL3NlcnZp Y2UgWUFORyBETSwgdGhlIG1hbmFnZW1lbnQgc3lzdGVtIGdlbmVyYXRlcyBjb25maWd1cmF0aW9u IGNvbW1hbmRzIA0KdG8gaW1wYWN0IG9yY2hlc3RyYXRvciwgY29udHJvbGxlciBhbmQgTkUuIDxv OnA+PC9vOnA+PC9TUEFOPjwvUD4NCjxQIGNsYXNzPU1zb05vcm1hbCANCnN0eWxlPSJURVhULUFM SUdOOiBsZWZ0OyBNQVJHSU46IDBjbSAwY20gMHB0OyBtc28tcGFnaW5hdGlvbjogd2lkb3ctb3Jw aGFuOyBtc28tbWFyZ2luLXRvcC1hbHQ6IGF1dG87IG1zby1tYXJnaW4tYm90dG9tLWFsdDogYXV0 byIgDQphbGlnbj1sZWZ0PjxTUEFOIGxhbmc9RU4tVVMgDQpzdHlsZT0iRk9OVC1TSVpFOiAxMnB0 OyBGT05ULUZBTUlMWTogJ1RpbWVzIE5ldyBSb21hbicsc2VyaWY7IG1zby1mYXJlYXN0LWZvbnQt ZmFtaWx5OiDlrovkvZM7IG1zby1mb250LWtlcm5pbmc6IDBwdCI+PG86cD4mbmJzcDs8L286cD48 L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsIA0Kc3R5bGU9IlRFWFQtQUxJR046IGxlZnQ7 IE1BUkdJTjogMGNtIDBjbSAwcHQ7IG1zby1wYWdpbmF0aW9uOiB3aWRvdy1vcnBoYW47IG1zby1t YXJnaW4tdG9wLWFsdDogYXV0bzsgbXNvLW1hcmdpbi1ib3R0b20tYWx0OiBhdXRvIiANCmFsaWdu PWxlZnQ+PFNQQU4gbGFuZz1FTi1VUyANCnN0eWxlPSJGT05ULVNJWkU6IDEycHQ7IEZPTlQtRkFN SUxZOiAnVGltZXMgTmV3IFJvbWFuJyxzZXJpZjsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IOWu i+S9kzsgbXNvLWZvbnQta2VybmluZzogMHB0Ij4oMykgDQpGb3IgdGhlIHN1YnRpdGxlIG9mIDMu NC4sIGRvIHRoZSBhdXRob3JzIG1lYW4gR2VuZXJpYyBZQU5HICpEYXRhKiANCk1vZHVsZXM/PG86 cD48L286cD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsIA0Kc3R5bGU9IlRFWFQtQUxJ R046IGxlZnQ7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IG1zby1wYWdpbmF0aW9uOiB3aWRvdy1vcnBo YW47IG1zby1tYXJnaW4tdG9wLWFsdDogYXV0bzsgbXNvLW1hcmdpbi1ib3R0b20tYWx0OiBhdXRv IiANCmFsaWduPWxlZnQ+PFNQQU4gbGFuZz1FTi1VUyANCnN0eWxlPSJGT05ULVNJWkU6IDEycHQ7 IEZPTlQtRkFNSUxZOiAnVGltZXMgTmV3IFJvbWFuJyxzZXJpZjsgbXNvLWZhcmVhc3QtZm9udC1m YW1pbHk6IOWui+S9kzsgbXNvLWZvbnQta2VybmluZzogMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwv U1BBTj48L1A+DQo8UCBjbGFzcz1Nc29Ob3JtYWwgDQpzdHlsZT0iVEVYVC1BTElHTjogbGVmdDsg TUFSR0lOOiAwY20gMGNtIDBwdDsgbXNvLXBhZ2luYXRpb246IHdpZG93LW9ycGhhbjsgbXNvLW1h cmdpbi10b3AtYWx0OiBhdXRvOyBtc28tbWFyZ2luLWJvdHRvbS1hbHQ6IGF1dG8iIA0KYWxpZ249 bGVmdD48U1BBTiBsYW5nPUVOLVVTIA0Kc3R5bGU9IkZPTlQtU0laRTogMTJwdDsgRk9OVC1GQU1J TFk6ICdUaW1lcyBOZXcgUm9tYW4nLHNlcmlmOyBtc28tZmFyZWFzdC1mb250LWZhbWlseTog5a6L 5L2TOyBtc28tZm9udC1rZXJuaW5nOiAwcHQiPig0KSANClRoZSB0ZXh0cyBjb250YWluICpOb3Rl IGZyb20gRWRpdG9yKi4gVGhlcmUgYXJlIHR3byBwbGFjZXMuIEFyZSB0aGV5IHRlbXBvcmFyeSAN CnJlbWFya3M/PG86cD48L286cD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxl PSJNQVJHSU46IDBjbSAwY20gMHB0Ij48U1BBTiBsYW5nPUVOLVVTIA0Kc3R5bGU9IkZPTlQtU0la RTogMTJwdDsgRk9OVC1GQU1JTFk6ICdUaW1lcyBOZXcgUm9tYW4nLHNlcmlmIj48bzpwPjwvbzpw PjwvU1BBTj4mbmJzcDs8L1A+DQo8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjogMGNt IDBjbSAwcHQiPjxTUEFOIGxhbmc9RU4tVVMgDQpzdHlsZT0iRk9OVC1TSVpFOiAxMnB0OyBGT05U LUZBTUlMWTogJ1RpbWVzIE5ldyBSb21hbicsc2VyaWYiPjxvOnA+PC9vOnA+PC9TUEFOPiZuYnNw OzwvUD4NCjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCI+PFNQ QU4gbGFuZz1FTi1VUyANCnN0eWxlPSJGT05ULVNJWkU6IDEycHQ7IEZPTlQtRkFNSUxZOiAnVGlt ZXMgTmV3IFJvbWFuJyxzZXJpZiI+PG86cD5CUiw8L286cD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9 TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0Ij48U1BBTiBsYW5nPUVOLVVTIA0K c3R5bGU9IkZPTlQtU0laRTogMTJwdDsgRk9OVC1GQU1JTFk6ICdUaW1lcyBOZXcgUm9tYW4nLHNl cmlmIj48bzpwPllpbmc8L286cD48L1NQQU4+PC9QPjwvbzpwPjwvRElWPg0KPERJVj48Rk9OVCBj b2xvcj0jMDAwMDgwIHNpemU9MiBmYWNlPVZlcmRhbmE+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJ Vj48Rk9OVCBjb2xvcj0jMDAwMDgwIHNpemU9MiBmYWNlPVZlcmRhbmE+PC9GT05UPiZuYnNwOzwv RElWPg0KPERJVj48Rk9OVCBjb2xvcj0jYzBjMGMwIHNpemU9MiBmYWNlPVZlcmRhbmE+MjAxNy0w Ny0yOCA8L0ZPTlQ+PC9ESVY+PEZPTlQgDQpjb2xvcj0jMDAwMDgwIHNpemU9MiBmYWNlPVZlcmRh bmE+DQo8SFIgc3R5bGU9IldJRFRIOiAxMDBweCIgYWxpZ249bGVmdCBjb2xvcj0jYjVjNGRmIFNJ WkU9MT4NCjwvRk9OVD4NCjxESVY+PEZPTlQgY29sb3I9I2MwYzBjMCBzaXplPTIgZmFjZT1WZXJk YW5hPjxTUEFOPg0KPERJVj5ZaW5nIENIRU5HJm5ic3A7IOeoi+iOuTxCUj5UZWNobm9sb2d5IERl cGFydG1lbnQsIENoaW5hIFVuaWNvbSANCuS4reWbveiBlOmAmumbhuWbouaKgOacr+mDqDxCUj5U ZWw6ICs4Ni0xMC02NjI1OTM5NDxCUj5Nb2JpbGU6ICs4Ni0xODYwMTEwMjk3MSANCjwvRElWPjwv U1BBTj48L0ZPTlQ+PC9ESVY+DQo8SFIgY29sb3I9I2I1YzRkZiBTSVpFPTE+DQoNCjxESVY+PEZP TlQgc2l6ZT0yIGZhY2U9VmVyZGFuYT48U1RST05HPuWPkeS7tuS6uu+8mjwvU1RST05HPiBOZXZp bCBCcm93bmxlZSANCjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yIGZhY2U9VmVyZGFu YT48U1RST05HPuWPkemAgeaXtumXtO+8mjwvU1RST05HPiAyMDE3LTA3LTE4Jm5ic3A7IDEzOjM0 OjE4IA0KPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTIgZmFjZT1WZXJkYW5hPjxTVFJP Tkc+5pS25Lu25Lq677yaPC9TVFJPTkc+IFNVUEEgbGlzdCA8L0ZPTlQ+PC9ESVY+DQo8RElWPjxG T05UIHNpemU9MiBmYWNlPVZlcmRhbmE+PFNUUk9ORz7mioTpgIHvvJo8L1NUUk9ORz4gPC9GT05U PjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTIgZmFjZT1WZXJkYW5hPjxTVFJPTkc+5Li76aKY77ya PC9TVFJPTkc+IFtTdXBhXSBXRyBMYXN0IENhbGwgc3RhcnRlZCANCmZvciBTVVBBIEZyYW1ld29y ayBkcmFmdCB2ZXJzaW9uIC0wMyA8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9MiBmYWNl PVZlcmRhbmE+PC9GT05UPiA8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yIGZhY2U9VmVyZGFuYT4N CjxESVY+PC9ESVY+DQo8RElWPkhpJm5ic3A7U1VQQSZuYnNwO2ZvbGs6PC9ESVY+DQo8RElWPjwv RElWPg0KPERJVj5BJm5ic3A7bmV3Jm5ic3A7cmV2aXNpb24mbmJzcDtvZiZuYnNwO3RoZSZuYnNw O1NVUEEmbmJzcDtGcmFtZXdvcmsmbmJzcDtkcmFmdCZuYnNwO2hhcyZuYnNwO2p1c3QmbmJzcDti ZWVuJm5ic3A7cG9zdGVkLjwvRElWPg0KPERJVj5UaGlzJm5ic3A7dmVyc2lvbiZuYnNwO2FkZHJl c3NlcyZuYnNwO2FsbCZuYnNwO3Jldmlld2VyJm5ic3A7Y29uY2VybnMmbmJzcDt0byZuYnNwO2Rh dGUsJm5ic3A7c28mbmJzcDt3ZSd2ZSZuYnNwO3N0YXJ0ZWQ8L0RJVj4NCjxESVY+YSZuYnNwO3R3 by13ZWVrJm5ic3A7V0cmbmJzcDtMYXN0Jm5ic3A7Q2FsbCZuYnNwO2ZvciZuYnNwO2l0LjwvRElW Pg0KPERJVj48L0RJVj4NCjxESVY+UGxlYXNlJm5ic3A7dGFrZSZuYnNwO2Fub3RoZXImbmJzcDts b29rJm5ic3A7YXQmbmJzcDtpdCwmbmJzcDthbmQmbmJzcDtzZW5kJm5ic3A7Y29tZW50cyZuYnNw O3RvJm5ic3A7dGhlJm5ic3A7U1VQQSZuYnNwO2xpc3QuPC9ESVY+DQo8RElWPkV2ZW4mbmJzcDth Jm5ic3A7YnJpZWYmbmJzcDsiSSZuYnNwO2FncmVlJm5ic3A7d2l0aCZuYnNwO3B1YmlzaGluZyIm bmJzcDtub3RlJm5ic3A7aXMmbmJzcDt1c2VmdWwmbmJzcDthdCZuYnNwO3RoaXMmbmJzcDtzdGFn ZSE8L0RJVj4NCjxESVY+PC9ESVY+DQo8RElWPkNoZWVycywmbmJzcDtOZXZpbDwvRElWPg0KPERJ Vj48L0RJVj4NCjxESVY+LS08L0RJVj4NCjxESVY+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPC9ESVY+DQo8RElWPiZu YnNwOyZuYnNwO05ldmlsJm5ic3A7QnJvd25sZWUmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtDb21wdXRlciZuYnNwO1NjaWVuY2Um bmJzcDtEZXBhcnRtZW50Jm5ic3A7fCZuYnNwO0lUUzwvRElWPg0KPERJVj4mbmJzcDsmbmJzcDtQ aG9uZTombmJzcDsrNjQmbmJzcDs5Jm5ic3A7MzczJm5ic3A7NzU5OSZuYnNwO3g4ODk0MSZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwO1RoZSZuYnNwO1VuaXZlcnNpdHkmbmJzcDtvZiZuYnNwO0F1Y2tsYW5k PC9ESVY+DQo8RElWPiZuYnNwOyZuYnNwO0ZBWDombmJzcDsrNjQmbmJzcDs5Jm5ic3A7MzczJm5i c3A7NzQ1MyZuYnNwOyZuYnNwOyZuYnNwO1ByaXZhdGUmbmJzcDtCYWcmbmJzcDs5MjAxOSwmbmJz cDtBdWNrbGFuZCZuYnNwOzExNDIsJm5ic3A7TmV3Jm5ic3A7WmVhbGFuZDwvRElWPg0KPERJVj48 L0RJVj4NCjxESVY+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188L0RJVj4NCjxESVY+U1VQQSZuYnNwO21haWxpbmcmbmJzcDtsaXN0PC9ESVY+DQo8RElWPlNV UEFAaWV0Zi5vcmc8L0RJVj4NCjxESVY+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9zdXBhPC9ESVY+DQo8RElWPjwvRElWPjwvRk9OVD48L0RJVj48L0JPRFk+PC9IVE1MPg0K --=====003_Dragon151401314028_=====--