•  9 non functional requirements have been prioritized up to now by the ONAP TSC for Guilin, requesting support from companies who are submitting usecase/functional reqs. How can we implement additional non functional requirements?
• Partial solution will also been discussed as a Cross-Community topic at 2.30pm UTC on Monday June 22nd, 2020- Help Recruit more Developers to LFN Projects! 
• Architecture Component Views in Readthedocs planned on Wednesday June 24th, 2020 at 3pm UTC to align with swagger work

• PTLs/Non functional reqs Owners on PTL call (6/29) to assess what can we agree with the project teams for Guilin either as additional TSC MUST Have and/or CI-Gating, etc.

Details regarding Non functional requirements REQ-379, REQ-380  - https://wiki.onap.org/display/DW/License+compliance

The list of "Base Image statistics" can be enhanced as long as the ONAP Community will maintain it.

•  Organize a TSC vote on the list of licenses that can be used within ONAP containers i.e. approved licenses means which once we agree to comply with, in terms of license terms for distribution in docker containers
• PTLs to confirm the comments in Green regarding "Upstream dockers in ONAP Nexus Server" section
• Define a list of approved base images
• Do the license compliance process for all approved base images
• Make sure that all components use only approved base images

• PTLs/Integration on PTL call (6/29) to discuss how to release more often prior M4 (conditions, regression and healcheck ok, rollback procedure, etc.)

Reviewed current modeling activities and candidate modeling requirements for Guilin.

The following topics were also presented:

1 Modeling process

2 Policy model

3 Slicing model

4 CNF Inventory Modeling 

5 CNF ETSI modeling overview

6 Modeling of Geolocation information

Recording may be found at: LNF_June_vDTF-ONAP-_Modeling_Subcommittee.mp4

• The former Policy architecture will be deprecated in order to embrace the new Self-Serve Policy Architecture developed from Dublin to Frankfurt.
• Presentation of the major Policy Guilin requirements including E2E Network Slicing, 5G OOF SON and improvements
• Policy team is in the process of creating Tutorials for the ONAP community to view to understand how to use the Policy Platform

• Any volunteer to flesh out these ideas
• How to implement in each LFN Open Community?

›How can we release more frequently, smaller scope without impacting the SW quality?

›How can we change the waterfall-ish development model?

›How can we get enough details about candidates requirements prior the release?

›How to manage the release in case of people turn-over?

›How to handle the scope and maintain a balance between Usecase/Functional reqs (attractive) and Non functional reqs (less sexy)?

•  Identify a set of projects that could prototype the Release Train approach

•  “Release cadence transition proposal” on June 25th, 2020 @ 11am UTC

•  Alignment with CNTT/CNCF TUG and O-RAN/ONAP in order to define their role as part of XGVela and identify what can be leveraged from the existing projects
• Introduction of XGVela to the TAC team

Track: Cloud Native in Telecom Cloud

Presenters/Moderators: Qihui Zhao, Ying Li

• Alignment with CNTT/CNCF TUG and O-RAN/ONAP in order to define their role as part of XGVela and identify what can be leveraged from the existing projects
• Introduction of XGVela to the TAC team

OOM Status update: what's planned internally

Presenters/Moderators: Sylvain Desbureaux, Krzysztof Opasiak

Review of the planned OOM changes :

Support of Helm V3

Kubernetes V1.17 (or 1.18)

Migrate to Seccom recommended Versions

Update defaults (use Ingress, Storage Class, Hardened OS)

OOM Status update: consequences on other components

Presenters/Moderators: Sylvain Desbureaux, Krzysztof Opasiak

Review of the required changes on components helm charts VS requirements

presentation of changes, use of templates, adding appender to Logback to support STDOUT as additional output

Container that do not contain ONAP code should not be hosted on Nexus

No Root access to DB

Application config should be fully prepared before starting the container

Containers must crash properly when a failure occurs

No more Nodeports

AAF optional (component should work without AAF even in degraded mode)

HTTPS is mandatory but should be configurable (disable in case of Service Mesh as this will be offloaded to Service Mesh)

Container RootFS should be mounted as ReadOnly

Commit message rules for OOM

Requirements Traceability:  Initial Request through TSC Approval

Presenters/Moderators: Alla Goldner, Chaker Al-Hakim, Pawel Pawlak, Pamela Dragosh, David McBride, Catherine Lefevre

• Enhance the mission of the Requirements Subcommittee:
  
  • Act as the ONAP Product Owners 
  • Recommend Prioritization to the TSC
  • Create the consolidated ONAP Backlog

wiki: 2020 June vDTF ONAP Requirements Traceability: Initial Request through TSC Approval

• How can we streamline the requirements coming from different sources inside and outside from the ONAP Community?
• As an example, EUAG → REq Subcommittee prioritirised → (Architecture Review) → TSC 

• Great Discussion around performance and it's relation to CNTT.
• Discussion to be continued with Al Morton, Trevor, and Mike B during CVC using Al proposed 4-tier structure.

• Continue discussion in CVC.
• Map 4-tier structure to CNTT.

• Interesting and detailed presentation by Ying Li and Shasha Guo of SDN implementations for several use cases like Traffic Mirroring and Routing Configuration, showing code snipets, network diagrams and parameter mappings