On Mon, Jul 06, 2015 at 07:59:29AM -0700, Andy Bierman wrote: > On Mon, Jul 6, 2015 at 12:45 AM, Juergen Schoenwaelder < > j.schoenwael...@jacobs-university.de> wrote: > > > On Mon, Jul 06, 2015 at 12:39:21AM -0700, Andy Bierman wrote: > > > On Sun, Jul 5, 2015 at 11:57 PM, Juergen Schoenwaelder < > > > j.schoenwael...@jacobs-university.de> wrote: > > > > > > > On Fri, Jul 03, 2015 at 02:12:30PM -0700, Andy Bierman wrote: > > > > > > > > > I propose this text in the conformance leaf: > > > > > > > > > > For import statements that do not specify a revision > > > > > date, the most recent revision in the library SHOULD > > > > > be used by the server."; > > > > > > > > > > It seems like a lot of data will be needed to model the dependency > > tree > > > > > for every import-stmt in every module. Don't forget every > > include-stmt > > > > > as well, since submodules can import with or without revision. > > > > > > > > > > IMO "SHOULD use latest" is good enough. > > > > > Perhaps modules should use import-by-revision when they > > > > > are published as RFCs (as Lada suggested). > > > > > > > > This sounds like "lets pretend the world is simple so we have less > > > > work to do". > > > > > > > > > > > No -- YANG currently says if there is no revision date > > > then the implementation can use any revision, > > > > Exactly - any revision. > > > > > This is also good enough. Prove that this is causing interoperability > > > problems. I don't think it is -- especially not such that the server > > > has to model all its imports so the client can retrieve the data. > > > > Did I say all imports? No. I think a server should announce which > > revision was picked to resolve imports without a revision. > > > > > But it could be any revision. > > A imports B.1 imports C > D imports B.4 imports C > E imports F imports G imports C
Can we agree on "all imports without a revision fixed in the data model"? > C can be imported many times without revision. Yes. > Any import in the chain can be with out without a revision date. Yes. > IMO "SHOULD use latest revision of C advertised" is best because > the latest revision is generally the most correct and supports the > most product features. But I thought the goal was to know precisely what a device implements, not what it _could_ implement. > If the import of C really depends on specific revisions of > some typedefs, groupings, etc. then import by revision MUST > be used everywhere in the dependency chain (C and all its imports). > > If no revision-stmt is present the server can pick whatever revision > it wants. If this is a problem, then fix this problem, don't add > some complex monitoring requirements for servers to implement > and clients to process. Let's make import-by-revision mandatory > if import-without-revision is a such a problem. If the data model leaves it open, then indeed the implementor can choose. What is wrong with reporting what was chosen? /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 netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
