Description
TL;DR
Add support for the ietf-yang-library YANG module (RFC 8525), which exposes module sets, datastore schemas, and datastore-to-schema mappings via NMDA-compliant /yang-library. Obsoletes RFC 7895's flat /modules-state tree.
Why
- Standard, protocol-agnostic way for NETCONF/RESTCONF clients to discover which modules/features/deviations a server implements per datastore, instead of scraping
<hello> capabilities or vendor docs.
- NMDA-aware: lets
<operational> expose a superset schema (e.g. hardware/state-only modules) without those modules being configurable in <running>/<startup>.
content-id + yang-library-update notification give clients a cheap cache-invalidation signal instead of re-fetching the whole tree.
Current state
sysrepo/libyang implement ietf-yang-library; need to confirm what netopeer2/rousette expose by default and whether Infix's module set already lines up with NMDA datastore boundaries (running, startup, operational) or still reflects the old flat model.
Scope
- Verify
sysrepo_shm/libyang populate /yang-library/module-set, /schema, /datastore correctly for Infix's actual datastore split.
- Confirm
content-id changes on module (re)load and that yang-library-update notification fires — check RAUC upgrade / confd-reload paths in particular, since content-id must change across a reboot if the module set differs.
- Decide whether to populate deprecated
/modules-state for legacy client compat (RFC 8525 §1 recommends SHOULD).
- Add to CI: a qeneth-based test that fetches
/yang-library over NETCONF and diffs content-id before/after a module load/unload.
Open questions
- Do we need more than one
module-set/schema split (e.g. separate schema for <operational> vendor-hardware deviations), or is a single flat module-set sufficient for Infix's current model set?
- RESTCONF (rousette) exposure — same data, does it need any RESTCONF-specific path handling?
References
Additional Information
No response
General Information
Anyone can help out by sponsoring development of new features or contributing pull requests.
Please use this issue for discussions related to the feature.
Description
TL;DR
Add support for the
ietf-yang-libraryYANG module (RFC 8525), which exposes module sets, datastore schemas, and datastore-to-schema mappings via NMDA-compliant/yang-library. Obsoletes RFC 7895's flat/modules-statetree.Why
<hello>capabilities or vendor docs.<operational>expose a superset schema (e.g. hardware/state-only modules) without those modules being configurable in<running>/<startup>.content-id+yang-library-updatenotification give clients a cheap cache-invalidation signal instead of re-fetching the whole tree.Current state
sysrepo/libyang implement
ietf-yang-library; need to confirm what netopeer2/rousette expose by default and whether Infix's module set already lines up with NMDA datastore boundaries (running,startup,operational) or still reflects the old flat model.Scope
sysrepo_shm/libyang populate/yang-library/module-set,/schema,/datastorecorrectly for Infix's actual datastore split.content-idchanges on module (re)load and thatyang-library-updatenotification fires — check RAUC upgrade / confd-reload paths in particular, since content-id must change across a reboot if the module set differs./modules-statefor legacy client compat (RFC 8525 §1 recommends SHOULD)./yang-libraryover NETCONF and diffscontent-idbefore/after a module load/unload.Open questions
module-set/schemasplit (e.g. separate schema for<operational>vendor-hardware deviations), or is a single flat module-set sufficient for Infix's current model set?References
Additional Information
No response
General Information
Anyone can help out by sponsoring development of new features or contributing pull requests.
Please use this issue for discussions related to the feature.