Re: [netconf] restconf collections

Qin Wu <bill.wu@huawei.com> Wed, 30 September 2020 10:33 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 2B3F63A0AA6 for <netconf@ietfa.amsl.com>; Wed, 30 Sep 2020 03:33:37 -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 qe5JWKXwGHXb for <netconf@ietfa.amsl.com>; Wed, 30 Sep 2020 03:33:35 -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 6CD2E3A0AA0 for <netconf@ietf.org>; Wed, 30 Sep 2020 03:33:35 -0700 (PDT)
Received: from lhreml747-chm.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 2932161A44F0826BFA61 for <netconf@ietf.org>; Wed, 30 Sep 2020 11:33:34 +0100 (IST)
Received: from lhreml747-chm.china.huawei.com (10.201.108.197) by lhreml747-chm.china.huawei.com (10.201.108.197) 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 11:33:34 +0100
Received: from DGGEML401-HUB.china.huawei.com (10.3.17.32) by lhreml747-chm.china.huawei.com (10.201.108.197) 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 11:33:33 +0100
Received: from DGGEML531-MBS.china.huawei.com ([169.254.5.245]) by DGGEML401-HUB.china.huawei.com ([fe80::89ed:853e:30a9:2a79%31]) with mapi id 14.03.0487.000; Wed, 30 Sep 2020 18:33:27 +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: AdaXFCv070wS8R0MTlOTHGsG6zVmmA==
Date: Wed, 30 Sep 2020 10:33:27 +0000
Message-ID: <B8F9A780D330094D99AF023C5877DABAADA34D14@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/yRtWgDe7PUUznSvFTvhLYo7PpK4>
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 10:33:37 -0000

-----邮件原件-----
发件人: Robert Varga [mailto:nite@hq.sk] 
发送时间: 2020年9月30日 16:39
收件人: Qin Wu <bill.wu@huawei.com>om>; Kent Watsen <kent+ietf@watsen.net>et>; Andy Bierman <andy@yumaworks.com>
抄送: netconf@ietf.org
主题: Re: [netconf] restconf collections

On 30/09/2020 03:11, Qin Wu wrote:
> Hi, Robert:

Hellow Qin,

> -----邮件原件-----
> 发件人: 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.

That is assuming the list in question has iteration order which is stable. I do not believe this is something RFC7950 mandates on anything except ordered-by=user.

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

So let's say the list has 4 elements A, B, C, D.

1) The first request returns items A, B, C.
2) An item is inserted before C, so that the list is E, A, B, C, D.
3) What does the second request return?
Similarly:

1) The first request returns items A, B, C.
2) An item is deleted before C, so that the list is B, C, D.
3) What does the second request return?

Pagination is deceptively hard.
[Qin]: maybe using position of the last element is not accurate, the client only needs to remember the last element he request in the first pagination request, and use the last element as cursor reference point and set count of elements he want in the second pagination request, so in both cases, the second request will return D.
But if C is deleted in the extreme case, I think the server should return error to indicate the C element as last element doesn't exist.

Regards,
Robert