Re: [netconf] Capability-fetching mechanisms

"maqiufang (A)" <> Wed, 12 May 2021 06:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CDCEA3A374B for <>; Tue, 11 May 2021 23:54:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=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 PzAN7HmhuPaJ for <>; Tue, 11 May 2021 23:54:47 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8F3283A374A for <>; Tue, 11 May 2021 23:54:46 -0700 (PDT)
Received: from (unknown []) by (SkyGuard) with ESMTP id 4Fg4xS1TbSz6tmqx for <>; Wed, 12 May 2021 14:43:24 +0800 (CST)
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.2176.2; Wed, 12 May 2021 08:54:41 +0200
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2176.2; Wed, 12 May 2021 14:54:39 +0800
Received: from ([]) by ([]) with mapi id 15.01.2176.012; Wed, 12 May 2021 14:54:39 +0800
From: "maqiufang (A)" <>
To: Wei Wang <>, Qin Wu <>, Kent Watsen <>
CC: "" <>
Thread-Topic: [netconf] Capability-fetching mechanisms
Thread-Index: AddG0HdnSNhQPyUmB0iwqeRmQPitBf//uS2A//9kl9A=
Date: Wed, 12 May 2021 06:54:39 +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_3a058efa22df47239b8d016c6ba9e431huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
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 06:54:52 -0000

Hi, folks,

Since data-export-capability draft defines a mechanism to discover a set of capabilities supported by the NETCONF/RESTCONF server(the network device, actually).

But in the http-notif draft, what we need to discover is the receiver's capabilities, rather than the device’s.

So I think the reason Kent said that the receiver must also be a NETCONF and/or RESTCONF server is that only in this case can the data-export-capability draft be used as capability discovery on the http-receiver side.

Please correct me if there exists any misunderstanding.-:)

From my perspective, The data-export-capability does not have to require the receiver to function as a NETCONF/RESTCONF server. The capability discovery mechanism in these two drafts can complement each other in this case. In other cases, data-export-capability provides the receiver with an overall  acquisition of the transport capabilities about the device.

From: netconf [] On Behalf Of Wei Wang
Sent: Wednesday, May 12, 2021 1:32 PM
To: Qin Wu <>om>; Kent Watsen <>et>;
Subject: Re: [netconf] Capability-fetching mechanisms

Hi, Qin and kent:

    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

------------------ Original ------------------
From: "Qin Wu" <<>>;
Date: Wed, May 12, 2021 09:51 AM
To: "Kent Watsen"<<>>;"<>"<<>>;
Subject: 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
                                [Qin]:Is receiver in this context NETCONF/RESTCONF server or client?
                                  I think we mix two things,

a.      one is the server advertise its capability to the client , (i.e., server capability advertisement)

b.      the other is server send the capability query request the client and get capability response from the client. (client capability fetching)
                                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
                                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
                   [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   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,
                                     [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.
                                  [Qin]: So HTTPs-notif can pick those three capabilities and ignore other capabilities.  I believe HTTP has mechanism to deal with these unhandled capabilities advertised by the network device.  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
             [Qin]: See clarification above. For UDP notif, it doesn’t require all the capability to be supported.


Kent and Mahesh  // as authors

netconf mailing list<>