Re: [netmod] YANG augmentation in notification
Alex Huang Feng <alex.huang-feng@insa-lyon.fr> Thu, 12 January 2023 16:54 UTC
Return-Path: <alex.huang-feng@insa-lyon.fr>
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 9D190C1527BE for <netmod@ietfa.amsl.com>; Thu, 12 Jan 2023 08:54:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.528
X-Spam-Level:
X-Spam-Status: No, score=-4.528 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_HELO_IP_MISMATCH=2.368, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
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 DC8xIlwXZOXe for <netmod@ietfa.amsl.com>; Thu, 12 Jan 2023 08:54:43 -0800 (PST)
Received: from smtpout01-ext2.partage.renater.fr (smtpout01-ext2.partage.renater.fr [194.254.240.33]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59BD3C15C523 for <netmod@ietf.org>; Thu, 12 Jan 2023 08:54:15 -0800 (PST)
Received: from zmtaauth03.partage.renater.fr (zmtaauth03.partage.renater.fr [194.254.240.26]) by smtpout10.partage.renater.fr (Postfix) with ESMTP id EABA96308E; Thu, 12 Jan 2023 17:45:43 +0100 (CET)
Received: from zmtaauth03.partage.renater.fr (localhost [127.0.0.1]) by zmtaauth03.partage.renater.fr (Postfix) with ESMTPS id D419780085; Thu, 12 Jan 2023 17:45:43 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by zmtaauth03.partage.renater.fr (Postfix) with ESMTP id CC3EA8001D; Thu, 12 Jan 2023 17:45:43 +0100 (CET)
Received: from zmtaauth03.partage.renater.fr ([127.0.0.1]) by localhost (zmtaauth03.partage.renater.fr [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Wof0eOn3GNK7; Thu, 12 Jan 2023 17:45:43 +0100 (CET)
Received: from 176.146.148.215 (unknown [194.254.241.251]) by zmtaauth03.partage.renater.fr (Postfix) with ESMTPA id 739B98012F; Thu, 12 Jan 2023 17:45:43 +0100 (CET)
From: Alex Huang Feng <alex.huang-feng@insa-lyon.fr>
Message-Id: <5B6C8D57-85C2-4BD3-BA07-386C8AE9DFD7@insa-lyon.fr>
Content-Type: multipart/alternative; boundary="Apple-Mail=_95A217BF-B04A-4661-ADDF-D05187BC8215"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\))
Date: Thu, 12 Jan 2023 17:45:42 +0100
In-Reply-To: <20221205.110218.1169164776212238415.id@4668.se>
Cc: Thomas Graf <Thomas.Graf@swisscom.com>, Martin Björklund <mbj+ietf@4668.se>
To: netmod@ietf.org
References: <BE9858A6-80CF-4819-89C6-4FE8EBA603B7@insa-lyon.fr> <20221205.110218.1169164776212238415.id@4668.se>
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Virus-Scanned: clamav-milter 0.103.6 at clamav01
X-Virus-Status: Clean
X-Renater-Ptge-SpamState: clean
X-Renater-Ptge-SpamScore: -100
X-Renater-Ptge-SpamCause: gggruggvucftvghtrhhoucdtuddrgedvhedrleeigdelfecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucftgffptefvgfftnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefhkfgtggfuffgjvefvfhfosegrtdhmrehhtdejnecuhfhrohhmpeetlhgvgicujfhurghnghcuhfgvnhhguceorghlvgigrdhhuhgrnhhgqdhfvghnghesihhnshgrqdhlhihonhdrfhhrqeenucggtffrrghtthgvrhhnpeehgfdtteetvdevgfejtefffefgfeekgeefteeigeeftdevkeetgfejveevvefgheenucffohhmrghinhepghhithhhuhgsrdgtohhmpdhivghtfhdrohhrghdprhhftgdqvgguihhtohhrrdhorhhgnecukfhppeduleegrddvheegrddvgedurddvhedunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepudelgedrvdehgedrvdeguddrvdehuddphhgvlhhopedujeeirddugeeirddugeekrddvudehpdhmrghilhhfrhhomheptehlvgigucfjuhgrnhhgucfhvghnghcuoegrlhgvgidrhhhurghnghdqfhgvnhhgsehinhhsrgdqlhihohhnrdhfrheqpdhnsggprhgtphhtthhopeefpdhrtghpthhtohepnhgvthhmohgusehivghtfhdrohhrghdprhgtphhtthhopefvhhhomhgrshdrifhrrghfsehsfihishhstghomhdrtghomhdprhgtphhtthhopehmsghjodhivghtfhesgeeiieekrdhsvg
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/KtHX1_9usm7vrubJj1qOwgVZFvc>
Subject: Re: [netmod] YANG augmentation in notification
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: Thu, 12 Jan 2023 16:54:46 -0000
Dear Netmod WG, I created the issue on github on the pyang project regarding augmented notification containers with mandatory leaves. https://github.com/mbj4668/pyang/issues/840 <https://github.com/mbj4668/pyang/issues/840> Regards, Alex > On 5 Dec 2022, at 11:02, Martin Björklund <mbj+ietf@4668.se> wrote: > > Hi, > > Alex Huang Feng <alex.huang-feng@insa-lyon.fr <mailto:alex.huang-feng@insa-lyon.fr>> wrote: >> Dear NETMOD WG, >> >> Some time ago I sent this email to the YANG doctors to check with >> them. I would also like to have your insights on mandatory augmented >> leaves. >> >> We are working on a YANG module for the following draft: >> https://datatracker.ietf.org/doc/draft-tgraf-netconf-yang-notifications-versioning/ <https://datatracker.ietf.org/doc/draft-tgraf-netconf-yang-notifications-versioning/> >> <https://datatracker.ietf.org/doc/draft-tgraf-netconf-yang-notifications-versioning/ <https://datatracker.ietf.org/doc/draft-tgraf-netconf-yang-notifications-versioning/>> >> In this draft, we are augmenting a notification container in the YANG >> module adding new leaves. >> We would like to have some of these leaves mandatories if the current >> YANG is used but are having an error code using the pyang compiler >> (error: cannot augment with mandatory node "revision-label”). >> >> The resulting YANG tree without the mandatory statement is the >> following: >> module: ietf-yang-push-metadata >> >> augment /yp:push-update: >> +--ro module? string >> +--ro namespace? string >> +--ro revision? rev:revision-date-or-label >> +--ro revision-label? ysver:version >> +--ro datastore-xpath-filter? yang:xpath1.0 {sn:xpath}? >> +--ro datastore-subtree-filter? {sn:subtree}? >> In RFC7950 Section 7.17, there is the following statement regarding >> the mandatory fields in augmented YANGs: >> >> If the augmentation adds mandatory nodes (see Section 3 >> <https://www.rfc-editor.org/rfc/rfc7950#section-3 <https://www.rfc-editor.org/rfc/rfc7950#section-3>>) that >> represent configuration to a target node in another module, the > ^^^^^^^^^^^^^^^^^^^^^^^ > >> augmentation MUST be made conditional with a "when" statement. Care >> must be taken when defining the "when" expression so that clients >> that do not know about the augmenting module do not break. >> >> Does this statement applies to YANG notification containers? >> Or does this statement applies only to configuration YANG modules? > > It applies to configuration nodes. > >> Is this a pyang compiler bug? > > Yes. > > > /martin > > > >> >> Regards, >> >> Alex Huang Feng
- [netmod] YANG augmentation in notification Alex Huang Feng
- Re: [netmod] YANG augmentation in notification Martin Björklund
- Re: [netmod] YANG augmentation in notification Alex Huang Feng