Re: [netconf] restconf collections

Kent Watsen <> Wed, 30 September 2020 20:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 780FC3A0B60 for <>; Wed, 30 Sep 2020 13:00:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.894
X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id G_B8p5hZuwNp for <>; Wed, 30 Sep 2020 13:00:25 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 842123A0B5B for <>; Wed, 30 Sep 2020 13:00:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono;; t=1601496024; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=5+Eos4eAgb+t74MHJEAVUD8dy4Oz9Ah+fueYmGqUgr4=; b=N328ZJ7RL/SHXgY9kvO2fKFafDzvO5ibeD7G7PEWIEq3ZAR7nPyE1a2NexTryhco LraYcovpKPBEz1w7O0kegUJMdH5/QAK7u14nFqmfzCbioMVdyCoAwrvAVi4txFghFwt S94pJrLmf+Cz3RtyH0GIX6QhqIJsQxVTX5PXaNWg=
From: Kent Watsen <>
Message-ID: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_5903AA6C-4871-467D-AEBC-89074BDDB7FA"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
Date: Wed, 30 Sep 2020 20:00:24 +0000
In-Reply-To: <>
Cc: "" <>
To: Olof Hagsand <>
References: <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3608.
X-SES-Outgoing: 2020.09.30-
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 20:00:28 -0000

Hi Olaf,

> I agree sorting is less important (than a,b,e).


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

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

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


> 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?

> 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?