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

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 <netmod-bounces@ietf.org> On Behalf Of Andy Bierman
Sent: 01 March 2022 14:49
To: William Lupton <wlupton@broadband-forum.org>
Cc: NetMod WG <netmod@ietf.org>
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 <wlupton@broadband-forum.org<mailto:wlupton@broadband-forum.org>> 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/iana-if-type@2021-06-21.yang>: 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
netmod@ietf.org<mailto:netmod@ietf.org>
https://www.ietf.org/mailman/listinfo/netmod