Subject: [Netmod-ver-dt] Do submodules have a semantic version associated with them?

From: Robert Wilton <[email-masked]>
Date: Mon, 26 Nov 2018 18:06:33 +0000

Do submodules have a semantic version associated with them?  It seems 
that it would be useful information.

If they are allowed a semantic version, then do we force that they have 
exactly the same version as the module including them? This would seem 
like a good idea to keep everything together.

Thanks,
Rob

---

From: "Sterne, Jason (Nokia - CA/Ottawa)" <[email-masked]>
Date: Mon, 26 Nov 2018 19:38:09 +0000

Yes - I think we should keep versions & revisions for submodules.

I'm don't think they should have the same version as the module. If a data model is organized into submodules then it is useful to know that certain submodules changed and others didn’t.

Jason

> -----Original Message-----
> From: Netmod-ver-dt <[email-masked]> On Behalf Of
> Robert Wilton
> Sent: Monday, November 26, 2018 10:07 AM
> To: [email-masked]
> Subject: [Netmod-ver-dt] Do submodules have a semantic version associated
> with them?
> 
> _______________________________________________
> Netmod-ver-dt mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod-ver-dt

---

From: Joe Clarke <[email-masked]>
Date: Mon, 26 Nov 2018 14:55:51 -0500

> like a good idea to keep everything together.

While they should retain their revisions, I think they should probably
share the semver of the main module.  They should not have their own
version.

The YANG version is for the whole module+submodules taken together.

Joe

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Mon, 26 Nov 2018 20:18:13 +0000

I agree with Joe, I don't see what use we'd make of submodule version. 

Jason, you mentioned that it'd allow us to know that certain submodules changed, but revisions provide that info. So you think it'd be useful to know if NBC change was made in a specific submodule?

Regards,
Reshad.

On 2018-11-26, 2:56 PM, "Netmod-ver-dt on behalf of Joe Clarke (jclarke)" <[email-masked] on behalf of [email-masked]> wrote:

    
    
    Joe

---

From: Ebben Aries <[email-masked]>
Date: Mon, 26 Nov 2018 13:18:20 -0700

> The YANG version is for the whole module+submodules taken together.

+1 - This came up a few yr back within OpenConfig and if you look at how
the models are grouped w/ heavy use of submodules per domain, you'll see
precisely this approach.  They are treated as a model grouping and the
semver increments across all simultaneously.

Though it doesn't appear any such wording was ever published on
http://openconfig.net/docs/semver/

/ebben

---

From: "Sterne, Jason (Nokia - CA/Ottawa)" <[email-masked]>
Date: Mon, 26 Nov 2018 23:20:09 +0000

Hi guys,

OC acts with a lot fewer constraints than vendors.

I don't agree with enforcing that submodules have the same SemVer as the main module. There is no such rule for YANG version today.

When a data model is organized into submodules that allows someone to indicate what parts of the overall model changed (BC or NBC or not at all) with more granularity than just the entire superset module.

We *could* consider that the main module must indicate a BC change if any submodule has a BC change, and an NBC change if any submodule has an NBC change though. Although not sure that is necessary.

Jason

> Ebben Aries
> Sent: Monday, November 26, 2018 12:18 PM
> To: Joe Clarke <[email-masked]>
> Cc: Robert Wilton <[email-masked]>; [email-masked]
> Subject: Re: [Netmod-ver-dt] Do submodules have a semantic version
> associated with them?
>

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Tue, 27 Nov 2018 01:12:54 +0000

We *could* consider that the main module must indicate a BC change if any submodule has a BC change, and an NBC change if any submodule has an NBC change though. Although not sure that is necessary.
<RR> Pretty sure it's necessary. Otherwise if a submodule has NBC change and the module version hasn't changed, we need to look at versions of all submodules to figure out whether NBC change took place in the module? A submodule is just a way to split a module in smaller pieces, and can't exist on its own.

On 2018-11-26, 6:20 PM, "Netmod-ver-dt on behalf of Sterne, Jason (Nokia - CA/Ottawa)" <[email-masked] on behalf of [email-masked]> wrote:

    Hi guys,

    

    Jason

---

From: Balázs Lengyel <[email-masked]>
Date: Tue, 27 Nov 2018 09:04:45 +0000

Hello,

The change of the submodule is signaled by the change of revision
date. Signalling whether a specific submodule changed in a BC-NBC
manner is problematic, IMHO should not be done. Please consider
https://tools.ietf.org/html/rfc7950#section-11

A module may be split into a set of submodules or a submodule may
be removed, provided the definitions in the module do not change
in any way other than those allowed here.

This would allow a submodule to change in NBC manner while the
module change is BC. That would just create confusion. It also
mean that an NMS MUST NOT check BC/NBC on a submodule, as it might
or might not mean anything for the full module.

regards Balazs

On 2018. 11. 27. 0:20, Sterne, Jason
(Nokia - CA/Ottawa) wrote:

Hi guys,

Jason

-----Original Message-----

/ebben

--
Balazs Lengyel Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909 email: [email-masked]

---

From: Robert Wilton <[email-masked]>
Date: Tue, 27 Nov 2018 10:00:19 +0000

I was coming from this from a slightly different perspective (actually 
thinking about YANG packages/versioning and also looking closely at YANG 
library), and hence somewhat considering this from the perspective of 
conformance.

RFC 7950 section 11 rules state:

    o  A module may be split into a set of submodules or a submodule may
       be removed, provided the definitions in the module do not change
       in any way other than those allowed here.

So, really sub-modules are only a file layout organization tool, and the 
structure between modules and submodules is allowed to change as a 
backwards compatible change.  I.e. if you were to absorb all the 
submodules into a module, from a YANG semver perspective I think that 
this would be regarded as patch level change, since the meaning of the 
module has not changed in any way.  It is also worth noting that 
submodules is the one place where a revision date makes sense, e.g., 
arguably all module includes of sub-modules should specify a revision date.

So, I think that this question can probably be split into two:

1) If we agree that the primary YANG semver applies at the module level, 
then does it make sense to require that the module level semver also be 
specified in all sub-modules?  On one hand this is useful information to 
have when reading a sub-module, on the other there is a slight overhead 
to having to update every sub-module whenever the module version changes.

2) Should we have a separate sub-module specific semver to track changes 
within the sub-module source file?  My intuitive preference here is no, 
that this would likely just end up causing confusion.

Thanks,
Rob

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 27 Nov 2018 11:32:34 +0100

On Tue, Nov 27, 2018 at 10:00:19AM +0000, Robert Wilton wrote:
> have when reading a sub-module, on the other there is a slight overhead to
> having to update every sub-module whenever the module version changes.
> 
> within the sub-module source file?  My intuitive preference here is no, that
> this would likely just end up causing confusion.
>

The relationship of module version numbers and submodule version
numbers will be non-trivial and from a client's perspective, what
really matters is the module version number.

There are people who proposed to remove submodules in a future version
of YANG since the complexity they add to YANG seems to be in mismatch
with the benefits they provide.

Perhaps we are better off by limiting the scope of this work to
versioning of modules and leaving versioning of submodules explicitly
out of the picture.

/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/>

---

From: Robert Wilton <[email-masked]>
Date: Tue, 27 Nov 2018 10:52:46 +0000

> really matters is the module version number.

I agree.

> with the benefits they provide.

Yes, I had previously proposed this.  But pragmatically, I'm now of the 
opinion that we shouldn't do this because there are two many people 
using them that will likely object, and hence is probably not a battle 
worth fighting.

> versioning of modules and leaving versioning of submodules explicitly

I'm OK with this, as long as we define that the module level version 
number effectively covers changes to the module file and all included 
sub-modules.  I think that any text that considers import by version, 
should probably recommend that sub-modules are included using 
"include-with-revision-date".  I.e. having a tight binding between a 
module and any component sub-modules is sensible.

Thanks,
Rob

---

From: Joe Clarke <[email-masked]>
Date: Tue, 27 Nov 2018 08:28:52 -0500

> <RR> Pretty sure it's necessary. Otherwise if a submodule has NBC change and the module version hasn't changed, we need to look at versions of all submodules to figure out whether NBC change took p…

My thinking is that any NBC change in a submodule is reflected in the
version of the main module.  The submodule still retains its own
revision and description/reference.  Ultimately, the totality of the
module includes the submodules.  So with the tooling we discussed, one
would still be able to determine the NBC changes for the module schema
as a whole.

Joe

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Tue, 27 Nov 2018 13:42:23 +0000

Joe, I agree. I was trying to point out that we must have module-level semver indicate changes in any contained submodules. So having semver at submodule level seems pointless.

On 2018-11-27, 8:28 AM, "Joe Clarke (jclarke)" <[email-masked]> wrote:

    
    Joe

---

From: Benoit Claise <[email-masked]>
Date: Tue, 27 Nov 2018 15:16:14 +0100

> would still be able to determine the NBC changes for the module schema
+ 1.

Regards, B.

---

From: "Sterne, Jason (Nokia - CA/Ottawa)" <[email-masked]>
Date: Tue, 27 Nov 2018 22:21:41 +0000

I think it is OK if the module has an "aggregate" SemVer (i.e. if any submodule changed in an NBC way, then the module SemVer should increment the major SemVer digit).

But I *do* think it is useful to allow submodules to have different and independent SemVer.

Some data models are broken down into multiple modules. It is useful having a SemVer for each module so that programmers can quickly see what parts of the data model have changed. We wouldn't want purely an overall SemVer for the *package* of modules. It is useful for each module to have its own SemVer.

Similarly with a data model that is broken down into multiple submodules. It is useful to have information about which submodules changed, and whether that was BC or NBC.

Jason

> From: Reshad Rahman (rrahman) <[email-masked]>
> Sent: Tuesday, November 27, 2018 5:42 AM
> To: Joe Clarke (jclarke) <[email-masked]>; Sterne, Jason (Nokia -
> CA/Ottawa) <[email-masked]>; Ebben Aries <[email-masked]>
> Cc: Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)
> <[email-masked]>; [email-masked]
> Joe, I agree. I was trying to point out that we must have module-level
> semver indicate changes in any contained submodules. So having semver at
> submodule level seems pointless.
> 
> 
>     >     We *could* consider that the main module must indicate a BC change
> if any submodule has a BC change, and an NBC change if any submodule has
> an NBC change though. Although not sure that is necessary.
>     > <RR> Pretty sure it's necessary. Otherwise if a submodule has NBC
> change and the module version hasn't changed, we need to look at versions
> of all submodules to figure out whether NBC change took place in the
> module? A submodule is just a way to split a module in smaller pieces, and
> can't exist on its own.
> 
>     > On 2018-11-26, 6:20 PM, "Netmod-ver-dt on behalf of Sterne, Jason
> (Nokia - CA/Ottawa)" <[email-masked] on behalf of
> [email-masked]> wrote:
>     >
>     >     Hi guys,
>     >
>     >     I don't agree with enforcing that submodules have the same SemVer as
> the main module. There is no such rule for YANG version today.
>     >
>     >     When a data model is organized into submodules that allows someone
> to indicate what parts of the overall model changed (BC or NBC or not at all)
> with more granularity than just the entire superset module.
>     >
>     >     We *could* consider that the main module must indicate a BC change
> if any submodule has a BC change, and an NBC change if any submodule has
> an NBC change though. Although not sure that is necessary.
>     >
>     >     Jason
>     >

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 28 Nov 2018 10:38:36 +0100

> Similarly with a data model that is broken down into multiple submodules. It is useful to have information about which submodules changed, and whether that was BC or NBC.

The relationship between version numbers is somewhat subtle. If I move
a definition from submodule A to submodule B, then nothing has changed
semantically at the module level.  However, depending on how you
define BC and NBC at the submodule level, this may have been two NBC
changes. But what exactly that BC and NBC mean for a submodule? A
submodule does not exist in isolation and it is not at all clear how
our notion of BC and NBC for modules should be extended to submodules.

I regret that we made the mistake to make submodules a first class
citizen of YANG. They add quite some complexity for very little gain.
Since interoperability is defined in terms of a schema constructed out
of sets of YANG modules, submodules are not really important.

Hence, my recommendation is to stay away from submodule versions. But
if you go there, I agree it is best to assume that submodule versions
have a very loose relationship to module versions.

/js

---

From: Robert Wilton <[email-masked]>
Date: Wed, 28 Nov 2018 09:54:31 +0000

I agree with Juergen's comments below.

I would rather that we just say that submodule versions are out of scope 
at this time.   They are different.  I think that they are likely to 
cause confusion, and given the complexity of versioning anyway, I think 
that this is one are of complexity we should try and avoid at this time.

I also think that it would be quite easy for a vendor to define a 
submodule version extension statement, and augment the YANG library with 
a sub-module version.

Thanks,
Rob