Association between NST and NSST shall be fixed at design time. In other words, an NST shall be composed of a set of NSSTs at design time.
As a result of (1), the AllocateNSSI API shall contain NSST info. This shall be re-visited beyond Guilin.
If the NSSMF is not capable of NSSI selection, ONAP acting as NSMF shall perform NSSI selection also and then pass the NSSI info in the AllocateNSSI API. This situation shall arise only when connecting to an external NSSMF, as all NSSMFs within ONAP shall support NSSI selection.

2. Common NSSMF

The API from NSMF towards NSSMF shall be based on 3GPP APIs with the following exceptions:
1. NSST id shall be passed in the AllocateNSSI API if the NSSMF is capable of NSSI selection. This is due to assumption (1) in "Common Aspects" - see above.
2. NSSI id shall be passed in the AllocateNSSI API if the NSSMF is not capable of NSSI selection. This is to enable interoperability with external NSSMFs that aren't capable of NSSI selection (so ONAP acting as NSMF shall also do NSSI selection).

3. Core Slicing

No impact is foreseen for Closed Loop or Intelligent Slicing for updating the configuration of the core NSSI.

RAN NFs are assumed to be instantiated apriori. So in case of RAN NSSI creation, the step involving RAN NF instantiation shall be skipped.

...

No trigger for KPI monitoring shall be sent from SO or other micro-services in DCAE. The KPIs to be computed by PM Handler MS shall be configured via Policy, and the NSI/NSSI for which the KPIs shall be computed shall be determined by accessing AAI before the computation.
It is assumed that the NFs already "know" which PM data should be reported to ONAP.

Any resource re-allocation for slice resource optimization shall be computed based on rules by SDN-R for the RAN (without involving OOF).

The training shall happen outside ONAP, and the ML models shall be onboarded as an MS in DCAE. This MS shall not be part of ONAP repos, and shall be used only for PoCs/demos.