Subject: [netconf] Clarification about RFC8040 plain PATCH operation

From: Henning Rogge <[email-masked]>
Date: Thu, 14 Jan 2021 08:45:31 +0100

Hi,

I have trouble making sure I get the meaning of the RFC8040 plain
Patch operation right... mostly because of the (potential) double
meaning of the word "merge".

Is the plain patch operation meant as a shallow merge or a deep merge?

Here is my attempt as an example with a PATCH operation of the node "rootC".

YANG context:
container rootC {
        container partA {
                leaf leafA1 {
                        type string;
                }
                leaf leafA2 {
                        type string;
                }
        }
        container partB {
                leaf leafB1 {
                        type string;
                }
                leaf leafB2 {
                        type string;
                }
        }
}

Datastore content before the PATCH operation:
{
        "ns:rootC": {
                "partA": {
                          "leafA1": "A1",
                          "leafA2": "A2"
                },
                "partB": {
                          "leafB1": "B1",
                          "leafB2": "B2"
                }
        }
}

Simple Patch Body:
{
        "ns:rootC": {
                "partA": {
                          "leafA1": "newA1",
                }
        }
}

Datastore content after PATCH with "shallow" merge:
{
        "ns:rootC": {
                "partA": {
                          "leafA1": "newA1",
                },
                "partB": {
                          "leafB1": "B1",
                          "leafB2": "B2"
                }
        }
}

Datastore content after PATCH with "deep/recursive" merge:
{
        "ns:rootC": {
                "partA": {
                          "leafA1": "newA1",
                          "leafA2": "A2"
               },
                "partB": {
                          "leafB1": "B1",
                          "leafB2": "B2"
                }
        }
}

With a shallow merge, the merging is only done for the
root-container... with the deep merge the server has to recursively go
down each patched container.

Henning Rogge

---

From: "Wisotzky, Sven (Nokia - DE/Stuttgart)" <[email-masked]>
Date: Thu, 14 Jan 2021 08:12:12 +0000

Hi Henning,

While rfc8040 does not deeply cover your question, I would argue that the PLAIN PATCH method would apply a MERGE operation along the lines of rfc6241 NETCONF operation / default-operation. This enables low overhead RESTCONF to NETCONF mapping, without big processing required. In essence this implies the implementation to follow what you are calling "deep/recursive merge".

From an user/client perspective this makes sense a lot, because a merge would never accidently replace children subtrees aka remove children container leafs. If that would become a requirement, one could still replace individual children using dedicated RESTCONF API requests OR to use YANG PATCH media type (rfc8072).

Indeed, when building a native RESTCONF stack this may result in extra work, as one might need to visit every children container / list-entry to create/update those entities as needed.

/wiso

On 1/14/21, 08:46, "Henning Rogge" <[email-masked]> wrote:

    Hi,

    YANG context:
    container rootC {
            container partA {
                    leaf leafA1 {
                            type string;
                    }
                    leaf leafA2 {
                            type string;
                    }
            }
            container partB {
                    leaf leafB1 {
                            type string;
                    }
                    leaf leafB2 {
                            type string;
                    }
            }
    }

    Simple Patch Body:
    {
            "ns:rootC": {
                    "partA": {
                              "leafA1": "newA1",
                    }
            }
    }

    Henning Rogge

    _______________________________________________
    netconf mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/netconf