Subject: Re: [Supa] SUPA Update

From: "Diego R. Lopez" <[email-masked]>
Date: Mon, 3 Jul 2017 16:16:16 +0000

Hi Benoit,

In the CogNet project (http://www.cognet.5g-ppp.eu) we are applying the data models to express the policy rules (and the events and actions) derived from the application of the so-called Smart Engine. We are discussing about following a similar path in SHIELD (https://www.shield-h2020.eu) to express security policies, and advocating for it in 5G-TRANSFORMER (http://5g-transformer.eu) when expressing rules for policy-based management. The results of these projects are being or will be transferred to our operational practices, as well as what is being defined in I2NSF, where SUPA seems the natural data model for expressing policies to the Security Controller.

Is tis the kind of statement you were asking for?

Be goode,

On 22 Jun 2017, at 07:58 , Benoit Claise <[email-masked]<mailto:[email-masked]>> wrote:

Hi Diego,

Can you expand on the re-usability aspects.
What is being reused? the information model, the data model, something else? I hope more than the concepts.
What are you, yourself, reusing?

Regards, Benoit
Hi Benoit,

While I cannot talk for YANG module authors, and it is true that the WG has a significant delay in its deliverables, I ‘d like to stress that SUPA has produced reusable work that is being used elsewhere, and a closing of the group before it finishes its commitments would damage these other works. I am directly involved in the I2NSF WG (that is progressing quite well in my opinion), and in several collaborative European projects related with 5G and security, including a number of network operators that are experimenting with SUPA-based policy statements. And I am aware of the ONUG interest as well, though not being involved I cannot detail what they are targeting now.

So I would ask you to reconsider the decision of closing SUPA at IETF 99.

Be goode,

On 15 Jun 2017, at 14:46 , Benoit Claise <[email-masked]<mailto:[email-masked]>> wrote:

Dear all,

After the last IETF, I put a calendar reminder on June 16th to decide on the next steps for SUPA.
This is inline with the our previous meeting minutes, so it should not come as a surprise.
Granted, this is one day earlier than foreseen, but the IESG agenda coordination call takes place today, and it was important from a scheduling point of view to understand if SUPA would meet. The chairs informed me that no SUPA meeting is required in Prague. That triggered this discussion, just one day earlier.

Our meeting minutes: https://www.ietf.org/mail-archive/web/supa/current/msg01612.html

At the SUPA WG at IETF 98 (Tuesday, 28 March) we discussed the
progress of the WG.  Benoit (our AD) summed up the situation, pointing
out that our drafts are not updated very frequently, and that the SUPA
mailing list has been very quiet between meetings.

At the meeting the authors of the SUPA Information model and the SUPA
Data Model drafts said that those drafts should be ready for WG Last
Call by 1 June, so that they could be sent to IESG for approval by
about 1 July.

After summing up the pros and cons for SUPA continuing, Benoit
concluded by saying that the WG will be closed at IETF 99 (Prague, 16
July) unless there is substantive progress on the Information Model
and especially on the Data Model drafts by one month before the Prague
meeting.  'Substantive progress' here means seeing comments on and/or
reviews of these drafts demonstrating that people - outside the small
group of authors - have carefully read the drafts, or better, that they
are actually using SUPA's Information and Data Models.

I've been watching the list.
Since the last IETF meeting, we received two new drafts ...
    draft-ietf-supa-generic-policy-info-model-03.txt
    draft-ietf-supa-generic-policy-data-model-03.txt
... and some draft reviews:
[email-masked]<mailto:[email-masked]> on on draft-ietf-supa-policy-based-management-framework:
Good feedback but it seems like only editorial to me.
Tony [email-masked]<mailto:[email-masked]> on draft-cheng-supa-applicability:
Some editorial comments and three technical ones:
1.       I wonder the meaning of section 3, the part copied from framework draft, may not be needed.
2.       I suggest to replace the title of 4.2.2.and 4.2.3 with detailed information instead of writing just   Example 1 / 2.
3.       The writer wrote “We will define "edgeInterface" role and "EnterpriseDomain" later in  this note” but I failed to find the explanation for these two term.
Benoit => it's more like one technical comment, the last one.

Haining Wang: [email-masked]<mailto:[email-masked]> on draft-ietf-supa-generic-policy-data-model-03:
I understand that the GPIM YANG model provides an example of how to convert IM to DM (for general policy), and John’s SNMP blocking example (https://mailarchive.ietf.org/arch/msg/supa/DWEzaSBK6KBdsmQ0FE2-eypTzeY) exposes some details. But I am sorry that the whole picture is still not clear to me. It would be nice if the ECA Data Model part can explain in more details.

March Blanchet on draft-ietf-supa-policy-based-management-framework:
- larger comment: I’m not sure what to do with this document. It looks like a large wish list of features. I guess I’m probably too used to implementation/protocol details. I guess I will wait until to see the actual protocol/yang models.

Let's analyze the situation:
I don't consider those reviews (btw a single one the DM, none on the IM) as "substantive progress".
I don't see interest from YANG module authors, ready to reuse the SUPA YANG constructs.
Being a year late according to the charter milestones, the window of opportunity to produce reusable work has been closing rapidly.
I believe that SUPA had multiple chances to make it happen, and failed to deliver.
With this in mind, I don't see how I should conclude anything else than this WG will be closing at IETF 99.

Regards, Benoit (OPS AD)
Dear supa’rs,

We have cancelled our formal meeting in Prague. This decision was taken based on a proposed plan to focus effort on completing the existing WG items and prepare for closure of the supa working group sometime between IETF 99 and 100. A plan that is yet to be approved by Benoit.

During the last working group meeting Benoit stated:

“the WG will be closed at IETF 99 (Prague, 16 July) unless there is substantive progress on the Information Model and especially on the Data Model draft by one month before the Prague meeting.”

The authors of the Data Model and Information Model I-Ds did submit new versions but we only received one review. However, Nevil and I are working with the IM and DM authors to gather reviewers in preparation of Last Call. Essentially, we are working to prep folks who would be able to review the documents we Last Call, ideally these should be from policy/yang implementers.

The Framework I-D has also received a review which is positive, and I am in the process of reviewing the document myself to also help prepare the document for Last Call. Additionally, the Applicability I-D (a non-working group document) received a review which is also useful.

We have also seen notifications from other SDOs following supa, specifically:
- ONUG: Investigating I2NSF combined with the SUPA data model and framework
- ETSI Experiential Networked Intelligence (ENI): New initiative defining context aware networking systems, SUPA was identified as a key building block
- MEF Open Lifecycle Service Orchestrator (LSO): Using SUPA between functional components

However, the indication from ONUG, ETSI and MEF does not materially change the situation of SUPA but it does demonstrate wider interest in our work, and at least some responsibility for supa/IETF to complete it (if possible). If you are aware of near-term implementations now is the time to highlight them.

Again, we felt we did not need a WG meeting in Prague to progress the working group I-Ds, and given the IETF agenda coordination call (is today) we had to cancel the supa WG session request ASAP, and unfortunately before we had a chance to communicate the current situation to the rest of the working group. Apologies for any surprise when you saw the cancellation notification, and the lack of opportunity for wider discussion.

As mentioned our proposed plan has been submitted to Benoit and is yet to be approved, therefore we will wait for his thoughts and ultimate decision.

The SUPA Chairs would sincerely like to thank everyone for their participation and especially the authors of I-Ds for their efforts.

BR, Nevil and Dan.

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

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

e-mail: [email-masked]<mailto:[email-masked]>
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------

________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

e-mail: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------

________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição

---

From: Benoit Claise <[email-masked]>
Date: Wed, 5 Jul 2017 15:39:54 +0200

Hi Diego,

Thanks for the discussion.
So you're applying the SUPA data model 
(draft-ietf-supa-generic-policy-data-model-04) 
<https://datatracker.ietf.org/doc/draft-ietf-supa-generic-policy-data-model/>?
Can you please share how you reuse them and what's your experience?

Regards, Benoit
> Hi Benoit,
>
> In the CogNet project (http://www.cognet.5g-ppp.eu) we are applying 
> the data models to express the policy rules (and the events and 
> actions) derived from the application of the so-called Smart Engine. 
> We are discussing about following a similar path in SHIELD 
> (https://www.shield-h2020.eu) to express security policies, and 
> advocating for it in 5G-TRANSFORMER (http://5g-transformer.eu) when 
> expressing rules for policy-based management. The results of these 
> projects are being or will be transferred to our operational 
> practices, as well as what is being defined in I2NSF, where SUPA seems 
> the natural data model for expressing policies to the Security Controller.
>
>> What is being reused? the information model, the data model, 
>> something else? I hope more than the concepts.
>>> While I cannot talk for YANG module authors, and it is true that the 
>>> WG has a significant delay in its deliverables, I ‘d like to stress 
>>> that SUPA has produced reusable work that is being used elsewhere, 
>>> and a closing of the group before it finishes its commitments would 
>>> damage these other works. I am directly involved in the I2NSF WG 
>>> (that is progressing quite well in my opinion), and in several 
>>> collaborative European projects related with 5G and security, 
>>> including a number of network operators that are experimenting with 
>>> SUPA-based policy statements. And I am aware of the ONUG interest as 
>>> well, though not being involved I cannot detail what they are 
>>> targeting now.
>>>
>>>> Granted, this is one day earlier than foreseen, but the IESG agenda 
>>>> coordination call takes place today, and it was important from a 
>>>> scheduling point of view to understand if SUPA would meet. The 
>>>> chairs informed me that no SUPA meeting is required in Prague. That 
>>>> triggered this discussion, just one day earlier.
>>>>
>>>> Our meeting minutes: 
>>>> https://www.ietf.org/mail-archive/web/supa/current/msg01612.html
>>>>
>>>>         [email-masked] on on
>>>>         draft-ietf-supa-policy-based-management-framework:
>>>>
>>>>         Tony [email-masked] on draft-cheng-supa-applicability:
>>>>
>>>>             1.       I wonder the meaning of section 3, the part
>>>>             copied from framework draft, may not be needed.
>>>>
>>>>             2.       I suggest to replace the title of 4.2.2.and
>>>>             4.2.3 with detailed information instead of writing just
>>>>               Example 1 / 2.
>>>>
>>>>             3.       The writer wrote “We will define
>>>>             "edgeInterface" role and "EnterpriseDomain" later in
>>>>              this note” but I failed to find the explanation for
>>>>             these two term.
>>>>
>>>>         Haining Wang: [email-masked] on
>>>>         draft-ietf-supa-generic-policy-data-model-03:
>>>>
>>>>             I understand that the GPIM YANG model provides an
>>>>             example of how to convert IM to DM (for general
>>>>             policy), and John’s SNMP blocking example
>>>>             (https://mailarchive.ietf.org/arch/msg/supa/DWEzaSBK6KBdsmQ0FE2-eypTzeY)
>>>>             exposes some details. But I am sorry that the whole
>>>>             picture is still not clear to me. It would be nice if
>>>>             the ECA Data Model part can explain in more details.
>>>>
>>>>         March Blanchet on
>>>>         draft-ietf-supa-policy-based-management-framework:
>>>>
>>>>             - larger comment: I’m not sure what to do with this
>>>>             document. It looks like a large wish list of features.
>>>>             I guess I’m probably too used to
>>>>             implementation/protocol details. I guess I will wait
>>>>             until to see the actual protocol/yang models. 
>>>>
>>>>
>>>> Being a year late according to the charter milestones, the window 
>>>> of opportunity to produce reusable work has been closing rapidly.
>>>>> We have cancelled our formal meeting in Prague. This decision was 
>>>>> taken based on a proposed plan to focus effort on completing the 
>>>>> existing WG items and prepare for closure of the supa working 
>>>>> group sometime between IETF 99 and 100. A plan that is yet to be 
>>>>> approved by Benoit.
>>>>>
>>>>> “the WG will be closed at IETF 99 (Prague, 16 July) unless there 
>>>>> is substantive progress on the Information Model and especially on 
>>>>> the Data Model draft by one month before the Prague meeting.”
>>>>>
>>>>> The authors of the Data Model and Information Model I-Ds did 
>>>>> submit new versions but we only received one review. However, 
>>>>> Nevil and I are working with the IM and DM authors to gather 
>>>>> reviewers in preparation of Last Call. Essentially, we are working 
>>>>> to prep folks who would be able to review the documents we Last 
>>>>> Call, ideally these should be from policy/yang implementers.
>>>>>
>>>>> The Framework I-D has also received a review which is positive, 
>>>>> and I am in the process of reviewing the document myself to also 
>>>>> help prepare the document for Last Call. Additionally, the 
>>>>> Applicability I-D (a non-working group document) received a review 
>>>>> which is also useful.
>>>>>
>>>>> - ETSI Experiential Networked Intelligence (ENI): New initiative 
>>>>> defining context aware networking systems, SUPA was identified as 
>>>>> a key building block
>>>>>
>>>>> However, the indication from ONUG, ETSI and MEF does not 
>>>>> materially change the situation of SUPA but it does demonstrate 
>>>>> wider interest in our work, and at least some responsibility for 
>>>>> supa/IETF to complete it (if possible). If you are aware of 
>>>>> near-term implementations now is the time to highlight them.
>>>>>
>>>>> Again, we felt we did not need a WG meeting in Prague to progress 
>>>>> the working group I-Ds, and given the IETF agenda coordination 
>>>>> call (is today) we had to cancel the supa WG session request ASAP, 
>>>>> and unfortunately before we had a chance to communicate the 
>>>>> current situation to the rest of the working group. Apologies for 
>>>>> any surprise when you saw the cancellation notification, and the 
>>>>> lack of opportunity for wider discussion.
>>>>>
>>>>> As mentioned our proposed plan has been submitted to Benoit and is 
>>>>> yet to be approved, therefore we will wait for his thoughts and 
>>>>> ultimate decision.
>>>>>
>>>>> The SUPA Chairs would sincerely like to thank everyone for their 
>>>>> participation and especially the authors of I-Ds for their efforts.
>>>>>
>>>>> BR, Nevil and Dan.
>>>>>
>>>>
>>>> [email-masked] <mailto:[email-masked]>
>>> ------------------------------------------------------------------------
>>>
>>> Este mensaje y sus adjuntos se dirigen exclusivamente a su 
>>> destinatario, puede contener información privilegiada o confidencial 
>>> y es para uso exclusivo de la persona o entidad de destino. Si no es 
>>> usted. el destinatario indicado, queda notificado de que la lectura, 
>>> utilización, divulgación y/o copia sin autorización puede estar 
>>> prohibida en virtud de la legislación vigente. Si ha recibido este 
>>> mensaje por error, le rogamos que nos lo comunique inmediatamente 
>>> por esta misma vía y proceda a su destrucción.
>>>
>>> The information contained in this transmission is privileged and 
>>> confidential information intended only for the use of the individual 
>>> or entity named above. If the reader of this message is not the 
>>> intended recipient, you are hereby notified that any dissemination, 
>>> distribution or copying of this communication is strictly 
>>> prohibited. If you have received this transmission in error, do not 
>>> read it. Please immediately reply to the sender that you have 
>>> received this communication in error and then delete it.
>>>
>>> Esta mensagem e seus anexos se dirigem exclusivamente ao seu 
>>> destinatário, pode conter informação privilegiada ou confidencial e 
>>> é para uso exclusivo da pessoa ou entidade de destino. Se não é 
>>> vossa senhoria o destinatário indicado, fica notificado de que a 
>>> leitura, utilização, divulgação e/ou cópia sem autorização pode 
>>> estar proibida em virtude da legislação vigente. Se recebeu esta 
>>> mensagem por erro, rogamos-lhe que nos o comunique imediatamente por 
>>> esta mesma via e proceda a sua destruição
>>
>
> --
> ------------------------------------------------------------------------
>
> Este mensaje y sus adjuntos se dirigen exclusivamente a su 
> destinatario, puede contener información privilegiada o confidencial y 
> es para uso exclusivo de la persona o entidad de destino. Si no es 
> usted. el destinatario indicado, queda notificado de que la lectura, 
> utilización, divulgación y/o copia sin autorización puede estar 
> prohibida en virtud de la legislación vigente. Si ha recibido este 
> mensaje por error, le rogamos que nos lo comunique inmediatamente por 
> esta misma vía y proceda a su destrucción.
>
> The information contained in this transmission is privileged and 
> confidential information intended only for the use of the individual 
> or entity named above. If the reader of this message is not the 
> intended recipient, you are hereby notified that any dissemination, 
> distribution or copying of this communication is strictly prohibited. 
> If you have received this transmission in error, do not read it. 
> Please immediately reply to the sender that you have received this 
> communication in error and then delete it.
>
> Esta mensagem e seus anexos se dirigem exclusivamente ao seu 
> destinatário, pode conter informação privilegiada ou confidencial e é 
> para uso exclusivo da pessoa ou entidade de destino. Se não é vossa 
> senhoria o destinatário indicado, fica notificado de que a leitura, 
> utilização, divulgação e/ou cópia sem autorização pode estar proibida 
> em virtude da legislação vigente. Se recebeu esta mensagem por erro, 
> rogamos-lhe que nos o comunique imediatamente por esta mesma via e 
> proceda a sua destruição

---

From: "Diego R. Lopez" <[email-masked]>
Date: Wed, 5 Jul 2017 20:37:55 +0000

Hi Benoit,

The most detailed discussion of the application of the SUPA data model can be found in the CogNet deliverable D6.2, “Integrated Platform and Performance Reports. Release 1”, which is a public document available at http://www.cognet.5g-ppp.eu/wp-content/uploads/2017/05/CogNet_D62.pdf The discussion of how SUPA is used is fundamentally made in sections 3 and 4, and appendix B.

I was thinking about summarizing this to augment the applicability statement, but I am afraid I have not found time for it yet…

Be goode,

On 5 Jul 2017, at 15:39 , Benoit Claise <[email-masked]<mailto:[email-masked]>> wrote:

Hi Diego,

Thanks for the discussion.
So you're applying the SUPA data model (draft-ietf-supa-generic-policy-data-model-04)<https://datatracker.ietf.org/doc/draft-ietf-supa-generic-policy-data-model/>?
Can you please share how you reuse them and what's your experience?

Regards, Benoit
Hi Benoit,

In the CogNet project (http://www.cognet.5g-ppp.eu<http://www.cognet.5g-ppp.eu/>) we are applying the data models to express the policy rules (and the events and actions) derived from the application of the so-called Smart Engine. We are discussing about following a similar path in SHIELD (https://www.shield-h2020.eu<https://www.shield-h2020.eu/>) to express security policies, and advocating for it in 5G-TRANSFORMER (http://5g-transformer.eu<http://5g-transformer.eu/>) when expressing rules for policy-based management. The results of these projects are being or will be transferred to our operational practices, as well as what is being defined in I2NSF, where SUPA seems the natural data model for expressing policies to the Security Controller.

Be goode,

Hi Diego,

Regards, Benoit
Hi Benoit,

Be goode,

Dear all,

Regards, Benoit (OPS AD)
Dear supa’rs,

BR, Nevil and Dan.

Dr Diego R. Lopez
Telefonica I+D

Dr Diego R. Lopez
Telefonica I+D

Dr Diego R. Lopez
Telefonica I+D

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 5 Jul 2017 21:07:02 +0000

Diego,

Thanks for the link.

Do you mean Section 3.2.2.3 using SUPA data model to configure a policy?

"supa-policy": {
"supa-policy-validity-period": {
"start": "2015-11-09T00:42:57.527404Z"
}
"supa-policy-target": {
"topicName": "demoX",
"domainName": "systemX",
"subNetwork": "192.168.1.1",
"instanceName": "rack1"
}
"supa-policy-statement": {
"event": {
"event-name": "noisy-neighbor",
"event-value-type": "float",
"event-value": "5.1"
"instanceName": "compute0.vm3",
}
"condition": {
"condition-name": "noisy-neighbor",
"condition-operator": ">",
"condition-threshold": "5.0",
"supa-script-content": {
"script-Java": "if (value > 5.0) return TRUE"
}
}
"action": {
"action-name": "noisy-neighbor",
"action-type": "migrate-vm"
"action-param1": {
"param-type": "entity"
"param-value": "compute2"
"instanceName": "compute2"
}
}
}
}

Thanks, Linda

From: SUPA [mailto:[email-masked]] On Behalf Of Diego R. Lopez
Sent: Wednesday, July 05, 2017 3:38 PM
To: Benoit Claise <[email-masked]>
Cc: King, Daniel <[email-masked]>; [email-masked]; [email-masked]; SUPA list <[email-masked]>
Subject: Re: [Supa] SUPA Update

Hi Benoit,

The most detailed discussion of the application of the SUPA data model can be found in the CogNet deliverable D6.2, "Integrated Platform and Performance Reports. Release 1", which is a public document available at http://www.cognet.5g-ppp.eu/wp-content/uploads/2017/05/CogNet_D62.pdf The discussion of how SUPA is used is fundamentally made in sections 3 and 4, and appendix B.

I was thinking about summarizing this to augment the applicability statement, but I am afraid I have not found time for it yet...

Be goode,

Hi Diego,

Regards, Benoit
Hi Benoit,

Be goode,

Hi Diego,

Regards, Benoit
Hi Benoit,

While I cannot talk for YANG module authors, and it is true that the WG has a significant delay in its deliverables, I 'd like to stress that SUPA has produced reusable work that is being used elsewhere, and a closing of the group before it finishes its commitments would damage these other works. I am directly involved in the I2NSF WG (that is progressing quite well in my opinion), and in several collaborative European projects related with 5G and security, including a number of network operators that are experimenting with SUPA-based policy statements. And I am aware of the ONUG interest as well, though not being involved I cannot detail what they are targeting now.

Be goode,

Dear all,

about 1 July.

3.       The writer wrote "We will define "edgeInterface" role and "EnterpriseDomain" later in  this note" but I failed to find the explanation for these two term.

Haining Wang: [email-masked]<mailto:[email-masked]> on draft-ietf-supa-generic-policy-data-model-03:
I understand that the GPIM YANG model provides an example of how to convert IM to DM (for general policy), and John's SNMP blocking example (https://mailarchive.ietf.org/arch/msg/supa/DWEzaSBK6KBdsmQ0FE2-eypTzeY) exposes some details. But I am sorry that the whole picture is still not clear to me. It would be nice if the ECA Data Model part can explain in more details.
March Blanchet on draft-ietf-supa-policy-based-management-framework:
- larger comment: I'm not sure what to do with this document. It looks like a large wish list of features. I guess I'm probably too used to implementation/protocol details. I guess I will wait until to see the actual protocol/yang models.

Regards, Benoit (OPS AD)

Dear supa'rs,

"the WG will be closed at IETF 99 (Prague, 16 July) unless there is substantive progress on the Information Model and especially on the Data Model draft by one month before the Prague meeting."

BR, Nevil and Dan.

Dr Diego R. Lopez
Telefonica I+D

Dr Diego R. Lopez
Telefonica I+D

Dr Diego R. Lopez
Telefonica I+D

---

From: youlizhao <[email-masked]>
Date: Thu, 6 Jul 2017 02:39:59 +0000

Dear All,

Below are my thought on ECA DM based on the materials I read and the project I am doing. Any comments would be welcome.

The discussions are based on an ECA Policy DM draft [eca-data-model]. According to our understanding, it is aligned with the ECA Policy IM [eca-info-model].

We appreciate that the draft [draft-chen-supa-eca-data-model-05] provides the entity/script abstraction that allows extension for different scenarios, and they match our implementation. In particular, our ECA policy parser can read entity fields (or script fields), and map them to the CLI command parameters (or script implementation).

However, we found that the current definition still makes DM parsing complicate. Note that, in [draft-chen-supa-eca-data-model-05], the condition-list clause may still involve with network details (e.g., bandwidth and threshold in the service-flow example), and the action-list clause may still contain the decision logic (i.e., when the bandwidth exceeds a threshold) to trigger an action. To extract the “real” condition, our policy parser needs to understand the action-list clause, and then generate the “condition” logic in real implementation.

To make things more complicate, sometimes we need to judge several conditions to trigger an action (e.g., in Cisco EEM [CiscoEEM, Pages 69, 342, 368] and some SD-WAN examples in Huawei SD-WAN solution [Huawei-SD-WAN]). In addition, some constraints may be added, e.g., the conjunctive-type duration that indicates how long the conjunctive relationship should hold. However, the current model is weak on expressing the capability (although conjunctive-type is defined in [eca-data-model], how to use it is not clear).

Based on the above arguments, we would like to suggest the following changes:
(a) A clear separation of events, conditions, and actions is welcome so that our parser can just care different parts and directly map them to implementation;
(b) The condition clause can be enriched to express the conjunctive-type, conjunctive-duration, and other possible fields.

Thanks!

Regards,
Leo

[eca-info-model] Generic Policy Information Model for SUPA
https://tools.ietf.org/html/draft-strassner-supa-generic-policy-info-model-05
[eca-data-model] ECA Policy YANG Data Model
https://tools.ietf.org/html/draft-chen-supa-eca-data-model-05
[Cisco-EEM] Embedded Event Manager Configuration Guide,
http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/eem/configuration/12-2sx/eem-12-2sx-book.pdf
[Huawei-SD-WAN] Huawei SD-WAN Solution Brochure
http://e.huawei.com/en/solutions/technical/sdn/enterprise-wan/sd-wan

From: SUPA [mailto:[email-masked]] On Behalf Of youlizhao
Sent: 2017年6月20日 15:38
To: Benoit Claise <[email-masked]>; King, Daniel <[email-masked]>
Cc: [email-masked]; [email-masked]; SUPA list <[email-masked]>
Subject: Re: [Supa] SUPA Update

Dear Benoit AD,

Thanks for pushing and monitoring the SUPA WG progress.

I am sorry to see the email below. I am an engineer in Huawei, and recently we have been developing the code of SUPA ECA policy to control the network. In particular, we provide restful interface to users for configuring ECA policies following the ECA DM.

To be honest, IMO, the ECA IM and DM are not mature enough for direct implementation. We are revising some parts facilitating the implementation.

Although the SUPA IM and DM still contain flaws, we hoped to see them completed (also other documents, e.g., SUPA framework) so that we can complete our own implementations based on SUPA standard work.

Thanks for your consideration.

Regards,
Leo

From: SUPA [mailto:[email-masked]] On Behalf Of Benoit Claise
Sent: 2017年6月15日 20:47
To: King, Daniel <[email-masked]<mailto:[email-masked]>>; SUPA list <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Supa] SUPA Update

Dear all,

about 1 July.

Regards, Benoit (OPS AD)
Dear supa’rs,

BR, Nevil and Dan.

---

From: "Diego R. Lopez" <[email-masked]>
Date: Thu, 6 Jul 2017 02:50:31 +0000

Hi Linda,

Actually, SUPA application is described along 3.2.3, 3.2.4, and 4.3. Appendix B is a deployment guide for the CogNet infrastructure, including examples of the SUPA constructs used.

Be goode,

On 5 Jul 2017, at 23:07 , Linda Dunbar <[email-masked]<mailto:[email-masked]>> wrote:

Diego,

Thanks for the link.

“supa-policy": {
“supa-policy-validity-period”: {
“start”: "2015-11-09T00:42:57.527404Z"
}
“supa-policy-target”: {
“topicName": “demoX”,
“domainName": “systemX”,
“subNetwork”: “192.168.1.1”,
“instanceName”: “rack1”
}
“supa-policy-statement”: {
“event": {
“event-name”: “noisy-neighbor”,
“event-value-type”: “float”,
“event-value”: “5.1”
“instanceName”: “compute0.vm3”,
}
“condition": {
“condition-name”: “noisy-neighbor”,
“condition-operator”: “>”,
“condition-threshold”: “5.0”,
“supa-script-content”: {
“script-Java”: “if (value > 5.0) return TRUE”
}
}
“action": {
“action-name”: “noisy-neighbor”,
“action-type”: “migrate-vm”
“action-param1”: {
“param-type”: “entity”
“param-value”: “compute2”
“instanceName”: “compute2”
}
}
}
}

Thanks, Linda

From: SUPA [mailto:[email-masked]] On Behalf Of Diego R. Lopez
Sent: Wednesday, July 05, 2017 3:38 PM
To: Benoit Claise <[email-masked]<mailto:[email-masked]>>
Cc: King, Daniel <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; SUPA list <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Supa] SUPA Update

Hi Benoit,

Be goode,

Hi Diego,

Regards, Benoit
Hi Benoit,

Be goode,

Hi Diego,

Regards, Benoit
Hi Benoit,

Be goode,

Dear all,

about 1 July.

Regards, Benoit (OPS AD)

Dear supa’rs,

BR, Nevil and Dan.

Dr Diego R. Lopez
Telefonica I+D

Dr Diego R. Lopez
Telefonica I+D

Dr Diego R. Lopez
Telefonica I+D

Dr Diego R. Lopez
Telefonica I+D

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 6 Jul 2017 00:52:11 -0400

I have not reviewed the Chen draft until now.
A brief review shows that it does not follow the patterns or approach 
defined in the IETF SUPA Information Model and the correspnding generic 
data model.

This matters as those models use exactly the strong separation you ask for.

Yours,
Joel

On 7/5/17 10:39 PM, youlizhao wrote:
> Dear All,
> 
> Below are my thought on ECA DM based on the materials I read and the 
> project I am doing. Any comments would be welcome.
> 
> The discussions are based on an ECA Policy DM draft [eca-data-model]. 
> According to our understanding, it is aligned with the ECA Policy IM 
> [eca-info-model].
> 
> We appreciate that the draft [draft-chen-supa-eca-data-model-05] 
> provides the entity/script abstraction that allows extension for 
> different scenarios, and they match our implementation. In particular, 
> our ECA policy parser can read entity fields (or script fields), and map 
> them to the CLI command parameters (or script implementation).
> 
> However, we found that the current definition still makes DM parsing 
> complicate. Note that, in [draft-chen-supa-eca-data-model-05], the 
> condition-list clause may still involve with network details (e.g., 
> bandwidth and threshold in the service-flow example), and the 
> action-list clause may still contain the decision logic (i.e., when the 
> bandwidth exceeds a threshold) to trigger an action. To extract the 
> “real” condition, our policy parser needs to understand the action-list 
> clause, and then generate the “condition” logic in real implementation.
> 
> To make things more complicate, sometimes we need to judge several 
> conditions to trigger an action (e.g., in Cisco EEM [CiscoEEM, Pages 69, 
> 342, 368] and some SD-WAN examples in Huawei SD-WAN solution 
> [Huawei-SD-WAN]). In addition, some constraints may be added, e.g., the 
> conjunctive-type duration that indicates how long the conjunctive 
> relationship should hold. However, the current model is weak on 
> expressing the capability (although conjunctive-type is defined in 
> [eca-data-model], how to use it is not clear).
> 
> (a) A clear separation of events, conditions, and actions is welcome so 
> that our parser can just care different parts and directly map them to 
> implementation;
> 
> (b) The condition clause can be enriched to express the 
> conjunctive-type, conjunctive-duration, and other possible fields.
> 
> Thanks!
> 
> Regards,
> 
> Leo
> 
> *From:*SUPA [mailto:[email-masked]] *On Behalf Of *youlizhao
> *Sent:* 2017年6月20日15:38
> *To:* Benoit Claise <[email-masked]>; King, Daniel 
> <[email-masked]>
> *Cc:* [email-masked]; [email-masked]; SUPA list <[email-masked]>
> *Subject:* Re: [Supa] SUPA Update
> 
> Dear Benoit AD,
> 
> I am sorry to see the email below. I am an engineer in Huawei, and 
> recently we have been developing the code of SUPA ECA policy to control 
> the network. In particular, we provide restful interface to users for 
> configuring ECA policies following the ECA DM.
> 
> To be honest, IMO, the ECA IM and DM are not mature enough for direct 
> implementation. We are revising some parts facilitating the implementation.
> 
> Although the SUPA IM and DM still contain flaws, we hoped to see them 
> completed (also other documents, e.g., SUPA framework) so that we can 
> complete our own implementations based on SUPA standard work.
> 
> *From:*SUPA [mailto:[email-masked]] *On Behalf Of *Benoit Claise
> *Sent:* 2017年6月15日20:47
> *To:* King, Daniel <[email-masked] 
> <mailto:[email-masked]>>; SUPA list <[email-masked] 
> <mailto:[email-masked]>>
> *Cc:* [email-masked] <mailto:[email-masked]>; [email-masked] 
> <mailto:[email-masked]>
> *Subject:* Re: [Supa] SUPA Update
> 
> Dear all,
> 
> scheduling point of view to understand if SUPA would meet. The chairs 
> informed me that no SUPA meeting is required in Prague. That triggered 
> this discussion, just one day earlier.
> 
> Our meeting minutes: 
>         [email-masked] <mailto:[email-masked]> on on
>         Tony [email-masked] <mailto:[email-masked]> on
>         draft-cheng-supa-applicability:
> 
>             2.       I suggest to replace the title of 4.2.2.and 4.2.3
>             with detailed information instead of writing just   Example
>             1 / 2.
> 
>             3.       The writer wrote “We will define "edgeInterface"
>             role and "EnterpriseDomain" later in  this note” but I
>             failed to find the explanation for these two term.
> 
>         Haining Wang: [email-masked] <mailto:[email-masked]> on
>             I understand that the GPIM YANG model provides an example of
>             how to convert IM to DM (for general policy), and John’s
>             SNMP blocking example
>             exposes some details. But I am sorry that the whole picture
>             is still not clear to me. It would be nice if the ECA Data
>             Model part can explain in more details.
> 
>             document. It looks like a large wish list of features. I
>             guess I’m probably too used to implementation/protocol
>             details. I guess I will wait until to see the actual
>             protocol/yang models.
> 
> 
> Being a year late according to the charter milestones, the window of 
> opportunity to produce reusable work has been closing rapidly.
>     existing WG items and prepare for closure of the supa working group
>     sometime between IETF 99 and 100. A plan that is yet to be approved
>     by Benoit.
> 
>     “the WG will be closed at IETF 99 (Prague, 16 July) unless there is
>     substantive progress on the Information Model and especially on the
>     Data Model draft by one month before the Prague meeting.”
> 
>     The authors of the Data Model and Information Model I-Ds did submit
>     new versions but we only received one review. However, Nevil and I
>     are working with the IM and DM authors to gather reviewers in
>     preparation of Last Call. Essentially, we are working to prep folks
>     who would be able to review the documents we Last Call, ideally
>     these should be from policy/yang implementers.
> 
>     The Framework I-D has also received a review which is positive, and
>     I am in the process of reviewing the document myself to also help
>     prepare the document for Last Call. Additionally, the Applicability
>     I-D (a non-working group document) received a review which is also
>     useful.
> 
>     defining context aware networking systems, SUPA was identified as a
>     key building block
> 
>     However, the indication from ONUG, ETSI and MEF does not materially
>     change the situation of SUPA but it does demonstrate wider interest
>     in our work, and at least some responsibility for supa/IETF to
>     complete it (if possible). If you are aware of near-term
>     implementations now is the time to highlight them.
> 
>     the working group I-Ds, and given the IETF agenda coordination call
>     (is today) we had to cancel the supa WG session request ASAP, and
>     unfortunately before we had a chance to communicate the current
>     situation to the rest of the working group. Apologies for any
>     surprise when you saw the cancellation notification, and the lack of
>     opportunity for wider discussion.
> 
> [email-masked]

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 6 Jul 2017 00:54:36 -0400

I just noticed that the Chen draft is long expired.  So it is not the 
authors' fault that it does not follow the strong separation approach 
that the SUPA WG is now using.
(My apologies to the authors if my note implied any fault by them.)

yours,
Joel

On 7/6/17 12:52 AM, Joel M. Halpern wrote:
>> our ECA policy parser can read entity fields (or script fields), and 
>> map them to the CLI command parameters (or script implementation).
>>
>> action-list clause may still contain the decision logic (i.e., when 
>> the bandwidth exceeds a threshold) to trigger an action. To extract 
>> the “real” condition, our policy parser needs to understand the 
>> action-list clause, and then generate the “condition” logic in real 
>> implementation.
>>
>> conditions to trigger an action (e.g., in Cisco EEM [CiscoEEM, Pages 
>> 69, 342, 368] and some SD-WAN examples in Huawei SD-WAN solution 
>> [Huawei-SD-WAN]). In addition, some constraints may be added, e.g., 
>> the conjunctive-type duration that indicates how long the conjunctive 
>> (a) A clear separation of events, conditions, and actions is welcome 
>> so that our parser can just care different parts and directly map them 
>> to implementation;
>>
>> recently we have been developing the code of SUPA ECA policy to 
>> control the network. In particular, we provide restful interface to 
>> users for configuring ECA policies following the ECA DM.
>>

---

From: youlizhao <[email-masked]>
Date: Tue, 11 Jul 2017 09:23:13 +0000

Hi Joel,

Thanks for your reply. I will take a look at the SUPA IM and generic DM.
Would you mind advising me which parts correspond to the separation? Many thanks! 

Regards,
Leo

----------------------------------------------------------------------------------------------
Lizhao (Leo) You, PhD
Senior Research Engineer
Huawei Technologies Co.,Ltd
[email-masked]
Tel: +86-1304-942-7487
www.linkedin.com/in/lizhao-you
----------------------------------------------------------------------------------------------

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]] 
Sent: 2017年7月6日 12:55
To: youlizhao <[email-masked]>; SUPA list <[email-masked]>; Benoit Claise <[email-masked]>
Cc: King, Daniel <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Supa] SUPA Update

I just noticed that the Chen draft is long expired.  So it is not the authors' fault that it does not follow the strong separation approach that the SUPA WG is now using.
(My apologies to the authors if my note implied any fault by them.)

yours,
Joel

On 7/6/17 12:52 AM, Joel M. Halpern wrote:
> defined in the IETF SUPA Information Model and the correspnding 
> generic data model.
> 
>> different scenarios, and they match our implementation. In 
>> particular, our ECA policy parser can read entity fields (or script 
>> fields), and map them to the CLI command parameters (or script implementation).
>>
>> so that our parser can just care different parts and directly map 
>> them to implementation;
>>
>> *Cc:* [email-masked] <mailto:[email-masked]>; 
>> [email-masked] <mailto:[email-masked]>
>> informed me that no SUPA meeting is required in Prague. That