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

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Tue, 02 Jun 2015 12:57:57 +0200

Juergen wrote:

    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.

Maybe my misunderstanding. But I think you want to say that the policies control how some
of the things get configure on network elements, no? Or is the intend that these policies
control all of the configuration?

I do see there is a newer version SUPA CHARTER PROPOSAL (2015-06-01) of the  proposed
charter from yesterday. The only questions in my mind to that latest proposed charter are:

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

Does the list of work items not already specify the deliverables? Or at least the titles
for the documents? DO we have no idea as to when we want to deliver these
(i.e. a set of milestones)? I can understand and can accept if we say that such would be
decided in/during a WG-chartering/formation BOF

The other question I have is: are the work items listed in sequence of delivery?
I would think that one would do some use cases first before one starts mapping into YANG, no?

Bert

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 2 Jun 2015 13:21:12 +0200

> control all of the configuration?

Policies certainly won't control everything. How can the charter text be
improved to avoid this confusion? The above was just an email explanation
and hence it is not that important.
 
> Does the list of work items not already specify the deliverables? Or at 
> least the titles for the documents?

There was a discussion whether the information model will be one
document or perhaps be split into multiple documents. Dan suggested
that it is OK for the WG to decide how to best split things into
documents.

> DO we have no idea as to when we want to deliver these (i.e. a set
> of milestones)? I can understand and can accept if we say that such
> would be decided in/during a WG-chartering/formation BOF

Yes, this was the idea. Milestones are usually easy to settle once
there is a sign of green light on the horizon.

> I would think that one would do some use cases first before one starts 

I guess the framework indeed goes first. In some other WG, we did an
information model and afterwards a data model but it was decided to
not submit the information model until the data model is reasonably
complete. The reason is that changes you discover while writing the
data model may be carried back to the information model. Use cases may
go earlier but then it might also be good to keep the document alive
in the WG until we are pretty sure the other deliverables are
consistent wrt the use cases. But perhaps it makes sense to move 4) to
position 2).

I have started charter version 2015-06-02.

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

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 2 Jun 2015 11:27:22 +0000

Hi Bert,

See in-line a couple of answers to your concerns.

Regards,

Dan

> -----Original Message-----
> From: Supa [mailto:[email-masked]] On Behalf Of Bert Wijnen (IETF)

...
> 
> I do see there is a newer version SUPA CHARTER PROPOSAL (2015-06-01) of
> the  proposed charter from yesterday. The only questions in my mind to that
> latest proposed charter are:
> 
> Does the list of work items not already specify the deliverables? Or at least
> the titles for the documents? DO we have no idea as to when we want to
> deliver these (i.e. a set of milestones)? I can understand and can accept if we
> say that such would be decided in/during a WG-chartering/formation BOF
> 

Milestones need to be discussed and a set of initial milestones approved when SUPA charter will go through internal and external reviews. I believe that this sentence tends to indicate a level of flexibility the WG would like to keep (as other do nowadays) in what concerns the final documents structure e.g. one or more documents for the IM? Does the UC document need to become an (Informational) RFC at all?

> I would think that one would do some use cases first before one starts

Maybe, but this is also reflecting that this document is also somehow more than an usual use case document. It also provides an example (proof of concept) of how generic policies apply to specific use cases. And, again, some WGs nowadays use these documents as a reference and update them during the WG life time, but may decide that they do not become RFCs.

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Tue, 02 Jun 2015 13:32:30 +0200

Thanks Dan,

your anwers make me feel more comfortable with the proposed text
that is already in the charter proposal.

Bert

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Tue, 02 Jun 2015 13:36:29 +0200

inline

> and hence it is not that important.

OK, as long as it is an email explanation and doesn't go into the charter text this way,
\then I am fine with it.

> that it is OK for the WG to decide how to best split things into

Ah... I agree that the/a WG should get the freedom to merge/split documents
as it feels/wants. But at least some major milestones (wether it is one or
multiple documents per milestone) makes sense at the WG-formation BOF, or so
I think. I would think that would also make it easier to defend/justify it to IESG.

> there is a sign of green light on the horizon.
OK, fine if we do that in/during the BOF

> data model may be carried back to the information model.

That makes a lot of sense yes.

> Use cases may
OK

Bert

---

From: Andy Bierman <[email-masked]>
Date: Tue, 2 Jun 2015 12:10:11 -0700

> and hence it is not that important.

Let's say I had a simple policy for configuration.
Perhaps I want to the user to choose between speed
and robustness, i.e., edits are done as fast as possible
vs. edits done as robustly as possible.

Is this a valid intent-based policy?  I know how to
change the NETCONF parameters to implement either
for speed or for robustness.  I don't understand how
high-level policy gets translated into a low-level implementation
of the policy in an automated fashion.

I am hoping SUPA can support this sort of usage instead of
just the narrow scope of the hard-wired items.  I should be able
to write a structured document (policy mapping?) that tells a SUPA
system how to glue the policy to the implementation.

Andy

> _______________________________________________
> Supa mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/supa

---

From: Tina TSOU <[email-masked]>
Date: Tue, 2 Jun 2015 23:26:21 +0000

Dear Andy,

Awesome!

Would you like to be the editor of document #3 at http://trac.tools.ietf.org/bof/trac/ ?

  *   #3<http://trac.tools.ietf.org/bof/trac/ticket/3> one I-D translate information model to generic YANG, 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.
     *   Converged from
     *   ​http://datatracker.ietf.org/doc/draft-wang-netmod-yang-policy-dm/<http://datatracker.ietf.org/doc/draft-wang-netmod-yang-policy-dm/>

Thank you,
Tina

On Jun 3, 2015, at 3:10 AM, Andy Bierman <[email-masked]<mailto:[email-masked]>> wrote:

On Tue, Jun 2, 2015 at 4:21 AM, Juergen Schoenwaelder
<[email-masked]<mailto:[email-masked]>> wrote:
On Tue, Jun 02, 2015 at 12:57:57PM +0200, Bert Wijnen (IETF) wrote:
Juergen wrote:

Maybe my misunderstanding. But I think you want to say that the policies
control how some
of the things get configure on network elements, no? Or is the intend that
these policies
control all of the configuration?

Andy

I do see there is a newer version SUPA CHARTER PROPOSAL (2015-06-01) of the
proposed
charter from yesterday. The only questions in my mind to that latest
proposed charter are:

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

The other question I have is: are the work items listed in sequence of
delivery?
I would think that one would do some use cases first before one starts
mapping into YANG, no?

/js

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

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

---

From: Andy Bierman <[email-masked]>
Date: Tue, 2 Jun 2015 17:48:47 -0700

> http://trac.tools.ietf.org/bof/trac/ ?

I can probably help with that.

Andy

> #3 one I-D translate information model to generic YANG, 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.
>
> Converged from
> http://datatracker.ietf.org/doc/draft-wang-netmod-yang-policy-dm/
>
>
> Thank you,
> Tina
>
> On Jun 3, 2015, at 3:10 AM, Andy Bierman <[email-masked]> wrote:
>

---

From: Tina TSOU <[email-masked]>
Date: Wed, 3 Jun 2015 01:14:27 +0000

Dear Andy,

Great!

Would you propose the name, scope and ToC of document #3?

Thank you,
Tina

> On Jun 3, 2015, at 8:48 AM, Andy Bierman <[email-masked]> wrote:
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 3 Jun 2015 07:57:08 +0200

> vs. edits done as robustly as possible.

I can't tell whether this would be expressable. This policy does not
concern how network elements behave at the end but how a network
management application or controller talks to a network element.

> of the policy in an automated fashion.

I am not sure what you mean with NETCONF parameters. My understanding
is that you have to change how the NETCONF client uses NETCONF. Or do
you mean some implementation specific server parameters that an
implementation might expose through a proprietary NETCONF
configuration data model?

> system how to glue the policy to the implementation.

Not sure where you got "narrow scope of the hard-wired items" from and
how you define that.  My think the goal is that SUPA policies can
control anything that is configurable via YANG data models.

/js

---

From: Andy Bierman <[email-masked]>
Date: Wed, 3 Jun 2015 04:23:57 -0700

> management application or controller talks to a network element.

So SUPA only applies to YANG models implemented on network elements?

> configuration data model?

fast-policy:
   send edit-config w/ test-option=set

robust-policy:
   lock all datastores
   send edit-config with test-option=test-then-set
   unlock all datastores

If I can't use policy to drive a trivial binary decision, then what good is it?
Or worse, if it takes 2 days to figure out how to do this with policy.

> control anything that is configurable via YANG data models.

YANG can be used for a lot more than implementing config on network
elements.  You should refine the scope further so people don't
assume SUPA can be used for other purposes than a handful
of data models that are picked by the WG in advance.

Andy

---

From: alagalah <[email-masked]>
Date: Wed, 03 Jun 2015 06:48:12 -0700

>system how to glue the policy to the implementation.

I think this is a great call out. There needs to be an acknowledgement of
the different consumers of an Intent System. For instance, if we take a
DevOps viewpoint, what a Developer wants to express in Intent, and what an
Operator needs to express/modulate in Intent needs to accommodated
differently. In OpenDaylight GroupBasedPolicy, we look at this as
Expressed Intent, and Operational Constraints.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 3 Jun 2015 16:36:01 +0200

> Or worse, if it takes 2 days to figure out how to do this with policy.

I thought I explained it. I won't repeat myself. Write a YANG data
model for your policy engine and there we go.
 
> of data models that are picked by the WG in advance.

The 'picked by the WG in advanced' is your idea, not mine. Can you
point to the text in the charter that made you think policy can only
be applied to a 'handful of data models that are picked by the WG in
advance'?

/js

---

From: Andy Bierman <[email-masked]>
Date: Wed, 3 Jun 2015 08:48:25 -0700

> model for your policy engine and there we go.

I guess I need to read more about SUPA.
It seems I have to implement NETCONF between 2 software components,
just to implement a trivial boolean policy.

> be applied to a 'handful of data models that are picked by the WG in

I need to read more to determine if this is something
real or not. Charter text is written for the IESG, not developers,
so I tend to ignore it.

Andy