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

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

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