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

Qin Wu <> Fri, 25 June 2021 16:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 864253A09C1; Fri, 25 Jun 2021 09:37:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QehzDcMD-uC1; Fri, 25 Jun 2021 09:37:10 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 61A093A09BB; Fri, 25 Jun 2021 09:37:10 -0700 (PDT)
Received: from (unknown []) by (SkyGuard) with ESMTP id 4GBMkY05Ngz6L52v; Sat, 26 Jun 2021 00:23:33 +0800 (CST)
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.2176.2; Fri, 25 Jun 2021 18:37:06 +0200
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2176.2; Sat, 26 Jun 2021 00:37:04 +0800
Received: from ([]) by ([]) with mapi id 15.01.2176.012; Sat, 26 Jun 2021 00:37:03 +0800
From: Qin Wu <>
To: Michael Richardson <>, "" <>, "" <>
Thread-Topic: some comments on netconf-adaptive-subscription
Thread-Index: Addp3Xbz9EsUzJGVQoilQopppt0Pig==
Date: Fri, 25 Jun 2021 16:37:03 +0000
Message-ID: <>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <>
Subject: Re: [netconf] some comments on netconf-adaptive-subscription
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 Jun 2021 16:37:16 -0000

发件人: Michael Richardson [] 
发送时间: 2021年6月26日 0:10
收件人: Qin Wu <>om>;;
主题: Re: some comments on netconf-adaptive-subscription

Qin Wu <> wrote:
    > [Qin]: That's a good suggestion, WiFi provides a good use case for this
    > adaptive subscription mechanism. we did try some existing published
    > YANG models, but it seems YANG models size is too big.  That's why we
    > create simplified Wifi mac example Module. If you can provide a link to
    > CHIP/MATTER WIFI statistics module, we are happy to quote that existing
    > module.

The CHIP/MATTER document not public yet, but Huawei is a member and can get the document.
But, it's not a YANG module.  The fact that they have a set of wifi statistics in their base definition argues that there ought to be an equivalent YANG model though.

[Qin]:Thanks, I will take a look at it and see if something can be reused.

    > [Qin]: The intention is to optimize the existing YANG push mechanism
    > for NETCONF/RESTCONF and other management protocols. And the network
    > device can support multiple capture periodic intervals, the mechanism
    > we introduce is to allow the network device switch to different capture
    > periodic interval automatically without asking the NMS for permission
    > each time. I hope this clarifies.

yes, I understood that from the document.

    > [Qin]: I am also hoping RESTCONF and CORECONF can work together, but
    > they seems to look into different use cases (constrained device
    > management vs unconstrained device management) .  I am not sure we
    > should generalized RESTCONF and CORECONF into a single protocol.

That's not what I'm suggesting.
I'm asking, if bandwidth is an issue, why not use a smaller encoding.
[Qin]: For YANG push, usually the server learns the encoding supported by the client at the beginning of the management session. Two relevant drafts are:
I am not sure we can switch encoding in the middle of session, which probably needs to tear down the session and loss the service continuity.
For the network device support multiple capture periodic intervals, switch the interval is cheap and doesn't cause the session to be interrupted.
That is why we not consider a smaller encoding in the solution.
And, why not integrate with CoAP Observe?
[Qin]: I have a quick look at COAP Observe. I see the commonality between CoAP Observer and this draft is 
The server or network device in both cases, need to send notification to the client to inform the current temperature or subscribed data.
The client in both case needs to observer resource change or data change in the server.
But the difference is the server in adaptive-subscription draft has some control and can switch capture periodic interval. In addition, the server in the adaptive-subscription draft
Can send interval switching notification to the client.
So based on this analysis, I believe CoAP Observe has been integrated into this draft which is similar to what RFC8641 specifies (i.e., Pub Sub mechanism).

Michael Richardson <>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide