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

Qin Wu <bill.wu@huawei.com> Thu, 26 September 2019 01:27 UTC

Return-Path: <bill.wu@huawei.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 97221120131 for <netconf@ietfa.amsl.com>; Wed, 25 Sep 2019 18:27:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.189
X-Spam-Level:
X-Spam-Status: No, score=-4.189 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_MIME_MALF=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 OcPZv--QIe8v for <netconf@ietfa.amsl.com>; Wed, 25 Sep 2019 18:27:23 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E190A120088 for <netconf@ietf.org>; Wed, 25 Sep 2019 18:27:22 -0700 (PDT)
Received: from lhreml705-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id A2993E7B47BF6A3F63EC for <netconf@ietf.org>; Thu, 26 Sep 2019 02:27:16 +0100 (IST)
Received: from lhreml722-chm.china.huawei.com (10.201.108.73) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 26 Sep 2019 02:27:15 +0100
Received: from lhreml722-chm.china.huawei.com (10.201.108.73) by lhreml722-chm.china.huawei.com (10.201.108.73) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Thu, 26 Sep 2019 02:27:16 +0100
Received: from DGGEML406-HUB.china.huawei.com (10.3.17.50) by lhreml722-chm.china.huawei.com (10.201.108.73) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1713.5 via Frontend Transport; Thu, 26 Sep 2019 02:27:15 +0100
Received: from DGGEML511-MBS.china.huawei.com ([169.254.4.185]) by dggeml406-hub.china.huawei.com ([10.3.17.50]) with mapi id 14.03.0439.000; Thu, 26 Sep 2019 09:27:00 +0800
From: Qin Wu <bill.wu@huawei.com>
To: Andy Bierman <andy@yumaworks.com>
CC: netconf <netconf@ietf.org>
Thread-Topic: [netconf] FW: [netmod] CRUD operations on Leaf-list in RFC8040
Thread-Index: AdV0B+HZ9iWcMAYYRQa4/ijv7YCCIw==
Date: Thu, 26 Sep 2019 01:26:59 +0000
Message-ID: <B8F9A780D330094D99AF023C5877DABAA9323418@dggeml511-mbs.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.134.31.203]
Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABAA9323418dggeml511mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/u1p31cIqJzA1JhM41FL-sX8nwNI>
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 01:27:27 -0000

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?

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<mailto: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<mailto:bill.wu@huawei.com>>
收件人: netmod<netmod@ietf.org<mailto:netmod@ietf.org>>
抄送: Zengjuan<annette.zeng@huawei.com<mailto: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<http://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<http://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<mailto:netconf@ietf.org>
https://www.ietf.org/mailman/listinfo/netconf