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