[netmod] Re: Defining groupings after the fact? draft-jouqui-netmod-yang-full-include and the reuse of definitions
"Rob Wilton (rwilton)" <rwilton@cisco.com> Fri, 02 August 2024 15:15 UTC
Return-Path: <rwilton@cisco.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 19D34C180B4C for <netmod@ietfa.amsl.com>; Fri, 2 Aug 2024 08:15:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.741
X-Spam-Level:
X-Spam-Status: No, score=-14.741 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.148, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 WAU3R_9Yv4iK for <netmod@ietfa.amsl.com>; Fri, 2 Aug 2024 08:15:14 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BD4EC18DB91 for <netmod@ietf.org>; Fri, 2 Aug 2024 08:15:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.com; i=@cisco.com; l=40708; q=dns/txt; s=iport; t=1722611714; x=1723821314; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=E280O5KhfrmLSbKYVn5YMBohnwdHJ9sXujDfZe23R74=; b=Lvm88Hjg8TwwTx4mhlr/jeBRr0hQsNiUz5ONqKyUu1DC7Ao4zddlN/h+ DqlIW+3Vwrv/ZpqR8ST67nk/qQji2U0IaamyM7UK1sF+uJvNw7kHa2pBN Zv9FbIL78Ms1LFkp4RXoCdHey9DOEEA+FsqzoFSCYcSMa+cZTuHSpR9rM Q=;
X-CSE-ConnectionGUID: SLNQscAvRWOAEvMRUB0jWg==
X-CSE-MsgGUID: 4VHvp10tTt2ZPKm7xSeT0A==
X-IPAS-Result: A0ALAQCl9qxmmIcNJK1aHQEBAQEJARIBBQUBZYEqgUExUnsCgRxIhFWDTAOFLYhxA54lgREDVg8BAQENAQE5CwQBAYIpgl0CFokyAiY4EwECBAEBAQEDAgMBAQEBAQEBAQEFAQEFAQEBAgEHBRQBAQEBAQEBATcFSYV1DYZdAQEBAQMOBAgJKxcJCwwEAgEIEQMBAQEhAwcCAgIuARQJCAIECAYFCBMCBAGCWQQBAYIcFAMxAwEQBJ9sAYFAAoooeoEygQHdOAOCYoFIiDEaAShIagIOhBSEZycbgUlEgRVCgmg+gmEEGIERARIBCRoFEAkMDAaDHTqCLwSBQSQCAgKCCAIDAgQ1B34hgSUCEwNlbkgCAURUgniBT4IXAmkOLD0DgTECBhaBGFZXDyotVR0eMygaAj4Dg00kAktngkZBgmcCAgICAgICAgICAgICAjqBaIYtUnUiAyYzIQIRAVUTFwsJBYlKCkeBMoEqKYFLJoENgw6BNYN5gWsMYYhUgQ+BPoFfAYM/SoNngX+BBIJ/HUADC209NRQbBQSBNQWiagQygxQBEC4tBmg7CBAEHAI+IhYtEgMFCxouC5NYAYMsizijXQqEFYwUlVsXhAWNAJhVZJhwIoI0gkGIZJVIBIUlAgQCBAUCDwEBBoF+Iw9ccHAVO4JnCUkZD446H4NCgm6BUMdOeAIBOAIHAQoBAQMJimsBAQ
IronPort-PHdr: A9a23:CZNkFRSHG09dR8N+ucXI0ue5ltpso47LVj580XJvo7tKdqLm+IztI wmGo/5sl1TOG47c7qEMh+nXtvX4UHcbqdaasX8EeYBRTRJNl8gMngIhDcLEQU32JfLndWo7S exJVURu+DewNk09JQ==
IronPort-Data: A9a23:yWo1R6x6cRVdrslbhGp6t+c9xirEfRIJ4+MujC+fZmUNrF6WrkVUx zdJCGCCOavfN2WhftonOouxpENQ7MPRyodmHVQ++1hgHilAwSbn6Xt1DatR0we6dJCroJdPt p1GAjX4BJlpCCKa/1H1b+WJQUBUjcmgXqD7BPPPJhd/TAplTDZJoR94kobVuKYw6TSCK13L4 YKaT/H3Ygf/h2YkajhMsMpvlTs21BjMkGJA1rABTagjUG/2zxE9EJ8ZLKetGHr0KqE8NvK6X evK0Iai9Wrf+Ro3Yvv9+losWhRXKlJ6FVHmZkt+A8BOsDAbzsAB+vpT2M4nVKtio27hc+adZ zl6ncfYpQ8BZsUgkQmGOvVSO3kW0aZuoNcrLZUj2CCe5xWuTpfi/xlhJHoSG7QD8c9pO15p3 NEGDQowREiBuO3jldpXSsE07igiBMDvOIVasXZ6wHSDS/0nWpvEBa7N4Le03h9p2ZsIRqiYP pFfMGEyBPjDS0Un1lM/Eo0/mPuvgFH0ciZTrxSeoq9fD237llcsgeO1YIaIEjCMbZlrvliA/ zraw3ijMCk5MYOP8je5qlv504cjmgugBdpNT+fnnhJwu3WVy3AWDxE+VFanr7++kEHWZj5EA 0UQ/ixrpq8o+QnxCNL8RBa/5nWDu3bwRua8DcUBzCe00aH9/TymIUEpUBt7VfZ+tvA5EGlCO kCyo/vlAjlmsbuwQH2b96uJoT7aBcTzBTFdDcPjZVVZi+QPsL0OYgTzosGP+ZNZY/X8HTX2h juNtiV73fMYjNUA0OOw+lWvb9OQSnrhEFNdCub/Bz7NAuZFiGiNPNbABb/ztqgoEWphZgPd1 EXoYuDHhAz0MbmDlTaWXMIGF6yz6vCOPVX02AE1RcV/r2vzpC78Jei8BQ2Swm83bq7onhe0M CfuVf95vsQ70IaCNPUuOtngUazGM4C8RIS+DJg4keaikrAqKVfYp3sxDaJh92vsi0Mr2bouI ouWdN3kDHART8xaIMmeGY8gPUsQ7nlmnwv7HMmjpzz+iOr2TCDOE98tbgDRBt3VGYvZ+m05B f4FaZvTo/ieOcWjChTqHXk7dAxSfCZkVc2r96S6tIere2JbJY3oMNeIqZsJcI1+lKMTneDNl kxRkGcCoLYjrRUr8Tm3V00=
IronPort-HdrOrdr: A9a23:59vcEK0i5c3F8j3ohaOU/wqjBftxeYIsimQD101hICG9Lfbo9P xGzc566farslcssSkb6K690cm7LU819fZOkO8s1MSZLXjbUQqTXc1fBOTZskfd8kHFh4pgPO JbAtdD4b7LfBdHZKTBkXSF+r8bqbHtntHL9ILjJjVWPH1Xgspbnn5E43OgYzZLrX59dOIE/f Snl616jgvlU046Ku68AX4IVfXCodrkqLLKCCRtOzcXrCO1oXeN8rDVLzi0ty1yb9pI+9gf2F mAtza8yrSosvm9xBOZ/XTU9Y5qlNzozcYGLNCQi+AOQw+cyzqAVcBEYfmvrTo1qOag5BIBi9 /XuSotOMx19jf4Yny1mx3wwAPtuQxeq0MKiGXowkcLk/aJAQ7SOPAxwb6xtSGprHbIiesMkp 6jGVjp8aa/QymwxRgVrOK4Jy2C3nDE0kbK19RjwUC2leAlGeRsRUt1xjIMLL4QWC3984wpC+ 9oEYXV4+tXa0qTazTDsnBo28HEZAV5Iv6qeDlKhiWu6UkfoFlpi08DgMAPlHYJ85wwD5FC+u TfK6xt0LVDVNUfY65xDPoIBZLfMB2BfTvcdGaJZVj3HqAOPHzA75bx/bUu/emvPJgF1oE7lp jNWE5R8WQyZ0XtA8uT24AjyGGGfEytGTD2js1O7ZlwvbPxALLtLC2YUVgr19Ctpv0Oa/erLc pb+KgmdMMLAVGebbqhhTeOKaW6AUNuJfEohg==
X-Talos-CUID: 9a23:B9IS0GFCk2JpR9W1qmJc0GgtAcsMbEfi6179PWqCNEwxSoKaHAo=
X-Talos-MUID: 9a23:/d32xgXNdTmA17Lq/GPSpC96bZ9037j0OngulMoWgMS4bQUlbg==
X-IronPort-Anti-Spam-Filtered: true
Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-7.cisco.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Aug 2024 15:15:12 +0000
Received: from alln-opgw-1.cisco.com (alln-opgw-1.cisco.com [173.37.147.229]) by alln-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 472FFC9J019239 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for <netmod@ietf.org>; Fri, 2 Aug 2024 15:15:12 GMT
X-CSE-ConnectionGUID: uq+ZZC7dSHm+F501jL5+fw==
X-CSE-MsgGUID: 1L6PXh9NT5SDAOJmkDWX7w==
Authentication-Results: alln-opgw-1.cisco.com; dkim=pass (signature verified) header.i=@cisco.com
X-IronPort-AV: E=Sophos;i="6.09,258,1716249600"; d="scan'208,217";a="35352669"
Received: from mail-mw2nam04lp2177.outbound.protection.outlook.com (HELO NAM04-MW2-obe.outbound.protection.outlook.com) ([104.47.73.177]) by alln-opgw-1.cisco.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Aug 2024 15:15:11 +0000
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=bExxWgMGD8QYhsu0YaqbtrocaL3DIc6WGh2WPNComp82QhKYHOU2OG6YDAqUjizJ/CRvzDXNxk4lRHmCpSkg+R6MTXYOuCyHQObohsDtg661c/EwaeeMSJLkzx+QPyts86zbFKV81Rs7dtBf1SPEA0p7nQT/aePtjPRkyncgxbqQCB+xY0N5jYT9b6jNAcKIDNOa1F7vTd0EQjAe4xfKMNY98TDPj5pSPygtIqHTSNvJdc1NYTf5thvNVMg62OH5LU4QfCAj24wQXk8h1fAyvZSWqv6DFkAgPPR65kyEQ23U3A9gaQz/iR4ys4j0YvPfJTfDMocUyl1BeH7qKNgwPQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=E280O5KhfrmLSbKYVn5YMBohnwdHJ9sXujDfZe23R74=; b=KrBBuyFmZk/xzHBigHZPK5FBp4hYdpyOSOXki+XuZrHZRMckZTRsvI+KiFYZwb7GKcWtkz1r0S3PbJbKXYXXJA5y8S5GPwgjRz7Pl/XPXSIyhAL6EUoqtKRVfw4c3vXeXUB/MI300fr2qCrpjpbvUDYrQ//iN2juwWq+P7qwRvcK9bLi9HJQ/BUmA355g4of1qhD936YzcxIACwuo3sEASEixxxoQOCcq0HpoW8vz84jlPy4aMGROHh+IDaMXfgZBfMu6zgufqmW03l2F4Iwvb/VNpEVu7nVrL2fmLcz1L0h2FjnWTFvEEdsuHl2b3FNhH0eqcHjVbO7NyHMH+cf5A==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
Received: from LV8PR11MB8536.namprd11.prod.outlook.com (2603:10b6:408:1ec::19) by PH7PR11MB6056.namprd11.prod.outlook.com (2603:10b6:510:1d4::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7828.22; Fri, 2 Aug 2024 15:15:09 +0000
Received: from LV8PR11MB8536.namprd11.prod.outlook.com ([fe80::ff1c:486e:efc9:119e]) by LV8PR11MB8536.namprd11.prod.outlook.com ([fe80::ff1c:486e:efc9:119e%3]) with mapi id 15.20.7828.016; Fri, 2 Aug 2024 15:15:07 +0000
From: "Rob Wilton (rwilton)" <rwilton@cisco.com>
To: Kent Watsen <kent+ietf@watsen.net>, "Shiya Ashraf (Nokia)" <shiya.ashraf=40nokia.com@dmarc.ietf.org>
Thread-Topic: [netmod] Defining groupings after the fact? draft-jouqui-netmod-yang-full-include and the reuse of definitions
Thread-Index: AQHa5N7THb+Nkg7W4k6GnJuAg9E35LIUCwUq
Date: Fri, 02 Aug 2024 15:15:07 +0000
Message-ID: <LV8PR11MB8536F394FD1B80AADE9357E1B5B32@LV8PR11MB8536.namprd11.prod.outlook.com>
References: <e111be29-e825-4357-88e3-19c9b3f87930@clemm.org> <b0780aa0c8504c93b7d5ff6c837ea697@huawei.com> <2abcd109-455b-42f3-8529-fb9f3d68321e@clemm.org> <AM9PR07MB77296196896D50A06FC6A1A39CB22@AM9PR07MB7729.eurprd07.prod.outlook.com> <d804e1bf-931a-44dd-a00f-d21606edd2de@clemm.org> <AM9PR07MB7729A5190CF4A48E9F3E3C8B9CB32@AM9PR07MB7729.eurprd07.prod.outlook.com> <01000191133fffc0-9dad0787-154a-4f66-a2c8-2f5a4b6dadc6-000000@email.amazonses.com>
In-Reply-To: <01000191133fffc0-9dad0787-154a-4f66-a2c8-2f5a4b6dadc6-000000@email.amazonses.com>
Accept-Language: en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: LV8PR11MB8536:EE_|PH7PR11MB6056:EE_
x-ms-office365-filtering-correlation-id: 7aca48b6-ca6e-49b4-825b-08dcb305e4f4
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|4022899009|1800799024|376014|366016|38070700018;
x-microsoft-antispam-message-info: Gg05ZwzAehsrFOANm1U7jilbRY/ZC+dQ8Eg2gqo27TJhULn027/K9ZNYcj6ODOzkLx0euHxNl8a9nFSxYPsuYGBYIKUR+5b87ATMleKONBF/a8BfliGsr8Ywh8B3FZIlb6HyY20f0x4wVIRaM/IaR18brZVti+aWo33jwTftLNNyD9BI1fQ4BPWR2xHUCiFSA0QuOrBR8vVWONy/oCmPcUPHqhaMnFoGUesLowR6SHaYQCcSyiSHzu0U10Y0wj/MGcoMJBjvR3a1qSNn+KcWR6FQi2h76UbHm77BUk1kmCwV3SLhX0XlpEfwJT7dbOBzB+RZiIbgmhvp0RfAhMRIrk9/NzVvuVF6WYPT7YbeK+kBMqdtkSik0aJgmi9W4gQn+SP7WNpY//LasWv4RheAO188WD55v8F66BkGY7gOAr/JtJQr7sYyp4yAax04A+TAyA0Kucc0vSxSxk2nlnkLqZQswqtr9H20q0lkrjOje+EAAIHOlZzMtTVaxtxm8QvsPe7ooOL1gYDC4yB1Iz7O0xsry8swgBHqUuFFa4Sb/tNF8BRxGu98qFrHOHfxEqsVnpxAzxB4hFH9HuDN8hLnUlzwYfkDOSzTmfZEKpcRAkuA7+csahF1pltXeJGmvrnknI1zLW6fE5GbivHYarQIkd9VpYXBrUq1paxMfPqPMTYf9diAEYwSJP82dk3nvEV02yfZv1aXSA+Qm4IXIQd//8fASK+1fDUfNpdTV+lkF47jDhKIzpOOjuTcD6+IoXYxLyk7dEqGv3YbJLVki3GRHgpytLVmFvk/yjx/jaPO44VzZh6zx4OwqRR+Kcb+MbfeHyIODuXG0EWzbEGlEurjUeCOxD8+5M9Vmd5aQ+XeQ58jyGTqccRy9JKHwVrlardUUK5Pig/EP6ZUqDFRY+Tw3WYXONUny2kiRAyXq69gDNxZjC1CY6cZW0IGuxfAKpJhlhm5rMFvjg2cycXpelWpTgXl52ruXCYmYWWHVnIQOM4n5K1nykutmaoa6BeFVl484Z1JJfOq+2EM4gNH9y2fW2D/1XHr8kf/xkk5BdR60vYzS9Ox847yHqviilwOinE41bGG8WJuaR3FGrkuTALUXeztAexILwJI8opBLeDrFMvpchmv+dY1jTEUrMYQuixprUmuhpsHrKgKlRLoHmYdgcbbbjyzrMlF7+ZnN6yi+lWTcO6KHLAryY9u4TWFibAF5A8nsYOHVtkGDsiohVGauHaJlbWDzf0x1XrfbLWkVJLuxqgdhrFpoFDhxby6xN7yuQexTjFmfJaWiMUjBZSo+Yh8NToDEBsqYZW3xts2/IDXojEpzC7Z92bNSZUBFR5Op6m5FPgsneujyK3g/FGA/azWB2pf4sDLFQc2H0SADQI=
x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:LV8PR11MB8536.namprd11.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(4022899009)(1800799024)(376014)(366016)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: 1Affegp58ROA6pEnB7MpBHG3G9UuIYixhvfYQDgEt6LfOlpFVEYk/GH2I8BiUJ3H18p2ndiloSYhNo2hQ/re9H3rXZeXz3FWBiw3zZodV7FTARpH98Wy+86XRdkZs5S9cUZrBqnUl7YuljwFzueVj+hP4MBH+ajM1hnFnF94hR2AVpnPKgaETN+ry3JFRJbxLixmtgkVmEn0MOzZdwzRhhQ1mkmKjmMfa/HRbg+wOBvIZTvpPteQbquzS3XrE+kCfXc1A7yqBQGekm7BkMdsEfjzOzmjb6MxwEjV2Rl25Zf+XGXHE5xhFoNQNaCoo+BWpv6EsOPk1gq1LuGKop3VjWFemyvP+kIuc9uIBpqq6dPFHvgb1Rnz5JXGq/vmeZz8YCOo5Ce3DAg4agobl4Ev6jydSJF0jHw5JG7CSAMBwbLKI/93HREw3cfeUKnIavJtMuFO8PkiAFlyDAJGgW7ldQ7VY+MmzkX4RmKi+MWtPK6ZnKY2mQaurUFEbKKNoJDIFY8JwHwqYIDsT8cMQR3XI+bfZ33jW1rgNSLlOyQJiybjX5hVU3W7RHi3CMCSRL43vm+EWtywBsInPs/qpW/G1oMc0ebJY9o0kcGWrwhM9P5fieaqu/T3itYpsHuUxcZ+HoljqUaSNyDwThQpY60G4cpsdFkUhaLfvMQRvSbK92KizXTFmXjR7zKLgRQKviLpqAfqFRUxdWvMrrD0f7QLzyWUNoMYpRSFgmn/5XzzwkwwKIXnmrtLnvrn1Nu65I8LQ0UpBNeQMrTeZrl+QuOnzpSP1pqlfZ5ICBq7qkjjsvGcwGNZ4EA7oP9in3R/At2SS66gEz21Z6HdT+TbS6fvCxe2XXQlF/APKxBGEROM0o5WMzE5yHhxxENqfAhwWEpf9PPbt+3+x8MET83M2+sVDtFJUWJM9Un4YE0z026rs1AoxHsWjThNlM08fIaNC9+F+gaUYPv8rz0co7KqSwU3r2WF5FTpCUwbmF+a6X4LLuhG+aFAOtWuQNP/6lg/KhqIZnvkTAZ+mz/1NXOrYfRg3MfqUNGZIQGpm4+P7XLw7Kb72aGYUretg+ngDbcX5psRer8YyQeDMkQADX6eteFtMkPcFehKWoQt9OQaxnv3WXe5n2PUYMReJnsxQrfz5nHpTEehh9HaI6BmkCRst5h5ze7AVBAPpNnnDP7PXIPxrcjGbogqDh8J19KBhRr3W/ZOEuinaUnZWzWV/oTHebQyVgTJ0zQ/bma7iB6W3ztSXP8EsqfvMDYNvNNii9qGnCJoyc5dctv46tRq6R4Qojh62NIwH1mnFc8HVrNY+HAUd9GFC4fjAqJlAs1aQdveZwioIwF0HusrqPQwDq0vtxEwus7YVx2zRUO24SOjU7Y6wofDHTs2B3s7YY3aY5EXWOz1z6aYgf/lYfyZ+1nQKmori9/p9OYozArk3uPSxtJ4/6hNtoxVccxwyBL3uUHDVh0pfR2QwI8l2d8V7xHqMRmP3LfJ5nYnb5s3o6+yrPudc9Rw90V87Gmx0IusCdkIKkM8EusTQfx5CRce7irtNA0QGEp7XNc+KEu6B4/L5XGn5XqJ2Bp2bdPitjvSiLV+Z4Mc2+Ext644uXMj7b0trRlctZxHOmCfS2vm1y9GvPnhnToJXfwqQUh2DFHaAAfRBhzWIpiawdUAzEikH9rEMVbW3A==
Content-Type: multipart/alternative; boundary="_000_LV8PR11MB8536F394FD1B80AADE9357E1B5B32LV8PR11MB8536namp_"
MIME-Version: 1.0
X-OriginatorOrg: cisco.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: LV8PR11MB8536.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 7aca48b6-ca6e-49b4-825b-08dcb305e4f4
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Aug 2024 15:15:07.6820 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: BID5NWYkRmLhMc0NhIL9fbrSRG0dgJ05TSeEsuliFDRgvriGOX/ClGRBrn4cqzGNLjZWDNl1cJNF7AWzM0J7qA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR11MB6056
X-Outbound-SMTP-Client: 173.37.147.229, alln-opgw-1.cisco.com
X-Outbound-Node: alln-core-2.cisco.com
Message-ID-Hash: 5MHWMCGUFMFOTHXIC33EVMYLZY2UWTV2
X-Message-ID-Hash: 5MHWMCGUFMFOTHXIC33EVMYLZY2UWTV2
X-MailFrom: rwilton@cisco.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: Alexander L Clemm <ludwig=40clemm.org@dmarc.ietf.org>, "netmod@ietf.org" <netmod@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [netmod] Re: Defining groupings after the fact? draft-jouqui-netmod-yang-full-include and the reuse of definitions
List-Id: NETMOD WG list <netmod.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/2JiuzD4At6fu6aMDeMFDMy7jxlQ>
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>
I think that there is a balance to how much groupings are used. E.g., I would regard the OpenConfig models as an example of where groupings are overly used resulting in YANG models where it is impossible to glean the structure. I’m also not sure whether groupings really help here – e.g., if you put the top level of the module under a grouping, then another module may just want to reuse a subtree. I’m also slightly concerned about whether this can really be achieved in an extension (which tooling is allowed to ignore). I.e., it feels like this really need a new (probably major) version of the YANG language – and possible would need a more radical rethink about how to manage and reuse parts of YANG schema. Regards, Rob From: Kent Watsen <kent+ietf@watsen.net> Date: Friday, 2 August 2024 at 14:21 To: Shiya Ashraf (Nokia) <shiya.ashraf=40nokia.com@dmarc.ietf.org> Cc: Alexander L Clemm <ludwig=40clemm.org@dmarc.ietf.org>, Alexander L Clemm <ludwig@clemm.org>, Jean Quilbeuf <jean.quilbeuf@huawei.com>, BOUCADAIR Mohamed IMT/OLN <mohamed.boucadair@orange.com>, netmod@ietf.org <netmod@ietf.org>, Rob Wilton (rwilton) <rwilton@cisco.com> Subject: Re: [netmod] Defining groupings after the fact? draft-jouqui-netmod-yang-full-include and the reuse of definitions [CC-ing Med] I wonder if rfc8047bis should have a recommendation to use groupings extensively? FWIW, my "client-server” suite of drafts in NETCONF use groupings extensively. In fact, whenever a data-node is needed, it is always just a container that uses a grouping. Kent On Aug 2, 2024, at 4:54 AM, Shiya Ashraf (Nokia) <shiya.ashraf=40nokia.com@dmarc.ietf.org> wrote: Hello Alex, " However, even in that case, an update to the original model is still required - you cannot simply say "let me use these data definitions from that other models", they need to be defined as a grouping" <Shiya> Oh sure, absolutely. As you pointed out in one of the earlier emails, if this could address 99+% of the cases, why not do it at least for the models which we think will have more chance of getting reused, say for instance, ietf-interfaces, ietf-hardware etc. And this we could do it today in YANG 1.1 and with no extra tools support - which is clearly an advantage over the new embed mechanisms for faster commercial deployments of the solutions. Isn't it? Thanks, Shiya -----Original Message----- From: Alexander L Clemm <ludwig=40clemm.org@dmarc.ietf.org> Sent: Thursday, August 1, 2024 10:49 PM To: Shiya Ashraf (Nokia) <shiya.ashraf@nokia.com>; Alexander L Clemm <ludwig@clemm.org>; Jean Quilbeuf <jean.quilbeuf@huawei.com>; netmod@ietf.org Subject: Re: [netmod] Re: Defining groupings after the fact? draft-jouqui-netmod-yang-full-include and the reuse of definitions [You don't often get email from ludwig=40clemm.org@dmarc.ietf.org. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information. Hello Shiya, re your comment on the "Once models have been defined this way, they cannot be altered after the fact": Well, I guess as William has pointed out, it is possible to update a model with another, equivalent model which pulls data node definitions into groupings and then uses those groupings. That would be a compatible change. The same groupings will then also be free for other models to use. However, even in that case, an update to the original model is still required - you cannot simply say "let me use these data definitions from that other models", they need to be defined as a grouping (or per Jean's proposal in the draft, you define a new construct that would let you "use" aka embed definitions without the need for a grouping to be defined). Cheers --- Alex On 8/1/2024 2:20 AM, Shiya Ashraf (Nokia) wrote: Hi Alex, "<AC> Correct, you cannot augment a grouping. However, you can define a second grouping and then use both groupings. I do think that with properly designed modules that make extensive use of groupings 99+% of reuse scenarios would be covered. " <Shiya> Thanks for bringing this point up and I tend to fully agree here. In fact when I was reading the schema mount RFC where it starts with the short comings of "grouping", I also felt that there could be use-cases where some of these aspects of the groupings can turn out to be its strengths. For eg: for cases where you need greater control on what you want to embed on the mounted tree, for instance, only a selection of the augments from the original module or add new augments only on the embedding context etc. So though schema-mount/full-embed are very good solutions for reusability of existing YANG modules for certain use-cases with its own advantages, for many cases the existing methods based on groupings might do the job and in a much more simpler way. But then you say: " Once models have been defined this way, they cannot be altered after the fact." <Shiya> Could you explain more on this? Technically, One can still define a new grouping with all the data nodes that are today in a standard module and then replaces the content of the standard module with a simple uses statement of the new grouping with out causing a backward compatibility issue or any functional change, can’t we ? Thanks, Shiya -----Original Message----- From: Alexander L Clemm <ludwig=40clemm.org@dmarc.ietf.org> Sent: Thursday, August 1, 2024 12:37 AM To: Jean Quilbeuf <jean.quilbeuf=40huawei.com@dmarc.ietf.org>; netmod@ietf.org Subject: [netmod] Re: Defining groupings after the fact? draft-jouqui-netmod-yang-full-include and the reuse of definitions [You don't often get email from ludwig=40clemm.org@dmarc.ietf.org. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information. Hi Jean, thank you - quick replies in line --- Alex On 7/30/2024 2:35 AM, Jean Quilbeuf wrote: Hello Alexander, I put some answers inline. -----Original Message----- From: Alexander L Clemm <ludwig=40clemm.org@dmarc.ietf.org> Sent: Monday, July 29, 2024 8:22 PM To: netmod@ietf.org Subject: [netmod] Defining groupings after the fact? draft-jouqui-netmod-yang- full-include and the reuse of definitions Hello Jean, Benoit, Thomas, After your presentation at IETF 120, I looked at your draft https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fda tatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-jouqui-netmod-yang-full-i&da ta=05%7C02%7Cshiya.ashraf%40nokia.com%7Cf800a99bb9ed462e8f7108dcb26b a815%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638581422668726221 %7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI 6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=NdC02cJcdQPE7hc76ekJos%2B UoPjRQ4NEjYfLe4%2Ft%2B0k%3D&reserved=0 nclude- 02. I do have some questions regarding what happens if the embedded module is being augmented. Is the augmentation automatically embedded as well; does such embedding need to be explicitly stated? Is there a way to augment an embedded module only within the context of the embedding module? Yes, as per the example in the slides: if you want ietf-interfaces augmented by ietf-ip, you have to embed them both. <AC> I.e., you would need to augment the embedding module as well to embed the augmentation. The aumentation of the embedding module would then include a new "embed" statement to for the augmentation of the module that had been originally embedded. Correct? On a more general note, it strikes me that there is an increased need in reusing definitions. In various forms, we see this in your use cases, in network inventory use cases, in schema-mount, in peer-mount. YANG does not provide good support for that, which is somewhat ironic in that it does actually support several constructs with reuse and extensibility in mind, from identities to groupings. Hopefully the YANG-next effort will go a long ways towards improving definition reuse to that the need for after-the-fact bandaids can be avoided. Fully agree, the full embed as defined here should be a keyword in YANG-next. Similar constructs exist in protobuf and json-schema for instance. <AC> Cool. </ALEX> When it comes to reusing parts of definitions, it seems that a lot of grief could be avoided if portions that are to be reused would have been defined as groupings, which could then be used wherever needed. The problem is that the grouping construct is rarely used, so many YANG definitions are not available for reuse that otherwise might be. Grouping does not solve everything, you cannot augment a grouping so any augmentation would have to be repeated for each use of the grouping. I recommend reading the intro of RFC8528 YANG Schema Mount for a detailed description of these reuse issues. <AC> Correct, you cannot augment a grouping. However, you can define a second grouping and then use both groupings. I do think that with properly designed modules that make extensive use of groupings 99+% of reuse scenarios would be covered. The problem of course that in general groupings are used only sparingly and in cases where the need for reuse becomes obvious already within the same model. Once models have been defined this way, they cannot be altered after the fact. That is one of the shortcomings in YANG today, that it makes it easy to define models that are not as reusable as they should. </AC> As a thought, it might be useful to introduce a construct that will allow to define a _grouping_ after-the-fact, for later reuse. I.e., allow groupings to be defined in a way that the new grouping embeds an existing definition, then simply make use of that grouping. That would seem perhaps cleanest, able to address many of the use cases and have the additional advantage that the semantics here will be very clear since part of the exising YANG framework. There is still the augment issue from above, we have it in draft-ietf-opsawg-collected-data-manifest when reusing ietf-yang-push which augments ietf-subscribed-notifications. All these augments have to be rewritten with paths corresponding to the new location of the uses. <AC> I don't think that would be an issue, actually. Just declare modular, fine grained groupings and use those. Of course, this is somewhat a speculative discussion as YANG is what it is and does not support this today. This discussion probably belongs in YANG next. Perhaps I'll put together some slides at some point to illustrate what I mean. </AC> I think the semantics for Schema Mount as defined in RFC8525 is the key to reuse the full semantics of YANG (i.e. not only groupings but also augmentations, rpcs ...) without having to modify existing modules. What we propose in full embed is just to enable a simplified version of schema mount, for design time. Best, Jean <AC> Cheers, Alex </AC> --- Alex _______________________________________________ netmod mailing list -- netmod@ietf.org To unsubscribe send an email to netmod-leave@ietf.org _______________________________________________ netmod mailing list -- netmod@ietf.org To unsubscribe send an email to netmod-leave@ietf.org _______________________________________________ netmod mailing list -- netmod@ietf.org To unsubscribe send an email to netmod-leave@ietf.org _______________________________________________ netmod mailing list -- netmod@ietf.org To unsubscribe send an email to netmod-leave@ietf.org
- [netmod] Defining groupings after the fact? draft… Alexander L Clemm
- [netmod] Re: Defining groupings after the fact? d… Jean Quilbeuf
- [netmod] Re: Defining groupings after the fact? d… Robert Peschi (Nokia)
- [netmod] Re: Defining groupings after the fact? d… Alexander L Clemm
- [netmod] Re: Defining groupings after the fact? d… William Lupton
- [netmod] Re: Defining groupings after the fact? d… Alexander L Clemm
- [netmod] Re: Defining groupings after the fact? d… Shiya Ashraf (Nokia)
- [netmod] Re: Defining groupings after the fact? d… Alexander L Clemm
- [netmod] Re: Defining groupings after the fact? d… Kent Watsen
- [netmod] Re: Defining groupings after the fact? d… Shiya Ashraf (Nokia)
- [netmod] Re: Defining groupings after the fact? d… Kent Watsen
- [netmod] Re: Defining groupings after the fact? d… Rob Wilton (rwilton)
- [netmod] Re: Defining groupings after the fact? d… Andy Bierman