Re: [core] some comments on netconf-adaptive-subscription

Andy Bierman <andy@yumaworks.com> Fri, 25 June 2021 00:56 UTC

Return-Path: <andy@yumaworks.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A11C3A31F7 for <core@ietfa.amsl.com>; Thu, 24 Jun 2021 17:56:11 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable 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 HXoPn7Pf9Qrg for <core@ietfa.amsl.com>; Thu, 24 Jun 2021 17:56:05 -0700 (PDT)
Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (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 E9E463A31F8 for <core@ietf.org>; Thu, 24 Jun 2021 17:56:04 -0700 (PDT)
Received: by mail-lj1-x22f.google.com with SMTP id d2so10246204ljj.11 for <core@ietf.org>; Thu, 24 Jun 2021 17:56:04 -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=SQy6StQU3uZn8R/PmCSK5VavK6G+vxD67aEl0yPTPn0=; b=0NAkdvnEcSDjFbUBe9KvbH12nBjWaSBH75x3VSdHB8QXL0UxURI/Kk9TRfvmZBb5nO lGyv7zdusOeJF6iF3Eu24eAxkz2df+IzQqTSEBetIt5t6mw+FXjp2MOGBg1Eq7T/tG57 dCOXKqgbm9iJ3kvrtRe9iPu7R2HcfPcim3aO8xxs5V30Dw1L6zPJUPZniBDreZmGEZhm RSV2MMFvzTPNWyXyHGYNfd7SkTgUpDls5eQu+3Mc5sZVggAjmS5MHwfMPb81qBPna5EG lEgVpkoSwHvwTmrWgA46QKLKp9798tJgigXovMq8J+Z8qZFMWK4Yzk0i7wGhIB2a01Fa kxwQ==
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=SQy6StQU3uZn8R/PmCSK5VavK6G+vxD67aEl0yPTPn0=; b=GJ8jDU4/dWg4A0S85+OZ3p2z8g5vxSM6K5c337hRhgYusAt9hJyeEwrnrsqJbnkHSq 2X79B9geiXBNG5T7RJfQRXF1n8GSgzdwpy/ZuZArjx9v0fciStwHfpOuaehorLb8WGqO D68eSbUZb/uob9hKRhszuHTIc2M+Y5mFaHRv0NuSSfzz5vUZz0D8Jf4+Q/y19xH7FoeO 8l3/QDNvoND8gD/gR6ZnOKuED9Dgg8wL87D0izuavYxAcc2DxAV9OIE0xjsE8k1Tuhy8 g+F2zq1XAPp4s7gyHcYjq5Asm1/lKH8HyVc5JJqusTIoTjSALE3jvn6kqLsScBTw1v4d kVtg==
X-Gm-Message-State: AOAM533ArXl93nCufU1glM9ItjcbBBh8iWAj0/BDvhsOGI3s3To4taMx mOLRPQEaXGksrbUm9GY1ku02MDJpMWxDACsdZiybaA==
X-Google-Smtp-Source: ABdhPJzS7ZKzmSQ53eVoP56k72vvUm/TjMod//0xu7DCXgroJJHgKUowlwILBIL4EAk5P8uefjBNDaiEuWFpzwqIcRY=
X-Received: by 2002:a2e:9297:: with SMTP id d23mr5902837ljh.160.1624582562195; Thu, 24 Jun 2021 17:56:02 -0700 (PDT)
MIME-Version: 1.0
References: <5ba27e43a63e427091f3093b35be09a0@huawei.com> <14286.1624562075@localhost>
In-Reply-To: <14286.1624562075@localhost>
From: Andy Bierman <andy@yumaworks.com>
Date: Thu, 24 Jun 2021 17:55:51 -0700
Message-ID: <CABCOCHTCOvDYXc1LiKXspbHdyQzf0Ftv1V1nGdcg=PHD9YoXMA@mail.gmail.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>
Cc: Qin Wu <bill.wu@huawei.com>, Netconf <netconf@ietf.org>, Core <core@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000873f7805c58c9ad8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/l95AE-nJm_aMKmphyOVY2P4Fs6I>
Subject: Re: [core] some comments on netconf-adaptive-subscription
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 25 Jun 2021 00:56:11 -0000

On Thu, Jun 24, 2021 at 12:15 PM Michael Richardson <mcr+ietf@sandelman.ca>
wrote:

>
> I read:
>         Title           : Adaptive Subscription to YANG Notification
>         Filename        : draft-wang-netconf-adaptive-subscription-05.txt
>
> today.  I understand the need for some kind of way to switch between
> some kind of periodic capture of value vs a edge-triggered/on-change
> process.
>
> I'm a bit surprised that the example-wifi-mac module had to be created in
> the
> appendix to provide an example.  Surely we should already have likely
> modules that are really being used and need this kind of thing.
> So one recommendation is that the document focus on already published YANG
> models that could benefit from this kind of subscription.
> (Perhaps the wifi-mac module is something that also needs to exist, and
> does
> not.  I will note that CHIP/MATTER has some kind of WIFI statistics module,
> but it's not presently written up in YANG)
>
> I had to back to RFC8641, which I don't know well at all, to be sure I
> understood the xpath criteria.  I guess I don't understand how RFC8641 and
> this document can be used for non-XML serialized YANG interactions.
>
> If bandwidth is at a premium, wouldn't you want to use
> draft-ietf-core-comi-11
> (YANG in CBOR) rather than XML?
> At which point, the obvious interaction with RFC7641 would need to be
> explained?
>
>

Commenting only on the use of CORECONF, not this draft...
IMO CORECONF is for constrained devices, possibly on constrained networks.
But if only the network is constrained, then perhaps only CBOR is really
needed.

E.g., Use RESTCONF and support "application/yang-data+cbor" in the Accept
and Content-Type headers.
Expect developers to use this media type in creative ways ;-)



It seems that the netconf (RESTCONF) and CORECONF groups should spend some
> more time together.
>

I first raised these issues in NETCONF WG in 2013
https://datatracker.ietf.org/doc/html/draft-bierman-netconf-efficiency-extensions-00

There was not then (or is now) much interest in minimizing resources used
by NETCONF.
The WG rejected other efforts as well
https://datatracker.ietf.org/doc/html/draft-mahesh-netconf-binary-encoding-00

IMO the WG missed the point of this draft, which was to preserve the
massive and expensive
investment in the NETCONF application layer already deployed. Just optimize
the network traffic
and not rewrite any feature code.


Andy


> --
> ]               Never tell me the odds!                 | ipv6 mesh
> networks [
> ]   Michael Richardson, Sandelman Software Works        |    IoT
> architect   [
> ]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on
> rails    [
>
>
>
>
>
>
> --
> Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
>            Sandelman Software Works Inc, Ottawa and Worldwide
>
>
>
>
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core
>