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

["Joe Clarke (jclarke)" <[e-mail]>]

Hmmm, interesting.  I haven’t done that myself.  When I’ve needed an alternate port, I ran another instance of the service.  However, I agree that different ports per AF could be supported.  A list of address/port would be much more flexible.

Joe

From: [e-mail] <[e-mail]>
Date: Tuesday, March 19, 2024 at 20:36
To: Kent Watsen <[e-mail]>, Joe Clarke (jclarke) <[e-mail]>
Cc: Rob Wilton (rwilton) <[e-mail]>, [e-mail] <[e-mail]>
Subject: RE: [netconf] Pullback tcp-client-server also?
Re-,

This would address the first cases I mentioned, but not the third one.

At least some narrative text is needed to explain the intended use of distinct port per AF. A cleaner approach would to model this is as a list keyed per AF.

Cheers,
Med

De : Kent Watsen <[e-mail]>
Envoyé : mercredi 20 mars 2024 10:29
À : Joe Clarke (jclarke) <[e-mail]>
Cc : BOUCADAIR Mohamed INNOV/NET <[e-mail]>; Rob Wilton (rwilton) <[e-mail]>; [e-mail]
Objet : Re: [netconf] Pullback tcp-client-server also?

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) <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>> on behalf of [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, March 19, 2024 at 18:23
To: Kent Watsen <[e-mail]<mailto:[e-mail]>>, Rob Wilton (rwilton) <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
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 <[e-mail]<mailto:[e-mail]>> De la part de Kent Watsen
Envoyé : mercredi 20 mars 2024 06:54
À : Rob Wilton <[e-mail]<mailto:[e-mail]>>
Cc : [e-mail]<mailto:[e-mail]>
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.

____________________________________________________________________________________________________________

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.