Subject: [Supa] For your charter discussion

From: Jon Saperia <[email-masked]>
Date: Mon, 20 Jul 2015 10:50:12 -0400

In talking about the effort with people over the past couple of weeks, it seems like the charter could be updated a bit based on some of the presentation material for the meeting.

I started with the existing charter and made changes.  Here is a proposal:

SUPA CHARTER PROPOSAL - Suggested Revision (2015-07-19)

Configuration error continues to be a key contributor to service failures.
The manual way configuration changes are made to individual network and other
service delivery elements is central to this problem. These errors tend not
to be basic syntax errors but errors of logic in provisioning the elements
to cooperatively deliver a desired service throughout the service delivery
environment. This is especially important as services become more complex,
existing in both physical and virtual environments across multiple vendors,
technologies and configuration paradigms. A unified approach to the specification
of policy that can accommodate these differences is critical to the interoperation
of these environments.

The SUPA (Simplified Use of Policy Abstractions) WG is chartered to
define an architecture for the specification of high-level policy such as:
only allow traffic from subnets "A" and "B" over ports "D" and "E" to be
expressed across multiple physical and virtual systems or, all sales group 
systems must us VPN XXX, and use YYY code server.

The working group will accomplish this by constructing several 
components and defined interfaces to them to foster greater management
interoperation.

     - A generic policy information model (GPIM) for use in network
       operations and management applications. The GPIM is the way 
       policies are expressed in a vendor and technology independent
       way. 

     - A generic data model and interfaces. This generic model
       defines the set of rules through which a policy based on the
       GPIM is converted into managed system/technology specific
       data models. It is the interface that enables system/technology
       data models to be integrated into the SUPA environment. This model
       will be architected to be modular so that additions may be made as 
       needed and initial steps are not restricted by a desire to address
       every possible technology.

     - YANG-specific data models as examples of how to integrate 
       into the SUPA environment using NETCONF/RESTCONF.

     - One or more additional system/technology data models as
       examples of other device/element protocols and how they
       integrate into the SUPA environment as examples of broad
       interoperability.

The working group will define the language/methods to represent the 
information and generic data models. The YANG-specific examples show 
how the environment integrates with the NETCONF/RESTCONF environment. 
The additional data models, in the form/language that is native to them
will show how other technologies can be brought under the SUPA 
environment fostering wider interoperability.

SUPA will be designed to work together with network service models.
In particular, the creation of a network service instance should be
able to trigger the execution of SUPA policies, and the same is true
for the deletion of network service instances, or any other major
state changes, during the network service development and deployment
lifecycle. SUPA will be loosely bound to network service models.
SUPA will also allow operators to express policies that are not bound
to specific network service instances.

List of work items:

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

2) A generic policy information model consisting of a base policy
   information model for representing policy management concepts
   independent of the type or structure of a policy, an extension of
   the base policy information model for defining policy rules
   according to the event-condition-action paradigm, and an extension
   of the base policy information model for defining policy rules
   according to a declarative, or intent-based, paradigm.

3) A set of YANG data models that express the concepts defined in the
   generic policy information model in concrete data models. These
   models will be designed to be generic and extensible.

4) A set of data models appropriate to the expression of concepts
   in the generic policy information model in concrete data models
   appropriate to one or more technologies/models such as SDN.

4) An applicability document providing a number of examples that
   demonstrate how the generic policy models can be used to express
   policies that are relevant for operators. The examples may
   tie into 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 the L3SM working group working
on layer 3 VPN service models and the I2RS working group working on
generic network topology models in the context of the use cases.

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

Milestones:

TBD

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 20 Jul 2015 17:34:58 +0200

Jon,

I have been holding the pen on the charter in the past and I would
appreciate if people suggesting changes send the specific change
requests together with a reasoning for the change. Just throwing out
new text is not that helpful. After all, there needs to be some sort
of consensus between the contributors and for that it is useful to
know what is proposed to be changed and why.

/js

On Mon, Jul 20, 2015 at 10:50:12AM -0400, Jon Saperia wrote:
> _______________________________________________
> Supa mailing list
> [email-masked]
> 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         <http://www.jacobs-university.de/>

---

From: Jon Saperia <[email-masked]>
Date: Mon, 20 Jul 2015 11:45:01 -0400

Juergen, I made the suggestions based on the posting John made to this list on material to be presented at the BOF. The suggestions below are also consistent with material andy is also presenting. The old charter did not have a clear statement of the problem to be solved.
/jon
> On Jul 20, 2015, at 11:34 AM, Juergen Schoenwaelder <[email-masked]> wrote:
> 
> Jon,
> 

Thanks
/jon
------------------------------------
Jon Saperia
(mobil) 617-201-2655
[email-masked]

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 20 Jul 2015 18:03:56 +0200

Jon, I like to understand exactly what was changed and why and this
explanation is I think too broad. There has been lots of back and
forth on the charter text and it just does not work to say "hey here
is I think a better charter".

/js

---

From: Jon Saperia <[email-masked]>
Date: Mon, 20 Jul 2015 13:10:38 -0400

I used the charter that Dan pointed to in his note to this list on 7/14.  The URL he had was:

	http://cnds.eecs.jacobs-university.de/users/schoenw/supa/supa-charter-2015-06-15.txt <http://cnds.eecs.jacobs-university.de/users/schoenw/supa/supa-charter-2015-06-15.txt>

> SUPA CHARTER PROPOSAL (2015-06-15)
> 
> SUPA (Simplified Use of Policy Abstractions) is defining an interface
> to a network management function that takes high-level, possibly
> network-wide policies as input and creates element configurations
> snippets as output.
The paragraph above does not contain a statement of the problem to be solved which is often at the start of a charter. The paragraph above has “defining an interface to a network management function”. Based on the slides presented to this list for discussion at the BOF, SUPA is more than an interface.  It is an architecture that incorporates more than an interface or the GPIM in the following paragraph.
> 
> SUPA will define a generic policy information model (GPIM) for use in
> network operations and management applications. The GPIM can represent
> different types of policy rules for controlling managed entities
> throughout the service development and deployment lifecycle. The GPIM
> will be translated into corresponding YANG data models to define
> interoperable implementations that can exchange and modify generic
> policies using protocols such as NETCONF/RESTCONF.
> 
> SUPA defines technology to express management policies that control
> the configuration of network elements. Management policies can be
> interpreted outside of network elements, and the interpretation
> typically results in configuration changes of collections of network
> elements.
The two paragraphs above omitted an example how this would work and look from an operator perspective. For this reason I created the alternate material I sent. It did not incorporate a clear list of components either. The first part is designed to address both of these concerns:

> 
> Policies embedded in the configuration of network elements are not in
> the scope of SUPA. In contrast to policies targeted by SUPA, embedded
> policies are usually interpreted on network elements in isolation, and
> often at timescales that require the representation of embedded
> policies to be optimized for a specific purpose. Some examples of
> embedded policies that are not in the scope of SUPA:
> 
>   - packet filtering policies
>   - packet marking and scheduling policies
>   - route import and export policies
>   - authorization policies (configured on network elements)
I appreciate the value describing out of scope work.  The examples above however were confusing to me and deleted them in favor of the examples used in the previous section.  Text was added to further illustrate how the anticipated system could work:

> lifecycle. SUPA will be loosely bound to network service models. In
> particular, SUPA will also allow operators to express policies that
> are not bound to specific network service instances.

The above paragraph was largely unchanged with the exception of the removal of “In particular” at the start of the last sentence. It seemed unnecessary.
> 
> The SUPA working group will develop an information model for
> expressing policy at different levels of abstraction.  Specifically,
> three information model fragments are envisioned: (i) a generic
> information model that defines concepts needed by policy management
> independent of the form and content of the policy, (ii) a more
> specific information model that refines the generic information model
> to specify how to build policy rules of the event-condition-action
> paradigm, and (iii) a more specific information model that refines the
> generic information model to specify how to build policy rules that
> declaratively specify what goals to achieve (but not how to achieve
> those goals); this is often called "intent-based" policy. The SUPA
> working group will translate the generic policy information model into
> concrete YANG data models that define how to manage and communicate
> policies between systems.
> 
The detail about information model abstraction (the three levels) is probably quite correct, but seemed a bit more than needed in the charter statement which is why it was not included in the proposal.  
>    IETF.
In order to foster better interoperability, SDOs beyond the IETF are relevant.  That is why the above was modified as:

>    according to a declarative, or intent-based, paradigm.
No changes.
>    models will be designed to be generic and extensible.
No changes.

Added:
>    policies that are relevant for network operators. The examples may

No changes other than this was mis-numbered in my previous note.  It should be #5 given the addition (4) suggested above.
> that are working on related issues.

No changes.

> On Jul 20, 2015, at 12:03 PM, Juergen Schoenwaelder <[email-masked]> wrote:
> 
> Fax:   +49 421 200 3103         <http://www.jacobs-university.de/ <http://www.jacobs-university.de/>>

Thanks
/jon

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 21 Jul 2015 14:38:15 +0200

Comments inline...

/js

> of policy that can accommodate these differences is critical to the interoperation

Well, I do not have a strong opinion whether this motivation paragraph
is neededd or not.

> systems must us VPN XXX, and use YYY code server.

I might disagree with replacement of function with architecture. I
believe to be useful, SUPA needs to work out how the translation of
policy into device configuration works. Just having an architecture is
not helping anyone to run a network. I believe the focus on the
function is crucial to deliver something practically useful.

>        data models.

I am confused here. Using the compiler analogy, the idea is to produce
a generic data model that exposes how the compiler internally works?
This is I think a major shift from what I understood SUPA is before.

>        It is the interface that enables system/technology

I am unsure what this boils down to in practice and

>        integrate into the SUPA environment as examples of broad

how it is different from this later point. I also find the phrase
"other device/element protocols" somewhat open ended to begin with.

> I appreciate the value describing out of scope work.  The examples above however were confusing to me and deleted them in favor of the examples used in the previous section.

Why did the examples confuse you? There was a long discussion that
lead to this and I do feel we should dismiss this. I believe the
distinction of SUPA policies and policy mechanisms embedded in
technology specific data models is crucial. As I said, we had a long
discussion about this.

>  Text was added to further illustrate how the anticipated system could work:
 
> environment fostering wider interoperability.

I believe this is expanding the work significantly. The devil is in
the details of semantic differences.
 
> The above paragraph was largely unchanged with the exception of the removal of “In particular” at the start of the last sentence. It seemed unnecessary.

OK

> The detail about information model abstraction (the three levels) is probably quite correct, but seemed a bit more than needed in the charter statement which is why it was not included in the propo…

Again, there was lots of discussion that led to this text in this
level of detail. And it is a major scope clarification, namely whether
SUPA is limite to ECA policies or also inclues declarative policies.

>    management framework and how it relates to existing work of the

Again, it is feasible to do this for the IETF, it is harder to do this
for an open ended set of SDOs. How does the WG determine that they are
done with the framework?

> No changes other than this was mis-numbered in my previous note.  It should be #5 given the addition (4) suggested above.

I believe your 4) is covered by the old 4). My understanding so far
was that the YANG data model is generic enough that it can take
high-level policies that translate to config snippets of arbitrary
data models. And for a WG charter, 'one or more technologies/models
such as SDN' is IMHO too vague.

---

From: Jon Saperia <[email-masked]>
Date: Tue, 21 Jul 2015 08:56:53 -0400

Tell you what, others have been talking about this as well.  Since I am not there and time is short, leave it to the the people at the meeting. If they want a change, OK, if not, OK. Perhaps it is too late.
/jon
> On Jul 21, 2015, at 8:38 AM, Juergen Schoenwaelder <[email-masked]> wrote:
> 
> Comments inline...
> 
> /js
> 

Thanks
/jon

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 21 Jul 2015 15:19:20 +0200

Jon,

it is not too late to change the charter text since I do expect
charter text discussion during the BoF - this is what a BoF is at the
end good for.

However, people prepare for the BoF sessions using the charter that
has to been posted well in advance of the meeting (so that people can
prepare for the meeting), hence making significant changes before the
BoF causes confusion.

Note that you can join the BoF remotely to make your points if you
feel so. But things need to be broken down in pieces for people to
grok it during the BoF.

/js

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 21 Jul 2015 14:51:14 +0000

I would agree with Juergen on this. If the BOF is successful the next thing that this team will be asked to do is revising the charter towards submission to the IESG. Of course, people who have huge reservation concerning the charter should clearly state this in the BoF. 

Regards,

Dan

> -----Original Message-----
> From: Supa [mailto:[email-masked]] On Behalf Of Juergen
> Schoenwaelder
> Sent: Tuesday, July 21, 2015 4:19 PM
> To: Jon Saperia
> Cc: [email-masked]
> Subject: Re: [Supa] For your charter discussion
> 
> Jon,
> 
> it is not too late to change the charter text since I do expect charter text
> discussion during the BoF - this is what a BoF is at the end good for.
> 
> However, people prepare for the BoF sessions using the charter that has to
> been posted well in advance of the meeting (so that people can prepare for
> the meeting), hence making significant changes before the BoF causes
> confusion.
> 
> Note that you can join the BoF remotely to make your points if you feel so.
> But things need to be broken down in pieces for people to grok it during the
> BoF.
> 
> /js
> 
> > Tell you what, others have been talking about this as well.  Since I am not
> there and time is short, leave it to the the people at the meeting. If they
> want a change, OK, if not, OK. Perhaps it is too late.
> > /jon
> > > On Jul 21, 2015, at 8:38 AM, Juergen Schoenwaelder
> <[email-masked]> wrote:
> > >
> > > Comments inline...
> > >
> > > /js
> > >
> > >> https://urldefense.proofpoint.com/v2/url?u=http-3A__cnds.eecs.jacob
> > >> s-2Duniversity.de_users_schoenw_supa_supa-2Dcharter-2D2015-2D06-
> 2D1
> > >>
> 5.txt&d=AwIGaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvls
> iLQf
> > >>
> ucBXRucPvdrphpBsFA&m=EO0aw5JtQmEUoZqKCbwrELIIRW7XsXlMFMppTlN
> vC1E&s=
> > >> 0zz6iZEbhoaFlEkK9Y_LlIaZvGlZqNi0sGj9MXafB14&e=
> > >> <https://urldefense.proofpoint.com/v2/url?u=http-3A__cnds.eecs.jaco
> > >> bs-2Duniversity.de_users_schoenw_supa_supa-2Dcharter-2D2015-
> 2D06-2D
> > >>
> 15.txt&d=AwIGaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvl
> siLQ
> > >>
> fucBXRucPvdrphpBsFA&m=EO0aw5JtQmEUoZqKCbwrELIIRW7XsXlMFMppTl
> NvC1E&s
> > >> =0zz6iZEbhoaFlEkK9Y_LlIaZvGlZqNi0sGj9MXafB14&e= >
> > >>
> > >>> SUPA (Simplified Use of Policy Abstractions) is defining an
> > >>> interface to a network management function that takes high-level,
> > >>> possibly network-wide policies as input and creates element
> > >>> configurations snippets as output.
> > >> The paragraph above does not contain a statement of the problem to
> be solved which is often at the start of a charter. The paragraph above has
> “defining an interface to a network management function”. Based on the
> slides presented to this list for discussion at the BOF, SUPA is more than an
> interface.  It is an architecture that incorporates more than an interface or
> the GPIM in the following paragraph.
> > >>>
> > >>> SUPA will define a generic policy information model (GPIM) for use
> > >>> in network operations and management applications. The GPIM can
> > >>> represent different types of policy rules for controlling managed
> > >>> entities throughout the service development and deployment
> > >>> lifecycle. The GPIM will be translated into corresponding YANG
> > >>> data models to define interoperable implementations that can
> > >>> exchange and modify generic policies using protocols such as
> NETCONF/RESTCONF.
> > >>>
> > >>> SUPA defines technology to express management policies that
> > >>> control the configuration of network elements. Management policies
> > >>> can be interpreted outside of network elements, and the
> > >>> interpretation typically results in configuration changes of
> > >>> collections of network elements.
> > >> The two paragraphs above omitted an example how this would work
> and look from an operator perspective. For this reason I created the
> alternate material I sent. It did not incorporate a clear list of components
> either. The first part is designed to address both of these concerns:
> > >>
> > >> The manual way configuration changes are made to individual network
> > >> and other service delivery elements is central to this problem.
> > >> These errors tend not to be basic syntax errors but errors of logic
> > >> in provisioning the elements to cooperatively deliver a desired
> > >> service throughout the service delivery environment. This is
> > >> especially important as services become more complex, existing in
> > >> both physical and virtual environments across multiple vendors,
> > >> technologies and configuration paradigms. A unified approach to the
> > >> specification of policy that can accommodate these differences is critical
> to the interoperation of these environments.
> > >
> > > Well, I do not have a strong opinion whether this motivation
> > > paragraph is neededd or not.
> > >
> > >> only allow traffic from subnets "A" and "B" over ports "D" and "E"
> > >> to be expressed across multiple physical and virtual systems or,
> > >> all sales group systems must us VPN XXX, and use YYY code server.
> > >
> > > policy into device configuration works. Just having an architecture
> > > is not helping anyone to run a network. I believe the focus on the
> > >> components and defined interfaces to them to foster greater
> > >> management interoperation.
> > >>
> > > I am confused here. Using the compiler analogy, the idea is to
> > > produce a generic data model that exposes how the compiler internally
> works?
> > >>> Policies embedded in the configuration of network elements are not
> > >>> in the scope of SUPA. In contrast to policies targeted by SUPA,
> > >>> embedded policies are usually interpreted on network elements in
> > >>> isolation, and often at timescales that require the representation
> > >>> of embedded policies to be optimized for a specific purpose. Some
> > >>> examples of embedded policies that are not in the scope of SUPA:
> > >>>
> > >> I appreciate the value describing out of scope work.  The examples
> above however were confusing to me and deleted them in favor of the
> examples used in the previous section.
> > >
> > >> information and generic data models. The YANG-specific examples
> > >> show how the environment integrates with the NETCONF/RESTCONF
> environment.
> > >> The additional data models, in the form/language that is native to
> > >> them will show how other technologies can be brought under the SUPA
> > >>> In particular, the creation of a network service instance should
> > >>> be able to trigger the execution of SUPA policies, and the same is
> > >>> true for the deletion of network service instances, or any other
> > >>> major state changes, during the network service development and
> > >>> deployment lifecycle. SUPA will be loosely bound to network
> > >>> service models. In particular, SUPA will also allow operators to
> > >>> express policies that are not bound to specific network service
> instances.
> > >>
> > >> The above paragraph was largely unchanged with the exception of the
> removal of “In particular” at the start of the last sentence. It seemed
> unnecessary.
> > >
> > > OK
> > >
> > >>> expressing policy at different levels of abstraction.
> > >>> Specifically, three information model fragments are envisioned:
> > >>> (i) a generic information model that defines concepts needed by
> > >>> policy management independent of the form and content of the
> > >>> policy, (ii) a more specific information model that refines the
> > >>> generic information model to specify how to build policy rules of
> > >>> the event-condition-action paradigm, and (iii) a more specific
> > >>> information model that refines the generic information model to
> > >>> specify how to build policy rules that declaratively specify what
> > >>> goals to achieve (but not how to achieve those goals); this is
> > >>> often called "intent-based" policy. The SUPA working group will
> > >>> translate the generic policy information model into concrete YANG
> > >>> data models that define how to manage and communicate policies
> between systems.
> > >>>
> > >> The detail about information model abstraction (the three levels) is
> probably quite correct, but seemed a bit more than needed in the charter
> statement which is why it was not included in the proposal.
> > >
> > > level of detail. And it is a major scope clarification, namely
> > > whether SUPA is limite to ECA policies or also inclues declarative policies.
> > >
> > >>> List of work items:
> > >>>
> > >> In order to foster better interoperability, SDOs beyond the IETF are
> relevant.  That is why the above was modified as:
> > >>
> > > Again, it is feasible to do this for the IETF, it is harder to do
> > > this for an open ended set of SDOs. How does the WG determine that
> > > they are done with the framework?
> > >
> > >> No changes other than this was mis-numbered in my previous note.  It
> should be #5 given the addition (4) suggested above.
> > >
> > >>> The working group will decide how the work items are best mapped
> > >>> into deliverables.
> > >>>
> > >>> The working group will communicate with the L3SM working group
> > >>> working on layer 3 VPN service models and the I2RS working group
> > >>> working on generic network topology models in the context of the use
> cases.
> > >>>
> > >>> The working group will communicate with other SDOs (MEF, TMF,
> > >>> ETSI) that are working on related issues.
> > >>>
> > >>> Milestones:
> > >>>
> > >>> TBD
> > >>
> > >> No changes.
> > >>
> > >>> On Jul 20, 2015, at 12:03 PM, Juergen Schoenwaelder
> <[email-masked]> wrote:
> > >>>
> > >>> Jon, I like to understand exactly what was changed and why and
> > >>> this explanation is I think too broad. There has been lots of back
> > >>> and forth on the charter text and it just does not work to say
> > >>> "hey here is I think a better charter".
> > >>>
> > >>> /js
> > >>>
> > >>>> Juergen, I made the suggestions based on the posting John made to
> this list on material to be presented at the BOF. The suggestions below are
> also consistent with material andy is also presenting. The old charter did not
> have a clear statement of the problem to be solved.
> > >>>> /jon
> > >>>>> On Jul 20, 2015, at 11:34 AM, Juergen Schoenwaelder
> <[email-masked]> wrote:
> > >>>>>
> > >>>>> Jon,
> > >>>>>
> > >>>>> I have been holding the pen on the charter in the past and I
> > >>>>> would appreciate if people suggesting changes send the specific
> > >>>>> change requests together with a reasoning for the change. Just
> > >>>>> throwing out new text is not that helpful. After all, there
> > >>>>> needs to be some sort of consensus between the contributors and
> > >>>>> for that it is useful to know what is proposed to be changed and
> why.
> > >>>>>
> > >>>>> /js
> > >>>>>
> > >>>>>> In talking about the effort with people over the past couple of
> weeks, it seems like the charter could be updated a bit based on some of the
> presentation material for the meeting.
> > >>>>>>
> > >>>>>> The manual way configuration changes are made to individual
> > >>>>>> network and other service delivery elements is central to this
> > >>>>>> problem. These errors tend not to be basic syntax errors but
> > >>>>>> errors of logic in provisioning the elements to cooperatively
> > >>>>>> deliver a desired service throughout the service delivery
> > >>>>>> environment. This is especially important as services become
> > >>>>>> more complex, existing in both physical and virtual
> > >>>>>> environments across multiple vendors, technologies and
> > >>>>>> configuration paradigms. A unified approach to the specification of
> policy that can accommodate these differences is critical to the
> interoperation of these environments.
> > >>>>>>
> > >>>>>> The SUPA (Simplified Use of Policy Abstractions) WG is
> > >>>>>> chartered to define an architecture for the specification of high-
> level policy such as:
> > >>>>>> only allow traffic from subnets "A" and "B" over ports "D" and
> > >>>>>> "E" to be expressed across multiple physical and virtual
> > >>>>>> systems or, all sales group systems must us VPN XXX, and use YYY
> code server.
> > >>>>>>
> > >>>>>> components and defined interfaces to them to foster greater
> > >>>>>> management interoperation.
> > >>>>>>
> > >>>>>> The working group will define the language/methods to represent
> > >>>>>> the information and generic data models. The YANG-specific
> > >>>>>> examples show how the environment integrates with the
> NETCONF/RESTCONF environment.
> > >>>>>> The additional data models, in the form/language that is native
> > >>>>>> to them will show how other technologies can be brought under
> > >>>>>> the SUPA environment fostering wider interoperability.
> > >>>>>>
> > >>>>>> In particular, the creation of a network service instance
> > >>>>>> should be able to trigger the execution of SUPA policies, and
> > >>>>>> the same is true for the deletion of network service instances,
> > >>>>>> or any other major state changes, during the network service
> > >>>>>> development and deployment lifecycle. SUPA will be loosely
> bound to network service models.
> > >>>>>> SUPA will also allow operators to express policies that are not
> > >>>>>> bound to specific network service instances.
> > >>>>>>
> > >>>>>> List of work items:
> > >>>>>>
> > >>>>>> 1) A framework document that explains the scope of the
> > >>>>>> policy-based management framework and how it relates to
> > >>>>>> existing work of the IETF and other SDOs.
> > >>>>>>
> > >>>>>> 2) A generic policy information model consisting of a base
> > >>>>>> policy information model for representing policy management
> > >>>>>> concepts independent of the type or structure of a policy, an
> > >>>>>> extension of the base policy information model for defining
> > >>>>>> policy rules according to the event-condition-action paradigm,
> > >>>>>> and an extension of the base policy information model for
> > >>>>>> defining policy rules according to a declarative, or intent-based,
> paradigm.
> > >>>>>>
> > >>>>>> 3) A set of YANG data models that express the concepts defined
> > >>>>>> in the generic policy information model in concrete data
> > >>>>>> models. These models will be designed to be generic and
> extensible.
> > >>>>>>
> > >>>>>> 4) A set of data models appropriate to the expression of
> > >>>>>> concepts in the generic policy information model in concrete
> > >>>>>> data models appropriate to one or more technologies/models such
> as SDN.
> > >>>>>>
> > >>>>>> 4) An applicability document providing a number of examples
> > >>>>>> that demonstrate how the generic policy models can be used to
> > >>>>>> express policies that are relevant for operators. The examples
> > >>>>>> may tie into 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 the L3SM working group
> > >>>>>> working on layer 3 VPN service models and the I2RS working
> > >>>>>> group working on generic network topology models in the context
> of the use cases.
> > >>>>>>
> > >>>>>> The working group will communicate with other SDOs (MEF, TMF,
> > >>>>>> ETSI) that are working on related issues.
> > >>>>>>
> > >>>>>> Milestones:
> > >>>>>>
> > >>>>>> TBD
> > >>>>>>
> > >>>>>> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.o
> > >>>>>>
> rg_mailman_listinfo_supa&d=AwIGaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4
> > >>>>>>
> dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=EO0aw5JtQmEUoZqKCb
> w
> > >>>>>>
> rELIIRW7XsXlMFMppTlNvC1E&s=QMfHvDnlBcEXkPjMuABOTqmfOEmYHYhjlj
> qB
> > >>>>>> EwMCMXI&e=
> > >>>>>
> > >>>>> --
> > >>>>> Fax:   +49 421 200 3103
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.jacobs-
> 2Duniversity.de_&d=AwIGaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31
> OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=EO0aw5JtQmEUoZqKCbwrELIIR
> W7XsXlMFMppTlNvC1E&s=HuSH7p4-
> 3Wlc1CCjIAYi1tXTiiYCd5pUW9F0pG6A8Rg&e= >
> > >>>>>
> > >>>>
> > >>>> Thanks
> > >>>> /jon
> > >>> Fax:   +49 421 200 3103
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.jacobs-
> 2Duniversity.de_-20-3Chttp-3A__www.jacobs-
> 2Duniversity.de_&d=AwIGaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31
> OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=EO0aw5JtQmEUoZqKCbwrELIIR
> W7XsXlMFMppTlNvC1E&s=x03NPw7M81RNjPNhAOQYxdErN95LCzAh-
> MkX3ngBdxU&e= >>
> > >>
> > >> Thanks
> > >> /jon
> > > Fax:   +49 421 200 3103
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.jacobs-
> 2Duniversity.de_&d=AwIGaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31
> OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=EO0aw5JtQmEUoZqKCbwrELIIR
> W7XsXlMFMppTlNvC1E&s=HuSH7p4-
> 3Wlc1CCjIAYi1tXTiiYCd5pUW9F0pG6A8Rg&e= >
> > >
> > > https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_ma
> > >
> ilman_listinfo_supa&d=AwIGaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR3
> 1OcN
> > >
> XCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=EO0aw5JtQmEUoZqKCbwrELIIRW7Xs
> XlMFM
> > >
> ppTlNvC1E&s=QMfHvDnlBcEXkPjMuABOTqmfOEmYHYhjljqBEwMCMXI&e=
> > >
> >
> > Thanks
> > /jon
> Fax:   +49 421 200 3103
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.jacobs-
> 2Duniversity.de_&d=AwIGaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31
> OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=EO0aw5JtQmEUoZqKCbwrELIIR
> W7XsXlMFMppTlNvC1E&s=HuSH7p4-
> 3Wlc1CCjIAYi1tXTiiYCd5pUW9F0pG6A8Rg&e= >
> 
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_supa&d=AwIGaQ&c=BFpWQw8bsuKpl
> 1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=EO0aw
> 5JtQmEUoZqKCbwrELIIRW7XsXlMFMppTlNvC1E&s=QMfHvDnlBcEXkPjMuAB
> OTqmfOEmYHYhjljqBEwMCMXI&e=

---

From: Jon Saperia <[email-masked]>
Date: Tue, 21 Jul 2015 11:15:47 -0400

Great Dan,

I have put forward my reservations and proposal.  I will not be at the BOF.  I am sure there will be a good discussion at the BOF that can then be input to either confirm or change the charter.

/jon
> On Jul 21, 2015, at 10:51 AM, Romascanu, Dan (Dan) <[email-masked]> wrote:
> 
>> From: Supa [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Juergen
>> Schoenwaelder
>> Cc: [email-masked] <mailto:[email-masked]>
>>>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__cnds.eecs.jacob <https://urldefense.proofpoint.com/v2/url?u=http-3A__cnds.eecs.jacob>
>>>>> s-2Duniversity.de <http://s-2duniversity.de/>_users_schoenw_supa_supa-2Dcharter-2D2015-2D06-
>> 2D1
>>>>> 
>>>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__cnds.eecs.jaco <https://urldefense.proofpoint.com/v2/url?u=http-3A__cnds.eecs.jaco>
>>>>> bs-2Duniversity.de <http://bs-2duniversity.de/>_users_schoenw_supa_supa-2Dcharter-2D2015-
>> 2D06-2D
>>>>> 
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>>>>> 
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>>>>>>> 
>>>>>>>> Jon,
>>>>>>>> 
>>>>>>>>> [email-masked] <mailto:[email-masked]>
>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=https- <https://urldefense.proofpoint.com/v2/url?u=https->
>> 3A__www.ietf.o
>>>>>>>>> 
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.jacobs- <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.jacobs->
>> 2Duniversity.de <http://2duniversity.de/>_&d=AwIGaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31
>>>>>>> [email-masked] <mailto:[email-masked]>
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> --
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.jacobs- <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.jacobs->
>> 2Duniversity.de <http://2duniversity.de/>_-20-3Chttp-3A__www.jacobs-
>> 2Duniversity.de <http://2duniversity.de/>_&d=AwIGaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31
>>>>> [email-masked] <mailto:[email-masked]>
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> --
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.jacobs- <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.jacobs->
>> 2Duniversity.de <http://2duniversity.de/>_&d=AwIGaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31
>>>> [email-masked] <mailto:[email-masked]>
>>>> https://urldefense.proofpoint.com/v2/url?u=https- <https://urldefense.proofpoint.com/v2/url?u=https->
>> 3A__www.ietf.org_ma
>>>> 
>>> [email-masked] <mailto:[email-masked]>
>>> 
>>> 
>>> 
>>> 
>> 
>> --
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.jacobs- <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.jacobs->
>> 2Duniversity.de <http://2duniversity.de/>_&d=AwIGaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31
>> [email-masked] <mailto:[email-masked]>
>> https://urldefense.proofpoint.com/v2/url?u=https- <https://urldefense.proofpoint.com/v2/url?u=https->
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/supa <https://www.ietf.org/mailman/listinfo/supa>
Thanks
/jon