Re: [netmod] New I-D Submission: draft-bertz-netmod-commonaugment

We did that.  Unfortunately, underlying YANG to object oriented code
generators treated the wrapping class as only inheriting the interface.
This seems fine until you attempt to translate from one of these classes to
another and the real work is much larger than expected.  Part of this is
the schema context carried in one object to another - copying is not just
copying as we began to discover.

The proposal's end result is the same as you propose - a grouping with
multiple augments and this is sufficient from a standards level as it
achieves the correct structures.  However, it appears to as separate,
independent modifications to the schema tree.   Thus, the intent of the
author (for it to be the same augment / addition in multiple locations) is
lost.

We then thought, "okay, modify the compiler to just assume equivalence"
which only works a) if that is true and b) if the signature is exactly the
same.  We could not guarantee a) and b) become problematic when computing
"exactly the same"; especially across modules (which is another subject
entirely).

The final issue is one of space.  If you only support the extension you
have the intent of the author and a smaller amount of YANG.  However, we
keep the proposal backwards compatible assuming that we will not just dump
old YANG files for slightly better ones.

A final point, this should not be an issue in the main information tree as
it implies you have an object "everywhere" which begs several questions
regarding design.  It is however a common problem when you have several
rpcs that send data in the request and response.  It was in the rpc
definitions that we really took a hit when implementing the DMM FPC drafts.

Lyle

On Fri, Mar 10, 2017 at 8:17 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:

> Lyle Bertz <lyleb551144@gmail.com> writes:
>
> > Understood.
> >
> > Let's discuss at the meeting though.  This was a significant issue in the
> > development of the IETF DMM FPC yang files and our open source project.
>  I
> > am open to this going in the proper direction wherever that is but wanted
> > to bring the issue and a possible solution to the table.
>
> Yes, that's fine. One way to alleviate this problem is to define a
> grouping and then have multiple augments that use this grouping. We used
> this approach in RFC 8022. Would this work for your use cases?
>
> Lada
>
> >
> > Lyle
> >
> >
> > On Tue, Mar 7, 2017 at 2:43 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
> >
> >> Hi,
> >>
> >> while the use case is clear, I believe such rather fundamental changes
> >> to YANG cannot be done through extensions because otherwise the value of
> >> YANG as a standard will be lost.
> >>
> >> Lada
> >>
> >> Lyle Bertz <lyleb551144@gmail.com> writes:
> >>
> >> > All,
> >> >
> >> > This is a small submission that allows a single augment statement to
> be
> >> > used to augment multiple schema locations or, at the very least, give
> the
> >> > YANG to language generation tools a hint that the augment is similar
> to
> >> > other augments in the module.
> >> >
> >> > It can be found at
> >> > https://datatracker.ietf.org/doc/draft-bertz-netmod-commonaugment/
> >> >
> >> > It is in direct response to issues that arose writing YANG for the
> IETF
> >> DMM
> >> > FPC specification that can be found at
> >> > https://datatracker.ietf.org/doc/draft-ietf-dmm-fpc-cpdp/
> >> >
> >> > and also in response to issues found wrt yangtools (OpenDaylight) code
> >> > generation of the FPC specification.
> >> >
> >> > Lyle
> >> > _______________________________________________
> >> > netmod mailing list
> >> > netmod@ietf.org
> >> > https://www.ietf.org/mailman/listinfo/netmod
> >>
> >> --
> >> Ladislav Lhotka, CZ.NIC Labs
> >> PGP Key ID: 0xB8F92B08A9F76C67
> >>
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
>