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

[Andy Bierman <[e-mail]>]

On Mon, Oct 15, 2018 at 1:28 PM, Robert Varga <[e-mail]> wrote:

> On 06/03/2018 00:56, [e-mail] 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.
>
>

I do not agree that the scope of this work should be expanded.
If there are specific language features that need to be standardized, then
a new
version of YANG should be standardized instead.


Andy



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 {
>         as:augmentable-statement;
>     }
>
>     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 7.20.3.2), 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.
>
> Regards,
> Robert
>
>
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod
>
>