> On Jul 16, 2016:7:17 PM, at 7:17 PM, William Lupton
> <wlup...@broadband-forum.org> 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.
It is a good idea to explicitly specify whatever the default behavior
is in 6020bis - or at least on the wiki -
so that we have a well-defined behavior here.
—Tom
>
> 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
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod