Page Comparison

We were asked to fulfill our non functional requirements on this wiki.

Jira Epics to be started for each project.

Deadline is 27th of May

1)

SECCOM-136

ONAP MUST support the creation of multiple unique IDs so that individual accountability can be supported.

For our point of view must be:

ONAP MUST support the creation of multiple unique IDs so that individual accountability is supported.

2)

Due to lack of any requirement around the Traceability

New requirement propsoed

ONAP MUST associate each action to a responsible user and logged in order to be exported to an external component (e.g. Syslog, SIEM/SOC, etc.)

to be reviewed by Fabian.

OOM requirements for Guilin - follow-up discussion with Sylvain

AAF is optional  - this was the intention. Bell Canada does not want to have AAF inegrated in their setup. RBAC and https should be possible to disable it - based on Sylvain's point of view.

Consultation on AAF approach with Architecture Subcommittee was not done and we think it should be.

Why Bell Canada does not address their need with TSC?

TSC logging presentation – discussion point

20_04_30_ONAPLoggingGuilin_V1.pptx

We agreed we need to bring it to the Architecture Subcommittee. ONAP component retirement and replacement still requires discusssion at the TSC level.

Logging is not just a collection of logs but also analysis and the retention.

FluentD - we need to check if full logging needs could be fulfilled.  

2 next steps:

-Understand logging and upgrade path to Java 11. In order to move forward, we have to identify logging project representative.

-Consider open source projects as equivalent for logging and impact on other ONAP projects - we would need a proxy/representative for logging open source.

VErsions required are inline with SECCOM recommendations.

As the AAF usage (or rather not using it at all) statement seems to collect different points of view, Sylvain proposal was shared with SECCOM distribution list, so we could conclude the discussion at the next SECCOM (on 12th of May). 

Rephrase proposal: for the purpose of using an alternative solution to AAF, whatever this solution would be.

OOM requirements are acceptance criteria for submitted patches and shall be know to the ONAP projects in advance - before Guilin release: for example if patch  would require root access to DB - it would be rejected as it would be not compliant with OOM requirement for Guilin release.

We we speak about an external https - in the future this feature will be used and deployed and feature will be used with ingress that is why we don't want to use https for an external communication for each component we need it. For Kubernetes we just need to deploy ingress feature. And we already have ingress in the source code (it came with F release). For now we are doing SSL redirect , if service support https. It is also a valid deployment option if you do SSL termination at the ingress gateway, not at the component. 

Internal request - if you use in the future service mesh, we do not want to have double https and mTLS in the same way but only one point to manage certification. In this case sidecar will be managing TLS  

have consistent requirements with OOM team ones, although the ability to turn off security is a bit odd for SECCOM.

We still do not know if AAF has a new PTL.

We should have documentation on how to deploy certificates with AAF Certman and without it.

Service mesh POC should answer some questions.

AAF inegration effort to be checked with PTLs.

We should have LoE estimation for those few projects on service mesh integration. 

To check with Sylvain if we can retrieve information valid for us. For DCAE external communication is already done.

Other external communication types to be identified.