Re: [netconf] restconf collections

Kent Watsen <> Wed, 30 September 2020 23:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4D3073A0D7A for <>; Wed, 30 Sep 2020 16:56:11 -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 E7xVL6y9FRbw for <>; Wed, 30 Sep 2020 16:56:10 -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 C396C3A09F7 for <>; Wed, 30 Sep 2020 16:56:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono;; t=1601510168; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=Bs62I5FqhP0bmhh/44o8T5Aarabj3vREREzmoVZKMlg=; b=DAzP4pNnVqc9daGR9G/Hq64xI9HVgzy3BtoMB8HJF9AFAfJufBdVHLuo2bRqIMvS GrXvcZz9Tx9lsS8uO9SnJG8gY7mLkqwNP3O6W73fEbvCXtGXKrcey0RXuMHE6xlfMeZ QwY62udMNlI69B1PiYPjC6JbN4O9KCCLczsLUYi8=
From: Kent Watsen <>
Message-ID: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_41F33E7C-8A4A-45B6-A4CC-1BC03FD79A97"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
Date: Wed, 30 Sep 2020 23:56:08 +0000
In-Reply-To: <>
Cc: Qin Wu <>, Andy Bierman <>, "" <>
To: Robert Varga <>
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 23:56:11 -0000

Hi Robert,

> It's been quite some time since I did lawyer-reading the RFCs, but for
> the sake of argument:
> - is use of hash maps for keyed lists okay, hence the sort order is the
> encounter order based on the contents?
> - if so, does that order remain the same even across server restarts?
> I am not sure what the litmus test for 'reasonable' would look like, I
> am afraid.

Perhaps it’s derived from the next sentence:

	The "description" string for the list may suggest an order
	to the server implementor.

This suggests that the intention is that servers should be able to at least *return* a stable order.   How a server achieves this (given its DB-backend, etc.) is implementation-specific.  

> If the requirement is to really just have an iterator, which breaks when
> the list changes, then a node-tag+offset would be sufficient. But then
> you could end up in a situation where you will never traverse the list
> simply because its rate of change exceeds your ability to traverse it.
> The path forks quite a bit if you want something more specific, like:
> "visit all elements in any order, i.e. additions do not break iteration".
> If we have requirements towards that level of complexity, then yes, I
> would very much prefer if there was a cursor-like resource associated
> with an ongoing pagination request.


And the tradeoffs aren’t even just "easy/potentially-imperfect" vs. "hard/perfect", as resources come into play, and the scales tip after a number of successive calls.

FWIW, for CT-queries, RESTCONF's Etag/Last-Modified tags can be used to catch a potential imperfect response.

> If I squint just a little bit, the first paginated request is not that
> different for a (one-shot) subscription to receive notification of all
> list entries. Subsequent requests are fetches from that notification
> stream... which shows my reactive systems bias :)

Yes, streaming is goodness, but there’s generally a need for the most-recent to be on-box also.  That said, we could conclude that streaming SHOULD be used to export very-fast logs and therefore easy/potentially-imperfect is “good enough” for queries.

Streaming only applies the CF lists holding time-series data (e.g., logs), which is an important part, but not the only part, being discussed.  Maybe different “requirements”, as you say, apply to CF vs CT lists?