Re: [netconf] restconf collections

Andy Bierman <> Fri, 25 September 2020 16:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2FCB63A0E03 for <>; Fri, 25 Sep 2020 09:00:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.887
X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6rNihwZ89i9E for <>; Fri, 25 Sep 2020 09:00:19 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6A2EC3A1192 for <>; Fri, 25 Sep 2020 09:00:05 -0700 (PDT)
Received: by with SMTP id a22so2860082ljp.13 for <>; Fri, 25 Sep 2020 09:00:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0mKLyAZiFoGB6Bci/c083fp/zAHhRU2swC4i0bsrdFE=; b=ud3jm2EQgv0HMIvv4Xl7M/C42XgB3smhULGpnE1eLPPOIldw+WlMLQjrv+/7vyWf9h 2658Tkyl5voAVjqntk+/8ZPVCPdCbAK44LGNzww77l/koZSJvcrzJUyDFCbXjG17wyGu 43MQWHsvxTRnF/iwvRjcKiioO6tMu+Oo1UlF6+w+gGidW3GbqXATP0vbfXnJGzuTVAUm 7nLec5h9BuP/c7tRf4Vs08hGgzUK+GpdI8ofDy49D9KuvmUnOV2WZMBvAGPuIIUgpEv5 Ef2bw7EzGmabE71Ylv3qFvFr8SWL0X2ph4V8tr4CKVzgLTvPVxAUmk+B5NoDfC0d//T0 oamg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0mKLyAZiFoGB6Bci/c083fp/zAHhRU2swC4i0bsrdFE=; b=A7UPh+JbRuqrJdfq+YqMVctZz83mrujXhDY1VhuGVCWPrNMhfLftlBqCwuAjdx/bX/ TasVeANyiPrTFRMrx/GcDAycmHmYgbDPqfevr/Utc81Eoz+lkBzUhWBblMbYE7OQ8HXX 5Nav+gJll5aUE9EnJYz65oTORqb1G/NAlFt5oxc+awVqi6nRs994n5W0CeQem4azo0I5 yd8XopFHhdvy9SHBpoLmfMK0BfCvqkH5I/BiXTjlick7zcOB5gdg5hUyV+/r9eMK/moD EYYbk4uW2j6bTl4yM3wn77jx8aCNCTVuUmyB3IhXZNKwbOSE0pQpDTZ7WL741jGPCl04 rpnw==
X-Gm-Message-State: AOAM530xV5+PtOcrKyCxu280OBNMYZ+RgZGFP0fxNdeS9emUu+EEGhMb hidy6nXRzvnnlV5JcB3fviVx2dd43uzejaJI6aDj/iP/663T5Q==
X-Google-Smtp-Source: ABdhPJyP0cc9+eQfz6k74CxkDM+DHKSvXq0R7y119UE16bUNS9+64bxZWxZbzdnXRZM+ylsCfTOOa1stauhngabIH8U=
X-Received: by 2002:a2e:4e01:: with SMTP id c1mr1534413ljb.144.1601049603381; Fri, 25 Sep 2020 09:00:03 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Andy Bierman <>
Date: Fri, 25 Sep 2020 08:59:52 -0700
Message-ID: <>
To: Kent Watsen <>
Cc: "" <>
Content-Type: multipart/alternative; boundary="000000000000e0af4005b0256802"
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: Fri, 25 Sep 2020 16:00:21 -0000


This has been discussed a few times by the WG.
The co-authors never agreed on the set of bells and whistles that should be
There was an objection from Phil Shafer at the time that pagination was not
at all and handling large responses from the server was just a minor
implementation detail.
The most significant objection was that this is a RESTCONF-only solution
and that
was not acceptable to ignore NETCONF (since <get> and GET end being the same
in the end, so the problem also exists for NETCONF)


On Fri, Sep 25, 2020 at 4:03 AM Kent Watsen <> wrote:

> 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]
> _______________________________________________
> netconf mailing list