We may have to be more explicit. A decent client talking to a NETCONF/RESTCONF server should pick the latest version of the YANG modules announced in the server's YANG library. A development tool should pick the latest version available to the tool. In case the tool is used to develop code running on the server, then this version should be announced as the latest version on the server.
/js On Tue, Jul 19, 2016 at 11:50:18AM +0200, Balazs Lengyel wrote: > +1 for specifying to use the latest available. > > Balazs > > > On 2016-07-16 19:17, William Lupton wrote: > > All, > > > > RFC 6020bis has no recommendation re use of import/include revision-date > > but makes it clear that if it’s omitted then the revision that will be used > > is undefined (I believe that pyang will parse all the revisions that it > > finds and then use the most recent one). Perhaps that’s a recommendation by > > implication? RFC 6087bis says that the import/include revision-date SHOULD > > be used when groupings from the imported/included module/submodule are used. > > > > In discussing this today with people at the hackathon the general opinion > > was that an omitted revision date means the latest available revision. This > > matches the pyang behaviour and (I gather) matches the behaviour of most > > implementations. > > > > In discussion I also said that I didn’t understand why the only groupings > > are singled out for mention in RFC 6087. Why not types for example? > > > > So should the behaviour when revision-date is omitted be specified? And > > does the recommendation for using revision-date need to be refined? > > > > Thanks, > > William > > > > —— some musings ---- > > > > On the one hand, always referencing a specific revision is good because it > > means that you know exactly what you are getting. But is it always good, > > especially (perhaps) for low-level modules such ietf-yang-types, > > ietf-inet-types and (especially?) iana-if-type? Perhaps it’s better to > > reference low-level files such as these without revision numbers and > > trusting to rigorous backwards compatibility? > > > > RFC 6020bis is (I think) silent on whether a later revision could remove > > import/include revision dates but it’s pretty obvious that you could change > > them to later revisions, so probably this is regarded as “plumbing” that > > doesn’t need to be mentioned? > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > -- > Balazs Lengyel Ericsson Hungary Ltd. > Senior Specialist > Mobile: +36-70-330-7909 email: balazs.leng...@ericsson.com > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- 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
