Re: [netconf] restconf collections

Qin Wu <> Thu, 01 October 2020 04:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7B2783A0A6A for <>; Wed, 30 Sep 2020 21:33:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jPGc4-xwhw2M for <>; Wed, 30 Sep 2020 21:33:25 -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 E11003A0A2E for <>; Wed, 30 Sep 2020 21:33:24 -0700 (PDT)
Received: from (unknown []) by Forcepoint Email with ESMTP id BC39B2A4BE4A37858B6B for <>; Thu, 1 Oct 2020 05:33:22 +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; Thu, 1 Oct 2020 05:33:22 +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; Thu, 1 Oct 2020 05:33:21 +0100
Received: from ([]) by ([fe80::74d9:c659:fbec:21fa%31]) with mapi id 14.03.0487.000; Thu, 1 Oct 2020 12:33:16 +0800
From: Qin Wu <>
To: Kent Watsen <>, Martin Björklund <>
CC: "" <>
Thread-Topic: [netconf] restconf collections
Thread-Index: AdaXqmqKAXfr1Ii5SXaCwhU6e4V5sQ==
Date: Thu, 01 Oct 2020 04:33:15 +0000
Message-ID: <>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
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: Thu, 01 Oct 2020 04:33:32 -0000

>> Yes, XPath is the “right answer”, but we need to ensure it’s 
>> constrained enough to be mappable to common DB-backends.
> So the client talks to the server, and the server talks to the "db"
> backend (note that in many implementations  operational state is 
> typically not stored in a real database).

Some opstate must be persisted, e.g., long-lived counters, logs, etc., but it’s a good point about other opstate not being persisted.   Perhaps “node-tags” can be used here, to differentiate which is which…and servers can indicate if/how they support the ephemeral opstate leafs in queries?

[Qin]:That's a good case for node tag, in earlier discussion, we discussed operation type, which distinguishs cumulative statistics value from current value. The case discussed here is very close to operation type proposal discussed earlier.

> So we have:
>  client ->  server ->  backend
> If we don't have any filter capabilities, the client has to get 
> everything, and then filter.  If we support XPath and the backend 
> doesn't support it, the server will have to filter.  This is still 
> more efficient than filtering in the client.

Probably, especially when assuming the server has better resources and/or the client <--> server bandwidth is constrained.

> In ConfD/NSO we moved more and more filtering logic towards the 
> backend, to speed up performance.


> I think e) is way more important than c).  I suggest focus on a + b + 
> c.

Noted, but I think you meant a + b + e.

Note sure how others feel about “direction: (c), but my primary use-case revolves around time-series data (e.g., logs), where the interest is commonly on the most-recent entries, so "reverse-->offset—>limit” works nicely.  

Perhaps an alternative would be to lift a concept from Python with negative indexes so, for instance, offset=-N and limit=-N gives the last N entries?
[Qin]: Yes, that's what I thought as well, with negative indexes, (b) and (c) seems to me, can be combined.

>> 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!
> See above.  It can be quite efficient even if the backend doesn't 
> support it.

I don’t see that above, but I don’t doubt that it can be so, it’s just a whole lot of implementation complexity.  It seems that we should/must support servers doing it, we just need to find a way (node-tags?) to enable them to express that ability.
[Qin]: My feeling is this efficiency more depends on the amount of data we need to request. If amount of data we request is huge, maybe, client-> server-> backend may be the better choice.


netconf mailing list