[netmod] schematree-statement extension?

Robert Varga <nite@hq.sk> Mon, 15 October 2018 18:41 UTC

Return-Path: <nite@hq.sk>
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 B466B130EBB for <netmod@ietfa.amsl.com>; Mon, 15 Oct 2018 11:41:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] 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 iY8KlUd--P5j for <netmod@ietfa.amsl.com>; Mon, 15 Oct 2018 11:41:53 -0700 (PDT)
Received: from mail.hq.sk (hq.sk [81.89.59.181]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B671130EAA for <netmod@ietf.org>; Mon, 15 Oct 2018 11:41:53 -0700 (PDT)
Received: from nitebug.localdomain (chello085216197060.chello.sk [85.216.197.60]) by mail.hq.sk (Postfix) with ESMTPSA id A73D9240240 for <netmod@ietf.org>; Mon, 15 Oct 2018 20:41:50 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hq.sk; s=mail; t=1539628910; bh=84LC9k97XPYU1jeUJUAuvUmV454wBp7rrt4c1EaRuWs=; h=To:From:Subject:Date; b=H1EZ1MlnbInyaxbmER2jHc53oMSs+t/2lvyjKRfLDd8SMe+6NolIe0zgXNJpBd0V1 YsY+CZMhaRUTWNXrvZ2h+HDa5ZbVZmiKd7Teauq8rryCRKqtf+mQcxc9m1136kmx+l kjlMyUf2XajBqulDW2YwXdXEcJc+KLTV84SSHvEw=
To: "netmod@ietf.org" <netmod@ietf.org>
From: Robert Varga <nite@hq.sk>
Openpgp: preference=signencrypt
Message-ID: <4d793f08-4073-751e-105d-f83ce407611c@hq.sk>
Date: Mon, 15 Oct 2018 20:41:45 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="38YuB15dySnhpqARToYxE2N3zOTRqiGlW"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/7pJl6Ev4VQYZ9MhuaaqvqaHEQXw>
Subject: [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 18:41:56 -0000

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.

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;
   }

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?

Thanks,
Robert