Re: [netmod] schematree-statement extension?

Martin Bjorklund <mbj@tail-f.com> Mon, 15 October 2018 19:09 UTC

Return-Path: <mbj@tail-f.com>
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 74145124C04 for <netmod@ietfa.amsl.com>; Mon, 15 Oct 2018 12:09:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 gZRDaI62m8od for <netmod@ietfa.amsl.com>; Mon, 15 Oct 2018 12:09:41 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id CB038130F24 for <netmod@ietf.org>; Mon, 15 Oct 2018 12:09:38 -0700 (PDT)
Received: from localhost (h-80-27.A165.priv.bahnhof.se [212.85.80.27]) by mail.tail-f.com (Postfix) with ESMTPSA id 313861AE033A; Mon, 15 Oct 2018 21:09:37 +0200 (CEST)
Date: Mon, 15 Oct 2018 21:09:37 +0200 (CEST)
Message-Id: <20181015.210937.2105117531520960939.mbj@tail-f.com>
To: nite@hq.sk
Cc: netmod@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <4d793f08-4073-751e-105d-f83ce407611c@hq.sk>
References: <4d793f08-4073-751e-105d-f83ce407611c@hq.sk>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/HCghtdTeYlU9Eo-MUjwlcTtR_6M>
Subject: Re: [netmod] schematree-statement extension?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
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, 15 Oct 2018 19:09:51 -0000

Hi,

Robert Varga <nite@hq.sk> wrote:
> Hello,
> 
> I have recently been reminded that there is a potential interoperability
> issue between RFC6020/RFC7950 and extension statements. So far the only
> case where this has manifested is tailf:action, but there may be others
> lurking in the future.
> 
> The issue is that a YANG extension has no standardized way of declaring
> it is a part of the schema tree, which means that unless a parser has at
> least partial support for a particular extension, attempting to use
> deviation or augment statements with it cannot work.
> 
> It is wide-spread practice to use tailf:action and target statements
> within it with augment/deviate statements -- which I think is a failure
> to follow RFC7950 section 6.3.1:
> 
>    Care must be taken when defining extensions so that modules that use
>    the extensions are meaningful also for applications that do not
>    support the extensions.

Yes, but note that 7950 means a 1.1 module, and tailf:action should be
replaced with 'action' in a 1.1 module.

One reason we added the quoted paragraph to 7950 was because of the
problem you describe with tailf:action.

> Therefore a parser which ignores the extension in its entirety, as per
> section 6.3.1, will not populate the schema tree with the production of
> (for example) 'tailf:action foo' nor its descendants and hence an
> attempt to augment the use of the extension or any of its descendant
> will result in failure to resolve the schema node identifier to a schema
> tree node -- similar to what happens when an attempt is made to augment
> a non-existing statement, a grouping, a typedef or an extension
> statement (which may itself be unsupported).
> 
> I think the proper way of fixing this would be to define a YANG
> extension, which, when used within another extension, would indicate
> that the extension being defined is part of the schema tree, for example:
> 
>    extension schematree-statement;
> 
>    extension foo {
>        argument bar;
> 
>        sts:schematree-statement;
>    }

Unfortunately, this doesn't solve the problem, since a parser that
doesn't understand sts:schematree-statement still wouldn't know that
foo defined a schema node, and thus it will still complain if it sees
an augment of a node introduced with "ex:foo".

In order for this to work, "schematree-statement" would have to be a
builtin statement.

(... and if we had this statement, we could have used it in yang-ext
as well, and avoid augement-yang-data)

> With that, any parser not knowing "foo", but understanding
> "sts:schematree-statement" would know that:
> - foo's argument is an identifier as per RFC7950 section 14
> - the use of "foo" follows the usual schema tree population rules
> 
> Using that knowledge, the parser can correctly interpret
> augment/deviation arguments as validly pointing to a particular use of
> foo (or its descendants) and correctly ignore their effects.
> 
> Is this something the WG feels is a real problem and would be interested
> in solving?

The current advice is of course to NEVER add nodes to the schema tree
with an extension.  I think it is probably best to stick to this
advice...


/martin