[netconf] some comments on netconf-adaptive-subscription

Michael Richardson <mcr+ietf@sandelman.ca> Thu, 24 June 2021 19:15 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 5E77D3A27F5; Thu, 24 Jun 2021 12:15:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 Zyrkn1vGMaqi; Thu, 24 Jun 2021 12:14:57 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79F5A3A28D7; Thu, 24 Jun 2021 12:14:40 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id EA37038BAD; Thu, 24 Jun 2021 15:16:21 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id umpEeHiBq0DK; Thu, 24 Jun 2021 15:16:20 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id E157138B34; Thu, 24 Jun 2021 15:16:19 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 6336763B; Thu, 24 Jun 2021 15:14:35 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Qin Wu <bill.wu@huawei.com>, netconf@ietf.org
CC: core@ietf.org
In-Reply-To: <5ba27e43a63e427091f3093b35be09a0@huawei.com>
References: <5ba27e43a63e427091f3093b35be09a0@huawei.com>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature"
Date: Thu, 24 Jun 2021 15:14:35 -0400
Message-ID: <14286.1624562075@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/x7DALsLzS38LCV9E_lZTucQxRzI>
Subject: [netconf] some comments on netconf-adaptive-subscription
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: Thu, 24 Jun 2021 19:15:03 -0000

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?

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

--
]               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