Subject: Re: [Netmod-ver-dt] Import-versions proposal

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Thu, 7 Feb 2019 13:35:06 +0000

Hi Balasz,

In 5.5, to specify a  combination of versions, instead of having a pattern why not allow multiple import-version statements or multiple arguments to an import-version statement. I think it'd be clearer than a regexp pattern.

Also, regarding the following paragraph, this can be a backwards incompatible change e.g. when using a grouping from an imported module. IMO the only way we can guarantee that changing an import version is backwards compatible is if the old and new imported versions are backward compatible?
>> Adding, removing or changing the import-versions statements is a compatible change to a module.  

Regards,
Reshad.

On 2019-02-06, 10:58 AM, "Netmod-ver-dt on behalf of Balázs Lengyel" <[email-masked] on behalf of [email-masked]> wrote:

    Hello,
    
    I have an alternative proposal for import-versions. I hope it is easier 
    to understand. See attachment. Lets discuss it!
    
    regards Balazs
    
    -- 
    Balazs Lengyel                       Ericsson Hungary Ltd.
    Senior Specialist
    Mobile: +36-70-330-7909              email: [email-masked]

---

From: Balázs Lengyel <[email-masked]>
Date: Thu, 7 Feb 2019 14:22:48 +0000

Hello fine,

I agree, that's what I want, just my text was not clear enough.

So an import statement MAY have zero, one or more import-version 
substatements. (as described in 5.5)

The regexp which should go into the YANG module definition of the 
extension import-versions actually only allows one of the 4 methods.
So each import-versions includes a simple statement, but you can have 
multiple statements.

----------------------------------------------------------------

Compatibility:

Removing the import-versions statements as long as at least one of the 
original statements remain, is BC

Changing an import-versions statement to prohibit some previously 
allowed versions and NOT to allow any new import-candidates is BC.

adding import-versions statements or changing an import-versions 
statement to allow new import-candidates is risky. It may or may not be 
compatible depending on the compatibility of the imported module, on how 
the import is used etc. It gets to complicated, so lets call it NBC.

regards Balazs

---

From: Balázs Lengyel <[email-masked]>
Date: Wed, 13 Feb 2019 15:31:38 +0000

Hello,

I have updated my proposal for import-versions.  See attachment. It 
includes the relevant part of the YAM too.

Regards Balazs

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Wed, 13 Feb 2019 18:00:18 +0000

Hi,

1)   -- TODO: Do we need to define the ordering(greatest) of semver or is that trivial?
Better be explicit IMO.

2) I still don't understand the rationale for allowing m/M in 5.1 (specific version import). 3.6.1m is really 3.7.1 but that's already taken, so if I import specific version 3.6.1 and I get 3.6.1m or 3.6.1M, that doesn't make sense to me. But if that's the consensus, I'll tag along.

3) The + in 5.2 doesn't accept m/M but the + in 5.4/5.5 does accept m/M, I think this inconsistency will be confusing.

4) Not a fan of 3.6# in 5.3, but I don't have a better proposal. Use C for compatible?

5) 5.4, I might be alone in this but not a fan of this assumption. What makes an M change usable v/s a +1 major version unsable?

Regards,
Reshad.

On 2019-02-13, 10:32 AM, "Netmod-ver-dt on behalf of Balázs Lengyel" <[email-masked] on behalf of [email-masked]> wrote:

    Hello,

    Regards Balazs

---

From: Balázs Lengyel <[email-masked]>
Date: Thu, 14 Feb 2019 09:38:16 +0000

> 1)   -- TODO: Do we need to define the ordering(greatest) of semver or is that trivial?

BALAZS:

X.Y.Zv format version number are considered to be ordered from lowest to 
highest as follows:
When deciding if X1.Y1.Y1v1 or X2.Y2.Z2v2 is higher

if X1 != X2 the version number with the higher X number is higher
If (X1 == X2 AND Y1 != Y2)  the version number with the higher Y number 
is higher
If (X1 == X2 AND Y1 == Y2 AND Z1 != Z2)  the version number with the 
higher Z number is higher
if (X1 == X2 AND Y1 == Y2 AND Z1 == Z2) the version numbers are equal

> 2) I still don't understand the rationale for allowing m/M in 5.1 (specific version import). 3.6.1m is really 3.7.1 but that's already taken, so if I import specific version 3.6.1 and I get 3.6.1m…

BALAZS: That's not how I understand this. If you have 3.6.1 already used 
you MUST NOT declare a new version 3.6.1M. You MUST use 3.6.2M. There 
can not exist two different versions that only differ in the value of 
the modifier. If you need a new modifier, take out the next Z value. So 
once you specified 3.6.1 there is only exactly one version with any 
specific x.y.z. That's why I included in my comment at the end of 
chapter 4.2.

       If two modules versions share the same major and minor and patch
       version (X.Y.z) they MUST have the same content.

Anyway this MUST be stated explicitly somewhere!

> 3) The + in 5.2 doesn't accept m/M but the + in 5.4/5.5 does accept m/M, I think this inconsistency will be confusing.
BALAZS: Think about what the use-case is: We want a specific 
functionality. m or M would change that, so disallowed. 5.4 and 5.5 are 
about cases where we are not worried about compatibility. 5.2 is a case 
where we want to specify the functionality we want.  It is consistent in 
that if you specify x.y you don't want something else.
> 4) Not a fan of 3.6# in 5.3, but I don't have a better proposal. Use C for compatible?
BALAZS: I am OK with C if the group says so, IMHO BC would be even better.
> 5) 5.4, I might be alone in this but not a fan of this assumption. What makes an M change usable v/s a +1 major version unsable?
BALAZS: I could get rid of this, it would simplify the solution. It was 
Rob who wanted it, even stated that it is more important than 5.3 the 
real compatible case.

---

From: Robert Wilton <[email-masked]>
Date: Thu, 14 Feb 2019 10:23:09 +0000

On 14/02/2019 09:38, Balázs Lengyel wrote:
> X.Y.Zv format version number are considered to be ordered from lowest 
> to highest as follows:
> If (X1 == X2 AND Y1 != Y2)  the version number with the higher Y 
> number is higher
>> 2) I still don't understand the rationale for allowing m/M in 5.1 
>> (specific version import). 3.6.1m is really 3.7.1 but that's already 
>> taken, so if I import specific version 3.6.1 and I get 3.6.1m or 
>> 3.6.1M, that doesn't make sense to me. But if that's the consensus, 
>> I'll tag along.
>
> BALAZS: That's not how I understand this. If you have 3.6.1 already 
> used you MUST NOT declare a new version 3.6.1M. You MUST use 3.6.2M. 
> There can not exist two different versions that only differ in the 
> value of the modifier. If you need a new modifier, take out the next Z 
> value. So once you specified 3.6.1 there is only exactly one version 
> with any specific x.y.z. That's why I included in my comment at the 
> end of chapter 4.2.

RW:

I agree.

The X.Y.Z number alone uniquely identifies a version of a YANG module.  
The m|M modifier indicates its semantic relationship to previous 'patch' 
revisions.

Thanks,
Rob

>> 3) The + in 5.2 doesn't accept m/M but the + in 5.4/5.5 does accept 
>> m/M, I think this inconsistency will be confusing.
> functionality. m or M would change that, so disallowed. 5.4 and 5.5 
> are about cases where we are not worried about compatibility. 5.2 is a 
> case where we want to specify the functionality we want. It is 
> consistent in that if you specify x.y you don't want something else.
>> 5) 5.4, I might be alone in this but not a fan of this assumption. 
>> What makes an M change usable v/s a +1 major version unsable?
> BALAZS: I could get rid of this, it would simplify the solution. It 
> was Rob who wanted it, even stated that it is more important than 5.3 
> the real compatible case.
>> Regards,
>> Reshad.
>>
>> On 2019-02-13, 10:32 AM, "Netmod-ver-dt on behalf of Balázs Lengyel" 
>> <[email-masked] on behalf of 
>> [email-masked]> wrote:
>>
>>      Hello,
>> _______________________________________________
>> Netmod-ver-dt mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/netmod-ver-dt

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Thu, 14 Feb 2019 13:52:55 +0000

Hi, 

Inline.

On 2019-02-14, 4:39 AM, "Netmod-ver-dt on behalf of Balázs Lengyel" <[email-masked] on behalf of [email-masked]> wrote:

    BALAZS:

<RR> Ack.

    
    
    Anyway this MUST be stated explicitly somewhere!
<RR> My mistake, you are correct. But my point was that the m and M (especially) are important indicators which seem to be ignored here. if you are importing a specific version and want 3.6.1M, why not import 3.6.1M? Import 3.6.1 should fail IMO if 3.6.1 does not exist but 3.6.1M exists, otherwise it is misleading.
    
<RR> I understand the use-cases, I just wish we could have different symbols for when we want compatibility and when we don't. 

<RR> Ack.

    BALAZS: I could get rid of this, it would simplify the solution. It was 
    Rob who wanted it, even stated that it is more important than 5.3 the 
    real compatible case.
<RR> If that's what the group wants I think we should spell out what M changes are acceptable and which ones aren't. Just saying "will not be drastic" sounds too much like a Brexit election promise to me (sorry Rob).

Regards,
Reshad.

---

From: Balázs Lengyel <[email-masked]>
Date: Thu, 14 Feb 2019 14:14:55 +0000

> <RR> My mistake, you are correct. But my point was that the m and M (especially) are important indicators which seem to be ignored here. if you are importing a specific version and want 3.6.1M, why…
BALAZS: OK. I will require m/M as correct.
>      BALAZS: I am OK with C if the group says so, IMHO BC would be even better.

BALAZS: So how about

          The version-clause argument MUST follow one of the below 
patterns:
          (\d+\.\d+\.\d+([mM])?)|      // specific version
                                // e.g. 3.6.1m
          (\d+\.\d+\.\d+\BC)|    // specific functionality and minimum 
patch level
                                // e.g. 3.6.1BC
          (\d+\.\d+BC)|          // compatible version
                                // e.g. 3.6BC
          (\d+\.\d+\+)|         // assumed compatible version
                                // e.g. 3.6+
          (\d+\+)|              // newer than a specific major version
                                // e.g. 3+
          (\d+\.\d+-\d+\.\d+)   // range of versions
                                // e.g. 3.6-7.8

> <RR> If that's what the group wants I think we should spell out what M changes are acceptable and which ones aren't. Just saying "will not be drastic" sounds too much like a Brexit election promise…
BALAZS: I am not a fan either

---

From: Robert Wilton <[email-masked]>
Date: Thu, 14 Feb 2019 14:32:46 +0000

> <RR> I understand the use-cases, I just wish we could have different symbols for when we want compatibility and when we don't.

My suggest in the meeting last week was that "+" always includes m|M 
versions because by default that is the right thing to do.

> <RR> If that's what the group wants I think we should spell out what M changes are acceptable and which ones aren't. Just saying "will not be drastic" sounds too much like a Brexit election promise…

This would be painting ourselves into a corner.

Import by revision is broken today because it assumes that any revision 
to the module is likely to be incompatible.

But, I think that this is the wrong default assumption to make. I think 
realistically the reverse is going to be true.  Most modules are going 
to be updated in an import compatible way (even if the changes itself is 
classified as an NBC change), and we want the default imports to be 
based around this assumption, with a way of fixing this if the 
assumption doesn't hold.  E.g. if I fix a regex in a module (most likely 
flagged as an NBC change) then I don't want to have to fix all the 
imports to pull in that change.

Hence I think that the key thing that we are trying to express is that 
the import is at least version "blah" because I know that version (or 
versions) define container "bar" that I'm augmenting or referencing.

So, I still think that this current scheme is too complex/confusing.

Thanks,
Rob

---

From: Robert Wilton <[email-masked]>
Date: Thu, 14 Feb 2019 14:50:34 +0000

I'm currently thinking whether the following scheme (which is quite 
different that what has been previously proposed) would be sufficient:

I suggest just 3 rules:
1) Multiple "version" statements can be specified, and the imported 
versions available for selection are the union of the "version" statements.
2) Version statements take one of two forms:
  i) "A.B.C +" matches ANY version greater than "A.B.C".  (E.g. a module 
with version "4.0.0" would match "3.4.0 +" because 4 > 3)
  ii) "A.B.C - X.Y.Z" matches ANY version between the two ranges.

I'm not sure that everyone is going to be keen on this approach :-)

Thanks,
Rob

On 14/02/2019 14:32, Robert Wilton wrote:
>> On 2019-02-14, 4:39 AM, "Netmod-ver-dt on behalf of Balázs Lengyel" 
>>      > Hi,
>>      >
>>      > 1)   -- TODO: Do we need to define the ordering(greatest) of 
>> semver or is that trivial?
>>      > Better be explicit IMO.
>>           BALAZS:
>> number
>>      >
>>      > 2) I still don't understand the rationale for allowing m/M in 
>> 5.1 (specific version import). 3.6.1m is really 3.7.1 but that's 
>> already taken, so if I import specific version 3.6.1 and I get 3.6.1m 
>> or 3.6.1M, that doesn't make sense to me. But if that's the 
>> consensus, I'll tag along.
>> <RR> My mistake, you are correct. But my point was that the m and M 
>> (especially) are important indicators which seem to be ignored here. 
>> if you are importing a specific version and want 3.6.1M, why not 
>> import 3.6.1M? Import 3.6.1 should fail IMO if 3.6.1 does not exist 
>> but 3.6.1M exists, otherwise it is misleading.
>>           >
>>      > 3) The + in 5.2 doesn't accept m/M but the + in 5.4/5.5 does 
>> accept m/M, I think this inconsistency will be confusing.
>> <RR> I understand the use-cases, I just wish we could have different 
>> symbols for when we want compatibility and when we don't.
>
>>      > 4) Not a fan of 3.6# in 5.3, but I don't have a better 
>> proposal. Use C for compatible?
>>      > 5) 5.4, I might be alone in this but not a fan of this 
>> assumption. What makes an M change usable v/s a +1 major version 
>> unsable?
>> <RR> If that's what the group wants I think we should spell out what 
>> M changes are acceptable and which ones aren't. Just saying "will not 
>> be drastic" sounds too much like a Brexit election promise to me 
>> (sorry Rob).
>
> Import by revision is broken today because it assumes that any 
> revision to the module is likely to be incompatible.
>
> But, I think that this is the wrong default assumption to make. I 
> think realistically the reverse is going to be true.  Most modules are 
> going to be updated in an import compatible way (even if the changes 
> itself is classified as an NBC change), and we want the default 
> imports to be based around this assumption, with a way of fixing this 
> if the assumption doesn't hold.  E.g. if I fix a regex in a module 
> (most likely flagged as an NBC change) then I don't want to have to 
> fix all the imports to pull in that change.
>
>>      > Regards,
>>      > Reshad.
>>      >
>>      > On 2019-02-13, 10:32 AM, "Netmod-ver-dt on behalf of Balázs 
>> Lengyel" <[email-masked] on behalf of 
>>      >
>>      >      Hello,
>>      >
>>      >      I have updated my proposal for import-versions. See 
>> attachment. It
>>      >      includes the relevant part of the YAM too.
>>      >
>>      >      Regards Balazs
>>      >
>>      >      --
>>      >      Balazs Lengyel                       Ericsson Hungary Ltd.
>>      >      Senior Specialist
>>      >      Mobile: +36-70-330-7909              email: 
>> [email-masked]
>>      >
>>      >
>>      >
>>      --

---

From: Robert Wilton <[email-masked]>
Date: Mon, 18 Feb 2019 16:59:29 +0000

Hi all,

Here is my proposed text for the simpler import-versions proposal based 
on what we discussed in Thursday's meeting:

5.  Import by Semantic Version

    RFC 7950 allows YANG module 'import' statements to optionally require
    the imported module to have a particular revision date.  In practice,
    importing a module with an exact revision date is overly burdensome
    because it requires the importing module to be updated whenever any
    change to the imported module occurs.  The alternative choice of
    using an import statement without a revision date is also not ideal
    because the importing module may not work with all possible revisions
    of the imported module.

    With semantic versioning, it is desirable for a importing module to
    specify the set of module versions of the imported module that are
    anticipated to be compatible.

    This document specifies a YANG extension for selecting which versions
    of a module may be imported.  It is designed around the assumption
    that most changes to a YANG module do not break importing modules,
    even if the changes themselves are not backwards compatible.

    The ietf-semver module defines the 'version' extension, a
    substatement to the YANG 'import' statement.  An 'import' statement
    may contain 'version' statements or a 'revision-date' statement, but
    not both.  The 'version' statement may be specified multiple times,
    requiring that the imported module version conforms to at least one
    of the 'version' statements.

    The argument to the 'version' statement takes one of three valid
    forms:

    1.  "A.B.Cc" - import the exact module version that matches "A.B.Cc".

    2.  "A.B.Cc+" - import any module version that matches, or is greater
        than, "A.B.Cc".

    3.  "A.B.Cc-X.Y.Zz" - import any module version that matches, or is
        greater than, "A.B.Cc"; and also matches, or is less than,
        "X.Y.Zz".  The word "MAX" can be used for 'Y' or 'Z' to represent
        the numerical value 32,767.

    The rules for comparing module version numbers are as follows:

    1.  Version "R.S.Tt" matches version "A.B.Cc", only if

           R = A, S = B, T = C and t = c.

    2.  Version "R.S.Tt" is greater than version "A.B.Cc", only if

           R = A, S = B and T > C; or

           R = A and S > B; or

           R > A

    3.  Version "R.S.Tt" is less than version "X.Y.Zz", only if

           R = X, S = Y, and T < Z; or

           R = X and S < Y; or

           R < X

5.1.  Module import examples

    Consider an example module "example-module" that is hypothetically
    available in the following versions: 0.1.0, 1.0.0, 1.1.0, 1.1.1m,
    1.1.2M, 1.1.3M, 1.2.0, 2.0.0, 3.0.0.

    The first example selects the specific version 1.1.2M.  A specific
    version import might be used if 1.1.2M contained changes that are
    incompatible with other versions.

    import example-module {
      semver:version 1.1.2M;
    }

    The next example selects the module versions that are match, or are
    greater than, version 1.1.0.  This form may be used if there is a
    dependency on a data node introduced in version 1.1.0.  This form of
    version import is expected to be most prevalent.

    Includes versions: 1.1.0, 1.1.1m, 1.1.2M, 1.1.3M, 1.2.0, 2.0.0 and
    3.0.0.

    import example-module {
      semver:version 1.1.0+;
    }

    The next example selects the module versions that are greater than
    1.1.0, but excluding the 1.1.2M and 1.1.3M versions.  This form may
    be needed if structural non backwards compatible changes are
    introduced in a patch 'M' version.  Generally, it is advisable to
    avoid making such changes.

    Includes versions: 1.0.0, 1.1.0, 1.1.1m, 1.2.0, 2.0.0 and 3.0.0.

    import example-module {
      semver:version 1.0.0-1.1.1m;
      semver:version 1.2.0+;
    }

    The last example selects all module versions with a major version
    number of 1.  This form may be useful if significant non backwards
    compatible changes have been introduced in version 2.0.0 that break
    import backwards compatibility.

    Includes versions: 1.0.0, 1.1.0, 1.1.1m, 1.1.2M, 1.1.3M, 1.2.0.

    import example-module {
      semver:version 1.0.0-1.MAX.MAX;
    }

Thanks,
Rob

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Wed, 20 Feb 2019 21:30:58 +0000

Hi Rob,

I think it’s a very good starting point.

Please see inline.

From: Robert Wilton <[email-masked]>
Date: Monday, February 18, 2019 at 11:59 AM
To: Balázs Lengyel <[email-masked]>, "Reshad Rahman (rrahman)" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Netmod-ver-dt] Import-versions proposal

Hi all,

Here is my proposed text for the simpler import-versions proposal based on what we discussed in Thursday's meeting:

   of the imported module.

<RR> Please consider giving examples of what would break importing modules (e.g. removing a container which is augmented in the importing module) and what wouldn’t. It would clarify this point significantly.

   forms:

       than, "A.B.Cc".

<RR> For 2 and 3 above, if multiple versions match, don’t we need to specify the rules for which version (singular) should be included?

          R = A and S > B; or

          R > A

<RR> Thinking out loud, since t and c are not used, should they even be mentioned? Although I can see why you’d e.g. want to say 1.2.2m instead of 1.2.2 since 1.2.2 doesn’t exist if 1.2.2m does.

          R = X and S < Y; or

          R < X

   import example-module {

     semver:version 1.1.2M;

   }

<RR> s/that are match/that match/?

   3.0.0.

<RR> If all versions above are available, which one is included? Same question for the examples below.

Regards,

Reshad.

   import example-module {

     semver:version 1.1.0+;

   }

   import example-module {

     semver:version 1.2.0+;

   }

   import example-module {

   }

Thanks,
Rob

BALAZS: So how about

         The version-clause argument MUST follow one of the below patterns:
         (\d+\.\d+\.\d+([mM])?)|      // specific version
                               // e.g. 3.6.1m
         (\d+\.\d+\.\d+\BC)|    // specific functionality and minimum patch level
                               // e.g. 3.6.1BC
         (\d+\.\d+BC)|          // compatible version
                               // e.g. 3.6BC
         (\d+\.\d+\+)|         // assumed compatible version
                               // e.g. 3.6+
         (\d+\+)|              // newer than a specific major version
                               // e.g. 3+
         (\d+\.\d+-\d+\.\d+)   // range of versions
                               // e.g. 3.6-7.8

Regards,
Reshad.

     > Regards,
     > Reshad.
     >
     > On 2019-02-13, 10:32 AM, "Netmod-ver-dt on behalf of Balázs Lengyel" <[email-masked] on behalf of [email-masked]><mailto:[email-masked]@ericsson.com> wrote:
     >
     >      Hello,
     >
     >      Mobile: +36-70-330-7909              email: [email-masked]<mailto:[email-masked]>
     >
     >
     >
     --
     Balazs Lengyel                       Ericsson Hungary Ltd.
     Senior Specialist
     Mobile: +36-70-330-7909              email: [email-masked]<mailto:[email-masked]>

[email-masked]<mailto:[email-masked]>

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Thu, 21 Feb 2019 11:53:53 +0000

Hi Reshad,

Please see inline …

[Sorry about the indentation, I’ve get to figure out how, or if it is even possible, to get Outlook 2016 to do indentation is a sane way.]

From: Reshad Rahman (rrahman) <[email-masked]>
Sent: 20 February 2019 21:31
To: Rob Wilton (rwilton) <[email-masked]>; Balázs Lengyel <[email-masked]>; [email-masked]
Subject: Re: [Netmod-ver-dt] Import-versions proposal

Hi Rob,

Please see inline.

From: Robert Wilton <[email-masked]<mailto:[email-masked]>>
Date: Monday, February 18, 2019 at 11:59 AM
To: Balázs Lengyel <[email-masked]<mailto:[email-masked]>>, "Reshad Rahman (rrahman)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Netmod-ver-dt] Import-versions proposal

Hi all,

   of the imported module.

RW: Yes OK.

   forms:

       than, "A.B.Cc".

RW:

I’m actually still quite strongly opposed to adding this text here.  I see the import statement as just stating which versions are compatible, and shouldn’t say anything about which version would be selected.  I think that structures like YANG library, or YANG packages, should specify how to resolve such conflicts, if they are allowed to exist at all.  Otherwise, I think that we risk making this a much bigger change to RFC 7950.

Probably we should check the YANG library behaviour here, and raise this on NETMOD if required.  I’m not adverse to adding an issue to track this.

          R = A and S > B; or

          R > A

RW:

So, my rationale was coming from your statement that if you are matching an exact version then it should be “R.S.Tt”.  I guess, that my logic is that all YANG versions are of the format “R.S.Tt”, where t could be empty, ‘m’ or ‘M’.

          R = X and S < Y; or

          R < X

   import example-module {

     semver:version 1.1.2M;

   }

RW: Yes, will fix.

   3.0.0.

RW: Rather than saying “includes versions”, perhaps  “allows import of versions” would be clearer here?

Thanks,

Rob

Regards,

Reshad.

   import example-module {

     semver:version 1.1.0+;

   }

   import example-module {

     semver:version 1.2.0+;

   }

   import example-module {

   }

Thanks,
Rob

BALAZS: So how about

Regards,
Reshad.

---

From: Balázs Lengyel <[email-masked]>
Date: Thu, 21 Feb 2019 13:36:54 +0000

See below, Balazs

On 2019. 02. 21. 12:53, Rob Wilton
(rwilton) wrote:

Hi Reshad,

Please see inline …

[Sorry
about the indentation, I’ve get to figure out how, or if it
is even possible, to get Outlook 2016 to do indentation is a
sane way.]

From: Reshad Rahman (rrahman)
<[email-masked]>

To: Rob Wilton (rwilton)
<[email-masked]>; Balázs Lengyel
<[email-masked]>;
[email-masked]

Subject: Re: [Netmod-ver-dt] Import-versions
proposal

Hi
Rob,

I think it’s a very
good starting point.

Please see inline.

From:
Robert Wilton <[email-masked]>

To: Balázs Lengyel <[email-masked]>,
"Reshad Rahman (rrahman)" <[email-masked]>,
"[email-masked]" <[email-masked]>

Subject: Re: [Netmod-ver-dt] Import-versions
proposal

Hi all,

Here is my proposed text for the simpler
import-versions proposal based on what we discussed in
Thursday's meeting:

of the imported module.

RW: Yes OK.

forms:

than, "A.B.Cc".

RW:

BALAZS: Lets say both modA1 and modA2 are
eligible for import. modA2 has a grouping where a mandatory config
leaf was removed. How do I know if I must or must not configure
the leaf. This is today not solved by YANG. YANG should specifiy
the available leafs! IMHO this is a bug in YANG. We should specify
that anyone using semver:version MUST use modA1 (or modA2). As
long as this is only valid for cases where a semver extension is
used I do not see why this would change 7950.

yang library today does not provide any information about which
version is imported.

BALAZS: Add a note, that for a specific A.B.C
version only one of an unmodified or 'm' or 'M' version MAY exist.
So comparing t =c is unneeded, it is really only useful to find
error cases.

R = A and S > B; or

R > A

RW:

R = X and S < Y; or

R < X

import example-module {

semver:version 1.1.2M;

}

RW: Yes, will fix.

3.0.0.

Thanks,

Rob

Regards,

Reshad.

import example-module {

semver:version 1.1.0+;

}

import example-module {

semver:version 1.2.0+;

}

import example-module {

}

Thanks,

Rob

On 14/02/2019 14:14,
Balázs Lengyel wrote:

On 2019. 02. 14. 14:52, Reshad Rahman (rrahman) wrote:

> 2) I
still don't understand the rationale for allowing m/M
in 5.1 (specific version import). 3.6.1m is really
3.7.1 but that's already taken, so if I import
specific version 3.6.1 and I get 3.6.1m or 3.6.1M,
that doesn't make sense to me. But if that's the
consensus, I'll tag along.

BALAZS: That's not how I understand this. If
you have 3.6.1 already used

you MUST NOT declare a new version 3.6.1M. You
MUST use 3.6.2M. There

can not exist two different versions that only
differ in the value of

the modifier. If you need a new modifier, take
out the next Z value. So

once you specified 3.6.1 there is only exactly
one version with any

specific x.y.z. That's why I included in my
comment at the end of

chapter 4.2.

If two modules versions share the
same major and minor and patch

version (X.Y.z) they MUST have the same
content.

Anyway this MUST be stated explicitly
somewhere!

<RR> My mistake, you are correct. But my point
was that the m and M (especially) are important
indicators which seem to be ignored here. if you are
importing a specific version and want 3.6.1M, why not
import 3.6.1M? Import 3.6.1 should fail IMO if 3.6.1
does not exist but 3.6.1M exists, otherwise it is
misleading.

> 3) The +
in 5.2 doesn't accept m/M but the + in 5.4/5.5 does
accept m/M, I think this inconsistency will be
confusing.

BALAZS: Think about what the use-case is: We want
a specific

functionality. m or M would change that, so
disallowed. 5.4 and 5.5 are

about cases where we are not worried about
compatibility. 5.2 is a case

where we want to specify the functionality we
want.  It is consistent in

that if you specify x.y you don't want something
else.

<RR> I understand the use-cases, I just wish we
could have different symbols for when we want
compatibility and when we don't.

> 4) Not a fan of 3.6# in 5.3, but I don't
have a better proposal. Use C for compatible?

BALAZS: I am OK with C if the group says so, IMHO
BC would be even better.

<RR> Ack.

BALAZS: So how about

The version-clause argument MUST follow one of
the below patterns:

(\d+\.\d+\.\d+([mM])?)|      // specific
version

// e.g. 3.6.1m

(\d+\.\d+\.\d+\BC)|    // specific
functionality and minimum patch level

// e.g. 3.6.1BC

// e.g. 3.6BC

(\d+\.\d+\+)|         // assumed compatible
version

// e.g. 3.6+

(\d+\+)|              // newer than a specific
major version

// e.g. 3+

// e.g. 3.6-7.8

> 5) 5.4,
I might be alone in this but not a fan of this
assumption. What makes an M change usable v/s a +1
major version unsable?

BALAZS: I could get rid of this, it would
simplify the solution. It was

Rob who wanted it, even stated that it is more
important than 5.3 the

real compatible case.

<RR> If that's what the group wants I think we
should spell out what M changes are acceptable and
which ones aren't. Just saying "will not be drastic"
sounds too much like a Brexit election promise to me
(sorry Rob).

Regards,

Reshad.

> On 2019-02-13, 10:32 AM, "Netmod-ver-dt on
behalf of Balázs Lengyel"
<[email-masked]
on behalf of [email-masked]> wrote:

--

Balazs Lengyel                       Ericsson
Hungary Ltd.

Senior Specialist

[email-masked]

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Thu, 21 Feb 2019 14:17:18 +0000

Please see inline.

From: Netmod-ver-dt <[email-masked]> on behalf of Balázs Lengyel <[email-masked]>
Date: Thursday, February 21, 2019 at 8:37 AM
To: "Rob Wilton (rwilton)" <[email-masked]>, "Reshad Rahman (rrahman)" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Netmod-ver-dt] Import-versions proposal

See below, Balazs
On 2019. 02. 21. 12:53, Rob Wilton (rwilton) wrote:
Hi Reshad,

Please see inline …

From: Reshad Rahman (rrahman) <[email-masked]><mailto:[email-masked]>
Sent: 20 February 2019 21:31
To: Rob Wilton (rwilton) <[email-masked]><mailto:[email-masked]>; Balázs Lengyel <[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Netmod-ver-dt] Import-versions proposal

Hi Rob,

Please see inline.

Hi all,

   of the imported module.

RW: Yes OK.

   forms:

       than, "A.B.Cc".

RW:

Probably we should check the YANG library behaviour here, and raise this on NETMOD if required.  I’m not adverse to adding an issue to track this.
BALAZS: Lets say both modA1 and modA2 are eligible for import. modA2 has a grouping where a mandatory config leaf was removed. How do I know if I must or must not configure the leaf. This is today not solved by YANG. YANG should specifiy the available leafs! IMHO this is a bug in YANG. We should specify that anyone using semver:version MUST use modA1 (or modA2). As long as this is only valid for cases where a semver extension is used I do not see why this would change 7950.
yang library today does not provide any information about which version is imported.

<RR2> I took a look at RFC7950<https://tools.ietf.org/html/rfc7950#section-5.1.1> and it says “If a module is not imported with a specific revision, it is undefined which revision is used.”. That’s ok there since all revisions are backwards compatible. But with semver that’s not the case, so we need something to define which version is used otherwise it’s way too loose. I don’t understand how YANG library could help.

Regards,

Reshad.

<snip>

---

From: Balázs Lengyel <[email-masked]>
Date: Thu, 21 Feb 2019 14:23:50 +0000

On 2019. 02. 21. 15:17, Reshad Rahman
(rrahman) wrote:

Please see inline.

From: Netmod-ver-dt
<[email-masked]> on behalf of Balázs
Lengyel <[email-masked]>

To: "Rob Wilton (rwilton)"
<[email-masked]>, "Reshad Rahman (rrahman)"
<[email-masked]>, "[email-masked]"
<[email-masked]>

See below, Balazs

Hi Reshad,

Please see inline …

[Sorry about
the indentation, I’ve get to figure out how, or if it is
even possible, to get Outlook 2016 to do indentation is a
sane way.]

To: Rob Wilton (rwilton) <[email-masked]>;
Balázs Lengyel
<[email-masked]>;

[email-masked]

Hi Rob,

I think it’s a very
good starting point.

Please see inline.

From: Robert Wilton
<[email-masked]>

To: Balázs Lengyel <[email-masked]>, "Reshad
Rahman (rrahman)" <[email-masked]>, "[email-masked]" <[email-masked]>

Hi all,

Here is my proposed text for the simpler import-versions
proposal based on what we discussed in Thursday's meeting:

of the imported module.

RW: Yes OK.

forms:

than, "A.B.Cc".

RW:

BALAZS: Lets
say both modA1 and modA2 are eligible for import. modA2 has
a grouping where a mandatory config leaf was removed. How do
I know if I must or must not configure the leaf. This is
today not solved by YANG. YANG should specifiy the available
leafs! IMHO this is a bug in YANG. We should specify that
anyone using semver:version MUST use modA1 (or modA2). As
long as this is only valid for cases where a semver
extension is used I do not see why this would change 7950.

yang library today does not provide any information about
which version is imported.

<RR2> I took a look at RFC7950 and it says “If a module is not imported with a specific revision, it is undefined which revision is used.”. That’s ok there since all revisions are backwards compatible. But with semver that’s not the case, so we need something to define which version is used otherwise it’s way too loose. I don’t understand how YANG library could help.

BALAZS2: This sentence does not say that a system or other
documents are not allowed to specify which

module will be used. It only states that here and now in RFC7950
we do not tell you.

So we are free to specify it, and we SHOULD.

Regards,

Reshad.

<snip>

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Thu, 21 Feb 2019 14:25:27 +0000

Hi Balazs,

Please see inline …

From: Netmod-ver-dt <[email-masked]> On Behalf Of Balázs Lengyel
Sent: 21 February 2019 13:37
To: Rob Wilton (rwilton) <[email-masked]>; Reshad Rahman (rrahman) <[email-masked]>; [email-masked]
Subject: Re: [Netmod-ver-dt] Import-versions proposal

See below, Balazs

Please see inline …

Hi Rob,

Please see inline.

Hi all,

   of the imported module.

RW: Yes OK.

   forms:

       than, "A.B.Cc".

RW:

Probably we should check the YANG library behaviour here, and raise this on NETMOD if required.  I’m not adverse to adding an issue to track this.
BALAZS: Lets say both modA1 and modA2 are eligible for import. modA2 has a grouping where a mandatory config leaf was removed. How do I know if I must or must not configure the leaf. This is today not solved by YANG.
[RW]
So I think that YANG library should have specified an exact schema.  YANG packages, if that work progresses, will specify an exact schema.  I.e. there should never be a choice as to why file to import.  It should always be explicit.

So, I agree with you that this is an issue, but I don’t think that this is the right place to fix it.  A module import is only in the context of a module.  But the issue that you are raising is in the context of a YANG schema (i.e. a collective set of YANG modules that work together).

YANG should specify the available leafs! IMHO this is a bug in YANG. We should specify that anyone using semver:version MUST use modA1 (or modA2). As long as this is only valid for cases where a semver extension is used I do not see why this would change 7950.
yang library today does not provide any information about which version is imported.
[RW]
Because RFC 7950 today says that the compiler can choose which version to use.

          R = A, S = B, T = C and t = c.
BALAZS: Add a note, that for a specific A.B.C version only one of an unmodified or 'm' or 'M' version MAY exist. So comparing t =c is unneeded, it is really only useful to find error cases.

[RW]
Yes, I agree that we should specify that there can only be a single letter, but it should be added where YANG semver is defined rather than here (if it isn’t already specified).

If the range is 1.2.3M – 1.6.7M, then I think that having the ‘M’ characters is important and makes it clear.  Should a range of “1.2.3” match “1.2.3M”?  What if “1.2.3M” was specified and the actual  version is “1.2.3m”?

Thanks,
Rob

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Thu, 21 Feb 2019 14:44:34 +0000

Hi Reshad,

Please see inline …

From: Reshad Rahman (rrahman) <[email-masked]>
Sent: 21 February 2019 14:17
To: Balázs Lengyel <[email-masked]>; Rob Wilton (rwilton) <[email-masked]>; [email-masked]
Subject: Re: [Netmod-ver-dt] Import-versions proposal

Please see inline.

From: Netmod-ver-dt <[email-masked]<mailto:[email-masked]>> on behalf of Balázs Lengyel <[email-masked]<mailto:[email-masked]>>
Date: Thursday, February 21, 2019 at 8:37 AM
To: "Rob Wilton (rwilton)" <[email-masked]<mailto:[email-masked]>>, "Reshad Rahman (rrahman)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Netmod-ver-dt] Import-versions proposal

See below, Balazs

Please see inline …

Hi Rob,

Please see inline.

Hi all,

   of the imported module.

RW: Yes OK.

   forms:

       than, "A.B.Cc".

RW:

<RR2> I took a look at RFC7950<https://tools.ietf.org/html/rfc7950#section-5.1.1> and it says “If a module is not imported with a specific revision, it is undefined which revision is used.”. That’s ok there since all revisions are backwards compatible.

[RW]

No, it can still break.  If the second revision of a module introduces a new type that is used by the importing module then it can still fail to compile.  Semver doesn’t introduce a new breakage that isn’t already there, although I do agree that it provides more ways that it could be broken. ☺

 But with semver that’s not the case, so we need something to define which version is used otherwise it’s way too loose.

[RW]

But stating that you choose the latest available version is looser and not actual helpful!

That means that if my server happens to have a later version of that module available then I can use it.  But that doesn’t help.  Just because the client can see BGP module version 1.5.1, doesn’t mean that the server that implements version 1.0.0 is going to understand any of the extra config items added between the two revisions.  So regardless of which module version the server can see, when interacting with the server, for configuration at least, it better restrict itself to only the config that is backwards compatible with 1.0.0.  So, if I was building the client, I would not always want to choose the latest available version.

YANG library should define a precise schema.  I.e. a client should be able to know exactly what schema a server is using, or if it doesn’t then that is a bug in YANG library, and I think that should be fixed in YANG library to specify how to resolve the ambiguous case.  Specifying in YANG library that it must choose the latest revision, or greatest version Is fine.  Perhaps if we add a section to this document that augments YANG library with a YANG semantic version for each module then we could add text to that section saying that it resolves to the latest version.  I would have no issues with that because the import resolution is being scoped to just the set of modules defined in YANG library.

YANG packages can just be designed to avoid this problem, by always defining a precise YANG schema.

At the end of the day, I think that import-by-version is about specifying what the set of compatible versions are.  It shouldn’t be about selecting a particular version.  I completely agree that problem should be solved for YANG library, just not here.

Thanks,
Rob

 I don’t understand how YANG library could help.

Regards,

Reshad.

<snip>

---

From: Balázs Lengyel <[email-masked]>
Date: Thu, 21 Feb 2019 14:47:39 +0000

See below for BALAZS3

On 2019. 02. 21. 15:25, Rob Wilton
(rwilton) wrote:

Hi Balazs,

Please see
inline …

From: Netmod-ver-dt
<[email-masked]>
On Behalf Of Balázs Lengyel

To: Rob Wilton (rwilton)
<[email-masked]>; Reshad Rahman (rrahman)
<[email-masked]>; [email-masked]

See
below, Balazs

On 2019. 02.
21. 12:53, Rob Wilton (rwilton) wrote:

Hi
Reshad,

Please see inline …

[Sorry
about the indentation, I’ve get to figure out how, or if
it is even possible, to get Outlook 2016 to do indentation
is a sane way.]

From:
Reshad Rahman (rrahman)
<[email-masked]>

To: Rob Wilton (rwilton) <[email-masked]>; Balázs Lengyel
<[email-masked]>;
[email-masked]

Hi Rob,

Please see inline.

From:
Robert
Wilton <[email-masked]>

Hi all,

Here is my
proposed text for the simpler import-versions proposal
based on what we discussed in Thursday's meeting:

of the imported module.

RW: Yes OK.

forms:

than, "A.B.Cc".

RW:

BALAZS: Lets say both modA1
and modA2 are eligible for import. modA2 has a grouping
where a mandatory config leaf was removed. How do I know if
I must or must not configure the leaf. This is today not
solved by YANG.

[RW]

So I
think that YANG library should have specified an exact
schema.  YANG packages, if that work progresses, will
specify an exact schema.  I.e. there should never be a
choice as to why file to import.  It should always be
explicit.

So, I
agree with you that this is an issue, but I don’t think
that this is the right place to fix it.  A module import
is only in the context of a module.  But the issue that
you are raising is in the context of a YANG schema (i.e.
a collective set of YANG modules that work together).

YANG should specify the
available leafs! IMHO this is a bug in YANG. We should
specify that anyone using semver:version MUST use modA1 (or
modA2). As long as this is only valid for cases where a
semver extension is used I do not see why this would change
7950.

[RW]

Because RFC
7950 today says that the compiler can choose which version
to use.

BALAZS3: Don't agree. I don't see the world compiler  anywhere.
This is not the standard, it is your interpretation.

Not specified, only means it is not specified: It does not even
mean that all versions must be acceptable.

BALAZS: Add a note, that
for a specific A.B.C version only one of an unmodified or
'm' or 'M' version MAY exist. So comparing t =c is unneeded,
it is really only useful to find error cases.

[RW]

Yes, I agree
that we should specify that there can only be a single
letter, but it should be added where YANG semver is
defined rather than here (if it isn’t already specified).

If the range
is 1.2.3M – 1.6.7M, then I think that having the ‘M’
characters is important and makes it clear.  Should a
range of “1.2.3” match “1.2.3M”?  What if “1.2.3M” was
specified and the actual  version is “1.2.3m”?

BALAZS3: I would still remove the t=c comparision. I am happy
with the m/M in the version statements, but I would remove the
comparision. If the statement is 1.0.0-1.3.1 and the real version
number in the module is 1.3.1M is that eligible? If you keep the
t=c you never sad if that is equalt, greater or smaller: whther it
is eligible.

Thanks,

Rob