Inline.
On 2020-08-01, 2:47 PM, "Reshad Rahman (rrahman)" <rrah...@cisco.com> wrote:
On 2020-08-01, 1:39 AM, "Juergen Schoenwaelder"
<j.schoenwael...@jacobs-university.de> wrote:
On Sat, Aug 01, 2020 at 02:51:54AM +0000, Reshad Rahman (rrahman) wrote:
> WG,
>
> Following up from the discussions during NETMOD meeting on Thursday.
One of the main open topics is what to do when an import stmt is changed, for
example
>
> 1. Module A (1.0.0) imports module B using “2.0.0 or derived”.
There is no version 3+ for module B so module A uses 2.Y.Z
> 2. A new revision 3.0.0 of module B is created AND there is a
change in module A to import module B using “3.0.0 or derived”.
What does "2.0.0 or derived" mean? Does it mean (i) any module >=
2.0.0 or does it mean (ii) any (module >= 2.0.0 && < 3.0.0)?
It currently means (i). Kent asked about this on slide 12 during the
meeting stating he believes it should be (ii). My response was that this has
been discussed among the authors and there's no agreement among us right now.
I think Rob W has an AI from the WG meeting on this.
This is the email from Rob on this topic.
Regards,
Reshad.
> Authors/contributors have discussed 2 options and right now we don’t
have unanimity:
>
> 1. Option A: depending on the impact on the importing module A,
the import-stmt is deemed BC or NBC. E.g. if the only NBC change in the
imported module is to a type which the importing module does NOT use, that’s a
BC change for the importing module.
> 2. Option B: consider the import-stmt change as a BC change and
resolve this elsewhere e.g. YANG-Packages or YANG-Library.
Whether a change is BC or not always depends on which definitions have
changed, how they have changed, and how these definitions are used. So
the answer very likely must be option 1. Option 2 also seems to push
the problem elsewhere (packages, library) without providing the
details.
I agree.
We have discussed a bit how this would be done but that was right before
the IETF. With YANG-Packages, the package version would be modified accordingly
and a client would need to do schema comparison.
Thanks for the input,
Reshad.
/js
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax: +49 421 200 3103 <https://www.jacobs-university.de/>
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
