Re: [netmod] Follow-up: impact of changing an import statement

["Reshad Rahman (rrahman)" <[e-mail]>]

Inline.

On 2020-08-01, 2:47 PM, "Reshad Rahman (rrahman)" <[e-mail]> wrote:

    On 2020-08-01, 1:39 AM, "Juergen Schoenwaelder" <[e-mail]> 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.
<RR> This is the email from Rob on this topic:
https://mailarchive.ietf.org/arch/msg/netmod/dGQX4jeQWjPT1TqPjk8_yjVJhFM/

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: [phone]         Campus Ring 1 | 28759 Bremen | Germany
        Fax:   [phone]         <https://www.jacobs-university.de/>