On Tue, May 19, 2015 at 09:22:29AM -0700, Andy Bierman wrote: > On Tue, May 19, 2015 at 8:55 AM, Juergen Schoenwaelder > <[email protected]> wrote: > > On Tue, May 19, 2015 at 05:55:26AM -0700, Andy Bierman wrote: > >> Hi, > >> > >> RFC 6020, sec. 7.1.5 has this sentence: > >> > >> Multiple revisions of the same module MUST NOT be imported. > >> > >> I expect the new RFC will contain a complete explanation why > >> this MUST NOT is wrong and needs to be changed. > >> I would expect that multiple implementation examples of this > >> approach can be cited, as proof that the new solution already works > >> (before it is standardized). > >> > > > > The attached yang module compiles using pyang 1.3 and if you replace > > yang1:uuid with yang0:uuid, you get an error (as one would expect). > > A tool that parses the syntax is not really the same > as a server implementation. I do not question the ability > to distinguish 2 different strings as 2 different prefixes.
How does the resolution of symbols (typedef and grouping names) at module compile time impact the server implementation? > > Depending on how your code is organized, the Y45-04 behaviour may fall > > out naturally and it takes extra effort to implement the MUST quoted > > above. It may be possible to find a second implementation that > > actually does not implement this MUST. (Our libsmi code has a problem > > with import-by-revision so it is not a candidate unless we implement > > this.) > > > > The reason to change the MUST quoted above can certainly be explained. > > > > So what is the explanation? > Removing a MUST NOT (especially from a 1.1 maintenance release) > is a big deal. I would expect it to be easy to demonstrate that > the original MUST NOT is a bug. > The original MUST NOT makes it expensive to upgrade since it is an all or nothing upgrade mechanism and the only way to ease the pain is that the module author anticipates incremental updates and maintains N different versions of definitions to ease the pain. The NETMOD principle has always been that module readers are first priority, module writers are second priority, and tool implementers are third priority. Yes, Y45-04 is a change for tool implementors (except perhaps tools that failed to implement the MUST NOT) but it is done for a reason. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/> _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
