Subject: [netmod] YANG revision dates unique in module ?

From: "Sterne, Jason (Nokia - CA/Ottawa)" <[email-masked]>
Date: Tue, 1 Jun 2021 13:36:09 +0000

Hi all,

In our YANG versioning work we are proposing that a revision-label is unique and the revision history of a module must not contain the same revision-label twice.

We're debating whether we should state the same rule for revision *date* as well.

RFC7950 doesn't seem to explicitly say that revision date must not be duplicated in the revision history.

This issue came up recently in an OpenConfig discussion here:
Updates to OpenConfig types modules. * openconfig/public@f20ed84 (github.com)<https://github.com/openconfig/public/commit/f20ed8411a6fc1f55c9debed55c852ea4ffef5bb#commitcomment-51076470>

Was it the intention of RFC7950 that a revision history should never have the same revision date twice ?

I think it is somewhat inferred from various drafts that describe how a module name + revision date uniquely identifies a module revision. But it doesn't seem to be explicitly stated in RFC7950.

If we disallow duplicate revision dates, that makes the module-name+date tuple unique, but it does mean that authors can't produce 2 versions of a module in the same day. In theory we *could* do something like this:
- require unique revision-labels
- allow duplicate revision dates

But in that case, only the module-name+revision-label can be the unique identifier for a revision.

Jason

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 1 Jun 2021 15:44:22 +0200

The assumption back then was indeed that an organization would not
_publish_ two revisions on the same date. Note the choice of the verb
'publish', which is not to be confused with edits made during
development, at least back then we made this distinction between
module development and module publication.

/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: Andy Bierman <[email-masked]>
Date: Tue, 1 Jun 2021 07:42:06 -0700

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

> Hi all,
>
>
>
> In our YANG versioning work we are proposing that a revision-label is
> unique and the revision history of a module must not contain the same
> revision-label twice.
>
>
>
> We're debating whether we should state the same rule for revision **date**
> as well.
>
>
>
> Updates to OpenConfig types modules. · openconfig/public@f20ed84
> (github.com)
> <https://github.com/openconfig/public/commit/f20ed8411a6fc1f55c9debed55c852ea4ffef5bb#commitcomment-51076470>
>
>
>

It seems that way.
How would the duplicates be distinguished within a server?
The server cannot advertise "foo@datestring" twice.
Import-by-revision cannot identify the 2 revisions with the same date.

Andy

>
> I think it is somewhat inferred from various drafts that describe how a
> module name + revision date uniquely identifies a module revision. But it
> doesn't seem to be explicitly stated in RFC7950.
>
>
>
> If we disallow duplicate revision dates, that makes the module-name+date
> tuple unique, but it does mean that authors can't produce 2 versions of a
> module in the same day. In theory we **could** do something like this:
>

---

From: Italo Busi <[email-masked]>
Date: Tue, 1 Jun 2021 19:31:13 +0000

I recall I raised a similar question in one of the previous meetings (in the context of the YANG file naming) and the answer I have got is that the revision-date is still required to be unique for a given YANG module

IMHO, this requirement was very reasonable for a linear module development (as per current RFC7950) but it would impose an unnecessary and error-prone process for parallel model development which is enabled by the use of revision labels

For example, let’s consider a case where, after releases 1.0.0, 1.1.0 and 1.2.0 have been published, a bug is discovered from R1.0.0  and therefore three bug-fixing releases (1.0.1, 1.1.1 and 1.2.1) needs to be published  “almost” at the same time with the same bug fix

The requirement for unique revision-date makes this impossible and the developer needs to publish these three released in three different days

IMHO, most of the people will not follow this rule and publish these three releases “almost” at the same time

The revision-date uniqueness requirement can be relaxed if a module revision is announced as "foo#revision-label" instead of as "foo@datestring"

Italo

From: Andy Bierman [mailto:[email-masked]]
Sent: martedì 1 giugno 2021 16:42
To: Sterne, Jason (Nokia - CA/Ottawa) <[email-masked]>
Cc: [email-masked]
Subject: Re: [netmod] YANG revision dates unique in module ?

On Tue, Jun 1, 2021 at 6:36 AM Sterne, Jason (Nokia - CA/Ottawa) <[email-masked]<mailto:[email-masked]>> wrote:
Hi all,

This issue came up recently in an OpenConfig discussion here:
Updates to OpenConfig types modules. · openconfig/public@f20ed84 (github.com)<https://github.com/openconfig/public/commit/f20ed8411a6fc1f55c9debed55c852ea4ffef5bb#commitcomment-51076470>

It seems that way.

Andy

Jason

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

---

From: Andy Bierman <[email-masked]>
Date: Tue, 1 Jun 2021 12:51:06 -0700

On Tue, Jun 1, 2021 at 12:31 PM Italo Busi <[email-masked]> wrote:

> I recall I raised a similar question in one of the previous meetings (in
> the context of the YANG file naming) and the answer I have got is that the
> revision-date is still required to be unique for a given YANG module
>
>
>
> IMHO, this requirement was very reasonable for a linear module development
> (as per current RFC7950) but it would impose an unnecessary and error-prone
> process for parallel model development which is enabled by the use of
> revision labels
>
>
>
> For example, let’s consider a case where, after releases 1.0.0, 1.1.0 and
> 1.2.0 have been published, a bug is discovered from R1.0.0  and therefore
> three bug-fixing releases (1.0.1, 1.1.1 and 1.2.1) needs to be published
> “almost” at the same time with the same bug fix
>
>
>
> The requirement for unique revision-date makes this impossible and the
> developer needs to publish these three released in three different days
>
>
>
> The revision-date uniqueness requirement can be relaxed if a module
> revision is announced as "foo#revision-label" instead of as "foo@datestring
> "
>

I will never be convinced that it is a feature for every platform to have a
different copy
of all the YANG modules, with the same names and revision dates.  This
strategy is
not helpful to client developers because they cannot easily reuse code
across server platforms.

I agree that a revision-label helps in the case where "foo@datestring" is
only unique
within a certain proprietary context (like per-platform variants).

I do not agree it was the intent in RFC 7950 to support such a requirement.

Andy

>
>
> Italo
>
>
>
> *From:* Andy Bierman [mailto:[email-masked]]
> *Sent:* martedì 1 giugno 2021 16:42
> *To:* Sterne, Jason (Nokia - CA/Ottawa) <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [netmod] YANG revision dates unique in module ?
>
>
>
>
>
>
>