Subject: Re: [Supa] SUPA charter proposal

From: Benoit Claise <[email-masked]>
Date: Wed, 2 Sep 2015 17:36:51 +0200

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 <[email-masked] 
> <mailto:[email-masked]>> 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
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/listinfo/supa
>
>
>
>
> _______________________________________________
> Supa mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/supa

---

From: Benoit Claise <[email-masked]>
Date: Wed, 2 Sep 2015 17:40:45 +0200

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 
> <[email-masked] <mailto:[email-masked]>> 
> 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
>     <tel:%2B1%20%28781%29%20366-7763> | www.
>     <http://www.NetCracker.com>Net <http://www.NetCracker.com>Cracker
>     <http://www.NetCracker.com>.com <http://www.NetCracker.com>  >>>> 
>     * Proven Partner to Communications Service Providers*
>
>>     On Aug 8, 2015, at 1:48 PM, Andy Bierman <[email-masked]
>>     <mailto:[email-masked]>> wrote:
>>
>>     Hi,
>>
>>         As promised in my last email ("SUPA: Situation Summary and
>>         Next Steps"), here is a proposed charter.
>>         Hopefully, this new version will clarify the situation, and
>>         will be acceptable to everybody.
>>         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
>>         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.
>>
>>         -The specification of a new policy language. The YANG data
>>         models are to be used with protocols such as NETCONF/RESTCONF.
>>
>>         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:
>>
>>         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.
>>
>>         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.
>>
>>         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 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.
>
> -- 
> regards,
> John

---

From: Benoit Claise <[email-masked]>
Date: Wed, 2 Sep 2015 17:47:51 +0200

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 
> 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:[email-masked]] *On Behalf Of *Benoit Claise
> *Sent:* Friday, August 07, 2015 11:03 AM
> *To:* [email-masked]
> *Cc:* Eggert, Lars
> *Subject:* [Supa] SUPA charter proposal
>
> Dear all,
>
> Hopefully, this new version will clarify the situation, and will be 
> acceptable to everybody.
> 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.
>
> 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
>
> policy, which can point to device-, technology-, and service-specific 
> YANG models of other working groups.
>
> 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.
>
> 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.
>
> -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.
>
> 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.
>
> 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
>

---

From: Benoit Claise <[email-masked]>
Date: Wed, 2 Sep 2015 18:13:20 +0200

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
> *Sent:* Friday, August 07, 2015 7:03 PM
> *To:* [email-masked]
> *Cc:* Eggert, Lars
> 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 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.

---

From: Benoit Claise <[email-masked]>
Date: Wed, 2 Sep 2015 18:31:23 +0200

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 [[email-masked]] on behalf of Benoit Claise 
> [[email-masked]]
> *Sent:* 08 August 2015 02:03
> *To:* [email-masked]
> *Cc:* Eggert, Lars
> different levels of abstraction.Specifically, three model fragments

---

From: Maxim Klyus <[email-masked]>
Date: Thu, 3 Sep 2015 05:20:30 +0000

Hi Benoit,

my comments inline.

________________________________
From: Benoit Claise [[email-masked]]
Sent: Wednesday, September 02, 2015 7:13 PM
To: Maxim Klyus; [email-masked]
Cc: Eggert, Lars; Juergen Schoenwaelder ([email-masked])
Subject: Re: [Supa] SUPA charter proposal

Hi Benoit et al,

“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).“

[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 guess that 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 service management. Many SDOs already defined - controllers can ogranize hierarchy for management and administrative purpose, so I don't see any contradiction here.

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

[MK] Ok.

Regards, Benoit

Best Regards,
Maxim Klyus

From: Supa [mailto:[email-masked]] On Behalf Of Benoit Claise
Sent: Friday, August 07, 2015 7:03 PM
To: [email-masked]<mailto:[email-masked]>
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)

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.

-   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.

________________________________
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.

---

From: "Leroux, Francois" <[email-masked]>
Date: Mon, 7 Sep 2015 17:53:53 +0000

Benoit,
Thanks for your reply, and sorry for the (very) late response.
Please see possible update below for item 1). This is with the understanding 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 other
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 applicable to multiple systems, 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 suggest boiling the ocean...).
Regards,
François
--

From: Benoit Claise [mailto:[email-masked]]
Sent: Wednesday, September 02, 2015 10:48 AM
To: Leroux, Francois; [email-masked]
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 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

From: Supa [mailto:[email-masked]] On Behalf Of Benoit Claise
Sent: Friday, August 07, 2015 11:03 AM
To: [email-masked]<mailto:[email-masked]>
Cc: Eggert, Lars
Subject: [Supa] SUPA charter proposal

Dear all,

Regards, Benoit (OPS AD)