Re: [netconf] restconf collections

Martin Björklund <mbj+ietf@4668.se> Thu, 01 October 2020 06:33 UTC

Return-Path: <mbj+ietf@4668.se>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03FF43A0AEC for <netconf@ietfa.amsl.com>; Wed, 30 Sep 2020 23:33:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.101
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=4668.se header.b=RWzJbVi/; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=BeIUnoJT
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10EWGCzYUWSJ for <netconf@ietfa.amsl.com>; Wed, 30 Sep 2020 23:33:52 -0700 (PDT)
Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 840093A0AE3 for <netconf@ietf.org>; Wed, 30 Sep 2020 23:33:52 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id DA5665C0741; Thu, 1 Oct 2020 02:33:51 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Thu, 01 Oct 2020 02:33:51 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=4668.se; 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= messagingengine.com; 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 [158.174.4.215]) by mail.messagingengine.com (Postfix) with ESMTPA id C94243064680; Thu, 1 Oct 2020 02:33:50 -0400 (EDT)
Date: Thu, 01 Oct 2020 08:33:49 +0200 (CEST)
Message-Id: <20201001.083349.1861081830665539794.id@4668.se>
To: kent+ietf@watsen.net
Cc: olof@hagsand.se, netconf@ietf.org
From: Martin =?iso-8859-1?Q?Bj=F6rklund?= <mbj+ietf@4668.se>
In-Reply-To: <01000174e09a04a9-f53134f8-009f-4d0a-84a1-3165a494054b-000000@email.amazonses.com>
References: <01000174e0279006-63781c55-866c-4ea0-add6-a6fa8a11453c-000000@email.amazonses.com> <54cd8891-6c04-3ded-22ca-43a68ac8397f@hagsand.se> <01000174e09a04a9-f53134f8-009f-4d0a-84a1-3165a494054b-000000@email.amazonses.com>
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: <https://mailarchive.ietf.org/arch/msg/netconf/QPwt1LIAt6JItXT8LRFFdBFlIsA>
Subject: Re: [netconf] restconf collections
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Oct 2020 06:33:54 -0000

Hi,

Kent Watsen <kent+ietf@watsen.net> 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.
> (https://tools.ietf.org/html/draft-tao-netmod-yang-node-tags
> <https://tools.ietf.org/html/draft-tao-netmod-yang-node-tags>)
> 
> 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
issue.

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


/martin




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