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
