[NETCONF-1015] Define a netconf-api capability model Created: 04/May/23 Updated: 08/Nov/23 |
|
| Status: | In Review |
| Project: | netconf |
| Component/s: | netconf |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Low |
| Reporter: | Robert Varga | Assignee: | Yaroslav Lastivka |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | pick-next, pt | ||
| Σ Remaining Estimate: | Not Specified | Remaining Estimate: | Not Specified |
| Σ Time Spent: | Not Specified | Time Spent: | Not Specified |
| Σ Original Estimate: | Not Specified | Original Estimate: | Not Specified |
| Sub-Tasks: |
|
| Description |
|
Our current model of how capabilities are known is rather flawed, with constants being defined/used left and right – without a reasonable basic model behind them. Create a netconf.api.capabilities.ProtocolCapability enum and populate it with the current contents of https://www.iana.org/assignments/netconf-capability-urns/netconf-capability-urns.xhtml#netconf-capability-urns-1 . This enumeration should expose this basic interface: enum ProtocolCapability { WRITABLE_RUNNING(":writable-running", "urn:ietf:params:netconf:capability:writable-running:1.0"), ...; public @NonNull String capabilityName() { // returns ":writable-running" } public @NonNull String capabilityURN() { // returns "urn:ietf:params:netconf:capability:writable-running:1.0" } } Also create a companion ProtocolCapabilityURN static holder class for the individual URN strings and migrate constants. |
| Comments |
| Comment by Robert Varga [ 05/May/23 ] |
|
So this proposal will not quite work, as capabilities encode various things in their URIs. That implies we need a proper object model, for some of them – and hence is a bigger undertaking. Current contents are only used on server-side, so we can vacate that should do that first. |