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

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

Dear Med,

I integrated the proposed changes: https://github.com/netconf-wg/udp-client-server/blob/master/draft-ietf-netconf-udp-client-server-03.txt

Diff of last commit: https://author-tools.ietf.org/diff?url_1=https://raw.githubusercontent.com/netconf-wg/udp-client-server/2e8ac0ec7efcd333e156352313be8c828e5a4e5b/draft-ietf-netconf-udp-client-server-03.txt&url_2=https://raw.githubusercontent.com/netconf-wg/udp-client-server/master/draft-ietf-netconf-udp-client-server-03.txt

Diff to last iteration: https://author-tools.ietf.org/diff?doc_1=draft-ietf-netconf-udp-client-server-02&url_2=https://raw.githubusercontent.com/netconf-wg/udp-client-server/master/draft-ietf-netconf-udp-client-server-03.txt 

Yes, regarding the default, I’ll wait for a bit to see if other members from the ML have any opinions.
But yes, my reflex is also removing it.

Cheers,
Alex

> On 27 Jun 2024, at 13:28, [e-mail] wrote:
> 
> Hi Alex,
>  
> Thanks for the follow-up and for addressing the comments.
>  
> I confirm that issue#2 below applies for draft-ietf-netconf-tcp-client-server-26#section-3.1.1.
>  
> Noted the pending point about the default. If you decide to remove the default, you may consider adding a note to explain why that design is a hurdle for better reusability.
>  
> Please find below some comments on the candidate version:
>  
> # Section 5.2: 6020 is authoritative here
>  
> OLD:
>   This document requests IANA to register the following YANG modules in
>   the "YANG Module Names" registry [RFC8342] within the "YANG
>   Parameters" registry group.
>  
> NEW:
>   This document requests IANA to register the following YANG modules in
>   the "YANG Module Names" registry [RFC6020] within the "YANG
>   Parameters" registry group.
>  
> # Move “I-D.ietf-netmod-rfc8407bis” to be listed as informative instead of normative.
>  
> Thank you.
>  
> Cheers,
> Med
>  
> De : Alex Huang Feng <[e-mail] <mailto:[e-mail]>> 
> Envoyé : jeudi 27 juin 2024 12:21
> À : BOUCADAIR Mohamed INNOV/NET <[e-mail] <mailto:[e-mail]>>
> Cc : netconf <[e-mail] <mailto:[e-mail]>>
> Objet : Re: [netconf] I-D Action: draft-ietf-netconf-udp-client-server-02.txt
>  
> 
> Dear Med,
>  
> Thank you very much for the review and comments.
> Please see inline.
> 
> 
> On 18 Jun 2024, at 17:28, [e-mail] <mailto:[e-mail]> wrote:
>  
> Hi Alex, 
> 
> Thanks for this revised versions. 
> 
> Please find below some easy-to-fix comments:
> 
> # Sections 2 and 3.3.
> 
> OLD:
>       reference
>         "RFC-to-be: YANG Grouping for UDP Clients and UDP Servers";
> NEW:
>       reference
>         "RFC-to-be: YANG Groupings for UDP Clients and UDP Servers";
> 
> # Section 2: Not sure how to interpret this feature in a module for managing UDP clients:
> 
> CURRENT:
>     feature local-binding-supported {
>       description
>         "Indicates that the UDP server supports configuring local
>          bindings (i.e., the local address and local port) for
>          UDP clients.";
>     }
>  
> It is a typo. Changed to
> Indicates that the UDP client supports configuring local
>        bindings (i.e., the local address and local port) for
>        UDP clients.
>  
> I understand this feature as a way to advertise that the client is able to configure the local IP and local port.
>  
> I guess the typo is also valid for https://datatracker.ietf.org/doc/html/draft-ietf-netconf-tcp-client-server-26#section-3.1.1? If not, I am missing something.
> 
> # Section 2
> 
> CURRENT:
>           "The local IP address/interface to bind to when sending UDP
>           messages to the remote server. INADDR_ANY ('0.0.0.0') or
>           INADDR6_ANY ('0:0:0:0:0:0:0:0' a.k.a. '::') MAY be used to
>           explicitly indicate the implicit default, that the server
>           can bind to any IPv4 or IPv6 address.";
> 
> ## only ip-address type is defined here. I would delete the "interface" mention.
> ## s/MAY/may
> ## I would delete "explicitly indicate the implicit default"
> 
> # Section 2
> 
> OLD:
>           "The local IP port number to bind to when sending UDP
> NEW:
>           "The local port number to bind to when sending UDP
> 
> # delete " which is the default value," or "default "0";" as there are redundant. I have a preference to delete "default "0";" as this is reusable grouping and my prevent some uses. 
>  
> I already encountered this “issue" in UDP-notif, how to use this grouping with a YANG model that implements a mandatory port. YANG does not allow refining a default statement to a mandatory field.
> I am totally okay removing the default “0”, but also wanted some consistency with the tcp-client-server draft. That’s is why I implemented default.
> Is there any other thoughts about this from the WG? Should I remove the default in the next iteration?
> 
> 
> 
> # Section 3.2: Per https://datatracker.ietf.org/doc/html/rfc5952
> 
> OLD: <local-address>2001:DB8::0</local-address>
> NEW: <local-address>2001:db8::0</local-address>
> 
> # Security: I would follow the template at https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc8407bis-11#name-security-considerations-sect
>  
> Changed
>  
> For the rest, all integrated to the next iteration: https://github.com/netconf-wg/udp-client-server/blob/master/draft-ietf-netconf-udp-client-server-03.txt
>  
> rfcdiff: https://author-tools.ietf.org/diff?doc_1=draft-ietf-netconf-udp-client-server-02&url_2=https://raw.githubusercontent.com/netconf-wg/udp-client-server/master/draft-ietf-netconf-udp-client-server-03.txt
>  
> I will submit before cutoff.
>  
> Cheers,
> Alex
> 
> 
> 
> # Section 5.1:
> 
> OLD:  IANA is requested to assign two new URI from the IETF XML Registry
> NEW:  IANA is requested to assign two new URIs from the IETF XML Registry
> 
> # Section 5.2:
> 
> OLD:
>   This document also requests two new YANG module names in the YANG
>   Module Names registry [RFC8342] with the following suggestions:
> 
> NEW:
>   This document requests IANA to register the following YANG modules in
>   the "YANG Module Names" registry [RFC6020] within the "YANG
>   Parameters" registry group.
> 
> Cheers,
> Med
> 
> 
> -----Message d'origine-----
> De : Alex Huang Feng <[e-mail] <mailto:[e-mail]>>
> Envoyé : mardi 18 juin 2024 17:08
> À : netconf <[e-mail] <mailto:[e-mail]>>
> Cc : [e-mail] <mailto:[e-mail]>
> Objet : [netconf] Re: I-D Action: draft-ietf-netconf-udp-client-
> server-02.txt
> 
> 
> Dear NETCONF,
> 
> Following the feedback from the last IETF WG meeting, I updated
> the client-server groupings mimicking the tcp client-server
> groupings.
> 
> Changes:
> - On the client-grouping, the remote-address is a generic
> inet:host instead of the limited inet:ip-address-no-zone and
> supports local bindings
> - On the server-grouping, it is a list of local binding
> addresses.
> - Added some examples of usage.
> 
> We welcome any new comment on this draft.
> 
> Regards,
> 
> Alex
> 
> 
> On 18 Jun 2024, at 16:57, [e-mail] <mailto:[e-mail]> wrote:
> 
> Internet-Draft draft-ietf-netconf-udp-client-server-02.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-02.txt
>  Pages:   12
>  Dates:   2024-06-18
> 
> Abstract:
> 
>  This document defines two YANG 1.1 modules to support the
>  configuration of UDP clients and UDP servers.
> 
> ____________________________________________________________________________________________________________
> 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.