Subject: Re: [Supa] supa charter 2015-05-29

From: Benoit Claise <[email-masked]>
Date: Mon, 01 Jun 2015 07:06:29 -0700

Thanks Jürgen for your efforts.
A few points below.

1.
Question to the group:

    Policies embedded in the configuration of network elements are not the
    scope of SUPA. Below are some examples of embedded policies that are
    not in the scope of SUPA:

       - packet filtering policies
       - packet marking and scheduling policies
       - route imported and export policies
       - authorization policies (configured on network elements)

Maybe I misunderstood, but I thought I understood that the principles 
(and models) behind ECA could be reused in the future "Policies embedded 
in the configuration of network elements"?

2.

    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.

I don't understand that. The creation of a network service: this is just 
another resource to look at for a policy, right?

3.
This item below is on the boundary between use cases and applicability

    4) A use cases document providing a number of 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 network service models developed by other working groups.

4.
"The working group will coordinate with the L3SM working group working
on layer 3 VPN service models"
     what for? For which goal?

" and the I2RS working group working on generic network topology models."
     What's the connection with the topology model here?

Regards, Benoit
> Hi,
>
> I got ask to revise the charter text. I received quite some input from
> various sources but unfortunately the input often was not consistent.
> One of the bigger obstacles that I felt is the apparent confusion
> around the term 'policy'. So I did sit down in an attempt to rewrite
> the charter text to make a clearer distinction between 'generic
> policy' and 'embedded policy'. (Perhaps not great terms but hopefully
> better than having no distinction at all.) I also tried to make the
> charter text not longer, I actually made John's latest version a bit
> shorter again. I added a framework document to the set of work items
> since given the discussions we had, it seems this is needed.
>
> I am sure I have not addressed all suggestions and I am also sure that
> there is still text that can be unclear or mis-understood. I do very
> much appreciate actionable comments. I am also fine with 'I liked
> charter version XYZ way better than this one'.
>
> /js
>
> PS: I have uploaded all the charter text revisions to a web page in
>      case someone is interested in the evolution of the text.
>
>      http://cnds.eecs.jacobs-university.de/users/schoenw/supa/
>
>
>
> _______________________________________________
> Supa mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/supa

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 1 Jun 2015 16:47:26 +0200

> in the configuration of network elements"?

I am sometimes getting lost at these questions. What the charter tries
to say (and I apologize if this is still not clear enough) is that
SUPA intends to work on policies that control how things get configured
on network elements, it is not aiming to replace or reformulate how
packet filters work etc.
 
> another resource to look at for a policy, right?

If you want to see it that way. Or I may simply not understand the
comment/question. An example: If I instantiate a new virtual machine
for a student project, than this triggers the execution of policies
that I apply to all VMs for student projects. This is what I was
trying to capture.

>        tie into network service models developed by other working groups.

And that means what?
 
>     What's the connection with the topology model here?

One of the use cases that has been around for quite some time has been
distributed data centers and this is where this is coming from. Shall
we take it out or shall we make it clearer that we plan to look a
certain specific use cases?

/js

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