[YANGTOOLS-765] yang-common: allow application-specific RpcErrors Created: 22/Mar/17 Updated: 19/Sep/23 |
|
| Status: | Confirmed |
| Project: | yangtools |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 14.0.0 |
| Type: | New Feature | Priority: | Highest |
| Reporter: | Robert Varga | Assignee: | Unassigned |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
Operating System: All |
||
| Issue Links: |
|
||||||||||||||||
| Epic Link: | Usable RpcError | ||||||||||||||||
| Description |
|
yang.common.RpcError does not model https://tools.ietf.org/html/rfc6241#section-4.3 correctly, specifically it misinterprets error-info as a String field, whereas the RFC defines it as a tag, which can be extended with richer content (https://tools.ietf.org/html/rfc6241#appendix-A, see ' error-tag: missing-attribute'). At least the cases covered in RFC6241 need to be covered, but there seems to be appetite to add more: https://lists.opendaylight.org/pipermail/yangtools-dev/2017-January/001730.html. We need to devise a way to channel this information in a way which will allow both XML and JSON encodings to work correctly. One way of achieving that would we to allow getInfo() to return a NormalizedNode structure, which would be allowed to only contain String leaves – but that is not possible due to this class being shared by both BI and BA applications. We may need to move RpcResult to its proper domain, i.e. have it defined in md-sal for both BA and BI interfaces and perform transcoding. |
| Comments |
| Comment by Vratko Polak [ 27/Sep/17 ] |
|
> does not model https://tools.ietf.org/html/rfc6241#section-4.3 Are there any gotchas which would prevent us writing a Yang model to define the allowed structure? |
| Comment by Robert Varga [ 21/Sep/20 ] |
|
Well, first of all the data is not instantiated in the tree, hence it requires either RFC8040 yang-data or RFC8791 structure extension. The second is that the namespace itself seems to be rooted in RFC6241. The third is that this needs to be correctly mapped across all the spaces. |
| Comment by Robert Varga [ 21/Sep/20 ] |
|
We need the parser to understand RFC8791 constructs. We then need to a yang-data-api binding for those, which could be as simple as ContainerNode. We then need to decide what to do with yang-common implications. Finally, we want the yang-{model,data}-api model of RpcError be mirrored in MD-SAL's DOM layer. We want to generate bindings from RFC8791 constructs and have those be present in errors. |