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 <[email protected]> wrote: > Lyle Bertz <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 > >> > [email protected] > >> > 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 >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
