Re: [netconf] restconf collections

Hongwei Li <flycoolman@gmail.com> Wed, 30 September 2020 22:54 UTC

Return-Path: <flycoolman@gmail.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 15E343A0D2A for <netconf@ietfa.amsl.com>; Wed, 30 Sep 2020 15:54:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 (2048-bit key) header.d=gmail.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 1-obvrD8OYyI for <netconf@ietfa.amsl.com>; Wed, 30 Sep 2020 15:54:46 -0700 (PDT)
Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) (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 B16ED3A0DF3 for <netconf@ietf.org>; Wed, 30 Sep 2020 15:54:37 -0700 (PDT)
Received: by mail-lj1-x236.google.com with SMTP id k25so2989437ljg.9 for <netconf@ietf.org>; Wed, 30 Sep 2020 15:54:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=c0lcNzk9w3pQZiptmFOEEKxm+pnC1c+oTPboJAFJORc=; b=Aq6n2d1Gznm12jjJR3bAqEYc1vRvShmWzBg8wVnE8IKrBfhGX7ufz+OInJQy3ghkeO 4aTzADiEgWEEa2QXO/kvapWEfIYkbkMdvT8Ny+C4jyt0ZXtbFSpZQe6Lv0aTadzBYL9l Z6tgyA6lpkXAYSV69ogi61yOEjC/5qTtYa5ESbQDb4bcH/vWC2sRRVob5E/8SqYI5XIn g79fLbCr+6Xu6zJnOZ4as0NFrl3kuVa9DIx0v/nEevJg7bEOJVl0GbrcwJSlIxhP8aQe BQaGY3AzdJBpuHOlGQzsEueA34h89AqvHsNDYZls9TUT9JwvtVZOKOfQyeu7v8hIBu8P 4qfg==
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=c0lcNzk9w3pQZiptmFOEEKxm+pnC1c+oTPboJAFJORc=; b=dqo+kFdJJDwam24Ks+UANYmffQaigLMRZhIEUzs5voSzYUOCtrujmS2MJm+s/4KXuw D446tach3jomvCfE+RnyZnqY7T67xDZLaktT9+bAjV6YKOYVYpogFQSAjbzd9XxzU7Yz lDQ1C6R1NX/7MF1bJocd7/hs5qSu0DCVoN/jZfkHs4yKMHltbpc+Emx8ww6Yd2bVvZ6n T2Z35vrM1mKavgTvFaKWy+9TmqP5VZ4IX+ZwhGIZKwEE0c+UjtncmXOESQZHH/2s97U5 naQ0NySQ8wWD7hC7LPI97Vzg/8pfNqo5AAFzTrWnyhJHY6RFuGbhdbFTKMQsGLB5FXFO i1zw==
X-Gm-Message-State: AOAM531oLMibCF9WbxlUovEWPtZrocr1mm+rsScNtzZ1UHT41dYq/UEF CfXNTfvsGHCNBLGxPx+6K2qLznBY5qVnSIKhZ5b0ugkxuPmzow==
X-Google-Smtp-Source: ABdhPJzqEfBXJoin0jHoGVLrlyqT35O+tpn3jYLbid6I+LhfxCg0jrHR61DWL78zC6X1f0NFmSHfRS6YKupwEtFerXo=
X-Received: by 2002:a05:651c:1af:: with SMTP id c15mr1504429ljn.347.1601506475670; Wed, 30 Sep 2020 15:54:35 -0700 (PDT)
MIME-Version: 1.0
References: <B8F9A780D330094D99AF023C5877DABAADA343D1@dggeml531-mbs.china.huawei.com> <441d95cc-fe41-6d63-849f-a1d30c86859d@hq.sk> <01000174e013b1f6-fd0b45d1-951d-41dd-85d8-39685a52e998-000000@email.amazonses.com> <fedbd2ba-39e4-08a4-adbf-198ea1b6efd2@hq.sk>
In-Reply-To: <fedbd2ba-39e4-08a4-adbf-198ea1b6efd2@hq.sk>
From: Hongwei Li <flycoolman@gmail.com>
Date: Wed, 30 Sep 2020 18:54:24 -0400
Message-ID: <CAL73O_ydeWCtwD_NRnLvuPg9D2XoZDtFXtq_Hs5UL05A8-ZbSA@mail.gmail.com>
To: Robert Varga <nite@hq.sk>
Cc: Kent Watsen <kent+ietf@watsen.net>, "netconf@ietf.org" <netconf@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000967f0805b08fc8dc"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/n1CqmMyFyPnfJXF-AwceknufIBU>
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 22:54:51 -0000

On Wed, Sep 30, 2020 at 4:04 PM Robert Varga <nite@hq.sk> wrote:

> On 30/09/2020 19:33, Kent Watsen wrote:
> > Hi Robert,
> >
> >> 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.
> >
> > If not “ordered-by user”, then its “ordered-by system” that, as RFC 7950
> says, "the server is free to sort the list entries in any reasonable
> order.”  This is a stable ordering, IMO.
>
> It's been quite some time since I did lawyer-reading the RFCs, but for
> the sake of argument:
>
> - is use of hash maps for keyed lists okay, hence the sort order is the
> encounter order based on the contents?
> - if so, does that order remain the same even across server restarts?
>
> I am not sure what the litmus test for 'reasonable' would look like, I
> am afraid.
>
> [HL] I would say there is no guarantee on the stable ordering. And the
status may change across server restarts.


> >> 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.
> >
> > Is your conjecture that the solution should enable something akin to
> cursors?  Would this be an advanced feature that a server might support on
> a list-by-list basis?   Maybe "node-tags” could be useful here too…
>
> If the requirement is to really just have an iterator, which breaks when
> the list changes, then a node-tag+offset would be sufficient. But then
> you could end up in a situation where you will never traverse the list
> simply because its rate of change exceeds your ability to traverse it.
>
> The path forks quite a bit if you want something more specific, like:
> "visit all elements in any order, i.e. additions do not break iteration".
>
> If we have requirements towards that level of complexity, then yes, I
> would very much prefer if there was a cursor-like resource associated
> with an ongoing pagination request.
>
> If I squint just a little bit, the first paginated request is not that
> different for a (one-shot) subscription to receive notification of all
> list entries. Subsequent requests are fetches from that notification
> stream... which shows my reactive systems bias :)
>
> [HL] In the above examples, they are more of dynamic linked lists with
multiple threads making operations on the lists.
The index or position parameter can't be used to get the same values as
they change with system running.
However pagination can be done on snapshot. It means the server can send
data in pages (some or all) once the request is made.
This also complies with the characteristic of a running system.


> Regards,
> Robert
>
> _______________________________________________
> netconf mailing list
> netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>