On Tue, May 19, 2015 at 11:24 PM, Juergen Schoenwaelder <[email protected]> wrote: > 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? >
Implementors who followed the MUST NOT rule may have optimizations wrt/ symbol resolution. These will be invalid once the MUST NOT is removed. It is fairly trivial to parse YANG compared to implementing NETCONF/YANG it in a server. >> > 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. > The original MUST NOT depends on the update rules in sec. 10. IMO following lots of dependencies makes YANG modules harder to read, so I don't agree Y45-04 is good for readers. > /js Andy > > -- > 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
