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

From: Lyle Bertz <[email-masked]>
Date: Mon, 6 Mar 2017 21:15:25 -0600

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

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 07 Mar 2017 09:43:54 +0100

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 <[email-masked]> writes:

> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

---

From: Lyle Bertz <[email-masked]>
Date: Thu, 9 Mar 2017 10:33:50 -0600

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.

Lyle

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 10 Mar 2017 15:17:53 +0100

> 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

---

From: Andy Bierman <[email-masked]>
Date: Fri, 10 Mar 2017 09:08:45 -0800

> this approach in RFC 8022. Would this work for your use cases?
I agree with Martin that this YANG extension replaces augment-stmt and
therefore will
break tools that conform to RFC 7950.  The extension saves 1 line of YANG
for each
"extra augment" so the benefit for readers and writers seems minimal.

> Lada

Andy

> >> > It is in direct response to issues that arose writing YANG for the
> IETF
> >> DMM

---

From: Lyle Bertz <[email-masked]>
Date: Fri, 10 Mar 2017 11:41:12 -0600

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