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

[Alex Huang Feng <[e-mail]>]

Re,

Yes, I plan to mirror the tcp structure.

Cheers,
Alex

> On 20 Mar 2024, at 16:18, [e-mail] wrote:
> 
> 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] <mailto:[e-mail]>>
>> Envoyé : mercredi 20 mars 2024 12:27
>> À : BOUCADAIR Mohamed INNOV/NET <[e-mail] <mailto:[e-mail]>>
>> Cc : netconf <[e-mail] <mailto:[e-mail]>>; Kent Watsen <[e-mail] <mailto:[e-mail]>>;
>> Pierre Francois <[e-mail] <mailto:[e-mail]>>; draft-ietf-netconf-
>> [e-mail] <mailto:[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 <http://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 <http://ietf.org/>%2Fgroup%2Fops%2Fyang-security-
>>>> 
>> guidelines&data=05%7C02%7Cmohamed.boucadair%40orange.com <http://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] <mailto:[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 <http://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 <http://tracker.ietf.org/>%2Fdoc%2Fdraft-ietf-netconf-udp-client-
>>>> 
>> server%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com <http://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 <http://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 <http://tracker.ietf.org/>%2Fdoc%2Fhtml%2Fdraft-ietf-netconf-udp-client-
>> server-
>>>> 
>> 01&data=05%7C02%7Cmohamed.boucadair%40orange.com <http://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 <http://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 <http://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.