Re: [netconf] restconf collections

Robert Varga <nite@hq.sk> Wed, 30 September 2020 08:39 UTC

Return-Path: <nite@hq.sk>
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 796E13A12FD for <netconf@ietfa.amsl.com>; Wed, 30 Sep 2020 01:39:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.312
X-Spam-Level:
X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.213, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hq.sk
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 euHfiyfn1jiL for <netconf@ietfa.amsl.com>; Wed, 30 Sep 2020 01:39:23 -0700 (PDT)
Received: from mail.hq.sk (hq.sk [81.89.59.181]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 706A43A12FA for <netconf@ietf.org>; Wed, 30 Sep 2020 01:39:23 -0700 (PDT)
Received: from nitebug.nitenet.local (46.229.239.158.host.vnet.sk [46.229.239.158]) by mail.hq.sk (Postfix) with ESMTPSA id C57C8246E16; Wed, 30 Sep 2020 10:39:20 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hq.sk; s=mail; t=1601455160; bh=eTG6lV3Y0dfdLFrDYcA2c5xvLv1YFFUsYVLqGC5i8yI=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=ImtVcSIuDbYnToie4sVDGWSjewqqtrF3mhxlOlrJPgez6CP7Nldp3owZehDVuwIgg HyhWr8hKdyuFvoXCh3GWGW/2tT+Ft4tRis0wg/4C5Smtbr5/tsAw0bFBLH2uktNxTL WtLVcplTsMyWvUVbU9FsvIVSl2x1dBfcEY9tJsNw=
To: Qin Wu <bill.wu@huawei.com>, Kent Watsen <kent+ietf@watsen.net>, Andy Bierman <andy@yumaworks.com>
Cc: "netconf@ietf.org" <netconf@ietf.org>
References: <B8F9A780D330094D99AF023C5877DABAADA343D1@dggeml531-mbs.china.huawei.com>
From: Robert Varga <nite@hq.sk>
Message-ID: <441d95cc-fe41-6d63-849f-a1d30c86859d@hq.sk>
Date: Wed, 30 Sep 2020 10:39:15 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0
MIME-Version: 1.0
In-Reply-To: <B8F9A780D330094D99AF023C5877DABAADA343D1@dggeml531-mbs.china.huawei.com>
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="gufZKMcNdbaAnDCaK5N1RhOm59YHcs2SH"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/11_v5PKISlyfCViaanorzV6atFw>
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 08:39:26 -0000

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

Regards,
Robert