On Tue, Jul 19, 2016 at 3:13 AM, Juergen Schoenwaelder < j.schoenwael...@jacobs-university.de> wrote:
> 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. > > Our tools use a module search path approach, plus pick latest as the 'supported' version. It is very common (in programming anyway) to control the versions used by controlling the include and library search paths. IMO the IETF should not specify how implementations should work except the normative text in RFCs. So write a new RFC and get IETF consensus on it in order to enforce a rule like this one. > /js > Andy > > 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 >
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
