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

[[e-mail]]

Re-, 

Thanks, Alex.

I trust that you will also mirror the changes to better cover dual-stack.

Cheers,
Med

> -----Message d'origine-----
> De : Alex Huang Feng <[e-mail]>
> Envoyé : mercredi 20 mars 2024 12:27
> À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>
> Cc : netconf <[e-mail]>; Kent Watsen <[e-mail]>;
> Pierre Francois <[e-mail]>; draft-ietf-netconf-
> [e-mail]
> Objet : Re: [netconf] I-D Action: draft-ietf-netconf-udp-client-
> server-01.txt
> 
> Dear Med,
> 
> I will change the generic grouping and follow the tcp-client-server
> groupings structure.
> - changing the ip to a generic inet:host
> - adding the local-address and local-port to the client
> 
> I will check then how to manage all this at the UDP-notif level.
> 
> Cheers,
> Alex
> 
> > On 20 Mar 2024, at 09:29, [e-mail] wrote:
> >
> > 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%2Fwik
> >>
> i%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C0ce6616e305f4842
> >>
> 4efb08dc488545a4%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6384649
> >>
> 84442693669%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM
> >>
> zIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=NSjZp0gtzCLDxJyE
> >> CsxgFgy2DhHrWmRE2yy%2FMXniny4%3D&reserved=0
> >> .ietf.org%2Fgroup%2Fops%2Fyang-security-
> >>
> guidelines&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C4903e1a9e9
> >> 2
> >>
> 74255fd9508dc376b0a9e%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63
> >> 8
> >>
> 446180073833970%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV
> >> 2
> >>
> luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=zbfiZ3YElo07o
> >> 1
> >> 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%2Fdat
> >>
> a%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C0ce6616e305f4842
> >>
> 4efb08dc488545a4%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6384649
> >>
> 84442700896%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM
> >>
> zIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=DGC4XFNP1qDAM90d
> >> 5scijz7Wd%2B0WG5dsrAuKVxWbiRg%3D&reserved=0
> >> tracker.ietf.org%2Fdoc%2Fdraft-ietf-netconf-udp-client-
> >>
> server%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C4903e1a9e92
> >> 7
> >>
> 4255fd9508dc376b0a9e%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638
> >> 4
> >>
> 46180073841986%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2
> >> l
> >>
> uMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=PAbiUWOrSH1Qi2
> >> Z
> >> GVy9CFrGiEJFcqAasOkY0vYaFt5k%3D&reserved=0
> >>>
> >>> There is also an HTMLized version available at:
> >>>
> >>
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdat
> >>
> a%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C0ce6616e305f4842
> >>
> 4efb08dc488545a4%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6384649
> >>
> 84442706013%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM
> >>
> zIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=sHRsNQ0nB1qc6L6x
> >> XKGfvPCWs0UcE55b2fmczJWttyE%3D&reserved=0
> >> tracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-netconf-udp-client-
> server-
> >>
> 01&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C4903e1a9e9274255fd
> >> 9
> >>
> 508dc376b0a9e%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6384461800
> >> 7
> >>
> 3847727%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL
> >> C
> >>
> JBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=NmZVjwYZbHbpfhv5m3cd5
> >> t
> >> %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%2Faut
> >>
> h%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C0ce6616e305f4842
> >>
> 4efb08dc488545a4%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6384649
> >>
> 84442709810%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM
> >>
> zIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=6DmzQAcf%2FxI7sJ
> >> HLEAchHF4gvtOYfzj6zAusMAzWZzI%3D&reserved=0
> >> or-tools.ietf.org%2Fiddiff%3Furl2%3Ddraft-ietf-netconf-udp-client-
> >> server-
> >>
> 01&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C4903e1a9e9274255fd
> >> 9
> >>
> 508dc376b0a9e%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6384461800
> >> 7
> >>
> 3852383%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL
> >> C
> >>
> 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%
> 2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C0ce6616e305f48424ef
> b08dc488545a4%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63846498444
> 2713497%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLC
> JBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=b7niUljN1%2BoXrhPGjVLz
> Y8doT1VKPo9bxan0YwKY0Iw%3D&reserved=0.
> >>
> ietf.org%2Fmailman%2Flistinfo%2Fnetconf&data=05%7C02%7Cmohamed.boucad
> >> a
> >>
> ir%40orange.com%7C4903e1a9e9274255fd9508dc376b0a9e%7C90c7a20af34b40bf
> >> b
> >>
> c48b9253b6f5d20%7C0%7C0%7C638446180073856995%7CUnknown%7CTWFpbGZsb3d8
> >> e
> >>
> yJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0
> >> %
> >>
> 7C%7C%7C&sdata=pP6kCUfCJGvwDzlJ08VjjhqoHqfoWWaSsWTu33f%2FIXI%3D&reser
> >> v
> >> 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.
> >

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