Andy Bierman <[email protected]> writes: > Martin, > > I will remove my objection to Y45-04 if you write a section > in the draft about why multiple imports of the same module > is needed, plus examples that show appropriate use > of this new feature.
The use case is clear: With the IETF process in place, one cannot expect fine granularity of module revisions. That is, a new revision may typically include several changes, and authors of modules that import such a module may want to use just a subset of the changes and stick to the old revision for the rest. There is some evidence it was you who came up with this use case when you advocated that every change in a grouping/typedef be accompanied with a name change of the grouping/typedef, and both the old and new version be kept. Lada > > I also think examples are needed that highlight how data nodes and > augments ignore the revision date (multiple module augments > example), while still using groupings and typedefs that do not > ignore the revision dates. > > IETF modules should not need to cherry-pick from multiple > revisions. That means the WG is deciding to stay "down-rev" > on something, and that should not be approved without good reason. > > > Andy > > > On Thu, May 21, 2015 at 1:36 PM, Martin Bjorklund <[email protected]> wrote: >> Andy, >> >> I don't think the implementation burden on the server is that heavy. >> A YANG 1.0 compliant server today supports: >> >> leaf a in module A of type foo from foo@2001-01-01 >> leaf b in module B of type foo from foo@2002-02-02 >> >> I.e., it supports different leafs in the combined data model referring >> to different versions of the same type. >> >> A YANG 1.1 server would also support >> >> leaf a in module A of type foo from foo@2001-01-01 >> leaf b in module A of type foo from foo@2002-02-02 >> >> Of course, how much a specific implementation is affected will vary, >> but I don't think the concepts are *that* different. >> >> >> /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
