URGENT - TSC Frankfurt Prioritization - Time to decide (10/28)


Catherine LEFEVRE
 

Good morning/afternoon/evening TSC Members  (or proxies),

 

Please find an update regarding the last review performed about TSC Frankfurt Prioritization and based on latest ONAP Community’s feedback.

I have also created a wiki page that will give a view of Code impact per component https://wiki.onap.org/display/DW/Frankfurt+Code+Impact+View+per+Component

 

Please provide your feedback no later than Tuesday, Oct 29th EOD

We really need to conclude on TSC prioritization asap – thanks

If no feedback received then I will publish the TSC prioritization as suggested below by Wednesday, Oct 30th, 2019

Your voice really matters so please raise it now – thank you !!

I am also sending this e-mail to tsc-vote in case you did not see my previous tsc-private e-mails related to Frankfurt prioritization.

 

I have also attached the spreadsheet for additional details.

 

·        RANK #0  – Special GO - fully covered by involved companies

·        RANK #1  – GO “Must Have”

·        RANK #2 - GO “Continuity of previous releases”

·        RANK #3 – GO if PTLs are OK since the impacted applications are less “stretched”

·        RANK #4 – NO GO – Mostly new requirements/features/projects

 

It means

RANK0-2 – these will be our initial Frankfurt if PTLs (including Integration confirmed they have the right level of details, developers and testers)

RANK3 – Only possible if PTLs are getting additional resources vs #Committers that can review the submitted code

RANK4 - Descoped

 

Candidates to Rank #0 (Special Go)

·        Documentation/Modeling Impact Only – No DEV/TEST Impact

o   Modeling: documentation of policy and allotted resource model

o   5G / 5G Service Modeling: Modeling (exploratory) work for creating a 5G Service

o   Modeling: Runtime instance model based on A&AI reverse engineering

o   Architecture - Modeling Alignment

o   5G / License Management

 

·        Small change and can bring adoption

o   3rd party Operational Domain Manager

 

Candidates to RANK 1- TSC Must have

Companies who are developing use cases/requirements for a specific component must also help PTL to meet “TSC MUST Have”

·        Remove Python2 dependencies

·        Waivers granted in El-Alto should be resolved in Frankfurt

·        Portal Security Enhancements

·        S3P Maturity Improvements  - Need Jason/Pawal to confirm S3P MUST HAVE

o   Document current upgrade component upgrade strategy

o   SECCOM Perform Software Composition Analysis - Vulnerability tables

o   SECCOM Password removal from OOM HELM charts

o   SECCOM HTTPS communication vs. HTTP

 

 

Candidates to RANK 2- Continuity

o   CCVPN:E-LINE Service over OTN NNI

o   Policy Update Notifications

o   Self Serve Control Loops

o   All Control Loop Policy Models should be TOSCA Compliant

o   5G / Bulk PM / PM Control

o   PNF / PNF pre-onboarding onboarding

o   5G / OOF SON Enhancement

o   PNF / PNF Software Upgrade using direct Netconf/Yang interface with PNF

o   Component Upgrades to new Policy Lifecycle API

o   Multicloud K8s Support (Continuation from R4)

o   PNF / Enhancement on PNF Software Upgrade with EM with Ansible

o   Scaling Extensions

o   PNF / Enable Schema Update once PNF software is updated

o   5G / PM dictionary

o   PNF / PNF Software Upgrade with EM with Netconf

o   Change Management: APPC Ansible automation with VNF-C LCM support / CHM

o   Change Management: vFW Traffic Distribution with Software Upgrade / CHM

 

 

Depending on PTL bandwidth

 

Candidates to Rank #3

Only possible if PTLs are getting additional resources vs #Committers that can review the submitted code

Let’s take an example – “End to End Layer 1 Service Management. Modeling the Optical Service

This use case is impacting AAI, UUI, SDNC, SO – code impact

               This use case can only be implemented if the 4 components are able to deliver their RANK0-2 i.e

o   AAI – CCVPN-E; Modeling: Enhanced Nested and Shared Service Information Model - 5G / E2E Network Slicing modeling;

o   SO - End to End Layer 1 Service Management. Modeling the Optical Service

o   UUI - CCVPN-E; End to End Layer 1 Service Management. Modeling the Optical Service

o   SDNC - CCVPN-E; End to End Layer 1 Service Management. Modeling the Optical Service;Component Upgrades to new Policy Lifecycle API; 5G / OOF SON Enhancement;

 

o   S3P – Other Security requirements

o   End to End Layer 1 Service Management. Modeling the Optical Service

o   Modeling: 5G / ORAN & 3GPP Standards Harmonization

o   5G / 5G NRM Network Resource Model (Configuration Mgmt)

o   CMPv2 CA Plugin for AAF

o   5G / Run-time data persistency (RunTime DB / CM): VES Model relations, VES CM model (CM Notify)

o   Integration of CDS as Actor in Control Loops

o   K8s CDS Support

o   Portal Technology Stack Upgrade and New reporting features

o   CLAMP Deployment of Policies to PDP Groups

o   K8s Security and traffic controller

o   K8s HPA Support

 

These requirements will be descoped from the Frankfurt official release if the PTLs can not confirm they can commit first to their RANK0-2

and then these can be pursued as POC in alignment with our POC definition.

 

Candidates to Rank #4 (NO GO-descoped or POC)

 

These requirements were provided post Sept 27th (deadline to submit use case/requirements) and require code change.

Some of them are even not yet reviewed by the ONAP Architecture subcommittee.

These requirements will be therefore descoped from the Frankfurt official release and can be pursued as POC in alignment with our POC definition.

 

Modeling: GeoLocation Model (and standards harmonization)

5G / Bulk PM / Secure Communication between xNFs and ONAP

PNF / Plug and Play

PNF / Configuration with NETCONF/ Secure Communication between xNFs and ONAP

VSP Compliance and Validation Check within SDC  - Phase 2

OVP Testing and Certification Support Within SDC

 

These requirements were not approved by the Architecture Team and/or missing information to provide TSC prioritization

These requirements will be therefore be descoped from the Frankfurt official release and can be pursued as POC in alignment with our POC definition.

 

·        Service Resolver Features

·        Deployed distributed external functions

 

Require further decisions/discussions

#1 I do not know what to suggest regarding “Network Slicing”.

I have not been closely engaged but I have not a good feeling that we know what we want to develop as part of Frankfurt versus the whole multi-release development

We need to avoid several architecture/Solution implementing the same requirement

Shall we just commit for a concrete design/POC then move to the implementation as part of Guilin?

Shall we deep dive it during the next TSC call and then decide?

·        Network Slicing

·        Modeling: Enhanced Nested and Shared Service Information Model - 5G / E2E Network Slicing modeling

 

#2 ETSI Alignment – No Commitment from any company, no feedback from PTL

 

#3 Control Loop tutorial Documentation – shall we consider it as RANK1-TSC Must have – today no resource confirmed any company

 

Best regards

Catherine

 

Catherine Lefèvre

AVP Software Development & Engineering

 

AT&T Labs – Network Cloud and SDN Platform Integration

SDN Platform & Systems

ECOMP/RUBY/SPP-NEAM-Appl. Servers/SIA

ONAP TSC Chair

 

 

Phone: +32 81 84 09 08

Mobile: +32 475 77 36 73

catherine.lefevre@...

 

TEXTING and DRIVING… It Can Wait

AT&T

BUROGEST OFFICE PARK SA

Avenue des Dessus-de-Lives, 2

5101 Loyers (Namur)

Belgium

 

 

NOTE: This email (or its attachments) contains information belonging to the sender, which may be confidential. proprietary and/or legally privileged. The information is intended only for the use of the individual(s) or entity(ies) named above. If you are not the intended recipient, you are hereby notified that any disclosure, distribution or taking of any action in reliance on the content of this is strictly forbidden. If you have received this e-mail in error please immediately notify the sender identified above

 


Srini
 

Hi Catherine,

 

On “Deployment of  distributed external functions”:  It went through the architecture review and I have taken all the changes suggested by the team.  It is GO in my view, but I like Steve to endorse it 😊.

 

Thanks
Srini

 

 

From: onap-tsc-private@... <onap-tsc-private@...> On Behalf Of Catherine LEFEVRE
Sent: Monday, October 28, 2019 11:10 AM
To: onap-tsc-private@...; onap-tsc-vote@...
Subject: [onap-tsc-private] URGENT - TSC Frankfurt Prioritization - Time to decide (10/28)
Importance: High

 

Good morning/afternoon/evening TSC Members  (or proxies),

 

Please find an update regarding the last review performed about TSC Frankfurt Prioritization and based on latest ONAP Community’s feedback.

I have also created a wiki page that will give a view of Code impact per component https://wiki.onap.org/display/DW/Frankfurt+Code+Impact+View+per+Component

 

Please provide your feedback no later than Tuesday, Oct 29th EOD

We really need to conclude on TSC prioritization asap – thanks

If no feedback received then I will publish the TSC prioritization as suggested below by Wednesday, Oct 30th, 2019

Your voice really matters so please raise it now – thank you !!

I am also sending this e-mail to tsc-vote in case you did not see my previous tsc-private e-mails related to Frankfurt prioritization.

 

I have also attached the spreadsheet for additional details.

 

  • RANK #0  – Special GO - fully covered by involved companies
  • RANK #1  – GO “Must Have”
  • RANK #2 - GO “Continuity of previous releases”
  • RANK #3 – GO if PTLs are OK since the impacted applications are less “stretched”
  • RANK #4 – NO GO – Mostly new requirements/features/projects

 

It means

RANK0-2 – these will be our initial Frankfurt if PTLs (including Integration confirmed they have the right level of details, developers and testers)

RANK3 – Only possible if PTLs are getting additional resources vs #Committers that can review the submitted code

RANK4 - Descoped

 

Candidates to Rank #0 (Special Go)

  • Documentation/Modeling Impact Only – No DEV/TEST Impact
    • Modeling: documentation of policy and allotted resource model
    • 5G / 5G Service Modeling: Modeling (exploratory) work for creating a 5G Service
    • Modeling: Runtime instance model based on A&AI reverse engineering
    • Architecture - Modeling Alignment
    • 5G / License Management

 

  • Small change and can bring adoption
    • 3rd party Operational Domain Manager

 

Candidates to RANK 1- TSC Must have

Companies who are developing use cases/requirements for a specific component must also help PTL to meet “TSC MUST Have”

  • Remove Python2 dependencies
  • Waivers granted in El-Alto should be resolved in Frankfurt
  • Portal Security Enhancements
  • S3P Maturity Improvements  - Need Jason/Pawal to confirm S3P MUST HAVE
    • Document current upgrade component upgrade strategy
    • SECCOM Perform Software Composition Analysis - Vulnerability tables
    • SECCOM Password removal from OOM HELM charts
    • SECCOM HTTPS communication vs. HTTP

 

 

Candidates to RANK 2- Continuity

  • CCVPN:E-LINE Service over OTN NNI
  • Policy Update Notifications
  • Self Serve Control Loops
  • All Control Loop Policy Models should be TOSCA Compliant
  • 5G / Bulk PM / PM Control
  • PNF / PNF pre-onboarding onboarding
  • 5G / OOF SON Enhancement
  • PNF / PNF Software Upgrade using direct Netconf/Yang interface with PNF
  • Component Upgrades to new Policy Lifecycle API
  • Multicloud K8s Support (Continuation from R4)
  • PNF / Enhancement on PNF Software Upgrade with EM with Ansible
  • Scaling Extensions
  • PNF / Enable Schema Update once PNF software is updated
  • 5G / PM dictionary
  • PNF / PNF Software Upgrade with EM with Netconf
  • Change Management: APPC Ansible automation with VNF-C LCM support / CHM
  • Change Management: vFW Traffic Distribution with Software Upgrade / CHM

 

 

Depending on PTL bandwidth

 

Candidates to Rank #3

Only possible if PTLs are getting additional resources vs #Committers that can review the submitted code

Let’s take an example – “End to End Layer 1 Service Management. Modeling the Optical Service

This use case is impacting AAI, UUI, SDNC, SO – code impact

               This use case can only be implemented if the 4 components are able to deliver their RANK0-2 i.e

  • AAI – CCVPN-E; Modeling: Enhanced Nested and Shared Service Information Model - 5G / E2E Network Slicing modeling;
  • SO - End to End Layer 1 Service Management. Modeling the Optical Service
  • UUI - CCVPN-E; End to End Layer 1 Service Management. Modeling the Optical Service
  • SDNC - CCVPN-E; End to End Layer 1 Service Management. Modeling the Optical Service;Component Upgrades to new Policy Lifecycle API; 5G / OOF SON Enhancement;

 

  • S3P – Other Security requirements
  • End to End Layer 1 Service Management. Modeling the Optical Service
  • Modeling: 5G / ORAN & 3GPP Standards Harmonization
  • 5G / 5G NRM Network Resource Model (Configuration Mgmt)
  • CMPv2 CA Plugin for AAF
  • 5G / Run-time data persistency (RunTime DB / CM): VES Model relations, VES CM model (CM Notify)
  • Integration of CDS as Actor in Control Loops
  • K8s CDS Support
  • Portal Technology Stack Upgrade and New reporting features
  • CLAMP Deployment of Policies to PDP Groups
  • K8s Security and traffic controller
  • K8s HPA Support

 

These requirements will be descoped from the Frankfurt official release if the PTLs can not confirm they can commit first to their RANK0-2

and then these can be pursued as POC in alignment with our POC definition.

 

Candidates to Rank #4 (NO GO-descoped or POC)

 

These requirements were provided post Sept 27th (deadline to submit use case/requirements) and require code change.

Some of them are even not yet reviewed by the ONAP Architecture subcommittee.

These requirements will be therefore descoped from the Frankfurt official release and can be pursued as POC in alignment with our POC definition.

 

Modeling: GeoLocation Model (and standards harmonization)

5G / Bulk PM / Secure Communication between xNFs and ONAP

PNF / Plug and Play

PNF / Configuration with NETCONF/ Secure Communication between xNFs and ONAP

VSP Compliance and Validation Check within SDC  - Phase 2

OVP Testing and Certification Support Within SDC

 

These requirements were not approved by the Architecture Team and/or missing information to provide TSC prioritization

These requirements will be therefore be descoped from the Frankfurt official release and can be pursued as POC in alignment with our POC definition.

 

  • Service Resolver Features
  • Deployed distributed external functions

 

Require further decisions/discussions

#1 I do not know what to suggest regarding “Network Slicing”.

I have not been closely engaged but I have not a good feeling that we know what we want to develop as part of Frankfurt versus the whole multi-release development

We need to avoid several architecture/Solution implementing the same requirement

Shall we just commit for a concrete design/POC then move to the implementation as part of Guilin?

Shall we deep dive it during the next TSC call and then decide?

  • Network Slicing
  • Modeling: Enhanced Nested and Shared Service Information Model - 5G / E2E Network Slicing modeling

 

#2 ETSI Alignment – No Commitment from any company, no feedback from PTL

 

#3 Control Loop tutorial Documentation – shall we consider it as RANK1-TSC Must have – today no resource confirmed any company

 

Best regards

Catherine

 

Catherine Lefèvre

AVP Software Development & Engineering

 

AT&T Labs – Network Cloud and SDN Platform Integration

SDN Platform & Systems

ECOMP/RUBY/SPP-NEAM-Appl. Servers/SIA

ONAP TSC Chair

 

 

Phone: +32 81 84 09 08

Mobile: +32 475 77 36 73

catherine.lefevre@...

 

TEXTING and DRIVING… It Can Wait

AT&T

BUROGEST OFFICE PARK SA

Avenue des Dessus-de-Lives, 2

5101 Loyers (Namur)

Belgium

 

 

NOTE: This email (or its attachments) contains information belonging to the sender, which may be confidential. proprietary and/or legally privileged. The information is intended only for the use of the individual(s) or entity(ies) named above. If you are not the intended recipient, you are hereby notified that any disclosure, distribution or taking of any action in reliance on the content of this is strictly forbidden. If you have received this e-mail in error please immediately notify the sender identified above

 


Catherine LEFEVRE
 

Thanks Srini for your feedback. The centralized wiki was still highlighting it as pink i.e. Archi No Go

 

Could you and Bin (who is also our MultiCloud) review the following reqs and confirm that you can deliver them?

 

We also need to be sure that Bin will be able to progress on TSC Must Have supported by the companies who are submitting MultiCloud use cases?

  • Remove Python2 dependencies
  • Waivers granted in El-Alto should be resolved in Frankfurt
  • Document current upgrade component upgrade strategy
  • SECCOM Perform Software Composition Analysis - Vulnerability tables
  • SECCOM Password removal from OOM HELM charts
  • SECCOM HTTPS communication vs. HTTP

 

Similar queries regarding TSC MUST HAVE will be asked to support the other PTLs

 

Best regards

Catherine

 

From: onap-tsc-vote@... [mailto:onap-tsc-vote@...] On Behalf Of Srini
Sent: Monday, October 28, 2019 9:36 PM
To: Lefevre, Catherine <catherine.lefevre@...>; onap-tsc-private@...; onap-tsc-vote@...
Subject: Re: [onap-tsc-vote] URGENT - TSC Frankfurt Prioritization - Time to decide (10/28)

 

Hi Catherine,

 

On “Deployment of  distributed external functions”:  It went through the architecture review and I have taken all the changes suggested by the team.  It is GO in my view, but I like Steve to endorse it 😊.

 

Thanks
Srini

 

 

From: onap-tsc-private@... <onap-tsc-private@...> On Behalf Of Catherine LEFEVRE
Sent: Monday, October 28, 2019 11:10 AM
To: onap-tsc-private@...; onap-tsc-vote@...
Subject: [onap-tsc-private] URGENT - TSC Frankfurt Prioritization - Time to decide (10/28)
Importance: High

 

Good morning/afternoon/evening TSC Members  (or proxies),

 

Please find an update regarding the last review performed about TSC Frankfurt Prioritization and based on latest ONAP Community’s feedback.

I have also created a wiki page that will give a view of Code impact per component https://wiki.onap.org/display/DW/Frankfurt+Code+Impact+View+per+Component

 

Please provide your feedback no later than Tuesday, Oct 29th EOD

We really need to conclude on TSC prioritization asap – thanks

If no feedback received then I will publish the TSC prioritization as suggested below by Wednesday, Oct 30th, 2019

Your voice really matters so please raise it now – thank you !!

I am also sending this e-mail to tsc-vote in case you did not see my previous tsc-private e-mails related to Frankfurt prioritization.

 

I have also attached the spreadsheet for additional details.

 

  • RANK #0  – Special GO - fully covered by involved companies
  • RANK #1  – GO “Must Have”
  • RANK #2 - GO “Continuity of previous releases”
  • RANK #3 – GO if PTLs are OK since the impacted applications are less “stretched”
  • RANK #4 – NO GO – Mostly new requirements/features/projects

 

It means

RANK0-2 – these will be our initial Frankfurt if PTLs (including Integration confirmed they have the right level of details, developers and testers)

RANK3 – Only possible if PTLs are getting additional resources vs #Committers that can review the submitted code

RANK4 - Descoped

 

Candidates to Rank #0 (Special Go)

  • Documentation/Modeling Impact Only – No DEV/TEST Impact
    • Modeling: documentation of policy and allotted resource model
    • 5G / 5G Service Modeling: Modeling (exploratory) work for creating a 5G Service
    • Modeling: Runtime instance model based on A&AI reverse engineering
    • Architecture - Modeling Alignment
    • 5G / License Management

 

  • Small change and can bring adoption
    • 3rd party Operational Domain Manager

 

Candidates to RANK 1- TSC Must have

Companies who are developing use cases/requirements for a specific component must also help PTL to meet “TSC MUST Have”

  • Remove Python2 dependencies
  • Waivers granted in El-Alto should be resolved in Frankfurt
  • Portal Security Enhancements
  • S3P Maturity Improvements  - Need Jason/Pawal to confirm S3P MUST HAVE
    • Document current upgrade component upgrade strategy
    • SECCOM Perform Software Composition Analysis - Vulnerability tables
    • SECCOM Password removal from OOM HELM charts
    • SECCOM HTTPS communication vs. HTTP

 

 

Candidates to RANK 2- Continuity

  • CCVPN:E-LINE Service over OTN NNI
  • Policy Update Notifications
  • Self Serve Control Loops
  • All Control Loop Policy Models should be TOSCA Compliant
  • 5G / Bulk PM / PM Control
  • PNF / PNF pre-onboarding onboarding
  • 5G / OOF SON Enhancement
  • PNF / PNF Software Upgrade using direct Netconf/Yang interface with PNF
  • Component Upgrades to new Policy Lifecycle API
  • Multicloud K8s Support (Continuation from R4)
  • PNF / Enhancement on PNF Software Upgrade with EM with Ansible
  • Scaling Extensions
  • PNF / Enable Schema Update once PNF software is updated
  • 5G / PM dictionary
  • PNF / PNF Software Upgrade with EM with Netconf
  • Change Management: APPC Ansible automation with VNF-C LCM support / CHM
  • Change Management: vFW Traffic Distribution with Software Upgrade / CHM

 

 

Depending on PTL bandwidth

 

Candidates to Rank #3

Only possible if PTLs are getting additional resources vs #Committers that can review the submitted code

Let’s take an example – “End to End Layer 1 Service Management. Modeling the Optical Service

This use case is impacting AAI, UUI, SDNC, SO – code impact

               This use case can only be implemented if the 4 components are able to deliver their RANK0-2 i.e

o   AAI – CCVPN-E; Modeling: Enhanced Nested and Shared Service Information Model - 5G / E2E Network Slicing modeling;

o   SO - End to End Layer 1 Service Management. Modeling the Optical Service

o   UUI - CCVPN-E; End to End Layer 1 Service Management. Modeling the Optical Service

o   SDNC - CCVPN-E; End to End Layer 1 Service Management. Modeling the Optical Service;Component Upgrades to new Policy Lifecycle API; 5G / OOF SON Enhancement;

 

  • S3P – Other Security requirements
  • End to End Layer 1 Service Management. Modeling the Optical Service
  • Modeling: 5G / ORAN & 3GPP Standards Harmonization
  • 5G / 5G NRM Network Resource Model (Configuration Mgmt)
  • CMPv2 CA Plugin for AAF
  • 5G / Run-time data persistency (RunTime DB / CM): VES Model relations, VES CM model (CM Notify)
  • Integration of CDS as Actor in Control Loops
  • K8s CDS Support
  • Portal Technology Stack Upgrade and New reporting features
  • CLAMP Deployment of Policies to PDP Groups
  • K8s Security and traffic controller
  • K8s HPA Support

 

These requirements will be descoped from the Frankfurt official release if the PTLs can not confirm they can commit first to their RANK0-2

and then these can be pursued as POC in alignment with our POC definition.

 

Candidates to Rank #4 (NO GO-descoped or POC)

 

These requirements were provided post Sept 27th (deadline to submit use case/requirements) and require code change.

Some of them are even not yet reviewed by the ONAP Architecture subcommittee.

These requirements will be therefore descoped from the Frankfurt official release and can be pursued as POC in alignment with our POC definition.

 

Modeling: GeoLocation Model (and standards harmonization)

5G / Bulk PM / Secure Communication between xNFs and ONAP

PNF / Plug and Play

PNF / Configuration with NETCONF/ Secure Communication between xNFs and ONAP

VSP Compliance and Validation Check within SDC  - Phase 2

OVP Testing and Certification Support Within SDC

 

These requirements were not approved by the Architecture Team and/or missing information to provide TSC prioritization

These requirements will be therefore be descoped from the Frankfurt official release and can be pursued as POC in alignment with our POC definition.

 

  • Service Resolver Features
  • Deployed distributed external functions

 

Require further decisions/discussions

#1 I do not know what to suggest regarding “Network Slicing”.

I have not been closely engaged but I have not a good feeling that we know what we want to develop as part of Frankfurt versus the whole multi-release development

We need to avoid several architecture/Solution implementing the same requirement

Shall we just commit for a concrete design/POC then move to the implementation as part of Guilin?

Shall we deep dive it during the next TSC call and then decide?

  • Network Slicing
  • Modeling: Enhanced Nested and Shared Service Information Model - 5G / E2E Network Slicing modeling

 

#2 ETSI Alignment – No Commitment from any company, no feedback from PTL

 

#3 Control Loop tutorial Documentation – shall we consider it as RANK1-TSC Must have – today no resource confirmed any company

 

Best regards

Catherine

 

Catherine Lefèvre

AVP Software Development & Engineering

 

AT&T Labs – Network Cloud and SDN Platform Integration

SDN Platform & Systems

ECOMP/RUBY/SPP-NEAM-Appl. Servers/SIA

ONAP TSC Chair

 

 

Phone: +32 81 84 09 08

Mobile: +32 475 77 36 73

catherine.lefevre@...

 

TEXTING and DRIVING… It Can Wait

AT&T

BUROGEST OFFICE PARK SA

Avenue des Dessus-de-Lives, 2

5101 Loyers (Namur)

Belgium

 

 

NOTE: This email (or its attachments) contains information belonging to the sender, which may be confidential. proprietary and/or legally privileged. The information is intended only for the use of the individual(s) or entity(ies) named above. If you are not the intended recipient, you are hereby notified that any disclosure, distribution or taking of any action in reliance on the content of this is strictly forbidden. If you have received this e-mail in error please immediately notify the sender identified above