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

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:andy@yumaworks.com]
Sent: martedì 1 giugno 2021 16:42
To: Sterne, Jason (Nokia - CA/Ottawa) <jason.sterne@nokia.com>
Cc: netmod@ietf.org
Subject: Re: [netmod] YANG revision dates unique in module ?

On Tue, Jun 1, 2021 at 6:36 AM Sterne, Jason (Nokia - CA/Ottawa) <jason.sterne@nokia.com<mailto:jason.sterne@nokia.com>> 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.

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 ?

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

_______________________________________________
netmod mailing list
netmod@ietf.org<mailto:netmod@ietf.org>
https://www.ietf.org/mailman/listinfo/netmod