Re: [netconf] Adoption-suitability for draft-tao-netconf-data-export-capabilities

"" <> Tue, 18 August 2020 16:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8A0C73A0E9C for <>; Tue, 18 Aug 2020 09:23:31 -0700 (PDT)
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, 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 K0JjsnOQlCr7 for <>; Tue, 18 Aug 2020 09:23:27 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 35EEA3A0E97 for <>; Tue, 18 Aug 2020 09:23:24 -0700 (PDT)
Received: from clientip- (unknown []) by (HERMES) with SMTP id 2FBCC2800A5; Wed, 19 Aug 2020 00:23:19 +0800 (CST)
Received: from ([]) by App0021 with ESMTP id e353a56b9e334946bef3eb8056c6d473 for; Wed Aug 19 00:23:20 2020
X-Transaction-ID: e353a56b9e334946bef3eb8056c6d473
X-filter-score: filter<0>
X-MEDUSA-Status: 0
Date: Wed, 19 Aug 2020 00:23:20 +0800
From: "" <>
To: "" <>
X-Priority: 3
X-GUID: 51B0E99C-AA97-4A13-94D8-117C6CCD23C4
X-Has-Attach: no
X-Mailer: Foxmail[cn]
Mime-Version: 1.0
Message-ID: <>
Content-Type: multipart/alternative; boundary="----=_001_NextPart433504405586_=----"
Archived-At: <>
Subject: Re: [netconf] Adoption-suitability for draft-tao-netconf-data-export-capabilities
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, 18 Aug 2020 16:23:32 -0000

Dear all,

I read the draft, regarding the two questions, the comments are as follows:

1. Is the problem important for the NETCONF WG to solve?
I believe that it is important to minimize the number of subscription iterations between subscriber and publisher on which transport protocol, encoding, security parameters, compression schemes are supported, what kind of subscription policy can be composed and Random guessing of different parameters by a subscriber is not desirable according to RFC8641. Data export aim at addressing these issues. I believe that the NETCONF WG is the appropriate WG for this work. Service capability notification defined in draft-ietf-netconf-notification-capabilities has been re-factored to be more generic and provides a good basis.

2. Is the draft a suitable basis for the work?
I think this draft has been mature enough and provide a solid basis for being moved forward. If this work gets adopted, I will be glad to review any update of this draft and contribute to relate discussion.

I believe it should move forward. If the draft gets adopted, I am willing to contribute to it.

Best regards,

Yuan ZHANG 张园 

China Telecom Research Institute 中国电信研究院
Tel: +86-18918588990