Re: [netmod] schematree-statement extension?

Martin Bjorklund <> Mon, 15 October 2018 19:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 74145124C04 for <>; Mon, 15 Oct 2018 12:09:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gZRDaI62m8od for <>; Mon, 15 Oct 2018 12:09:41 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id CB038130F24 for <>; Mon, 15 Oct 2018 12:09:38 -0700 (PDT)
Received: from localhost ( []) by (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: <>
From: Martin Bjorklund <>
In-Reply-To: <>
References: <>
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: <>
Subject: Re: [netmod] schematree-statement extension?
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 15 Oct 2018 19:09:51 -0000


Robert Varga <> 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