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

[Mahesh Jethanandani <[e-mail]>]

Hi Med,


> On Mar 20, 2024, at 11:04 AM, [e-mail] wrote:
> 
> Re-,
>  
> As Joe rightfully mentioned, running different instances is likely to happen at the device level. For that case, the leaf-list approach is just fine. 
>  
> Now, when the model is reused in upper layers (network or service models), that would not be sufficient. Think about a DHC service model which hides the internal of the service (whether this is dhcp or dhcpv6) but simply needs to expose where the dhc service is enabled: distinct ports are required for that case.

[mj] So a list of local-address and local-port?

Cheers.

>  
> Cheers,
> Med
>  
> De : Kent Watsen <[e-mail] <mailto:[e-mail]>> 
> Envoyé : mercredi 20 mars 2024 10:48
> À : BOUCADAIR Mohamed INNOV/NET <[e-mail] <mailto:[e-mail]>>
> Cc : Joe Clarke (jclarke) <[e-mail] <mailto:[e-mail]>>; Rob Wilton (rwilton) <[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]>
> Objet : Re: [netconf] Pullback tcp-client-server also?
>  
> Hi Med,
>  
> Do you mean a list of “local-address + local-port” tuples?
>  
> Can you post a concrete proposal?
>  
> K. 
>  
>  
> On Mar 20, 2024, at 10:36 AM, [e-mail] <mailto:[e-mail]> wrote:
> 
>  
> 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] <mailto:[e-mail]>> 
> Envoyé : mercredi 20 mars 2024 10:29
> À : Joe Clarke (jclarke) <[e-mail] <mailto:[e-mail]>>
> Cc : BOUCADAIR Mohamed INNOV/NET <[e-mail] <mailto:[e-mail]>>; Rob Wilton (rwilton) <[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[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 [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 deKent 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.
> ____________________________________________________________________________________________________________
> 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.
> _______________________________________________
> netconf mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/netconf <https://www.ietf.org/mailman/listinfo/netconf>


Mahesh Jethanandani
[e-mail]