Re: [netconf] restconf collections

Andy Bierman <andy@yumaworks.com> Fri, 25 September 2020 17:22 UTC

Return-Path: <andy@yumaworks.com>
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 2F9D73A1050 for <netconf@ietfa.amsl.com>; Fri, 25 Sep 2020 10:22:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.887
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.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 ncaaE8bOhfdJ for <netconf@ietfa.amsl.com>; Fri, 25 Sep 2020 10:22:23 -0700 (PDT)
Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 960853A104D for <netconf@ietf.org>; Fri, 25 Sep 2020 10:22:23 -0700 (PDT)
Received: by mail-lj1-x22a.google.com with SMTP id k25so3084764ljg.9 for <netconf@ietf.org>; Fri, 25 Sep 2020 10:22:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=edPOZn8BOSOiqPbzH0LdUWXeH0sOOBXmYllentoujvM=; b=vwJwqfCsicq6THxp60xHRJhkJvbpnwjSVQ9nNhFC/NywnIQcCe0kTnAOZGx9/7kHXz x+qoUtefLSU/ibfVovgmnEv5sjB/XjuMz2Bo55CwsKAPtUc1apdWDeKGD71ggh2RjQRS KlCh988E0gC2c/yp+C2WjfDWD1pF5oAJKOZQgSLisoIdq3jKpHCSS2/a57DGuTQCssgU BiiAip8kkZJ3a8Pu+eYHVXjFI+ZXwqOuqfTiyo7bSSuiXsZDFDZVOMZUU1v/SqIYYync 3jD0RfJW41SYilEAwUJbA8DfmLIRZeWaXqRCkXUqaAD5NK0lN6+vOAceFx3/syx9miJT QLYg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=edPOZn8BOSOiqPbzH0LdUWXeH0sOOBXmYllentoujvM=; b=KusKNL2rCLUYR5DVI90PFzwHBjDgJ4gVSwAObuWKGd8+TjQtH65dGpmkCI9FSrsugo 2A265Frci2EAH3W9v6IYvGC+hRaPx3eGJpYblRqdyH2FOz8MLJlQFybWdw9GA/oetyJa mAmvaBzcGyeuM6k656NMPvP/+G6I2QWWCz4Wotb0eytNv2k5tm6ZOpqb7Ph/FLEZQ2Ry Jjk/kHGkxczRwVUU8PENmBRQvPz2NocXO40Lfizm9s94GmB7zubNmXBI3b4DNe8lPcGX QLSNc596iZcM/RvkU49EHASkabMsnQIX429fhsA9FxP4uT8oynfRMjJRZAjnkG6hT7/s WLbQ==
X-Gm-Message-State: AOAM533kPRyGBwTqajc+qzCLot363MR6uiamQcNXXhurbvCGYXQclY/W E24XBtGHztQyujsj6JLodOj/6FNAragJtfrwNxVdqMVBEH0Nnw==
X-Google-Smtp-Source: ABdhPJyxQJ+8oSdj0d9+c2XqXFZ74nHIbmccJqWRvQhEEjtp7Csi4WINDnn5zPU9HQn4Qe6AhBDTW/tCgu5xfr8bako=
X-Received: by 2002:a2e:780d:: with SMTP id t13mr1839212ljc.324.1601054541317; Fri, 25 Sep 2020 10:22:21 -0700 (PDT)
MIME-Version: 1.0
References: <01000174c4eeb24e-c672ebe0-23a1-4f0e-afba-5b44d932e0ed-000000@email.amazonses.com> <CABCOCHQVHtS-8Yxt5=FRtfVmHJh9WAC_V3gg7fmnkTsn4oH_aw@mail.gmail.com> <01000174c631e0c3-8b790f60-b8f4-44f1-9d7f-e6a1d826ecd4-000000@email.amazonses.com>
In-Reply-To: <01000174c631e0c3-8b790f60-b8f4-44f1-9d7f-e6a1d826ecd4-000000@email.amazonses.com>
From: Andy Bierman <andy@yumaworks.com>
Date: Fri, 25 Sep 2020 10:22:10 -0700
Message-ID: <CABCOCHTAM0cxaNcb0-6kXP99+cSX9y3y5=P_y9trHTV5R+44Mg@mail.gmail.com>
To: Kent Watsen <kent+ietf@watsen.net>
Cc: "netconf@ietf.org" <netconf@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000339f0905b0268f88"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/Tdmnj5xc-DiRPUlX2DqVFUUfmko>
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: Fri, 25 Sep 2020 17:22:25 -0000

On Fri, Sep 25, 2020 at 9:56 AM Kent Watsen <kent+ietf@watsen.net> wrote:

> Hi Andy,
>
>
> This has been discussed a few times by the WG.
>
>
> Perhaps a testament to it being a real problem?
>
>
> The co-authors never agreed on the set of bells and whistles that should
> be supported.
>
>
> True, but it's more like we lost interest / time to work on it...at least
> that's my story!  ;)
>
>
> There was an objection from Phil Shafer at the time that pagination was
> not needed
> at all and handling large responses from the server was just a minor
> implementation detail.
>
>
> Clearly Phil is in the rough, as many APIs support pagination for a
> reason.   Even if constraining the solution to networking gear, interfaces
> and logs may be numerous, and on-box cli/web UIs can only show a screen
> at a time...
>
>

Our customers agree with you.  Some of them only use our <get-bulk>, and
stopped using <get> and <get-config>.
Since it is implemented as an RPC, all YANG-based protocols can use it.
Obviously you need XPath filtering (XSLT-style) to select the list entries
of interest.
Count and depth and other parameters from <get> are also useful.

(My concern is that the IETF version will be too complex to implement or
use as the feature list grows.)


IMO, it's okay if we don't support for CT-lists (i.e., interfaces).  As you
> write above, and I wrote in before, it seems like a nice-to-have.   FYI,
> I'm asking Per in a fork of this thread to justify if supporting CT-lists
> is a "must-have"...hopefully he'll come back with something compelling.
>
>
There is no extra complexity to support config vs. operational data.
I don't see the value in restricting the operation.



> CF-lists, on the other hand, can be enormous...so much so that trying to
> return all could exhaust server and/or client resources.   I think
> supporting CF-lists is a must-have.
>
>
> 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)
>
>
> True.  If we can find a way to extend support to NETCONF, all the better.
>   Of course, the solutions would be wildly different, much like how NMDA
> had separate solutions for NC and RC (RFCs 8526 and 8527, respectively).
> Perhaps Per or Martin can clue us into if they have a NC-equivalent
> solution?
>
>
It is easy. Use RPC operations which map to RESTCONF POST automatically.



> However, if NC-support cannot be achieved, then I don't think it means we
> don't do it for RC.   Much like NC supports somethings RC doesn't (e.g.,
> confirmed commit), each protocol plays into its strengths.   So mote it be.
>
>
> Andy
>
>
> K.
>
>
>
Andy