Re: [netconf] Adoption-suitability for draft-unyte-netconf-udp-notif

Tianran Zhou <> Tue, 11 August 2020 02:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 498D23A0EF5 for <>; Mon, 10 Aug 2020 19:39:26 -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 SvVPGcob3r9Z for <>; Mon, 10 Aug 2020 19:39:24 -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 175D93A0EE7 for <>; Mon, 10 Aug 2020 19:39:24 -0700 (PDT)
Received: from (unknown []) by Forcepoint Email with ESMTP id B97B383B9830C20458FE; Tue, 11 Aug 2020 03:39:18 +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:39:18 +0100
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 10:39:15 +0800
Received: from ([]) by ([]) with mapi id 15.01.1913.007; Tue, 11 Aug 2020 10:39:15 +0800
From: Tianran Zhou <>
To: Mahesh Jethanandani <>, Andy Bierman <>
CC: "" <>
Thread-Topic: [netconf] Adoption-suitability for draft-unyte-netconf-udp-notif
Thread-Index: AQHWa3XJ0mBLbRaES02VUjy2aRVTDKkxPlqAgAAkPACAANHOgA==
Date: Tue, 11 Aug 2020 02:39:15 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_ec828c2e12b2460094988d84721dd7b9huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <>
Subject: Re: [netconf] Adoption-suitability for draft-unyte-netconf-udp-notif
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:39:26 -0000

Hi Andy,

Thanks Mahesh for the clarification from the chairs perspective.

And here is my clarification from the co-author perspective.
We implemented the previous solution, and contributed it to IETF.
But we dropped the solution because no customer has interest about this at that time. I do not want to waste the WG time.

We restart the draft because now several operators and customers have real requirements and use cases, and would like to work on this solution.
We reconstructed the solution with inputs, and would like to implement it to align with the changes.
We would also like to share and contribute to the community.


From: netconf [] On Behalf Of Mahesh Jethanandani
Sent: Tuesday, August 11, 2020 5:47 AM
To: Andy Bierman <>
Subject: Re: [netconf] Adoption-suitability for draft-unyte-netconf-udp-notif

Hi Andy,

On Aug 10, 2020, at 12:37 PM, Andy Bierman <<>> wrote:


I am trying to understand the NETCONF WG plan for UDP transport of notifications.

The WG was developing a UDP draft already I think, and it was dropped.

In IETF 103, there was extensive discussion on draft-ietf-netconf-udp-pub-channel, with questions raised about the scope of the draft. In IETF 105 and 106, our guidance (see meeting minutes) was to repurpose the draft for a UDP notification channel, which the WG would then ultimately adopt. This draft satisfies that request. To clarify this further, the datatracker marks the new draft as a replacement for the draft-ietf-netconf-udp-pub-channel.

Mahesh & Kent (as co-chair)

Since the WG dropped this problem and work item already, why should it reverse that decision
and start over with a new solution?


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

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

   Title: UDP-based Transport for Configured Subscriptions

      This document describes an UDP-based notification mechanism to
      collect data from networking devices.  A shim header is proposed to
      facilitate the streaming of data directly from line cards to a
      collector.  The objective is to rely on a lightweight approach to
      allow for higher frequency and better transit performance compared to
      already established notification mechanisms.

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<>
netconf mailing list<>