Re: [netconf] I-D Action: draft-ietf-netconf-udp-client-server-01.txt

[[e-mail]]

Hi Alex, 

Thanks for taking care of the comments. 

For this specific one:
 
> The current model was based on the comments that were coming from the
> UDP-notif YANG model, where the WG felt it was safer to be more
> conservative on how to configure the udp-notif receiver.

I don't think we need to restrict the common model based on a very specific use. 

I do still prefer a consistent approach independent of the transport protocol.  

Cheers,
Med

> -----Message d'origine-----
> De : Alex Huang Feng <[e-mail]>
> Envoyé : mardi 27 février 2024 18:06
> À : netconf <[e-mail]>; BOUCADAIR Mohamed INNOV/NET
> <[e-mail]>
> Cc : Kent Watsen <[e-mail]>; Pierre Francois
> <[e-mail]>; draft-ietf-netconf-udp-
> [e-mail]
> Objet : Re: [netconf] I-D Action: draft-ietf-netconf-udp-client-
> server-01.txt
> 
> Dear NETCONF WG,
> 
> I submitted a new iteration addressing some of the comments from the
> ML during the adoption call.
> 
> Changes:
> - The ports have become "mandatory false" with a default value of 0
> following the tcp-client-server model.
> - Security Considerations is following the template
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki
> .ietf.org%2Fgroup%2Fops%2Fyang-security-
> guidelines&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C4903e1a9e92
> 74255fd9508dc376b0a9e%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638
> 446180073833970%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2
> luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=zbfiZ3YElo07o1
> 9C0ySLccaLrEpk4AoHS4TLStewyr8%3D&reserved=0
> 
> Med asked why the udp-server model was not following the tcp-server
> model:
> grouping tcp-client-grouping:
>     +-- remote-address                inet:host
>     +-- remote-port?                  inet:port-number
>     +-- local-address?                inet:ip-address
>     |       {local-binding-supported}?
>     +-- local-port?                   inet:port-number
>     |       {local-binding-supported}?
> 
> The current model was based on the comments that were coming from the
> UDP-notif YANG model, where the WG felt it was safer to be more
> conservative on how to configure the udp-notif receiver.
> As of now, the UDP-notif draft is the main user of this grouping
> draft.
> That is the reason why the remote-address is "inet:ip-address-no-zone"
> instead of a simple "inet:ip-address" or "inet:host" as was defined in
> the tcp grouping.
> 
> My question to the WG is:
> - Should udp-client-server groupings follow the tcp-client-server
> groupings models and have generic "inet:host" and local-addresses in
> the client OR stay conservative following the comments from UDP-notif
> draft?
> 
> One comment on the impacts:
> - At first, UDP-notif was going to use this generic grouping to
> configure its receiver (this draft has become a dependance for UDP-
> notif).
> If client-server-grouping draft follow the tcp model, should the UDP-
> notif not use this model and implement a specific one with the
> "inet:ip-address-no-zone"?
> 
> Regarding managing dual stacks on a single server, I don't have an
> answer, so I am open to any suggestions or contributions.
> 
> Cheers,
> Alex
> 
> 
> > On 27 Feb 2024, at 17:03, [e-mail] wrote:
> >
> > Internet-Draft draft-ietf-netconf-udp-client-server-01.txt is now
> available.
> > It is a work item of the Network Configuration (NETCONF) WG of the
> IETF.
> >
> >   Title:   YANG Groupings for UDP Clients and UDP Servers
> >   Authors: Alex Huang Feng
> >            Pierre Francois
> >            Kent Watsen
> >   Name:    draft-ietf-netconf-udp-client-server-01.txt
> >   Pages:   10
> >   Dates:   2024-02-27
> >
> > Abstract:
> >
> >   This document defines two YANG 1.1 modules to support the
> >   configuration of UDP clients and UDP servers.
> >
> > The IETF datatracker status page for this Internet-Draft is:
> >
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata
> tracker.ietf.org%2Fdoc%2Fdraft-ietf-netconf-udp-client-
> server%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C4903e1a9e927
> 4255fd9508dc376b0a9e%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6384
> 46180073841986%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2l
> uMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=PAbiUWOrSH1Qi2Z
> GVy9CFrGiEJFcqAasOkY0vYaFt5k%3D&reserved=0
> >
> > There is also an HTMLized version available at:
> >
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata
> tracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-netconf-udp-client-server-
> 01&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C4903e1a9e9274255fd9
> 508dc376b0a9e%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63844618007
> 3847727%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLC
> JBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=NmZVjwYZbHbpfhv5m3cd5t
> %2FFRbFV%2Fa4CgzBK8%2BINlIw%3D&reserved=0
> >
> > A diff from the previous version is available at:
> >
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauth
> or-tools.ietf.org%2Fiddiff%3Furl2%3Ddraft-ietf-netconf-udp-client-
> server-
> 01&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C4903e1a9e9274255fd9
> 508dc376b0a9e%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63844618007
> 3852383%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLC
> JBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=l1Za3akPcYeXEn%2FagYy%
> 2Ba9n4K6ZtZAqmM6Mc2tRCfrU%3D&reserved=0
> >
> > Internet-Drafts are also available by rsync at:
> > rsync.ietf.org::internet-drafts
> >
> >
> > _______________________________________________
> > netconf mailing list
> > [e-mail]
> >
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Fmailman%2Flistinfo%2Fnetconf&data=05%7C02%7Cmohamed.boucada
> ir%40orange.com%7C4903e1a9e9274255fd9508dc376b0a9e%7C90c7a20af34b40bfb
> c48b9253b6f5d20%7C0%7C0%7C638446180073856995%7CUnknown%7CTWFpbGZsb3d8e
> yJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%
> 7C%7C%7C&sdata=pP6kCUfCJGvwDzlJ08VjjhqoHqfoWWaSsWTu33f%2FIXI%3D&reserv
> ed=0

____________________________________________________________________________________________________________
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.