Re: [netconf] Capability-fetching mechanisms

Kent Watsen <kent+ietf@watsen.net> Mon, 10 May 2021 20:15 UTC

Return-Path: <0100017957ebcbb9-d8daa1f2-1eba-4600-aa3a-1ca9d19fdce1-000000@amazonses.watsen.net>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 658D13A29A5 for <netconf@ietfa.amsl.com>; Mon, 10 May 2021 13:15:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iOwl-eebkkMx for <netconf@ietfa.amsl.com>; Mon, 10 May 2021 13:15:44 -0700 (PDT)
Received: from a48-90.smtp-out.amazonses.com (a48-90.smtp-out.amazonses.com [54.240.48.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7099B3A29D9 for <netconf@ietf.org>; Mon, 10 May 2021 13:15:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; 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 <kent+ietf@watsen.net>
Content-Type: multipart/alternative; boundary="Apple-Mail=_A1705125-B5E3-4623-ACD4-859D41603245"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\))
Date: Mon, 10 May 2021 20:15:41 +0000
References: <CD217B11-D85C-45EF-AB9A-344EA948B1EE@watsen.net> <01000178ec1343cb-74c9995e-8043-4e49-aa81-9da0fb07045b-000000@email.amazonses.com>
To: "netconf@ietf.org" <netconf@ietf.org>
In-Reply-To: <01000178ec1343cb-74c9995e-8043-4e49-aa81-9da0fb07045b-000000@email.amazonses.com>
Message-ID: <0100017957ebcbb9-d8daa1f2-1eba-4600-aa3a-1ca9d19fdce1-000000@email.amazonses.com>
X-Mailer: Apple Mail (2.3654.60.0.2.21)
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
X-SES-Outgoing: 2021.05.10-54.240.48.90
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/Q1uvW9xOfonllTbgobiz_ePOc_A>
Subject: Re: [netconf] Capability-fetching mechanisms
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=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 <kent@watsen.net> 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
> netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf