On Wed, Jun 24, 2026 at 8:39 AM Ladislav Lhotka <[email protected]> wrote: > > Per Andersson <[email protected]> writes: > > > On Tue, Jun 23, 2026 at 8:49 AM Vojtech Vilimek > > <[email protected]> wrote: > >> > >> Hi netmod, > >> > >> I found an inconsistency in the RFC 7950: YANG 1.1, see below. > >> > >> Section 7.1.5 The "import" statement, 3rd paragraph: > >> When the optional "revision-date" substatement is present, any > >> typedef, grouping, extension, feature, and identity referenced by > >> definitions in the local module are taken from the specified revision > >> of the imported module. It is an error if the specified revision of > >> the imported module does not exist. If no "revision-date" > >> substatement is present, it is undefined from which revision of the > >> module they are taken. > >> > >> Section 5.6.5 Implemening a Module, 5th paragraph: > >> If a server lists a module C in the "/modules-state/module" list from > >> "ietf-yang-library" and there are other modules Ms listed that import > >> C without specifying the revision date of module C, the server MUST > >> use the definitions from the most recent revision of C listed for > >> modules Ms. > >> > >> > >> The revision could not be undefined and the most recent at the same > >> time. The MUST in overview section make things easier. I want to file > >> an erratum but before that I am open for discussion. > > > > Having a clear rule is desireable, and it already exists as you state. > > > > I would expect to take the statements from the latest available YANG > > module on the system if not stating which version to import explicitly. > > An alternative is to leave imported revisions unresolved at the YANG level > and modify YANG library so that the actual revisions imported to each module > can be specified there. This makes more sense to me as different > implementations may have different preferences wrt revisions used.
Perhaps this is solved by using YANG Packages? In any case, it seems to be a bigger effort that the suggested Errata. Currently the presented sections contradict each other, and undefined behavior is never desired. -- Per > Lada > > > > > > > -- > > Per > > > > _______________________________________________ > > netmod mailing list -- [email protected] > > To unsubscribe send an email to [email protected] > > -- > Ladislav Lhotka <[email protected]> > PGP Key ID: 0xB8F92B08A9F76C67 _______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
