Re: [netmod] I-D Action: draft-ietf-netmod-yang-data-ext-01.txt

Robert Varga <> Mon, 15 October 2018 20:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5840B130EC3 for <>; Mon, 15 Oct 2018 13:28:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id D76lDWzELp9M for <>; Mon, 15 Oct 2018 13:28:14 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2A086130DE2 for <>; Mon, 15 Oct 2018 13:28:14 -0700 (PDT)
Received: from nitebug.localdomain ( []) by (Postfix) with ESMTPSA id 7C1A42401B7 for <>; Mon, 15 Oct 2018 22:28:11 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=mail; t=1539635291; bh=5laEnXvmYX509t1W9qrm64kfmH7xEP9fvigRH65UxM8=; h=Subject:References:From:To:Date:In-Reply-To; b=GHvqvjGiEXukWPBslva95QZZG7wEHDed6L+59K6KaGDgdvGABATt4qgVQXiB6oqnN v7wSQVD84hXXQJcnKU/XjEnC2InVqOceobKhKkb3b393lVSR0Cj/vGshnCEfpdz0iC ao4+ymKwMLSKIdEOCeIMAjgDpXPAz9c6jpnQ/tZ8=
References: <>
From: Robert Varga <>
Openpgp: preference=signencrypt
Message-ID: <>
Date: Mon, 15 Oct 2018 22:28:11 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="vs5nfXtnc4S6uu7jGNNlge2wHoUbl8BLI"
Archived-At: <>
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-yang-data-ext-01.txt
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 20:28:16 -0000

On 06/03/2018 00:56, wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Network Modeling WG of the IETF.
>         Title           : YANG Data Extensions
>         Authors         : Andy Bierman
>                           Martin Bjorklund
>                           Kent Watsen
> 	Filename        : draft-ietf-netmod-yang-data-ext-01.txt
> 	Pages           : 11
> 	Date            : 2018-03-05
> Abstract:
>    This document describes YANG mechanisms for defining abstract data
>    structures with YANG.  It is intended to replace and extend the
>    "yang-data" extension statement defined in RFC 8040.

Sorry to be a late reviewer on this.

To me "augment-yang-data" feels really like "augment a particular
instance of a schema tree", i.e. increasing specificity of augment
target node with knowledge on which tree instantiation it operates.

RFC7950 already does this (implicitly) for notification, rpc and action
statements by making them members of the schema tree and the same
"augment" and "deviation" mechanics for them being defined shared with
the data tree.

I would argue this problem from a different point of view.

I think the purpose of "augment-yang-data" would be much better
addressed with an extension usable within augment (and deviate) to
reference a particular schema tree instantiation.

What that means in terms of YANG metamodel is two-fold:

1) an extension statement can define a conceptual schema tree
instantiation -- very much like NMDA does, but applied not to datastore,
but to schema tree.

2) an augment (or deviation) statement can be restricted to operate on a
schema tree instantiation defined by an extension statement

Rough example:

    extension augmentable-statement;
    extension schematree-instance;

    extension yang-data {

    yd:yang-data foo;

    augment /foo {
        // i.e. interpret argument as a target valid in the schema tree
        // as defined by yang-data, with the semantics specified therein
        si:schematree-instance "yd:yang-data";

Note how as:schematree-instance is completely unnecessary here:
yang-data's use of as:augmentable-statement is already indicating that
the statement is augmentable, thus bridging it to RFC7950 section 7.19:

   An extension can allow refinement (see Section 7.13.2) and deviations
   (Section, but the mechanism for how this is defined is
   outside the scope of this specification.

hence the only extension that is needed for yang-data and future similar
extensions is augmentable-statement, simply because as soon as "augment"
argument touches an extension statement, you have to know something
about it. If an augment argument crosses an extension statement, it must
share fate with the parser's handling of the extension: if the parser
chooses to ignore the extension, it should reasonably also ignore the
augment statement.

Unless "augment" is not allowed to touch extension statements (i.e.
extensions must never define a schema tree member) -- if that is the
case, that should be normatively defined somewhere, too.