On Tue, Jun 30, 2026 at 10:33 AM Andy Bierman <[email protected]> wrote:
> > > On Tue, Jun 30, 2026 at 6:57 AM Joe Clarke (jclarke) <jclarke= > [email protected]> wrote: > >> Hello, netmod. As part of the ongoing YANG module versioning work, >> Michal Vasko created a comprehensive libyang test suite for >> non-backwards-compatible (NBC), backwards-compatible (BC), and editorial >> (ED) changes. I’ve run my pyang against his suite. Unsurprisingly, there >> are several commonalities. >> >> However, there were a few deviations. First, the question. Consider >> this diff: >> >> container cont { >> leaf l1 { >> type string; >> } >> >> - leaf l2 { >> - type uint8; >> - } >> - >> container cont2 { >> leaf-list ll { >> type instance-identifier; >> } >> } >> + >> + leaf l2 { >> + type uint8; >> + } >> + >> + leaf l3 { >> + type int8; >> + } >> } >> >> Michal asserted that changing the order of data nodes is NBC. The base >> pyang’s check-update-from algorithm does not recognize this as NBC. So, my >> version reports this as BC. RFC7950 states: >> >> In statements that have any data definition statements as >> substatements, those data definition substatements MUST NOT be >> reordered. If new data definition statements are added, they can be >> added anywhere in the sequence of existing substatements. >> >> But adding a node anywhere in the sequence would change its order. So, >> which is the expected output, NBC or BC? >> >> Now, the observation. Michal has a test of a YANG module moving from >> YANG 1 to YANG 1.1. He labels that as NBC. While RFC7950 Section 12 >> describes how the two versions interact, I think this assertion is correct >> since an older YANG 1 vendor-bar cannot import a newer YANG 1.1 ietf-foo >> even if there were no other schema changes. This means that all IETF >> modules that have moved from YANG 1 to YANG 1.1 will have a MAJOR YANG >> Semver update in their histories. >> >> > I think you are correct. > > > A YANG version 1 module or submodule MUST NOT import a YANG > version 1.1 module by revision. > > So just changing the yang-version to 1.1 in module 'foo' means any 1.0 > module importing foo by revision-date > is breaking this rule. > > I have no idea why import by revision is MUST NOT, but import without any > revision is MAY. > Seems like the rule is too picky and should be ignored. > > sec 12, para 3 is the confusing part: If a YANG version 1 module A imports module B without revision and module B is updated to YANG version 1.1, a server MAY implement both of these modules (A and B) at the same time. In such cases, a NETCONF server MUST advertise both modules using the rules defined in Section 5.6.4, and SHOULD advertise module A and the latest revision of module B that is specified with YANG version 1 according to the rules defined in [RFC6020]. sec 5.6.5, para 2: A server MUST NOT implement more than one revision of a module. Release 1: The server implements A(1.0.0) and B(1.0.0). (Change yang-version in B to 1.1) Release 2: The server implements A(1.0.0) and B(2.0.0). These are advertised as implemented in the YANG library. The server is also supposed to advertise B(1.0.0) as import-only? This behavior needs clarification > Andy > Andy > > > > Joe >> >> _______________________________________________ >> netmod mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> >
_______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
