From nobody Wed Sep 2 06:58:37 2015 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 867661B4169 for ; Wed, 2 Sep 2015 06:58:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hJMG3Z_UpK71 for ; Wed, 2 Sep 2015 06:58:35 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87E881B2E9D for ; Wed, 2 Sep 2015 06:58:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2800; q=dns/txt; s=iport; t=1441202314; x=1442411914; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=L5yrmZo2l0E6Imp3OINKdg0Rzg/ZiqyEEEETPkKb+O8=; b=hc7I8nOkicfT4YeyvfsiJdvOXpA8xg/rvJDRI0YzQFfz6u14Q0WBqX0g WZ/iqpKFGBtElwjVTMUQZYFAfNFdciaXkqfkeOB+1sBWj6dvu/kr+afXv HJJ6Bz7216/Xv0Ux+qriOi5g9VQ75k64LTtMnlv2CIPZOE5o9OqjNOTnj I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CbBABJAOdV/xbLJq1dg2/AMoV7AoIBAQEBAQEBgQuEJAEBBDhRCxgJJQ8CRgYBDAgBAReIEw3LLAEBAQEBAQEBAgEBAQEBAQEXBIRKgimEe4Q5AQEBVoQsAQSVSYUHh2+IeJF3JoIPHIFWPIFBgT8BAQE X-IronPort-AV: E=Sophos;i="5.17,453,1437436800"; d="scan'208";a="606745780" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 02 Sep 2015 13:58:22 +0000 Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t82DwLX5019670; Wed, 2 Sep 2015 13:58:21 GMT To: Andy Bierman , "Scharf, Michael (Michael)" , John Strassner , "Romascanu, Dan (Dan)" , "Eggert, Lars" , Adrian Farrel , "supa@ietf.org" References: <9904FB1B0159DA42B0B887B7FA8119CA5CAF26AA@AZ-FFEXMB04.global.avaya.com> <20150809173025.GA14833@elstar.local> <9904FB1B0159DA42B0B887B7FA8119CA5CAF26F9@AZ-FFEXMB04.global.avaya.com> <20150809205503.GB15079@elstar.local> <655C07320163294895BBADA28372AF5D4845EBEC@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20150813200304.GA23279@elstar.local> <655C07320163294895BBADA28372AF5D4845F647@FR712WXCHMBA15.zeu.alcatel-lucent.com> <655C07320163294895BBADA28372AF5D48461F68@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20150815202231.GA61946@elstar.local> From: Benoit Claise Message-ID: <55E70078.80507@cisco.com> Date: Wed, 2 Sep 2015 15:58:16 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20150815202231.GA61946@elstar.local> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Supa] SUPA charter proposal X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2015 13:58:36 -0000 Juergen, So you wants a SIEVE-like language for policies? Not sure I understood that from the BoF. Regards, Benoit > On Sat, Aug 15, 2015 at 10:09:32AM -0700, Andy Bierman wrote: >> I prefer a solution where the smarts are provided by the client, >> not built into the policy engine. > +1 > >> Programming in YANG is a non-starter, >> but programming in a scripting language that is very YANG-aware is quite >> the opposite. >> >> event: leverage pub/sub work in NETCONF WG >> condition: scripts, using event data and framework to access topology and >> NE data >> action: scripts, using some framework to access topology and NE data >> >> It is hard to standardize a script language, so not sure how this will >> happen. > There are examples in the IETF, like for instance the SIEVE mail > filtering language: > > https://en.wikipedia.org/wiki/Sieve_%28mail_filtering_language%29 > > Unfortunately, Benoit's proposed charter seems to rule out solutions > where the power is in scriptable events / conditions / actions. So, > the alternatives that are in Benoit's proposed charter are we either > do something that > > (a) requires domain specific data models for every type of policy > (unlikely to be implemented if you ask me) or something that > > (b) exposes even simple boolean expressions as complex collections of > YANG objects (leading to something way too complex to be used for > anything more serious than hello world examples), or > > (c) we will define a policy framework that essentially only works with > strings that mean something to black boxes that interpret them in > whatever way they like best (which is unlikely to be > interoperable). > > Going back to the 'disable SNMP on all edge routers' example, I would > assume that a solution has an action that essentially instantiates ACL > entries according to the YANG ACL configuration data model. The > knowledge of which ports need to be blocked is encoded in the config > snippet embodied in the action. The condition needs to hook into the > topology data model and extract all routers that are edge routers. > This ideally boils down to filtering on some tags in the topology > model. The events that trigger the rule would essentially be any > changes to the IP topology layer (e.g., when edge routers are added or > removed) and it might in addition be periodic. With scriptable > events/conditions/actions, I can see how I could do all this with > meaningful complexity. But as said above, unfortunately Benoit's > proposed charter rules this option out. So the proponents of the other > approaches need to explain how they are going to implement a simple > policy like 'disable SNMP on all edge routers'. > > /js > From nobody Wed Sep 2 08:37:46 2015 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A3C41B44F3 for ; Wed, 2 Sep 2015 08:37:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SnUL4TkLXhNM for ; Wed, 2 Sep 2015 08:37:41 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E11D31B4997 for ; Wed, 2 Sep 2015 08:37:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=27158; q=dns/txt; s=iport; t=1441208234; x=1442417834; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=JR1Xp2jZdaf04jGeAwBRK45L5KCL3A69PtCISMbtC0E=; b=acoatOaknSWDtVZGiQ4CUc3VAOFf7DrdFXTINi89h8bWRksdMJUxE61n vKIDkF/klGe9qo4Fxj++HlW4hmQuhQMHnG2ZdmqCI2igyL1Og/hQ8PjZB xkZl2N4rpFG8Q9BXk09vqsMJMB8QEP36VloBrn7CpmjaI2pYUhj/ddkoU A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BFAgBkF+dV/xbLJq1dg29pvUkBCYFtAQuFeQKBcBQBAQEBAQEBgQqEJAEBBAEBAWsKARALGAkWAQcHCQMCAQIBFR8RBg0GAgEBF4gTDctlAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSGc4R7hCgRAVEHhCwBBJIsgx2FB4dvgUqEMoJ8kXcmghAcgVY8M4EOgT8BAQE X-IronPort-AV: E=Sophos;i="5.17,454,1437436800"; d="scan'208,217";a="629471271" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 02 Sep 2015 15:36:54 +0000 Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t82Fap5K028218; Wed, 2 Sep 2015 15:36:52 GMT To: Andy Bierman References: <55C4D6C1.5040504@cisco.com> From: Benoit Claise Message-ID: <55E71793.1000509@cisco.com> Date: Wed, 2 Sep 2015 17:36:51 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------000800010102020603090506" Archived-At: Cc: "Eggert, Lars" , "supa@ietf.org" Subject: Re: [Supa] SUPA charter proposal X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2015 15:37:44 -0000 This is a multi-part message in MIME format. --------------000800010102020603090506 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Wrt milestones, I'm all in favor of include them. However, there was no point to discuss milestones if the group could not agree on the work first. Regards, Benoit > Hi, > > I have a lot of questions about this work, but in general I would like > a coherent approach to all YANG data model development. This includes > data models for policy-base management. SUPA can really help > in this area. > > Without work item (1) completed, I don't see how any speculation > on the details of (2), (3), and (4) are possible. (But I will > speculate anyway ;-) > > The deliverable in (2) is not very clear. Does this mean an > Informational RFC > based on > https://tools.ietf.org/html/draft-strassner-supa-generic-policy-info-model-00 > I hope it does not mean create a CIM-like model of everything. > This text should be clear wrt/ identifying the deliverable(s). > > The data models in (3) are not very clear either. > Since a "new policy language" is out of scope, > it makes me wonder if the IETF is going to attempt > to get people to "program in YANG" instead. I am only > interested in practical, efficient, and easy-to-use solutions. > I am skeptical that SUPA is going to deliver that. > > There are no milestones mentioned at all. > I guess this is the new normal in the IETF? > Schedules are a joke, so let's just get rid of them completely? > I share Adrian's concern about taking too long to deliver (3), > because other policy work is not going to wait for SUPA. > Can (3) be delivered within 1 year or not? If not, then why not? > > > Andy > > > > On Fri, Aug 7, 2015 at 9:03 AM, Benoit Claise > wrote: > > Dear all, > > As promised in my last email ("SUPA: Situation Summary and Next > Steps"), here is a proposed charter. > Thanks to Robert Sparks, Adrian Farrel, and Dan Romascanu. > > Hopefully, this new version will clarify the situation, and will > be acceptable to everybody. > Please let us know. Note: I prefer to keep the edit token from now. > > Regards, Benoit (OPS AD) > > ============================================================== > > SUPA CHARTER PROPOSAL (2015-08-07) > > Policy is an important configurable component in the delivery of > services and the operation of networks. Operators want and need to > be able to determine the policies that apply to their different > customers and to the equipment that comprises their physical and > virtual networks. As policy spans such a wide range of services > and device types, it will be helpful if there is a common way of > expressing and describing policies that is uniform and consistent > in all environments. Such an approach will help to avoid > configuration errors that arise from confusion between different > systems, will enable easy understanding of policies that apply in > different environments, will make the implementation of > policy-based systems quicker and cheaper, and will facilitate the > rapid development of standards-based data models that include > policy elements. > > SUPA (Simplified Use of Policy Abstractions) defines a model to > interface with a network management function (within a controller, > an orchestrator, a network element) that takes high-level, > possibly network-wide policies as input. SUPA will not define what > the function does with that input but anticipates that it will > ultimately result in network configuration changes > > Practically, SUPA will define generic YANG data models to encode > policy, which can point to device-, technology-, and > service-specific YANG models of other working groups. > > SUPA will be designed to work with device, protocol, network, and > service data models. > > The SUPA working group will develop a model for expressing policy > at different levels of abstraction.Specifically, three model > fragments are envisioned: (i) a generic model that defines > concepts and vocabulary needed by policy management independent of > the form and content of the policy, (ii) a more specific model > that refines the generic model to specify how to build policy > rules of the event-condition-action paradigm, and (iii) the > working group will investigate the practically of building policy > rules that declaratively specify what goals to achieve (this is > often called "intent-based" policy) but not how to achieve those > goals and may create a model accordingly. > > If the working group finds it necessary to work on an information > model before the data model, to help provide guidance and derive > the data models, it might do so. The working group will decide > later whether the information model needs to be published as an RFC. > > Out of scope of this working group is: > > -The specification of a new policy language. The YANG data models > are to be used with protocols such as NETCONF/RESTCONF. > > -Design of protocol-specific policies and specific design for > embedded policies in network elements (which are usually > interpreted in isolation, and often at timescales that require > optimization for specific purposes). > > -Specific handling of policies (although the application document > will provide some examples), and therefore the specification of a > policy engine that maps a specific policy instance to actual > configuration snippets. > > List of work items: > > 1) A document that explains the scope of the policy-based > management framework and how it relates to existing work of the IETF. > > 2) If the working group considers it necessary, an information > model composed of policy concepts and vocabulary. > > 3) A set of YANG data models consisting of a base policy model for > representing policy management concepts independent of the type or > structure of a policy, plus an extension for defining policy rules > according to the event-condition-action paradigm. Another > extension for defining policy rules according to a declarative, or > intent-based, paradigm, may be produced. These models will be > designed to be generic and extensible. > > 4) An applicability document providing a few examples that > demonstrate how the generic policy models can be used to express > policies that are relevant for network operators. The examples may > tie into configuration models or network service models developed > by other working groups. > > The working group will decide how the work items are best mapped > into deliverables. > > This working group will be a success when the SUPA policy > constructs are re-used in future IETF specifications (and, > ideally, specifications from other SDOs), in a manner that will > save development time and avoid inconsistencies between data > models developed by different working groups. In the meantime, > SUPA should not impede work in other working groups while waiting > for SUPA to produce its deliverables. > > The working group will communicate with other SDOs (MEF, TMF, > ETSI) that are working on related issues. > > Milestones: > > TBD > > > > _______________________________________________ > 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 --------------000800010102020603090506 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Wrt milestones, I'm all in favor of include them.
However, there was no point to discuss milestones if the group could not agree on the work first.

Regards, Benoit
Hi,

I have a lot of questions about this work, but in general I would like
a coherent approach to all YANG data model development.  This includes
data models for policy-base management. SUPA can really help
in this area.

Without work item (1) completed, I don't see how any speculation
on the details of (2), (3), and (4) are possible. (But I will speculate anyway ;-)

The deliverable in (2) is not very clear. Does this mean an Informational RFC
I hope it does not mean create a CIM-like model of everything.
This text should be clear wrt/ identifying the deliverable(s).

The data models in (3) are not very clear either.
Since a "new policy language" is out of scope,
it makes me wonder if the IETF is going to attempt
to get people to "program in YANG" instead.  I am only
interested in practical, efficient, and easy-to-use solutions.
I am skeptical that SUPA is going to deliver that.

There are no milestones mentioned at all.
I guess this is the new normal in the IETF?
Schedules are a joke, so let's just get rid of them completely?
I share Adrian's concern about taking too long to deliver (3),
because other policy work is not going to wait for SUPA.
Can (3) be delivered within 1 year or not? If not, then why not?


Andy



On Fri, Aug 7, 2015 at 9:03 AM, Benoit Claise <bclaise@cisco.com> wrote:
Dear all,

As promised in my last email ("SUPA: Situation Summary and Next Steps"), here is a proposed charter.
Thanks to Robert Sparks, Adrian Farrel, and Dan Romascanu.

Hopefully, this new version will clarify the situation, and will be acceptable to everybody.
Please let us know. Note: I prefer to keep the edit token from now.

Regards, Benoit (OPS AD)

==============================================================

SUPA CHARTER PROPOSAL (2015-08-07)

 

Policy is an important configurable component in the delivery of services and the operation of networks. Operators want and need to be able to determine the policies that apply to their different customers and to the equipment that comprises their physical and virtual networks. As policy spans such a wide range of services and device types, it will be helpful if there is a common way of expressing and describing policies that is uniform and consistent in all environments. Such an approach will help to avoid configuration errors that arise from confusion between different systems, will enable easy understanding of policies that apply in different environments, will make the implementation of policy-based systems quicker and cheaper, and will facilitate the rapid development of standards-based data models that include policy elements.

 

 

SUPA (Simplified Use of Policy Abstractions) defines a model to interface with a network management function (within a controller, an orchestrator, a network element) that takes high-level, possibly network-wide policies as input. SUPA will not define what the function does with that input but anticipates that it will ultimately result in network configuration changes

 

 

Practically, SUPA will define generic YANG data models to encode policy, which can point to device-, technology-, and service-specific YANG models of other working groups.

 

SUPA will be designed to work with device, protocol, network, and service data models.

 

The SUPA working group will develop a model for expressing policy at different levels of abstraction.  Specifically, three model fragments are envisioned: (i) a generic model that defines concepts and vocabulary needed by policy management independent of the form and content of the policy, (ii) a more specific model that refines the generic model to specify how to build policy rules of the event-condition-action paradigm, and (iii) the working group will investigate the practically of building policy rules that declaratively specify what goals to achieve (this is often called "intent-based" policy) but not how to achieve those goals and may create a model accordingly.

 

If the working group finds it necessary to work on an information model before the data model, to help provide guidance and derive the data models, it might do so. The working group will decide later whether the information model needs to be published as an RFC.

 

Out of scope of this working group is:  

-   The specification of a new policy language. The YANG data models are to be used with protocols such as NETCONF/RESTCONF.

-   Design of protocol-specific policies and specific design for embedded policies in network elements (which are usually interpreted in isolation, and often at timescales that require optimization for specific purposes).

-   Specific handling of policies (although the application document will provide some examples), and therefore the specification of a policy engine that maps a specific policy instance to actual configuration snippets.

 

List of work items:

 

1) A document that explains the scope of the policy-based management framework and how it relates to existing work of the IETF.

 

2) If the working group considers it necessary, an information model composed of policy concepts and vocabulary.

 

3) A set of YANG data models consisting of a base policy model for representing policy management concepts independent of the type or structure of a policy, plus an extension for defining policy rules according to the event-condition-action paradigm. Another extension for defining policy rules according to a declarative, or intent-based, paradigm, may be produced. These models will be designed to be generic and extensible.

 

4) An applicability document providing a few examples that demonstrate how the generic policy models can be used to express policies that are relevant for network operators. The examples may tie into configuration models or network service models developed by other working groups.

 

The working group will decide how the work items are best mapped into deliverables.

 

This working group will be a success when the SUPA policy constructs are re-used in future IETF specifications (and, ideally, specifications from other SDOs), in a manner that will save development time and avoid inconsistencies between data models developed by different working groups. In the meantime, SUPA should not impede work in other working groups while waiting for SUPA to produce its deliverables.

 

The working group will communicate with other SDOs (MEF, TMF, ETSI) that are working on related issues.

 

Milestones:

 

TBD



_______________________________________________
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

--------------000800010102020603090506-- From nobody Wed Sep 2 08:41:19 2015 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD2E21B2CA6 for ; Wed, 2 Sep 2015 08:41:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Clhf4EuDmBcW for ; Wed, 2 Sep 2015 08:41:11 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD3701B3AE7 for ; Wed, 2 Sep 2015 08:40:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=48861; q=dns/txt; s=iport; t=1441208457; x=1442418057; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=l3EmiVGtNJ1y7YmPf5CeN2ROxOsjO5JKQ/W2MjVPLR0=; b=c6OvuWX9iXm5uX8fNWWrMJFzg6L8HTT3A3O895oDc3uOtkgB343brjE1 V5meBCUC0TB4dMIWqqimj5Ls3R7lGOuqx2lBuV3mHlG+atcYGmrLTgPdL StFYDVuGLgl+gBkNkPReD8kVHChz791vXBllp9ffKAkwdW8HQH8qpsrX1 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DMBAB6F+dV/xbLJq1aA4JOgSFpgyO8BBkBC4V5AoIEAQEBAQEBgQuEIwEBAQMBAQEBFwkmJQMHAQULCQIOCgkWAQEGAwICCQMCAQIBFR8RBgEMBgIBAReICwgNmVGdHZR4AQEBAQEBAQEBAQEBAQEBAQEBAQEBF4ZzhHuEKBEBJwQUAgYKBgESgleBQwEEhy2Kf4MdhQeCbYUCgUqEMoJ8jguDbCaCEByBVjwzgQ6BPwEBAQ X-IronPort-AV: E=Sophos;i="5.17,454,1437436800"; d="scan'208,217";a="606747935" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 02 Sep 2015 15:40:46 +0000 Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t82FejPD029076; Wed, 2 Sep 2015 15:40:45 GMT To: John Strassner , Andrew Veitch References: <55C4D6C1.5040504@cisco.com> <4E723A87-C269-4886-9436-CC85C46E040C@netcracker.com> From: Benoit Claise Message-ID: <55E7187D.3010404@cisco.com> Date: Wed, 2 Sep 2015 17:40:45 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------030909090203030502070201" Archived-At: Cc: "Eggert, Lars" , Andy Bierman , "supa@ietf.org" Subject: Re: [Supa] SUPA charter proposal X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2015 15:41:16 -0000 This is a multi-part message in MIME format. --------------030909090203030502070201 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 09/08/2015 22:58, John Strassner wrote: > Hi, > > > Your comment on (3) is interesting. I do not think there is any > > expectation of programming in Yang. I did have some thoughts > > like that in Prague, as the policies (as I understood them and I > > might have this wrong) are in the form of First Order Logic > > statements. If at a fine enough granularity, perhaps they could > > be strung together and processed as statements are in Prolog. > > Remember that SUPA defines a framework for both imperative > (e.g., event-condition-action) and declarative policies. I think that > mapping the former to YANG is easier than the latter, Exactly. As I mentioned before, this is the reason why the charter proposal includes those 2 "may" sentences , stressing the experimental aspect of the intent-based: (iii) the working group will investigate the practically of building policy rules that declaratively specify what goals to achieve (this is often called "intent-based" policy) but not how to achieve those goals and may create a model accordingly. Another extension for defining policy rules according to a declarative, or intent-based, paradigm, may be produced. Regards, Benoit > since > additional semantics (e.g., some system of inference rules and > axioms must be supplied, along with the ability to ensure that > formulae are well-formed (e.g., restricted stratification). > > Put another way: > > 1) for ECA, YANG data models should be able to be directly produced > 2) for declarative policies, I would first send to a logic evaluation > function, and then send the output to produce YANG data models > > regards, > John > > > On Sat, Aug 8, 2015 at 12:01 PM, Andrew Veitch > > > wrote: > > Hi Andy, > > Your comment on (3) is interesting. I do not think there is any > expectation of programming in Yang. I did have some thoughts like > that in Prague, as the policies (as I understood them and i might > have this wrong) are in the form of First Order Logic statements. > If at a fine enough granularity, perhaps they could be strung > together and processed as statements are in Prolog. > > But I believe the intention, buttressed by my reading of the term > “high level … policies” (I take that very seriously) in the > charter, is that these define high-level policies and a policy > engine (or whatever) would process them and use scripts, or rules, > or whatever, to figure out how to support them (also specifically > listed as out of scope.) > > My hope for SUPA is what you listed up front, and I think it could > deliver: providing a piece for the coherent approach to data > models. And it seems like SUPA could deliver a common form for > representing policy, with specializations for ECA and/or > Declarative as needed. > > I agree, milestones are a must. I think the TBD is just that, > perhaps these can be easily addressed after the first part is settled. > > Best regards, > > Andy > > > > Andrew Veitch | Mobile: +1 (781) 366-7763 > | www. > Net Cracker > .com   >>>>  > * Proven Partner to Communications Service Providers* > >> On Aug 8, 2015, at 1:48 PM, Andy Bierman > > wrote: >> >> Hi, >> >> I have a lot of questions about this work, but in general I would >> like >> a coherent approach to all YANG data model development. This >> includes >> data models for policy-base management. SUPA can really help >> in this area. >> >> Without work item (1) completed, I don't see how any speculation >> on the details of (2), (3), and (4) are possible. (But I will >> speculate anyway ;-) >> >> The deliverable in (2) is not very clear. Does this mean an >> Informational RFC >> based on >> https://tools.ietf.org/html/draft-strassner-supa-generic-policy-info-model-00 >> I hope it does not mean create a CIM-like model of everything. >> This text should be clear wrt/ identifying the deliverable(s). >> >> The data models in (3) are not very clear either. >> Since a "new policy language" is out of scope, >> it makes me wonder if the IETF is going to attempt >> to get people to "program in YANG" instead. I am only >> interested in practical, efficient, and easy-to-use solutions. >> I am skeptical that SUPA is going to deliver that. >> >> There are no milestones mentioned at all. >> I guess this is the new normal in the IETF? >> Schedules are a joke, so let's just get rid of them completely? >> I share Adrian's concern about taking too long to deliver (3), >> because other policy work is not going to wait for SUPA. >> Can (3) be delivered within 1 year or not? If not, then why not? >> >> >> Andy >> >> >> >> On Fri, Aug 7, 2015 at 9:03 AM, Benoit Claise > > wrote: >> >> Dear all, >> >> As promised in my last email ("SUPA: Situation Summary and >> Next Steps"), here is a proposed charter. >> Thanks to Robert Sparks, Adrian Farrel, and Dan Romascanu. >> >> Hopefully, this new version will clarify the situation, and >> will be acceptable to everybody. >> Please let us know. Note: I prefer to keep the edit token >> from now. >> >> Regards, Benoit (OPS AD) >> >> ============================================================== >> >> SUPA CHARTER PROPOSAL (2015-08-07) >> >> Policy is an important configurable component in the delivery >> of services and the operation of networks. Operators want and >> need to be able to determine the policies that apply to their >> different customers and to the equipment that comprises their >> physical and virtual networks. As policy spans such a wide >> range of services and device types, it will be helpful if >> there is a common way of expressing and describing policies >> that is uniform and consistent in all environments. Such an >> approach will help to avoid configuration errors that arise >> from confusion between different systems, will enable easy >> understanding of policies that apply in different >> environments, will make the implementation of policy-based >> systems quicker and cheaper, and will facilitate the rapid >> development of standards-based data models that include >> policy elements. >> >> SUPA (Simplified Use of Policy Abstractions) defines a model >> to interface with a network management function (within a >> controller, an orchestrator, a network element) that takes >> high-level, possibly network-wide policies as input. SUPA >> will not define what the function does with that input but >> anticipates that it will ultimately result in network >> configuration changes >> >> Practically, SUPA will define generic YANG data models to >> encode policy, which can point to device-, technology-, and >> service-specific YANG models of other working groups. >> >> SUPA will be designed to work with device, protocol, network, >> and service data models. >> >> The SUPA working group will develop a model for expressing >> policy at different levels of abstraction.Specifically, three >> model fragments are envisioned: (i) a generic model that >> defines concepts and vocabulary needed by policy management >> independent of the form and content of the policy, (ii) a >> more specific model that refines the generic model to specify >> how to build policy rules of the event-condition-action >> paradigm, and (iii) the working group will investigate the >> practically of building policy rules that declaratively >> specify what goals to achieve (this is often called >> "intent-based" policy) but not how to achieve those goals and >> may create a model accordingly. >> >> If the working group finds it necessary to work on an >> information model before the data model, to help provide >> guidance and derive the data models, it might do so. The >> working group will decide later whether the information model >> needs to be published as an RFC. >> >> Out of scope of this working group is: >> >> -The specification of a new policy language. The YANG data >> models are to be used with protocols such as NETCONF/RESTCONF. >> >> -Design of protocol-specific policies and specific design for >> embedded policies in network elements (which are usually >> interpreted in isolation, and often at timescales that >> require optimization for specific purposes). >> >> -Specific handling of policies (although the application >> document will provide some examples), and therefore the >> specification of a policy engine that maps a specific policy >> instance to actual configuration snippets. >> >> List of work items: >> >> 1) A document that explains the scope of the policy-based >> management framework and how it relates to existing work of >> the IETF. >> >> 2) If the working group considers it necessary, an >> information model composed of policy concepts and vocabulary. >> >> 3) A set of YANG data models consisting of a base policy >> model for representing policy management concepts independent >> of the type or structure of a policy, plus an extension for >> defining policy rules according to the event-condition-action >> paradigm. Another extension for defining policy rules >> according to a declarative, or intent-based, paradigm, may be >> produced. These models will be designed to be generic and >> extensible. >> >> 4) An applicability document providing a few examples that >> demonstrate how the generic policy models can be used to >> express policies that are relevant for network operators. The >> examples may tie into configuration models or network service >> models developed by other working groups. >> >> The working group will decide how the work items are best >> mapped into deliverables. >> >> This working group will be a success when the SUPA policy >> constructs are re-used in future IETF specifications (and, >> ideally, specifications from other SDOs), in a manner that >> will save development time and avoid inconsistencies between >> data models developed by different working groups. In the >> meantime, SUPA should not impede work in other working groups >> while waiting for SUPA to produce its deliverables. >> >> The working group will communicate with other SDOs (MEF, TMF, >> ETSI) that are working on related issues. >> >> Milestones: >> >> TBD >> >> >> >> _______________________________________________ >> 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 > > ------------------------------------------------------------------------ > The information transmitted herein is intended only for the person > or entity to which it is addressed and may contain confidential, > proprietary and/or privileged material. Any review, > retransmission, dissemination or other use of, or taking of any > action in reliance upon, this information by persons or entities > other than the intended recipient is prohibited. If you received > this in error, please contact the sender and delete the material > from any computer. > > _______________________________________________ > Supa mailing list > Supa@ietf.org > https://www.ietf.org/mailman/listinfo/supa > > > > > -- > regards, > John --------------030909090203030502070201 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 09/08/2015 22:58, John Strassner wrote:
Hi,

> Your comment on (3) is interesting.   I do not think there is any
> expectation of programming in Yang.  I did have some thoughts
> like that in Prague, as the policies (as I understood them and I
> might have this wrong) are in the form of First Order Logic
> statements.  If at a fine enough granularity,  perhaps they could
> be strung together and processed as statements are in Prolog.  

Remember that SUPA defines a framework for both imperative
(e.g., event-condition-action) and declarative policies. I think that
mapping the former to YANG is easier than the latter,
Exactly.
As I mentioned before, this is the reason why the charter proposal includes those 2 "may" sentences , stressing the experimental aspect of the intent-based: 
(iii) the working group will investigate the practically of building policy
rules that declaratively specify what goals to achieve (this is often called
"intent-based" policy) but not how to achieve those goals and may create a model
accordingly.
Another extension for defining policy rules
according to a declarative, or intent-based, paradigm, may be produced.
Regards, Benoit
since
additional semantics (e.g., some system of inference rules and
axioms must be supplied, along with the ability to ensure that
formulae are well-formed (e.g., restricted stratification).

Put another way:

  1) for ECA, YANG data models should be able to be directly produced
  2) for declarative policies, I would first send to a logic evaluation
      function, and then send the output to produce YANG data models

regards,
John


On Sat, Aug 8, 2015 at 12:01 PM, Andrew Veitch <andrew.veitch@netcracker.com> wrote:
Hi Andy,

Your comment on (3) is interesting.   I do not think there is any expectation of programming in Yang.  I did have some thoughts like that in Prague, as the policies (as I understood them and i might have this wrong) are in the form of First Order Logic statements.  If at a fine enough granularity,  perhaps they could be strung together and processed as statements are in Prolog.  

But I believe the intention, buttressed by my reading of the term “high level … policies” (I take that very seriously) in the charter, is that these define high-level policies and a policy engine (or whatever) would process them and use scripts, or rules, or whatever, to figure out how to support them (also specifically listed as out of scope.)

My hope for SUPA is what you listed up front, and I think it could deliver: providing a piece for the coherent approach to data models.  And it seems like SUPA could deliver a common form for representing policy, with specializations for ECA and/or Declarative as needed.  

I agree, milestones are a must.  I think the TBD is just that, perhaps these can be easily addressed after the first part is settled.

Best regards,

Andy



Andrew Veitch | Mobile: +1 (781) 366-7763 | www.NetCracker.com  >>>>  Proven Partner to Communications Service Providers

On Aug 8, 2015, at 1:48 PM, Andy Bierman <andy@yumaworks.com> wrote:

Hi,

I have a lot of questions about this work, but in general I would like
a coherent approach to all YANG data model development.  This includes
data models for policy-base management. SUPA can really help
in this area.

Without work item (1) completed, I don't see how any speculation
on the details of (2), (3), and (4) are possible. (But I will speculate anyway ;-)

The deliverable in (2) is not very clear. Does this mean an Informational RFC
I hope it does not mean create a CIM-like model of everything.
This text should be clear wrt/ identifying the deliverable(s).

The data models in (3) are not very clear either.
Since a "new policy language" is out of scope,
it makes me wonder if the IETF is going to attempt
to get people to "program in YANG" instead.  I am only
interested in practical, efficient, and easy-to-use solutions.
I am skeptical that SUPA is going to deliver that.

There are no milestones mentioned at all.
I guess this is the new normal in the IETF?
Schedules are a joke, so let's just get rid of them completely?
I share Adrian's concern about taking too long to deliver (3),
because other policy work is not going to wait for SUPA.
Can (3) be delivered within 1 year or not? If not, then why not?


Andy



On Fri, Aug 7, 2015 at 9:03 AM, Benoit Claise <bclaise@cisco.com> wrote:
Dear all,

As promised in my last email ("SUPA: Situation Summary and Next Steps"), here is a proposed charter.
Thanks to Robert Sparks, Adrian Farrel, and Dan Romascanu.

Hopefully, this new version will clarify the situation, and will be acceptable to everybody.
Please let us know. Note: I prefer to keep the edit token from now.

Regards, Benoit (OPS AD)

==============================================================

SUPA CHARTER PROPOSAL (2015-08-07)

 

Policy is an important configurable component in the delivery of services and the operation of networks. Operators want and need to be able to determine the policies that apply to their different customers and to the equipment that comprises their physical and virtual networks. As policy spans such a wide range of services and device types, it will be helpful if there is a common way of expressing and describing policies that is uniform and consistent in all environments. Such an approach will help to avoid configuration errors that arise from confusion between different systems, will enable easy understanding of policies that apply in different environments, will make the implementation of policy-based systems quicker and cheaper, and will facilitate the rapid development of standards-based data models that include policy elements.

 

 

SUPA (Simplified Use of Policy Abstractions) defines a model to interface with a network management function (within a controller, an orchestrator, a network element) that takes high-level, possibly network-wide policies as input. SUPA will not define what the function does with that input but anticipates that it will ultimately result in network configuration changes

 

 

Practically, SUPA will define generic YANG data models to encode policy, which can point to device-, technology-, and service-specific YANG models of other working groups.

 

SUPA will be designed to work with device, protocol, network, and service data models.

 

The SUPA working group will develop a model for expressing policy at different levels of abstraction.  Specifically, three model fragments are envisioned: (i) a generic model that defines concepts and vocabulary needed by policy management independent of the form and content of the policy, (ii) a more specific model that refines the generic model to specify how to build policy rules of the event-condition-action paradigm, and (iii) the working group will investigate the practically of building policy rules that declaratively specify what goals to achieve (this is often called "intent-based" policy) but not how to achieve those goals and may create a model accordingly.

 

If the working group finds it necessary to work on an information model before the data model, to help provide guidance and derive the data models, it might do so. The working group will decide later whether the information model needs to be published as an RFC.

 

Out of scope of this working group is:  

-   The specification of a new policy language. The YANG data models are to be used with protocols such as NETCONF/RESTCONF.

-   Design of protocol-specific policies and specific design for embedded policies in network elements (which are usually interpreted in isolation, and often at timescales that require optimization for specific purposes).

-   Specific handling of policies (although the application document will provide some examples), and therefore the specification of a policy engine that maps a specific policy instance to actual configuration snippets.

 

List of work items:

 

1) A document that explains the scope of the policy-based management framework and how it relates to existing work of the IETF.

 

2) If the working group considers it necessary, an information model composed of policy concepts and vocabulary.

 

3) A set of YANG data models consisting of a base policy model for representing policy management concepts independent of the type or structure of a policy, plus an extension for defining policy rules according to the event-condition-action paradigm. Another extension for defining policy rules according to a declarative, or intent-based, paradigm, may be produced. These models will be designed to be generic and extensible.

 

4) An applicability document providing a few examples that demonstrate how the generic policy models can be used to express policies that are relevant for network operators. The examples may tie into configuration models or network service models developed by other working groups.

 

The working group will decide how the work items are best mapped into deliverables.

 

This working group will be a success when the SUPA policy constructs are re-used in future IETF specifications (and, ideally, specifications from other SDOs), in a manner that will save development time and avoid inconsistencies between data models developed by different working groups. In the meantime, SUPA should not impede work in other working groups while waiting for SUPA to produce its deliverables.

 

The working group will communicate with other SDOs (MEF, TMF, ETSI) that are working on related issues.

 

Milestones:

 

TBD



_______________________________________________
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

 

The information transmitted herein is intended only for the person or entity to which it is addressed and may contain confidential, proprietary and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.  

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




--
regards,
John

--------------030909090203030502070201-- From nobody Wed Sep 2 08:48:01 2015 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44E811A9008 for ; Wed, 2 Sep 2015 08:48:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yA0MygNBVijC for ; Wed, 2 Sep 2015 08:47:57 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F75B1B3844 for ; Wed, 2 Sep 2015 08:47:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=28409; q=dns/txt; s=iport; t=1441208878; x=1442418478; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=7EYpZy3kLGSdgKyOw3fjpcGf0tnBDiEpgqVhf1nZ/O8=; b=g0cozXY3s8RlOM/euqG5g2HPDhAIHD8mBgXFZNszWVo+Vw6LNJJVMWaR A8O13NZV6v6K7ua1H2k1LGannIiovNf23bICh6CweiMAL8iAIdcnkl4uw 9X7AW23tHjUliyMsakWWBDgqV4i8qx2Xb61zkC7qp4GWEkJLB+ZtIlavl U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BDAgDKGedV/xbLJq1dgk6CCr1JAQmHcgKBcBQBAQEBAQEBgQqEIwEBAQQtSwEQCxEEAQEKFgEHBwkDAgECATQJCAYBDAYCAQGIKstrAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4ZzhHuEKBEBUQYBBoQmAQSVSYx2gUqEMoJ8kXcmhAI8M4EOgT8BAQE X-IronPort-AV: E=Sophos;i="5.17,454,1437436800"; d="scan'208,217";a="629471499" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 02 Sep 2015 15:47:55 +0000 Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t82FlrB9014920; Wed, 2 Sep 2015 15:47:53 GMT To: "Leroux, Francois" , "supa@ietf.org" References: <55C4D6C1.5040504@cisco.com> <4832DE1A6E651043A4B3EC7A4E5BCF15C81B6D9D@RCHEXMBP1.fnc.net.local> From: Benoit Claise Message-ID: <55E71A27.9050901@cisco.com> Date: Wed, 2 Sep 2015 17:47:51 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <4832DE1A6E651043A4B3EC7A4E5BCF15C81B6D9D@RCHEXMBP1.fnc.net.local> Content-Type: multipart/alternative; boundary="------------020507030800030908030805" Archived-At: Cc: "Eggert, Lars" Subject: Re: [Supa] SUPA charter proposal X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2015 15:48:00 -0000 This is a multi-part message in MIME format. --------------020507030800030908030805 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Francois, > > Benoit, et al, > > Our initial reaction after reading the revised charter was that it was > clear and precise. The objectives are well explained and > understandable even by people who are not familiar with the history of > the group. > > I gathered two immediate comments: > > 1)“-Specific handling of policies (although the application document > will provide some examples), and therefore the specification of a > policy engine that maps a specific policy instance to actual > configuration snippets.” > > The term “configuration snippets” maybe too specific as it is > conceivable that the outcome of a policy evaluation could affect some > behavior in the management and control layer, which may or may not > involve actual NE/NF/vNF level changes (assuming this is what > configuration snippets is referring to). > Do you have a new proposal? > > 2)“The working group will communicate with other SDOs (MEF, TMF, ETSI) > that are working on related issues.” > > The list of SDOs should include ONF or just not mention any specific > ones. “Intent NBI” specifically has become a highly debated topic > within ONF. Please see the attached message suggesting a new > organization aimed at accelerating this work with modeling activities > (possibly similar to SUPA’s) done under the ONF framework group. An > Intent NBI implementation would certainly benefit from a unified > information/data modeling framework aimed at expressing (and possibly > mixing) different types of policy through well defined abstractions. > I'm hesitant to list all the foundatios and open source projects. That list will be incomplete anyway. Regards, Benoit > > Best regards, > > François Leroux > > -- > > Fujitsu Network Communications > > 2801 Telecom Pkwy > > Richardson, TX 75082 > > *From:*Supa [mailto:supa-bounces@ietf.org] *On Behalf Of *Benoit Claise > *Sent:* Friday, August 07, 2015 11:03 AM > *To:* supa@ietf.org > *Cc:* Eggert, Lars > *Subject:* [Supa] SUPA charter proposal > > Dear all, > > As promised in my last email ("SUPA: Situation Summary and Next > Steps"), here is a proposed charter. > Thanks to Robert Sparks, Adrian Farrel, and Dan Romascanu. > > Hopefully, this new version will clarify the situation, and will be > acceptable to everybody. > Please let us know. Note: I prefer to keep the edit token from now. > > Regards, Benoit (OPS AD) > > ============================================================== > > SUPA CHARTER PROPOSAL (2015-08-07) > > Policy is an important configurable component in the delivery of > services and the operation of networks. Operators want and need to be > able to determine the policies that apply to their different customers > and to the equipment that comprises their physical and virtual > networks. As policy spans such a wide range of services and device > types, it will be helpful if there is a common way of expressing and > describing policies that is uniform and consistent in all > environments. Such an approach will help to avoid configuration errors > that arise from confusion between different systems, will enable easy > understanding of policies that apply in different environments, will > make the implementation of policy-based systems quicker and cheaper, > and will facilitate the rapid development of standards-based data > models that include policy elements. > > SUPA (Simplified Use of Policy Abstractions) defines a model to > interface with a network management function (within a controller, an > orchestrator, a network element) that takes high-level, possibly > network-wide policies as input. SUPA will not define what the function > does with that input but anticipates that it will ultimately result in > network configuration changes > > Practically, SUPA will define generic YANG data models to encode > policy, which can point to device-, technology-, and service-specific > YANG models of other working groups. > > SUPA will be designed to work with device, protocol, network, and > service data models. > > The SUPA working group will develop a model for expressing policy at > different levels of abstraction. Specifically, three model fragments > are envisioned: (i) a generic model that defines concepts and > vocabulary needed by policy management independent of the form and > content of the policy, (ii) a more specific model that refines the > generic model to specify how to build policy rules of the > event-condition-action paradigm, and (iii) the working group will > investigate the practically of building policy rules that > declaratively specify what goals to achieve (this is often called > "intent-based" policy) but not how to achieve those goals and may > create a model accordingly. > > If the working group finds it necessary to work on an information > model before the data model, to help provide guidance and derive the > data models, it might do so. The working group will decide later > whether the information model needs to be published as an RFC. > > Out of scope of this working group is: > > -The specification of a new policy language. The YANG data models are > to be used with protocols such as NETCONF/RESTCONF. > > -Design of protocol-specific policies and specific design for embedded > policies in network elements (which are usually interpreted in > isolation, and often at timescales that require optimization for > specific purposes). > > -Specific handling of policies (although the application document will > provide some examples), and therefore the specification of a policy > engine that maps a specific policy instance to actual configuration > snippets. > > List of work items: > > 1) A document that explains the scope of the policy-based management > framework and how it relates to existing work of the IETF. > > 2) If the working group considers it necessary, an information model > composed of policy concepts and vocabulary. > > 3) A set of YANG data models consisting of a base policy model for > representing policy management concepts independent of the type or > structure of a policy, plus an extension for defining policy rules > according to the event-condition-action paradigm. Another extension > for defining policy rules according to a declarative, or intent-based, > paradigm, may be produced. These models will be designed to be generic > and extensible. > > 4) An applicability document providing a few examples that > demonstrate how the generic policy models can be used to express > policies that are relevant for network operators. The examples may tie > into configuration models or network service models developed by other > working groups. > > The working group will decide how the work items are best mapped into > deliverables. > > This working group will be a success when the SUPA policy constructs > are re-used in future IETF specifications (and, ideally, > specifications from other SDOs), in a manner that will save > development time and avoid inconsistencies between data models > developed by different working groups. In the meantime, SUPA should > not impede work in other working groups while waiting for SUPA to > produce its deliverables. > > The working group will communicate with other SDOs (MEF, TMF, ETSI) > that are working on related issues. > > Milestones: TBD > --------------020507030800030908030805 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Francois,

Benoit, et al,

Our initial reaction after reading the revised charter was that it was clear and precise. The objectives are well explained and understandable even by people who are not familiar with the history of the group.

I gathered two immediate comments:

1)       “-   Specific handling of policies (although the application document will provide some examples), and therefore the specification of a policy engine that maps a specific policy instance to actual configuration snippets.”

The term “configuration snippets” maybe too specific as it is conceivable that the outcome of a policy evaluation could affect some behavior in the management and control layer, which may or may not involve actual NE/NF/vNF level changes (assuming this is what configuration snippets is referring to).

Do you have a new proposal?

 

2)      “The working group will communicate with other SDOs (MEF, TMF, ETSI) that are working on related issues.”

The list of SDOs should include ONF or just not mention any specific ones. “Intent NBI” specifically has become a highly debated topic within ONF. Please see the attached message suggesting a new organization aimed at accelerating this work with modeling activities (possibly similar to SUPA’s) done under the ONF framework group. An Intent NBI implementation would certainly benefit from a unified information/data modeling framework aimed at expressing (and possibly mixing) different types of policy through well defined abstractions.

I'm hesitant to list all the foundatios and open source projects. That list will be incomplete anyway.

Regards, Benoit

Best regards,

François Leroux

--

Fujitsu Network Communications

2801 Telecom Pkwy

Richardson, TX 75082

 

From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of Benoit Claise
Sent: Friday, August 07, 2015 11:03 AM
To: supa@ietf.org
Cc: Eggert, Lars
Subject: [Supa] SUPA charter proposal

 

Dear all,

As promised in my last email ("SUPA: Situation Summary and Next Steps"), here is a proposed charter.
Thanks to Robert Sparks, Adrian Farrel, and Dan Romascanu.

Hopefully, this new version will clarify the situation, and will be acceptable to everybody.
Please let us know. Note: I prefer to keep the edit token from now.

Regards, Benoit (OPS AD)

==============================================================

SUPA CHARTER PROPOSAL (2015-08-07)

Policy is an important configurable component in the delivery of services and the operation of networks. Operators want and need to be able to determine the policies that apply to their different customers and to the equipment that comprises their physical and virtual networks. As policy spans such a wide range of services and device types, it will be helpful if there is a common way of expressing and describing policies that is uniform and consistent in all environments. Such an approach will help to avoid configuration errors that arise from confusion between different systems, will enable easy understanding of policies that apply in different environments, will make the implementation of policy-based systems quicker and cheaper, and will facilitate the rapid development of standards-based data models that include policy elements.

 SUPA (Simplified Use of Policy Abstractions) defines a model to interface with a network management function (within a controller, an orchestrator, a network element) that takes high-level, possibly network-wide policies as input. SUPA will not define what the function does with that input but anticipates that it will ultimately result in network configuration changes

Practically, SUPA will define generic YANG data models to encode policy, which can point to device-, technology-, and service-specific YANG models of other working groups.

SUPA will be designed to work with device, protocol, network, and service data models.

The SUPA working group will develop a model for expressing policy at different levels of abstraction.  Specifically, three model fragments are envisioned: (i) a generic model that defines concepts and vocabulary needed by policy management independent of the form and content of the policy, (ii) a more specific model that refines the generic model to specify how to build policy rules of the event-condition-action paradigm, and (iii) the working group will investigate the practically of building policy rules that declaratively specify what goals to achieve (this is often called "intent-based" policy) but not how to achieve those goals and may create a model accordingly.

If the working group finds it necessary to work on an information model before the data model, to help provide guidance and derive the data models, it might do so. The working group will decide later whether the information model needs to be published as an RFC.

Out of scope of this working group is: 

-   The specification of a new policy language. The YANG data models are to be used with protocols such as NETCONF/RESTCONF.

-   Design of protocol-specific policies and specific design for embedded policies in network elements (which are usually interpreted in isolation, and often at timescales that require optimization for specific purposes).

-   Specific handling of policies (although the application document will provide some examples), and therefore the specification of a policy engine that maps a specific policy instance to actual configuration snippets. 

List of work items:

1) A document that explains the scope of the policy-based management framework and how it relates to existing work of the IETF.

2) If the working group considers it necessary, an information model composed of policy concepts and vocabulary.

 3) A set of YANG data models consisting of a base policy model for representing policy management concepts independent of the type or structure of a policy, plus an extension for defining policy rules according to the event-condition-action paradigm. Another extension for defining policy rules according to a declarative, or intent-based, paradigm, may be produced. These models will be designed to be generic and extensible.

 4) An applicability document providing a few examples that demonstrate how the generic policy models can be used to express policies that are relevant for network operators. The examples may tie into configuration models or network service models developed by other working groups.

The working group will decide how the work items are best mapped into deliverables.

This working group will be a success when the SUPA policy constructs are re-used in future IETF specifications (and, ideally, specifications from other SDOs), in a manner that will save development time and avoid inconsistencies between data models developed by different working groups. In the meantime, SUPA should not impede work in other working groups while waiting for SUPA to produce its deliverables.

The working group will communicate with other SDOs (MEF, TMF, ETSI) that are working on related issues.

Milestones: TBD


--------------020507030800030908030805-- From nobody Wed Sep 2 09:13:28 2015 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF1671B4C98 for ; Wed, 2 Sep 2015 09:13:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MHHAzzW8MFzl for ; Wed, 2 Sep 2015 09:13:24 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 092221B4C7E for ; Wed, 2 Sep 2015 09:13:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=33277; q=dns/txt; s=iport; t=1441210404; x=1442420004; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=lZtMJM9ymbJXTYkweq598LZQmKCw8cxrn1goRvYqmnA=; b=XVmOoK3s/+52OYHg+WGG/Vdtk7Hyc4ybQNqAxQeed/R57n7m6SMwDjoF JX8SJrKe9w3gm5YPopImupmOUueSvwREZaYun5fM1NzyGjzWzxpXoeQAa uGGzvBLc5AZsLyzpTBG2jiuWab67A2FbSTeJkJaF8n4u6qPDhO3hoJYrh A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DGBACyHudV/xbLJq1dgk6CCoMjwiICggQBAQEBAQGBC4QjAQEBBCMKSwEQCxEEAQEBCRYBAQYDAgIJAwIBAgE0CQgGAQwGAgEBiCq2cZR6AQEBAQEBAQEBAQEBAQEBAQEBAQEBF4ZzhHuEKBEBJAMYCAoGAYJpgUMBBIctjhyMdoFKhDKCfJF3JoQCPDOBDoE/AQEB X-IronPort-AV: E=Sophos;i="5.17,454,1437436800"; d="scan'208,217";a="606748479" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 02 Sep 2015 16:13:21 +0000 Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t82GDKJs004438; Wed, 2 Sep 2015 16:13:20 GMT To: Maxim Klyus , "supa@ietf.org" References: <55C4D6C1.5040504@cisco.com> <11D8792D50CD7F46BFBA62E9E61D5A3ABB0E70F2@umaildb5.netcracker.com> From: Benoit Claise Message-ID: <55E72020.5030801@cisco.com> Date: Wed, 2 Sep 2015 18:13:20 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <11D8792D50CD7F46BFBA62E9E61D5A3ABB0E70F2@umaildb5.netcracker.com> Content-Type: multipart/alternative; boundary="------------060900080108030203090504" Archived-At: Cc: "Juergen Schoenwaelder \(j.schoenwaelder@jacobs-university.de\)" , "Eggert, Lars" Subject: Re: [Supa] SUPA charter proposal X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2015 16:13:27 -0000 This is a multi-part message in MIME format. --------------060900080108030203090504 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 10/08/2015 14:45, Maxim Klyus wrote: > > Hi Benoit et al, > > I would like to say thank you for the charter clarification. > > Also I agreed with comments provided by Juergen about policy types. > > So my suggestion will be add the following sentences: > > “The SUPA framework defines how to construct policy rules for > Environment and Administrative layers within one or more Management > domains, where Environment layer describes functional configuration > policies for domain network elements (specific protocols, functions) > and Administrative layer describes administrative non-functional > access/management policies across domain network elements (user > privileges, administrative states).“ > Regarding "one or more management domains", it would be best to focus on a single management domain to start with. Assuming that the policy engine resides in a controller, I guess that don't want to deal with inter-controller communication at this point. Wrt to "Environment and Administrative layers", I believe that these are topics for the framework document. Regards, Benoit > > Best Regards, > > Maxim Klyus > > *From:*Supa [mailto:supa-bounces@ietf.org] *On Behalf Of *Benoit Claise > *Sent:* Friday, August 07, 2015 7:03 PM > *To:* supa@ietf.org > *Cc:* Eggert, Lars > *Subject:* [Supa] SUPA charter proposal > > Dear all, > > As promised in my last email ("SUPA: Situation Summary and Next > Steps"), here is a proposed charter. > Thanks to Robert Sparks, Adrian Farrel, and Dan Romascanu. > > Hopefully, this new version will clarify the situation, and will be > acceptable to everybody. > Please let us know. Note: I prefer to keep the edit token from now. > > Regards, Benoit (OPS AD) > > ============================================================== > > SUPA CHARTER PROPOSAL (2015-08-07) > > Policy is an important configurable component in the delivery of > services and the operation of networks. Operators want and need to be > able to determine the policies that apply to their different customers > and to the equipment that comprises their physical and virtual > networks. As policy spans such a wide range of services and device > types, it will be helpful if there is a common way of expressing and > describing policies that is uniform and consistent in all > environments. Such an approach will help to avoid configuration errors > that arise from confusion between different systems, will enable easy > understanding of policies that apply in different environments, will > make the implementation of policy-based systems quicker and cheaper, > and will facilitate the rapid development of standards-based data > models that include policy elements. > > SUPA (Simplified Use of Policy Abstractions) defines a model to > interface with a network management function (within a controller, an > orchestrator, a network element) that takes high-level, possibly > network-wide policies as input. SUPA will not define what the function > does with that input but anticipates that it will ultimately result in > network configuration changes > > Practically, SUPA will define generic YANG data models to encode > policy, which can point to device-, technology-, and service-specific > YANG models of other working groups. > > SUPA will be designed to work with device, protocol, network, and > service data models. > > The SUPA working group will develop a model for expressing policy at > different levels of abstraction. Specifically, three model fragments > are envisioned: (i) a generic model that defines concepts and > vocabulary needed by policy management independent of the form and > content of the policy, (ii) a more specific model that refines the > generic model to specify how to build policy rules of the > event-condition-action paradigm, and (iii) the working group will > investigate the practically of building policy rules that > declaratively specify what goals to achieve (this is often called > "intent-based" policy) but not how to achieve those goals and may > create a model accordingly. > > If the working group finds it necessary to work on an information > model before the data model, to help provide guidance and derive the > data models, it might do so. The working group will decide later > whether the information model needs to be published as an RFC. > > Out of scope of this working group is: > > -The specification of a new policy language. The YANG data models are > to be used with protocols such as NETCONF/RESTCONF. > > -Design of protocol-specific policies and specific design for embedded > policies in network elements (which are usually interpreted in > isolation, and often at timescales that require optimization for > specific purposes). > > -Specific handling of policies (although the application document will > provide some examples), and therefore the specification of a policy > engine that maps a specific policy instance to actual configuration > snippets. > > List of work items: > > 1) A document that explains the scope of the policy-based management > framework and how it relates to existing work of the IETF. > > 2) If the working group considers it necessary, an information model > composed of policy concepts and vocabulary. > > 3) A set of YANG data models consisting of a base policy model for > representing policy management concepts independent of the type or > structure of a policy, plus an extension for defining policy rules > according to the event-condition-action paradigm. Another extension > for defining policy rules according to a declarative, or intent-based, > paradigm, may be produced. These models will be designed to be generic > and extensible. > > 4) An applicability document providing a few examples that demonstrate > how the generic policy models can be used to express policies that are > relevant for network operators. The examples may tie into > configuration models or network service models developed by other > working groups. > > The working group will decide how the work items are best mapped into > deliverables. > > This working group will be a success when the SUPA policy constructs > are re-used in future IETF specifications (and, ideally, > specifications from other SDOs), in a manner that will save > development time and avoid inconsistencies between data models > developed by different working groups. In the meantime, SUPA should > not impede work in other working groups while waiting for SUPA to > produce its deliverables. > > The working group will communicate with other SDOs (MEF, TMF, ETSI) > that are working on related issues. > > Milestones: > > TBD > > ------------------------------------------------------------------------ > The information transmitted herein is intended only for the person or > entity to which it is addressed and may contain confidential, > proprietary and/or privileged material. Any review, retransmission, > dissemination or other use of, or taking of any action in reliance > upon, this information by persons or entities other than the intended > recipient is prohibited. If you received this in error, please contact > the sender and delete the material from any computer. --------------060900080108030203090504 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 10/08/2015 14:45, Maxim Klyus wrote:

Hi Benoit et al,

 

I would like to say thank you for the charter clarification.

 

Also I agreed with comments provided by Juergen about policy types.

 

So my suggestion will be add the following sentences:

 

“The SUPA framework defines how to construct policy rules for Environment and Administrative layers within one or more Management domains, where Environment layer describes functional configuration policies for domain network elements (specific protocols, functions) and Administrative layer describes administrative non-functional access/management policies across domain network elements (user privileges, administrative states).“

Regarding "one or more management domains", it would be best to focus on a single management domain to start with.
Assuming that the policy engine resides in a controller, I guess that don't want to deal with inter-controller communication at this point.

Wrt to "Environment and Administrative layers", I believe that these are topics for the framework document.

Regards, Benoit

 

 

Best Regards,

Maxim Klyus

 

From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of Benoit Claise
Sent: Friday, August 07, 2015 7:03 PM
To: supa@ietf.org
Cc: Eggert, Lars
Subject: [Supa] SUPA charter proposal

 

Dear all,

As promised in my last email ("SUPA: Situation Summary and Next Steps"), here is a proposed charter.
Thanks to Robert Sparks, Adrian Farrel, and Dan Romascanu.

Hopefully, this new version will clarify the situation, and will be acceptable to everybody.
Please let us know. Note: I prefer to keep the edit token from now.

Regards, Benoit (OPS AD)

==============================================================

SUPA CHARTER PROPOSAL (2015-08-07)

 

Policy is an important configurable component in the delivery of services and the operation of networks. Operators want and need to be able to determine the policies that apply to their different customers and to the equipment that comprises their physical and virtual networks. As policy spans such a wide range of services and device types, it will be helpful if there is a common way of expressing and describing policies that is uniform and consistent in all environments. Such an approach will help to avoid configuration errors that arise from confusion between different systems, will enable easy understanding of policies that apply in different environments, will make the implementation of policy-based systems quicker and cheaper, and will facilitate the rapid development of standards-based data models that include policy elements.

 

 

SUPA (Simplified Use of Policy Abstractions) defines a model to interface with a network management function (within a controller, an orchestrator, a network element) that takes high-level, possibly network-wide policies as input. SUPA will not define what the function does with that input but anticipates that it will ultimately result in network configuration changes

 

 

Practically, SUPA will define generic YANG data models to encode policy, which can point to device-, technology-, and service-specific YANG models of other working groups.

 

SUPA will be designed to work with device, protocol, network, and service data models.

 

The SUPA working group will develop a model for expressing policy at different levels of abstraction.  Specifically, three model fragments are envisioned: (i) a generic model that defines concepts and vocabulary needed by policy management independent of the form and content of the policy, (ii) a more specific model that refines the generic model to specify how to build policy rules of the event-condition-action paradigm, and (iii) the working group will investigate the practically of building policy rules that declaratively specify what goals to achieve (this is often called "intent-based" policy) but not how to achieve those goals and may create a model accordingly.

 

If the working group finds it necessary to work on an information model before the data model, to help provide guidance and derive the data models, it might do so. The working group will decide later whether the information model needs to be published as an RFC.

 

Out of scope of this working group is:  

-   The specification of a new policy language. The YANG data models are to be used with protocols such as NETCONF/RESTCONF.

-   Design of protocol-specific policies and specific design for embedded policies in network elements (which are usually interpreted in isolation, and often at timescales that require optimization for specific purposes).

-   Specific handling of policies (although the application document will provide some examples), and therefore the specification of a policy engine that maps a specific policy instance to actual configuration snippets.

 

List of work items:

 

1) A document that explains the scope of the policy-based management framework and how it relates to existing work of the IETF.

 

2) If the working group considers it necessary, an information model composed of policy concepts and vocabulary.

 

3) A set of YANG data models consisting of a base policy model for representing policy management concepts independent of the type or structure of a policy, plus an extension for defining policy rules according to the event-condition-action paradigm. Another extension for defining policy rules according to a declarative, or intent-based, paradigm, may be produced. These models will be designed to be generic and extensible.

 

4) An applicability document providing a few examples that demonstrate how the generic policy models can be used to express policies that are relevant for network operators. The examples may tie into configuration models or network service models developed by other working groups.

 

The working group will decide how the work items are best mapped into deliverables.

 

This working group will be a success when the SUPA policy constructs are re-used in future IETF specifications (and, ideally, specifications from other SDOs), in a manner that will save development time and avoid inconsistencies between data models developed by different working groups. In the meantime, SUPA should not impede work in other working groups while waiting for SUPA to produce its deliverables.

 

The working group will communicate with other SDOs (MEF, TMF, ETSI) that are working on related issues.

 

Milestones:

 

TBD

 

 

The information transmitted herein is intended only for the person or entity to which it is addressed and may contain confidential, proprietary and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.  

--------------060900080108030203090504-- From nobody Wed Sep 2 09:31:59 2015 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFE9B1A1AB8 for ; Wed, 2 Sep 2015 09:31:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GXVWjqJ7lvhd for ; Wed, 2 Sep 2015 09:31:55 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40D591B42B8 for ; Wed, 2 Sep 2015 09:31:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=26612; q=dns/txt; s=iport; t=1441211505; x=1442421105; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=vrAYXIEOUhouvN3zXOQd0Xn97p9iVeBOL0Cijqgm91I=; b=gT5jNiDuWSGMBOzvlBT2S4hvMDsmY43xYJFFnTQkBitOr15MhHpEQ2EV Z9rrdFnSOzLZyaQbvzCBHG+BZADpcjjwed4gJ1iQw+sEwq0g378u/WZbD v3TesUKDq/jiGH2+CLBo9x/8FFZMR/vFkHe6VuODW8mI9kF0AZk8CLfBn 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CcBAA8IudV/xbLJq1dDoJAggrFRQKCBAEBAQEBAYELhCMBAQEEdAQBEAsRBAEBChYBDgkDAgECAT0IBgEMBgIBAYgqzAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEXhnOEe4QoEQE/CAoHhCwBBIctjhyMdoFKhDKCfIlCiDUmg0JAPDOBDoE/AQEB X-IronPort-AV: E=Sophos;i="5.17,454,1437436800"; d="scan'208,217";a="606748799" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 02 Sep 2015 16:31:25 +0000 Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t82GVNbp022945; Wed, 2 Sep 2015 16:31:24 GMT To: Xiaohong Deng , "supa@ietf.org" References: <55C4D6C1.5040504@cisco.com> <36ADAEDEF1F28546BC414651D641DDAB0EDB2B00@INFPWXM010.ad.unsw.edu.au> From: Benoit Claise Message-ID: <55E7245B.3030500@cisco.com> Date: Wed, 2 Sep 2015 18:31:23 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <36ADAEDEF1F28546BC414651D641DDAB0EDB2B00@INFPWXM010.ad.unsw.edu.au> Content-Type: multipart/alternative; boundary="------------050400020709050709030308" Archived-At: Cc: "Eggert, Lars" Subject: Re: [Supa] SUPA charter proposal X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2015 16:31:58 -0000 This is a multi-part message in MIME format. --------------050400020709050709030308 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hi Xiaohong, As I just replied in a different email: the first focus should be on a single management domain in this charter. If successful, nothing prevent a charter update. Regards, Benoit > Dear Benoit and all, > > Thanks for all the efforts putting together this chapter. I see this > is a fine start of providing an appropriate place to address policy > issues in IETF. > > My understanding is that the current chapter doesn't differentiate > between inter-domain and cross-domain. Please correct me if I'm wrong. > Though it may be too early to point out and may not necessary to > address that in the chapter at this stage, from our past experience in > SDN, cross-domain scenario does have different use cases than > inter-domain. And I am personally keen to see cross-domain framework > to be addressed. Thoughts? > > Cheers, > Xiaohong > > School of Electric Engineering and Telecom, > University of New South Wales, Australia > > ------------------------------------------------------------------------ > *From:* Supa [supa-bounces@ietf.org] on behalf of Benoit Claise > [bclaise@cisco.com] > *Sent:* 08 August 2015 02:03 > *To:* supa@ietf.org > *Cc:* Eggert, Lars > *Subject:* [Supa] SUPA charter proposal > > Dear all, > > As promised in my last email ("SUPA: Situation Summary and Next > Steps"), here is a proposed charter. > Thanks to Robert Sparks, Adrian Farrel, and Dan Romascanu. > > Hopefully, this new version will clarify the situation, and will be > acceptable to everybody. > Please let us know. Note: I prefer to keep the edit token from now. > > Regards, Benoit (OPS AD) > > ============================================================== > > SUPA CHARTER PROPOSAL (2015-08-07) > > Policy is an important configurable component in the delivery of > services and the operation of networks. Operators want and need to be > able to determine the policies that apply to their different customers > and to the equipment that comprises their physical and virtual > networks. As policy spans such a wide range of services and device > types, it will be helpful if there is a common way of expressing and > describing policies that is uniform and consistent in all > environments. Such an approach will help to avoid configuration errors > that arise from confusion between different systems, will enable easy > understanding of policies that apply in different environments, will > make the implementation of policy-based systems quicker and cheaper, > and will facilitate the rapid development of standards-based data > models that include policy elements. > > SUPA (Simplified Use of Policy Abstractions) defines a model to > interface with a network management function (within a controller, an > orchestrator, a network element) that takes high-level, possibly > network-wide policies as input. SUPA will not define what the function > does with that input but anticipates that it will ultimately result in > network configuration changes > > Practically, SUPA will define generic YANG data models to encode > policy, which can point to device-, technology-, and service-specific > YANG models of other working groups. > > SUPA will be designed to work with device, protocol, network, and > service data models. > > The SUPA working group will develop a model for expressing policy at > different levels of abstraction.Specifically, three model fragments > are envisioned: (i) a generic model that defines concepts and > vocabulary needed by policy management independent of the form and > content of the policy, (ii) a more specific model that refines the > generic model to specify how to build policy rules of the > event-condition-action paradigm, and (iii) the working group will > investigate the practically of building policy rules that > declaratively specify what goals to achieve (this is often called > "intent-based" policy) but not how to achieve those goals and may > create a model accordingly. > > If the working group finds it necessary to work on an information > model before the data model, to help provide guidance and derive the > data models, it might do so. The working group will decide later > whether the information model needs to be published as an RFC. > > Out of scope of this working group is: > > -The specification of a new policy language. The YANG data models are > to be used with protocols such as NETCONF/RESTCONF. > > -Design of protocol-specific policies and specific design for embedded > policies in network elements (which are usually interpreted in > isolation, and often at timescales that require optimization for > specific purposes). > > -Specific handling of policies (although the application document will > provide some examples), and therefore the specification of a policy > engine that maps a specific policy instance to actual configuration > snippets. > > List of work items: > > 1) A document that explains the scope of the policy-based management > framework and how it relates to existing work of the IETF. > > 2) If the working group considers it necessary, an information model > composed of policy concepts and vocabulary. > > 3) A set of YANG data models consisting of a base policy model for > representing policy management concepts independent of the type or > structure of a policy, plus an extension for defining policy rules > according to the event-condition-action paradigm. Another extension > for defining policy rules according to a declarative, or intent-based, > paradigm, may be produced. These models will be designed to be generic > and extensible. > > 4) An applicability document providing a few examples that demonstrate > how the generic policy models can be used to express policies that are > relevant for network operators. The examples may tie into > configuration models or network service models developed by other > working groups. > > The working group will decide how the work items are best mapped into > deliverables. > > This working group will be a success when the SUPA policy constructs > are re-used in future IETF specifications (and, ideally, > specifications from other SDOs), in a manner that will save > development time and avoid inconsistencies between data models > developed by different working groups. In the meantime, SUPA should > not impede work in other working groups while waiting for SUPA to > produce its deliverables. > > The working group will communicate with other SDOs (MEF, TMF, ETSI) > that are working on related issues. > > Milestones: > > TBD > > --------------050400020709050709030308 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Hi Xiaohong,

As I just replied in a different email: the first focus should be on a single management domain in this charter. If successful, nothing prevent a charter update.

Regards, Benoit
Dear Benoit and all,

Thanks for all the efforts putting together this chapter. I see this is a fine start of providing an appropriate place to address policy issues in IETF. 

My understanding is that the current chapter doesn't differentiate between inter-domain and cross-domain. Please correct me if I'm wrong. Though it may be too early to point out and may not necessary to address that in the chapter at this stage, from our past experience in SDN, cross-domain scenario does have different use cases than inter-domain. And I am personally keen to see cross-domain framework to be addressed. Thoughts?

Cheers,
Xiaohong

School of Electric Engineering and Telecom,
University of New South Wales, Australia

From: Supa [supa-bounces@ietf.org] on behalf of Benoit Claise [bclaise@cisco.com]
Sent: 08 August 2015 02:03
To: supa@ietf.org
Cc: Eggert, Lars
Subject: [Supa] SUPA charter proposal

Dear all,

As promised in my last email ("SUPA: Situation Summary and Next Steps"), here is a proposed charter.
Thanks to Robert Sparks, Adrian Farrel, and Dan Romascanu.

Hopefully, this new version will clarify the situation, and will be acceptable to everybody.
Please let us know. Note: I prefer to keep the edit token from now.

Regards, Benoit (OPS AD)

==============================================================

SUPA CHARTER PROPOSAL (2015-08-07)

 

Policy is an important configurable component in the delivery of services and the operation of networks. Operators want and need to be able to determine the policies that apply to their different customers and to the equipment that comprises their physical and virtual networks. As policy spans such a wide range of services and device types, it will be helpful if there is a common way of expressing and describing policies that is uniform and consistent in all environments. Such an approach will help to avoid configuration errors that arise from confusion between different systems, will enable easy understanding of policies that apply in different environments, will make the implementation of policy-based systems quicker and cheaper, and will facilitate the rapid development of standards-based data models that include policy elements.

 

 

SUPA (Simplified Use of Policy Abstractions) defines a model to interface with a network management function (within a controller, an orchestrator, a network element) that takes high-level, possibly network-wide policies as input. SUPA will not define what the function does with that input but anticipates that it will ultimately result in network configuration changes

 

 

Practically, SUPA will define generic YANG data models to encode policy, which can point to device-, technology-, and service-specific YANG models of other working groups.

 

SUPA will be designed to work with device, protocol, network, and service data models.

 

The SUPA working group will develop a model for expressing policy at different levels of abstraction.  Specifically, three model fragments are envisioned: (i) a generic model that defines concepts and vocabulary needed by policy management independent of the form and content of the policy, (ii) a more specific model that refines the generic model to specify how to build policy rules of the event-condition-action paradigm, and (iii) the working group will investigate the practically of building policy rules that declaratively specify what goals to achieve (this is often called "intent-based" policy) but not how to achieve those goals and may create a model accordingly.

 

If the working group finds it necessary to work on an information model before the data model, to help provide guidance and derive the data models, it might do so. The working group will decide later whether the information model needs to be published as an RFC.

 

Out of scope of this working group is:  

-   The specification of a new policy language. The YANG data models are to be used with protocols such as NETCONF/RESTCONF.

-   Design of protocol-specific policies and specific design for embedded policies in network elements (which are usually interpreted in isolation, and often at timescales that require optimization for specific purposes).

-   Specific handling of policies (although the application document will provide some examples), and therefore the specification of a policy engine that maps a specific policy instance to actual configuration snippets.

 

List of work items:

 

1) A document that explains the scope of the policy-based management framework and how it relates to existing work of the IETF.

 

2) If the working group considers it necessary, an information model composed of policy concepts and vocabulary.

 

3) A set of YANG data models consisting of a base policy model for representing policy management concepts independent of the type or structure of a policy, plus an extension for defining policy rules according to the event-condition-action paradigm. Another extension for defining policy rules according to a declarative, or intent-based, paradigm, may be produced. These models will be designed to be generic and extensible.

 

4) An applicability document providing a few examples that demonstrate how the generic policy models can be used to express policies that are relevant for network operators. The examples may tie into configuration models or network service models developed by other working groups.

 

The working group will decide how the work items are best mapped into deliverables.

 

This working group will be a success when the SUPA policy constructs are re-used in future IETF specifications (and, ideally, specifications from other SDOs), in a manner that will save development time and avoid inconsistencies between data models developed by different working groups. In the meantime, SUPA should not impede work in other working groups while waiting for SUPA to produce its deliverables.

 

The working group will communicate with other SDOs (MEF, TMF, ETSI) that are working on related issues.

 

Milestones:

 

TBD



--------------050400020709050709030308-- From nobody Wed Sep 2 12:23:49 2015 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 341AA1B2C42 for ; Wed, 2 Sep 2015 12:23:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IGRVfRrECEq1 for ; Wed, 2 Sep 2015 12:23:45 -0700 (PDT) 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 6DE561B29AB for ; Wed, 2 Sep 2015 12:23:44 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id EE90A171B; Wed, 2 Sep 2015 21:23:42 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id Ii_CuwGM9o4J; Wed, 2 Sep 2015 21:23:41 +0200 (CEST) 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; Wed, 2 Sep 2015 21:23:41 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 77DFD20048; Wed, 2 Sep 2015 21:23:41 +0200 (CEST) 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 Z6N1RISQvpRa; Wed, 2 Sep 2015 21:23:39 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6869D2004E; Wed, 2 Sep 2015 21:23:38 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 1AA6436F4474; Wed, 2 Sep 2015 21:23:35 +0200 (CEST) Date: Wed, 2 Sep 2015 21:23:35 +0200 From: Juergen Schoenwaelder To: Benoit Claise Message-ID: <20150902192335.GB28223@elstar.local> Mail-Followup-To: Benoit Claise , Andy Bierman , "Scharf, Michael (Michael)" , John Strassner , "Romascanu, Dan (Dan)" , "Eggert, Lars" , Adrian Farrel , "supa@ietf.org" References: <9904FB1B0159DA42B0B887B7FA8119CA5CAF26F9@AZ-FFEXMB04.global.avaya.com> <20150809205503.GB15079@elstar.local> <655C07320163294895BBADA28372AF5D4845EBEC@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20150813200304.GA23279@elstar.local> <655C07320163294895BBADA28372AF5D4845F647@FR712WXCHMBA15.zeu.alcatel-lucent.com> <655C07320163294895BBADA28372AF5D48461F68@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20150815202231.GA61946@elstar.local> <55E70078.80507@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55E70078.80507@cisco.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "Scharf, Michael \(Michael\)" , Andy Bierman , John Strassner , "Romascanu, Dan \(Dan\)" , "Eggert, Lars" , Adrian Farrel , "supa@ietf.org" Subject: Re: [Supa] SUPA charter proposal X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2015 19:23:48 -0000 I believe that exposing expressions as collections of operators and operands that are all separate YANG objects is the wrong level of abstraction. We use xpath in YANG must/when expressions and in NETCONF (see the :xpath capability) for filtering purposes. It feels odd to go back to an assembly language like notation for policy conditions and event expression. Personally, I think that policy actions should support basic primitives working on YANG configuration models, such as insert an entry in list a if it is not yet present, remove all entries from list b that match a certain expression, etc. This is what I always had in mind when I used the term 'generic policy model' - namely a mechanism that can evaluate event and candition expressions on arbitrary YANG data models and that can make modifications on arbitrary YANG configuration data models. /js On Wed, Sep 02, 2015 at 03:58:16PM +0200, Benoit Claise wrote: > Juergen, > > So you wants a SIEVE-like language for policies? > Not sure I understood that from the BoF. > > Regards, Benoit > >On Sat, Aug 15, 2015 at 10:09:32AM -0700, Andy Bierman wrote: > >>I prefer a solution where the smarts are provided by the client, > >>not built into the policy engine. > >+1 > > > >>Programming in YANG is a non-starter, > >>but programming in a scripting language that is very YANG-aware is quite > >>the opposite. > >> > >> event: leverage pub/sub work in NETCONF WG > >> condition: scripts, using event data and framework to access topology > >> and > >>NE data > >> action: scripts, using some framework to access topology and NE data > >> > >>It is hard to standardize a script language, so not sure how this will > >>happen. > >There are examples in the IETF, like for instance the SIEVE mail > >filtering language: > > > >https://en.wikipedia.org/wiki/Sieve_%28mail_filtering_language%29 > > > >Unfortunately, Benoit's proposed charter seems to rule out solutions > >where the power is in scriptable events / conditions / actions. So, > >the alternatives that are in Benoit's proposed charter are we either > >do something that > > > >(a) requires domain specific data models for every type of policy > > (unlikely to be implemented if you ask me) or something that > > > >(b) exposes even simple boolean expressions as complex collections of > > YANG objects (leading to something way too complex to be used for > > anything more serious than hello world examples), or > > > >(c) we will define a policy framework that essentially only works with > > strings that mean something to black boxes that interpret them in > > whatever way they like best (which is unlikely to be > > interoperable). > > > >Going back to the 'disable SNMP on all edge routers' example, I would > >assume that a solution has an action that essentially instantiates ACL > >entries according to the YANG ACL configuration data model. The > >knowledge of which ports need to be blocked is encoded in the config > >snippet embodied in the action. The condition needs to hook into the > >topology data model and extract all routers that are edge routers. > >This ideally boils down to filtering on some tags in the topology > >model. The events that trigger the rule would essentially be any > >changes to the IP topology layer (e.g., when edge routers are added or > >removed) and it might in addition be periodic. With scriptable > >events/conditions/actions, I can see how I could do all this with > >meaningful complexity. But as said above, unfortunately Benoit's > >proposed charter rules this option out. So the proponents of the other > >approaches need to explain how they are going to implement a simple > >policy like 'disable SNMP on all edge routers'. > > > >/js > > > > _______________________________________________ > 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 Wed Sep 2 13:57:38 2015 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1FFF1B505D for ; Wed, 2 Sep 2015 13:57:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vtJKRyF0RXl7 for ; Wed, 2 Sep 2015 13:57:33 -0700 (PDT) Received: from mail-lb0-f173.google.com (mail-lb0-f173.google.com [209.85.217.173]) (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 19A981B4FB7 for ; Wed, 2 Sep 2015 13:57:33 -0700 (PDT) Received: by lbbmp1 with SMTP id mp1so13542102lbb.1 for ; Wed, 02 Sep 2015 13:57:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=RVoaBGPbNO1A1ebt7lInNMgZqPxl+RdT0FL2HWam0jE=; b=es4uvBRYHWmfI1Yj+T11RsU5fVUQ+7/WEddEyN/tSi0iB2Kaf5tU/tQgFUuFhkQi0K OvNTZc4pTImGarQloDRfQI6RjX0dgl3eNJGnBQno8qkhcmUB6BR3r133Z68TMAsh4aIG LbYK1TEbdQdrfDvDblQMDXpZhDpLLjtfw8OzM20aZJlCFsu+nzEv+q/+BWQocMZcxlNp UC+4YDqaKEDxtpgKEgIly3lFI+hL8OVkP30YGE4xc678YAS9li4Bbkxr/ROX+eM26WHS VbZ8F0kc2aknMQW/GnjcLNa56sr5qI8fD2kMIa1oE6NiT195YqH/dxTRsVgxjD2mVucy BAnQ== X-Gm-Message-State: ALoCoQk8FJUVxyqyGRXKf0q7QURDnJmK49CDxi4VgOHbMKTafuBAI0SlTky+ESsR75HNU+FW4RDJ MIME-Version: 1.0 X-Received: by 10.152.120.74 with SMTP id la10mr17500793lab.37.1441227451025; Wed, 02 Sep 2015 13:57:31 -0700 (PDT) Received: by 10.112.200.104 with HTTP; Wed, 2 Sep 2015 13:57:30 -0700 (PDT) In-Reply-To: <20150902192335.GB28223@elstar.local> References: <9904FB1B0159DA42B0B887B7FA8119CA5CAF26F9@AZ-FFEXMB04.global.avaya.com> <20150809205503.GB15079@elstar.local> <655C07320163294895BBADA28372AF5D4845EBEC@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20150813200304.GA23279@elstar.local> <655C07320163294895BBADA28372AF5D4845F647@FR712WXCHMBA15.zeu.alcatel-lucent.com> <655C07320163294895BBADA28372AF5D48461F68@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20150815202231.GA61946@elstar.local> <55E70078.80507@cisco.com> <20150902192335.GB28223@elstar.local> Date: Wed, 2 Sep 2015 13:57:30 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Benoit Claise , Andy Bierman , "Scharf, Michael (Michael)" , John Strassner , "Romascanu, Dan (Dan)" , "Eggert, Lars" , Adrian Farrel , "supa@ietf.org" Content-Type: multipart/alternative; boundary=089e01229022425b6f051ec9ea66 Archived-At: Subject: Re: [Supa] SUPA charter proposal X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2015 20:57:36 -0000 --089e01229022425b6f051ec9ea66 Content-Type: text/plain; charset=UTF-8 On Wed, Sep 2, 2015 at 12:23 PM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > I believe that exposing expressions as collections of operators and > operands that are all separate YANG objects is the wrong level of > abstraction. We use xpath in YANG must/when expressions and in NETCONF > (see the :xpath capability) for filtering purposes. It feels odd to go > back to an assembly language like notation for policy conditions and > event expression. > > +1 I brought up the issue that the charter text could apply to either approach. IMO a leaf containing an XPath expression is far better than a leaf for every token in the XPath expression. It is also better to use an existing standard rather than invent yet another regular expression syntax. > Personally, I think that policy actions should support basic > primitives working on YANG configuration models, such as insert an > entry in list a if it is not yet present, remove all entries from list > b that match a certain expression, etc. This is what I always had in > mind when I used the term 'generic policy model' - namely a mechanism > that can evaluate event and candition expressions on arbitrary YANG > data models and that can make modifications on arbitrary YANG > configuration data models. > I don't think the "action" scripts can be YANG data nodes. The complexity here could vary greatly (e.g. 1-shot, or req. and need to examine response, or multiple req./resp. pairs with if/then/else branching) The problem is that boiling the ocean is no good and some trivial solution that is just a toy is no good. A completely prorietary "action" solution is also no good. I am really skeptical the IETF can deliver the 'A' in ECA. > /js > Andy > > On Wed, Sep 02, 2015 at 03:58:16PM +0200, Benoit Claise wrote: > > Juergen, > > > > So you wants a SIEVE-like language for policies? > > Not sure I understood that from the BoF. > > > > Regards, Benoit > > >On Sat, Aug 15, 2015 at 10:09:32AM -0700, Andy Bierman wrote: > > >>I prefer a solution where the smarts are provided by the client, > > >>not built into the policy engine. > > >+1 > > > > > >>Programming in YANG is a non-starter, > > >>but programming in a scripting language that is very YANG-aware is > quite > > >>the opposite. > > >> > > >> event: leverage pub/sub work in NETCONF WG > > >> condition: scripts, using event data and framework to access > topology > > >> and > > >>NE data > > >> action: scripts, using some framework to access topology and NE data > > >> > > >>It is hard to standardize a script language, so not sure how this will > > >>happen. > > >There are examples in the IETF, like for instance the SIEVE mail > > >filtering language: > > > > > >https://en.wikipedia.org/wiki/Sieve_%28mail_filtering_language%29 > > > > > >Unfortunately, Benoit's proposed charter seems to rule out solutions > > >where the power is in scriptable events / conditions / actions. So, > > >the alternatives that are in Benoit's proposed charter are we either > > >do something that > > > > > >(a) requires domain specific data models for every type of policy > > > (unlikely to be implemented if you ask me) or something that > > > > > >(b) exposes even simple boolean expressions as complex collections of > > > YANG objects (leading to something way too complex to be used for > > > anything more serious than hello world examples), or > > > > > >(c) we will define a policy framework that essentially only works with > > > strings that mean something to black boxes that interpret them in > > > whatever way they like best (which is unlikely to be > > > interoperable). > > > > > >Going back to the 'disable SNMP on all edge routers' example, I would > > >assume that a solution has an action that essentially instantiates ACL > > >entries according to the YANG ACL configuration data model. The > > >knowledge of which ports need to be blocked is encoded in the config > > >snippet embodied in the action. The condition needs to hook into the > > >topology data model and extract all routers that are edge routers. > > >This ideally boils down to filtering on some tags in the topology > > >model. The events that trigger the rule would essentially be any > > >changes to the IP topology layer (e.g., when edge routers are added or > > >removed) and it might in addition be periodic. With scriptable > > >events/conditions/actions, I can see how I could do all this with > > >meaningful complexity. But as said above, unfortunately Benoit's > > >proposed charter rules this option out. So the proponents of the other > > >approaches need to explain how they are going to implement a simple > > >policy like 'disable SNMP on all edge routers'. > > > > > >/js > > > > > > > _______________________________________________ > > 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 > --089e01229022425b6f051ec9ea66 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Sep 2, 2015 at 12:23 PM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
I believe that exposing expressions as collections o= f operators and
operands that are all separate YANG objects is the wrong level of
abstraction. We use xpath in YANG must/when expressions and in NETCONF
(see the :xpath capability) for filtering purposes. It feels odd to go
back to an assembly language like notation for policy conditions and
event expression.


+1

I brought = up the issue that the charter text could apply to either approach.
IMO a leaf containing an XPath expression is far better than
a = leaf for every token in the XPath expression.=C2=A0 It is also better to
use an existing standard rather than invent yet another regular exp= ression syntax.


=C2=A0
Personally, I think that policy actions should support basic
primitives working on YANG configuration models, such as insert an
entry in list a if it is not yet present, remove all entries from list
b that match a certain expression, etc. This is what I always had in
mind when I used the term 'generic policy model' - namely a mechani= sm
that can evaluate event and candition expressions on arbitrary YANG
data models and that can make modifications on arbitrary YANG
configuration data models.


I don't think the "action" scripts can be YANG data nodes.=
The complexity here could vary greatly (e.g. 1-shot, or
req. and need to examine response, or multiple req./resp. pairs
with if/then/else branching)

The problem is that = boiling the ocean is no good and some trivial
solution that is ju= st a toy is no good.=C2=A0 A completely prorietary
"action&q= uot; solution is also no good. I am really skeptical the IETF
can= deliver the 'A' in ECA.



/js

Andy
=C2=A0

On Wed, Sep 02, 2015 at 03:58:16PM +0200, Benoit Claise wrote:
> Juergen,
>
> So you wants a SIEVE-like language for policies?
> Not sure I understood that from the BoF.
>
> Regards, Benoit
> >On Sat, Aug 15, 2015 at 10:09:32AM -0700, Andy Bierman wrote:
> >>I prefer a solution where the smarts are provided by the clien= t,
> >>not built into the policy engine.
> >+1
> >
> >>Programming in YANG is a non-starter,
> >>but programming in a scripting language that is very YANG-awar= e is quite
> >>the opposite.
> >>
> >>=C2=A0 =C2=A0event: leverage pub/sub work in NETCONF WG
> >>=C2=A0 =C2=A0condition: scripts, using event data and framewor= k to access topology
> >>=C2=A0 =C2=A0and
> >>NE data
> >>=C2=A0 =C2=A0action: scripts, using some framework to access t= opology and NE data
> >>
> >>It is hard to standardize a script language, so not sure how t= his will
> >>happen.
> >There are examples in the IETF, like for instance the SIEVE mail > >filtering language:
> >
> >https://en.wikipedia.org/w= iki/Sieve_%28mail_filtering_language%29
> >
> >Unfortunately, Benoit's proposed charter seems to rule out sol= utions
> >where the power is in scriptable events / conditions / actions.=C2= =A0 So,
> >the alternatives that are in Benoit's proposed charter are we = either
> >do something that
> >
> >(a) requires domain specific data models for every type of policy<= br> > >=C2=A0 =C2=A0 =C2=A0(unlikely to be implemented if you ask me) or = something that
> >
> >(b) exposes even simple boolean expressions as complex collections= of
> >=C2=A0 =C2=A0 =C2=A0YANG objects (leading to something way too com= plex to be used for
> >=C2=A0 =C2=A0 =C2=A0anything more serious than hello world example= s), or
> >
> >(c) we will define a policy framework that essentially only works = with
> >=C2=A0 =C2=A0 =C2=A0strings that mean something to black boxes tha= t interpret them in
> >=C2=A0 =C2=A0 =C2=A0whatever way they like best (which is unlikely= to be
> >=C2=A0 =C2=A0 =C2=A0interoperable).
> >
> >Going back to the 'disable SNMP on all edge routers' examp= le, I would
> >assume that a solution has an action that essentially instantiates= ACL
> >entries according to the YANG ACL configuration data model. The > >knowledge of which ports need to be blocked is encoded in the conf= ig
> >snippet embodied in the action. The condition needs to hook into t= he
> >topology data model and extract all routers that are edge routers.=
> >This ideally boils down to filtering on some tags in the topology<= br> > >model. The events that trigger the rule would essentially be any > >changes to the IP topology layer (e.g., when edge routers are adde= d or
> >removed) and it might in addition be periodic. With scriptable
> >events/conditions/actions, I can see how I could do all this with<= br> > >meaningful complexity. But as said above, unfortunately Benoit'= ;s
> >proposed charter rules this option out. So the proponents of the o= ther
> >approaches need to explain how they are going to implement a simpl= e
> >policy like 'disable SNMP on all edge routers'.
> >
> >/js
> >
>
> _______________________________________________
> Supa mailing list
> Supa@ietf.org
> https://www.ietf.org/mailman/listinfo/supa

--
Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer= sity Bremen gGmbH
Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28= 759 Bremen | Germany
Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<http://www.jacobs-university.de/>

--089e01229022425b6f051ec9ea66-- From nobody Wed Sep 2 22:20:39 2015 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F00B1A6F80 for ; Wed, 2 Sep 2015 22:20:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PSTilkaLSI01 for ; Wed, 2 Sep 2015 22:20:35 -0700 (PDT) Received: from umail.netcracker.com (umail.netcracker.com [84.47.142.180]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7F331B2B19 for ; Wed, 2 Sep 2015 22:20:33 -0700 (PDT) From: Maxim Klyus To: Benoit Claise , "supa@ietf.org" Thread-Topic: [Supa] SUPA charter proposal Thread-Index: AQHQ0Sqtq68f6llmDkmz6MLeXzYKRJ4FATUggCRevACAAQcStQ== Date: Thu, 3 Sep 2015 05:20:30 +0000 Message-ID: <11D8792D50CD7F46BFBA62E9E61D5A3AD80A164E@umaildb4.netcracker.com> References: <55C4D6C1.5040504@cisco.com> <11D8792D50CD7F46BFBA62E9E61D5A3ABB0E70F2@umaildb5.netcracker.com>, <55E72020.5030801@cisco.com> In-Reply-To: <55E72020.5030801@cisco.com> Accept-Language: en-US, ru-RU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_11D8792D50CD7F46BFBA62E9E61D5A3AD80A164Eumaildb4netcrac_" MIME-Version: 1.0 Archived-At: Cc: "Juergen Schoenwaelder \(j.schoenwaelder@jacobs-university.de\)" , "Eggert, Lars" Subject: Re: [Supa] SUPA charter proposal X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2015 05:20:38 -0000 --_000_11D8792D50CD7F46BFBA62E9E61D5A3AD80A164Eumaildb4netcrac_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Benoit, my comments inline. ________________________________ From: Benoit Claise [bclaise@cisco.com] Sent: Wednesday, September 02, 2015 7:13 PM To: Maxim Klyus; supa@ietf.org Cc: Eggert, Lars; Juergen Schoenwaelder (j.schoenwaelder@jacobs-university.= de) Subject: Re: [Supa] SUPA charter proposal On 10/08/2015 14:45, Maxim Klyus wrote: Hi Benoit et al, I would like to say thank you for the charter clarification. Also I agreed with comments provided by Juergen about policy types. So my suggestion will be add the following sentences: =93The SUPA framework defines how to construct policy rules for Environment= and Administrative layers within one or more Management domains, where Env= ironment layer describes functional configuration policies for domain netwo= rk elements (specific protocols, functions) and Administrative layer descri= bes administrative non-functional access/management policies across domain = network elements (user privileges, administrative states).=93 [Benoit] Regarding "one or more management domains", it would be best to fo= cus on a single management domain to start with. [Benoit] Assuming that the policy engine resides in a controller, I guess t= hat don't want to deal with inter-controller communication at this point. [MK] In my understanding the one of the key moments - policy could be used = for inter-domain exchange and this is a great value for the end-to-end serv= ice management. Many SDOs already defined - controllers can ogranize hierar= chy for management and administrative purpose, so I don't see any contradic= tion here. [Benoit] Wrt to "Environment and Administrative layers", I believe that the= se are topics for the framework document. [MK] Ok. Regards, Benoit Best Regards, Maxim Klyus From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of Benoit Claise Sent: Friday, August 07, 2015 7:03 PM To: supa@ietf.org Cc: Eggert, Lars Subject: [Supa] SUPA charter proposal Dear all, As promised in my last email ("SUPA: Situation Summary and Next Steps"), he= re is a proposed charter. Thanks to Robert Sparks, Adrian Farrel, and Dan Romascanu. Hopefully, this new version will clarify the situation, and will be accepta= ble to everybody. Please let us know. Note: I prefer to keep the edit token from now. Regards, Benoit (OPS AD) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D SUPA CHARTER PROPOSAL (2015-08-07) Policy is an important configurable component in the delivery of services a= nd the operation of networks. Operators want and need to be able to determi= ne the policies that apply to their different customers and to the equipmen= t that comprises their physical and virtual networks. As policy spans such = a wide range of services and device types, it will be helpful if there is a= common way of expressing and describing policies that is uniform and consi= stent in all environments. Such an approach will help to avoid configuratio= n errors that arise from confusion between different systems, will enable e= asy understanding of policies that apply in different environments, will ma= ke the implementation of policy-based systems quicker and cheaper, and will= facilitate the rapid development of standards-based data models that inclu= de policy elements. SUPA (Simplified Use of Policy Abstractions) defines a model to interface w= ith a network management function (within a controller, an orchestrator, a = network element) that takes high-level, possibly network-wide policies as i= nput. SUPA will not define what the function does with that input but antic= ipates that it will ultimately result in network configuration changes Practically, SUPA will define generic YANG data models to encode policy, wh= ich can point to device-, technology-, and service-specific YANG models of = other working groups. SUPA will be designed to work with device, protocol, network, and service d= ata models. The SUPA working group will develop a model for expressing policy at differ= ent levels of abstraction. Specifically, three model fragments are envisio= ned: (i) a generic model that defines concepts and vocabulary needed by pol= icy management independent of the form and content of the policy, (ii) a mo= re specific model that refines the generic model to specify how to build po= licy rules of the event-condition-action paradigm, and (iii) the working gr= oup will investigate the practically of building policy rules that declarat= ively specify what goals to achieve (this is often called "intent-based" po= licy) but not how to achieve those goals and may create a model accordingly= . If the working group finds it necessary to work on an information model bef= ore the data model, to help provide guidance and derive the data models, it= might do so. The working group will decide later whether the information m= odel needs to be published as an RFC. Out of scope of this working group is: - The specification of a new policy language. The YANG data models are to= be used with protocols such as NETCONF/RESTCONF. - Design of protocol-specific policies and specific design for embedded p= olicies in network elements (which are usually interpreted in isolation, an= d often at timescales that require optimization for specific purposes). - Specific handling of policies (although the application document will p= rovide some examples), and therefore the specification of a policy engine t= hat maps a specific policy instance to actual configuration snippets. List of work items: 1) A document that explains the scope of the policy-based management framew= ork and how it relates to existing work of the IETF. 2) If the working group considers it necessary, an information model compos= ed of policy concepts and vocabulary. 3) A set of YANG data models consisting of a base policy model for represen= ting policy management concepts independent of the type or structure of a p= olicy, plus an extension for defining policy rules according to the event-c= ondition-action paradigm. Another extension for defining policy rules accor= ding to a declarative, or intent-based, paradigm, may be produced. These mo= dels will be designed to be generic and extensible. 4) An applicability document providing a few examples that demonstrate how = the generic policy models can be used to express policies that are relevant= for network operators. The examples may tie into configuration models or n= etwork service models developed by other working groups. The working group will decide how the work items are best mapped into deliv= erables. This working group will be a success when the SUPA policy constructs are re= -used in future IETF specifications (and, ideally, specifications from othe= r SDOs), in a manner that will save development time and avoid inconsistenc= ies between data models developed by different working groups. In the meant= ime, SUPA should not impede work in other working groups while waiting for = SUPA to produce its deliverables. The working group will communicate with other SDOs (MEF, TMF, ETSI) that ar= e working on related issues. Milestones: TBD ________________________________ The information transmitted herein is intended only for the person or entit= y to which it is addressed and may contain confidential, proprietary and/or= privileged material. Any review, retransmission, dissemination or other us= e of, or taking of any action in reliance upon, this information by persons= or entities other than the intended recipient is prohibited. If you receiv= ed this in error, please contact the sender and delete the material from an= y computer. ________________________________ The information transmitted herein is intended only for the person or entit= y to which it is addressed and may contain confidential, proprietary and/or= privileged material. Any review, retransmission, dissemination or other us= e of, or taking of any action in reliance upon, this information by persons= or entities other than the intended recipient is prohibited. If you receiv= ed this in error, please contact the sender and delete the material from an= y computer. --_000_11D8792D50CD7F46BFBA62E9E61D5A3AD80A164Eumaildb4netcrac_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hi Benoit,

my comments inline.

From: Benoit Claise [bclaise@cisco.com]
Sent: Wednesday, September 02, 2015 7:13 PM
To: Maxim Klyus; supa@ietf.org
Cc: Eggert, Lars; Juergen Schoenwaelder (j.schoenwaelder@jacobs-univ= ersity.de)
Subject: Re: [Supa] SUPA charter proposal

On 10/08/2015 14:45, Maxim Klyus wrote:

Hi Benoit et al,

 

I would like to say thank= you for the charter clarification.

 

Also I agreed with commen= ts provided by Juergen about policy types.

 

So my suggestion will be = add the following sentences:

 

=93The SUPA framework def= ines how to construct policy rules for Environment and Administrative layer= s within one or more Management domains, where Environment layer describes functional configuration policies for domain network elements (s= pecific protocols, functions) and Administrative layer describes administra= tive non-functional access/management policies across domain network elemen= ts (user privileges, administrative states).=93

[Benoit] Regarding "one or more management domains", it would be = best to focus on a single management domain to start with.
[Benoit] Assuming that the policy engine resides in a controller, I gu= ess that don't want to deal with inter-controller communication at this poi= nt.

[MK] In my understanding the one of the key moments - policy could be = used for inter-domain exchange and this is a great value for the end-to-end= service management. Many SDOs already defined - controllers can ogranize h= ierarchy for management and administrative purpose, so I don't see any contradiction here.

[Benoit] Wrt to "Environment and Administ= rative layers", I believe that these are topics for the framework docu= ment.

[MK] Ok.

Regards, Benoit

 

Best Regards,

Maxim Klyus

 <= /span>

From: Supa [mailto:supa-boun= ces@ietf.org] On Behalf Of Benoit Claise
Sent: Friday, August 07, 2015 7:03 PM
To: supa@ietf.org
Cc: Eggert, Lars
Subject: [Supa] SUPA charter proposal

 

Dear all,

As promised in my last email ("SUPA: Situation Summary and Next Steps&= quot;), here is a proposed charter.
Thanks to Robert Sparks, Adrian Farrel, and Dan Romascanu.

Hopefully, this new version will clarify the situation, and will be accepta= ble to everybody.
Please let us know. Note: I prefer to keep the edit token from now.

Regards, Benoit (OPS AD)

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

SUPA CHARTER PROPOSAL (2015-08-07)

 

Policy is an important configurable component in t= he delivery of services and the operation of networks. Operators want and n= eed to be able to determine the policies that apply to their different customers and to the equipment that comprise= s their physical and virtual networks. As policy spans such a wide range of= services and device types, it will be helpful if there is a common way of = expressing and describing policies that is uniform and consistent in all environments. Such an approach will = help to avoid configuration errors that arise from confusion between differ= ent systems, will enable easy understanding of policies that apply in diffe= rent environments, will make the implementation of policy-based systems quicker and cheaper, and will facil= itate the rapid development of standards-based data models that include pol= icy elements.

 

 

SUPA (Simplified Use of Policy Abstractions) defin= es a model to interface with a network management function (within a contro= ller, an orchestrator, a network element) that takes high-level, possibly network-wide policies as input. SUPA will = not define what the function does with that input but anticipates that it w= ill ultimately result in network configuration changes

 

 

Practically, SUPA will define generic YANG data mo= dels to encode policy, which can point to device-, technology-, and service= -specific YANG models of other working groups.

 

SUPA will be designed to work with device, protoco= l, network, and service data models.

 

The SUPA working group will develop a model for ex= pressing policy at different levels of abstraction.  Specifically, thr= ee model fragments are envisioned: (i) a generic model that defines concepts and vocabulary needed by policy management ind= ependent of the form and content of the policy, (ii) a more specific model = that refines the generic model to specify how to build policy rules of the = event-condition-action paradigm, and (iii) the working group will investigate the practically of building p= olicy rules that declaratively specify what goals to achieve (this is often= called "intent-based" policy) but not how to achieve those goals= and may create a model accordingly.

 

If the working group finds it necessary to work on= an information model before the data model, to help provide guidance and d= erive the data models, it might do so. The working group will decide later whether the information model needs to be = published as an RFC.

 

Out of scope of this working group is:  

-<= span lang=3D"EN-US" style=3D"font-size:7.0pt; line-height:115%">  = ; Th= e specification of a new policy language. The YANG data models are to be us= ed with protocols such as NETCONF/RESTCONF.

-<= span lang=3D"EN-US" style=3D"font-size:7.0pt; line-height:115%">  = ; De= sign of protocol-specific policies and specific design for embedded policie= s in network elements (which are usually interpreted in isolation, and ofte= n at timescales that require optimization for specific purposes).

-<= span lang=3D"EN-US" style=3D"font-size:7.0pt; line-height:115%">  = ; Sp= ecific handling of policies (although the application document will provide= some examples), and therefore the specification of a policy engine that ma= ps a specific policy instance to actual configuration snippets.

 

List of work items:

 

1) A document that explains the scope of the polic= y-based management framework and how it relates to existing work of the IET= F.

 

2) If the working group considers it necessary, an= information model composed of policy concepts and vocabulary.

 

3) A set of YANG data models consisting of a base = policy model for representing policy management concepts independent of the= type or structure of a policy, plus an extension for defining policy rules according to the event-condition-actio= n paradigm. Another extension for defining policy rules according to a decl= arative, or intent-based, paradigm, may be produced. These models will be d= esigned to be generic and extensible.

 

4) An applicability document providing a few examp= les that demonstrate how the generic policy models can be used to express p= olicies that are relevant for network operators. The examples may tie into configuration models or network service models d= eveloped by other working groups.

 

The working group will decide how the work items a= re best mapped into deliverables.

 

This working group will be a success when the SUPA= policy constructs are re-used in future IETF specifications (and, ideally,= specifications from other SDOs), in a manner that will save development time and avoid inconsistencies between data mod= els developed by different working groups. In the meantime, SUPA should not= impede work in other working groups while waiting for SUPA to produce its = deliverables.

 

The working group will communicate with other SDOs= (MEF, TMF, ETSI) that are working on related issues.

 

Milestones:

 

TBD

 

=  

=

The information transmitted herein is intended only for the person or entit= y to which it is addressed and may contain confidential, proprietary and/or= privileged material. Any review, retransmission, dissemination or other us= e of, or taking of any action in reliance upon, this information by persons or entities other than the inte= nded recipient is prohibited. If you received this in error, please contact= the sender and delete the material from any computer.  

=  

=

The information transmitted herein is intended only for the person or entit= y to which it is addressed and may contain confidential, proprietary and/or= privileged material. Any review, retransmission, dissemination or other us= e of, or taking of any action in reliance upon, this information by persons or entities other than the inte= nded recipient is prohibited. If you received this in error, please contact= the sender and delete the material from any computer.  

--_000_11D8792D50CD7F46BFBA62E9E61D5A3AD80A164Eumaildb4netcrac_-- From nobody Thu Sep 3 08:54:43 2015 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D8381B412E for ; Thu, 3 Sep 2015 08:54:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mEh8s_asyOgD for ; Thu, 3 Sep 2015 08:54:29 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDEC01B4159 for ; Thu, 3 Sep 2015 08:53:44 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2CQAgCobOhV/yYyC4ddGQQBglEsVGkGgx66NAEJgVAdCoV7AhyBGDgUAQEBAQEBAX8LhCMBAQEBAgESCwYRUQYBCA0EBAEBAwIGCxIDAgQwFAEGAQEFBAEEEwgMCwOIBAgBDKclhQyKV5RbAQEIAQEBAQEBARuBIoVThHmEKBEBID4EgiQ7Eh2BFAWMeIhZAYUGgm2GTUaDbIMTjXSDbCaEAHGIDTqBBQEBAQ X-IPAS-Result: A2CQAgCobOhV/yYyC4ddGQQBglEsVGkGgx66NAEJgVAdCoV7AhyBGDgUAQEBAQEBAX8LhCMBAQEBAgESCwYRUQYBCA0EBAEBAwIGCxIDAgQwFAEGAQEFBAEEEwgMCwOIBAgBDKclhQyKV5RbAQEIAQEBAQEBARuBIoVThHmEKBEBID4EgiQ7Eh2BFAWMeIhZAYUGgm2GTUaDbIMTjXSDbCaEAHGIDTqBBQEBAQ X-IronPort-AV: E=Sophos;i="5.17,462,1437451200"; d="scan'208";a="134344968" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by co300216-co-outbound.net.avaya.com with ESMTP; 03 Sep 2015 11:53:43 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC03.global.avaya.com) ([135.64.58.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES128-SHA; 03 Sep 2015 11:53:43 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC03.global.avaya.com ([135.64.58.13]) with mapi id 14.03.0174.001; Thu, 3 Sep 2015 11:53:42 -0400 From: "Romascanu, Dan (Dan)" To: "supa@ietf.org" Thread-Topic: NomCom 2015: Call for nominations Thread-Index: AdDmYLMhYt3qrZ7wRl2E6B8flj45mA== Date: Thu, 3 Sep 2015 15:53:41 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5CB115C0@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.47] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [Supa] FW: NomCom 2015: Call for nominations X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2015 15:54:34 -0000 UGxlYXNlIHNlZSBiZWxvdyB0aGUgQ2FsbCBmb3IgTm9taW5hdGlvbnMgZnJvbSBOb21Db20gMjAx NS4gUGxlYXNlIGhlbHAgTm9tQ29tIGFuZCB0aGUgSUVURiBjb21tdW5pdHkgYnkgcHJvcG9zaW5n IHRoZSBiZXN0IGNhbmRpZGF0ZXMgZm9yIHRoZSBvcGVuIHBvc2l0aW9ucy4gDQoNClRoYW5rcyBh bmQgUmVnYXJkcywNCg0KRGFuDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBG cm9tOiBJRVRGLUFubm91bmNlIFttYWlsdG86aWV0Zi1hbm5vdW5jZS1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YNCj4gTm9tQ29tIENoYWlyIDIwMTUNCj4gU2VudDogV2VkbmVzZGF5LCBB dWd1c3QgMjYsIDIwMTUgMToxMyBQTQ0KPiBUbzogSUVURiBBbm5vdW5jZW1lbnQgTGlzdA0KPiBD YzogaWV0ZkBpZXRmLm9yZw0KPiBTdWJqZWN0OiBOb21Db20gMjAxNTogQ2FsbCBmb3Igbm9taW5h dGlvbnMNCj4gDQo+IFRoZSAyMDE1LTE2IE5vbWluYXRpbmcgQ29tbWl0dGVlIChOb21jb20pIGlz IHNlZWtpbmcgbm9taW5hdGlvbnMgZnJvbQ0KPiBub3cgdW50aWwgT2N0b2JlciA4LCAyMDE1LiBU aGUgb3BlbiBwb3NpdGlvbnMgYmVpbmcgY29uc2lkZXJlZCBieSB0aGlzIHllYXIncw0KPiBOb21j b20gY2FuIGJlIGZvdW5kIGF0IHRoZSBlbmQgb2YgdGhpcyBlbWFpbCBhbmQgYWxzbyBvbiB0aGlz IHllYXIncw0KPiBOb21jb20gd2Vic2l0ZToNCj4gDQoNCg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9ub21jb20vMjAxNS8gDQoNCj4gDQo+IE5vbWluYXRpb25zIG1heSBiZSBtYWRlIGJ5 IHNlbGVjdGluZyB0aGUgTm9taW5hdGUgbGluayBhdCB0aGUgdG9wIG9mIHRoZQ0KPiBOb21jb20g MjAxNSBob21lIHBhZ2UsIG9yIGJ5IHZpc2l0aW5nIHRoZSBmb2xsb3dpbmcgVVJMOg0KPiANCg0K DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL25vbWNvbS8yMDE1L25vbWluYXRlLyANCg0K PiANCj4gICB7Tm90ZSB0aGF0IG5vbWluYXRpb25zIG1hZGUgdXNpbmcgdGhlIHdlYiB0b29sIHJl cXVpcmUgYW4gaWV0Zi5vcmcNCj4gICAgZGF0YXRyYWNrZXIgYWNjb3VudC4gWW91IGNhbiBjcmVh dGUgYSBkYXRhdHJhY2tlciBpZXRmLm9yZyBhY2NvdW50DQo+ICAgIGlmIHlvdSBkb24ndCBoYXZl IG9uZSBhbHJlYWR5IGJ5IHZpc2l0aW5nIHRoZSBmb2xsb3dpbmcgVVJMOg0KDQpodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2FjY291bnRzL2NyZWF0ZS8NCg0KPiANCj4gSWYgeW91IGFyZSB1 bmFibGUgdG8gdXNlIHRoZSB3ZWIgZm9ybSwgbm9taW5hdGlvbnMgbWF5IGluc3RlYWQgYmUgbWFk ZSBieQ0KPiBlbWFpbCB0byBub21jb20xNUBpZXRmLm9yZy4gSWYgdXNpbmcgZW1haWwsIHBsZWFz ZSBpbmNsdWRlIHRoZSB3b3JkDQo+ICJOb21pbmF0ZSIgaW4gdGhlIFN1YmplY3QgYW5kIGluZGlj YXRlIGluIHRoZSBlbWFpbCB3aG8gaXMgYmVpbmcgbm9taW5hdGVkLA0KPiB0aGVpciBlbWFpbCBh ZGRyZXNzICh0byBjb25maXJtIGFjY2VwdGFuY2Ugb2YgdGhlIG5vbWluYXRpb24pLCBhbmQgdGhl DQo+IHBvc2l0aW9uIGZvciB3aGljaCB5b3UgYXJlIG1ha2luZyB0aGUgbm9taW5hdGlvbi4NCj4g SWYgeW91IGFyZSBub21pbmF0aW5nIHNvbWVvbmUgb3RoZXIgdGhhbiB5b3Vyc2VsZiwgcGxlYXNl IHRlbGwgdXMgaWYgd2UgbWF5DQo+IHRlbGwgdGhlIG5vbWluZWUgdGhhdCB5b3Ugd2VyZSB0aGUg b25lIHdobyBtYWRlIHRoZSBub21pbmF0aW9uLg0KPiBJZiB5b3Ugd2lzaCB0byBub21pbmF0ZSBz b21lb25lIHZpYSBlbWFpbCBmb3IgbW9yZSB0aGFuIG9uZSBwb3NpdGlvbiwNCj4gcGxlYXNlIHVz ZSBzZXBhcmF0ZSBlbWFpbHMgdG8gZG8gc28uDQo+IA0KPiBTZWxmLW5vbWluYXRpb24gaXMgd2Vs Y29tZSENCj4gDQo+IE5vbUNvbSAyMDE1LTE2IHdpbGwgZm9sbG93IHRoZSBwb2xpY3kgZm9yICJP cGVuIERpc2Nsb3N1cmUgb2YgV2lsbGluZw0KPiBOb21pbmVlcyIgZGVzY3JpYmVkIGluIEJDUCAx MC9SRkMgNzQzNy4gIEFzIHN0YXRlZCBpbiBSRkMgNzQzNzogIlRoZSBsaXN0IG9mDQo+IG5vbWlu ZWVzIHdpbGxpbmcgdG8gYmUgY29uc2lkZXJlZCBmb3IgcG9zaXRpb25zIHVuZGVyIHJldmlldyBp biB0aGUgY3VycmVudA0KPiBOb21jb20gY3ljbGUgaXMgbm90IGNvbmZpZGVudGlhbCIuIFdpbGxp bmcgbm9taW5lZXMgZm9yIGVhY2ggcG9zaXRpb24gd2lsbCBiZQ0KPiBsaXN0ZWQgaW4gYSBwdWJs aWNseSBhY2Nlc3NpYmxlIHdheSAtIGFueW9uZSB3aXRoIGEgZGF0YXRyYWNrZXIgYWNjb3VudCBt YXkNCj4gYWNjZXNzIHRoZSBsaXN0cy4gIEFkZGl0aW9uYWxseSwgdGhlIG5vbWluYXRpb24gZm9y bSBhc2tzIGlmIHdlIG1heSBzaGFyZSB5b3VyDQo+IG93biBuYW1lIHdpdGggdGhlIG5vbWluZWUu IEluIGFsbCBvdGhlciB3YXlzLCB0aGUgY29uZmlkZW50aWFsaXR5DQo+IHJlcXVpcmVtZW50cyBv ZiBCQ1AxMCByZW1haW4gaW4gZWZmZWN0LiAgQWxsIGZlZWRiYWNrIGFuZCBhbGwgTm9tY29tDQo+ IGRlbGliZXJhdGlvbnMgd2lsbCByZW1haW4gY29uZmlkZW50aWFsIGFuZCB3aWxsIG5vdCBiZSBk aXNjbG9zZWQuDQo+IA0KPiBUaGVyZSBpcyBhIGZpZWxkIG9uIHRoZSBmb3JtIHlvdSBjYW4gbWFy ayBpbiBvcmRlciB0byBhbGxvdyB0aGUgTm9tY29tIHRvDQo+IHRlbGwgdGhlIG5vbWluZWUgdGhh dCB5b3Ugd2VyZSB0aGUgb25lIHdobyBtYWRlIHRoZSBub21pbmF0aW9uLiBUaGlzIGlzIGENCj4g bmV3IHRoaW5nIHRoaXMgeWVhciwgYW5kIGl0IGRlZmF1bHRzIHRvIOKAnG5v4oCdIC0gd2Ugd29u 4oCZdCB0ZWxsLiBBZnRlciB0aGUNCj4gbm9taW5hdGlvbiBjeWNsZSwgd2Ugd2lsbCBldmFsdWF0 ZSB0aGUgcmVzdWx0IG9mIHRoaXMgYW5kIHJlY29tbWVuZA0KPiB3aGV0aGVyIHRoZSBuZXh0IE5v bWNvbSBzaG91bGQgZG8gc29tZXRoaW5nIGRpZmZlcmVudC4NCj4gDQo+IEluIG9yZGVyIHRvIGVu c3VyZSB0aW1lIHRvIGNvbGxlY3Qgc3VmZmljaWVudCBjb21tdW5pdHkgZmVlZGJhY2sgYWJvdXQg ZWFjaA0KPiBvZiB0aGUgd2lsbGluZyBub21pbmVlcywgbm9taW5hdGlvbnMgbXVzdCBiZSByZWNl aXZlZCBieSB0aGUgTm9tY29tIG9uIG9yDQo+IGJlZm9yZSBPY3RvYmVyIDgsIDIwMTUuDQo+IA0K PiBQbGVhc2Ugc3VibWl0IHlvdXIgbm9taW5hdGlvbnMgYXMgZWFybHkgYXMgcG9zc2libGUgZm9y IHRoZSBzYWtlIG9mIHlvdXINCj4gbm9taW5lZXMuIE5vdGUgdGhhdCBub21pbmF0aW9ucyBzaG91 bGQgbm90IHdhaXQgZm9yIG1hbmFnZW1lbnQNCj4gcGVybWlzc2lvbiwgYXMgaXQgaXMgZWFzaWVy IHRvIGRlY2xpbmUgdGhlIG5vbWluYXRpb24gdGhhbiBwdXQgb25lIGluIGxhdGUuICBXZQ0KPiBo YXZlIHNldCB0aGUgcXVlc3Rpb25uYWlyZSBzdWJtaXNzaW9uIGRlYWRsaW5lIGZvciBPY3RvYmVy IDE1LCAyMDE1Lg0KPiANCj4gVGhlIE5vbWNvbSBhcHBvaW50cyBpbmRpdmlkdWFscyB0byBmaWxs IHRoZSBvcGVuIHNsb3RzIG9uIHRoZSBJQU9DLCB0aGUgSUFCLA0KPiBhbmQgdGhlIElFU0cuIFRo ZSBsaXN0IG9mIHBlb3BsZSBhbmQgcG9zdHMgd2hvc2UgdGVybXMgZW5kIHdpdGggdGhlIE1hcmNo DQo+IDIwMTYgSUVURiBtZWV0aW5nLCBhbmQgdGh1cyB0aGUgcG9zaXRpb25zIGZvciB3aGljaCB0 aGlzIE5vbWNvbSBpcw0KPiByZXNwb25zaWJsZSwgZm9sbG93czoNCj4gDQo+IElBQjoNCj4gKiBN YXJ5IEJhcm5lcw0KPiAqIEpvZSBIaWxkZWJyYW5kDQo+ICogVGVkIEhhcmRpZQ0KPiAqIEVyaWsg Tm9yZG1hcmsNCj4gKiBCcmlhbiBUcmFtbWVsbA0KPiAqIE1hcmsgQmxhbmNoZXQNCj4gDQo+IElF U0c6DQo+IC0gQWxpc3NhIENvb3BlciwgQVJUDQo+IC0gQmFycnkgTGVpYmEsIEFSVA0KPiAtIEJy aWFuIEhhYmVybWFuLCBJbnRlcm5ldCAoKikNCj4gLSBCZW5vaXQgQ2xhaXNlLCBPJk0NCj4gLSBB bGlhIEF0bGFzLCBSb3V0aW5nDQo+IC0gS2F0aGxlZW4gTW9yaWFydHksIFNlY3VyaXR5DQo+IC0g TWFydGluIFN0aWVtZXJsaW5nLCBUcmFuc3BvcnQgKCopDQo+IA0KPiAqLSBoYXZlIGluZGljYXRl ZCB0aGF0IHRoZXkgZG8gbm90IGludGVuZCB0byBhY2NlcHQgYSByZW5vbWluYXRpb24uIFRoaXMN Cj4gaW5mb3JtYXRpb24gaXMgYWx3YXlzIHVwIHRvIGRhdGUgb24NCg0KaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9ub21jb20vMjAxNS8NCg0KPiANCj4gUGxlYXNlIGJlIHJlc291cmNlZnVs IGluIGlkZW50aWZ5aW5nIHBvc3NpYmxlIGNhbmRpZGF0ZXMgZm9yIHRoZXNlIHBvc2l0aW9ucywN Cj4gYXMgZGV2ZWxvcGluZyBvdXIgdGFsZW50IGlzIGEgdmVyeSBjcnVjaWFsIHJlcXVpcmVtZW50 IGZvciB0aGUgSUVURiwgYW5kIGFsc28sDQo+IHBsZWFzZSBjb25zaWRlciBhY2NlcHRpbmcgYSBu b21pbmF0aW9uLiAgWW91J2xsIGZpbmQgZXh0ZW5zaXZlIGluZm9ybWF0aW9uDQo+IGFib3V0IHNw ZWNpZmljIHBvc2l0aW9ucywgZGV2ZWxvcGVkIGJ5IHRoZSBJQUIsIElFU0csIGFuZCBJQU9DLCB1 bmRlcg0KPiBpbmRpdmlkdWFsIHRhYnMgYXQ6DQo+IA0KDQpodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL25vbWNvbS8yMDE1L3JlcXVpcmVtZW50cy8NCg0KPiANCj4gSW4gYWRkaXRpb24gdG8g bm9taW5hdGlvbnMsIHRoZSBOb21jb20gc2Vla3MgY29tbXVuaXR5IGlucHV0IG9uIHRoZQ0KPiBw b3NpdGlvbnMgdGhlbXNlbHZlcy4gIFdlIG5lZWQgYW5kIHdlbGNvbWUgdGhlIGNvbW11bml0eSdz IHZpZXdzIGFuZA0KPiBpbnB1dCBvbiB0aGUgam9icyB3aXRoaW4gZWFjaCBvcmdhbml6YXRpb24u IElmIHlvdSBoYXZlIGlkZWFzIG9uIHRoZSBwb3NpdGlvbnMnDQo+IHJlc3BvbnNpYmlsaXRpZXMg KG1vcmUsIGxlc3MsIGRpZmZlcmVudCksIHBsZWFzZSBsZXQgdXMga25vdy4NCj4gDQo+IFBsZWFz ZSBzZW5kIHN1Z2dlc3Rpb25zIGFuZCBmZWVkYmFjayBhYm91dCB0aGlzIHRvIG5vbWNvbTE1QGll dGYub3JnLg0KPiANCj4gVGhhbmsgeW91IGZvciB5b3VyIGhlbHAgaW4gaWRlbnRpZnlpbmcgcXVh bGlmaWVkIG5vbWluZWVzIQ0KPiANCj4gSGFyYWxkIEFsdmVzdHJhbmQNCj4gTm9tY29tIENoYWly IDIwMTUtMTYNCj4gbm9tY29tLWNoYWlyLTIwMTVAaWV0Zi5vcmcsIGh0YStub21jb21AYWx2ZXN0 cmFuZC5ubw0KDQo= From nobody Mon Sep 7 07:52:09 2015 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8465B1B55DF for ; Mon, 7 Sep 2015 07:52:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RpBdsX88-vaO for ; Mon, 7 Sep 2015 07:52:04 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6169B1B5556 for ; Mon, 7 Sep 2015 07:52:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2964; q=dns/txt; s=iport; t=1441637524; x=1442847124; h=from:subject:to:message-id:date:mime-version; bh=cpfwyXc6bxVN3NRGd8ZhkwuVD4RDw4gY4qt3gDdolFM=; b=CiW9o6ENJZVPIV89qqvENLCuUQaTckS2N/jRpJT1Amqn7/xpmtSzzr65 +9VtXV/mBb+78aS+WreCcZAQ4AYbg24Qbdm5wu8Nk9cPFK6DdDI/q4Xau NFt/Z8xhtH8BD3etLPBZcUttojlCteHO+OQtFFu5iA1hptUYmG9FxjOUu o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0C6BAAlpO1V/xbLJq1dg3eEDbw/h3cBAQEBAQGBAAuETUsKIB0WCwILAwIBAgFLDQgBAYgqDaUbj2OUBgEBAQcBAQEBGgSGc4R7h3yBQwWVVYUKh3CBTIQzgnyEI41ZJoQCPIh8AQEB X-IronPort-AV: E=Sophos;i="5.17,485,1437436800"; d="scan'208,217";a="606843656" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 07 Sep 2015 14:52:02 +0000 Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t87Eq0jC031466 for ; Mon, 7 Sep 2015 14:52:01 GMT From: Benoit Claise To: "supa@ietf.org" Message-ID: <55EDA48D.5040802@cisco.com> Date: Mon, 7 Sep 2015 16:51:57 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------090902000002020307050001" Archived-At: Subject: [Supa] New SUPA charter text X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2015 14:52:08 -0000 This is a multi-part message in MIME format. --------------090902000002020307050001 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Dear all, Based on my review of the mailing list, https://github.com/IETF-SUPA/SUPA/wiki/Charter-Diff (thanks for this btw), my discussion with the BoF chairs and some other people, I tried to integrate all the changes in this new charter version. I moved this charter into the internal review state (https://datatracker.ietf.org/doc/help/state/charter/) Please review https://datatracker.ietf.org/doc/charter-ietf-supa/ version00-09ASAP, for any mistake. At this point, we passed the wordsmithing phase. Looking now at the timing before Yokohama. A charter takes at the minimum one week internal review + two IESG formal telechats. I'm shooting for the Sept 17th and Oct 1th IESG formal telechats. However, the request for WG agenda time must be completed by Sept 18th. If the IESG approves the charter for external review on the Sept 17th telechat, I'll reserve the WG slot in the agenda, anticipating a positive answer on the WG creation. Regards, Benoit (OPS AD) --------------090902000002020307050001 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Dear all,

Based on my review of the mailing list, https://github.com/IETF-SUPA/SUPA/wiki/Charter-Diff (thanks for this btw), my discussion with the BoF chairs and some other people, I tried to integrate all the changes in this new charter version.
I moved this charter into the internal review state (https://datatracker.ietf.org/doc/help/state/charter/)

Please review https://datatracker.ietf.org/doc/charter-ietf-supa/ version 00-09ASAP, for any mistake.
At this point, we passed the wordsmithing phase.

Looking now at the timing before Yokohama.
A charter takes at the minimum one week internal review + two IESG formal telechats.
I'm shooting for the Sept 17th and Oct 1th IESG formal telechats.
However, the request for WG agenda time must be completed by Sept 18th.
If the IESG approves the charter for external review on the Sept 17th telechat, I'll reserve the WG slot in the agenda, anticipating a positive answer on the WG creation.

Regards, Benoit (OPS AD)
--------------090902000002020307050001-- From nobody Mon Sep 7 10:54:06 2015 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EE6E1B4094 for ; Mon, 7 Sep 2015 10:54:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.01 X-Spam-Level: X-Spam-Status: No, score=-5.01 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q-naKO2lLPXP for ; Mon, 7 Sep 2015 10:53:57 -0700 (PDT) Received: from fncnmp04.fnc.fujitsu.com (fncnmp04.fnc.fujitsu.com [168.127.0.57]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4C3C1B30A4 for ; Mon, 7 Sep 2015 10:53:56 -0700 (PDT) X-IronPort-AV: E=Sophos; i="5.17,485,1437454800"; d="scan'208,217"; a="68952208" Received: from rchexhcp2.fnc.net.local ([168.127.134.76]) by fncnmp02.fnc.fujitsu.com with ESMTP/TLS/AES256-SHA; 07 Sep 2015 12:53:54 -0500 Received: from RCHEXMBP1.fnc.net.local ([169.254.2.53]) by RCHEXHCP2.fnc.net.local ([168.127.134.76]) with mapi id 14.03.0181.006; Mon, 7 Sep 2015 12:53:53 -0500 From: "Leroux, Francois" To: Benoit Claise , "supa@ietf.org" Thread-Topic: [Supa] SUPA charter proposal Thread-Index: AQHQ5Za5TecnoUsoPUqkD/B7qNTEs54xTVAQ Date: Mon, 7 Sep 2015 17:53:53 +0000 Message-ID: <4832DE1A6E651043A4B3EC7A4E5BCF15C81C6F46@RCHEXMBP1.fnc.net.local> References: <55C4D6C1.5040504@cisco.com> <4832DE1A6E651043A4B3EC7A4E5BCF15C81B6D9D@RCHEXMBP1.fnc.net.local> <55E71A27.9050901@cisco.com> In-Reply-To: <55E71A27.9050901@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [168.127.136.253] x-tm-as-product-ver: SMEX-10.2.0.3176-8.000.1202-21800.002 x-tm-as-result: No--55.518600-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_4832DE1A6E651043A4B3EC7A4E5BCF15C81C6F46RCHEXMBP1fncnet_" MIME-Version: 1.0 Archived-At: Cc: "Eggert, Lars" Subject: Re: [Supa] SUPA charter proposal X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2015 17:54:04 -0000 --_000_4832DE1A6E651043A4B3EC7A4E5BCF15C81C6F46RCHEXMBP1fncnet_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Benoit, Thanks for your reply, and sorry for the (very) late response. Please see possible update below for item 1). This is with the understandin= g that "configuration snippets" specifically refers to sending commands to = the NE(s). From "- Specific handling of policies (although the application document will provide some examples), and therefore the specification of a policy engine = that maps a specific policy instance to actual configuration snippets." To "- Specific handling of policies (although the application document will provide some examples), and therefore the specification of a policy engine = that maps a specific policy instance to actual configuration snippets or any oth= er actions affecting future behavior of the targeted environment." The comment came from internal discussions as we are looking at how SUPA's = abstractions could provide for a generic policy modeling framework applicab= le to multiple systems, with the hope of reducing system-specific implement= ations (80/20 rule, optimistically). Just ignore if the intent is obvious f= or everyone else (don't want to be splitting hairs or suggest boiling the o= cean...). Regards, Fran=E7ois -- From: Benoit Claise [mailto:bclaise@cisco.com] Sent: Wednesday, September 02, 2015 10:48 AM To: Leroux, Francois; supa@ietf.org Cc: Eggert, Lars Subject: Re: [Supa] SUPA charter proposal Francois, Benoit, et al, Our initial reaction after reading the revised charter was that it was clea= r and precise. The objectives are well explained and understandable even by= people who are not familiar with the history of the group. I gathered two immediate comments: 1) "- Specific handling of policies (although the application docume= nt will provide some examples), and therefore the specification of a policy= engine that maps a specific policy instance to actual configuration snippe= ts." The term "configuration snippets" maybe too specific as it is conceivable t= hat the outcome of a policy evaluation could affect some behavior in the ma= nagement and control layer, which may or may not involve actual NE/NF/vNF l= evel changes (assuming this is what configuration snippets is referring to)= . Do you have a new proposal? 2) "The working group will communicate with other SDOs (MEF, TMF, ETSI= ) that are working on related issues." The list of SDOs should include ONF or just not mention any specific ones. = "Intent NBI" specifically has become a highly debated topic within ONF. Ple= ase see the attached message suggesting a new organization aimed at acceler= ating this work with modeling activities (possibly similar to SUPA's) done = under the ONF framework group. An Intent NBI implementation would certainly= benefit from a unified information/data modeling framework aimed at expres= sing (and possibly mixing) different types of policy through well defined a= bstractions. I'm hesitant to list all the foundatios and open source projects. That list= will be incomplete anyway. Regards, Benoit Best regards, Fran=E7ois Leroux -- Fujitsu Network Communications 2801 Telecom Pkwy Richardson, TX 75082 From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of Benoit Claise Sent: Friday, August 07, 2015 11:03 AM To: supa@ietf.org Cc: Eggert, Lars Subject: [Supa] SUPA charter proposal Dear all, As promised in my last email ("SUPA: Situation Summary and Next Steps"), he= re is a proposed charter. Thanks to Robert Sparks, Adrian Farrel, and Dan Romascanu. Hopefully, this new version will clarify the situation, and will be accepta= ble to everybody. Please let us know. Note: I prefer to keep the edit token from now. Regards, Benoit (OPS AD) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D SUPA CHARTER PROPOSAL (2015-08-07) Policy is an important configurable component in the delivery of services a= nd the operation of networks. Operators want and need to be able to determi= ne the policies that apply to their different customers and to the equipmen= t that comprises their physical and virtual networks. As policy spans such = a wide range of services and device types, it will be helpful if there is a= common way of expressing and describing policies that is uniform and consi= stent in all environments. Such an approach will help to avoid configuratio= n errors that arise from confusion between different systems, will enable e= asy understanding of policies that apply in different environments, will ma= ke the implementation of policy-based systems quicker and cheaper, and will= facilitate the rapid development of standards-based data models that inclu= de policy elements. SUPA (Simplified Use of Policy Abstractions) defines a model to interface = with a network management function (within a controller, an orchestrator, a= network element) that takes high-level, possibly network-wide policies as = input. SUPA will not define what the function does with that input but anti= cipates that it will ultimately result in network configuration changes Practically, SUPA will define generic YANG data models to encode policy, wh= ich can point to device-, technology-, and service-specific YANG models of = other working groups. SUPA will be designed to work with device, protocol, network, and service d= ata models. The SUPA working group will develop a model for expressing policy at differ= ent levels of abstraction. Specifically, three model fragments are envisio= ned: (i) a generic model that defines concepts and vocabulary needed by pol= icy management independent of the form and content of the policy, (ii) a mo= re specific model that refines the generic model to specify how to build po= licy rules of the event-condition-action paradigm, and (iii) the working gr= oup will investigate the practically of building policy rules that declarat= ively specify what goals to achieve (this is often called "intent-based" po= licy) but not how to achieve those goals and may create a model accordingly= . If the working group finds it necessary to work on an information model bef= ore the data model, to help provide guidance and derive the data models, it= might do so. The working group will decide later whether the information m= odel needs to be published as an RFC. Out of scope of this working group is: - The specification of a new policy language. The YANG data models are to= be used with protocols such as NETCONF/RESTCONF. - Design of protocol-specific policies and specific design for embedded p= olicies in network elements (which are usually interpreted in isolation, an= d often at timescales that require optimization for specific purposes). - Specific handling of policies (although the application document will p= rovide some examples), and therefore the specification of a policy engine t= hat maps a specific policy instance to actual configuration snippets. List of work items: 1) A document that explains the scope of the policy-based management framew= ork and how it relates to existing work of the IETF. 2) If the working group considers it necessary, an information model compos= ed of policy concepts and vocabulary. 3) A set of YANG data models consisting of a base policy model for represe= nting policy management concepts independent of the type or structure of a = policy, plus an extension for defining policy rules according to the event-= condition-action paradigm. Another extension for defining policy rules acco= rding to a declarative, or intent-based, paradigm, may be produced. These m= odels will be designed to be generic and extensible. 4) An applicability document providing a few examples that demonstrate how= the generic policy models can be used to express policies that are relevan= t for network operators. The examples may tie into configuration models or = network service models developed by other working groups. The working group will decide how the work items are best mapped into deliv= erables. This working group will be a success when the SUPA policy constructs are re= -used in future IETF specifications (and, ideally, specifications from othe= r SDOs), in a manner that will save development time and avoid inconsistenc= ies between data models developed by different working groups. In the meant= ime, SUPA should not impede work in other working groups while waiting for = SUPA to produce its deliverables. The working group will communicate with other SDOs (MEF, TMF, ETSI) that ar= e working on related issues. Milestones: TBD --_000_4832DE1A6E651043A4B3EC7A4E5BCF15C81C6F46RCHEXMBP1fncnet_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Benoit,

Thanks for your reply,= and sorry for the (very) late response.

Please see possible up= date below for item 1). This is with the understanding that “configur= ation snippets” specifically refers to sending commands to the NE(s).=

From=

“-   Specific handling of policies (although the= application document will

provide some examples), and therefore the specification of a pol= icy engine that

maps a specific policy instance to actual configuration snippets= .”

 

To

“-   Specific handling of policies (although the= application document will

provide some examples), and therefore the specification of a pol= icy engine that

maps a specific policy instance to actual configuration snippets= or any other

actions affecting future behavior of the targeted environment.&#= 8221;

 

The comment came from = internal discussions as we are looking at how SUPA’s abstractions cou= ld provide for a generic policy modeling framework applicable to multiple s= ystems, with the hope of reducing system-specific implementations (80/20 rule, optimistically). Just ignore if the intent is= obvious for everyone else (don’t want to be splitting hairs or sugge= st boiling the ocean…).

Regards,

Fran=E7ois

--

 

From: 

Francois,

Benoit, et al,<= o:p>

Our initial reaction a= fter reading the revised charter was that it was clear and precise. The obj= ectives are well explained and understandable even by people who are not fa= miliar with the history of the group.

I gathered two immedia= te comments:

1)      &= #8220;-   Specific handling = of policies (although the application document will provide some examples),= and therefore the specification of a policy engine that maps a specific po= licy instance to actual configuration snippets.”

The term “= ;configuration snippets” maybe too specific as it is conceivable that= the outcome of a policy evaluation could affect some behavior in the manag= ement and control layer, which may or may not involve actual NE/NF/vNF level changes (assuming this is what configuration snippe= ts is referring to).

Do you have a new proposal?

 <= /p>

2)      &= #8220;The working group will communicate with other SDOs (MEF, TMF, ETSI) t= hat are working on related issues.”

The list of SDO= s should include ONF or just not mention any specific ones. “Intent N= BI” specifically has become a highly debated topic within ONF. Please= see the attached message suggesting a new organization aimed at accelerating this work with modeling activities (possibly similar= to SUPA’s) done under the ONF framework group. An Intent NBI impleme= ntation would certainly benefit from a unified information/data modeling fr= amework aimed at expressing (and possibly mixing) different types of policy through well defined abstractions.

I'm hesitant to list all the foundatios and open source pro= jects. That list will be incomplete anyway.

Regards, Benoit

Best regards,

Fran=E7ois Leroux

--

Fujitsu Network Communications

2801 Telecom Pkwy

Richardson, TX 75082<= /o:p>

 

From:mailto:supa-bounces@ietf.= org] On Behalf Of Benoit Claise
Sent: Friday, August 07, 2015 11:03 AM
To: supa@ietf.org
Cc: Eggert, Lars
Subject: [Supa] SUPA charter proposal

 

Dear all,

As promised in my last email ("SUPA: Situation Summary and Next Steps&= quot;), here is a proposed charter.
Thanks to Robert Sparks, Adrian Farrel, and Dan Romascanu.

Hopefully, this new version will clarify the situation, and will be accepta= ble to everybody.
Please let us know. Note: I prefer to keep the edit token from now.

Regards, Benoit (OPS AD)

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

SUPA CHARTER PROPOSAL (2015-08-07)

Policy is an important configurable compone= nt in the delivery of services and the operation of networks. Operators wan= t and need to be able to determine the policies that apply to their different customers and to the equipment that= comprises their physical and virtual networks. As policy spans such a wide= range of services and device types, it will be helpful if there is a commo= n way of expressing and describing policies that is uniform and consistent in all environments. Such an appro= ach will help to avoid configuration errors that arise from confusion betwe= en different systems, will enable easy understanding of policies that apply= in different environments, will make the implementation of policy-based systems quicker and cheaper, and w= ill facilitate the rapid development of standards-based data models that in= clude policy elements.

 SUPA (Simplified Use of Policy Abstra= ctions) defines a model to interface with a network management function (wi= thin a controller, an orchestrator, a network element) that takes high-level, possibly network-wide policies as input. S= UPA will not define what the function does with that input but anticipates = that it will ultimately result in network configuration changes=

Practically, SUPA will define generic YANG = data models to encode policy, which can point to device-, technology-, and = service-specific YANG models of other working groups.

SUPA will be designed to work with device, = protocol, network, and service data models.

The SUPA working group will develop a model= for expressing policy at different levels of abstraction.  Specifical= ly, three model fragments are envisioned: (i) a generic model that defines concepts and vocabulary needed by policy mana= gement independent of the form and content of the policy, (ii) a more speci= fic model that refines the generic model to specify how to build policy rul= es of the event-condition-action paradigm, and (iii) the working group will investigate the practically of = building policy rules that declaratively specify what goals to achieve (thi= s is often called "intent-based" policy) but not how to achieve t= hose goals and may create a model accordingly.

If the working group finds it necessary to = work on an information model before the data model, to help provide guidanc= e and derive the data models, it might do so. The working group will decide later whether the information model n= eeds to be published as an RFC.

Out of scope of this working group is: = ;

-   The specification = of a new policy language. The YANG data models are to be used with protocol= s such as NETCONF/RESTCONF.

-   Design of protocol= -specific policies and specific design for embedded policies in network ele= ments (which are usually interpreted in isolation, and often at timescales = that require optimization for specific purposes).

-   Specific handling = of policies (although the application document will provide some examples),= and therefore the specification of a policy engine that maps a specific po= licy instance to actual configuration snippets. 

List of work items:

1) A document that explains the scope of th= e policy-based management framework and how it relates to existing work of = the IETF.

2) If the working group considers it necess= ary, an information model composed of policy concepts and vocabulary.

 3) A set of YANG data models consisti= ng of a base policy model for representing policy management concepts indep= endent of the type or structure of a policy, plus an extension for defining policy rules according to the event-conditi= on-action paradigm. Another extension for defining policy rules according t= o a declarative, or intent-based, paradigm, may be produced. These models w= ill be designed to be generic and extensible.

 4) An applicability document providin= g a few examples that demonstrate how the generic policy models can be used= to express policies that are relevant for network operators. The examples may tie into configuration models or netwo= rk service models developed by other working groups.

The working group will decide how the work = items are best mapped into deliverables.

This working group will be a success when t= he SUPA policy constructs are re-used in future IETF specifications (and, i= deally, specifications from other SDOs), in a manner that will save development time and avoid inconsistencies betw= een data models developed by different working groups. In the meantime, SUP= A should not impede work in other working groups while waiting for SUPA to = produce its deliverables.

The working group will communicate with oth= er SDOs (MEF, TMF, ETSI) that are working on related issues.

Milestones: TBD

 

--_000_4832DE1A6E651043A4B3EC7A4E5BCF15C81C6F46RCHEXMBP1fncnet_-- From nobody Tue Sep 8 05:40:36 2015 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C6951B4564 for ; Tue, 8 Sep 2015 05:40:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J96WC_Jjsijm for ; Tue, 8 Sep 2015 05:40:32 -0700 (PDT) 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 0FA2A1B453E for ; Tue, 8 Sep 2015 05:40:32 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 7C34B14A4; Tue, 8 Sep 2015 14:40:30 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id rfa0X0YK17f4; Tue, 8 Sep 2015 14:40:29 +0200 (CEST) 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; Tue, 8 Sep 2015 14:40:29 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6CA5C2004E; Tue, 8 Sep 2015 14:40:29 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id R5jT42ODLmEh; Tue, 8 Sep 2015 14:40:28 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B731C20048; Tue, 8 Sep 2015 14:40:27 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id D0C3037049F0; Tue, 8 Sep 2015 14:40:23 +0200 (CEST) Date: Tue, 8 Sep 2015 14:40:23 +0200 From: Juergen Schoenwaelder To: Benoit Claise Message-ID: <20150908124021.GB32230@elstar.local> Mail-Followup-To: Benoit Claise , "supa@ietf.org" References: <55EDA48D.5040802@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55EDA48D.5040802@cisco.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "supa@ietf.org" Subject: Re: [Supa] New SUPA charter text X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2015 12:40:34 -0000 On Mon, Sep 07, 2015 at 04:51:57PM +0200, Benoit Claise wrote: > > Please review https://datatracker.ietf.org/doc/charter-ietf-supa/ > version00-09ASAP, for any mistake. > At this point, we passed the wordsmithing phase. > It is unclear whether you want to have feedback or not. I will send it anyway, feel free to ignore since we 'passed the wordsmithing phase'. I have two comments: - It is unclear what SUPA is going to do regarding declarative policies. The charter text says (iii) the working group will investigate the practically of building policy rules that declaratively specify what goals to achieve (this is often called "intent-based" policy) but not how to achieve those goals and may create a model accordingly but it also says: Out of scope of this working group are: [...] - Declarative a.k.a intent-based policy rules. Another extension for defining policy rules according to a declarative, or intent-based, paradigm, may be produced in later phases of SUPA work. For me this is confusing but perhaps I just do not read the text in the right way. - The other comment concerns this text: SUPA however will not deal with the definition of the specific network configuration changes but with how the configuration changes are applied (e.g. who is allowed to set policies, when and how the policies are activated, changed or de-activated) Is SUPA going to work out how actions are specified and executed? For example: Assuming the ACL YANG data model worked on in NETMOD, will I be able to use SUPA policy data models without further data models to populate my ACL lists? Or is the idea that SUPA only provide a core framework that requires data model extensions to do anything meaningful? Pretty much like the interfaces data model that requires interface type specific extensions to be really useful. Now I shut up. ;-) /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 Sep 8 11:55:10 2015 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E4B51B525E for ; Tue, 8 Sep 2015 11:55:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R0Sqm-FSFXX8 for ; Tue, 8 Sep 2015 11:55:05 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDC121B525D for ; Tue, 8 Sep 2015 11:55:04 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2ACBQA3Q8ZV/xUHmMZYAxkBAQGCUyxUaQapbgaVQ4V5AoEmPBABAQEBAQEBgQqEIwEBAQECARIoNAsFBwICAgEIDQECAQQBAQEKFAkHGxcUCQgCBAENBQgaiAQIAQysaaA6AQEBAQEBAQEBAQEBAQEBAQEBAQEBEwQEhhuFMoRYIRAHBgyDBoEUBZULAYUBiSqEJYMLDIN7jH0XD4N9bwGBR4EEAQEB X-IPAS-Result: A2ACBQA3Q8ZV/xUHmMZYAxkBAQGCUyxUaQapbgaVQ4V5AoEmPBABAQEBAQEBgQqEIwEBAQECARIoNAsFBwICAgEIDQECAQQBAQEKFAkHGxcUCQgCBAENBQgaiAQIAQysaaA6AQEBAQEBAQEBAQEBAQEBAQEBAQEBEwQEhhuFMoRYIRAHBgyDBoEUBZULAYUBiSqEJYMLDIN7jH0XD4N9bwGBR4EEAQEB X-IronPort-AV: E=Sophos;i="5.15,634,1432612800"; d="scan'208";a="140175722" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 08 Sep 2015 14:55:03 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 08 Sep 2015 14:55:03 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC04.global.avaya.com ([135.64.58.14]) with mapi id 14.03.0174.001; Tue, 8 Sep 2015 20:55:01 +0200 From: "Romascanu, Dan (Dan)" To: Juergen Schoenwaelder , "Benoit Claise" Thread-Topic: [Supa] New SUPA charter text Thread-Index: AQHQ6jORZ99PaEMmBECww1YKzmmiNJ4y+gow Date: Tue, 8 Sep 2015 18:55:01 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5CB1F2F0@AZ-FFEXMB04.global.avaya.com> References: <55EDA48D.5040802@cisco.com> <20150908124021.GB32230@elstar.local> In-Reply-To: <20150908124021.GB32230@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "supa@ietf.org" Subject: Re: [Supa] New SUPA charter text X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2015 18:55:09 -0000 Hi,=20 See in-text.=20 Regards, Dan > -----Original Message----- > From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of Juergen > Schoenwaelder > Sent: Tuesday, September 08, 2015 3:40 PM > To: Benoit Claise > Cc: supa@ietf.org > Subject: Re: [Supa] New SUPA charter text >=20 > On Mon, Sep 07, 2015 at 04:51:57PM +0200, Benoit Claise wrote: > > > > Please review > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ietf= . > > org_doc_charter-2Dietf- > 2Dsupa_&d=3DBQICAg&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DI4d > > > zGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=3DFjFbmJya6x58nXbHAJ389 > Wd24wZ > > > U2zmjtIlRJFIAHB0&s=3DyGfhqxgu2nlg2EOrZwD3qlRzY9ykPQwO8IXMAc8KrFw& > e=3D > > version00-09ASAP, for any mistake. > > At this point, we passed the wordsmithing phase. > > >=20 > It is unclear whether you want to have feedback or not. I will send it an= yway, > feel free to ignore since we 'passed the wordsmithing phase'. >=20 > I have two comments: >=20 > - It is unclear what SUPA is going to do regarding declarative > policies. The charter text says >=20 > (iii) the working group will investigate the practically of building = policy > rules that declaratively specify what goals to achieve (this is often= called > "intent-based" policy) but not how to achieve those goals and may cre= ate a > model > accordingly >=20 > but it also says: >=20 > Out of scope of this working group are: > [...] > - Declarative a.k.a intent-based policy rules. Another extension for = defining > policy rules according to a declarative, or intent-based, paradigm, m= ay be > produced in later phases of SUPA work. >=20 > For me this is confusing but perhaps I just do not read the text in > the right way. >=20 IMO - the text says that we can (continue to) investigate 'practicality' as= well as how to avoid conflict with work chartered in other WGs, but we sho= uld not write a data model in the first phase of the WG. We may do this 'in= later phases'.=20 > - The other comment concerns this text: >=20 > SUPA however will not deal with > the definition of the specific network configuration changes but with= how > the > configuration changes are applied (e.g. who is allowed to set policie= s, when > and > how the policies are activated, changed or de-activated) >=20 > Is SUPA going to work out how actions are specified and executed? > For example: Assuming the ACL YANG data model worked on in NETMOD, > will I be able to use SUPA policy data models without further data > models to populate my ACL lists? Or is the idea that SUPA only > provide a core framework that requires data model extensions to do > anything meaningful? Pretty much like the interfaces data model that > requires interface type specific extensions to be really useful. >=20 IMO - rather the later. Yet, I would observe - as you brought up the exampl= e - that some people do useful things and get useful information from the i= nterfaces table MIB objects.=20 > Now I shut up. ;-) >=20 Why? :-) > /js >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > 2Duniversity.de_&d=3DBQICAg&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DI4dzGxR31O > cNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=3DFjFbmJya6x58nXbHAJ389Wd24wZ > U2zmjtIlRJFIAHB0&s=3DqrI__AXlgml5bUqjuH_K_dNchVZDYRzehsCmOTpRXRg > &e=3D > >=20 > _______________________________________________ > Supa mailing list > Supa@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__www.ietf.org_mailman_listinfo_supa&d=3DBQICAg&c=3DBFpWQw8bsuKpl1 > SgiZH64Q&r=3DI4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=3DFjFbmJy > a6x58nXbHAJ389Wd24wZU2zmjtIlRJFIAHB0&s=3DKp4a2MG8oVlIY- > HewXWBrbaebyraGmPqwd2xlfRSAfU&e=3D From nobody Tue Sep 8 12:19:21 2015 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43F931B5304 for ; Tue, 8 Sep 2015 12:19:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HzYBbmq6Mn4D for ; Tue, 8 Sep 2015 12:19:17 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 444001B52FF for ; Tue, 8 Sep 2015 12:19:16 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CBA51668; Tue, 08 Sep 2015 19:19:10 +0000 (GMT) Received: from SJCEML702-CHM.china.huawei.com (10.218.25.35) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 8 Sep 2015 20:19:07 +0100 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.222]) by SJCEML702-CHM.china.huawei.com ([169.254.4.111]) with mapi id 14.03.0235.001; Tue, 8 Sep 2015 12:19:03 -0700 From: John Strassner To: "Romascanu, Dan (Dan)" , Juergen Schoenwaelder , Benoit Claise Thread-Topic: [Supa] New SUPA charter text Thread-Index: AQHQ6jOYw5At2hdwtkyjeQw8LZRqT54zcKyA//+MpMA= Date: Tue, 8 Sep 2015 19:19:02 +0000 Message-ID: References: <55EDA48D.5040802@cisco.com> <20150908124021.GB32230@elstar.local> <9904FB1B0159DA42B0B887B7FA8119CA5CB1F2F0@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA5CB1F2F0@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.64.51] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "supa@ietf.org" Subject: Re: [Supa] New SUPA charter text X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2015 19:19:20 -0000 >> I have two comments: >>=20 >> - It is unclear what SUPA is going to do regarding declarative >> policies. The charter text says >>=20 >> (iii) the working group will investigate the practically of building= policy >> rules that declaratively specify what goals to achieve (this is ofte= n called >> "intent-based" policy) but not how to achieve those goals and may cr= eate a >> model accordingly >>=20 >> but it also says: >>=20 >> Out of scope of this working group are: >> [...] >> - Declarative a.k.a intent-based policy rules. Another extension for= defining >> policy rules according to a declarative, or intent-based, paradigm, = may be >> produced in later phases of SUPA work. >>=20 >> For me this is confusing but perhaps I just do not read the text in >> the right way. >>=20 > IMO - the text says that we can (continue to) investigate 'practicality' = as well > as how to avoid conflict with work chartered in other WGs, but we should = not > write a data model in the first phase of the WG. We may do this 'in later= phases'.=20 I agree with Juergen. The two pieces of text conflict with each other. The = simplest fix is to remove all of the first text cited. >> - The other comment concerns this text: >>=20 >> SUPA however will not deal with >> the definition of the specific network configuration changes but wit= h how >> the configuration changes are applied (e.g. who is allowed to set po= licies, >> when and how the policies are activated, changed or de-activated) I'm confused by the above text. Defining who (or what) is allowed to set=20 policies seems out of scope for the IETF. This is typically done using patt= erns (e.g., the role-object pattern), and I don't see how to map that easily to = YANG. >>=20 >> Is SUPA going to work out how actions are specified and executed? >> For example: Assuming the ACL YANG data model worked on in NETMOD, >> will I be able to use SUPA policy data models without further data >> models to populate my ACL lists? Or is the idea that SUPA only >> provide a core framework that requires data model extensions to do >> anything meaningful? Pretty much like the interfaces data model that >> requires interface type specific extensions to be really useful. > IMO - rather the later. Yet, I would observe - as you brought up the=20 > example - that some people do useful things and get useful information fr= om=20 > the interfaces table MIB objects. I would hope that it is the former. regards, John John Strassner, Ph.D. CTO, Software Laboratory, CRD Futurewei Technologies US R&D Center 2330 Central Expressway Building A, office A2-2143 Santa Clara, California=A0=A0 95050 =A0 Office:=A0 +1.408.330.4923 =A0 Email:=A0=A0 john.sc.strassner@huawei.com =20 -----Original Message----- From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Tuesday, September 08, 2015 11:55 AM To: Juergen Schoenwaelder; Benoit Claise Cc: supa@ietf.org Subject: Re: [Supa] New SUPA charter text Hi,=20 See in-text.=20 Regards, Dan > -----Original Message----- > From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of Juergen > Schoenwaelder > Sent: Tuesday, September 08, 2015 3:40 PM > To: Benoit Claise > Cc: supa@ietf.org > Subject: Re: [Supa] New SUPA charter text >=20 > On Mon, Sep 07, 2015 at 04:51:57PM +0200, Benoit Claise wrote: > > > > Please review > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ietf= . > > org_doc_charter-2Dietf- > 2Dsupa_&d=3DBQICAg&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DI4d > > > zGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=3DFjFbmJya6x58nXbHAJ389 > Wd24wZ > > > U2zmjtIlRJFIAHB0&s=3DyGfhqxgu2nlg2EOrZwD3qlRzY9ykPQwO8IXMAc8KrFw& > e=3D > > version00-09ASAP, for any mistake. > > At this point, we passed the wordsmithing phase. > > >=20 > It is unclear whether you want to have feedback or not. I will send it an= yway, > feel free to ignore since we 'passed the wordsmithing phase'. >=20 > I have two comments: >=20 > - It is unclear what SUPA is going to do regarding declarative > policies. The charter text says >=20 > (iii) the working group will investigate the practically of building = policy > rules that declaratively specify what goals to achieve (this is often= called > "intent-based" policy) but not how to achieve those goals and may cre= ate a > model > accordingly >=20 > but it also says: >=20 > Out of scope of this working group are: > [...] > - Declarative a.k.a intent-based policy rules. Another extension for = defining > policy rules according to a declarative, or intent-based, paradigm, m= ay be > produced in later phases of SUPA work. >=20 > For me this is confusing but perhaps I just do not read the text in > the right way. >=20 IMO - the text says that we can (continue to) investigate 'practicality' as= well as how to avoid conflict with work chartered in other WGs, but we sho= uld not write a data model in the first phase of the WG. We may do this 'in= later phases'.=20 > - The other comment concerns this text: >=20 > SUPA however will not deal with > the definition of the specific network configuration changes but with= how > the > configuration changes are applied (e.g. who is allowed to set policie= s, when > and > how the policies are activated, changed or de-activated) >=20 > Is SUPA going to work out how actions are specified and executed? > For example: Assuming the ACL YANG data model worked on in NETMOD, > will I be able to use SUPA policy data models without further data > models to populate my ACL lists? Or is the idea that SUPA only > provide a core framework that requires data model extensions to do > anything meaningful? Pretty much like the interfaces data model that > requires interface type specific extensions to be really useful. >=20 IMO - rather the later. Yet, I would observe - as you brought up the exampl= e - that some people do useful things and get useful information from the i= nterfaces table MIB objects.=20 > Now I shut up. ;-) >=20 Why? :-) > /js >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > 2Duniversity.de_&d=3DBQICAg&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DI4dzGxR31O > cNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=3DFjFbmJya6x58nXbHAJ389Wd24wZ > U2zmjtIlRJFIAHB0&s=3DqrI__AXlgml5bUqjuH_K_dNchVZDYRzehsCmOTpRXRg > &e=3D > >=20 > _______________________________________________ > Supa mailing list > Supa@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__www.ietf.org_mailman_listinfo_supa&d=3DBQICAg&c=3DBFpWQw8bsuKpl1 > SgiZH64Q&r=3DI4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=3DFjFbmJy > a6x58nXbHAJ389Wd24wZU2zmjtIlRJFIAHB0&s=3DKp4a2MG8oVlIY- > HewXWBrbaebyraGmPqwd2xlfRSAfU&e=3D _______________________________________________ Supa mailing list Supa@ietf.org https://www.ietf.org/mailman/listinfo/supa From nobody Wed Sep 9 08:55:53 2015 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC32C1B38A2 for ; Wed, 9 Sep 2015 08:55:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jkB3_5jktqbM for ; Wed, 9 Sep 2015 08:55:48 -0700 (PDT) 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 53AAC1B3896 for ; Wed, 9 Sep 2015 08:55:48 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 1F9441286; Wed, 9 Sep 2015 17:54:45 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id Y_cVNQRE0ToV; Wed, 9 Sep 2015 17:54:44 +0200 (CEST) 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; Wed, 9 Sep 2015 17:54:44 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1D69820054; Wed, 9 Sep 2015 17:54:44 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id lffMXH3EiGmO; Wed, 9 Sep 2015 17:54:42 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5394E2004E; Wed, 9 Sep 2015 17:54:42 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 435ED3705B92; Wed, 9 Sep 2015 17:54:38 +0200 (CEST) Date: Wed, 9 Sep 2015 17:54:37 +0200 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Message-ID: <20150909155437.GA35404@elstar.local> Mail-Followup-To: "Romascanu, Dan (Dan)" , Benoit Claise , "supa@ietf.org" References: <55EDA48D.5040802@cisco.com> <20150908124021.GB32230@elstar.local> <9904FB1B0159DA42B0B887B7FA8119CA5CB1F2F0@AZ-FFEXMB04.global.avaya.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA5CB1F2F0@AZ-FFEXMB04.global.avaya.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: Benoit Claise , "supa@ietf.org" Subject: Re: [Supa] New SUPA charter text X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2015 15:55:52 -0000 On Tue, Sep 08, 2015 at 06:55:01PM +0000, Romascanu, Dan (Dan) wrote: > Hi, > > See in-text. > > Regards, > > Dan > > > > -----Original Message----- > > From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of Juergen > > Schoenwaelder > > Sent: Tuesday, September 08, 2015 3:40 PM > > To: Benoit Claise > > Cc: supa@ietf.org > > Subject: Re: [Supa] New SUPA charter text > > > > On Mon, Sep 07, 2015 at 04:51:57PM +0200, Benoit Claise wrote: > > > > > > Please review > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf. > > > org_doc_charter-2Dietf- > > 2Dsupa_&d=BQICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4d > > > > > zGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=FjFbmJya6x58nXbHAJ389 > > Wd24wZ > > > > > U2zmjtIlRJFIAHB0&s=yGfhqxgu2nlg2EOrZwD3qlRzY9ykPQwO8IXMAc8KrFw& > > e= > > > version00-09ASAP, for any mistake. > > > At this point, we passed the wordsmithing phase. > > > > > > > It is unclear whether you want to have feedback or not. I will send it anyway, > > feel free to ignore since we 'passed the wordsmithing phase'. > > > > I have two comments: > > > > - It is unclear what SUPA is going to do regarding declarative > > policies. The charter text says > > > > (iii) the working group will investigate the practically of building policy > > rules that declaratively specify what goals to achieve (this is often called > > "intent-based" policy) but not how to achieve those goals and may create a > > model > > accordingly > > > > but it also says: > > > > Out of scope of this working group are: > > [...] > > - Declarative a.k.a intent-based policy rules. Another extension for defining > > policy rules according to a declarative, or intent-based, paradigm, may be > > produced in later phases of SUPA work. > > > > For me this is confusing but perhaps I just do not read the text in > > the right way. > > > > IMO - the text says that we can (continue to) investigate 'practicality' as well as how to avoid conflict with work chartered in other WGs, but we should not write a data model in the first phase of the WG. We may do this 'in later phases'. > Expecting a WG to "practically investigate" something that is clearly declared to be out of scope for the WG still sounds like a contradiction to me (and I also wonder what "practically investigate" means). > > - The other comment concerns this text: > > > > SUPA however will not deal with > > the definition of the specific network configuration changes but with how > > the > > configuration changes are applied (e.g. who is allowed to set policies, when > > and > > how the policies are activated, changed or de-activated) > > > > Is SUPA going to work out how actions are specified and executed? > > For example: Assuming the ACL YANG data model worked on in NETMOD, > > will I be able to use SUPA policy data models without further data > > models to populate my ACL lists? Or is the idea that SUPA only > > provide a core framework that requires data model extensions to do > > anything meaningful? Pretty much like the interfaces data model that > > requires interface type specific extensions to be really useful. > > IMO - rather the later. Yet, I would observe - as you brought up the example - that some people do useful things and get useful information from the interfaces table MIB objects. > There is little to gain from this exercise if the SUPA policies do nothing without data model extensions. It seems I have to lower my expectations. /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 Wed Sep 9 09:15:32 2015 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C31AD1B3CC6 for ; Wed, 9 Sep 2015 09:15:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nvYOvg_LXfNb for ; Wed, 9 Sep 2015 09:15:29 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) (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 9C9A41B3BC2 for ; Wed, 9 Sep 2015 09:15:28 -0700 (PDT) Received: by lbpo4 with SMTP id o4so8668959lbp.2 for ; Wed, 09 Sep 2015 09:15:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=3c9gQ3NfrovFfjZ5A9RU7YkYj9iWXerHymWMH9Ix88w=; b=cKOUj00ycxHEBv2kQtPlO3QOl9dVHTw5oJxXh+SN58Pi+U9iVGmqDsdWWLl8Sx9L4O lgnHLysJqJSHDfQvx/RlnjH8BY5utZ6719XJBKI+k4taE8D7qCKTPU7HbSlAvbzZQxH9 3k5uVbVzACWDnHknm0UXdV0UgP4lOh5EbcPWVp1rtIm9ayY08gI8snsrt2+PfWKp4hwE fubWc9cQHkqAaXkJC9QtQHh8UdXc33xMiiiuQL1EMWqvh0PmAiswl6ctidAf4N77/NaN hzs/63xr1KoAR2Xrl9728A/LtK5kPE/sidBU4A7xH+x0/RrIRLi8xuT2KOyRP9eKau+M 1W1A== X-Gm-Message-State: ALoCoQk2aVLeL4hz9yRHZZSyHpeXk8raVDRuAnl53In9fn6IzmTAWQO43VDhqAP1dl8fUkUik2qQ MIME-Version: 1.0 X-Received: by 10.112.12.165 with SMTP id z5mr29849631lbb.33.1441815326656; Wed, 09 Sep 2015 09:15:26 -0700 (PDT) Received: by 10.112.200.104 with HTTP; Wed, 9 Sep 2015 09:15:26 -0700 (PDT) In-Reply-To: <20150909155437.GA35404@elstar.local> References: <55EDA48D.5040802@cisco.com> <20150908124021.GB32230@elstar.local> <9904FB1B0159DA42B0B887B7FA8119CA5CB1F2F0@AZ-FFEXMB04.global.avaya.com> <20150909155437.GA35404@elstar.local> Date: Wed, 9 Sep 2015 09:15:26 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , "Romascanu, Dan (Dan)" , Benoit Claise , "supa@ietf.org" Content-Type: multipart/alternative; boundary=001a11c3b83060a2a6051f52caee Archived-At: Subject: Re: [Supa] New SUPA charter text X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2015 16:15:31 -0000 --001a11c3b83060a2a6051f52caee Content-Type: text/plain; charset=UTF-8 On Wed, Sep 9, 2015 at 8:54 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Tue, Sep 08, 2015 at 06:55:01PM +0000, Romascanu, Dan (Dan) wrote: > > Hi, > > > > See in-text. > > > > Regards, > > > > Dan > > > > > > > -----Original Message----- > > > From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of Juergen > > > Schoenwaelder > > > Sent: Tuesday, September 08, 2015 3:40 PM > > > To: Benoit Claise > > > Cc: supa@ietf.org > > > Subject: Re: [Supa] New SUPA charter text > > > > > > On Mon, Sep 07, 2015 at 04:51:57PM +0200, Benoit Claise wrote: > > > > > > > > Please review > > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf. > > > > org_doc_charter-2Dietf- > > > 2Dsupa_&d=BQICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4d > > > > > > > zGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=FjFbmJya6x58nXbHAJ389 > > > Wd24wZ > > > > > > > U2zmjtIlRJFIAHB0&s=yGfhqxgu2nlg2EOrZwD3qlRzY9ykPQwO8IXMAc8KrFw& > > > e= > > > > version00-09ASAP, for any mistake. > > > > At this point, we passed the wordsmithing phase. > > > > > > > > > > It is unclear whether you want to have feedback or not. I will send it > anyway, > > > feel free to ignore since we 'passed the wordsmithing phase'. > > > > > > I have two comments: > > > > > > - It is unclear what SUPA is going to do regarding declarative > > > policies. The charter text says > > > > > > (iii) the working group will investigate the practically of > building policy > > > rules that declaratively specify what goals to achieve (this is > often called > > > "intent-based" policy) but not how to achieve those goals and may > create a > > > model > > > accordingly > > > > > > but it also says: > > > > > > Out of scope of this working group are: > > > [...] > > > - Declarative a.k.a intent-based policy rules. Another extension > for defining > > > policy rules according to a declarative, or intent-based, > paradigm, may be > > > produced in later phases of SUPA work. > > > > > > For me this is confusing but perhaps I just do not read the text in > > > the right way. > > > > > > > IMO - the text says that we can (continue to) investigate 'practicality' > as well as how to avoid conflict with work chartered in other WGs, but we > should not write a data model in the first phase of the WG. We may do this > 'in later phases'. > > > > Expecting a WG to "practically investigate" something that is clearly > declared to be out of scope for the WG still sounds like a > contradiction to me (and I also wonder what "practically investigate" > means). > > +1 WGs try to work on individual submission drafts, instead of declaring any official WG drafts, as a way of ignoring the charter. That's what "practically investigate" sounds like to me. > > - The other comment concerns this text: > > > > > > SUPA however will not deal with > > > the definition of the specific network configuration changes but > with how > > > the > > > configuration changes are applied (e.g. who is allowed to set > policies, when > > > and > > > how the policies are activated, changed or de-activated) > > > > > > Is SUPA going to work out how actions are specified and executed? > > > For example: Assuming the ACL YANG data model worked on in NETMOD, > > > will I be able to use SUPA policy data models without further data > > > models to populate my ACL lists? Or is the idea that SUPA only > > > provide a core framework that requires data model extensions to do > > > anything meaningful? Pretty much like the interfaces data model that > > > requires interface type specific extensions to be really useful. > > > > IMO - rather the later. Yet, I would observe - as you brought up the > example - that some people do useful things and get useful information from > the interfaces table MIB objects. > > > > There is little to gain from this exercise if the SUPA policies do > nothing without data model extensions. It seems I have to lower my > expectations. > It seems to me that speculating or worrying about the SUPA solution is not very useful. It is possible there is a good solution path within the restrictions of this charter text. I haven't seen one yet, but it might happen. I agree it would be bad if SUPA requires YANG modules to be altered in any way so they can be used in SUPA. But conceptual meta-data annotations done in SUPA configuration modules would be OK. > /js > > Andy > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > Supa mailing list > Supa@ietf.org > https://www.ietf.org/mailman/listinfo/supa > --001a11c3b83060a2a6051f52caee Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Sep 9, 2015 at 8:54 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Tue, Sep 08, 2015 at 06:55:01PM +0000, Romascanu, = Dan (Dan) wrote:
> Hi,
>
> See in-text.
>
> Regards,
>
> Dan
>
>
> > -----Original Message-----
> > From: Supa [mailto:supa-= bounces@ietf.org] On Behalf Of Juergen
> > Schoenwaelder
> > Sent: Tuesday, September 08, 2015 3:40 PM
> > To: Benoit Claise
> > Cc: supa@ietf.org
> > Subject: Re: [Supa] New SUPA charter text
> >
> > On Mon, Sep 07, 2015 at 04:51:57PM +0200, Benoit Claise wrote: > > >
> > > Please review
> > > https://urldef= ense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ietf.
> > > org_doc_charter-2Dietf-
> > 2Dsupa_&d=3DBQICAg&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DI4d=
> > >
> > zGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=3DFjFbmJya6x58nXbH= AJ389
> > Wd24wZ
> > >
> > U2zmjtIlRJFIAHB0&s=3DyGfhqxgu2nlg2EOrZwD3qlRzY9ykPQwO8IXMAc8K= rFw&
> > e=3D
> > > version00-09ASAP, for any mistake.
> > > At this point, we passed the wordsmithing phase.
> > >
> >
> > It is unclear whether you want to have feedback or not. I will se= nd it anyway,
> > feel free to ignore since we 'passed the wordsmithing phase&#= 39;.
> >
> > I have two comments:
> >
> > - It is unclear what SUPA is going to do regarding declarative > >=C2=A0 =C2=A0policies. The charter text says
> >
> >=C2=A0 =C2=A0 =C2=A0(iii) the working group will investigate the p= ractically of building policy
> >=C2=A0 =C2=A0 =C2=A0rules that declaratively specify what goals to= achieve (this is often called
> >=C2=A0 =C2=A0 =C2=A0"intent-based" policy) but not how t= o achieve those goals and may create a
> > model
> >=C2=A0 =C2=A0 =C2=A0accordingly
> >
> >=C2=A0 =C2=A0but it also says:
> >
> >=C2=A0 =C2=A0 =C2=A0Out of scope of this working group are:
> >=C2=A0 =C2=A0 =C2=A0[...]
> >=C2=A0 =C2=A0 =C2=A0- Declarative a.k.a intent-based policy rules.= Another extension for defining
> >=C2=A0 =C2=A0 =C2=A0policy rules according to a declarative, or in= tent-based, paradigm, may be
> >=C2=A0 =C2=A0 =C2=A0produced in later phases of SUPA work.
> >
> >=C2=A0 =C2=A0For me this is confusing but perhaps I just do not re= ad the text in
> >=C2=A0 =C2=A0the right way.
> >
>
> IMO - the text says that we can (continue to) investigate 'practic= ality' as well as how to avoid conflict with work chartered in other WG= s, but we should not write a data model in the first phase of the WG. We ma= y do this 'in later phases'.
>

Expecting a WG to "practically investigate" something that is cle= arly
declared to be out of scope for the WG still sounds like a
contradiction to me (and I also wonder what "practically investigate&q= uot;
means).


+1

WGs try to= work on individual submission drafts, instead of declaring any
o= fficial WG drafts, as a way of ignoring the charter.=C2=A0 That's what<= /div>
"practically investigate" sounds like to me.
=

> > - The other comment concerns this text:
> >
> >=C2=A0 =C2=A0 =C2=A0SUPA however will not deal with
> >=C2=A0 =C2=A0 =C2=A0the definition of the specific network configu= ration changes but with how
> > the
> >=C2=A0 =C2=A0 =C2=A0configuration changes are applied (e.g. who is= allowed to set policies, when
> > and
> >=C2=A0 =C2=A0 =C2=A0how the policies are activated, changed or de-= activated)
> >
> >=C2=A0 =C2=A0Is SUPA going to work out how actions are specified a= nd executed?
> >=C2=A0 =C2=A0For example: Assuming the ACL YANG data model worked = on in NETMOD,
> >=C2=A0 =C2=A0will I be able to use SUPA policy data models without= further data
> >=C2=A0 =C2=A0models to populate my ACL lists? Or is the idea that = SUPA only
> >=C2=A0 =C2=A0provide a core framework that requires data model ext= ensions to do
> >=C2=A0 =C2=A0anything meaningful? Pretty much like the interfaces = data model that
> >=C2=A0 =C2=A0requires interface type specific extensions to be rea= lly useful.
>
> IMO - rather the later. Yet, I would observe - as you brought up the e= xample - that some people do useful things and get useful information from = the interfaces table MIB objects.
>

There is little to gain from this exercise if the SUPA policies do
nothing without data model extensions. It seems I have to lower my
expectations.

It seems to me that specu= lating or worrying about the SUPA solution is not
very useful.=C2= =A0 It is possible there is a good solution path within the restrictions
of this charter text.=C2=A0 I haven't seen one yet, but it migh= t happen.
I agree it would be bad if SUPA requires YANG modules t= o be altered in any way
so they can be used in SUPA.=C2=A0 But co= nceptual meta-data annotations done in
SUPA configuration modules= would be OK.



/js


Andy
=C2=A0
--
Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer= sity Bremen gGmbH
Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28= 759 Bremen | Germany
Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<http://www.jacobs-university.de/>

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

--001a11c3b83060a2a6051f52caee-- From nobody Wed Sep 9 09:49:06 2015 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7471D1B3EA2 for ; Wed, 9 Sep 2015 09:49:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mo3Eeh1l_2cM for ; Wed, 9 Sep 2015 09:49:03 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4143D1B3EAB for ; Wed, 9 Sep 2015 09:49:03 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2ABBQBBP8ZV/xUHmMZbGQEBAYJTLFRpBqluBpU7hgECgSY8EAEBAQEBAQGBCoQjAQEBAQMSKDIKAwwEAgEIDQECAQQBAQEKFAkHMhQJCAIEDgUIGogMAax4oD4BAQEBAQEBAwEBAQEBAQEBAQEBF4YfhTKEWDEHBoMSgRQFlQsBhQGCaYZBRoZqDJB4Fw+CDhyBU2+BSIEEAQEB X-IPAS-Result: A2ABBQBBP8ZV/xUHmMZbGQEBAYJTLFRpBqluBpU7hgECgSY8EAEBAQEBAQGBCoQjAQEBAQMSKDIKAwwEAgEIDQECAQQBAQEKFAkHMhQJCAIEDgUIGogMAax4oD4BAQEBAQEBAwEBAQEBAQEBAQEBF4YfhTKEWDEHBoMSgRQFlQsBhQGCaYZBRoZqDJB4Fw+CDhyBU2+BSIEEAQEB X-IronPort-AV: E=Sophos;i="5.15,634,1432612800"; d="scan'208";a="119407457" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by de307622-de-outbound.net.avaya.com with ESMTP; 09 Sep 2015 12:49:00 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 09 Sep 2015 12:49:00 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC01.global.avaya.com ([135.64.58.11]) with mapi id 14.03.0174.001; Wed, 9 Sep 2015 18:48:58 +0200 From: "Romascanu, Dan (Dan)" To: Juergen Schoenwaelder Thread-Topic: [Supa] New SUPA charter text Thread-Index: AQHQ6jORZ99PaEMmBECww1YKzmmiNJ4y+gowgAE/sICAAC0JMA== Date: Wed, 9 Sep 2015 16:48:57 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5CB20086@AZ-FFEXMB04.global.avaya.com> References: <55EDA48D.5040802@cisco.com> <20150908124021.GB32230@elstar.local> <9904FB1B0159DA42B0B887B7FA8119CA5CB1F2F0@AZ-FFEXMB04.global.avaya.com> <20150909155437.GA35404@elstar.local> In-Reply-To: <20150909155437.GA35404@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.47] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Benoit Claise , "supa@ietf.org" Subject: Re: [Supa] New SUPA charter text X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2015 16:49:05 -0000 Hi, See in-line.=20 Regards, Dan > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > university.de] > Sent: Wednesday, September 09, 2015 6:55 PM > To: Romascanu, Dan (Dan) > Cc: Benoit Claise; supa@ietf.org > Subject: Re: [Supa] New SUPA charter text >=20 > On Tue, Sep 08, 2015 at 06:55:01PM +0000, Romascanu, Dan (Dan) wrote: > > Hi, > > > > See in-text. > > > > Regards, > > > > Dan > > > > > > > -----Original Message----- > > > From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of Juergen > > > Schoenwaelder > > > Sent: Tuesday, September 08, 2015 3:40 PM > > > To: Benoit Claise > > > Cc: supa@ietf.org > > > Subject: Re: [Supa] New SUPA charter text > > > > > > On Mon, Sep 07, 2015 at 04:51:57PM +0200, Benoit Claise wrote: > > > > > > > > At this point, we passed the wordsmithing phase. > > > > > > > > > > It is unclear whether you want to have feedback or not. I will send > > > it anyway, feel free to ignore since we 'passed the wordsmithing phas= e'. > > > > > > I have two comments: > > > > > > - It is unclear what SUPA is going to do regarding declarative > > > policies. The charter text says > > > > > > (iii) the working group will investigate the practically of build= ing policy > > > rules that declaratively specify what goals to achieve (this is o= ften called > > > "intent-based" policy) but not how to achieve those goals and > > > may create a model > > > accordingly > > > > > > but it also says: > > > > > > Out of scope of this working group are: > > > [...] > > > - Declarative a.k.a intent-based policy rules. Another extension = for > defining > > > policy rules according to a declarative, or intent-based, paradig= m, may > be > > > produced in later phases of SUPA work. > > > > > > For me this is confusing but perhaps I just do not read the text in > > > the right way. > > > > > > > IMO - the text says that we can (continue to) investigate 'practicality= ' as > well as how to avoid conflict with work chartered in other WGs, but we > should not write a data model in the first phase of the WG. We may do thi= s > 'in later phases'. > > >=20 > Expecting a WG to "practically investigate" something that is clearly dec= lared > to be out of scope for the WG still sounds like a contradiction to me (an= d I > also wonder what "practically investigate" > means). >=20 It's not declared to be out of scope for the WG. Quite the opposite - it se= ems to me that there is an agreement that declarative / intent-based policy= rules are within the scope of the IETF work. What we did not agree is that= we do them in the first phase, and also how we differentiate from similar = or similarly labelled work in other IETF WGs or WGs-to-be. In order not to = get stuck while attending the resolution of this issue, the charter propose= s to start work in SUPA but delay the definition of the declarative/intent-= based policy rules for a later phase.=20 > > > - The other comment concerns this text: > > > > > > SUPA however will not deal with > > > the definition of the specific network configuration changes but > > > with how the > > > configuration changes are applied (e.g. who is allowed to set > > > policies, when and > > > how the policies are activated, changed or de-activated) > > > > > > Is SUPA going to work out how actions are specified and executed? > > > For example: Assuming the ACL YANG data model worked on in > NETMOD, > > > will I be able to use SUPA policy data models without further data > > > models to populate my ACL lists? Or is the idea that SUPA only > > > provide a core framework that requires data model extensions to do > > > anything meaningful? Pretty much like the interfaces data model tha= t > > > requires interface type specific extensions to be really useful. > > > > IMO - rather the later. Yet, I would observe - as you brought up the > example - that some people do useful things and get useful information fr= om > the interfaces table MIB objects. > > >=20 > There is little to gain from this exercise if the SUPA policies do nothin= g > without data model extensions. It seems I have to lower my expectations. >=20 Let us create the expectations as we do the work. This is just charter text= - and we want it approved - the results will be seen when the models are a= pproved.=20 > /js >=20 > -- From nobody Wed Sep 9 10:03:05 2015 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 861681ACE3F for ; Wed, 9 Sep 2015 10:03:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oYPEYAvU0oCv for ; Wed, 9 Sep 2015 10:03:02 -0700 (PDT) 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 4F3EE1ACE0C for ; Wed, 9 Sep 2015 10:03:02 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 1ABC42E36; Wed, 9 Sep 2015 19:03:01 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id z86i2GlXv68n; Wed, 9 Sep 2015 19:02:59 +0200 (CEST) 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; Wed, 9 Sep 2015 19:02:59 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3D56C2004E; Wed, 9 Sep 2015 19:02:59 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id dsGgac-61R3e; Wed, 9 Sep 2015 19:02:57 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9C5B320048; Wed, 9 Sep 2015 19:02:56 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 4E6CF3705CB0; Wed, 9 Sep 2015 19:02:53 +0200 (CEST) Date: Wed, 9 Sep 2015 19:02:52 +0200 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Message-ID: <20150909170252.GA35618@elstar.local> Mail-Followup-To: "Romascanu, Dan (Dan)" , Benoit Claise , "supa@ietf.org" References: <55EDA48D.5040802@cisco.com> <20150908124021.GB32230@elstar.local> <9904FB1B0159DA42B0B887B7FA8119CA5CB1F2F0@AZ-FFEXMB04.global.avaya.com> <20150909155437.GA35404@elstar.local> <9904FB1B0159DA42B0B887B7FA8119CA5CB20086@AZ-FFEXMB04.global.avaya.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA5CB20086@AZ-FFEXMB04.global.avaya.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: Benoit Claise , "supa@ietf.org" Subject: Re: [Supa] New SUPA charter text X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2015 17:03:04 -0000 On Wed, Sep 09, 2015 at 04:48:57PM +0000, Romascanu, Dan (Dan) wrote: > Hi, > > See in-line. > > Regards, > > Dan > > > > -----Original Message----- > > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > > university.de] > > Sent: Wednesday, September 09, 2015 6:55 PM > > To: Romascanu, Dan (Dan) > > Cc: Benoit Claise; supa@ietf.org > > Subject: Re: [Supa] New SUPA charter text > > > > On Tue, Sep 08, 2015 at 06:55:01PM +0000, Romascanu, Dan (Dan) wrote: > > > Hi, > > > > > > See in-text. > > > > > > Regards, > > > > > > Dan > > > > > > > > > > -----Original Message----- > > > > From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of Juergen > > > > Schoenwaelder > > > > Sent: Tuesday, September 08, 2015 3:40 PM > > > > To: Benoit Claise > > > > Cc: supa@ietf.org > > > > Subject: Re: [Supa] New SUPA charter text > > > > > > > > On Mon, Sep 07, 2015 at 04:51:57PM +0200, Benoit Claise wrote: > > > > > > > > > > > > > At this point, we passed the wordsmithing phase. > > > > > > > > > > > > > It is unclear whether you want to have feedback or not. I will send > > > > it anyway, feel free to ignore since we 'passed the wordsmithing phase'. > > > > > > > > I have two comments: > > > > > > > > - It is unclear what SUPA is going to do regarding declarative > > > > policies. The charter text says > > > > > > > > (iii) the working group will investigate the practically of building policy > > > > rules that declaratively specify what goals to achieve (this is often called > > > > "intent-based" policy) but not how to achieve those goals and > > > > may create a model > > > > accordingly > > > > > > > > but it also says: > > > > > > > > Out of scope of this working group are: > > > > [...] > > > > - Declarative a.k.a intent-based policy rules. Another extension for > > defining > > > > policy rules according to a declarative, or intent-based, paradigm, may > > be > > > > produced in later phases of SUPA work. > > > > > > > > For me this is confusing but perhaps I just do not read the text in > > > > the right way. > > > > > > > > > > IMO - the text says that we can (continue to) investigate 'practicality' as > > well as how to avoid conflict with work chartered in other WGs, but we > > should not write a data model in the first phase of the WG. We may do this > > 'in later phases'. > > > > > > > Expecting a WG to "practically investigate" something that is clearly declared > > to be out of scope for the WG still sounds like a contradiction to me (and I > > also wonder what "practically investigate" > > means). > > > > It's not declared to be out of scope for the WG. Quite the opposite - it seems to me that there is an agreement that declarative / intent-based policy rules are within the scope of the IETF work. What we did not agree is that we do them in the first phase, and also how we differentiate from similar or similarly labelled work in other IETF WGs or WGs-to-be. In order not to get stuck while attending the resolution of this issue, the charter proposes to start work in SUPA but delay the definition of the declarative/intent-based policy rules for a later phase. > I still find the text confusing and I wished it would not require interpretation to be understood the right way. > > > > - The other comment concerns this text: > > > > > > > > SUPA however will not deal with > > > > the definition of the specific network configuration changes but > > > > with how the > > > > configuration changes are applied (e.g. who is allowed to set > > > > policies, when and > > > > how the policies are activated, changed or de-activated) > > > > > > > > Is SUPA going to work out how actions are specified and executed? > > > > For example: Assuming the ACL YANG data model worked on in > > NETMOD, > > > > will I be able to use SUPA policy data models without further data > > > > models to populate my ACL lists? Or is the idea that SUPA only > > > > provide a core framework that requires data model extensions to do > > > > anything meaningful? Pretty much like the interfaces data model that > > > > requires interface type specific extensions to be really useful. > > > > > > IMO - rather the later. Yet, I would observe - as you brought up the > > example - that some people do useful things and get useful information from > > the interfaces table MIB objects. > > > > > > > There is little to gain from this exercise if the SUPA policies do nothing > > without data model extensions. It seems I have to lower my expectations. > > > > Let us create the expectations as we do the work. This is just charter text - and we want it approved - the results will be seen when the models are approved. > OK. I will shut up and then look at the results when the models are approved. /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 Wed Sep 9 10:05:30 2015 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DF781B3F02 for ; Wed, 9 Sep 2015 10:05:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R9QbJiAufAQs for ; Wed, 9 Sep 2015 10:05:27 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC5831B3B59 for ; Wed, 9 Sep 2015 10:05:26 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2ABBQA3Q8ZV/yYyC4dbGQEBAYJTLFRpBqluBpU7hgECgSY8EAEBAQEBAQGBCoQjAQEBAQIBEig/DAQCAQgNAQIBBAEBAQoUCQcyFAkIAgQOBQgaiAQIAax1oDoBAQEBAQEBAwEBAQEBAQEBARmGH4UyhFgxBwaDEoEUBZULAYUBgmmGQUaGagyQeBcPgg4cgVNvgUiBBAEBAQ X-IPAS-Result: A2ABBQA3Q8ZV/yYyC4dbGQEBAYJTLFRpBqluBpU7hgECgSY8EAEBAQEBAQGBCoQjAQEBAQIBEig/DAQCAQgNAQIBBAEBAQoUCQcyFAkIAgQOBQgaiAQIAax1oDoBAQEBAQEBAwEBAQEBAQEBARmGH4UyhFgxBwaDEoEUBZULAYUBgmmGQUaGagyQeBcPgg4cgVNvgUiBBAEBAQ X-IronPort-AV: E=Sophos;i="5.15,634,1432612800"; d="scan'208";a="140372987" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 09 Sep 2015 13:05:26 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES128-SHA; 09 Sep 2015 13:05:25 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC02.global.avaya.com ([135.64.58.12]) with mapi id 14.03.0174.001; Wed, 9 Sep 2015 19:05:23 +0200 From: "Romascanu, Dan (Dan)" To: Juergen Schoenwaelder Thread-Topic: [Supa] New SUPA charter text Thread-Index: AQHQ6jORZ99PaEMmBECww1YKzmmiNJ4y+gowgAE/sICAAC0JMP//5ggAgAAh3MA= Date: Wed, 9 Sep 2015 17:05:22 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5CB200B6@AZ-FFEXMB04.global.avaya.com> References: <55EDA48D.5040802@cisco.com> <20150908124021.GB32230@elstar.local> <9904FB1B0159DA42B0B887B7FA8119CA5CB1F2F0@AZ-FFEXMB04.global.avaya.com> <20150909155437.GA35404@elstar.local> <9904FB1B0159DA42B0B887B7FA8119CA5CB20086@AZ-FFEXMB04.global.avaya.com> <20150909170252.GA35618@elstar.local> In-Reply-To: <20150909170252.GA35618@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.47] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Benoit Claise , "supa@ietf.org" Subject: Re: [Supa] New SUPA charter text X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2015 17:05:28 -0000 > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > university.de] > Sent: Wednesday, September 09, 2015 8:03 PM > To: Romascanu, Dan (Dan) > Cc: Benoit Claise; supa@ietf.org > Subject: Re: [Supa] New SUPA charter text >=20 > On Wed, Sep 09, 2015 at 04:48:57PM +0000, Romascanu, Dan (Dan) wrote: > > Hi, > > > > See in-line. > > > > Regards, > > > > Dan > > > > > > > -----Original Message----- > > > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > > > university.de] > > > Sent: Wednesday, September 09, 2015 6:55 PM > > > To: Romascanu, Dan (Dan) > > > Cc: Benoit Claise; supa@ietf.org > > > Subject: Re: [Supa] New SUPA charter text > > > > > > On Tue, Sep 08, 2015 at 06:55:01PM +0000, Romascanu, Dan (Dan) wrote: > > > > Hi, > > > > > > > > See in-text. > > > > > > > > Regards, > > > > > > > > Dan > > > > > > > > > > > > > -----Original Message----- > > > > > From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of Juergen > > > > > Schoenwaelder > > > > > Sent: Tuesday, September 08, 2015 3:40 PM > > > > > To: Benoit Claise > > > > > Cc: supa@ietf.org > > > > > Subject: Re: [Supa] New SUPA charter text > > > > > > > > > > On Mon, Sep 07, 2015 at 04:51:57PM +0200, Benoit Claise wrote: > > > > > > > > > > > > > > > > > > At this point, we passed the wordsmithing phase. > > > > > > > > > > > > > > > > It is unclear whether you want to have feedback or not. I will > > > > > send it anyway, feel free to ignore since we 'passed the wordsmit= hing > phase'. > > > > > > > > > > I have two comments: > > > > > > > > > > - It is unclear what SUPA is going to do regarding declarative > > > > > policies. The charter text says > > > > > > > > > > (iii) the working group will investigate the practically of b= uilding > policy > > > > > rules that declaratively specify what goals to achieve (this = is often > called > > > > > "intent-based" policy) but not how to achieve those goals > > > > > and may create a model > > > > > accordingly > > > > > > > > > > but it also says: > > > > > > > > > > Out of scope of this working group are: > > > > > [...] > > > > > - Declarative a.k.a intent-based policy rules. Another > > > > > extension for > > > defining > > > > > policy rules according to a declarative, or intent-based, > > > > > paradigm, may > > > be > > > > > produced in later phases of SUPA work. > > > > > > > > > > For me this is confusing but perhaps I just do not read the tex= t in > > > > > the right way. > > > > > > > > > > > > > IMO - the text says that we can (continue to) investigate > > > > 'practicality' as > > > well as how to avoid conflict with work chartered in other WGs, but > > > we should not write a data model in the first phase of the WG. We > > > may do this 'in later phases'. > > > > > > > > > > Expecting a WG to "practically investigate" something that is > > > clearly declared to be out of scope for the WG still sounds like a > > > contradiction to me (and I also wonder what "practically investigate" > > > means). > > > > > > > It's not declared to be out of scope for the WG. Quite the opposite - i= t > seems to me that there is an agreement that declarative / intent-based > policy rules are within the scope of the IETF work. What we did not agree= is > that we do them in the first phase, and also how we differentiate from > similar or similarly labelled work in other IETF WGs or WGs-to-be. In ord= er not > to get stuck while attending the resolution of this issue, the charter pr= oposes > to start work in SUPA but delay the definition of the declarative/intent-= based > policy rules for a later phase. > > >=20 > I still find the text confusing and I wished it would not require interpr= etation > to be understood the right way. >=20 Ignoring Benoit's advice (' At this point, we passed the wordsmithing phase= ') - can you suggest the edits that would make the text clear with no need = of interpretation?=20 Thanks and Regards, Dan From nobody Thu Sep 10 01:02:11 2015 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4D171B2B5D for ; Thu, 10 Sep 2015 01:02:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9fx4ZQlwsQ9p for ; Thu, 10 Sep 2015 01:02:06 -0700 (PDT) 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 5E9AD1B55BE for ; Thu, 10 Sep 2015 01:02:06 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 0F93810AE; Thu, 10 Sep 2015 10:02:05 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id YxShvLlPGgJC; Thu, 10 Sep 2015 10:02:02 +0200 (CEST) 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; Thu, 10 Sep 2015 10:02:02 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3662820060; Thu, 10 Sep 2015 10:02:02 +0200 (CEST) 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 oRGZwdrWp8QW; Thu, 10 Sep 2015 10:01:59 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 65D792005F; Thu, 10 Sep 2015 10:01:59 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 0502F370620B; Thu, 10 Sep 2015 10:01:55 +0200 (CEST) Date: Thu, 10 Sep 2015 10:01:55 +0200 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Message-ID: <20150910080155.GC37020@elstar.local> Mail-Followup-To: "Romascanu, Dan (Dan)" , Benoit Claise , "supa@ietf.org" References: <55EDA48D.5040802@cisco.com> <20150908124021.GB32230@elstar.local> <9904FB1B0159DA42B0B887B7FA8119CA5CB1F2F0@AZ-FFEXMB04.global.avaya.com> <20150909155437.GA35404@elstar.local> <9904FB1B0159DA42B0B887B7FA8119CA5CB20086@AZ-FFEXMB04.global.avaya.com> <20150909170252.GA35618@elstar.local> <9904FB1B0159DA42B0B887B7FA8119CA5CB200B6@AZ-FFEXMB04.global.avaya.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA5CB200B6@AZ-FFEXMB04.global.avaya.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: Benoit Claise , "supa@ietf.org" Subject: Re: [Supa] New SUPA charter text X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2015 08:02:08 -0000 On Wed, Sep 09, 2015 at 05:05:22PM +0000, Romascanu, Dan (Dan) wrote: > > > > -----Original Message----- > > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > > university.de] > > Sent: Wednesday, September 09, 2015 8:03 PM > > To: Romascanu, Dan (Dan) > > Cc: Benoit Claise; supa@ietf.org > > Subject: Re: [Supa] New SUPA charter text > > > > On Wed, Sep 09, 2015 at 04:48:57PM +0000, Romascanu, Dan (Dan) wrote: > > > Hi, > > > > > > See in-line. > > > > > > Regards, > > > > > > Dan > > > > > > > > > > -----Original Message----- > > > > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > > > > university.de] > > > > Sent: Wednesday, September 09, 2015 6:55 PM > > > > To: Romascanu, Dan (Dan) > > > > Cc: Benoit Claise; supa@ietf.org > > > > Subject: Re: [Supa] New SUPA charter text > > > > > > > > On Tue, Sep 08, 2015 at 06:55:01PM +0000, Romascanu, Dan (Dan) wrote: > > > > > Hi, > > > > > > > > > > See in-text. > > > > > > > > > > Regards, > > > > > > > > > > Dan > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of Juergen > > > > > > Schoenwaelder > > > > > > Sent: Tuesday, September 08, 2015 3:40 PM > > > > > > To: Benoit Claise > > > > > > Cc: supa@ietf.org > > > > > > Subject: Re: [Supa] New SUPA charter text > > > > > > > > > > > > On Mon, Sep 07, 2015 at 04:51:57PM +0200, Benoit Claise wrote: > > > > > > > > > > > > > > > > > > > > > > > At this point, we passed the wordsmithing phase. > > > > > > > > > > > > > > > > > > > It is unclear whether you want to have feedback or not. I will > > > > > > send it anyway, feel free to ignore since we 'passed the wordsmithing > > phase'. > > > > > > > > > > > > I have two comments: > > > > > > > > > > > > - It is unclear what SUPA is going to do regarding declarative > > > > > > policies. The charter text says > > > > > > > > > > > > (iii) the working group will investigate the practically of building > > policy > > > > > > rules that declaratively specify what goals to achieve (this is often > > called > > > > > > "intent-based" policy) but not how to achieve those goals > > > > > > and may create a model > > > > > > accordingly > > > > > > > > > > > > but it also says: > > > > > > > > > > > > Out of scope of this working group are: > > > > > > [...] > > > > > > - Declarative a.k.a intent-based policy rules. Another > > > > > > extension for > > > > defining > > > > > > policy rules according to a declarative, or intent-based, > > > > > > paradigm, may > > > > be > > > > > > produced in later phases of SUPA work. > > > > > > > > > > > > For me this is confusing but perhaps I just do not read the text in > > > > > > the right way. > > > > > > > > > > > > > > > > IMO - the text says that we can (continue to) investigate > > > > > 'practicality' as > > > > well as how to avoid conflict with work chartered in other WGs, but > > > > we should not write a data model in the first phase of the WG. We > > > > may do this 'in later phases'. > > > > > > > > > > > > > Expecting a WG to "practically investigate" something that is > > > > clearly declared to be out of scope for the WG still sounds like a > > > > contradiction to me (and I also wonder what "practically investigate" > > > > means). > > > > > > > > > > It's not declared to be out of scope for the WG. Quite the opposite - it > > seems to me that there is an agreement that declarative / intent-based > > policy rules are within the scope of the IETF work. What we did not agree is > > that we do them in the first phase, and also how we differentiate from > > similar or similarly labelled work in other IETF WGs or WGs-to-be. In order not > > to get stuck while attending the resolution of this issue, the charter proposes > > to start work in SUPA but delay the definition of the declarative/intent-based > > policy rules for a later phase. > > > > > > > I still find the text confusing and I wished it would not require interpretation > > to be understood the right way. > > > > Ignoring Benoit's advice (' At this point, we passed the wordsmithing phase') - can you suggest the edits that would make the text clear with no need of interpretation? > If the intent is that SUPA is not working on declarative policies until the IETF has settled where to entertain such work, then simply state it that way. That is, remove (iii) from the 6th paragraph and the last item from the list of things that are out of scope and add a new paragraph that say something along these lines: Declarative policies that specify the goals to achieve but not how to achieve those goals (also called "intent-based" policies) are out of scope for the initial phase of SUPA but may be considered in future phases of SUPA. I think this is clearer and avoids the tension between the different paragraphs we have in the current charter text. /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 Thu Sep 10 17:05:53 2015 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ABBE1B3B4C for ; Thu, 10 Sep 2015 17:05:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hUStmUgCcx5j for ; Thu, 10 Sep 2015 17:05:50 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 296C51B36F9 for ; Thu, 10 Sep 2015 17:05:50 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BXM01954; Fri, 11 Sep 2015 00:05:47 +0000 (GMT) Received: from SZXEML430-HUB.china.huawei.com (10.82.67.185) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 11 Sep 2015 01:05:46 +0100 Received: from szxeml557-mbs.china.huawei.com ([169.254.6.212]) by szxeml430-hub.china.huawei.com ([10.82.67.185]) with mapi id 14.03.0235.001; Fri, 11 Sep 2015 08:05:42 +0800 From: Tina TSOU To: "supa@ietf.org" Thread-Topic: draft-vadrevu-supa-applicability-04 Thread-Index: AdDsJZiMW2/NdwxWTimXfF6qld77NQ== Date: Fri, 11 Sep 2015 00:05:41 +0000 Message-ID: <996DD7EC-26BB-4666-AB14-3832A5D76ADA@huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: <2D58B193F20C5B46AD698F0D6B6CE7FC@huawei.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Supa] draft-vadrevu-supa-applicability-04 X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2015 00:05:52 -0000 Dear all, Just saw a new revision. For your reading pleasure. https://www.ietf.org/id/draft-vadrevu-supa-applicability-04.txt Thank you, Tina From nobody Fri Sep 11 06:15:26 2015 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE8D81A9174 for ; Fri, 11 Sep 2015 06:15:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qBEfLTd71wU7 for ; Fri, 11 Sep 2015 06:15:21 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9DE21B34F1 for ; Fri, 11 Sep 2015 06:15:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16084; q=dns/txt; s=iport; t=1441977311; x=1443186911; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=FVQ1p44IHG/YIp3j36PDnlUtB1dAkwitg8Kiw02hje8=; b=RZagyJ0HAiKFW9q8jt7W9vdPd6AHcqY6c5ao4CZKEMeGOZMAyuxHY79w eWK4yP8bzWZVNrkrv5TB0wfA2Z5gTiF0HT4oUS6oFV7dgu8uDGqVcQza2 vfbwqRiPO9j6gQiqtH1BntqptXvsDSZxNJbsLWaATC5BhYPbE3JC5qL4z o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CeBAC90vJV/xbLJq1dg3dpvziFeQKCHwEBAQEBAYELhCMBAQEEeA0ECxABBAEBAQkWCAcJAwIBAgE0CQgGAQwGAgEBiCoNzAgBAQEBAQEBAQEBAQEBAQEBAQEBAQEXhnOEfYQqEQFNCwaEJgEElVaFCoJthQOBTEaGaiORWmOCEByBVjwziGCBPwEBAQ X-IronPort-AV: E=Sophos;i="5.17,511,1437436800"; d="scan'208,217";a="605057517" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Sep 2015 13:15:08 +0000 Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t8BDF7kS002165; Fri, 11 Sep 2015 13:15:08 GMT To: "Romascanu, Dan (Dan)" , "supa@ietf.org" References: <55EDA48D.5040802@cisco.com> <20150908124021.GB32230@elstar.local> <9904FB1B0159DA42B0B887B7FA8119CA5CB1F2F0@AZ-FFEXMB04.global.avaya.com> <20150909155437.GA35404@elstar.local> <9904FB1B0159DA42B0B887B7FA8119CA5CB20086@AZ-FFEXMB04.global.avaya.com> <20150909170252.GA35618@elstar.local> <9904FB1B0159DA42B0B887B7FA8119CA5CB200B6@AZ-FFEXMB04.global.avaya.com> <20150910080155.GC37020@elstar.local> From: Benoit Claise Message-ID: <55F2D3DB.1080802@cisco.com> Date: Fri, 11 Sep 2015 15:15:07 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20150910080155.GC37020@elstar.local> Content-Type: multipart/alternative; boundary="------------050504030403080505070002" Archived-At: Subject: Re: [Supa] New SUPA charter text - declarative X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2015 13:15:24 -0000 This is a multi-part message in MIME format. --------------050504030403080505070002 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Dear all, Based on https://github.com/IETF-SUPA/SUPA/wiki/Charter-Diff, and specifically "Aug 2016 Discuss with the IESG possible re-chartering, including a YANG data model for defining policy rules according to a declarative, or intent-based, paradigm", I adapted the charter (version 00-09) I understand the concern discussed in this email thread, specifically the two sentences (iii) the working group will investigate the practically of building policy rules that declaratively specify what goals to achieve (this is often called "intent-based" policy) but not how to achieve those goals and may create a model accordingly ... Out of scope of this working group are: [...] - Declarative a.k.a intent-based policy rules. Another extension for defining policy rules according to a declarative, or intent-based, paradigm, may be produced in later phases of SUPA work. The confusion comes from "and may create a model accordingly" in the first sentence. I've followed Jürgen and John's advice to remove the two pieces of text. And I have incorporated Jürgen's new proposal. Thanks Jürgen, it makes the charter clearer. The charter is on the IESG telechat next Thursday for external review approval. Regards, Benoit > On Wed, Sep 09, 2015 at 05:05:22PM +0000, Romascanu, Dan (Dan) wrote: >> >>> -----Original Message----- >>> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- >>> university.de] >>> Sent: Wednesday, September 09, 2015 8:03 PM >>> To: Romascanu, Dan (Dan) >>> Cc: Benoit Claise; supa@ietf.org >>> Subject: Re: [Supa] New SUPA charter text >>> >>> On Wed, Sep 09, 2015 at 04:48:57PM +0000, Romascanu, Dan (Dan) wrote: >>>> Hi, >>>> >>>> See in-line. >>>> >>>> Regards, >>>> >>>> Dan >>>> >>>> >>>>> -----Original Message----- >>>>> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- >>>>> university.de] >>>>> Sent: Wednesday, September 09, 2015 6:55 PM >>>>> To: Romascanu, Dan (Dan) >>>>> Cc: Benoit Claise; supa@ietf.org >>>>> Subject: Re: [Supa] New SUPA charter text >>>>> >>>>> On Tue, Sep 08, 2015 at 06:55:01PM +0000, Romascanu, Dan (Dan) wrote: >>>>>> Hi, >>>>>> >>>>>> See in-text. >>>>>> >>>>>> Regards, >>>>>> >>>>>> Dan >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of Juergen >>>>>>> Schoenwaelder >>>>>>> Sent: Tuesday, September 08, 2015 3:40 PM >>>>>>> To: Benoit Claise >>>>>>> Cc: supa@ietf.org >>>>>>> Subject: Re: [Supa] New SUPA charter text >>>>>>> >>>>>>> On Mon, Sep 07, 2015 at 04:51:57PM +0200, Benoit Claise wrote: >>>> >>>> >>>>>>>> At this point, we passed the wordsmithing phase. >>>>>>>> >>>>>>> It is unclear whether you want to have feedback or not. I will >>>>>>> send it anyway, feel free to ignore since we 'passed the wordsmithing >>> phase'. >>>>>>> I have two comments: >>>>>>> >>>>>>> - It is unclear what SUPA is going to do regarding declarative >>>>>>> policies. The charter text says >>>>>>> >>>>>>> (iii) the working group will investigate the practically of building >>> policy >>>>>>> rules that declaratively specify what goals to achieve (this is often >>> called >>>>>>> "intent-based" policy) but not how to achieve those goals >>>>>>> and may create a model >>>>>>> accordingly >>>>>>> >>>>>>> but it also says: >>>>>>> >>>>>>> Out of scope of this working group are: >>>>>>> [...] >>>>>>> - Declarative a.k.a intent-based policy rules. Another >>>>>>> extension for >>>>> defining >>>>>>> policy rules according to a declarative, or intent-based, >>>>>>> paradigm, may >>>>> be >>>>>>> produced in later phases of SUPA work. >>>>>>> >>>>>>> For me this is confusing but perhaps I just do not read the text in >>>>>>> the right way. >>>>>>> >>>>>> IMO - the text says that we can (continue to) investigate >>>>>> 'practicality' as >>>>> well as how to avoid conflict with work chartered in other WGs, but >>>>> we should not write a data model in the first phase of the WG. We >>>>> may do this 'in later phases'. >>>>> Expecting a WG to "practically investigate" something that is >>>>> clearly declared to be out of scope for the WG still sounds like a >>>>> contradiction to me (and I also wonder what "practically investigate" >>>>> means). >>>>> >>>> It's not declared to be out of scope for the WG. Quite the opposite - it >>> seems to me that there is an agreement that declarative / intent-based >>> policy rules are within the scope of the IETF work. What we did not agree is >>> that we do them in the first phase, and also how we differentiate from >>> similar or similarly labelled work in other IETF WGs or WGs-to-be. In order not >>> to get stuck while attending the resolution of this issue, the charter proposes >>> to start work in SUPA but delay the definition of the declarative/intent-based >>> policy rules for a later phase. >>> I still find the text confusing and I wished it would not require interpretation >>> to be understood the right way. >>> >> Ignoring Benoit's advice (' At this point, we passed the wordsmithing phase') - can you suggest the edits that would make the text clear with no need of interpretation? >> > If the intent is that SUPA is not working on declarative policies > until the IETF has settled where to entertain such work, then simply > state it that way. That is, remove (iii) from the 6th paragraph and > the last item from the list of things that are out of scope and add a > new paragraph that say something along these lines: > > Declarative policies that specify the goals to achieve but not how > to achieve those goals (also called "intent-based" policies) are out > of scope for the initial phase of SUPA but may be considered in > future phases of SUPA. > > I think this is clearer and avoids the tension between the different > paragraphs we have in the current charter text. > > /js > --------------050504030403080505070002 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Dear all,

Based on https://github.com/IETF-SUPA/SUPA/wiki/Charter-Diff, and specifically "Aug 2016 Discuss with the IESG possible re-chartering, including a YANG data model for defining policy rules according to a declarative, or intent-based, paradigm",  I adapted the charter (version 00-09)

I understand the concern discussed in this email thread, specifically the two sentences
    (iii) the working group will investigate the practically of building policy
    rules that declaratively specify what goals to achieve (this is often called
    "intent-based" policy) but not how to achieve those goals and may create a model
    accordingly

  ...

    Out of scope of this working group are:
    [...]
    - Declarative a.k.a intent-based policy rules. Another extension for defining
    policy rules according to a declarative, or intent-based, paradigm, may be
    produced in later phases of SUPA work.
The confusion comes from "and may create a model accordingly" in the first sentence.

I've followed Jürgen and John's advice to remove the two pieces of text.
And I have incorporated Jürgen's new proposal. Thanks Jürgen, it makes the charter clearer.

The charter is on the IESG telechat next Thursday for external review approval.

Regards, Benoit
On Wed, Sep 09, 2015 at 05:05:22PM +0000, Romascanu, Dan (Dan) wrote:



-----Original Message-----
From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-
university.de]
Sent: Wednesday, September 09, 2015 8:03 PM
To: Romascanu, Dan (Dan)
Cc: Benoit Claise; supa@ietf.org
Subject: Re: [Supa] New SUPA charter text

On Wed, Sep 09, 2015 at 04:48:57PM +0000, Romascanu, Dan (Dan) wrote:

Hi,

See in-line.

Regards,

Dan



-----Original Message-----
From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-
university.de]
Sent: Wednesday, September 09, 2015 6:55 PM
To: Romascanu, Dan (Dan)
Cc: Benoit Claise; supa@ietf.org
Subject: Re: [Supa] New SUPA charter text

On Tue, Sep 08, 2015 at 06:55:01PM +0000, Romascanu, Dan (Dan) wrote:

Hi,

See in-text.

Regards,

Dan



-----Original Message-----
From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of Juergen
Schoenwaelder
Sent: Tuesday, September 08, 2015 3:40 PM
To: Benoit Claise
Cc: supa@ietf.org
Subject: Re: [Supa] New SUPA charter text

On Mon, Sep 07, 2015 at 04:51:57PM +0200, Benoit Claise wrote:


                  

                

              

            

            




            

              

                

                  

                    
At this point, we passed the wordsmithing phase.



                  

                  
It is unclear whether you want to have feedback or not. I will
send it anyway, feel free to ignore since we 'passed the wordsmithing


                

              

            

          

          
phase'.


          

            

              

                

                  
I have two comments:

- It is unclear what SUPA is going to do regarding declarative
  policies. The charter text says

    (iii) the working group will investigate the practically of building


                

              

            

          

          
policy


          

            

              

                

                  
    rules that declaratively specify what goals to achieve (this is often


                

              

            

          

          
called


          

            

              

                

                  
    "intent-based" policy) but not how to achieve those goals
and may create a model
    accordingly

  but it also says:

    Out of scope of this working group are:
    [...]
    - Declarative a.k.a intent-based policy rules. Another
extension for


                

              

              
defining


              

                

                  
    policy rules according to a declarative, or intent-based,
paradigm, may


                

              

              
be


              

                

                  
    produced in later phases of SUPA work.

  For me this is confusing but perhaps I just do not read the text in
  the right way.



                

                
IMO - the text says that we can (continue to) investigate
'practicality' as


              

              
well as how to avoid conflict with work chartered in other WGs, but
we should not write a data model in the first phase of the WG. We
may do this 'in later phases'.


              

                

              

              
Expecting a WG to "practically investigate" something that is
clearly declared to be out of scope for the WG still sounds like a
contradiction to me (and I also wonder what "practically investigate"
means).



            

            
It's not declared to be out of scope for the WG. Quite the opposite - it


          

          
seems to me that there is an agreement that declarative / intent-based
policy rules are within the scope of the IETF work. What we did not agree is
that we do them in the first phase, and also how we differentiate from
similar or similarly labelled work in other IETF WGs or WGs-to-be. In order not
to get stuck while attending the resolution of this issue, the charter proposes
to start work in SUPA but delay the definition of the declarative/intent-based
policy rules for a later phase.


          

            

          

          
I still find the text confusing and I wished it would not require interpretation
to be understood the right way.



        

        
Ignoring Benoit's advice (' At this point, we passed the wordsmithing phase') - can you suggest the edits that would make the text clear with no need of interpretation? 



      

      
If the intent is that SUPA is not working on declarative policies
until the IETF has settled where to entertain such work, then simply
state it that way. That is, remove (iii) from the 6th paragraph and
the last item from the list of things that are out of scope and add a
new paragraph that say something along these lines:

  Declarative policies that specify the goals to achieve but not how
  to achieve those goals (also called "intent-based" policies) are out
  of scope for the initial phase of SUPA but may be considered in
  future phases of SUPA.

I think this is clearer and avoids the tension between the different
paragraphs we have in the current charter text.

/js



    

    

  


--------------050504030403080505070002--


From nobody Fri Sep 11 06:20:08 2015
Return-Path: 
X-Original-To: supa@ietfa.amsl.com
Delivered-To: supa@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A64A31A0338 for ; Fri, 11 Sep 2015 06:20:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -16.51
X-Spam-Level: 
X-Spam-Status: No, score=-16.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N-oFZaVgDcWb for ; Fri, 11 Sep 2015 06:20:02 -0700 (PDT)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70ED91B2DBC for ; Fri, 11 Sep 2015 06:20:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3032; q=dns/txt; s=iport; t=1441977603; x=1443187203; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=RMZhWtdD1ZWNfD8W/m74ZhaoNlkuShbeNJ0Ups0GZQA=; b=Hm1e+m4tzPS7WzLPp4+5Kaq31gncTJykSwdghgulKi8i3uebTQsczOXN b/0e77b1dxZR972F/nbUaKhJV4r95lLb4qAJCuOvqcMtVYaEq4kjknNug SJ8L06PYkoF1xv2720jn38KrsuqfSorMpSlNzHTwDXkympT6T6Bj+BrPg 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CZBAC/1PJV/xbLJq1dwiCHcQKCDRIBAQEBAQEBgQqEJAEBBHgBEAsEHRYPCQMCAQIBRQYBDAgBAYgqzB0BAQEBAQEBAQEBAQEBAQEBAQEBAQEXhnOEfYUNB4QsAQSVVox6iHyRfSgLMIQCPIpSAQEB
X-IronPort-AV: E=Sophos;i="5.17,511,1437436800";  d="scan'208,217";a="611543229"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 11 Sep 2015 13:19:53 +0000
Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t8BDJqh0015963; Fri, 11 Sep 2015 13:19:52 GMT
To: John Strassner , "Romascanu, Dan (Dan)" , Juergen Schoenwaelder 
References: <55EDA48D.5040802@cisco.com> <20150908124021.GB32230@elstar.local> <9904FB1B0159DA42B0B887B7FA8119CA5CB1F2F0@AZ-FFEXMB04.global.avaya.com> 
From: Benoit Claise 
Message-ID: <55F2D4F8.4060205@cisco.com>
Date: Fri, 11 Sep 2015 15:19:52 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------010305010203010205050502"
Archived-At: 
Cc: "supa@ietf.org" 
Subject: Re: [Supa] New SUPA charter text
X-BeenThere: supa@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Sep 2015 13:20:06 -0000

This is a multi-part message in MIME format.
--------------010305010203010205050502
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

Hi John,
>
>>> - The other comment concerns this text:
>>>
>>>      SUPA however will not deal with
>>>      the definition of the specific network configuration changes but with how
>>>      the configuration changes are applied (e.g. who is allowed to set policies,
>>>      when and how the policies are activated, changed or de-activated)
> 
> I'm confused by the above text. Defining who (or what) is allowed to set
> policies seems out of scope for the IETF. This is typically done using patterns
> (e.g., the role-object pattern), and I don't see how to map that easily to YANG.
> 
Now, I'm confused. The text says:

    SUPA however will not deal with the definition of the specific
    network configuration changes but WILL DEAL with how the
    configuration changes are applied (e.g. who is allowed to set
    policies, when and how the policies are activated, changed or
    de-activated).

Note my addition in capital letters.
So the who (and when, how) is clearly in scope.

Regards, Benoit

--------------010305010203010205050502
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 7bit


  
    
  
  
    
Hi John,

    

    


      

        

          
- The other comment concerns this text:

    SUPA however will not deal with
    the definition of the specific network configuration changes but with how
    the configuration changes are applied (e.g. who is allowed to set policies,
    when and how the policies are activated, changed or de-activated)


        

      

      
<jcs>
I'm confused by the above text. Defining who (or what) is allowed to set 
policies seems out of scope for the IETF. This is typically done using patterns
(e.g., the role-object pattern), and I don't see how to map that easily to YANG.
</jcs>


    

    Now, I'm confused. The text says: 

    
SUPA however will not deal with the definition of the
      specific network configuration changes but WILL DEAL with how the
      configuration changes are applied (e.g. who is allowed to set
      policies, when and how the policies are activated, changed or
      de-activated).

    

    Note my addition in capital letters. 

    So the who (and when, how) is clearly in scope.

    

    Regards, Benoit

  


--------------010305010203010205050502--


From nobody Fri Sep 11 08:55:24 2015
Return-Path: 
X-Original-To: supa@ietfa.amsl.com
Delivered-To: supa@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8B1E1B4F72 for ; Fri, 11 Sep 2015 08:55:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xb1bZHu7CTM2 for ; Fri, 11 Sep 2015 08:55:19 -0700 (PDT)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFA0E1B4F6F for ; Fri, 11 Sep 2015 08:55:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11709; q=dns/txt; s=iport; t=1441986919; x=1443196519; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=uwiJzAX7bj9gYsqVyipCAz+hKnLsXzWg0Kkq2d8c370=; b=lJ16DM3wBc0RFPnn1I6we/XmuXxK80ETpHFBlfd82KGKapDySDSqgmUX RtNZugfKtmcMJTXAHeve05BzYBu53p9rqJGhdtU+I3VGSnzqQhtX9uMEv etIp0OTL0g5CXbxX7mLjqHj5A0X+u3vk1bxHNcJ8Bl9lkDGQyTk4nyd8C g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CgBABY+PJV/xbLJq1aA4N3ab8tAQaFfAKCIQEBAQEBAYELhCMBAQEEAQEBawoBDAICCxABBAEBAQkWCAcJAwIBAgEJDB8JCAYBDAYCAQGIKg3MRQEBAQEBAQEBAQEBAQEBAQEBAQEBARMEBIZvhH2EfRAHBgyEGgEElVaFCodwgUyEM4J9I4QAjVpjhAM8MwEBih0BAQE
X-IronPort-AV: E=Sophos;i="5.17,511,1437436800";  d="scan'208,217";a="605060477"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Sep 2015 15:55:17 +0000
Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t8BFtG5e023265; Fri, 11 Sep 2015 15:55:16 GMT
To: "Romascanu, Dan (Dan)" , Juergen Schoenwaelder 
References: <55EDA48D.5040802@cisco.com> <20150908124021.GB32230@elstar.local> <9904FB1B0159DA42B0B887B7FA8119CA5CB1F2F0@AZ-FFEXMB04.global.avaya.com>
From: Benoit Claise 
Message-ID: <55F2F964.7010206@cisco.com>
Date: Fri, 11 Sep 2015 17:55:16 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA5CB1F2F0@AZ-FFEXMB04.global.avaya.com>
Content-Type: multipart/alternative; boundary="------------060305030101000305020602"
Archived-At: 
Cc: "supa@ietf.org" 
Subject: Re: [Supa] New SUPA charter text
X-BeenThere: supa@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Sep 2015 15:55:22 -0000

This is a multi-part message in MIME format.
--------------060305030101000305020602
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

Hi,
> Hi,
>
> See in-text.
>
> Regards,
>
> Dan
>
>
>> -----Original Message-----
>> From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of Juergen
>> Schoenwaelder
>> Sent: Tuesday, September 08, 2015 3:40 PM
>> To: Benoit Claise
>> Cc: supa@ietf.org
>> Subject: Re: [Supa] New SUPA charter text
>>
>> On Mon, Sep 07, 2015 at 04:51:57PM +0200, Benoit Claise wrote:
>>> Please review
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.
>>> org_doc_charter-2Dietf-
>> 2Dsupa_&d=BQICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4d
>> zGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=FjFbmJya6x58nXbHAJ389
>> Wd24wZ
>> U2zmjtIlRJFIAHB0&s=yGfhqxgu2nlg2EOrZwD3qlRzY9ykPQwO8IXMAc8KrFw&
>> e=
>>> version00-09ASAP, for any mistake.
>>> At this point, we passed the wordsmithing phase.
>>>
>> It is unclear whether you want to have feedback or not. I will send it anyway,
>> feel free to ignore since we 'passed the wordsmithing phase'.
>>
>> I have two comments:
>>
>> - It is unclear what SUPA is going to do regarding declarative
>>    policies. The charter text says
>>
>>      (iii) the working group will investigate the practically of building policy
>>      rules that declaratively specify what goals to achieve (this is often called
>>      "intent-based" policy) but not how to achieve those goals and may create a
>> model
>>      accordingly
>>
>>    but it also says:
>>
>>      Out of scope of this working group are:
>>      [...]
>>      - Declarative a.k.a intent-based policy rules. Another extension for defining
>>      policy rules according to a declarative, or intent-based, paradigm, may be
>>      produced in later phases of SUPA work.
>>
>>    For me this is confusing but perhaps I just do not read the text in
>>    the right way.
>>
> IMO - the text says that we can (continue to) investigate 'practicality' as well as how to avoid conflict with work chartered in other WGs, but we should not write a data model in the first phase of the WG. We may do this 'in later phases'.
>
>
>> - The other comment concerns this text:
>>
>>      SUPA however will not deal with
>>      the definition of the specific network configuration changes but with how
>> the
>>      configuration changes are applied (e.g. who is allowed to set policies, when
>> and
>>      how the policies are activated, changed or de-activated)
>>
>>    Is SUPA going to work out how actions are specified and executed?
>>    For example: Assuming the ACL YANG data model worked on in NETMOD,
>>    will I be able to use SUPA policy data models without further data
>>    models to populate my ACL lists? Or is the idea that SUPA only
>>    provide a core framework that requires data model extensions to do
>>    anything meaningful? Pretty much like the interfaces data model that
>>    requires interface type specific extensions to be really useful.
>>
> IMO - rather the later.
The later, the way I understood.
This is the reason for this charter sentence:

    This working group will be a success when the SUPA policy constructs
    are re-used in future IETF specifications (and ideally
    specifications from other SDOs), in a manner that will save
    development time and avoid inconsistencies between data models
    developed by different working groups.

Regards, Benoit
> Yet, I would observe - as you brought up the example - that some people do useful things and get useful information from the interfaces table MIB objects.
>
>> Now I shut up. ;-)
>>
> Why? :-)
>
>> /js
>>
>> --
>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
>> Fax:   +49 421 200 3103
>> > 2Duniversity.de_&d=BQICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31O
>> cNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=FjFbmJya6x58nXbHAJ389Wd24wZ
>> U2zmjtIlRJFIAHB0&s=qrI__AXlgml5bUqjuH_K_dNchVZDYRzehsCmOTpRXRg
>> &e= >
>>
>> _______________________________________________
>> Supa mailing list
>> Supa@ietf.org
>> https://urldefense.proofpoint.com/v2/url?u=https-
>> 3A__www.ietf.org_mailman_listinfo_supa&d=BQICAg&c=BFpWQw8bsuKpl1
>> SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=FjFbmJy
>> a6x58nXbHAJ389Wd24wZU2zmjtIlRJFIAHB0&s=Kp4a2MG8oVlIY-
>> HewXWBrbaebyraGmPqwd2xlfRSAfU&e=
> _______________________________________________
> Supa mailing list
> Supa@ietf.org
> https://www.ietf.org/mailman/listinfo/supa
> .
>


--------------060305030101000305020602
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 7bit


  
    
  
  
    
Hi, 

    

    

      
Hi, 

See in-text. 

Regards,

Dan




      

        
-----Original Message-----
From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of Juergen
Schoenwaelder
Sent: Tuesday, September 08, 2015 3:40 PM
To: Benoit Claise
Cc: supa@ietf.org
Subject: Re: [Supa] New SUPA charter text

On Mon, Sep 07, 2015 at 04:51:57PM +0200, Benoit Claise wrote:


        

          
Please review
https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.
org_doc_charter-2Dietf-


        

        
2Dsupa_&d=BQICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4d


        

          

        

        
zGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=FjFbmJya6x58nXbHAJ389
Wd24wZ


        

          

        

        
U2zmjtIlRJFIAHB0&s=yGfhqxgu2nlg2EOrZwD3qlRzY9ykPQwO8IXMAc8KrFw&
e=


        

          
version00-09ASAP, for any mistake.
At this point, we passed the wordsmithing phase.



        

        
It is unclear whether you want to have feedback or not. I will send it anyway,
feel free to ignore since we 'passed the wordsmithing phase'.

I have two comments:

- It is unclear what SUPA is going to do regarding declarative
  policies. The charter text says

    (iii) the working group will investigate the practically of building policy
    rules that declaratively specify what goals to achieve (this is often called
    "intent-based" policy) but not how to achieve those goals and may create a
model
    accordingly

  but it also says:

    Out of scope of this working group are:
    [...]
    - Declarative a.k.a intent-based policy rules. Another extension for defining
    policy rules according to a declarative, or intent-based, paradigm, may be
    produced in later phases of SUPA work.

  For me this is confusing but perhaps I just do not read the text in
  the right way.



      

      
IMO - the text says that we can (continue to) investigate 'practicality' as well as how to avoid conflict with work chartered in other WGs, but we should not write a data model in the first phase of the WG. We may do this 'in later phases'. 




      

        
- The other comment concerns this text:

    SUPA however will not deal with
    the definition of the specific network configuration changes but with how
the
    configuration changes are applied (e.g. who is allowed to set policies, when
and
    how the policies are activated, changed or de-activated)

  Is SUPA going to work out how actions are specified and executed?
  For example: Assuming the ACL YANG data model worked on in NETMOD,
  will I be able to use SUPA policy data models without further data
  models to populate my ACL lists? Or is the idea that SUPA only
  provide a core framework that requires data model extensions to do
  anything meaningful? Pretty much like the interfaces data model that
  requires interface type specific extensions to be really useful.



      

      
IMO - rather the later. 

    

    The later, the way I understood.

    This is the reason for this charter sentence:

    
This working group will be a success when the SUPA
      policy constructs are re-used in future IETF specifications (and
      ideally specifications from other SDOs), in a manner that will
      save development time and avoid inconsistencies between data
      models developed by different working groups. 

    

    Regards, Benoit

    

      
Yet, I would observe - as you brought up the example - that some people do useful things and get useful information from the interfaces table MIB objects. 



      

        
Now I shut up. ;-)



      

      
Why? :-)



      

        
/js

--
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103
<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.jacobs-
2Duniversity.de_&d=BQICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31O
cNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=FjFbmJya6x58nXbHAJ389Wd24wZ
U2zmjtIlRJFIAHB0&s=qrI__AXlgml5bUqjuH_K_dNchVZDYRzehsCmOTpRXRg
&e= >

_______________________________________________
Supa mailing list
Supa@ietf.org
https://urldefense.proofpoint.com/v2/url?u=https-
3A__www.ietf.org_mailman_listinfo_supa&d=BQICAg&c=BFpWQw8bsuKpl1
SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=FjFbmJy
a6x58nXbHAJ389Wd24wZU2zmjtIlRJFIAHB0&s=Kp4a2MG8oVlIY-
HewXWBrbaebyraGmPqwd2xlfRSAfU&e=


      

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



    

    

  


--------------060305030101000305020602--


From nobody Mon Sep 14 15:12:26 2015
Return-Path: 
X-Original-To: supa@ietfa.amsl.com
Delivered-To: supa@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAF5B1B352F; Mon, 14 Sep 2015 15:12:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5dzhHoHJmgDG; Mon, 14 Sep 2015 15:12:22 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CD781B3538; Mon, 14 Sep 2015 15:12:22 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "Spencer Dawkins" 
To: "The IESG" 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.4.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150914221222.18261.91054.idtracker@ietfa.amsl.com>
Date: Mon, 14 Sep 2015 15:12:22 -0700
Archived-At: 
Cc: supa@ietf.org
Subject: [Supa] Spencer Dawkins' No Objection on charter-ietf-supa-00-11: (with COMMENT)
X-BeenThere: supa@ietf.org
X-Mailman-Version: 2.1.15
List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Sep 2015 22:12:23 -0000

Spencer Dawkins has entered the following ballot position for
charter-ietf-supa-00-11: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)



The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-supa/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I have no objection to chartering this working group.

I found this text somewhat unclear.

Out of scope of this working group are:  

... deleted down to ...

-   Specific handling of policies (although the application document
will
provide some examples), and therefore the specification of a policy
engine that
maps a specific policy instance to actual configuration snippets.

I'm pretty sure this means 

-   Specific handling of policies (although the application document
will
provide some examples). Therefore the specification of a policy engine
that
maps a specific policy instance to actual configuration snippets is also

out of scope.

But I struggled to parse the original text.



From nobody Tue Sep 15 23:35:04 2015
Return-Path: 
X-Original-To: supa@ietfa.amsl.com
Delivered-To: supa@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A08501A1B0C; Tue, 15 Sep 2015 08:55:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id prLnIykrsGRY; Tue, 15 Sep 2015 08:55:16 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4348F1A1B07; Tue, 15 Sep 2015 08:55:16 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "Brian Haberman" 
To: "The IESG" 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.4.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150915155516.31628.69224.idtracker@ietfa.amsl.com>
Date: Tue, 15 Sep 2015 08:55:16 -0700
Archived-At: 
X-Mailman-Approved-At: Tue, 15 Sep 2015 23:35:03 -0700
Cc: supa@ietf.org
Subject: [Supa] Brian Haberman's No Objection on charter-ietf-supa-00-11: (with COMMENT)
X-BeenThere: supa@ietf.org
X-Mailman-Version: 2.1.15
List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Sep 2015 15:55:18 -0000

Brian Haberman has entered the following ballot position for
charter-ietf-supa-00-11: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)



The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-supa/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I think the following has an issue:

The SUPA working group develops models for expressing policy at different
levels
of abstraction.  Specifically, three models are envisioned: 
(i) a generic model that defines concepts and vocabulary needed by
policy
management independent of the form and content of the policy
(ii) a more specific model that refines the generic model to specify how
to
build policy rules of the event-condition-action paradigm

Either s/three models/two models/ or there is a missing (iii).



From nobody Wed Sep 16 00:38:15 2015
Return-Path: 
X-Original-To: supa@ietfa.amsl.com
Delivered-To: supa@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E35F1B36F3; Wed, 16 Sep 2015 00:38:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5c3fj8TDGBgw; Wed, 16 Sep 2015 00:38:12 -0700 (PDT)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02B661B382B; Wed, 16 Sep 2015 00:38:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1393; q=dns/txt; s=iport; t=1442389091; x=1443598691; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=KQEP0J6GqEfgILgZoe6lsEhIgofQTj3BEgseXSltIpM=; b=e6obHSJkG13oBIhbwHZrwfMXH3/QAf9PKlsnasIwUSwC4mh5T/tdQmOy F0iMn6U4AT82wQZYyK84TAgFGZMyGXNYimKCw5sVSSWyopWlx/9ap4RmT dK8YwglMfVnaymF2DEJzCDQXtvPO4tyoNmiyiR8xOpaFf6TIfie07g9Dj g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CeBAD9G/lV/xbLJq1dg3dpvy8KhXkCgg0BAQEBAQGBC4QkAQEEAQEBNTYKARALIRYPCQMCAQIBFTAGAQwGAgEBiCoNyWEBAQEBAQEBAQEBAQEBAQEBAQEBAQETBIZzhH2EKhEBUQeELAEEhzOOK4UQh3OBTYQ1gn6SEGOCQ4FAPDOIa4E/AQEB
X-IronPort-AV: E=Sophos;i="5.17,537,1437436800"; d="scan'208";a="607032979"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 16 Sep 2015 07:38:09 +0000
Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t8G7c8FQ000929; Wed, 16 Sep 2015 07:38:08 GMT
To: Brian Haberman , The IESG 
References: <20150915155516.31628.69224.idtracker@ietfa.amsl.com>
From: Benoit Claise 
Message-ID: <55F91C60.8070804@cisco.com>
Date: Wed, 16 Sep 2015 09:38:08 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <20150915155516.31628.69224.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: supa@ietf.org
Subject: Re: [Supa] Brian Haberman's No Objection on charter-ietf-supa-00-11: (with COMMENT)
X-BeenThere: supa@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Sep 2015 07:38:13 -0000

Hi Brian,

Good catch. Some legacy text.
Corrected now in version 00-12.

Regards, Benoit
> Brian Haberman has entered the following ballot position for
> charter-ietf-supa-00-11: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/charter-ietf-supa/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> I think the following has an issue:
>
> The SUPA working group develops models for expressing policy at different
> levels
> of abstraction.  Specifically, three models are envisioned:
> (i) a generic model that defines concepts and vocabulary needed by
> policy
> management independent of the form and content of the policy
> (ii) a more specific model that refines the generic model to specify how
> to
> build policy rules of the event-condition-action paradigm
>
> Either s/three models/two models/ or there is a missing (iii).
>
>
> _______________________________________________
> Supa mailing list
> Supa@ietf.org
> https://www.ietf.org/mailman/listinfo/supa
> .
>


From nobody Wed Sep 16 00:38:32 2015
Return-Path: 
X-Original-To: supa@ietfa.amsl.com
Delivered-To: supa@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3210D1B3851; Wed, 16 Sep 2015 00:38:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1H4UgHa4J6U5; Wed, 16 Sep 2015 00:38:18 -0700 (PDT)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE7781B3844; Wed, 16 Sep 2015 00:38:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1473; q=dns/txt; s=iport; t=1442389098; x=1443598698; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=kbxwy5aP2roOzb3fzONbg9swpPiEB7MFK9d1KV8BvAg=; b=CP9HYadJWePUi9VWocl798vc6DN+/83Rfl9pK6Jwt+iRknLvzAPxu5zk sQuGz2Bg3UjyzOxA9R35v1fG76I6Tlx7PWBT7/IlH0YIiR4oSqH2P32DT LHGFZTFw+JLYLAbImRM7U5/qsAMr+02f7/BwF17PScPNkWxV9Y+6VfUj8 w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CbBAD9G/lV/xbLJq1dg3e+KYF5hXkCgXoTAQEBAQEBAYEKhCQBAQMBIxVAAQULCxoCBRYLAgIJAwIBAgFFBgEMCAEBiCIIDbUclEUBAQEBAQEBAQEBAQEBAQEBAQEBAQETBIEihVGEfYQqEQFRB4JpgUMBBIczjiuFEIdzgU2ENYJ+jiSDbCMBP4QDPIkegT8BAQE
X-IronPort-AV: E=Sophos;i="5.17,537,1437436800"; d="scan'208";a="629756698"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 16 Sep 2015 07:37:55 +0000
Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t8G7bsS0005624; Wed, 16 Sep 2015 07:37:54 GMT
To: Spencer Dawkins , The IESG 
References: <20150914221222.18261.91054.idtracker@ietfa.amsl.com>
From: Benoit Claise 
Message-ID: <55F91C52.7040204@cisco.com>
Date: Wed, 16 Sep 2015 09:37:54 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <20150914221222.18261.91054.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: supa@ietf.org
Subject: Re: [Supa] Spencer Dawkins' No Objection on charter-ietf-supa-00-11: (with COMMENT)
X-BeenThere: supa@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Sep 2015 07:38:22 -0000

Thanks Spencer for your text proposal, now in version 00-12
It's clearer this way.

Regards, Benoit

> Spencer Dawkins has entered the following ballot position for
> charter-ietf-supa-00-11: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/charter-ietf-supa/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> I have no objection to chartering this working group.
>
> I found this text somewhat unclear.
>
> Out of scope of this working group are:
>
> ... deleted down to ...
>
> -   Specific handling of policies (although the application document
> will
> provide some examples), and therefore the specification of a policy
> engine that
> maps a specific policy instance to actual configuration snippets.
>
> I'm pretty sure this means
>
> -   Specific handling of policies (although the application document
> will
> provide some examples). Therefore the specification of a policy engine
> that
> maps a specific policy instance to actual configuration snippets is also
>
> out of scope.
>
> But I struggled to parse the original text.
>
>
>


From nobody Wed Sep 16 18:13:53 2015
Return-Path: 
X-Original-To: supa@ietfa.amsl.com
Delivered-To: supa@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0FB51A8AD9; Wed, 16 Sep 2015 15:43:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qX4sAqjUkT7M; Wed, 16 Sep 2015 15:43:12 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 924F31A8AC5; Wed, 16 Sep 2015 15:43:12 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "Ben Campbell" 
To: "The IESG" 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.4.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150916224312.2254.90816.idtracker@ietfa.amsl.com>
Date: Wed, 16 Sep 2015 15:43:12 -0700
Archived-At: 
X-Mailman-Approved-At: Wed, 16 Sep 2015 18:13:52 -0700
Cc: supa@ietf.org
Subject: [Supa] Ben Campbell's No Objection on charter-ietf-supa-00-12: (with COMMENT)
X-BeenThere: supa@ietf.org
X-Mailman-Version: 2.1.15
List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Sep 2015 22:43:14 -0000

Ben Campbell has entered the following ballot position for
charter-ietf-supa-00-12: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)



The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-supa/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I do not object, but I think the milestones are a bit agressive. 

I also think this could use some editorial clean-up:

-- paragraph 2: Inconsistent verb tense for WG activitites (  "defines a
data model",  "will not deal with the definition") Also, who are  "We"?
(Normally I don't object to "We" in IETF documents, but in this case it's
not clear if it refers to the IESG, the WG, or the IETF as a whole).

s/"This working group will be a success when"/"The working group will
have succeeded"  ; or "will have been a success"

s/"manner that will save development"/"matter that saves development"

"In the meantime, SUPA should not impede work in other working groups
while waiting for SUPA to produce its deliverables."

I _think_ that means that other groups will not delay their deliverables
to wait for SUPA? If so, I propose: "In the mean time, other working
groups should not delay their deliverables waiting for SUPA to complete
it's work"

s/it might do so/it may do so

s/ A document that explains.../ An explanation of...



From nobody Thu Sep 17 00:23:45 2015
Return-Path: 
X-Original-To: supa@ietfa.amsl.com
Delivered-To: supa@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EA851A6F81; Thu, 17 Sep 2015 00:23:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EMeNq6yY5Irp; Thu, 17 Sep 2015 00:23:42 -0700 (PDT)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D95971A6F7D; Thu, 17 Sep 2015 00:23:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2395; q=dns/txt; s=iport; t=1442474622; x=1443684222; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=sWX6Fh/Zb8slMFJhM9ojzBt3faWb+pbI3m90gAqiUgg=; b=dpHFLiPgHtyTM+zeHd5CZoUEVxtcgcUpGJiiB3+jxjdJuwlOLntcKPsT oQbgwfpwfrkMT509rDNT5ghcajuTcJlAqB5y8lrBLHJfp93eugWY/7UIU tYUAY6FllT2sYBL48uSCh5kRkeGiJb/D1srRPlOGQmnucgnIsMe+TKBjv 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CdBAAbavpV/xbLJq1eg3dpv0aFfAKCBwEBAQEBAYELhCQBAQQjFUABEAsaAgUWCwICCQMCAQIBRQYBDAgBAYgqDbVylEQBAQEBAQEBAQEBAQEBAQEBAQEBAQETBIEihVGEfYQqEQFRB4JpgUMBBIc0ji2FEYd0gU2ENoJ+jiqDbWOEAzwzAQEBAYhngT8BAQE
X-IronPort-AV: E=Sophos;i="5.17,545,1437436800"; d="scan'208";a="607059128"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 17 Sep 2015 07:23:33 +0000
Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t8H7NXfL032197; Thu, 17 Sep 2015 07:23:33 GMT
To: Ben Campbell , The IESG 
References: <20150916224312.2254.90816.idtracker@ietfa.amsl.com>
From: Benoit Claise 
Message-ID: <55FA6A75.8090202@cisco.com>
Date: Thu, 17 Sep 2015 09:23:33 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <20150916224312.2254.90816.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: supa@ietf.org
Subject: Re: [Supa] Ben Campbell's No Objection on charter-ietf-supa-00-12: (with COMMENT)
X-BeenThere: supa@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Sep 2015 07:23:44 -0000

Hi Ben,

Thanks for your review.
> Ben Campbell has entered the following ballot position for
> charter-ietf-supa-00-12: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/charter-ietf-supa/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> I do not object, but I think the milestones are a bit agressive.
You might be right. This is what the SUPA people hope for. We'll see.
>
> I also think this could use some editorial clean-up:
>
> -- paragraph 2: Inconsistent verb tense for WG activitites (  "defines a
> data model",  "will not deal with the definition")
Done.
> Also, who are  "We"?
> (Normally I don't object to "We" in IETF documents, but in this case it's
> not clear if it refers to the IESG, the WG, or the IETF as a whole).
OLD: We anticipate that processing that input will result in network 
configuration changes.
NEW: Processing that input most probably results in network 
configuration changes
>
> s/"This working group will be a success when"/"The working group will
> have succeeded"  ; or "will have been a success"
Done.
>
> s/"manner that will save development"/"matter that saves development"
Done.
>
> "In the meantime, SUPA should not impede work in other working groups
> while waiting for SUPA to produce its deliverables."
>
> I _think_ that means that other groups will not delay their deliverables
> to wait for SUPA? If so, I propose: "In the mean time, other working
> groups should not delay their deliverables waiting for SUPA to complete
> it's work"
I believe it works even if I don't control the other working groups.
>
> s/it might do so/it may do so
Done.
>
> s/ A document that explains.../ An explanation of...
Done.

See the diff between version 00-14 and 00-12 at 
https://www.ietf.org/rfcdiff?url1=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-supa%2Fwithmilestones-00-12.txt&url2=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-supa%2Fwithmilestones-00-14.txt

Regards, Benoit
>
>
> .
>


From nobody Thu Sep 17 06:55:05 2015
Return-Path: 
X-Original-To: supa@ietfa.amsl.com
Delivered-To: supa@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3911E1B2FE0; Thu, 17 Sep 2015 06:55:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id czyx936MIbe6; Thu, 17 Sep 2015 06:55:03 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 023E81B2FF2; Thu, 17 Sep 2015 06:54:58 -0700 (PDT)
Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t8HDsjNw084296 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 17 Sep 2015 08:54:55 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23]
From: "Ben Campbell" 
To: "Benoit Claise" 
Date: Thu, 17 Sep 2015 08:54:45 -0500
Message-ID: <0A1EDC2E-2E6D-4A0F-AD78-B31776195B2C@nostrum.com>
In-Reply-To: <55FA6A75.8090202@cisco.com>
References: <20150916224312.2254.90816.idtracker@ietfa.amsl.com> <55FA6A75.8090202@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Mailer: MailMate (1.9.2r5107)
Archived-At: 
Cc: The IESG , supa@ietf.org
Subject: Re: [Supa] Ben Campbell's No Objection on charter-ietf-supa-00-12: (with COMMENT)
X-BeenThere: supa@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Sep 2015 13:55:05 -0000

Thanks, Benoit. The updated version looks good.

Ben.

On 17 Sep 2015, at 2:23, Benoit Claise wrote:

> Hi Ben,
>
> Thanks for your review.
>> Ben Campbell has entered the following ballot position for
>> charter-ietf-supa-00-12: No Objection
>>
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut =

>> this
>> introductory paragraph, however.)
>>
>>
>>
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/charter-ietf-supa/
>>
>>
>>
>> ----------------------------------------------------------------------=

>> COMMENT:
>> ----------------------------------------------------------------------=

>>
>> I do not object, but I think the milestones are a bit agressive.
> You might be right. This is what the SUPA people hope for. We'll see.
>>
>> I also think this could use some editorial clean-up:
>>
>> -- paragraph 2: Inconsistent verb tense for WG activitites (  =

>> "defines a
>> data model",  "will not deal with the definition")
> Done.
>> Also, who are  "We"?
>> (Normally I don't object to "We" in IETF documents, but in this case =

>> it's
>> not clear if it refers to the IESG, the WG, or the IETF as a whole).
> OLD: We anticipate that processing that input will result in network =

> configuration changes.
> NEW: Processing that input most probably results in network =

> configuration changes
>>
>> s/"This working group will be a success when"/"The working group will
>> have succeeded"  ; or "will have been a success"
> Done.
>>
>> s/"manner that will save development"/"matter that saves development"
> Done.
>>
>> "In the meantime, SUPA should not impede work in other working groups
>> while waiting for SUPA to produce its deliverables."
>>
>> I _think_ that means that other groups will not delay their =

>> deliverables
>> to wait for SUPA? If so, I propose: "In the mean time, other working
>> groups should not delay their deliverables waiting for SUPA to =

>> complete
>> it's work"
> I believe it works even if I don't control the other working groups.
>>
>> s/it might do so/it may do so
> Done.
>>
>> s/ A document that explains.../ An explanation of...
> Done.
>
> See the diff between version 00-14 and 00-12 at =

> https://www.ietf.org/rfcdiff?url1=3Dhttps%3A%2F%2Fdatatracker.ietf.org%=
2Fdoc%2Fcharter-ietf-supa%2Fwithmilestones-00-12.txt&url2=3Dhttps%3A%2F%2=
Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-supa%2Fwithmilestones-00-14.tx=
t
>
> Regards, Benoit
>>
>>
>> .
>>


From nobody Thu Sep 17 08:07:53 2015
Return-Path: 
X-Original-To: supa@ietfa.amsl.com
Delivered-To: supa@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B83BB1A870F for ; Thu, 17 Sep 2015 08:07:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WetuHRsqSl_3 for ; Thu, 17 Sep 2015 08:07:50 -0700 (PDT)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 308101A89B3 for ; Thu, 17 Sep 2015 08:07:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=443; q=dns/txt; s=iport; t=1442502433; x=1443712033; h=to:from:subject:message-id:date:mime-version: content-transfer-encoding; bh=TUT0Rn6FLiVjtBo5UU32y0xqVE73gGuiQMNs9+KO4/o=; b=DxYE/DlkFqGDQFYJLWg7X0Oq/Moj7VF50sroBCGLiZTRwUrgj9BAjcAR +k1DwAp86qM6LTSj3TBl6WkYGxnuDFMb+Rup/oR+U94JBqPYnkEE2xaYt LbJa29CYgo/QskVnOdG08Z2NS8MVtw8C/d90qnK8gqS5s5Dz5aIACjZIt 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CtBACS1vpV/xbLJq1dg3dpAb9IiAgBAQEBAQGBAAuETRVANgIFFgsCCwMCAQIBSw0IAQGIKg2nMY9qlEkBAQEHAgEfgSKFUYknEQGDQYFDAQSVYYURh3WCE4ZukhljhAM8NIhqgT8BAQE
X-IronPort-AV: E=Sophos;i="5.17,547,1437436800"; d="scan'208";a="605186433"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Sep 2015 15:07:11 +0000
Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t8HF7B9n028842 for ; Thu, 17 Sep 2015 15:07:11 GMT
To: "supa@ietf.org" 
From: Benoit Claise 
Message-ID: <55FAD71F.6020803@cisco.com>
Date: Thu, 17 Sep 2015 17:07:11 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: [Supa] SUPA approved for IETF review
X-BeenThere: supa@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Sep 2015 15:07:51 -0000

Dear all,

During the telechat today, the IESG approved SUPA for "IETF review". An 
email should be sent tomorrow.
The next step is a "proposed for approval" ballot, based on the IETF 
reviews, in the telechat in 2 weeks.
In the meantime, I booked a slot for the IETF 94 meeting. See 
http://trac.tools.ietf.org/bof/trac/wiki/WikiStart

The latest charter is at https://datatracker.ietf.org/doc/charter-ietf-supa/

Regards, Benoit




From nobody Thu Sep 17 22:42:34 2015
Return-Path: 
X-Original-To: supa@ietfa.amsl.com
Delivered-To: supa@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B80F1B2FAC; Thu, 17 Sep 2015 06:39:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PdUzLYdNiNeq; Thu, 17 Sep 2015 06:39:16 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 373181B2BDC; Thu, 17 Sep 2015 06:39:16 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "Stephen Farrell" 
To: "The IESG" 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.4.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150917133916.7090.37651.idtracker@ietfa.amsl.com>
Date: Thu, 17 Sep 2015 06:39:16 -0700
Archived-At: 
X-Mailman-Approved-At: Thu, 17 Sep 2015 22:42:33 -0700
Cc: supa@ietf.org
Subject: [Supa] Stephen Farrell's No Objection on charter-ietf-supa-00-14: (with COMMENT)
X-BeenThere: supa@ietf.org
X-Mailman-Version: 2.1.15
List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Sep 2015 13:39:17 -0000

Stephen Farrell has entered the following ballot position for
charter-ietf-supa-00-14: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)



The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-supa/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


I'll be interested to see if these folks can avoid boiling
a yang-flavoured policy ocean. Hopefully they can.



From nobody Fri Sep 18 22:57:49 2015
Return-Path: 
X-Original-To: supa@ietfa.amsl.com
Delivered-To: supa@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D2331B2DEB; Fri, 18 Sep 2015 08:13:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Level: 
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WMkXDgro3Gkh; Fri, 18 Sep 2015 08:13:36 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 029301A1BBE; Fri, 18 Sep 2015 08:13:36 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG 
To: "IETF-Announce" 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.4.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150918151336.5877.37314.idtracker@ietfa.amsl.com>
Date: Fri, 18 Sep 2015 08:13:36 -0700
Archived-At: 
X-Mailman-Approved-At: Fri, 18 Sep 2015 22:57:47 -0700
Cc: supa WG 
Subject: [Supa] WG Review: Simplified Use of Policy Abstractions (supa)
X-BeenThere: supa@ietf.org
X-Mailman-Version: 2.1.15
List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Sep 2015 15:13:40 -0000

A new IETF working group has been proposed in the Operations and
Management Area. The IESG has not made any determination yet. The
following draft charter was submitted, and is provided for informational
purposes only. Please send your comments to the IESG mailing list (iesg
at ietf.org) by 2015-09-28.

Simplified Use of Policy Abstractions (supa)
------------------------------------------------
Current Status: Proposed WG

Assigned Area Director:
  Benoit Claise 

Mailing list
  Address: supa@ietf.org
  To Subscribe: https://www.ietf.org/mailman/listinfo/supa
  Archive: https://mailarchive.ietf.org/arch/browse/supa/

Charter:

Policies are a set of rules that define how services are designed,
delivered, and operated within an operator's networking environment. As
such, policies play a critical role in the automated service delivery and
operational procedures. Operators want and need to be able to define the
policies that apply to their different customers and to the equipment
that comprises their physical and virtual networks. Policies usually span
a wide range of services that are supported by various technologies:
thus, a common way for expressing and describing policies that is uniform
and consistent regardless of the nature of the networking environment is
likely to facilitate the overall service delivery procedure and
operation. Such an approach will minimize the risk of configuration
errors that arise from confusion between different systems, will enable
easy understanding of policies that apply in different environments, will
make the implementation of policy-based systems quicker and cheaper, and
will facilitate the rapid development of standards-based data models that
include policy elements.

The SUPA (Simplified Use of Policy Abstractions) working group defines a
data model, to be used to represent high-level, possibly network-wide
policies, which can be input to a network management function (within a
controller, an orchestrator, or a network element). Processing that input
most probably results in network configuration changes. SUPA however does
not deal with the definition of the specific network configuration
changes but with how the configuration changes are applied (e.g. who is
allowed to set policies, when and how the policies are activated, changed
or de-activated).
 
Practically, SUPA defines base YANG data models to encode policy, which
will point to device-, technology-, and service-specific YANG models
developed in other working groups.

SUPA focuses on a single management domain, and is designed to work with
device, protocol, network, and service data models. 

The working group will have succeeded when the SUPA policy constructs are
re-used in future IETF specifications (and ideally specifications from
other SDOs), in a matter that saves development time and avoid
inconsistencies between data models developed by different working
groups. In the mean time, other working groups should not delay their
deliverables waiting for SUPA to complete its work.

The SUPA working group develops models for expressing policy at different
levels of abstraction.  Specifically, two models are envisioned: 
(i) a generic model that defines concepts and vocabulary needed by policy
management independent of the form and content of the policy
(ii) a more specific model that refines the generic model to specify how
to build policy rules of the event-condition-action paradigm

If the working group finds it necessary to work on an information model
before the data model, to help provide guidance and derive the data
models, it may do so. The working group will decide later whether the
information model needs to be published as an RFC.

Out of scope of this working group are:  
-   The specification of a new policy protocol or a new data modelling
language. 
-   Design of protocol-specific policies and specific design for embedded
policies in network elements (which are usually interpreted in isolation,
and often at timescales that require optimization for specific purposes).
-   Specific handling of policies (although the application document will
provide some examples). Therefore the specification of a policy engine
that maps a specific policy instance to actual configuration snippets is
also out of scope.

Declarative policies that specify the goals to achieve but not how to
achieve those goals (also called "intent-based" policies) are out of
scope for the initial phase of SUPA but may be considered in future
phases of SUPA.

List of work items:
1) An explanation of the scope of the policy-based management framework
and how it relates to existing work of the IETF.

2) If the working group considers it necessary, a generic information
model composed of policy concepts and vocabulary. 

3) A set of YANG data models consisting of a base policy model for
representing policy management concepts independent of the type or
structure of a policy, plus an extension for defining policy rules
according to the event-condition-action paradigm. 

4) An applicability document providing a few examples that demonstrate
how the YANG policy data models can be used to express policies that are
relevant for network operators. The examples may tie into configuration
models or network service models developed by other working groups.

The working group will decide how the work items are best mapped into
deliverables.

The working group will communicate with other SDOs (MEF, TMF, ETSI) that
are working on related issues.

Milestones:
Apr 2016 Submit the policy-based management framework (Informational)
Apr 2016 Submit the generic information model (Informational)
Jun 2016 Submit the set of YANG data models (Standards Track)
Aug 2016 Submit the applicability document (Informational)
Aug 2016 Re-charter or close



From nobody Tue Sep 22 14:51:21 2015
Return-Path: 
X-Original-To: supa@ietfa.amsl.com
Delivered-To: supa@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD8441A8AF3 for ; Tue, 22 Sep 2015 14:51:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.01
X-Spam-Level: 
X-Spam-Status: No, score=-5.01 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fqZfBCuJS1Fm for ; Tue, 22 Sep 2015 14:51:17 -0700 (PDT)
Received: from fncnmp03.fnc.fujitsu.com (fncnmp03.fnc.fujitsu.com [168.127.0.56]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 502A61A8AEF for ; Tue, 22 Sep 2015 14:51:17 -0700 (PDT)
X-IronPort-AV: E=Sophos; i="5.17,574,1437454800"; d="scan'208,217"; a="67930675"
Received: from rchexhcp2.fnc.net.local ([168.127.134.76]) by fncnmp01.fnc.fujitsu.com with ESMTP/TLS/AES256-SHA; 22 Sep 2015 16:51:16 -0500
Received: from RCHEXMBP1.fnc.net.local ([169.254.2.53]) by RCHEXHCP2.fnc.net.local ([168.127.134.76]) with mapi id 14.03.0181.006; Tue, 22 Sep 2015 16:51:14 -0500
From: "Leroux, Francois" 
To: "supa@ietf.org" 
Thread-Topic: ECA Component class inheritance
Thread-Index: AdD1gMyDrdQm8GnjR7esww9Asg+fmg==
Date: Tue, 22 Sep 2015 21:51:13 +0000
Message-ID: <4832DE1A6E651043A4B3EC7A4E5BCF15C81C93B3@RCHEXMBP1.fnc.net.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [168.127.136.253]
x-tm-as-product-ver: SMEX-10.2.0.3176-8.000.1202-21832.003
x-tm-as-result: No--43.752100-0.000000-31
x-tm-as-user-approved-sender: Yes
x-tm-as-user-blocked-sender: No
Content-Type: multipart/alternative; boundary="_000_4832DE1A6E651043A4B3EC7A4E5BCF15C81C93B3RCHEXMBP1fncnet_"
MIME-Version: 1.0
Archived-At: 
Subject: [Supa] ECA Component class inheritance
X-BeenThere: supa@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Sep 2015 21:51:20 -0000

--_000_4832DE1A6E651043A4B3EC7A4E5BCF15C81C93B3RCHEXMBP1fncnet_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

John and Yang modeling team,

While cross reading information and data model drafts I could not figure th=
e inheritance scheme for ECA Component. Please see potentially conflicting =
bullets below. IM refers to [I-D. draft-strassner-supa-generic-policy-info-=
model-02] and DM refers to [I-D. draft-chen-supa-eca-data-model-03]. SUPA (=
or supa) prefix is omitted for readability.


1.       IM p.57 (fig. 10) - ECA Component inherits from Policy Atomic

2.       IM p.60 (fig. 11) - ECA Component inherits from Policy

3.       DM p.7 (fig. 4) - ECA Component inherits from ECA Policy Rule

I first suspected that #3 (DM) was the original intent but then noticed IM =
text at the top of p.58 ("(EPRIM)... also specializes the SUPAPolicy class =
to create a SUPAECAComponent...") suggesting #2 is correct (and #1 is a typ=
o).

Please let me know which one is correct.

Regards,
Fran=E7ois
--


--_000_4832DE1A6E651043A4B3EC7A4E5BCF15C81C93B3RCHEXMBP1fncnet_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











John and Yang modeling team,


 


While cross reading information and data model draft=
s I could not figure the inheritance scheme for ECA Component. Please see p=
otentially conflicting bullets below. IM refers to [I-D. draft-strassner-su=
pa-generic-policy-info-model-02] and
 DM refers to [I-D. draft-chen-supa-eca-data-model-03]. SUPA (or supa) pref=
ix is omitted for readability.


 


1.     &=
nbsp;
IM p.57 (fig. 10) - ECA Component inherits from Pol=
icy Atomic


2.     &=
nbsp;
IM p.60 (fig. 11) - ECA Component inherits from Pol=
icy


3.     &=
nbsp;
DM p.7 (fig. 4) - ECA Component inherits from ECA P=
olicy Rule


 


I first suspected that #3 (DM) was the original inte=
nt but then noticed IM text at the top of p.58 (“(EPRIM)… also =
specializes the SUPAPolicy class to create a SUPAECAComponent…”=
) suggesting #2 is correct (and #1 is a typo).


 


Please let me know which one is correct.<=
/p>

 


Regards,


Fran=E7ois


--


 






--_000_4832DE1A6E651043A4B3EC7A4E5BCF15C81C93B3RCHEXMBP1fncnet_--


From nobody Tue Sep 22 15:57:33 2015
Return-Path: 
X-Original-To: supa@ietfa.amsl.com
Delivered-To: supa@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E615B1B2F35 for ; Tue, 22 Sep 2015 15:57:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fzmhsEi_X-v4 for ; Tue, 22 Sep 2015 15:57:29 -0700 (PDT)
Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c:c05::22c]) (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 A23E61B2F41 for ; Tue, 22 Sep 2015 15:57:29 -0700 (PDT)
Received: by vkhf67 with SMTP id f67so16783429vkh.1 for ; Tue, 22 Sep 2015 15:57:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QyEPfIXLWI2WS8p3PehynvkAoqzdeY3GUi0FsRR3q20=; b=mDQfNWt1z5/rvCCn6kseh0p9vDsxXZDofUET2fmPTOuBGYQGyp5ZY3F1X/7eyd+xBN 7qRllICYx1CqVDNIxiYoghQfk1y7hyq1I/K3QQOTABveTEc70hQnMyc78lub+IiMjN2z pMhjvGgXkNtr6HT0RR78OkdN8CwKZF71MXnqwlmXeCBNY7oqN2v5TCpCXxavKqavHMQ1 6hUMmLsqgBh0qWHb9Z0zafx3vXZzJPlU7B7J6z3zELS+opWd+0l9koJxEfI656uBsZB0 nXS15gaqer5RWCc4JPOPqvP/HEyfIsO6ocec7IChZV0xcNCaTYlzhWD6wq/0WIMmgVMM 93qg==
MIME-Version: 1.0
X-Received: by 10.31.142.142 with SMTP id q136mr20081824vkd.41.1442962648818;  Tue, 22 Sep 2015 15:57:28 -0700 (PDT)
Received: by 10.103.24.67 with HTTP; Tue, 22 Sep 2015 15:57:28 -0700 (PDT)
In-Reply-To: <4832DE1A6E651043A4B3EC7A4E5BCF15C81C93B3@RCHEXMBP1.fnc.net.local>
References: <4832DE1A6E651043A4B3EC7A4E5BCF15C81C93B3@RCHEXMBP1.fnc.net.local>
Date: Tue, 22 Sep 2015 15:57:28 -0700
Message-ID: 
From: John Strassner 
To: "Leroux, Francois" , John Strassner 
Content-Type: multipart/alternative; boundary=001a1143a1ac1b6c5e05205dec2f
Archived-At: 
Cc: "supa@ietf.org" 
Subject: Re: [Supa] ECA Component class inheritance
X-BeenThere: supa@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Sep 2015 22:57:32 -0000

--001a1143a1ac1b6c5e05205dec2f
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Francois,

thank you for noticing this. Figure 10 in the IM is incorrect - a
PolicyAtomic is the superclass for different types of policies (e.g.,
imperative (ECA) and declarative (LogicStatement).

Figure 11 in the IM is correct - an ECAComponent is a type of Policy object=
.

I need to think more about Figure 4 in draft-chen. I know that this is a
"SUPA ECA Policy Data Model", and I know that SUPA (if it turns into a WG)
is not currently mandated to work on declarative (e.g., intent) policies.
However, if it ever does, then Figure 4 strikes me as wrong, since it is
useless to declarative policies.

I will try and comment on draft-chen soon.

regards,
John

On Tue, Sep 22, 2015 at 2:51 PM, Leroux, Francois <
francois.leroux@us.fujitsu.com> wrote:

> John and Yang modeling team,
>
>
>
> While cross reading information and data model drafts I could not figure
> the inheritance scheme for ECA Component. Please see potentially
> conflicting bullets below. IM refers to [I-D.
> draft-strassner-supa-generic-policy-info-model-02] and DM refers to [I-D.
> draft-chen-supa-eca-data-model-03]. SUPA (or supa) prefix is omitted for
> readability.
>
>
>
> 1.       IM p.57 (fig. 10) - ECA Component inherits from Policy Atomic
>
> 2.       IM p.60 (fig. 11) - ECA Component inherits from Policy
>
> 3.       DM p.7 (fig. 4) - ECA Component inherits from ECA Policy Rule
>
>
>
> I first suspected that #3 (DM) was the original intent but then noticed I=
M
> text at the top of p.58 (=E2=80=9C(EPRIM)=E2=80=A6 also specializes the S=
UPAPolicy class to
> create a SUPAECAComponent=E2=80=A6=E2=80=9D) suggesting #2 is correct (an=
d #1 is a typo).
>
>
>
> Please let me know which one is correct.
>
>
>
> Regards,
>
> Fran=C3=A7ois
>
> --
>
>
>
> _______________________________________________
> Supa mailing list
> Supa@ietf.org
> https://www.ietf.org/mailman/listinfo/supa
>
>


--=20
regards,
John

--001a1143a1ac1b6c5e05205dec2f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi Francois,

thank you for n=
oticing this. Figure 10 in the IM=C2=A0is incorrect - a PolicyAtomic is the=
 superclass for different types of policies (e.g., imperative (ECA) and dec=
larative (LogicStatement).

Figure 11 in the IM is =
correct - an ECAComponent is a type of Policy object.

<=
div>I need to think more about Figure 4 in draft-chen. I know that this is =
a "SUPA ECA Policy Data Model", and I know that SUPA (if it turns=
 into a WG) is not currently mandated to work on declarative (e.g., intent)=
 policies. However, if it ever does, then Figure 4 strikes me as wrong, sin=
ce it is useless to declarative policies.

I will t=
ry and comment on draft-chen soon.

regards,
<=
div>John

On Tue, Sep 22, 2015 at 2:51 PM, Leroux, Francois <=
francoi=
s.leroux@us.fujitsu.com> wrote:











John and Yang modeling team,


=C2=A0


While cross reading information and data model draft=
s I could not figure the inheritance scheme for ECA Component. Please see p=
otentially conflicting bullets below. IM refers to [I-D. draft-strassner-su=
pa-generic-policy-info-model-02] and
 DM refers to [I-D. draft-chen-supa-eca-data-model-03]. SUPA (or supa) pref=
ix is omitted for readability.


=C2=A0


1.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0
IM p.57 (fig. 10) - ECA Component inherits from Policy=
 Atomic


2.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0
IM p.60 (fig. 11) - ECA Component inherits from Policy=



3.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0
DM p.7 (fig. 4) - ECA Component inherits from ECA Poli=
cy Rule


=C2=A0


I first suspected that #3 (DM) was the original inte=
nt but then noticed IM text at the top of p.58 (=E2=80=9C(EPRIM)=E2=80=A6 a=
lso specializes the SUPAPolicy class to create a SUPAECAComponent=E2=80=A6=
=E2=80=9D) suggesting #2 is correct (and #1 is a typo).


=C2=A0


Please let me know which one is correct.


=C2=A0


Regards,


Fran=C3=A7oi=
s


--=



=C2=A0







_______________________________________________

Supa mailing list

Supa@ietf.org

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





-- 
regards,
John




--001a1143a1ac1b6c5e05205dec2f--


From nobody Wed Sep 23 12:15:59 2015
Return-Path: 
X-Original-To: supa@ietfa.amsl.com
Delivered-To: supa@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01B161ABD3F for ; Wed, 23 Sep 2015 12:15:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.909
X-Spam-Level: 
X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OKOP96z0sWXu for ; Wed, 23 Sep 2015 12:15:56 -0700 (PDT)
Received: from fncnmp04.fnc.fujitsu.com (fncnmp04.fnc.fujitsu.com [168.127.0.57]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 277741ABD3B for ; Wed, 23 Sep 2015 12:15:56 -0700 (PDT)
X-IronPort-AV: E=Sophos; i="5.17,579,1437454800"; d="scan'208,217"; a="69438211"
Received: from rchexhcp1.fnc.net.local ([168.127.134.75]) by fncnmp02.fnc.fujitsu.com with ESMTP/TLS/AES256-SHA; 23 Sep 2015 14:15:40 -0500
Received: from RCHEXMBP1.fnc.net.local ([169.254.2.53]) by RCHEXHCP1.fnc.net.local ([168.127.134.75]) with mapi id 14.03.0181.006; Wed, 23 Sep 2015 14:15:40 -0500
From: "Leroux, Francois" 
To: John Strassner 
Thread-Topic: [Supa] ECA Component class inheritance
Thread-Index: AdD1gMyDrdQm8GnjR7esww9Asg+fmgAMyokAAB+XfLA=
Date: Wed, 23 Sep 2015 19:15:39 +0000
Message-ID: <4832DE1A6E651043A4B3EC7A4E5BCF15C81C957A@RCHEXMBP1.fnc.net.local>
References: <4832DE1A6E651043A4B3EC7A4E5BCF15C81C93B3@RCHEXMBP1.fnc.net.local> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [168.127.136.253]
x-tm-as-product-ver: SMEX-10.2.0.3176-8.000.1202-21834.002
x-tm-as-result: No--55.808100-0.000000-31
x-tm-as-user-approved-sender: Yes
x-tm-as-user-blocked-sender: No
Content-Type: multipart/alternative; boundary="_000_4832DE1A6E651043A4B3EC7A4E5BCF15C81C957ARCHEXMBP1fncnet_"
MIME-Version: 1.0
Archived-At: 
Cc: "supa@ietf.org" 
Subject: Re: [Supa] ECA Component class inheritance
X-BeenThere: supa@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Sep 2015 19:15:59 -0000

--_000_4832DE1A6E651043A4B3EC7A4E5BCF15C81C957ARCHEXMBP1fncnet_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGkgSm9obiwNCg0KVGhhbmtzIGZvciB0aGUgcXVpY2sgY2xhcmlmaWNhdGlvbi4gRmlndXJlIDEx
IGlzIHdoYXQgSSB0aG91Z2h0IHRvbywgZm9yIHRoZSByZWFzb24geW91IG1lbnRpb25lZCBhbmQg
bW9yZSBnZW5lcmFsbHkgYXMgaW5oZXJpdGFuY2UgZnJvbSBoaWdoZXIgbGV2ZWwgY2xhc3NlcyBm
YXZvcnMgb3ZlcmFsbCByZXVzYWJpbGl0eS4gVGhlIHJlbGF0aW9uc2hpcHMgYmV0d2VlbiBQb2xp
Y3kgQXRvbWljLCBQb2xpY3kgU3RhdGVtZW50IGFuZCBFQ0EgQ29tcG9uZW50IChvci9hbmQgdGhl
aXIgc3ViLWNsYXNzZXMpIGFyZSBub3QgYWx3YXlzIG9idmlvdXMsIGFuZCBlYWNoIHRpbWUgSSBl
bmRlZCB1cCBnZXR0aW5nIHN0dWNrIG9uIEVDQSBDb21wb25lbnQuLi4NCg0KUmVnYXJkcywNCkZy
YW7Dp29pcw0KLS0NCg0KRnJvbTogSm9obiBTdHJhc3NuZXIgW21haWx0bzpzdHJhenBkakBnbWFp
bC5jb21dDQpTZW50OiBUdWVzZGF5LCBTZXB0ZW1iZXIgMjIsIDIwMTUgNTo1NyBQTQ0KVG86IExl
cm91eCwgRnJhbmNvaXM7IEpvaG4gU3RyYXNzbmVyDQpDYzogc3VwYUBpZXRmLm9yZw0KU3ViamVj
dDogUmU6IFtTdXBhXSBFQ0EgQ29tcG9uZW50IGNsYXNzIGluaGVyaXRhbmNlDQoNCkhpIEZyYW5j
b2lzLA0KDQp0aGFuayB5b3UgZm9yIG5vdGljaW5nIHRoaXMuIEZpZ3VyZSAxMCBpbiB0aGUgSU0g
aXMgaW5jb3JyZWN0IC0gYSBQb2xpY3lBdG9taWMgaXMgdGhlIHN1cGVyY2xhc3MgZm9yIGRpZmZl
cmVudCB0eXBlcyBvZiBwb2xpY2llcyAoZS5nLiwgaW1wZXJhdGl2ZSAoRUNBKSBhbmQgZGVjbGFy
YXRpdmUgKExvZ2ljU3RhdGVtZW50KS4NCg0KRmlndXJlIDExIGluIHRoZSBJTSBpcyBjb3JyZWN0
IC0gYW4gRUNBQ29tcG9uZW50IGlzIGEgdHlwZSBvZiBQb2xpY3kgb2JqZWN0Lg0KDQpJIG5lZWQg
dG8gdGhpbmsgbW9yZSBhYm91dCBGaWd1cmUgNCBpbiBkcmFmdC1jaGVuLiBJIGtub3cgdGhhdCB0
aGlzIGlzIGEgIlNVUEEgRUNBIFBvbGljeSBEYXRhIE1vZGVsIiwgYW5kIEkga25vdyB0aGF0IFNV
UEEgKGlmIGl0IHR1cm5zIGludG8gYSBXRykgaXMgbm90IGN1cnJlbnRseSBtYW5kYXRlZCB0byB3
b3JrIG9uIGRlY2xhcmF0aXZlIChlLmcuLCBpbnRlbnQpIHBvbGljaWVzLiBIb3dldmVyLCBpZiBp
dCBldmVyIGRvZXMsIHRoZW4gRmlndXJlIDQgc3RyaWtlcyBtZSBhcyB3cm9uZywgc2luY2UgaXQg
aXMgdXNlbGVzcyB0byBkZWNsYXJhdGl2ZSBwb2xpY2llcy4NCg0KSSB3aWxsIHRyeSBhbmQgY29t
bWVudCBvbiBkcmFmdC1jaGVuIHNvb24uDQoNCnJlZ2FyZHMsDQpKb2huDQoNCk9uIFR1ZSwgU2Vw
IDIyLCAyMDE1IGF0IDI6NTEgUE0sIExlcm91eCwgRnJhbmNvaXMgPGZyYW5jb2lzLmxlcm91eEB1
cy5mdWppdHN1LmNvbTxtYWlsdG86ZnJhbmNvaXMubGVyb3V4QHVzLmZ1aml0c3UuY29tPj4gd3Jv
dGU6DQpKb2huIGFuZCBZYW5nIG1vZGVsaW5nIHRlYW0sDQoNCldoaWxlIGNyb3NzIHJlYWRpbmcg
aW5mb3JtYXRpb24gYW5kIGRhdGEgbW9kZWwgZHJhZnRzIEkgY291bGQgbm90IGZpZ3VyZSB0aGUg
aW5oZXJpdGFuY2Ugc2NoZW1lIGZvciBFQ0EgQ29tcG9uZW50LiBQbGVhc2Ugc2VlIHBvdGVudGlh
bGx5IGNvbmZsaWN0aW5nIGJ1bGxldHMgYmVsb3cuIElNIHJlZmVycyB0byBbSS1ELiBkcmFmdC1z
dHJhc3NuZXItc3VwYS1nZW5lcmljLXBvbGljeS1pbmZvLW1vZGVsLTAyXSBhbmQgRE0gcmVmZXJz
IHRvIFtJLUQuIGRyYWZ0LWNoZW4tc3VwYS1lY2EtZGF0YS1tb2RlbC0wM10uIFNVUEEgKG9yIHN1
cGEpIHByZWZpeCBpcyBvbWl0dGVkIGZvciByZWFkYWJpbGl0eS4NCg0KDQoxLiAgICAgICBJTSBw
LjU3IChmaWcuIDEwKSAtIEVDQSBDb21wb25lbnQgaW5oZXJpdHMgZnJvbSBQb2xpY3kgQXRvbWlj
DQoNCjIuICAgICAgIElNIHAuNjAgKGZpZy4gMTEpIC0gRUNBIENvbXBvbmVudCBpbmhlcml0cyBm
cm9tIFBvbGljeQ0KDQozLiAgICAgICBETSBwLjcgKGZpZy4gNCkgLSBFQ0EgQ29tcG9uZW50IGlu
aGVyaXRzIGZyb20gRUNBIFBvbGljeSBSdWxlDQoNCkkgZmlyc3Qgc3VzcGVjdGVkIHRoYXQgIzMg
KERNKSB3YXMgdGhlIG9yaWdpbmFsIGludGVudCBidXQgdGhlbiBub3RpY2VkIElNIHRleHQgYXQg
dGhlIHRvcCBvZiBwLjU4ICjigJwoRVBSSU0p4oCmIGFsc28gc3BlY2lhbGl6ZXMgdGhlIFNVUEFQ
b2xpY3kgY2xhc3MgdG8gY3JlYXRlIGEgU1VQQUVDQUNvbXBvbmVudOKApuKAnSkgc3VnZ2VzdGlu
ZyAjMiBpcyBjb3JyZWN0IChhbmQgIzEgaXMgYSB0eXBvKS4NCg0KUGxlYXNlIGxldCBtZSBrbm93
IHdoaWNoIG9uZSBpcyBjb3JyZWN0Lg0KDQpSZWdhcmRzLA0KRnJhbsOnb2lzDQotLQ0KDQoNCl9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpTdXBhIG1haWxp
bmcgbGlzdA0KU3VwYUBpZXRmLm9yZzxtYWlsdG86U3VwYUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3
LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3VwYQ0KDQoNCg0KLS0NCnJlZ2FyZHMsDQpKb2hu
DQo=

--_000_4832DE1A6E651043A4B3EC7A4E5BCF15C81C957ARCHEXMBP1fncnet_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2
IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs
aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t
Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv
bWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy
aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph
OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5
Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7
bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdp
bi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6
MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs
InNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1y
ZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMwMDIw
NjA7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBh
Z2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBp
biAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30N
Ci0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6
ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBn
dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2
OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0t
LT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxl
Ij4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwMjA2MCI+SGkgSm9obiw8bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm
cXVvdDs7Y29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDIwNjAi
PlRoYW5rcyBmb3IgdGhlIHF1aWNrIGNsYXJpZmljYXRpb24uIEZpZ3VyZSAxMSBpcyB3aGF0IEkg
dGhvdWdodCB0b28sIGZvciB0aGUgcmVhc29uIHlvdSBtZW50aW9uZWQgYW5kIG1vcmUgZ2VuZXJh
bGx5IGFzIGluaGVyaXRhbmNlIGZyb20gaGlnaGVyIGxldmVsIGNsYXNzZXMNCiBmYXZvcnMgb3Zl
cmFsbCByZXVzYWJpbGl0eS4gVGhlIHJlbGF0aW9uc2hpcHMgYmV0d2VlbiBQb2xpY3kgQXRvbWlj
LCBQb2xpY3kgU3RhdGVtZW50IGFuZCBFQ0EgQ29tcG9uZW50IChvci9hbmQgdGhlaXIgc3ViLWNs
YXNzZXMpIGFyZSBub3QgYWx3YXlzIG9idmlvdXMsIGFuZCBlYWNoIHRpbWUgSSBlbmRlZCB1cCBn
ZXR0aW5nIHN0dWNrIG9uIEVDQSBDb21wb25lbnQuLi4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj
MDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwMjA2MCI+UmVnYXJkcyw8bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJGUiIg
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm
cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDIwNjAiPkZyYW7Dp29pczxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwMjA2MCI+LS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAw
MjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v
bmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAw
aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi
PkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEpvaG4gU3RyYXNz
bmVyIFttYWlsdG86c3RyYXpwZGpAZ21haWwuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNk
YXksIFNlcHRlbWJlciAyMiwgMjAxNSA1OjU3IFBNPGJyPg0KPGI+VG86PC9iPiBMZXJvdXgsIEZy
YW5jb2lzOyBKb2huIFN0cmFzc25lcjxicj4NCjxiPkNjOjwvYj4gc3VwYUBpZXRmLm9yZzxicj4N
CjxiPlN1YmplY3Q6PC9iPiBSZTogW1N1cGFdIEVDQSBDb21wb25lbnQgY2xhc3MgaW5oZXJpdGFu
Y2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5I
aSBGcmFuY29pcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+dGhhbmsgeW91IGZvciBub3RpY2luZyB0aGlzLiBGaWd1cmUgMTAgaW4gdGhlIElN
Jm5ic3A7aXMgaW5jb3JyZWN0IC0gYSBQb2xpY3lBdG9taWMgaXMgdGhlIHN1cGVyY2xhc3MgZm9y
IGRpZmZlcmVudCB0eXBlcyBvZiBwb2xpY2llcyAoZS5nLiwgaW1wZXJhdGl2ZSAoRUNBKSBhbmQg
ZGVjbGFyYXRpdmUgKExvZ2ljU3RhdGVtZW50KS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RmlndXJlIDExIGluIHRoZSBJTSBpcyBjb3JyZWN0
IC0gYW4gRUNBQ29tcG9uZW50IGlzIGEgdHlwZSBvZiBQb2xpY3kgb2JqZWN0LjxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIG5lZWQgdG8gdGhp
bmsgbW9yZSBhYm91dCBGaWd1cmUgNCBpbiBkcmFmdC1jaGVuLiBJIGtub3cgdGhhdCB0aGlzIGlz
IGEgJnF1b3Q7U1VQQSBFQ0EgUG9saWN5IERhdGEgTW9kZWwmcXVvdDssIGFuZCBJIGtub3cgdGhh
dCBTVVBBIChpZiBpdCB0dXJucyBpbnRvIGEgV0cpIGlzIG5vdCBjdXJyZW50bHkgbWFuZGF0ZWQg
dG8gd29yayBvbiBkZWNsYXJhdGl2ZSAoZS5nLiwgaW50ZW50KSBwb2xpY2llcy4gSG93ZXZlciwg
aWYgaXQNCiBldmVyIGRvZXMsIHRoZW4gRmlndXJlIDQgc3RyaWtlcyBtZSBhcyB3cm9uZywgc2lu
Y2UgaXQgaXMgdXNlbGVzcyB0byBkZWNsYXJhdGl2ZSBwb2xpY2llcy48bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB3aWxsIHRyeSBhbmQgY29t
bWVudCBvbiBkcmFmdC1jaGVuIHNvb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPnJlZ2FyZHMsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Kb2huPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFR1ZSwgU2VwIDIyLCAyMDE1IGF0IDI6NTEg
UE0sIExlcm91eCwgRnJhbmNvaXMgJmx0OzxhIGhyZWY9Im1haWx0bzpmcmFuY29pcy5sZXJvdXhA
dXMuZnVqaXRzdS5jb20iIHRhcmdldD0iX2JsYW5rIj5mcmFuY29pcy5sZXJvdXhAdXMuZnVqaXRz
dS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t
Ym90dG9tLWFsdDphdXRvIj5Kb2huIGFuZCBZYW5nIG1vZGVsaW5nIHRlYW0sPG86cD48L286cD48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87
bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t
Ym90dG9tLWFsdDphdXRvIj5XaGlsZSBjcm9zcyByZWFkaW5nIGluZm9ybWF0aW9uIGFuZCBkYXRh
IG1vZGVsIGRyYWZ0cyBJIGNvdWxkIG5vdCBmaWd1cmUgdGhlIGluaGVyaXRhbmNlIHNjaGVtZSBm
b3IgRUNBIENvbXBvbmVudC4gUGxlYXNlIHNlZSBwb3RlbnRpYWxseSBjb25mbGljdGluZyBidWxs
ZXRzIGJlbG93LiBJTSByZWZlcnMgdG8NCiBbSS1ELiBkcmFmdC1zdHJhc3NuZXItc3VwYS1nZW5l
cmljLXBvbGljeS1pbmZvLW1vZGVsLTAyXSBhbmQgRE0gcmVmZXJzIHRvIFtJLUQuIGRyYWZ0LWNo
ZW4tc3VwYS1lY2EtZGF0YS1tb2RlbC0wM10uIFNVUEEgKG9yIHN1cGEpIHByZWZpeCBpcyBvbWl0
dGVkIGZvciByZWFkYWJpbGl0eS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cD4xLjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4w
cHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+SU0gcC41NyAo
ZmlnLiAxMCkgLSBFQ0EgQ29tcG9uZW50IGluaGVyaXRzIGZyb20gUG9saWN5IEF0b21pYzxvOnA+
PC9vOnA+PC9wPg0KPHA+Mi48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0Ij4mbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPklNIHAuNjAgKGZpZy4gMTEpIC0gRUNB
IENvbXBvbmVudCBpbmhlcml0cyBmcm9tIFBvbGljeTxvOnA+PC9vOnA+PC9wPg0KPHA+My48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjcuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsgPC9zcGFuPkRNIHAuNyAoZmlnLiA0KSAtIEVDQSBDb21wb25lbnQgaW5oZXJpdHMgZnJv
bSBFQ0EgUG9saWN5IFJ1bGU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+
Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgZmlyc3Qgc3Vz
cGVjdGVkIHRoYXQgIzMgKERNKSB3YXMgdGhlIG9yaWdpbmFsIGludGVudCBidXQgdGhlbiBub3Rp
Y2VkIElNIHRleHQgYXQgdGhlIHRvcCBvZiBwLjU4ICjigJwoRVBSSU0p4oCmIGFsc28gc3BlY2lh
bGl6ZXMgdGhlIFNVUEFQb2xpY3kgY2xhc3MgdG8gY3JlYXRlIGEgU1VQQUVDQUNvbXBvbmVudOKA
puKAnSkNCiBzdWdnZXN0aW5nICMyIGlzIGNvcnJlY3QgKGFuZCAjMSBpcyBhIHR5cG8pLjxvOnA+
PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs
dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t
bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+UGxlYXNlIGxldCBtZSBrbm93IHdoaWNoIG9uZSBpcyBj
b3JyZWN0LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t
YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw
PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h
bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOmJs
YWNrIj5SZWdhcmRzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
byI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJjb2xvcjpibGFjayI+RnJhbsOnb2lzPC9zcGFuPjxv
OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w
LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJGUiIgc3R5
bGU9ImNvbG9yOmJsYWNrIj4tLTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h
bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpfX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NClN1cGEgbWFpbGluZyBs
aXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOlN1cGFAaWV0Zi5vcmciPlN1cGFAaWV0Zi5vcmc8L2E+
PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdXBh
IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9z
dXBhPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+
DQo8YnIgY2xlYXI9ImFsbCI+DQo8YnI+DQotLSA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+cmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkpvaG48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_4832DE1A6E651043A4B3EC7A4E5BCF15C81C957ARCHEXMBP1fncnet_--


From nobody Wed Sep 30 16:03:57 2015
Return-Path: 
X-Original-To: supa@ietfa.amsl.com
Delivered-To: supa@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BDEC1AC409; Wed, 30 Sep 2015 16:03:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ovxmit6H-FPe; Wed, 30 Sep 2015 16:03:53 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C9DC1AC408; Wed, 30 Sep 2015 16:03:53 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "Ben Campbell" 
To: "The IESG" 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.4.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150930230353.508.22284.idtracker@ietfa.amsl.com>
Date: Wed, 30 Sep 2015 16:03:53 -0700
Archived-At: 
Cc: supa@ietf.org
Subject: [Supa] Ben Campbell's No Record on charter-ietf-supa-00-14: (with COMMENT)
X-BeenThere: supa@ietf.org
X-Mailman-Version: 2.1.15
List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Sep 2015 23:03:54 -0000

Ben Campbell has entered the following ballot position for
charter-ietf-supa-00-14: No Record

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)



The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-supa/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

paragraph 5:

s/matter that saves development time/manner that saves development time



From nobody Wed Sep 30 16:04:18 2015
Return-Path: 
X-Original-To: supa@ietfa.amsl.com
Delivered-To: supa@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 339DA1AC3E1; Wed, 30 Sep 2015 16:04:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TSRM2fUSuT_b; Wed, 30 Sep 2015 16:04:17 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 20D2B1AC3DB; Wed, 30 Sep 2015 16:04:17 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "Ben Campbell" 
To: "The IESG" 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.4.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150930230417.757.4141.idtracker@ietfa.amsl.com>
Date: Wed, 30 Sep 2015 16:04:17 -0700
Archived-At: 
Cc: supa@ietf.org
Subject: [Supa] Ben Campbell's No Objection on charter-ietf-supa-00-14: (with COMMENT)
X-BeenThere: supa@ietf.org
X-Mailman-Version: 2.1.15
List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Sep 2015 23:04:18 -0000

Ben Campbell has entered the following ballot position for
charter-ietf-supa-00-14: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)



The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-supa/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

paragraph 5:

s/matter that saves development time/manner that saves development time



From nobody Wed Sep 30 23:24:45 2015
Return-Path: 
X-Original-To: supa@ietfa.amsl.com
Delivered-To: supa@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C590B1B2A5C; Wed, 30 Sep 2015 23:24:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OTuU3LKs70e2; Wed, 30 Sep 2015 23:24:43 -0700 (PDT)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25B451B2A4B; Wed, 30 Sep 2015 23:24:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=747; q=dns/txt; s=iport; t=1443680684; x=1444890284; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=L+uupmQDSuqaV3/IL2nFAvYlzMRTrtNS4p+xVoIK2x0=; b=Yks3D6LfCF2k/BRhUHPwazN5QIjB2CFKM5JzpBJVdGS0DQwiCpkCaeKX SGloT4aFHEdhZJBnW4bK/5Up0ou4q0XiCujKgg5HQUnogXe6EDlcqf49V lmD7dIP9rxWmCzE/f/KRjJnAMHAwnEZzgtUOQTX0DNQPgIf0DG3GOUkzL 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DYAQAh0QxW/xbLJq1eg3uEGLYbhCEBDYF7hXkCgWUUAQEBAQEBAYEKhCUBAQMBIxVAAQULCxoCBRYLAgIJAwIBAgFFBgEMCAEBiCIIDbcNlE4BAQEBAQEBAQEBAQEBAQEBAQEBAQETBIEihVGEfYQqEQFRB4JpgUMBBIc2jkKFFod9gU+ENoMAkksfAQFChAQ8iG6BPwEBAQ
X-IronPort-AV: E=Sophos;i="5.17,616,1437436800"; d="scan'208";a="611949503"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 01 Oct 2015 06:24:40 +0000
Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t916OdNL032601; Thu, 1 Oct 2015 06:24:39 GMT
To: Ben Campbell , The IESG 
References: <20150930230417.757.4141.idtracker@ietfa.amsl.com>
From: Benoit Claise 
Message-ID: <560CD1A7.8080300@cisco.com>
Date: Thu, 1 Oct 2015 08:24:39 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <20150930230417.757.4141.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: supa@ietf.org
Subject: Re: [Supa] Ben Campbell's No Objection on charter-ietf-supa-00-14: (with COMMENT)
X-BeenThere: supa@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 01 Oct 2015 06:24:44 -0000

Fixed. Thanks Ben.

Regards, Benoit

> Ben Campbell has entered the following ballot position for
> charter-ietf-supa-00-14: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/charter-ietf-supa/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> paragraph 5:
>
> s/matter that saves development time/manner that saves development time
>
>
> .
>