Re: [netconf] I-D Action: draft-ietf-netconf-https-notif-08.txt

Qin Wu <> Tue, 09 March 2021 03:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D46333A0CB8 for <>; Mon, 8 Mar 2021 19:25:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id X6ZDyFKSK-At for <>; Mon, 8 Mar 2021 19:25:26 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B443B3A0CB7 for <>; Mon, 8 Mar 2021 19:25:25 -0800 (PST)
Received: from (unknown []) by (SkyGuard) with ESMTP id 4DvgPF2Q9hz67wst; Tue, 9 Mar 2021 11:17:21 +0800 (CST)
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2106.2; Tue, 9 Mar 2021 04:25:19 +0100
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.2106.2 via Frontend Transport; Tue, 9 Mar 2021 04:25:19 +0100
Received: from ([]) by ([fe80::74d9:c659:fbec:21fa%31]) with mapi id 14.03.0513.000; Tue, 9 Mar 2021 11:25:16 +0800
From: Qin Wu <>
To: Mahesh Jethanandani <>, "" <>
Thread-Topic: [netconf] I-D Action: draft-ietf-netconf-https-notif-08.txt
Thread-Index: AdcUjigDoxhQ3oCcQuu/YHKBXSbk0w==
Date: Tue, 09 Mar 2021 03:25:15 +0000
Message-ID: <>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABAADE4CAA7dggeml511mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <>
Subject: Re: [netconf] I-D Action: draft-ietf-netconf-https-notif-08.txt
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, 09 Mar 2021 03:25:30 -0000

Hi, Mahesh:
I am thinking whether rfc8639<>-enabled should be listed as encoding related capability, which is a little weird to me and I think it is different xml encoding, json ecoding, I believe this has been brought up in yesterday meeting at the end of presentation.
Also for Publisher to receiver interaction it is not clear why the second target resource is called “relay-notification”? What relay means in this HTTP notif context?

As for capability discovery and advertisement proposed in draft-ietf-netconf-https-notif-08 and draft-tao-netconf-data-export-capabilities<>, I believe I raised issues for discussion when both work are under progress, my impression, is
Both are one way message, used in different scenario which can be complementary. Now this issue has been brought up again in yesterday netconf session. The question is whether should take holistic way to handle the capability.

I think
1.http notif  defines receiver capability discovery which allow publisher discover what encoding is supported by the receiver, export capabilities define data export capability advertisement which is built on top of server capability advertisement
specified in draft-ietf-netconf-notification-messages<>. Data export capability draft allow the receiver to learn the server capability
including transport protocol, encoding format.
Commonality for these capability discovery or advertisement is both are one way message.
The difference is data export capabilities define generic mechanism can work together with RFC8639 and UDP Notif draft,
RFC8639 “2.4.2.  Establishing a Dynamic Subscription” said:
If the transport used by the RPC supports multiple encodings, an
      optional "encoding" for the event records pushed.  If no
      "encoding" is included, the encoding of the RPC MUST be used.
So data export capabilities advertise multiple encodings from the server to the client, the client can use RFC8639 Dynamic subscription to select the encoding advertised by the server or configure the client favored encoding on the server.
So does the UDP notif, the server advertises multiple encoding support the client, the client use RFC8639 Dynamic Subscription to select encoding advertised by the server or configure client favored encoding on the server.

If we consider to use server capability advertisement in data export capability draft together with receiver capability in http notif together, I think we should focus on non-RFC8639 capability case, in such case,
The server can use a single message not only advertise the what encoding is supported by the server but also request the encoding supported by the client, This seems to provide more control to the publisher to control the encoding to be used rather than provide control to the client and allow the client configure encoding support for the transport designed for publisher. I am not sure whether this case makes sense, this needs to be investigated.

发件人: netconf [] 代表 Mahesh Jethanandani
发送时间: 2021年2月23日 7:39
主题: Re: [netconf] I-D Action: draft-ietf-netconf-https-notif-08.txt

Hi WG,

The authors believe that this version of the draft addresses comments received during LC.


On Feb 22, 2021, at 3:33 PM,<> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network Configuration WG of the IETF.

       Title           : An HTTPS-based Transport for YANG Notifications
       Authors         : Mahesh Jethanandani
                         Kent Watsen
  Filename        : draft-ietf-netconf-https-notif-08.txt
  Pages           : 27
  Date            : 2021-02-22

  This document defines a protocol for sending notifications over
  HTTPS.  YANG modules for configuring publishers are also defined.
  Examples are provided illustrating how to configure various

  This document requires that the publisher is a "server" (e.g., a
  NETCONF or RESTCONF server), but does not assume that the receiver is
  a server.

The IETF datatracker status page for this draft is:

There are also htmlized versions available at:

A diff from the previous version is available at:

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at

Internet-Drafts are also available by anonymous FTP at:

netconf mailing list<>

Mahesh Jethanandani<>