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

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

Dear Med,

Thank you very much for the review and comments.
Please see inline.

> On 18 Jun 2024, at 17:28, [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] 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.