Re: [netconf] restconf collections

Qin Wu <> Wed, 30 September 2020 01:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A40A33A0992 for <>; Tue, 29 Sep 2020 18:27:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id F6sY_5KxJEoe for <>; Tue, 29 Sep 2020 18:27:50 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9C3023A0982 for <>; Tue, 29 Sep 2020 18:27:50 -0700 (PDT)
Received: from (unknown []) by Forcepoint Email with ESMTP id 27C596BB8E2A243A69F8 for <>; Wed, 30 Sep 2020 02:27:49 +0100 (IST)
Received: from ( by ( 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:27:48 +0100
Received: from ( by ( 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:27:48 +0100
Received: from ([]) by ([]) with mapi id 14.03.0487.000; Wed, 30 Sep 2020 09:27:43 +0800
From: Qin Wu <>
To: Kent Watsen <>, Martin Björklund <>
CC: "" <>
Thread-Topic: [netconf] restconf collections
Thread-Index: AdaWyD+878Wbd/BNR1i0vXS4P7t/Ug==
Date: Wed, 30 Sep 2020 01:27:43 +0000
Message-ID: <>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABAADA34671dggeml531mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <>
Subject: Re: [netconf] restconf collections
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 30 Sep 2020 01:27:53 -0000

发件人: netconf [] 代表 Kent Watsen
发送时间: 2020年9月30日 5:57
收件人: Martin Björklund <>
主题: Re: [netconf] restconf collections

Hi Martin,

I don't think d) and e) should be restricted to obu lists, and I don't
think they should be restricted to "indexable" columns.

And I think "expression of some sort" should be XPath.

Also, since the main objective is efficient retrieval, "sort-by"
can perhaps be removed.  Consider large lists in operational state
that also change often.

Your last paragraph, if I read it correctly, says “maybe don’t do ‘d’”, which if applied to the first part of your response becomes "I don't think 'e' should be restricted to OBU-lists”, which is something I can agree with.  As for ‘d’ being a reasonable thing to support for OBU-lists, please explain the use-case.

Regarding “I don’t think they should be restricted to ‘indexable’ columns”, we need to keep in mind that, if the DB-backend can’t do it, then the server logic will need to it, likely by retrieving all records and brute-forcing its way through them, which would not only be painfully slow, but a lot of implementation complexity.  That said, I’m unsure what use-case you have in mind whereby a non-indexable column is being filtered/sorted.  Only a couple of the built-in types aren’t indexable, right?

Yes, XPath is the “right answer”, but we need to ensure it’s constrained enough to be mappable to common DB-backends.

Updating my previous response (per above, plus adding leaf-list, plus locking-in names, which I’m choosing only to NOT sound like SQL):

    For all lists and leaf-lists:

       a) count      (uint, default: 0)
       b) skip       (uint, default: 0)
       c) direction  (enum: forwards/backwards, default: forwards)

    For non “ordered-by user” lists only (N/A to leaf-lists), but
    only for indexable columns:

       d) sort-by    (string: a single column/leaf name)

    For all lists and leaf-lists, but only for indexable columns (note: for
    a leaf-list, it is its own indexable column):
       e) filter     (a constrained Xpath expression)

    Again: sequence of operation is e —> a.

We haven’t discussed “feature” statements yet, but it seems reasonable to me for both ‘d’ and ‘e’ to be optionally implemented.  Additionally, it may be that additional Xpath expressions can be unlocked by feature statements).

[Qin] Umm, this seems a good choice. I feel sort-by is nice to have feature, in many cases, very useful. But we need to when sort-by is required and when is not.

We could define a few more XPath functions for such comparisons.

Sure, but I wonder if, e.g., a netmask filter, is supportable by common DB-backends.  I’m hoping we have some DB-experts on the list!