Re: [netconf] restconf collections

Qin Wu <bill.wu@huawei.com> Wed, 30 September 2020 01:12 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 B3C8C3A0598 for <netconf@ietfa.amsl.com>; Tue, 29 Sep 2020 18:12:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, 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 eZEKAXhkUkbP for <netconf@ietfa.amsl.com>; Tue, 29 Sep 2020 18:12:06 -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 93BD83A0597 for <netconf@ietf.org>; Tue, 29 Sep 2020 18:12:06 -0700 (PDT)
Received: from lhreml734-chm.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 3BFFBA0B9C1A59244B53 for <netconf@ietf.org>; Wed, 30 Sep 2020 02:12:03 +0100 (IST)
Received: from lhreml734-chm.china.huawei.com (10.201.108.85) by lhreml734-chm.china.huawei.com (10.201.108.85) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Wed, 30 Sep 2020 02:12:03 +0100
Received: from DGGEML422-HUB.china.huawei.com (10.1.199.39) by lhreml734-chm.china.huawei.com (10.201.108.85) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1913.5 via Frontend Transport; Wed, 30 Sep 2020 02:12:02 +0100
Received: from DGGEML531-MBS.china.huawei.com ([169.254.5.245]) by dggeml422-hub.china.huawei.com ([10.1.199.39]) with mapi id 14.03.0487.000; Wed, 30 Sep 2020 09:11:57 +0800
From: Qin Wu <bill.wu@huawei.com>
To: Robert Varga <nite@hq.sk>, Kent Watsen <kent+ietf@watsen.net>, "Andy Bierman" <andy@yumaworks.com>
CC: "netconf@ietf.org" <netconf@ietf.org>
Thread-Topic: [netconf] restconf collections
Thread-Index: AdaWxrARb7QoF9WvRqqa3/OiAxOZvg==
Date: Wed, 30 Sep 2020 01:11:57 +0000
Message-ID: <B8F9A780D330094D99AF023C5877DABAADA343D1@dggeml531-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.136.101.103]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/J5t7RyM7IeWEvmK_6mv2t_cYb0E>
Subject: Re: [netconf] restconf collections
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: Wed, 30 Sep 2020 01:12:08 -0000

Hi, Robert:
-----邮件原件-----
发件人: netconf [mailto:netconf-bounces@ietf.org] 代表 Robert Varga
发送时间: 2020年9月30日 7:05
收件人: Kent Watsen <kent+ietf@watsen.net>et>; Andy Bierman <andy@yumaworks.com>
抄送: netconf@ietf.org
主题: Re: [netconf] restconf collections

On 26/09/2020 20:57, Kent Watsen wrote:
>> There are 3 completely different approaches:
>>
>>   1) stateless
>>   2) stateful
>>   3) stateful snapshot
>>
>> How to efficiently iterate through data that is changing constantly?
>> This problem is harder than it looks.
> 
> Agreed.  I recommend we NOT try to solve that problem.

Unfortunately you do need to pick an interaction model to tie together the first and second pagination requests. At the very least you need to specify consistency guarantees between the two -- which gives them worms juuust enough room to wiggle out of the can.

[Qin]:I think when the client Using page request to get access to the element in the list, he only need to remember the position of last element in the first pagination request and set the number of element he want to request in the pagination requests,
The server doesn't need to keep any additional states, the server only need to support list operation.

A fair answer is 'well, they are not tied together and if the datastore moves, you are SOL' ... but then how do you make forward progress with enough consistency to be useful in the real world? :)


[Qin]: I think it doesn't matter whether the list will grow and add new elements, we could still use last element position and count of elements in the list that need to be queried to retrieve additional elements we want.

At the end of the day, you will end up creating some state on the server, which the server will need to be free to revoke at any time (due to resource constraints, or whatever implementation-specific reasons).

Regards,
Robert