IETF Logo Mail Archive

[netmod] Re: [netconf] Re: Default statements on udp-client-server groupings

Thomas.Graf@swisscom.com Wed, 18 September 2024 06:52 UTC

Return-Path: <Thomas.Graf@swisscom.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3198C1D4A72; Tue, 17 Sep 2024 23:52:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.104
X-Spam-Level:
X-Spam-Status: No, score=-2.104 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_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_NONE=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=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=swisscom.com
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 JFDhyN_bp3Y7; Tue, 17 Sep 2024 23:52:30 -0700 (PDT)
Received: from mail.swisscom.com (mailout120.swisscom.com [138.188.166.120]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E0D6C1519A2; Tue, 17 Sep 2024 23:52:27 -0700 (PDT)
Received: by mail.swisscom.com; Wed, 18 Sep 2024 08:52:25 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=swisscom.com; s=iscm; t=1726642345; bh=12k7SiyiWYNiQeRYKQQPYPsMyI9iaguuJmIHuTnUHsA=; h=From:To:CC:Subject:Date:References:In-Reply-To; b=WE3wIpgm9sCcjn2TB08RSioUxZ26F7au2JzH0q1TOUK8nGF/8q7gT8p+aRrDsVQ4H COSFw/8rPsphQiyTd9Rlf+zj/YeWgMRZU0QhnxvwNZjlyZkU/Is8BAk+81Tml0xvPg jFPlBF5a4/HQ6T3wLZssUFTWz8NzLJe/qe94TnaonSpyp5Y5PCrCmtfUjZal12tei9 tWG4O0iJ6ebgSUnUBdu8gshe6IIT98a2ps58mGqLszdyMYLhyv1pmBWSmj6/MsUM/d 4l2dTXYNVPvWXca93KSE06nQkyZCAuo4P6bon6AN3i/6w6CEcWrvs5zu/VqHOe89kB RrrMs+TGc8FqA==
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="----=_Part_580504_566843508.1726642345125"
X-Mailer: Totemo_TrustMail_(Notification)
From: Thomas.Graf@swisscom.com
To: kent+ietf@watsen.net, andy@yumaworks.com, alex.huang-feng@insa-lyon.fr
Thread-Topic: [netconf] Re: Default statements on udp-client-server groupings
Thread-Index: AQHbA5g9xsWaA+6ZZ0+22Hf2sAQj1LJRCl8AgAAJ+wCAABTSgIAAGq2AgAi8EACAAPMmAIABMDSAgACDkYCAAHvugA==
Date: Wed, 18 Sep 2024 06:52:22 +0000
Message-ID: <3dde2b41370c473389221aca2a371c8b@swisscom.com>
References: <EAA84133-F9D5-4380-994D-297993F13675@insa-lyon.fr> <01000191dc9a8080-119f64d0-f1d7-4549-9789-ba05daa87609-000000@email.amazonses.com> <CABCOCHRYQmo+XDZMGuTwNJ+OW2F1ZbRDcjMst40Z0GXpFD86-w@mail.gmail.com> <01000191dcc4509d-0c99ab29-a02e-4a3e-b68b-3b1d58a87f27-000000@email.amazonses.com> <CABCOCHT6Wsh=mwpPNq+3nGzf8EU8fGtwvstakEtbPetTsL9NDQ@mail.gmail.com> <01000191dd5fee26-d7465934-4131-40b1-9549-ff693917b0d6-000000@email.amazonses.com> <D0230B09-8D6B-4615-8C16-ED6BA6AAFDA7@insa-lyon.fr> <01000191fd1bd27b-042e2602-c072-44bf-9342-f38a74086dbb-000000@email.amazonses.com> <CABCOCHRw4Puhm2bNzSbXLsZD1-M+Miw6KypEbk=ENDj+C6xqPg@mail.gmail.com> <0100019202afbee4-44734060-0753-4ea1-b160-11772eda550a-000000@email.amazonses.com>
In-Reply-To: <0100019202afbee4-44734060-0753-4ea1-b160-11772eda550a-000000@email.amazonses.com>
Accept-Language: en-US, de-CH
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_ActionId=78a3ffcf-afb4-4f83-a295-154f45f18b0d;MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_ContentBits=0;MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_Enabled=true;MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_Method=Standard;MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_Name=C2 Internal;MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_SetDate=2024-09-18T06:35:37Z;MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_SiteId=364e5b87-c1c7-420d-9bee-c35d19b557a1;
x-originating-ip: [10.29.92.185]
X-CFilter-Loop: Reflected
X-Trustmail: processed
Message-ID-Hash: 3MGNKQGT3NPSW6CSMI5DSYF6SD6YMTG7
X-Message-ID-Hash: 3MGNKQGT3NPSW6CSMI5DSYF6SD6YMTG7
X-MailFrom: Thomas.Graf@swisscom.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-netmod.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: netconf@ietf.org, draft-ietf-netconf-udp-client-server.authors@ietf.org, netmod@ietf.org
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [netmod] Re: [netconf] Re: Default statements on udp-client-server groupings
List-Id: NETMOD WG list <netmod.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/B2uUTcZqCLi1oaeqINESgLSNtbU>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Owner: <mailto:netmod-owner@ietf.org>
List-Post: <mailto:netmod@ietf.org>
List-Subscribe: <mailto:netmod-join@ietf.org>
List-Unsubscribe: <mailto:netmod-leave@ietf.org>

Dear Kent, Andy and Alex,

I think Alex statement https://mailarchive.ietf.org/arch/msg/netconf/5Yaiom0B0lDTeSPOvgNfPIEFvBw/, Andy's feedback and guidelines in https://datatracker.ietf.org/doc/html/rfc8407#section-4.4 resp. https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc8407bis-15#section-4.4 makes perfectly sense and I don't see why we should do else. As an author, I suggest to add in section 4 of draft-ietf-netmod-rfc8407bis based on the conclusion of this discussion guidelines on reusable YANG groupings.

Best wishes
Thomas

From: Kent Watsen <kent+ietf@watsen.net>
Sent: Wednesday, September 18, 2024 3:12 AM
To: Andy Bierman <andy@yumaworks.com>
Cc: netconf@ietf.org; draft-ietf-netconf-udp-client-server.authors@ietf.org
Subject: [netconf] Re: Default statements on udp-client-server groupings


Be aware: This is an external email.


Hi Andy,

The main purpose for YANG defaults is ease of use.
If there are less things to configure then the device is easier to use.
Without a default port then this parameter becomes mandatory to configure.

Alex is trying to maximize lazy binding.  That is, as a general statement,  unless 100% sure, groupings should never specify the “default” or “mandatory” statements, leaving it to terminal “uses” statements to specify.   His comment raises to the level of something that could be an addition to rfc8407bis.

Thoughts?

Kent

v2.29.0 | Report a Bug | By Email | System Status