Subject: Re: [netmod] Adoption poll for draft-wwx-netmod-event-yang-10

From: Qin Wu <[email-masked]>
Date: Tue, 8 Dec 2020 01:20:45 +0000

Support as a coauthor.

-Qin
-----邮件原件-----
发件人: netmod [mailto:[email-masked]] 代表 Lou Berger
发送时间: 2020年12月8日 6:28
收件人: NETMOD Group <[email-masked]>
抄送: NetMod WG Chairs <[email-masked]>
主题: [netmod] Adoption poll for draft-wwx-netmod-event-yang-10

This email begins a 2-week adoption poll for:

https://tools.ietf.org/html/draft-wwx-netmod-event-yang-10

Please voice your support or technical objections on list before the end of December 21, any time zone.

Thank you!

Netmod Chairs

PS Note the IPR poll is running concurrently as the private response all indicated that no IPR exists.  The draft will not be formally adopted until both the IPR and WG polls are complete.

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

---

From: [email-masked]<[email-masked]>
Date: Tue, 8 Dec 2020 10:14:06 +0800 (GMT+08:00)

Yes, support.

Regards,

Peng

---Original---

From: "Lou Berger"<[email-masked]>

Date: Tue, Dec 8, 2020 06:27 AM

To: "NETMOD Group"<[email-masked]>;

Cc: "NetMod WG Chairs"<[email-masked]>;

Subject: [netmod] Adoption poll for draft-wwx-netmod-event-yang-10

Please voice your support or technical objections on list before the end
of December 21, any time zone.

Thank you!

Netmod Chairs

PS Note the IPR poll is running concurrently as the private response all
indicated that no IPR exists.  The draft will not be formally adopted
until both the IPR and WG polls are complete.

---

From: "ybliu"<[email-masked]>
Date: Thu, 10 Dec 2020 21:32:12 +0800

Hi all:
I support this draft.

Yonbo Liu

-----邮件原件----- 发件人: netmod [mailto:[email-masked]] 代表 Lou Berger 发送时间: 2020年12月8日 6:28 收件人: NETMOD Group <[email-masked]> 抄送: NetMod WG Chairs <[email-masked]> 主题: [netmod] Adoption poll for draft-wwx-netmod-event-yang-10 This email begins a 2-week adoption poll for: https://tools.ietf.org/html/draft-wwx-netmod-event-yang-10 Please voice your support or technical objections on list before the end of December 21, any time zone. Thank you! Netmod Chairs PS Note the IPR poll is running concurrently as the private response all indicated that no IPR exists.  The draft will not be formally adopted until both the IPR and WG polls are complete. _______________________________________________ netmod mailing list [email-masked] https://www.ietf.org/mailman/listinfo/netmod

---

From: Qin Wu <[email-masked]>
Date: Fri, 11 Dec 2020 09:52:45 +0000

Forward the message from Ander to the list, thanks!

-Qin
-----邮件原件-----
发件人: andersliu(刘琛) [mailto:[email-masked]] 
发送时间: 2020年12月11日 17:18
收件人: Qin Wu <[email-masked]>
主题: FW: [netmod] Adoption poll for draft-wwx-netmod-event-yang-10(Internet mail)

在 2020/12/11 下午4:30，“andersliu(刘琛)”<[email-masked]> 写入:

    Hi,ALL

    I support the adoption of this draft

    BR
    Anders

        -----邮件原件-----
        发件人: netmod [mailto:[email-masked]] 代表 Lou Berger
        发送时间: 2020年12月8日 6:28
        收件人: NETMOD Group <[email-masked]>
        抄送: NetMod WG Chairs <[email-masked]>
        主题: [netmod] Adoption poll for draft-wwx-netmod-event-yang-10

        Thank you!

        Netmod Chairs

---

From: "Wubo (lana)" <[email-masked]>
Date: Tue, 15 Dec 2020 06:12:56 +0000

I support the adoption. 

Best regards,
Bo

-----邮件原件-----
发件人: netmod [mailto:[email-masked]] 代表 Lou Berger
发送时间: 2020年12月8日 6:28
收件人: NETMOD Group <[email-masked]>
抄送: NetMod WG Chairs <[email-masked]>
主题: [netmod] Adoption poll for draft-wwx-netmod-event-yang-10

Thank you!

Netmod Chairs

---

From: Chang Liu(联通集团中国联通研究院-本部) <[email-masked]>
Date: Fri, 18 Dec 2020 01:38:25 +0000

Hi all,

We support the adoption of it.
ECA is useful for the future network, and it needs a YANG for its management.
We hope that an experimental network can be realized in a few years.

Best Regards

________________________________
Liu Chang
China Unicom
Email: [email-masked]
Phone: +8618601102572

---Original---

From: Lou Berger
Date: 2020-12-08 06:27
To: NETMOD Group
CC: NetMod WG Chairs

Thank you!

Netmod Chairs

如果您错误接收了该邮件，请通过电子邮件立即通知我们。请回复邮件到 [email-masked]，即可以退订此邮件。我们将立即将您的信息从我们的发送目录中删除。 If you have received this email in error please notify us immediately by e-mail. Please reply to [email-masked] ,you can unsubscribe from this mail. We will immediately remove your information from send catalogue of our.

---

From: Igor Bryskin <[email-masked]>
Date: Fri, 18 Dec 2020 18:12:27 +0000 (UTC)

I support (as a co-anther/
Cheers,Igor

hould have mentioned that this is the 2nd adoption call on this document.  for full context on discussion on this draft, see https://mailarchive.ietf.org/arch/browse/netmod/?q=draft-wwx-netmod-event-yang

On 12/7/2020 5:27 PM, Lou Berger wrote:
> PS Note the IPR poll is running concurrently as the private response 
> all indicated that no IPR exists.  The draft will not be formally 
> adopted until both the IPR and WG polls are complete.
>
>

---

From: andy L <[email-masked]>
Date: Mon, 21 Dec 2020 13:13:01 +0800

I support this adoption.
thanks
Liu

---

From: "Lingli Deng" <[email-masked]>
Date: Mon, 21 Dec 2020 15:52:27 +0800

Hi all,

I support the adoption.

Lingli

-----邮件原件-----
发件人: netmod [mailto:[email-masked]] 代表 Lou Berger
发送时间: 2020年12月8日 6:28
收件人: NETMOD Group <[email-masked]>
抄送: NetMod WG Chairs <[email-masked]>
主题: [netmod] Adoption poll for draft-wwx-netmod-event-yang-10

Thank you!

Netmod Chairs

---

From: Henk Birkholz <[email-masked]>
Date: Mon, 21 Dec 2020 12:27:56 +0100

Hi chairs,
hi group,

as an author, I support the adoption of this document. Robust event 
generation is an important foundation for corresponding automation 
mechanics.

Viele Grüße,

Henk

---

From: Qin Wu <[email-masked]>
Date: Tue, 22 Dec 2020 02:28:18 +0000

Thanks Adrian for valuable comments, see reply inline below.
-----邮件原件-----
发件人: netmod [mailto:[email-masked]] 代表 Adrian Farrel
发送时间: 2020年12月8日 18:51
收件人: 'Lou Berger' <[email-masked]>; 'NETMOD Group' <[email-masked]>
抄送: 'NetMod WG Chairs' <[email-masked]>
主题: Re: [netmod] Adoption poll for draft-wwx-netmod-event-yang-10

Hi,

I have generally been sceptical about Intention-based network operations within the IETF, and I was ambivalent about this document at the first adoption poll. 

However, I think that some good work has been done since then and the document has reached a level where the WG could adopt it and further refine it. There is clearly a body of people who want to work on it, and it seems to be within the WG scope, so I support adoption.

I also think that splitting this piece off the larger body of Intention-based work is a wise first step.
[Qin]: Thanks ,Agree.

Here are a few comments for the authors based on a quick reading...

Abstract.
I appreciate the brevity of the Abstract, but I don't find it very clear. Specifically, what is "the server" and what role would it play absent this YANG model? Conversely, who/what is delegating some of the network management functions? And lastly, is the choice of which network management functions to delegate well known (I assume it is) or up to an implementation?

[Qin]: Good comment, I think the server is referred to an entity that provides access to YANG-defined data to a client, over some network management protocol. I will quote the terminology defined in RFC7950 for the "server" defined in this document.
The client, more precisely the remote client, i.e., NMS or management system will delegate the network management functions, these network management functions will realize the ECA logic or ECA Policy management. 
The choice of which network management function should be well known, that's why define this model and associated ECA XPath Function Library to make sure
these network management function can be implemented in the standard way or interoperable way.
---

Introduction
The first mention of "ECA" comes in...
   This document defines an ECA Policy management YANG data model.
I think you need to:
- Expand the abbreviation
- Explain in one or two sentences what ECA is
[Qin]: Good suggestion, here is the proposed change:
OLD TEXT:
"
This document defines a YANG data model for Event Condition Action (ECA) policy management.
"
NEW TEXT:
"
Event Condition Action (ECA) provides the structure of active rules in event-driven architecture which exhibits self-management 
properties such as self-configuration, self-healing, self-optimization, and self-protection. This document defines a YANG data 
model for ECA policy management.
"
---

Section 2.1
You need to update to the more recent boilerplate that mentions RFC 8174

[Qin] Good catch, will change the boilerplate and add reference to RFC8174.
---

Section 2.1
You use the term "Event Stream" without defining it
[Qin]: Will reference RFC5277 for event stream definition, thanks.
Cheers,
Adrian

-----Original Message-----
From: netmod <[email-masked]> On Behalf Of Lou Berger
Sent: 07 December 2020 22:28
To: NETMOD Group <[email-masked]>
Cc: NetMod WG Chairs <[email-masked]>
Subject: [netmod] Adoption poll for draft-wwx-netmod-event-yang-10

Thank you!

Netmod Chairs

---

From: Qin Wu <[email-masked]>
Date: Tue, 22 Dec 2020 02:33:14 +0000

-----邮件原件-----
发件人: netmod [mailto:[email-masked]] 代表 Dhruv Dhody
发送时间: 2020年12月22日 1:12
收件人: Lou Berger <[email-masked]>
抄送: NetMod WG Chairs <[email-masked]>; NETMOD Group <[email-masked]>
主题: Re: [netmod] Adoption poll for draft-wwx-netmod-event-yang-10

Hi Lou, WG,

I find the motivation in the Introduction to be focused on ECA at the network devices (with all the talk about issues with Centralized network management).
[Qin]: Thanks Dhruv, ECA at the network device is one typical case, but ECA can be applicable to any Client server model.

I see the value of ECA on the controller as well, say a customer network controller or an orchestrator can set the ECA on a central controller (reference ACTN in TEAS WG). Perhaps you would consider adding a sentence to describe this as well. The client-server terminology in the rest of the document covers it already.

[Qin]: That's correct, will make this clear in the text.

And I do see value in this and support adoption.

Thanks!
Dhruv

---

From: Qin Wu <[email-masked]>
Date: Wed, 23 Dec 2020 05:09:20 +0000

Thanks Lou, I have pinged the last author to confirm IPR call explicitly on the list.

-Qin
-----邮件原件-----
发件人: netmod [mailto:[email-masked]] 代表 Lou Berger
发送时间: 2020年12月23日 8:28
收件人: NETMOD Group <[email-masked]>
抄送: NetMod WG Chairs <[email-masked]>
主题: Re: [netmod] Adoption poll for draft-wwx-netmod-event-yang-10

Hi,

The response to this poll is sufficient for it to be adopted.  We just need the 3 missing IPR statements and, assuming no surprises, the document can be republished as a WG document.

Authors,

Please prepare a version of the draft with only the file name changed to draft-ietf-netmod-eca-policy-00.  The -01 version should address issues / comments raised during adoption.  Note that publication of the -00 version is gated by the completion of the IPR poll.

Thank you!

Lou (for co-chairs)

---

From: Qin Wu <[email-masked]>
Date: Thu, 24 Dec 2020 02:25:36 +0000

Hi, 
-----邮件原件-----
发件人: tom petch [mailto:[email-masked]] 
发送时间: 2020年12月24日 0:49
收件人: Qin Wu <[email-masked]>; Dhruv Dhody <[email-masked]>; Lou Berger <[email-masked]>
抄送: NetMod WG Chairs <[email-masked]>; NETMOD Group <[email-masked]>
主题: Re: [netmod] Adoption poll for draft-wwx-netmod-event-yang-10

From: Qin Wu <[email-masked]>
Sent: 23 December 2020 14:30

Hi, Tom:
-----邮件原件-----
发件人: netmod [mailto:[email-masked]] 代表 tom petch
发送时间: 2020年12月23日 19:14
收件人: Dhruv Dhody <[email-masked]>; Lou Berger <[email-masked]>
抄送: NetMod WG Chairs <[email-masked]>; NETMOD Group <[email-masked]>
主题: Re: [netmod] Adoption poll for draft-wwx-netmod-event-yang-10

From: netmod <[email-masked]> on behalf of Dhruv Dhody <[email-masked]>
Sent: 21 December 2020 17:12

Hi Lou, WG,

<tp>
My take is that the I-D is unclear on what ECA is.

[Qin]: Thanks Tom, Adrian raised the similar issue about the abstract improvement and we will address this in v-01.

ECA has been worked on in at least two IETF WG AFAICT.  It cropped up in I2RS but as I recall, it was along the lines of 'This is ECA'  'No It is not'  'Yes it is' which gave me the impression that ECA is not a well-defined, or well-understood, term.

More recently, I2NSF have produced a YANG capability-data-model which is 55 pages of ECA.  Lacking a definition in this netmod I-D, I am unclear what the relationship is between the I2NSF I-D and the netmod I-D, whether or not they are using ECA in the same sense.

[Qin]: I haven't followed closely on what had been done in I2NSF.  But I did talk with two of I2NSF proponents in this year. They tend to agree the model proposed in draft-wwx will serve as the basis for I2NSF security policy model or NSF facing interface DM. Unfortunately I haven't seen their update to do the alignment. I missed their I2NSF recharter discussion meeting. But I would also highly recommend they import the model in draft-wwx and reuse some of these building block. I plan to raise this issue later on.
For I2RS model, it was packet forwarding policy model, which has been expired for many years. If that draft needs to be revived, I think we can follow the similar approach for I2NSF security policy model.

[tp] No need to bother with I2RS, I think that that I-D is well buried but the I2NSF work is well advanced, one in the RFC Editor queue, two submitted to the IESG while the capability data model has had YANG Doctor, Tsvart and Genart reviews none of which doubted the approach to ECA so you could find I2NSF saying that the Netmod WG should fall into line with prior art!.

[Qin]:Good suggestion, thanks Tom, I revisit some of these drafts in I2NSF again and find they lack concrete reference for ECA policy paradigm and definition. Let's see if we can make alignment for this.

Tom Petch

Dhruv

---

From: Qin Wu <[email-masked]>
Date: Thu, 24 Dec 2020 02:26:46 +0000

发件人: netmod [mailto:[email-masked]] 代表 Andy Bierman
发送时间: 2020年12月23日 23:06
收件人: tom petch <[email-masked]>
抄送: NetMod WG Chairs <[email-masked]>; NETMOD Group <[email-masked]>
主题: Re: [netmod] Adoption poll for draft-wwx-netmod-event-yang-10

On Wed, Dec 23, 2020 at 3:14 AM tom petch <[email-masked]<mailto:[email-masked]>> wrote:
From: netmod <[email-masked]<mailto:[email-masked]>> on behalf of Dhruv Dhody <[email-masked]<mailto:[email-masked]>>
Sent: 21 December 2020 17:12

Hi Lou, WG,

I find the motivation in the Introduction to be focused on ECA at the
network devices (with all the talk about issues with Centralized
network management).

I see the value of ECA on the controller as well, say a customer
network controller or an orchestrator can set the ECA on a central
controller (reference ACTN in TEAS WG). Perhaps you would consider
adding a sentence to describe this as well. The client-server
terminology in the rest of the document covers it already.

<tp>

Hi Tom,

It usually helps to agree on the problem-space before focusing on the solution-space.
ECA seems like a methodology (ala MVC) more than anything else.
The problem statement seems to be that some client tasks need to be handled on the
server using ECA methodology, instead of on the client.
Which tasks? Seems to be any task of arbitrary purpose or complexity.
And now the scope is supposed to include controllers (just another client), so the problem-stmt
is even less clear.

[Qin]:Just to clarify, the idea is to delegate network control logic to the server from the client for self management such as self monitoring.
The client can be the domain controller, the sever can be the network device. In another case based on the discussion on the list, is the client can
Be multi-domain controller, the server can be domain controller, it doesn’t intend to expand the scope.
The typical use cases are the smart filter or cronjob task management. Some of these cases require multiple step interactions between the server and local client.

The traditional approach is to pick specific client tasks to move to the server.
The example of detecting and reporting route-flaps has been used.
(No ECA example of this complexity has been provided yet).
The traditional approach would be to write a route-flap-detection YANG module with some
configuration, monitoring data, and notification events.

[Qin]: The tradition approach doesn’t allow you send notification events to the local client (i.e., the server itself)
for self-management.
In addition, the down side of the tradition approach is that for each case, you need to define a technology specific module.

The generalized approach is likely to be extremely complex to standardize and implement.
[Qin]: Agree to limit the scope to the concrete use cases and not take SUPA approach and boil ocean to address any cases.
Thanks Andy.

Tom Petch

Andy

Thanks!
Dhruv

On Tue, Dec 8, 2020 at 3:59 AM Lou Berger <[email-masked]<mailto:[email-masked]>> wrote:
> [email-masked]<mailto:[email-masked]>

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

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

---

From: Qin Wu <[email-masked]>
Date: Thu, 24 Dec 2020 02:29:26 +0000

-----邮件原件-----
发件人: netmod [mailto:[email-masked]] 代表 Juergen Schoenwaelder
发送时间: 2020年12月24日 2:09
收件人: Andy Bierman <[email-masked]>
抄送: NetMod WG Chairs <[email-masked]>; NETMOD Group <[email-masked]>
主题: Re: [netmod] Adoption poll for draft-wwx-netmod-event-yang-10

On Wed, Dec 23, 2020 at 07:05:44AM -0800, Andy Bierman wrote:
> On Wed, Dec 23, 2020 at 3:14 AM tom petch <[email-masked]> wrote:
> 
> > I find the motivation in the Introduction to be focused on ECA at 
> > the network devices (with all the talk about issues with Centralized 
> > network management).
> >
> > ECA has been worked on in at least two IETF WG AFAICT.  It cropped 
> > up in I2RS but as I recall, it was along the lines of 'This is ECA'  
> > 'No It is not'  'Yes it is' which gave me the impression that ECA is 
> > not a well-defined, or well-understood, term.
> >
> > More recently, I2NSF have produced a YANG capability-data-model 
> > which is
> > 55 pages of ECA.  Lacking a definition in this netmod I-D, I am 
> > unclear what the relationship is between the I2NSF I-D and the 
> > netmod I-D, whether or not they are using ECA in the same sense.
> >
> >
> Hi Tom,
> 
> The problem statement seems to be that some client tasks need to be 
> handled on the server using ECA methodology, instead of on the client.
> And now the scope is supposed to include controllers (just another 
> client), so the problem-stmt is even less clear.
> 
> The traditional approach would be to write a route-flap-detection YANG 
> module with some configuration, monitoring data, and notification 
> events.
> 

ECA work has a long 20+ year tradition in the IETF and several specifications have been published over the years by various working groups. As far as I can tell, none of them got traction in terms of signifiant deployment of interoperable implementations.

I would have hoped that the next iteration of ECA work would have started with a deep reflection about why all the previous attempts failed to gain traction and some genuine insights how to design things differently in order to improve the likelihood to have impact.

[Qin]: Thanks Jurgen for good advice, we will learn the lesson in the past and avoid that pitfall. 
/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: Qin Wu <[email-masked]>
Date: Thu, 24 Dec 2020 13:21:55 +0000

Speaking for myself, breaking down ECA logic or ECA paradigm, extracting policy variable from the event, Mapping Policy Variables to XPath Variables, using standard function call defined in ECA XPath Function Library will guarantee us to create an interoperable standard, the last one is the most important one, I think that is the key difference with the previous attempts. We spent a quite a lot of time to discuss this and got this agreed in the design team.

-Qin
-----邮件原件-----
发件人: netmod [mailto:[email-masked]] 代表 Juergen Schoenwaelder
发送时间: 2020年12月24日 16:25
收件人: NETMOD Group <[email-masked]>
主题: Re: [netmod] Adoption poll for draft-wwx-netmod-event-yang-10

On Wed, Dec 23, 2020 at 07:08:52PM +0100, Juergen Schoenwaelder wrote:
> 
> ECA work has a long 20+ year tradition in the IETF and several 
> specifications have been published over the years by various working 
> groups. As far as I can tell, none of them got traction in terms of 
> signifiant deployment of interoperable implementations.
> 
> I would have hoped that the next iteration of ECA work would have 
> started with a deep reflection about why all the previous attempts 
> failed to gain traction and some genuine insights how to design things 
> differently in order to improve the likelihood to have impact.
>

Let me be a bit more explicit.

I would have expected that the senior IETF people mentioned as co-authors or contributors, who are very well familiar with the relevant history (Benoit Claise, Andy Bierman, Alex Clemm), would have explained here (or in the document) why this approach to create an interoperable standard for ECA has potential to succeed given the limited success of the prior attempts.

Adopting this work without having answered this question seems premature. If the proponents of this work do not have an answer to this question, the WG will likely not find one either.

/js

---

From: Qin Wu <[email-masked]>
Date: Fri, 25 Dec 2020 01:20:04 +0000

IMO this is an area where running code really matters.

[Qin]: Fully agree, I believe many vendors and proponents have implemented this functionality (I don’t want to name them) and could be a good basis for this model implementation.
Follow similar fashion, we can ask implementation report before this draft gets out of WG.

We should be standardizing the "trailing edge": multiple independent non-standard solutions

exist and the IETF creates a "best-hits" standard.

[Qin]: This is exactly what we are doing in the past, one single draft consolidated from 2~3 independent individual drafts, way back 2~3 years
if we remember the history where this come from.
I have been told recently by some of operators, some other SDO such as ETSI NFV and open source community, they are also looking for such solution and want to use this work as basis for alignment.
Hopefully they will provide input to this work soon.

We should be avoiding Ivory Tower "leading edge" standards where design teams decide how
the world SHOULD work, and there is no running code to back up the theory.

---

From: "Diego R. Lopez" <[email-masked]>
Date: Wed, 30 Dec 2020 00:34:27 +0000

Hi,

I support the adoption, as a contributor.

While it is true previous attempts have ended in awkward approaches to the general problem of policy-based management, I believe there are new elements at hand in what relates to data flows (with proposals such as model-based telemetry and dynamic probes), decision mechanisms (with all the AI/ML variants you can think of) and action flows (with any SDN mechanism you prefer) to explore a model-based solution.

Be goode,

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
https://www.linkedin.com/in/dr2lopez/

e-mail: [email-masked]
Mobile:  +34 682 051 091
----------------------------------

On 7/12/2020, 17:27, Lou Berger <[email-masked]> wrote:

    Thank you!

    Netmod Chairs

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