Hi, Vendors (including YumaWorks) have been violating the [name, date] uniqueness rule for about a decade. This is because vendors do not release YANG modules independently from software. Only SDOs do that.
A common software release train model (obsolete, oldstable, stable, latest, testing) shows how a YANG module with the same date ends up in multiple release trains. - Obsolete release trains do not get any module updates at all - Oldstable modules usually only get changed for serious bugfixes. - Stable modules usually only get changed for bugfixes and minor enhancements - Latest modules get all bugfixes and all new features - Testing is work-in-progress and the version tracking is not useful during this phase since the modules and code are unstable and subject to many changes Consider a simple use-case: a bugfix in a leaf is added to the oldstable release train This is then merged downstream into each subsequent release train. It is impractical and misleading to give each updated release train a different revision date. This may break client applications and break import-by-revision in other modules. IMO a practical solution is to add a leaf to the yang-library list entries called "need-get-schema" (or whatever) that tells the client that the [name, date] is not globally unique and the <get-schema> operation should be used to retrieve the module used on this server with that tuple. Andy On Fri, Mar 4, 2022 at 6:53 AM Rob Wilton (rwilton) <[email protected]> wrote: > Hi Andy, > > > > On this specific point: > > > > Note that with multiple release trains and the new SERMVER, it is likely > > that multiple [name, date, label] tuples resolve to the same [name, date] > pair, > > making the uniqueness problem even worse. > > > > The module versioning draft explicitly disallows this. Even when using > revision-labels/Semver there is a requirement that they are separate > revision modules with unique revision dates. > > > > Specifically, it contains this text: > > > > In addition, this document uses the following terminology: > > > > o YANG module revision: An instance of a YANG module, *uniquely* > > * identified with a revision date*, with no implied ordering or > > backwards compatibility between different revisions of the same > > module. > > > > This document clarifies [RFC7950] and [RFC6020] to explicitly allow > > non-linear development of YANG module and submodule revisions, so > > that they MAY have multiple revisions that directly derive from the > > same parent revision. *As per [RFC7950] and [RFC6020], YANG module* > > * and submodule revisions continue to be uniquely identified by their* > > * revision date, and hence all revisions of a given module or submodule* > > * MUST have unique revision dates.* > > > > And for revision labels: > > > > Revision labels MUST be unique amongst all revisions of a > > module or submodule. > > > > Regards, > > Rob > > // As an author/contributor. > > > > > > > > *From:* netmod <[email protected]> *On Behalf Of *Andy Bierman > *Sent:* 01 March 2022 14:49 > *To:* William Lupton <[email protected]> > *Cc:* NetMod WG <[email protected]> > *Subject:* Re: [netmod] iana-if-type.yang has multiple revisions with the > same date > > > > > > > > On Tue, Mar 1, 2022 at 4:54 AM William Lupton <[email protected]> > wrote: > > All, > > > > Sorry if (as is quite likely) this is a duplicate. > > > > I noticed from > https://yangcatalog.org/private-page/BBFYANGPageCompilation.html that > there's a (long-standing?) problem in iana-if-type.yang > <https://www.iana.org/assignments/yang-parameters/[email protected]>: > it has multiple revision statements with the same date: > > > > revision 2018-06-28 { > description > "Registered ifType 294."; > } > > revision 2018-06-28 { > description > "Registered ifType 293."; > } > > This has presumably happened as a result of an automated update script > that doesn't check for this case (*)? From a quick scan, I didn't see > anything in RFC 7950 banning duplicate revision dates, but RFC 8407 section > 4.8 says "*If the module contents have changed, then the revision date of > that new module version MUST be updated to a date later than that of the > previous version*" and of course yangdump-pro is checking this. > > > > I think that this should be fixed. What's the best way to achieve this? > > > > I think this issue should be resolved as well. > > The YANG library identifies each module by a [name, date] tuple. > > The <get-schema> operation uses this tuple to identify a specific revision > to retrieve. > > The import-by-revision mechanism uses this tuple to identify a specific > revision to import. > > > > If this [name, date] tuple is not unique, then it cannot be mapped to a > single module revision. > > > > Note that with multiple release trains and the new SERMVER, it is likely > > that multiple [name, date, label] tuples resolve to the same [name, date] > pair, > > making the uniqueness problem even worse. > > > > This is quite significant if a client reads the YANG library from a server > > and decides it already has the module cached (based on the [name, date] > tuple, > > as defined in the standard. Then it will not use the <get-schema> > operation > > to retrieve the module from the server. > > > > YANG artifacts and SID files also rely on this [name, date] tuple > uniqueness. > > > > Even with the new versioning drafts, it is impossible for the client to > know > > "Do you mean the REAL module foo, version xxxx-xx-xx, or your private > version?" > > > > > > Thanks, > > William > > > > Andy > > > > > > (*) In the rare event that multiple changes are made in the same day, > perhaps the second change should be (strictly wrongly) assigned to the > following day. In theory this could cause revision dates to run far into > the future but in practice I don't think this will happen :). > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod > >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
