Subject: [Supa] draft-klyus-supa-proposition-00 review

From: Benoit Claise <[email-masked]>
Date: Mon, 08 Jun 2015 23:42:13 +0200

You asked me to read this draft tonight, and here is my feedback.

- Let me be very candid. I believe that SUPA has been suffering from a 
specific syndrome for some time: not being to explain in a 2 min 
elevator pitch what SUPA is about.
The goal of the WIKI, https://github.com/IETF-SUPA/SUPA/wiki/Q-&-A was 
to help with that point: to have a quick view on the SUPA 
goals/non-goals/scope/etc.
Instead, this is yet another document, 27 pages. I'm thinking that this 
draft missed its goal. It's a mix of complete terminology, framework, 
and design spec (Section 3.2.2: Why is this important to show a NM/NC 
Functional Blocks for a SUPA value proposition draft? You want to 
specify the interface between a SDN app and a controller anyway, and not 
a NM/CM). The examples and the related work is helpful.
Reading the draft took almost 2 hours. Not sure if everybody (IESG/IAB) 
will have 2 hours to spend on preparing SUPA... We'll see. Anyway, I 
repeated my point a few times (actually the point I received from 
multiple people).
Along the same lines, this draft has got some redundancies. Example: 
section 1.2 with the last paragraphs of section 1.1

- From the questions at https://github.com/IETF-SUPA/SUPA/wiki/Q-&-A, I 
don't find back essential points:
What does the IETF gain by chartering a SUPA WG?
What will be lost by not chartering it?
Why does SUPA want to work on an information model at the time the IETF 
moves away from information models to focus on data models?
What is the difference between SUPA and previous RFCs (e.g., 3060, 3460)?
etc...
So I conclude that the IESG/IAB read both this draft and the WIKI. 
Please update the WIKI.

Some more specific points:

- I don't understand the last sentence in the abstract.

- Coming back to a point I made during the meeting.
The draft focuses a lot on the north bound interface of a controller. Be 
consistent between the charter and this document

  o) Specify how to map the above mentioned information models
       into corresponding YANG standardized data models to define
       interoperable implementations that can exchange and modify
       generic policies using protocols such as NETCONF/RESTCONF on
       the interface north of the controller (or other similar
       management entity) and south of the service manager.

We don't want to specify a UML to YANG mapping. There is a mapping: no 
need to specify the "how"

-

    Information Model: a representation of managed objects and
    their relationships that is independent of data repository,
    language, and protocol.

    Data Model: a representation of managed objects and their
    relationships that is dependent on data repository, language,
    and/or protocol (typically all three).

Refer to RFC 3444

-
    Model Mapping: a translation from one type of model to another
    type of model. Model mapping changes the representation and/or
    level of abstraction used to another representation and/or
    level of abstraction. The most common form of model mapping is
    from an information model to a data model; another important
    form is from a vendor-neutral data model to a vendor-specific
    data model.

Why is the last sentence important to SUPA?

-
    The policy information model defines event-condition-action
    (ECA), declarative (intent-based), utility function, and
    promise policies. The work indraft-strassner-supa-generic-  <https://tools.ietf.org/html/draft-strassner-supa-generic-policy-info-model-01>
    policy-info-model-01  <https://tools.ietf.org/html/draft-strassner-supa-generic-policy-info-model-01>  is based on this work. It currently
    extends the ECA model and provides additional detail not
    currently present in ZOOM; the next version of this draft will
    do the same for declarative policies.

The "policy information model" in the first sentence refers to the TMF/ZOOM policy IM?

- section 5.2.5.1. Group-Based Policies

    This type of
    approach is more relational than declarative

What does it mean?

- There are some of the 5.2.x technologies for which I'm not sure about the pros/cons versus what SUPA:
  Group-based policies, ONOS (It supports abstraction for both southbound and northbound interfaces)

Regards, Benoit

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 9 Jun 2015 00:16:05 +0200

> elevator pitch what SUPA is about.

How about this:

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

If I read this very slowly, I might fill 2 min or I leave the elevator
early. ;-)

> What is the difference between SUPA and previous RFCs (e.g., 3060, 3460)?

The technical differences are discussed in the information model
document but likely too boring or too long for decision makers. What
really matters, I think, are not the technical difference to RFC 3060
and RFC 3460 but the fact that today we do have configuration data
models we can hook on while back at the end of last century we only
had disagreement about technologies and proprietary CLIs.

I think Bob Natale stated this very well in one of his emails.

/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, 9 Jun 2015 09:29:14 +0000

I suggest  that this nice sentence written by Juergen be inserted om the Abstract in the revised I-D, and show up also in the Charter and wiki. 

>   creates element configurations snippets as output.

Regards,

Dan

> -----Original Message-----
> From: Supa [mailto:[email-masked]] On Behalf Of Juergen
> Schoenwaelder
> Sent: Tuesday, June 09, 2015 1:16 AM
> To: Benoit Claise
> Cc: [email-masked]
> Subject: Re: [Supa] draft-klyus-supa-proposition-00 review
> 
> If I read this very slowly, I might fill 2 min or I leave the elevator early. ;-)
> 
> The technical differences are discussed in the information model document
> but likely too boring or too long for decision makers. What really matters, I
> think, are not the technical difference to RFC 3060 and RFC 3460 but the fact
> that today we do have configuration data models we can hook on while back
> at the end of last century we only had disagreement about technologies and
> proprietary CLIs.
> 
> Fax:   +49 421 200 3103
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.jacobs-
> 2Duniversity.de_&d=AwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31O
> cNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=QE9fmluvJcjUHl7wCcugUhNQJzY5
> OHjRHvQtCEdBvzE&s=tVljz2clLoFi31kwqNklHPQL64wUKDg9bCOfRAsbTxg&e
> = >
> 
> _______________________________________________
> Supa mailing list
> [email-masked]
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_supa&d=AwICAg&c=BFpWQw8bsuKpl1
> SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=QE9fmlu
> vJcjUHl7wCcugUhNQJzY5OHjRHvQtCEdBvzE&s=_bxlHuiWhc1Ht1DYwzSg-
> rI8aUaKuULpW2lETqS6YbY&e=

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 9 Jun 2015 12:16:39 +0200

Dan and all,

what about replacing the entire first paragraph of the charter with
this one sentence? I mean, do we really need to state in the charter
that network operations and management is getting more difficult?  My
preference would be to keep the charter concise focused on what the WG
will do.

/js

On Tue, Jun 09, 2015 at 09:29:14AM +0000, Romascanu, Dan (Dan) wrote:
> https://www.ietf.org/mailman/listinfo/supa

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 9 Jun 2015 10:17:22 +0000

Yes!

> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-
> university.de]
> Sent: Tuesday, June 09, 2015 1:17 PM
> To: Romascanu, Dan (Dan)
> Cc: [email-masked]
> what about replacing the entire first paragraph of the charter with this one
> sentence? I mean, do we really need to state in the charter that network
> operations and management is getting more difficult?  My preference would
> be to keep the charter concise focused on what the WG will do.
> 
> /js
> 
> > I suggest  that this nice sentence written by Juergen be inserted om the
> Abstract in the revised I-D, and show up also in the Charter and wiki.
> >
> > > > - Let me be very candid. I believe that SUPA has been suffering
> > > > from a specific syndrome for some time: not being to explain in a
> > > > 2 min elevator pitch what SUPA is about.
> > >
> > > How about this:
> > >
> > > really matters, I think, are not the technical difference to RFC
> > > 3060 and RFC 3460 but the fact that today we do have configuration
> > > data models we can hook on while back at the end of last century we
> > > only had disagreement about technologies and proprietary CLIs.
> > >
> 3A__www.ietf.org_mail
> man_listinfo_supa&d=AwIBAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31
> OcNXCJf
> >
> QzvlsiLQfucBXRucPvdrphpBsFA&m=fI6xg6EBwf5sSi2Avc5CafJTkpD1yllDwnZ
> MeouQ
> > 7Tw&s=oXK9N-OYPSskjfCLdhHZGILjQ8WdZnjlVjSn5scjR4I&e=
> 
> --
> 2Duniversity.de_&d=AwIBAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31O
> cNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=fI6xg6EBwf5sSi2Avc5CafJTkpD1yll
> DwnZMeouQ7Tw&s=T5S9ab0gnrsS4kuCxK1xiMAyjCKd6l4KliLQtMRl36M&e=
> >

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 9 Jun 2015 12:31:44 +0200

So here we go:

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

/js

---

From: Tina TSOU <[email-masked]>
Date: Tue, 9 Jun 2015 13:06:23 +0000

Dear all,

Should this nice sentence be used to replace the BoF description at the BoF wiki?

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

Thank you,
Tina

On Jun 9, 2015, at 6:33 PM, Juergen Schoenwaelder <[email-masked]<mailto:[email-masked]>> wrote:

So here we go:

/js

-----Original Message-----
From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-
university.de<http://university.de>]
Sent: Tuesday, June 09, 2015 1:17 PM
To: Romascanu, Dan (Dan)
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Supa] draft-klyus-supa-proposition-00 review

Dan and all,

/js

Regards,

Dan

-----Original Message-----
From: Supa [mailto:[email-masked]] On Behalf Of Juergen
Schoenwaelder
Sent: Tuesday, June 09, 2015 1:16 AM
To: Benoit Claise
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Supa] draft-klyus-supa-proposition-00 review

How about this:

If I read this very slowly, I might fill 2 min or I leave the
elevator early. ;-)

What is the difference between SUPA and previous RFCs (e.g., 3060,
3460)?
etc...

/js

2Duniversity.de<http://2Duniversity.de>_&d=AwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31O

_______________________________________________
Supa mailing list
[email-masked]<mailto:[email-masked]>
https://urldefense.proofpoint.com/v2/url?u=https-

_______________________________________________
Supa mailing list
[email-masked]<mailto:[email-masked]>
https://urldefense.proofpoint.com/v2/url?u=https-
3A__www.ietf.org_mail

2Duniversity.de<http://2Duniversity.de>_&d=AwIBAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31O

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

---

From: John Strassner <[email-masked]>
Date: Tue, 9 Jun 2015 10:33:23 -0700

+1

regards,
John

On Tue, Jun 9, 2015 at 3:16 AM, Juergen Schoenwaelder <
[email-masked]> wrote:

> document

-- 
regards,
John

---

From: "Narasimha Rao Vadrevu" <[email-masked]>
Date: Tue, 9 Jun 2015 12:03:30 -0700

Agree that the statement below doesn’t specifically talk about North or Southbound and may be relevant to get the Charter through.

But IMHO the  real value add of SUPA is getting an end to end policy  which is complement to NETCONF/SETCONF.

Thanks,

Narasimha

From: Supa [mailto:[email-masked]] On Behalf Of John Strassner
Sent: Tuesday, June 09, 2015 10:33 AM
To: Juergen Schoenwaelder; Romascanu, Dan (Dan); [email-masked]
Subject: Re: [Supa] draft-klyus-supa-proposition-00 review

+1

regards,

John

On Tue, Jun 9, 2015 at 3:16 AM, Juergen Schoenwaelder <[email-masked] <mailto:[email-masked]> > wrote:

Dan and all,

/js

On Tue, Jun 09, 2015 at 09:29:14AM +0000, Romascanu, Dan (Dan) wrote:
> > From: Supa [mailto:[email-masked] <mailto:[email-masked]> ] On Behalf Of Juergen
> > Schoenwaelder
> > Cc: [email-masked] <mailto:[email-masked]> 
> > [email-masked] <mailto:[email-masked]> 
> [email-masked] <mailto:[email-masked]> 

--
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 <tel:%2B49%20421%20200%203587>          Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 <tel:%2B49%20421%20200%203103>          <http://www.jacobs-university.de/>

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

-- 

regards,

John

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 10 Jun 2015 09:01:31 +0200

> But IMHO the  real value add of SUPA is getting an end to end policy  which is complement to NETCONF/SETCONF.

I do not know what 'an end to end policy which is complement to
NETCONF/RESTCONF' is. You may need to explain this to me.

Note that YANG and NETCONF/RESTCONF are having quite some uptake in
the IETF and that we are talking about a proposal for a WG within the
IETF.

/js

---

From: Benoit Claise <[email-masked]>
Date: Wed, 10 Jun 2015 22:19:22 +0200

Jürgen,
>    creates element configurations snippets as output.
That's the best one summary sentence of the SUPA work I've seen so far.
Thanks for the new charter.

Regards, Benoit