Operating System: All
Platform: All

Adding initial design notes:

MDSAL - Netconf northbound ifc

Tasks:
1. Implement Netconf -> Md-sal mapper
a. Implement base netconf ops
a1. Implement get and get-config (complex subtree filtering required)
I suggest splitting this into several pieces:
1.get and get-config – whole tree – simplest one
2. simple subtree filter – XML to instance identifier
3. advanced filtering (maybe not Lithium, will require additional design).

a2. Implement edit config (same functionality as restconf patch required)
a2.1. Commit/Discard-changes rpcs not an issue.
a3. Lock/Unlock should not be an issue since this will be only candidate (no writable-running) and each client would get isolated transactions.
a4. Validate + test option in edit-config.
Will require better analysis how to hook up into MD-SAL lifecycle or small API changes.
a5. Copy-config/Delete-config not supported most likely.
Probably not in lithium

2. Implement Netconf monitoring
a. Entire monitoring could be reused from netconf->config-subsystem monitoring
This will require design to reuse common monitoring parts for netconf-monitoring and
restconf-monitoring
Monitoring data should be stored in data broker – so you will be able to get restconf state
via netconf and vice-versa.

3. Implement notification support in netconf-impl
a. Notification supports is not present at all. This requires changes of the SPIs and possibly APIs of netconf.

Problems:
1. Dynamic nature of DomDataBroker. THe broker gets auto-updated after every schemaContext change, the netconf server will need to auto update as well. Current netconf clients do not really support dynamic netconf servers(servers that change the yang schemas) ? However once the ODL is up and running, the incomming clients would not experience the dynamic nature, since the controller will not change its features much.

2. Invoking get rpc should return both config and operational data in one response. Does read from DomDataBroker return both the data ? Or will we need to merge both of them ? In that case, could we experience inconsistencies between operational and config due to 2 separated reads ?

It is application responsibility to synchronize config / operational data tree (for now).

3. How to read candidate ? It means reading the transaction opened for client that is performing an edit-config operation. Is this possible somehow ?

Read from allocated MD-SAL transaction to particular client

4. How to perform validation/testing of a transaction before its commitment ?

Need to be analysed.

Initial implementation of MD-SAL netconf northbound was merged into master branch