Re: [netconf] Pullback tcp-client-server also?

Kent Watsen <kent+ietf@watsen.net> Wed, 20 March 2024 00:28 UTC

Return-Path: <0100018e59428053-7866dd74-77a6-444e-972e-b7273b47c0ea-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 46C3AC151552 for <netconf@ietfa.amsl.com>; Tue, 19 Mar 2024 17:28:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.905
X-Spam-Level:
X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=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] 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 7_9Jvoy3ScQU for <netconf@ietfa.amsl.com>; Tue, 19 Mar 2024 17:28:35 -0700 (PDT)
Received: from a48-94.smtp-out.amazonses.com (a48-94.smtp-out.amazonses.com [54.240.48.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 717F5C151536 for <netconf@ietf.org>; Tue, 19 Mar 2024 17:28:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1710894514; h=Content-Type:Content-Transfer-Encoding:From:Mime-Version:Subject:Date:Message-Id:References:Cc:In-Reply-To:To:Feedback-ID; bh=rqEj406nbH+X1UL5HkA4eFb/34G2l5BBkpKx9AIuV3U=; b=HAhf1moojxpJXrtvjyvxVjdMlvP+SqhxXuG8CeVJoOjajAWAKkCkQnCv2dSpIs6x R8yP3pR5gknjaR8V+ETEczjPLE+cp1dxv8LbNNRVF05khhHRUg43tVi/FAY1rXp1CJB xcbQr+TOnVGhrCrntp0CbXuexIiZLKhGDLQayxI0=
Content-Type: multipart/alternative; boundary="Apple-Mail-B3B83C0C-A55F-4C56-8196-328DC8368DFC"
Content-Transfer-Encoding: 7bit
From: Kent Watsen <kent+ietf@watsen.net>
Mime-Version: 1.0 (1.0)
Date: Wed, 20 Mar 2024 00:28:34 +0000
Message-ID: <0100018e59428053-7866dd74-77a6-444e-972e-b7273b47c0ea-000000@email.amazonses.com>
References: <BN9PR11MB537133C145210D8560CA25B1B82C2@BN9PR11MB5371.namprd11.prod.outlook.com>
Cc: mohamed.boucadair@orange.com, "Rob Wilton (rwilton)" <rwilton@cisco.com>, netconf@ietf.org
In-Reply-To: <BN9PR11MB537133C145210D8560CA25B1B82C2@BN9PR11MB5371.namprd11.prod.outlook.com>
To: "Joe Clarke (jclarke)" <jclarke@cisco.com>
X-Mailer: iPhone Mail (21E219)
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
X-SES-Outgoing: 2024.03.20-54.240.48.94
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/q3-fcFOKJpvxyqYtxEoLDwC3iKo>
Subject: Re: [netconf] Pullback tcp-client-server also?
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.39
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: Wed, 20 Mar 2024 00:28:36 -0000

Thanks Med and Joe.  I had a sidebar with Rob and Mahesh, and we’re going to do this update in Auth48.  

Let us (the WG) agree on the exact change.  
  1) change ‘leaf’ to ‘leaf-list’
  2) tweak the ‘description’ to say that it’s a list
  
Anything else?  Do we need to disallow shadows?  (e.g., two wildcards)

K. 


> On Mar 20, 2024, at 9:02 AM, Joe Clarke (jclarke) <jclarke@cisco.com> wrote:
> 
> 
> I agree with Med.  Your description is an either/or, but one server might do something like:
>  
> tcp46      0      0 *.9100                 *.*                    LISTEN  Listen on all v4 and v6 addresses
>  
> Or:
>  
> tcp4       0      0 127.0.0.1.25           *.*                    LISTEN  Listen on just v4 on an explicit address
>  
> Or:
>  
> tcp6       0      0 ::1.25   *.*                              LISTEN  Listen on just v6 on an explicit address
>  
> In the first case, I’d think you’d at least need a leaf-list to hold both 0.0.0.0 and ::.  In the second two cases, you’d want this service to have a leaf list for 127.0.0.1 and ::1.
>  
> Joe
>  
> From: netconf <netconf-bounces@ietf.org> on behalf of mohamed.boucadair@orange.com <mohamed.boucadair@orange.com>
> Date: Tuesday, March 19, 2024 at 18:23
> To: Kent Watsen <kent+ietf@watsen.net>, Rob Wilton (rwilton) <rwilton@cisco.com>
> Cc: netconf@ietf.org <netconf@ietf.org>
> Subject: Re: [netconf] Pullback tcp-client-server also?
> 
> Hi Kent, all,
>  
> When I initially raised the issue for the UDP grouping, I had in mind any, IPv4/IPv6 explicit address bindings, and eventually listening on distinct port numbers per AF. Given this is a reusable model, these cases should be all covered.
>  
> Cheers,
> Med
>  
> De : netconf <netconf-bounces@ietf.org> De la part de Kent Watsen
> Envoyé : mercredi 20 mars 2024 06:54
> À : Rob Wilton <rwilton@cisco.com>
> Cc : netconf@ietf.org
> Objet : [netconf] Pullback tcp-client-server also?
>  
> Rob, Netconf, 
>  
> Regarding support for “dual-stack”, do we need to convert from a “leaf” to a “leaf-list”?
>  
> Please note that the existing text says that a wildcard card may be used to bind to all addresses:
>  
> leaf local-address {
>       type inet:ip-address;
>       mandatory true;
>       description
>         "The local IP address to listen on for incoming
>          TCP client connections.  INADDR_ANY (0.0.0.0) or
>          INADDR6_ANY (0:0:0:0:0:0:0:0 a.k.a. ::) MUST be
>          used when the server is to listen on all IPv4 or
>          IPv6 address.";
>     }
>  
> Good enough?
>  
> Kent 
>  
> ____________________________________________________________________________________________________________
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>  
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.