[netmod] Defining groupings after the fact? draft-jouqui-netmod-yang-full-include and the reuse of definitions
Alexander L Clemm <ludwig@clemm.org> Mon, 29 July 2024 19:22 UTC
Return-Path: <ludwig@clemm.org>
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 95959C180B5B for <netmod@ietfa.amsl.com>; Mon, 29 Jul 2024 12:22:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Level:
X-Spam-Status: No, score=-2.106 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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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=clemm.org
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 fsnjfcPgJ9-M for <netmod@ietfa.amsl.com>; Mon, 29 Jul 2024 12:21:56 -0700 (PDT)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.197]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B254AC180B70 for <netmod@ietf.org>; Mon, 29 Jul 2024 12:21:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=clemm.org; s=s1-ionos; t=1722280915; x=1722885715; i=ludwig@clemm.org; bh=nwQs+K4gaEsnUvb0ZPZhTN01Ylj6IGjYa4/0FxvPGAs=; h=X-UI-Sender-Class:Message-ID:Date:MIME-Version:To:From:Subject: Content-Type:Content-Transfer-Encoding:cc: content-transfer-encoding:content-type:date:from:message-id: mime-version:reply-to:subject:to; b=Ny+Jj0yUXK8oSz8619CiJeBJzVu0uz69/HxSl1NZ6V233YKC2Ut1Eo/+L3qk/vEc 0UHtpnp8HoTJLrqdtGDaBA4y3PPaY5Cyl15AK2cz20++Z1ucdg+TCr31AVgJgMIoy 5oOkuzOIGqqTW1N5MIdpPWEArgNklVqwlbT4v7kkC9vQIN10hX5sw7+TcP7weF+n3 cHqBlyaZUY7RSuxTg6MDQe3YkH+OZyJOLR7I7z8AQOdppX58BEDRfgtJGYUmcLL/S V9DrQwUZMnJwGxZdCRFSinxONVEA2Rhiu1r6qHGhUAyswS7Qh3bb3wa3hnM5xtDvi /bdu4WgeOI+PTJHX4A==
X-UI-Sender-Class: 55c96926-9e95-11ee-ae09-1f7a4046a0f6
Received: from [172.16.0.44] ([172.56.46.195]) by mrelay.perfora.net (mreueus004 [74.208.5.2]) with ESMTPSA (Nemesis) id 1MQuoF-1ssXMS0wpL-00JRlE for <netmod@ietf.org>; Mon, 29 Jul 2024 21:21:55 +0200
Message-ID: <e111be29-e825-4357-88e3-19c9b3f87930@clemm.org>
Date: Mon, 29 Jul 2024 12:21:53 -0700
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: "netmod@ietf.org" <netmod@ietf.org>
From: Alexander L Clemm <ludwig@clemm.org>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:CEz2Fb9thxJbjfbQHjJs1A4+E70Puh9v24FCOkXm8pSerfa78qi 1sElC5zbzVmno12+W6Wb4OZCC4bdgTc4CfNyQdkn69YJ1kR+E/3tcdcsxKDwm+/BhtHABMC BSprHnVZX9wQnShXzrZd9lfGszN1ZUxp2CG0ssmmeHITM7UkqypcobgagBUT1iKuyfiOI2d 2bat7nI7ddevPxTRqGUtA==
UI-OutboundReport: notjunk:1;M01:P0:iGMnLkENt5k=;9oTw0MMTWneQ+5dul88o2/8rtRu e5hwCTpesAOWWVJRcO5R+bd+AjnaDG2C+pHSNu5i+Kon+lzA6xeeRIJAAAmyhLARSVeOCVmNy GjSx41F5CQ31ECDxnDfLuodDkYFhTlqcvz8MU81O9xYgwN4lXHKjDdaNtltFWviOwb+B8U9Mv V0S/mRivxn0iyEaw8RcRWkuAyYX71psGgY+vFls/E72+/BVV64Ef3o748CJRFcgQNb7HB0xJK W9JBsXdZdrTRHzR/gWBqTjHRpJO2wm7fXtZxA77IvGMzJR8Ln8Bn/OmCVPd/QCJ7DlQpTYiCi OAABLMP5QNPeIlFvy0OJWf9LoOtOHzQ54PrTFWwHnisSwSPAVY4N+O0XivOfRGdCEM529/kST gI6qc8c4vjvMF9igdUPnzq0WJapb1KwWtUM7U/f8cA2bOKOmsP4U1qm1aPPDLOisFHJ+vi9jX LSNlmivQjbeQrMXdmnTY4mp7RsrwHLQGVLqgPOaXxuZ1KHg66w3ueymBxpNqRAe8mOLl6fKit jxb3N5RkUk4ReWHZ2LmYV2/BOZ4nbp+rQvC2fzbIpDxWbJdtDIvl6QWPRNzCQNK9P7tiFaD56 NrJIiRKkaEC+WyeSpqgE6VYvFiokrBkuLT6voVnykEHGXmfYJQLRTMkX0k1OsebE9QAJh0dhw FCyRWWrWKfaEKJFmtGIoSPcnwOnnNSoWwCjuvZeAAKnCa85Zayu8usk0JOF27zz4/0n0gTi3X Y7KkulNw/ViTIpsY0eQdhr3Bx9Q1/nLrQ==
Message-ID-Hash: 3EWIMMP4WGS4ED2IJ2NTBQHGIW353JJQ
X-Message-ID-Hash: 3EWIMMP4WGS4ED2IJ2NTBQHGIW353JJQ
X-MailFrom: ludwig@clemm.org
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
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [netmod] 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/XCW5qikUKVxYinJoNKXW6ztIkHM>
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>
Hello Jean, Benoit, Thomas, After your presentation at IETF 120, I looked at your draft https://datatracker.ietf.org/doc/html/draft-jouqui-netmod-yang-full-include-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? 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. 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. 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. --- Alex
- [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