Re: [netconf] Capability-fetching mechanisms

Wei Wang <> Wed, 12 May 2021 05:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2B2AB3A34C1 for <>; Tue, 11 May 2021 22:32:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.863
X-Spam-Status: No, score=-0.863 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FROM_EXCESS_BASE64=0.001, HTML_MESSAGE=0.001, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RDNS_DYNAMIC=0.982, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id a70TkRlWirmx for <>; Tue, 11 May 2021 22:31:57 -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 69B493A1A49 for <>; Tue, 11 May 2021 22:31:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=s201512; t=1620797513; bh=L+WFXNhVMxfrlu3zrOOQOaMserZIQXlts+po1C6nI50=; h=In-Reply-To:References:From:To:Subject:Date; b=bk1E0xPwhMivGxCjQWPY8r5dZwk213dS/kw14NoC8ItVxOzk8iO0BHEqBSravt0nJ JaQ1cmab4cFgi4Ho+568nh59R+JpZQas5C8tyjL2MOeV0TQ/knSyn48kMQF5WIRKyQ rn+MOhgz+a6/nq02p63BU1KFD1E8XSWSDvlGxidM=
X-QQ-FEAT: Kol1Dm0TdrCyBuMnE/ts1JZfIdR44peApqbeiARwk8ZxM4+4ZlnQYBs0OnaiI yB36K3pxtSY9KAhljxmZ/A8iwdpNPWanDPHPDK1oc1P6e011PAPM/oNDOgMRttOmHXxHObd qCE6+gWhoAOumCLcuW+8bCJ1zpSmcFcNXwq3al4xUcSprEgSzSbE3Cwxh01X3RC9VHpRQTy Thvd4Jm8XHxLDRQyJ2UFaETueEeZAOskb8oCXFIMOUzgx5nEPs0tRRUa4GNtuFjQeg9gP65 C+zIlrdhL/qiXR2F9C0RVkzDy26iA/EUp/XUaci4r6qm0Q6htWjUcDMeJzhUIItxKXSA==
X-QQ-SSF: 00000000000000F000000000000000L
X-QQ-XMAILINFO: MwkkaHu5BHik+TUO8PKhxaFOecYPDm0Axwjeu+rl47Hz5/6GfT+1pZ/dzW21mC p+lVRINR4ZycCRWRxh5QhZUgPaTi1igdXcxKonAbbVdXRNxhHbYrDxJjuype1mKARirFoKcpCeA7O R22XECPBpFSwc+o+G0mEV75IOpsfDdn6LUQGJ9awvjZQJ1AdWVazdZlPc2uBLMdoC2PNj7PR2n0Y6 LJYyb6Q6FpCOxsJtbJsXl4+NiXxN9uy1SD69ae/CujR/9CBuvjpSEVBlov4zwjgxPNn3R7E4wPQtX jjfq9IVqko26YhHsGCUIctlLmMnHy9TPPs/7AIc5VRMwLdddsTAS6Q0Xx9asMzfkZC8zy0vT/nEI5 yUAn8Toz6pcRvankdTCL2ClEzETiICUnnubzCs77ykAVQCLbcumxuiCn3vsZ9sibODyVe2+iBy0Cn rcxyRue8mczaekqGHQGOt6YJVw58gKNgwuXmh5A72NuxHc6jB71QEyztLcUOSquwfB1u3W+aAUfT0 9N47CiANitpopaGWysaBHYogYc0nmGb3PoYZPZLz06TctWmVVD2l15s4n83k7ZKbzEyBhbliwk+tE bWFXaeX1U6B4z5YvEryHbOw5EHXyUIptoNOVDQKWZ0DotD2nBf016VDIj6F8Z0ViFvCtmrmhWdy8U iMUDZobGpv7vmmmOSGSxdppGTp0Qfcovw8t4Zazmm1cGPUPRnZliIU7H+SAGayy6s5tbksyVd40yV 5m/C2Qp/oFJ8XB8OYL3hHIQ/mexZgXq0HjHL13bLukLK7ofS+3YoAivlmxFLVBXIK7KqpFEJ6Zzsu wWDE69nBe5vDCAcf1aYXg5FSFll0Z4CAsw==
In-Reply-To: <>
References: <>
X-QQ-mid: webmail812t1620797511t4392113
From: Wei Wang <>
To: Qin Wu <>, Kent Watsen <>, "" <>
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_609B6847_11CBDF20_7724030D"
Content-Transfer-Encoding: 8bit
Date: Wed, 12 May 2021 13:31:51 +0800
X-Priority: 3
Message-ID: <>
X-QQ-MIME: TCMime 1.0 by Tencent
X-Mailer: QQMail 2.x
X-QQ-Mailer: QQMail 2.x
X-QQ-ReplyHash: 3983706953
Received: from (unknown []) by (ESMTP) with SMTP id ; Wed, 12 May 2021 13:31:53 +0800 (CST)
Archived-At: <>
Subject: Re: [netconf] Capability-fetching mechanisms
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: Wed, 12 May 2021 05:32:03 -0000

Hi, Qin and kent:

&nbsp; &nbsp; Thanks for clarification, I feel it will be useful to have one common model to support both pull and push approach and help both the server and client know each other’s capability.

China Telecom

From:                                                                                                                        "Qin Wu"                                                                                    <;;
Date:&nbsp;Wed, May 12, 2021 09:51 AM
To:&nbsp;"Kent Watsen"<;;""<;;

Subject:&nbsp;Re: [netconf] Capability-fetching mechanisms

Hi, Kent:
Sorry for late follow up.
On Apr 19, 2021, at 5:39 PM, Kent Watsen <; wrote:
Dear WG,
One of the outcomes from “https-notif” presentation during the NETCONF 110 session was to what extent all the notif (e.g., https, udp, etc.) drafts should define their own capability-fetching mechanism, or use the mechanism  defined by the "data-export-capabilities” draft.
As authors, Mahesh and I discussed some of the PROs and CONs of the approaches as follows:
[Qin]:I am under impression that shared-mechanism has a lot of benefit.:-)
 PROs (for having a shared-mechanism):
 Enables a common mechanism spanning multiple notif transports to exist 
 CONs (against having a shared mechanism):
 Entails each receiver also needing to be a NETCONF and/or RESTCONF server
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [Qin]:Is receiver in this context NETCONF/RESTCONF server  or client? 
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; I think we mix two things, 
 a.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;  one is the server advertise its capability to the client , (i.e., server capability advertisement)
 b.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;  the other is server send the capability query request the client and get capability response from the client. (client capability fetching)
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; I think data-export-capabilities right now focuses on  (a), the question you ask here is whether (b) can be defined as shared mechanism which can be part of 
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the "data-export-capabilities” draft. If my understanding is correct, I think it will be nice to have (b) such shared  mechanism, i.e., Defining (a) and (b) in a single place.
 Whereas a notif-specific solution can be optimized on a per-protocol basis.

 FWIW, if RC, the receiver COULD minimally support *just* the single GET request (i.e., not a complete RC server)

 Still, networking/firewall would have to support the outbound NC/RC flow, in addition to the base notification flow
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [Qin]: "data-export-capabilities " draft uses draft-ietf-netconf-notification-capabilities-16  as basis or foundation. If my understanding is correct, draft-ietf-netconf- notification-capabilities-16 doesn’t 
 require receiver to support NETCONF or &nbsp; RESTCONF.
 Potentially extends the number of capabilities to be more than minimally necessary
 e.g., the current "data-export-capabilities” modules define dozens of capabilities supporting RFC 8639 and RFC 8641 that are not needed for https-notif, 
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [Qin] Dozens of capabilities defined by the current "data-export-capabilities” modules are all optional capability. It doesn’t require  all the capabilities to be supported.
 when RFC 8639 is not in use.
 HTTPS-Notif seems to need only three capabilities:
 What encodings are supported (json, xml, binary)

 If the RFC 8639 state machine is supported.

 If bundled messages is supported.
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [Qin]: So HTTPs-notif can pick those three capabilities  and ignore other capabilities. &nbsp;I believe HTTP has mechanism to deal with these unhandled capabilities advertised by the network device.&nbsp; One of such example is unhandled
 Namespace defined in (
 Presumably, UDP-Notif would similarly have a small set of capacities.
 In fact, it may be less, as UDP may be unable to support RFC 8639
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; [Qin]: See clarification above. For UDP notif, it doesn’t require all the capability  to be supported.
Kent and Mahesh &nbsp;// as authors
 netconf mailing list