[netmod] YANG augmentation in notification

Alex Huang Feng <alex.huang-feng@insa-lyon.fr> Mon, 05 December 2022 09:50 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 A173BC1522B7 for <netmod@ietfa.amsl.com>; Mon, 5 Dec 2022 01:50:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.474
X-Spam-Level:
X-Spam-Status: No, score=0.474 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_HELO_IP_MISMATCH=2.368, RCVD_IN_DNSWL_BLOCKED=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=no 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 7VSPWnoUrW30 for <netmod@ietfa.amsl.com>; Mon, 5 Dec 2022 01:50:27 -0800 (PST)
Received: from smtpout02-ext4.partage.renater.fr (smtpout02-ext4.partage.renater.fr [194.254.241.31]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C195C1522B6 for <netmod@ietf.org>; Mon, 5 Dec 2022 01:50:27 -0800 (PST)
Received: from zmtaauth04.partage.renater.fr (zmtaauth04.partage.renater.fr [194.254.241.26]) by smtpout20.partage.renater.fr (Postfix) with ESMTP id C1C75C00F9; Mon, 5 Dec 2022 10:50:21 +0100 (CET)
Received: from zmtaauth04.partage.renater.fr (localhost [127.0.0.1]) by zmtaauth04.partage.renater.fr (Postfix) with ESMTPS id E43961C0107; Mon, 5 Dec 2022 10:48:42 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by zmtaauth04.partage.renater.fr (Postfix) with ESMTP id DDA8B1C0153; Mon, 5 Dec 2022 10:48:42 +0100 (CET)
Received: from zmtaauth04.partage.renater.fr ([127.0.0.1]) by localhost (zmtaauth04.partage.renater.fr [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id G-pOiBXeFjsf; Mon, 5 Dec 2022 10:48:42 +0100 (CET)
Received: from 134.214.146.150 (unknown [194.254.241.251]) by zmtaauth04.partage.renater.fr (Postfix) with ESMTPA id A2C9D1C0107; Mon, 5 Dec 2022 10:48:42 +0100 (CET)
From: Alex Huang Feng <alex.huang-feng@insa-lyon.fr>
Content-Type: multipart/alternative; boundary="Apple-Mail=_D0ADBDAE-7FDE-4615-BBCA-658FD30A4E45"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\))
Message-Id: <BE9858A6-80CF-4819-89C6-4FE8EBA603B7@insa-lyon.fr>
Date: Mon, 05 Dec 2022 10:48:42 +0100
Cc: Benoit Claise <benoit.claise@huawei.com>, Thomas Graf <Thomas.Graf@swisscom.com>
To: netmod@ietf.org
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Virus-Scanned: clamav-milter 0.103.6 at clamav04
X-Virus-Status: Clean
X-Renater-Ptge-SpamState: clean
X-Renater-Ptge-SpamScore: -100
X-Renater-Ptge-SpamCause: gggruggvucftvghtrhhoucdtuddrgedvhedrudeggddtkecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucftgffptefvgfftnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefhtggguffkffevvffosegrtdhmrehhtdejnecuhfhrohhmpeetlhgvgicujfhurghnghcuhfgvnhhguceorghlvgigrdhhuhgrnhhgqdhfvghnghesihhnshgrqdhlhihonhdrfhhrqeenucggtffrrghtthgvrhhnpefgjeevgfevgfegffdvudegtdehheevvdduffekgfduudfggeeiledtfedtueekkeenucffohhmrghinhepihgvthhfrdhorhhgpdhrfhgtqdgvughithhorhdrohhrghenucfkphepudelgedrvdehgedrvdeguddrvdehudenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepihhnvghtpeduleegrddvheegrddvgedurddvhedupdhhvghlohepudefgedrvddugedrudegiedrudehtddpmhgrihhlfhhrohhmpeetlhgvgicujfhurghnghcuhfgvnhhguceorghlvgigrdhhuhgrnhhgqdhfvghnghesihhnshgrqdhlhihonhdrfhhrqedpnhgspghrtghpthhtohepfedprhgtphhtthhopehnvghtmhhougesihgvthhfrdhorhhgpdhrtghpthhtohepsggvnhhoihhtrdgtlhgrihhsvgeshhhurgifvghirdgtohhmpdhrtghpthhtohepvfhhohhmrghsrdfirhgrfhesshifihhsshgtohhmrdgtohhm
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/n6CS-p0anUM_2eXiMxXBwk8UUOE>
Subject: [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: Mon, 05 Dec 2022 09:50:32 -0000

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/>
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>) 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?
Is this a pyang compiler bug?

Regards,

Alex Huang Feng