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

[[e-mail]]

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]>
Envoyé : jeudi 27 juin 2024 12:21
À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>
Cc : netconf <[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.