[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