Re: [netconf] FW: [netmod] CRUD operations on Leaf-list in RFC8040

Andy Bierman <andy@yumaworks.com> Thu, 26 September 2019 03:58 UTC

Return-Path: <andy@yumaworks.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 3CCDA120271 for <netconf@ietfa.amsl.com>; Wed, 25 Sep 2019 20:58:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.888
X-Spam-Level:
X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_MIME_MALF=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.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 GPWBJQWNIRH7 for <netconf@ietfa.amsl.com>; Wed, 25 Sep 2019 20:58:48 -0700 (PDT)
Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) (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 9733A120170 for <netconf@ietf.org>; Wed, 25 Sep 2019 20:58:47 -0700 (PDT)
Received: by mail-lf1-x12c.google.com with SMTP id t8so554043lfc.13 for <netconf@ietf.org>; Wed, 25 Sep 2019 20:58:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2UZ9Enhg+VDgO9vvuKrd5cqQEt+UkV8j3+CHT/AoZog=; b=DxInh9BbSyBMY0sNvIqDS6Dn5fqBy+N6MQMa5+eVwgXPwU3pR6GI9fOo66ipuxs/SZ QbOqLKo7wxiW4TPWT0JCcMdLH1TtI3y6raO3ALGXWCP5aKN7l6FGCoCBJd7bT3xiSPE/ S+U176lGBlc4B5jANbT3kNWkJhU8xlDx9cBm4Xc2M6rwFh0pqJZ8SkC8cIVAOihyAUhd +thPB/s+PcsizmKaaYM0AlH8G/+GQjYlKfxI9jmh5WPOUvddLhYdIG2h97PR6AOO2ihJ BOGqWwSzOgfheWF5J4WhE+DauGve1A8R6HIhPRcm63UsjlA76UP+8XToqV4IqwwQ77zM K5fQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2UZ9Enhg+VDgO9vvuKrd5cqQEt+UkV8j3+CHT/AoZog=; b=XO4zeUAuePWSkzzUtzcMc/MRJ44WaqVazfMxn4fNqJhpb27yrGL0FnfNQRiBq2nK9a 9NLecfF2HsJw0wjYCesvbMCYGzo/ZkyejVIaXONxYdRivufLMTnFLEfYnZ64z1mf2Oi0 +Ok5nydN0xEPEjfcZkQbW5wQk3CqEipCSMtOxf8q3HKhCvugrhDTupFg8SbjunZRUy8u PVu6Pw9sXcP8cB0ZiD5xxM/t6n1s0B4N+PggAieHoiKtVI7SeNR4Vt9k1HD0utzXmQI6 sqxOjxO1lTu2mQEnuVZH5nc1hCndNs0kmJ9kTdyUKA+it2tBioaBCw9SNBvtRHQR1I9K pLBA==
X-Gm-Message-State: APjAAAVIDTKlk1ahFYGcxD5nWROZpUw8fWQZE0ZZYzQnOO88aAFVw7X6 KFVkmmrSz/boSdw3BjpCu8OFfpveoBsrZxTVLUSihnn1
X-Google-Smtp-Source: APXvYqyn1hvQPUq0fNLSW/PhC9RpsW+1LL9Qmp9+MPXMR6kWK/fsOMF5vmmldAazd0THPaCDWqkhOdZgxbIc/BG81ok=
X-Received: by 2002:ac2:554e:: with SMTP id l14mr840532lfk.32.1569470325701; Wed, 25 Sep 2019 20:58:45 -0700 (PDT)
MIME-Version: 1.0
References: <B8F9A780D330094D99AF023C5877DABAA9323418@dggeml511-mbs.china.huawei.com>
In-Reply-To: <B8F9A780D330094D99AF023C5877DABAA9323418@dggeml511-mbs.china.huawei.com>
From: Andy Bierman <andy@yumaworks.com>
Date: Wed, 25 Sep 2019 20:58:34 -0700
Message-ID: <CABCOCHQ=3GFmMTcKDGO02JZ2XwS+B3_Ae_2KQd4RreQB6OR_Gg@mail.gmail.com>
To: Qin Wu <bill.wu@huawei.com>
Cc: netconf <netconf@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000004009b705936cc976"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/0xb5zDuetDidIsJV3cMnlYbEIFo>
Subject: Re: [netconf] FW: [netmod] CRUD operations on Leaf-list in RFC8040
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, 26 Sep 2019 03:58:51 -0000

On Wed, Sep 25, 2019 at 6:27 PM Qin Wu <bill.wu@huawei.com> wrote:

> Andy:
>
> It is not clear to me how YANG Patch operation on leaf-list is different
> from what RFC8040 is doing.
>
> Similar to RFC8040, YANG example described in RFC8072 appendix is using
> "example-jukebox" YANG module
>
> With "artist" list, "album" list, "song" list, "playlist" list instead of
> any leaf-list node
>
>
>
> Can you provide an YANG patch example which allows CRUD operations on
> multiple leaf-list instances?
>
>
>

no (I don't have time) but you would have an "edit" list entry for each
leaf-list instance

Andy


> By reading Section 4.3 of RFC8040
>
> “
>
> More than one element MUST NOT be
>
>    returned for XML encoding.  If multiple elements are sent in a JSON
>
>    message-body, then they MUST be sent as a JSON array.
>
> ”
>
> It looks to me XML encoding restricts only one element or leaf-list
> instance can be returned but JSON encoding has no such limitation.
>
> I am wondering whether YANG patch in RFC8072 has similar issue when we
> select between XML encoding and JSON encoding.
>
>
>
> -Qin
>
> *发件人:* Andy Bierman [mailto:andy@yumaworks.com]
> *发送时间:* 2019年9月25日 23:01
> *收件人:* Qin Wu <bill.wu@huawei.com>
> *抄送:* netconf <netconf@ietf.org>
> *主题:* Re: [netconf] FW: [netmod] CRUD operations on Leaf-list in RFC8040
>
>
>
> Hi,
>
>
>
> The RESTCONF target resource has to be one resource.
>
> The WG added YANG Patch (RFC 8072) to do more complex editing operations.
>
>
>
> Andy
>
>
>
>
>
> On Wed, Sep 25, 2019 at 7:57 AM Qin Wu <bill.wu@huawei.com> wrote:
>
>
> Send to netconf for discussion in the right place,thank Jurgen for kindly
> reminder.
>
> *发件人: *Qin Wu<bill.wu@huawei.com>
>
> *收件人: *netmod<netmod@ietf.org>
>
> *抄送: *Zengjuan<annette.zeng@huawei.com>
>
> *主题: *[netmod] CRUD operations on Leaf-list in RFC8040
>
> *时间: *2019-09-25 19:55:12
>
>
>
> Hi, All:
>
> During implementing RFC8040, we face a few problems related to leaf-list
> usage.
>
> I am wondering how do we create multiple instance of leaf-list data
> resource?
>
> Suppose we have example-foo.yang model as follows:
>
> example-top.yang
>
>
>
>    container top {
>
>     list list1 {
>
>         key "key1 key2 key3";
>
>          ...
>
>          list list2 {
>
>              key "key4 key5";
>
>              ...
>
>              leaf X { type string; }
>
>          }
>
>      }
>
>      leaf-list Y {
>
>        type uint32;
>
>      }
>
> }
>
> To create a new "Y" resource within the "top" resource, can we make
>
> the client send the following request:
>
> POST /restconf/data/example-top:top HTTP/1.1
>
> Host: example.com
>
> Content-Type: application/yang-data+json
>
>
>
> {
>
>   "example-top:Y" : [value1,value2]
>
> }
>
>
>
> response:
>
> HTTP/1.1 201 Created
>
> Date: Thu, 26 Jan 2017 20:56:30 GMT
>
> Server: example-server
>
> Location:
> https://example.com/restconf/data/example-top:top/Y=value1&value2
>
> Last-Modified: Thu, 26 Jan 2017 20:56:30 GMT
>
> ETag: "b3830f23a4c"
>
>
>
> Also I don’t understand why we add limitation to PUT method and plain
> patch method on leaf-list and don’t allow
>
> The value of leaf-list instance to be changed by these two methods
>
> see section 4.5 and section 4.6.1
>
> “
>
> 4.5.  PUT
>
>    If the target resource represents a YANG leaf-list, then the PUT
>
>    method MUST NOT change the value of the leaf-list instance.
>
> 4.6.1..  Plain Patch
>
>    If the target resource represents a YANG leaf-list, then the PATCH
>
>    method MUST NOT change the value of the leaf-list instance.
>
> “
>
> Suppose I want to delete all leaf-list instance values associated with
> leaf-list "Y",
>
> Can I send the following request:
>
> DELETE /restconf/data/example-top:top/Y  HTTP/1.1
>
> Host: example.com
>
>
>
> Quoted section 4.7:
>
> “
>
> 4.7.  DELETE
>
>    If the target resource represents a configuration leaf-list or list
>
>    data node, then it MUST represent a single YANG leaf-list or list
>
>    instance.  The server MUST NOT use the DELETE method to delete more
>
>    than one such instance.
>
> ”
>
> It seems obvious that DELETE method can not delete more than one
> instances. But I don’t know why?
>
>
>
> Also I don’t know we add constraint on XML encoding in the Get request, only allow one single element be
>
> returned for XML encoding, see section 4.3 of RFC8040 as follows:
>
> “
>
> 4.3.  GET
>
>    If a retrieval request for a data resource representing a YANG
>
>    leaf-list or list object identifies more than one instance and XML
>
>    encoding is used in the response, then an error response containing a
>
>    "400 Bad Request" status-line MUST be returned by the server.
>
> “
>
> Suppose I want to retrieve/delete/modify multiple leaf-list instance data
> resource, can I wrap leaf-list "Y" within container "top",
>
> create/delete/modify container "top" data resource?
>
> “
>
> Comments?
>
>
>
> -Qin
>
>
>
> _______________________________________________
> netconf mailing list
> netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>
>