Re: [netconf] [netmod] YANG Push module errors

Robert Varga <nite@hq.sk> Tue, 13 April 2021 11:43 UTC

Return-Path: <nite@hq.sk>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26C2A3A116A; Tue, 13 Apr 2021 04:43:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hq.sk
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LQY23kYyUV5T; Tue, 13 Apr 2021 04:43:44 -0700 (PDT)
Received: from mail.hq.sk (hq.sk [81.89.59.181]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AF193A1166; Tue, 13 Apr 2021 04:43:44 -0700 (PDT)
Received: from nitebug.nitenet.local (46.229.239.158.host.vnet.sk [46.229.239.158]) by mail.hq.sk (Postfix) with ESMTPSA id 31F0A245135; Tue, 13 Apr 2021 13:43:39 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hq.sk; s=mail; t=1618314219; bh=XwdX1JJxfjoOCwVXlWEens2Yu5qpa8AoJfYDK6hH5Fw=; h=To:References:From:Subject:Date:In-Reply-To; b=Y6cE2Xlcwnh6ziZ859s5XuFwL0JlFPnomWB3LRBgGNh4Aiqal8y6IluCEGnGaue2d j8E7/WqS5m+ZogOzMv2dtvzkffi3dTuds5EuRL2XZWzpXPIK2RmRW21tnCyy07Uf2I Pv/mYkqiUeykhlxawlpIm4C/CHKjQKKjCvDnJ0QU=
To: =?UTF-8?Q?Michal_Va=c5=a1ko?= <mvasko@cesnet.cz>, Andy Bierman <andy@yumaworks.com>, "Eric Voit (evoit)" <evoit@cisco.com>, netconf <netconf@ietf.org>, netmod <netmod@ietf.org>
References: <52f2-606b1d80-d-7afd9d00@152658395> <87wntf3nca.fsf@nic.cz>
From: Robert Varga <nite@hq.sk>
Message-ID: <44da4ec9-da0e-ba39-eda1-b785b0f8d478@hq.sk>
Date: Tue, 13 Apr 2021 13:43:38 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1
MIME-Version: 1.0
In-Reply-To: <87wntf3nca.fsf@nic.cz>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="excyv2uMZZv8rGFLx1lMLA2Y7VNZcxZWL"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/mgshpo1eTL6RoJGFc5aglVkl3Ls>
Subject: Re: [netconf] [netmod] YANG Push module errors
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 13 Apr 2021 11:43:50 -0000

On 06/04/2021 09:04, Ladislav Lhotka wrote:
>> I see. Okay, thanks for the clarification and yes, if this was explicitly mentioned in the RFC it would be great. Although, the validity of your example was not in question. Rather something like:
>>
>>     container foo {
>>         if-feature X;
>>         container bar;
>>     }
>>
>>     augment /foo/bar {
>>         container Y;
>>     }
>>
>> I am just going to assume this is what you meant and simply that the requirement is that any schema path must point to an existing schema node, ignoring any "if-feature" statements.
> I think it also depends on whether features are set before or after processing the modules. In the former case, an augment statement with an effectively missing target node can IMO be silently ignored, without even parsing its contents.

This very case has been discussed here:
https://mailarchive.ietf.org/arch/msg/netmod/Icd5c8J27P3UKjloNG8VC9fApoM/

FTR the original request for OpenDaylight lives here:
https://jira.opendaylight.org/browse/YANGTOOLS-859 and it provides some
additional context.

As an implementation author, I certainly did not like the implications
of the request, but Andy brought up a very important point in that thread:

> The modules are valid.
> The conformance decision (i.e., which features are advertised and which are
> not by a server implementation)
> does not change the compile-time validity of the YANG modules

i.e. even if the YANG modules are being interpreted as part of
assembling a server implementation, if-feature processing phase comes
only after cross-statement relationships have been established and
therefore the augment is valid, but 'container Y' disappears just as
'container bar' does.

This is further reinforced by Martin's response in this (related)
thread:
https://mailarchive.ietf.org/arch/msg/netmod/9JgPZphOdim-wLZA3NrSe3I1un4/

Regards,
Robert