Subject: [Supa] SUPA: Situation Summary and Next Steps

From: Benoit Claise <[email-masked]>
Date: Thu, 30 Jul 2015 14:33:03 +0200

Dear all,

Here is a summary of the situation after the SUPA BoF.
As we ran over time during the BoF, my conclusions were rather short at 
the mic. So let me start by expanding on a couple of points (in no 
particular order).

- Data model versus information model [RFC 3444].
There are no instructions that the IETF must only be working on data 
models as opposed to information models. If the group wants to work on 
information models, and can justify why this is important, fine. In this 
case, if it helps to connect with other SDOs that use information 
models, fine. IMO, I think a case for developing an information model 
has been made for SUPA.
However, we have to understand that the end goal is data models. Talking 
to some operators, their feedback is: "I can't do much with an 
information model, provide me with data models". And this is right, the 
end goal is more programmability and manageability for our networks, and 
this comes from data models. So if a group spends too long on an 
information model at the cost of delaying the rest of the work, there is 
something wrong.
This way of thinking would be in line with the LIME charter: "If the 
working group finds it necessary to work on an information model before 
the data model, it might do so. The working group will decide later 
whether the information model needs to be published as an RFC."
Note also some potentially interesting work related to information model 
in NETMOD: 
http://datatracker.ietf.org/doc/draft-mansfield-netmod-uml-to-yang/

- If SUPA could specify some reusable policy components, and some 
standard ways to manage policies, that could be beneficial for our 
industry.  So there is something into SUPA. However, we also have to 
acknowledge that there is some experimental aspects to SUPA, at least in 
the intent based part of the work (as opposed to the Event - Condition 
-  Action, which can be compared to the old RMON MIB). Indeed, what does 
it mean for "do what I mean" in a YANG model object? (Note: feel free to 
replace "do what I mean" with whatever intent-based example you want). 
This is why I repeatedly asked the question to the SUPA community: I 
wonder what we have in those YANG models?

- It's great that some operators came to the IETF to express their 
interest for SUPA.
On the other end, I'll still trying to understand how they would be 
using the SUPA deliverables: how do you plan to use a YANG model with 
generic policy objects. I'm in contact with some of them.****

- We had some balanced hums on the following two questions.
     Does the community think that the problem statement is clear, 
well-scoped, solvable, and useful to solve?
     Is there support to form a WG with the charter presented at the BOF 
(with edits)?
This is the most difficult situation for an AD.

- During the BoF, there was still some confusion about generic objects, 
a specific instance of a policy, mapping function, and the policy 
engine. Having the audience prepared the SUPA BoF by reading the 15 SUPA 
drafts, the proposed charter, the WIKI... wishful thinking. Btw, reading 
the draft-klyus-supa-proposition-02, I see a couple of points that we 
should make crystal clear in the proposed charter.

- I've been trying to get feedback from different vendors regarding 
SUPA, as we have to observe that this SUPA effort is mainly pushed by a 
single vendor. This is absolutely not a problem, but I need to 
understand why other vendors were not involved. From my discussions, I 
gathered feedback such as "no interested", "this is a terrible idea", 
"no harm".

What are the next steps?

1. I'll take the pen on the charter (Robert Sparks, from the IAB, will 
be helping), incorporating changes that hopefully will clarify the 
situation, based on my understanding. Those additions/changes come from 
questions during the BoF, form draft-klyus-supa-proposition-02, from 
email discussions (SUPA mailing list and numerous private exchanges), 
and from the IESG/IAB discussions.
Give me at least a couple of working days for this.

3. Then, we will see if this new charter is more broadly 
understood/accepted. I'll take my inputs not only from the SUPA 
community, but also from people who were vocal against SUPA, people who 
had clarifying questions, from operators, and from vendors.

4. From there, three possible outcomes:
     - charter is clarified and well received: we proceed with the 
charter proposal
     - again, we face balanced support. Then,
         - we might explore the IRTF track
         - or we simply stop

Regards, Benoit (OPS AD)