Re: [netconf] Adoption-suitability for draft-unyte-netconf-udp-notif

Kent Watsen <kent+ietf@watsen.net> Fri, 07 August 2020 20:15 UTC

Return-Path: <01000173ca90a8d5-78b55d80-3a92-406a-8544-594dbe223735-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 9DCBC3A08E2 for <netconf@ietfa.amsl.com>; Fri, 7 Aug 2020 13:15:47 -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_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 W9p5EoM9R1Gz for <netconf@ietfa.amsl.com>; Fri, 7 Aug 2020 13:15:46 -0700 (PDT)
Received: from a8-83.smtp-out.amazonses.com (a8-83.smtp-out.amazonses.com [54.240.8.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A7083A046E for <netconf@ietf.org>; Fri, 7 Aug 2020 13:15:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1596831345; h=From:Content-Type:Mime-Version:Subject:Date:References:To:In-Reply-To:Message-Id:Feedback-ID; bh=yug7PSQUtr2UfzNxSNNQ65Vc3qxtnwmHv6OydYg9/Og=; b=T6eX8mBegCLEADgQ5hwSPGYYJ7X6knxwHNxPoBZm7X4u+ttAbyN50k35WdlDJt00 RSM+Pz8glLcRJSSfkgm8u7k1BSAyUAE7qUFzu1ju2lUg9Ix+c3mbYsSoK+yDOjgq47Z Qo1XaFUXu1VCtVztC2w9oCR/Yb26A3mUxDyCWW1w=
From: Kent Watsen <kent+ietf@watsen.net>
Content-Type: multipart/alternative; boundary="Apple-Mail=_44258DED-442A-40AF-9A75-4A75E4D713A3"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Fri, 07 Aug 2020 20:15:44 +0000
References: <01000173c0b039d4-76bb4e31-9f40-4a5d-bdac-39512c8b4e9d-000000@us-east-1.amazonses.com>
To: "netconf@ietf.org" <netconf@ietf.org>
In-Reply-To: <01000173c0b039d4-76bb4e31-9f40-4a5d-bdac-39512c8b4e9d-000000@us-east-1.amazonses.com>
Message-ID: <01000173ca90a8d5-78b55d80-3a92-406a-8544-594dbe223735-000000@email.amazonses.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
X-SES-Outgoing: 2020.08.07-54.240.8.83
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/3aZuFDFr6H4AV54AhbMSy7awqU8>
Subject: Re: [netconf] Adoption-suitability for draft-unyte-netconf-udp-notif
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: Fri, 07 Aug 2020 20:15:48 -0000

[as a contributor]


>    1) is the problem important for the NETCONF WG to solve?

I believe that it is important to enable publishers to send notifications using a UDP-based transport.   This belief is based on my experience from when at Juniper dealing with very high-end firewalls with enormous log output.

I believe that the NETCONF WG is the appropriate WG for this work, having defined RFC 8639 (SN), RFC 8640 (NN), and RFC 8650 (RN).


>    2) is the draft a suitable basis for the work?

I have read the current version of the draft and find it to be a reasonable start.

Presuming the “receiver-instances” augmentation defined in https://tools.ietf.org/html/draft-ietf-netconf-https-notif-04#section-3 <https://tools.ietf.org/html/draft-ietf-netconf-https-notif-04#section-3> takes off, the module defined in this draft should be updated to augment into it instead.

I appreciate Section 5 (Applicability) noting that the UDP-transport is primarily for the data plane (not the control plane), as it doesn’t matter so much if data plane notifications are lost.  This addresses (I think) the issue that Rob Shakir raised before: https://datatracker.ietf.org/doc/minutes-103-netconf <https://datatracker.ietf.org/doc/minutes-103-netconf> (search for “Rob S”).  That said, it is unclear to me how a receiver could configure this while, e.g., configuring control plane notifications to be sent via a TCP-based transport such as “https-notif”.


3) regarding Juergen’s questions:

  a) I am willing to substantially review the drafts.
  b) I am willing to contribute to the discussion of any issue.
  c) I do NOT plan to implement the technology defined.



Kent