Re: [netmod] structured metadata for schema nodes using YANG extensions

Martin Björklund <mbj+ietf@4668.se> Wed, 13 March 2024 09:07 UTC

Return-Path: <mbj+ietf@4668.se>
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 392D2C15106F for <netmod@ietfa.amsl.com>; Wed, 13 Mar 2024 02:07:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.109
X-Spam-Level:
X-Spam-Status: No, score=-7.109 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_HI=-5, RCVD_IN_MSPIKE_H2=-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=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=4668.se header.b="2Vk6Vhws"; dkim=pass (2048-bit key) header.d=messagingengine.com header.b="eG7dWzso"
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 zQPHDfdRoJ3x for <netmod@ietfa.amsl.com>; Wed, 13 Mar 2024 02:07:48 -0700 (PDT)
Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF9C2C14F69D for <netmod@ietf.org>; Wed, 13 Mar 2024 02:07:48 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id B303332001FF; Wed, 13 Mar 2024 05:07:45 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Wed, 13 Mar 2024 05:07:45 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=4668.se; h=cc:cc :content-transfer-encoding:content-type:content-type:date:date :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm3; t=1710320865; x=1710407265; bh=piB+AIjc/Jh4Imcf/CLvYWlwBrA5Kc1lNHxcRF/S/Pg=; b= 2Vk6Vhws8jaVxTt3fwvKmfAEPh54w/qePhHy96pPj74gc8LEE17pnkkmgRMd7wsU dzwzHB6JuIOvMRSEtmOILApc7mtAdB3gZ6HHreVuklXM3TRQb6qVWgXD6DS0P8H1 kZYfWTITmIFj+mmd9LK2YM/IQr5CLTku2PJo5Cm0/D8ruf0jiOqAEoomiOmYSgoH 3KreDgI4yTMWL+BpfM1Tn1IbQzrmLK+YaNa+IvvhXDJaOCqsWTPNnK+p8e9xBUBF TJsCWcnu0Jr9Y5xvNAU311xt/DzqLSOa+++5lwQzKLUI6opb+rqhVcf5c8ubjzm2 QO9RMN3iMh9Q2pk9b3MMwg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1710320865; x= 1710407265; bh=piB+AIjc/Jh4Imcf/CLvYWlwBrA5Kc1lNHxcRF/S/Pg=; b=e G7dWzsolpZFsfQ5OXNH27rU72IrJiNvHAfRPk3EctImQ2SCnOQJ8z1qSd00Xfx4N 5WiDhuAr1lnttzNR+AVVkQgXLYthKIHTaY6QVPXfeN648H5e7G3CJvNrgf6WchSv svux7zWXzSGYIZL8BR90oZPX+vrLHYIxZVp9XxeRKctOvgU2Yf/c43qTHIcxVHAP CBTcNG7euQ5/uEWUtNBDNXePoUp5+0q5csFLFCEAsJTO8TTF/acKPDBcOHk3GFW+ 1KgG44CfgSlFTCXk8SFb3pX6Yabf0fcPjliX9Bs4z3BdlaFlJjqWSic047sVrEsl /UbYbmR1tl22mInHlUWKw==
X-ME-Sender: <xms:4GzxZXGi1jWff4kEiBt84zs5XmX30tmJDXLEJz1Um4H3TiLQ3y03UA> <xme:4GzxZUXMdsiFQWnsI1kMAohn16UJ2esf__5guTmnXzveV8gVmgnkUNXFCm6Zj1nf- mNgn_6D6Dcun2HgJx8>
X-ME-Received: <xmr:4GzxZZJPFzM8D1aAUmK3lW2dumLp1TscC871putGdx17n3YuzKCEvZt7ZXYrYL75syZ5YKDWTuqZLeoKftKiK1tB0G89H5bVBQ>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrjeeggdduvdelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffkffvvefuhfgjfhfogggtgfesth ejredtredtvdenucfhrhhomhepofgrrhhtihhnuceujhpnrhhklhhunhguuceomhgsjhdo ihgvthhfseegieeikedrshgvqeenucggtffrrghtthgvrhhnpeffkefhvdejheelkedvje eugeethfejueehgefhieevheejgefgteeuheduveetjeenucffohhmrghinhepghhithhh uhgsrdgtohhmnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhepmhgsjhdoihgvthhfseegieeikedrshgv
X-ME-Proxy: <xmx:4GzxZVF55e12VOfBkgV6uxx2d5wSnsBO1jt9lMS8fb35fmbDvh9nwg> <xmx:4GzxZdUxo8aGmnY0qaC6TCoxkTa0uWiKmzLzVmsq_Oa_7H7vPCnFMA> <xmx:4GzxZQMyhFlQKsxNJL8_I4r_mRR-ngokE43YXvM5i8h1RT8v052hdA> <xmx:4GzxZc2OmQl3Bc0fJ9ahnHrl7J0PuJCxca7XYxzXwRP664Gpw4gP2g> <xmx:4WzxZcf9-SO-7To0v_yrMp7lAOKPUhfavQKuu7OyaUKfPj7OnNTbdA>
Feedback-ID: icc614784:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 13 Mar 2024 05:07:44 -0400 (EDT)
Date: Wed, 13 Mar 2024 10:07:42 +0100
Message-Id: <20240313.100742.1986844484799977524.id@4668.se>
To: jason.sterne=40nokia.com@dmarc.ietf.org
Cc: netmod@ietf.org
From: Martin Björklund <mbj+ietf@4668.se>
In-Reply-To: <SN6PR08MB4847A4E43785C38E77331CC89B2B2@SN6PR08MB4847.namprd08.prod.outlook.com>
References: <SN6PR08MB4847A4E43785C38E77331CC89B2B2@SN6PR08MB4847.namprd08.prod.outlook.com>
X-Mailer: Mew version 6.8 on Emacs 27.1
Mime-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/jg4N_Re4zG9fWuReCX4potaJeNw>
Subject: Re: [netmod] structured metadata for schema nodes using YANG extensions
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Mar 2024 09:07:54 -0000

"Jason Sterne \(Nokia\)" <jason.sterne=40nokia.com@dmarc.ietf.org> wrote:
> Hi all,
> 
> I'm looking for information about doing more complex YANG extensions
> that the basic <name,value> type, e.g.:
> oc-ext:openconfig-version "2.5.0";

See https://github.com/netmod-wg/yang-next/issues/54 for a discussion
about one approach.



/martin






> 
> The node-tags approach doesn't fit what I'm trying to do (tags can't
> have values).
> 
> RFC7950 says the following:
>    The substatements of an
>    extension are defined by the "extension" statement, using some
>    mechanism outside the scope of this specification.  Syntactically,
>    the substatements MUST be YANG statements, including extensions
>    defined using "extension" statements.
> 
> Let me start with a simple example and build on it. Say I want to
> associate a color with any schema node. That's easy:
> 
>     extension color {
>         argument "color";
>         description "Takes a value of red, green or blue";
>     }
> 
>     leaf foo {
>         myext:color "red";
>     }
> 
> But what if I want a more complex structure for my color metadata like
> this?  (a leaf-list and leaf inside a container)
> 
>     leaf foo {
>         myext:chroma-metadata {
>             myext:colors "red green";
>             myext:saturation "45";
>         }
> 
> >From what I can tell, I'd have to define it like this:
> 
>     extension chroma-metadata {
>     }
>     extension colors {
>         argument "color-list";
>         description "sub-statement of chroma-metadata. Space separated list of
>         colors red, green and blue.";
>     }
>     extension saturation {
>         argument "saturation-level";
>         description "sub-statement of chroma-metadata";
>     }
> 
> Or if I wanted a list like this?
> 
>     myext:chroma-metadata {
>         myext:color "red" {
>             myext:saturation "45";
>         }
>         myext:color "green" {
>             myext:saturation "23";
>         }
>     }
> 
> I don't think there is any formal way to do it, but could I say that
> the structure of the chroma-metadata follows a grouping I define?
> 
>     grouping cm-struct {
>         list color {
>             leaf saturation { ... }
>         }
>     }
> 
> Could another option be to just define the top level extension
> chroma-metadata with a single argument, and then describe that the
> argument itself is a json-ietf blob of instance data that conforms to
> YANG grouping xyz?
> 
> Jason (he/him)
>