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 > >