Re: [netconf] Capability-fetching mechanisms

Mahesh Jethanandani <> Tue, 01 June 2021 22:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 15A9F3A2A32 for <>; Tue, 1 Jun 2021 15:43:47 -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, 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 7p3whWkXg4Ki for <>; Tue, 1 Jun 2021 15:43:42 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::62a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B4D373A2A30 for <>; Tue, 1 Jun 2021 15:43:42 -0700 (PDT)
Received: by with SMTP id c13so107771plz.0 for <>; Tue, 01 Jun 2021 15:43:42 -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=4SivZjQQXSPr3BGmfIG5dTbePjjN3/QHU4q8weQpzv8=; b=gTqiI9k6YVVrjVSHzW1twVNzQwRvAJUFVsaTEmg5p+YMmty5AVxcIIcQ+lB0eA8Vox gPoWw8YzK8aRsxxxl0vL8w1QFw/241/xOmchrB+/2Zp1+M63HBdIlwjmOD3mQ0YFYNv2 HTjmrzuM/JiwHnmhgFm4BUJbXtaJWpLN6E/fylkFGwa7W/+gOXZhOCceotLCQQGgVE3P jt4Xr9O4vdsCmQzKZ+QW4BLZ3SLaYnlRhvUOEtESQBhi14CPPQzZp8Z18WCejPLS/lL4 Btf3CbL7cj0OYDkCuANBtTtufIQGUhYBoahMDHZFsGUYxktnXxkp31DO57QBF8WJp7rD zSiA==
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=4SivZjQQXSPr3BGmfIG5dTbePjjN3/QHU4q8weQpzv8=; b=SZw+sGJMT7sZ8YdFFpL02VMuTGpJgueK5N/LYV8P9jov3lIduRfmRuPLPSy24FC6ah jOljbVn/+XkIUd/lLrBIp9j2i9a/zsa8rBWrNr2QE6cprxIep99FFXvHA9QY6LGxARvv BbWziaRpc8djVnZOuuUA5CXE0rv9TXS9aFUxfH6kID0GDzBC1UWNwz1gwqgETJYNArK9 NJPBcAlsMVhRXRih8LVuD7tbS4tRrlJZkJrBPll3nhS8ZPjc46qDXnfsLk4IiWthND91 SvSbfLoyWK3quqJruZ7LoX/+/+YilPITuD/vH5KWuhhRAqMfKszcfASSZaQ2N0cVUU41 Wu1Q==
X-Gm-Message-State: AOAM531sMrg6stMly5SYzddl4kkUXTL5ImDsT7Gi8NqjZMx9i8g5blGG LWY3UIAHzBgPg+Jc0MaEUlG+bCokTsbVHg==
X-Google-Smtp-Source: ABdhPJyHI0cxXmyWsqS0mbwO++tCuTZFVIaqUHhdr59YrMhUewXqTobvmACUlhZKFHD0PDH4vI67BQ==
X-Received: by 2002:a17:90b:1d8a:: with SMTP id pf10mr27649070pjb.53.1622587421226; Tue, 01 Jun 2021 15:43:41 -0700 (PDT)
Received: from ([2601:647:5600:5020:14c1:fda:26ed:c601]) by with ESMTPSA id k7sm2915969pjj.46.2021. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 01 Jun 2021 15:43:40 -0700 (PDT)
From: Mahesh Jethanandani <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_51E80E50-02EB-4801-B35F-B8C65C84494A"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.\))
Date: Tue, 01 Jun 2021 15:43:38 -0700
In-Reply-To: <>
Cc: Kent Watsen <>, "" <>
To: Qin Wu <>
References: <>
X-Mailer: Apple Mail (2.3654.
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: Tue, 01 Jun 2021 22:43:47 -0000

[Trimming down the e-mail to open topics]

Hi Qin,

See inline with [mj1]

> On May 18, 2021, at 4:40 AM, Qin Wu <> wrote:
> Hi, Mahesh:
> 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.
> [Qin]:My understanding is data-export-capabilities doesn’t require receiver to be tied with NETCONF/RESTCONF server. I assume the management system (i.e., receiver) and network device (i.e., publisher) can use HTTPS to exchange advertised data.
> In addition, Maybe what is missing in the data-export-capabilities draft is to define RPC to allow the publisher get capability from receiver through HTTPS channel, similar to what is get-bootstrapping-data RPC defined in RFC8572.

[mj1] Stipulating a HTTPs channel works for the HTTPS notif draft. But what will other transport type drafts use? e.g. the UDP notif draft?? 

> 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.
> [Qin]: Understand this case, Do you think we should define a new notification in the data-export-capabilities draft instead of considering to define RPC?

[mj1] I do not understand this statement. Can you expand?

Mahesh Jethanandani