[netmod] Re: Defining groupings after the fact? draft-jouqui-netmod-yang-full-include and the reuse of definitions

Alexander L Clemm <ludwig@clemm.org> Wed, 31 July 2024 22:37 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 53889C14F71E; Wed, 31 Jul 2024 15:37:07 -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 NKW2tSIzXnjl; Wed, 31 Jul 2024 15:37:03 -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 C4C55C14F69C; Wed, 31 Jul 2024 15:37:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=clemm.org; s=s1-ionos; t=1722465421; x=1723070221; i=ludwig@clemm.org; bh=o3BT3TPy5IBWG8h2y9owrIGv5jl54f0Xx3338mMcAiI=; h=X-UI-Sender-Class:Message-ID:Date:MIME-Version:Subject:To: References:From:In-Reply-To:Content-Type: Content-Transfer-Encoding:cc:content-transfer-encoding: content-type:date:from:message-id:mime-version:reply-to:subject: to; b=P0dFLGEcWHSaNiYQtDaFJKZGUV/pzO0o0fPSDOLLy0Dzu5NfhHse+mA0mq093IiV vfzVubDSIq+AzK3IQvLvMCxki3lYUR4Ybe1+6sYHQmqd5OYC/hrw/sxB+j2coMRgD h9fDWXWSgC3FVtq+hTJptpPhA+qQ8myJ2FktUUKIKHr9Fo7ivvvXZv1GPM69ELiT0 9RY2SD6AACRL6jQD6Yc8MvhRp+tY5IUTMw46rj6Hh5wA4vvwvzc/kdOv+uxMd9DT1 a8GQmK1n7ltLtsxfgQk2I6mbK6CK3EPghgcAEjXD9EqFtFpF7gfoLziBI2fQrWzvA MgzDHAKK3JowAtvAhA==
X-UI-Sender-Class: 55c96926-9e95-11ee-ae09-1f7a4046a0f6
Received: from [172.16.0.44] ([172.56.46.195]) by mrelay.perfora.net (mreueus003 [74.208.5.2]) with ESMTPSA (Nemesis) id 0MIcHO-1sX50v2MW0-002DPU; Thu, 01 Aug 2024 00:37:01 +0200
Message-ID: <2abcd109-455b-42f3-8529-fb9f3d68321e@clemm.org>
Date: Wed, 31 Jul 2024 15:36:59 -0700
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: Jean Quilbeuf <jean.quilbeuf=40huawei.com@dmarc.ietf.org>, "netmod@ietf.org" <netmod@ietf.org>
References: <e111be29-e825-4357-88e3-19c9b3f87930@clemm.org> <b0780aa0c8504c93b7d5ff6c837ea697@huawei.com>
Content-Language: en-US
From: Alexander L Clemm <ludwig@clemm.org>
In-Reply-To: <b0780aa0c8504c93b7d5ff6c837ea697@huawei.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:Tfr4g5OgO0NXyaQQwAKqPR/RxZ16S701LjIUg5X45y+Zgxj6jq/ ECvXJ5zf2RU9wWwICr/cYampn0NoyXFHqH6CzVovoWIQGV3wzisB9MhU+Ofm42TtLWwgVC7 X07VwFhmiu2kO43HVWhioxPByNmU3wctN3ulziuUU51cFMgmI1pTCKXh0MAy9A29kYH+epV 5Hqdc5Uo4ucvY206Rot+w==
UI-OutboundReport: notjunk:1;M01:P0:cnDNl6rp2ps=;/zNn0pCxvvyEMaExTJo5QcroeR/ XRoW+tluzBKDIuMooLrWuwFHOzGI81Jh2snY4vBZfIWmjlosmUvJtOcTThlx/j+xsjKBkWgN5 nnPFN7pS8tFXkNgdXmki4eV6TRF1FNwO7qrQ8Afez+sayNqnnotsqs50sIz8UqjGc4y12AM7m yI16wLeLzrqJV73hSEY1pJtA/nq1eOy6Coi0leRNa/kXyzV/UNt2wM4zCvZJqcSfeGPeOfn2z ftrjeSTIVjFUhiSDhnAJh0dHtIJXDl/Iuob4fc6lRiGi/zRlu4dGjkukuSMjC9iJLRsseLlgF btv1ReL0lKzBd2GjESgwfkuER2/BASwV6GBN0EnNL8oQLR1ZQ5fu8VB+BeynpTBdwLwbxQEym okSuLMxJXiuUxkryL/2NM/s+KkJL+Clmp/9ehPYCzydYnUxnNQC0nz0XCgR+sy5jCt/cA9yw0 hfh0QqPkOzrjUyXg02TK1+U0+gJRKRfCZR9actME+EUvnbT9o8cqxmW54D3RL2ltBLDOW9VKO EBzJNsNvH8RO731ZQrP1DTPov9UINfM7OgmlxO0Lp8CfcuMDchGoUZ64+0GXVjCk22pKcm7lQ Pua5WC+ILNjBb9mg44GSwBiqE+RsCYQ7Haep0k+obttScEEmyiusq/Fu8X4N+P8WUKMXfjMev 1vf1Xav64ojvJH6PRG13zPUq2LYflEkGjroGldkomk3BKKdyiK0Q+Ru5i/NAG7r+6P6ckXwnL st0CZFLCC7GbZ9tWAaYiOtfId+4cOSTFg==
Message-ID-Hash: A3Q2KIFUBHT46O4CCMBHIOQO5OBZKUOI
X-Message-ID-Hash: A3Q2KIFUBHT46O4CCMBHIOQO5OBZKUOI
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] 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/SyP_c7XhBAwYQNAeXre89a_Vkl0>
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>

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://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?
> 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