Note we also need to plan the (1) xApp adaptation effort and (2) adaptation effort in the xApp frameworks (RIC-725, RIC-726, RIC-727) related to this item and coordinate/inform other projects of needed work.

General principle: If config already in Redis, then take it from there (and ignore config map). If not, push config from ConfigMap into Redis and that is notified to NMS (network management system). This should be in line with O2 use case in WG1 document.

Included in this item:

1. a) xapp framework for go to handle initial config via configmap (newly deployed) , but also if config is already in SDL (restart case). There was also a proposal (2021-01-05) that the initial config is passed to xapp manager which then puts it (new) into SDL. But this 2021-01-05 approach would mean that we can't use the xapp framework for platform components (which we intend). So we stick with xapp framework updating SDL directly.
2. a2) note we have to do this as a bare minimum also for c++ and python frameworks to achieve the overall goal that all config is visible in SDL.
3. b) implement CM support for xapp framework for golang (see (c) for other languages)
4. c) not in Dawn or only if Samsung/ATT picks it up (see also item (h), on the why): xapp framework for py/c++ do the same . This means c++ or python xapps/platform components can only use initial configmap, and no updates, and their config not visible in SDL
5. d) xapp manager pushes yang model into O1 mediator and removes if xApp is undeployed
6. e) optional implementation: xapp framework could revalidate JSON obtained against same schema as O1 mediator already validates (all the same as the yang model
7. e2) NOT (YET): note that the initial config (=config map) is just placed into SDL, but we do not revalidate it against yang model at that time. Right now it will only be validated in DMS CLI.
8. f) NOT (YET): upgrade of yang models (not even parameter addition)
9. g) not relevant here
10. h) if xapp does not provide yang model, we implement things so that config comes as JSON file via configmap and we push to SDL (in-built into xapp framework), but we do not expose via O1 (this item is for backwards compatibility)
11. i) just a note: use (h) for xApps that do not want to spend time on dynamic config capabilities
12. j) for platform services (not xApps) we use the same way, i.e., components like sub mgr pushes the yang model to xapp manager's REST interface during the startup of submgr.
13. k) adapt one platform service to support dynamic config: one of (submgr, e2mgr, rtmgr)
14. l) Not yet: restful notifications as per O1 from O1 mediator to NMS (ONAP)
15. m) not yet: support for running vs startup vs candidate config
16. n) if you don't have ONAP, then you can also use a "netconf cli with parameters" (existing RIC impl. that is command-line argument driven vs open-src netconf-cli that is menu driven; both use same library).