Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55628C14F6A0 for ; Thu, 27 Jun 2024 03:21:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.263 X-Spam-Level: X-Spam-Status: No, score=0.263 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_HELO_IP_MISMATCH=2.368, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=insa-lyon.fr Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id thkSSuIvMzvE for ; Thu, 27 Jun 2024 03:21:08 -0700 (PDT) Received: from smtpout01-ext2.partage.renater.fr (smtpout01-ext2.partage.renater.fr [194.254.240.33]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FDDCC14F68D for ; Thu, 27 Jun 2024 03:21:07 -0700 (PDT) Received: from zmtaauth01.partage.renater.fr (zmtaauth01.partage.renater.fr [194.254.240.25]) by smtpout10.partage.renater.fr (Postfix) with ESMTP id 76E41640AA; Thu, 27 Jun 2024 12:21:03 +0200 (CEST) Received: from zmtaauth01.partage.renater.fr (localhost [127.0.0.1]) by zmtaauth01.partage.renater.fr (Postfix) with ESMTPS id 6E7D81405F9; Thu, 27 Jun 2024 12:21:03 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zmtaauth01.partage.renater.fr (Postfix) with ESMTP id 5D6FA1405FC; Thu, 27 Jun 2024 12:21:03 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.10.3 zmtaauth01.partage.renater.fr 5D6FA1405FC DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=insa-lyon.fr; s=CB289C06-95B8-49FE-9C4B-D197C6D2E7CB; t=1719483663; bh=1k2ozAOX/K1CU2JTH/xUKgoRZz2wNvJRZR3mneqIuV8=; h=From:Message-Id:Mime-Version:Date:To; b=HXOJOOhtEkL1vlLRWIYDrigcXMzfPqbCPHIKQDAvDQ2VbJRveIlKR6ZUG7vh0OMzR dSAhnkQrbGR6arfJuYc1laOIUursHRi4/BUrrojwneQPcE6Lm6mtIpd9RjHr6NcEIY jGK/sHfTegFLOJk7PYUuC050sj7tX6PVBk8NJa72IFqseN1RoSGdYbc9OeJrkE6DrR PUHN0810u0qhMYls6MYDZIpsE4ElJyOxZNti5KoC+HQKvIU7IOEXWVPghIl9nZjEuq hDVXgYCNG8qMya+Xlr8/05/R+csk9FMe889bYTwKhhejwkC3UHz303JfwmRxkJngpY HQtViZw0bsmkg== Received: from zmtaauth01.partage.renater.fr ([127.0.0.1]) by localhost (zmtaauth01.partage.renater.fr [127.0.0.1]) (amavis, port 10026) with ESMTP id yWSGV8iaf7t4; Thu, 27 Jun 2024 12:21:03 +0200 (CEST) Received: from 134.214.58.21 (unknown [194.254.241.249]) by zmtaauth01.partage.renater.fr (Postfix) with ESMTPA id 0D9631405F9; Thu, 27 Jun 2024 12:21:03 +0200 (CEST) From: Alex Huang Feng Message-Id: <124ED22D-FAB1-4DF4-AF71-3B6C9C3452E0@insa-lyon.fr> Content-Type: multipart/alternative; boundary="Apple-Mail=_602C8899-BC91-4BE8-B4F8-A55F40C04308" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.600.62\)) Date: Thu, 27 Jun 2024 12:20:52 +0200 In-Reply-To: To: mohamed.boucadair@orange.com References: <171872264355.20027.6027117271461135736@ietfa.amsl.com> X-Mailer: Apple Mail (2.3774.600.62) X-Virus-Scanned: clamav-milter 0.103.8 at clamav03 X-Virus-Status: Clean X-Renater-Ptge-SpamState: clean X-Renater-Ptge-SpamScore: 0 X-Renater-Ptge-SpamCause: gggruggvucftvghtrhhoucdtuddrgeeftddrtdeggddvjecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucftgffptefvgfftnecuuegrihhlohhuthemuceftddtnecunecujfgurhephffktgggufffjgevvfhfofesrgdtmherhhdtjeenucfhrhhomheptehlvgigucfjuhgrnhhgucfhvghnghcuoegrlhgvgidrhhhurghnghdqfhgvnhhgsehinhhsrgdqlhihohhnrdhfrheqnecuggftrfgrthhtvghrnhepieekvdfgudduuddvfefgffegkeelfeetvdethfehiedvffdulefhfedugfetfedunecuffhomhgrihhnpehivghtfhdrohhrghdpghhithhhuhgsrdgtohhmpdhgihhthhhusghushgvrhgtohhnthgvnhhtrdgtohhmnecukfhppeduleegrddvheegrddvgedurddvgeelnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepudelgedrvdehgedrvdeguddrvdegledphhgvlhhopedufeegrddvudegrdehkedrvddupdhmrghilhhfrhhomheprghlvgigrdhhuhgrnhhgqdhfvghnghesihhnshgrqdhlhihonhdrfhhrpdhnsggprhgtphhtthhopedvpdhrtghpthhtohepmhhohhgrmhgvugdrsghouhgtrggurghirhesohhrrghnghgvrdgtohhmpdhrtghpthhtohepnhgvthgtohhnfhesihgvthhfrdhorhhg Message-ID-Hash: F3BG2ILLUGWVVOILB23FQJWEIGNICLZI X-Message-ID-Hash: F3BG2ILLUGWVVOILB23FQJWEIGNICLZI X-MailFrom: alex.huang-feng@insa-lyon.fr X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-netconf.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: netconf X-Mailman-Version: 3.3.9rc4 Precedence: list Subject: =?utf-8?q?=5Bnetconf=5D_Re=3A_I-D_Action=3A_draft-ietf-netconf-udp-client-se?= =?utf-8?q?rver-02=2Etxt?= List-Id: NETCONF WG list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --Apple-Mail=_602C8899-BC91-4BE8-B4F8-A55F40C04308 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear Med, Thank you very much for the review and comments. Please see inline. > On 18 Jun 2024, at 17:28, mohamed.boucadair@orange.com wrote: >=20 > Hi Alex,=20 >=20 > Thanks for this revised versions.=20 >=20 > Please find below some easy-to-fix comments: >=20 > # Sections 2 and 3.3. >=20 > 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"; >=20 > # Section 2: Not sure how to interpret this feature in a module for = managing UDP clients: >=20 > 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. >=20 > # Section 2 >=20 > 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."; >=20 > ## only ip-address type is defined here. I would delete the = "interface" mention. > ## s/MAY/may > ## I would delete "explicitly indicate the implicit default" >=20 > # Section 2 >=20 > OLD: > "The local IP port number to bind to when sending UDP > NEW: > "The local port number to bind to when sending UDP >=20 > # 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.=20 I already encountered this =E2=80=9Cissue" 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 =E2=80=9C0=E2=80=9D, but also = wanted some consistency with the tcp-client-server draft. That=E2=80=99s = is why I implemented default. Is there any other thoughts about this from the WG? Should I remove the = default in the next iteration? >=20 > # Section 3.2: Per https://datatracker.ietf.org/doc/html/rfc5952 >=20 > OLD: 2001:DB8::0 > NEW: 2001:db8::0 >=20 > # 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-net= conf-udp-client-server-03.txt rfcdiff: = https://author-tools.ietf.org/diff?doc_1=3Ddraft-ietf-netconf-udp-client-s= erver-02&url_2=3Dhttps://raw.githubusercontent.com/netconf-wg/udp-client-s= erver/master/draft-ietf-netconf-udp-client-server-03.txt I will submit before cutoff. Cheers, Alex >=20 > # Section 5.1: >=20 > 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 >=20 > # Section 5.2: >=20 > OLD: > This document also requests two new YANG module names in the YANG > Module Names registry [RFC8342] with the following suggestions: >=20 > NEW: > This document requests IANA to register the following YANG modules = in > the "YANG Module Names" registry [RFC6020] within the "YANG > Parameters" registry group. >=20 > Cheers, > Med >=20 >> -----Message d'origine----- >> De : Alex Huang Feng > >> Envoy=C3=A9 : mardi 18 juin 2024 17:08 >> =C3=80 : netconf > >> Cc : i-d-announce@ietf.org >> Objet : [netconf] Re: I-D Action: draft-ietf-netconf-udp-client- >> server-02.txt >>=20 >>=20 >> Dear NETCONF, >>=20 >> Following the feedback from the last IETF WG meeting, I updated >> the client-server groupings mimicking the tcp client-server >> groupings. >>=20 >> 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. >>=20 >> We welcome any new comment on this draft. >>=20 >> Regards, >>=20 >> Alex >>=20 >>> On 18 Jun 2024, at 16:57, internet-drafts@ietf.org wrote: >>>=20 >>> 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. >>>=20 >>> 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 >>>=20 >>> Abstract: >>>=20 >>> This document defines two YANG 1.1 modules to support the >>> configuration of UDP clients and UDP servers. >>>=20 > = __________________________________________________________________________= __________________________________ > 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. >=20 > 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. --Apple-Mail=_602C8899-BC91-4BE8-B4F8-A55F40C04308 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Dear = Med,

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

On 18 Jun 2024, at 17:28, = mohamed.boucadair@orange.com 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
         binding= s (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-iet= f-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
          m= essages to the remote server. INADDR_ANY ('0.0.0.0') or
          I= NADDR6_ANY ('0:0:0:0:0:0:0:0' a.k.a. '::') MAY be used to
          e= xplicitly indicate the implicit default, that the server
          c= an 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 = =E2=80=9Cissue" 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 =E2=80=9C0=E2=80=9D, but also wanted some consistency with the = tcp-client-server draft. That=E2=80=99s 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-1= 1#name-security-considerations-sect

C= hanged

For the rest, all integrated to the next = iteration: https://github.com/netconf-wg/udp-c= lient-server/blob/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 <alex.huang-feng@insa-lyon.fr<= /a>>
Envoy=C3=A9 : mardi 18 juin 2024 17:08
=C3=80 : = netconf <netconf@ietf.org>
Cc : i-d-announce@ietf.org
Objet&n= bsp;: [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, internet-drafts@ietf.org = 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
          Ke= nt Watsen
 Name: =    draft-ietf-netconf-udp-client-server-02.txt
 Pag= es:   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.

= --Apple-Mail=_602C8899-BC91-4BE8-B4F8-A55F40C04308--