Re: [netconf] Capability-fetching mechanisms

Mahesh Jethanandani <> Mon, 17 May 2021 21:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6D81C3A4641 for <>; Mon, 17 May 2021 14:47:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 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_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HTsz97CglGge for <>; Mon, 17 May 2021 14:47:52 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::102c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 61E1E3A463D for <>; Mon, 17 May 2021 14:47:52 -0700 (PDT)
Received: by with SMTP id b15-20020a17090a550fb029015dad75163dso421012pji.0 for <>; Mon, 17 May 2021 14:47:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=/TAxNwNcXotvg5+0E02/5KgFy5gFJHzNTxAk4IdtRtw=; b=O2fY02DA5rynEK2Tbsezg4KYXlt7aZd0x0VvZjfCZUkazUcVxYbTccVrHD3K0pP2Ze O97Gj+CmoLZa8sOqOzPBXyl6mZimYNufh1m/ySkO2WAAPZrD3rMwl6UFWnKPKRWrlVjf EvPpaEAGhIyT7ePMd5q5WwtYsaPhkNERcXIhp8o9XR22BezwWUKK1wxmwDDe23wfIEf1 xxb3EJ5iRXO0FlyIzX7NuZB4og0IBx3ybCffmqcwPTfGPY9EdRjoWyLyA7p7reDKGzZK MJQe+qVigtpt4T0onvUpvinxAU/+PcWWQmDYJ8VhVWIe5Ldd9HuMC9Yoic7AkJJiHCqb fARg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=/TAxNwNcXotvg5+0E02/5KgFy5gFJHzNTxAk4IdtRtw=; b=IMz1mr+dF3ecQSLW3FEvZugxuDt6URC6oddu5uzQhwQuJgf94VKnIG4XOJV7CjMj+b d/eqboFtuWO/5+PPEEVEohBKW4KvV76otvgdY5Phh8fGW4X5mKDaUFqywYFmlzqxSEbu COUOlXJkiCN8Pkh2d/mFhZR6VuFMoqtw/hyYfTDz8h+3r+T5fzKJG8eAbT9xVeknOh4I nz/3TJf761BysTFsHnDND3v9X/Q5PsOcTdFg5aLvomixEVSJRW64CfKwknyynafUO0Io exu6QaUPxKLyRS2kdtEKp6Nvpj46SSTokW1rYqN9CUcthGFzhawVoEeQa/+N4Drab96l yLwA==
X-Gm-Message-State: AOAM532gog8CYbQ0fnYUSIxJ5UwBXM2km34NmxeR3g/GKjN0boy5hruB K2SlhjcFumK7CdrKBb5gWjzQJp2uKtFbig==
X-Google-Smtp-Source: ABdhPJzqr3QhuUF2wJZiJlwDGXpd+PtUEKX5b9pTcDG58H8Vz6YBIeauOeGx0opEvKofSwQgjoYvZQ==
X-Received: by 2002:a17:90a:4147:: with SMTP id m7mr1214022pjg.7.1621288070960; Mon, 17 May 2021 14:47:50 -0700 (PDT)
Received: from ?IPv6:2601:647:5600:5020:bccb:929a:9858:4f92? ([2601:647:5600:5020:bccb:929a:9858:4f92]) by with ESMTPSA id h18sm1402259pfr.49.2021. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 May 2021 14:47:50 -0700 (PDT)
From: Mahesh Jethanandani <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_64D87F51-F9FE-4435-B6E6-788595F78D2D"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
Date: Mon, 17 May 2021 14:47:46 -0700
In-Reply-To: <>
Cc: Kent Watsen <>, "" <>
To: Qin Wu <>
References: <>
X-Mailer: Apple Mail (2.3608.
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: Mon, 17 May 2021 21:47:58 -0000

Hi Qin,

> On May 13, 2021, at 1:27 AM, Qin Wu <> wrote:
> 发件人: Mahesh Jethanandani [ <>] 
> 发送时间: 2021年5月13日 8:13
> 收件人: Qin Wu < <>>
> 抄送: Kent Watsen < <>>; <>
> 主题: Re: [netconf] Capability-fetching mechanisms
> Hi Qin,
> When Kent and I started working on the HTTPs notif draft we wanted to make sure that it was lightweight as it relates to setting it up. That means that if the publisher and receiver are HTTPS capable, that in most cases that is all that isneeded to establish the notification channel. To quite an extent that is still true. With default values (JSON encoding), one can setup a HTTPS notification channel by configuring the *publisher* where the receiver resides (its IP address) and any credentials that are needed to setup the channel. The receiver does not need to be configured, and as such does not need to be a NETCONF/RESTCONF server (or a client for that matter).
> [Qin]: Thanks for your clarification, I think in appendix using subscribed notification and not using subscribed notification are both supported.
> In the case of using subscribed notification, RFC8639 enabled capability is supported while in the case without using subscribed notification, RFC8639 enabled capability is not supported?
> In the first case, the publisher need to be NETCONF/RESTCONF server? In the second case, it is not. Right?

[mj] The fact that the publisher has to be a NETCONF/RESTCONF server was never in dispute. The question is whether the receiver needs to be a NETCONF/RESTCONF server. As maqiufang wrote in his response, if the receiver supports the data-export-capabilities draft, then it would need to be a NETCONF/RESTCONF server, whereas with the https-notif draft that is not the case. This is the case whether the receiver supports RFC 8639 or not.

Please note that RFC 8639 receivers do not have to be NETCONF/RESTCONF servers for configured subscriptions. RFC 8639, Section 2.7 defines the control messages such as <subscription-started> using one-way YANG “notification” statements.


> Cheers.
> On May 11, 2021, at 6:51 PM, Qin Wu < <>> wrote:
> 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.
> Thoughts?
> Kent and Mahesh  // as authors
> _______________________________________________
> netconf mailing list
> <>
> <>
> _______________________________________________
> netconf mailing list
> <>
> <>
> Mahesh Jethanandani
> <>

Mahesh Jethanandani