Subject: [Supa] FW: supa - New Meeting Session Request for IETF 93

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 11 Jun 2015 18:29:58 +0000

It looks like the BOF was approved. 

A small but important step. 

Let us start working towards a successful BOF. I suggest to focus in the next Monday meeting on the status of the supa document and plan what needs to be updated between now and the cut-off date. 

Regards,

Dan

> -----Original Message-----
> From: "IETF Meeting Session Request Tool"
> [mailto:[email-masked]]
> Sent: Thursday, June 11, 2015 9:04 PM
> To: [email-masked]
> Cc: [email-masked]; Romascanu, Dan (Dan);
> [email-masked]; [email-masked]
> Subject: supa - New Meeting Session Request for IETF 93
> 
> 
> 
> A new meeting session request has just been submitted by Stephanie
> McCammon, on behalf of the supa working group.
> 
> 
> ---------------------------------------------------------
> Working Group Name: Simplified Use of Policy Abstractions Area Name:
> Operations and Management Area Session Requester: Stephanie
> McCammon
> 
> Number of Sessions: 1
> Length of Session(s):  2 Hours
> Number of Attendees: 150
> Conflicts to Avoid:
>  First Priority:  opsawg opsarea netconf netmod i2rs rtgarea alto bess idr l3sm
> nvo3 pce rtgwg teas lmap sacm xrblock i2nsf detnet
> 
> 
> 
> 
> Special Requests:
> 
> ---------------------------------------------------------

---

From: Tina TSOU <[email-masked]>
Date: Thu, 11 Jun 2015 22:27:08 +0000

Dear all,

Good job!

Draft agenda for next Monday call is below. Suggestions to update is very welcome.
----------
1. Note Well, logistics, agenda bashing (chairs, 0 min)
2. Status of the supa document and plan what needs to be updated between now and the cut-off date.
Value proposition (Max/John, 10 min)
 ​http://datatracker.ietf.org/doc/draft-klyus-supa-proposition<http://datatracker.ietf.org/doc/draft-klyus-supa-proposition>
Information model (John, 20 min)
 ​http://datatracker.ietf.org/doc/draft-strassner-supa-generic-policy-info-model/<http://datatracker.ietf.org/doc/draft-strassner-supa-generic-policy-info-model/>
Data model: TBD (Andy, 20 min)
Converged from ​http://datatracker.ietf.org/doc/draft-wang-netmod-yang-policy-dm/<http://datatracker.ietf.org/doc/draft-wang-netmod-yang-policy-dm/>
-----------

Questions to the group.
Should we work on exactly one to one mapping to the list of work items in the draft charter?
1. A framework document
2. A generic policy information model
3. A set of YANG data models
4. An applicability document
Though it says "The working group will decide how the work items are best mapped into deliverables".

Thank you,
Tina

On Jun 12, 2015, at 2:30 AM, Romascanu, Dan (Dan) <[email-masked]<mailto:[email-masked]>> wrote:

Regards,

Dan

-----Original Message-----
From: "IETF Meeting Session Request Tool"
[mailto:[email-masked]]
Sent: Thursday, June 11, 2015 9:04 PM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; Romascanu, Dan (Dan);
[email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: supa - New Meeting Session Request for IETF 93

Number of Sessions: 1

Special Requests:

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

---

From: John Strassner <[email-masked]>
Date: Fri, 12 Jun 2015 02:25:11 +0000

I have not yet updated the information model. I'm happy to discuss it, but I think it would be better served to first fill out what we said we would do in the BoF (http://trac.tools.ietf.org/bof/trac/). Since the value proposition and info model at least have entries, we should start thinking about the data model. We should also start thinking about the applicability document as mentioned in the charter.

regards,
John

From: Supa [mailto:[email-masked]] On Behalf Of Tina TSOU
Sent: Thursday, June 11, 2015 3:27 PM
To: Romascanu, Dan (Dan)
Cc: [email-masked]
Subject: Re: [Supa] FW: supa - New Meeting Session Request for IETF 93

Dear all,

Good job!

Questions to the group.

Thank you,
Tina

Regards,

Dan

-----Original Message-----

Number of Sessions: 1

Special Requests:

---

From: Tina TSOU <[email-masked]>
Date: Fri, 12 Jun 2015 02:39:43 +0000

Dear John, Dan et al,

How about this?

----------

2. What we would do in the BoF (all, 15 mins)
http://trac.tools.ietf.org/bof/trac/

3. Status of the supa document and plan what needs to be updated between now and the cut-off date.
Value proposition (Max/John, 10 min)
http://datatracker.ietf.org/doc/draft-klyus-supa-proposition

Information model (John, 10 min)
http://datatracker.ietf.org/doc/draft-strassner-supa-generic-policy-info-model/

Data model: TBD (Andy, 15 min)
Converged from http://datatracker.ietf.org/doc/draft-wang-netmod-yang-policy-dm/

Applicability: TBD (Volunteers, 10min)
-----------

Thank you,
Tina

From: John Strassner
Sent: Friday, June 12, 2015 10:25 AM
To: Tina TSOU; Romascanu, Dan (Dan)
Cc: [email-masked]
Subject: RE: [Supa] FW: supa - New Meeting Session Request for IETF 93

regards,
John

From: Supa [mailto:[email-masked]] On Behalf Of Tina TSOU
Sent: Thursday, June 11, 2015 3:27 PM
To: Romascanu, Dan (Dan)
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Supa] FW: supa - New Meeting Session Request for IETF 93

Dear all,

Good job!

Questions to the group.

Thank you,
Tina

Regards,

Dan

-----Original Message-----

Number of Sessions: 1

Special Requests:

---

From: John Strassner <[email-masked]>
Date: Fri, 12 Jun 2015 02:40:46 +0000

MUCH better :-)

regards,
John

From: Tina TSOU
Sent: Thursday, June 11, 2015 7:40 PM
To: John Strassner; Romascanu, Dan (Dan)
Cc: [email-masked]
Subject: RE: [Supa] FW: supa - New Meeting Session Request for IETF 93

Dear John, Dan et al,

How about this?

----------

Thank you,
Tina

From: John Strassner

regards,
John

Dear all,

Good job!

Questions to the group.

Thank you,
Tina

Regards,

Dan

-----Original Message-----

Number of Sessions: 1

Special Requests:

---

From: Andy Bierman <[email-masked]>
Date: Sun, 14 Jun 2015 12:56:32 -0700

Hi,

A am catching up on the SUPA reading material, especially
draft-strassner-supa-generic-policy-info-model-01.txt.

IMO the deconstruction of logic goes too far.
The level of abstraction is too high.
I prefer to be able to just write "if .. else ... end" in scripts
not model it in YANG or UML or anything else.

This snippet in 6.4 demonstrates what I have in mind:

    ON RECEIPT OF <policy-event-clause>
         IF <policy-condition-clause> EVALUATES TO TRUE
            THEN EXECUTE <policy-action-clause>
         END
    END

SUPA should pay attention to the Script MIB (RFC 3165)
and Policy MIB (RFC 4011) attempted to accomplish
and the approaches that were taken.

IMO:

  <policy-event-clause> can be supported with the
   pub/sub services proposed for I2RS. Even RFC 5277
   features could support this.

   <policy-condition-clause> is an XPath boolean expression
   Support for multiple contexts is needed:
       - Test contents in event notifications
       - Test contents of running config and operational state

   <policy-action-clause> is an actual scripting language.
   E.g. "if, else, elif, while, for , eval" statements, using XPath

IMO the work of implementing a system that allows a deconstructed info model
to be configured is just too much work and too complicated for users to ever
get started, let alone use for complex policy implementation.
Implementation of a scripting language is much easier and the result
is much more user-friendly.

The SUPA engine works with its own conceptual "policy datastore" and the
datastores on each target device.  Like Juergen said, anything that
can be in a YANG model can be manipulated by the policy engine.
But the formal coupling between YANG models seems like overkill.
The XPath expressions and the scripts themselves can express the
relationships informally.

Andy

On Thu, Jun 11, 2015 at 7:25 PM, John Strassner <
[email-masked]> wrote:

>  I have not yet updated the information model. I'm happy to discuss it,
> but I think it would be better served to first fill out what we said we
> would do in the BoF (http://trac.tools.ietf.org/bof/trac/). Since the
> value proposition and info model at least have entries, we should start
> thinking about the data model. We should also start thinking about the
> applicability document as mentioned in the charter.
>
>
>
> regards,
>
> John
>
>
>
> *From:* Supa [mailto:[email-masked]] *On Behalf Of *Tina TSOU
> *Sent:* Thursday, June 11, 2015 3:27 PM
> *To:* Romascanu, Dan (Dan)
> *Cc:* [email-masked]
> *Subject:* Re: [Supa] FW: supa - New Meeting Session Request for IETF 93
>
>
>
> Dear all,
>
>
>
> Good job!
>
>
>
>  ​http://datatracker.ietf.org/doc/draft-klyus-supa-proposition
>
>  ​
> Converged from ​
> http://datatracker.ietf.org/doc/draft-wang-netmod-yang-policy-dm/
>
> -----------
>
>
>
> Questions to the group.
>
> On Jun 12, 2015, at 2:30 AM, Romascanu, Dan (Dan) <[email-masked]>
> wrote:
>
> Let us start working towards a successful BOF. I suggest to focus in the
> next Monday meeting on the status of the supa document and plan what needs
> to be updated between now and the cut-off date.
>
> Regards,
>
> Dan
>
>
>
>  [mailto:[email-masked]
> <[email-masked]>]
>
> [email-masked]
> [email-masked]

---

From: John Strassner <[email-masked]>
Date: Sun, 14 Jun 2015 23:01:33 -0700

Hi Andy,

thank you for your thoughtful comments. I have a couple of responses.

> not model it in YANG or UML or anything else.

<jcs> The logic section (i.e., declarative, or intent-based) is
there based on people wanting it. OpenStack Congress uses
Datalog + extensions, which is similar to SUPA FOL. ODL NIC,
ONF NBI intent work, and others have all "threatened" to
define syntax, but haven't yet. These others all describe
intent in a way similar to SUPA describes declarative logic.

That being said, you can happily ignore SUPALogicStatement
and just use SUPAECAPolicyRule - nothing in the model is
adversely affected by doing that. </jcs>

> and the approaches that were taken.

<jcs> Agreed, I will think about how to work examples of using
those into the next version of my I-D, due at the end of this week.
</jcs>

>IMO:
> <policy-event-clause> can be supported with...
> <policy-condition-clause> is an XPath boolean expression...
> <policy-action-clause> is an actual scripting language....

<jcs> These are certainly good alternatives. The purpose of the
object model is to define the same data structures that you would
manipulate in the above clauses. </jcs>

> is much more user-friendly.

<jcs> I personally have used the info model to provide the objects used in
DSLs. They have to come from somewhere, right? Otherwise, there is no
reusability. Defining them in an info model makes their definition clear and
extensible, and it certainly doesn't prevent you from taking those objects
and formulating your clauses using them.

The key point is that without the model structure, how would you make your
approach interoperable? How could you standardize it?

There is a long history of using models in this way. I'm happy to work with
and support alternatives. That just shows the power of the model.
However, I would like to keep the original intent (pun intended) of the
work open and also be able to support using objects to build rules. </jcs>

> The SUPA engine works with its own conceptual "policy datastore" and
>  the datastores on each target device.  Like Juergen said, anything that

<jcs> I'm confused. Without formalisms there are no interoperable
standards. If anyone can substitute their favorite scripting language
for an action, then how do we interoperate? </jcs>

regards,
John

-- 
regards,
John

---

From: Benoit Claise <[email-masked]>
Date: Mon, 15 Jun 2015 14:59:05 +0200

Dear all,

Indeed the SUPA BoF was approved.

Between now and the BoF, I believe you should spend your time on making 
sure that the BoF is successful.
I advice you to read RFC 5434.

 From RFC 5434:

    The goal of the BOF is to demonstrate that the community has
    agreement that:
    - there is a problem that needs solving, and the IETF is the right
    group to attempt solving it.
    - there is a critical mass of participants willing to work on the
    problem (e.g., write drafts, review drafts, etc.).
    - the scope of the problem is well defined and understood, that is,
    people generally understand what the WG will work on (and what it
    won't) and what its actual deliverables will be.
    - there is agreement that the specific deliverables (i.e., proposed
    documents) are the right set.
    - it is believed that the WG has a reasonable probability of having
    success (i.e., in completing the deliverables in its charter in a
    timely fashion).

For this, the BoF proponents should be ready to answer any 
questions/concerns. Hence my attempt to guide you with a Q/A wiki.

    " 6) During the 2-4 weeks before an IETF (assuming a BOF has been
    approved and scheduled), the focus (on the mailing list) should be
    on identifying areas of agreement and areas of disagreement. Since
    disagreement, or "lack of consensus", tends to be the main reason
    for not forming a WG, focusing on those specific areas where "lack
    of consensus" exists is critically important. In general, only after
    those disagreements have been resolved will a WG be formed; thus,
    the main goal should be to find consensus and work through the areas
    of disagreement. Alternatively, a specific case should be made about
    why the charter, as it is written, is the best one, in spite of the
    stated opposition.", RFC 5434

Also, from a timing point of view, it's not particularly important to 
work on the WG deliverables (the deliverables are not written in stone 
anyway). The community must simply understand what you want to work on.

    "At this phase of the BOF preparation, the emphasis should be on
    getting agreement on the problem statement; discussions about
    specific solutions tend to be distracting and unhelpful.", RFC 5434

And finally, in terms of diversity of the SUPA group,

    "It is not enough for a handful of people to assert that they want a
    BOF; there needs to be broader community interest.", RFC 5434.

Regards, Benoit