Subject: [netmod] Materials for NETMOD Virtual Interim meeting (Monday)

From: "Sterne, Jason (Nokia - CA/Ottawa)" <[email-masked]>
Date: Fri, 11 Dec 2020 19:17:22 +0000

Hi all,

Enclosed are the materials for the Virtual Interim on Monday.  Have a good weekend!

Rgds,
Jason

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 11 Dec 2020 22:02:32 +0100

It may help to add a slide explaining the purpose YANG module
checksums have. In the packages I-D, there is an explanation what
package checksums are good for, but I have not found an explanation
why YANG module checksums are useful to have.

If the checksum is specific to a certain location (i.e., its scoped to
the location), then there is no need to have a universal checksum for
a YANG module. But it anyway, it would help to understand that the
purpose of the checksum is.

/js

> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

-- 
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: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 12 Dec 2020 14:47:17 +0100

If module A imports from module B, then the question whether a change
in module B is compatible or not for module A is answered by what
module A actually uses of module B's definitions. The question is not
answered by module B's version number.

The maintainer of module B can't tell whether her change breaks module
A without knowing A. And the maintainer of A can't predict how module
B will change in the future. As a consequence, the maintainer of A
cannot realiably decide whether revision-or-derived or
revision-or-derived-compatible is the right choice. The author of A
has to _guess_, having more options to guess may help, or it may
not. My point is that it is always a guess.

The maintainer of module B may be acting in a conservative way and
bumping major numbers frequently (and many times not affecting module
A) or maintainer B may be lenient - and B's decision may be influenced
by how central module B is, the more modules depend on B, the higher
the pressure to not bump the major version number of B and to either
avoid non-backwards compatible changes or to label them as compatible
(even though it is possible they are not).

In some realities, you end up with a need for more complex expressions
over the version number space to define which versions are known to
work together. And this information is often maintained _outside_ the
code artifacts (one advantage being that this makes dependency updates
possible without having to touch the files with the definitions). Some
examples:

https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html

https://cabal.readthedocs.io/en/latest/developing-packages.html#modules-imported-from-other-packages

https://semver.npmjs.com/

Given these examples, one can ask whether decorating the YANG import
statement with 'inline' versioning constraints is actually the right
way to go. Perhaps dependency constraints are better managed outside.

/js

---

From: Andy Bierman <[email-masked]>
Date: Sat, 12 Dec 2020 07:38:43 -0800

> not. My point is that it is always a guess.

It seems that SEMVER is a choice between a version that is not granular
enough
to be useful, and a version that is granular enough, but now there are so
many
versioned items that the system is unmanageable.

Taken to its logical extreme, every construct would need a semver and every
import would need to be at the granularity of 1 identifier.

The owner of module A can only update/fix the import of B after
the owner of B has finished breaking backward compatibility (or not).

This only invalidates the utility of the upper bound of semver,
e.g., the newest version of B that can be imported by A.

The fatal flaw in YANG imports has always been that import EXACT version
is too fragile to be useful.  When module A is written, the author knows
the MINIMUM VERSION of B that can be imported, yet YANG has no way to
express that.
For BC changes (which are the vast majority) this is sufficient.
Please just fix that.

Andy

---

From: Rahman <[email-masked]>
Date: Sun, 13 Dec 2020 22:17:33 -0500

Thanks for the comments. What you describe below is spot on and IMO is the reason why we have been going round in circles on this topic. We haven’t discussed specifying the version import constraints outside of the modules, but we should consider this approach (packages?).

Regards,
Reshad.

Sent from my iPhone

> On Dec 12, 2020, at 8:47 AM, Juergen Schoenwaelder <[email-masked]> wrote:
>

---

From: "Sterne, Jason (Nokia - CA/Ottawa)" <[email-masked]>
Date: Mon, 14 Dec 2020 17:17:46 +0000

Hi Andy,

I like the way you phrased it "too fragile to be useful".

I think that's a concern we'd also have with an "or-compatible" version of import by revision-or-derived.  Authors may use it "to be safe" (similar to how they may want to specify an exact vesion) but it would end up keeping everything to tightly in lock step.

With just the "revision-or-derived" we would solve the MINIMUM VERSION problem, but then leave all the other complexities of compatible versions outside the scope of import statements.  (e.g. solve that with information outside the modules themselves like Packages).

Jason

From: Andy Bierman <[email-masked]>
Sent: Saturday, December 12, 2020 10:39 AM
To: Juergen Schoenwaelder <[email-masked]>; Sterne, Jason (Nokia - CA/Ottawa) <[email-masked]>; [email-masked]
Subject: Re: [netmod] Materials for NETMOD Virtual Interim meeting (Monday)

On Sat, Dec 12, 2020 at 5:47 AM Juergen Schoenwaelder <[email-masked]<mailto:[email-masked]>> wrote:

It seems that SEMVER is a choice between a version that is not granular enough
to be useful, and a version that is granular enough, but now there are so many
versioned items that the system is unmanageable.

The fatal flaw in YANG imports has always been that import EXACT version
is too fragile to be useful.  When module A is written, the author knows
the MINIMUM VERSION of B that can be imported, yet YANG has no way to express that.
For BC changes (which are the vast majority) this is sufficient.
Please just fix that.

Andy

/js

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

_______________________________________________
netmod mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netmod

---

From: Andy Bierman <[email-masked]>
Date: Mon, 14 Dec 2020 13:30:31 -0800

> I like the way you phrased it "too fragile to be useful".
It seems intuitively obvious that determining compatibility with versions
that may exist in the future is mostly speculation.

Also obvious: there is little benefit writing automation code to determine
"X will work" if
you still have to write the code to implement X and check for errors. Might
as well just try X
and determine if it did or did not work.

>
> I think that's a concern we'd also have with an "or-compatible" version of
> import by revision-or-derived.  Authors may use it "to be safe" (similar to
> how they may want to specify an exact vesion) but it would end up keeping
> everything to tightly in lock step.
>
>
>
> With just the "revision-or-derived" we would solve the MINIMUM VERSION
> problem, but then leave all the other complexities of compatible versions
> outside the scope of import statements.  (e.g. solve that with information
> outside the modules themselves like Packages).
>

A common use case is for shared data types like ietf-yang-types.
If the module uses "hex-string" then the RFC 6991 version must be found
or else the RFC 6021 version can be used.

I support the extensions for the import-stmt that help the compiler find
the right version.  Although not a good practice, in this case the
"import-without-revision"
semantics are not changed if an extension is used to restrict the search
for the import.

Andy

>
>
> *From:* Andy Bierman <[email-masked]>
> *Sent:* Saturday, December 12, 2020 10:39 AM
> *To:* Juergen Schoenwaelder <[email-masked]>;
> Sterne, Jason (Nokia - CA/Ottawa) <[email-masked]>;
> [email-masked]
> *Subject:* Re: [netmod] Materials for NETMOD Virtual Interim meeting
> (Monday)
>
>
>
>
>
>
>

---

From: Jan Lindblad <[email-masked]>
Date: Wed, 16 Dec 2020 15:31:17 +0100

Hi all,

Thank you for your contributions to the versioning+whitespace discussions here on the list and on the interim Monday. 

In short, the discussions did not really lead us any closer to consensus around the whitespace related questions raised. In order to move on, the versioning subgroup decided yesterday that for the continued work on the versioning drafts, YANG module integrity & veracity will be moved out of scope. This means we will remove all forms of module checksums from the drafts and leave that as future work. Hopefully that should make it easier to conclude the versioning work.

Best Regards,
/jan

> On 11 Dec 2020, at 20:17, Sterne, Jason (Nokia - CA/Ottawa) <[email-masked]> wrote:
> 
> Hi all,
>  
> <Versioning Interim 20201214 Imports v3.pptx><Versioning Interim 20201214 Whitespace.pptx>_______________________________________________
> netmod mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/netmod <https://www.ietf.org/mailman/listinfo/netmod>