Re: [netconf] Capability-fetching mechanisms

Kent Watsen <> Mon, 10 May 2021 20:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 658D13A29A5 for <>; Mon, 10 May 2021 13:15:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id iOwl-eebkkMx for <>; Mon, 10 May 2021 13:15:44 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7099B3A29D9 for <>; Mon, 10 May 2021 13:15:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug;; t=1620677742; h=From:Content-Type:Mime-Version:Subject:Date:References:To:In-Reply-To:Message-Id:Feedback-ID; bh=Ao7sgLuxh5M/+oQ55yaFiqGOEyFmtGrcv2QiGNTzcDQ=; b=WvXRDxZqS03MLzIT8/UO13GCGFwLx0kAZoCMf7xdTKM1DoD5n2pCwHhp0SOeP/JC rYJBUjyK88PX65hN4EMIVqUyfhnQuTiOhfhQZts1w9z6zWxTqA/zisniZnj/mi3tIoX j+tybT0MW1NxPjcIQL4Q62DP23sdH+SRiP/wYrjA=
From: Kent Watsen <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_A1705125-B5E3-4623-ACD4-859D41603245"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.\))
Date: Mon, 10 May 2021 20:15:41 +0000
References: <> <>
To: "" <>
In-Reply-To: <>
Message-ID: <>
X-Mailer: Apple Mail (2.3654.
X-SES-Outgoing: 2021.05.10-
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, 10 May 2021 20:15:59 -0000

Dear WG,

Mahesh and I were sure that this message would kickoff a massive debate!  ;)

Seriously, though, any thoughts on this?  If none, then perhaps Rob (as AD and chair-fallback) can advise on a path forward?

FWIW, Mahesh and I are of the opinion that protocol-specific mechanisms provide a better overall solution (e.g., ease of implementation)...

Kent and Mahesh (as contributors)

> 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:
> 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
> 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
> 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, 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.
> 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
> Thoughts?
> Kent and Mahesh  // as authors
> _______________________________________________
> netconf mailing list