On Mon, Jul 6, 2015 at 8:04 AM, Juergen Schoenwaelder < j.schoenwael...@jacobs-university.de> wrote:
> 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"? > That's not what the RFC 6020 says (not sure about bis) > > > 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? > If there is just a leaf that says 'default-revision=true' like I proposed, then no problem. If I have to reproduce the entire imports/include->imports tree with filled in revision dates, then this is overkill, too much memory/data, and it is a problem. > /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 netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
