From nobody Mon Nov 14 23:33:24 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1C60129516 for ; Mon, 14 Nov 2016 23:33:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 HevxS8BqdUuy for ; Mon, 14 Nov 2016 23:33:21 -0800 (PST) Received: from mh-1-0.lancs.ac.uk (mh-1-0.lancs.ac.uk [148.88.65.130]) by ietfa.amsl.com (Postfix) with ESMTP id 7CD1B1294AD for ; Mon, 14 Nov 2016 23:33:21 -0800 (PST) Received: from ex-0-ht0.lancs.ac.uk ([10.42.18.47] helo=EX-0-HT0.lancs.local) by mh-1-0.lancs.ac.uk with esmtp (Exim 4.85) (envelope-from ) id 1c6YF5-0002WN-D0; Tue, 15 Nov 2016 07:33:19 +0000 Received: from EX-0-MB2.lancs.local ([fe80::9d98:936b:54d1:c531]) by EX-0-HT0.lancs.local ([fe80::7d10:114a:53b0:7f2f%12]) with mapi id 14.03.0319.002; Tue, 15 Nov 2016 07:33:18 +0000 From: "King, Daniel" To: SUPA list Thread-Topic: Updated Agenda for Friday & Scribe Request Thread-Index: AdI/Eb6IN6Gu0GJtT4O4XcctBwScnA== Date: Tue, 15 Nov 2016 07:33:18 +0000 Message-ID: <65174429B5AF4C45BD0798810EC48E0A8C46A31C@EX-0-MB2.lancs.local> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [71.19.251.248] x-iss-local-domain: 1 Content-Type: multipart/alternative; boundary="_000_65174429B5AF4C45BD0798810EC48E0A8C46A31CEX0MB2lancsloca_" MIME-Version: 1.0 Archived-At: Cc: Nevil Brownlee Subject: [Supa] Updated Agenda for Friday & Scribe Request X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is to discuss SUPA $Simplified Use of Policy Abstractions$ related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2016 07:33:23 -0000 --_000_65174429B5AF4C45BD0798810EC48E0A8C46A31CEX0MB2lancsloca_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi SUPA WG, Please note a slight agenda change on Friday. Unfortunately, John is not ab= le to attend this IETF so Joel will take over his SUPA information model pr= esentation slot. Friday Afternoon session I (11:50-13:20) https://www.ietf.org/proceedings/97/agenda/agenda-97-supa-01 We would also like to request scribe (Minute Taker and Jabber) volunteers. = Your support would be highly appreciated. BR, Dan & Nevil. --_000_65174429B5AF4C45BD0798810EC48E0A8C46A31CEX0MB2lancsloca_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi SUPA WG,

Please note a slight agenda change on Friday. Unfort= unately, John is not able to attend this IETF so Joel will take over his SU= PA information model presentation slot.

Friday Afternoon session I (11:50-13:20)<= /p>

https://www.ietf.org/proceedings/97/agenda/agenda-97-s= upa-01

We would also like to request scribe (Minute Taker a= nd Jabber) volunteers. Your support would be highly appreciated.

BR, Dan & Nevil.

--_000_65174429B5AF4C45BD0798810EC48E0A8C46A31CEX0MB2lancsloca_-- From nobody Tue Nov 15 00:19:18 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD2631294E3 for ; Tue, 15 Nov 2016 00:19:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 J3730SkqADIC for ; Tue, 15 Nov 2016 00:19:15 -0800 (PST) Received: from mh-0-0.lancs.ac.uk (mh-0-0.lancs.ac.uk [148.88.65.128]) by ietfa.amsl.com (Postfix) with ESMTP id 10CAA129A3F for ; Tue, 15 Nov 2016 00:19:15 -0800 (PST) Received: from ex-0-ht0.lancs.ac.uk ([10.42.18.47] helo=EX-0-HT0.lancs.local) by mh-0-0.lancs.ac.uk with esmtp (Exim 4.85) (envelope-from ) id 1c6YxV-00061m-JD; Tue, 15 Nov 2016 08:19:13 +0000 Received: from EX-0-MB2.lancs.local ([fe80::9d98:936b:54d1:c531]) by EX-0-HT0.lancs.local ([fe80::7d10:114a:53b0:7f2f%12]) with mapi id 14.03.0319.002; Tue, 15 Nov 2016 08:19:13 +0000 From: "King, Daniel" To: SUPA list Thread-Topic: Updated Agenda for Friday & Scribe Request Thread-Index: AdI/GKL6xTEzLqJqRXyOq6n0CcPKtQ== Date: Tue, 15 Nov 2016 08:19:13 +0000 Message-ID: <65174429B5AF4C45BD0798810EC48E0A8C46A42E@EX-0-MB2.lancs.local> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [104.254.90.251] x-iss-local-domain: 1 Content-Type: multipart/alternative; boundary="_000_65174429B5AF4C45BD0798810EC48E0A8C46A42EEX0MB2lancsloca_" MIME-Version: 1.0 Archived-At: Cc: Nevil Brownlee Subject: Re: [Supa] Updated Agenda for Friday & Scribe Request X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is to discuss SUPA $Simplified Use of Policy Abstractions$ related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2016 08:19:17 -0000 --_000_65174429B5AF4C45BD0798810EC48E0A8C46A42EEX0MB2lancsloca_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Will has volunteered as a minute taker, if we have another and/or Jabber sc= ribe we are all set. Remote participants can view the session video stream via: https://grandbal= lroom1.conf.meetecho.com/q-meetecho/login.jsp?ietf=3Dsupa (Thanks Will for the link remember as well.) BR, Dan. From: King, Daniel Sent: 15 November 2016 16:33 To: SUPA list Cc: Nevil Brownlee Subject: Updated Agenda for Friday & Scribe Request Hi SUPA WG, Please note a slight agenda change on Friday. Unfortunately, John is not ab= le to attend this IETF so Joel will take over his SUPA information model pr= esentation slot. Friday Afternoon session I (11:50-13:20) https://www.ietf.org/proceedings/97/agenda/agenda-97-supa-01 We would also like to request scribe (Minute Taker and Jabber) volunteers. = Your support would be highly appreciated. BR, Dan & Nevil. --_000_65174429B5AF4C45BD0798810EC48E0A8C46A42EEX0MB2lancsloca_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Will has volunteered as a minute taker, if we have a= nother and/or Jabber scribe we are all set.

Remote participants can view the session video strea= m via: https://grandballroom1.conf.meetecho.com/q-meetecho/login.jsp?ietf=3Dsupa

(Thanks Will for the link remember as well.)

BR, Dan. =

&n= bsp;

From: King, Daniel
Sent: 15 November 2016 16:33
To: SUPA list <supa@ietf.org>
Cc: Nevil Brownlee <n.brownlee@auckland.ac.nz>
Subject: Updated Agenda for Friday & Scribe Request

Hi SUPA WG,

Please note a slight agenda change on Friday. Unfort= unately, John is not able to attend this IETF so Joel will take over his SU= PA information model presentation slot.

Friday Afternoon session I (11:50-13:20)<= /p>

https://www.ietf.org/proceedings/97/agenda/agenda-97-s= upa-01

We would also like to request scribe (Minute Taker a= nd Jabber) volunteers. Your support would be highly appreciated.

BR, Dan & Nevil.

--_000_65174429B5AF4C45BD0798810EC48E0A8C46A42EEX0MB2lancsloca_-- From nobody Thu Nov 17 00:49:23 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 403E21294F7; Thu, 17 Nov 2016 00:49:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.717 X-Spam-Level: X-Spam-Status: No, score=-5.717 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=-1.497, 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 Jry-nkwSHzS4; Thu, 17 Nov 2016 00:49:18 -0800 (PST) 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 0709A1295EA; Thu, 17 Nov 2016 00:49:16 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DAR95774; Thu, 17 Nov 2016 08:49:14 +0000 (GMT) Received: from SZXEMA418-HUB.china.huawei.com (10.82.72.36) by lhreml708-cah.china.huawei.com (10.201.5.202) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 17 Nov 2016 08:49:12 +0000 Received: from SZXEMA509-MBS.china.huawei.com ([169.254.2.147]) by SZXEMA418-HUB.china.huawei.com ([10.82.72.36]) with mapi id 14.03.0235.001; Thu, 17 Nov 2016 16:49:04 +0800 From: "Liushucheng (Will)" To: SUPA list , "jonathan@hansfords.net" Thread-Topic: updating SUPA framework draft Thread-Index: AdJAr3Fyxk8opWsoS6SzfdzA3EV54w== Date: Thu, 17 Nov 2016 08:49:03 +0000 Message-ID: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.119.201] Content-Type: multipart/alternative; boundary="_000_C9B5F12337F6F841B35C404CF0554ACB89888D33SZXEMA509MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090202.582D6F0B.0017, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.2.147, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 6eb31bbae54d6483dcb24f400adb49b2 Archived-At: Cc: "draft-ietf-supa-policy-based-management-framework@ietf.org" Subject: [Supa] updating SUPA framework draft X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is to discuss SUPA $Simplified Use of Policy Abstractions$ related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2016 08:49:22 -0000 --_000_C9B5F12337F6F841B35C404CF0554ACB89888D33SZXEMA509MBSchi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, After a long off-list discussion, we are doing our final review of -01 vers= ion of Framework draft after comments addressed and figures updated, and w= ill submit -01 version soon. Thanks to many reviewers, especially to Jonath= an Hansford for his very detailed review. I'm writing to summarize these co= mments we received as well as our off-list discussion conclusions to keep t= he group updated. The main technical comments are about the three figures.( Which make sense = as this is a framework draft :)) Figure 2: added C arrow from GPDM and EPDM to controllers, changed the sen= tence explaining D arrow. Some issue still under discussion: 1. whether we should show all the cases = in charter 2. whether we should split the design time and running time in t= his figure. Welcome the group to give opinions. Figure 3: Policies are used to control the management of resources and serv= ices, while data from resources and services are used to select and/or modi= fy policies during runtime. Therefore, Lines (1)&(2) connecting policy to r= esource and policy to service are the same, while Line (3) connecting resou= rce to service is different as it's navigable only from resource to service Also there is one comment requesting to reconstruct the section 2.3, and we= addressed in the upcoming version. There are also a couple of editorial issues were pointed out, especially th= e email from Jonathan helped us a lot in improving written English and remo= ve the misleading sentences. Many thanks! Detailed comments and response are also showed below starts with Will et al= .:" ---start--- From: "Jonathan Hansford" =B7 General o The phrase "the GPIM (or the combination of the GPIM and the E= PRIM)" or its equivalent appears a number of times throughout this document= so clearly it is important but, coming to SUPA cold, I failed to understan= d its importance. If there is a need to constantly repeat this phrase, coul= d it not do with further explanation? Will et al.: This means that policies can be defined using the GPIM directl= y, or using the combination of the GPIM and the EPRIM. If you use only the = GPIM, you get a technology- and vendor-independent information model that y= ou are free to map to the data model of your choice; note that the structur= e of a policy is NOT defined. If you use the GPIM and the EPRIM, you get a = technology- and vendor-independent information model that defines policies = as an event-condition-action (i.e., imperative) rule. =B7 Page 2 o 1. Introduction =A7 "the task of network operations and management applications a= nd deploying new services" - is that one task and, if so, what is it? Shoul= d that read "the task of network operations and management applications and= deploying new services"? Will et al.: should be "the task of network operations and management appli= cations deploying new services", fixed =B7 Page 3 o 1. Introduction =A7 s/indepednent/independent Will et al.: fixed =A7 What is the term "snippet" intended to imply? Should it be de= fined somewhere? Will et al.: A "snippet" is a small piece of information (e.g., part of a s= entence that was cut out). We added this sentence at the term first used pl= ace for readers better understanding. o 2.1 Overview =A7 "The GPIM, as well as the combination of the GPIM and EPRIM,= are converted to generic YANG data modules." Shouldn't that be either The = GPIM, as well as the combination of the GPIM and EPRIM, is converted ..." = or "The GPIM and the combination of the GPIM and EPRIM are converted ..."? Will et al.: Technically, you could have both. So "The GPIM, and/or the com= bination of the GPIM and the EPRIM, is converted...". =B7 Page 4 o 2.1 Overview =A7 For consistency with capitalisation, either e.g. "SUPA Generi= c & ECA Policy YANG Data modules" or "SUPA generic policy YANG data modules= " Will et al.: "SUPA Generic Policy and SUPA ECA Policy YANG data modules", f= ixed =B7 Page 7 o 2.1 Overview =A7 None of the arrows with Ds appear to be double-headed and not= all of the arrows with Cs Will et al.: You're right. The Ds should NOT be double-headed. However, the= Cs can be; depends on context. So we removed the double-headed term for th= e sentence of Ds. =A7 Since lower down we have "ECA Policy Rule Information Data Mo= del (EPRIM):" for consistency should we not also have "Generic Policy Infor= mation Model (GPIM):"? Will et al.: yes, thanks, fixed =A7 "query, and implementation languages, and protocol" (appears = twice) - should that be "query, implementation languages, and protocol"? Will et al.: yes, thanks, fixed =A7 "policy rules for that are" - should that be ""policy rules t= hat are"? Will et al.: yes, thanks, fixed =A7 "dependent of" - should that be "independent of" or "dependen= t on"? Will et al.: yes, thanks, fixed =A7 "policy rules derived from EPRIM, consist" - should that be "= policy rules, derived from EPRIM, that consist"? Will et al.: yes, thanks, fixed =B7 Page 8 o 2.1 Overview =A7 "Relationship among Policy, Service and Resource" (appears tw= ice) - should that be "Relationship between Policy, Service and Resource"? Will et al.: fixed. btw, policy is used to orchestrate and control resource= and service management. However, the reverse is NOT true. Put another way: - Policies are used to control the management of resources and services - Data from resources and services are used to select and/or modify poli= cies during runtime Note that this latter relationship is currently missing from the previous v= ersion, so we merged them into the paragraph below this figure. We also upd= ated the figure based on this point. =A7 Should the caption for Figure 3 end with "models"? Will et al.: Yes, added. Please note that SUPA is trying to be model-driven= . This means that you don't change code directly - you change models, which= then generates the correct code. o 2.2 Operation =A7 "the goals to achieve" - would "the goals to be achieved" be = better? Will et al.: yes, thanks, fixed =B7 Page 9 o 2.3 The GPIM and the EPRIM =A7 The structure of this section feels a little odd. Item (1) ap= pears to repeat a little of what is in the first two paragraphs and I wonde= r whether the section would be better structured if those two paragraphs we= re incorporated into item (1). Will et al.: The first paragraph defines the purpose of the GPIM. The secon= d paragraph says that since we have a common vocabulary, we can relate diff= erent actors that use different representations of policy to each other as = a continuum. Without the common vocabulary, this would be impossible. The third paragraph is confusing and should be deleted. Now, incorporate the gist of what was said in the two points in the first p= aragraph, as follows: The GPIM provides a common vocabulary for representing concepts that are common to expressing different types of policy, but which are independent of language, protocol, repository, and level of abstraction. Hence, the GPIM defines concepts and vocabulary needed by policy management systems independent of the form and content of the policy. The ERPIM is a more specific model that refines the GPIM to specify policy rules in an event-condition-action form =B7 Page 10 o 2.4 Creation of Generic YANG Modules =A7 "the addition of new, as well as editing of existing model el= ements" - should that be "the addition of new, as well as the editing of ex= isting model elements"? Will et al.: yes, thanks, fixed o Pagination fails on the PDF version of this Internet-Draft. Is= this page too long? Will et al.: fixed now. ---cut--- Regards, Will --_000_C9B5F12337F6F841B35C404CF0554ACB89888D33SZXEMA509MBSchi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi all,

After a long off-list discussio= n, we are doing our final review of -01 version of Framework draft after co= mments addressed and figures updated, and will submit -01 version soo= n. Thanks to many reviewers, especially to Jonathan Hansford for his very detailed review. I'm writing to summarize t= hese comments we received as well as our off-list discussion conclusions to= keep the group updated.

The main technical comments are= about the three figures.( Which make sense as this is a framework draft :)= )

Figure 2: added C arrow f= rom GPDM and EPDM to controllers, changed the sentence explaining D arrow.

Some issue still under discussi= on: 1. whether we should show all the cases in charter 2. whether we should= split the design time and running time in this figure. Welcome the group t= o give opinions.

Figure 3: Policies are used to = control the management of resources and services, while data from resources= and services are used to select and/or modify policies during runtime. The= refore, Lines (1)&(2) connecting policy to resource and policy to service are the same, while Line (3) connecting = resource to service is different as it’s navigable only from resource= to service

Also there is one comment reque= sting to reconstruct the section 2.3, and we addressed in the upcoming vers= ion.

There are also a couple of edit= orial issues were pointed out, especially the email from Jonathan helped us= a lot in improving written English and remove the misleading sentences. Ma= ny thanks!

Detailed comments and response = are also showed below starts with Will et al.:"

---start---

&= nbsp; From: "Jonathan Hansford" <jonathan at hansf= ords.net>

&= nbsp; =B7 Gener= al

&= nbsp; o The phrase “the GPIM (or the combinat= ion of the GPIM and the EPRIM)” or its equivalent appears a number of= times throughout this document so clearly it is important but, coming to S= UPA cold, I failed to understand its importance. If there is a need to constantly repeat this phrase, could= it not do with further explanation?

Will et al.: This means that po= licies can be defined using the GPIM directly, or using the combination of = the GPIM and the EPRIM. If you use only the GPIM, you get a technology- and= vendor-independent information model that you are free to map to the data model of your choice; note that the s= tructure of a policy is NOT defined. If you use the GPIM and the EPRIM, you= get a technology- and vendor-independent information model that defines po= licies as an event-condition-action (i.e., imperative) rule.

&= nbsp; =B7 Page = 2

&= nbsp; o 1. Introduction

&= nbsp; =A7 “the task of network operations and manag= ement applications and deploying new services” – is that one ta= sk and, if so, what is it? Should that read “the task of network oper= ations and management applications and deploying new services”?

Will et al.: should be "th= e task of network operations and management applications deploying new serv= ices", fixed

&= nbsp; =B7 Page = 3

&= nbsp; o 1. Introduction

&= nbsp; =A7 s/indepednent/independent

Will et al.: fixed

&= nbsp; =A7 What is the term “snippet” intended= to imply? Should it be defined somewhere?

Will et al.: A "snippet&qu= ot; is a small piece of information (e.g., part of a sentence that was cut = out). We added this sentence at the term first used place for readers bette= r understanding.

&= nbsp; o 2.1 Overview

&= nbsp; =A7 “The GPIM, as well as the combination of = the GPIM and EPRIM, are converted to generic YANG data modules.”= ; Shouldn’t that be either The GPIM, as well as the combination of th= e GPIM and EPRIM, is converted …” or “The GPIM and the combination of the GPIM an= d EPRIM are converted …”?

Will et al.: Technically, you c= ould have both. So "The GPIM, and/or the combination of the GPIM and t= he EPRIM, is converted...".

&= nbsp; =B7 Page = 4

&= nbsp; o 2.1 Overview

&= nbsp; =A7 For consistency with capitalisation, either e.g= . “SUPA Generic & ECA Policy YANG Data modules” or “S= UPA generic policy YANG data modules”

Will et al.: "SUPA Generic= Policy and SUPA ECA Policy YANG data modules", fixed

&= nbsp; =B7 Page = 7

&= nbsp; o 2.1 Overview

&= nbsp; =A7 None of the arrows with Ds appear to be double-= headed and not all of the arrows with Cs

Will et al.: You're right. The = Ds should NOT be double-headed. However, the Cs can be; depends on context.= So we removed the double-headed term for the sentence of Ds.

&= nbsp; =A7 Since lower down we have “ECA Policy Rule= Information Data Model (EPRIM):” for consistency should we not also = have “Generic Policy Information Model (GPIM):”?

Will et al.: yes, thanks, fixed=

&= nbsp; =A7 “query, and implementation languages, and= protocol” (appears twice) – should that be “query, imple= mentation languages, and protocol”?

Will et al.: yes, thanks, fixed=

&= nbsp; =A7 “policy rules for that are” –= should that be “”policy rules that are”?

Will et al.: yes, thanks, fixed=

&= nbsp; =A7 “dependent of” – should that = be “independent of” or “dependent on”?

Will et al.: yes, thanks, fixed=

&= nbsp; =A7 “policy rules derived from EPRIM, consist= ” – should that be “policy rules, derived from EPRIM, tha= t consist”?

Will et al.: yes, thanks, fixed=

&= nbsp; =B7 Page = 8

&= nbsp; o 2.1 Overview

&= nbsp; =A7 “Relationship among Policy, Service and R= esource” (appears twice) – should that be “Relationship b= etween Policy, Service and Resource”?

Will et al.: fixed. btw, policy= is used to orchestrate and control resource and service management. Howeve= r, the reverse is NOT true. Put another way:

- Policies are use= d to control the management of resources and services

- Data from resour= ces and services are used to select and/or modify policies during runtime

Note that this latter relations= hip is currently missing from the previous version, so we merged them into = the paragraph below this figure. We also updated the figure based on this p= oint.

&= nbsp; =A7 Should the caption for Figure 3 end with “= ;models”?

Will et al.: Yes, added. Please= note that SUPA is trying to be model-driven. This means that you don't cha= nge code directly - you change models, which then generates the correct cod= e.

&= nbsp; o 2.2 Operation

&= nbsp; =A7 “the goals to achieve” – woul= d “the goals to be achieved” be better?

Will et al.: yes, thanks, fixed=

&= nbsp; =B7 Page = 9

&= nbsp; o 2.3 The GPIM and the EPRIM

&= nbsp; =A7 The structure of this section feels a little od= d. Item (1) appears to repeat a little of what is in the first two paragrap= hs and I wonder whether the section would be better structured if those two= paragraphs were incorporated into item (1).

Will et al.: The first paragrap= h defines the purpose of the GPIM. The second paragraph says that since we = have a common vocabulary, we can relate different actors that use different= representations of policy to each other as a continuum. Without the common vocabulary, this would be impossible.

The third paragraph is co= nfusing and should be deleted.

Now, incorporate the gist of wh= at was said in the two points in the first paragraph, as follows:

The GPIM provides = a common vocabulary for representing concepts

that are common to= expressing different types of policy, but which

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

abstraction. Hence= , the GPIM defines concepts and vocabulary

needed by policy m= anagement systems independent of the form

and content of the= policy. The ERPIM is a more specific model

that refines the G= PIM to specify policy rules in an

event-condition-ac= tion form

&= nbsp; =B7 Page = 10

&= nbsp; o 2.4 Creation of Generic YANG Modules

&= nbsp; =A7 “the addition of new, as well as editing = of existing model elements” – should that be “the additio= n of new, as well as the editing of existing model elements”?

Will et al.: yes, thanks, fixed=

&= nbsp; o Pagination fails on the PDF version of this= Internet-Draft. Is this page too long?

Will et al.: fixed now. &n= bsp;

---cut---

Regards,

Will

--_000_C9B5F12337F6F841B35C404CF0554ACB89888D33SZXEMA509MBSchi_-- From nobody Thu Nov 17 01:32:04 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F0E5129683; Thu, 17 Nov 2016 01:32:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.798 X-Spam-Level: X-Spam-Status: No, score=-5.798 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=-1.497, 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 Dj0_wcuVa4TS; Thu, 17 Nov 2016 01:32:00 -0800 (PST) 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 2BE84129681; Thu, 17 Nov 2016 01:31:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1479375119; x=1510911119; h=from:subject:cc:to:message-id:date:mime-version: content-transfer-encoding; bh=gap6nfIjgLwuK2fGckLCyaGUYiqxD6BB8Xrd/p2Jms8=; b=Ym8Po4kgxtOm+XH46Jt/T0Gw7JT/9EXYMv9dxy1VvWP2wsYoi8sNDeP2 Zr7NTZKHr0rCEB/DUeeLcIjCzpryX3R/bQLEvk4oEgtfHHnBq9ZqRN2K9 FjAIb/ZxDqB2nhHgb2o1FWxB0m2E4g/Aj58gz8KBDvaC9HJXckRoRszSn pzUZC/NpNzY9cEJdXamFfFy+Ac1Rt7gboOACLcVCO/OkJP40omiLVbNWp SOiuciFMU55Zh2gqtRL0KCINAMxAk/BCeIDu0PhCo8/Ox8eYGIjkCE/k6 KOjS+lDoMcygeoxgx2gEJtiLQ9c5EIXq1Al6wlxjhxfU5wh+X9JwGUfHh Q==; X-IronPort-AV: E=Sophos;i="5.31,653,1473076800"; d="scan'208";a="115631668" X-Ironport-HAT: None - $RELAY-AUTH X-Ironport-Source: 31.133.148.63 - Outgoing - Outgoing-SSL Received: from dhcp-943f.meeting.ietf.org (HELO [31.133.148.63]) ([31.133.148.63]) by mx4-int.auckland.ac.nz with ESMTP; 17 Nov 2016 22:31:53 +1300 From: Nevil Brownlee To: draft-cheng-supa-applicability@ietf.org Message-ID: Date: Thu, 17 Nov 2016 22:31:50 +1300 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: SUPA list Subject: [Supa] We need some good examples of what SUPA can do ! X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is to discuss SUPA $Simplified Use of Policy Abstractions$ related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2016 09:32:02 -0000 Hi all: Your SUPA chairs met this morning with some of the SUPA I-D authors to consider "how can we get people working on some simple examples to demonstrate how SUPA could be used." One idea we considered was "we need a few good example uses, with clear specs written for each - we could start with the examples in our (draft) Applicability Statement. That considers five examples - 4.1. Use Case 1: Switched Ethernet services (SES) 4.2. Use Case 2: Virtualized Private Clouds (VPC) 4.3. Use Case 3: Traffic Manipulation cross DCs 4.4. Use Case 4: Virtual SP 4.5. Use Case 5: Instant VPN 4.6. Use Case 6: traffic optimization and Qos assurance on ISP DC It would help SUPA a lot to have input, especially from network operators, telling us "what do you actually want (SUPA to) do?" Do please give this some thought, and send your 'wishes' text to the SUPA list! Cheers, Nevil -- --------------------------------------------------------------------- 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 Thu Nov 17 01:54:58 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BDAD1295F1; Thu, 17 Nov 2016 01:54:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I4QcPOMR-UaS; Thu, 17 Nov 2016 01:54:56 -0800 (PST) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A94091296E8; Thu, 17 Nov 2016 01:54:55 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 8004F2408CB; Thu, 17 Nov 2016 01:54:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1479376495; bh=AT9g0gr1xh9kMrTH9US175a77iO3x6mtPKQtW2cKx5Q=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=puRtarkUruL7Yp/B4cqBbTDHRrBFVGS4da8usIq9QYofUL48Eo8zrbosLU9nvDoYB 36+UdG3wb4DtLtPLgMMdhwTWia/R5YAjPCNmnlr3C26vUp+9fBild7NyOU+/2eMCJN xcEv3ofXXW6rzQHNDJ8kOFt2IN1BBZLBVARHZDV8= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from dhcp-93c0.meeting.ietf.org (dhcp-93c0.meeting.ietf.org [31.133.147.192]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id BBC3A240258; Thu, 17 Nov 2016 01:54:54 -0800 (PST) To: Nevil Brownlee , draft-cheng-supa-applicability@ietf.org References: From: "Joel M. Halpern" Message-ID: Date: Thu, 17 Nov 2016 04:55:05 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: SUPA list Subject: Re: [Supa] We need some good examples of what SUPA can do ! X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is to discuss SUPA $Simplified Use of Policy Abstractions$ related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2016 09:54:57 -0000 What I would find particularly useful woulde be examples of policies or policy sets that we can show how to represent using the SUPA model. Yours, joel On 11/17/16 4:31 AM, Nevil Brownlee wrote: > Hi all: > > Your SUPA chairs met this morning with some of the SUPA I-D > authors to consider "how can we get people working on some > simple examples to demonstrate how SUPA could be used." > > One idea we considered was "we need a few good example uses, > with clear specs written for each - we could start with the > examples in our (draft) Applicability Statement. That considers > five examples - > > 4.1. Use Case 1: Switched Ethernet services (SES) > 4.2. Use Case 2: Virtualized Private Clouds (VPC) > 4.3. Use Case 3: Traffic Manipulation cross DCs > 4.4. Use Case 4: Virtual SP > 4.5. Use Case 5: Instant VPN > 4.6. Use Case 6: traffic optimization and Qos assurance on ISP DC > > It would help SUPA a lot to have input, especially from network > operators, telling us "what do you actually want (SUPA to) do?" > > Do please give this some thought, and send your 'wishes' text to > the SUPA list! > > Cheers, Nevil > From nobody Thu Nov 17 12:27:29 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69ED8129607 for ; Thu, 17 Nov 2016 12:27:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.346 X-Spam-Level: ** X-Spam-Status: No, score=2.346 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=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 rFa-yxJz9rXO for ; Thu, 17 Nov 2016 12:27:26 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 EEA36129561 for ; Thu, 17 Nov 2016 12:27:25 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=31.133.152.135; From: "Susan Hares" To: Date: Thu, 17 Nov 2016 15:24:48 -0500 Message-ID: <028a01d24110$a880a110$f981e330$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_028B_01D240E6.BFAB8370" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdJBECNlOM2fsmngTuuXj2iYHLIffQ== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: "'Joel M. Halpern'" , pauljeong@skku.edu, 'Linda Dunbar' , 'John Strassner' Subject: [Supa] SUPA success X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is to discuss SUPA $Simplified Use of Policy Abstractions$ related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2016 20:27:27 -0000 This is a multipart message in MIME format. ------=_NextPart_000_028B_01D240E6.BFAB8370 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Nevil: It appears my nomcom duties will make it impossible to join SUPA. The SUPA success is simple: The SUPA work is simple: SUPA policy - helped developed I2NSF capability information model The I2NSF capability information model helped us develop the I2NSF yang data model. Paul Jeong's team took the I2NSF Yang data models. They modified the single data models into multiple to create logical pieces, and implemented this code between IETF 96 an IETF 97 for the Hackathon at this IETF (IETF 97). It supports filtering (firewall, DPI, forwarding) or bypass (DPI, forwarding). It supported a VoIP filtering. Without the thoughtful policy work, the capability work in I2NSF would have taken longer. Sue ------=_NextPart_000_028B_01D240E6.BFAB8370 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Nevil:

It = appears my nomcom duties will make it impossible to join SUPA. The = SUPA success is simple:

The = SUPA work is simple:

SUPA = policy - helped developed I2NSF capability information model The = I2NSF capability information model helped us develop the I2NSF yang data = model.

Paul Jeong’s team took the I2NSF Yang data = models. They modified the single data models into multiple to = create logical pieces, and implemented this code between IETF 96 an IETF = 97 for the Hackathon at this IETF (IETF 97). It supports filtering = (firewall, DPI, forwarding) or bypass (DPI, forwarding). It = supported a VoIP filtering.

Without the thoughtful policy work, the capability = work in I2NSF would have taken longer.

Sue =

------=_NextPart_000_028B_01D240E6.BFAB8370-- From nobody Thu Nov 17 14:04:25 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64E9312947E; Thu, 17 Nov 2016 14:04:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.718 X-Spam-Level: X-Spam-Status: No, score=-5.718 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=-1.497, 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 r5P7A3DvE1cC; Thu, 17 Nov 2016 14:04:22 -0800 (PST) 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 5F6CC129479; Thu, 17 Nov 2016 14:04:21 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CVJ99153; Thu, 17 Nov 2016 22:04:16 +0000 (GMT) Received: from DFWEML701-CAH.china.huawei.com (10.193.5.175) by lhreml705-cah.china.huawei.com (10.201.5.168) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 17 Nov 2016 22:03:38 +0000 Received: from DFWEML501-MBS.china.huawei.com ([10.193.5.222]) by dfweml701-cah.china.huawei.com ([10.193.5.175]) with mapi id 14.03.0235.001; Thu, 17 Nov 2016 14:03:35 -0800 From: John Strassner To: Nevil Brownlee , "draft-cheng-supa-applicability@ietf.org" , John Strassner Thread-Topic: [Supa] We need some good examples of what SUPA can do ! Thread-Index: AQHSQLWGDMPUz5kTbEit85ik1wGrraDdqV/g Date: Thu, 17 Nov 2016 22:03:34 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.245.11] 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.0A0B0208.582E2962.0072, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 03fed9005732f26bbc6450fa8f42aab5 Archived-At: Cc: "'Joel M. Halpern'" , SUPA list Subject: Re: [Supa] We need some good examples of what SUPA can do ! X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is to discuss SUPA $Simplified Use of Policy Abstractions$ related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2016 22:04:24 -0000 Hi Nevil and Dan, One of my other roles is the Orchestration Area Co-Director of the MEF. We = have the following uses of SUPA artifacts planned: 1) we will use the SUPA IM and DM as-is, and then add to both, to represent policies to manage MEF Third Network Services; 2) we will use the above SUPA models and extensions in the MEF policy-driven orchestration project 3) we will use the above SUPA models and extensions in the MEF OpenLSO project to develop open source tools and open source policy systems We will hopefully be able to share the open source work in a future IETF Ha= ckathon once it is mature and stable. Best, John -----Original Message----- From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of Nevil Brownlee Sent: Thursday, November 17, 2016 1:32 AM To: draft-cheng-supa-applicability@ietf.org Cc: SUPA list Subject: [Supa] We need some good examples of what SUPA can do ! Hi all: Your SUPA chairs met this morning with some of the SUPA I-D authors to cons= ider "how can we get people working on some simple examples to demonstrate = how SUPA could be used." One idea we considered was "we need a few good example uses, with clear spe= cs written for each - we could start with the examples in our (draft) Appli= cability Statement. That considers five examples - 4.1. Use Case 1: Switched Ethernet services (SES) 4.2. Use Case 2: Virtualized Private Clouds (VPC) 4.3. Use Case 3: Traffic Manipulation cross DCs 4.4. Use Case 4: Virtual SP 4.5. Use Case 5: Instant VPN 4.6. Use Case 6: traffic optimization and Qos assurance on ISP DC It would help SUPA a lot to have input, especially from network operators, = telling us "what do you actually want (SUPA to) do?" Do please give this some thought, and send your 'wishes' text to the SUPA l= ist! 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 From nobody Thu Nov 17 17:28:22 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFD3F129429 for ; Thu, 17 Nov 2016 17:28:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001] autolearn=unavailable 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 yFQV0NS-TTtl for ; Thu, 17 Nov 2016 17:28:18 -0800 (PST) Received: from lb1-smtp-cloud6.xs4all.net (lb1-smtp-cloud6.xs4all.net [194.109.24.24]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58A78126579 for ; Thu, 17 Nov 2016 17:28:18 -0800 (PST) Received: from dhcp-8e4b.meeting.ietf.org ([31.133.142.75]) by smtp-cloud6.xs4all.net with ESMTP id 9DU91u00A1dofpr01DUD3H; Fri, 18 Nov 2016 02:28:16 +0100 To: Nevil Brownlee , draft-cheng-supa-applicability@ietf.org References: From: "Bert Wijnen (IETF)" Message-ID: Date: Fri, 18 Nov 2016 10:28:09 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: SUPA list Subject: Re: [Supa] We need some good examples of what SUPA can do ! X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is to discuss SUPA $Simplified Use of Policy Abstractions$ related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2016 01:28:21 -0000 Could the proponets of the current (in my view still complex) IM and DM work out how one would define/configure/populate the policies for: ensure that SNMP is blocked on ports at the edge of the administrative domain to prevent SNMP going out or coming in from outside the enterprise. This should be simple, no? Thanks, Bert On 17/11/2016 18:31, Nevil Brownlee wrote: > Hi all: > > Your SUPA chairs met this morning with some of the SUPA I-D > authors to consider "how can we get people working on some > simple examples to demonstrate how SUPA could be used." > > One idea we considered was "we need a few good example uses, > with clear specs written for each - we could start with the > examples in our (draft) Applicability Statement. That considers > five examples - > > 4.1. Use Case 1: Switched Ethernet services (SES) > 4.2. Use Case 2: Virtualized Private Clouds (VPC) > 4.3. Use Case 3: Traffic Manipulation cross DCs > 4.4. Use Case 4: Virtual SP > 4.5. Use Case 5: Instant VPN > 4.6. Use Case 6: traffic optimization and Qos assurance on ISP DC > > It would help SUPA a lot to have input, especially from network > operators, telling us "what do you actually want (SUPA to) do?" > > Do please give this some thought, and send your 'wishes' text to > the SUPA list! > > Cheers, Nevil > From nobody Thu Nov 17 17:45:08 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0DC212985B; Thu, 17 Nov 2016 17:45:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1WiZWeQ8ms6L; Thu, 17 Nov 2016 17:45:03 -0800 (PST) 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 797891299E4; Thu, 17 Nov 2016 17:44:47 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 5FF8CDC0390; Thu, 17 Nov 2016 17:44:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1479433487; bh=gFWK9Zm7YiYjPDc9l4KEkZ70yH76OpY68GRT+sVLpUk=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=jZx9MV+hqKIQMFlUcxTGlT8esKzuReH3WpZw0Z6Ag7TrovuKbrSgmzx78oQvXAKP2 oQZMpSdnUyciVGEAPR47MZf/IHab0XKOZhgm3YdbkvMBX9dqYi8JFPCeV4DHkQCZqh B0gK8DkgU6pV3L35gIynkpnxJt3Rv0yRjSh4u8b4= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from dhcp-893a.meeting.ietf.org (unknown [31.133.138.58]) (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 6F93ADC038B; Thu, 17 Nov 2016 17:44:46 -0800 (PST) To: "Bert Wijnen (IETF)" , Nevil Brownlee , draft-cheng-supa-applicability@ietf.org References:

From: "Joel M. Halpern" Message-ID: Date: Thu, 17 Nov 2016 20:44:45 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: SUPA list Subject: Re: [Supa] We need some good examples of what SUPA can do ! X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is to discuss SUPA $Simplified Use of Policy Abstractions$ related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2016 01:45:07 -0000 Thank you Bert. That is exactly the kind of request I am looking for. No, I do not think it will be simple to answer your question. But I do think that showing how to do so will show both what we have and what more we need. Yours, Joel On 11/17/16 8:28 PM, Bert Wijnen (IETF) wrote: > Could the proponets of the current (in my view still complex) IM and DM > work out how one would define/configure/populate the policies for: > > ensure that SNMP is blocked on ports at the edge > of the administrative domain to prevent SNMP going > out or coming in from outside the enterprise. > > This should be simple, no? > > Thanks, Bert > > On 17/11/2016 18:31, Nevil Brownlee wrote: >> Hi all: >> >> Your SUPA chairs met this morning with some of the SUPA I-D >> authors to consider "how can we get people working on some >> simple examples to demonstrate how SUPA could be used." >> >> One idea we considered was "we need a few good example uses, >> with clear specs written for each - we could start with the >> examples in our (draft) Applicability Statement. That considers >> five examples - >> >> 4.1. Use Case 1: Switched Ethernet services (SES) >> 4.2. Use Case 2: Virtualized Private Clouds (VPC) >> 4.3. Use Case 3: Traffic Manipulation cross DCs >> 4.4. Use Case 4: Virtual SP >> 4.5. Use Case 5: Instant VPN >> 4.6. Use Case 6: traffic optimization and Qos assurance on ISP DC >> >> It would help SUPA a lot to have input, especially from network >> operators, telling us "what do you actually want (SUPA to) do?" >> >> Do please give this some thought, and send your 'wishes' text to >> the SUPA list! >> >> Cheers, Nevil >> > > _______________________________________________ > Supa mailing list > Supa@ietf.org > https://www.ietf.org/mailman/listinfo/supa > From nobody Thu Nov 17 18:43:33 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E1D11294B5; Thu, 17 Nov 2016 18:43:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.418 X-Spam-Level: X-Spam-Status: No, score=-2.418 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=-1.497, 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 dPLY26dCxzlM; Thu, 17 Nov 2016 18:43:28 -0800 (PST) Received: from sendg.mailex.chinaunicom.cn (sendg.mailex.chinaunicom.cn [210.53.66.230]) by ietfa.amsl.com (Postfix) with ESMTP id D1FCB126CD8; Thu, 17 Nov 2016 18:43:25 -0800 (PST) X-AuditID: 0a000f35-f793b6d000004ac9-1d-582e6addcb24 Received: from M10-CEN-MLHUB02.cnc.intra ( [10.0.192.42]) by sendg.mailex.chinaunicom.cn (Symantec Messaging Gateway) with SMTP id 52.2E.19145.DDA6E285; Fri, 18 Nov 2016 10:43:41 +0800 (HKT) Received: from M10-HQ-MLCEN06.cnc.intra (10.249.212.36) by M10-CEN-MLHUB02.cnc.intra (10.0.192.42) with Microsoft SMTP Server (TLS) id 8.3.406.0; Fri, 18 Nov 2016 10:43:32 +0800 Received: from M10-HQ-ML06.hq.cnc.intra (10.249.213.76) by M10-HQ-MLCEN06.cnc.intra (10.249.212.36) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Fri, 18 Nov 2016 10:43:32 +0800 Received: from ying-PC (10.161.31.196) by M10-HQ-ML06.hq.cnc.intra (10.249.213.76) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Fri, 18 Nov 2016 10:43:32 +0800 Date: Fri, 18 Nov 2016 10:43:17 +0800 From: =?utf-8?B?WWluZyBDaGVuZw==?= To: =?utf-8?B?TmV2aWwgQnJvd25sZWU=?= , =?utf-8?B?ZC5raW5n?= Message-ID: <201611181043173697826@chinaunicom.cn> X-mailer: Foxmail 6, 15, 201, 26 [cn] MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=====003_Dragon783067356188_=====" X-Originating-IP: [10.161.31.196] X-ClientProxiedBy: M10-HQ-MLF03.hq.cnc.intra (10.249.213.52) To M10-HQ-ML06.hq.cnc.intra (10.249.213.76) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrILMWRmVeSWpSXmKPExsXCxXBAS/dull6Ewcm1khYv1gVbPJjwnN3i 9a27jBazt6xidmDx+P37IaPHkiU/mTxOHUgPYI7isklJzcksSy3St0vgyjjXcoqloCOn4srV j+wNjBMyuxg5OSQETCSeru9gh7DFJC7cW8/WxcjFISRwgFFi6taJ7BDOVkaJIytmsEI4Oxgl 1p7YzALhLGeUePq5ESjDwcEioCoxbyknyCg2AXuJpu27WEFsEYFCiV+Xm5lAbGaBOYwSax5m gNjCArESE3c+ZQSxeQWMJI6umMMIcYaqxNW2PiaIuKDEyZlPWCB6gyV2NT1nB1klJKAusfyW HUS5osSLy6eZQMISAlkSVz4JTmAUmoWkeRaS5llAVcwCmhLrd+lDhBUlpnQ/ZIewNSRa58xl RxZfwMi2ipEr2NfdwtjCQNffeBMjOCL4TXcw3l7oeohRgINRiYd3QYJehBBrYllxZe4hRgkO ZiUR3oZkoBBvSmJlVWpRfnxRaU5q8SFGaQ4WJXHeWj7NCCGB9MSS1OzU1ILUIpgsEwenVANj kKW35+V+qY2FaxLuSShUc674cphp3jX9B1syT3839/q+ql+b780rCTPWbrHeKG4W323ZbI8l lYzU5Z7F7+jf4zzDR8NE1qxEUHKGYVS8W+wVlSNP2Tb856y2veXW7LDqzLyugI+y8/M+Kegm nBWNWtek5e12xLv23+GSktxua4ZMy3L3FUosxRmJhlrMRcWJAPxmzByEAgAA Archived-At: Cc: =?utf-8?B?ZHJhZnQtY2hlbmctc3VwYS1hcHBsaWNhYmlsaXR5QGlldGYub3Jn?= , =?utf-8?B?U1VQQSBsaXN0?= Subject: Re: [Supa] =?utf-8?q?We_need_some_good_examples_of_what_SUPA_can_do_!?= X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is to discuss SUPA $Simplified Use of Policy Abstractions$ related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2016 02:43:32 -0000 --=====003_Dragon783067356188_===== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBOZXZpbCwgRGFuLCBldCBhbCwNCg0KSSBzdXBwb3J0IHRoaXMgcHJvcG9zYWwgd2hpY2gg bWF5IG1ha2Ugb3VyIHdvcmsgbW9yZSBjb252ZXJnZW50IGFuZCBlZmZpY2llbnQuIFdlIGRpc2N1 c3MgdGhlIHVzZSBjYXNlIHNldCBmb3IgYSBsb25nIHRpbWUgc2luY2UgdGhlIGNyZWF0aW9uIG9m IFNVUEEgY29uY2VwdCBhbmQgSSBhbSB2ZXJ5IGdsYWQgdG8gc2VlIHRoYXQgdGhlIFNVUEEgSU0g YW5kIERNIGFyZSBuZWFybHkgbWF0dXJlIHRvIGJlIHVzZWQgaW4gdGhlIHVzZSBjYXNlIGRlc2Ny aXB0aW9uLg0KDQpSZWdhcmRpbmcgdGhlIGN1cnJlbnQgdXNlIGNhc2VzIGluIGFwcGxpY2FiaWxp dHkgZHJhZnQsIEkgcHJvcG9zZSB0byBzdGFydCB3aXRoIFZQQyAodXNlIGNhc2UgMikgYW5kIGlu c3RhbnQgVlBOICh1c2UgY2FzZSA1KSAsIHdob3NlIHNpbWlsYXIgaW1wbGVtZW50YXRpb24gY2Fu IGJlIGZvdW5kIGluIENoaW5hIFVuaWNvbSBhbmQgd2hlcmUgU1VQQSBETSBhbmQgSU0gY2FuIGhl bHAgdG8gZW5hYmxlIHRoZSBzY2FsYWJsZSBhbmQgY29uc2lzdGVudCBwcm9ncmFtbWF0aWMgY29u dHJvbC4NCg0KVGhhbmtzIGFuZCBiZXN0IHJlZ2FyZHMsDQpZaW5nDQoNCjIwMTYtMTEtMTgNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpZaW5nIENIRU5HICDnqIvojrkNClRlY2hu b2xvZ3kgRGVwYXJ0bWVudCwgQ2hpbmEgVW5pY29tIOS4reWbveiBlOmAmumbhuWbouaKgOacr+mD qA0KVGVsOiArODYtMTAtNjYyNTkzOTQNCk1vYmlsZTogKzg2LTE4NjAxMTAyOTcxDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0K5Y+R5Lu25Lq677yaIE5ldmlsIEJyb3dubGVlDQrl j5HpgIHml7bpl7TvvJogMjAxNi0xMS0xNyAgMTc6MzI6MTMNCuaUtuS7tuS6uu+8miBkcmFmdC1j aGVuZy1zdXBhLWFwcGxpY2FiaWxpdHlAaWV0Zi5vcmcNCuaKhOmAge+8miBTVVBBIGxpc3QNCuS4 u+mimO+8miBXZSBuZWVkIHNvbWUgZ29vZCBleGFtcGxlcyBvZiB3aGF0IFNVUEEgY2FuIGRvICEN CkhpIGFsbDoNCllvdXIgU1VQQSBjaGFpcnMgbWV0IHRoaXMgbW9ybmluZyB3aXRoIHNvbWUgb2Yg dGhlIFNVUEEgSS1EDQphdXRob3JzIHRvIGNvbnNpZGVyICJob3cgY2FuIHdlIGdldCBwZW9wbGUg d29ya2luZyBvbiBzb21lDQpzaW1wbGUgZXhhbXBsZXMgdG8gZGVtb25zdHJhdGUgaG93IFNVUEEg Y291bGQgYmUgdXNlZC4iDQpPbmUgaWRlYSB3ZSBjb25zaWRlcmVkIHdhcyAid2UgbmVlZCBhIGZl dyBnb29kIGV4YW1wbGUgdXNlcywNCndpdGggY2xlYXIgc3BlY3Mgd3JpdHRlbiBmb3IgZWFjaCAt IHdlIGNvdWxkIHN0YXJ0IHdpdGggdGhlDQpleGFtcGxlcyBpbiBvdXIgKGRyYWZ0KSBBcHBsaWNh YmlsaXR5IFN0YXRlbWVudC4gIFRoYXQgY29uc2lkZXJzDQpmaXZlIGV4YW1wbGVzIC0NCiAgIDQu MS4gIFVzZSBDYXNlIDE6IFN3aXRjaGVkIEV0aGVybmV0IHNlcnZpY2VzIChTRVMpDQogICA0LjIu ICBVc2UgQ2FzZSAyOiBWaXJ0dWFsaXplZCBQcml2YXRlIENsb3VkcyAoVlBDKQ0KICAgNC4zLiAg VXNlIENhc2UgMzogVHJhZmZpYyBNYW5pcHVsYXRpb24gY3Jvc3MgRENzDQogICA0LjQuICBVc2Ug Q2FzZSA0OiBWaXJ0dWFsIFNQDQogICA0LjUuICBVc2UgQ2FzZSA1OiBJbnN0YW50IFZQTg0KICAg NC42LiAgVXNlIENhc2UgNjogdHJhZmZpYyBvcHRpbWl6YXRpb24gYW5kIFFvcyBhc3N1cmFuY2Ug b24gSVNQIERDDQpJdCB3b3VsZCBoZWxwIFNVUEEgYSBsb3QgdG8gaGF2ZSBpbnB1dCwgZXNwZWNp YWxseSBmcm9tIG5ldHdvcmsNCm9wZXJhdG9ycywgdGVsbGluZyB1cyAid2hhdCBkbyB5b3UgYWN0 dWFsbHkgd2FudCAoU1VQQSB0bykgZG8/Ig0KRG8gcGxlYXNlIGdpdmUgdGhpcyBzb21lIHRob3Vn aHQsIGFuZCBzZW5kIHlvdXIgJ3dpc2hlcycgdGV4dCB0bw0KdGhlIFNVUEEgbGlzdCENCkNoZWVy cywgTmV2aWwNCi0tDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiAgTmV2aWwgQnJvd25sZWUgICAgICAgICAgICAg ICAgICAgIENvbXB1dGVyIFNjaWVuY2UgRGVwYXJ0bWVudCB8IElUUw0KICBQaG9uZTogKzY0IDkg MzczIDc1OTkgeDg4OTQxICAgICAgICAgICAgIFRoZSBVbml2ZXJzaXR5IG9mIEF1Y2tsYW5kDQog IEZBWDogKzY0IDkgMzczIDc0NTMgICBQcml2YXRlIEJhZyA5MjAxOSwgQXVja2xhbmQgMTE0Miwg TmV3IFplYWxhbmQNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCuWmguaenOaC qOmUmeivr+aOpeaUtuS6huivpemCruS7tu+8jOivt+mAmui/h+eUteWtkOmCruS7tueri+WNs+mA muefpeaIkeS7rOOAguivt+WbnuWkjemCruS7tuWIsGhxcy1zcG1jQGNoaW5hdW5pY29tLmNu77yM 5Y2z5Y+v5Lul6YCA6K6i5q2k6YKu5Lu244CC5oiR5Lus5bCG56uL5Y2z5bCG5oKo55qE5L+h5oGv 5LuO5oiR5Lus55qE5Y+R6YCB55uu5b2V5Lit5Yig6Zmk44CCDQpJZiB5b3UgaGF2ZSByZWNlaXZl ZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdXMgaW1tZWRpYXRlbHkgYnkgZS1t YWlsLiBQbGVhc2UgcmVwbHkgdG8gaHFzLXNwbWNAY2hpbmF1bmljb20uY24gaWYgeW91IHdhbnQg dG8gdW5zdWJzY3JpYmUgZnJvbSB0aGlzIG1haWwuIFdlIHdpbGwgaW1tZWRpYXRlbHkgcmVtb3Zl IHlvdXIgaW5mb3JtYXRpb24gZnJvbSBvdXIgc2VuZGluZyBjYXRhbG9ndWUuDQo= --=====003_Dragon783067356188_===== Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxodG1sPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNv bnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8c3R5bGUgdHlwZT0idGV4dC9jc3Mi PkBpbXBvcnQgdXJsKCBDOlxVc2Vyc1x5aW5nXEFwcERhdGFcUm9hbWluZ1xGb3htYWlsXEZveFRl bXA2LjUoNjcpXFxzY3JvbGxiYXIuY3NzICk7DQo8L3N0eWxlPg0KPG1ldGEgbmFtZT0iR0VORVJB VE9SIiBjb250ZW50PSJNU0hUTUwgOC4wMC43NjAxLjE5MTA0Ij4NCjxzdHlsZT5AZm9udC1mYWNl IHsNCglmb250LWZhbWlseTog5a6L5L2TOw0KfQ0KQGZvbnQtZmFjZSB7DQoJZm9udC1mYW1pbHk6 IFZlcmRhbmE7DQp9DQpAZm9udC1mYWNlIHsNCglmb250LWZhbWlseTogQOWui+S9kzsNCn0NCkBw YWdlIFNlY3Rpb24xIHtzaXplOiA1OTUuM3B0IDg0MS45cHQ7IG1hcmdpbjogNzIuMHB0IDkwLjBw dCA3Mi4wcHQgOTAuMHB0OyBsYXlvdXQtZ3JpZDogMTUuNnB0OyB9DQpQLk1zb05vcm1hbCB7DQoJ VEVYVC1KVVNUSUZZOiBpbnRlci1pZGVvZ3JhcGg7IFRFWFQtQUxJR046IGp1c3RpZnk7IE1BUkdJ TjogMGNtIDBjbSAwcHQ7IEZPTlQtRkFNSUxZOiAiVGltZXMgTmV3IFJvbWFuIjsgRk9OVC1TSVpF OiAxMC41cHQNCn0NCkxJLk1zb05vcm1hbCB7DQoJVEVYVC1KVVNUSUZZOiBpbnRlci1pZGVvZ3Jh cGg7IFRFWFQtQUxJR046IGp1c3RpZnk7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IEZPTlQtRkFNSUxZ OiAiVGltZXMgTmV3IFJvbWFuIjsgRk9OVC1TSVpFOiAxMC41cHQNCn0NCkRJVi5Nc29Ob3JtYWwg ew0KCVRFWFQtSlVTVElGWTogaW50ZXItaWRlb2dyYXBoOyBURVhULUFMSUdOOiBqdXN0aWZ5OyBN QVJHSU46IDBjbSAwY20gMHB0OyBGT05ULUZBTUlMWTogIlRpbWVzIE5ldyBSb21hbiI7IEZPTlQt U0laRTogMTAuNXB0DQp9DQpBOmxpbmsgew0KCUNPTE9SOiBibHVlOyBURVhULURFQ09SQVRJT046 IHVuZGVybGluZQ0KfQ0KU1BBTi5Nc29IeXBlcmxpbmsgew0KCUNPTE9SOiBibHVlOyBURVhULURF Q09SQVRJT046IHVuZGVybGluZQ0KfQ0KQTp2aXNpdGVkIHsNCglDT0xPUjogcHVycGxlOyBURVhU LURFQ09SQVRJT046IHVuZGVybGluZQ0KfQ0KU1BBTi5Nc29IeXBlcmxpbmtGb2xsb3dlZCB7DQoJ Q09MT1I6IHB1cnBsZTsgVEVYVC1ERUNPUkFUSU9OOiB1bmRlcmxpbmUNCn0NClNQQU4uRW1haWxT dHlsZTE3IHsNCglGT05ULVNUWUxFOiBub3JtYWw7IEZPTlQtRkFNSUxZOiBWZXJkYW5hOyBDT0xP Ujogd2luZG93dGV4dDsgRk9OVC1XRUlHSFQ6IG5vcm1hbDsgVEVYVC1ERUNPUkFUSU9OOiBub25l OyBtc28tc3R5bGUtdHlwZTogcGVyc29uYWwtY29tcG9zZQ0KfQ0KRElWLlNlY3Rpb24xIHsNCglw YWdlOiBTZWN0aW9uMQ0KfQ0KVU5LTk9XTiB7DQoJRk9OVC1TSVpFOiAxMHB0DQp9DQpCTE9DS1FV T1RFIHsNCglNQVJHSU4tVE9QOiAwcHg7IE1BUkdJTi1CT1RUT006IDBweDsgTUFSR0lOLUxFRlQ6 IDJlbQ0KfQ0KT0wgew0KCU1BUkdJTi1UT1A6IDBweDsgTUFSR0lOLUJPVFRPTTogMHB4DQp9DQpV TCB7DQoJTUFSR0lOLVRPUDogMHB4OyBNQVJHSU4tQk9UVE9NOiAwcHgNCn0NCjwvc3R5bGU+DQo8 L2hlYWQ+DQo8Ym9keSBzdHlsZT0iTUFSR0lOOiAxMHB4OyBGT05ULUZBTUlMWTogdmVyZGFuYTsg Rk9OVC1TSVpFOiAxMHB0Ij4NCjxkaXY+PGZvbnQgY29sb3I9IiMwMDAwODAiIHNpemU9IjIiIGZh Y2U9IlZlcmRhbmEiPkRlYXIgTmV2aWwsIERhbiwgZXQgYWwsPC9mb250PjwvZGl2Pg0KPGRpdj48 Zm9udCBjb2xvcj0iIzAwMDA4MCI+PC9mb250PiZuYnNwOzwvZGl2Pg0KPGRpdj48Zm9udCBjb2xv cj0iIzAwMDA4MCI+SSBzdXBwb3J0IHRoaXMgcHJvcG9zYWwgd2hpY2ggbWF5IG1ha2UmbmJzcDtv dXIgd29yayBtb3JlIGNvbnZlcmdlbnQgYW5kIGVmZmljaWVudC4gV2UgZGlzY3VzcyB0aGUgdXNl IGNhc2Ugc2V0IGZvciBhIGxvbmcgdGltZSBzaW5jZSB0aGUgY3JlYXRpb24gb2YgU1VQQSZuYnNw O2NvbmNlcHQgYW5kIEkgYW0gdmVyeSBnbGFkIHRvIHNlZSB0aGF0IHRoZSBTVVBBIElNIGFuZCBE TSBhcmUgbmVhcmx5IG1hdHVyZSB0byBiZQ0KIHVzZWQgaW4gdGhlIHVzZSBjYXNlIGRlc2NyaXB0 aW9uLjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgY29sb3I9IiMwMDAwODAiPjwvZm9udD4mbmJz cDs8L2Rpdj4NCjxkaXY+PGZvbnQgY29sb3I9IiMwMDAwODAiPlJlZ2FyZGluZyB0aGUgY3VycmVu dCB1c2UgY2FzZXMgaW4gYXBwbGljYWJpbGl0eSBkcmFmdCwgSSBwcm9wb3NlIHRvIHN0YXJ0IHdp dGggVlBDICh1c2UgY2FzZSAyKSBhbmQgaW5zdGFudCBWUE4gKHVzZSBjYXNlIDUpICwgd2hvc2Ug c2ltaWxhciBpbXBsZW1lbnRhdGlvbiBjYW4gYmUgZm91bmQgaW4gQ2hpbmEgVW5pY29tIGFuZCB3 aGVyZSBTVVBBIERNIGFuZCBJTSBjYW4gaGVscCB0byBlbmFibGUNCiB0aGUgc2NhbGFibGUgYW5k IGNvbnNpc3RlbnQgcHJvZ3JhbW1hdGljIGNvbnRyb2wuJm5ic3A7PC9mb250PjwvZGl2Pg0KPGRp dj48Zm9udCBjb2xvcj0iIzAwMDA4MCI+PC9mb250PiZuYnNwOzwvZGl2Pg0KPGRpdj48Zm9udCBj b2xvcj0iIzAwMDA4MCI+VGhhbmtzIGFuZCBiZXN0IHJlZ2FyZHMsPC9mb250PjwvZGl2Pg0KPGRp dj48Zm9udCBjb2xvcj0iIzAwMDA4MCI+WWluZzwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgY29s b3I9IiMwMDAwODAiPjwvZm9udD4mbmJzcDs8L2Rpdj4NCjxkaXY+PGZvbnQgY29sb3I9IiNjMGMw YzAiIHNpemU9IjIiIGZhY2U9IlZlcmRhbmEiPjIwMTYtMTEtMTggPC9mb250PjwvZGl2Pg0KPGZv bnQgY29sb3I9IiMwMDAwODAiIHNpemU9IjIiIGZhY2U9IlZlcmRhbmEiPg0KPGhyIHN0eWxlPSJX SURUSDogMTAwcHgiIGFsaWduPSJsZWZ0IiBjb2xvcj0iI2I1YzRkZiIgc2l6ZT0iMSI+DQo8L2Zv bnQ+DQo8ZGl2Pjxmb250IGNvbG9yPSIjYzBjMGMwIiBzaXplPSIyIiBmYWNlPSJWZXJkYW5hIj48 c3Bhbj4NCjxkaXY+WWluZyBDSEVORyZuYnNwOyDnqIvojrk8YnI+DQpUZWNobm9sb2d5IERlcGFy dG1lbnQsIENoaW5hIFVuaWNvbSDkuK3lm73ogZTpgJrpm4blm6LmioDmnK/pg6g8YnI+DQpUZWw6 ICYjNDM7ODYtMTAtNjYyNTkzOTQ8YnI+DQpNb2JpbGU6ICYjNDM7ODYtMTg2MDExMDI5NzEgPC9k aXY+DQo8L3NwYW4+PC9mb250PjwvZGl2Pg0KPGhyIGNvbG9yPSIjYjVjNGRmIiBzaXplPSIxIj4N CjxkaXY+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iVmVyZGFuYSI+PHN0cm9uZz7lj5Hku7bkurrvvJo8 L3N0cm9uZz4gTmV2aWwgQnJvd25sZWUgPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBzaXplPSIy IiBmYWNlPSJWZXJkYW5hIj48c3Ryb25nPuWPkemAgeaXtumXtO+8mjwvc3Ryb25nPiAyMDE2LTEx LTE3Jm5ic3A7IDE3OjMyOjEzIDwvZm9udD4NCjwvZGl2Pg0KPGRpdj48Zm9udCBzaXplPSIyIiBm YWNlPSJWZXJkYW5hIj48c3Ryb25nPuaUtuS7tuS6uu+8mjwvc3Ryb25nPiBkcmFmdC1jaGVuZy1z dXBhLWFwcGxpY2FiaWxpdHlAaWV0Zi5vcmcNCjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgc2l6 ZT0iMiIgZmFjZT0iVmVyZGFuYSI+PHN0cm9uZz7mioTpgIHvvJo8L3N0cm9uZz4gU1VQQSBsaXN0 IDwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iVmVyZGFuYSI+PHN0cm9u Zz7kuLvpopjvvJo8L3N0cm9uZz4gV2UgbmVlZCBzb21lIGdvb2QgZXhhbXBsZXMgb2Ygd2hhdCBT VVBBIGNhbiBkbyAhDQo8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IHNpemU9IjIiIGZhY2U9IlZl cmRhbmEiPjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iVmVyZGFuYSI+ DQo8ZGl2PkhpJm5ic3A7YWxsOjwvZGl2Pg0KPGRpdj48L2Rpdj4NCjxkaXY+WW91ciZuYnNwO1NV UEEmbmJzcDtjaGFpcnMmbmJzcDttZXQmbmJzcDt0aGlzJm5ic3A7bW9ybmluZyZuYnNwO3dpdGgm bmJzcDtzb21lJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtTVVBBJm5ic3A7SS1EPC9kaXY+DQo8ZGl2 PmF1dGhvcnMmbmJzcDt0byZuYnNwO2NvbnNpZGVyJm5ic3A7JnF1b3Q7aG93Jm5ic3A7Y2FuJm5i c3A7d2UmbmJzcDtnZXQmbmJzcDtwZW9wbGUmbmJzcDt3b3JraW5nJm5ic3A7b24mbmJzcDtzb21l PC9kaXY+DQo8ZGl2PnNpbXBsZSZuYnNwO2V4YW1wbGVzJm5ic3A7dG8mbmJzcDtkZW1vbnN0cmF0 ZSZuYnNwO2hvdyZuYnNwO1NVUEEmbmJzcDtjb3VsZCZuYnNwO2JlJm5ic3A7dXNlZC4mcXVvdDs8 L2Rpdj4NCjxkaXY+PC9kaXY+DQo8ZGl2Pk9uZSZuYnNwO2lkZWEmbmJzcDt3ZSZuYnNwO2NvbnNp ZGVyZWQmbmJzcDt3YXMmbmJzcDsmcXVvdDt3ZSZuYnNwO25lZWQmbmJzcDthJm5ic3A7ZmV3Jm5i c3A7Z29vZCZuYnNwO2V4YW1wbGUmbmJzcDt1c2VzLDwvZGl2Pg0KPGRpdj53aXRoJm5ic3A7Y2xl YXImbmJzcDtzcGVjcyZuYnNwO3dyaXR0ZW4mbmJzcDtmb3ImbmJzcDtlYWNoJm5ic3A7LSZuYnNw O3dlJm5ic3A7Y291bGQmbmJzcDtzdGFydCZuYnNwO3dpdGgmbmJzcDt0aGU8L2Rpdj4NCjxkaXY+ ZXhhbXBsZXMmbmJzcDtpbiZuYnNwO291ciZuYnNwOyhkcmFmdCkmbmJzcDtBcHBsaWNhYmlsaXR5 Jm5ic3A7U3RhdGVtZW50LiZuYnNwOyZuYnNwO1RoYXQmbmJzcDtjb25zaWRlcnM8L2Rpdj4NCjxk aXY+Zml2ZSZuYnNwO2V4YW1wbGVzJm5ic3A7LTwvZGl2Pg0KPGRpdj48L2Rpdj4NCjxkaXY+Jm5i c3A7Jm5ic3A7Jm5ic3A7NC4xLiZuYnNwOyZuYnNwO1VzZSZuYnNwO0Nhc2UmbmJzcDsxOiZuYnNw O1N3aXRjaGVkJm5ic3A7RXRoZXJuZXQmbmJzcDtzZXJ2aWNlcyZuYnNwOyhTRVMpPC9kaXY+DQo8 ZGl2PiZuYnNwOyZuYnNwOyZuYnNwOzQuMi4mbmJzcDsmbmJzcDtVc2UmbmJzcDtDYXNlJm5ic3A7 MjombmJzcDtWaXJ0dWFsaXplZCZuYnNwO1ByaXZhdGUmbmJzcDtDbG91ZHMmbmJzcDsoVlBDKTwv ZGl2Pg0KPGRpdj4mbmJzcDsmbmJzcDsmbmJzcDs0LjMuJm5ic3A7Jm5ic3A7VXNlJm5ic3A7Q2Fz ZSZuYnNwOzM6Jm5ic3A7VHJhZmZpYyZuYnNwO01hbmlwdWxhdGlvbiZuYnNwO2Nyb3NzJm5ic3A7 RENzPC9kaXY+DQo8ZGl2PiZuYnNwOyZuYnNwOyZuYnNwOzQuNC4mbmJzcDsmbmJzcDtVc2UmbmJz cDtDYXNlJm5ic3A7NDombmJzcDtWaXJ0dWFsJm5ic3A7U1A8L2Rpdj4NCjxkaXY+Jm5ic3A7Jm5i c3A7Jm5ic3A7NC41LiZuYnNwOyZuYnNwO1VzZSZuYnNwO0Nhc2UmbmJzcDs1OiZuYnNwO0luc3Rh bnQmbmJzcDtWUE48L2Rpdj4NCjxkaXY+Jm5ic3A7Jm5ic3A7Jm5ic3A7NC42LiZuYnNwOyZuYnNw O1VzZSZuYnNwO0Nhc2UmbmJzcDs2OiZuYnNwO3RyYWZmaWMmbmJzcDtvcHRpbWl6YXRpb24mbmJz cDthbmQmbmJzcDtRb3MmbmJzcDthc3N1cmFuY2UmbmJzcDtvbiZuYnNwO0lTUCZuYnNwO0RDPC9k aXY+DQo8ZGl2PjwvZGl2Pg0KPGRpdj5JdCZuYnNwO3dvdWxkJm5ic3A7aGVscCZuYnNwO1NVUEEm bmJzcDthJm5ic3A7bG90Jm5ic3A7dG8mbmJzcDtoYXZlJm5ic3A7aW5wdXQsJm5ic3A7ZXNwZWNp YWxseSZuYnNwO2Zyb20mbmJzcDtuZXR3b3JrPC9kaXY+DQo8ZGl2Pm9wZXJhdG9ycywmbmJzcDt0 ZWxsaW5nJm5ic3A7dXMmbmJzcDsmcXVvdDt3aGF0Jm5ic3A7ZG8mbmJzcDt5b3UmbmJzcDthY3R1 YWxseSZuYnNwO3dhbnQmbmJzcDsoU1VQQSZuYnNwO3RvKSZuYnNwO2RvPyZxdW90OzwvZGl2Pg0K PGRpdj48L2Rpdj4NCjxkaXY+RG8mbmJzcDtwbGVhc2UmbmJzcDtnaXZlJm5ic3A7dGhpcyZuYnNw O3NvbWUmbmJzcDt0aG91Z2h0LCZuYnNwO2FuZCZuYnNwO3NlbmQmbmJzcDt5b3VyJm5ic3A7J3dp c2hlcycmbmJzcDt0ZXh0Jm5ic3A7dG88L2Rpdj4NCjxkaXY+dGhlJm5ic3A7U1VQQSZuYnNwO2xp c3QhPC9kaXY+DQo8ZGl2PjwvZGl2Pg0KPGRpdj5DaGVlcnMsJm5ic3A7TmV2aWw8L2Rpdj4NCjxk aXY+PC9kaXY+DQo8ZGl2Pi0tJm5ic3A7PC9kaXY+DQo8ZGl2Pi0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTwvZGl2Pg0K PGRpdj4mbmJzcDsmbmJzcDtOZXZpbCZuYnNwO0Jyb3dubGVlJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Q29tcHV0ZXImbmJzcDtT Y2llbmNlJm5ic3A7RGVwYXJ0bWVudCZuYnNwO3wmbmJzcDtJVFM8L2Rpdj4NCjxkaXY+Jm5ic3A7 Jm5ic3A7UGhvbmU6Jm5ic3A7JiM0Mzs2NCZuYnNwOzkmbmJzcDszNzMmbmJzcDs3NTk5Jm5ic3A7 eDg4OTQxJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7VGhlJm5ic3A7VW5pdmVyc2l0eSZuYnNwO29mJm5i c3A7QXVja2xhbmQ8L2Rpdj4NCjxkaXY+Jm5ic3A7Jm5ic3A7RkFYOiZuYnNwOyYjNDM7NjQmbmJz cDs5Jm5ic3A7MzczJm5ic3A7NzQ1MyZuYnNwOyZuYnNwOyZuYnNwO1ByaXZhdGUmbmJzcDtCYWcm bmJzcDs5MjAxOSwmbmJzcDtBdWNrbGFuZCZuYnNwOzExNDIsJm5ic3A7TmV3Jm5ic3A7WmVhbGFu ZDwvZGl2Pg0KPC9mb250PjwvZGl2Pg0KPGJyPg0KPGhyPg0KPGZvbnQgZmFjZT0iQXJpYWwiIGNv bG9yPSJCbHVlIiBzaXplPSIyIj7lpoLmnpzmgqjplJnor6/mjqXmlLbkuobor6Xpgq7ku7bvvIzo r7fpgJrov4fnlLXlrZDpgq7ku7bnq4vljbPpgJrnn6XmiJHku6zjgILor7flm57lpI3pgq7ku7bl iLBocXMtc3BtY0BjaGluYXVuaWNvbS5jbu+8jOWNs+WPr+S7pemAgOiuouatpOmCruS7tuOAguaI keS7rOWwhueri+WNs+WwhuaCqOeahOS/oeaBr+S7juaIkeS7rOeahOWPkemAgeebruW9leS4reWI oOmZpOOAgjxicj4NCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxl YXNlIG5vdGlmeSB1cyBpbW1lZGlhdGVseSBieSBlLW1haWwuIFBsZWFzZSByZXBseSB0byBocXMt c3BtY0BjaGluYXVuaWNvbS5jbiBpZiB5b3Ugd2FudCB0byB1bnN1YnNjcmliZSBmcm9tIHRoaXMg bWFpbC4gV2Ugd2lsbCBpbW1lZGlhdGVseSByZW1vdmUgeW91ciBpbmZvcm1hdGlvbiBmcm9tIG91 ciBzZW5kaW5nIGNhdGFsb2d1ZS48YnI+DQo8L2ZvbnQ+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --=====003_Dragon783067356188_=====-- From nobody Mon Nov 21 07:53:53 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D91F129492 for ; Mon, 21 Nov 2016 07:53:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JS65eSbQ5BD1 for ; Mon, 21 Nov 2016 07:53:51 -0800 (PST) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5989129AD1 for ; Mon, 21 Nov 2016 07:53:51 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 8DF90243321 for ; Mon, 21 Nov 2016 07:53:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1479743631; bh=MVuD1tjAWCxAQHA8YxseKYtHoOvCl0XMSdSO8GQn+Lg=; h=To:From:Subject:Date:From; b=Ge4IY/l9dGOXq7RI2G7L9JxcOw01JHJoX/FqkDRrdno7RCL2M/slanwXonDgQpi8o e7k0GI0vQd9N1qHLT3y5AIynofszAy6EGLEzJf0X95x+HLo+qIr3Vl0S1p4uvpEQ2j ZKg74lN+UX7E/seR7Bp7IG1WlGdwAfgz8tiCXYbo= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 3B0B92405C2 for ; Mon, 21 Nov 2016 07:53:51 -0800 (PST) To: SUPA list From: "Joel M. Halpern" Message-ID: <33a671b9-be0b-3f11-a708-4ab673154ea1@joelhalpern.com> Date: Mon, 21 Nov 2016 10:54:12 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Supa] DM Enumerations X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is to discuss SUPA $Simplified Use of Policy Abstractions$ related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2016 15:53:52 -0000 As discussed in Korea, there is one aspect of the YANG usage in the data model that concerns me. There are a number of enumerations in the model that represent a range of choices (encodings, information location representations, constraint languages, ...). These are current represented as YANG enums. YANG enums can be revised when a document is reved, but can not be extended by an augmentation. So new models, based on this work, can not add new values to the enumerations. If we stick with enumerations, this means that we frequently end up with catch-all "other" entries (or worse, undefined1, undefined2, undefined3). As an alternative, we can switch to identities. For each enumeration, the model can define a base identity (the type as it were), and then a derived identity for each value in the enumeration. Then, new models building on that work can define additional identities on the same base. Does the working group want the authors to make this change? Yours, Joel From nobody Mon Nov 21 09:02:25 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86B89129ACA for ; Mon, 21 Nov 2016 09:02:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.697 X-Spam-Level: X-Spam-Status: No, score=-5.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497] 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 AL2xt9CQwqRU for ; Mon, 21 Nov 2016 09:01:59 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0388129AE2 for ; Mon, 21 Nov 2016 09:01:59 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id D3B5D1006; Mon, 21 Nov 2016 18:01:57 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id fawA9ug00MJA; Mon, 21 Nov 2016 18:01:56 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 21 Nov 2016 18:01:57 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id AC29F20055; Mon, 21 Nov 2016 18:01:57 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id vHFsR9S5d5gE; Mon, 21 Nov 2016 18:01:57 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0F7E620054; Mon, 21 Nov 2016 18:01:57 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 00B283D56C6F; Mon, 21 Nov 2016 18:01:55 +0100 (CET) Date: Mon, 21 Nov 2016 18:01:55 +0100 From: Juergen Schoenwaelder To: "Joel M. Halpern" Message-ID: <20161121170155.GA31314@elstar.local> Mail-Followup-To: "Joel M. Halpern" , SUPA list References: <33a671b9-be0b-3f11-a708-4ab673154ea1@joelhalpern.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <33a671b9-be0b-3f11-a708-4ab673154ea1@joelhalpern.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: SUPA list Subject: Re: [Supa] DM Enumerations X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder 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, 21 Nov 2016 17:02:23 -0000 On the abstract level, it seems that identities are fine. That said, I wonder how you plan to arrive at interoperable implementations if everything is flexible. Are there any mandatory to implement identities? /js On Mon, Nov 21, 2016 at 10:54:12AM -0500, Joel M. Halpern wrote: > As discussed in Korea, there is one aspect of the YANG usage in the data > model that concerns me. > > There are a number of enumerations in the model that represent a range of > choices (encodings, information location representations, constraint > languages, ...). These are current represented as YANG enums. > > YANG enums can be revised when a document is reved, but can not be extended > by an augmentation. So new models, based on this work, can not add new > values to the enumerations. > > If we stick with enumerations, this means that we frequently end up with > catch-all "other" entries (or worse, undefined1, undefined2, undefined3). > > As an alternative, we can switch to identities. For each enumeration, the > model can define a base identity (the type as it were), and then a derived > identity for each value in the enumeration. Then, new models building on > that work can define additional identities on the same base. > > Does the working group want the authors to make this change? > > Yours, > Joel > > _______________________________________________ > Supa mailing list > Supa@ietf.org > https://www.ietf.org/mailman/listinfo/supa -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Nov 21 09:22:05 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4A5B129441 for ; Mon, 21 Nov 2016 09:21:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O9rJxuqjVMkX for ; Mon, 21 Nov 2016 09:21:48 -0800 (PST) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27C6B12956D for ; Mon, 21 Nov 2016 09:21:48 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 1613D24064D for ; Mon, 21 Nov 2016 09:21:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1479748908; bh=m6VPxZj9DtsrX6jsdiz4jjGQscySOExK16lQedbtofA=; h=Subject:To:References:From:Date:In-Reply-To:From; b=HcDTmxO2x9pMzfKl/5cNr08JHa9b9weHiKRWIsQ+jj2bKycWScK8UFbfcETsD8Ao7 nfMLEwcgq4yosDDAvnMpzYQc8S6rmi9CfT+DHbEr7o3ug4Yto5BJtGJ4iKGMy0KV0k 8ugQyTF5d4LVOAUT+WhMKR9pankhPifh8OeW/niA= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id AFE222405C2 for ; Mon, 21 Nov 2016 09:21:47 -0800 (PST) To: SUPA list References: <33a671b9-be0b-3f11-a708-4ab673154ea1@joelhalpern.com> <20161121170155.GA31314@elstar.local> From: "Joel M. Halpern" Message-ID: <8b749cdb-5feb-8412-bcf4-50ec683823f1@joelhalpern.com> Date: Mon, 21 Nov 2016 12:22:09 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <20161121170155.GA31314@elstar.local> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Supa] DM Enumerations X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is to discuss SUPA $Simplified Use of Policy Abstractions$ related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2016 17:21:50 -0000 Sorry Juergen, I am not following your question. There are enumerations in the current model. In terms of model support, all the current models will become base identities. If the quesiton is about what values an implementation will support, it is already the case that different implementations will use different values. Not all policy systems will support OCL for constraints. Not all policy systems will support URLs for external references. It may well be that we should pick some things as mandatory to implement. Most of the enumerations are tied to optional capabilities anyway. Yours, Joel On 11/21/16 12:01 PM, Juergen Schoenwaelder wrote: > On the abstract level, it seems that identities are fine. That said, I > wonder how you plan to arrive at interoperable implementations if > everything is flexible. Are there any mandatory to implement > identities? > > /js > > On Mon, Nov 21, 2016 at 10:54:12AM -0500, Joel M. Halpern wrote: >> As discussed in Korea, there is one aspect of the YANG usage in the data >> model that concerns me. >> >> There are a number of enumerations in the model that represent a range of >> choices (encodings, information location representations, constraint >> languages, ...). These are current represented as YANG enums. >> >> YANG enums can be revised when a document is reved, but can not be extended >> by an augmentation. So new models, based on this work, can not add new >> values to the enumerations. >> >> If we stick with enumerations, this means that we frequently end up with >> catch-all "other" entries (or worse, undefined1, undefined2, undefined3). >> >> As an alternative, we can switch to identities. For each enumeration, the >> model can define a base identity (the type as it were), and then a derived >> identity for each value in the enumeration. Then, new models building on >> that work can define additional identities on the same base. >> >> Does the working group want the authors to make this change? >> >> Yours, >> Joel >> >> _______________________________________________ >> Supa mailing list >> Supa@ietf.org >> https://www.ietf.org/mailman/listinfo/supa > From nobody Mon Nov 21 09:44:05 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F1FE129495 for ; Mon, 21 Nov 2016 09:44:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.697 X-Spam-Level: X-Spam-Status: No, score=-5.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497] 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 IpeR7AvlU1jW for ; Mon, 21 Nov 2016 09:44:02 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 838A212954E for ; Mon, 21 Nov 2016 09:44:02 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 4F46611EC; Mon, 21 Nov 2016 18:44:01 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id aIAGxtOAqBE4; Mon, 21 Nov 2016 18:44:00 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 21 Nov 2016 18:44:01 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 366C620055; Mon, 21 Nov 2016 18:44:01 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id egR0qv4iri6N; Mon, 21 Nov 2016 18:44:00 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3778520054; Mon, 21 Nov 2016 18:44:00 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id DD3793D56EAD; Mon, 21 Nov 2016 18:43:59 +0100 (CET) Date: Mon, 21 Nov 2016 18:43:59 +0100 From: Juergen Schoenwaelder To: "Joel M. Halpern" Message-ID: <20161121174359.GC31314@elstar.local> Mail-Followup-To: "Joel M. Halpern" , SUPA list References: <33a671b9-be0b-3f11-a708-4ab673154ea1@joelhalpern.com> <20161121170155.GA31314@elstar.local> <8b749cdb-5feb-8412-bcf4-50ec683823f1@joelhalpern.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8b749cdb-5feb-8412-bcf4-50ec683823f1@joelhalpern.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: SUPA list Subject: Re: [Supa] DM Enumerations X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder 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, 21 Nov 2016 17:44:04 -0000 On Mon, Nov 21, 2016 at 12:22:09PM -0500, Joel M. Halpern wrote: > Sorry Juergen, I am not following your question. > > There are enumerations in the current model. In terms of model support, all > the current models will become base identities. As I said, on the abstract level, it seems that identities are fine. > If the quesiton is about what values an implementation will support, it is > already the case that different implementations will use different values. > Not all policy systems will support OCL for constraints. Not all policy > systems will support URLs for external references. It may well be that we > should pick some things as mandatory to implement. Most of the enumerations > are tied to optional capabilities anyway. Unless there is a common baseline of mandatory to implement 'features', my expectations that you will end up with interoperable policy systems is small. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Nov 22 19:16:39 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EDFC129484; Tue, 22 Nov 2016 19:16:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.717 X-Spam-Level: X-Spam-Status: No, score=-5.717 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=-1.497, 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 0PAmX1gxu37u; Tue, 22 Nov 2016 19:16:32 -0800 (PST) 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 6F21A129454; Tue, 22 Nov 2016 19:16:31 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DBF22850; Wed, 23 Nov 2016 03:16:28 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 23 Nov 2016 03:16:27 +0000 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0235.001; Wed, 23 Nov 2016 11:16:17 +0800 From: Zhoutianran To: "Liushucheng (Will)" , SUPA list , "jonathan@hansfords.net" Thread-Topic: updating SUPA framework draft Thread-Index: AdJAr3Fyxk8opWsoS6SzfdzA3EV54wEhj4Sw Date: Wed, 23 Nov 2016 03:16:16 +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.111.156.116] Content-Type: multipart/alternative; boundary="_000_BBA82579FD347748BEADC4C445EA0F21A2261054NKGEML515MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.58350A0E.0016, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 27545ac4844b1796579718e562dad8a2 Archived-At: Cc: "draft-ietf-supa-policy-based-management-framework@ietf.org" Subject: Re: [Supa] updating SUPA framework draft X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is to discuss SUPA $Simplified Use of Policy Abstractions$ related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2016 03:16:37 -0000 --_000_BBA82579FD347748BEADC4C445EA0F21A2261054NKGEML515MBXchi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Will and all, As from my previous comments, the figure 2 need to reflect: 1. SUPA data model can "be input to a network management function (within a= controller, an orchestrator, or a network element)" as in the charter. 2. The design time and run time. So I would suggest to modify the figure 2 as follows. SUPA designed YANG da= ta models can be the input for management functions, and automatically gene= rate interfaces and data stores. During the run time, components communicat= e with data instances for management and monitoring. + | SUPA Policy Model | | +----------------------------------+ | | Generic Policy Information Model | | +----------------------------------+ | D D | D +-------------v-------------+ +----------------------+ | D | ECAPolicyRule Information | | OSS/BSS/Orchestrator <--+ | D | Model (EPRIM) | +----------^-----------+ | | D +---------------------------+ C | | +----+D+------------------------+D+---+ C +-----+ D SUPA Policy DM D | +----------v-----------+ | | ----v-----------------------+ D | | EMS/NMS/Controller <--------+ | Generic Policy Data Model | D | +----------^-----------+ | | ----------------------------+ D | C +-----+ D D | C | | | +--------v-----------------v--+ | +----------v-----------+ | | | | ECA PolicyRule Data Model | | | Network Element <--+ | | +-----------------------------+ | +----------------------+ | +-------------------------------------+ | + Best, Tianran From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of Liushucheng (Will) Sent: Thursday, November 17, 2016 4:49 PM To: SUPA list; jonathan@hansfords.net Cc: draft-ietf-supa-policy-based-management-framework@ietf.org Subject: [Supa] updating SUPA framework draft Hi all, After a long off-list discussion, we are doing our final review of -01 vers= ion of Framework draft after comments addressed and figures updated, and w= ill submit -01 version soon. Thanks to many reviewers, especially to Jonath= an Hansford for his very detailed review. I'm writing to summarize these co= mments we received as well as our off-list discussion conclusions to keep t= he group updated. The main technical comments are about the three figures.( Which make sense = as this is a framework draft :)) Figure 2: added C arrow from GPDM and EPDM to controllers, changed the sen= tence explaining D arrow. Some issue still under discussion: 1. whether we should show all the cases = in charter 2. whether we should split the design time and running time in t= his figure. Welcome the group to give opinions. Figure 3: Policies are used to control the management of resources and serv= ices, while data from resources and services are used to select and/or modi= fy policies during runtime. Therefore, Lines (1)&(2) connecting policy to r= esource and policy to service are the same, while Line (3) connecting resou= rce to service is different as it's navigable only from resource to service Also there is one comment requesting to reconstruct the section 2.3, and we= addressed in the upcoming version. There are also a couple of editorial issues were pointed out, especially th= e email from Jonathan helped us a lot in improving written English and remo= ve the misleading sentences. Many thanks! Detailed comments and response are also showed below starts with Will et al= .:" ---start--- From: "Jonathan Hansford" =B7 General o The phrase "the GPIM (or the combination of the GPIM and the E= PRIM)" or its equivalent appears a number of times throughout this document= so clearly it is important but, coming to SUPA cold, I failed to understan= d its importance. If there is a need to constantly repeat this phrase, coul= d it not do with further explanation? Will et al.: This means that policies can be defined using the GPIM directl= y, or using the combination of the GPIM and the EPRIM. If you use only the = GPIM, you get a technology- and vendor-independent information model that y= ou are free to map to the data model of your choice; note that the structur= e of a policy is NOT defined. If you use the GPIM and the EPRIM, you get a = technology- and vendor-independent information model that defines policies = as an event-condition-action (i.e., imperative) rule. =B7 Page 2 o 1. Introduction =A7 "the task of network operations and management applications a= nd deploying new services" - is that one task and, if so, what is it? Shoul= d that read "the task of network operations and management applications and= deploying new services"? Will et al.: should be "the task of network operations and management appli= cations deploying new services", fixed =B7 Page 3 o 1. Introduction =A7 s/indepednent/independent Will et al.: fixed =A7 What is the term "snippet" intended to imply? Should it be de= fined somewhere? Will et al.: A "snippet" is a small piece of information (e.g., part of a s= entence that was cut out). We added this sentence at the term first used pl= ace for readers better understanding. o 2.1 Overview =A7 "The GPIM, as well as the combination of the GPIM and EPRIM,= are converted to generic YANG data modules." Shouldn't that be either The = GPIM, as well as the combination of the GPIM and EPRIM, is converted ..." = or "The GPIM and the combination of the GPIM and EPRIM are converted ..."? Will et al.: Technically, you could have both. So "The GPIM, and/or the com= bination of the GPIM and the EPRIM, is converted...". =B7 Page 4 o 2.1 Overview =A7 For consistency with capitalisation, either e.g. "SUPA Generi= c & ECA Policy YANG Data modules" or "SUPA generic policy YANG data modules= " Will et al.: "SUPA Generic Policy and SUPA ECA Policy YANG data modules", f= ixed =B7 Page 7 o 2.1 Overview =A7 None of the arrows with Ds appear to be double-headed and not= all of the arrows with Cs Will et al.: You're right. The Ds should NOT be double-headed. However, the= Cs can be; depends on context. So we removed the double-headed term for th= e sentence of Ds. =A7 Since lower down we have "ECA Policy Rule Information Data Mo= del (EPRIM):" for consistency should we not also have "Generic Policy Infor= mation Model (GPIM):"? Will et al.: yes, thanks, fixed =A7 "query, and implementation languages, and protocol" (appears = twice) - should that be "query, implementation languages, and protocol"? Will et al.: yes, thanks, fixed =A7 "policy rules for that are" - should that be ""policy rules t= hat are"? Will et al.: yes, thanks, fixed =A7 "dependent of" - should that be "independent of" or "dependen= t on"? Will et al.: yes, thanks, fixed =A7 "policy rules derived from EPRIM, consist" - should that be "= policy rules, derived from EPRIM, that consist"? Will et al.: yes, thanks, fixed =B7 Page 8 o 2.1 Overview =A7 "Relationship among Policy, Service and Resource" (appears tw= ice) - should that be "Relationship between Policy, Service and Resource"? Will et al.: fixed. btw, policy is used to orchestrate and control resource= and service management. However, the reverse is NOT true. Put another way: - Policies are used to control the management of resources and services - Data from resources and services are used to select and/or modify poli= cies during runtime Note that this latter relationship is currently missing from the previous v= ersion, so we merged them into the paragraph below this figure. We also upd= ated the figure based on this point. =A7 Should the caption for Figure 3 end with "models"? Will et al.: Yes, added. Please note that SUPA is trying to be model-driven= . This means that you don't change code directly - you change models, which= then generates the correct code. o 2.2 Operation =A7 "the goals to achieve" - would "the goals to be achieved" be = better? Will et al.: yes, thanks, fixed =B7 Page 9 o 2.3 The GPIM and the EPRIM =A7 The structure of this section feels a little odd. Item (1) ap= pears to repeat a little of what is in the first two paragraphs and I wonde= r whether the section would be better structured if those two paragraphs we= re incorporated into item (1). Will et al.: The first paragraph defines the purpose of the GPIM. The secon= d paragraph says that since we have a common vocabulary, we can relate diff= erent actors that use different representations of policy to each other as = a continuum. Without the common vocabulary, this would be impossible. The third paragraph is confusing and should be deleted. Now, incorporate the gist of what was said in the two points in the first p= aragraph, as follows: The GPIM provides a common vocabulary for representing concepts that are common to expressing different types of policy, but which are independent of language, protocol, repository, and level of abstraction. Hence, the GPIM defines concepts and vocabulary needed by policy management systems independent of the form and content of the policy. The ERPIM is a more specific model that refines the GPIM to specify policy rules in an event-condition-action form =B7 Page 10 o 2.4 Creation of Generic YANG Modules =A7 "the addition of new, as well as editing of existing model el= ements" - should that be "the addition of new, as well as the editing of ex= isting model elements"? Will et al.: yes, thanks, fixed o Pagination fails on the PDF version of this Internet-Draft. Is= this page too long? Will et al.: fixed now. ---cut--- Regards, Will --_000_BBA82579FD347748BEADC4C445EA0F21A2261054NKGEML515MBXchi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Will and all,

As from my previous comments, the figure 2 nee= d to reflect:

1. SUPA data model can “be input to a ne= twork management function (within a controller, an orchestrator, or a netwo= rk element)” as in the charter.

2. The design time and run time.

So I would suggest to modify the figure 2 as f= ollows. SUPA designed YANG data models can be the input for management func= tions, and automatically generate interfaces and data stores. During the run time, components communicate with data instanc= es for management and monitoring.

&nbs= p; &= nbsp; +

&nbs= p; = | SUPA Policy Model

&nbs= p; &= nbsp; |

&nbs= p; &= nbsp; | +--------------= --------------------+

&nbs= p; &= nbsp; | | Generic Policy In= formation Model |

&nbs= p; &= nbsp; | +--------------= --------------------+

&nbs= p; &= nbsp; | &n= bsp; D &nb= sp; D

&nbs= p; &= nbsp; | &n= bsp; D +-------------v-------------+

+----------------------+ &n= bsp; | D | ECAP= olicyRule Information |

| OSS/BSS/Orchestrator <--+ |&nbs= p; D | Model (EPRIM) &= nbsp; |

+----------^-----------+ | = | D +-----------= ----------------+

&nbs= p; C = ; | | +----+D+-------------------= -----+D+---+

&nbs= p; C = ; +-----+ D S= UPA Policy DM D = |

+----------v-----------+ &n= bsp; | | ----v-----------------------+ D &= nbsp; |

| EMS/NMS/Controller <--------&= #43; | Generic Policy Data Model | D |

+----------^-----------+ &n= bsp; | | ----------------------------+ D &= nbsp; |

&nbs= p; C = ; +-----+ &nbs= p; D = ; D = |

&nbs= p; C = ; | | | +--------= v-----------------v--+ |

+----------v-----------+ | = | | | ECA PolicyRule Data Model = | |

| Network Element = ; <--+ | | +----------------= -------------+ |

+----------------------+ &n= bsp; | +-------------------------------------+

&nbs= p; &= nbsp; |

&nbs= p; &= nbsp; +

Best,

Tianran

From: Supa [mailto= :supa-bounces@ietf.org] On Behalf Of Liushucheng (Will)
Sent: Thursday, November 17, 2016 4:49 PM
To: SUPA list; jonathan@hansfords.net
Cc: draft-ietf-supa-policy-based-management-framework@ietf.org
Subject: [Supa] updating SUPA framework draft

Hi all,

The main technical comments are= about the three figures.( Which make sense as this is a framework draft :)= )

Figure 2: added C arrow f= rom GPDM and EPDM to controllers, changed the sentence explaining D arrow.

Also there is one comment reque= sting to reconstruct the section 2.3, and we addressed in the upcoming vers= ion.

There are also a couple of edit= orial issues were pointed out, especially the email from Jonathan helped us= a lot in improving written English and remove the misleading sentences. Ma= ny thanks!

Detailed comments and response = are also showed below starts with Will et al.:"

---start---

&= nbsp; From: "Jonathan Hansford" <jonathan at hansf= ords.net>

&= nbsp; =B7 Gener= al

&= nbsp; =B7 Page = 2

&= nbsp; o 1. Introduction

Will et al.: should be "th= e task of network operations and management applications deploying new serv= ices", fixed

&= nbsp; =B7 Page = 3

&= nbsp; o 1. Introduction

&= nbsp; =A7 s/indepednent/independent

Will et al.: fixed

&= nbsp; =A7 What is the term “snippet” intended= to imply? Should it be defined somewhere?

Will et al.: A "snippet&qu= ot; is a small piece of information (e.g., part of a sentence that was cut = out). We added this sentence at the term first used place for readers bette= r understanding.

&= nbsp; o 2.1 Overview

Will et al.: Technically, you c= ould have both. So "The GPIM, and/or the combination of the GPIM and t= he EPRIM, is converted...".

&= nbsp; =B7 Page = 4

&= nbsp; o 2.1 Overview

&= nbsp; =A7 For consistency with capitalisation, either e.g= . “SUPA Generic & ECA Policy YANG Data modules” or “S= UPA generic policy YANG data modules”

Will et al.: "SUPA Generic= Policy and SUPA ECA Policy YANG data modules", fixed

&= nbsp; =B7 Page = 7

&= nbsp; o 2.1 Overview

&= nbsp; =A7 None of the arrows with Ds appear to be double-= headed and not all of the arrows with Cs

Will et al.: You're right. The = Ds should NOT be double-headed. However, the Cs can be; depends on context.= So we removed the double-headed term for the sentence of Ds.

&= nbsp; =A7 Since lower down we have “ECA Policy Rule= Information Data Model (EPRIM):” for consistency should we not also = have “Generic Policy Information Model (GPIM):”?

Will et al.: yes, thanks, fixed=

&= nbsp; =A7 “query, and implementation languages, and= protocol” (appears twice) – should that be “query, imple= mentation languages, and protocol”?

Will et al.: yes, thanks, fixed=

&= nbsp; =A7 “policy rules for that are” –= should that be “”policy rules that are”?

Will et al.: yes, thanks, fixed=

&= nbsp; =A7 “dependent of” – should that = be “independent of” or “dependent on”?

Will et al.: yes, thanks, fixed=

&= nbsp; =A7 “policy rules derived from EPRIM, consist= ” – should that be “policy rules, derived from EPRIM, tha= t consist”?

Will et al.: yes, thanks, fixed=

&= nbsp; =B7 Page = 8

&= nbsp; o 2.1 Overview

&= nbsp; =A7 “Relationship among Policy, Service and R= esource” (appears twice) – should that be “Relationship b= etween Policy, Service and Resource”?

Will et al.: fixed. btw, policy= is used to orchestrate and control resource and service management. Howeve= r, the reverse is NOT true. Put another way:

- Policies are use= d to control the management of resources and services

- Data from resour= ces and services are used to select and/or modify policies during runtime

Note that this latter relations= hip is currently missing from the previous version, so we merged them into = the paragraph below this figure. We also updated the figure based on this p= oint.

&= nbsp; =A7 Should the caption for Figure 3 end with “= ;models”?

Will et al.: Yes, added. Please= note that SUPA is trying to be model-driven. This means that you don't cha= nge code directly - you change models, which then generates the correct cod= e.

&= nbsp; o 2.2 Operation

&= nbsp; =A7 “the goals to achieve” – woul= d “the goals to be achieved” be better?

Will et al.: yes, thanks, fixed=

&= nbsp; =B7 Page = 9

&= nbsp; o 2.3 The GPIM and the EPRIM

The third paragraph is co= nfusing and should be deleted.

Now, incorporate the gist of wh= at was said in the two points in the first paragraph, as follows:

The GPIM provides = a common vocabulary for representing concepts

that are common to= expressing different types of policy, but which

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

abstraction. Hence= , the GPIM defines concepts and vocabulary

needed by policy m= anagement systems independent of the form

and content of the= policy. The ERPIM is a more specific model

that refines the G= PIM to specify policy rules in an

event-condition-ac= tion form

&= nbsp; =B7 Page = 10

&= nbsp; o 2.4 Creation of Generic YANG Modules

&= nbsp; =A7 “the addition of new, as well as editing = of existing model elements” – should that be “the additio= n of new, as well as the editing of existing model elements”?

Will et al.: yes, thanks, fixed=

&= nbsp; o Pagination fails on the PDF version of this= Internet-Draft. Is this page too long?

Will et al.: fixed now. &n= bsp;

---cut---

Regards,

Will

--_000_BBA82579FD347748BEADC4C445EA0F21A2261054NKGEML515MBXchi_-- From nobody Wed Nov 23 01:28:39 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECE2912967C; Wed, 23 Nov 2016 01:28:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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 BlnlFdQFl3y3; Wed, 23 Nov 2016 01:28:31 -0800 (PST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0102.outbound.protection.outlook.com [104.47.2.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA3AC12967A; Wed, 23 Nov 2016 01:28:30 -0800 (PST) Received: from DB6PR0601MB2167.eurprd06.prod.outlook.com (10.168.57.26) by DB6PR0601MB2165.eurprd06.prod.outlook.com (10.168.57.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.734.8; Wed, 23 Nov 2016 09:28:26 +0000 Received: from DB6PR0601MB2167.eurprd06.prod.outlook.com ([10.168.57.26]) by DB6PR0601MB2167.eurprd06.prod.outlook.com ([10.168.57.26]) with mapi id 15.01.0734.014; Wed, 23 Nov 2016 09:28:26 +0000 From: "Diego R. Lopez" To: Zhoutianran Thread-Topic: [Supa] updating SUPA framework draft Thread-Index: AdJAr3Fyxk8opWsoS6SzfdzA3EV54wEhj4SwAA2NxgA= Date: Wed, 23 Nov 2016 09:28:26 +0000 Message-ID: <21F92D9B-1254-46F0-B464-A8E0D5C24311@telefonica.com> References:

In-Reply-To: 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-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [217.64.251.58] x-microsoft-exchange-diagnostics: 1; DB6PR0601MB2165; 7:6NSByK9UvVkePVdR9aalQV+ra23GZ1lf3SueIhyAye1kTOqPAGM5czWxERSzz8Ev5cThMoRSaDT/tlohZ9EZkKLqR5KSvN3lIauKKc2LMKhlclEc7YoPIFAD7aRu0ggclEBrFkpWlCn+dTIyiECQTWPmXsViCAi9OX60DJyQwXDkfbaJ0ogbPrRmZQqczQBUlUfGVY9W8sHXROKkUzZS2AufEw77ENnmWIIMXV/8L/hqMUOt0JZDkCO+4438SEp2u+yizQ8jZrq+AZ+8IUnVmxoHYI6UPpeLMod/tS0NJ4pFN9vw2A7nAe4gG0nRMkenewA1sNmlxeQkTyxLK+SmEHJ+2qxtmsUROxa6Lyd/uY0= x-ms-office365-filtering-correlation-id: 6a33a339-6823-4a07-66cb-08d41383144f x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:DB6PR0601MB2165; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(40392960112811)(278428928389397)(131327999870524)(50582790962513); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6060326)(6040307)(6045199)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6061324)(6041248); SRVR:DB6PR0601MB2165; BCL:0; PCL:0; RULEID:; SRVR:DB6PR0601MB2165; x-forefront-prvs: 013568035E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(189002)(24454002)(199003)(66654002)(252514010)(53754006)(377454003)(229853002)(606004)(6512003)(33656002)(110136003)(6506003)(36756003)(2950100002)(66066001)(2900100001)(77096005)(4326007)(38730400001)(6916009)(97736004)(122556002)(92566002)(2906002)(81156014)(83716003)(81166006)(82746002)(189998001)(8676002)(68736007)(54356999)(50986999)(31430400001)(76176999)(7736002)(101416001)(8936002)(3660700001)(5660300001)(7906003)(3846002)(7846002)(6116002)(102836003)(15395725005)(3280700002)(106356001)(105586002)(86362001)(104396002)(579004)(559001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6PR0601MB2165; H:DB6PR0601MB2167.eurprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; 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_21F92D9B125446F0B464A8E0D5C24311telefonicacom_" MIME-Version: 1.0 X-OriginatorOrg: telefonica.com X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Nov 2016 09:28:26.7042 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9744600e-3e04-492e-baa1-25ec245c6f10 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0601MB2165 Archived-At: Cc: "draft-ietf-supa-policy-based-management-framework@ietf.org" , "jonathan@hansfords.net" , "Liushucheng $Will$" , SUPA list Subject: Re: [Supa] updating SUPA framework draft X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is to discuss SUPA $Simplified Use of Policy Abstractions$ related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2016 09:28:36 -0000 --_000_21F92D9B125446F0B464A8E0D5C24311telefonicacom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, Just to express my full support to this suggested change. It directly refle= cts how we are using SUPA in our implementation of a smart network manageme= nt engine. Be goode, On 23 Nov 2016, at 04:16 , Zhoutianran > wrote: Hi Will and all, As from my previous comments, the figure 2 need to reflect: 1. SUPA data model can =93be input to a network management function (within= a controller, an orchestrator, or a network element)=94 as in the charter. 2. The design time and run time. So I would suggest to modify the figure 2 as follows. SUPA designed YANG da= ta models can be the input for management functions, and automatically gene= rate interfaces and data stores. During the run time, components communicat= e with data instances for management and monitoring. + | SUPA Policy Model | | +----------------------------------+ | | Generic Policy Information Model | | +----------------------------------+ | D D | D +-------------v-------------+ +----------------------+ | D | ECAPolicyRule Information | | OSS/BSS/Orchestrator <--+ | D | Model (EPRIM) | +----------^-----------+ | | D +---------------------------+ C | | +----+D+------------------------+D+---+ C +-----+ D SUPA Policy DM D | +----------v-----------+ | | ----v-----------------------+ D | | EMS/NMS/Controller <--------+ | Generic Policy Data Model | D | +----------^-----------+ | | ----------------------------+ D | C +-----+ D D | C | | | +--------v-----------------v--+ | +----------v-----------+ | | | | ECA PolicyRule Data Model | | | Network Element <--+ | | +-----------------------------+ | +----------------------+ | +-------------------------------------+ | + Best, Tianran From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of Liushucheng (Will) Sent: Thursday, November 17, 2016 4:49 PM To: SUPA list; jonathan@hansfords.net Cc: draft-ietf-supa-policy-based-management-framework@ietf.org Subject: [Supa] updating SUPA framework draft Hi all, After a long off-list discussion, we are doing our final review of -01 vers= ion of Framework draft after comments addressed and figures updated, and w= ill submit -01 version soon. Thanks to many reviewers, especially to Jonath= an Hansford for his very detailed review. I'm writing to summarize these co= mments we received as well as our off-list discussion conclusions to keep t= he group updated. The main technical comments are about the three figures.( Which make sense = as this is a framework draft :)) Figure 2: added C arrow from GPDM and EPDM to controllers, changed the sen= tence explaining D arrow. Some issue still under discussion: 1. whether we should show all the cases = in charter 2. whether we should split the design time and running time in t= his figure. Welcome the group to give opinions. Figure 3: Policies are used to control the management of resources and serv= ices, while data from resources and services are used to select and/or modi= fy policies during runtime. Therefore, Lines (1)&(2) connecting policy to r= esource and policy to service are the same, while Line (3) connecting resou= rce to service is different as it=92s navigable only from resource to servi= ce Also there is one comment requesting to reconstruct the section 2.3, and we= addressed in the upcoming version. There are also a couple of editorial issues were pointed out, especially th= e email from Jonathan helped us a lot in improving written English and remo= ve the misleading sentences. Many thanks! Detailed comments and response are also showed below starts with Will et al= .:" ---start--- From: "Jonathan Hansford" > =B7 General o The phrase =93the GPIM (or the combination of the GPIM and the= EPRIM)=94 or its equivalent appears a number of times throughout this docu= ment so clearly it is important but, coming to SUPA cold, I failed to under= stand its importance. If there is a need to constantly repeat this phrase, = could it not do with further explanation? Will et al.: This means that policies can be defined using the GPIM directl= y, or using the combination of the GPIM and the EPRIM. If you use only the = GPIM, you get a technology- and vendor-independent information model that y= ou are free to map to the data model of your choice; note that the structur= e of a policy is NOT defined. If you use the GPIM and the EPRIM, you get a = technology- and vendor-independent information model that defines policies = as an event-condition-action (i.e., imperative) rule. =B7 Page 2 o 1. Introduction =A7 =93the task of network operations and management applications= and deploying new services=94 =96 is that one task and, if so, what is it?= Should that read =93the task of network operations and management applicat= ions and deploying new services=94? Will et al.: should be "the task of network operations and management appli= cations deploying new services", fixed =B7 Page 3 o 1. Introduction =A7 s/indepednent/independent Will et al.: fixed =A7 What is the term =93snippet=94 intended to imply? Should it b= e defined somewhere? Will et al.: A "snippet" is a small piece of information (e.g., part of a s= entence that was cut out). We added this sentence at the term first used pl= ace for readers better understanding. o 2.1 Overview =A7 =93The GPIM, as well as the combination of the GPIM and EPRI= M, are converted to generic YANG data modules.=94 Shouldn=92t that be eithe= r The GPIM, as well as the combination of the GPIM and EPRIM, is converted= =85=94 or =93The GPIM and the combination of the GPIM and EPRIM are conve= rted =85=94? Will et al.: Technically, you could have both. So "The GPIM, and/or the com= bination of the GPIM and the EPRIM, is converted...". =B7 Page 4 o 2.1 Overview =A7 For consistency with capitalisation, either e.g. =93SUPA Gene= ric & ECA Policy YANG Data modules=94 or =93SUPA generic policy YANG data m= odules=94 Will et al.: "SUPA Generic Policy and SUPA ECA Policy YANG data modules", f= ixed =B7 Page 7 o 2.1 Overview =A7 None of the arrows with Ds appear to be double-headed and not= all of the arrows with Cs Will et al.: You're right. The Ds should NOT be double-headed. However, the= Cs can be; depends on context. So we removed the double-headed term for th= e sentence of Ds. =A7 Since lower down we have =93ECA Policy Rule Information Data = Model (EPRIM):=94 for consistency should we not also have =93Generic Policy= Information Model (GPIM):=94? Will et al.: yes, thanks, fixed =A7 =93query, and implementation languages, and protocol=94 (appe= ars twice) =96 should that be =93query, implementation languages, and proto= col=94? Will et al.: yes, thanks, fixed =A7 =93policy rules for that are=94 =96 should that be =93=94poli= cy rules that are=94? Will et al.: yes, thanks, fixed =A7 =93dependent of=94 =96 should that be =93independent of=94 or= =93dependent on=94? Will et al.: yes, thanks, fixed =A7 =93policy rules derived from EPRIM, consist=94 =96 should tha= t be =93policy rules, derived from EPRIM, that consist=94? Will et al.: yes, thanks, fixed =B7 Page 8 o 2.1 Overview =A7 =93Relationship among Policy, Service and Resource=94 (appear= s twice) =96 should that be =93Relationship between Policy, Service and Res= ource=94? Will et al.: fixed. btw, policy is used to orchestrate and control resource= and service management. However, the reverse is NOT true. Put another way: - Policies are used to control the management of resources and services - Data from resources and services are used to select and/or modify poli= cies during runtime Note that this latter relationship is currently missing from the previous v= ersion, so we merged them into the paragraph below this figure. We also upd= ated the figure based on this point. =A7 Should the caption for Figure 3 end with =93models=94? Will et al.: Yes, added. Please note that SUPA is trying to be model-driven= . This means that you don't change code directly - you change models, which= then generates the correct code. o 2.2 Operation =A7 =93the goals to achieve=94 =96 would =93the goals to be achie= ved=94 be better? Will et al.: yes, thanks, fixed =B7 Page 9 o 2.3 The GPIM and the EPRIM =A7 The structure of this section feels a little odd. Item (1) ap= pears to repeat a little of what is in the first two paragraphs and I wonde= r whether the section would be better structured if those two paragraphs we= re incorporated into item (1). Will et al.: The first paragraph defines the purpose of the GPIM. The secon= d paragraph says that since we have a common vocabulary, we can relate diff= erent actors that use different representations of policy to each other as = a continuum. Without the common vocabulary, this would be impossible. The third paragraph is confusing and should be deleted. Now, incorporate the gist of what was said in the two points in the first p= aragraph, as follows: The GPIM provides a common vocabulary for representing concepts that are common to expressing different types of policy, but which are independent of language, protocol, repository, and level of abstraction. Hence, the GPIM defines concepts and vocabulary needed by policy management systems independent of the form and content of the policy. The ERPIM is a more specific model that refines the GPIM to specify policy rules in an event-condition-action form =B7 Page 10 o 2.4 Creation of Generic YANG Modules =A7 =93the addition of new, as well as editing of existing model = elements=94 =96 should that be =93the addition of new, as well as the editi= ng of existing model elements=94? Will et al.: yes, thanks, fixed o Pagination fails on the PDF version of this Internet-Draft. Is= this page too long? Will et al.: fixed now. ---cut--- Regards, Will _______________________________________________ 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 ---------------------------------- --_000_21F92D9B125446F0B464A8E0D5C24311telefonicacom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable Hi,

Just to express my full support to this suggested change. I= t directly reflects how we are using SUPA in our implementation of a smart = network management engine.

Be goode,

On 23 Nov 2016, at 04:16 , Zhoutianran <zhoutianran@huawei.com> wrote:<= /div>

Hi Will and all,

As from my previous comments, the figure 2 need to refl= ect:

1. SUPA data model can =93be input to a network managem= ent function (within a controller, an orchestrator, or a network element)= =94 as in the charter.

2. The design time and run time.<= /span>

So I would suggest to modify the figure 2 as follows. S= UPA designed YANG data models can be the input for management functions, an= d automatically generate interfaces and data stores. During the run time, components communicate with data instanc= es for management and monitoring.

         &= nbsp;           &nbs= p;       +
         &= nbsp;            &nb= sp;      | SUPA Policy Model

         &= nbsp;           &nbs= p;       |

         &= nbsp;           &nbs= p;       | +-----------------------= -----------+

         &= nbsp;           &nbs= p;       | | Generic Policy Information= Model |

         &= nbsp;           &nbs= p;       | +-----------------------= -----------+

         &= nbsp;           &nbs= p;       |      = ; D           =       D

         &= nbsp;           &nbs= p;       |      = ; D   +-------------v-------------+=

+----------------------+    = ; |        D   | ECAPolicyRule= Information |

| OSS/BSS/Orchestrator <--+ |  &= nbsp;     D   | Model (EPRIM)  &nbs= p;          |<= /o:p>

+----------^-----------+ | | &= nbsp;      D   +--------------------= -------+

         &= nbsp; C           &n= bsp; | | +----+D+------------------------+= ;D+---+

         &= nbsp; C           &n= bsp; +-----+     D   SUPA Polic= y DM         D    |<= o:p class=3D"">

+----------v-----------+    = ; | | ----v-----------------------+ D    |

| EMS/NMS/Controller <--------+ | Ge= neric Policy Data Model | D    |=

+----------^-----------+    = ; | | ----------------------------+ D    |

         &= nbsp; C           &n= bsp; +-----+        &= nbsp;     D       &n= bsp;         D    |<= o:p class=3D"">

         &= nbsp; C           &n= bsp; | | |     +--------v--------= ---------v--+ |

+----------v-----------+ | | = |     | ECA PolicyRule Data Model | |

| Network Element     <--&= #43; | |     +-------------------------= ----+ |

+----------------------+    = ; | +-------------------------------------+

         &= nbsp;           &nbs= p;       |

         &= nbsp;           &nbs= p;       +

Best,

Tianran

From: Supa [mailto:supa-bounces@ietf.org]&= nbsp;On Behalf Of Liushuchen= g (Will)
Sent: T= hursday, November 17, 2016 4:49 PM
To: SUP= A list; jonathan@hansfords.net
Cc: draft-ietf-= supa-policy-based-management-framework@ietf.org
Subject: [Supa] updating SUPA framework draft

Hi all,

After a long off-list discussion, we are do= ing our final review of -01 version of Framework draft after comments addre= ssed and figures updated, and will submit -01 version soon. Thanks to= many reviewers, especially to Jonathan Hansford for his very detailed review. I'm writing to summarize these comments we r= eceived as well as our off-list discussion conclusions to keep the group up= dated.

The main technical comments are about the t= hree figures.( Which make sense as this is a framework draft :))

Figure 2: added C arrow from GPDM and= EPDM to controllers, changed the sentence explaining D arrow.

Some issue still under discussion: 1. wheth= er we should show all the cases in charter 2. whether we should split the d= esign time and running time in this figure. Welcome the group to give opini= ons.

Figure 3: Policies are used to control the = management of resources and services, while data from resources and service= s are used to select and/or modify policies during runtime. Therefore, Line= s (1)&(2) connecting policy to resource and policy to service are the same, while Line (3) connecting resource to = service is different as it=92s navigable only from resource to service

Also there is one comment requesting to rec= onstruct the section 2.3, and we addressed in the upcoming version.

There are also a couple of editorial issues= were pointed out, especially the email from Jonathan helped us a lot in im= proving written English and remove the misleading sentences. Many thanks!

Detailed comments and response are also sho= wed below starts with Will et al.:"

---start---

       &= nbsp; From: "Jonathan Hansford" <jonathan at hansfords.net&g= t;

       &= nbsp; =B7         General

       &= nbsp; o   The phrase =93the GPIM (or the combination of the GPIM = and the EPRIM)=94 or its equivalent appears a number of times throughout th= is document so clearly it is important but, coming to SUPA cold, I failed t= o understand its importance. If there is a need to constantly repeat this phrase, could it = not do with further explanation?

Will et al.: This means that policies can b= e defined using the GPIM directly, or using the combination of the GPIM and= the EPRIM. If you use only the GPIM, you get a technology- and vendor-inde= pendent information model that you are free to map to the data model of your choice; note that the structure of a= policy is NOT defined. If you use the GPIM and the EPRIM, you get a techno= logy- and vendor-independent information model that defines policies as an = event-condition-action (i.e., imperative) rule.

       &= nbsp; =B7         Page 2

       &= nbsp; o   1. Introduction

       &= nbsp; =A7 =93the task of network operations and management applicatio= ns and deploying new services=94 =96 is that one task and, if so, what is i= t? Should that read =93the task of network operations and management applic= ations and deploying new services=94?

Will et al.: should be "the task of ne= twork operations and management applications deploying new services", = fixed

       &= nbsp; =B7         Page 3

       &= nbsp; o   1. Introduction

       &= nbsp; =A7 s/indepednent/independent
Will et al.: fixed

       &= nbsp; =A7 What is the term =93snippet=94 intended to imply? Should it= be defined somewhere?

Will et al.: A "snippet" is a sma= ll piece of information (e.g., part of a sentence that was cut out). We add= ed this sentence at the term first used place for readers better understand= ing.

       &= nbsp; o   2.1 Overview

       &= nbsp; =A7 =93The GPIM, as well as the combination of the GPIM a= nd EPRIM, are converted to generic YANG data modules.=94 Shouldn=92t that b= e either The GPIM, as well as the combination of the GPIM and EPRIM, = is converted =85=94 or =93The GPIM and the combination of the GPIM and EPRIM are converted =85=94?=

Will et al.: Technically, you could have bo= th. So "The GPIM, and/or the combination of the GPIM and the EPRIM, is= converted...".

       &= nbsp; =B7         Page 4

       &= nbsp; o   2.1 Overview

       &= nbsp; =A7 For consistency with capitalisation, either e.g. =93SUPA Ge= neric & ECA Policy YANG Data modules=94 or =93SUPA generic policy YANG = data modules=94

Will et al.: "SUPA Generic Policy and = SUPA ECA Policy YANG data modules", fixed=

       &= nbsp; =B7         Page 7

       &= nbsp; o   2.1 Overview

       &= nbsp; =A7 None of the arrows with Ds appear to be double-headed and n= ot all of the arrows with Cs

Will et al.: You're right. The Ds should NO= T be double-headed. However, the Cs can be; depends on context. So we remov= ed the double-headed term for the sentence of Ds.

       &= nbsp; =A7 Since lower down we have =93ECA Policy Rule Information Dat= a Model (EPRIM):=94 for consistency should we not also have =93Generic Poli= cy Information Model (GPIM):=94?

Will et al.: yes, thanks, fixed

       &= nbsp; =A7 =93query, and implementation languages, and protocol=94 (ap= pears twice) =96 should that be =93query, implementation languages, and pro= tocol=94?

Will et al.: yes, thanks, fixed

       &= nbsp; =A7 =93policy rules for that are=94 =96 should that be =93=94po= licy rules that are=94?

Will et al.: yes, thanks, fixed

       &= nbsp; =A7 =93dependent of=94 =96 should that be =93independent of=94 = or =93dependent on=94?

Will et al.: yes, thanks, fixed

       &= nbsp; =A7 =93policy rules derived from EPRIM, consist=94 =96 should t= hat be =93policy rules, derived from EPRIM, that consist=94?

Will et al.: yes, thanks, fixed

       &= nbsp; =B7         Page 8

       &= nbsp; o   2.1 Overview

       &= nbsp; =A7 =93Relationship among Policy, Service and Resource=94 (appe= ars twice) =96 should that be =93Relationship between Policy, Service and R= esource=94?

Will et al.: fixed. btw, policy is used to = orchestrate and control resource and service management. However, the rever= se is NOT true. Put another way:

   - Policies are used to control= the management of resources and services
   - Data from resources and serv= ices are used to select and/or modify policies during runtime

Note that this latter relationship is curre= ntly missing from the previous version, so we merged them into the paragrap= h below this figure. We also updated the figure based on this point.

       &= nbsp; =A7 Should the caption for Figure 3 end with =93models=94?

Will et al.: Yes, added. Please note that S= UPA is trying to be model-driven. This means that you don't change code dir= ectly - you change models, which then generates the correct code.

       &= nbsp; o   2.2 Operation

       &= nbsp; =A7 =93the goals to achieve=94 =96 would =93the goals to be ach= ieved=94 be better?

Will et al.: yes, thanks, fixed

       &= nbsp; =B7         Page 9

       &= nbsp; o   2.3 The GPIM and the EPRIM=

       &= nbsp; =A7 The structure of this section feels a little odd. Item (1) = appears to repeat a little of what is in the first two paragraphs and I won= der whether the section would be better structured if those two paragraphs = were incorporated into item (1).

Will et al.: The first paragraph defines th= e purpose of the GPIM. The second paragraph says that since we have a commo= n vocabulary, we can relate different actors that use different representat= ions of policy to each other as a continuum. Without the common vocabulary, this would be impossible.

The third paragraph is confusing and = should be deleted.

Now, incorporate the gist of what was said = in the two points in the first paragraph, as follows:=

   The GPIM provides a common voc= abulary for representing concepts

   that are common to expressing = different types of policy, but which

   are independent of language, p= rotocol, repository, and level of

   abstraction. Hence, the GPIM d= efines concepts and vocabulary

   needed by policy management sy= stems independent of the form

   and content of the policy. The= ERPIM is a more specific model

   that refines the GPIM to speci= fy policy rules in an

   event-condition-action form

       &= nbsp; =B7         Page 10

       &= nbsp; o   2.4 Creation of Generic YANG Modules

       &= nbsp; =A7 =93the addition of new, as well as editing of existing mode= l elements=94 =96 should that be =93the addition of new, as well as the edi= ting of existing model elements=94?

Will et al.: yes, thanks, fixed

       &= nbsp; o   Pagination fails on the PDF version of this Internet-Dr= aft. Is this page too long?

Will et al.: fixed now.   &n= bsp;

---cut---

Regards,

Will

_______________________________________________
Supa mailing list
Supa@ietf.org
https://www.ietf.or= g/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
----------------------------------

--_000_21F92D9B125446F0B464A8E0D5C24311telefonicacom_-- From nobody Wed Nov 23 01:57:21 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 895AE129810; Wed, 23 Nov 2016 01:57:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.718 X-Spam-Level: X-Spam-Status: No, score=-5.718 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=-1.497, 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 2C_tVkS8OfHa; Wed, 23 Nov 2016 01:57:18 -0800 (PST) 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 DF8B01297E9; Wed, 23 Nov 2016 01:57:12 -0800 (PST) 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 CVU69900; Wed, 23 Nov 2016 09:56:56 +0000 (GMT) Received: from LHREML502-MBS.china.huawei.com ([10.125.30.101]) by lhreml706-cah.china.huawei.com ([10.201.5.182]) with mapi id 14.03.0235.001; Wed, 23 Nov 2016 09:56:13 +0000 From: Georgios Karagiannis To: "Joel M. Halpern" , "Bert Wijnen (IETF)" , Nevil Brownlee , "draft-cheng-supa-applicability@ietf.org" Thread-Topic: [Supa] We need some good examples of what SUPA can do ! Thread-Index: AQHSQLWGy4CQjJs4RE6wpi1WTasz0aDd9J6AgAAEpICACGSFIA== Date: Wed, 23 Nov 2016 09:56:12 +0000 Message-ID: References:

From: "Bert Wijnen (IETF)" Message-ID: Date: Wed, 23 Nov 2016 11:54:56 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: SUPA list Subject: Re: [Supa] We need some good examples of what SUPA can do ! X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is to discuss SUPA $Simplified Use of Policy Abstractions$ related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2016 10:55:07 -0000 On 23/11/2016 10:56, Georgios Karagiannis wrote: > Hi Bert, > > Thanks for your input. > Please note that I agree with Joel that the input is useful. > Can you please provide more details on what will be the Event Condition Action? well, is that not my exact question? I am asking what ECA policies need to be setup/defined in order to achieve/effectuate a policy that ensures that SNMP is blocked on ports at the edge of the administrative domain to prevent SNMP going out or coming in from outside the enterprise. Bert > Best regards, > Georgios > > > -----Original Message----- > From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of Joel M. Halpern > Sent: Friday, November 18, 2016 2:45 AM > To: Bert Wijnen (IETF); Nevil Brownlee; draft-cheng-supa-applicability@ietf.org > Cc: SUPA list > Subject: Re: [Supa] We need some good examples of what SUPA can do ! > > Thank you Bert. That is exactly the kind of request I am looking for. > > No, I do not think it will be simple to answer your question. But I do think that showing how to do so will show both what we have and what more we need. > > Yours, > Joel > > On 11/17/16 8:28 PM, Bert Wijnen (IETF) wrote: >> Could the proponets of the current (in my view still complex) IM and >> DM work out how one would define/configure/populate the policies for: >> >> ensure that SNMP is blocked on ports at the edge >> of the administrative domain to prevent SNMP going >> out or coming in from outside the enterprise. >> >> This should be simple, no? >> >> Thanks, Bert >> >> On 17/11/2016 18:31, Nevil Brownlee wrote: >>> Hi all: >>> >>> Your SUPA chairs met this morning with some of the SUPA I-D authors >>> to consider "how can we get people working on some simple examples to >>> demonstrate how SUPA could be used." >>> >>> One idea we considered was "we need a few good example uses, with >>> clear specs written for each - we could start with the examples in >>> our (draft) Applicability Statement. That considers five examples - >>> >>> 4.1. Use Case 1: Switched Ethernet services (SES) >>> 4.2. Use Case 2: Virtualized Private Clouds (VPC) >>> 4.3. Use Case 3: Traffic Manipulation cross DCs >>> 4.4. Use Case 4: Virtual SP >>> 4.5. Use Case 5: Instant VPN >>> 4.6. Use Case 6: traffic optimization and Qos assurance on ISP DC >>> >>> It would help SUPA a lot to have input, especially from network >>> operators, telling us "what do you actually want (SUPA to) do?" >>> >>> Do please give this some thought, and send your 'wishes' text to the >>> SUPA list! >>> >>> Cheers, Nevil >>> >> _______________________________________________ >> Supa mailing list >> Supa@ietf.org >> https://www.ietf.org/mailman/listinfo/supa >> > _______________________________________________ > Supa mailing list > Supa@ietf.org > https://www.ietf.org/mailman/listinfo/supa > From nobody Wed Nov 23 02:59:04 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E70EE129C7C; Wed, 23 Nov 2016 02:59:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.718 X-Spam-Level: X-Spam-Status: No, score=-5.718 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=-1.497, 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 IIJzb98so2OO; Wed, 23 Nov 2016 02:59:00 -0800 (PST) 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 461FF129C65; Wed, 23 Nov 2016 02:58:41 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DBF89562; Wed, 23 Nov 2016 10:58:24 +0000 (GMT) Received: from LHREML502-MBS.china.huawei.com ([10.125.30.101]) by lhreml704-cah.china.huawei.com ([10.201.5.130]) with mapi id 14.03.0235.001; Wed, 23 Nov 2016 10:58:20 +0000 From: Georgios Karagiannis To: "Bert Wijnen (IETF)" , "Joel M. Halpern" , Nevil Brownlee , "draft-cheng-supa-applicability@ietf.org" Thread-Topic: [Supa] We need some good examples of what SUPA can do ! Thread-Index: AQHSQLWGy4CQjJs4RE6wpi1WTasz0aDd9J6AgAAEpICACGSFIIAAENsAgAAAqEA= Date: Wed, 23 Nov 2016 10:58:20 +0000 Message-ID: References:

In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.221.38.52] 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.0A020206.58357652.011A, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: f4982320c6e83e1795f351178955eb14 Archived-At: Cc: SUPA list Subject: Re: [Supa] We need some good examples of what SUPA can do ! X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is to discuss SUPA $Simplified Use of Policy Abstractions$ related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2016 10:59:03 -0000 Hi Bert, Okay, I see your point. Best regards, Georgios -----Original Message----- From: Bert Wijnen (IETF) [mailto:bwietf@bwijnen.net]=20 Sent: Wednesday, November 23, 2016 11:55 AM To: Georgios Karagiannis; Joel M. Halpern; Nevil Brownlee; draft-cheng-supa= -applicability@ietf.org Cc: SUPA list Subject: Re: [Supa] We need some good examples of what SUPA can do ! On 23/11/2016 10:56, Georgios Karagiannis wrote: > Hi Bert, > > Thanks for your input. > Please note that I agree with Joel that the input is useful. > Can you please provide more details on what will be the Event Condition A= ction? well, is that not my exact question? I am asking what ECA policies need to be setup/defined in order to achieve/= effectuate a policy that ensures that SNMP is blocked on ports at the edge of the administrative domain to prevent SNMP going out or coming in from outside the enterprise. Bert > Best regards, > Georgios > > > -----Original Message----- > From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of Joel M. Halpern > Sent: Friday, November 18, 2016 2:45 AM > To: Bert Wijnen (IETF); Nevil Brownlee;=20 > draft-cheng-supa-applicability@ietf.org > Cc: SUPA list > Subject: Re: [Supa] We need some good examples of what SUPA can do ! > > Thank you Bert. That is exactly the kind of request I am looking for. > > No, I do not think it will be simple to answer your question. But I do t= hink that showing how to do so will show both what we have and what more we= need. > > Yours, > Joel > > On 11/17/16 8:28 PM, Bert Wijnen (IETF) wrote: >> Could the proponets of the current (in my view still complex) IM and=20 >> DM work out how one would define/configure/populate the policies for: >> >> ensure that SNMP is blocked on ports at the edge >> of the administrative domain to prevent SNMP going >> out or coming in from outside the enterprise. >> >> This should be simple, no? >> >> Thanks, Bert >> >> On 17/11/2016 18:31, Nevil Brownlee wrote: >>> Hi all: >>> >>> Your SUPA chairs met this morning with some of the SUPA I-D authors=20 >>> to consider "how can we get people working on some simple examples=20 >>> to demonstrate how SUPA could be used." >>> >>> One idea we considered was "we need a few good example uses, with=20 >>> clear specs written for each - we could start with the examples in=20 >>> our (draft) Applicability Statement. That considers five examples - >>> >>> 4.1. Use Case 1: Switched Ethernet services (SES) >>> 4.2. Use Case 2: Virtualized Private Clouds (VPC) >>> 4.3. Use Case 3: Traffic Manipulation cross DCs >>> 4.4. Use Case 4: Virtual SP >>> 4.5. Use Case 5: Instant VPN >>> 4.6. Use Case 6: traffic optimization and Qos assurance on ISP=20 >>> DC >>> >>> It would help SUPA a lot to have input, especially from network=20 >>> operators, telling us "what do you actually want (SUPA to) do?" >>> >>> Do please give this some thought, and send your 'wishes' text to the=20 >>> SUPA list! >>> >>> Cheers, Nevil >>> >> _______________________________________________ >> Supa mailing list >> Supa@ietf.org >> https://www.ietf.org/mailman/listinfo/supa >> > _______________________________________________ > Supa mailing list > Supa@ietf.org > https://www.ietf.org/mailman/listinfo/supa > From nobody Wed Nov 23 03:27:47 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E17B5129981; Wed, 23 Nov 2016 03:27:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.717 X-Spam-Level: X-Spam-Status: No, score=-5.717 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=-1.497, 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 kRYfxkkpf6sv; Wed, 23 Nov 2016 03:27:42 -0800 (PST) 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 5179B129963; Wed, 23 Nov 2016 03:27:41 -0800 (PST) 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 DBF94821; Wed, 23 Nov 2016 11:27:31 +0000 (GMT) Received: from LHREML502-MBS.china.huawei.com ([10.125.30.101]) by lhreml701-cah.china.huawei.com ([10.201.5.93]) with mapi id 14.03.0235.001; Wed, 23 Nov 2016 11:27:21 +0000 From: Georgios Karagiannis To: Ying Cheng , SUPA list Thread-Topic: [Supa] We need some good examples of what SUPA can do ! Thread-Index: AQHSRXyOZg4gE1B5qECKLIt6ek5i3Q== Date: Wed, 23 Nov 2016 11:27:21 +0000 Message-ID: References: <201611181043173697826@chinaunicom.cn> In-Reply-To: <201611181043173697826@chinaunicom.cn> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.221.38.52] Content-Type: multipart/alternative; boundary="_000_C5034E44CD620A44971BAAEB372655DC2DC4C378lhreml502mbs_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A010202.58357D27.00AA, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: f4982320c6e83e1795f351178955eb14 Archived-At: Cc: "draft-cheng-supa-applicability@ietf.org" Subject: Re: [Supa] We need some good examples of what SUPA can do ! X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is to discuss SUPA $Simplified Use of Policy Abstractions$ related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2016 11:27:46 -0000 --_000_C5034E44CD620A44971BAAEB372655DC2DC4C378lhreml502mbs_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBZaW5nLCBEZWFyIGFsbCwNCg0KWWluZywgdGhhbmsgeW91IHZlcnkgbXVjaCBmb3IgeW91 ciByZWNvbW1lbmRhdGlvbiBvbiBwcmlvcml0aXppbmcgdGhlIFZQQyAodXNlIGNhc2UgMikgYW5k IGluc3RhbnQgVlBOICh1c2UgY2FzZSA1KSwgZnJvbSB0aGUgc2l4IHVzZSBjYXNlcyBwcmVzZW50 ZWQgaW46DQpodHRwczovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85Ny9zbGlkZXMvc2xpZGVz LTk3LXN1cGEtNDEtZXhhbXBsZXMtYmFzZWQtb24tZHJhZnQtY2hlbmctc3VwYS1hcHBsaWNhYmls aXR5LTAwLTAwLnBwdHgNCg0KVGhlc2UgIHNpeCB1c2UgY2FzZXMgYXJlIGRlc2NyaWJlZCBpbiBt b3JlIGRldGFpbCBpbjoNCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtY2hlbmctc3Vw YS1hcHBsaWNhYmlsaXR5LTAwLnR4dA0KDQoNCkFMTDogQ2FuIHlvdSBwbGVhc2UgbG9vayBpbnRv IHRoZXNlIHNpeCBleGFtcGxlcy91c2UgY2FzZXMgYW5kIGFsc28gaWRlbnRpZnkgYnkgdXNpbmcg YSBwcmlvcml0eSBsaXN0ICh0b3AgaGFzIGhpZ2hlc3QgcHJpb3JpdHkpIHdoaWNoIG9mIHRoZXNl IHVzZSBjYXNlcyB5b3Ugd291bGQgbGlrZSB0byBzZWUgd29ya2VkIG91dCBhcyBTVVBBIFlBTkcg ZGF0YSBtb2RlbHMuDQoNCkJlc3QgcmVnYXJkcywNCkdlb3JnaW9zDQoNCg0KDQpGcm9tOiBTdXBh IFttYWlsdG86c3VwYS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgWWluZyBDaGVuZw0K U2VudDogRnJpZGF5LCBOb3ZlbWJlciAxOCwgMjAxNiAzOjQzIEFNDQpUbzogTmV2aWwgQnJvd25s ZWU7IGQua2luZw0KQ2M6IGRyYWZ0LWNoZW5nLXN1cGEtYXBwbGljYWJpbGl0eUBpZXRmLm9yZzsg U1VQQSBsaXN0DQpTdWJqZWN0OiBSZTogW1N1cGFdIFdlIG5lZWQgc29tZSBnb29kIGV4YW1wbGVz IG9mIHdoYXQgU1VQQSBjYW4gZG8gIQ0KDQpEZWFyIE5ldmlsLCBEYW4sIGV0IGFsLA0KDQpJIHN1 cHBvcnQgdGhpcyBwcm9wb3NhbCB3aGljaCBtYXkgbWFrZSBvdXIgd29yayBtb3JlIGNvbnZlcmdl bnQgYW5kIGVmZmljaWVudC4gV2UgZGlzY3VzcyB0aGUgdXNlIGNhc2Ugc2V0IGZvciBhIGxvbmcg dGltZSBzaW5jZSB0aGUgY3JlYXRpb24gb2YgU1VQQSBjb25jZXB0IGFuZCBJIGFtIHZlcnkgZ2xh ZCB0byBzZWUgdGhhdCB0aGUgU1VQQSBJTSBhbmQgRE0gYXJlIG5lYXJseSBtYXR1cmUgdG8gYmUg dXNlZCBpbiB0aGUgdXNlIGNhc2UgZGVzY3JpcHRpb24uDQoNClJlZ2FyZGluZyB0aGUgY3VycmVu dCB1c2UgY2FzZXMgaW4gYXBwbGljYWJpbGl0eSBkcmFmdCwgSSBwcm9wb3NlIHRvIHN0YXJ0IHdp dGggVlBDICh1c2UgY2FzZSAyKSBhbmQgaW5zdGFudCBWUE4gKHVzZSBjYXNlIDUpICwgd2hvc2Ug c2ltaWxhciBpbXBsZW1lbnRhdGlvbiBjYW4gYmUgZm91bmQgaW4gQ2hpbmEgVW5pY29tIGFuZCB3 aGVyZSBTVVBBIERNIGFuZCBJTSBjYW4gaGVscCB0byBlbmFibGUgdGhlIHNjYWxhYmxlIGFuZCBj b25zaXN0ZW50IHByb2dyYW1tYXRpYyBjb250cm9sLg0KDQpUaGFua3MgYW5kIGJlc3QgcmVnYXJk cywNCllpbmcNCg0KMjAxNi0xMS0xOA0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CllpbmcgQ0hFTkcgIOeoi+iOuQ0KVGVjaG5vbG9neSBEZXBhcnRtZW50LCBDaGluYSBVbmljb20g 5Lit5Zu96IGU6YCa6ZuG5Zui5oqA5pyv6YOoDQpUZWw6ICs4Ni0xMC02NjI1OTM5NA0KTW9iaWxl OiArODYtMTg2MDExMDI5NzENCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQrlj5Hk u7bkurrvvJogTmV2aWwgQnJvd25sZWUNCuWPkemAgeaXtumXtO+8miAyMDE2LTExLTE3ICAxNzoz MjoxMw0K5pS25Lu25Lq677yaIGRyYWZ0LWNoZW5nLXN1cGEtYXBwbGljYWJpbGl0eUBpZXRmLm9y ZzxtYWlsdG86ZHJhZnQtY2hlbmctc3VwYS1hcHBsaWNhYmlsaXR5QGlldGYub3JnPg0K5oqE6YCB 77yaIFNVUEEgbGlzdA0K5Li76aKY77yaIFdlIG5lZWQgc29tZSBnb29kIGV4YW1wbGVzIG9mIHdo YXQgU1VQQSBjYW4gZG8gIQ0KSGkgYWxsOg0KWW91ciBTVVBBIGNoYWlycyBtZXQgdGhpcyBtb3Ju aW5nIHdpdGggc29tZSBvZiB0aGUgU1VQQSBJLUQNCmF1dGhvcnMgdG8gY29uc2lkZXIgImhvdyBj YW4gd2UgZ2V0IHBlb3BsZSB3b3JraW5nIG9uIHNvbWUNCnNpbXBsZSBleGFtcGxlcyB0byBkZW1v bnN0cmF0ZSBob3cgU1VQQSBjb3VsZCBiZSB1c2VkLiINCk9uZSBpZGVhIHdlIGNvbnNpZGVyZWQg d2FzICJ3ZSBuZWVkIGEgZmV3IGdvb2QgZXhhbXBsZSB1c2VzLA0Kd2l0aCBjbGVhciBzcGVjcyB3 cml0dGVuIGZvciBlYWNoIC0gd2UgY291bGQgc3RhcnQgd2l0aCB0aGUNCmV4YW1wbGVzIGluIG91 ciAoZHJhZnQpIEFwcGxpY2FiaWxpdHkgU3RhdGVtZW50LiAgVGhhdCBjb25zaWRlcnMNCmZpdmUg ZXhhbXBsZXMgLQ0KICAgNC4xLiAgVXNlIENhc2UgMTogU3dpdGNoZWQgRXRoZXJuZXQgc2Vydmlj ZXMgKFNFUykNCiAgIDQuMi4gIFVzZSBDYXNlIDI6IFZpcnR1YWxpemVkIFByaXZhdGUgQ2xvdWRz IChWUEMpDQogICA0LjMuICBVc2UgQ2FzZSAzOiBUcmFmZmljIE1hbmlwdWxhdGlvbiBjcm9zcyBE Q3MNCiAgIDQuNC4gIFVzZSBDYXNlIDQ6IFZpcnR1YWwgU1ANCiAgIDQuNS4gIFVzZSBDYXNlIDU6 IEluc3RhbnQgVlBODQogICA0LjYuICBVc2UgQ2FzZSA2OiB0cmFmZmljIG9wdGltaXphdGlvbiBh bmQgUW9zIGFzc3VyYW5jZSBvbiBJU1AgREMNCkl0IHdvdWxkIGhlbHAgU1VQQSBhIGxvdCB0byBo YXZlIGlucHV0LCBlc3BlY2lhbGx5IGZyb20gbmV0d29yaw0Kb3BlcmF0b3JzLCB0ZWxsaW5nIHVz ICJ3aGF0IGRvIHlvdSBhY3R1YWxseSB3YW50IChTVVBBIHRvKSBkbz8iDQpEbyBwbGVhc2UgZ2l2 ZSB0aGlzIHNvbWUgdGhvdWdodCwgYW5kIHNlbmQgeW91ciAnd2lzaGVzJyB0ZXh0IHRvDQp0aGUg U1VQQSBsaXN0IQ0KQ2hlZXJzLCBOZXZpbA0KLS0NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICBOZXZpbCBCcm93 bmxlZSAgICAgICAgICAgICAgICAgICAgQ29tcHV0ZXIgU2NpZW5jZSBEZXBhcnRtZW50IHwgSVRT DQogIFBob25lOiArNjQgOSAzNzMgNzU5OSB4ODg5NDEgICAgICAgICAgICAgVGhlIFVuaXZlcnNp dHkgb2YgQXVja2xhbmQNCiAgRkFYOiArNjQgOSAzNzMgNzQ1MyAgIFByaXZhdGUgQmFnIDkyMDE5 LCBBdWNrbGFuZCAxMTQyLCBOZXcgWmVhbGFuZA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0K5aaC5p6c5oKo6ZSZ6K+v5o6l5pS25LqG6K+l6YKu5Lu277yM6K+36YCa6L+H55S1 5a2Q6YKu5Lu256uL5Y2z6YCa55+l5oiR5Lus44CC6K+35Zue5aSN6YKu5Lu25YiwaHFzLXNwbWNA Y2hpbmF1bmljb20uY27vvIzljbPlj6/ku6XpgIDorqLmraTpgq7ku7bjgILmiJHku6zlsIbnq4vl jbPlsIbmgqjnmoTkv6Hmga/ku47miJHku6znmoTlj5HpgIHnm67lvZXkuK3liKDpmaTjgIINCklm IHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB1cyBp bW1lZGlhdGVseSBieSBlLW1haWwuIFBsZWFzZSByZXBseSB0byBocXMtc3BtY0BjaGluYXVuaWNv bS5jbjxtYWlsdG86aHFzLXNwbWNAY2hpbmF1bmljb20uY24+IGlmIHlvdSB3YW50IHRvIHVuc3Vi c2NyaWJlIGZyb20gdGhpcyBtYWlsLiBXZSB3aWxsIGltbWVkaWF0ZWx5IHJlbW92ZSB5b3VyIGlu Zm9ybWF0aW9uIGZyb20gb3VyIHNlbmRpbmcgY2F0YWxvZ3VlLg0K --_000_C5034E44CD620A44971BAAEB372655DC2DC4C378lhreml502mbs_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJNUyBHb3RoaWMiOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDcgMiA1IDgg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6TWluZ0xpVTsNCglwYW5vc2UtMToyIDIg NSA5IDAgMCAwIDAgMCAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEBNaW5nTGlVIjsNCglwYW5vc2UtMToy IDIgNSA5IDAgMCAwIDAgMCAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxATVMgR290 aGljIjsNCglwYW5vc2UtMToyIDExIDYgOSA3IDIgNSA4IDIgNDt9DQpAZm9udC1mYWNlDQoJe2Zv bnQtZmFtaWx5OlZlcmRhbmE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyog U3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29O b3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJdGV4dC1hbGln bjpqdXN0aWZ5Ow0KCWZvbnQtc2l6ZToxMC41cHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBS b21hbiIsInNlcmlmIjsNCgltc28tYmVsaWV2ZS1ub3JtYWwtbGVmdDp5ZXM7fQ0KYTpsaW5rLCBz cGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsN Cgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxp bmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRl eHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IlZlcmRhbmEiLCJzYW5zLXNlcmlmIjsNCglj b2xvcjp3aW5kb3d0ZXh0Ow0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0eWxlOm5vcm1h bDsNCgl0ZXh0LWRlY29yYXRpb246bm9uZSBub25lO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUt dHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwh W2lmIG1zbyA5XT48c3R5bGU+cC5Nc29Ob3JtYWwNCgl7bWFyZ2luLWxlZnQ6Ny41cHQ7fQ0KPC9z dHlsZT48IVtlbmRpZl0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIiBzdHlsZT0ibWFyZ2luLWxlZnQ6Ny41cHQ7bWFyZ2luLXRvcDo3LjVwdDttYXJnaW4tcmln aHQ6Ny41cHQ7bWFyZ2luLWJvdHRvbTo3LjVwdCI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPkRlYXIgWWluZywgRGVhciBhbGwsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5ZaW5nLCB0aGFuayB5b3Ug dmVyeSBtdWNoIGZvciB5b3VyIHJlY29tbWVuZGF0aW9uIG9uIHByaW9yaXRpemluZyB0aGUNCjwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJk YW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6bmF2eSI+VlBDICh1c2UgY2Fz ZSAyKSBhbmQgaW5zdGFudCBWUE4gKHVzZSBjYXNlIDUpLCBmcm9tIHRoZSBzaXggdXNlIGNhc2Vz IHByZXNlbnRlZCBpbjo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6bmF2eSI+PGEgaHJlZj0iaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTcvc2xpZGVzL3NsaWRlcy05Ny1zdXBhLTQxLWV4 YW1wbGVzLWJhc2VkLW9uLWRyYWZ0LWNoZW5nLXN1cGEtYXBwbGljYWJpbGl0eS0wMC0wMC5wcHR4 Ij5odHRwczovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85Ny9zbGlkZXMvc2xpZGVzLTk3LXN1 cGEtNDEtZXhhbXBsZXMtYmFzZWQtb24tZHJhZnQtY2hlbmctc3VwYS1hcHBsaWNhYmlsaXR5LTAw LTAwLnBwdHg8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOm5hdnkiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjpuYXZ5Ij5UaGVzZSZuYnNwOyBzaXggdXNlIGNhc2VzIGFyZSBkZXNjcmliZWQg aW4gbW9yZSBkZXRhaWwgaW46PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVy ZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOm5hdnkiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjpuYXZ5Ij48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9pZC9k cmFmdC1jaGVuZy1zdXBhLWFwcGxpY2FiaWxpdHktMDAudHh0Ij5odHRwczovL3d3dy5pZXRmLm9y Zy9pZC9kcmFmdC1jaGVuZy1zdXBhLWFwcGxpY2FiaWxpdHktMDAudHh0PC9hPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjpuYXZ5Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6bmF2eSI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOm5hdnkiPkFMTDogQ2FuIHlvdSBwbGVhc2UgbG9vayBpbnRv IHRoZXNlIHNpeCBleGFtcGxlcy91c2UgY2FzZXMgYW5kIGFsc28gaWRlbnRpZnkgYnkgdXNpbmcg YSBwcmlvcml0eSBsaXN0ICh0b3AgaGFzIGhpZ2hlc3QgcHJpb3JpdHkpIHdoaWNoIG9mIHRoZXNl IHVzZSBjYXNlcyB5b3Ugd291bGQNCiBsaWtlIHRvIHNlZSB3b3JrZWQgb3V0IGFzIFNVUEEgWUFO RyBkYXRhIG1vZGVscy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6bmF2eSI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOm5hdnkiPkJlc3QgcmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6bmF2 eSI+R2Vvcmdpb3M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6bmF2eSI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOm5hdnkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiIHN0eWxlPSJ0ZXh0LWFsaWduOmxl ZnQiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPiBTdXBhIFttYWlsdG86c3VwYS1ib3VuY2VzQGlldGYub3Jn XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5ZaW5nIENoZW5nPGJyPg0KPGI+U2VudDo8L2I+IEZyaWRh eSwgTm92ZW1iZXIgMTgsIDIwMTYgMzo0MyBBTTxicj4NCjxiPlRvOjwvYj4gTmV2aWwgQnJvd25s ZWU7IGQua2luZzxicj4NCjxiPkNjOjwvYj4gZHJhZnQtY2hlbmctc3VwYS1hcHBsaWNhYmlsaXR5 QGlldGYub3JnOyBTVVBBIGxpc3Q8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtTdXBhXSBXZSBu ZWVkIHNvbWUgZ29vZCBleGFtcGxlcyBvZiB3aGF0IFNVUEEgY2FuIGRvICE8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249Imxl ZnQiIHN0eWxlPSJ0ZXh0LWFsaWduOmxlZnQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0IiBzdHlsZT0idGV4dC1hbGlnbjpsZWZ0 Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6bmF2eSI+RGVhciBOZXZpbCwgRGFu LCBldCBhbCw8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVm dCIgc3R5bGU9InRleHQtYWxpZ246bGVmdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBhbGlnbj0ibGVmdCIgc3R5bGU9InRleHQtYWxpZ246bGVmdCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOm5hdnkiPkkgc3VwcG9ydCB0aGlzIHByb3Bvc2FsIHdoaWNo IG1heSBtYWtlJm5ic3A7b3VyIHdvcmsgbW9yZSBjb252ZXJnZW50IGFuZCBlZmZpY2llbnQuIFdl IGRpc2N1c3MgdGhlIHVzZSBjYXNlIHNldCBmb3IgYSBsb25nIHRpbWUNCiBzaW5jZSB0aGUgY3Jl YXRpb24gb2YgU1VQQSZuYnNwO2NvbmNlcHQgYW5kIEkgYW0gdmVyeSBnbGFkIHRvIHNlZSB0aGF0 IHRoZSBTVVBBIElNIGFuZCBETSBhcmUgbmVhcmx5IG1hdHVyZSB0byBiZSB1c2VkIGluIHRoZSB1 c2UgY2FzZSBkZXNjcmlwdGlvbi48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBhbGlnbj0ibGVmdCIgc3R5bGU9InRleHQtYWxpZ246bGVmdCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCIgc3R5bGU9InRleHQtYWxpZ246bGVmdCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOm5hdnkiPlJlZ2FyZGluZyB0aGUgY3Vy cmVudCB1c2UgY2FzZXMgaW4gYXBwbGljYWJpbGl0eSBkcmFmdCwgSSBwcm9wb3NlIHRvIHN0YXJ0 IHdpdGggVlBDICh1c2UgY2FzZSAyKSBhbmQgaW5zdGFudCBWUE4gKHVzZSBjYXNlDQogNSkgLCB3 aG9zZSBzaW1pbGFyIGltcGxlbWVudGF0aW9uIGNhbiBiZSBmb3VuZCBpbiBDaGluYSBVbmljb20g YW5kIHdoZXJlIFNVUEEgRE0gYW5kIElNIGNhbiBoZWxwIHRvIGVuYWJsZSB0aGUgc2NhbGFibGUg YW5kIGNvbnNpc3RlbnQgcHJvZ3JhbW1hdGljIGNvbnRyb2wuJm5ic3A7PC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiIHN0eWxlPSJ0ZXh0LWFsaWduOmxl ZnQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRh bmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiIHN0 eWxlPSJ0ZXh0LWFsaWduOmxlZnQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpu YXZ5Ij5UaGFua3MgYW5kIGJlc3QgcmVnYXJkcyw8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBhbGlnbj0ibGVmdCIgc3R5bGU9InRleHQtYWxpZ246bGVmdCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOm5hdnkiPllpbmc8L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCIgc3R5bGU9InRleHQtYWxpZ246bGVmdCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCIgc3R5bGU9InRl eHQtYWxpZ246bGVmdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOnNpbHZlciI+ MjAxNi0xMS0xOA0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0 IiBzdHlsZT0idGV4dC1hbGlnbjpsZWZ0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6bmF2eSI+DQo8aHIgc2l6ZT0iMSIgd2lkdGg9IjEwMCIgc3R5bGU9IndpZHRoOjc1LjBwdCIg bm9zaGFkZT0iIiBzdHlsZT0iY29sb3I6I0I1QzRERiIgYWxpZ249ImxlZnQiPg0KPC9zcGFuPjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCIgc3R5 bGU9InRleHQtYWxpZ246bGVmdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOnNp bHZlciI+WWluZyBDSEVORyZuYnNwOw0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O01TIEdvdGhpYyZxdW90Oztjb2xvcjpzaWx2ZXIiPueoizwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpNaW5nTGlVO2Nv bG9yOnNpbHZlciI+6I65PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpz aWx2ZXIiPjxicj4NClRlY2hub2xvZ3kgRGVwYXJ0bWVudCwgQ2hpbmEgVW5pY29tIDwvc3Bhbj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtNUyBHb3RoaWMm cXVvdDs7Y29sb3I6c2lsdmVyIj7kuK3lm708L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6TWluZ0xpVTtjb2xvcjpzaWx2ZXIiPuiBlOmAmumbhuWbouaKgOac r+mDqDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6c2lsdmVyIj48YnI+ DQpUZWw6ICYjNDM7ODYtMTAtNjYyNTkzOTQ8YnI+DQpNb2JpbGU6ICYjNDM7ODYtMTg2MDExMDI5 NzEgPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9Ik1z b05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPg0KPGhyIHNpemU9IjEiIHdpZHRoPSIxMDAlIiBub3NoYWRl PSIiIHN0eWxlPSJjb2xvcjojQjVDNERGIiBhbGlnbj0iY2VudGVyIj4NCjwvc3Bhbj48L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCIgc3R5bGU9InRleHQtYWxp Z246bGVmdCI+PHN0cm9uZz48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTpNaW5nTGlVIj7lj5Hku7bkurrvvJo8L3NwYW4+PC9zdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij4gTmV2aWwgQnJvd25sZWUNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0IiBzdHlsZT0idGV4dC1h bGlnbjpsZWZ0Ij48c3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5Ok1pbmdMaVUiPuWPkemAgeaXtumXtO+8mjwvc3Bhbj48L3N0cm9uZz48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPiAyMDE2LTExLTE3Jm5ic3A7IDE3OjMyOjEzDQo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVm dCIgc3R5bGU9InRleHQtYWxpZ246bGVmdCI+PHN0cm9uZz48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDsiPuaUtuS7tuS6uu+8mjwv c3Bhbj48L3N0cm9uZz48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPg0KPGEgaHJlZj0ibWFp bHRvOmRyYWZ0LWNoZW5nLXN1cGEtYXBwbGljYWJpbGl0eUBpZXRmLm9yZyI+ZHJhZnQtY2hlbmct c3VwYS1hcHBsaWNhYmlsaXR5QGlldGYub3JnPC9hPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiIHN0eWxlPSJ0 ZXh0LWFsaWduOmxlZnQiPjxzdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7TVMgR290aGljJnF1b3Q7Ij7mioTpgIHvvJo8L3NwYW4+PC9zdHJvbmc+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gU1VQQSBsaXN0DQo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCIg c3R5bGU9InRleHQtYWxpZ246bGVmdCI+PHN0cm9uZz48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDsiPuS4uzwvc3Bhbj48L3N0cm9u Zz48c3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5Ok1pbmdM aVUiPumimDwvc3Bhbj48L3N0cm9uZz48c3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O01TIEdvdGhpYyZxdW90OyI+77yaPC9zcGFuPjwvc3Ryb25n PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+DQogV2UgbmVlZCBzb21lIGdvb2QgZXhhbXBs ZXMgb2Ygd2hhdCBTVVBBIGNhbiBkbyAhIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCIgc3R5bGU9InRl eHQtYWxpZ246bGVmdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5IaSZuYnNwO2FsbDo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBhbGlnbj0ibGVmdCIgc3R5bGU9InRleHQtYWxpZ246bGVmdCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5Zb3VyJm5ic3A7U1VQQSZuYnNwO2NoYWlycyZuYnNwO21ldCZuYnNwO3RoaXMm bmJzcDttb3JuaW5nJm5ic3A7d2l0aCZuYnNwO3NvbWUmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO1NV UEEmbmJzcDtJLUQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCIgc3R5bGU9InRleHQtYWxpZ246bGVmdCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5hdXRob3JzJm5ic3A7dG8mbmJzcDtjb25zaWRlciZuYnNw OyZxdW90O2hvdyZuYnNwO2NhbiZuYnNwO3dlJm5ic3A7Z2V0Jm5ic3A7cGVvcGxlJm5ic3A7d29y a2luZyZuYnNwO29uJm5ic3A7c29tZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0IiBzdHlsZT0idGV4dC1hbGlnbjps ZWZ0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJk YW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPnNpbXBsZSZuYnNwO2V4YW1wbGVzJm5i c3A7dG8mbmJzcDtkZW1vbnN0cmF0ZSZuYnNwO2hvdyZuYnNwO1NVUEEmbmJzcDtjb3VsZCZuYnNw O2JlJm5ic3A7dXNlZC4mcXVvdDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCIgc3R5bGU9InRleHQtYWxpZ246bGVm dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFu YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5PbmUmbmJzcDtpZGVhJm5ic3A7d2UmbmJz cDtjb25zaWRlcmVkJm5ic3A7d2FzJm5ic3A7JnF1b3Q7d2UmbmJzcDtuZWVkJm5ic3A7YSZuYnNw O2ZldyZuYnNwO2dvb2QmbmJzcDtleGFtcGxlJm5ic3A7dXNlcyw8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCIgc3R5 bGU9InRleHQtYWxpZ246bGVmdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij53aXRoJm5i c3A7Y2xlYXImbmJzcDtzcGVjcyZuYnNwO3dyaXR0ZW4mbmJzcDtmb3ImbmJzcDtlYWNoJm5ic3A7 LSZuYnNwO3dlJm5ic3A7Y291bGQmbmJzcDtzdGFydCZuYnNwO3dpdGgmbmJzcDt0aGU8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGln bj0ibGVmdCIgc3R5bGU9InRleHQtYWxpZ246bGVmdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5leGFtcGxlcyZuYnNwO2luJm5ic3A7b3VyJm5ic3A7KGRyYWZ0KSZuYnNwO0FwcGxpY2Fi aWxpdHkmbmJzcDtTdGF0ZW1lbnQuJm5ic3A7Jm5ic3A7VGhhdCZuYnNwO2NvbnNpZGVyczxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFs aWduPSJsZWZ0IiBzdHlsZT0idGV4dC1hbGlnbjpsZWZ0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPmZpdmUmbmJzcDtleGFtcGxlcyZuYnNwOy08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCIgc3R5bGU9InRl eHQtYWxpZ246bGVmdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDsmbmJzcDsm bmJzcDs0LjEuJm5ic3A7Jm5ic3A7VXNlJm5ic3A7Q2FzZSZuYnNwOzE6Jm5ic3A7U3dpdGNoZWQm bmJzcDtFdGhlcm5ldCZuYnNwO3NlcnZpY2VzJm5ic3A7KFNFUyk8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCIgc3R5 bGU9InRleHQtYWxpZ246bGVmdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDsm bmJzcDsmbmJzcDs0LjIuJm5ic3A7Jm5ic3A7VXNlJm5ic3A7Q2FzZSZuYnNwOzI6Jm5ic3A7Vmly dHVhbGl6ZWQmbmJzcDtQcml2YXRlJm5ic3A7Q2xvdWRzJm5ic3A7KFZQQyk8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVm dCIgc3R5bGU9InRleHQtYWxpZ246bGVmdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4m bmJzcDsmbmJzcDsmbmJzcDs0LjMuJm5ic3A7Jm5ic3A7VXNlJm5ic3A7Q2FzZSZuYnNwOzM6Jm5i c3A7VHJhZmZpYyZuYnNwO01hbmlwdWxhdGlvbiZuYnNwO2Nyb3NzJm5ic3A7RENzPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249 ImxlZnQiIHN0eWxlPSJ0ZXh0LWFsaWduOmxlZnQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7NC40LiZuYnNwOyZuYnNwO1VzZSZuYnNwO0Nhc2UmbmJzcDs0 OiZuYnNwO1ZpcnR1YWwmbmJzcDtTUDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0IiBzdHlsZT0idGV4dC1hbGlnbjps ZWZ0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJk YW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOzQuNS4m bmJzcDsmbmJzcDtVc2UmbmJzcDtDYXNlJm5ic3A7NTombmJzcDtJbnN0YW50Jm5ic3A7VlBOPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg YWxpZ249ImxlZnQiIHN0eWxlPSJ0ZXh0LWFsaWduOmxlZnQiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7NC42LiZuYnNwOyZuYnNwO1VzZSZuYnNwO0Nhc2Um bmJzcDs2OiZuYnNwO3RyYWZmaWMmbmJzcDtvcHRpbWl6YXRpb24mbmJzcDthbmQmbmJzcDtRb3Mm bmJzcDthc3N1cmFuY2UmbmJzcDtvbiZuYnNwO0lTUCZuYnNwO0RDPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiIHN0 eWxlPSJ0ZXh0LWFsaWduOmxlZnQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SXQmbmJz cDt3b3VsZCZuYnNwO2hlbHAmbmJzcDtTVVBBJm5ic3A7YSZuYnNwO2xvdCZuYnNwO3RvJm5ic3A7 aGF2ZSZuYnNwO2lucHV0LCZuYnNwO2VzcGVjaWFsbHkmbmJzcDtmcm9tJm5ic3A7bmV0d29yazxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IGFsaWduPSJsZWZ0IiBzdHlsZT0idGV4dC1hbGlnbjpsZWZ0Ij48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPm9wZXJhdG9ycywmbmJzcDt0ZWxsaW5nJm5ic3A7dXMmbmJzcDsmcXVvdDt3aGF0 Jm5ic3A7ZG8mbmJzcDt5b3UmbmJzcDthY3R1YWxseSZuYnNwO3dhbnQmbmJzcDsoU1VQQSZuYnNw O3RvKSZuYnNwO2RvPyZxdW90OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0IiBzdHlsZT0idGV4dC1hbGlnbjpsZWZ0 Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkRvJm5ic3A7cGxlYXNlJm5ic3A7Z2l2ZSZu YnNwO3RoaXMmbmJzcDtzb21lJm5ic3A7dGhvdWdodCwmbmJzcDthbmQmbmJzcDtzZW5kJm5ic3A7 eW91ciZuYnNwOyd3aXNoZXMnJm5ic3A7dGV4dCZuYnNwO3RvPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiIHN0eWxl PSJ0ZXh0LWFsaWduOmxlZnQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+dGhlJm5ic3A7 U1VQQSZuYnNwO2xpc3QhPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiIHN0eWxlPSJ0ZXh0LWFsaWduOmxlZnQiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Q2hlZXJzLCZuYnNwO05ldmlsPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249Imxl ZnQiIHN0eWxlPSJ0ZXh0LWFsaWduOmxlZnQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ LS0mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBhbGlnbj0ibGVmdCIgc3R5bGU9InRleHQtYWxpZ246bGVmdCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCIgc3R5bGU9InRl eHQtYWxpZ246bGVmdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDsmbmJzcDtO ZXZpbCZuYnNwO0Jyb3dubGVlJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Q29tcHV0ZXImbmJzcDtTY2llbmNlJm5ic3A7RGVwYXJ0 bWVudCZuYnNwO3wmbmJzcDtJVFM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCIgc3R5bGU9InRleHQtYWxpZ246bGVm dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFu YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDsmbmJzcDtQaG9uZTombmJzcDsm IzQzOzY0Jm5ic3A7OSZuYnNwOzM3MyZuYnNwOzc1OTkmbmJzcDt4ODg5NDEmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDtUaGUmbmJzcDtVbml2ZXJzaXR5Jm5ic3A7b2YmbmJzcDtBdWNrbGFuZDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWdu PSJsZWZ0IiBzdHlsZT0idGV4dC1hbGlnbjpsZWZ0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPiZuYnNwOyZuYnNwO0ZBWDombmJzcDsmIzQzOzY0Jm5ic3A7OSZuYnNwOzM3MyZuYnNwOzc0 NTMmbmJzcDsmbmJzcDsmbmJzcDtQcml2YXRlJm5ic3A7QmFnJm5ic3A7OTIwMTksJm5ic3A7QXVj a2xhbmQmbmJzcDsxMTQyLCZuYnNwO05ldyZuYnNwO1plYWxhbmQ8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiIHN0 eWxlPSJ0ZXh0LWFsaWduOmxlZnQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2Vu dGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+DQo8aHIgc2l6ZT0iMiIgd2lkdGg9IjEwMCUiIGFsaWduPSJjZW50ZXIiPg0KPC9zcGFuPjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiIHN0eWxlPSJ0ZXh0LWFsaWdu OmxlZnQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O01T IEdvdGhpYyZxdW90Oztjb2xvcjpibHVlIj7lpoLmnpzmgqg8L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6TWluZ0xpVTtjb2xvcjpibHVlIj7plJnor6/mjqXm lLbkuobor6Xpgq7ku7bvvIzor7fpgJrov4fnlLXlrZDpgq7ku7bnq4vljbPpgJrnn6XmiJHku6zj gILor7flm57lpI3pgq7ku7bliLA8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjpibHVlIj5ocXMtc3BtY0BjaGluYXVuaWNvbS5jbjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDs7Y29sb3I6Ymx1ZSI+ 77yM5Y2z5Y+v5Lul6YCAPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5Ok1pbmdMaVU7Y29sb3I6Ymx1ZSI+6K6i5q2k6YKu5Lu244CC5oiR5Lus5bCG56uL5Y2z 5bCG5oKo55qE5L+h5oGv5LuO5oiR5Lus55qE5Y+R6YCB55uu5b2V5Lit5Yig6Zmk44CCPC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+PGJyPg0KSWYgeW91IGhhdmUg cmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5IHVzIGltbWVkaWF0ZWx5 IGJ5IGUtbWFpbC4gUGxlYXNlIHJlcGx5IHRvDQo8YSBocmVmPSJtYWlsdG86aHFzLXNwbWNAY2hp bmF1bmljb20uY24iPmhxcy1zcG1jQGNoaW5hdW5pY29tLmNuPC9hPiBpZiB5b3Ugd2FudCB0byB1 bnN1YnNjcmliZSBmcm9tIHRoaXMgbWFpbC4gV2Ugd2lsbCBpbW1lZGlhdGVseSByZW1vdmUgeW91 ciBpbmZvcm1hdGlvbiBmcm9tIG91ciBzZW5kaW5nIGNhdGFsb2d1ZS48L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYm9k eT4NCjwvaHRtbD4NCg== --_000_C5034E44CD620A44971BAAEB372655DC2DC4C378lhreml502mbs_-- From nobody Wed Nov 23 06:33:00 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E80D0129E28; Wed, 23 Nov 2016 06:32:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vOwp1s9Ue8gi; Wed, 23 Nov 2016 06:32:56 -0800 (PST) Received: from maila1.tigertech.net (maila1.tigertech.net [208.80.4.151]) (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 51BFA129E08; Wed, 23 Nov 2016 06:32:56 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila1.tigertech.net (Postfix) with ESMTP id 2B6B336139D; Wed, 23 Nov 2016 06:32:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1479911576; bh=sz6cKbyT2GUIwJJbYNCOpPqhaL/FZyW851Wgz9sSBTk=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=H00Dqop5Cxuo8/bRvD9o676JpCGc/y7cp7tNrV4m3dFe1vMJmscOIKPk/5p7nalc9 M+IPboe4i2UHArRbC6pBEK5Dl769ajc0ljvyF/0EKz+NqznZOp4gofEytZ/cxVCBFe +L1ea6SyF2JbMAD2OaG9X2meFSoD6VhWjsuYIxKU= X-Virus-Scanned: Debian amavisd-new at maila1.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila1.tigertech.net (Postfix) with ESMTPSA id 6B7763613AE; Wed, 23 Nov 2016 06:32:55 -0800 (PST) To: "Bert Wijnen (IETF)" , Georgios Karagiannis , Nevil Brownlee , "draft-cheng-supa-applicability@ietf.org" References:

From: "Joel M. Halpern" Message-ID: <7daae66b-1a6b-5591-8818-75ae1d7139a3@joelhalpern.com> Date: Wed, 23 Nov 2016 09:33:41 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: SUPA list Subject: Re: [Supa] We need some good examples of what SUPA can do ! X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is to discuss SUPA $Simplified Use of Policy Abstractions$ related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2016 14:32:59 -0000 To some degree Bert, you are demonstrating the limitations of the directive from the AD that SUPA is to use only ECA policies, not declarative. Modeling the policy goal would be much easier. I do believe that with a few extra definitions, we can create a set of meaningful events to trigger. Mostly the insertion of ports at the edge of the domain. And then the actions will be to create the filter rules to block SNMP in both directions. I will be working with John to work out the exact modeling. Yours, Joel On 11/23/16 5:54 AM, Bert Wijnen (IETF) wrote: > On 23/11/2016 10:56, Georgios Karagiannis wrote: >> Hi Bert, >> >> Thanks for your input. >> Please note that I agree with Joel that the input is useful. >> Can you please provide more details on what will be the Event >> Condition Action? > well, is that not my exact question? > > I am asking what ECA policies need to be setup/defined in order to > achieve/effectuate a policy that > > ensures that SNMP is blocked on ports at the edge > of the administrative domain to prevent SNMP going > out or coming in from outside the enterprise. > > Bert >> Best regards, >> Georgios >> >> >> -----Original Message----- >> From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of Joel M. Halpern >> Sent: Friday, November 18, 2016 2:45 AM >> To: Bert Wijnen (IETF); Nevil Brownlee; >> draft-cheng-supa-applicability@ietf.org >> Cc: SUPA list >> Subject: Re: [Supa] We need some good examples of what SUPA can do ! >> >> Thank you Bert. That is exactly the kind of request I am looking for. >> >> No, I do not think it will be simple to answer your question. But I >> do think that showing how to do so will show both what we have and >> what more we need. >> >> Yours, >> Joel >> >> On 11/17/16 8:28 PM, Bert Wijnen (IETF) wrote: >>> Could the proponets of the current (in my view still complex) IM and >>> DM work out how one would define/configure/populate the policies for: >>> >>> ensure that SNMP is blocked on ports at the edge >>> of the administrative domain to prevent SNMP going >>> out or coming in from outside the enterprise. >>> >>> This should be simple, no? >>> >>> Thanks, Bert >>> >>> On 17/11/2016 18:31, Nevil Brownlee wrote: >>>> Hi all: >>>> >>>> Your SUPA chairs met this morning with some of the SUPA I-D authors >>>> to consider "how can we get people working on some simple examples to >>>> demonstrate how SUPA could be used." >>>> >>>> One idea we considered was "we need a few good example uses, with >>>> clear specs written for each - we could start with the examples in >>>> our (draft) Applicability Statement. That considers five examples - >>>> >>>> 4.1. Use Case 1: Switched Ethernet services (SES) >>>> 4.2. Use Case 2: Virtualized Private Clouds (VPC) >>>> 4.3. Use Case 3: Traffic Manipulation cross DCs >>>> 4.4. Use Case 4: Virtual SP >>>> 4.5. Use Case 5: Instant VPN >>>> 4.6. Use Case 6: traffic optimization and Qos assurance on ISP DC >>>> >>>> It would help SUPA a lot to have input, especially from network >>>> operators, telling us "what do you actually want (SUPA to) do?" >>>> >>>> Do please give this some thought, and send your 'wishes' text to the >>>> SUPA list! >>>> >>>> Cheers, Nevil >>>> >>> _______________________________________________ >>> Supa mailing list >>> Supa@ietf.org >>> https://www.ietf.org/mailman/listinfo/supa >>> >> _______________________________________________ >> Supa mailing list >> Supa@ietf.org >> https://www.ietf.org/mailman/listinfo/supa >> > From nobody Sat Nov 26 05:29:59 2016 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0ED0129682 for ; Sat, 26 Nov 2016 05:29:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, 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 EIycnza1HT8t for ; Sat, 26 Nov 2016 05:29:55 -0800 (PST) Received: from mail-pf0-x241.google.com (mail-pf0-x241.google.com [IPv6:2607:f8b0:400e:c00::241]) (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 0BBF4129634 for ; Sat, 26 Nov 2016 05:29:55 -0800 (PST) Received: by mail-pf0-x241.google.com with SMTP id i88so4210603pfk.2 for