...
Open Questions/Issues/Decisions
| Questions/Issues | Notes | Decisions |
|---|
- Are there any major advantages of using RFC 9144?
- Does it have major differences when compared to RFC6902?
- Can it be modified as per requirements of CPS? For example using xpath format
|
|
|
The documentation of RFC 9144 defines a POST operation to find the delta. - Does this mean this approach intends to persist the Delta generated to a database?
- If so will it be an indefinite persistence of delta report or will the delta be removed from storage after a specific time period.
| | Code Block |
|---|
| title | Sample POST request from RFC9144 |
|---|
| collapse | true |
|---|
| POST /restconf/operations/ietf-nmda-compare:compare HTTP/1.1
Host: example.com
Content-Type: application/yang-data+json
Accept: application/yang-data+json
{ "ietf-nmda-compare:input" : {
"source" : "ietf-datastores:operational",
"target" : "ietf-datastores:intended",
"report-origin" : null,
"xpath-filter" : "/ietf-interfaces:interfaces"
}
} |
|
|
The current approach that is being used for development of Delta feature in CPS is a GET operation with no intention to persist the delta report. It is meant to return the delta in following JSON format. |
| Code Block |
|---|
| title | Sample delta report format |
|---|
| collapse | true |
|---|
| [
{
"action": "ADD",
"xpath": "/bookstore/categories/[@code=3]",
"payload": {
"code": 3,
"name": "kidz"
}
},
{
"action": "DELETE",
"xpath": "/bookstore/categories/[@code=1]",
"payload": {
"code": 1,
"name": "Fiction"
}
},
{
"action": "UPDATE",
"xpath": "/bookstore/categories/[@code=2]",
"payload": {
"name": "Comic"
}
|
|
|
- RFC 9144 defines a yang data model which will be helpful when persisting the Delta Report,
- But if we go with the approach where the generated delta is not persisted then what will be the benefit of using the model?
| |
|
- Are we following any RFC specifications for PATCH operation?
| |
|
Intention of RFC 9144
RFC 9144 YANG data model that defines RPCs intended to be used in conjunction with NETCONF [RFC6241] or RESTCONF [RFC8040]. These RPCs allow a client to request a server to compare two NMDA datastores and report any differences.
...
- The core of the RFC 9144 solution is a new management operation, <compare>, that compares the data tree contents of two datastores. The operation checks whether there are any differences in values or in data nodes that are contained in either datastore and returns any differences as output. The output is returned in the format specified in YANG Patch [RFC8072].
- The RFC6902 approach to Delta report generation follows the JSON patch format. A JSON Patch document represents an array of objects, where each object contains exactly one operation, path and associated values. The operation can have following values: add, remove, replace, move, copy and test. The path represents the JSON patch and the values contain the difference in source and target values.
Brief summary of JSON patch can be found in the following page: CPS Delta: Conventions to be used for Delta Report
| Example Delta generated as part of RFC9144 | Example JSON Patch document, transferred in an HTTP PATCH request: |
|---|
| Code Block |
|---|
| title | Sample delta as per RFC9144 |
|---|
| collapse | true |
|---|
| { "ietf-nmda-compare:output" : {
"differences" : {
"ietf-yang-patch:yang-patch" : {
"patch-id" : "interface status",
"comment" : "diff between intended (source) and operational",
"edit" : [
{
"edit-id" : "1",
"operation" : "replace",
"target" : "/ietf-interfaces:interface=eth0/enabled",
"value" : {
"ietf-interfaces:interface/enabled" : "false"
},
"source-value" : {
"ietf-interfaces:interface/enabled" : "true",
"@ietf-interfaces:interface/enabled" : {
"ietf-origin:origin" : "ietf-origin:learned"
}
}
},
{
"edit-id" : "2",
"operation" : "create",
"target" : "/ietf-interfaces:interface=eth0/description",
"value" : {
"ietf-interface:interface/description" : "ip interface"
}
}
]
}
}
}
} |
|
| Code Block |
|---|
| title | Sample JSON Patch document |
|---|
| collapse | true |
|---|
| PATCH /my/data HTTP/1.1
Host: example.org
Content-Length: 326
Content-Type: application/json-patch+json
If-Match: "abc123"
[
{ "op": "test", "path": "/a/b/c", "value": "foo" },
{ "op": "remove", "path": "/a/b/c" },
{ "op": "add", "path": "/a/b/c", "value": [ "foo", "bar" ] },
{ "op": "replace", "path": "/a/b/c", "value": 42 },
{ "op": "move", "from": "/a/b/c", "path": "/a/b/d" },
{ "op": "copy", "from": "/a/b/d", "path": "/a/b/e" }
] |
|
|---|
RFC 9144 example using RESTCONF
...
