Re: [netmod] iana-if-type.yang has multiple revisions with the same date

[Andy Bierman <[e-mail]>]

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) <[e-mail]>
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 <[e-mail]> *On Behalf Of *Andy Bierman
> *Sent:* 01 March 2022 14:49
> *To:* William Lupton <[e-mail]>
> *Cc:* NetMod WG <[e-mail]>
> *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 <[e-mail]>
> 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/[e-mail]>:
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod
>
>