Versions Compared

Old Version 13

changes.mady.by.user Arpit Singh

Saved on

compared with

New Version 14

changes.mady.by.user Arpit Singh

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Questions/IssuesNotesDecisions
  • 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.

Both RFC have their pros and cons. 

  • RFC 6902 thrives with its simple approach but lacks proper categorization of data.
  • RFC 9144 benefits because of proper categorization of data and detailed information provided as part of the report. But in doing so it complicates things by making it mandatory to persist the delta and adding and "edit-id" field to identify each delta report entity uniquely. And this approach does not report the paths of individual data nodes that changed, instead it reports only one path that was sent as part of request.

CPS delta report takes inspiration from both RFCs and cherry pics the best of both worlds to achieve its goals.

  • Keeping the simplicity in mind the Delta report will only contain 4 fields:
    • action, xpath, source-data and target-data.
  • The operation field present in both RFCs is replaced with "action" field because in CPS we want to report the action that was performed on the data.
  • The JSON path is replaced with xpath as CPS is based around xpaths. And the delta report will have the xpaths of every data node changed.
  • To properly categorize the data, we take the source-data and target-data fields from RFC 9144, this provides better data visualization over a combined field of "values" defined in RFC 6902.
  • Persisting of delta report is not needed in case of CPS. 

The documentation of RFC 9144 defines a POST operation to find the delta.

The reason for this is, according to the approach both source and target data are sent as JSON payload (as seen in source and target fields).



Code Block
titleSample POST request from RFC9144
collapsetrue
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:source",
   "target" : "ietf-datastores:target",
   "report-origin" : null,
   "xpath-filter" : "/ietf-interfaces:interfaces"
   }
}


  • The first Delta API does not require any payload to be sent as it uses 2 anchors and data stored under them to generate the delta. Hence it will be a GET API.
  • The second Delta API is going to generate delta between an anchor and JSON payload. Hence following the best practice, the second API will be a POST operation.


  • RFC 9144 defines a 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?


CPS does not require persisting of the delta generated.

So, only a few key points from this RFC are taken into consideration. Such as categorization of data as source and target data.

Intention of RFC 9144

...