[netconf] UDP-noitf ports and other considerations
Kent Watsen <kent+ietf@watsen.net> Fri, 20 September 2024 00:28 UTC
Return-Path: <010001920cd42fa0-d8483923-7446-457e-ab26-59bcaba47d7e-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 0E44BC16942C for <netconf@ietfa.amsl.com>; Thu, 19 Sep 2024 17:28:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level:
X-Spam-Status: No, score=-1.906 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, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R-BXm22fejsg for <netconf@ietfa.amsl.com>; Thu, 19 Sep 2024 17:28:06 -0700 (PDT)
Received: from a8-88.smtp-out.amazonses.com (a8-88.smtp-out.amazonses.com [54.240.8.88]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AB35C1D6FBD for <netconf@ietf.org>; Thu, 19 Sep 2024 17:28:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1726792085; h=From:Content-Type:Mime-Version:Subject:Message-Id:References:To:Date:Feedback-ID; bh=YlDg+bS7QmX8ytt29lkHQvjNLPW/VOAxHJguwqBGCaU=; b=Iil5WCJVqHSViHk5TDblatP2uv3aBpigJyyXrIcFPoqyZ6u0FnwM9QXPf6Cz8tJ7 4tx0H5jZa4nRPGHWHym6E97/ZAjl1LMuUgjg/Pte2D+PXBea1nD7qU3Y+UVf1Uu4dr8 O8OeFw9eRptVJ81R0y6bOIKACu6AnuCqDXxyfItY=
From: Kent Watsen <kent+ietf@watsen.net>
Content-Type: multipart/alternative; boundary="Apple-Mail=_CC824CBC-4611-4C3D-AFE9-9D73B2810D5A"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.400.31\))
Message-ID: <010001920cd42fa0-d8483923-7446-457e-ab26-59bcaba47d7e-000000@email.amazonses.com>
References: <377E3D18-6F72-4CE5-BBDA-DCA9CB9A6599@insa-lyon.fr>
To: "netconf@ietf.org" <netconf@ietf.org>
Date: Fri, 20 Sep 2024 00:28:05 +0000
X-Mailer: Apple Mail (2.3774.400.31)
Feedback-ID: ::1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
X-SES-Outgoing: 2024.09.20-54.240.8.88
Message-ID-Hash: R463NTK2ZLSFAZO7IS5LFKJB2SMHAZHH
X-Message-ID-Hash: R463NTK2ZLSFAZO7IS5LFKJB2SMHAZHH
X-MailFrom: 010001920cd42fa0-d8483923-7446-457e-ab26-59bcaba47d7e-000000@amazonses.watsen.net
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-netconf.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [netconf] UDP-noitf ports and other considerations
List-Id: NETCONF WG list <netconf.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/TZ2nVoTFspiYU1xX9iu3ha0UxG0>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Owner: <mailto:netconf-owner@ietf.org>
List-Post: <mailto:netconf@ietf.org>
List-Subscribe: <mailto:netconf-join@ietf.org>
List-Unsubscribe: <mailto:netconf-leave@ietf.org>
The discussion about registering a port for UDP-notif questions why a registration is needed/required, when the client is always configured, and hence no assignment is needed. I decided to look into what it takes to register a port. Here [1] is where the application for a port is, and [2] provides guidance on when it is appropriate the register a port. I think everyone interested in this topic should read [2]. My reading of [2] is that a port-assignment is justified, to simplify the configuration of services such as firewall, NAT, and QoS. Separately, while reading these RFCs, I started asking myself questions: - should there be one port for unencrypted and another for encrypted, or can encryption be negotiated? [note: syslog has separate ports] - are both unencrypted and encrypted UDP-notif mandatory-to-implement by receivers? If not, how does a receiver indicate what it supports? - should other transports be considered, e.g. tcp, sctp, dccp? [syslog can be layered on top of any transport, e.g., udp/514, tcp/6514, udp/6514, and dccp/6514]. - when encrypted, and assuming a distinct port is needed, would it make sense to use QUIC instead of DTLS? - since HTTPS-notif can already be layered on top on QUIC, when would a deployment choose to use UDP-notif over DTLS or QUIC vs HTTPS-notif over QUIC? - would the service name be “udp-notif”? Or would something like “yanglog” and “yanglog-tls” would be better? (modeled after syslog and syslog-tls) “yanglog" sounds dorky ;) - the document defines 3 media-types, are any of them mandatory to implement? How does the client know which a server supports? [note: the https-notif draft includes a discovery mechanism for this] - why is the protocol limited to RFC 8639 configured subscriptions? Ultimately the protocol is a sequence notification messages, with or without the 8639-specific notification messages? [HTTPS-notif does not care in which context it is used] [1] https://www.iana.org/form/ports-services [2] https://www.rfc-editor.org/rfc/rfc7605.html Kent / contributor > Begin forwarded message: > > From: Alex Huang Feng <alex.huang-feng@insa-lyon.fr> > Subject: [netconf] Re: Default statements on udp-client-server groupings > Date: September 17, 2024 at 5:19:56 AM EDT > To: Kent Watsen <kent+ietf@watsen.net> > Cc: "netconf@ietf.org" <netconf@ietf.org>, draft-ietf-netconf-udp-client-server.authors@ietf.org > >>> - Personally I am not against having a default IANA port for UDP-Notif. I actually asked for it on the -13 iteration. >>> But from the feedback received on the ML [1] and the last IETF meeting [2], the conclusion was that a port is not needed because an operator already needs to configure the IP address where the collector is located. >>> I also see the same use case on the NC/RC Call home RFC. Even though a default port is defined, the operator still needs to configure the IP address of the NC client on the network management system... >>> >>> [1] https://mailarchive.ietf.org/arch/msg/netconf/gP5AApWL0Ha8uey9yIQvBlqOJ7A/ >>> [2] https://datatracker.ietf.org/doc/minutes-120-netconf-202407251630/ >> >> It’s true that it’s not a “first contact” situation, but many times Operators want a port for firewalls, wireshark, etc. And if we’re lucky, udp-notif will be very popular, easily justifying its allocation. >> >> Looking at the numbers, I see a 50/50 split in proponents of the two choices. This is far from WG consensus (not to mention weak participation). >> >> The minutes [2] show Rob suggesting asking a designated expert. This is what we should do. > > As I said, I am happy to add it back if it is needed. > I’ll leave this thread to udp-client-server groupings and follow up on udp-notif in another thread. > > Regards, > Alex >
- [netconf] Default statements on udp-client-server… Alex Huang Feng
- [netconf] Re: Default statements on udp-client-se… Thomas.Graf
- [netconf] Re: Default statements on udp-client-se… mohamed.boucadair
- [netconf] Re: Default statements on udp-client-se… Benoit Claise
- [netconf] Re: Default statements on udp-client-se… Qin Wu
- [netconf] Re: Default statements on udp-client-se… Kent Watsen
- [netconf] Re: Default statements on udp-client-se… Andy Bierman
- [netconf] Re: Default statements on udp-client-se… Kent Watsen
- [netconf] Re: Default statements on udp-client-se… Andy Bierman
- [netconf] Re: Default statements on udp-client-se… Kent Watsen
- [netconf] Re: Default statements on udp-client-se… Alex Huang Feng
- [netconf] Re: Default statements on udp-client-se… Kent Watsen
- [netconf] Re: Default statements on udp-client-se… Alex Huang Feng
- [netconf] UDP-noitf ports and other considerations Kent Watsen
- [netconf] Re: Default statements on udp-client-se… Andy Bierman
- [netconf] Re: Default statements on udp-client-se… Thomas.Graf
- [netconf] Re: [netmod] Re: Default statements on … Per Andersson
- [netconf] Re: UDP-noitf ports and other considera… Thomas.Graf
- [netconf] Re: [netmod] Re: Default statements on … Kent Watsen
- [netconf] Re: [netmod] Re: Default statements on … Kent Watsen
- [netconf] Re: [netmod] Re: Default statements on … Andy Bierman
- [netconf] Re: [netmod] Re: Default statements on … Andy Bierman
- [netconf] Re: UDP-noitf ports and other considera… Paolo Lucente
- [netconf] Re: Default statements on udp-client-se… Kent Watsen
- [netconf] Re: [netmod] Re: Default statements on … Andy Bierman
- [netconf] Re: [netmod] Re: Default statements on … Thomas.Graf
- [netconf] Re: [netmod] Re: Re: Default statements… Alex Huang Feng
- [netconf] Re: [netmod] Re: Default statements on … tom petch