adetalhouet do I understand correctly 3. to mean that effectively you'd like to see a stream of updates to a particular Kafka topic being delivered whenever a YangInstanceIdentifier changes?

Yes, but this is, at this point, the least important part of the feature.

The key of this really to have the ability to load yang in the system at runtime  and have restconf binding auto-generated with APIs for that yang being exposed.

Yes, so essentially you would be using this as a REST-accessible external datastore to some other system, right?

Yes, exactly.

Right. So I think we do have all the building blocks needed, it's just a matter of some quality LEGO time.

That's what I think as well. I'll be glad to help assembling LEGO if needed. If you have pointers/ideas on how to do, I can work on it.

Thank you for considering the feature, I believe this will be a great addition to ODL.

Changed to epic, as this really is a project-scoped thing, i.e. it has a RESTCONF dependency, but it's not something we want to co-install with other features except our dependencies.

One thing to consider: should the management (add/remove models) and access (get/put) have different endpoints?

> this really is a project-scoped thing

Right, I was initially thinking MDSAL providing this feature, but I don't know if MDSAL could have dependency on RESTCONF, given the dependency tree. But with these projects having their own release lifecycle, maybe it is acceptable..

> One thing to consider: should the management (add/remove models) and access (get/put) have different endpoints?

Yes, I envision management API/contract having its own model, defining a container having a list with revision-date and namespace as keys. That model could have RPCs for add/remove models, but this could be redundant with get/put to the list.

For data access, I was thinking of using RESTCONF RFC standard following the same pattern as other YANGs already exposed by ODL.

adetalhouet so on the datastore semantics: do you just need running (implied stored), or running without persistence, or also operational?

In NMDA-speak:

• do you need to manipulate 'intended'?
• if so, is 'intended' all you care about?

I was thinking having configuration and operational datastores, so the external system can track state accordingly.

I'm not familiar with the NMDA terminology, but it seems
The intended configuration datastore (<intended>) is a read-only configuration datastore
hence I'm not sure that is the expectation, as the point would be to have external system able to write to the datastore.

Not only that, <intended> is not persisted and derived from <running> plus-whatever-implementation-specific.

At any rate, if you are looking for operational, you are in violation of RFC8040 (which boils down to running-only), so you need NMDA as well.

That opens up a bit of a question: to what extent do you need the validated? Should we go for 'config=true, paranoid' or are there things we can rely on the user to do?

Forgot to explicitly call out: do you expect persistence guarantees? (assuming here that you'd run a container-per-datastore model here)

I'm not familiar with these things. Basically, datastore semantics doesn't need to be anything different than what ODL has to offer today. Likewise for the persistence, as there are already mechanisms to backup&restore and persist datastore today.