[netconf] restconf collections

Kent Watsen <kent+ietf@watsen.net> Fri, 25 September 2020 11:03 UTC

Return-Path: <01000174c4eeb24e-c672ebe0-23a1-4f0e-afba-5b44d932e0ed-000000@amazonses.watsen.net>
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 9B0953A1361 for <netconf@ietfa.amsl.com>; Fri, 25 Sep 2020 04:03:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.916
X-Spam-Level:
X-Spam-Status: No, score=-1.916 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.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com
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 ipnOHVCA_neA for <netconf@ietfa.amsl.com>; Fri, 25 Sep 2020 04:03:33 -0700 (PDT)
Received: from a48-92.smtp-out.amazonses.com (a48-92.smtp-out.amazonses.com [54.240.48.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4A113A1360 for <netconf@ietf.org>; Fri, 25 Sep 2020 04:03:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1601031811; h=From:Content-Type:Mime-Version:Subject:Message-Id:Date:To:Feedback-ID; bh=WUjay43KW1TsomkSKH36Y5FHKENKsTKrnfGbcShFn20=; b=OCZkIO3EadKOwo2pOV3kIdJ649qVvQcdn2mNrfFvYZdgt2HfGgxPl3ER0gM0779W IGc/aiEjkDnoPnSfYy9SjSLcKdARcwEOk5hsHCPD24FOiTi8/XcD21hu68EWaDPBXmS DjGLxYMs6mJC7q0uqk9AO9KatO7ChguotMLfw5Y8=
From: Kent Watsen <kent+ietf@watsen.net>
Content-Type: multipart/alternative; boundary="Apple-Mail=_45FD12B9-D9D9-49E1-B793-7D7152CF644C"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Message-ID: <01000174c4eeb24e-c672ebe0-23a1-4f0e-afba-5b44d932e0ed-000000@email.amazonses.com>
Date: Fri, 25 Sep 2020 11:03:31 +0000
To: "netconf@ietf.org" <netconf@ietf.org>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
X-SES-Outgoing: 2020.09.25-54.240.48.92
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/lGTR-w942S9u6xxQiRasa5-V5Zo>
Subject: [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: Fri, 25 Sep 2020 11:03:35 -0000

The restconf-collections draft [1] expired long ago, and yet the problem remains.

What is the problem?  In my opinion, the problem is more narrow in scope than before.  Specifically, I feel that it is limited to just "config false" lists, which tend to contain an enormous number entries.  Classic examples include "audit logs" and "device logs".

I do not feel that "config true" lists are a problem because 1) if it's possible for the client to configure a list, then it should be no problem for the client to handle getting it back and 2) clearly this is what everyone is doing today, unless using proprietary solutions, as RFC 8040 offers no option.

It's understood that supporting "config true" lists could improve performance some, but this seems more like a "nice to have" compared to supporting "config false" lists, where returning all list entries in a single response risks exhausting internal memory buffers resulting in failures, and thus solving this problem seems more of a "must have".  Not to mention, handling "ordered-by user" lists would be very difficult.

[As an aside, how are people handling large "config false" lists today?  Is each list-entry streamed out as a "notification"?  Isn't there still always a need to have at least the most-recent list entries, which could still be a lot, on the server?]

The net-net is that I'm thinking we should brushoff the restconf-collections draft, and I'm wondering to what extent the WG agrees.

Anyone?


Regarding solution, I suggest a two-fold approach:

  1) only support query parameters (e.g., offset, limit, sort, where) if a "config false" list is queried directly.  E.g., GET {+restconf}/ds/ietf-datastores:operational/example-module:widgets/widget?offset=20?limit=50.  Note that RESTCONF does not allow the list itself to be a resource target is exactly why this makes sense.

  2) any "config false" list that is a descendent of the resource target returns a placeholder response, rather than its contents.  Specifically, a top-level query on <operational> would NOT return any "config false" list entries.  As for the placeholder response, perhaps it could return metadata, something like: { "example-module:widgets": { "widget": [ { "@": { "ietf-collections:redacted": [None] } } ] } }.  To be backwards-compatible, it could be this list "entry" is only returned if the client sends a special query parameter (e.g., ?collections-supported) or, alternately, the server implicitly always only returns at most one list-entry (e.g., as if ?limit=1 was passed).


Comments?

K.


[1] https://datatracker.ietf.org/doc/draft-ietf-netconf-restconf-collection <https://datatracker.ietf.org/doc/draft-ietf-netconf-restconf-collection>