Re: [netconf] restconf collections

Kent Watsen <> Tue, 29 September 2020 21:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7AC883A0C94 for <>; Tue, 29 Sep 2020 14:56:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 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_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 h5ENQ2_xrWlD for <>; Tue, 29 Sep 2020 14:56:41 -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 F35143A0C7A for <>; Tue, 29 Sep 2020 14:56:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono;; t=1601416599; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=KF31aAdDkIa0lbHe1RiY7qRqwdrrnBwBJmkfZyG0ZXQ=; b=A6rlD1Qd2oZXyqdsuNUUXR24rI0ZZvcBY9zZ45VB3i1sQJr4kUR0SgQFLhXMw2U+ eAxW+V8OrwVdaNRwQlRv9lnU5/babVwtC+VDAx/KTaSoyhq45ev2z5DlkkVZpRqqP7y wNunYt9ANAa7qLzbpmysCcHY7jAF4jCB9upkr9fQ=
From: Kent Watsen <>
Message-ID: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_4EEBF8F0-A620-479E-92E7-8805CFB43A8C"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
Date: Tue, 29 Sep 2020 21:56:39 +0000
In-Reply-To: <>
Cc: "" <>
To: Martin Björklund <>
References: <> <> <> <>
X-Mailer: Apple Mail (2.3608.
X-SES-Outgoing: 2020.09.29-
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: Tue, 29 Sep 2020 21:56:43 -0000

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

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