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

Alex Huang Feng <alex.huang-feng@insa-lyon.fr> Tue, 15 October 2024 09:42 UTC

Return-Path: <alex.huang-feng@insa-lyon.fr>
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 B0753C14F617 for <netconf@ietfa.amsl.com>; Tue, 15 Oct 2024 02:42:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.367
X-Spam-Level:
X-Spam-Status: No, score=0.367 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, HTTPS_HTTP_MISMATCH=0.1, RCVD_HELO_IP_MISMATCH=2.368, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, 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 j7HPtoBGaJ-c for <netconf@ietfa.amsl.com>; Tue, 15 Oct 2024 02:42:37 -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 E0164C14F738 for <netconf@ietf.org>; Tue, 15 Oct 2024 02:42:35 -0700 (PDT)
Received: from zmtaauth03.partage.renater.fr (zmtaauth03.partage.renater.fr [194.254.240.26]) by smtpout10.partage.renater.fr (Postfix) with ESMTP id 7B931651F1; Tue, 15 Oct 2024 11:42:20 +0200 (CEST)
Received: from zmtaauth03.partage.renater.fr (localhost [127.0.0.1]) by zmtaauth03.partage.renater.fr (Postfix) with ESMTPS id 60F188000E; Tue, 15 Oct 2024 11:42:20 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by zmtaauth03.partage.renater.fr (Postfix) with ESMTP id 4ADAF800D2; Tue, 15 Oct 2024 11:42:20 +0200 (CEST)
DKIM-Filter: OpenDKIM Filter v2.10.3 zmtaauth03.partage.renater.fr 4ADAF800D2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=insa-lyon.fr; s=CB289C06-95B8-49FE-9C4B-D197C6D2E7CB; t=1728985340; bh=4W3tqKEEKrdgIMPviXAJB556c5qmUu1OgHKvQzGFDmQ=; h=From:Message-Id:Mime-Version:Date:To; b=S+7vUyGc+4XbrfxHLewtGnQ7sn+mGEZbM++1U6nqTdsYq2hbyK4TlCoT0Yi8D9WqW iIEnbwDpTb1Zrfcysabrg8ejdTGz0s3qm7MFCWWHvMrz1n9tpK1lD1JmQQypx4EiDb GljkpQ+UjNO9H11IQxRlHnffENXipvE33qzdMBAyOcrAbUlu9q09kwQPbaub2r87zV tkBm3zznTtoNqXaNYLbgLlWN2B+tQc0/ccKEy7T9KfrAz9MpYFvxcwMxy4b2OSVaSi UEqCUaYTr4UwpmRsTrYGjDqZdwxBC4tkVF45cCDNr+zlRqeVRsdYH0dsSwJHamc9jU xE+M+ED2R6Mnw==
Received: from zmtaauth03.partage.renater.fr ([127.0.0.1]) by localhost (zmtaauth03.partage.renater.fr [127.0.0.1]) (amavis, port 10026) with ESMTP id D560TZtIhAIT; Tue, 15 Oct 2024 11:42:20 +0200 (CEST)
Received: from 134.214.58.28 (unknown [194.254.241.250]) by zmtaauth03.partage.renater.fr (Postfix) with ESMTPA id F0F528000E; Tue, 15 Oct 2024 11:42:19 +0200 (CEST)
From: Alex Huang Feng <alex.huang-feng@insa-lyon.fr>
Message-Id: <7BA201DB-74AD-4099-8E59-582E23C2F5C0@insa-lyon.fr>
Content-Type: multipart/alternative; boundary="Apple-Mail=_682AB290-3730-4893-891A-80B49B34E8B8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3776.700.51.11.1\))
Date: Tue, 15 Oct 2024 11:42:09 +0200
In-Reply-To: <DU2PR02MB101609B5E1D07BF3EC0A9F58188442@DU2PR02MB10160.eurprd02.prod.outlook.com>
To: mohamed.boucadair@orange.com
References: <172804948425.100084.1485968544504943811@dt-datatracker-cb674fff7-jr9km> <6C73CA66-BF3A-4EED-BE26-590EE7349877@insa-lyon.fr> <DU2PR02MB1016097AD8FA519D17D4949DE88722@DU2PR02MB10160.eurprd02.prod.outlook.com> <0100019258920611-d4e16e9f-afaa-4033-86c4-ad5e10af3923-000000@email.amazonses.com> <DU2PR02MB101601664ACEE5EE068864EBF887D2@DU2PR02MB10160.eurprd02.prod.outlook.com> <83A4598F-3797-4069-A758-2ADC1A060FA2@insa-lyon.fr> <DU2PR02MB101609B5E1D07BF3EC0A9F58188442@DU2PR02MB10160.eurprd02.prod.outlook.com>
X-Mailer: Apple Mail (2.3776.700.51.11.1)
X-Virus-Scanned: clamav-milter 0.103.8 at clamav03
X-Virus-Status: Clean
X-Renater-Ptge-SpamState: clean
X-Renater-Ptge-SpamScore: -100
X-Renater-Ptge-SpamCause: gggruggvucftvghtrhhoucdtuddrgeeftddrvdegjedgudelucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecutffgpfetvffgtfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhephffktgggufffjgevvfhfofesrgdtmherhhdtjeenucfhrhhomheptehlvgigucfjuhgrnhhgucfhvghnghcuoegrlhgvgidrhhhurghnghdqfhgvnhhgsehinhhsrgdqlhihohhnrdhfrheqnecuggftrfgrthhtvghrnhepgfefgfeiffetveehvedvudetheefffeiudeiheevgfffjedtjeffudffudeiteegnecuffhomhgrihhnpehivghtfhdrohhrghdpghhithhhuhgsuhhsvghrtghonhhtvghnthdrtghomhenucfkphepudelgedrvdehgedrvdeguddrvdehtdenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepihhnvghtpeduleegrddvheegrddvgedurddvhedtpdhhvghlohepudefgedrvddugedrheekrddvkedpmhgrihhlfhhrohhmpegrlhgvgidrhhhurghnghdqfhgvnhhgsehinhhsrgdqlhihohhnrdhfrhdpnhgspghrtghpthhtohepgedprhgtphhtthhopehmohhhrghmvggurdgsohhutggruggrihhrsehorhgrnhhgvgdrtghomhdprhgtphhtthhopehkvghnthdoihgvthhfseifrghtshgvnhdrnhgvthdprhgtphhtthhopehnvghttghonhhfsehivghtfhdrohhrghdprhgtphhtthhopehpihgvrhhrvgdrfhhr rghntghoihhssehinhhsrgdqlhihohhnrdhfrh
Message-ID-Hash: DTSGAXABGHAYCZLZINHCZEPULRSCJZSD
X-Message-ID-Hash: DTSGAXABGHAYCZLZINHCZEPULRSCJZSD
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: Kent Watsen <kent+ietf@watsen.net>, "netconf@ietf.org" <netconf@ietf.org>, Pierre Francois <pierre.francois@insa-lyon.fr>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [netconf] Re: I-D Action: draft-ietf-netconf-udp-client-server-04.txt
List-Id: NETCONF WG list <netconf.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/F1fD5m7kWZ1dkClkyJOi-Jy7Br4>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Owner: <mailto:netconf-owner@ietf.org>
List-Post: <mailto:netconf@ietf.org>
List-Subscribe: <mailto:netconf-join@ietf.org>
List-Unsubscribe: <mailto:netconf-leave@ietf.org>

Dear William and Med,

Happy to see more feedback.

I have a neutral opinion on adding the “-grouping” on the grouping and the “-supported” on the feature.
I felt it was useful to have consistency with the tcp-goruping, but if the WG feels is better to shorten the names, happy to do it.
(I will add these changes unless there are objections.)

Regarding the QUIC-grouping draft, I agree with Med, the groupings defined in the draft so far can be used outside of QUIC (but I guess in the future iterations, QUIC-dependent parameters will be present).
However, given that the tls and transport level groupings are already defined, I don’t see a lot of value in creating groupings that only combine groupings (at least the way is defined currently).
Any consumer can just use and combine these grouping to have its own custom configuration.

Cheers,
Alex

> On 14 Oct 2024, at 17:16, mohamed.boucadair@orange.com wrote:
> 
> Hi Alex,
>  
> Thanks for the follow-up.
>  
> Please see inline.
>  
> Cheers,
> Med
>  
>  
> Orange Restricted
> De : Alex Huang Feng <alex.huang-feng@insa-lyon.fr <mailto:alex.huang-feng@insa-lyon.fr>> 
> Envoyé : lundi 14 octobre 2024 16:38
> À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@orange.com <mailto:mohamed.boucadair@orange.com>>
> Cc : Kent Watsen <kent+ietf@watsen.net <mailto:kent+ietf@watsen.net>>; netconf@ietf.org <mailto:netconf@ietf.org>; Pierre Francois <pierre.francois@insa-lyon.fr <mailto:pierre.francois@insa-lyon.fr>>
> Objet : Re: [netconf] I-D Action: draft-ietf-netconf-udp-client-server-04.txt
>  
> Dear Med and Kent,
>  
> Thanks for your feedback.
>  
> I integrated some of the proposed changes.
> Few comments:
> - I haven’t changed the “-grouping”, I think it can be useful when someone reads the YANG using the grouping.
> [Med] I really don’t parse this.
>  
> - The feature has not been shorten either.
> [Med] This might have implication on the length of generated trees (folding, etc.) for modules that use them.
>  
> - All the proposed text has been integrated. Thanks Med for the review.
>  
> Changes: https://author-tools.ietf.org/diff?doc_1=draft-ietf-netconf-udp-client-server-04&url_2=https://raw.githubusercontent.com/network-analytics/draft-ahuang-netconf-udp-client-server-grouping/refs/heads/master/draft-ietf-netconf-udp-client-server-05.txt
> -05: https://raw.githubusercontent.com/network-analytics/draft-ahuang-netconf-udp-client-server-grouping/refs/heads/master/draft-ietf-netconf-udp-client-server-05.txt <https://author-tools.ietf.org/diff?doc_1=draft-ietf-netconf-udp-client-server-04&url_2=https://raw.githubusercontent.com/network-analytics/draft-ahuang-netconf-udp-client-server-grouping/refs/heads/master/draft-ietf-netconf-udp-client-server-05.txt>
>  
> I will submit the following days (I don’t think I will get any new feedback but will wait for a bit)
>  
> Regarding dtls groupings, this was present on the very first version of the draft, but I got feedback from the WG that this was not necessary as someone needing to create a UDP client-server with DTLS already have all the necessary pieces to create one (with draft-ietf-netconf-tls-client-server). This is actually what is happening on UDP-notif model.
>  
> Regarding quic features, Per started the work in draft-andersson-netconf-quic-client-server.
> [Med] Please see my comments for that draft:https://mailarchive.ietf.org/arch/msg/netconf/yqfsMSYH_RpWQng3xJJQ6vJCLUI/. I think that we need to rationalize the various drafts out there. Thanks.
>  
> Cheers,
> Alex
>  
> 
> On 7 Oct 2024, at 15:22, mohamed.boucadair@orange.com <mailto:mohamed.boucadair@orange.com> wrote:
>  
> Hi Kent, 
> 
> Thanks for the feedback. 
> 
> As I said, these were about nits. So, I really leave it to the authors to grab whatever useful. However, I disagree with the reasoning of some of the objections below.
> 
> Please see inline. 
> 
> Cheers,
> Med
> 
> 
> -----Message d'origine-----
> De : Kent Watsen <kent+ietf@watsen.net <mailto:kent+ietf@watsen.net>>
> Envoyé : vendredi 4 octobre 2024 19:27
> À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@orange.com <mailto:mohamed.boucadair@orange.com>>
> Cc : Alex Huang Feng <alex.huang-feng@insa-lyon.fr <mailto:alex.huang-feng@insa-lyon.fr>>;
> netconf@ietf.org <mailto:netconf@ietf.org>; Pierre Francois <pierre.francois@insa-lyon.fr <mailto:pierre.francois@insa-lyon.fr>>
> Objet : Re: [netconf] I-D Action: draft-ietf-netconf-udp-client-
> server-04.txt
> 
> 
> 
> 
> * I know Kent uses this for TCP, but no need IMO to prefix
> groupings with "-grouping". This change would also make statements
> such as "udp-client-grouping" grouping" read better.
> 
> Actually, this is done for the entire suite of client-server
> drafts.
> 
> Yes, it is annoying, but it also improves readability in places.
> 
> [Med] I'm having troubles to see where it does so. The use "*-grouping" grouping makes it really hard let alone that this is redundant. If this reasoning is flowed, one can extrapolate it to always suffix the type "*-list", etc, which I don't think is a good approach. 
> 
> 
> Somehow my doing so was never challenged all these years.
> 
> [Med] This is not a valid argument, Kent :-) 
> 
> If we applied that reasoning, we wouldn't be fixing major issues in AUTH48 of the tcp spec.
> 
>  Making
> 
> a divergent change for this one draft may not be good.
> 
> 
> [Med] "not good" for what? It is the other way around actually, having more and more documents following that approach may be seen as this is a good practice, which I don't think it is.
> 
> 
>  
> 
> * s/ as an IPv4 address, an IPv6 address, or a hostname/ as an
> IPv4 address, an IPv6 address, or a domain name
> 
> Even after looking at RFC 9499 (DNS Terminology) and various web
> search query results, this doesn’t seem obviously better.
> 
> 
> [Med] Hmm, no need to go that far. We already have a def for it in 6991 :-)
> 
> See the discussion around "domain names"/RFC1034. Also, host description in 6991 is:
> 
>        "The host type represents either an IP address or a DNS
>         domain name.";
> 
>  
> 
> * s/The SHOULD can be ignored when/This MAY be ignored
> * s/The "remote-port" leaf/ The "remote-port": I'm picky here
> but "leaf" is defined per 7950 as "A data node that exists in at
> most one instance in the data tree", while groupings do not
> defined any data node.
> 
> * s/Defines a generic grouping for UDP-based client
> applications/Defines a generic grouping for UDP-based clients.
> 
> For both bullet points above, I strongly suggest not changing the
> text that was just finalized in the Auth48 thread, which Mahesh
> participated in and approved.
> 
> 
> [Med] Again, this is not a valid argument :-). Even text in an RFC can be updated/corrected/etc.
> 
> The intent of "SHOULD can be ignored" can be simply expressed as "MAY be ignored".
> 
> 
> 
> Kent / contributor
> 
> ____________________________________________________________________________________________________________
> 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.