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

Tianran Zhou <> Mon, 17 August 2020 03:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 289793A0866 for <>; Sun, 16 Aug 2020 20:23:48 -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 boUm2K7OF81n for <>; Sun, 16 Aug 2020 20:23:46 -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 C446E3A0865 for <>; Sun, 16 Aug 2020 20:23:45 -0700 (PDT)
Received: from (unknown []) by Forcepoint Email with ESMTP id 32B3A889E4105D792505; Mon, 17 Aug 2020 04:23:44 +0100 (IST)
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Mon, 17 Aug 2020 04:23:43 +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; Mon, 17 Aug 2020 11:23:40 +0800
Received: from ([]) by ([]) with mapi id 15.01.1913.007; Mon, 17 Aug 2020 11:23:40 +0800
From: Tianran Zhou <>
To: Andy Bierman <>, Mahesh Jethanandani <>
CC: "" <>
Thread-Topic: [netconf] Adoption-suitability for draft-unyte-netconf-udp-notif
Thread-Index: AQHWa3XJ0mBLbRaES02VUjy2aRVTDKkxPlqAgAAkPACABk8RgIAD/vmA
Date: Mon, 17 Aug 2020 03:23:40 +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_1b59196e6b3347e7b6eaf5aa4fa6ffe0huaweicom_"
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: Mon, 17 Aug 2020 03:23:48 -0000

Hi Andy,

Thank you very much for your interest.
The two drafts was one when it first came out.
We split it based on the WG discussion, so that the distributed-notif can also serve the tcp based notif.

Current distributed-notif solution depends on draft-ietf-netconf-notification-messages. But I believe draft-ietf-netconf-notification-messages tries to solve more problems in addition to distributed-notif.

On your suggestion, I think we can work on an profile or applicability, to see how they can work together.


From: netconf [] On Behalf Of Andy Bierman
Sent: Saturday, August 15, 2020 6:08 AM
To: Mahesh Jethanandani <>
Subject: Re: [netconf] Adoption-suitability for draft-unyte-netconf-udp-notif

On Mon, Aug 10, 2020 at 2:47 PM Mahesh Jethanandani <<>> wrote:
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.

I support adoption of this draft.
I am willing to work on the document, review it, and implement it.
Hopefully the authors will add an example of a notification in each encoding soon.

IMO there really should be 1 RFC that combines these documents:


The single source vs. multi-source distinction does not really require separate documents.
General one-size-fits-all notification headers are too inefficient to use in
a high performance telemetry system.  Not sure where notification-messages will ever get used.
IMO these 3 documents could be a good protocol, if combined and focused correctly.

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