On Wed, May 20, 2015 at 10:51:28AM -0700, Andy Bierman wrote: > The solution is not intuitive at all. The implications of cherry-picking > YANG statements from various revisions of a YANG module are > not well understood.
If there are issues that have not been brought up before that we do not understand, please put them on the table. But things need to be concrete, not abstract. > The concept of writing a YANG module so it works with all possible > combinations of all possible back-revisions of imported modules is > not well understood. This is an example of an abstract claim that is difficult to work with. > The question "why can't the module being updated use the latest revision > of an import" is quite legitimate. So is the question "Why can't I determine > what a server implementation is required to support for a given YANG module?" > > The issue title "Better YANG conformance" is misleading because YANG > conformance specificity is actually much worse with this solution. > It's great for vendors who want to interpret for themselves > what conformance means. This is what I wrote: I believe we have reached rough consensus to adopt Y45-04 in order to resolve import ambiguities (aka typedef drift and grouping drift) and we will leave it to YANG extensions (to be worked on in the future) to provide means to define explicit conformance requirements (instead of trying to derive conformance requirements from import relationships alone). I think we concluded from ~1 year of discussions that deriving conformance requirements from import statements does not work. /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
