Subject: [netmod] YANG Versioning Weekly Call Minutes - 2021-06-08

From: "Sterne, Jason (Nokia - CA/Ottawa)" <[email-masked]>
Date: Tue, 8 Jun 2021 17:39:25 +0000

YANG Versioning Weekly Call Minutes - 2021-06-08

Submodule vs Module in module versioning draft:
- avoid 'artifact', put "submodule or module" everywhere it is applicable
- Reshad: add "or submodules" in most places.

Non duplicate revision dates:
- revision-label is just another label for that revision date
- we won't say anything in our drafts about non-duplicate revision dates in a revision history. This is something for YANG NEXT.

YANG SemVer Draft - IETF 110 feedback

Raise github issue in verdt *and* against pyang to flag when a module or submodule is missing a revision label

Raise github issue to review the IANA guidelines (in our 2 drafts) with IANA folks

We discussed pre-release version precedence
- can't assume precedence of pre-release versions
- wipe out the pre-release revision history when publishing the final version (SHOULD) ?  or when publishing each pre-release version? Put this guidance in Module Revision Handling (instead of Semver ?)
- Joe to propose wording

Rgds,
Jason

----------------------------------------------
Weekly webex call details:
Meeting number (access code): 171 069 0374
Meeting password: semver?
Occurs every Tuesday effective Tuesday, September 1, 2020 until Tuesday, August 24, 2021 from 9:00 AM to 10:00 AM, (UTC-04:00) Eastern Time (US & Canada)
9:00 am  |  (UTC-04:00) Eastern Time (US & Canada)  |  1 hr
https://ietf.webex.com/ietf/j.php?MTID=ma7627a2ae7b770537cff5f5b89293c70
Tap to join from a mobile device (attendees only)
+1-650-479-3208,,1710690374## Call-in toll number (US/Canada)

---

From: Andy Bierman <[email-masked]>
Date: Tue, 8 Jun 2021 10:48:54 -0700

On Tue, Jun 8, 2021 at 10:39 AM Sterne, Jason (Nokia - CA/Ottawa) <
[email-masked]> wrote:

> - we won't say anything in our drafts about non-duplicate revision dates
> in a revision history. This is something for YANG NEXT.
>
>
>

Can you find any text in RFC 7950 that says that a module
with a specific name and revision date can refer to multiple YANG modules?
It seems like the opposite is true -- that if the name and revision date
are the
same then they refer to the same specific module.

Andy

> - wipe out the pre-release revision history when publishing the final
> version (SHOULD) ?  or when publishing each pre-release version? Put this
> guidance in Module Revision Handling (instead of Semver ?)
>
> - Joe to propose wording
>
>
>
> Rgds,
>
> Jason
>
>
>
> Occurs every Tuesday effective Tuesday, September 1, 2020 until Tuesday,
> August 24, 2021 from 9:00 AM to 10:00 AM, (UTC-04:00) Eastern Time (US &
> Canada)
>
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>

---

From: "Sterne, Jason (Nokia - CA/Ottawa)" <[email-masked]>
Date: Tue, 8 Jun 2021 18:00:49 +0000

Hi Andy,

Nothing in RFC7950 says duplicates are allowed. We don't plan to change that (or particularly say anything about it) in any of our YANG revision work.

But maybe in YANG NEXT, *if* a Semver-like revision label was adopted as the main identifier (and revision date just becomes a non-key attribute), i.e. yang library was changed to use revision label instead of revision date, then two versions could be allowed on the same date.  But that's for a YANG NEXT discussion.

Jason

From: Andy Bierman <[email-masked]>
Sent: Tuesday, June 8, 2021 1:49 PM
To: Sterne, Jason (Nokia - CA/Ottawa) <[email-masked]>
Cc: [email-masked]
Subject: Re: [netmod] YANG Versioning Weekly Call Minutes - 2021-06-08

On Tue, Jun 8, 2021 at 10:39 AM Sterne, Jason (Nokia - CA/Ottawa) <[email-masked]<mailto:[email-masked]>> wrote:
YANG Versioning Weekly Call Minutes - 2021-06-08

Can you find any text in RFC 7950 that says that a module
with a specific name and revision date can refer to multiple YANG modules?
It seems like the opposite is true -- that if the name and revision date are the
same then they refer to the same specific module.

Andy

Rgds,
Jason

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

---

From: Andy Bierman <[email-masked]>
Date: Wed, 9 Jun 2021 15:27:09 -0700

On Tue, Jun 8, 2021 at 11:00 AM Sterne, Jason (Nokia - CA/Ottawa) <
[email-masked]> wrote:

> Hi Andy,
>
>
>
> Nothing in RFC7950 says duplicates are allowed. We don't plan to change
> that (or particularly say anything about it) in any of our YANG revision
> work.
>
>
>
> But maybe in YANG NEXT, **if** a Semver-like revision label was adopted
> as the main identifier (and revision date just becomes a non-key
> attribute), i.e. yang library was changed to use revision label instead of
> revision date, then two versions could be allowed on the same date.  But
> that's for a YANG NEXT discussion.
>

If we were having a YANG-Next discussion, I would certainly agree that
YANG 2.0 should officially use module-name + revision-label and not use
revision-date as a module identifier at all.

Although non-intuitive, creating a new version of YANG is actually more
backward-compatible than continually adding ad-hoc bits and pieces to YANG
1.1.
A new language version allows NBC changes to be clearly identified,
and lots of NBC changes (like revision-label) are needed to take YANG to
the next level.
Attempts to fix major problems indirectly (e.g. YANG extensions) will fail
in the long run.

Good thing we are not discussing YANG-next...

Andy

>
>
> *From:* Andy Bierman <[email-masked]>
> *Sent:* Tuesday, June 8, 2021 1:49 PM
> *To:* Sterne, Jason (Nokia - CA/Ottawa) <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [netmod] YANG Versioning Weekly Call Minutes - 2021-06-08
>
>
>
>
>
>
>

---

From: "Sterne, Jason (Nokia - CA/Ottawa)" <[email-masked]>
Date: Fri, 11 Jun 2021 20:12:05 +0000

I raised an issue in the verdt project about pyang checking for revision-label:
pyang --ietf should check if a module has a revision-label * Issue #99 * netmod-wg/yang-ver-dt (github.com)<https://github.com/netmod-wg/yang-ver-dt/issues/99>

From: netmod <[email-masked]> On Behalf Of Sterne, Jason (Nokia - CA/Ottawa)
Sent: Tuesday, June 8, 2021 1:39 PM
To: [email-masked]
Subject: [netmod] YANG Versioning Weekly Call Minutes - 2021-06-08

Rgds,
Jason

---

From: Kent Watsen <[email-masked]>
Date: Mon, 14 Jun 2021 10:34:28 +0000

> Good thing we are not discussing YANG-next...

Sarcasm?  ;)

I do wonder if it’s not about time we make another go at that effort...perhaps a 111-hum on interest?

That said, there’s a world apart from WG-interest and author-commitments.

In either case, said effort wouldn’t complete for some time, which may be disagreeable to the versioning rollout. 

Kent

---

From: Andy Bierman <[email-masked]>
Date: Mon, 14 Jun 2021 07:19:37 -0700

> > Good thing we are not discussing YANG-next...

No. The NETMOD WG has repeatedly decided not to produce a new YANG language
version in which the yang-version string is changed.

> disagreeable to the versioning rollout.

I agree there is little WG interest for this work.

Andy

---

From: Kent Watsen <[email-masked]>
Date: Mon, 14 Jun 2021 16:38:03 +0000

> version in which the yang-version string is changed. 

That’s not possibly true.   It's a matter of “when", not “if”, unless you’re anticipating YANG moving to HISTORIC.

K.

---

From: Andy Bierman <[email-masked]>
Date: Mon, 14 Jun 2021 10:01:34 -0700

On Mon, Jun 14, 2021 at 9:38 AM Kent Watsen <[email-masked]> wrote:

> That’s not possibly true.   It's a matter of “when", not “if”, unless
> you’re anticipating YANG moving to HISTORIC.
>
>
I meant the current work is using extensions instead of new language
statements.
Not that the yang-version will never be changed in the future.

It is not a matter of "when" if new functionality is added via extensions.
In theory the WG could add new functionality to YANG 1.1 this way for years.
In practice it might be difficult to achieve widespread interoperability if
nobody
agrees what "YANG next"  actually contains. Also, YANG 1.1 clearly says a
tool MAY
skip over and ignore ANY external statement, so it is problematic to use
extension-stmt
as if it was defining real statements. It is better to have a tool clearly
fail
with an "unsupported YANG version" error than it is to silently ignore
external statements.

K.
Andy

---

From: Kent Watsen <[email-masked]>
Date: Mon, 14 Jun 2021 17:16:37 +0000

> I meant the current work is using extensions instead of new language statements.

Ah, okay.

> In practice it might be difficult to achieve widespread interoperability if nobody
> agrees what "YANG next"  actually contains. Also, YANG 1.1 clearly says a tool MAY
> skip over and ignore ANY external statement, so it is problematic to use extension-stmt
> as if it was defining real statements. It is better to have a tool clearly fail
> with an "unsupported YANG version" error than it is to silently ignore external statements.

Agreed.

K.

---

From: "Sterne, Jason (Nokia - CA/Ottawa)" <[email-masked]>
Date: Mon, 14 Jun 2021 17:40:43 +0000

Hi guys,

I can understand that concern; and in particular for something like the new import by "revision-or-derived". Ignoring that extension can mean tools may not build the right schema (although is that any worse than today without using import by revision ?).

Despite that issue, I'd still advocate for revision-or-derived to be taken to standard now. It is part of a few things that cause problems today that really need to be addressed in the short term.

But for things like the rev:non-backwards-compatible tag, and using YANG semver, do those actually cause any new problems (vs what they help solve) ? It doesn't cause tools to build the wrong thing, or servers to implement the wrong thing.  It only helps supply information about what is already happening today (particularly in vendor modules, but also in standard modules) that isn't being described at all (NBC changes that really do impact the client, but the module name is kept the same). The WG had a fair bit of discussion 2-3 years ago that this versioning work was needed and should be adopted and progressed. That is still the case IMO.

Jason

> -----Original Message-----
> From: Kent Watsen <[email-masked]>
> Sent: Monday, June 14, 2021 1:17 PM
> To: Andy Bierman <[email-masked]>
> Cc: Sterne, Jason (Nokia - CA/Ottawa) <[email-masked]>;
> [email-masked]

---

From: Andy Bierman <[email-masked]>
Date: Mon, 14 Jun 2021 10:55:19 -0700

On Mon, Jun 14, 2021 at 10:40 AM Sterne, Jason (Nokia - CA/Ottawa) <
[email-masked]> wrote:

> Hi guys,
>
> I can understand that concern; and in particular for something like the
> new import by "revision-or-derived". Ignoring that extension can mean tools
> may not build the right schema (although is that any worse than today
> without using import by revision ?).
>
> Despite that issue, I'd still advocate for revision-or-derived to be taken
> to standard now. It is part of a few things that cause problems today that
> really need to be addressed in the short term.
>
> But for things like the rev:non-backwards-compatible tag, and using YANG
> semver, do those actually cause any new problems (vs what they help solve)
> ? It doesn't cause tools to build the wrong thing, or servers to implement
> the wrong thing.  It only helps supply information about what is already
> happening today (particularly in vendor modules, but also in standard
> modules) that isn't being described at all (NBC changes that really do
> impact the client, but the module name is kept the same). The WG had a fair
> bit of discussion 2-3 years ago that this versioning work was needed and
> should be adopted and progressed. That is still the case IMO.
>
>
The all-or-none approach to the versioning work is producing more "none"
than "all". ;-)

YANG was designed to be used in a linear and singular release train.
This is clearly not the way the real world can use YANG.
Ignoring this pain point is making the problem worse over time.

There are many corner-cases that the DT is spending a lot of time on that
do not cause the deployment problems that a revision label could solve.

My original point: Fix this problem with the best engineering solution
possible
even if that means a new YANG language version.  Import-by-semver should
not be super-complicated and it should not be optional for a compiler to
use.

Import-by-exact-revision is flawed and not worth preserving.

Jason

Andy