Hi Rob, all, My concern with "rev:revision-or-derived" is that an NBC change to an imported module can "break" the importing module without any action on the part of the owner of the importing module.
So yes I would want to use "rev:revision-or-compatible-derived", despite the coupling described below. Regards, Reshad. On 2020-09-02, 7:25 AM, "netmod on behalf of Rob Wilton (rwilton)" <[email protected] on behalf of [email protected]> wrote: Hi, My second email on imports ... RFC 7950 supports two variants of import: The default choice is import any revision of a module, but the revision-date substatement may be used to restrict the import to a single specific revision. The "import specific revision" has been found to be less useful than expected and potentially harmful by creating tight coupling between modules and hence draft-ietf-netmod-yang-module-versioning-01 states that the "revision-date" substatement SHOULD NOT be used. Instead, draft-ietf-netmod-yang-module-versioning-01 introduces the extension statement "rev:revision-or-derived AAAA-BB-CC" that specifies an earliest revision that may be imported. Any module revision that included revision AAAA-BB-CC in the module's revision history would satisfy the import, regardless of whether the revision history includes non-backwards-compatible changes. There have also been discussions between the authors whether to also introduce a separate (perhaps rev:revision-or-compatible-derived AAAA-BB-CC) statement that would only allow a revision to be imported if it was backwards-compatible with the selected earliest revision. Specifically, during the import, the module would check the imported modules history to ensure that the "rev:nbc-changes" extension statement isn't present in the history between the latest revision of the module and revision AAAA-BB-CC. Abstractly, you can consider these 4 revision options are gradually more restrictive subsets of revisions that could satisfy an import: (i) default import allows any published revision of an imported module, (ii) "revision-or-derived AAAA-BB-CC" reduces set (i) to only those that include AAAA-BB-CC in their revision history, (iii) "rev:revision-or-compatible-derived AAAA-BB-CC" reduces set (ii) to only include those that are backwards-compatible with AAAA-BB-CC, (iv) revision-date reduces (iii) to the set containing only the specified revision. The question to the WG is whether we should also define "rev:revision-or-compatible-derived" now, or initially just go with "rev:revision-or-derived"? The authors seem to be somewhat split on this issue. My personal concern regarding rev:revision-or-compatible-derived is that it may appear to have desirable properties for module authors but still result in too tight coupling between modules in practice, making it harder to release NBC fixes, although that could presumably be mitigated by having some guideline text warning of the potential risks. This extension could be defined in future if it turns out to be useful. Conversely, some authors believe that this statement would be useful now to help more tightly constrain import dependencies, and arguably defining it now doesn't seem to do any real harm, and means it is available if required. Input from the WG on this issue is welcome and desired. Regards, Rob [As an individual contributor] _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
