[netconf] Clarification about RFC8040 plain PATCH operation

Henning Rogge <hrogge@gmail.com> Thu, 14 January 2021 07:46 UTC

Return-Path: <hrogge@gmail.com>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 067ED3A1217 for <netconf@ietfa.amsl.com>; Wed, 13 Jan 2021 23:46:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GchvwOboA2h5 for <netconf@ietfa.amsl.com>; Wed, 13 Jan 2021 23:45:59 -0800 (PST)
Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95AE53A1216 for <netconf@ietf.org>; Wed, 13 Jan 2021 23:45:59 -0800 (PST)
Received: by mail-lj1-x22c.google.com with SMTP id e7so5366300ljg.10 for <netconf@ietf.org>; Wed, 13 Jan 2021 23:45:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=bUXid5zvsyKUxRAJbIm0N/DRUvDAXhMV/GQh1vnymw0=; b=I101FPifH1b58NsXIf0IZmx12mFjN51OpgTdpZzuYFyTP197ZeXKdO8hZQt5FG0+im fQjNU+u+J0K+aD6l8tQtUOwyFkEQskZ7of4cz5zprXowyvqn5EAYhM3jLNQCUKFnBJ5y iMNqZ3C7dsdUlQt9sSUfYyjy44uxa8ADRrwx64v9sWj8o2PScNNvGPMmEJxk4RcHn/6+ igCNqXj/B6ECqU95N59gUloZsZ1AOqQu6Qeo3uexsi7Om7ccPXXEzyyXV3El6gd46r6W m4c+YRkyFQQwzAlBRAeK5OJsOShuP/6KDf/EPQ6p7QZsYy6UAMpfKWi+FwI6olxMvurO pF+g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=bUXid5zvsyKUxRAJbIm0N/DRUvDAXhMV/GQh1vnymw0=; b=ZMYmIHVPPdV3a7mcrCUBAnLH1gM0yzh7iXUL9vOzjeryMtU/qLyuEHViIrU2odlzm2 MwdIKOh2A5agsHQj9jZSeOgI+om22ImhG6gOFLtGcfOaihc0o3UBzNzuYzuFYd5HsD75 9wAF03pYNJjqcYE3OKlmnUEPJ48s63CEFGPgZOmqs+EAxYoae54kFbfv4JXyica5teCs nuDhG3rPP1joX6JuU4Z0RaZicTBypbAKHLBNnpsoRxcDNIs5nV/STjUx9cy5dkyRxclH NatrU9qKI0mEVLWbSm5vaVr8mINeOMzmSC3vu2GMBB4/kTX2iwFkdD0NF4tEwuQvz6n6 8KwQ==
X-Gm-Message-State: AOAM532EBCX94/Au2GjKvidYfJweaAkSy3LhB5JSN1YzN1LybowFxvkn xWyTw7cAMlCgQrGAlLPlgMCwPWLZGMxkrlZXbr5AwpJycQ6M7w==
X-Google-Smtp-Source: ABdhPJyiVnNFu3KdlS5iIo5OwrolboUb50HvenXdizfUlHXJO2XArmJKQD4hjcIsB/FlTfD5MJ7bWMVUkIXYLB/cJok=
X-Received: by 2002:a2e:908:: with SMTP id 8mr2614807ljj.52.1610610357191; Wed, 13 Jan 2021 23:45:57 -0800 (PST)
MIME-Version: 1.0
From: Henning Rogge <hrogge@gmail.com>
Date: Thu, 14 Jan 2021 08:45:31 +0100
Message-ID: <CAGnRvuoQ1DR8et6BVL6FSwM=m-6z+3+ujVoY2mx5e7mrvhO22A@mail.gmail.com>
To: Netconf <netconf@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/904eXBOpUJRsZqOpbRi_3525rqU>
Subject: [netconf] Clarification about RFC8040 plain PATCH operation
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Jan 2021 07:46:01 -0000

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