Subject: [Netmod-ver-dt] Balazs Review of draft-verdt-netmod-yang-semver-01

From: Balázs Lengyel <[email-masked]>
Date: Fri, 13 Sep 2019 13:34:47 +0000

Hello Joe,

Some comments:

General: I would like this to be merged with module-versioning. 

*	I would like this to be main-stream. It may be optional, but it
should be the single recommended scheme.
*	Putting restrictions on “other” schemes that use the revision label
can not be enforced. If they don’t support this draft/RFC they will never
know what they are not allowed to do.
*	A YANG module with a single typedef looks really strange.

After workgroup adoption I would raise this issue again.

Ch 1) 

Add something like:

“The goal is to add a human readable version label that provides
compatibility information for the module without comparing or parsing the
module’s body.”

This is the whole reason to create this draft.

Ch 2. And General) We really need to give our versioning scheme a “name” and
refer to it as such. I propose “yangver”.

Ch 3.1 paragraph after the bullets)

Do we need to specify different metadata  types? Or is this text directly
from semver?

Reword as it is hard to understand:

Old text:

   Versioning schemes that are not this modified semver MUST NOT use

   this same version pattern.  Other schemes may, for example, use

   additional leading characters to distinguish them from this semantic

   versioning scheme.

New text:

   Other version schemes MUST use versioning strings that do not match the
format and the pattern specified for yangver , e.g. use

   additional leading characters to distinguish them from yangver.

Ch 3.4.2) I have not read the package draft recently, but does this example
imply that a package has a single revision-label? IMHO for each revision a
description, reference and revision label is needed.

Ch 4) Shouldn’t we allow any BC version to be used for import even if it is
not in the revision history.

Ch 5.) I would find a more descriptive name for the typedef e.g. yangver

Regards Balazs

-- 

Balazs Lengyel                    Senior Specialist
Ericsson Hungary Ltd. 

Mobile: +36-70-330-7909              email: [email-masked]

---

From: "Joe Clarke (jclarke)" <[email-masked]>
Date: Fri, 13 Sep 2019 13:54:57 +0000

On Sep 13, 2019, at 09:34, Balázs Lengyel <[email-masked]<mailto:[email-masked]>> wrote:

Hello Joe,
Some comments:

  *   I would like this to be main-stream. It may be optional, but it should be the single recommended scheme.

I like keeping this separate and having the label schemes modular.  This is especially true when you consider other consumers like packages.

  *
  *   Putting restrictions on “other” schemes that use the revision label can not be enforced. If they don’t support this draft/RFC they will never know what they are not allowed to do.

That’s fair.  This text is a restatement of what will also be in module-versioning, and may become just a reference to there.  If one uses the revision label concept, then, they would know that the semver pattern is reserved.

  *

I agree, but maybe no more odd than a single extension statement.  We discussed perhaps making this part of the module version module, but since you have packages as consumers, breaking it out might be okay.  We saw similar things when they packed yang-data into RESTCONF.

I’ll review your inline changes as I make further changes to the text today.  Thanks for the review!

Joe

  *

Ch 1)
Add something like:
“The goal is to add a human readable version label that provides compatibility information for the module without comparing or parsing the module’s body.”
This is the whole reason to create this draft.

Ch 2. And General) We really need to give our versioning scheme a “name” and refer to it as such. I propose “yangver”.

Ch 3.1 paragraph after the bullets)
Do we need to specify different metadata  types? Or is this text directly from semver?

   Other version schemes MUST use versioning strings that do not match the format and the pattern specified for yangver , e.g. use

Ch 3.4.2) I have not read the package draft recently, but does this example imply that a package has a single revision-label? IMHO for each revision a description, reference and revision label is needed.

Ch 4) Shouldn’t we allow any BC version to be used for import even if it is not in the revision history.

Regards Balazs

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

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

---

From: "Joe Clarke (jclarke)" <[email-masked]>
Date: Fri, 13 Sep 2019 20:05:40 +0000

Ch 1)
Add something like:

Thanks.  I incorporated some of this.  Please let me know if you like it.

I left this as an open item for discussion.  I personally like yangver.  It gets auto-corrected to “hangover” on the Mac :-).

Yes, this comes directly from server.org<http://server.org>.

Thanks!  The original text was a pain.  I tweaked it based on your recommendation.

I don’t follow this exactly.  Each revision of a package will have its own revision label, reference, and description.

Good question.  I left that open to the team.

If we settle on yangver, I’ll update the prefix.  Then it would typically be written as yangver:version.  Would that be sufficient?

Joe

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Tue, 17 Sep 2019 14:00:26 +0000

Hi Balazs,

Please see further comments inline ...

From: Netmod-ver-dt <[email-masked]> On Behalf Of Balázs Lengyel
Sent: 13 September 2019 14:35
To: [email-masked]
Subject: [Netmod-ver-dt] Balazs Review of draft-verdt-netmod-yang-semver-01

Hello Joe,
Some comments:
General: I would like this to be merged with module-versioning.
[RW]
I don't think that we should do this.  I'm pretty sure that both Martin and Andy would strongly object to this, so I think that this would end up just slowing the work down.

-        I would like this to be main-stream. It may be optional, but it should be the single recommended scheme.
[RW]
I agree that it should be mainstream, and should be the single recommended scheme.  But I think that it is OK to allow other labels/schemes.

-        Putting restrictions on "other" schemes that use the revision label can not be enforced. If they don't support this draft/RFC they will never know what they are not allowed to do.
[RW]
Agreed.  The plan is to write this restriction into the parent module-versioning draft.  I will send proposed/text updated doc soon.

-        A YANG module with a single typedef looks really strange.
After workgroup adoption I would raise this issue again.

Ch 1)
Add something like:
"The goal is to add a human readable version label that provides compatibility information for the module without comparing or parsing the module's body."
This is the whole reason to create this draft.

Ch 2. And General) We really need to give our versioning scheme a "name" and refer to it as such. I propose "yangver".
[RW]
I've been calling in "YANG semantic versioning".  If we want a shorter name for it, perhaps "yang-semver" would be a bit more descriptive.

Ch 3.4.2) I have not read the package draft recently, but does this example imply that a package has a single revision-label? IMHO for each revision a description, reference and revision label is needed.
[RW]
Each instance (i.e. version) of a YANG package has a single "revision-label" (actually called "version" in the latest package draft).

At the moment, it is proposed that YANG packages do not need to record the full revision history as part of the package definition.  They just store the current version, and also the previous one, allowing a full revision tree to be constructed, if required.

Thanks,
Rob

Ch 4) Shouldn't we allow any BC version to be used for import even if it is not in the revision history.

Regards Balazs