Re: [netconf] Adoption-suitability for draft-wang-netconf-adaptive-subscription

Qin Wu <> Tue, 11 August 2020 02:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 288373A0EEA for <>; Mon, 10 Aug 2020 19:34:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-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 F_gyp-Q56b_G for <>; Mon, 10 Aug 2020 19:34:29 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 00B7B3A0DF7 for <>; Mon, 10 Aug 2020 19:34:29 -0700 (PDT)
Received: from (unknown []) by Forcepoint Email with ESMTP id 76D3329E96A7E9F65ACB for <>; Tue, 11 Aug 2020 03:34:27 +0100 (IST)
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Tue, 11 Aug 2020 03:34:26 +0100
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1913.5 via Frontend Transport; Tue, 11 Aug 2020 03:34:26 +0100
Received: from ([]) by ([]) with mapi id 14.03.0487.000; Tue, 11 Aug 2020 10:34:22 +0800
From: Qin Wu <>
To: Andy Bierman <>, Kent Watsen <>
CC: "" <>
Thread-Topic: [netconf] Adoption-suitability for draft-wang-netconf-adaptive-subscription
Thread-Index: AdZvhfX1gq2ykwPUQ5qu3a8I9wZYeA==
Date: Tue, 11 Aug 2020 02:34:22 +0000
Message-ID: <>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABAAD8FACB0dggeml511mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <>
Subject: Re: [netconf] Adoption-suitability for draft-wang-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: Tue, 11 Aug 2020 02:34:31 -0000

I fully agree there is limitation for the current filter and trigger mechanisms when we implement YANG push mechanism in our products.
We do implement this feature in our product.
We see a lot of similar implementations which try to address some of these challenges, e.g., adaptive sampling implemented
by Microsoft in Azure, Event based telemetry proposed by many different vendors,
I am hoping we need to keep on working on ECA model and align this draft with ECA.  low hanging fruit is not far from us,:-).
I also hope who are interested to tackle this issue can join and work together. We need to seek common ground while reserving differences.

发件人: netconf [] 代表 Andy Bierman
发送时间: 2020年8月11日 3:40
收件人: Kent Watsen <>
主题: Re: [netconf] Adoption-suitability for draft-wang-netconf-adaptive-subscription


I am trying to understand the problem statement in this draft.
It appears to propose a complex self-monitoring system so that YANG Push
subscriptions can change their parameters on the fly to adapt to
changing network conditions. E.g. lower the 'period' parameter when
conditions are right, to produce more push-update records than normal.

The problem is somewhat interesting.
The filtering mechanisms in YANG Push are really awful and there is a need
to improve both filter and trigger mechanisms.  I don't think this draft offers
a reasonable solution, but I encourage further experimentation.
Prove it works in real products then maybe it will be ready for standardization.


On Wed, Aug 5, 2020 at 3:18 PM Kent Watsen <<>> wrote:

Per the previous email sent moments ago, the chairs would like to solicit input on the following draft:

   Title: Adaptive Subscription to YANG Notification
      This document defines a YANG data model and associated mechanism
      enabling subscriber's adaptive subscriptions to a publisher's event
      streams at various different period intervals with which to report
      updates.  Applying these elements allows both subscriber and
      publisher to automatically adjust the volume of telemetry traffic
      sent from publisher to the receivers.

In particular, please discuss adoption-suitability as it regards to the following questions:

    1) is the problem important for the NETCONF WG to solve?
    2) is the draft a suitable basis for the work?

PS: this message is itself not an adoption poll, but rather an attempt to gauge interest/support for a potential future adoption poll.

netconf mailing list<>