On Tue, Jun 1, 2021 at 12:31 PM Italo Busi <italo.b...@huawei.com> 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 > > > > 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 > " > 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:a...@yumaworks.com] > *Sent:* martedì 1 giugno 2021 16:42 > *To:* Sterne, Jason (Nokia - CA/Ottawa) <jason.ste...@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.ste...@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 > https://www.ietf.org/mailman/listinfo/netmod > >
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
