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

[[e-mail]]

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.";
     }

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

# 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

# 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]>
> Envoyé : mardi 18 juin 2024 17:08
> À : netconf <[e-mail]>
> Cc : [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.