Re: [netconf] restconf collections

Martin Björklund <> Thu, 01 October 2020 06:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 03FF43A0AEC for <>; Wed, 30 Sep 2020 23:33:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.101
X-Spam-Status: No, score=-0.101 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, PDS_NAKED_TO_NUMERO=1.997, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b=RWzJbVi/; dkim=pass (2048-bit key) header.b=BeIUnoJT
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 10EWGCzYUWSJ for <>; Wed, 30 Sep 2020 23:33:52 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 840093A0AE3 for <>; Wed, 30 Sep 2020 23:33:52 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id DA5665C0741; Thu, 1 Oct 2020 02:33:51 -0400 (EDT)
Received: from mailfrontend2 ([]) by compute4.internal (MEProxy); Thu, 01 Oct 2020 02:33:51 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=date :message-id:to:cc:subject:from:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=fm2; bh= OyTmKMkwHslLgOh+GFfSNI2b4GwwWDXIc7t9HS1h1+M=; b=RWzJbVi/CqpqpxFK +8dpyRskVROyVwbnWhBD/CtkenYMcIbDUhLNTzKVYxs/W4qo4kbZH0tw3Jkmwzak 0uutvu0x9WvWkYt71HwVFWvKIkCcj3AvhKgbv51KhsqeU0CNpguC1gxy6COZ7kAV ONgAC9x9psh3nbC+iCBIyQ5BuzBXF6UaOCfmr5WZY/3arzl0Tycr0mkWcOBttB8F ivziBvNWcykYLWGeiJxRzQv4U1Ol70fzKUMKmHr3/AzmvI2huO77nGfnqhnveTfp AdmMOWnC1yx7VBeVSeahDt458LF47uyOP5pm4wrWJiewsd5xX8hxao/A9vEIwEgA 66Zepg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=OyTmKMkwHslLgOh+GFfSNI2b4GwwWDXIc7t9HS1h1 +M=; b=BeIUnoJTYxwvtT8c9V7qeYleyH3T2eFanE98Fh/bxiOlVugNxTKsBcYVN m5S+ovwxK1svbSBxqMFN2YXPss/WXzPnly66CeTs+LCrsMg4Hyi/LeVGu6wl20EL oZr9Jnfs7ky10NUNy3K/Sa24y7p6lSLIN5AjJUpX+6uQZ+Ggypv6yJaPlbK7TygT qmVSvBZjiy7Aq1oyExkiWnzBVu9X3SP7IgUcYAa45S2xCL2co0HW7u+sQCkrC3Aq UO+FwzOeEAU396Hsyxm+7u5IaMLTIEWE/xEYlbJMb/mUyuZw4gT4BEWZTg4unRNs 4uEYslYSwZi3t0eN6SNo0Ji/ROwkw==
X-ME-Sender: <xms:T3h1X8W_eMQUGw3BhCl0ddcGyL4cG3uSgeBVpSvM7Ptu-OJtolW0Sw> <xme:T3h1XwnBRgv3bFZY7vnv1mvhUdNMkWiIY4VI7VtB_ph3e9n8vN_AjGYorcV1VNs9V inXWT78tjqdjraZ-54>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrfeefgdduudduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffkffvuffhjghfofggtgfgsehtsg ertdertdejnecuhfhrohhmpeforghrthhinhcuuehjnphrkhhluhhnugcuoehmsghjodhi vghtfhesgeeiieekrdhsvgeqnecuggftrfgrthhtvghrnhepfeehkefgudekfeehieehhf ekgedvffehteevgfeffeeghfdvfeeuleduvddvgfehnecuffhomhgrihhnpehivghtfhdr ohhrghenucfkphepudehkedrudejgedrgedrvdduheenucevlhhushhtvghrufhiiigvpe dtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmsghjodhivghtfhesgeeiieekrdhsvg
X-ME-Proxy: <xmx:T3h1XwafOhiF4SH6D8HUd5Yr36jRAapn1iOgF0zrNRMP1YkbTh87Tg> <xmx:T3h1X7WFQA6vxsLtSxc27V_74QleEVuMyQbKKZj2y7tuXCcmZfoxQQ> <xmx:T3h1X2lQuX5xNo5Tmji3hTLGp84OK51-6CeMCNVNOUZANgQlRBlGUQ> <xmx:T3h1X9tWfmZgWCon4_lu-lUfg38UED-WZtBQGvdZWG5Hrimw4ZGCzg>
Received: from localhost (unknown []) by (Postfix) with ESMTPA id C94243064680; Thu, 1 Oct 2020 02:33:50 -0400 (EDT)
Date: Thu, 01 Oct 2020 08:33:49 +0200
Message-Id: <>
From: Martin Björklund <>
In-Reply-To: <>
References: <> <> <>
X-Mailer: Mew version 6.8 on Emacs 26.3
Mime-Version: 1.0
Content-Type: Text/Plain; charset="utf-8"
Content-Transfer-Encoding: base64
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 06:33:54 -0000


Kent Watsen <> wrote:
> Hi Olaf,
> > I agree sorting is less important (than a,b,e).
> Noted.
> > Is it not also somewhat beyond the present yang concepts where there
> > is
> > already ordered-by and key indices?
> > Supplying a differing sorting could in effect require a different set
> > of
> > index(es) which could be quite costly in runtime for large data sets.
> > If you want to sort differently, should it not be present in the
> > underlying model, ie as declaring a secondary set of keys, for
> > example,
> > as an extension of the original yang model (thus being out of scope
> > here)?
> A couple messages I sent yesterday alluded to defining an extension
> statement that could be added to nodes in the YANG modules.
> Now I’m thinking that one-size doesn’t necessarily fit all, and
> something like a server-specific “node-tag” would be more flexible.
> (
> <>)
> Maybe the answer is somewhere in-between, i.e., an extension that acts
> like a “hint” and a node-tag indicating if the server delivered it.
> Bad news w/ an extension is that legacy modules would need to be
> revved or augmented.
> One thing, though, filtering on non-indexed nodes is guaranteed to
> have slow performance, thus it seems that we need to enable indexing
> for more than just a list’s keys.

I disagree with both these statements.  This is an implementation

> My conjecture is that, once we have the indexes for filtering (e),
> they can be used for sorting (d).  At least, that’s the way it works
> with some DB-backends I’m familiar with...

This is one implementation strategy.  We should not design the
standard around one implementation.

> >>>> Yes, XPath is the “right answer”, but we need to ensure it’s
> >>>> constrained enough to be mappable to common DB-backends.
> > 
> > I would think a (strongly) constrained XPath would be a very nice
> > solution.
> +1
> > To me reverse direction seems a subset of ordering/sorting?
> Indeed.  In some DB-backends, “direction" is a sub-statement to the
> “sort” statement.
> > If sorting is less important, so would an alternate direction?
> Maybe, but an independent “direction" works with OBU-lists, which is
> why I teased it out.
> And, besides, that assumes sorting is less important.  I do hear a
> consensus beginning to form in that direction, so we’ll see...
> All I know is that there are tons of UIs that enable column sorting
> (e.g., an email client).  Do we feel data models defined by YANG are
> somehow immune to this?
> I hear folks expressing concern around sorting big data (e.g., logs),
> which I grok, but what about for non-OBU CT lists (e.g., admins)?
> Wouldn’t we like to sort by name, last-time-connected, etc.?  Can not
> supporting sorting on big data set be expressed via some combination
> of extension + node-tag, or implicitly disabled if the pre-filter
> fails to whittle the result set down to something that can be sorted
> reasonably?

I agree that this can be useful.  But as has been pointed out earlier
in this thread, sorting implies a stateful solution which will consume
more resources and probably comes with some additional complexity.

At Cisco/tail-f we implemented such a solution; a more generic "query"
mechanism, for both NETCONF and RESTCONF.  Perhaps Per A can share
some details.


> > Unless there are some important use-cases, reverse order having the
> > advantage of the same sorting mechanism/indexes, just in reverse (not
> > introducing other keys, for example)
> Sorry, I didn’t parse that.  Can you say another way?
> K.